M'enfin ?!?

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 23 décembre 2009

Mise à jour de FrenchRails

J'ai un petit plugin pour Rails qui permet de localiser facilement une application Rails : FrenchRails. Pour ceux qui auraient raté l'épisode précédent, en gros, ça permet de prendre en compte le fait que 0 est un singulier en français (alors que c'est pluriel en anglais).

Je viens de mettre à jour ce plugin pour qu'il traduise également les 'new' et 'edit' qui se balladent dans les URL générées par Rails. Maintenant, ce sera 'nouveau' et 'modifier', ai-je décidé.

Enfin, tant qu'à resortir ce plugin du grenier, j'en ai également profité pour faire quelque chose que j'aurais dû faire depuis un certain temps : le passer en gem. Il est disponible sur http://gemcutter.org/gems/french_rails et peut donc s'installer d'un simple gem install french_rails.

dimanche 13 décembre 2009

Je m'interroge sur twitter

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.

jeudi 21 mai 2009

Annotez vos modèles

Quand je travaille sur des modèles dans Rails, j'ai souvent besoin de regarder la liste des champs de ce modèle. Vous savez, ces petites questions toutes bêtes que l'on se pose tous : c'est firstname ou first_name ? phone ou mobile ? name ou title ? description ou body ?

Pour répondre à ces questions, il faut aller chercher dans db/schema.rb, fichier que l'on a rarement sous les yeux. Mais j'ai mieux à vous proposer : Annotate. C'est un gem qui ajoute un commentaire en haut de chacun de vos modèles (et tests unitaires) avec la déclaration du modèle en question.

Voici un exemple tiré de ma réécriture de LinuxFr.org en Rails :

# == Schema Information
# Schema version: 20090120005239
#
# Table name: news
#
#  id          :integer(4)      not null, primary key
#  state       :string(255)     default("draft"), not null
#  title       :string(255)
#  body        :text
#  second_part :text
#  section_id  :integer(4)
#  created_at  :datetime
#  updated_at  :datetime
#

Pour l'utiliser, c'est on ne peut plus simple. On fait un gem install annotate pour l'installer, puis on lance annotate quand on veut mettre à jour les commentaires. Pour ma part, je fais ça après chaque rake db:migrate, mais libre à chacun de le lancer quand il le souhaite.

dimanche 17 mai 2009

Request-log-analyzer

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.

lundi 4 mai 2009

Railroad

Je commence une série d'articles sur des outils qu'il m'arrive d'utiliser quand je fais du développement Rails et qui mériterait, à mon avis, d'être plus connu. Le premier article de la série est Railroad.

Railroad est un script Ruby qui permet de générer des graphes à partir d'une application d'une Rails, ce qui peut être très pratique pour accompagner une documentation quand on a la flemme de faire ces diagrammes soi-même. Railroad permet de générer 3 types de graphes : un pour les modèles, un pour les controlleurs et un pour les machines à états d'acts_as_state_machine. Les diagrammes sont générés au format .dot, ce qui permet d'en faire facilement des .png ou des .svg avec la suite graphviz.

L'auteur du script original ne maintient plus ce script mais on peut en trouver des forks sur Github. Je conseille la branche de David Dollar : elle fonctionne avec les dernières versions de Rails et comporte mes patchs (1 2 et 3).

En pratique, on installe le gem ddollar-railroad, on ajoute une ligne à son fichier Rakefile et roulez jeunesse :

gem install ddollar-railroad
echo "require 'railroad/tasks/diagrams' if RAILS_ENV == 'development'" >> Rakefile
rake doc:diagrams

On obtient 3 diagrammes dans doc/diagrams (à condition que graphviz soit installé). Voici, par exemple, ceux que j'obtiens pour la version Rails de LinuxFr.org :

Railroad - controllers Railroad - models Railroad - states

mercredi 18 mars 2009

Un plugin RoR nommé FrenchRails

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.

dimanche 8 février 2009

LinuxFr.org avec des commentaires et des réponses aux commentaires, et des réponses aux réponses, etc.

Les développements continuent d'avancer pour la refonte en Rails de LinuxFr.org. Je me suis attaqué à un refactoring des commentaires. Les fils de discussions de LinuxFr.org sous forme d'arbres sont une des forces du site : ils permettent de suivre les discussions très intéressantes (et les trolls, bien sûr). Malheureusement, c'est aussi une structure qui se prête assez mal aux bases de données relationnelles.

J'étais d'abord sur une technique d'ensembles imbriqués (« nested set »), avec le plugin rails awesome nested set, mais celui-ci ne fournissait pas les méthodes qui m'intéressaient. Par exemple, je veux pouvoir construire tout un arbre de discussions en effectuant une seule requête SQL. J'aurais pu compléter ce plugin, mais quitte à écrire du code, j'ai préféré partir sur une structure plus adaptée à mon cas : le chemin matérialisé (« materialized path ») consiste à garder pour chaque commentaire la liste de tous les IDs des commentaires parents dans un champs sérialisé. J'ai fait cela aujourd'hui et j'ai déjà une version fonctionnelle. La preuve en images : Les threads de commentaires en cours de développement

Dans les jours qui viennent, je pense me concentrer sur les dépêches et les commentaires (nettoyer le code, rajouter les fonctionnalités vraiment essentielles, corriger un ou deux bugs que j'ai remarqué, etc.). Je pourrais ensuite me pencher sur une nouvelle partie (la tribune ou le tracker, je ne sais pas encore).

mercredi 4 février 2009

Attention les yeux, ça va piquer !

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) : Premier screenshot de la refonte de LinuxFr.org en Rails 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.

lundi 19 janvier 2009

LinuxFr.org sur des rails

Pour 2009, je n'ai pris qu'une bonne résolution, mais elle est de taille. Ceux qui ont lu ce journal sur LinuxFr.org savent déjà en quoi elle consiste. Pour les autres, la voici : je compte refaire le site LinuxFr.org en Ruby on Rails.

C'est un défi de taille, car la version actuelle existe depuis de nombreuses années, et a accumulé un grand nombre de fonctionnalités au fil du temps. Pour situer, je viens de récupérer la dernière version, elle comporte 18 000 lignes de code (pour les templates), auxquelles on peut ajouter à peu près autant de lignes pour les feuilles de styles. En plus, le site a un fort traffic (en gros, 280 000 pages vues par jour), ce qui oblige à se pencher très sérieusement sur les questions de performance et de sécurité.

J'ai attaqué le développement le 5 janvier, et on peut suivre les commits sur Github. Pour le moment, j'ai commencé à poser les bases pour les utilisateurs et les contenus (principalement, journaux et forums). J'ai également mis en place les commentaires, mais je ne suis pas satisfait du modèle de données, et je vais donc sûrement refaire ça rapidement. Mais la semaine prochaine, je vais surtout me concentrer sur les dépêches : proposition d'une dépêche par un lecteur authentifié ou non, relecture et modération par les AMR, puis affichage sur la home page, les listings de dépêches et les flux RSS.

En bref, c'est un projet qui en est encore à ses débuts, et quasiment tout reste à faire. Je n'ai pas pu avancer beaucoup cette semaine, mais ma motivation reste intacte. Je vais tout faire pour éviter ces périodes creuses, car le seul moyen de sortir un projet de cette taille est d'en faire un peu tous les jours.

mardi 9 décembre 2008

The broken window theory

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 !

- page 1 de 4