Le site arthur.bebou.netlib.re - retour accueil
git clone git://bebou.netlib.re/arthur.bebou
Log | Files | Refs |
commit bd6c014e9d39f9b57dee0b6aaca58d3770f3d52b parent db5f5367e14ec946c3d2c9dd2c7b979ae5bb1789 Auterice: Arthur Pons <arthur.pons@unistra.fr> Date: Wed, 25 Sep 2024 21:37:19 +0200 francium -> catium Diffstat:
| A | contents/benchmarkcatium/index.sh | | | 398 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| D | contents/benchmarkfrancium/index.sh | | | 398 | ------------------------------------------------------------------------------- |
| A | contents/chronocatium/index.sh | | | 289 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| D | contents/chronofrancium/index.sh | | | 289 | ------------------------------------------------------------------------------ |
| M | contents/emoji/index.sh | | | 2 | +- |
| A | contents/extension-catium/index.sh | | | 542 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| D | contents/extension-francium/index.sh | | | 542 | ------------------------------------------------------------------------------- |
| M | contents/legal.sh | | | 2 | +- |
| M | contents/liverepl/index.sh | | | 2 | +- |
| M | contents/portabilite/index.sh | | | 14 | +++++++------- |
| M | contents/services-sobres/index.sh | | | 10 | +++++----- |
| M | contents/sup-sonore/index.sh | | | 5 | ++++- |
| M | contents/tsv2anything/index.sh | | | 2 | +- |
| M | layouts/html | | | 2 | +- |
14 files changed, 1250 insertions(+), 1247 deletions(-)
diff --git a/contents/benchmarkcatium/index.sh b/contents/benchmarkcatium/index.sh @@ -0,0 +1,398 @@ +#! page + +title: Benchmark de Catium +author: Arthur Pons +publication: 2023-03-11 +description: Quelques statistiques sur le site de Katzele +sectionmd: main + +# Benchmark et critique des performances de Catium + +## Le benchmark + +J'ai eu l'idée d'écrire cette note en entendant parler d'11ty, un générateur de +site statique. Il est écrit sur leur site + +> Fast Builds and even Faster Web Sites + +Et on trouve une petite animation qui présente qu'11ty construit 4000 +fichiers markdown en 2s, plus rapide que qu'Astro en 20 secondes, Gatbsy en 30 +secondes etc. Le site omet qu'Hugo est plus rapide mais soit. + +Ces résultats proviennent de [ce +benchmark](https://github.com/zachleat/bench-framework-markdown). + +Et Catium ? Testons d'abord les performances de cmark et lowdown, les deux +parseur de markdown qui nous utilisons. En prenant les 4000 fichiers markdown +du benchmark et en lançant les commandes : + + time find -name '*.md' | xargs -n1 -P0 sh -c 'lowdown "$1" > "$1".html' -- + xargs -n1 -P0 sh -c 'lowdown "$1" > "$1".html' -- 4,84s user 1,05s system 307% cpu **2,291** total + +et + + time find -name '*.md' | xargs -n1 -P0 sh -c 'cmark "$1" > "$1".html' -- + xargs -n1 -P0 sh -c 'lowdown "$1" > "$1".html' -- 4,84s user 1,05s system 307% cpu **1,914** total + +On tombe sur des temps d'environ deux secondes. Je trouvais surprenant que ces +deux logiciels, écrits en C et dont le seul but est de convertir du md en html +ne soient pas plus rapides qu'Hugo. Marc m'a rappelé que cette commande fait un +fork par fichier et les forks c'est "couteux". + +> Un fork c'est la création d'un nouveau processus par un autre. Nos commandes +> seront un processus qui, pour chaque fichier en créera un nouveau pour faire +> sa traduction. Créer un nouveau processus a un coût fixe. Il serait donc plus +> performant de créer un minimum de processus qui gèrent un maximum de fichiers +> chacun. + +En l'occurence cmark peut prendre plusieurs fichiers en argument, on peut donc +écrire + + time cmark *.md + cmark *.md 0,08s user 0,07s system 29% cpu 0,528 total + +ou pour lowdown tout concaténer + + time cat *.md | lowdown + lowdown 0,15s user 0,07s system 32% cpu 0,689 total + +Dans les deux cas on s'économise le fait de devoir créer 4000 fichiers mais pas +celui d'écrire les données pour les voir dans la console. D'ailleurs avec : + + time cmark *.md /dev/null + cmark *.md > /dev/null 0,08s user 0,07s system 29% cpu 0,093 total + +on voit que la majorité du temps est passé à écrire le résultat. + +J'identifie avec le code suivant + + for i in $(seq 1 4000) + do + echo $i > $i.txt + done + ./test 0,03s user 0,17s system 99% cpu 0,199 total + +que cela prend un peu moins de 0,2 secondes de créer 4000 fichiers presque +vides[^1] ce qui voudrait dire que l'on a la découpe approximative suivante : + +| opération | temps (s) | +|---|---| +|traiter les données|0,1| +|créer les fichiers|0,2| +|écrire les données|0,22| + +En réalité j'en sais rien, je connais pas assez bien linux pour savoir si je +mesure les choses comme il faut. Prenez tout ça avec des pincettes. + +Quoi qu'il en soit nous apprenons de ce test que Catium ne pourra pas aller +plus vite qu'environ une demie seconde pour 4000 fichiers. Pour en faire un +benchmark assez équivalent j'ai retiré tous les alias de page, sauf %S et +modifié les pages md du dépôt de benchmark pour qu'elles n'aient plus le + + --- + title: blablabla + --- + +et leur ajouter le shebang + + #! page + +et les rendre exécutables. + +> J'ai fait ça avec +> +> find -name '*.md' | xargs -n1 -P0 sed -i 's/^/#! page\n/;2,4d' +> chmod 755 ./* + +J'ai vérifié au préalable, le titre n'est pas pris en compte dans le benchmark. +Du moins l'HTML généré par Hugo et 11ty a une balise `<title>` vide. +Une fois que tout est prêt on construit le site comme on le fait habituellement +avec Catium[^2] (version qui utilise lowdown) : + + time make -B -j + make -B -j 30,29s user 8,31s system 302% cpu **12,741** total + +On est donc sur du six fois plus lent que la simple conversion en HTML depuis +lowdown. Tentons de comprendre pourquoi en bidouillant, faute de savoir comment +correctement diagnostiquer ce genre de choses. + +Retirer les shebang et modifier le makefile pour faire + + ./page machin.md + +ne change rien en terme de performance. + +Supprimer l'appel à `install` en faisant directement une redirection semble +économiser environ une seconde. + +Supprimer l'appel à page en demandant à makefile de directement utiliser +lowdown et en supprimant les heredoc `%S` (en gros ce qu'on a fait au début +mais avec l'overhead de make) fait tomber le temps d'exécution à 3,7 secondes. +C'est donc quelque part dans page que l'on perd de la performance. + +J'ai ensuite repris depuis le début en supprimant la gestion des sections. Cela +revient à s'économiser la création d'un dossier temporaire et d'un fichier +temporaire[^3] par article. Ne plus créer le fichier temporaire qu'il faut +ensuite relire pour insérer son contenu dans le layout fait gagner environ 2 +secondes, make ne prend plus qu'environ 9,5 secondes. Ne plus créer le dossier +temporaire fait gagner 3 secondes supplémentaires pour descendre à 6,5 secondes +environ. + +Il semblerait donc que notre façon de gérer le layout soit responsable de 3 +secondes d'overhead sur 4000 fichiers. Pour que la comparaison tienne à peu +près la route j'ai modifié le template pour qu'il soit identique à celui généré +par Hugo. Je m'arrête là dans l'exploration des performances de Catium. + +On en retient qu'à la louche et avec mes outils de diagnostiques très +approximatifs, ce qui coûte est : + +| Modification | Temps (s) | +|---|---| +| overhead make | 1,7 | +| la création du dossier temporaire | 2 | +| la création puis la lecture du fichier temporaire par section | 3 | +| l'appel à install | 1 | +| le template | 3 | + +Ce qui ajoutés bout à bout explique la différence entre les deux secondes de +lowdown et les 12/13 de Catium. + +Résultats finaux : + +| Générateur | Temps (s) | +|---|---| +| Hugo | 1,6 | +| 11ty | 2 | +| Catium (sans sections) | 6 | +| Catium | 12 | +| Le reste | 20+ | + +## Et alors ? + +Catium tel qu'il existe pour le site de Katzele est 6 fois plus lent que les +deux générateurs de sites statiques les plus rapides et plus rapide que tous les +autres. Dans une version allégée, pour un site avec une seule section que l'on +souhaite alimenter de contenu il n'est "que" trois fois plus lent. + +C'est significatif mais à mettre au regard du temps d'ingénieurie investit. Il +est probable que le temps passé à construire Catium dans son ensemble est un +ou deux ou trois ordres de grandeur inférieur au temps passé à rendre Hugo et +11ty performants. + +De plus la comparaison de performances de logiciels est compliquée et +hasardeuse. Déjà parce que cela dépend du matériel sur lequel les logiciels +sont testés. Ensuite parce que les couvertures fonctionnelles ne sont pas les +mêmes. Nous avons vu que l'intégration de fonctionnalités supplémentaires dans +Catium pouvait avoir un fort impact sur sa performance. Qu'en est-il des +autres outils ? Hugo et 11ty font *beaucoup* plus de choses que Catium mais +le benchmark leur fait générer un site aussi simple que gros. Au vu de leurs +performances, ils ne semblent pas ralentir quand leurs très nombreuses +fonctionnalités ne sont pas effectivement utilisées. Comment Hugo et 11ty +réagiraient-ils si l'on construisait des sites plus complexes ? Et Catium ? +En l'absence de réponse à ces questions les benchmarks ne veulent pas dire +grand chose. + +Cela dit, pourquoi est-ce que ces logiciels font la promotion de leurs +performances sur leurs pages d'accueil ? Au-delà d'une éventuelle volonté de +savoir qui a ~~la plus gro~~ le plus rapide, possibilité à ne pas sous-estimer, +on pourrait aller regarder du côté des générateurs historiques. On me racontait +que fut une époque nombre de générateurs de sites étaient particulièrement +"lents". Il fallait attendre possiblement plusieurs dizaines de secondes pour +faire la revu de ses modifications ce qui rendait l'itération lente et le +travail fastidieux. Pour résoudre ce souci il semblerait que les communautés +autour de ces outils aient opté pour de l'ingénierie logicielle supplémentaire +faisant appel à nos matériels informatiques modernes très puissants. "Cela +prend 30 secondes de reconstruire tout le site pour vérifier le rendu de +notre nouvelle page ? Optimisons le code pour que les opérations aillent plus +vite et fassent usage de toute la puissance des processeurs pour le faire +descendre à deux secondes". + +Ce qui est intéressant c'est qu'en puisant dans une autre culture informatique, +comme la notre par exemple, ce n'est pas une autre solution qui aurait été +choisie mais le problème qui n'aurait tout simplement existé - ou suffisamment +rarement pour que ça n'en soit pas un. + +Illustrons cette idée en trois points : + +1. Dans le monde Unix le système de "build"[^4] traditionnel permet de ne + reconstruire que le nécessaire. + +Le système utilisé pour compiler de nombreux programmes dans le monde Unix (et +sur lequel Catium se base), make, utilise un graph de dépendance pour savoir +ce qui doit être reconstruit et ce qui est encore à jour. Ainsi, si l'on +modifie 10 fichiers markdown sur les 4000 il n'est nécessaire de reconstruire +que 10 fichiers HTML. A moins d'avoir vraiment besoin de tout reconstruire, +pour une raison technique ou parce que l'on a touché à quelque de chose de +commun à tout le site (un template par exemple), la question du temps de +génération de la totalité d'un si gros site est caduque. La variable +qui influe sur la vitesse de construction est dorénavant la quantité de +fichiers modifiés et non plus la quantité de fichiers au total. + +A noter que cet avantage n'est pas gratuit, les moteurs de production sont +souvent des logiciels assez complexes. L'alternative à priori plus légère et +maintenable à cmake et make serait +[mk](https://doc.cat-v.org/plan_9/4th_edition/papers/mk). + +Si les personnes impliquées dans les communautés des générateurs de site +statique avaient identifié des moteurs tels que make comme judicieux pour leurs +besoins alors le problème ne ce serait probablement jamais posé. + +Dans la pratique une configuration parmi d'autres qui permettrait d'itérer +rapidement serait d'avoir une fenêtre vim d'ouverte sur le fichier qui nous +intéresse et depuis le dossier dans lequel le makefile se trouve, et une autre +fenêtre avec l'aperçu du fichier html. Dans vim on met la configuration +"autowrite" (aw de son petit nom) à vraie en faisant `set aw` et lorsque l'on +veut vérifier nos modifs faire `:make!`. Suffit ensuite de rafraichir la page +dans le navigateur. + +> autowrite permet d'indiquer à vim que vous voulez qu'il enregistre les +> modifications apportées au lancement de tout un tas de commandes dont make. +> Voir `:help autowrite` pour plus d'infos. + +Un petit map pour n'avoir à appuyer sur qu'un seul bouton dans vim : + + map <F3>:set aw<CR>:make!<CR><CR> + +2. L'utilisation d'éditeurs de texte s'interfaçant bien avec le système permet + de tester des bouts de markdown. + +Toujours en partant du principe que le besoin principal est d'obtenir un +feedback rapide sur ce que l'on a écrit, un éditeur tel que vim permet d'y +répondre sans jamais toucher à la génération du site. + +Exemple, on a un doute sur la syntaxe des liens (personnellement j'inverse +souvent les () et les []), on écrit : + + (un lien)[http://katzele.netlib.re] + +On teste si ça fonctionne en se mettant sur la ligne et en le filtrant avec +lowdown - ou markdown ou pandoc ou... - en lançant `:.!lowdown` : + + <p>(un lien)[<a href="http://katzele.netlib.re">http://katzele.netlib.re</a>]</p> + +Ah oui non c'est pas ça + + [un lien](http://katzele.netlib.re) + <p><a href="http://katzele.netlib.re">un lien</a></p> + +mieux ! + +Si l'on veut tester plusieurs lignes on peut faire une sélection visuelle sur +plusieurs lignes ou remplacer `.` de la commande `:.!lowdown` par un autre range[^5]. + +On peut aussi écrire un heredoc et le filtrer avec sh. En faisant `vip` puis `:!sh` +(ce qui va écrire `:'<,'>!sh` dans la ligne de commande, les `'<>` étant les ranges +du début jusqu'à la fin de la sélection visuelle) : + + <<. lowdown + | Générateur | Temps (s) | + |---| + | Hugo | 1,6 | + | 11ty | 2 | + | Catium (sans sections) | 6 | + | Catium | 12 | + | Le reste | 20+ | + . + +et ça va donner + + <p>| Générateur | Temps (s) | + |—| + | Hugo | 1,6 | + | 11ty | 2 | + | Catium (sans sections) | 6 | + | Catium | 12 | + | Le reste | 20+ |</p> + +Ce n'est pas un tableau, réessayons en ajoutant un colonne ligne 2 : + + <<. lowdown + | Générateur | Temps (s) | + |---|---| + | Hugo | 1,6 | + | 11ty | 2 | + | Catium (sans sections) | 6 | + | Catium | 12 | + | Le reste | 20+ | + . + +et ça donne : + + <table> + <thead> + <tr> + <th>Générateur</th> + <th>Temps (s)</th> + </tr> + </thead> + + <tbody> + <tr> + <td>Hugo</td> + <td>1,6</td> + </tr> + <tr> + <td>11ty</td> + <td>2</td> + </tr> + <tr> + <td>Catium (sans sections)</td> + <td>6</td> + </tr> + <tr> + <td>Catium</td> + <td>12</td> + </tr> + <tr> + <td>Le reste</td> + <td>20+</td> + </tr> + </tbody> + </table> + +Sauf que c'est difficile de dire à l'oeil nu si c'est juste. On peut le piper +dans lynx et lui demander de dump le résultat dans vim pour voir ce que ça +donne : + + <<. lowdown | lynx -stdin --dump + | Générateur | Temps (s) | + |---|---| + | Hugo | 1,6 | + | 11ty | 2 | + | Catium (sans sections) | 6 | + | Catium | 12 | + | Le reste | 20+ | + . + + Générateur Temps (s) + Hugo 1,6 + 11ty 2 + Catium (sans sections) 6 + Catium 12 + Le reste 20+ + +Nickel. + +J'imagine qu'il y a pleins d'autres façons d'obtenir du feedback, que ce soit +avec vim ou d'autres outils. Vous pouvez écrire au collectif si vous voulez +les partager. Ou mieux encore, écrire sur la liste linux du lug. + +## Mot de la fin + +Le but de l'article est de mettre en lumière que pour une situation donnée des +cultures informatiques différentes peuvent mener à des lectures radicalement +différentes. Ce qui est un problème pour un groupe n'en est pas un pour un +autre. Ce qui doit donc être produit pour y remédier par le premier n'a pas à +l'être pour l'autre. Ce n'est pas sans conséquence. + +Problème ou pas, une autre façon de le voir serait de prendre le problème à +l'envers. Plutôt que d'estimer qu'un temps de construction "long" pour un gros +site est un problème d'optimisation logiciel, on pourrait estimer que lorsque +le temps de construction du site est perçu comme "long" c'est que le site est +trop gros. + +[^1]: Peut-être que ça a un gros impact qu'ils ne le soient pas d'ailleurs, je ne sais pas +[^2]: Nous utiliserons lowdown à partir d'ici +[^3]: Un seul puisque les fichiers markdown du benchmark n'ont pas de "section". Tout va donc au même endroit dans le layout et un seul fichier de section a besoin d'être créé +[^4]: moteur de production en bon français semble-t-il +[^5]: `.` est le range qui veut dire "la ligne sous le curseur". Voir `:help range` pour plus d'infos diff --git a/contents/benchmarkfrancium/index.sh b/contents/benchmarkfrancium/index.sh @@ -1,398 +0,0 @@ -#! page - -title: Benchmark de Francium -author: Arthur Pons -publication: 2023-03-11 -description: Quelques statistiques sur le site de Katzele -sectionmd: main - -# Benchmark et critique des performances de Francium - -## Le benchmark - -J'ai eu l'idée d'écrire cette note en entendant parler d'11ty, un générateur de -site statique. Il est écrit sur leur site - -> Fast Builds and even Faster Web Sites - -Et on trouve une petite animation qui présente qu'11ty construit 4000 -fichiers markdown en 2s, plus rapide que qu'Astro en 20 secondes, Gatbsy en 30 -secondes etc. Le site omet qu'Hugo est plus rapide mais soit. - -Ces résultats proviennent de [ce -benchmark](https://github.com/zachleat/bench-framework-markdown). - -Et Francium ? Testons d'abord les performances de cmark et lowdown, les deux -parseur de markdown qui nous utilisons. En prenant les 4000 fichiers markdown -du benchmark et en lançant les commandes : - - time find -name '*.md' | xargs -n1 -P0 sh -c 'lowdown "$1" > "$1".html' -- - xargs -n1 -P0 sh -c 'lowdown "$1" > "$1".html' -- 4,84s user 1,05s system 307% cpu **2,291** total - -et - - time find -name '*.md' | xargs -n1 -P0 sh -c 'cmark "$1" > "$1".html' -- - xargs -n1 -P0 sh -c 'lowdown "$1" > "$1".html' -- 4,84s user 1,05s system 307% cpu **1,914** total - -On tombe sur des temps d'environ deux secondes. Je trouvais surprenant que ces -deux logiciels, écrits en C et dont le seul but est de convertir du md en html -ne soient pas plus rapides qu'Hugo. Marc m'a rappelé que cette commande fait un -fork par fichier et les forks c'est "couteux". - -> Un fork c'est la création d'un nouveau processus par un autre. Nos commandes -> seront un processus qui, pour chaque fichier en créera un nouveau pour faire -> sa traduction. Créer un nouveau processus a un coût fixe. Il serait donc plus -> performant de créer un minimum de processus qui gèrent un maximum de fichiers -> chacun. - -En l'occurence cmark peut prendre plusieurs fichiers en argument, on peut donc -écrire - - time cmark *.md - cmark *.md 0,08s user 0,07s system 29% cpu 0,528 total - -ou pour lowdown tout concaténer - - time cat *.md | lowdown - lowdown 0,15s user 0,07s system 32% cpu 0,689 total - -Dans les deux cas on s'économise le fait de devoir créer 4000 fichiers mais pas -celui d'écrire les données pour les voir dans la console. D'ailleurs avec : - - time cmark *.md /dev/null - cmark *.md > /dev/null 0,08s user 0,07s system 29% cpu 0,093 total - -on voit que la majorité du temps est passé à écrire le résultat. - -J'identifie avec le code suivant - - for i in $(seq 1 4000) - do - echo $i > $i.txt - done - ./test 0,03s user 0,17s system 99% cpu 0,199 total - -que cela prend un peu moins de 0,2 secondes de créer 4000 fichiers presque -vides[^1] ce qui voudrait dire que l'on a la découpe approximative suivante : - -| opération | temps (s) | -|---|---| -|traiter les données|0,1| -|créer les fichiers|0,2| -|écrire les données|0,22| - -En réalité j'en sais rien, je connais pas assez bien linux pour savoir si je -mesure les choses comme il faut. Prenez tout ça avec des pincettes. - -Quoi qu'il en soit nous apprenons de ce test que Francium ne pourra pas aller -plus vite qu'environ une demie seconde pour 4000 fichiers. Pour en faire un -benchmark assez équivalent j'ai retiré tous les alias de page, sauf %S et -modifié les pages md du dépôt de benchmark pour qu'elles n'aient plus le - - --- - title: blablabla - --- - -et leur ajouter le shebang - - #! page - -et les rendre exécutables. - -> J'ai fait ça avec -> -> find -name '*.md' | xargs -n1 -P0 sed -i 's/^/#! page\n/;2,4d' -> chmod 755 ./* - -J'ai vérifié au préalable, le titre n'est pas pris en compte dans le benchmark. -Du moins l'HTML généré par Hugo et 11ty a une balise `<title>` vide. -Une fois que tout est prêt on construit le site comme on le fait habituellement -avec Francium[^2] (version qui utilise lowdown) : - - time make -B -j - make -B -j 30,29s user 8,31s system 302% cpu **12,741** total - -On est donc sur du six fois plus lent que la simple conversion en HTML depuis -lowdown. Tentons de comprendre pourquoi en bidouillant, faute de savoir comment -correctement diagnostiquer ce genre de choses. - -Retirer les shebang et modifier le makefile pour faire - - ./page machin.md - -ne change rien en terme de performance. - -Supprimer l'appel à `install` en faisant directement une redirection semble -économiser environ une seconde. - -Supprimer l'appel à page en demandant à makefile de directement utiliser -lowdown et en supprimant les heredoc `%S` (en gros ce qu'on a fait au début -mais avec l'overhead de make) fait tomber le temps d'exécution à 3,7 secondes. -C'est donc quelque part dans page que l'on perd de la performance. - -J'ai ensuite repris depuis le début en supprimant la gestion des sections. Cela -revient à s'économiser la création d'un dossier temporaire et d'un fichier -temporaire[^3] par article. Ne plus créer le fichier temporaire qu'il faut -ensuite relire pour insérer son contenu dans le layout fait gagner environ 2 -secondes, make ne prend plus qu'environ 9,5 secondes. Ne plus créer le dossier -temporaire fait gagner 3 secondes supplémentaires pour descendre à 6,5 secondes -environ. - -Il semblerait donc que notre façon de gérer le layout soit responsable de 3 -secondes d'overhead sur 4000 fichiers. Pour que la comparaison tienne à peu -près la route j'ai modifié le template pour qu'il soit identique à celui généré -par Hugo. Je m'arrête là dans l'exploration des performances de Francium. - -On en retient qu'à la louche et avec mes outils de diagnostiques très -approximatifs, ce qui coûte est : - -| Modification | Temps (s) | -|---|---| -| overhead make | 1,7 | -| la création du dossier temporaire | 2 | -| la création puis la lecture du fichier temporaire par section | 3 | -| l'appel à install | 1 | -| le template | 3 | - -Ce qui ajoutés bout à bout explique la différence entre les deux secondes de -lowdown et les 12/13 de Francium. - -Résultats finaux : - -| Générateur | Temps (s) | -|---|---| -| Hugo | 1,6 | -| 11ty | 2 | -| Francium (sans sections) | 6 | -| Francium | 12 | -| Le reste | 20+ | - -## Et alors ? - -Francium tel qu'il existe pour le site de Katzele est 6 fois plus lent que les -deux générateurs de sites statiques les plus rapides et plus rapide que tous les -autres. Dans une version allégée, pour un site avec une seule section que l'on -souhaite alimenter de contenu il n'est "que" trois fois plus lent. - -C'est significatif mais à mettre au regard du temps d'ingénieurie investit. Il -est probable que le temps passé à construire Francium dans son ensemble est un -ou deux ou trois ordres de grandeur inférieur au temps passé à rendre Hugo et -11ty performants. - -De plus la comparaison de performances de logiciels est compliquée et -hasardeuse. Déjà parce que cela dépend du matériel sur lequel les logiciels -sont testés. Ensuite parce que les couvertures fonctionnelles ne sont pas les -mêmes. Nous avons vu que l'intégration de fonctionnalités supplémentaires dans -Francium pouvait avoir un fort impact sur sa performance. Qu'en est-il des -autres outils ? Hugo et 11ty font *beaucoup* plus de choses que Francium mais -le benchmark leur fait générer un site aussi simple que gros. Au vu de leurs -performances, ils ne semblent pas ralentir quand leurs très nombreuses -fonctionnalités ne sont pas effectivement utilisées. Comment Hugo et 11ty -réagiraient-ils si l'on construisait des sites plus complexes ? Et Francium ? -En l'absence de réponse à ces questions les benchmarks ne veulent pas dire -grand chose. - -Cela dit, pourquoi est-ce que ces logiciels font la promotion de leurs -performances sur leurs pages d'accueil ? Au-delà d'une éventuelle volonté de -savoir qui a ~~la plus gro~~ le plus rapide, possibilité à ne pas sous-estimer, -on pourrait aller regarder du côté des générateurs historiques. On me racontait -que fut une époque nombre de générateurs de sites étaient particulièrement -"lents". Il fallait attendre possiblement plusieurs dizaines de secondes pour -faire la revu de ses modifications ce qui rendait l'itération lente et le -travail fastidieux. Pour résoudre ce souci il semblerait que les communautés -autour de ces outils aient opté pour de l'ingénierie logicielle supplémentaire -faisant appel à nos matériels informatiques modernes très puissants. "Cela -prend 30 secondes de reconstruire tout le site pour vérifier le rendu de -notre nouvelle page ? Optimisons le code pour que les opérations aillent plus -vite et fassent usage de toute la puissance des processeurs pour le faire -descendre à deux secondes". - -Ce qui est intéressant c'est qu'en puisant dans une autre culture informatique, -comme la notre par exemple, ce n'est pas une autre solution qui aurait été -choisie mais le problème qui n'aurait tout simplement existé - ou suffisamment -rarement pour que ça n'en soit pas un. - -Illustrons cette idée en trois points : - -1. Dans le monde Unix le système de "build"[^4] traditionnel permet de ne - reconstruire que le nécessaire. - -Le système utilisé pour compiler de nombreux programmes dans le monde Unix (et -sur lequel Francium se base), make, utilise un graph de dépendance pour savoir -ce qui doit être reconstruit et ce qui est encore à jour. Ainsi, si l'on -modifie 10 fichiers markdown sur les 4000 il n'est nécessaire de reconstruire -que 10 fichiers HTML. A moins d'avoir vraiment besoin de tout reconstruire, -pour une raison technique ou parce que l'on a touché à quelque de chose de -commun à tout le site (un template par exemple), la question du temps de -génération de la totalité d'un si gros site est caduque. La variable -qui influe sur la vitesse de construction est dorénavant la quantité de -fichiers modifiés et non plus la quantité de fichiers au total. - -A noter que cet avantage n'est pas gratuit, les moteurs de production sont -souvent des logiciels assez complexes. L'alternative à priori plus légère et -maintenable à cmake et make serait -[mk](https://doc.cat-v.org/plan_9/4th_edition/papers/mk). - -Si les personnes impliquées dans les communautés des générateurs de site -statique avaient identifié des moteurs tels que make comme judicieux pour leurs -besoins alors le problème ne ce serait probablement jamais posé. - -Dans la pratique une configuration parmi d'autres qui permettrait d'itérer -rapidement serait d'avoir une fenêtre vim d'ouverte sur le fichier qui nous -intéresse et depuis le dossier dans lequel le makefile se trouve, et une autre -fenêtre avec l'aperçu du fichier html. Dans vim on met la configuration -"autowrite" (aw de son petit nom) à vraie en faisant `set aw` et lorsque l'on -veut vérifier nos modifs faire `:make!`. Suffit ensuite de rafraichir la page -dans le navigateur. - -> autowrite permet d'indiquer à vim que vous voulez qu'il enregistre les -> modifications apportées au lancement de tout un tas de commandes dont make. -> Voir `:help autowrite` pour plus d'infos. - -Un petit map pour n'avoir à appuyer sur qu'un seul bouton dans vim : - - map <F3>:set aw<CR>:make!<CR><CR> - -2. L'utilisation d'éditeurs de texte s'interfaçant bien avec le système permet - de tester des bouts de markdown. - -Toujours en partant du principe que le besoin principal est d'obtenir un -feedback rapide sur ce que l'on a écrit, un éditeur tel que vim permet d'y -répondre sans jamais toucher à la génération du site. - -Exemple, on a un doute sur la syntaxe des liens (personnellement j'inverse -souvent les () et les []), on écrit : - - (un lien)[http://katzele.netlib.re] - -On teste si ça fonctionne en se mettant sur la ligne et en le filtrant avec -lowdown - ou markdown ou pandoc ou... - en lançant `:.!lowdown` : - - <p>(un lien)[<a href="http://katzele.netlib.re">http://katzele.netlib.re</a>]</p> - -Ah oui non c'est pas ça - - [un lien](http://katzele.netlib.re) - <p><a href="http://katzele.netlib.re">un lien</a></p> - -mieux ! - -Si l'on veut tester plusieurs lignes on peut faire une sélection visuelle sur -plusieurs lignes ou remplacer `.` de la commande `:.!lowdown` par un autre range[^5]. - -On peut aussi écrire un heredoc et le filtrer avec sh. En faisant `vip` puis `:!sh` -(ce qui va écrire `:'<,'>!sh` dans la ligne de commande, les `'<>` étant les ranges -du début jusqu'à la fin de la sélection visuelle) : - - <<. lowdown - | Générateur | Temps (s) | - |---| - | Hugo | 1,6 | - | 11ty | 2 | - | Francium (sans sections) | 6 | - | Francium | 12 | - | Le reste | 20+ | - . - -et ça va donner - - <p>| Générateur | Temps (s) | - |—| - | Hugo | 1,6 | - | 11ty | 2 | - | Francium (sans sections) | 6 | - | Francium | 12 | - | Le reste | 20+ |</p> - -Ce n'est pas un tableau, réessayons en ajoutant un colonne ligne 2 : - - <<. lowdown - | Générateur | Temps (s) | - |---|---| - | Hugo | 1,6 | - | 11ty | 2 | - | Francium (sans sections) | 6 | - | Francium | 12 | - | Le reste | 20+ | - . - -et ça donne : - - <table> - <thead> - <tr> - <th>Générateur</th> - <th>Temps (s)</th> - </tr> - </thead> - - <tbody> - <tr> - <td>Hugo</td> - <td>1,6</td> - </tr> - <tr> - <td>11ty</td> - <td>2</td> - </tr> - <tr> - <td>Francium (sans sections)</td> - <td>6</td> - </tr> - <tr> - <td>Francium</td> - <td>12</td> - </tr> - <tr> - <td>Le reste</td> - <td>20+</td> - </tr> - </tbody> - </table> - -Sauf que c'est difficile de dire à l'oeil nu si c'est juste. On peut le piper -dans lynx et lui demander de dump le résultat dans vim pour voir ce que ça -donne : - - <<. lowdown | lynx -stdin --dump - | Générateur | Temps (s) | - |---|---| - | Hugo | 1,6 | - | 11ty | 2 | - | Francium (sans sections) | 6 | - | Francium | 12 | - | Le reste | 20+ | - . - - Générateur Temps (s) - Hugo 1,6 - 11ty 2 - Francium (sans sections) 6 - Francium 12 - Le reste 20+ - -Nickel. - -J'imagine qu'il y a pleins d'autres façons d'obtenir du feedback, que ce soit -avec vim ou d'autres outils. Vous pouvez écrire au collectif si vous voulez -les partager. Ou mieux encore, écrire sur la liste linux du lug. - -## Mot de la fin - -Le but de l'article est de mettre en lumière que pour une situation donnée des -cultures informatiques différentes peuvent mener à des lectures radicalement -différentes. Ce qui est un problème pour un groupe n'en est pas un pour un -autre. Ce qui doit donc être produit pour y remédier par le premier n'a pas à -l'être pour l'autre. Ce n'est pas sans conséquence. - -Problème ou pas, une autre façon de le voir serait de prendre le problème à -l'envers. Plutôt que d'estimer qu'un temps de construction "long" pour un gros -site est un problème d'optimisation logiciel, on pourrait estimer que lorsque -le temps de construction du site est perçu comme "long" c'est que le site est -trop gros. - -[^1]: Peut-être que ça a un gros impact qu'ils ne le soient pas d'ailleurs, je ne sais pas -[^2]: Nous utiliserons lowdown à partir d'ici -[^3]: Un seul puisque les fichiers markdown du benchmark n'ont pas de "section". Tout va donc au même endroit dans le layout et un seul fichier de section a besoin d'être créé -[^4]: moteur de production en bon français semble-t-il -[^5]: `.` est le range qui veut dire "la ligne sous le curseur". Voir `:help range` pour plus d'infos diff --git a/contents/chronocatium/index.sh b/contents/chronocatium/index.sh @@ -0,0 +1,289 @@ +#! page + +title: Chronologie du code du site de Katzele +author: Arthur Pons +publication: 2023-01-13 +description: Une petite chronologie de l\'évolution du contenu du dépôt git contenant le site de Katzele +sectionmd: main + +# Une chronologie de l'évolution du code de Catium tel qu'utilisé par Katzele + +Je me suis demandé comment avait évolué la base de code du site, notamment sa +taille mise au regard des fonctionnalités ajoutées. Pour cela je suis allé +chercher la première ligne du message de chaque commit de ce dépôt ainsi que la +quantité de ligne de code ajoutée au dépôt. Ce qui compte comme du code est +soumis à interprétation. J'ai décidé de supprimer les commentaires par exemple. +J'inclus des choses telles que le template HTML et le CSS. Je devrais +probablement les exclure si je voulais m'intéresser spécifiquement à Catium +et non pas à ce site. Je n'inclus pas le code qui génère du markdown dans les +pages. Ces bouts de code peuvent être complexes, assez nombreux et doivent être +maintenus mais ne font pas vraiment partie de Catium. Pour info aujourd'hui +(13 janvier 2023) cela représente quatre lignes. + +Évolution du total nombre de lignes (sans commentaire, sans ligne vide, avec template +heredoc) par commit : + + 500 +--------------------------------------------------------------------+ + | | + 450 |- -| + | | + 400 |- AAAAAAAA -| + | | + 350 |- -| + | | + 300 |- -| + | AAAA | + 250 |- A AAAAA -| + | AAAAAAAAAAAAAAAAAAAAAAAAAAA | + 200 |- A -| + | AAAAAAAAAAAA | + 150 |- -| + | | + 100 |- AAA -| + | | + 50 |- -| + +--------------------------------------------------------------------+ + +Le premier saut représente l'ajout d'une css et d'un moteur pour en générer. +Le second l'ajout d'un système pour générer un flux atom, le troisième un autre +système de génération de flux, la chute qui suit est due à la supression du +premier. Ensuite quelques modification du template html font bouger les choses +et le dernier saut est l'ajout du css actuellement en production. + +Le détail en différence de nombre de ligne par commit : + +> +107 - first release\ +> 0 - ajout du lien "None of these are Unix"\ +> +1 - liste des notes depuis la page principale\ +> 0 - ajout d'une todo list\ +> 0 - ajout d'un lien dans notes ui\ +> 0 - liens vers bitreich et suckless\ +> 0 - correction proposée par tjay\ +> 0 - lien vers ecoinfo\ +> +63 - introduction des styles\ +> 0 - annecdotes sur l'ui\ +> 0 - retour vers le futur et autres ajouts\ +> 0 - ajout d'une section contact\ +> 0 - usage direct de save_md\ +> -1 - template layout: stylesheet optionnel avec $STYLE\ +> 0 - Correction de fautes, proposition de légères modifications du texte introductif\ +> 0 - création d'une section "nos activités"\ +> +1 - *make* it work\ +> 0 - Ajout d'une note concernant les interfaces alternatives à youtube.com Dépôt d'un patch permettant de modifier sfeed_curses\ +> 0 - Ajout du nom de ou des auteur·ices des notes sur la page d'accueil Est-ce que c'est utile ? Attention ! Casse si la note ne renseigne pas son auteurice\ +> 0 - Retrait de l'option --safe pour cmark La version de cmark packagée pour debian n'a pas cette option mais c'est bien le comportement par défaut Son ajout explicite ne fait dont qu'introduire un bug\ +> +3 - Modification du makefile pour permettre d'ajouter des fichiers annexes aux notes\ +> 0 - Ajout d'un patch pour pouvoir choisir l'ouverture audio/video dans sfeed_curses Modification en conséquence de l'article\ +> +3 - Modif du makefile pour générer les raw et commenter\ +> 0 - Modification de la page d'accueil\ +> 0 - Ajout des évènements passés et futurs à la page d'accueil\ +> 0 - Ajout des dates aux notes\ +> +16 - Ajout d'un script pour générer un flux rss/atom/sfeed correspondant aux notes\ +> +37 - ajout de bin/atomic: RFC\ +> -17 - Suppression de rss au profit d'atomic\ +> 0 - Relecture, ménage\ +> 0 - Modification de la TODO après discussions à la roue libres\ +> 0 - Modification d'Atomic, modification des markdown en fonction\ +> 0 - Ajout d'un dossier flux et du fichier pour 2022\ +> +3 - Modification de page et du script de la page d'accueil pour les notes\ +> 0 - Modification du makefile pour copier les sources md\ +> +3 - Modification d'atomic et du fichier des évènements\ +> +1 - Génération automatique des évènements passés et futurs dans la page d'accueil\ +> 0 - Documentation de la syntaxe des fichiers dans events\ +> +2 - Modification d'atomic pour utiliser les lieux et les ressources\ +> +1 - Flux rss pour les interventions, obstacle à la génération du flux des articles\ +> 0 - Ajout des dates de tous les évènements passés\ +> +2 - Ajout d'un champ fin d'intervention et affichage dans le flux rss\ +> 0 - Oups, oublié de renommer certains champs %D en %P\ +> 0 - Ajout d'un README\ +> 0 - Tri chronologique des évènements à venir (je crois)\ +> 0 - Progrès sur la documentation\ +> 0 - Modification du makefile\ +> 0 - La documentation avance\ +> 0 - Progrès sur la partie page du README\ +> 0 - Toujours plus de documentation dans le README\ +> 0 - Ajout des futurs évènements aux techdays 13\ +> 0 - Tri par ordre chronologique des évènements à venir\ +> 0 - Modification du patch sfeed_curses pour passer un arg à sfeed_plumber\ +> 0 - Ménage README\ +> 0 - Modification et ajout de ressources pour évènement eveille\ +> 0 - Transformer les dates des évènements à venir en format lisible par un humain\ +> 0 - Modification de l'article youtube\ +> 0 - ajout d'une note todo sur les conférences passées\ +> 0 - Ajout d'une meta donnée visible ou non L'ajout se fait avec un alias %V, l'absence %V indique que la note est en cours de rédaction Utilisation de deux grep pour filtrer les notes dans src/index.md @Note un filtre pour exclure %V serait surement une solution plus adaptée.\ +> 0 - Ajout d'une note sur des idées d'outils convivialiste pour le web Mise à jour de la note sur le design pour encourager l'ajout de commentaires et retours Respect de la structure avec notes/date/titre/index.md pour toutes les notes\ +> 0 - ajout d'un exemple de réseau internet alternatif\ +> 0 - Affichage dates des évènement passés et ajout des slides pour prez techdays 13\ +> 0 - Ajout de la vidéo de la conf avec Adrastia\ +> 0 - Modifications diverses page d'accueil\ +> 0 - On retire les articles déposés aux mauvais endroits\ +> 0 - Modif de la fonct de visibilité et modification des articles en fonction\ +> 0 - Intégration des nouveaux articles de Derek et de la gestion de la visibilité\ +> 0 - Ajout de références dans l'article premier pas hors du web\ +> +23 - Intégration de certaines des propositions de Derek pour le template html\ +> 0 - Ajout d'un article sur la gestion de playlists\ +> 0 - Progression sur l'article à propos des playlists\ +> 0 - Publication de l'article sur les playlists\ +> 0 - Modif du script des notes pour publier à la date annoncée et pas le lendemain\ +> 0 - Modification de la structure de la page d'accueil\ +> 0 - édition de la note sur le web\ +> 0 - On crédite comme il se doit qui de droit :)\ +> +3 - Modif d'atomic et du fichier des interventions pour obtenir un flux atom valide\ +> 0 - Ajout article Kun, sép "articles"/"notes" modif page d'accueil, archives events\ +> 0 - Début de prise de notes sur la convivialité\ +> 0 - Ajout d'un guide pour nouvelleaux\ +> 0 - Ajouts et modifications diverses du contenu\ +> +146 - proposition d'un premier style proche des TUI, les couleurs sont provisoires\ +> 0 - mise à jour des critères pour le design du site\ +> -3 - intégration du CSS de Derek\ +> 0 - header > head\ +> 0 - style.css comme dépendance de page\ +> 0 - virer 1 niveau d'arbo\ +> 0 - Ajout du lien de la vidéo pour une intervention aux techdays\ +> 0 - Ajout du transcript d'une conversation avec chatgpt\ +> 0 - Progrès sur la documentation de Catium\ +> 0 - Progression sur la doc de Catium\ +> 0 - Suppression du doc test laissé par Arthur\ +> 0 - Ajout d'une nouvelle note sur la chrono du code du site\ + +Quelques remarques me viennent à l'esprit en voyant ce résultat : + +Les commits qui ajoutent du code sont rares, 23 contre 72 + +Les ajouts sont généralement petits. Quand ils ne le sont pas le commit porte +sur le css du site ou l'ajout d'une grosse fonctionnalité (générer un flux +atom) + +Quand il y a des retraits ils sont très petits. D'ailleurs certaines parties du +site ne sont actuellement (13 janv. 2023) pas utilisées mais n'ont pour autant +pas été supprimées. Soit par oubli soit parce qu'elles pourront l'être à +nouveau à l'avenir. Ces fichiers représentent 132 lignes à l'écriture de cet +article, 53 pour shylus, un système de génération de css actuellement abandonné +au profit du css écrit à la main de Derek. 79 pour pug, un système de +templating html actuellement abandonné au profit un template écrit à la main. +Autant shylus ne serait peut-être jamais utilisé, autant pug devrait revenir +sur le devant de la scène. + +Une bonne partie non négligeable du code hors css est du templating (36 +lignes). + +Si l'on retire le code de ces deux systèmes le nombre de ligne de Catium +passe à 262. Moins 147 de CSS on tombe à 115, moins les 36 de templating on +tombe à 79. En somme il y a actuellement bien moins de 100 lignes de shell à +proprement parler qui fait réellement fonctionner Catium. Cela pose la +question de la nécessité du reste. Peut-être un ménage à venir. + +Les ajouts de fonctionnalités me semblent générer des quantités raisonnables de +code. Par exemple la copie de fichier "annexes" accompagnant les md de src vers +root et la copie des sources de src vers root n'a ajouté que six lignes dans le +makefile. Aujourd'hui cela permet d'héberger au côté de l'article youtube les +fichiers de patch d'sfeed_curses et d'avoir accès aux sources en modifiant le +`.html` en `.md` dans l'url. Autre exemple le commit avec le message "Modif de +la fonct de visibilité et modification des articles en fonction" intègre une +gestion du conditionnement de la visibilité d'un lien dans une page +"gratuitement" sur la base d'un alias qui existait déjà et en ajoutant un peu +de code dans la page où l'on souhaite afficher des liens et pas d'autre. + +Dans l'ensemble, si l'on considère l'évolution de Catium depuis septembre +2022 (date du premier commit) à aujourd'hui je pense que l'on peut dire que la +croissance de la base de code est maîtrisée. Avant tout parce qu'en quelques +mois la quantité de fonctionnalités supplémentaires n'est pas très élevée +(autant par manque de temps que par volonté de ne pas en ajouter), mais +également parce que la structure de cet outil permet de le faire à un coût +raisonnable. + +Les données du total des lignes de code par commit : + +> 107 - first release\ +> 107 - ajout du lien "None of these are Unix"\ +> 108 - liste des notes depuis la page principale\ +> 108 - ajout d'une todo list\ +> 108 - ajout d'un lien dans notes ui\ +> 108 - liens vers bitreich et suckless\ +> 108 - correction proposée par tjay\ +> 108 - lien vers ecoinfo\ +> 171 - introduction des styles\ +> 171 - annecdotes sur l'ui\ +> 171 - retour vers le futur et autres ajouts\ +> 171 - ajout d'une section contact\ +> 171 - usage direct de save_md\ +> 170 - template layout: stylesheet optionnel avec $STYLE\ +> 170 - Correction de fautes, proposition de légères modifications du texte introductif\ +> 170 - création d'une section "nos activités"\ +> 171 - *make* it work\ +> 171 - Ajout d'une note concernant les interfaces alternatives à youtube.com Dépôt d'un patch permettant de modifier sfeed_curses\ +> 171 - Ajout du nom de ou des auteur·ices des notes sur la page d'accueil Est-ce que c'est utile ? Attention ! Casse si la note ne renseigne pas son auteurice\ +> 171 - Retrait de l'option --safe pour cmark La version de cmark packagée pour debian n'a pas cette option mais c'est bien le comportement par défaut Son ajout explicite ne fait dont qu'introduire un bug\ +> 174 - Modification du makefile pour permettre d'ajouter des fichiers annexes aux notes\ +> 174 - Ajout d'un patch pour pouvoir choisir l'ouverture audio/video dans sfeed_curses Modification en conséquence de l'article\ +> 177 - Modif du makefile pour générer les raw et commenter\ +> 177 - Modification de la page d'accueil\ +> 177 - Ajout des évènements passés et futurs à la page d'accueil\ +> 177 - Ajout des dates aux notes\ +> 193 - Ajout d'un script pour générer un flux rss/atom/sfeed correspondant aux notes\ +> 230 - ajout de bin/atomic: RFC\ +> 213 - Suppression de rss au profit d'atomic\ +> 213 - Relecture, ménage\ +> 213 - Modification de la TODO après discussions à la roue libres\ +> 213 - Modification d'Atomic, modification des markdown en fonction\ +> 213 - Ajout d'un dossier flux et du fichier pour 2022\ +> 216 - Modification de page et du script de la page d'accueil pour les notes\ +> 216 - Modification du makefile pour copier les sources md\ +> 219 - Modification d'atomic et du fichier des évènements\ +> 220 - Génération automatique des évènements passés et futurs dans la page d'accueil\ +> 220 - Documentation de la syntaxe des fichiers dans events\ +> 222 - Modification d'atomic pour utiliser les lieux et les ressources\ +> 223 - Flux rss pour les interventions, obstacle à la génération du flux des articles\ +> 223 - Ajout des dates de tous les évènements passés\ +> 225 - Ajout d'un champ fin d'intervention et affichage dans le flux rss\ +> 225 - Oups, oublié de renommer certains champs %D en %P\ +> 225 - Ajout d'un README\ +> 225 - Tri chronologique des évènements à venir (je crois)\ +> 225 - Progrès sur la documentation\ +> 225 - Modification du makefile\ +> 225 - La documentation avance\ +> 225 - Progrès sur la partie page du README\ +> 225 - Toujours plus de documentation dans le README\ +> 225 - Ajout des futurs évènements aux techdays 13\ +> 225 - Tri par ordre chronologique des évènements à venir\ +> 225 - Modification du patch sfeed_curses pour passer un arg à sfeed_plumber\ +> 225 - Ménage README\ +> 225 - Modification et ajout de ressources pour évènement eveille\ +> 225 - Transformer les dates des évènements à venir en format lisible par un humain\ +> 225 - Modification de l'article youtube\ +> 225 - ajout d'une note todo sur les conférences passées\ +> 225 - Ajout d'une meta donnée visible ou non L'ajout se fait avec un alias %V, l'absence %V indique que la note est en cours de rédaction Utilisation de deux grep pour filtrer les notes dans src/index.md @Note un filtre pour exclure %V serait surement une solution plus adaptée.\ +> 225 - Ajout d'une note sur des idées d'outils convivialiste pour le web Mise à jour de la note sur le design pour encourager l'ajout de commentaires et retours Respect de la structure avec notes/date/titre/index.md pour toutes les notes\ +> 225 - ajout d'un exemple de réseau internet alternatif\ +> 225 - Affichage dates des évènement passés et ajout des slides pour prez techdays 13\ +> 225 - Ajout de la vidéo de la conf avec Adrastia\ +> 225 - Modifications diverses page d'accueil\ +> 225 - On retire les articles déposés aux mauvais endroits\ +> 225 - Modif de la fonct de visibilité et modification des articles en fonction\ +> 225 - Intégration des nouveaux articles de Derek et de la gestion de la visibilité\ +> 225 - Ajout de références dans l'article premier pas hors du web\ +> 248 - Intégration de certaines des propositions de Derek pour le template html\ +> 248 - Ajout d'un article sur la gestion de playlists\ +> 248 - Progression sur l'article à propos des playlists\ +> 248 - Publication de l'article sur les playlists\ +> 248 - Modif du script des notes pour publier à la date annoncée et pas le lendemain\ +> 248 - Modification de la structure de la page d'accueil\ +> 248 - édition de la note sur le web\ +> 248 - On crédite comme il se doit qui de droit :)\ +> 251 - Modif d'atomic et du fichier des interventions pour obtenir un flux atom valide\ +> 251 - Ajout article Kun, sép "articles"/"notes" modif page d'accueil, archives events\ +> 251 - Début de prise de notes sur la convivialité\ +> 251 - Ajout d'un guide pour nouvelleaux\ +> 251 - Ajouts et modifications diverses du contenu\ +> 397 - proposition d'un premier style proche des TUI, les couleurs sont provisoires\ +> 397 - mise à jour des critères pour le design du site\ +> 394 - intégration du CSS de Derek\ +> 394 - header > head\ +> 394 - style.css comme dépendance de page\ +> 394 - virer 1 niveau d'arbo\ +> 394 - Ajout du lien de la vidéo pour une intervention aux techdays\ +> 394 - Ajout du transcript d'une conversation avec chatgpt\ +> 394 - Progrès sur la documentation de Catium\ +> 394 - Progression sur la doc de Catium\ +> 394 - Suppression du doc test laissé par Arthur\ +> 394 - Ajout d'une nouvelle note sur la chrono du code du site\ diff --git a/contents/chronofrancium/index.sh b/contents/chronofrancium/index.sh @@ -1,289 +0,0 @@ -#! page - -title: Chronologie du code du site de Katzele -author: Arthur Pons -publication: 2023-01-13 -description: Une petite chronologie de l\'évolution du contenu du dépôt git contenant le site de Katzele -sectionmd: main - -# Une chronologie de l'évolution du code de Francium tel qu'utilisé par Katzele - -Je me suis demandé comment avait évolué la base de code du site, notamment sa -taille mise au regard des fonctionnalités ajoutées. Pour cela je suis allé -chercher la première ligne du message de chaque commit de ce dépôt ainsi que la -quantité de ligne de code ajoutée au dépôt. Ce qui compte comme du code est -soumis à interprétation. J'ai décidé de supprimer les commentaires par exemple. -J'inclus des choses telles que le template HTML et le CSS. Je devrais -probablement les exclure si je voulais m'intéresser spécifiquement à Francium -et non pas à ce site. Je n'inclus pas le code qui génère du markdown dans les -pages. Ces bouts de code peuvent être complexes, assez nombreux et doivent être -maintenus mais ne font pas vraiment partie de Francium. Pour info aujourd'hui -(13 janvier 2023) cela représente quatre lignes. - -Évolution du total nombre de lignes (sans commentaire, sans ligne vide, avec template -heredoc) par commit : - - 500 +--------------------------------------------------------------------+ - | | - 450 |- -| - | | - 400 |- AAAAAAAA -| - | | - 350 |- -| - | | - 300 |- -| - | AAAA | - 250 |- A AAAAA -| - | AAAAAAAAAAAAAAAAAAAAAAAAAAA | - 200 |- A -| - | AAAAAAAAAAAA | - 150 |- -| - | | - 100 |- AAA -| - | | - 50 |- -| - +--------------------------------------------------------------------+ - -Le premier saut représente l'ajout d'une css et d'un moteur pour en générer. -Le second l'ajout d'un système pour générer un flux atom, le troisième un autre -système de génération de flux, la chute qui suit est due à la supression du -premier. Ensuite quelques modification du template html font bouger les choses -et le dernier saut est l'ajout du css actuellement en production. - -Le détail en différence de nombre de ligne par commit : - -> +107 - first release\ -> 0 - ajout du lien "None of these are Unix"\ -> +1 - liste des notes depuis la page principale\ -> 0 - ajout d'une todo list\ -> 0 - ajout d'un lien dans notes ui\ -> 0 - liens vers bitreich et suckless\ -> 0 - correction proposée par tjay\ -> 0 - lien vers ecoinfo\ -> +63 - introduction des styles\ -> 0 - annecdotes sur l'ui\ -> 0 - retour vers le futur et autres ajouts\ -> 0 - ajout d'une section contact\ -> 0 - usage direct de save_md\ -> -1 - template layout: stylesheet optionnel avec $STYLE\ -> 0 - Correction de fautes, proposition de légères modifications du texte introductif\ -> 0 - création d'une section "nos activités"\ -> +1 - *make* it work\ -> 0 - Ajout d'une note concernant les interfaces alternatives à youtube.com Dépôt d'un patch permettant de modifier sfeed_curses\ -> 0 - Ajout du nom de ou des auteur·ices des notes sur la page d'accueil Est-ce que c'est utile ? Attention ! Casse si la note ne renseigne pas son auteurice\ -> 0 - Retrait de l'option --safe pour cmark La version de cmark packagée pour debian n'a pas cette option mais c'est bien le comportement par défaut Son ajout explicite ne fait dont qu'introduire un bug\ -> +3 - Modification du makefile pour permettre d'ajouter des fichiers annexes aux notes\ -> 0 - Ajout d'un patch pour pouvoir choisir l'ouverture audio/video dans sfeed_curses Modification en conséquence de l'article\ -> +3 - Modif du makefile pour générer les raw et commenter\ -> 0 - Modification de la page d'accueil\ -> 0 - Ajout des évènements passés et futurs à la page d'accueil\ -> 0 - Ajout des dates aux notes\ -> +16 - Ajout d'un script pour générer un flux rss/atom/sfeed correspondant aux notes\ -> +37 - ajout de bin/atomic: RFC\ -> -17 - Suppression de rss au profit d'atomic\ -> 0 - Relecture, ménage\ -> 0 - Modification de la TODO après discussions à la roue libres\ -> 0 - Modification d'Atomic, modification des markdown en fonction\ -> 0 - Ajout d'un dossier flux et du fichier pour 2022\ -> +3 - Modification de page et du script de la page d'accueil pour les notes\ -> 0 - Modification du makefile pour copier les sources md\ -> +3 - Modification d'atomic et du fichier des évènements\ -> +1 - Génération automatique des évènements passés et futurs dans la page d'accueil\ -> 0 - Documentation de la syntaxe des fichiers dans events\ -> +2 - Modification d'atomic pour utiliser les lieux et les ressources\ -> +1 - Flux rss pour les interventions, obstacle à la génération du flux des articles\ -> 0 - Ajout des dates de tous les évènements passés\ -> +2 - Ajout d'un champ fin d'intervention et affichage dans le flux rss\ -> 0 - Oups, oublié de renommer certains champs %D en %P\ -> 0 - Ajout d'un README\ -> 0 - Tri chronologique des évènements à venir (je crois)\ -> 0 - Progrès sur la documentation\ -> 0 - Modification du makefile\ -> 0 - La documentation avance\ -> 0 - Progrès sur la partie page du README\ -> 0 - Toujours plus de documentation dans le README\ -> 0 - Ajout des futurs évènements aux techdays 13\ -> 0 - Tri par ordre chronologique des évènements à venir\ -> 0 - Modification du patch sfeed_curses pour passer un arg à sfeed_plumber\ -> 0 - Ménage README\ -> 0 - Modification et ajout de ressources pour évènement eveille\ -> 0 - Transformer les dates des évènements à venir en format lisible par un humain\ -> 0 - Modification de l'article youtube\ -> 0 - ajout d'une note todo sur les conférences passées\ -> 0 - Ajout d'une meta donnée visible ou non L'ajout se fait avec un alias %V, l'absence %V indique que la note est en cours de rédaction Utilisation de deux grep pour filtrer les notes dans src/index.md @Note un filtre pour exclure %V serait surement une solution plus adaptée.\ -> 0 - Ajout d'une note sur des idées d'outils convivialiste pour le web Mise à jour de la note sur le design pour encourager l'ajout de commentaires et retours Respect de la structure avec notes/date/titre/index.md pour toutes les notes\ -> 0 - ajout d'un exemple de réseau internet alternatif\ -> 0 - Affichage dates des évènement passés et ajout des slides pour prez techdays 13\ -> 0 - Ajout de la vidéo de la conf avec Adrastia\ -> 0 - Modifications diverses page d'accueil\ -> 0 - On retire les articles déposés aux mauvais endroits\ -> 0 - Modif de la fonct de visibilité et modification des articles en fonction\ -> 0 - Intégration des nouveaux articles de Derek et de la gestion de la visibilité\ -> 0 - Ajout de références dans l'article premier pas hors du web\ -> +23 - Intégration de certaines des propositions de Derek pour le template html\ -> 0 - Ajout d'un article sur la gestion de playlists\ -> 0 - Progression sur l'article à propos des playlists\ -> 0 - Publication de l'article sur les playlists\ -> 0 - Modif du script des notes pour publier à la date annoncée et pas le lendemain\ -> 0 - Modification de la structure de la page d'accueil\ -> 0 - édition de la note sur le web\ -> 0 - On crédite comme il se doit qui de droit :)\ -> +3 - Modif d'atomic et du fichier des interventions pour obtenir un flux atom valide\ -> 0 - Ajout article Kun, sép "articles"/"notes" modif page d'accueil, archives events\ -> 0 - Début de prise de notes sur la convivialité\ -> 0 - Ajout d'un guide pour nouvelleaux\ -> 0 - Ajouts et modifications diverses du contenu\ -> +146 - proposition d'un premier style proche des TUI, les couleurs sont provisoires\ -> 0 - mise à jour des critères pour le design du site\ -> -3 - intégration du CSS de Derek\ -> 0 - header > head\ -> 0 - style.css comme dépendance de page\ -> 0 - virer 1 niveau d'arbo\ -> 0 - Ajout du lien de la vidéo pour une intervention aux techdays\ -> 0 - Ajout du transcript d'une conversation avec chatgpt\ -> 0 - Progrès sur la documentation de Francium\ -> 0 - Progression sur la doc de Francium\ -> 0 - Suppression du doc test laissé par Arthur\ -> 0 - Ajout d'une nouvelle note sur la chrono du code du site\ - -Quelques remarques me viennent à l'esprit en voyant ce résultat : - -Les commits qui ajoutent du code sont rares, 23 contre 72 - -Les ajouts sont généralement petits. Quand ils ne le sont pas le commit porte -sur le css du site ou l'ajout d'une grosse fonctionnalité (générer un flux -atom) - -Quand il y a des retraits ils sont très petits. D'ailleurs certaines parties du -site ne sont actuellement (13 janv. 2023) pas utilisées mais n'ont pour autant -pas été supprimées. Soit par oubli soit parce qu'elles pourront l'être à -nouveau à l'avenir. Ces fichiers représentent 132 lignes à l'écriture de cet -article, 53 pour shylus, un système de génération de css actuellement abandonné -au profit du css écrit à la main de Derek. 79 pour pug, un système de -templating html actuellement abandonné au profit un template écrit à la main. -Autant shylus ne serait peut-être jamais utilisé, autant pug devrait revenir -sur le devant de la scène. - -Une bonne partie non négligeable du code hors css est du templating (36 -lignes). - -Si l'on retire le code de ces deux systèmes le nombre de ligne de Francium -passe à 262. Moins 147 de CSS on tombe à 115, moins les 36 de templating on -tombe à 79. En somme il y a actuellement bien moins de 100 lignes de shell à -proprement parler qui fait réellement fonctionner Francium. Cela pose la -question de la nécessité du reste. Peut-être un ménage à venir. - -Les ajouts de fonctionnalités me semblent générer des quantités raisonnables de -code. Par exemple la copie de fichier "annexes" accompagnant les md de src vers -root et la copie des sources de src vers root n'a ajouté que six lignes dans le -makefile. Aujourd'hui cela permet d'héberger au côté de l'article youtube les -fichiers de patch d'sfeed_curses et d'avoir accès aux sources en modifiant le -`.html` en `.md` dans l'url. Autre exemple le commit avec le message "Modif de -la fonct de visibilité et modification des articles en fonction" intègre une -gestion du conditionnement de la visibilité d'un lien dans une page -"gratuitement" sur la base d'un alias qui existait déjà et en ajoutant un peu -de code dans la page où l'on souhaite afficher des liens et pas d'autre. - -Dans l'ensemble, si l'on considère l'évolution de Francium depuis septembre -2022 (date du premier commit) à aujourd'hui je pense que l'on peut dire que la -croissance de la base de code est maîtrisée. Avant tout parce qu'en quelques -mois la quantité de fonctionnalités supplémentaires n'est pas très élevée -(autant par manque de temps que par volonté de ne pas en ajouter), mais -également parce que la structure de cet outil permet de le faire à un coût -raisonnable. - -Les données du total des lignes de code par commit : - -> 107 - first release\ -> 107 - ajout du lien "None of these are Unix"\ -> 108 - liste des notes depuis la page principale\ -> 108 - ajout d'une todo list\ -> 108 - ajout d'un lien dans notes ui\ -> 108 - liens vers bitreich et suckless\ -> 108 - correction proposée par tjay\ -> 108 - lien vers ecoinfo\ -> 171 - introduction des styles\ -> 171 - annecdotes sur l'ui\ -> 171 - retour vers le futur et autres ajouts\ -> 171 - ajout d'une section contact\ -> 171 - usage direct de save_md\ -> 170 - template layout: stylesheet optionnel avec $STYLE\ -> 170 - Correction de fautes, proposition de légères modifications du texte introductif\ -> 170 - création d'une section "nos activités"\ -> 171 - *make* it work\ -> 171 - Ajout d'une note concernant les interfaces alternatives à youtube.com Dépôt d'un patch permettant de modifier sfeed_curses\ -> 171 - Ajout du nom de ou des auteur·ices des notes sur la page d'accueil Est-ce que c'est utile ? Attention ! Casse si la note ne renseigne pas son auteurice\ -> 171 - Retrait de l'option --safe pour cmark La version de cmark packagée pour debian n'a pas cette option mais c'est bien le comportement par défaut Son ajout explicite ne fait dont qu'introduire un bug\ -> 174 - Modification du makefile pour permettre d'ajouter des fichiers annexes aux notes\ -> 174 - Ajout d'un patch pour pouvoir choisir l'ouverture audio/video dans sfeed_curses Modification en conséquence de l'article\ -> 177 - Modif du makefile pour générer les raw et commenter\ -> 177 - Modification de la page d'accueil\ -> 177 - Ajout des évènements passés et futurs à la page d'accueil\ -> 177 - Ajout des dates aux notes\ -> 193 - Ajout d'un script pour générer un flux rss/atom/sfeed correspondant aux notes\ -> 230 - ajout de bin/atomic: RFC\ -> 213 - Suppression de rss au profit d'atomic\ -> 213 - Relecture, ménage\ -> 213 - Modification de la TODO après discussions à la roue libres\ -> 213 - Modification d'Atomic, modification des markdown en fonction\ -> 213 - Ajout d'un dossier flux et du fichier pour 2022\ -> 216 - Modification de page et du script de la page d'accueil pour les notes\ -> 216 - Modification du makefile pour copier les sources md\ -> 219 - Modification d'atomic et du fichier des évènements\ -> 220 - Génération automatique des évènements passés et futurs dans la page d'accueil\ -> 220 - Documentation de la syntaxe des fichiers dans events\ -> 222 - Modification d'atomic pour utiliser les lieux et les ressources\ -> 223 - Flux rss pour les interventions, obstacle à la génération du flux des articles\ -> 223 - Ajout des dates de tous les évènements passés\ -> 225 - Ajout d'un champ fin d'intervention et affichage dans le flux rss\ -> 225 - Oups, oublié de renommer certains champs %D en %P\ -> 225 - Ajout d'un README\ -> 225 - Tri chronologique des évènements à venir (je crois)\ -> 225 - Progrès sur la documentation\ -> 225 - Modification du makefile\ -> 225 - La documentation avance\ -> 225 - Progrès sur la partie page du README\ -> 225 - Toujours plus de documentation dans le README\ -> 225 - Ajout des futurs évènements aux techdays 13\ -> 225 - Tri par ordre chronologique des évènements à venir\ -> 225 - Modification du patch sfeed_curses pour passer un arg à sfeed_plumber\ -> 225 - Ménage README\ -> 225 - Modification et ajout de ressources pour évènement eveille\ -> 225 - Transformer les dates des évènements à venir en format lisible par un humain\ -> 225 - Modification de l'article youtube\ -> 225 - ajout d'une note todo sur les conférences passées\ -> 225 - Ajout d'une meta donnée visible ou non L'ajout se fait avec un alias %V, l'absence %V indique que la note est en cours de rédaction Utilisation de deux grep pour filtrer les notes dans src/index.md @Note un filtre pour exclure %V serait surement une solution plus adaptée.\ -> 225 - Ajout d'une note sur des idées d'outils convivialiste pour le web Mise à jour de la note sur le design pour encourager l'ajout de commentaires et retours Respect de la structure avec notes/date/titre/index.md pour toutes les notes\ -> 225 - ajout d'un exemple de réseau internet alternatif\ -> 225 - Affichage dates des évènement passés et ajout des slides pour prez techdays 13\ -> 225 - Ajout de la vidéo de la conf avec Adrastia\ -> 225 - Modifications diverses page d'accueil\ -> 225 - On retire les articles déposés aux mauvais endroits\ -> 225 - Modif de la fonct de visibilité et modification des articles en fonction\ -> 225 - Intégration des nouveaux articles de Derek et de la gestion de la visibilité\ -> 225 - Ajout de références dans l'article premier pas hors du web\ -> 248 - Intégration de certaines des propositions de Derek pour le template html\ -> 248 - Ajout d'un article sur la gestion de playlists\ -> 248 - Progression sur l'article à propos des playlists\ -> 248 - Publication de l'article sur les playlists\ -> 248 - Modif du script des notes pour publier à la date annoncée et pas le lendemain\ -> 248 - Modification de la structure de la page d'accueil\ -> 248 - édition de la note sur le web\ -> 248 - On crédite comme il se doit qui de droit :)\ -> 251 - Modif d'atomic et du fichier des interventions pour obtenir un flux atom valide\ -> 251 - Ajout article Kun, sép "articles"/"notes" modif page d'accueil, archives events\ -> 251 - Début de prise de notes sur la convivialité\ -> 251 - Ajout d'un guide pour nouvelleaux\ -> 251 - Ajouts et modifications diverses du contenu\ -> 397 - proposition d'un premier style proche des TUI, les couleurs sont provisoires\ -> 397 - mise à jour des critères pour le design du site\ -> 394 - intégration du CSS de Derek\ -> 394 - header > head\ -> 394 - style.css comme dépendance de page\ -> 394 - virer 1 niveau d'arbo\ -> 394 - Ajout du lien de la vidéo pour une intervention aux techdays\ -> 394 - Ajout du transcript d'une conversation avec chatgpt\ -> 394 - Progrès sur la documentation de Francium\ -> 394 - Progression sur la doc de Francium\ -> 394 - Suppression du doc test laissé par Arthur\ -> 394 - Ajout d'une nouvelle note sur la chrono du code du site\ diff --git a/contents/emoji/index.sh b/contents/emoji/index.sh @@ -61,7 +61,7 @@ quatrième on récupère les emojis et leurs descriptions. Ce script pourrait Quand il s'agit de choisir parmi une liste arbitraire d'éléments sur la base du contenu des lignes il est propice d'utiliser fzy. J'en parle dans l'[article -sur les extensions de francium](/extension-francium/index.html) et [celui sur +sur les extensions de catium](/extension-catium/index.html) et [celui sur la musique](/musique/index.html). Pour notre besoin cela pourrait ressembler à ça, avec `dbemoji` le fichier que l'on a créé avec le précédent script : diff --git a/contents/extension-catium/index.sh b/contents/extension-catium/index.sh @@ -0,0 +1,542 @@ +#! page + +title: Étendre Catium \: Quelques exemples pratiques +description: Regardons ce que cela coûte d\'étendre Catium à travers l\'implémentation de plusieurs besoins +author: Arthur Pons +publication: 2023-11-17 + +sectionmd: main + +Catium ne comporte pas beaucoup de fonctionnalités. La base de code est +petite et faite de façon à "avoir la main" au maximum d'endroits possibles via +la ligne de commande. L'idée sous-jacente est que cela permettrait d'étendre +facilement les fonctionnalités comme souhaité. Dans cet article tentons +d'implémenter plusieurs fonctionnalités pour vérifier ou infirmer cette +hypothèse. + +## Tags + +Beaucoup de générateur de sites statiques offrent la possibilité de tagger +certains articles. Cela permet de les regrouper par thème, de favoriser la +navigation et la découvrabilité du contenu. On retrouve souvent les tags +inscrits sur les articles, sur la page d'accueil et sur leur propres pages. +Tentons, en partant d'une version minimale de Catium, d'implémenter une telle +fonctionnalité. + +Il est à noter qu'il y aurait pleins de façons différentes de le faire, je +n'en documente ici qu'une seule[^1] ayant ses avantages et ses désavantages. + +### Tagger un article + +Admettons que nous avons des articles dans notre dossier `src/articles` : + + ./src/articles/article4.md + ./src/articles/article3.md + ./src/articles/article2.md + ./src/articles/article1.md + +Ces articles n'ont pour le moment qu'un seul type de "métadonnée", le titre du +document. Il est renseigné avec `title: titre du document` dans chacun des +fichiers. Pour ajouter des tags nous pourrions faire le choix de les ajouter +directement dans les fichiers, pour qu'ils se suffisent à eux même, en créant un +nouveau type de métadonnée `title:AGS`. Les valeurs pourraient être délimitées par +des virgules comme ceci : + + title:AGS musique,youtube,sobriété + +Et hop, nous avons taggué la page. La première chose qui devrait vous venir à +l'esprit est que si l'on bosse sur un gros site nous voulons probablement +réutiliser un tag déjà existant sans pour autant tous les avoir en tête. Pour +aider à la tâche[^2] on peut imaginer un script listant tous les tags : + +azdjazdazd + + grep -Ihrm1 "^title:AGS" src/* | + cut -d' ' -f2 | + tr ',' '\n' | sort -u + + +> Pour `grep`, `-I` empêche de scanner les fichiers binaires, `-h` permet de ne +> pas afficher les noms des fichiers même s'il y en a plusieurs, `-r` permet de +> faire une recherche récursive dans `src` et `-m1` de s'arrêter sur le premier +> résultat plutôt que de scanner les fichiers dans leur totalité. Techniquement +> il est possible d'ajouter le `title:AGS` après le contenu de l'article auquel cas +> si l'article parle lui même de `title:AGS` et le mentionne en tout début de ligne +> le script pourrait casser mais cela paraît très très peu probable. Le `cut` +> permet de se débarrasser du `title:AGS`, le `tr` d'avoir un tag par ligne et le +> `sort -u` de supprimer les doublons. + +Imaginons un autre script permettant de construire la ligne nécessaire dans les +documents en se basant sur un sélection de tags : + + paste -s -d',' | xargs printf "%title:AGS %s\n" + +> `paste -s` permet de "sérialiser" le collage. Autrement dit, avec une seule +> source de donnée (ici stdin), cela va coller toutes les lignes les une avec +> les autres. `-d` permet de choisir le délimiteur. Le `xargs printf` permet +> d'insérer le résultat dans une chaîne de caractère passée en premier argument +> de `printf`. En l'occurence faut bien échapper le `%` avec un autre. Le +> second argument du `printf` (c'est à dire note liste de tag) se placera là où +> on trouve le `%s`.' + +Avec ces deux scripts à notre portée, si l'on est en train d'éditer un document +on peut les exécuter dans vim et facilement le tagguer avec des tags dont on +saura qu'ils existent déjà exactement sous cette forme à travers le site. La +commande `:r!commande1` insérera quelque chose du type : + + data + musique + sobriété + youtube + +Là où le curseur se trouve. On peut ensuite supprimer les tags que l'on ne +souhaite pas. Finalement on sélectionne ce que l'on souhaite et on filtre avec +`commande2` pour obtenir : + + title:AGS data,youtube + +Si vous acceptez d'ajouter une petite dépendance à quelque chose comme `fzy` ou +`fzf` on peut même avoir une jolie interface pour sélectionner ses tags en +lançant : + + :r!commande1 | fzy -m | commande2 + +On sélectionne ses tags avec la tabulation, on appuie sur entrée et hop voilà. + +### L'afficher quelque part + +Si l'on tente de construire le site à ce stade on obtiendra comme quoi `title:AGS` n'est +pas une commande. Il faut déclarer l'alias et choisir quoi lui faire faire dans +le script qui gère ces pages. En plus du script de base `common` nous allons +créé un script `article` pour gérer notre cas particulier. Cela fait sens si l'on +ne tagguera que des articles. Pour la suite il faudra donc que chaque document que +l'on souhaite tagguer commence par `#! page` pour que cela soit pris en compte. +Dans `article` on appel `common` pour avoir les alias et fonctions communes à toutes +les pages et on spécifie le petit nouveau `title:AGS` avec : + + #! /bin/sh + + . ./common + + alias title:AGS="tags" + tags() tags="$*" + +Ici on décide d'instancier la variable `$tags` contenant la liste des tags mais +nous aurions pu faire n'importe quoi d'autre. Dorénavant nous avons deux choix +pour les afficher sur un article. Soit on créer un nouveau layout html dans +lequel on intègre les tags soit on les injecte dans le markdown juste avant qu'il +soit traduit en html. Chaque méthode à ses avantages et inconvénients. + +> L'ajouter au layout est peut-être un peu plus "propre" dans le sens que le +> code s'exécute une seule fois et pas à chaque appel de `save_md`. Cependant +> impossible d'insérer les tags au milieu du contenu markdown écrit à la main. + +Si l'on veut l'ajouter au layout on peut créer un nouveau layout en ajoutant par exemple : + + <meta name="keywords" content="$tags" /> + # Et plus loin + <div class="tags"> + <p>tags : $(echo "$tags" | tr ',' '\n' | sed 'p' | xargs printf "<a href='/tags/%s.html'>%s</a> - " | sed -z 's/ - $//')</p> + </div> + +> Dans `$tags` la liste des tags séprarés par des virgules. On les met tous sur +> une ligne différente avec `tr`, on les double avec `sed` puis on a à nouveau +> recours à la technique du `xargs` + `printf` pour générer les liens html. +> Finalement on retire le ` - ` qui traîne à la fin. Il a fallu doubler les +> lignes puisque que pour chaque tag on fait appel à son nom deux fois dans la +> commande `printf` qui créer le lien (voir les deux `%s`). Sachant que chaque +> `%s` "consomme" un argument, si l'on ne doublait pas les lignes on aurait des +> liens type `<a href='tags/1.html'>2</a>`. `sed 'p'` double les lignes parce +> que le comportement par défaut de `sed` est, après avoir exécuté toutes les +> commandes, d'imprimer ce qu'il a dans son "pattern space" (c'est à dire ce +> sur quoi il travail, généralement la ligne courante). La commande sed `p` +> imprime le pattern space. Cet appel à sed va donc, pour chaque ligne, +> l'imprimer puis, à la sortie du script pour la ligne courante, imprimer le +> pattern space. On se retrouvera donc avec un doublon de chaque ligne. + +et en appelant le nouveau layout dans `article` : + + . lib/htmltags + +Alternativement on peut surcharger le `save_md` de `common` pour insérer, par +exemple juste après le titre principal, la liste des tags : + + save_md() { + taglinks=$(echo "$tags" | tr ',' '\n' | sed 'p' | xargs printf "[%s](/tags/%s.html)\ - " | sed -z 's/ - $//') + cat | + sed -E " + /^# .+/ s+$+\ + \n\ + tags : $taglinks \n\ + \n\ + ------------\n\ + +" | + lowdown >> "$the/$1" + } + +> On met dans la variable `taglinks` la même chose que ce que l'on avait généré +> dans le layout mais version markdown. Ensuite on fait un coup de `sed` qui, +> pour toutes les lignes commençant le titre principal, ajoute juste après le +> bloc qui suit. Ce n'est pas super lisible mais j'ai tenté de faire de mon +> mieux en échappant les nouvelles lignes avec un `\` de façon à ce que ça +> ressemble au plus près à ce qui est réellement inséré dans le flux. + +Un petit coup de make et hop on devrait voir les tags affichés sur les articles. +J'ai à chaque fois créé des liens avec l'idée de créer ensuite des pages de tags. + +### Les pages des tags + +Chaque tags pourrait avoir sa page, listant les articles concernés. Cette partie +est la plus hasardeuse de mon exploration. Je ne la trouve pas satisfaisante et +je ne sais pas comment faire autrement. + +Il serait délicat de créer à la main chaque page, d'autant plus qu'elle n'a +pas vocation à contenir du contenu écrit par des humain·e·s. Je propose donc +d'avoir un script qui, basé sur les tags existant dans les articles, va créé +les sources des pages des tags. Au prochain make ces pages seront convertie +en html comme toutes les autres. Le script en question pourrait être : + + #! /bin/sh + + mkdir -p src/tags + for tag in $( grep -Ihrm1 "^title:AGS" src/* | cut -d' ' -f2 | tr ',' '\n' | sort -u) + do + + <<. cat > src/tags/$tag.md ; chmod +x src/tags/$tag.md + #! page + title: 'Tag $tag' + + sectionmd: main + # $tag + + Articles concernés : + % + + grep -lIrm1 '^title:AGS.*musique.*$' src/* | + xargs grep -Hm1 '^title: ' | + sed -E 's/([^:]*)[^ ]+ (.+)$/\2\n\1/' | + sed 's/^"//;s/"$//;s/^src//;s/md$/html/' | + xargs -d'\n' printf ' * [%s](%s)\n' | + save_md main + . + + done + +> On créé le dossier `tags`. On récupère la liste des tags (comme dans la +> commande1) et on boucle dessus avec une heredoc. Le heredoc contient le +> "template" du fichier permettant de générer la page des tags. On insère les +> noms des tags avec la variable `$tag` qui est celle récupérée par la boucle +> `for`. Le contenu du heredoc est mis dans le fichier `src/tags/...md` dont on +> modifie les droits d'exécution. Pour récupérer les articles concernés on fait +> un `grep` sur la présence du tag en cours dans les fichiers de `src` avec +> `-l` pour n'avoir que les noms des fichiers (pas besoin de la valeur des +> tags, juste de savoir qu'il y a celui qu'on veut), `-I`, `-r` et `-m1` sont +> expliqués plus tôt dans l'article. Pour chacun des fichiers ayant matchés il +> nous faut son titre, on fait donc un combo `xargs grep` sur la métadonnée du +> titre en prenant bien soin de mettre un `-H` pour que le nom du fichier +> apparaisse même s'il n'y a qu'un seul résultat. Un peu (pas mal) de `sed` +> pour arranger les résultat comment on le veut, encore un `xargs` + `printf` +> pour créer les liens au format makrdown et on sauve tout ça dans la section +> main. + +Le script fonctionne très bien, là où il ne m'offre pas satisfaction est +l'intégration avec le makefile. En effet, les pages de tags étant toutes générées +depuis le même script il n'est pas possible de créer des dépendances différentes. +Si l'une doit être modifiée elles devront toutes l'être. De toute façon, les tags +ne vivant que dans les articles eux même il ne serait de toute façon pas possible +de savoir quelle page de tag remettre à jour à la modif d'un article puisque l'on +ne sait pas *qu'est-ce* qui a été modifié dans l'article. Est-ce que c'était +les tags ? Si oui, qu'est-ce qui a été supprimé / ajouté ? Dans le doute, la seule +solution vaguement convenable serait de reconstruire ces pages à chaque +build du site. Ce n'est pas forcément très coûteux mais c'est un peu bête +d'utiliser `make` pour en arriver là. De plus, si l'on utilise la parallélisation +des règles avec `-j` il est possible que `make` ne reconstruise pas certaines pages +de tags s'il tente de déclencher ces règles *avant* que le script générant les +fichiers sources ait terminé. + +Peut-être qu'une solution serait de faire vivre les tags en dehors des articles, +avec un fichier `tags` listant les tags et vivant à côté de son article : + + src/articles/ + └── article1 + ├── index.html + └── tags + +Auquel cas il serait possible de créer des règles ayant du sens. Ce système à +le désavantage de devoir maintenir un lien entre les deux fichiers, que ce soit +à travers leurs emplacements dans l'arborescence, leurs noms, éventuellement +une entête dans le fichier `tags` etc. Ces liens semblent tous un peu plus +délicats à maintenir, migrer, porter, faire évoluer que celui d'avoir les tags +écrits à l'intérieur du document que l'on souhaite tagguer. + +Et si l'on veut maintenant voir tous les tags, mettons sur la page d'accueil ? + +### Aperçu général des tags + +Mettons que nous voulons voir la liste des tags avec le nombre d'articles +associés à côté. On peut ajouter le script suivant au fichier : + + grep -hrm1 "^title:AGS" src/* | + cut -d' ' -f2 | + tr ',' '\n' | + sort | uniq -c | + sed -E 's/^ *([0-9]+*) (.+)$/\2\n\2\n\1/' | + xargs printf " * [%s](/tags/%s.html) - %s articles\n" | + save_md main + +> Toujours la même chose pour récupérer les tags, mais au lieu de retirer les +> doublons on les compte avec `uniq -c`. Avec sed on réarrange le contenu de +> façon à avoir sur deux lignes le nom du tag et la troisième le nombre +> d'articles associés. Finalement un dernier combo `xargs` + `printf` pour +> créer la liste comme on veut et hop on enregistre. + +## Programmation de la publication + +Il y a plus d'un an de cela Derek voulait pousser un article en cours +d'écriture sur le dépôt git pour le partager avec nous sans pour autant qu'il +apparaisse sur la page d'accueil puisque non fini. Pour implémenter cela nous +avons choisi d'ajouter une date de publication dans les articles. + +### Ajout de la donnée + +Dans les articles, quelques chose sous la forme suivante pour publication le 13 juillet 2023 : + + publication: 2023-07-13 + +### Condition d'apparition en fonction de la date + +Le simple fait d'ajouter la donnée ne change rien mais on peut dorénavant +l'utiliser pour conditionner l'apparition des pages en fonction de cette date. +Par exemple, si l'on souhaite lister toutes les articles dans le dossier +`articles` : + + find src/articles/ -type f -name 'index.md' | + xargs grep -Hm3 '^title:\|^author:\|^publication:' | + paste - - - | + sed -Ee 's,src/(.*).md:title: "?([^"]*)"? src/.*.md:author: (.*) src/.*publication: (.*),* \4 - [\2](\1.html),'\ + -e 's,([0-9]{4})-([0-9]{2})-([0-9]{2}),\1/\2/\3,' | + sort -rn + +alors il suffit d'ajouter une commande `awk` faisant comparant les dates au +format `yyyy-mm-dd` quelque part dans le pipeline : + + find src/articles/ -type f -name 'index.md' | + xargs grep -Hm3 '^title:\|^author:\|^publication:' | + paste - - - | + awk -F'\t' -v now="publication: "$(date -I) '{if(substr($3,length($3)-12,13)<=now){print $0}}' | + sed -Ee 's,src/(.*).md:title: "?([^"]*)"? src/.*.md:author: (.*) src/.*publication: (.*),* \4 - [\2](\1.html),'\ + -e 's,([0-9]{4})-([0-9]{2})-([0-9]{2}),\1/\2/\3,' | + sort -rn + +pour ne voir apparaître que les articles dont la date de publication est +antérieur à aujourd'hui. Le tour est joué en une seule ligne de code. + +### Limitations + +Évidemment ce système permet uniquement de contrôler la présence +ou non d'un article quelque part dans une liste. Cela n'empêche +pas de pouvoir voir les sources dans le dépôt git si celui-ci +est publique ni de tomber totalement par hasard dessus si l'on +trouve l'url (très peu probable cependant). Pour empêcher ce +second scénario il faudrait implémenter quelque chose au niveau +de makefile. + +## Bilinguisme + +J'ai eu à implémenter un site en version bilingue anglais<->français récemment, +voilà comment j'ai fait. [Le dépôt du site en +question](https://gitlab.in2p3.fr/adele) et [son url](adele.helpdesk). + +L'idée est que les fichiers sources continennent dans leurs noms la langue de +destination. Je crois que d'autres systèmes fonctionnent comme ça. Par exemple +`contact.fr.sh` est la source de `contact.html` en français et `contact.en.sh` +la source de `contact.html` en anglais. + +Dans le makefile on récupère les fichiers sources et avec une petite commande +sed on créer le chemin de la cible en prenant compte de la langue + + sources != find contents -type f -name '*.sh' + html != echo "${sources}" | sed -E 's,contents/([^.]+)\.(en|fr)\.sh,public/\2/\1.html,g' + +Ainsi on a + +| sources | cibles | +|---|---| +| `contents/contact.fr.sh` | `public/fr/contact.html` | +| `contents/contact.en.sh` | `public/en/contact.html` | +| `contents/apropos.fr.sh` | `public/fr/apropos.html` | +| `contents/apropos.en.sh` | `public/en/apropos.html` | + +La commande sed est un peu moche et ne gère pas des langues arbitraires parce +que j'ai eu la flemme d'écrire une expression régulière généraliste. Sans un +système plus complexe il faudra toujours que la page s'appelle de la même +manière dans les deux langues. Pas de "about.html" en anglais donc. Au pire +cela empêche une personne qui parle anglais de deviner les noms des pages et de +trouver toute seule `site.com/en/about.html`. Si les urls des sites étaient +assez standardisée pourquoi pas mais en l'état ça ne me semble pas être un gros +problème. + +Il nous faut ensuite générer des liens sur les pages permettant de passer d'une +langue vers une autre. Pour cela il nous faut, lorsque l'on génère une version, +construire l'url de l'autre pour l'insérer dans la page. On peut modifier +`page` de la sorte : + + destination=$(echo "$@" | + sed -E 's,contents/([^.]+)\.(en|fr)\.sh,public/\2/\1.html,g' | + sed -E 's,^public,,') + echo "$@" | grep -q ".fr." && autre="en" || autre="fr" + destinationautre=$(echo "$destination" | sed "s,/../,/$autre/,") + +On reproduit le traitement du makefile pour connaître l'url de destination[^3], +on retire la partie `public` puis on met la langue opposée dans une variable +puis on construit le chemin vers l'article de l'autre version en fonction +de la langue récupérée. + +Dans le layout on ajoute là où l'on souhaite voir le lien apparaître : + + <a href="$destinationautre">$autre</a> + + +En l'état tout fonctionne bien sauf la page d'accueil servie par défaut, +généralement index.html. En effet avec notre système toutes les pages +html se retrouveront sous les dossiers fr ou en mais jamais à la racine. + +Pour contourner ce problème on peut à nouveau modifier le makefile de +façon à ce que le fichier `index.fr.sh` (ou `index.en.sh` en fonction +de la langue par défaut de votre site) génère à la fois `/fr/index.html` +et `/index.html` : + + + all: public/index.html ... + + public/index.html : contents/index.fr.sh page common + mkdir -p $(shell dirname $@) + $< > $@ + +On ajoute l'index.html de la racine dans les dépendances de la règle all puis +une règle personnalisée pour cette page qui ne dépend pas directement de son +clône dans le dossier source mais de index.fr.sh ou index.en.sh selon la langue +par défaut. + +Notre site intègre une gestion basique du bilinguisme ! Il ne reste plus qu'à +tout traduire ! + +## S'auto-référencer dans un article + +J'ai récemment entrepris la rédaction d'une [longue page se faisant fréquemment +référence à elle même](http://bebou.netlib.re/faq). Pour renvoyer vers une +autre page du site ou pire, renvoyer vers un titre spécifiquement, il faut faire +preuve d'une mémoire colossale et d'une implémentation mentale de l'algorithme +de génération des identifiants de titre de votre traducteur markdown -> html. + +J'ai donc entrepris de créer un script permettant de lister toutes les options +et d'en choisir une. Ce script a pour dépendance fzy pour l'interface de choix +et ne fonctionnera qu'après une première construction du site puisqu'il va +chercher les données dans l'html et non pas dans les sources. + +Il faut d'abord mettre dans une variable la totalité des éléments +ayant un attribut `id` et les titres de tous les articles[^4] : + + link=$(find public -type f -iname '*.html' | + xargs grep -Er '(<title>|id=")' | + cut -b7- | + fzy) + +find liste tous les fichiers html, xargs grep permet de chercher toutes les +lignes contenant `<title>` ou `id="` dans chacun de ces fichiers puis cut +supprime le nom du dossier public. Le format de sortie est comme ceci : + + /youtube/index.html: <title>Guide de survie en territoire youtubesque</title> + /youtube/index.html: <h2 id="pourquoi-">Pourquoi ?</h2> + /youtube/index.html: <h2 id="pour-les-smartphones">Pour les smartphones</h2> + +Ensuite, le traitement sera différent selon si notre sélection est un +identifiant vers lequel renvoyer ou le titre d'une page entière. Pour +tester cela on utilise des grep : + + if $(echo "$link" | grep -q 'id='); then + [...] + else $(echo "$link" | grep -q '<title>'); then + [...] + fi + +Si l'on veut faire un lien vers un titre en particulier page on choisit la ligne +contenant la balise titre correspondante et le traitement est comme suit : + + if $(echo "$link" | grep -q 'id='); then + echo "$link" | + sed -E 's,:.+id=",#,;s/index.html//' | + cut -d'"' -f1 + else $(echo "$link" | grep -q '<title>') + [...] + fi + +On remplace tout ce qui se trouve entre le chemin du fichier et la première +apostrophe par un `#`, on retire l'index.html (optionnel) et on ne +garde que ce qu'il y a à gauche de l'apostrophe restante. L'avant-après : + + /youtube/index.html: <h2 id="pour-les-smartphones">Pour les smartphones</h2> + /youtube/#pour-les-smartphones + +Si l'on veut faire un lien vers une page, on choisit la ligne qui contient +sa balise titre et le traitement sera le suivant : + + if $(echo "$link" | grep -q 'id='); then + [...] + else $(echo "$link" | grep -q '<title>'); then + echo "$link" | + cut -d':' -f1 | + sed 's/index.html//' + fi + +On ne garde que le chemin du fichier dans lequel on a trouvé la balise avec cut +et on supprime index.html (toujours optionnel). L'avant-après : + + /youtube/index.html: <title>Guide de survie en territoire youtubesque</title> + /youtube/ + +Le script final : + + link=$(find public -type f -iname '*.html' | + xargs grep -Er '(<title>|id=")' | + cut -b7- | + fzy) + + if $(echo "$link" | grep -q 'id='); then + echo "$link" | + sed -E 's,:.+id=",#,;s/index.html//' | + cut -d'"' -f1 + else $(echo "$link" | grep -q '<title>'); then + echo "$link" | + cut -d':' -f1 | + sed 's/index.html//' + fi + +Si on veut l'utiliser dans vim à la volée en mode insertion on peut +utiliser cette macro : + + inoremap <buffer> (-l <ESC>:r!./slug<CR>kgJEa + +En tapant rapidement sur `(-l` en mode insertion fzy s'ouvrira, on fait son +choix et hop on continue à écrire derrière le lien nouvellement inséré. + +## Conclusion + +J'espère avoir démontré qu'étendre Catium est raisonnablement facile pour une +personne sachant développer. Le résultat final et surtout la base nécessaire à +pouvoir permettre une telle implémentation me semble petite et gérable sur le +long terme. Le compte du nombre de lignes de code est délicat, est-ce que l'on +compte les parties "template", est-ce que chaque pipe compte comme une ligne, +chaque commande sed comme une autre ? En tout cas on peut remarquer qu'il est +possible de factoriser une quantité non négligeable du code écrit. +Pour les tags je dirais qu'il y a environ une trentaine de lignes importantes, +une dizaine pour le bilinguisme. Ce n'est pas négligeable, surtout quand on +considère la relative crypticité de certaines commandes mais **tout** est +devant vos yeux. La totalité de l'implémentation a été décrite ici. + +[^1]: du moins pour commencer, peut-être que j'en ferai d'autres à l'avenir +[^2]: et à condition d'utiliser vim mais vraiment essayez. Passez en atelier les mardi après-midi à l'atrium sur le campus de l'Unistra pour vous faire aider :) +[^3]: Peut-être qu'on pourrait le factoriser pour éviter d'avoir à le modifier à au moins deux endroits. +[^4]: J'ai choisi la balise `<title>` parce que c'est celle qui me permet le plus facilement d'identifier le contenu d'un article + + diff --git a/contents/extension-francium/index.sh b/contents/extension-francium/index.sh @@ -1,542 +0,0 @@ -#! page - -title: Étendre Francium \: Quelques exemples pratiques -description: Regardons ce que cela coûte d\'étendre Francium à travers l\'implémentation de plusieurs besoins -author: Arthur Pons -publication: 2023-11-17 - -sectionmd: main - -Francium ne comporte pas beaucoup de fonctionnalités. La base de code est -petite et faite de façon à "avoir la main" au maximum d'endroits possibles via -la ligne de commande. L'idée sous-jacente est que cela permettrait d'étendre -facilement les fonctionnalités comme souhaité. Dans cet article tentons -d'implémenter plusieurs fonctionnalités pour vérifier ou infirmer cette -hypothèse. - -## Tags - -Beaucoup de générateur de sites statiques offrent la possibilité de tagger -certains articles. Cela permet de les regrouper par thème, de favoriser la -navigation et la découvrabilité du contenu. On retrouve souvent les tags -inscrits sur les articles, sur la page d'accueil et sur leur propres pages. -Tentons, en partant d'une version minimale de Francium, d'implémenter une telle -fonctionnalité. - -Il est à noter qu'il y aurait pleins de façons différentes de le faire, je -n'en documente ici qu'une seule[^1] ayant ses avantages et ses désavantages. - -### Tagger un article - -Admettons que nous avons des articles dans notre dossier `src/articles` : - - ./src/articles/article4.md - ./src/articles/article3.md - ./src/articles/article2.md - ./src/articles/article1.md - -Ces articles n'ont pour le moment qu'un seul type de "métadonnée", le titre du -document. Il est renseigné avec `title: titre du document` dans chacun des -fichiers. Pour ajouter des tags nous pourrions faire le choix de les ajouter -directement dans les fichiers, pour qu'ils se suffisent à eux même, en créant un -nouveau type de métadonnée `title:AGS`. Les valeurs pourraient être délimitées par -des virgules comme ceci : - - title:AGS musique,youtube,sobriété - -Et hop, nous avons taggué la page. La première chose qui devrait vous venir à -l'esprit est que si l'on bosse sur un gros site nous voulons probablement -réutiliser un tag déjà existant sans pour autant tous les avoir en tête. Pour -aider à la tâche[^2] on peut imaginer un script listant tous les tags : - -azdjazdazd - - grep -Ihrm1 "^title:AGS" src/* | - cut -d' ' -f2 | - tr ',' '\n' | sort -u - - -> Pour `grep`, `-I` empêche de scanner les fichiers binaires, `-h` permet de ne -> pas afficher les noms des fichiers même s'il y en a plusieurs, `-r` permet de -> faire une recherche récursive dans `src` et `-m1` de s'arrêter sur le premier -> résultat plutôt que de scanner les fichiers dans leur totalité. Techniquement -> il est possible d'ajouter le `title:AGS` après le contenu de l'article auquel cas -> si l'article parle lui même de `title:AGS` et le mentionne en tout début de ligne -> le script pourrait casser mais cela paraît très très peu probable. Le `cut` -> permet de se débarrasser du `title:AGS`, le `tr` d'avoir un tag par ligne et le -> `sort -u` de supprimer les doublons. - -Imaginons un autre script permettant de construire la ligne nécessaire dans les -documents en se basant sur un sélection de tags : - - paste -s -d',' | xargs printf "%title:AGS %s\n" - -> `paste -s` permet de "sérialiser" le collage. Autrement dit, avec une seule -> source de donnée (ici stdin), cela va coller toutes les lignes les une avec -> les autres. `-d` permet de choisir le délimiteur. Le `xargs printf` permet -> d'insérer le résultat dans une chaîne de caractère passée en premier argument -> de `printf`. En l'occurence faut bien échapper le `%` avec un autre. Le -> second argument du `printf` (c'est à dire note liste de tag) se placera là où -> on trouve le `%s`.' - -Avec ces deux scripts à notre portée, si l'on est en train d'éditer un document -on peut les exécuter dans vim et facilement le tagguer avec des tags dont on -saura qu'ils existent déjà exactement sous cette forme à travers le site. La -commande `:r!commande1` insérera quelque chose du type : - - data - musique - sobriété - youtube - -Là où le curseur se trouve. On peut ensuite supprimer les tags que l'on ne -souhaite pas. Finalement on sélectionne ce que l'on souhaite et on filtre avec -`commande2` pour obtenir : - - title:AGS data,youtube - -Si vous acceptez d'ajouter une petite dépendance à quelque chose comme `fzy` ou -`fzf` on peut même avoir une jolie interface pour sélectionner ses tags en -lançant : - - :r!commande1 | fzy -m | commande2 - -On sélectionne ses tags avec la tabulation, on appuie sur entrée et hop voilà. - -### L'afficher quelque part - -Si l'on tente de construire le site à ce stade on obtiendra comme quoi `title:AGS` n'est -pas une commande. Il faut déclarer l'alias et choisir quoi lui faire faire dans -le script qui gère ces pages. En plus du script de base `common` nous allons -créé un script `article` pour gérer notre cas particulier. Cela fait sens si l'on -ne tagguera que des articles. Pour la suite il faudra donc que chaque document que -l'on souhaite tagguer commence par `#! page` pour que cela soit pris en compte. -Dans `article` on appel `common` pour avoir les alias et fonctions communes à toutes -les pages et on spécifie le petit nouveau `title:AGS` avec : - - #! /bin/sh - - . ./common - - alias title:AGS="tags" - tags() tags="$*" - -Ici on décide d'instancier la variable `$tags` contenant la liste des tags mais -nous aurions pu faire n'importe quoi d'autre. Dorénavant nous avons deux choix -pour les afficher sur un article. Soit on créer un nouveau layout html dans -lequel on intègre les tags soit on les injecte dans le markdown juste avant qu'il -soit traduit en html. Chaque méthode à ses avantages et inconvénients. - -> L'ajouter au layout est peut-être un peu plus "propre" dans le sens que le -> code s'exécute une seule fois et pas à chaque appel de `save_md`. Cependant -> impossible d'insérer les tags au milieu du contenu markdown écrit à la main. - -Si l'on veut l'ajouter au layout on peut créer un nouveau layout en ajoutant par exemple : - - <meta name="keywords" content="$tags" /> - # Et plus loin - <div class="tags"> - <p>tags : $(echo "$tags" | tr ',' '\n' | sed 'p' | xargs printf "<a href='/tags/%s.html'>%s</a> - " | sed -z 's/ - $//')</p> - </div> - -> Dans `$tags` la liste des tags séprarés par des virgules. On les met tous sur -> une ligne différente avec `tr`, on les double avec `sed` puis on a à nouveau -> recours à la technique du `xargs` + `printf` pour générer les liens html. -> Finalement on retire le ` - ` qui traîne à la fin. Il a fallu doubler les -> lignes puisque que pour chaque tag on fait appel à son nom deux fois dans la -> commande `printf` qui créer le lien (voir les deux `%s`). Sachant que chaque -> `%s` "consomme" un argument, si l'on ne doublait pas les lignes on aurait des -> liens type `<a href='tags/1.html'>2</a>`. `sed 'p'` double les lignes parce -> que le comportement par défaut de `sed` est, après avoir exécuté toutes les -> commandes, d'imprimer ce qu'il a dans son "pattern space" (c'est à dire ce -> sur quoi il travail, généralement la ligne courante). La commande sed `p` -> imprime le pattern space. Cet appel à sed va donc, pour chaque ligne, -> l'imprimer puis, à la sortie du script pour la ligne courante, imprimer le -> pattern space. On se retrouvera donc avec un doublon de chaque ligne. - -et en appelant le nouveau layout dans `article` : - - . lib/htmltags - -Alternativement on peut surcharger le `save_md` de `common` pour insérer, par -exemple juste après le titre principal, la liste des tags : - - save_md() { - taglinks=$(echo "$tags" | tr ',' '\n' | sed 'p' | xargs printf "[%s](/tags/%s.html)\ - " | sed -z 's/ - $//') - cat | - sed -E " - /^# .+/ s+$+\ - \n\ - tags : $taglinks \n\ - \n\ - ------------\n\ - +" | - lowdown >> "$the/$1" - } - -> On met dans la variable `taglinks` la même chose que ce que l'on avait généré -> dans le layout mais version markdown. Ensuite on fait un coup de `sed` qui, -> pour toutes les lignes commençant le titre principal, ajoute juste après le -> bloc qui suit. Ce n'est pas super lisible mais j'ai tenté de faire de mon -> mieux en échappant les nouvelles lignes avec un `\` de façon à ce que ça -> ressemble au plus près à ce qui est réellement inséré dans le flux. - -Un petit coup de make et hop on devrait voir les tags affichés sur les articles. -J'ai à chaque fois créé des liens avec l'idée de créer ensuite des pages de tags. - -### Les pages des tags - -Chaque tags pourrait avoir sa page, listant les articles concernés. Cette partie -est la plus hasardeuse de mon exploration. Je ne la trouve pas satisfaisante et -je ne sais pas comment faire autrement. - -Il serait délicat de créer à la main chaque page, d'autant plus qu'elle n'a -pas vocation à contenir du contenu écrit par des humain·e·s. Je propose donc -d'avoir un script qui, basé sur les tags existant dans les articles, va créé -les sources des pages des tags. Au prochain make ces pages seront convertie -en html comme toutes les autres. Le script en question pourrait être : - - #! /bin/sh - - mkdir -p src/tags - for tag in $( grep -Ihrm1 "^title:AGS" src/* | cut -d' ' -f2 | tr ',' '\n' | sort -u) - do - - <<. cat > src/tags/$tag.md ; chmod +x src/tags/$tag.md - #! page - title: 'Tag $tag' - - sectionmd: main - # $tag - - Articles concernés : - % - - grep -lIrm1 '^title:AGS.*musique.*$' src/* | - xargs grep -Hm1 '^title: ' | - sed -E 's/([^:]*)[^ ]+ (.+)$/\2\n\1/' | - sed 's/^"//;s/"$//;s/^src//;s/md$/html/' | - xargs -d'\n' printf ' * [%s](%s)\n' | - save_md main - . - - done - -> On créé le dossier `tags`. On récupère la liste des tags (comme dans la -> commande1) et on boucle dessus avec une heredoc. Le heredoc contient le -> "template" du fichier permettant de générer la page des tags. On insère les -> noms des tags avec la variable `$tag` qui est celle récupérée par la boucle -> `for`. Le contenu du heredoc est mis dans le fichier `src/tags/...md` dont on -> modifie les droits d'exécution. Pour récupérer les articles concernés on fait -> un `grep` sur la présence du tag en cours dans les fichiers de `src` avec -> `-l` pour n'avoir que les noms des fichiers (pas besoin de la valeur des -> tags, juste de savoir qu'il y a celui qu'on veut), `-I`, `-r` et `-m1` sont -> expliqués plus tôt dans l'article. Pour chacun des fichiers ayant matchés il -> nous faut son titre, on fait donc un combo `xargs grep` sur la métadonnée du -> titre en prenant bien soin de mettre un `-H` pour que le nom du fichier -> apparaisse même s'il n'y a qu'un seul résultat. Un peu (pas mal) de `sed` -> pour arranger les résultat comment on le veut, encore un `xargs` + `printf` -> pour créer les liens au format makrdown et on sauve tout ça dans la section -> main. - -Le script fonctionne très bien, là où il ne m'offre pas satisfaction est -l'intégration avec le makefile. En effet, les pages de tags étant toutes générées -depuis le même script il n'est pas possible de créer des dépendances différentes. -Si l'une doit être modifiée elles devront toutes l'être. De toute façon, les tags -ne vivant que dans les articles eux même il ne serait de toute façon pas possible -de savoir quelle page de tag remettre à jour à la modif d'un article puisque l'on -ne sait pas *qu'est-ce* qui a été modifié dans l'article. Est-ce que c'était -les tags ? Si oui, qu'est-ce qui a été supprimé / ajouté ? Dans le doute, la seule -solution vaguement convenable serait de reconstruire ces pages à chaque -build du site. Ce n'est pas forcément très coûteux mais c'est un peu bête -d'utiliser `make` pour en arriver là. De plus, si l'on utilise la parallélisation -des règles avec `-j` il est possible que `make` ne reconstruise pas certaines pages -de tags s'il tente de déclencher ces règles *avant* que le script générant les -fichiers sources ait terminé. - -Peut-être qu'une solution serait de faire vivre les tags en dehors des articles, -avec un fichier `tags` listant les tags et vivant à côté de son article : - - src/articles/ - └── article1 - ├── index.html - └── tags - -Auquel cas il serait possible de créer des règles ayant du sens. Ce système à -le désavantage de devoir maintenir un lien entre les deux fichiers, que ce soit -à travers leurs emplacements dans l'arborescence, leurs noms, éventuellement -une entête dans le fichier `tags` etc. Ces liens semblent tous un peu plus -délicats à maintenir, migrer, porter, faire évoluer que celui d'avoir les tags -écrits à l'intérieur du document que l'on souhaite tagguer. - -Et si l'on veut maintenant voir tous les tags, mettons sur la page d'accueil ? - -### Aperçu général des tags - -Mettons que nous voulons voir la liste des tags avec le nombre d'articles -associés à côté. On peut ajouter le script suivant au fichier : - - grep -hrm1 "^title:AGS" src/* | - cut -d' ' -f2 | - tr ',' '\n' | - sort | uniq -c | - sed -E 's/^ *([0-9]+*) (.+)$/\2\n\2\n\1/' | - xargs printf " * [%s](/tags/%s.html) - %s articles\n" | - save_md main - -> Toujours la même chose pour récupérer les tags, mais au lieu de retirer les -> doublons on les compte avec `uniq -c`. Avec sed on réarrange le contenu de -> façon à avoir sur deux lignes le nom du tag et la troisième le nombre -> d'articles associés. Finalement un dernier combo `xargs` + `printf` pour -> créer la liste comme on veut et hop on enregistre. - -## Programmation de la publication - -Il y a plus d'un an de cela Derek voulait pousser un article en cours -d'écriture sur le dépôt git pour le partager avec nous sans pour autant qu'il -apparaisse sur la page d'accueil puisque non fini. Pour implémenter cela nous -avons choisi d'ajouter une date de publication dans les articles. - -### Ajout de la donnée - -Dans les articles, quelques chose sous la forme suivante pour publication le 13 juillet 2023 : - - publication: 2023-07-13 - -### Condition d'apparition en fonction de la date - -Le simple fait d'ajouter la donnée ne change rien mais on peut dorénavant -l'utiliser pour conditionner l'apparition des pages en fonction de cette date. -Par exemple, si l'on souhaite lister toutes les articles dans le dossier -`articles` : - - find src/articles/ -type f -name 'index.md' | - xargs grep -Hm3 '^title:\|^author:\|^publication:' | - paste - - - | - sed -Ee 's,src/(.*).md:title: "?([^"]*)"? src/.*.md:author: (.*) src/.*publication: (.*),* \4 - [\2](\1.html),'\ - -e 's,([0-9]{4})-([0-9]{2})-([0-9]{2}),\1/\2/\3,' | - sort -rn - -alors il suffit d'ajouter une commande `awk` faisant comparant les dates au -format `yyyy-mm-dd` quelque part dans le pipeline : - - find src/articles/ -type f -name 'index.md' | - xargs grep -Hm3 '^title:\|^author:\|^publication:' | - paste - - - | - awk -F'\t' -v now="publication: "$(date -I) '{if(substr($3,length($3)-12,13)<=now){print $0}}' | - sed -Ee 's,src/(.*).md:title: "?([^"]*)"? src/.*.md:author: (.*) src/.*publication: (.*),* \4 - [\2](\1.html),'\ - -e 's,([0-9]{4})-([0-9]{2})-([0-9]{2}),\1/\2/\3,' | - sort -rn - -pour ne voir apparaître que les articles dont la date de publication est -antérieur à aujourd'hui. Le tour est joué en une seule ligne de code. - -### Limitations - -Évidemment ce système permet uniquement de contrôler la présence -ou non d'un article quelque part dans une liste. Cela n'empêche -pas de pouvoir voir les sources dans le dépôt git si celui-ci -est publique ni de tomber totalement par hasard dessus si l'on -trouve l'url (très peu probable cependant). Pour empêcher ce -second scénario il faudrait implémenter quelque chose au niveau -de makefile. - -## Bilinguisme - -J'ai eu à implémenter un site en version bilingue anglais<->français récemment, -voilà comment j'ai fait. [Le dépôt du site en -question](https://gitlab.in2p3.fr/adele) et [son url](adele.helpdesk). - -L'idée est que les fichiers sources continennent dans leurs noms la langue de -destination. Je crois que d'autres systèmes fonctionnent comme ça. Par exemple -`contact.fr.sh` est la source de `contact.html` en français et `contact.en.sh` -la source de `contact.html` en anglais. - -Dans le makefile on récupère les fichiers sources et avec une petite commande -sed on créer le chemin de la cible en prenant compte de la langue - - sources != find contents -type f -name '*.sh' - html != echo "${sources}" | sed -E 's,contents/([^.]+)\.(en|fr)\.sh,public/\2/\1.html,g' - -Ainsi on a - -| sources | cibles | -|---|---| -| `contents/contact.fr.sh` | `public/fr/contact.html` | -| `contents/contact.en.sh` | `public/en/contact.html` | -| `contents/apropos.fr.sh` | `public/fr/apropos.html` | -| `contents/apropos.en.sh` | `public/en/apropos.html` | - -La commande sed est un peu moche et ne gère pas des langues arbitraires parce -que j'ai eu la flemme d'écrire une expression régulière généraliste. Sans un -système plus complexe il faudra toujours que la page s'appelle de la même -manière dans les deux langues. Pas de "about.html" en anglais donc. Au pire -cela empêche une personne qui parle anglais de deviner les noms des pages et de -trouver toute seule `site.com/en/about.html`. Si les urls des sites étaient -assez standardisée pourquoi pas mais en l'état ça ne me semble pas être un gros -problème. - -Il nous faut ensuite générer des liens sur les pages permettant de passer d'une -langue vers une autre. Pour cela il nous faut, lorsque l'on génère une version, -construire l'url de l'autre pour l'insérer dans la page. On peut modifier -`page` de la sorte : - - destination=$(echo "$@" | - sed -E 's,contents/([^.]+)\.(en|fr)\.sh,public/\2/\1.html,g' | - sed -E 's,^public,,') - echo "$@" | grep -q ".fr." && autre="en" || autre="fr" - destinationautre=$(echo "$destination" | sed "s,/../,/$autre/,") - -On reproduit le traitement du makefile pour connaître l'url de destination[^3], -on retire la partie `public` puis on met la langue opposée dans une variable -puis on construit le chemin vers l'article de l'autre version en fonction -de la langue récupérée. - -Dans le layout on ajoute là où l'on souhaite voir le lien apparaître : - - <a href="$destinationautre">$autre</a> - - -En l'état tout fonctionne bien sauf la page d'accueil servie par défaut, -généralement index.html. En effet avec notre système toutes les pages -html se retrouveront sous les dossiers fr ou en mais jamais à la racine. - -Pour contourner ce problème on peut à nouveau modifier le makefile de -façon à ce que le fichier `index.fr.sh` (ou `index.en.sh` en fonction -de la langue par défaut de votre site) génère à la fois `/fr/index.html` -et `/index.html` : - - - all: public/index.html ... - - public/index.html : contents/index.fr.sh page common - mkdir -p $(shell dirname $@) - $< > $@ - -On ajoute l'index.html de la racine dans les dépendances de la règle all puis -une règle personnalisée pour cette page qui ne dépend pas directement de son -clône dans le dossier source mais de index.fr.sh ou index.en.sh selon la langue -par défaut. - -Notre site intègre une gestion basique du bilinguisme ! Il ne reste plus qu'à -tout traduire ! - -## S'auto-référencer dans un article - -J'ai récemment entrepris la rédaction d'une [longue page se faisant fréquemment -référence à elle même](http://bebou.netlib.re/faq). Pour renvoyer vers une -autre page du site ou pire, renvoyer vers un titre spécifiquement, il faut faire -preuve d'une mémoire colossale et d'une implémentation mentale de l'algorithme -de génération des identifiants de titre de votre traducteur markdown -> html. - -J'ai donc entrepris de créer un script permettant de lister toutes les options -et d'en choisir une. Ce script a pour dépendance fzy pour l'interface de choix -et ne fonctionnera qu'après une première construction du site puisqu'il va -chercher les données dans l'html et non pas dans les sources. - -Il faut d'abord mettre dans une variable la totalité des éléments -ayant un attribut `id` et les titres de tous les articles[^4] : - - link=$(find public -type f -iname '*.html' | - xargs grep -Er '(<title>|id=")' | - cut -b7- | - fzy) - -find liste tous les fichiers html, xargs grep permet de chercher toutes les -lignes contenant `<title>` ou `id="` dans chacun de ces fichiers puis cut -supprime le nom du dossier public. Le format de sortie est comme ceci : - - /youtube/index.html: <title>Guide de survie en territoire youtubesque</title> - /youtube/index.html: <h2 id="pourquoi-">Pourquoi ?</h2> - /youtube/index.html: <h2 id="pour-les-smartphones">Pour les smartphones</h2> - -Ensuite, le traitement sera différent selon si notre sélection est un -identifiant vers lequel renvoyer ou le titre d'une page entière. Pour -tester cela on utilise des grep : - - if $(echo "$link" | grep -q 'id='); then - [...] - else $(echo "$link" | grep -q '<title>'); then - [...] - fi - -Si l'on veut faire un lien vers un titre en particulier page on choisit la ligne -contenant la balise titre correspondante et le traitement est comme suit : - - if $(echo "$link" | grep -q 'id='); then - echo "$link" | - sed -E 's,:.+id=",#,;s/index.html//' | - cut -d'"' -f1 - else $(echo "$link" | grep -q '<title>') - [...] - fi - -On remplace tout ce qui se trouve entre le chemin du fichier et la première -apostrophe par un `#`, on retire l'index.html (optionnel) et on ne -garde que ce qu'il y a à gauche de l'apostrophe restante. L'avant-après : - - /youtube/index.html: <h2 id="pour-les-smartphones">Pour les smartphones</h2> - /youtube/#pour-les-smartphones - -Si l'on veut faire un lien vers une page, on choisit la ligne qui contient -sa balise titre et le traitement sera le suivant : - - if $(echo "$link" | grep -q 'id='); then - [...] - else $(echo "$link" | grep -q '<title>'); then - echo "$link" | - cut -d':' -f1 | - sed 's/index.html//' - fi - -On ne garde que le chemin du fichier dans lequel on a trouvé la balise avec cut -et on supprime index.html (toujours optionnel). L'avant-après : - - /youtube/index.html: <title>Guide de survie en territoire youtubesque</title> - /youtube/ - -Le script final : - - link=$(find public -type f -iname '*.html' | - xargs grep -Er '(<title>|id=")' | - cut -b7- | - fzy) - - if $(echo "$link" | grep -q 'id='); then - echo "$link" | - sed -E 's,:.+id=",#,;s/index.html//' | - cut -d'"' -f1 - else $(echo "$link" | grep -q '<title>'); then - echo "$link" | - cut -d':' -f1 | - sed 's/index.html//' - fi - -Si on veut l'utiliser dans vim à la volée en mode insertion on peut -utiliser cette macro : - - inoremap <buffer> (-l <ESC>:r!./slug<CR>kgJEa - -En tapant rapidement sur `(-l` en mode insertion fzy s'ouvrira, on fait son -choix et hop on continue à écrire derrière le lien nouvellement inséré. - -## Conclusion - -J'espère avoir démontré qu'étendre Francium est raisonnablement facile pour une -personne sachant développer. Le résultat final et surtout la base nécessaire à -pouvoir permettre une telle implémentation me semble petite et gérable sur le -long terme. Le compte du nombre de lignes de code est délicat, est-ce que l'on -compte les parties "template", est-ce que chaque pipe compte comme une ligne, -chaque commande sed comme une autre ? En tout cas on peut remarquer qu'il est -possible de factoriser une quantité non négligeable du code écrit. -Pour les tags je dirais qu'il y a environ une trentaine de lignes importantes, -une dizaine pour le bilinguisme. Ce n'est pas négligeable, surtout quand on -considère la relative crypticité de certaines commandes mais **tout** est -devant vos yeux. La totalité de l'implémentation a été décrite ici. - -[^1]: du moins pour commencer, peut-être que j'en ferai d'autres à l'avenir -[^2]: et à condition d'utiliser vim mais vraiment essayez. Passez en atelier les mardi après-midi à l'atrium sur le campus de l'Unistra pour vous faire aider :) -[^3]: Peut-être qu'on pourrait le factoriser pour éviter d'avoir à le modifier à au moins deux endroits. -[^4]: J'ai choisi la balise `<title>` parce que c'est celle qui me permet le plus facilement d'identifier le contenu d'un article - - diff --git a/contents/legal.sh b/contents/legal.sh @@ -32,6 +32,6 @@ Développement du site et du générateur : Marc Chantreux et moi\ CSS : [simple.css](https://simplecss.org/) - Kev Quirk\ Nom de domaine : [netlib](https://netlib.re) -Générateur du site : [Francium](https://git.unistra.fr/arthur.pons/francium) +Générateur du site : [Catium](https://git.unistra.fr/arthur.pons/catium) diff --git a/contents/liverepl/index.sh b/contents/liverepl/index.sh @@ -35,7 +35,7 @@ pour une quantité arbitraire de commandes et éditable dans vim. Au passage je découvre sans l'avoir prévu que ce système me permet de résoudre d'une manière bien plus puissante qu'auparavant un problème que j'avais documenté -dans ce [vieil article](/benchmarkfrancium/#et-alors-), section : +dans ce [vieil article](/benchmarkcatium/#et-alors-), section : "L’utilisation d’éditeurs de texte s’interfaçant bien avec le système permet de tester des bouts de markdown". En effet, si j'ouvre l'un des fichiers sources de ce site avec la configuration vim qui va suivre j'obtiens automatiquement le diff --git a/contents/portabilite/index.sh b/contents/portabilite/index.sh @@ -1,7 +1,7 @@ #! page -title: Rendre francium portable +title: Rendre catium portable author: Arthur Pons -description: Faisons des efforts pour rendre francium fonctionnel sur macos et les *bsd +description: Faisons des efforts pour rendre catium fonctionnel sur macos et les *bsd publication: 2024-01-12 sectionmd: main @@ -20,7 +20,7 @@ quatre raisons : 4. La croyance que puisque l'on fait du shell simple alors ce sera portable de toute façon En profitant d'une rare exception à la première raison, je propose de tester -les deux dernières raisons en portant Francium sur MacOs version 10.x et +les deux dernières raisons en portant Catium sur MacOs version 10.x et supérieure ainsi qu'OpenBSD 7.4. Merci à mon frère qui m'a prêté son mac pour faire des tests. @@ -28,9 +28,9 @@ Merci à mon frère qui m'a prêté son mac pour faire des tests. ## La demande [Timothée Goguely], designer et dev web basé à Strasbourg, souhaite tester -Francium pour la création d'un site pour l'un de ses clients soucieux de faire +Catium pour la création d'un site pour l'un de ses clients soucieux de faire très simple. Timothée utilise un mac, le client utilise un mac, il est donc -opportun de tester Francium sur un mac. +opportun de tester Catium sur un mac. Par la suite j'ai profité de la gentillesse de Victor Hoffner pour tester la version modifiée sur OpenBSD. @@ -43,7 +43,7 @@ Première chose à faire, cloner le projet. Mac vient avec git (en tout cas je n'ai pas eu à l'installer sur les deux macs que j'ai utilisé), il suffit donc de faire : - git clone git://katzele.netlib.re/francium + git clone git://katzele.netlib.re/catium En théorie, si tout fonctionne bien il suffit ensuite d'installer lowdown, de créer le dossier root dans lequel on génère le site et de lancer `make`. Pas @@ -173,7 +173,7 @@ fonctionner ailleurs". J'en retire qu'il faut être encore plus clair sur les dépendances. Par exemple ne pas dire "make" mais "GNU Make testé en version >4.3", ne pas dire "interpréteur shell POSIX" mais "Dash". Cela dit, nous avons testé et -Francium fonctionne avec zsh et ksh, pas bash. +Catium fonctionne avec zsh et ksh, pas bash. La totalité de ce travail, y compris la rédaction de cet article, aura pris quelque part entre 6h et 8h, ce que je trouve raisonnable. La quantité de code diff --git a/contents/services-sobres/index.sh b/contents/services-sobres/index.sh @@ -25,17 +25,17 @@ notamment de quoi [conjuguer](/conjugaison/), récupérer des [synonymes](/crisco-des/), faire une recherche youtube et certainement d'autres à l'avenir. Ces outils sont généralement des scripts shell de scraping assez simples, utilisés en local. -Ils se substituent généralement à des usages inadéquats de sites web ou de -recherches Google. Remplacer "ouvrir firefox -> taper 'conjugaison manger' -> +Ils se substituent à des usages inadéquats de sites web ou de +recherches Google. Remplacer *"ouvrir firefox -> taper 'conjugaison manger' -> cliquer sur le premier lien qui a pas l'air de vouloir me montrer mille popups de cookies ou de newsletters -> scroller à travers la page pour trouver la -ligne que je veux -> faire un copier-coller" par "ouvrir un terminal -> taper 'c -manger je présent' -> faire un copier-coller" ou tout autre utilisation +ligne que je veux -> faire un copier-coller"* par *"ouvrir un terminal -> taper 'c +manger je présent' -> faire un copier-coller"* ou tout autre utilisation davantage automatisée semblait opportun. On économise du temps, de la frustration, des aller-retour clavier/souris, du texte à taper, de la bande passante, des cycles cpu, de la ram et on s'offre en prime une meilleure interopérabilité avec le reste du système. Selon quelle est la source des -données du on se permet également de travailler en mode hors-ligne. +données on se permet également de travailler en mode hors-ligne. ### Qu'est-ce que "service" convoque comme images dans ma tête ? diff --git a/contents/sup-sonore/index.sh b/contents/sup-sonore/index.sh @@ -6,7 +6,10 @@ publication: 2024-06-11 sectionmd: main -Cet article n'a pas encore été relu, un peu d'indulgence svp :) +Je suis récemment tombé sur des projets similaires, je les liste ici : + + * Sonoriser les cookies : https://vimeo.com/502348796 + * Bip à chaque paquet envoyé à un tracker : https://berthub.eu/articles/posts/tracker-beeper/ ## But et outillage diff --git a/contents/tsv2anything/index.sh b/contents/tsv2anything/index.sh @@ -197,7 +197,7 @@ l'ordre du template. Il faut jeter un oeil aux données (et possiblement au prétraitement) pour se souvenir de quoi va où. Peut mieux faire en terme de maintenabilité. -### Variables shell + here-doc "à la francium" +### Variables shell + here-doc "à la catium" Si on instancie les variables shell diff --git a/layouts/html b/layouts/html @@ -26,7 +26,7 @@ $([ "$file" = "contents/index.sh" -o "$file" = "contents/legal.sh" ] || echo "~$ <footer> Contact : arthur.pons (a bizarre) unistra.fr<br> Code : <a href="http://git.bebou.netlib.re/arthur.bebou/log.html">http://git.bebou.netlib.re/arthur.bebou</a><br> -Généré avec un francium modifié pour faire un blog<br> +Généré avec un catium modifié pour faire un blog<br> <a href="/legal.html">Mentions légales</a> </footer> </html>