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

Dimanche dernier, je me posais de très sérieuses questions quant à l’avenir de Typo, le blogware développé en Ruby on Rails qui permet à ce site de tourner. Je ne reviendrai pas sur la liste des griefs qui me poussaient à envisager un fork du projet – tout en préparant la migration du projet original sur mes serveurs, cohérence quand tu nous tiens – mais cela n’arrivera pas.

Depuis hier soir, je fais partie de l’équipe de développements de Typo, et mon point de vue concernant l’utilisation de HAML dans le thème de base a été pris en compte.

Mes principales priorités pour le projet sont (dans l’ordre chronologique) :

• L’intégration de mon patch de refonte fonctionnelle de l’administration : passer d’un modèle basé sur les contrôleurs / actions à un modèle de navigation basé sur l’utilisation réelle d’un outil de blogging. Une démonstration est d’ors et déjà visible sur ma plate-forme de démonstration de le version de développement. Les identifiants / mots de passe sont admin / admin.
• La sortie d’une version 4.1 stable basée sur Ruby on Rails 1.2 et intégrant ma refonte de l’administration le plus rapidement possible, probablement d’ici la fin du mois.
• Terminer la refonte complète de l’administration, aussi bien en termes fonctionnels qu’en terme d’IHM. Un gros effort sera fait sur l’accessibilité notamment au niveau de la sidebar.
• Ajouter le support de l’internationalisation sur l’application. Je l’avais fait à l’époque sur la version 2.6.0 pour mon usage personnel, et cela ne représentait rien de vraiment compliqué.

Et pour paraphraser un de nos anciens premiers ministres, la roadmap est longue, mais les releases sont proches.

Typo est un blogware développé à l’aide du framework Ruby on Rails. Il fait tourner ce blog depuis l’abandon simultané de Wordpress et du PHP. Malheureusement, l’avenir de ce projet qui pourrait être de qualité ne prête pas vraiment à l’optimisme :

• Arrêt total des développement durant plusieurs mois, période suivie par la mise hors service du site principal sans aucune explication officielle durant près de trois mois.
• Aucune visibilité quant à la possible sortie d’une prochaine version stable – même mineure – compatible avec Rails 1.2.
• Des corrections et des contributions dont l’intégration prend des semaines, si ce ne sont des mois.
• Une hémorragie d’utilisateurs qui préfèrent migrer vers Mephisto ou – ironie – vers des outils en PHP.
• Des développeurs aux abonnés absents, et aucune intégration de sang neuf.
• Et, dernièrement, le changement pur et simple du système de templates de RHTML vers HAML sans rétro compatibilité qui rend du même coup tout le parc de thèmes de Typo inutilisable.

Le fork d’un projet – c’est à dire sa séparation en deux branches – est toujours douloureux dans le monde de l’open source. D’une part il monte souvent deux communautés l’une contre l’autres là où elles collaboraient parfaitement auparavant, d’autre part, il disperse des talents et des individus qui pourraient travailler ensemble afin de réaliser des applications de grande qualité. C’est aussi un des avantages posés par l’open source : quand un projet est moribond ou va clairement dans le mur, une équipe peut se le réapproprier pour en faire ce qu’il lui semble le mieux, en profitant du travail réalisé auparavant.

J’ai posé quelques questions aux développeurs de Typo quant à l’avenir du projet. S’il s’avérait que la direction actuelle se maintenait, un fork ne serait pas à exclure depuis la version précédant l’intégration de HAML afin d’y ajouter ce qui y manque le plus :

• Une administration utilisable.
• Le support de l’internationalisation.

Cette idée est d’autant plus délicate que j’apprécie beaucoup les développeurs et la (petite) communauté rassemblée autour de Typo, mais voir ce projet mourir serait un beau gâchis. L’avenir seul nous dira ce qu’il en est.

What futur for Typo ?

Typo is a blogware developped with the famous Ruby on Rails framework. It powers this blog since I quit both Wordpress and PHP. Unfortunately, in spite being an application with a real potential, this project’s futur looks pretty dark to me :

