Sur la route d'Oxiane digressions diverses

On a tous passé des heures et des week ends sur une propale ou un document qu’on a évidemment ni mailé, ni backupé, et dont on est si fier.

Pour plus de praticité, celui-ci est sur une clé usb et tout va pour le mieux dans le meilleur des mondes quand arrive la relecture du lundi matin par un nouvel intervenant.

Or voila, un raccourci clavier trop rapide et c’est le drame, la propale part dans les limbes de la micro informatique.

Oui je sais c’était couru, je n’ai qu’à utiliser les serveurs internes, le cloud, le wiki, du Google doc ou que sais-je encore, toujours est t-il que le fruit de mon intellect n’est plus et que je ne suis pas sûr de retranscrire tout de tête.

Vous êtes tristes hein vous aussi ?

Que faire si vous voulez conserver vos cheveux, réparer l’erreur et pas spécialement dépenser d’argent ?

Voici un undelete bien salvateur : http://www.easeus.com/datarecoverywizard/free-data-recovery-software.htm

Version gratuite jusqu’à 1 Go, oui je sais VOS propales sont plus grosses mais ca doit être les images

Si j’arrive à l’utiliser alors que je scratche si facilement un document important, le commun des mortels devrait pouvoir aussi.

Ca ne vous dispense pas des bonnes pratiques pour autant

Pour cette fois, le JUG Montpellier délaisse Java et tout ce qui tourne autour (Android, Spring, Liferay, SOA ou WebLogic par exemple) pour s’ouvrir à d’autres horizons : les interfaces web en 2011.

La soirée de la semaine dernière était décomposée en 2 parties.

Une première montrait les évolutions des interfaces utilisateurs, en faisant un rappel des grands principes d’ergonomie, de graphisme, ou d’expérience utilisateur.

J’ai bien apprécié l’évolution technologique du web

• dans les années 1990, on a fait du HTML + CSS + JAVASCRIPT et l’on appelait cela du DHTML,
• dans les années 2000, on a fait du HTML + CSS + JAVASCRIPT et l’on appelait cela de l’AJAX,
• dans les années 2010, on va faire du HTML + CSS + JAVASCRIPT et l’on va appeler cela de l’HTML 5.

C’est un peu carricatural et réducteur mais comme dirait l’autre « C’est pas faux« .

Une autre évolution est aussi liée à la diversité des écrans, euh des plateformes : mobile, tablette, netbooks, …

La deuxième partie était consacrée à l’accesibilité des interfaces web
La présentation a commencé par une démonstration qui nous montre sur des sites grands publics ce que « voit » un aveugle aidé par une assistance vocale et là c’est le drame …
Des sites constitués en grande majorité d’images sans texte ou de liens associés, et l’on se retrouve tel une personne en fauteuil roulant dans les couloirs du métro : impossible d’aller bien loin.

Ceci à permis de nous sensibiliser et de démontrer l’intérêt de l’accessibilité pour toutes les personnes en situtation d’handicap.
Les avantages de rendre son site accessible sont multiples :

• un meilleur référencement par les moteurs de recherche,
• une meilleure ergonomie,
• et une conformité avec la loi sur l’handicap de 2005 qui « obligent » tous les sites web publics à être accessibles.

Mais accessible cela veut dire quoi concrètement ?

On peut déjà parler qu’il y a différents niveaux et atteindre le niveau bronze constitue déjà une gageure, surtout lorsque l’on décide de vouloir atteindre ce niveau après la réalisation du site. Eh oui, connaitre les règles du jeu après avoir jouer rend plus difficile la gagne.

On peut décomposer les règles à respecter en 13 thématiques :

• images
• frames
• couleurs (contraste, la couleur ne doit pas être le seul moyen de porter l’information, …)
• multimédia (pouvoir contrôler une piste audio ou vidéo : pause, stop, …)
• tableau
• liens (pas de lien vide, …)
• scripts
• sémantique des balises
• balises titres
• css (pied, em, % sont les seules valables)
• form (bouton « ok » c’est beau mais cela manque d’informations)
• navigation
• le reste (clignotement autorisé si l’on peut l’éteindre)

Ces règles sont nombreuses (plus de 300) et à réaliser sur chaque page du site …

Un logiciel libre Tanaguru (.com) peut nous aider sur certaines règles automatisables mais elles ne le sont pas toutes, loin de là.

Voilà un critère de plus à prendre en compte dans nos applications si « on » veut bien y mettre un minimum de budget.

Enfin !

Certains attendaient ça depuis … la version alpha 1

JQuery Mobile est sorti enfin en version 1.0 ! On peut retrouver toutes les infos sur le site dédié.

Je vous laisse parcourir le blog en anglais mais je peux déjà faire quelques remarques :

