M'enfin ?!?

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 !

Dans la série des astuces pour Vim, voici le troisième épisode (le premier se trouve par ici et le second par là).

• Jamis Buck, l'auteur de Capistrano, revient sous Vim après plusieurs années de textmate. La bonne nouvelle, c'est qu'il ne peut pas se passer de Cmd-T pour trouver des fichiers, et qu'il a donc développé un plugin Vim pour faire cela : Fuzzy File Finder. Je vous conseille fortement de l'essayer, ca simplifie vraiment la vie pour ouvrir des fichiers bien planqués dans des sous-répertoires.

• La recherche sous Vim se fait en tapant / puis l'expression recherchée. Je suppose que vous connaissiez cette commande, mais saviez-vous que l'on peut spécifier un déplacement en tapant un deuxième / puis le déplacement voulu ? Par exemple, /foo/e+1 placera le curseur sur le premier caractère après foo. Ceci est très pratique quand on répète plusieurs fois la même recherche.

• Si vous débuggez souvent des feuilles de style CSS, vous êtes amené à faire beaucoup d'allers-retours entre votre navigateur web et Vim. Et à chaque fois que vous faîtes une modification, vous êtes obligés de taper <ESC>:w<CR> pour la tester. Pour gagner quelques touches à chaque itération, je vous propose de rajouter la ligne suivante à votre fichier .vimrc :

autocmd FocusLost *.css :up

Elle enregistre automatiquement chaque fichier .css quand Vim perd le focus (et uniquement s'il y a des changements à enregistrer).

• Le dernier truc n'en est pas vraiment un, je voulais juste vous faire part du dernier plugin que j'ai développé pour Vim. Celui-ci permet d'avoir la coloration syntaxique pour le framework Merb, la bibliothèque Datamapper et le framework javascript jQuery. Voici un petit screenshot de ce que cela donne chez moi :

RubyflowFr est en ligne depuis une dizaine de jours. C'est l'occasion de faire un premier retour dessus :

• 18 posts
• 8 utilisateurs enregistrés
• environ 1500 pages vues
• une trentaine de personnes suivent quotidiennement les flux RSS, d'après Feedburner
• déjà des changements de CSS !

Merci à Nicolas Gruson pour ces modifications de CSS qui améliorent grandement la lisibilité du site. Bref, cela démarre pas mal, même si j'aimerais bien que plus de personnes proposent des liens (il n'y a pas besoin de compte pour cela).

Rubyflow est une application de publications de liens à destination de la communauté Ruby. Peter Cooper a libéré le code source de cette application, aussi Ruby France a décidé d'en sortir une version française destinée à la communauté française des rubyistes et railers.

L'adresse du site est http://flow.rubyfrance.org/. Bien entendu, vous êtes encouragés à partager vos liens sur Ruby, Rails, Merb ou autres en les postant accompagnés d'une courte description. Vous savez ce qu'il vous reste à faire ;)