• Devs have been stopped for a few months. Then the whole website has been out of order for 3 months without any official explanation.
• Can’t get any information about the next stable release date, which would include Rails 1.2 support.
• Contributions take weeks or months to be taken into account (I don’t talk about mines).
• Lots of users are migrating from Typo to Mephisto or – isn’t it irony ? – to PHP based applications.
• And – last but not least – the base template have been rewriten in HAML which makes them impossible to edit with a simple HTML editor.

Forking a project is never a good thing in the open source world. It creates 2 communities with opposed views and interests when everybody was working fine together before. It’s also a strength of open source : when a project is dying or taking a really discutable direction, some people can restart from what have already been done and make a better product. I’ve been asking the development team some question, and if the project keeps going the way it is today, I think about forking to the last version preceding HAML integration to add what lacks the most :

• A nice and usable admin zone.
• i18n support.

I’m really reluctant to this. I like the (small) community built around Typo, and I’ve recently offered to migrate the whole Typosphere site on my server. But I really don’t want to see this project die. Hope to give some news about it soon.

La version à venir de la Debian apporte son lot de mises à jour intéressantes, et parmi elles, pas des moindres, l’arrivée d’Apache 2.2 en tant que serveur web par défaut et de Ruby 1.8.5, propre à faire tourner Ruby on Rails dans de bonnes conditions. Alors pourquoi ne pas franchir le pas et enfin vous mettre à ce merveilleux framework dont vous entendez monts et merveilles depuis bientôt 4 ans, d’autant qu’on vous prend par la main pour mettre en place votre environnement de développement. Un didacticiel pour vous emmener pas à pas vers le paradis des applications web (rien que ça).

Apache 2.2 et Mysql5

Dans un premier temps, vous allez installer le serveur web Apache 2.2, et la version 5.0 de la base de données MySQL. Ce didacticiel ne traite pas encore de PostgreSQL, mais ça ne saurait tarder.

7el.net:~$ sudo aptitude install mysql-client mysql-server apache2-mpm-prefork apache2.2-common apache2-utils
[...]
7el.net:~$ sudo a2enmod rewrite

Normalement, aptitude devrait vous demander un mot de passe pour l’administrateur. Si ce n’est pas le cas, tapez juste

7el.net:~$ mysqladmin -u root -h localhost -p 'toto'

Mod_fcgid 2.0

Malheureusement pour les utilisateurs de Ruby on Rails – et d’une manière générale pour n’importe quelle application utilisant fastcgi, trac par exemple si vous ne souhaitez pas installer modpython – Etch n’inclut pas le module Apache modfcgid pour la version 2.2 du serveur. Le paquetage est en effet cassé, et seule la version pour Apache 2.0 est supportée. Il vous faudra donc à priori choisir entre :

• Installer Apache 2.2, PHP5 et vous passer de mod_fcgid.
• Ou bien installer Apache 2.0 et mod_fcgid, mais vous passer de PHP5 (pourquoi pas).
• Ou encore backporter mod_fcgid depuis la version unstable de la Debian.

Vous allez donc télécharger les sources de mod_fcgid depuis la version unstable de Debian, puis reconstruire et installer le paquetage.

Commencez par ajouter la ligne suivante à votre fichier /etc/apt/sources.list :

deb-src http://mirrors.kernel.org/debian unstable main contrib non-free

7el.net:~$ sudo aptitude update 7el.net:~$ cd /tmp
7el.net:/tmp$ sudo apt-get build-deps libapache2-mod-fcgid-2.0
[...]
7el.net:/tmp$ apt-get -b source libapache2-mod-fcgid-2.0

Et là, c’est le drame : au moment d’activer le module à l’aide d’a2enmod, dpkg vous annonce “ce module n’existe pas”. Pour une raison que j’ignore, le paquetage n’a pas copié les fichiers fcgid.conf et fcgid.load dans /etc/apache2/mods-avaliable. Pas de panique, vous allez le faire et tout va rentrer dans l’ordre.

7el.net:/tmp$ cd libapache2-mod-fcgid-2.0/debian
7el.net:/tmp/libapache2-mod-fcgid-2.0/debian$ sudo cp fcgid.load fcgid.conf /etc/apache2/mods-avaliable
7el.net:/tmp/libapache2-mod-fcgid-2.0/debian$ a2enmod fcgid
7el.net:/tmp/libapache2-mod-fcgid-2.0/debian$ /etc/init.d/apache2 restart


