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

Plusieurs personnes se sont plaintes de la lenteur des dernières versions de Typo, le blogware en Ruby on Rails, sans que quoi que ce soit dans le code puisse justifier de tels problèmes de performances.

La solution a été trouvée un peu par hasard par Mathijs van Zuijlen : une ligne mal formée forçait le cache à fonctionner en mode testing, ce qui signifiait au final pas de cache du tout. Incidemment, cela empêchait également l’envoi parallèle des trackbacks au moment de la publication d’un billet.

Si vous utilisez la version de développement, la correction est présente dans le Changeset 1477.

Si vous utilisez la version stable de l’application, il vous suffit de commenter la première ligne du fichier vendor/memcache-client/lib/memcache.rb.

Puis, redémarrez Typo.

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.

Bonsoir à toutes et à tous,
Nous ne désirons pas vous spamer ou vous inonder de communiqués de presse mais il nous a semblé plus qu’évident que vous deviez avoir l’information en primeur… N’hésitez pas à me dire si vous ne souhaitez plus recevoir d’information sur chut chut pas de marque et je suis à votre disposition pour vous mettre en contact avec les fondateurs…

Suit un communiqué de presse non sollicité présentant de manière stéréotypée et insipide à souhait un quelconque service web comme il s’en ouvre des dizaines ces dernières semaines.

Évidemment qu’il ne s’agit pas de spam, pas plus qu’il ne s’agit d’un communiqué de presse ; c’est tout simplement un scoop sensationnel que l’auteur de ce mail m’adresse en exclusivité – ainsi qu’à un bon paquet d’autres blogueurs mis en copie carbone comme en atteste l’absence de mon adresse courriel dans le champ to de cet envoi non sollicité.

Ce qui aurait pu passer pour une bévue il y a encore trois ou quatre ans de la part d’une agence de relations publiques relève aujourd’hui de la connerie pure et simple au vu des nombreux précédents qui ont fait couler un paquet d’encre virtuelle ces dernières années. Il existe encore des agences qui imaginent les blogueurs tout juste bons à complaisamment relayer leurs envois massifs et pas sollicités pour deux sous sans la moindre réaction négative. Il en est visiblement des bons usages dans les boites de RP comme des standards du web chez les développeurs et les intégrateurs : on s’imagine qu’à force de coups sur les doigts, les bases sont acquises, et dès qu’on relève un peu la tête, on se rend compte que tout reste à faire.

Je ne donne généralement pas le nom des sociétés contre lesquelles je râle, je fais une exception pour cette fois. Il s’agit de Rescue Team Communications, à n’appeler qu’en dernier recours.

Je recherche actuellement un outil ou un service me permettant de créer des sondages et de les intégrer ensuite à une page web, sous forme de formulaire ou d’un bout de javascript, bien que cette solution ne me satisfasse pas entièrement vu son caractère peu accessible.

S’il s’agit d’une solution hébergée, peu me chaut qu’elle soit payante tant que cela reste dans les limites du raisonnable, et s’il s’agit de scripts à héberger moi-même, il faudrait que ce soit du Ruby.

La solution devra être un minimum complète, puisque les sondages feront de 10 à 20 questions, et chaque question comptera jusqu’à 10 réponses possibles.

Si vous connaissez quelque-chose comme ça, je suis preneur, dans le cas contraire, je coderai un greffon en Ruby on Rails en rentrant de week-end.

Je ne sais pas si c’est le printemps qui fait ça, ou simplement une conjoncture exceptionnellement favorable aux NTIC, mais je reçois quotidiennement quatre ou cinq “propositions de collaboration” de la part d’entreprises ou de SSII oeuvrant dans le nouveau web, comme elles aiment se définir.

Bien qu’actuellement en poste, j’aime bien recevoir ce genre de sollicitations : c’est bon pour l’ego, et, si ça se trouve, le job de ma vie va me tomber dessus, pouf, comme ça, sans prévenir. Malheureusement, tout n’est pas rose au pays du 2.0, et comme le montrent ces quelques chiffres pris sur les 20 dernières offres reçues :

