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

Présentation Guillaume Desrat, président de l’association Ruby France sur les applications web en entreprise avec Ruby on Rails donnée lors du premier Railscamp Paris.

Cyril Mougel a réalisé une intéressante présentation de Ruby on Rails destinée à des développeurs ne connaissant ni le langage ni le framework associé. Je vous recommande fortement la lecture et la diffusion de ce slide autour de vous.

S’il existe un grand nombre de manières de déployer et de faire tourner des applications développées avec Ruby on Rail, comme, au hasard, ce blog, l’hébergement de masse reste encore un vrai problème, principalement pour des raisons de complexité de configuration côté serveur. L’absence sous Apache d’un modrails comme il existe un modphp y était certainement pour beaucoup, jusqu’à la sortie hier de Passenger, aussi appelé modrails. Enfin terminés les atermoiements entre mongrel + modproxy, ou fastcgi, avec tous les inconvénients inhérents à ces deux solutions. Il existe certes d’autres solutions logicielles, parmi lesquelles ma préférée va à Nginx + Thin, cependant quand on héberge des sites faisant très massivement appel à mod_rewrite, ces dernières sont malheureusement exclues (à moins que quelqu’un ne me porte les quelques 500 rewrite rules qui restent encore ici et là).

Mais sans plus attendre, rentrons immédiatement dans le vif du sujet, l’installation de mod_rails pour Apache 2 sous Debian.

Les problèmes de montée en charge sont choses courantes pour un site ou une application web une fois atteint un certain succès. Ces derniers sont bien trop souvent négligés, généralement jusqu’au jour où se trouve atteinte la limite critique entre l’inconfort et l’instabilité. Le trend actuel veut qu’il soit à la fois plus simple et moins cher de rajouter des machines que de reprendre son code en profondeur pour l’optimiser. Encore faut-il que l’application permette un redimensionnement de ce genre sans rentrer dans une phase de refactoring complet. Évidemment, avant d’en arriver à une solution aussi lourde, il vaut mieux s’assurer que tout a été fait pour exploiter au mieux les ressources disponibles, et cela passe notamment par un peu d’optimisation côté serveur.

Depuis maintenant 3 ans que l’AJAX a commencé à rentrer dans les usages du développement web, on a pu assister à un peu tout et surtout à n’importe quoi. Souvent, la tentation fut forte de mettre d’en mettre pour le seul principe de suivre la mode du moment, au mépris de l’expérience utilisateur et des besoins fonctionnels réels. S’il est très facile de se tromper, il existe pourtant des endroits assez génériques où ajouter une pointe d’AJAX par dessus le fonctionnement normal du site – et j’insiste sur ce point – améliore l’expérience de navigation, simplifie l’utilisation du site, et rend la vie bien plus agréable.

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.

À 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.

À mesure que le web gagne en maturité, les exigences des clients sur les sites et les projets livrés deviennent de plus en plus importantes. Au point d’avoir, depuis au moins deux ans, atteint sinon dépassé les exigences de design, ergonomie et stabilité autrefois réservées aux seuls éditeurs de logiciels. Dans un premier temps apparaître comme un point particulièrement positif, preuve que le web a gagné en maturité et cessé d’être un terrain de jeu pour innovateurs frappé d’un certain jeunisme, à la fois par les expérimentations parfois catastrophiques de la première bulle Internet, et par un soucis de qualité souvent au rabais. Cependant, cette exigence, venue à la fois des clients et des utilisateurs, a pour nous professionnels du web des impacts non négligeables et crée des problématiques avec lesquelles il nous faut apprendre à composer, l’imputation des problèmes étant souvent à sens unique quand les solutions à apporter sont clairement multilatérales.