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

Je viens de tomber sur le ticket le plus extraordinaire qu’il m’ait été donné de lire à ce jour sur un projet open source. Et, comme par hasard, c’est à Ruby on Rails que je dois cette belle crise de fou-rire matinale.

Cool URIs don’t change, dit Tim Berner Lee, et il a bien raison ; rien ne m’énerve plus que de voir une recherche échouer sur une bête erreur 404, soit parce que son propriétaire en a supprimé le résultat, soit parce qu’il l’a déplacé ailleurs sans faire attention à ceux qui pourraient vouloir y accéder. Malheureusement, les raisons pour lesquelles on doit déplacer une ressource d’un endroit du web à un autre ne manquent pas : changement d’outil de content management, d’URL ou réorganisation du site.

La création d’applications ultra rapide et de manière particulièrement impressionnante grâce au scaffolding a été pour beaucoup dans le succès du framework de développement web Ruby on Rails. Cette méthode, francisée en un peu élégant échafaudage permet de générer automatiquement une application en fonction de son schéma de base de donnée, permettant d’implémenter immédiatement tout ce qu’il faut pour faire du CRUD (create, read, update, delete). Le scaffolding est donc particulièrement utile pour commencer très rapidement une application et permettre immédiatement la saisie des données par les utilisateurs à venir.

Je profite de ce beau dimanche matin ensoleillé pour vous annoncer la sortie de la version 5.0.2 de Typo “Eugène Atget”. Il s’agit d’une version de maintenance qui corrige plusieurs bugs critiques apparus dans la 5.0 et la 5.0.1.

Elle guérit les tendances suicidaires de Typo qui avait tendance à se supprimer – littéralement – chaque fois qu’on tente d’effacer le cache. Ce bug aurait du être corrigé dans la 5.0.1, mais il semblerait que le correctif n’ait pas été intégré dans l’archive. Il corrige également un bug inhérent à Rails 2.0.2 sur la méthode update_all d’ActiveRecord qui ajoute une clause ORDER BY incompatible avec PosgreSQL et SQLite en fin de requête, en attendant un correctif officiel dans la prochaine version de Rails.

À mesure que les applications web à héberger se développent, disposer d’un installer automatisé devient de plus en plus souvent une étape obligatoire, là où elle n’était qu’un luxe il y a encore quelques mois. En aucun cas les utilisateurs ne devraient plonger les mains dans le code, pas même pour remplir les informations nécessaires à la connexion à une base de données. Les hébergeurs ne pouvant automatiser le déploiement de toutes les applications web existantes, il revient donc aux équipes de développement de simplifier l’installation de leur produit.

Si le setup de Wordpress peut être cité comme exemple de simplicité et de concision, les applications Rails ne sont heureusement pas en reste (mais bien en REST), et un installer, originellement développé pour Typo existe. On ne dispose malheureusement pas toujours de ce dernier, soit par manque d’accès SSH sur le serveur, soit parce que l’application ne le supporte pas, soit parce qu’elle utilise Rails 2.0 pour lequel l’installer n’a pas encore été mis à jour.

1. Porter Standard Issue.
2. Corriger le plugin Flickr qui crash comme une m@#$.
3. Terminer l’éditeur de thèmes.
4. Terminer la détection et le retrait des plugins retirés (Bastieeeeeeeeeeen).
5. Vérifier que les tests passent.
6. Mettre à jour le fichier de traduction français.
7. Fabriquer la gem et les archives sources.
8. Écrire le CHANGELOG.
9. Traduire le CHANGELOG.
10. Écrire la release note.
11. Traduire la release note.
12. Sortir Typo 5.0.
13. Manger, prendre une douche, dormir.

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…