Blog de David MASCLET

Certains connaissent peut être pastebin qui permet d'envoyer du code à quelqu'un (ou d'un PC à l'autre ;) ) en générant une shortURL. Il existe des sites qui vont plus loin en permettant de tester du code directement en ligne : http://codepad.org/. il suffit de copier / coller votre code, et le site vous le compile et vous l'interprète. c'est le cas de codepad

Il supporte les langages suivants :

• C
• C++
• D
• Haskell
• Lua
• OCaml
• PHP
• Perl
• Plain Text
• Python
• Ruby
• Scheme
• Tcl

Vous pouvez mettre votre code "privé", ce qui est pratique, car j'ai déjà retrouvé du code, que je ne voulais pas partager publiquement, indexé par Google, après l'avoir envoyé via pastebin)

Dans la même lignée, il existe des sites plus spécialisés pour tester les interactions HTML<=>Javascript : http://jsbin.com/. Son utilisation est triviale : vous avez le code javascript à gauche et le code HTML à droite.

Le site va beaucoup plus loin que pastebin, d'une part, car il est spécialisé dans un langage, mais aussi parce qu' il offre la possibilité :

• De sauvegarder votre code.
• D'inclure des librairies connues, comme Prototype, Jquery, Mootools, Dojo et de choisir parmi différentes versions
• De générer une short URL de votre code (exemple : http://jsbin.com/ilomu3)
• De modifier un code existant en cliquant sur ''Edit using JS Bin" en haut à droite (j'avoue c'est pas flagrant :) ).
• De gérer plusieurs versions d'un même code

L'avantage est qu'il permet de tester du code avant de mettre à jour un librairie (exemple : passer de Prototype 1.6.03 à 1.6.1.0), de vous faire la main sur des librairies, ou de partager du code entre collègues.

Après le billet consacré à JsUnit et celui qui expliquait comment mocker une requête Ajax, nous allons maintenant voir comment mocker en javascript. Pour cela je vous propose une courte présentation de JsMock. Les exemples de code sont en annexe de ce billet.

Beaucoup de développeurs Java sont familiers avec Junit, EasyMock,... ces librairies qui permettent de tester du code Java afin de rendre les programmes plus robustes. Javascript dispose également de frameworks équivalents. Avec l'apparition du Web 2.0, le Javascript et l'Ajax sont de plus en plus présents dans nos applications (j'avais d'ailleurs poster un billet sur comment mocker une requête Ajax,il y a quelques mois) et représente une part non négligeable de code.

Si vous utilisez GWT, qui permet d'écrire à partir de code écrit en Java, de générer une application en HTML / javascript, vous n'avez pas de problème pour tester votre code, puisque Junit suffit. En revanche, si vous avez du code javascript à tester, il existe des librairies qui permettent de simplifier les tests. Je vous propose de voir comment tester du Javascript au moyen de ces 3 frameworks :

• JsUnit : Qui fournit des mécanismes d'assertions et d'exécutions de tests.
• JsMock : Permet de simuler des comportements pour des objets Javascript,tout comme EasyMock le fait
• JsTester : Permet d'executer du code Javascript en java grâce à Rhino.

les exemples de code sont disponibles en annexe de ce billet

Après la folie commerciale de fin d'année je voudrais bloguer sur les différentes stratégies des sociétés dites "innovantes". je sais dors et déjà que je vais me faire des ennemis et que cette article ne fera pas l'unanimité, mais peu importe, ce post trouvera aussi des personnes allant dans le même sens que moi :)