Toi aussi tu veux un mod_fcgid avec bas de caisse, phasres violets et une sono de 10000 watts ?

Afin de bénéficier de meilleures performances, nous allons modifier la configuration de base de mod_fcgid. Remplacez le fichier /etc/apache2/mods-available/fcgid.conf par ceci :

<IfModule mod_fcgid.c>
  AddHandler fcgid-script .fcgi
  SocketPath /var/lib/apache2/fcgid/sock
  IPCConnectTimeout 6
  IdleTimeout 60
  ProcessLifeTime 6000
  MaxProcessCount 32
  DefaultMaxClassProcessCount 5
  IPCConnectTimeout 6
  IPCCommTimeout 6
</IfModule>

La signification de tout ceci peut sembler obscure, aussi quelques éclaircissements s’imposent.

• AddHandler fcgid-script .fcgi : nous disons explicitement à Apache d’exécuter tous les fichiers portant l’extension .fcgi avec mod_fcgid.
• SocketPath /var/lib/apache2/fcgid/sock : le chemin de la chaussette à l’aide de laquelle Apache et le serveur de fcgi vont communiquer.
• IPCConnectTimeout 6 : timeout d’une connexion à un processus fcgi.
• IdleTimeout 60 : une application lancée par fcgi se terminera après 60 secondes d’idle. Cela permet de ne pas avoir trop de processus lancés en même temps.
• ProcessLifeTime 6000 : durée maximum d’un processus fcgid.
• MaxProcessCount 32 : nombre maximum de processus fcgid lancés en parallèle. À ajuster en fonction de la charge de votre serveur.
• DefaultMaxClassProcessCount 5 : nombre maximum d’instances d’une même application fcgid pouvant être lancées en parallèle.
• IPCConnectTimeout 6 : timeout d’une connexion à un processus fcgid.
• IPCCommTimeout 6 : timeout d’une communication avec un processus fcgid.

Vous ne trouvez pas ça tellement plus clair ? Ce n’est pas grave, et ça ne vous empêchera pas d’avancer plus avant dans ce didacticiel.

Ruby et Gem

Vous allez maintenant installer Ruby, rdoc et irb depuis les paquetages Debian, puis Gem à l’aide des sources afin de bénéficier de la toute dernière version. Gem est le gestionnaire de paquetages de Ruby, un outil absolument indispensable.

7el.net:~$ sudo aptitude install ruby1.8 rdoc irb
[...]
7el.net:~$ cd /usr/bin
7el.net:/usr/bin$ sudo ln -s ruby1.8 ruby


Récupérez maintenant les sources de la dernière version de Gem, actuellement la 0.9.1, et installez la.

7el.net:/usr/bin$ cd /tmp
7el.net:/tmp$ wget http://rubyforge.org/frs/download.php/16452/rubygems-0.9.1.tgz
[...]
7el.net:/tmp$ tar xvzf rubygems-0.9.1.tgz
7el.net:/tmp$ cd rubygems-0.9.1
7el.net:/tmp/rubygems-0.9.1$ sudo ruby setup.rb


Rails, MySQL et fcgid

Il reste que Ruby ne peut pas encore converser avec fcgid ni avec MySQL – ou PostgreSQL si vous avez opté pour cette solution.

Dans un premier temps, il va vous falloir installer les en-têtes des librairies nécessaires à l’installation des gems mysql et fcgid :

7el.net:~$ sudo aptitude install libmysqlclient-dev libfcgi-dev
7el.net:~$ sudo gem install mysql
7el.net:~$ sudo gem install fcgid


Typo

Typo dispose d’un programme d’installation, mais il implique d’utiliser SQLite en tant que base de données. Vous allez donc commencer par récupérer la dernière version de l’application sur Typosphere (hébergé ici à partir de demain ou après demain, le temps de terminer ma conf), et créer une base de données pour votre application.

Pas une mais 3 bases

Nous allons en fait créer 3 bases de données, correspondant aux 3 environnements d’une application Rails : développement, production et test.

