Ours & Hippy — le blog [blog]

Comme promis, voici la seconde partie de mon article traitant de ce sujet ô combien passionant qu’est… mon blog. Finies la conception et les questions programmatiques profondes, et place à l’action, au déploiement, à la publication, au référencement ! Autant de sujets qui pourront surprendre le lecteur habitué de ce blog.

Mais pourquoi s’embêter avec tout ça, me souffle-t-on ? On a développé un produit, à n’en pas douter, technologiquement révolutionnaire… il faut maintenant le vendre ! Et pour un blog, pour un site Internet, pour un projet amateur tel que celui-ci, se vendre, cela signifie avant tout se faire connaître, et plus précisément, dans notre cas, être lu.^α

Dans ce petit billet, je vous propose un tour d’horizon des techniques que j’ai appliquées à mon blog, dans l’optique d’améliorer la navigation, pour les humains, comme pour les robots. Ces optimisations sont adaptées au modèle que j’ai choisi. Elles ne conviendront certainement pas à tout le monde, ou à tous les contextes. Mais si vous aussi vous tenez un blog, ou un petit site à but informatif, que vous êtes jeunes et candides, face à la perversion grandissante du Web, peut-être cet article saura-t-il vous apporter quelques réponses… à des questions que vous ne vous êtes sans doute jamais posées. :)

Vitesse, charge, hébergement

La première question qui se pose, une fois le blog codé, est de savoir où l’héberger. J’ai opté pour un hébergement à la maison, c’est-à-dire sur une de mes machines, derrière ma Freebox. C’est une décision critiquable, étant donné la petite bande passante dont dispose ainsi le site, mais jusqu’à maintenant, la faible fréquentation du blog ne s’est pas révélée être un problème pour ma connexion.

En contrepartie, l’hébergement chez soi permet une grande flexibilité. On configure soi-même la bête, on y déploie la plateforme que l’on veut : serveur HTTP, SSH, langages de script, bibliothèques appropriées, etc.

Mais si le cœur du blog, c’est-à-dire le script de génération des pages HTML, est toujours servi depuis chez moi, un des changements majeurs de cette nouvelle mouture est l’externalisation des ressources statiques. Ainsi, lorsque vous naviguez sur le site, les feuilles de style et les images sont en réalité téléchargées depuis media1.huoc.org, un domaine pointant sur un petit compte gratuit que j’ai pris chez alwaysdata. Le bénéfice est double : d’une part, je me décharge ainsi d’une petite moitié du trafic lié à chaque nouveau visiteur (les anciens ayant déjà ces fichiers en cache), d’autre part, les requêtes HTTP sont réparties entre deux hôtes (de manière certes inégale : plus de données d’un côté, plus de requêtes de l’autre).

De même, le flux Atom principal du site est maintenant réchauffé par FeedBurner, ce qui, au passage, me permet de collecter quelques statistiques.

Bien sûr, avant même de s’occuper de cela, la meilleure optimisation pour gagner un peu de bande passante passe d’abord par la prise en charge de la mise en cache (en-têtes HTTP Last-Modified, If-Modified-Since et Cache-Control) accompagnée d’une compression gzip du contenu textuel.

Une autre astuce que j’utilise, enfin, est l’incrustation d'images dans le CSS pour réduire le nombre de requêtes HTTP.

Tout cela combiné me permet de vous présenter le contenu de la page principale du blog en à peine plus de 50K (dont 10K sont pris par le script JavaScript de Google Analytics…) d’images et de texte compressé, ce qui, entre nous, est mieux que la plupart des blogs que j’ai pu voir ; ceux basés sur Wordpress^β tournent généralement autour de 200K.

Promotion, référencement

Le blog est maintenant en place, on peut y accéder, tout va bien, mais le plus dur reste à faire : le faire connaître. Honnêtement, avec la modeste fréquentation de mon blog, ce n’est probablement pas moi qui vais vous donner des leçons concernant le référencement. Si j’ai retenu une chose de mes lectures et de mes expérimentations, cependant, c’est certainement ceci : présenter du contenu correctement structuré par un HTML simple et sémantique, avec des URL courtes et sympas contenant quelques mots-clés, est agréable à naviguer, et plutôt bien récompensé par Google. Que demande le peuple ?

Ce qu’il demande, généralement, c’est des liens retour, les fameux liens retour… avoir des gens qui font référence à vos articles, si ce n’est pas là un symbole de réussite ! Hélas, il n’est pas aisé de stimuler l’enthousiasme au point que l’on veuille vous citer.

