Denis Bernard a écrit 222 commentaires

le but d'un langage de programmation est de générer un source assembleur.

Mauvaise définition (beaucoup de langages de programmation ne respectent pas cette définitions)

Bon, ceci est hors du topic de mon journal qui visait à faire en première lieu à faire la promo de fBlog et en second lieu de mettre en parallèle deux sites identiques générés sous fBlog (l'un en hébergement à domicile sur un ordi de bureau banal oceamer.com, l'autre chez un hébergeur de premier plan oceamer.fr ). L'aspect du choix de Fortran pour la programmation est pour moi secondaire. Si j'avais eu la maîtrise de Python au début, nul doute que c'est ce langage que j'aurais employé. Mais comme j'avais un passé avec Basic, Fortran m'a paru être plus évident.

Chacun a sa petite opinion sur la définition d'un langage informatique, je vais donc préciser ici ce que j'en pense (mais je suis un pur autodidacte, pas un distingué docteur en informatique !).

À mon sens la programmation pure se fait en opcode ou en assembleur. J'ai connu un navire de commerce construit en 1999 avec un système de contrôle de cargaison de gaz de pétrole liquéfié qui ne pouvait se programmer qu'en opcode depuis un télétype qui servait aussi d'imprimante pour la transcription des alarmes. Je ne sais pas si ça existe toujours dans l'industrie de nos jours.

Par abus de langage, dans la mesure où l'on écrit dans un langage informatique qui va ensuite générer du code assembleur qui ensuite sera transformé en un fichier elf (ou autre), je parle encore de programmation et de langage de programmation. Mais, j'en conviens, c'est un abus de langage !

Ceci étant, il n'y a pas que des langages capables de générer au final un fichier elf. Il y a ceux qui sont interprété soit dans une runtime soit dans un interpréteur externe. Si l'on prend le cas de Fortran, la norme n'emploie absolument pas le mot de "compilateur" mais celui de "processeur". Car Fortran peut tout aussi bien être exécuté par un interpréteur ! Si je ne connais pas d'interpréteur Fortran en usage aujourd'hui, d'après mes lectures, j'ai des raisons de penser qu'il en a existé jadis.

De nos jours, le mot "développeur" tend à se substituer à celui de "programmeur". Je pense qu'il y a là-aussi un abus de langage. Pour moi le développement est la création d'un logiciel alors que la programmation est la création d'une routine. Le développeur fait une agrégation de plusieurs routines (qui pourront être écrites dans des langages différents) alors que le programmeur agit sur un spectre plus étroit.

Par exemple, si j'écris une routine pour afficher un calendrier sur une console à la ligne de commande, j'estime être dans le cas d'une programmation. Si la même routine fait appel à la bibliothèque ncurse pour afficher le calendrier d'une manière plus jolie, j'entre dans le développement. Idem si la routine attaque une bibliothèque graphique sous X-Window.

s'il est difficile de citer les principaux moteurs de blog statiques, c'est parce ce genre d'outil est assez peu utilisé.

Oui, c'est statistiquement vrai. Mais je crois que les gens commencent à s'y intéresser un peu plus car les moteurs de blogs statiques ont certains avantages de robustesse.

Ajouter deux liens dans une page, oui, si on veux, c'est du traitement, sauf que ça ne demande rien à faire. Comme cela a été dis plus haut, ce que fait ton moteur de blog, c'est trois fois rien pour un développeur. Surtout avec des outils plus adaptés.

Absolument d'accord ! La partie programmation pure d'un moteur de blog n'est pas un exploit. Tant que l'on sait ce que l'on veut. Si l'on sait ce que l'on veut, soit le problème a déjà été fait par autrui et il n'y a qu'à copier-coller, soit on est dans dans un cas nouveau. Auquel cas on ne sait pas d'avance si c'est réalisable ou pas. Mais très vite on est fixé.

Le souci commence quand on ne sait pas très bien ce qu'on veut. Généralement on sait très bien ce qu'on ne veut pas. Si la liste des options restantes est bornée, il suffit de procéder par élimination. Sinon, on brasse…

Dans mon cas, j'avais identifié mes problèmes avec NanoBlogger qui étaient uniquement dû à un mauvais passage à l'échelle. (Un mur au-delà de 100 billets).

Dans le cadre d'un blog tenu sur une longue durée avec de nombreux billets par mois, il me semblait indispensable d'avoir un système d'archivage. Le problème n'est pas de coder ça mais de savoir combien de pages on veut (une récapitulation par an, une récapitulation par mois, une récapitulation par semaine ?).

Je m'arrête là car il y aurait beaucoup d'autres point de détails à communiquer et la place, et l'énergie me manque.

En fait, si l'on a déjà vu à quoi ressemblait une roue et si l'on en a vue une application (pour une brouette par ex.) n'importe quel abruti peut construire une brouette. Mais on a connu jadis de très grandes civilisations qui ignorait cet accessoire si banal dans nos jardins.

Donc coder un logiciel en se basant sur le design d'un logiciel existant est à la portée de bien des gens. Et c'est même le minimum syndical pour un pro. Reste l'outillage : sujet hautement trollesque ! J'ai donné plus haut mes motivations sur le choix de Fortran, je n'y reviendrai donc pas.