7el.net:~$ mysql -u root -p
[...]
mysql> create database typo;
mysql> grant all privileges on typo.* to 'typo'@'localhost' identified by 'typosaibo'
mysql> create database typo_dev;
mysql> grant all privileges on typo_dev.* to 'typo'@'localhost' identified by 'typosaibo'
mysql> create database typo_test;
mysql> grant all privileges on typo_test.* to 'typo'@'localhost' identified by 'typosaibo'


7el.net:~$ cd /var/www
7el.net:/var/www$ sudo wget http://rubyforge.org/frs/download.php/12504/typo-4.0.3.tgz
7el.net:/var/www$ sudo tar xvzf typo-4.0.3.tgz
7el.net:/var/www$ sudo mv typo-4.0.3 typo


Nous allons maintenant configurer la base de données de Typo :

7el.net:/var/www$ cd typo
7el.net:/var/www/typo$ sudo vim config/database.yml
7el.net:/var/www/typo$ sudo rake RAILS_ENV=production db:migrate


Les petites particularités d’Apache 2.2

Parmi les nouveautés d’Apache 2, nous avons le retrait du support des options du .htaccess. Nous allons donc devoir supprimer une ligne de celui de Typo et les ajouter dans le vhost Apache que nous allons créer pour lui.

7el.net:/var/www/typo$ sudo vim public/.htaccess

La ligne incriminée :

Options +FollowSymLinks +ExecCGI

Notre virtualhost va alors ressembler à :

7el.net:/var/www/typo$ sudo vim /etc/apache2/sites-avaliable/typo

<VirtualHost 87.106.13.102:80>
  ServerAdmin root@typo
  DocumentRoot /var/www/typo/public
  Options +FollowSymLinks +ExecCGI
  ServerName typo.t37.net

  CustomLog /var/log/apache2/log.typo.t37.net combined
  Errorlog /var/log/apache2/error.typo.t37.net
</VirtualHost>

Il s’agit évidemment d’une configuration minimale, qui permet à Typo de tourner. Il ne nous reste plus qu’à activer le site et à redémarrer Apache.

7el.net:/var/www/typo$ sudo a2ensite typo
7el.net:/var/www/typo$ sudo chown -R www-data:www-data *
7el.net:/var/www/typo$ sudo /etc/init.d/apache2 restart


Et voilà, ça marche.

Typo est l’outil de publication développé avec Ruby on Rails qui propulse ce blog pratiquement depuis ses débuts. Malgré des erreurs de jeunesse, principalement en termes d’ergonomie de l’IHM et des performances, toutes deux en passe d’être réglées dans la version de développement, Typo dispose d’indéniables atouts. On pourra notamment citer une très belle collection de thèmes, une API de greffons particulièrement puissante, la construction de la “sidebar” par simple cliquer / déplacer des éléments, ou une “live preview” particulièrement bien faite.

Afin de permettre au plus grand nombre de découvrir cet outil sans avoir à l’installer, je viens de mettre en place deux plates-formes de test en libre accès :

• La première permet d’accéder à la version stable de l’application.
• La seconde permet d’accéder à la version de développement de Typo, mise à jour quotidiennement.

Vous pouvez accéder à l’ensemble des fonctionnalités de l’application à deux bémols près :

1. Afin d’éviter le spam, la base de données est remise à zéro toutes les heures.
2. Dans le même but, les pings vers l’extérieur ont été désactivés.

N’hésitez pas à faire remonter vos impressions, elles seront transmises à l’équipe de développement, ou directement prises en compte ici dans le cas où elles concerneraient l’ergonomie de l’administration actuellement en cours de refonte. Alors enjoy and have fun!.

[edit]
Le lien vers la version stable était cassée. Il est maintenant réparé.

I’ve just released a “Recent Posts” sidebar plugin for Typo, the Ruby on Rails blog engine that powers this blog. It displays the last posts title and a snippet of the post body.

You can configure the title of the plugin, the number of posts and the excerpt’s length in the sidebar admin.

Download and install

Download

Download Typo “Recent Posts” plugin.

Requirements

Typo V4.0 and above (trunk works) with plugins in /vendor/plugins.

Install

Just unpack the archive into the /vendor/plugins folder of your Typo install. Restart your Typo instance. Go to the admin / sidebar to configure it. You’re done.

Licence

The plugin is released under the MIT Licence.

