Initial commit

content/interets/informatique/2023/04/06/previsualiser-des-eml-dans-gitea/index.md

@@ -0,0 +1,134 @@
+---
+date: '2023-04-06'
+title: Prévisualiser des .eml dans Gitea
+---
+
+## Contexte
+
+Voilà [un an et demi](/interets/informatique/2022/04/05/retour-d-experience-six-mois-de-stockage-dans-git/) que je stocke tout dans git, et j'en suis pleinement satisfait.
+
+L'une des rares choses que je n'y stockais pas jusqu'à maintenant sont certains emails que j'estime être d'un intérêt particulier.
+
+Mon objectif était de pouvoir exporter manuellement un ou plusieurs messages de mon choix (généralement, au moment où j'ai fini de les lire) dans un format plus ou moins standard, et les déposer dans ma forge logicielle via les commandes git classiques.
+
+Jusque là, aucun soucis : sous macOS, `Fichier` puis `Enregistrer`, `git commit` et `git push`, travail accompli.
+
+## Problématique
+
+Sauf que les emails sont encodés, ce qui signifie qu'ils ne sont pas directement lisibles par un humain.
+Un fichier eml est comme une archive contenant tout un tas d'informations, telles que les en-têtes, parfois un corps de message en texte-brut et un autre en HTML, sans compter les pièces jointes.
+Il faut donc faire appel à un outil spécialisé pour extraire ces informations, et les décoder correctement.
+
+Parce qu'avoir mes emails stockés dans git c'est bien, mais une fois qu'ils y sont, sans leur dépaquetage, sans leur décodage, ils sont difficilement exploitables, je veux surtout que Gitea m'en offre une version *human-friendly*.
+
+## Prérogatives
+
+- Je ne veux pas que le fichier d'origine soit altéré
+- Je veux pouvoir visualiser les en-têtes du message, y compris ce qui semble inutile aux humains
+- Je veux afficher la partie texte-brut du message en priorité, la partie HTML ne m'intéresse pas (sauf si c'est la seule qui existe)
+- Je veux que gitea m'affiche le fichier eml comme si j'étais dans un client mail, ou en tout cas que je puisse directement lire le mail sans devoir déchiffrer des séquences de caractères comme `=C3=A9` (qui encode le caractère `é`)
+- Je veux que le HTML produit soit propre ("markdownisé", en gros)
+- Je veux que la solution soit légère, au point de pouvoir le faire à la demande
+
+## Solutions
+
+### Overengineering
+
+La solution "évidente", c'est d'utiliser la CI pour faire une conversion lors d'un push.
+C'est *apparemment* la solution la plus simple, mais en fait, non :
+
+- je ne veux pas créer de fichiers additionnels pour des raisons de simplicité et d'espace disque
+- j'ai plusieurs dépôts en fonction des contextes des emails et non en fonction des boîtes de réception, et je n'ai pas envie de m'amuser à créer des jobs pour chacun d'entre eux dans ma CI
+
+### Gitea tout puissant
+
+Gitea offre une fonctionnalité toute puissante que j'utilise déjà pour permettre l'affichage direct de documents au format .docx : les [*external renderers*](https://docs.gitea.io/en-us/external-renderers/).
+Gitea permet de déclarer une commande qui prend en entrée le fichier en cours de prévisualisation et qui doit sortir le code HTML qui doit permettre sa prévisualisation.
+
+Dans le contexte particulier des .docx, c'est [pandoc](https://pandoc.org) qui fait ce travail, comme parfaitement expliqué [dans la documentation de gitea](https://docs.gitea.io/en-us/external-renderers/#example-office-docx) (un exemple qui fonctionne d'ailleurs *out-of-the-box*).
+
+C'est donc vers cette solution que je vais me tourner.
+
+## Résolution du problème
+
+Ça n'a pas été simple, vu que manifestement, comme d'habitude, personne n'a jamais fait ce que j'essaye de faire...
+
+Toutes mes recherches se sont soldées par des solutions à base de Java, de docker, et surtout, d'export en PDF, sans jamais mentionner l'intégration à gitea.
+Certaines évoquaient d'utiliser des outils avec interface graphique, des solutions où tu dois cliquer 12 000 fois pour avoir un fichier HTML exploitable, donc des solutions parfaitement impossibles à industrialiser.
+
+**Aucune des solutions que j'ai trouvé n'était simple à mettre en oeuvre**.
+Aucune des solutions que j'ai trouvé ne permet de prendre en entrée un flux standard et de sortir un flux standard, autrement dit en une ligne de commande utilisant les pipes (et `munpack` semble créer systématiquement des fichiers supplémentaires).
+
+Et puis, je suis tombé sur un container docker plus vieux que les autres, plus maintenu, et surtout, beaucoup plus léger que tout ce que j'ai vu jusqu'à maintenant.
+Dans ce container, un outil était mentionné, et un fichier de configuration était joint.
+Cet outil, c'est [Mhonarc](https://www.mhonarc.org).
+
+Il m'a fallut quelques secondes pour intégrer l'outil aux renderers de gitea.
+
+Le rendu n'est pas très propre, mais après avoir digéré une partie de la (grosse) doc de l'application, j'arrive au résultat escompté.
+
+La transformation de l'eml en HTML est presque parfaite, mais surtout, elle est quasi-instantanée.
+Cerise sur le gâteau, gitea m'offre un bouton pour basculer facilement et immédiatement du fichier source d'origine à sa prévisualisation en HTML.
+Voilà, c'est ça l'informatique que j'aime.
+
+### Configuration de mhonarc
+
+Les options par défaut de mhonarc sont assez satisfaisantes, mais je voulais aller un chouilla plus loin.
+Il suffit de créer un fichier de configuration qui va substituer les paramètres à ceux par défaut, donc il peut ne faire que quelques lignes et ne cassera pas l'ensemble de ce qui est généré.
+
+```xml
+<MIMEARGS>
+m2h_text_html::filter; allownoncidurls
+m2h_text_plain::filter; nonfixed fancyquote maxwidth=80
+</MIMEARGS>
+
+<MIMEAltPrefs>
+text/plain
+text/html
+</MIMEAltPrefs>
+
+<MIMEFilters>
+text/html;   m2h_text_plain::filter; mhtxtplain.pl
+text/x-html; m2h_text_plain::filter; mhtxtplain.pl
+</MIMEFilters>
+```
+
+Honnêtement, je n'ai pas encore tout compris à ce que j'ai fait ici, mais en gros, je demande à mhonarc d'utiliser en premier lieu la partie texte-brute en priorité par rapport à la partie en HTML du message d'origine, en tout cas s'il en contient une (c'est le bloc `MIMEAltPrefs`).
+
+Pour les messages qui ne contiennent qu'une partie en HTML, ce HTML est transformé pratiquement en texte-brut (le bloc `MIMEFilters`).
+
+Le texte brut obtenu est alors quelque peu formaté, avec un maximum de 80 caractères par ligne et l'utilisation de la balise `blockquote` pour les citations (c'est le bloc `MIMEARGS`).
+
+### Configuration de gitea
+
+Avec NixOS, c'est facile :
+
+```nix {linenos=false,class=not-prose}
+{
+  services.gitea = {
+    # [...]
+    settings = {
+      # [...]
+      "markup.eml" = {
+        ENABLED = true;
+        FILE_EXTENSIONS = ".eml";
+        RENDER_COMMAND = "/run/current-system/sw/bin/mhonarc -single -rcfile /etc/nixos/environment/etc/mhonarc";
+      };
+    };
+  };
+}
+```
+
+À noter que je sais que la spécification des chemins est sub-optimale mais je n'ai pas encore la maîtrise de nix nécessaire pour les éviter : ça fonctionne mais c'est une mauvaise pratique.
+Par exemple, je crois qu'il vaudrait mieux remplacer `/run/current-system/sw/bin/mhonarc` par `${pkgs.mhonarc}/bin/mhonarc` ou quelque chose du genre, mais je ne suis pas sûr de mon coup : je laisse le soin au lecteur de me corriger au cas où, et je mettrai cet article à jour en conséquence.
+
+### Avantages, inconvénients
+
+Ben déjà, ça juste marche, c'est hyper léger, ça s'intègre facilement à gitea.
+
+En revanche, j'ai des balises `<html><head></head></html>` qui traînent dans la sortie, et il y a certainement moyen de s'en débarasser mais je n'ai pas encore trouvé comment.
+Et puis j'aimerais "markdownifier" le corps du message.
+J'ai fait quelques essais pour piper pandoc mais je n'obtiens qu'une erreur 500 dans gitea.
+Enfin, j'aimerais adapter le CSS pour utiliser une fonte monospace pour le corps du message (mais ça devrait être facile à faire).
+
+Ce sont des améliorations futures mais pour l'heure, je suis satisfait.

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/0mQZdR.yaml