On peut bien sûr faire un peu de publicité par-ci, par-là, en insérant un lien discret dans ses profils, sur les forums, ou autres réseaux sociaux que l’on fréquente, mais les liens ainsi générés risquent d’être relativement médiocres (en revanche, c’est un bon moyen d’amener des visiteurs).

Ou on peut s’inscrire sur des annuaires… Option que j’ai envisagée à plusieurs reprises sans jamais vraiment me décider. J’ai mis longtemps avant de franchir le pas pour dmoz, et c’est pourtant le plus gros annuaire ! Il y a plusieurs raisons à cela. D’une part, la plupart des annuaires que j’ai pu voir (et j’en ai parcouru un rayon) ont un air très amateur. Parmi les rares qui sont visuellement acceptables, il y a souvent le problème du voisinage : certains annuaires ont trop de liens entassés les uns sur les autres sans hiérarchisation, d’autres souffrent de problèmes de modération, ou parfois, on se heurte tout simplement à des fluctuations de la qualité des liens au sein d’une même page ou d’une même catégorie, qui laissent dubitatif (vais-je me retrouver à côté de ce vilain site-là ? ou de celui, qui a l’air plus correct ?).

Conclusion

Voilà qui conclut ma brève non-série d’articles portant sur mon blog. Et après toutes ces semaines de développement Web, je suis impatient de reprendre une activité plus… normale. Il reste certes encore quelques bugs, mais il est grand temps pour moi de changer d’air…

Après deux semaines de développement (et une semaine de déploiement qu’il serait dommage d’oublier…), le nouveau blog est là. Pour les pauvres âmes égarées par erreur en ces lieux, permettez-moi de rappeler que ce blog, sur lequel vous êtes, est un produit entièrement artisanal, issu de nos belles campagnes, ahem, je me dissipe.

Mais si je vous écris aujourd’hui, ce n’est pas pour vous parler des nouvelles fonctionnalités trop cools du blog (vous pouvez bien voir par vous-mêmes, vous êtes assez grands), mais pour vous faire part de cette petite expérience, la mienne, dans le monde du développement Web. Au programme donc, aujourd’hui : comment écrire un blog, ou plutôt, comment j’ai écrit le mien. Original, n’est-t-il-pas ?^α :]

Avant de poursuivre, il faut replacer la démarche dans son contexte (wow, je croirais entendre mes profs). Mon blog est un petit blog, hébergé en grande partie sur mon PC de bureau reconverti en serveur malgré lui, tout ça derrière une Freebox. Il est clair, à partir de là, que les enjeux ne sont pas du tout comparables à un site moyen ou gros comptant les visiteurs par milliers.

Le fond

Dans le fond, un blog, c’est quoi ? C’est un tas d’articles, de commentaires (si le blog n’est pas trop perdu), et toute une taxinomie de ce vaste petit monde en tags, catégories, séries, ou tout autre mode de classification que l’on pourra imaginer.

Besoins très classiques et à la fois pas si évidents à modéliser correctement.

Bien sûr, le but, du moins le mien, n’est pas d’implémenter tous les outils de filtrage et de tri possibles et imaginables. J’ai toujours pensé, par exemple, que les tags et les catégories étaient redondants. Je ne doute pas que certains y trouvent leur compte, à séparer en tags et en catégories ; moi, honnêtement, avec mon modeste blog, je n’en vois pas l’intérêt. Il n’y a tout simplement pas suffisamment de contenu pour nécessiter autant de sophistication.^β

J’ai donc retenu les éléments suivants :

• des articles ;
• des commentaires ;
• des séries (collections d’articles, avec possibilité de lier deux articles d’une même série par des liens précédent / suivant) ;^γ
• et des tags (mots-clés décrivant un article).

Séries, articles, commentaires, et hiérarchie

Durant les dernières vacances (ou était-ce avant ?), j’ai eu une discussion intéressante sur #sdz, sur l’organisation des commentaires. Certains argumentaient que les commentaires hiérarchiques étaient plus clairs, tandis que je restais sceptique.

Mais si je vous parle de cela, c’est qu’un tel choix n’est pas sans conséquences sur l’implémentation. Si l’on opte pour une vue généralisée en arbres des commentaires, il vient naturellement que l’on pourrait faire de même pour les articles, et quitte à faire, ne maintenir qu’un seul arbre gigantesque comprenant toutes les séries, les articles, et les commentaires. Une telle stratégie suggère une représentation spécialisée des données, adaptée à la consultation d’arborescences, telle que la représentation intervallaire.