Contrairement à ce que pourraientt laisser penser un site à l’abandon, et un manque particulièrement remarquable de communications, Typo, le moteur de blog basé sur Ruby on Rails qui fait tourner ce blog n’est pas mort et enterré au cimetière des projets open source malchanceux. Ses développeurs développent, ses testeurs testent et sa communauté d’utilisateurs… l’utilise quotidiennement.

Que ceux qui souhaitent installer Typo se rassurent, la mort temporaire du site projet – suite à un bug de Trac faisant monter le serveur en charge au point de le rendre inutilisable – n’empêche en rien sa mise en place. Des procédures adaptées existent pour ceux qui souhaiteraient l’utiliser au quotidien ou tester la version de développement afin d’en rapporter les bugs et lacunes.

Version stable :

La dernière version stable de typo est la 4.0.3. Basée sur Ruby on Rails 1.1.6, elle s’installe à partir de la gem éponyme :

$ sudo gem -y install typo $ typo install chemin/vers/typo

Et le tour est joué.

Version de développement

Ce billet n’aurait probablement pas lieu d’être si Piers ne m’avait pas annoncé hier le passage de la version de développement de Typo sous Rails 1.2RC1 à l’occasion de la révision 1300. Rails 1.2, autrement nommé Rails Edge contient en standard le merveilleux SimplyRestful, et cela seul justifie la migration.

Le passage à Ruby on Rails 1.2 rend le trunk de Typo incompatible avec la branche 1.1 du framework, dont la version de développement se trouve néanmoins dans /vendor/rails. Ceci permettra d’éviter les problèmes de compatibilité.

Pour télécharger la version de développement de typo, il vous faut juste taper :

$ svn co svn://typosphere.org/typo/trunk typo

Et maintenant ?

Beaucoup de choses restent à faire sur Typo, et la TODO se remplit quotidiennement. Piers m’a annoncé hier vouloir travailler en priorité sur la refonte totale du système de feedback pour l’instant couplé au système de publication. Bien que ce changement demande de repenser l’architecture de la base, la souplesse de Rails limitera les temps de développement à deux ou trois heures. Je considère cette refonte comme capitale, car elle permettra la création de greffons autorisant la modération à priori des commentaires, l’ajout d’un système de capchas, ou d’outils de lutte contre les commentaires indésirables proches dans leur architecture de Spam Karma utilisé sous Wordpress.

Ce remaniement en entraînant d’autres, c’est toute une partie du système de publication qui s’en trouvera changé, particulièrement le content state qui gagnera en souplesse. On peut espérer à court terme l’arrivée d’un environnement véritablement multiutilisateurs dans lequel des directeurs de publication valideraient le contenu de multiples rédacteurs, ceci étant proposé sous la forme d’un greffon afin de ne pas surcharger le noyau de l’application.

Je retire tout ce que j’ai pu dire sur les limites de Typo en ce qui concerne les thèmes utilisateurs : loin de me limiter au XHTML généré par défaut par rails dans /app/views/..., le système de thèmes utilisé par Typo me permet de surcharger les fichiers .rhtml, pour mon plus grand plaisir.

Il me suffit pour cela de placer le fichier .rhtml à utiliser dans /themes/montheme/views/.... Il était autrefois possible de définir soi-même la sortie XHTML des plugins utilisés dans la barre latérale, mais depuis que ceux-ci sont passés dans /vendor/plugins/, ça ne semble plus aussi évident. Mais je sens que je vais trouver…

[edit]

La révision 1263 de la version de développement de Typo autorise à nouveau la modification du rendu des greffons de la barre latérale au niveau du thème. Pour une version de Typo antérieure supportant le déplacement des greffons dans /vendor/plugins, il suffit de remplacer la fonction render_sidebar() qui se trouve dans /app/helpers/ par :

    def render_sidebar(sidebar)
        if sidebar.view_root
            view_root = File.expand_path(sidebar.view_root) 
            rails_root = File.expand_path(RAILS_ROOT) 
            if view_root =~ /^#{Regexp.escape(rails_root)}/ 
                new_root = view_root[rails_root.size..-1] 
                new_root.sub! %r{^/?vendor/}, "" 
                new_root.sub! %r{/views}, "" 
                new_root = File.join(this_blog.current_theme.path, "views", new_root) 
                view_root = new_root if File.exists?(File.join(new_root, "content.rhtml")) 
            end 
            render_to_string(:file => "#{view_root}/content.rhtml", 
                :locals => sidebar.to_locals_hash)
        else
            render_to_string(:partial => sidebar.content_partial,
                :locals => sidebar.to_locals_hash)
        end
    end