@@ -0,0 +1,2 @@
+file: images/0mQZdR.png
+title: Il est temps de changer

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/2MQuZh.yaml

@@ -0,0 +1,2 @@
+file: images/2MQuZh.png
+title: Mon site dans le navigateur links2. Ça va. Peut mieux faire.

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/2kCA23.yaml

@@ -0,0 +1,2 @@
+file: images/2kCA23.png
+title: Un article sans feuille de style

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/nrCkIz.yaml

@@ -0,0 +1,2 @@
+file: images/nrCkIz.png
+title: J'ai *un peu* merdé l'intégration du sprite...

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/tAd2tY.yaml

@@ -0,0 +1,2 @@
+file: images/tAd2tY.png
+title: '...et celle des articles non plus'

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/tIAVMD.yaml

@@ -0,0 +1,2 @@
+file: images/tIAVMD.png
+title: La liste de mes collectables n'est pas très engageante...

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/data/images/u5AZum.yaml

@@ -0,0 +1,2 @@
+file: images/u5AZum.png
+title: Mon site sans feuille de style. C'est de la merde.

content/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/index.md

@@ -0,0 +1,98 @@
+---
+date: '2023-04-08'
+title: 'Rant : Mon site, c''est de la merde'
+---
+
+Aujourd'hui, c'est tentative d'auto-critique honnête.
+Vous avez l'habitude de me lire râler sur tout, et bien aujourd'hui, je râle sur mon propre site.
+
+## Esthétique
+
+J'en peux plus de l'esthétique de ce site...
+Elle n'a pratiquement pas changé depuis qu'il est en ligne, et depuis le premier jour, je me dis que c'est de la merde, mais pas non plus trop repoussante.
+Juste assez esthétique pour être fonctionnelle, mais trop moche pour être personnelle.
+Cette esthétique, ce n'est pas moi, alors que c'est mon site.
+J'en peux plus.
+
+![0mQZdR](images/0mQZdR.png)
+
+Maintenant que j'arrive plus ou moins à faire des trucs relativement avancés avec [Hugo](https://gohugo.io/), je peux me focaliser sur l'identité visuelle de mon site.
+
+Bien que très gros fan de la fonte [Fantasque](https://fontlibrary.org/en/font/fantasque-sans-mono), et bien qu'ayant apprécié la possibilité de définir des fontes personnalisées en CSS, je commence à devenir partisan de l'arrêt de leur usage.
+Mais ce sujet reste conflictuel en mon for intérieur : mon site web doit posséder une identité visuelle qui me correspond, ce qui inclut les fontes utilisées, mais en même temps, quitte à utiliser une fonte qui n'est pas réellement la mienne, autant utiliser celles fournies par défaut par les systèmes, ce qui supprime la nécessité pour les clients d'en télécharger d'autres, donc amélioration de la compatibilité, délestage, etc.
+
+Le sujet est loin d'être nouveau, évidemment, mais je me rends compte de la difficulté d'équilibrer esthétisme, originalité, identité, accessibilité, etc, de se plier à des règles d'interopérabilité, de ne pas être trop en rupture avec l'existant, respecter les habitudes et les souhaits des utilisateurs, etc.
+
+![2MQuZh](images/2MQuZh.png)
+
+En vérité, à terme, je souhaite revenir à un principe que je m'étais fixé dès le départ mais que j'ai rapidement perdu de vue pour me focaliser sur d'autres choses : j'aimerais que mon site puisse être visité depuis un navigateur en mode console.
+Voyez cela comme un challenge personnel, plus que comme l'adhérence à une philosophie particulière, encore que...
+
+![u5AZum](images/u5AZum.png)
+
+Comme le montre la capture ci-dessus, au-delà de l'aspect purement esthétique du site gouverné par CSS, il y a aussi la base HTML qui n'est pas top.
+
+![2kCA23](images/2kCA23.png)
+
+Toujours ce sprite svg qui fout sa merde...
+Je sais, ce n'est pas tant le sprite que mon incapacité à l'intégrer correctement...
+
+Ce qui m'amène à questionner les performances de mon site.
+
+## Performances
+
+Je me suis rendu compte que je râlais sur le manque d'optimisation des ressources sur les sites web en général alors que mon propre site est moins optimisé que je le pensais.
+
+![nrCkIz](images/nrCkIz.png)
+
+1.79Mo à charger.
+Selon des critères modernes, ce n'est pas énorme.
+Sauf qu'à peu près 500Ko sont dûs à ce sprite chargé à de multiples reprises.
+Je pensais que le navigateur pallierait à ma fénéantise et mettrait le svg en cache, mais apparemment, ce n'est pas le cas.
+
+Les images (non svg) représentent environ 1Mo, sachant qu'il y en a 38 sur la page d'accueil.
+Là par contre je trouve que j'ai fait un bon travail d'optimisation (enfin, pour être exact, je n'ai rien fait pour entraver le travail d'optimisation d'Hugo).
+Il y aurait moyen de gagner quelques Ko (surtout en les dégageant mais je ne veux pas aller jusque là non plus !) mais bon à ce niveau, c'est peut-être des économies de bouts de chandelles, surtout que leur nombre ne va plus augmenter, en tout cas sur la page d'accueil.
+
+Par contre, si je veux rester sous 1Mo par page, images comprises, il va falloir que j'envisage la pagination dans les listes.
+
+Ce qui m'embête avec ces images, c'est le temps total de chargement de la page, visible en bas à droite (près de 500ms).
+Pour moi, c'est trop.
+Là, l'optimisation est à faire côté serveur web, il va falloir que je creuse le sujet.
+Peut-être l'occasion de tester l'introduction d'un serveur de cache ([Varnish](https://varnish-cache.org/)), ou de jouer avec les paramètres de [Caddy](https://caddyserver.com/), je ferai mes essais.
+
+Avec 15Ko, je trouve le CSS trop gros.
+Je pourrais faire des efforts d'optimisation de Tailwind, en particulier dans le domaine des couleurs, mais j'aimerais profiter de l'occasion pour explorer d'autres possibilités, surtout que Tailwind aussi, j'en ai ma claque...
+
+Je ne parle pas de javascript : il n'y en a pas, et il n'y en aura jamais.
+
+## Organisation
+
+Dans une mise à jour récente, j'ai décidé de mettre en avant les mots-clés dans les vignettes des articles.
+Mais je ne suis pas enthousiasmé : bien que cela offre un certain contexte aux titres un peu évasifs, je trouve que cela casse un peu la lecture en diagonale des listes.
+
+En sus, je trouve l'accès aux mots-clés assez pénible.
+La page les listant existe, mais le chemin pour y parvenir est fastidieux (article, cliquer sur mot-clé, cliquer sur le lien "Mots-clés").
+Le prochain design intègrera un lien direct vers la liste complète des mots-clés.
+J'aimerais d'ailleurs ajouter une vue avec les mots-clés triés par ordre d'occurrences.
+
+En outre, j'aimerais présenter les liens intéressants un peu différemment, en ajoutant un peu de profondeur.
+Je trouve qu'ils ne sont pas assez mis en avant, en particulier en ce qui concerne le webring.
+
+C'est un peu le bordel aussi dans mes [collections](/collections/).
+Toute cette section mériterait un remaniement dans sa présentation, maintenant que je commence à avoir un peu de contenu.
+
+![tIAVMD](images/tIAVMD.png)
+
+Comme dit précédemment, je pense qu'il va falloir que je mette en place une pagination pour les listes.
+Mais avant tout, je vais repenser l'affichage des éléments de ces listes.
+Maintenant que mon contenu s'étoffe, je trouve qu'il est de moins en moins agréable de naviguer.
+
+![tAd2tY](images/tAd2tY.png)
+
+## Conclusion
+
+Voilà qui annonce une grosse mise à jour prochaine.
+
+Tout cela vient du fait que j'ai complété ma migration depuis OVH, depuis que [je suis enfin passé à la fibre optique](/interets/informatique/2023/03/17/passage-a-la-fibre-optique/) (au passage, je remercie chaleureusement mes lecteurs qui ont particulièrement apprécié cet article et qui l'ont manifesté par différents moyens !).
+Je rappelle que du coup, puisque je rapatrie tout sur mon propre serveur, je suis dans une optique d'économie, aussi en relation avec mes prérogatives d'[éco-responsabilité](/interets/informatique/2021/09/25/l-eco-responsabilite-en-informatique/) : si déjà j'en parle, autant que je sois moi-même irréprochable à ce sujet...

content/interets/informatique/2023/04/18/refonte-du-site/data/images/LOdjJu.yaml

@@ -0,0 +1,2 @@
+file: images/LOdjJu.png
+title: Mon site, sans feuille de style

content/interets/informatique/2023/04/18/refonte-du-site/data/images/SVEA5r.yaml

@@ -0,0 +1,2 @@
+file: images/SVEA5r.png
+title: Mon site, dans links

content/interets/informatique/2023/04/18/refonte-du-site/data/images/gz89Oe.yaml

@@ -0,0 +1,2 @@
+file: images/gz89Oe.png
+title: Performances avant la refonte

content/interets/informatique/2023/04/18/refonte-du-site/data/images/kIlyRg.yaml

@@ -0,0 +1,2 @@
+file: images/kIlyRg.png
+title: Performances après la refonte

content/interets/informatique/2023/04/18/refonte-du-site/index.md

@@ -0,0 +1,153 @@
+---
+date: "2023-04-18"
+title: Refonte du site
+---
+
+Après avoir [critiqué mon blog](/interets/informatique/2023/04/06/rant-mon-site-c-est-de-la-merde/), j'ai retroussé mes manches, je suis - un peu - sorti de ma zone de confort en matière de développement front-end, et j'ai pondu une nouvelle interface, un peu plus personnalisée.
+
+Permettez-moi de vous faire un tour d'horizon.
+
+## Esthétique
+
+Les goûts et les couleurs, ça ne se discute pas.
+Mais je suis assez content du résultat pour aujourd'hui.
+
+### Menu principal
+
+Premier changement notable : les liens auparavant situés en haut et en bas de page sont désormais tous situés dans une barre toujours visible à gauche, et dotés de grosses icônes colorées.
+Le texte de ces liens disparaît en fonction de la taille de l'écran afin de maximiser l'espace de lecture.
+Dans le cas où la hauteur de l'écran serait insuffisante, il est possible de scroller verticalement.
+Afin d'avoir toujours accès au haut de page, j'ai inclus un lien spécial directement accessible sous le lien vers la page d'accueil.
+Avant, c'était un bouton en bas à droite.
+
+Tout peut se discuter, mais je pense que cette configuration offre plus de visibilité à certains éléments (notamment les mots-clés et le webring).
+En outre, ce que je gérais autrefois par un fichier de configuration se fait désormais tout seul (les liens vers les sections principales du site).
+
+Je trouve également intéressant sur le plan visuel de disposer de cette barre à gauche : sur les hautes résolutions, c'est un menu latéral on ne peut plus classique.
+Sur les écrans plus modestes (mobiles), c'est une barre de raccourcis qui n'empêche pas la lecture confortable du contenu des pages.
+
+### Sections principales
+
+Toutes les sections principales, y compris la page d'accueil, reposent désormais sur le même _template_.
+Sous le titre principal, une section de texte que je peux personnaliser, suivie du nombre d'articles présents dans cette section, puis d'une liste des pages liées.
+
+#### Pagination
+
+Comme prévu, j'ai fini par mettre en place la pagination que j'avais longtemps évité pour diverses raisons.
+On dispose donc de deux barres de navigation entre les pages, encadrant la liste des articles correspondants à la page en cours.
+On y trouve de part et d'autre un bouton pour aller à la page précédente, et un pour accéder à la page suivante.
+
+La disposition "traditionnelle" d'un paginateur fait consensus autour d'un groupe de page central, et à mesure qu'on s'en écarte, les pages en question s'éloignent du centre.
+
+Exemple : `[1] ... [6] [7] [8] [9] [10] ... [16]`, admettant que la page courante est la page 8.
+
+Comme je déteste faire comme tout le monde, et que j'ai eu 30 ans pour mûrir la question, j'estime que la meilleure façon de proposer une pagination est de virer ces liens et utiliser un menu déroulant.
+
+Dans l'exemple ci-dessus, si je veux accéder à la page 15, soit je clique 7 fois sur le bouton _Suivant_ (8 + 7 = 15), soit je clique sur la page 16, ce qui provoquera le déplacement du lien vers le milieu de l'écran.
+C'est très inconfortable, surtout pour les gens pressés qui savent exactement où ils doivent cliquer (ou plutôt, où ils _devraient_ cliquer).
+
+Avec un menu déroulant, le menu est toujours au même endroit, on peut accéder à n'importe quelle page depuis n'importe quelle page, avec un minimum de mouvements de la souris : il s'agit simplement de scroller, ce qui est infiniment plus pratique que courir après des numéros de page dont la position change à chaque changement de page...
+
+Je suis assez fier de mon menu déroulant.
+Si j'étais un peu plus souple sur la question du javascript, il m'aurait suffit de faire quelque chose du genre :
+
+```html
+<form method="GET" action="@{{ .URL }}">
+  <select name="page" onchange="form.submit()">
+    <!-- Reste du code -->
+  </select>
+</form>
+```
+
+Mais, considérant que je suis intraitable sur le javascript pour mon blog, cette méthode est bonne pour la poubelle : un navigateur qui désactive javascript serait incapable de choisir une page spécifique par ce moyen.
+
+Du coup, mon sélecteur de page n'utilise que ce bon vieux composant HTML [`details`](https://developer.mozilla.org/fr/docs/Web/HTML/Element/details), que j'utilise un peu partout tant il est versatile.
+Habilement maquillé par CSS, c'est un _dropdown_ on ne peut plus convainquant qui remplit parfaitement son office.
+On pourra toujours me critiquer que, contrairement à un composant en javascript, il est impossible de le fermer en cliquant ailleurs sur la page, ce à quoi je répondrai : "hérétique".
+
+### Listes
+
+Du coup, j'ai aussi changé la façon dont les articles sont présentés sous la forme de listes.
+J'ai décidé de limiter à dix articles par page.
+Je trouve qu'au-delà, ça devient trop chiant de scroller.
+Avec dix articles par page, le scroll est tolérable sur des résolutions modestes, et inexistant sur de plus hautes résolutions.
+
+Au lieu d'inclure les mots-clés à chaque article, j'ai préféré proposer un court résumé autogénéré par Hugo.
+Non, ce n'est pas de l'IA, c'est juste une troncature pas trop stupide.
+
+On verra que j'ai rajouté des liens directs vers la page originale et vers la _Wayback Machine_ sous chacun de mes liens intéressants pour un accès rapide, sans passer par la page intermédiaire où je rajoute parfois mes commentaires.
+
+### Articles
+
+Les pages présentant un article complet ont également été revues (comme tout le reste).
+
+Deux choses sont à noter en particulier : le sommaire, quand il existe, se présente juste sous le titre au lieu d'être intégré dans le corps de l'article, et le positionnement de l'image d'en-tête diffère selon sa forme.
+
+Pour le premier point, c'est encore le refus de javascript qui m'a challengé : une table des matières devrait être visible en permanence.
+Du coup, il faut lui réserver un espace conséquent et dont les dimensions ne peuvent pas toujours être prévues à l'avance.
+C'est d'autant plus problématique pour sa largeur, puisque sa hauteur peut toujours être restreinte sans pour autant nuire à son parcours (c'est exactement ce que j'ai fait pour le menu déroulant évoqué plus haut).
+
+En javascript, ça se fait assez simplement, et même, de différentes manières.
+
+Sans javascript aussi, mais aucune méthode ne me convenait vraiment : positionnement _absolute_, _static_, _fixed_, _float_, _flex_, non, décidément, tout cela prend trop de place, alors qu'une balise `details` fait parfaitement l'affaire.
+Je verrai ultérieurement si je peux fixer cette balise à un endroit peut-être plus approprié (genre dans la colonne de droite), mais pour l'heure, je me contenterai de ça.
+
+Concernant le deuxième point, cela concerne plus "l'arrière-boutique" d'Hugo.
+Avant, dans mes articles, je gérais différemment les images de couverture pour les livres et les films par exemple.
+La variable utilisée pour stocker l'image désirée était différente dans les deux cas.
+
+J'ai voulu uniformiser ça afin de faciliter la maintenance des articles.
+Du coup, je me base sur les dimensions de l'image pour choisir où la positionner : si l'image est en mode "portrait", elle ira dans la colonne de droite, sinon elle ira dans le corps de l'article.
+Simple, facile à faire.
+
+### Fontes
+
+J'ai décidé d'être un peu moins sage que d'habitude et surtout, de me laisser tenter par non pas une mais deux fontes custom.
+Je sais, c'est un peu à contre-courant de ce que j'ai dit dans mon article précédent, mais j'ai aussi mentionné que je n'étais pas encore décidé...
+
+On a donc une fonte que je qualifierai de plutôt mignonne pour les titres, tout en restant esthétique et lisible : il s'agit de [Jellee](https://fontlibrary.org/en/font/jellee-typeface).
+
+L'autre fonte est utilisée pour tout ce qui code et s'ajoute à la stack "_mono_" de Tailwind : c'est ma chère [Fantasque](https://fontlibrary.org/en/font/fantasque-sans-mono) que je n'ai pu me résoudre à abandonner...
+
+En outre, je me suis un peu laissé aller sur le choix des couleurs des titres et des liens...
+On verra plus tard si je décide que ça ne me convient pas ; pour l'heure, ces couleurs ne me mettent pas mal à l'aise et ne semblent pas être trop inaccessibles (visuellement).
+
+## Performances
+
+Gros, gros gain de performance.
+Juste avant de migrer vers la nouvelle interface, j'ai pris une capture des performances de chargement de l'ancienne, où je pointais déjà un temps de réponse de près de 500ms pour presque 2Mo de ressources transférées.
+
+![gz89Oe](images/gz89Oe.png)
+
+Roulement de tambour...
+
+![kIlyRg](images/kIlyRg.png)
+
+La nouvelle interface se charge en un peu plus de 215ms à froid et transfère 200ko de données seulement.
+Et pourtant : j'ai ajouté de nouvelles couleurs (au lieu d'en enlever), et deux fontes custom.
+La raison d'une telle cure d'amaigrissement tient bien évidemment à la réduction des images d'illustration sur la page d'accueil, et surtout, je n'utilise plus de sprite svg pour les icônes.
+Enfin, techniquement si, mais via les feuilles de style.
+
+Du coup, certes, la feuille de style a pris du poids (je me plaignais avant de ses 15ko, elle est passée à 16, c'est pas la mort non plus), mais mon site se trouve désormais être totalement apte à être navigué en mode console, et/ou sans feuille de style du tout :
+
+![LOdjJu](images/LOdjJu.png)
+
+![SVEA5r](images/SVEA5r.png)
+
+## Le mot de la fin
+
+["Peinture fraîche"](/interets/informatique/2021/01/01/introduction/#le-mot-de-la-fin-peinture-fraîche).
+Il y a peut-être des choses qui m'ont échappé, mais j'ai l'impression d'avoir fait le tour.
+C'était une refonte presque _from scratch_ parce que je voulais élaguer tout ce qui me semblait superflu.
+
+En outre, Hugo et Tailwind continuent de me les briser, et pourtant je ne suis captif que par crainte que le boulot soit encore plus difficile pour migrer vers la concurrence.
+
+Hugo est bourré d'absurdités, ou plus exactement, Go est bourré d'absurdités que Hugo tente désespérément de corriger, sans grand succès.
+Rien ne fait sens dans le templating de Go, c'est contre-intuitif, mal documenté, la grammaire et la syntaxe en général sont imbitables.
+Dès que tu veux faire un truc qui sort du cadre classique c'est la merde.
+Et puis Tailwind qui, pour des raisons que j'ignore, me pond un CSS de 130ko sur mon mac et de 16ko sur ma CI alors qu'on utilise **exactement** les mêmes commandes, les mêmes paramètres et les mêmes environnements de build...
+
+Bref, [je ne vais pas vous la refaire](/interets/informatique/2022/02/12/rant-hugo-et-tailwind/).
+
+Au final, allez-y : cliquez partout, perdez-vous dans le millier de pages approchant, et envoyez-moi vos insultes par email.
+Mais [envoyez-moi](/contact/) aussi vos félicitations, hein, je prends aussi...