Comments on Je voudrais changer le moteur de ce blog

SB (2012-11-06T18:26:08Z)

C'est dommage que le lien vers chaque commentaire ne figure pas dans chaque commentaire (par exemple derrière la date et l'heure du commentaire, comme cela se fait sur pas mal de blogs): un nouveau venu qui ne connaît pas, par exemple, la page des commentaires récents, ne pourra pas donner le lien d'un commentaire particulier.

Ruxor (2011-09-20T19:44:12Z)

SB → Je vais répondre exactement ce que j'ai répondu ailleurs sur le même sujet : Quel est l'inconvénient de simplement utiliser le bouton « back » du navigateur ? Ça a l'avantage de remettre l'emplacement exactement où il était. Personnellement, c'est ce que je fais, quand je vais lire les notes sur Wikipédia (je n'utilise le lien arrière que si je suis tombé sur la note par hasard et je cherche d'où elle vient ; mais sur mon blog, comme les notes sont référencées par des trucs comme #42, il suffit de chercher #42 sur la page, ou en fait de chercher le caractère '#' dont je ne me sers quasiment jamais autrement).

SB (2011-09-20T18:37:58Z)

Est-ce qu'il quelque chose qui échappe à mon navigateur, ou est-ce qu'il est normal qu'on ne puisse pas, à partir d'une note de bas de billet, remonter automatiquement à l'appel de cette note ? Cette phrase: "les notes en bas d'entrée, elles ne sont pas formatées automatiquement comme elles devraient l'être" concerne-t-elle entre autres ce problème ?

Hélène (2010-03-24T19:08:57Z)

Le changement de moteur de ce blog sera peut-être aussi l'occasion de changer le système de numérotation des billets, actuellement sur 4 chiffres (1741 pour ce billet) : en effet, en 7 ans, près de 1800 billets ont été publiés ; à ce rythme, le billet 9999 sera publié en 2047 (=23*89) ou 2048 (=2^11). Peut-être ne pensais-tu pas être aussi prolifique au début du blog et tenir aussi longtemps.

Ruxor (2010-03-16T00:04:36Z)

Hélène → Bravo pour le sens de l'observation. :-) La raison de la disparition de cette ligne, c'est que j'ai migré de CVS à Git pour le contrôle de version de mon site Web, ce qui est effectivement lié à (mais pas directement une conséquence de) mon intention de refaire le moteur de blog (chose qui n'est pas encore faite).

Hélène (2010-03-15T21:04:13Z)

Cette histoire de changement du moteur de ce blog a-t-elle un rapport avec la disparition de $Id: index.daml.fr,v 1.24 2010-01-28 17:30:30 david Exp $ au bas de cette page, par exemple : <URL: http://www.madore.org/~david/ > ?

Militons pour le retour de ce si joli pied de page !

Ruxor (2010-03-13T00:16:50Z)

Couard Anonyme → J'avais bien compris que tu parlais de Cduce. Je n'aime pas trop les langages trop spécialisés (il vaut mieux une bibliothèque spécialisée dans un langage relativement généraliste), et je n'aime pas trop les langages ultra-marginaux (trop de risque qu'ils ne soient pas correctement maintenus lorsque, par exemple, un développeur-clé part faire de la finance).

Couard Anonyme (2010-03-12T23:01:57Z)

L'allusion etant bien entendu a Cduce d'Alain Frsch desormais parti dans la finance.

xavier (2010-03-10T10:32:40Z)

Quand on y pense… on parle d'ajouter des bouts de texte/code html entre deux balises.
Il n'y a presque rien à parser si ce n'est le titre et la date de l'entrée et peut être une ou deux autres clefs d'archivage.

Si on suppose que le squelette html/css existe, ca devrait tenir en qlqs page de code (en étant large).

Geo (2010-03-10T01:21:32Z)

CVS devient vite une habitude, même pour des projets à un seul utilisateur. Pour peu que le serveur soit backupé, on s'évite beaucoup de tracas pour un coup vraiment minimal (svn commit quand on finit de bosser…). Ce n'est pas QUE pour les control freaks et les bidouilleurs fous comme Ruxor. Désolé pour le HS…

ushu (2010-03-09T23:00:56Z)

