Ergonomie, Rails et Architecture de l'information web (2.0)

La conférence sur l’état de l’art du sous-titrage des vidéos donnée par Jean-Louis Carves d’IBM à Paris Web 2007 était particulièrement impressionnante. La démonstration de sous-titrage des vidéos à la volée avec une latence de moins de 6 secondes – et quelques erreurs de grammaire minimes – a notamment montré l’avancée des technologies de reconnaissance vocale depuis les premières versions de Viavoice sous Windows 95.

Liveblogging de la conférence de Myriam Lorant à Paris Web 2007. Notes prises en vrac et donc susceptibles d’erreur.

Ces deux là ont des points de vue toujours opposés

Le décideur : à l’origine du projet. Décisionnaire intéressé par le média internet comme support de communication. Décision de lancer le projet, décision de sa réussite. Pourquoi : développer son image. Fait un site pour lui, il faut que le site lui plaise. Approche commerciale et non informative. Aboutit à des sites au contenu par forcément pertinent.

Je viens d’apprendre que David Larlet se lançait en tant que freelance spécialisé Django, le principal framework de développement web en Python.

Depuis maintenant trois ou quatre ans, on peut lire jusqu’à plus soif que le web 2.0 a inauguré le règne du contenu, et cette allégation n’est pas complètement fausse. L’auteur d’un site publie un contenu ; les visiteurs y réagissent par des commentaires, des billets liés, du bookmarking social, ou de la mise en avant sur les agrégateur sociaux. Bien que la qualité des contenus promus laisse souvent à désirer – il vaut mieux ne pas trop demander aux gens de réfléchir – le système marche semble fonctionner malgré quelques ratés ici et là. Pourtant, si l’on parle beaucoup du contenu, on en oublie que trop souvent la structure, y compris dans le monde des développeurs web, à l’exception peut-être du web sémantique.
Contrairement à ce que j’ai longtemps cru, le XHTML n’est pas seulement un langage de mise en forme ; par la nature même de chacun de ses éléments, il donne du sens à la structure de la page, et ce sens peut être exploité de bien des manières. C’est pour cette raison que l’on parlera dans la suite de cet article de sémantique structurelle.

Les petits gars de Railsenvy, dont je vous avais déjà parlé à l’occasion de la sortie de leurs imitations des publicités Apple brocardant Cake PHP ou PHP tout court, entre autres victimes potentielles, viennent de lancer le premier podcast entièrement consacré à Ruby on Rails, votre framework web préféré.

Sous ce titre primesautier se dissimule un problème idiot rencontré hier soir sur le développement de Typo que j’aurais certainement résolu plus rapidement sans un abus de mojitos.

Je voulais modifier la manière dont Typo transforme les URL en liens permanents en supprimant les caractères spéciaux et accentués. J’ai donc fait le bout de code suivant :

Les problèmes de performances sur un site ou une application web proviennent plus souvent d’erreurs de développement que de soucis de montée en charge. Développée par Yahoo, Yslow, littéralement “pourquoi ça rame” est une extension Firefox qui permet d’effectuer des contrôles de performances sur 13 points clés d’un site web. Chaque point testé reçoit une note pouvant aller de A à F, et les problèmes rencontrés s’accompagnent de conseils tournés vers une optimisation du code. Plus la note est élevée, et plus votre site est rapide.

Pas moins de 13 points de contrôle

YSlow met en avant 13 bonnes pratiques fondamentales dans l’optimisation d’une page web :

1. Minimisez le nombre de requêtes HTTP.
2. Utilisez un réseau spécialisé dans la fourniture de contenus.
3. Ajoutez un en-tête d’expiration.
4. Compressez les contenus côté serveur.
5. Placez les feuilles de style en haut de la page.
6. Déplacez les Javascript en bas de page.
7. Proscrivez les expressions CSS.
8. Placez un maximum de javascript et de CSS dans des fichiers externes.
9. Minimisez les besoins en requêtes DNS.
10. Optimisez le javascript.
11. Évitez les redirections HTTP (301, 302).
12. Supprimez les scripts redondants.
13. Configurez les etags