Pour mon blog, j’ai décidé de rester sur un modèle plus simple, avec une hiérarchie figée, à trois niveaux : séries, articles, commentaires. Se pose tout de même la question de faire une seule ou plusieurs tables ; j’ai décidé de n’en faire qu’une. Un article, une série, ou un commentaire est, dans ma base de données, un enregistrement dans la table entry. Il y a à cela plusieurs raisons, qui peuvent finalement toutes se résumer à un mot : homogénéité. J’aime pouvoir traiter les articles et les commentaires de manière similaire… car ils sont similaires ! L’interface est différente (voy. ci-dessous : Rédaction, mises à jour, et Atom), mais les données sont analogues : des auteurs, un contenu, une date, et quelques autres broutilles.

Mais la conception ne s’arrête pas là : on ne va guère loin avec juste des articles, des commentaires, et des séries… reste à les lier entre eux ! Et c’est là où les choses se gâtent quelque peu. Résumons les différents types de liens qui peuvent lier deux objets :

• un article peut appartenir à au plus une série ;
• un article peut avoir un prédécesseur et un successeur ;
• un commentaire appartient à un et un seul article.

En SQL, cela donne ceci :

CREATE TABLE entry (
        -- Un identifiant :
        e_eid INTEGER PRIMARY KEY,

        -- Des métadonnées :
        e_atomid TEXT UNIQUE NOT NULL,
        e_title TEXT NOT NULL,
        e_ctime INTEGER NOT NULL,
        e_mtime INTEGER NOT NULL,
        e_lang TEXT,

        -- Quelques liens :
        e_parent INTEGER,
        e_prev INTEGER,
        e_next INTEGER,

        -- Le contenu :
        e_content TEXT,

        -- D'autres métadonnées (relatives au site) :
        e_url TEXT UNIQUE,
        e_type CHAR(1) NOT NULL, -- Series | Article | Topic | Comment.
        e_from CHAR(1) NOT NULL, -- Primary | Secondary | Foreign.
        e_banned CHAR(1) NOT NULL, -- Auto-banned | Banned | -.
        e_level INTEGER NOT NULL,

        -- D'autres champs...
);

De plus, il est fréquent, quand on récupère les données d’un objet, d’avoir besoin de certaines informations connexes, telles que le nombre de commentaires d’un article, ou le titre de la série apparentée. Avec une base de données relationnelle, on a des jointures. C’est un joli concept, dirait bluestorm, mais une jointure pour la série parente, une pour l’article précédent, une autre pour l’article suivant, et encore une pour les commentaires associés, cela fait… beaucoup.

C’est là qu’intervient le cache. Enfin, un cache ; car il y a toute une flopée de façons de faire. On peut mettre en cache le résultat de certaines requêtes, ou carrément la sortie HTML produite par notre script. On peut stocker ça en mémoire (p.ex. en utilisant memcached), ou dans la base de données. Sans compter les mille et une manières de maintenir ce cache à jour.

Dans mon cas, il s’agit tout simplement d’une petite table,^δ dont les données sont extraites à partir d’une vue associée. C’est la méthode du pauvre pour matérialiser une vue, disons.

Et pour ceux qui aiment le code, voici :

-- La vue :
CREATE VIEW entry_cache_1 AS
SELECT
    self.e_eid AS ec_eid,
    parent.e_url AS ec_parent_url,
    parent.e_title AS ec_parent_title,
    parent.e_atomid AS ec_parent_atomid,
    parent.e_authors AS ec_parent_authors,
    parent.e_tags AS ec_parent_tags,
    thread.et_utime AS ec_parent_utime,
    prev.e_url AS ec_prev_url,
    prev.e_title AS ec_prev_title,
    prev.e_atomid AS ec_prev_atomid,
    next.e_url AS ec_next_url,
    next.e_title AS ec_next_title,
    next.e_atomid AS ec_next_atomid
FROM
    entry self LEFT JOIN
    entry parent ON self.e_parent = parent.e_eid LEFT JOIN
    entry_thread thread ON self.e_parent = thread.et_eid LEFT JOIN
    entry prev ON self.e_prev = prev.e_eid LEFT JOIN
    entry next ON self.e_next = next.e_eid;

-- La table :
CREATE TABLE entry_cache (
        ec_eid INTEGER PRIMARY KEY,
        ec_parent_url TEXT,
        ec_parent_title TEXT,
        ec_parent_atomid TEXT,
        ec_parent_authors TEXT,
        ec_parent_tags TEXT,
        ec_parent_utime INTEGER,
        ec_prev_url TEXT,
        ec_prev_title TEXT,
        ec_prev_atomid TEXT,
        ec_next_url TEXT,
        ec_next_title TEXT,
        ec_next_atomid TEXT
);