Mais j'affirme que la partie codage en Fortran de fBlog n'a été qu'une très petite part du temps consacré. Le restant se partageant entre mes hésitations sur le design des pages et le codage HTML et CSS. Vous pouvez ricaner sur la difficulté à maîtriser HTML et CSS ! Mais regardez donc l'annonce faite dans ces colonnes le mois dernier concernant la mise à jour de Dotclear et une remarque que j'avais faite. Aujourd'hui le site officiel de Dotclear est toujours sous le doctype XHTML 1.0 Strict ! J'ai exploré aussi les limites des CSS en supprimant les balises DIV et SPAN et en les remplaçant par des pseudo classes. Ça aussi, ça prend temps. Et je n'étais même pas sûr que ce soit faisable. Mais, tant que j'y suis : amis lecteurs, avez-connaissance d'un moteur de blog n'employant que des pseudo classes ?

Donc à a vue de pif dans ce cas tu passes 20% du temps on CPU dans la fonction html_month_archive

Ça confirme bien ce que je pensais; mais bien évidement ce n'est pas impactant sauf sur ma petite fierté !

Si le nombre de fichiers dans export_html dépasse le nombre d'argument supporté par la ligne de commande tu plantes.

Merci de l'info !

De tête Jekyll, Pelican et quelques dizaines d'autres dont j'ai oublié le nom

Oui, sauf que je n'en ai pas encore vu un seul qui répondait à mes désirs : des permaliens, un chaînage par lien des permaliens entre-eux et un moyen de retrouver un billet précis connaissant le mois de sa publication puis connaissant soit son titre, soit son jour et heure de publication. Il doit aussi supporter au moins un billet par jour sur de nombreuses années.

Jekyll et Pelican ne semblent pas avoir de liens chaînant les permaliens entre-eux et la page d'archive ne convient pas pour un blog ayant de nombreux billets sur de nombreuses années. Mais si je dis une bêtise, que quelqu'un donne l'URL d'un blog fait sous Pelican ou Jekyll et qui répondrait à mes besoins.

Et si quelqu'un a la connaissance d'un moteur de blog statique qui a au moins les mêmes fonctionnalités que fBlog, merci de me répondre ici !

je ne vois pas en quoi cela mettrait à mal la sécurité, pourquoi un rafraîchissement partiel serait plus propice à des "loupés"

Si l'on se place dans le cadre d'une mise à jour partielle d'un blog, l'on n'aura que peu de fichiers à transférer vers le répertoire du serveur (environ 2 ou 3). Et d'une manière générale, toute modification sera systématiquement l'ajout ou la modification d'un billet existant. Dans ce cas, au fur et à mesure que le blog grossi, on pourra faire ce transfert manuellement soit en copiant en vrac la totalité des fichiers si le répertoire du serveur est sur la même machine que le moteur de blog soit en les transférant vers le répertoire de l'hébergeur. Il y a deux possibilités alors : rsync ou ftp. Mais certains hébergements n'ont que ftp. Alors il semble évident de ne transférer que la poignée de fichiers modifiés. C'est absolument sans inconvénient tant que l'on ajoute ou que l'on modifie un billet.

Comme la routine de la mise à jour du blog devient une seconde nature, lors du cas exceptionnel d'une suppression de billet, s'il agit comme d'habitude l'utilisateur peut oublier d'enlever le billet incriminé résidant sur le répertoire du serveur. Ou se tromper dans la suppression du fichier car mon système de nommage n'est absolument pas fait pour les humains (une suite de chiffres).