Dix mois après ma migration de Wordpress vers Typo, je trouve enfin un moment pour réfléchir à un vrai bilan de mon utilisation de cet outil de blog développé en Ruby On Rails. Pour résumer, je dirais qu’il convient presque parfaitement à mes besoins et aux objectifs que je m’étais assignés lorsque j’ai choisi de changer d’environnement. Le tour de la question sous la forme d’une classique alternance de j’aime / j’aime pas.

Pour enfin devenir utilisable en production, il manquait à Typo un système de lutte contre le spam dans les commentaires et les rétroliens autre qu’une simple liste noire de mots clés et d’adresses IP. C’est chose faite depuis ce week-end avec l’intégration d’Akismet à la dernière gemme de Typo.

Une fois Typo installé, il vous faudra obtenir une clé Akismet en vous créant un blog sur Wordpress.com, et vous pourrez l’activer dans l’interface d’administration de votre Typo.

Bien que son intégration à Typo représente un grand pas vers l’ouverture de cet outil au grand public, je ne crois pas que l’utilisation d’Akismet soit une solution viable à terme. D’abord parce qu’Akismet nécessite une inscription préalable sur Wordpress.com, et que je ne vois pas très bien la relation entre les deux si ce n’est gonfler artificiellement les chiffres de la plate forme lancée par Matt Mullenweg. Ensuite, parce qu’utiliser Akiismet implique de confier une partie du traitement de ses données à des tiers, et que cela va à l’encontre de la démarche d’héberger soi-même son blog dans laquelle le contrôle de l’environnement et des données prime sur le reste. Enfin parce que la visibilité sur l’avenir de Wordpress.com et d’Akismet est nulle. Matt peut très bien décider de fermer totalement Akismet ou d’en rendre l’utilisation payante pour les sites externes à Wordpress.com.

Une solution plus viable serait évidemment d’éliminer totalement le spam, mais cela relève de la douce utopie. Typo gagnerait grandement à acquérir son indépendance énergétique, par exemple en portant Spam Karma 2 dont l’architecture modulaire conviendrait parfaitement à la création de greffons pour Ruby on Rails.

Pour enfin devenir utilisable en production, il manquait à Typo un système de lutte contre le spam dans les commentaires et les rétroliens autre qu’une simple liste noire de mots clés et d’adresses IP. C’est chose faite depuis ce week-end avec l’intégration d’Akismet à la dernière gemme de Typo.

Une fois Typo installé, il vous faudra obtenir une clé Akismet en vous créant un blog sur Wordpress.com, et vous pourrez l’activer dans l’interface d’administration de votre Typo.

Bien que son intégration à Typo représente un grand pas vers l’ouverture de cet outil au grand public, je ne crois pas que l’utilisation d’Akismet soit une solution viable à terme. D’abord parce qu’Akismet nécessite une inscription préalable sur Wordpress.com, et que je ne vois pas très bien la relation entre les deux si ce n’est gonfler artificiellement les chiffres de la plate forme lancée par Matt Mullenweg. Ensuite, parce qu’utiliser Akiismet implique de confier une partie du traitement de ses données à des tiers, et que cela va à l’encontre de la démarche d’héberger soi-même son blog dans laquelle le contrôle de l’environnement et des données prime sur le reste. Enfin parce que la visibilité sur l’avenir de Wordpress.com et d’Akismet est nulle. Matt peut très bien décider de fermer totalement Akismet ou d’en rendre l’utilisation payante pour les sites externes à Wordpress.com.

Une solution plus viable serait évidemment d’éliminer totalement le spam, mais cela relève de la douce utopie. Typo gagnerait grandement à acquérir son indépendance énergétique, par exemple en portant Spam Karma 2 dont l’architecture modulaire conviendrait parfaitement à la création de greffons pour Ruby on Rails.