-- Et la requête pour remplir la seconde depuis la première :
REPLACE INTO entry_cache SELECT * FROM entry_cache_1
WHERE ec_eid = ?

En vérité, il manque sur cette démonstration certaines données capitales telles que le nombre de commentaires d’un article. Celles-ci sont en fait maintenues à part, dans une table entry_thread. Cette dernière est mise à jour par incréments, à chaque ajout d’un nouveau commentaire. Elle peut également être rafraîchie à partir d’une requête, à la manière d’entry_cache.^ε

Des approches plus complexes (principalement du fait de leurs possibilités de passage à l’échelle) peuvent se justifier pour des gros sites, mais compte tenu de mon hébergement quelque peu technologiquement précaire, pour parler comme Poulet, la ressource limitante est clairement la bande passante, et s’il est rigolo de jouer au petit jeu de l’optimisation un moment, on peut dire que j’aurais déjà perdu assez de temps comme cela. :)

Et les tags, dans tout ça ?

La question du stockage et de l’indexation des tags est l’autre gros problème d’implémentation. Le sujet est plutôt bien présenté, benchmarks à l’appui, dans cet article sur la représentation des tags dans une base de données ; je ne vais pas épiloguer sur les différentes manières de faire. Pour résumer, on a le choix entre stocker les tags d’un article de manière dénormalisée avec l’objet lui-même, ou utiliser des tables d’associations entre des objets articles et des objets tags, avec toutes les variantes possibles et imaginables.

L’ancienne version du blog utilisait la forme dénormalisée… essentiellement par flemme. Le problème qui s’est posé fut celui de faire des statistiques (p.ex. des nuages de tags) sur les tags. Cette approche est fondamentalement asymétrique et privilégie l’accès par articles au détriment de l’accès par tags.

On pourrait imaginer maintenir un index orthogonal, qui recense tous les articles associés à chaque tag. Avec des structures de données appropriées, l’intuition me dit que l’on devrait arriver à queque chose de pas mal. Je n’ai pas tellement étudié la question, mais il me semble logique que les mecs qui se branlent sur les bases de données non relationnelles, dans lesquelles la redondance est reine, soient enclins à opter pour ce genre de solutions. Quelqu’un au courant pour m’expliquer à quel point j’ai tort ?

Bref, pour revenir à des choses plus modestes, l’architecture actuelle du blog utilise également un modèle redondant : les tags sont stockés à la fois dans la table des articles, sous forme dénormalisée, et dans une table tag, à part, associée à entry par la table d’association tagmap :

CREATE TABLE entry (
        -- Champs précédemment décrits...

        -- Listes d'auteurs et de tags dénormalisées :
        e_authors TEXT,
        e_tags TEXT,

        -- D'autres champs...
);

CREATE TABLE tag (
        t_tid INTEGER PRIMARY KEY,
        t_name VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE tagmap (
        tm_eid INTEGER NOT NULL,
        tm_tid INTEGER NOT NULL,
        PRIMARY KEY (tm_eid, tm_tid)
);

Rédaction, mises à jour, et Atom

Le dernier point que j’aimerais aborder est une des particularités de mon blog. En effet, on n’écrit pas ses articles directement sur le site Web ! Mais ce n’est pas un blog entièrement statique non plus…

Mon blog est une espèce hybride qui se nourrit de fichiers Atom. En fait, quand bluestorm ou moi poste un billet, il l’ajoute à un fil Atom interne (grâce à un jeu d’outils en ligne de commandes développés en parallèle), et ping le blog pour lui demander de rafraîchir sa mémoire.

Cela peut paraître un peu compliqué pour pas grand chose, au premier abord, mais l’intérêt de cette méthode est qu’elle découple la rédaction et la présentation du contenu… Pas convaincus ? :p Accessoirement, la généralisation de cette approche permet d’importer du contenu d’autres blogs, le but étant au final d’obtenir une espèce de gros annuaire de billets intéressants affiliés à la micro-communauté #sdz.^ζ

Conclusion

Voilà qui conclut la première partie de cet article. Il me reste pas mal de choses à raconter ; des anecdotes plus légères, plus digestes sans doute pour certains, plus ennuyeuses pour d’autres. J’ai fini de parler de la machinerie derrière le blog. La prochaine fois, je parlerai de la partie directement visible : les questions d’interface, de présentation, de déploiement, tous ces petits ingrédients qui contribuent à créer des petites pages mignonnes et, je l’espère, agréables à lire, pour les visiteurs… sans oublier les robots, moteurs de recherches, et autres joyeusetés qui accompagnent immanquablement tout site Web dans sa vie, ou sa non-vie ! :]