En ne conservant qu'une seule procédure de mise à jour, la procédure de transfert sera la même qu'elle que soit le nombre de billets ajoutés ou supprimés. Et les fichiers auront tous la même date ce qui rend encore plus délicat de savoir ceux qui ont été réellement modifiés ou pas. Le plus simple sera donc de procéder par wagon entier pour les transferts. (Par exemple, mon hébergeur conseille d'uploader une tarball plutôt que les fichiers individuellement.) Dans ce cas, on videra le répertoire du serveur et l'on y éclatera une tarball. Ce qui veut dire que le blog mis à nouveau en ligne sera complètement clean que l'on ait fait une mise à jour anodine ou critique.

Une autre possibilité serait de lier symboliquement le répertoire du serveur sur celui d'export du moteur de blog si les deux résident sur la même machine (ou de faire un montage NFS sur un serveur distant ?).

Tout ceci peut sembler paranoïaque mais, faisant parti des gens que l'on peut qualifier de "tête en l'air", je sais qu'il existe un risque sérieux et réel lors d'une suppression de billet. Et je sais aussi que les conséquences sociales peuvent être lourdes.

fBlog ne fait RIEN. Grosso modo il rajoute un header et un footer à des fichiers texte et maintient trois pauvres index. C'est entièrement IO bound et ça ne peut pas être lent au delà des lectures et écritures de fichier.

C'est si facile à faire un moteur de blog statique qu'il en existe des centaines de projets ! La vérité oblige à dire que si l'on peut aisément citer de tête les trois premiers acteurs en matière de moteur de blog dynamique, on ne peut pas en dire autant des moteurs de blog statiques (enfin, ceux qui tiennent vraiment la route).

Oui, pour la fabrication d'une page, il y a juste à l'encadrer de l'en-tête et du pied de page qui va bien. Là où ça se corse c'est quand on veut y mettre les deux liens des pages précédentes et suivantes. C'est quand même une fonctionnalité sympa que bien des moteurs de blog (statiques ou dynamiques) n'ont pas. Pour Wordpress, il semblerait qu'il ne le fasse que depuis peu. Et ça c'est du traitement de données internes. Pas du I/O.

Pour les index : ah ah, ça c'est le gros morceau à coder ! Au point qu'il n'y a pas tant de moteurs de blog que ça offrant une recherche par date d'un permalien. fBlog le fait en 2 clics. Une grande partie des autres moteurs de blog (statiques ou dynamiques) se contentent de saucissonner le montant des billets en paquets de dix et à en mettre les liens en bas de pages (comme les résultats des moteurs de recherche). Les plus sophistiqués font un tri par mois et il faut se taper la totalité de la page de ce mois où va s'agglutiner tous les billet dudit mois. S'il y en trois ok ; mais avec une vingtaine… Et ça, c'est du traitement de donnée interne. Pas du I/O

Le test de performance m'a intéressé car je n'ai pas de SSD. Sauf qu'il est à refaire complètement car il ne rime à rien ! En effet, ton one liner génère les billets sur des dates très rapprochées. Il faudrait tu refasses ce test en se basant sur un billet par jour sur 50 ans. Et là, je suis certain que les chiffres seront très différents. Et je suis sûr que tu verras que le temps de cogitation est non négligeable comparés aux I/O. Tu verras aussi qu'il y a une routine qui rame, celle qui fait l'indexation des mois. (Elle est codée naïvement, j'avais prévu de l'optimiser cet hiver mais je n'ai pas eu le temps.)

J'attends avec impatience ces nouveaux tests !

ça t'obligera à taper 14 caractères plutôt que 3 ou 4 pour les commandes précitées

Honnêtement, qui est capable de copier 14 caractères de mémoire ? Certes on peut toujours utiliser la souris pour faire un copier-coller… Non, définitivement non, un identifiant basé sur la date et l'heure ça ne le fait pas pour les humains.

Concernant le principe du rafraîchissement partiel du blog et de sa reconstruction totale de temps à autre : ma réponse précédente me semblait claire. Relis-la ! J'ajoute que je l'avais implémenté au début dans mon propre projet. Je sais faire ! Et quand je dis que prends à cœur les loupés que l'utilisateur pourrait commettre en cas de rafraîchissement partiel de son blog au lieu d'une totale reconstruction, c'est sincère et basé sur mon expérience de la communauté des utilisateurs francophones de NanoBlogger. Je privilégie la sécurité des données au détriment de la performance.

J'ajoute aussi que tenir un blog n'est pas une chose anodine : il ne se passe pas une semaine en France (ou ailleurs) sans qu'un scandale éclate à la seule vue d'une phrase scabreuse écrite à la va-vite dans un post ou la photographie d'une soirée arrosée entre copains où l'on est vu déguisé d'une manière inapproprié ou en tenue d'Adan. Pouvoir éliminer le billet compromettant à coup sûr alors, que l'on en proie à une émotion vive due à un entourage très colère ou encore dans les vapeurs d'alcool de la soirée de la veille, me semble une chose importante.

De tout ce qui précède je maintiendrai ma position en matière d'ergonomie et de sûreté des données. Ceci étant, fBlog est sous GPL, chacun est libre de le forker. Et les connaisseurs du langage Fortran pourront témoigner, j'en suis sûr, que j'ai pris soin à ne pas offusquer le code ni à le rendre abscons (c'est si facile avec Fortran !).

mais tu n'as pas besoin de tout régénérer à chaque fois que tu postes un article, si ?

Si. Et j’ai fait exprès, en plus !

Il y a deux bonnes raisons raisons à vouloir réécrire 100% des fichiers lorsque l’on poste un article. La première est technique (la facilité de maintenance du logiciel), la seconde est d’ordre humain (un logiciel ne doit pas nuire).

Fblog est issu de ma seule expérience d’avec NanoBlogger (je n’avais jamais blogué auparavant). NanoBlogger a l’option de rafraîchissement qui permet une mise à jour partielle du blog en cas d’ajout d’un billet (ou de sa modification) et une autre de reconstruction totale. Je pense que d’autres moteurs de blog statique ont eux aussi ces deux options (mais en fait, je n’en sais rien…). Les utilisateurs de NanoBlogger ont rapportés de nombreux bogues car ils se contentaient de faire une mise à jour partielle plutôt qu’une mise à jour intégrale lors de certaines circonstances. Le vrai problème pour le programmeur est de décider où doit se situer le curseur entre le partiel  et l’intégral. Et le problème pour l’utilisateur est de savoir ce qu’en pense le programmeur. En plus, du point de vue du code, c’est une sacré complication que d’implémenter et faire coexister les routines des mises à jour partielles et intégrales.