• 15 admettent avoir trouvé mon profil sur ce blog mais 3 seulement affirment le lire régulièrement.
• 17 présentent plus de 5 fautes d’orthographe et de grammaire dans le corps du mail.
• 4 ont plus de 10 fautes de grammaire et d’orthographe.
• 11 oublient de me dire bonjour.
• 2 omettent de mettre un sujet à leur mail.
• 4 ont visiblement oublié qu’une phrase commençait par une majuscule et pouvait éventuellement contenir des signes de ponctuation.
• 9 font moins de 7 lignes signature comprise.
• 12 ne présentent pas leur société.
• 6 me disent travailler sur un projet faramineux qui va les emmener aux sommets du NASDAQ, mais une seule m’a vaguement dévoilé le sujet général du projet.
• 3 ont envoyé leur mail à eux même et à un certain “undisclosed recipients”.
• Une s’est prise une fin de non recevoir de ma part, et est tout de même revenue à la charge’
• Et j’en oublie certainement.

Que seraient des statistiques sans remarques ni interprétation ?

La première chose qui me vient à l’esprit est évidemment que ces gens là ont, pour la très grande majorité, appris le français sur Skyblog. Je sais bien que c’est un peu facile, mais cela pourrait expliquer pourquoi ils n’ont pas activé la correction orthographique de leur logiciel de courrier.

La seconde, qui pourrait expliquer pas mal de choses, est que, persuadés de devenir les futurs maîtres du monde, ils se permettent de prendre leurs futurs valets pour de la merde. Quand je vois l’attention que portent aujourd’hui les sociétés à la qualité orthographique et rédactionnelle des CV, je me dis que les offres d’emploi pourraient bien en faire autant.

Ma troisième pensée est quelque part un peu plus inquiétante. Il semblerait que la majorité des entreprises du web 2.0 amenées à me contacter aient été montées par des adolescents de 16 ans dans leur garage persuadés de se revendre quelques centaines de millions d’euros à Google dans quelques mois. Il risque d’y avoir des pleurs et des grincements de dents, sans compter une bulle 2.0 que je vois pointer à termes, encore que…

Et la quatrième va à I2BP. Vous avez un projet qui va révolutionner le web ? Vous pensez pouvoir faire fortune et voulez que nous collaborions ? Soit, mais dites m’en un peu plus alors. Si vous voulez que nous travaillions ensemble c’est que vous souhaitez nouer une relation de confiance avec moi. À vous de faire le premier pas pour que je vois qu’on peut vous faire confiance. Comme je le disais à un chef d’entreprise pas plus tard qu’aujourd’hui, je ne tiens pas à mettre le futur de ma famille entre les mains du premier abruti venu.

D’une manière plus générale, j’ai l’impression que les entrepreneurs 2.0 (en italique, pour ne pas choquer les entrepreneurs sérieux) confondent détente et je m’en foutisme, convivialité et impolitesse. Si vous souhaitez qu’on vous prenne au sérieux, et qu’on ne vous impute pas les erreurs de vos prédécesseurs, il serait bon, messieurs, que vous songiez à faire montre d’un peu de rigueur dans votre communication.

Sur ce, je vous laisse, j’ai des specs à terminer si je veux les rendre dans les temps.

À bon entendeur…

Lors du premier Yulbiz Paris, j’ai eu la chance de rencontrer Patricia Gallot-Lavallée, consultant web chez Kenazart Strategy Interactive. Patricia finalise en ce moment son premier livre ”Internet, donne-moi ce que je veux !” (dont la couverture resemble furieusement à celle de Don’t make me think), ouvrage d’ergonomie dans lequel elle passe au crible pas moins de 60 modèles de navigation afin d’en extraire la substantifique moelle :

