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...