J’ai longtemps hésité sur l’utilité d’une mise à jour partielle. Mais quand j’ai vu que la technologie des machines d’aujourd’hui permettait de générer des milliers de fichiers en quelques secondes, d’un point de vue pragmatique, j’ai décidé que c’était un tracas inutile que d’implémenter l’option de rafraîchissement. L’autre raison est bien plus cruciale : un logiciel ne doit pas nuire à son utilisateur.

Un blog est une chose amusante à tenir, sinon en en tiendrait pas, hein ? Sauf que sur Internet, comme dans la vraie vie, « si les paroles s’envolent, les écrits restent ». Il peut arriver que l’on ait à supprimer un ancien billet devenu compromettant. Dans ce cas, l’option de rafraîchissement du blog devra-t-il en tenir compte ou pas ? C’est le choix du programmeur et uniquement lui. Et encore heureux s’il ne change pas d’avis entre deux versions ! Il y a aussi, dans le cas d’une option de rafraîchissement, la possibilité de dé-indexer le billet mais sans le supprimer du système de fichier. Tout est possible, c’est le programmeur qui décide ! Reste qu’à ce moment là, si le billet compromettant a été mis en marque-page quelque part, il sera toujours lisible sur Internet même si son lien au sein du blog a été supprimé.

Il y a aussi une chose encore plus pernicieuse concernant la suppression d’un billet de blog : celle que cette action entraîne un aveu de culpabilité. En effet, si quelqu’un demande et obtient la suppression d’un billet offensant, il jubile. Encore faut-il qu’il puisse apporter la preuve que sa réclamation ait été couronnée de succès ! En effet, pour des facilités de modification / suppression d’un billet de blog statique, il semble évident d’attribuer un identifiant à chaque billet. Ce pourrait être la date et l’heure mais c’est pas pratique à saisir. Donc, j’ai choisi un identifiant numérique. Mais si j’attribue un identifiant numérique fixe qui s’incrémente au fur et à mesure que le blog grossi , la suppression d’un billet sera visible car il y aura un trou dans l’ordre des identifiants. C’est pourquoi fBlog renumérote absolument tous les billets que l’on en ajoute ou que l’on en supprime. Et pour couronner le tout, j’ai choisi de mettre le numéro le plus faible pour le plus récent des billets (numéro 1) et le numéro le plus fort pour le billet le plus ancien (numéro égal au total des billets du blog). Ainsi, en ouvrant la page d’accueil du blog, on ne peut pas deviner si un billet a été supprimé suite à un contentieux.

Le seul fait de renuméroter tous les billets du blog entraîne une mise à jour intégrale. Fblog, pour ces raisons de sûreté de la vie privée, détruit l’intégralité des données résidant dans le sous-répertoire « fBlog/export_html » avant de procéder à la mise à jour. Ceci évite donc d’y voir résider un billet que l’on pensait avoir supprimer de bonne fois. Cependant, si l’utilisateur se contente d’uploader les fichiers de ce sous-répertoire vers son serveur Web (au lieu de faire une vraie synchronisation !), le billet qu’il croyait avoir supprimé sera toujours visible sur Internet. Mais ça, ce n’est plus de ma responsabilité d’auteur !

Nope, le plus ancien langage c’est l’assembleur (1949)

Je n'ai jamais pratiqué l'assembleur (tout juste quelques "hello world!"). Je n'ai jamais rien entendu d'une quelconque normalisation de l'assembleur et je remarque qu'il existe plusieurs notations (AT&T ou Intel ?). Je ne mets pas l'assembleur pur dans les langages de programmation sauf, à la rigueur, si on le mixe avec des directives et des macros comme ça semble se faire aujourd'hui.