- WHOAH ! j’ouvre le site de démo sous Firefox 8 sous windows … et là je prends une baffe : un layout de type fragment Android ! L’impression se confirme sur les pages suivantes, on va voir les démos de listes, aussi variés qu’utiles … c’est propre ! Ca s’annonce déjà très bien pour les tablettes… l’API se dit compatible Galaxy 10.1 et on a pas de mal à le croire. Pour avoir testé notre propre site mobile en RC1 (je crois) sur une tablette, c’est une belle initiative !

- HO ! Un Theme Roller pour mobile ??? Sérieux ? C’est une tuerie ça aussi … en fait je n’étais pas collé à mes tweets jquery depuis quelques semaines, alors c’est une grosse surprise, une deuxième baffe quoi ! La baffe est d’autant plus violente que c’est un outil loin d’être minable … des options dans tous les sens, du drag and drop pour les couleurs … gestion des arrondis

- Vous voyez ce que je vois en haut du Theme Roller ? Je vous ai assez cassé les oreilles avec ça, Adobe est dans la place, ils ont déjà montré leur intérêt pour cette API mobile et on retrouve leur sympathique Kuler pour générer des jeux de couleurs cohérents afin de ne pas casser les yeux de vos visiteurs … ou afin de le faire volontairement, c’est selon. C’est d’ailleurs à Adobe que l’on doit une partie du développement de l’outil lui même.

- Des ressources en pagaille, il faut dire que la version 1.0 sort à la suite d’une expérience maintenant assez longue, pas étonnant de retrouver autant de gens impliqués. Articles, extensions, livres, outils, plugins, frameworks … vous avez de quoi y passer de belles soirées !

Voici les liens officiels de cette version :

Download

CDN-Hosted JavaScript:

• Uncompressed: jquery.mobile-1.0.js (useful for debugging)
• Minified and Gzipped: jquery.mobile-1.0.min.js (24KB, ready to deploy)

CDN-Hosted CSS:

• Uncompressed with Default theme: jquery.mobile-1.0.css (useful for debugging)
• Minified and Gzipped with Default theme: jquery.mobile-1.0.min.css (7KB, ready to deploy)
• Uncompressed structure without a theme: jquery.mobile.structure-1.0.css (useful for theme development)
• Minified and Gzipped structure without a theme: jquery.mobile.structure-1.0.min.css (6KB, ready to deploy)

Je termine par une ouverture sur un « concurrent » si on peut dire. J’ai testé le développement sous sencha touch, et j’ai très vite été rebuté ! Construire une simple liste à partir d’un flux XML se révèle vite être une mission ! Le parti pris du mode de développement proche d’ext mais pas tout à fait est désastreux … Quand on voit la facilité de construire ses écrans sous JQM, on ne peut que se détourner de ST. Mais c’est juste mon avis, je serais ravi d’être contredit avec de beaux exemples à l’appui.

Un très bon article trouvé en rédigeant ces lignes, par mathrobin, au taquet sur le sujet

Nous avions déjà causé de Google swiffy dans un précédent article.

Google sort une extention swiffy pour flash pro qui permet de générer du HTML5 directement depuis l’interface Flash !

Encore un outil dans la ligné de Wallaby que nous avons déjà testé également, la convergence ne semble pas prête de s’arrêter, et le poids que met Adobe dans la promotion du HTML5 fait plaisir.

SVG, HTML et CSS, tout ça se met en place alors qu’on attend encore les specs officielles !

Pendant ma dernière formation, le sujet est encore une fois tombé sur les calculs et les erreurs d’arrondis. C’est une discussion que je me rappelle avoir eu pour la première fois il y a bientôt 20 ans chez un client et qui revient régulièrement depuis. Pour résumer très simplement, il suffit de faire le test suivant avec votre langage préféré (ici, c’était une formation Java EE) :

System.out.println(1.0f - 0.9f == 0.1f);

Ce qui donne false comme tout le monde devrait le savoir.

Evidemment, le pro .Net de l’assistance n’a pu s’empêcher de sourire, un peu moins lorsqu’il a fait le test avec son langage préféré.

Il est facile de comprendre ce résultat en effectuant :

System.out.println(1.0f - 0.9f - 0.1f);

On obtient 2.2351742E-8

Passer à du double précision ne résout pas le problème mais le repousse un peu plus loin :

System.out.println(1.0 - 0.9 - 0.1);

on obtient -2.7755575615628914E-17, ce qui est plus proche de 0 mais pas exactement 0.

Ce résultat surprenant est indépendant des langages car il provient de la norme d’encodage des nombres flottants, à savoir la fameuse norme IEEE (IEEE 754 de son vrai nom)
Si votre langage préféré ne produit pas ce résultat surprenant alors il faut vous inquiéter (c’est qu’il ne respecte pas la norme)