In da blog

Les visiteurs réguliers l’auront remarqué, le blog vient de se doter de quelques petites fonctionnalités supplémentaires ! La première, et la plus visible, est le nouveau menu de navigation en haut de chaque page d’index (page principale ou de résultats d’une recherche par tags) : celui-ci offre un accès direct aux billets affichés sur la page ! Ça n’a pas l’air beaucoup, dit comme ça, mais c’est un moyen de plus d’aider les visiteurs (vous) à mieux naviguer sur le site, entre les blocs de vrai texte massif.

Remarquez également que le nombre de billets n’a pas doublé ; j’ai simplement réduit de moitié (ou presque) le nombre d’articles affichés par page d’index… Nos textes, ceux de bluestorm et les miens, sont généralement assez conséquents, et six épisodes par page semble être plus qu’il n’en faut pour satisfaire les plus voraces de nos lecteurs. Pour citer Cygal : « je veux dire qui lit index.html de haut en bas ? »

L’autre changement majeur, mais qui passera probablement inaperçu aux yeux de la majorité de nos visiteurs, est l’ajout (ou plutôt la finition) de la prise en charge des pages statiques par le moteur du blog. « Wow, mais à quoi cela sert-il ? » me demande-t-on. Bah, simplement, cela permet d’intégrer au blog du contenu statique… Il est plus logique que certaines pages se trouvent sur www.huoc.org plutôt que blog.huoc.org, mais leur centralisation sur le blog permet de recycler pleinement l’interface de ce dernier. J’en ai également profité pour déplacer et mettre à jour la liste de liens (en haut à droite), ainsi que les pages associées.

Autour du blog

La page sur #sdz et ses environs, en particulier, se voit apporter de nombreux ajouts et corrections. Citons l’arrivée de nouveaux sites dans la grande famille des projets morts-vivants issus de #sdz :

• le Wiki officiel de #sdz ;
• Buzzerl ;
• le blog de Cygal ;
• la page de Zopieux ;
• et le repaire d'iksaif.

Je tiens également à créditer un projet anonyme, dû à xarch et gnomnain, avec la participation bienveillante de Poulet, qui n’a pas souhaité être recensé car, dit-on, trop jeune.

Dans la catégorie des candidats non retenus, un monticule de pages par krankkatze qui n’a pas réussi à changer de nom de domaine à temps, et des blogs et idées diverses qui n’ont jamais vu le jour, comme #sdz en connait toujours beaucoup.

Enfin, la palme de l’improductivité de ces derniers mois revient cette fois-ci à IUWT, car notons que même la World Company a connu un semblant d’activité en ce début d’année 2010 !

Le blog

Je me suis toujours dit que je ferais un billet compilant les statistiques du blog, un peu comme le « Six mois après, où ça en est » de BHM.

Quand j’ai le temps, et que je déprime un peu, que la vie, elle n’est pas trop cool, et que je n’ai pas envie de faire des choses sérieuses, je m’occupe du blog. En plus, c’est motivant parce que je ne suis pas tout seul sur ce blog, il y a aussi blueblue.

Bref, et quand je m’occupe du blog, je commence toujours par disséquer un peu les logs et les stats. Il y a plein d’analyses rigolotes à mener ; il y a des mecs qui peuvent se toucher des heures sur des questions d’optimisation du trafic, et plus généralement de SEO. Mais soyons réalistes : avec une cinquantaine de visiteurs par jour, ce ptit blog n’a guère à se soucier de cela.

Quelques chiffres intéressants toutefois :

• D’après Webalizer, environ 120 IP uniques atteignent le serveur chaque jour. Parmi celles-ci, la moitié appartient à des agrégateurs de flux. Si ces derniers apportent avec eux une inflation certaine du nombre de visites, les adresses, elles, ne devraient pas, normalement, connaître plus de variations qu’avec des visiteurs normaux.

• Au mois d’octobre dernier, le nombre d’IP uniques provenant d’agrégateurs s’approchait davantage de 20. Il y a eu, dans tous les cas, une progression évidente de ce côté-là.

• En revanche, le nombre de visiteurs s’est plus ou moins stabilisé durant la même période. Nous échangeons des lecteurs Web contre des lecteurs Atom ! Cela s’explique sans doute par ma présence (et celle de bluestorm) moindre sur le Site du Zéro depuis quelques mois.