Dans le contexte des années 50 (je ne faisait pas d'informatique à ce moment là !) il n'existait que des programmeurs purs et durs. Un ingénieur ou un scientifique devait passer par eux car l'apprentissage de la programmation était vrai métier pas un hobby. L'invention de Fortran visait à rendre accessible l'écriture de programmes aux personnes n'ayant rigoureusement aucune qualification en programmation. Et donc à se passer de programmeur. Aujourd'hui, gfortran traduit le source Fortran en source assembleur. Et gcc fait de même pour le langage C.

De ce qui précède, je ne considère pas l'assembleur comme étant un langage de programmation car le but d'un langage de programmation est de générer un source assembleur.

La première version de FORTRAN en 1957.

Oui, mais au sein d'IBM. On peut aussi considérer que Fortran est vraiment né quand il a été porté chez d'autres constructeurs qu'IBM. Et là, oui, on est dans les années 60 !

Ça me fait doucement rire de lire que Fortran savait tout faire depuis ses débuts. On en est loin.

Le sujet de mon article était la promotion de mon logiciel et non pas celle du langage Fortran, j'ai forcément fait court. Par exemple, j'ai le livre de Madeleine Bernheim "Fortran mode d'emploi" édité en 1991 et qui donne la version F77 comme étant la cinquième évolution de ce langage. (Peu de gens savent aussi qu'il a été normalisé par l'ISO un Fortran "Temps réel" !)

Mais si l'on doit faire court, on peut raisonnablement considérer la version F77 comme étant la première au vue de sa popularité. D'ailleurs gfortran supporte la version F77 et non celle plus ancienne F66 pourtant normalisée par l'ISO.

pour du traitement de données en mémoire ouais Fortran va sûrement être performant, mais pour des I/O sur des fichiers sur disques, non.

Tout à fait d'accord ! Mais, là encore, j'ai voulu faire court dans mes propos. À disque dur égal, Fblog aura des variations de performances considérables selon les options de journalisation du système de fichier. Ceci portant sur le second volet des I/O. Et l'on est tous les deux d'accord sur la bonne prise en charge du traitement des données en mémoire par Fortran.

Il s'agit essentiellement d'IO de quelques centaines (soyons fous, milliers) de fichiers

J’ai dimensionné fBlog sur la base d’un blogueur hypothétique qui posterait un billet par jour sur 50 ans. Si l’on multiplie 365 jours X 50 ans, ça fait déjà 18250 permaliens. Comme on a aussi une page d’indexation des billets chaque mois, ça fait 12 mois X 50 ans soit 600 pages. À cela l'on ajoute la page d’accueil plus la page d’archive récapitulative soit 2 pages. Au total : 18250 + 600 + 2 = 18852 pages Web à générer. Mes tests sur un vieil ordinateur me donnent moins de une minute de traitement avec fBlog.

Dans la pratique, il peut se passer deux choses : soit le blogueur poste 2 billets par mois et fBlog est surdimensionné, soit il prend six photos par jours qu’il poste à chaque fois sur son blog et là fBlog tiendra la charge seulement quelques années (alors il faudra bien me remettre au code et étudier la parallélisation des tâches qui est l’un des dadas du langage Fortran).

Les chiffres que je donne sont à considérer avec ceux des utilisateurs de Facebook : ils sont plus ou moins bavards (et aussi plutôt « texte écrit » ou plutôt « images »).

Choisir le bon outil pour effectuer le bon travail

Désolé de vous contredire ! Le langage Fortran (historiquement le plus ancien des langages de programmation) a été inventé à une époque où les programmes tournaient sous hyperviseur et non pas sous système d'exploitation (pas encore inventé). Ceci a fait que Fortran, dès ses débuts, devait gérer lui-même les lectures-écritures des fichiers en mémoire vive et aussi les entrées-sorties sur les périphériques. Par exemple, Fortran a toujours connu le principe des fichiers temporaires en mode virtuel (fichiers scratch). Et Fortran peut agir sur les fichiers de façon à se créer des bases de données sans recourir à un logiciel externe.

Oui, La part de calcul pour un moteur de blog est minuscule. Par contre la gestion des fichiers est d'une toute autre ampleur ! Faite le calcul du nombre de pages générées pour un blog qui serait tenu par un blogueur qui posterait au même rythme qu'un Bortzmeyer à la fin de sa vie ? J'ai fait un test en convertissant le blog (sous Wordpress) du très fameux Eric S. Raymond pour voir si fBlog tenait la charge…

Que Fortran ait été créé pour faire du calcul intensif est une évidence. Mais ledit calcul intensif suppose de brasser des tonnes de données. Or un blog, qu'il soit statique ou qu'il soit dynamique, doit brasser des tonnes de données. Si l'on a pas le bon langage de programmation pour le faire, on est obliger de sous-traiter la chose par une base de données externe *SQL (ce qui résoudra la question des lectures-écritures des données mais pas celle les entrées-sorties sur les mémoires de masse).

l'héritage ancestral des métiers qui utilisent ce type de calculs et les librairies "métier" qui vont avec

Est-il nécessaire de rappeler que Fortran est presque entièrement interopérable avec C/C++ (donc la libc !) de nos jours ?

vos problèmes venaient-ils de changements dans Bash ou dans NB lui-même (auquel cas le langage n'a rien a voir là dedans) ?

Ce qui m'a motivé à écrire fBlog (et je jure que c'est bien la seule raison !) c'était que NanoBlogger commençait à ramer sérieusement quand on dépassait une centaine de billets. Et bien des utilisateurs sont passés à un autre moteur de blog pour cette seule raison. (C'est toujours vérifiable car NanoBlogger est toujours disponible en téléchargement et il est toujours packagé par les grandes distributions.) L'aspect maintenance ne se posait pas car elle était assurée par son auteur (Kevin Wood), je n'avais qu'un rôle mineur de traducteur.

Sur les machines de l'époque (mono-cœur), ça prenait environ une minute pour générer un centaine de billets. La cause est multiple : un script Bash est forcément lent, déclenche des tas de processus en parallèle et sature le système. Les lectures-écriture des fichiers sont nombreuses et arrive le moment où le système de fichier doit se synchroniser avec le disque dur ce qui amène à de nouveaux processus. Alors ça rame de partout. Mais, aujourd'hui, je suis sûr que Nanoblogger doit tenir mieux la charge avec les processeurs mufti-coeurs et un disque SSD.