Un premier test de performances me montre que la refonte en cours du site ne devra pas seulement être ergonomique ou graphique, mais qu’un gros travail d’optimisation est aussi nécessaire. Comme quoi les histoires de cordonnier…

Les deux animateurs de Railsenvy remettent le couvert avec leurs parodies des films publicitaires d’Apple comparant Ruby on Rails à ses concurrents. À ceux qui leur reprochaient de comparer un framework à des langages, réjouissez-vous, ils vous ont écouté et égratignent cette fois Cake PHP dans un spot qui s’avère être de loin le meilleur de la série.

À mourir de rire… sauf peut-être pour les fans de Cake PHP.

La toute nouvelle mouture de Safari, la navigateur fourni par défaut sur Mac OS X a fait couler beaucoup d’encre, aussi bien pour annoncer son arrivée sous Windows que pour dénoncer les nombreuses failles de sécurité qui l’affectent au point – pouvait-on lire chez les mauvaises langues pommophobes – de concurrencer Internet Explorer toutes versions confondues. C’était évidemment en occulter toutes nouveautés intéressantes, à commencer par le nouveau Web Inspector, la nouvelle suite d’outils Safari pour développeurs web. Et pour cause, puisque cette dernière n’est disponible que sous Mac OS, et qu’elle est surtout désactivée par défaut.

Je n’ai pas pour habitude de traduire les textes d’autrui, je ferai une exception pour cette fois sans rien y ajouter ni retrancher. D’abord parce que je ne vois pas ce que je pourrais dire de plus, ensuite parce que l’esprit même du texte rentre pour une bonne partie dans son intérêt, enfin parce que Rails manque trop de bonnes documentations en français, et que celle ci vaut le déplacement.

Ceci est la traduction de Ruby on Rails rake tutorial, de Greg Pollack.

Si vous développez en Ruby on Rail, vous avez certainement utilisé l’utilitaire Rake afin de lancer les tests, ou pour mettre à jour votre base de données en lançant rake db:migrate. Mais avez-vous vraiment conscience de ce qui se passe lorsque vous lancez une tâche Rake ? Savez-vous qu’il vous est possible de créer vos propres tâches rake, ou même de créer votre propre librairies de ces si pratiques descripteurs de tâches ?

Voici quelques cas d’usages des tâches Rake :

• Récupérer une liste d’inscrits afin d’envoyer un email.
• Lancer des traitements de calcul et de statistiques pendant la nuit.
• Supprimer et régénérer le cache d’une application.
• Sauvegarder ma base de données et mon dépôt subversion.
• Exécuter n’importe quel traitement de données.
• Me saouler la gueule.

Dans ce billet, vous allez découvrir le pourquoi de l’existence de Rake, et comment il peut vous aider dans le développement de vos applications Rails. À la fin de cette lecture, vous devriez être capable de créer vos propres tâches et de finir bourré comme un coing grâce à Rake en seulement trois petites étapes.

Pourquoi faire un retour en arrière ?

Pour comprendre les origines de Rake, il convient de s’intéresser un peu à son vénérable ancêtre, j’ai nommé Make.

Je vous propose un voyage dans le temps, à l’époque où le code devait obligatoirement être compilé, c’est à dire avant que l’iPhone et les langages interprétés ne parcourent la planète.

À cette époque, quand vous téléchargiez un logiciel, vous obteniez généralement des fichiers contenant le code source et un script shell. Ce script contenait tout ce que votre machine avait besoin de savoir afin de compiler, lier et construire votre application. Vous lanciez install_me.sh, chacune des lignes du fichier était exécutée, et vous obteniez au bout d’un moment un exécutable.

Ça marchait plutôt pas mal, il faut l’avouer, à part peut être pour les quelques développeurs de l’application. Chaque fois qu’ils changeaient la moindre ligne de code, il leur fallait relancer le script afin de tout recompiler. cela prenait évidemment un temps fou pour les gros logiciels.

En 1977, Stuart Feldman des laboratoires Bell inventa Make, qui résolut la majorité des problèmes liés aux compilations à répétition. Make est également utilisé afin de compiler des programmes, mais avec deux différences majeures :

