M'enfin ?!?

Je connais Twitter depuis longtemps, mais je n'ai jamais senti le besoin de m'y inscrire. Et pourtant, récemment, j'ai créé un compte twitter.

Pourquoi ?

Je n'ai pas eu une soudaine révélation sur twitter. Je ne vois pas d'intérêt particulier à twitter, comparé aux autres moyens de communications à ma disposition. Autant pour Facebook, je peux voir un intérêt (mais je ne suis pas prêt à accepter les atteintes à ma vie privée qui en découlerait), autant pour twitter, je reste perplexe.

Alors pourquoi me suis-je inscrit ? Principalement par curiosité. Je travaille sur ce que pourrait-être le web de demain (Nodzle), et twitter est sensé être le meilleur représentant du web temps-réel. On m'a fait remarquer que le meilleur moyen de découvrir twitter est encore de l'essayer, principe qui peut être illustré par cette citation :

Twitter is like sex. You can read all the stuff (or look at it) about sex all you want, but if you’ve never had it, you simply have no idea what it’s like.

Et alors ?

OK, j'ai donc créé un compte twitter et j'ai commencé à twitter. Mais ai-je été touché par la grâce divine et suis-je devenu un fervent défenseur du twit ?

Non, loin de là. Pour le moment, l'usage que j'en fais est très proche de l'IRC, mais avec de gros défauts :

• je n'ai pas trouvé comment faire l'auto-complétion des nicks ou des hashtags ;
• je ne sais pas non plus comment voir les réponses à une question intéressante posée par une personne que je suis ;
• déjà confronté aux spams :/
• c'est dur de relire les anciens messages...

Bref, je ne me suis pas converti à la religion twitter, mais je vais continuer à l'utiliser pour voir si mon opinion évolue.

Dans la série des outils pour Rails que j'apprécie, je vais vous parler de request-log-analyzer. Pourquoi lui ? Parce qu'il m'a rendu bien service cette semaine.

