Teorem's Blog

Je suis tombé sur un problème typique (et récurrent) qui guette tout programmeur dont l'application se doit d'être internationalisable.

Un copain s'est amusé à créer des scripts GreaseMonkey afin de se faciliter la vie sur une application web : son script détecte des chaînes de caractères particulières et va changer le look&feel de cette partie de la page afin de lui permettre de repérer plus rapidement les choses qui peuvent être importantes pour lui.

Il s'est trouvé récemment devant un problème incompréhensible : la détection de chaîne ne marchait plus et les commentaires apparaissant dans les boîtes de dialogues (par exemple, la description de son script apparaissant dans un dialogue greasemonkey) montraient des caractères bizarres ou des points d'interrogation à la place des caractères accentués. Evidemment, quand il regardait son script avec son éditeur, les accents étaient bien là. Il a essayé de modifier les paramètres du navigateur pour accepter ce qu'il croyait être le bon encoding, mais sans succès.

Au final, le problème venait simplement de son éditeur qui avait un encoding par défaut différent de ce qu'il pensait.

Morale de l'histoire: il ne faut jamais rien laisser au hasard, surtout en matière de paramètres liés à l'internationalisation, le bug qui risque de vous pourrir la vie est là car vous n'avez pas spécifiez et mis en place correctement votre environnement de développement, de test ou de production !

On vient de demander à l'architecte que je suis de donner son avis sur le langage de programmation Ruby et le framework Ruby On Rails. N'ayant jamais pratiqué ce langage, j'aurais été bien à mal de répondre mais mes différentes lectures (remises à jour rapidement) me permettent de dire que pour une application web "industrielle", je me ferai un peu de souci vis à vis de la rapidité de l'interpréteur que certains jugent lent même si Ruby et RoR permettent de faire gagner des developer cycles sinon des cpu cycles. L'autre souci, mais qui est commun à la plupart des frameworks offrant des facilités de programmation vis à vis des bases de données, est que le programmeur se laisse abuser par la simplicité de développement et oublie qu'une application web nécessitant de bonnes performances ne peut se contenter de requêtes SQL génériques si celles-ci doivent être nombreuses et répétées.

Dans mes lectures de ce soir, je me suis rendu compte que Ruby permettrait de manipuler des threads (ce qui est à mon avis l'une des meilleures features de Java) de qui n'ets pas forcément d'une grand intérêt pour une application Web sauf si l'on considère que celle-ci est un mash-up et doit faire appel à de multiples web services, en essayant de minimiser les temps d'accès à ceux-ci, ainsi que le traitement permettant d'utiliser les résultats qu'ils renvoient. L'utilisation de threads, notamment sur une machine multi-processeurs (ce qui est assez commun de nos jours), permet alors d'assurer de bonnes performances à cette application Web. Malheureusement, j'ai été déçu de lire que les interpréteurs Ruby ne fournissaient pas le support des threads natifs, seuls à même de faire profiter de la puissance des multi-pros.

De la même manière, il n'y a pas à ma connaissance de support des threads natifs ou non dans PHP. Mais il se trouve que l'on peut au moins démarrer des demandes en parallèle et attendre la réponse la plus rapide pour commencer le traitement. Pour cela, il faudra utiliser stream_select, ou de manière plus simple les fonctions multi de curl.