1. Make est capable de reconnaître quels fichiers ont été modifiés depuis la dernière compilation. Il pouvait donc ne compiler que ce qui avait changé d’une fois sur l’autre. Autant dire que cela a dramatiquement réduit les temps de compilation.
2. Make peut aussi résoudre les dépendances. Il sait que pour être compilé, le fichier A a besoin du fichier B, qui lui-même a besoin de fichier C. Ce qui fait que si Make tente de compiler le fichier source A et que le fichier source B n’a pas été compilé, il commence par traiter ce dernier.

Je ne devrais pas continuer sans vous expliquer que Make est un simple exécutable, un peu comme “ls”, ou “dir”, et qu’il a besoin pour fonctionner d’un fichier annexe, appelé un “makefile”, qui va contenir toutes les sources et les dépendances du programme à compiler. Les “makefiles” ont leur propre syntaxe cabalistique qu’il ne nous sera pas donné de voir ici.

Au fur et à mesure, Make a évolué, et on a commencé à l’utiliser pour d’autres langages. En fait, de nombreux développeurs Ruby l’utilisaient avant l’avènement de Rake.

“Mais, Ruby n’a pas besoin d’être compilé, alors à quoi ça sert ?”. Vous ne l’avez peut-être pas dit, mais vous l’avez certainement pensé très fort.

Oui, je suis d’accord, Ruby est un langage interprété, et nous ne compilons pas notre code. Alors pourquoi utiliser Make ?

Eh bien, pour au moins deux raisons fondamentales :

1. Automatiser des tâches : toute application d’envergure se termine presque fatalement par l’écriture de scripts à lancer en ligne de commande, qu’il s’agisse de lancer une maintenance, supprimer un cache ou faire évoluer la base de données. Et au lieu de créer une dizaine de petits scripts shell, ou un gros, vous pouvez aussi créer un seul “Makefile” dans lequel vous organiserez les choses à faire en tâches. Vous pouvez ensuite exécuter les tâches en lançant “make stupid”, c’est à dire littéralement “fait l’imbécile”, et cela lance la tâche “stupid”.
2. Vérifier la résolution des dépendances entre les tâches. Quand vous lancez des opérations de maintenance en chaîne, vous en répétez fatalement certaines d’une tâche à l’autre. Par exemple, migrer une base de données et en faire une extraction ont toutes deux une connexion à la base pour prérequis. Vous pouvez donc créer une tâche de connexion qui sera lancée juste avant la migration.

Et Rake, dans tout ça ?

Il y a quelques années, Jim Weirich utilisait régulièrement Make sur un projet en Java. Tout en travaillant sur son Makefile, il réalisa combien il lui serait pratique d’avoir des bouts de Ruby dedans. Et Rake était né.

Jim donna à Rake la possibilité de réaliser des tâches, résoudre les dépendances, et même éviter de recommencer des tâches qui avaient déjà été réalisées. C’est évidemment quelque-chose que nous ne faisons pas vraiment, puisque Ruby n’est pas un langage compilé.

Comment ça marche ?

Imaginons que je veuille me saouler la gueule, quelles en seraient les étapes ?

1. J’irais acheter à boire.
2. Je me servirais à boire.
3. Je boirais jusqu’à plus soif.

Si je voulais utiliser Rake pour chacune de ces tâches, je créerais un fichier nommé Rakefile, qui contiendrait quelque-chose comme ça :

Je peux maintenant lancer ces tâches depuis le répertoire où se trouve mon Rakefile, comme ça :

Sympa non ? Malheureusement, je ne vérifie pas que les tâches sont effectuées dans le bon ordre. Et bien qu’il puisse m’arriver de souhaiter être bourré avant d’avoir commencé à boire, ou même avant d’avoir acheté quoi que ce soit, ce n’est évidemment pas possible.

Rake et les dépendances

Maintenant, il me faut acheter à boire et me servir un verre avant de pouvoir me saouler la gueule convenablement. Cela donne donc :

Comme vous pouvez le voir, avant que je ne puisse boire, il me faut acheter de l’alcool et me servir un verre. L’ordre des choses est rétabli.

