Sonnez hautbois, résonnez musettes ! Il est arrivé le moteur de blog nouveau ! Chantons tous son avènement !
Ça fait un an et demi que j'y pensais, que je bassinais mes lecteurs régulièrement avec ça, que j'y travaillais très très épisodiquement (après avoir mis du temps à faire les choix techniques), mais voilà, enfin, les choses sont en place et j'ai une première version un peu coupante sur les bords mais réellement fonctionnelle : ce blog[#] n'est plus généré par un programme en C de 3000 lignes mal écrit, buggué et impossible à maintenir, mais par… un programme en Java de 3000 lignes que j'espère légèrement moins mal écrit, légèrement moins buggué et légèrement moins impossible à maintenir.
Vous ne voyez pas la différence ? C'est normal. C'est voulu,
même : à part de timides petits changements dans l'en-tête et le
pied-de-page des différentes parties de ce blog, j'ai visé à tout
garder identique. Le principal changement qui devrait être visible
pour ceux qui utilisent
le flux RSS, c'est le
truc qu'on me réclamait régulièrement, à savoir une date et
heure sur les entrées, et le (début du) contenu des entrées
elles-mêmes dans le flux (chose qu'il aurait été quasiment impossible
de faire avec l'ancien moteur sans s'arracher les cheveux). Sinon, la
plupart des changements ont lieu de mon côté : mon blog n'est plus
tapé comme un fichier unique de 6.6Mo (and
counting) mais comme un petit fichier par mois (ça va
rendre git plus heureux, même si en contrepartie c'est
moins commode pour rechercher dedans), et quand je recompile il y a
plein de magie noire mêlant du PostgreSQL, du Perl et du
Java pour ne regénérer que les bouts vraiment modifiés. J'ai aussi dû
me battre avec plusieurs misfeatures de XML ou des
parseurs XML[#2].
Ceci étant, le but n'était pas tellement de changer des choses, même pour moi, mais de me donner les moyens de pouvoir les changer : autrement dit, de quitter une situation où je ne peux rien faire évoluer parce que le programme est tellement horrible que je refuse d'y toucher. Et pour ça, je crois avoir effectivement gagné.
[#] Ce blog, et avec lui une bonne partie des pages Web de ce site, celles qui ont vaguement le même look.
[#2] En voici une qui
m'a causé pas mal d'arrachage de cheveux : si vous considérez le
fichier XML
suivant : <?xml version="1.0"?> <pouet>&pouet;</pouet>,
il n'est pas bien-formé, parce que l'entité &pouet;
est référencée sans être définie ; en revanche, si je rajoute
n'importe quelle référence à un document externe,
disons <?xml version="1.0"?> <!DOCTYPE pouet
[<!ENTITY % nothing SYSTEM "/dev/null">
%nothing;]> <pouet>&pouet;</pouet>, alors magiquement le
document devient bien-formé. La logique, assez compréhensible, est
que le caractère bien-formé ou non d'un document XML doit
pouvoir se décider sans consulter la moindre ressource externe, donc
dès qu'on ne peut plus être sûr sans en consulter que l'entité n'a pas
été définie, ce ne peut plus être une contrainte
de bien-formitude bonne forme. (C'est cependant toujours
une contrainte de validité.) Mais ce qui m'agace c'est que, du coup,
les parseurs XML ne signalent pas d'erreur et qu'il
n'y a apparemment pas de moyen de les forcer à en produire une
(j'ai vraiment envie
que Xerces me
signale si j'utilise une entité non définie parce que j'ai fait une
faute de frappe, et pas qu'il la remplace par la chaîne vide !). La
seule façon de faire semble être de demander au parseur de valider, et
d'ignorer la floppée d'erreurs qu'il va pondre sauf celle-ci : c'est
vraiment absurde. (Et je ne vous parle pas du fait que Xerces a douze
interfaces différentes avec douze façons différentes d'enregistrer un
gestionnaire d'erreurs, et que trouver comment lui faire avaler
un org.apache.xerces.xni.parser.XMLErrorHandler et pas
un org.xml.sax.ErrorHandler parce qu'on veut éviter
d'avoir à parser le message d'erreur, c'est pas évident.)