• StatCounter (comptage basé sur les cookies, cette fois-ci) donne une cinquantaine de visiteurs uniques par jour, et ne prend pas en compte les fichiers Atom. Cela rejoint plus ou moins les observations précédentes.

• Enfin, un petit mot sur les visiteurs eux-mêmes (chiffres approximatifs calculés sur la base du nombre de requêtes effectuées). Les linuxiens constituent une petite moitié du trafic (45%). Viennent en second les windowsiens, qui représentent un quart de notre lectorat virtuel. Les BSD arrivent en troisième position avec 5%, et enfin les macqueux ferment la marche avec 3%. Le reste provient de systèmes divers ou non identifiés.

Voilà, voilà ! Je voulais faire une autre section encore, mais ça attendra un prochain billet !

Et non, le blog n’est pas mort, ahem, enfin. bluestorm et moi sommes juste très occupés. Mais, au détour d’une discussion IRC, il m’a convaincu de dire deux mots sur le nouveau machin de Google (Go). Je peux en profiter pour dire deux mots sur le pas-si-nouveau-que-ça machin d’OS X (GCD). Et oui, que voulez-vous, on n’est pas vraiment in sync with da hype.

Honnêtement, je n’ai pas grand chose à dire, là-dessus. Globalement, comme presque toujours, je suis sceptique (not impressed), surtout pour Go. Pour citer bluestorm, « la syntaxe ne casse pas de briques ». En fait, je ne vois pas l’intérêt de la nouvelle syntaxe ; la rationale est franchement faiblarde et l’intérêt que je vois à maintenir une certaine compatibilité avec les autres descendants syntaxiques du C (Java, C#, etc.) aurait largement justifié de ne pas dévier à ce point. Mais pourquoi s’attarder sur la syntaxe, après tout… bah parce que du reste, je ne suis pas franchement convaincu par la nouveauté de ce langage, qui n’est pas sans rappeler, à mon avis, Alef, pour le côté « on rajoute des machins au C pour gérer la concurrence et quelques types de données pratiques ». Bref, à mon avis, les vieux gurus risquent un peu trop leur peau, du moins leur réputation, en jouant à ce jeu-là.

Le machin d’Apple est sans doute plus rigolo, et ça a l’avantage d’être déployé, et blah et blah. Je n’ai rien contre le principe : on a vraiment besoin d’outils pratiques pour faire de la concurrence en C… par contre je conchie ((c) conno) la syntaxe des blocs de clang. Je trouve que ça ne ressemble pas à du C, et que l’on aurait pu utiliser une syntaxe dérivée des littéraux composés du C99 (quelque chose comme (T (args)){ ... }), quitte à ajouter un qualificateur particulier (fat ? :p) pour les pointeurs de blocs (après tout, ils le font déjà pour les variables lexicalement accessibles de manière imbriquée). Pourquoi ? Parce qu’avec une syntaxe comme celle qui est actuellement implantée, aussi distante du C classique, je vois mal comment on pourrait voir ce genre de fonctionnalités devenir ne serait-ce que vaguement standard un jour ! J’ai toujours voulu avoir des fermetures lexicales en C… et je pense que les idées sous-jacentes ne sont pas dégueulasses, mais je prie pour que cette syntaxe-là ne devienne jamais quelque chose que l’on pourrait appeler, en toute bonne foi, du C.

…et pendant ce temps-là, au p^W^W blue, lui, se touche plutôt sur ATS. Ne m’en demandez pas trop, je n’ai pas vraiment eu le temps de regarder en détail, mais à vue, c’est hum, un nouveau langage avec une syntaxe fonctionnelle et une théorie sous-jacente probablement trop-bien-et-tout-aussi-compliquée.

Voilà, voilà, à bientôt, pour de nouvelles aventures !

Billet non technique ! Bon, alors pendant qu’on se touchait sur un tas de trucs techniques, et avant que j’aille bosser sur xmlsed à nouveau, il fallait que j’écrive ce magnifique billet pour vous parler de tout et de rien (et donner l’illusion que malgré la fin des vacances, on a encore du contenu).

Tout d’abord, lumières sur : ce qui n’a pas été fait chez nous !

• Bon, c’est un peu du réchauffé, mais d’un côté, on a une réaction d'asmanur sur son blog. Ça parle de P2P, de sécurité… et bien sûr, on sent l’ombre d’un nouveau projet avorté ! À suivre donc (jusqu’à avortement).

• Dans un tout autre registre, conno nous a sorti la version râpée d’Agruman, à découvrir sans plus attendre : WC, miroir.^α

  α : Bon, le miroir, c’est le serveur du blog, donc faut éviter, si possible. :-’

Voilà, voilà, et maintenant, recadrage sur le blog : bah, le blog, blah blah, ça fait trois mois, blah blah. Du coup, je vous offre cette magnifique auto-interview de moi-même (spéciale dédicace à qui se reconnaîtrait si elle lisait mon blog) :^β

Salut Nhat Minh, a/k/a rz0, a/k/a len[h], a/k/a Ours.

Tak tak.

Alors, comme ça, ça fait trois mois ? Ton petit projet de blog est devenu grand ?

Et non, c’est encore le trou du cul du monde, ici. On fait pitié, personne ne nous lit, et ça ne va pas s’arranger, avec la rentrée. Mais comme dit l’autre, l’important c’est d’en être fier !

J’ai vu que Google était responsable de 0.75% de tes hits, c’est pas mal, non ?

Ah ouais, ouais, on est vachement bien placé sur tout ce qui concerne les hippies : les polices, les fonds d’écran, les cœurs, et autres techniques osées. Mais c’est grâce à bluestorm tout ça, merci à lui.

D’ailleurs, paraît que ça sent l’herbe de partout, maintenant, chez toi, avec tous ces fort longs trips…

Bah, bluestorm is in da place.

Et niveau features trokools ?

Bah, on a des commentaires, enfin, depuis quelques temps. Mais aussi le mode discussion troklass, qui accompagne superbement le formulaire de commentaire que la moitié des gens n’arrive pas à utiliser correctement. Tout ça bien sûr, comme toujours, subtilement relevé par un design trobien comme je sais les faire.

Un dernier mot ?

Tkt.

J’écris ce billet pour me plaindre : les lecteurs (de ce blog ou d’ailleurs) ne postent pas assez de commentaires. J’expliquerai ici que nous avons besoin de vos commentaires, je débusquerai les mauvaises raisons qui poussent les lecteurs à rester silencieux, et donnerais quelques idées pour l’écriture de commentaires qui feront le bonheur de vos vieux jours.

Mise à jour (30 août 2009) En conséquence d’une suggestion de Cygal, j’ai ajouté un passage sur les canaux privés. J’en profite pour vous signaler une fonctionnalité intéressante que rz0 a mise en place pour suivre plus facilement les dicussions qui se déroulent en commentaires : le mode discussion, auquel on accède par la petite icône tout en haut de la page.^α

Les exemples sont nombreux et désolants ; deux jour après sa publication (donc après que la plupart des habitués l’aient lu), la réaction de Cygal est toujours sans commentaires. L’article sur les conventions de rz0 est lui aussi resté dans le vide. Certains de mes billets ont eu plus de chance, mais j’ai souvent dû aller chercher certains lecteurs et leur mettre le couteau sous la gorge pour qu’ils acceptent de revenir mettre un commentaire.

Cette situation est très désagréable pour un auteur de billet. L’écriture demande un effort considérable, et ne pas avoir de commentaire ça donne exactement l’impression qu’on parle dans le vide. Parler dans le vide, ça va la première fois, mais on se lasse rapidement. Pour garder la motivation, il faut des commentaires.

On écrit sur un blog, jette ton clavier dans les airs,
Fais du bruit si t’as envie d’avoir des commentaires

Je suis donc forcé d’utiliser les grands mots : vous, les lecteurs, vous devez écrire des commentaires. Voilà, c’est votre devoir, c’est dit, je suis esclavagiste. Alors bien sûr, vous lisez ce blog, anonyme, sans obligation aucune, et rien ne vous y contraint. Mais c’est une situation perdant-perdant : ce petit effort que nous vous demandons est indispensable pour maintenir la motivation des auteurs. Si vous continuez à refuser, par choix ou par ignorance, de le faire, notre productivité bon enfant s’essouflera rapidement, et vous aurez de moins en moins de billets à lire sans obligation aucune. Si vous ne nous donnez pas plus de commentaires, vous serez privés de nos formidables billets, et en serez inconsolables.

Mauvaises raisons de ne pas commenter

Je n’ai rien à dire :-’(

Vous vous trompez certainement. Vous pouvez dire quelque chose d’intéressant, et la prochaine section libérera le féroce commentateur qui sommeille en vous.

Dire juste « j’ai bien aimé », ça fait nul.

Vous avez encore les yeux écarquillés car vous venez de lire un billet qui a révolutionné votre vision du monde, et vous êtes peut-être habitué à ce que chaque phrase contienne des perles de savoir unique en leur genre, no less. Mettre un simple "merci" derrière, ça paraît idiot.

Mais non ! Un simple merci, un petit encouragement est agréable pour un auteur, et ça peut être ce qui fait la différence entre un coup de déprime suite à un silence d’encre, et l’envie de rédiger de suite un nouveau billet.

Bon, si un jour on se retrouve avec une centaine de "trop cool !" derrière chaque billet, et que cela empêche de remarquer les questions cachées dans certains des commentaires, auxquelles nous nous devons de répondre, hein, ce sera peut-être un peu différent, mais nous en sommes assez loin.

Je n’ai pas les compétences techniques pour commenter.

Certains billets ont un contenu technique. Ça ne veut pas dire que le droit de commenter est réservé aux gens qui baignent dans le domaine depuis des années. Si vous avez réussi à lire un billet qui n’est pas dans votre domaine, votre avis nous intéresse tout particulièrement, parce que justement vous avez un point de vue extérieur. Est-ce que ça vous a apporté quelque chose ? Est-ce qu’il y a quelque chose à changer, pour que ce soit plus accessible aux non-spécialistes la prochaine fois ?

J’ai eu des difficultés à comprendre une partie du billet, je n’ose pas commenter.

Parfois, vous avez les compétences pour entrer pleinement dans les détails du sujet abordé, mais vous avez buté sur certains points du billet, et avez donc perdu toute confiance en votre légitimité à commenter : « Et si la question que j’ai en tête était en fait déjà traitée par une partie de l’article que je n’ai pas comprise ? Je vais passer pour un(e) idiot(e) ! »

Justement, si vous avez buté sur un point du billet, il faut faire un commentaire à ce sujet. C’est sans doute que le billet est à clarifier, que cette partie était mal ou pas assez expliquée, et on a besoin de vos retours pour repérer les points à retravailler. Et oui, nous pouvons modifier nos billets après leur parution pour y mettre en place des améliorations suggérés par les lecteurs, donc n’hésitez pas, vous rendrez aussi service aux lecteurs suivants.

Je n’ai pas aimé le billet.

C’est votre droit, et ce n’est pas une raison pour ne pas commenter. Au contraire, les retours négatifs sont même parfois les plus intéressants pour un auteur. Essayez de faire un effort pour formuler les principaux défauts du billet, avec tact si possible : ça nous aide à accepter la critique.

Je vais plutôt envoyer un mail à l’auteur ou le contacter par messagerie instantanée, c’est moins intimidant

Certains lecteurs ont la possibilité de faire leurs commentaires directement à l’auteur (mail, IRC…) ; en particulier, c’est quasiment toujours le cas quand rz0 relit mes propres billets : j’ai son avis avant la parution, et il ne poste pas de commentaire pour répéter ses remarques.

C’est cependant une pratique déconseillée. Une page de blog, ce n’est pas juste un billet suivi éventuellement de quelques remerciements : les commentaires font partie du document dans son ensemble, et ils sont parfois au moins aussi intéressants, et importants pour les lecteurs, que le billet original.| Dans cette optique, il est intéressant de regrouper ces commentaires sur la page du billet, qui est un lieu durable (pas sur IRC dont les conversations tombent dans l’oubli) et public (pas dans un mail privé, sauf cas exceptionnel).

Si l’aspect public vous intimide, dites vous que c’est pareil pour tout le monde : on ne vous reprochera pas une éventuelle erreur, et il vaut mieux qu’elle soit corrigée pendant la discussion plutôt que vous la gardiez pour vous. De toute façon, vu le nombre de messages de vous qui traînent sûrement déjà sur internet, ce ne sont pas une question mal posée ou une fausse faute d’orthographe qui vont vous couvrir de honte…

Comment écrire un bon commentaire

Écrire un commentaire satisfaisant pour l’auteur n’est pas très difficile, il suffit de se poser quelques questions :

• Est-ce que le billet m’a plu ? Pourquoi ?

• Est-ce que je vois un point qui pourrait être amélioré ?

• Est-ce qu’il y a une question que je pourrais poser à l’auteur ?

Le mot d’ordre : fais pas ta fiote (rz0-hijacked! en langage genthippy ça donne « ne soyez pas timide »). On ne va pas vous reprocher un commentaire, et il vaut mieux écrire quelque chose dont on se dit ensuite « j’aurais pu faire mieux » que ne rien écrire du tout.

Faites le, ça nous rendra vraiment service.