Avec le temps, vous risquez d’être tenté d’accroître votre alcoolisme, et donc votre Rakefile. Vous serez aussi certainement tentés de m’inviter à boire un coup. Comme dans tout logiciel d’envergure, rien ne vaut une bonne documentation.

Comment documenter mes tâches ?

Rake possède une manière très simple de documenter les tâches. Il s’agit de “desc” et c’est simple comme bonjour :

Comme vous pouvez le voir, chacune de mes tâches a maintenant une description. Mes amis peuvent les lire en tapant rake -T, ou rake --tasks.

Facile non ?

L’espace de nommage de Rake

Maintenant que vous êtes devenu un bon alcoolique, vous utilisez un grand nombre de tâches Rake, et vous avez besoin d’un bon moyen de les classer. C’est là que viennent les espaces de nommage. Si je devais utiliser un espace de nommage dans l’exemple précédent, il deviendrait :

Vous n’avez plus qu’à classer vos tâches en fonction des catégories, et OUI, vous pouvez en avoir plusieurs dans un même fichier. Maintenant, rake --tasks me donne :

Tu ne pourrais pas être un peu sérieux pour une fois ?

Les applications Rails viennent avec un lot de tâches prédéfinies, dont vous pouvez obtenir la liste en allant dans le répertoire de travail et en lançant rake --tasks. Si vous n’avez pas encore essayé, allez y, je peux attendre deux minutes…

Afin de créer une nouvelle tâche rake pour votre application Rails, vous devez dans un premier temps vous rendre dans le répertoire /lib/tasks (créé par défaut). Si vous y placez vos Rakefiles avec le suffixe “.rake”, celles-ci seront automatiquement récupérées par Rake. Nous allons ajouter la tâche suivante à notre application Rails.

Remarquez comment j’ai pu utiliser #{RAILS_ROOT} pour obtenir le chemin complet de l’application. Maintenant, si je lance rake --tasks dans le répertoire de mon application, je trouverai les nouvelles fonctions mélangées aux autres tâches Rake.

Génial ! Maintenant voyons comment ça devient vraiment utile.

Et on peux accéder aux modèles Rails depuis une tâche ?

Évidemment ! En fait, c’est même pour ça que j’utilise Rake : écrire des tâches que je lance à la main ou que je planifie en utilisant Crontab. Comme je le disais au début de l’article, j’utilise Rake pour les tâches suivantes :

• Récupérer une liste d’inscrits afin d’envoyer un email.
• Lancer des traitements de calcul et de statistiques pendant la nuit.
• Supprimer et régénérer le cache d’une application.
• Sauvegarder ma base de données et mon dépôt subversion.
• Exécuter n’importe quel traitement de données.
• Me saouler la gueule.

Sacrément utile, et facile qui plus est. Le code suivant récupère la liste des utilisateurs dont l’abonnement arrive à expiration et leur envoie un courriel :

Comme vous pouvez le voir, nous accédons au modèle en deux étapes : la directive require et le => :environment.

1. require File.expand_path(File.dirname(__FILE__) + “/../../config/environment”)
2. task(:send_expire_soon_emails => :environment) do

Pour lancer ça tous les soirs à minuit, je n’ai qu’à créer une tâche dans Crontab, de cette manière :

Où trouver plus d’exemples ?

Maintenant que vous en savez assez pour écrire des tâches utiles, je me suis dit que je pourrais vous laisser repartir avec quelques ressources supplémentaires. La meilleure manière de vous améliorer est encore de lire le code des autres, comme ces tâches Rake :

• Ces nouvelles tâches incluses dans Rails Edge remettent votre base de données à zéro pour vous.
• Craig Ambrose a écrit une tâche pour sauvegarder votre base de données.
• Adam Greene a écrit une série de tâches qui vous permettent de sauvegarder vos données sur Amazon S3.

C’est fait. Si vous en connaissez d’autres, n’hésitez pas à les publier dans les commentaires.

Toujours là ? Ça tombe bien, les gens de RailsEnvy à qui nous devons cet excellent article cherchent de nouveaux collaborateurs. Contactez Greg at RailsEnvy si ça vous intéresse.