Mais pourquoi ce résultat ?

Brièvement, il faut comprendre que la représentation des nombres flottants dans 32 ou 64 bits est basée sur un encodage avec un nombre limité de bits (1 bit de signe, quelques bits pour l’exposant et le reste pour la mantisse). Dans ce format, la représentation de nombre décimaux tels que 0.9 ou 0.1 est tronquée. C’est un peu similaire à la représentation de 1/3 en notation décimale. Le représenter sous la forme 0,33333… est acceptable mais si on tronque, on enlève un petit bout et des additions comme 0,33333+0,33333+0,33333 donnent 0,99999 et non 1.

Il faut retenir que les nombres flottants ne conviennent pas aux calculs monétaires.

Il y a presque 20 ans, le discours avait alors porté sur COBOL.
Ah ah, c’est là qu’on m’avait expliqué qu’en COBOL, les calculs monétaires ne sont pas fait avec des nombres flottants mais avec des entiers, le point décimal étant simplement affiché devant les deux derniers chiffres.

Java propose la classe BigDecimal pour traiter ce problème.
J’ai alors montré à mes stagiaires ce qu’il faudrait normalement écrire :

BigDecimal n1 = new BigDecimal("1.0");
BigDecimal n2 = new BigDecimal("0.9");
BigDecimal n3 = new BigDecimal("0.1");
System.out.println(n1.subtract(n2).subtract(n3));

Et on obtient le 0.0 attendu.

Un dernier test sur notre équation initiale :

System.out.println(n1.subtract(n2) == n3);

Ah !?, pas de chance, ça donne encore false
(l’autoboxing ne résout pas tout)

System.out.println(n1.subtract(n2).equals(n3));

Enfin, on obtient le true attendu.

Là, évidemment, le pro .Net de l’assistance rigole à nouveau. Faut reconnaître que c’est un peu capilo-tracté tout ça.
Il recherche et me montre alors comment cela s’écrirait en .Net.
Je ne me souviens plus exactement comment c’était mais effectivement c’était un petit plus simple.

A ce stade, je suppose que mes collègues et lecteurs assidus se disent « Tiens c’est bizarre, il a pas encore parlé de Smalltalk ! ».

Bon ok, j’y viens (forcément, je cherche toujours à parler de mon langage préféré à moi).
Donc je regarde le pro .Net bien dans les yeux et lui dit un truc du genre « Vous pensez vraiment que ça c’est simple ? »
C’était l’occasion pour moi de montrer c’est quoi la simplicité (et le pur objet, la dynamicité et tout ce qui va avec).
Je lance mon implémentation Smalltalk de prédilection (VisualWorks) et je montre dans un workspace (une fenêtre de texte).

En simple précision on écrit :

1.0 - 0.9 = 0.1

Ce qui donne false (normal, on respecte le standard)

1.0 - 0.9 - 0.1

Donne 2.23517e-8 (toujours normal)

Pour passer en double précision, on écrit :

1.0d - 0.9d - 0.1d

Ce qui donne -2.7755575615629d-17
Oui, c’est bizarre ce « d », mais ça s’explique. En Smalltalk (un langage qui date d’une époque où les octets de mémoire coûtaient cher), les seules nombres flottants qui existaient étaient sur 32 bits. Le langage a ensuite intégré les doubles précisions lorsque ce fut nécessaire.
Java est né après, lorsque la double précision était devenue la norme et que le float était là pour compatibilité).

En Smalltalk, on dispose aussi de nombres de types Fraction. C’est sympa les fractions et ça rappelle l’école (nostalgie, quand tu nous tiens)

1 - (9/10)

Donne (1/10) (trop la classe !)

Et on peut écrire :

1 - (9/10) = (1/10)

Ce qui donne true (c’est y pas beau ça madame !)

Evidemment, les fractions pour la monnaie c’est pas terrible. Du coup, il y a aussi les FixedPoint (initialement nommés ScalableNumber). Ces nombres sont directement exprimables dans la syntaxe avec un suffixe « s ».
Le nombre 1 avec deux décimales peut être noté 1.00s ou bien 1s2.

On peut alors écrire :

1.00s - 0.90s - 0.10s

et on obtient 0.00s

1.00s - 0.90s = 0.10s

Nous donne true.

On peut difficilement faire plus simple.
Ce que je ne comprend pas, c’est pourquoi les langages récents ne proposent pas ce type de nombre directement dans la syntaxe comme le fait VisualWorks depuis au moins 1995 (je ne me souviens plus dans quelle version cela a été introduit).
Manifestement, on doit juger que c’est plus important de laisser les développeurs retomber systématiquement dans les mêmes problèmes de propagation d’erreurs avec les virgules flottantes.