Request-log-analyser est un outil très simple qui permet d'analyser les logs de Rails pour découvrir les requêtes HTTP qui consomment du temps CPU. En pratique, ça s'installe simplement avec gem, puis on le lance pour générer un rapport (j'aime bien la version HTML) :

gem install request-log-analyzer
request-log-analyzer --output HTML --file report.html log/production.log
firefox report.html

Le rapport nous fournit un certain nombres d'informations que les hits sur chaque page, les codes HTTP renvoyés, les requêtes les plus lourdes. Pour ma part, je me sers surtout du tableau des 20 requêtes HTTP les plus longues en temps cumulé (Request duration - top 20 by cumulative time). Cela me donne une liste d'actions à bencher pour lesquelles une optimisation est toujours bonne à prendre. Je passe également un peu de temps à regarder si ces requêtes apparaissent dans les 20 requêtes les plus lourdes pour la base et les 20 requêtes avec le temps de rendering le plus long (toujours en temps cumulé). Je peux ainsi avoir une idée de ce qui prend du temps, et de valider ainsi que les résultats du bench collent avec ça. Si je vois qu'une requête HTTP passe beaucoup de temps sur la base de données, mais que les résultats du bench ne montrent pas ça, je vais probablement importer la base de données du serveur de production et l'utiliser pour refaire les benchs.

Un autre tableau intéressant est la liste des requêtes bloquantes (Process blockers (> 1 sec duration)). Si je vois des requêtes faire pas mal de hits dans cette liste, je sais qu'il va falloir les surveiller de près.

Voilà, request-log-analyzer n'est pas un outil magique. Il ne fait qu'une chose, mais il le fait bien. Et c'est très utile pour savoir par où commencer à optimiser un site.

Comme vous le savez déjà sûrement, je suis en train de re-écrire LinuxFr.org en Rails. Et quand j'ai montré où j'en étais, on m'a remonté un bug étrange : j'affiche "0 commentaires" avec un s à la fin, ce qui est grammaticalement incorrect.

<interruption culturelle> Pour ceux qui ne sont pas très calés en internationalisation, sachez que les règles qui définissent singulier et pluriel ne sont pas les mêmes selon les langues (en fait, certaines langues ont mêmes plusieurs sortes de pluriels). En particulier, il y a une différence importante entre le français et l'anglais : en français, 0 est singulier, alors qu'il est pluriel en anglais. Ruby on Rails utilisant par défaut l'anglais, on comprend mieux d'où vient le 's' à la fin de "0 commentaires". </interruption culturelle>

J'utilise l'helper pluralize, et comme Rails a intégré une gestion de l'internationalisation à la version 2.2, je pensais qu'il suffirait de déclarer la locale pour que cela marche. Hé bien, non. Première surprise : l'helper pluralize ne passe pas par la partie I18n, mais utilise une règle en dure pour savoir si un nombre est singulier ou pluriel. Bon, ce n'est pas grave, ce n'est pas ça qui va m'arrêter : un petit monkey-patching et c'est réglé.

Sauf que, deuxième surprise, cela ne marche toujours pas ! Le backend d'I18n fourni avec Rails (I18n::Backend::Simple) ne connaît que la règle pour l'anglais, et ne tient donc pas compte de la locale. Après quelques errements et expérimentations, j'ai réussi à trouver un moyen relativement simple de corriger cela (créer un backend qui hérite de I18n::Backend::Simple, avec juste la méthode pluralize redéfinie). Et là, joie, ça marche :-)

Comme tout cela m'a pris quelques heures, j'en ai fait un plugin : FrenchRails. J'espère que cela pourra servir à d'autres personnes. En tout cas, moi, je compte l'utiliser sur plusieurs projets.

Dernière chose : si vous avez des besoins plus compliqués que les miens (au hasard, gérer plusieurs langues), ne cherchez pas à utiliser ce plugin, parter plutôt sur une solution plus costaud comme Globalize2.

Mise à jour : FrenchRails est maintenant disponible en gem.

J'ai repris mes développements sur LinuxFr.org, avec comme règle, d'en faire un peu tous les jours. Pour le moment, cela marche pas trop mal. Là, ça fait 5 jours de suite que je commite, et j'ai pu avancer sur les dépêches (aussi bien, création que toute la partie backend de modération). Pourvu que ça dure.

Sinon, je n'avais pas écrit la moindre de ligne de CSS jusque hier, et je commençais sérieusement à m'y perdre dans les différents blocs et balises qui structurent les pages. J'ai donc commencé à faire une CSS temporaire qui me servira juste pour le développement. Voici une capture de ce que cela donne (attention les yeux, ça pique) : Je vous rassure, je ne compte pas garder la moindre ligne de cette feuille de style pour la version finale. En fait, j'espère bien ne pas avoir à faire la feuille de style finale, je ne suis pas très doué pour ça.

La théorie des fenêtres cassées (« The broken window theory ») a inspiré les forces de police de New York et d'autres villes importantes pour lutter contre la criminalité.

Cette théorie postule que la différence entre un immeuble propre et joli, et un autre en très mauvais état peut être la conséquence d'une simple fenêtre cassée. Cette simple fenêtre cassée laisse une impression de négligence et d'impunité. Des personnes commencent à laisser traîner des détritus, puis des tags apparaissent, et en un rien de temps, l'immeuble est devenu insalubre et mal fréquenté. La morale ? Il ne faut pas laisser traîner des fenêtres cassées, mais au contraire, les réparer de suite pour éviter que des dégâts plus sérieux n'arrivent. Jusqu'à récemment, cette théorie n'était qu'une hypothèse, mais des études récentes viennent soutenir cette théorie.

Chose intéressante, les pragmatics programmers ont appliqué cette théorie au développement logiciel. Les fenêtres cassées sont alors tous les code smells : le test unitaire qui ne passe pas, le module mal documenté, le FIXME qui traîne, la fonction mal implémentée... Il est alors important de corriger au plus vite ces petits défauts, sans quoi ils vont s'accumuler et donner une mauvaise impression de la qualité du code. Et alors, ce seront des défauts de plus en plus en gros qui vont arriver, chaque développeur se disant que ce n'est pas grave s'il introduit un nouveau code louche pour gagner du temps, car d'autres développeurs l'ont déjà fait ailleurs. Le même développeur qui aurait une base de code propre, sans fenêtres cassées, n'aurait pourtant pas osé être le premier à écrire du code sale (surtout s'il sait que son code fera l'objet d'un code review, mais c'est un autre sujet).

Pour avoir déjà rencontré souvent ce cas de figure, je sais que cette analogie est très pertinente. Ne laissez pas des fenêtres cassées dans votre code !