C'est demain que sort le téléphone de Google : le Nexus One. Ceux qui me connaissent savent que je suis un fervent défenseur de Google. Ce n'est pas que j'aime tout ce qu'ils font (je n'aime pas chrome, par exemple), mais je trouve que leurs produits tapent souvent juste et fort. Et si certains sont frileux d'utiliser des applications et services d'une firme, il est vrai, un peu "big brother", on saluera tout de même leur stratégie qui leur a permis d'être le moteur de recherche utilisé par 90% des internautes et de sortir des produits innovant comme, Google Maps et Google documents, GWT, etc.

Je m'étonne encore de leur modèle économique basé sur la publicité. Pour mémoire, ce même modèle a causé, entre autre, la chute de la bulle internet. De très grosses sociétés (e.g : AOL) ont revu leur business modèle, en passant la publicité de "source de revenus" à "complément d'activité" ;). La stratégie de Google est de sortir des produits les plus complets possible, en sachant très bien ce qu'il amélioreront à la prochaine version, mais en visant un niveau de base déjà très élevé pour un effet "WHAOOOUU". Je voudrais (entre autre) comparer la différence de stratégie d'Apple et de Google pour leur téléphone pour montrer comment Apple est vraiment une société reine dans le marketing :

Lorsque vous développez, Vous pouvez avoir envie de savoir qui a comité un bout de code, pas forcément parce qu'il vous parait mauvais (soyons constructif !), mais peut être pour comprendre certains choix, parce que vous trouvez le code particulièrement beau, ou simplement par curiosité. La plupart des outils de gestion de versions fournissent des moyens de le faire grâce à la commande blame. Même si la commande peut porter à confusion, ce post, n'est pas à placer dans la rubrique "délation" mais plutôt "travail en équipe" : )

Pendant plusieurs années, j'ai travaillé dans une équipe QA (Quality Assurance), où mon rôle était de trouver les causes et de corriger les bugs que d'autres équipes avaient faits: il y avait les développeurs qui implémentaient les fonctionnalités, les testeurs / bêta-testeurs, et mon équipe qui prenait en charge les bugs un peu retords. J'avoue avoir eu des fois beaucoup de mal à reproduire certains bugs.

J'ai appris par expérience que certains bugs pouvaient apparaitre seulement dans des cas de tests et ne se seraient jamais reproduits dans une utilisation normale, d'autres n'apparaissent plus lorsqu'on tente de les observer. C'est là, la différence entre les Bohr bugs, Schrödinbugs, Heisenbugs, et Mandelbugs. Toutes ses catégories de bugs tirent leurs noms de physiciens. Voici les différences fondamentales :

Lors de l'affichage de pages avec des mots dans des alphabets différents il peux arriver que des problèmes d'affichages apparaissent avec des � et des é

Dans le cas de Gisgraphy (exemple pour Pékin), j'ai voulu vérifier que tout s'affiche correctement et que ce qui est affiché correspond bien à l'équivalent ASCII.

Je me suis donc rendu sur cette page et j'ai testé 北京, ce qui m'a donne 'bei jing'.ouah ça marche! et mon navigateur affiche le japonais! essayons en arabe avec بكين , cela me donne "bkyn" qui se rapproche de Beijing et Pékin en phonétique, et là aussi ça s'affiche correctement.

Cela m'a donné l'idée d'un post pour démystifier l'encoding par une suite de questions-réponses. (Finalement je le ferai en deux posts car c'est un peu long, et je risque de perdre et décourager pas mal de lecteurs si je n'en fais qu'un). Le premier expliquera ce qu'est l'encoding :

• Qu'est ce qu'Unicode ?
• Qu'est-ce que l'encoding, le BOM, le Little et le Big Endian
• Quel est le meilleur encoding ?
• Comment fonctionne une police de caractère ?
• Comment gérer les sens d'écriture différents (par exemple, l'arabe qui s'écrit de droite à gauche)

Le second expliquera comment résoudre les problèmes fréquents avec de cas concrets et des extraits de code :

• Comment gérer l'encoding dans un environnement web en java (Java, Apache, Tomcat, ModJK, base de données, navigateurs)
• Comment gérer et débugger des problèmes d'encoding en java

Après ces deux posts vous ne devriez plus jamais voir ça : � sur vos sites, ou si c'est le cas vous saurez comment résoudre le problème :)