Une autre cause de ralentissement de NanoBlogger est la possibilité de créer des catégories ce qui augmente considérablement le nombre de pages à générer. C'est la raison pour laquelle je n'ai pas voulu de catégories pour fBlog.

Ceci étant, pour ceux qui écrivent un ou deux billets par mois, NanoBlogger est un bon cheval. Concernant fBlog, j'ai décidé qu'il devait être capable de générer le blog d'un blogueur compulsif sur la base d'un billet par jour pendant 50 ans en moins d'une minute. D'après mes test, fBlog peut le faire !

en revanche si j'ai bien compris c'est plus le fait que compiler en statique qui vous intéresse

Le principe des langages pouvant tourner éventuellement sous runtime est une chose qui m'intéresse vivement. C'était le cas de QuickBasic qui était un outil fabuleux. Pour l'instant, je me mets (très doucement) à gForth. L'inconvénient de ce type de dispositif est que l'assise est faible : qu'advient-il quand l'équipe des développeurs (ou l'entreprise, ou l'institution) s'en désintéresse ?

Ce qui m'intéresse au plus haut point est de ne pas avoir à recoder un logiciel quelques années après, parce que le compilateur n'existe plus, que le langage interprété utilise une nouvelle machine ou change ses règles, etc. Ayant eu l'expérience de NanoBloger qui est codé en script Bash, j'ai vu qu'il fallait reprendre le code plusieurs fois par an juste pour en assurer la maintenance. Or, dans mon cas, mon emploi du temps ne me permet pas d'assumer cette maintenance de code. L'avantage des langages compilés (comme C, Ada ou Fortran) est qu'ils ont une sorte de parfum d'éternité.

plutôt que sur du html/css à la sauce fortran

Attention ! Seul le HTML généré est à la sauce fortran. La feuille de style est strictement en dehors du moteur de blog et totalement apportée (ou rédigée) par l'utilisateur. Si j'ai codé la feuille de style standard dans mon moteur, c'est pour faciliter le packaging du logiciel qui est ainsi en un seul tenant. Cette feuille de style standard est écrite sur un fichier dans le sous-répertoire fBlog/styles seulement lors de l'installation du logiciel. On peut la modifier avec un éditeur de texte ou la copier sur un nouveau fichier ou s'en inspirer pour créer une nouvelle CSS. Si vous supprimez cette feuille de style standard, vous ne pourrez pas demander à fBlog de la recréer. (Il vous faudra créer un nouveau blog dans un autre répertoire et faire un copier-coller de cette CSS.)

Dans mon choix, il faut bien tenir compte de mon passé. En effet, j'ai acheté ma première calculatrice 4 opérations à l'âge de 23 ans alors que mon pain quotidien étaient les tables des logarithmes des fonctions circulaires. Le premier programme que j'ai écrit était en basic sur une calculette programmable, j'avais 35 ans. Quand je suis passé de Windows 95 à Linux, j'avais 39 ans. Et l'ADSL est arrivé chez moi à l'âge de 47 ans. Tout ceci fait que j'ai les lacunes énormes que l'on trouve chez tous les autodidactes.

En ce qui concerne le C++, sans vouloir troller exagérément et sans l'avoir jamais pratiqué, je subodore que la toute dernière version de gfortran fait presque aussi bien que C++ mais sans douleur. Sincèrement, je ne savais pas que Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel pouvaient être compilés statiquement (et sans runtime ?) sur Linux.

En ce qui concerne mon choix de Fortran, sa normalisation (et donc sa pérennité) a été déterminante pour moi.

Il vrai que le langage Go semble avoir la cote en ce moment et on le voit bien dans la liste des moteurs de blog statiques.

Si la feuille de style n'est générée qu'à la création du blog, comment cela se passe lors d'une mise à jour du moteur ? La version existante sera conservée, ou bien remplacée par celle embarquée par le moteur ?

Quand il y a une mise à jour de fBlog et qu'on installe le binaire dans un répertoire global (/usr/bin), son invocation n'installera pas une nouvelle feuille de style ni aucun autre fichier. Seulement, les feuilles générées suivront le nouveau template HTML qui est codé en dur. Dans la mesure où la mise à jour n'a pas modifié le template HTML, la feuille de style ancienne (personnalisée par vos soins) restera valide et tout se passera bien. Dans le cas contraire, il faudra peut-être adapter la feuille de style.

Mais, et c'est la grande force de fBlog, ce logiciel peut se compiler en statique. Et cela, une fois fait, il reste opérationnel sur une même machine quelque que soit la version de Linux ou de la libc. Si vous avez un site Web dont vous voulez garder durablement la présentation, je vous conseille de mettre le binaire exécutable dans le même répertoire que celui où vous générez vos pages. Il n'y aucun inconvénient, il n'y a aucun risque à mettre plusieurs versions de fBlog sur une même machine.

Il y a des tas de bonnes raisons de vouloir éditer les templates html

Oui, je suis d'accord. Et d'autant plus ayant pratiqué NanoBlogger. Mais le revers de la médaille est de réussir le couplage du HTML d'avec le CSS. Et ça, ça demande énormément de temps, de patience et de compétence. En rigidifiant d'un côté, j'apporte plus de souplesse de l'autre. C'est l'orientation fondamentale de fBlog.