Je rentre à l’instant du tout premier Yulbiz Paris, excellente soirée passée à discuter autour d’un verre avec une ergonome, des entrepreneurs, un designer web2.0, une hôtesse de l’air, des experts en buzz marketing… Comme d’habitude, des discussions nombreuses et très instructives dont certaines devraient rapidement se concrétiser, stay tuned.

Une tradition venue du grand frère canadien veut que chaque participant à un Yulbiz réponde à une question en rapport avec l’événement ; les réponses sont ensuite collectées, puis publiées.

Ce soir, la question portait sur les grandes tendances du web pour les années à venir. Difficile d’y répondre vue la vitesse à laquelle les choses évoluent tant du côté des interfaces riches que de la géolocalisation, sans compter la perspective d’une “bulle 2.0” qui viendrait casser le dynamisme ambiant. J’ai fini par me prêter au jeu, et mes réponses portaient sur :

1. Mobilité.
2. Micropaiement.
3. Personnalisation.

Mobilité

Mobilité, comme web mobile et ubiquité, mais pas forcément tel qu’on l’imagine aujourd’hui. À mon sens la principale erreur qui empêche le web mobile de décoller vient du fait que l’on cherche à transposer sur des terminaux réduits disposant d’une bande passante ridicule un modèle qui prévu pour des écrans d’une résolution quatre fois supérieure et particulièrement gourmand dans les échanges client / serveur.

Micropaiement

Micropaiement, depuis que j’ai découvert à l’occasion d’un séminaire du W3C les usages pratiqués dans certains pays en voie de développement. Là bas, le téléphone mobile permet de régler ses impôts sans disposer d’un compte en banque. On devrait aussi voir fleurir des solutions de paiement sur le net destinées à des personnes ne disposant pas d’une carte de crédit ou ne souhaitant pas confier leur numéro de carte bancaire au web. Les français éprouvent encore beaucoup de réticences à payer en ligne, et il faudra probablement encore une génération pour que cette pratique se généralise.

Personnalisation

Personnalisation, parce que le médium électronique permet d’offrir à chacun ce dans quoi il se sentira le plus confortable, où qu’il soit. Cela rejoint la notion d’ubiquité dont je parlais plus haut. À l’inverse de Camus qui aimait se retrouver vraiment à l’étranger quand il quittait la France, il semble aujourd’hui que la tendance, tout en étant à l’exotisme, soit aussi de se retrouver chez soi où que l’on aille. À cela, ajoutons qu’en permettant à leurs utilisateurs de personnaliser leur produit de manière parfois amusante, les services recourant à ce genre de techniques jouent sur l’ego de l’utilisateur qui se sent par là même unique. Les jeux personnalisables du français Pictogames, ou de l’allemand Playmygame en sont deux exemples qui ne sont pas sans me rappeler les “livres dont vous êtes le héros” de mon enfance.
Je note au passage que cette tendance, si elle venait à se confirmer pourrait relancer la notion de valeur par la rareté au sein d’un média de masses et d’abondance, mais c’est une idée sur laquelle je ne développerai pas ce soir.

Et vous, quelles seront pour vous les grandes tendances des trois ans à venir ?

Mister Wong, un service de social bookmarking particulièrement populaire outre-rhin vient de lancer aujourd’hui sa pré bêta privée à destination du public français.

Utilisateur de Delicious de la première heure, j’ai répondu à l’invitation de leur équipe à participer au test de leur application francisée pour voir si cela pouvait valoir le coup de changer de crémerie.

Le service est intéressant et relativement classique. Aucune nouveauté fracassante, mais pas non plus d’absence choquante. Tout en proposant des fonctionnalités similaires à Delicious – autocomplétion des tags, toolbar Firefox et Internet Explorer fonctionnant même sous Flock – API, plugins et widgets pour vos blogs, il prend une orientation un peu plus sociale que son grand frère qui privilégie beaucoup plus largement le bookmarking, raison pour laquelle je l’ai adopté.

