M'enfin ?!?

Comme promis, pour vous éclairer sur les ''lifehacks'', je vais donner un premier exemple : le Seinfeld Calendar.

La légende veut que ce soit Jerry Seinfeld l'inventeur de ce hack. Quand on a lui a demandé quel était son secret, il a commencé à répondre de manière plutôt banale : « Pour devenir un bon comique, il faut faire de bonnes blagues, et pour faire de bonnes blagues, il faut travailler chaque jour ». Le secret est donc de s'entrainer tous les jours.

Mais là où ça devient intéressant, c'est qu'il ne s'est pas arrêté là. Il a monté un système ingénieux pour se forcer à travailler chaque jour. Pour ça, le matériel nécessaire est réduit à un calendrier (si possible, assez grand et surtout bien visible) et à un feutre (rouge de préférence). Il explique alors que chaque jour où le travail est fait, il coche le jour sur le calendrier avec le feutre rouge. Au bout de quelques jours, les croix au feutre commencent à former une chaîne, et le but est alors de ne pas casser la chaîne : « Don't break the chain ».

Cette technique est très efficace pour se motiver, car elle nous oblige à dépasser nos excuses. Même si la journée a été difficile, on a envie de cocher sa case pour ne pas avoir à recommencer à zéro une chaîne de 10, 20 ou 30 cases. Par contre, le revers de la médaille est que si l'on rate un jour, même pour une raison valable, le risque est grand de ne pas recommencer tout de suite, voir de ne pas recommencer du tout.

Pour mettre en place cette technique, vous pouvez bien entendu utiliser le calendrier et le feutre, mais si vous pouvez également vous tourner vers une version électronique. Les sites suivants permettent de faire son Seinfeld Calendar en ligne :

• Daily Stamp (mon préféré)
• Don't break the chain
• Seinfeldian Chain
• Calendar about nothing (les cases sont cochés automatiquement en fonction des commits sur github -> exemple avec mon compte).

Bon, ce n'est pas tout ça, mais je dois vous laisser : j'ai du travail à faire sur LinuxFr.org pour cocher ma case d'aujourd'hui.

Mon petit plugin french_rails est maintenant compatible avec Rails 3. La version 0.2 vient d'être publiée sur Gemcutter, et j'ai pu l'utiliser sur une application de test en Rails 3 beta. Vous devriez donc pouvoir faire de même.

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.