ou tout simplement vouloir contribuer à ton moteur de blog.

fBlog est un projet individuel et le restera : je fais des tas de choses dans ma vie et je suis dans l'impossibilité d'assumer une coordination au jour le jour d'une communauté. Cependant j'apprécierai grandement tout rapport de bug ! Et aussi le témoignage d'utilisateurs heureux.

En fait vous en changez tout le temps…

La variété des embarquements dépend de deux choses : le nombre de navires dans une entreprise donnée et le statut du marin.

1. Si une compagnie a plusieurs navires, les marins passeront de l'un à l'autre. Certes le capitaine aura tendance à se spécialiser plutôt sur l'un d'entre eux pour des raisons pratiques mais pas forcément. Et si la compagnie n'a qu'un seul navire, forcément ce sera toujours le même capitaine (ou plutôt deux pour le remplacer pour les congés). Mais beaucoup de compagnies n'ont très peu de navires ; donc ce sera toujours les mêmes à bord.

2. Le statut du marin (simple matelot ou capitaine) est le même que celui du secteur privé des entreprises terrestres : soit on est en CDD soit on est en CDI.

En ce qui me concerne, j'ai eu un parcours professionnel chaotique et je suis resté tout au long de ma vie en contrat précaire. D'où la diversité de mes embarquements.

il y a une sorte de répertoire des embarquements possibles ?

Ça se passe à peu près comme les pilotes de ligne : il faut obligatoirement les diplômes qui vont bien et ensuite on se débrouille pour trouver un employeur.

Je l'ai essayé, et il y a certains points qui sont pour moi rédhibitoires, le plus important étant que les templates html ainsi que les feuilles de styles soient écrites en fortran.

Attention, Seul le template HTML est écrit en fortan. Certes fBlog fournit une (et une seule) feuille de style standard qui est générée par un source fortran lors de l'installation mais vous êtes libre d'en créer de nouvelles autant que vous voulez.

La philosophie de fBlog est d'être personnalisable par la seule feuille de style : on ne touche pas au HTML ! Donc on n'a pas à recompiler le logiciel. C'est le contraire des autres moteurs de blog qui sont personnalisables à la fois au niveau du HTML et du CSS. Quant au JavaScript, la question ne se pose même pas pour un moteur de blog minimaliste.

Pour résumer, sauf à vouloir modifier la génération du code HTML (par exemple pour y inclure un support des commentaires avec JS), il n'est nul besoin de connaître un seul mot de fortran. Mais pour une traduction de l'interface utilisateur, oui il est nécessaire de rentrer dans le code. Mais ça nécessite que peu de savoir en fortran.

Oups ! Mea culpa.

On comprend mieux mon propos après la lecture de ce fil de discussion du forum de ce site en date du 02/03/14.