Le profil d’abord, est plus élaboré et permet de rentrer en contact avec les autres utilisateurs. Mr Wong vous permet de régler le degré de confidentialité de chacune des informations affichées – nom, prénom, messagerie instantanée, url. Tout en étant plus complet que ce que j’avais rempli sur Delicious, l’adepte des outils de mise en relation regrettera cependant qu’il ne soit pas plus fourni que ça.

La principale différence entre Delicious et Mr Wong réside principalement dans la notion de groupes d’utilisateurs, publics ou privés. Vous pouvez ainsi diffuser des listes de liens à un public restreint, ou créer des groupes autour de centres d’intérêts transverses là où les tags sont parfois trop précis.

Côté migration, tout s’est très bien passé, puisque Mr Wong a avalé en un instant tout mon export Delicous sans broncher, on peut donc très facilement passer de l’un à l’autre. Mr Wong a également l’avantage – et l’inconvénient – d’être plus beau malgré sa mascotte rapidement insupportable et plus soigné que Delicious, mais ce côté spartiate fait partie de ce qui m’a séduit là bas.

Bien que ne lui ayant pas trouvé de défauts majeurs, je ne quitterai cependant pas Delicious pour autant. La principale raison vient pour du cloisonnement linguistique de l’application. Je suis en effet un certain nombre de tags Delicious dans mon agrégateur RSS, et la grande majorité des contenus intéressants sont publiés par des anglophones, les francophones ayant, d expérience, tendance à ne publier que des contenus dans la langue de Molière. C’est un avantage que je ne retrouve pas dans une application franco-française, laquelle manque en plus cruellement d’utilisateurs à ce jour, et je ne souhaite pas me disperser pour l’instant.

[edit] Il me reste quelques invitations, si vous les voulez, signalez vous dans les commentaires. Étant d’humeur joueuse, je les donnerai au hasard de /dev/urandom et non dans l’ordre d’arrivée, qu’on se le dise.

Les premiers Yulbiz France se dérouleront vendredi premier juin 2007 à partir de 18 heures chez Urbi et Orbi, 93 rue Montmartre dans le deuxième arrondissement de Paris.

Derrière ce nom étrange se cache une intéressante pratique d’affaires qui veut rassembler blogueurs et professionnels du web autour d’un verre pour discuter des tendances passées, présentes et à venir et échanger des cartes de visite. Idéal si vous voulez étoffer votre réseau, trouver de futurs associés, partenaires… ou employeurs.

L’un des traits dominants du web 2.0 semble être la volonté de laisser un formalisme jugé trop traditionnel et dépassé au profit de spontanéité et de chaos organisé. Les plus “vieux” d’entre vous se souviendront certainement des flashmobs qui avaient fleuri entre l’été et l’automne 2003 – déjà – rassemblements éclairs organisés au dernier moment pour donner une impression de spontanéité. Hier, c’étaient les les Barcamp, ces non conférences, chaos organisé dont devait sortir la lumière, et aujourd’hui Twitter, que ses zélotes voient comme le parangon de la spontanéité et de l’abolition des barrières de l’espace et du temps, rien de moins.

Si vous comptez passer vendredi n’hésitez pas à vous signaler dans les commentaires, je serai ravi de vous voir ou vous revoir.

Durant les 7 jours précédant la mise en ligne de ce nouveau thème – qui ne passe toujours pas sous Internet Explorer 6 par flemme de ma part – Feedburner m’annonçait un nombre moyen de 541 abonnés à mon flux RSS. Trois semaines jours après l’arrivée de ce gros bouton orange, le nombre moyen d’abonnés sur les 7 derniers jours est passé à 679, soit une progression en valeur absolue de 25% en 20 jours.

Il me reste maintenant à travailler sur mon référencement. J’ai déjà commencé en changeant la structure du contenu et en rapatriant le site en France (merci Otto pour les conseil, si tu en as d’autres, je prends), mais il me reste encore pas mal de travail de ce côté là.

À titre de comparaison, cela représente ma progression totale entre le 15 février et le 5 mai 2007.