Python 3 avec ElementTree permet de manipuler du XML très facilement, et supporte nativement Unicode.
Je ne connais pas la façon dont Perl gère l'Unicode, l'approche de Python dans ce cas est de casser la compatibilité entre les versions 2 et 3…

sinon tu es la première personne que j'entends dire préférer écrire du XML plutôt que du Markdown.

Ruxor (2010-03-09T10:19:51Z)

bubbatls → « En l'état actuel du programme, le modifier pour produire plusieurs fichiers en sortie par un seul appel serait d'une difficulté inextricable. » Entre autres parce que le programme ne se soucie pas de (ne pas) polluer son espace mémoire (ni de (ne pas) détruire l'arbre source), donc quand il a fini de tourner une fois il n'y a plus grand-chose à en faire sinon quitter. Aussi parce que le même programme génère à la fois les pages du blog et toutes les autres pages du site : il serait très déplaisant d'ajouter une boucle ad hoc juste dans le cas d'un fichier particulier. Tout ça, ce sont des mauvaises excuses, bien sûr : ça veut surtout juste dire que le programme est très mal écrit (et c'est bien pour ça que je veux le refaire).

bubbatls (2010-03-09T08:37:10Z)

Pourquoi ne pas modifier le programme pour n'avoir à l'appeller qu'une fois et pas 86? Ainsi le fichier xml ne serait parsé qu'une fois.
Bien sur ce serait s'oter "le plaisir" de changer de technologie

Ruxor (2010-03-09T03:20:32Z)

xavier → Les arguments « moi je fais autrement (ou : on peut faire autrement), donc tel truc ne sert à rien », ils ne prouvent vraiment rien. Évidemment qu'une façon d'éviter les soucis dans l'édition d'un fichier sur plusieurs machines est de ne l'éditer que sur une machine : on perd aussi les bénéfices d'avoir un éditeur en local (par exemple, quand il est un chouïa graphique, ça va plus vite…), ou on perd simplement celui de travailler sur une machine qui n'a momentanément pas d'accès Internet. Évidemment que quand le directeur de thèse fait référence à la phrase <machin truc>, c'est mieux que quand il dit « dans la proposition 1.3.8, êtes-vous sûr de vos hypothèses ? » ; évidemment qu'on peut garder un PDF de chaque version de chaque chose qu'on lui envoie, et on risque plus facilement de se retrouver avec des mailboxes qui dépassent un quota idiot (ou avec des sauvegardes plus grosses à faire soi-même) que si on note juste un identifiant CVS ou Git. Évidemment qu'on peut faire (et d'ailleurs, qu'il est très conseillé de faire) des backups incrémentaux, mais on peut aussi trouver ça nettement moins commode pour remonter rapidement dans le temps et comparer des versions (bissecter, par exemple) qu'un système qui a été exprès prévu pour. Évidemment qu'on peut toujours mettre les données « ailleurs » (les systèmes de contrôle de version ne font pas de magie : tout ce qu'ils font peut *toujours* être fait autrement), mais on peut aussi trouver que c'est déplaisant comme organisation.

Bref, il faudrait arrêter de penser qu'il n'y a qu'une seule façon de se servir d'un ordinateur, et réagir par « wtf? » dès que quelqu'un trouve qu'une autre façon est plus simple ou plus commode. There's more than one way to do it: quand tout est question de confort, il faut juste admettre que les gens ont des notions de confort différentes. (Et si quelqu'un a choisi de mettre sa thèse sous un système de contrôle de versions, c'est peut-être qu'il avait des raisons, et qu'il est le mieux placé pour les connaître.)

Sur ce, on va arrêter cet échange, qui s'écarte furieusement du sujet.

xavier (2010-03-08T22:47:42Z)

"j'évitais toute inquiétude du style « est-ce que je suis bien en train de modifier la dernière version" : ne l'avoir que sur une machine et ssh suffit.

"Quand mon directeur de thèse me faisait un commentaire, je retrouvais sans problème les passages auxquels il faisait référence malgré les éventuelles renumérotations survenues entre temps" : Moi aussi. grep ou ctrl+s sous emacs.

"je décidais de changer complètement une démonstration, je n'avais pas à m'inquiéter de perdre l'ancienne version."
bakcup incrémental de /home tous les jours.

"notamment dans les cas où je commence une entrée et où la rédaction de celle-ci s'éternise mais que je veux quand même faire des modifications sur des entrées passées"
ben tu écris l'entrée dans un coin et tu la rentre dans le système quand elle est prête. Quel est le problème avec ça? trop simple/pas fun (c'est une raison valable (je ne rigole pas))

Je sais me servir de SVN mais je pense que son seul intéret était contenu dans le nom même de CVS: "Concurrent versions".
Ca n'est vraiment utile que quand on a plusieurs personnes qui travaille sur le même tas de fichiers…et encore, ça n'a rien de très fin…ça crie seulement quand il y a un conflit lors d'un commit. Ca ne remplace pas la discipline nécéssaire pour travailler à plusieurs sur un même code.

On ne peut même pas dire que ça fait un backup à peu de frais car il faut backuper le serveur si on ne veut pas perdre l'historique en cas de pb.

la coloration syntaxique? sans ça je ne regarde même pas ce qu'un éditeur sait faire d'autre. Depuis en gros 2ans, j'exige aussi la complétion quand je code. La complétion de tout en fonction de contexte. Ca a toujours existé sur les mauvais éditeurs de visual studio XXX. En libre, ça a eu un peu de mal à s'imposer (et ça en a toujours) car les geek disent "wtf".

Ruxor (2010-03-08T22:19:13Z)

xavier → Mettre ma thèse sous CVS m'a été *très* utile ! J'en avais des copies sur plein de machines différentes (une chez moi, une au bureau, une chez mes parents, une sur mon portable…), grâce à CVS j'évitais toute inquiétude du style « est-ce que je suis bien en train de modifier la dernière version ? ». Quand mon directeur de thèse me faisait un commentaire, je retrouvais sans problème les passages auxquels il faisait référence malgré les éventuelles renumérotations survenues entre temps. Et quand je décidais de changer complètement une démonstration, je n'avais pas à m'inquiéter de perdre l'ancienne version.

Pour un blog, c'est moins utile, mais ça l'est quand même : notamment dans les cas où je commence une entrée et où la rédaction de celle-ci s'éternise mais que je veux quand même faire des modifications sur des entrées passées (typiquement, des fautes d'orthographe qu'on me signale). Mais c'est surtout que je veux tenir l'ensemble du site sous un même contrôle de version, et si pour le blog ce n'est pas furieusement utile, pour le reste ça l'est.

Je pense que tu ne dois pas savoir assez bien te servir de ce genre d'outils pour en apprécier l'utilité. (C'est un peu comme la coloration syntaxique des éditeurs : la première fois que j'ai vu ça, je me suis dit : « wtf ? j'ai programmé très bien sans ça jusque là ! » — maintenant je ne pourrais plus m'en passer.)

xavier (2010-03-08T21:03:43Z)

yogsototh : Mettre ses sources sous git/whatever quand on est seul devel est une pure perte de temps. C'est une geekerie pure.
On se rend même vite compte que, dans ce cas, c'est moins souple qu'est bête backup incrémental.
Je vu je ne sais combien de personne mettre leur rep latex de thèse sous config control. wtf? J'ai appris qu'ils l'ont fait car ils demandaient comment faire en cas de merdouillage dans un comit ou whatever.
J'ai toujours répondu la même chose : Rien. Ne fais rien.

Ruxor (2010-03-08T20:10:30Z)

Je sais que Ruby 1.9 a un meilleur support Unicode que Ruby 1.8 (notamment, les regexps peuvent maintenant matcher des chaînes Unicode). Le temps qu'il passe dans Debian stable, ça risque de faire encore long, cependant. Par ailleurs, même dans Ruby 1.9, il me semble comprendre que c'est loin d'être parfait. Par parfait je veux dire que toutes, absolument toutes, les fonctions du langage qui manipulent des chaînes de caractères, manipulent des chaînes de caractères Unicode (et pas juste du UTF-16 comme Java, soit dit en passant) comme elles peuvent manipuler des chaînes d'octets ; et que toutes les bibliothèques qui en dépendent soient aussi mises à jour (par exemple, une bibliothèque de traitement XML devra être pas mal remaniée pour accepter et renvoyer des chaînes Unicode au lieu ou en plus d'accepter et renvoyer des chaînes d'octets les représentant). Faire tout ça sans casser la compatibilité ascendante est subtil, mais Perl a trouvé moyen de s'en sortir, et je ne comprends pas pourquoi tous les autres langages de script n'ont pas adopté exactement la même politique. Je crois comprendre que Ruby en est encore loin : je peux me tromper puisque je n'y connais quasiment rien, mais j'attendrai qu'on me confirme que tout est géré de façon absolument parfaite avant d'aborder ce langage.

yogsototh (2010-03-08T18:20:03Z)

@xavier : Mettre son blog sous controlle de version apporte déjà les backups. Mais aussi la possibilité avec git nottament de développer une nouvelle fonctionnalité dans un "bac à sable" tout en ayant la possibilité de continuer à blogger.

@ruxor, je n'ai pas un avis si tranché que cela en ce qui concerne Perl. Je l'utilise relativement souvent. Mais on peut quand même dire que Ruby est un Perl nouvelle génération. C'est le Perl avec la facilité de lecture du Python. De plus il me semble (mais je ne suis pas sûr) que depuis la version 1.9 Ruby supporte l'unicode (je suis tombé là dessus par exemple : http://yokolet.blogspot.com/2008/09/ruby-19s-unicode-regular-expression.html ).

@raph, j'irai certainement jeter un coup d'oeil à nanoblogger pour ma culture personnelle, ça me semble intéressant.

xavier (2010-03-08T16:07:08Z)

Je pense qu'on peut torcher le problème en un nombre relativement petit de lignes très lisibles de python.
Si on parle d'un truc qui lit une entrée tapée en xml (ou un truc proche de ca) et l'ajoute à une page statique alors c'est vraiment simple en python.

On peut bien sûr faire de même en Perl mais je déteste lire du Perl car sa syntaxe date des années où le moindre caractère coûtait cher.

Le faire en C est…je n'ose le dire…dans un langage qui ne sait rien faire ou presque sur les chaines…

Mettre un blog sous contrôle de version est une idée…étrange. Ca apporte quoi???

Ruxor (2010-03-08T15:44:21Z)

Vicnent → J'ai peut-être éliminé des programmes trop rapidement (ne connaissant rien à Wordpress, Dotclear, Joomla et autres, il est difficile de trouver dans leur doc la description exacte de leur fonctionnement technique en écartant tous les trucs publicitaires expliquant que c'est facile à utiliser), mais il me semble qu'il n'existe pas d'outil de gestion de contenu qui réponde aux critères suivants :

* Générer des pages statiques et pas dynamiques.
* Ne pas faire appel à PHP ni MySQL sur le serveur (probablement redondant avec la contrainte précédente, mais bon, c'est pour dire qu'il y a deux raisons différentes qui me font arriver plus ou moins à la même chose).
* Me permettre de taper mon contenu dans un fichier texte (et pas, par exemple, des widgets Web)…
* …dont la version maîtresse pourrait commodément être sous un contrôle de version (CVS ou Git, notamment)…
* …et qui soit au format XML (j'aime bien taper du XML, je déteste les trucs à la Markdown, markup wiki, ou dans une moindre mesure Haml ; et de toute façon, toutes mes archives sont en XML, je n'ai pas envie de les convertir en autre chose).

Sinon (pour répondre à d'autres remarques), pour les langages de programmation (je suis étonné de voir à quel point les gens ont des opinions très tranchées sur cette question), je me suis promis de me pencher sérieusement sur Ruby, qui m'a effectivement l'air très prometteur, dès qu'il aurait une gestion parfaite des chaînes de caractères en Unicode (ce qui est le cas de Perl depuis la version 5.8). Les principaux problèmes que je vois avec Perl, ce n'est pas son illisibilité, c'est le fait qu'on ne puisse pas précompiler un programme, et c'est le fait que le langage est assez moribond depuis qu'on promet Perl 6 pour dans +∞ années.

raph (2010-03-08T12:51:04Z)

Comme moteur de blog générant du html statique, il y a aussi nanoblogger (http://nanoblogger.sourceforge.net). Il repose sur "bash, vim, cat, grep, sed", supporte les tags/catégories, différents plugins peuvent être écrits (il en existe déjà pour des galleries photo", les commentaires, etc.), certains utilisent markdown pour leurs billets. Des fils RSS globaux et par catégorie sont disponibles, les pages sont générées à partir de templates HTML facilement éditables/lisibles.

Vicnent (2010-03-08T10:25:14Z)

Quelle est la problématique aujourd'hui? (tu as surtout exposé les raisons de tes choix en 2003).

Entre des choix comme Wordpress, Doclear et Blogspot qui sont 3 essences différentes, rien ne te va ? Tu vas encore re inventer la roue (pour de bonnes raisons en théorie) ?

Gabriel (2010-03-08T08:23:34Z)

Si tu tiens vraiment à conserver un fichier XML unique, et à utiliser perl, tu as webmake : http://webmake.taint.org/ (par l'auteur de SpamAssassin).

Pas mal, mais exclusivement tourné vers la génération de pages XML (la doc n'explique par exemple pas comment lui faire générer une CSS). Aucune idée en ce qui concerne les performances sur un fichier aussi gros que ton site.

Couard Anonyme (2010-03-08T04:51:31Z)

A quoi bon avoir des potes qui font des langages dedies pour traiter nativement de l'XML si meme les potes ne s'en servent pas… Autant partir dans la finance se remplir les poches de pognon.

yogsototh (2010-03-07T23:11:58Z)

J'utilise aussi un générateur de pages statiques. J'avais aussi envie de trifouiller moi-même mes pages HTML et d'avoir un système sur lequel je garde la main. Après quelques recherches, je me suis orienté vers nanoc (http://nanoc.stoneship.org/). Il n'utilise pas du C mais du ruby ce qui pour passer d'un algorithme à son exécution est bien plus pratique que du C et même bien plus que du Perl.

Le système n'est pas fait pour utiliser du XML mais peut facilement être adapté à cela. Le site de son auteur est très bien. De plus Denis Defreyne, le créateur de ce moteur de génération (engendrement) de pages statiques est très disponible et agréable. Son code source est lisible et propre. Il en est maintenant à la troisième version de son moteur. Les pages ne se regénèrent (réengendrent) que si on a modifier un fichier source.

C'est vraiment un système très pratique et Denis donne le code source de la plupart des sites (dont son blog personnel) pour pouvoir s'en inspirer. Je conseille vivement son système.

/!\ Point de vue subjectif /!\

De plus en tant que développeur, je bosse dans une boite qui a développé son CMS en utilisant des génération (engendrement) de page web via du Perl et du code en XML. Même si je suis persuadé que rien ne peut être aussi horrible que le code que j'utilise dans mon cadre professionnel. XML est bien trop verbeux, on fait beaucoup mieux pour la relecture et l'organisation à mon humble avis. Et Perl, est de tous les langages de programmation que je connais (et j'en connais beaucoup) celui qui peut le plus facilement devenir intraduisible par son propre développeur. Les trois seuls langages pires que Perl que je connaissent sont le langage machine, l'assembleur et whitespace (http://compsoc.dur.ac.uk/whitespace/ - plus difficile à déchiffrer que Perl, mais les codes sources sont plus propres).

Si j'avais un choix à faire la première chose que j'éviterai serait XML et Perl. Je préfèrerai cent fois coder un générateur à partir de fichier utilisant du pseudo-code personnel (style LaTeX ou markdown) avec un moteur écrit en C.

En tout cas, ça vaut le coup de tester nanoc. C'est un système propre, relativement rapide de prise en main et qui possède des "Helpers" qui permettent d'aider la gestion de blog ou des flux RSS par exemple. Comme je l'ai dit plus haut, le code de Denis souvent très propre et on peut le modifier à souhait le moteur étant bien entendu open source.

(pourquoi je n'arrive pas à faire de réponse rapide aux blog ?)


You can post a comment using the following fields:
Name or nick (mandatory):
Web site URL (optional):
Email address (optional, will not appear):
Identifier phrase (optional, see below):
Attempt to remember the values above?
The comment itself (mandatory):

Optional message for moderator (hidden to others):

Spam protection: please enter below the following signs in reverse order: b68f28


Recent comments