Il s'agissait de mon logiciel conçu pour tourner sur un ordi de bureau sous Linux et que quelqu'un a compilé le source tel quel pour le faire tourner sous Android. (Ledit logiciel tourne uniquement sur une console TTY mais il est possible d'émuler une console sous Android.) Sauf que mon logiciel qui fait obligatoirement appel à un éditeur de texte (Vi, par défaut) se trouve bloqué par l'éditeur appelé car il n'y a pas de touche échappement sur le clavier simplifié pour ces terminaux portables.

À la suite de quoi j'ai fait une recherche sur la liste des éditeurs de texte qui seraient compatibles avec les claviers pour Android et je n'ai trouvé que Ed. (Du moins en théorie car je n'ai pas essayé pour voir si ça marchait !)

S'agissant de la bascule insertion/lecture : Ed le fait quand on met un point tout seul sur la dernière ligne. Tout est documenté dans la page de man qui se trouve obligatoirement sur tout Unix car Ed fait fait parti de la liste des utilitaires obligatoires (Ed se trouve normalement sur toute machine Linux). Sinon, aller sur Wikipedia !

Pour la petite histoire, l'auteur de Ed est le regretté Ken Thompson.

Ed est une horreur à utiliser avec nos consoles d'aujourd'hui (il devait être parfait du temps où la sortie "normale" d'une console était une imprimante à picots). Mais Ed a une qualité qui, à mon humble avis, semble être unique : le basculement entre le mode insertion et le mode lecture se fait par un point final. Ce qui veut dire que Ed est utilisable sur absolument tous les claviers de la planète ; même ceux des tablettes qui ne connaissent pas la touche Echap (ni les touches Fn !). Si quelqu'un connaît un éditeur de texte (sous licence libre) autre que Ed qui soit compatible avec les claviers virtuels minimalistes de tablette, je lui serais très reconnaissant.

Lire aussi ceci sur le site de l'ANSSI.

Je plus. Bonne idée de titre !

Bonjour,

Quand je vois une annonce pour un moteur de blog, c'est plus fort que moi, je ne peux pas résister, je le soumets au Markup Validation Service ; ou mieux Unicorn. Mais là, pour le site "http://dotclear.org/", je me prends un "403 Forbidden". Idem pour les feuilles de style. C'est la première fois que je vois ce genre de réponse venant des vérificateurs du w3 ! Pas cool.

J'ai quand même fait vérifier la validité du HTML de la page d'accueil par téléchargement de fichier. Et là, je vois que le doctype est XHTML 1.0 Strict (et c'est évident aussi si l'on regarde le source !).

Là, je m'interroge : où est le HTML5 dont on parle dans la dépêche ? En tout cas, rendu fin 2014, publier en XHTML 1.0 Strict ça fait un peu désordre pour un site faisant la promotion d'un logiciel Web.

Bon, sachant que la critique est aisée alors que l'art est difficile, je souhaite bon succès aux auteurs.

C'est drôle, je voyais moi aussi la possibilité d'user d'un moteur de blog statique comme bloc note ou comme journal intime !

fBlog partage beaucoup de concepts avec NB comme le stockage des billet sous forme de fichier plat. Mais le format de fBlog est plus simple car il n'y a que deux méta données : la date d'édition est celle de la création du fichier et elle est intégrée (un peu comme NB) dans le nom du fichier sous la forme aaaammjjhhmmss.blog ; le titre est la première ligne du fichier et ne doit pas comporter de balise HTML. Le restant est le corps du texte et doit comporter des balises HTML.

Ce qui veut dire qu'il est possible de recycler ses vieux billets NB en renommant les fichiers et en extrayant la méta TITLE pour la mettre en tête dudit fichier.

À la date d'aujourd'hui, fBlog ne supporte pas les tags car j'ai remarqué que les internautes s'en fichaient complètement. Mais, dans le cas d'un usage bloc note, les tags reprennent tout leur intérêt ! Dans ce cas, selon le retour des utilisateurs, il se peut que je j'implémente cette fonctionnalité. Cependant je n'ajouterai pas une ligne supplémentaire de méta donnée dans le fichier car ça oblige à remettre un en-tête de méta balises comme dans NB ; et toute complication est un moins en ergonomie. Donc, si je le fais, ce sera en bout de la première ligne du fichier sous forme de crochets droits du genre : Mon titre du billet [humeur]. Le tag serait donc "humeur" et n'apparaîtrait pas sur la ligne titre en ligne mais créerait un lien "humeur" en bas du post qui renverrait vers une page index d'archives. Ce n'est pas la mort à programmer et ça conserve une compatibilité ascendante avec les billets existants.

Toujours est-il que j'invite tout futur utilisateur de fBlog à me transmettre son retour d'expérience. Sachant que les retours positifs sont tout aussi importants que ceux négatifs. (Pas pour le moral mais pour se sentir conforté dans ses choix de conception du logiciel et ne pas les modifier s'ils plaisent ainsi au public.) Autrement dit, sans retour d'expérience, on programme un peu à l'aveugle dès que ses besoins propres sont couverts. Certes il y a les sites de tests de conformité (HTML, CSS…) ainsi que d'autres pour les performances en vitesse de transfert et d'analyse des pages Web ; ils sont précieux mais il n'y a pas de logiciel capable de rendre compte des perceptions humaines comme l'ergonomie des interfaces utilisateurs ou la joliesse d'un thème.

Je suis l'ancien traducteur français de NanoBlogger. J'ai également participé au projet pour les feuilles de style et deux ou trois bricoles. Ça a été une aventure fantastique à l'époque avec une communauté d'enthousiastes : avec Blanko, nous avons animé la petite bande d'utilisateurs francophones.

NB est un des très rares projets ayant été codés en scripting Bash et sa lenteur est due uniquement à ça. Quand le blog contenait une centaine de billets, c'était galère. Je connais des développeurs (du genre qui ne peuvent pas se permettre de se faire pirater leur site Web au niveau de leur prestige personnel) qui utilisent encore NB pour la sécu apportée par un site statique. Cette lenteur intrinsèque peut être atténuée avec un SSD au lieu d'un HDD et d'un processeur (très) multicore.

Pour cette seule raison de lenteur, j'ai développé un remplaçant à NB en langage compilé au lieu de Bash. Maintenant pour une centaine de billets, au lieu de patienter une minute ou plus, ça me prend moins d'une seconde ! J'ai fait un test pour voir combien je pouvais faire traiter de billets en une minute, toujours sur le même PC qui me servait du temps de NB : l'équivalent de ce posterait un blogueur fou tous les jours pendant cinquante ans !

Ce projet est encore jeune et je ne connais encore personne l'ayant choisi pour son site perso. Mais il n'y a aucun risque à l'essayer puisqu'il s'agit juste de générer les pages du blog sur une machine Linux quelconque et pas forcément sur celle du serveur ! Si vous n'avez pas de serveur Apache ou Ngnix sur votre système, vous pouvez quand même visualiser le contenu de votre nouveau blog depuis un navigateur quelconque. Même hors ligne. Il n'y a aucune dépendance à la compilation donc pas de bibliothèque à ajouter au système. Il n'y a pas non plus de sorcellerie particulière pour l'installation : juste avoir le binaire dans le répertoire où l'on veut générer le blog ; ou sinon le mettre dans le répertoire "/usr/bin".

Il s'agit de fBlog et on peut le trouver sur SourceForge.