Blog on Carnet de découvertes

De Jekyll à Hugo

Florent Jardin — Wed, 09 Dec 2020 00:00:00 +0000

Dans l’univers des générateurs de sites statiques, la bataille fait rage entre plusieurs frameworks depuis quelques années. Vous avez peut-être entendu parler de Jekyll, Next.js, Gastby ou Hugo ? Je ne cite que les plus sollicités par la communauté sur GitHub, mais il en existe des centaines.

Pourquoi cet engouement ? Cet article n’en parlera pas.

Pour de louables raisons, je m’étais engagé l’année dernière à auto-héberger mon nouvel espace d’expression personnel. J’y ai découvert avec intérêt et amusement de nombreuses technologies que j’ai pliées, réinstallées, transformées pour les adapter à mon besoin. Sans trop rentrer dans les détails, j’ai fini par avoir :

un serveur VPS chez OVH pour un coût de 3,99€ par mois
une routine mensuelle de renouvellement de certificat avec certbot
une instance Theia dans un conteneur Docker
une image Jekyll 4.1.0 que j’invoquais dans Docker
deux dépôts GitHub privés pour les articles (posts) et les brouillons (drafts)
le thème Poole, léger et modulable… que j’ai modulé

Alors que la question de conserver ou non le serveur VPS se pose pour la nouvelle année qui démarre bientôt (il devient agé, limité, pour ne pas dire sénil), j’ai remis récemment en cause mon attachement pour le framework Jekyll, si élégant à l’époque.

Le machin repose sur des dépendances Ruby. Aussi nombreuses (ou presque) qu’un nouveau projet en Node.js. J’ai mangé du Gemfile par le passé, aussi je n’ai eu aucune réelle difficulté à installer les quelques modules nécessaires à la concrétisation de mon projet. En voici le contenu :

source "https://rubygems.org"

gem "jekyll", "~> 4.1.0"
gem "classifier-reborn"

# If you have any plugins, put them here!
group :jekyll_plugins do
 gem "jekyll-paginate-v2"
 gem 'jekyll-target-blank', "~> 2.0"
 gem 'jekyll-time-to-read'
end

Et c’est tout.

Je n’avais besoin que de la pagination et de l’estimation du temps de lecture par article. Mine de rien, ça me semblait un peu grossier d’exiger que ces simples modules ne soient pas intégrés nativement. J’ai donc engagé mes recherches et le portage du présent site sur l’une des autres solutions, à savoir Hugo.

Migre moi ça, p’ti con

Et les développeurs de Hugo n’y sont pas allé de main morte pour asseoir leur logiciel dans ce paysage turbulent : ils intègrent un assistant de migration spécialement pour un projet Jekyll en récupérant ses fichiers .md et ses ressources statiques. En soit, la chose n’est pas complexe et le résultat est au rendez-vous. Mais…

$ hugo import jekyll blog blog_hugo
Importing...
Congratulations! 128 post(s) imported!
Now, start Hugo by yourself:
$ cd blog_hugo
$ git clone https://github.com/spf13/herring-cove.git themes/herring-cove
$ hugo server --theme=herring-cove

Bien sûr, l’assistant propose un thème pour embellir le projet en lieu et place d’une transposition du language Liquid sur lequel repose les fichiers modèles de Jekyll. C’est plus simple mais… ce n’est pas réellement ce que je souhaitais.

Autant le rendu des articles est impeccable avec ce thème, autant la navigation est assez pauvre à mon goût. Bien évidemment, c’est bien suffisant pour n’importe qui. Mais voilà. Mon thème principal me manquait et malheureusement pour moi, il n’existait pas pour Hugo.

De longues soirées d’hiver

J’aime les choses simples. Et j’aime encore plus les comprendre en profondeur. C’est pour cette raison que je me suis lancé plusieurs heures dans la lecture assidue de la documentation très riche sur gohugo.io. Les concepts sont assez différents et le passage n’a pas été si évident que cela. Je vous propose un florilège des astuces qu’il m’a fallu découvrir pour proposer le portage intégral de mon site.

Les permaliens

Jekyll et Hugo proposent une gestion fine des URL à l’aide du paramètre permalinks pour reconstruire l’adresse d’une page ou d’un article et favoriser son référencement. Cependant, leur paramètrage par défaut diffère et il est nécessaire de retrouver le comportement de l’un avec l’autre.

permalinks:
 posts: /:year/:month/:day/:slug

Pour ma part, j’ai privilégié le dérivé :slug pour être en mesure de surcharger la dernière portion de l’URL dans les rares cas où le titre était malformé entre Jekyll et Hugo. Par exemple pour mon article « Tour d’horizon de PgBouncer » où l’apostrophe n’était pas remplacée par le tiret et où je ne voulais pas perdre le référencement, j’ai pu contourner le problème avec l’ajout d’une simple ligne en en-tête du fichier Markdown.

---
title: "Tour d'horizon de PgBouncer"
slug: tour-d-horizon-de-pgbouncer
---

Il m’a également fallu découvrir un paramètre particulier pour ne pas prendre en compte les accents présents dans les titres lors de la génération du slug.

removePathAccents: true

Syndication automatique du contenu

Pour le coup, j’ai bénéficié d’une simplification dans mon projet grâce au support natif et avancé des flux RSS. Alors qu’avec Jekyll, je devais maintenir mes fichiers feed.xml et atom.xml à la racine du projet, j’ai découvert avec Hugo la notion de taxonomie qui permet la classification des articles. La taxonomie regroupe autant les sections, les catégories et les tags, et je trouve ça astucieux.

Imaginons une arborescence très simple avec une page et un article :

content/
├── pages
│   └── a-propos.md
└── posts
 └── 2020-11-18-quelques-outils-meconnus.md

Sans configuration supplémentaire, Hugo générera le contenu statique pour chacun des éléments du projet, en consultant notamment les en-têtes pour extraire les informations categories et tags des articles.

La magie opère avec un ensemble de fichiers index.xml regroupant les éléments d’une même taxonomie.

public/
├── 2020
│   └── 11
│   └── 18
│   └── quelques-outils-meconnus
│   └── index.html
├── categories
│   ├── index.html
│   ├── index.xml
│   └── postgresql
│   ├── index.html
│   └── index.xml
├── index.html
├── index.xml
├── pages
│   ├── a-propos
│   │   └── index.html
│   ├── index.html
│   └── index.xml
└── tags
 └── administration
    ├── index.html
    └── index.xml

La colorisation syntaxique

À ce sujet, j’ai eu une petite surprise avec les balises HTML jusqu’à ce que je me penche sur la documentation. En effet, par défaut, Hugo transforme un bloc de code Markdown en série de balises stylisées.

<div class="highlight">
<pre style="color:#f8f8f2;background-color:#272822;
 -moz-tab-size:4;-o-tab-size:4;tab-size:4">
<code class="language-sql" data-lang="sql">
 <span style="color:#66d9ef">CREATE</span>
 <span style="color:#66d9ef">TABLE</span> people (
 id BIGINT
 <span style="color:#66d9ef">GENERATED</span>
 ALWAYS <span style="color:#66d9ef">AS</span>
 <span style="color:#66d9ef">IDENTITY</span>,
 details jsonb,
 <span style="color:#66d9ef">PRIMARY</span>
 <span style="color:#66d9ef">KEY</span> (id)
 );
</code>
</pre>
</div>

Puisque mon thème original proposait une feuille de style au format SASS spécfiquement pour la colorisation syntaxique, j’ai tenté d’activer l’un des paramètres de Hugo pour utiliser les classes de style plutôt que le comportement ci-dessus.

pygmentsUseClasses: true

Le résultat était inespéré avec les classes reconnus par mes règles CSS.

<div class="highlight">
<pre class="chroma">
<code class="language-sql" data-lang="sql">
 <span class="k">CREATE</span>
 <span class="k">TABLE</span> <span class="n">people</span>
 <span class="p">(</span>
 <span class="n">id</span> <span class="nb">BIGINT</span>
 <span class="k">GENERATED</span>
 <span class="n">ALWAYS</span> <span class="k">AS</span>
 <span class="k">IDENTITY</span><span class="p">,</span>
 <span class="n">details</span> <span class="n">jsonb</span>
 <span class="p">,</span>
 <span class="k">PRIMARY</span> <span class="k">KEY</span>
 <span class="p">(</span><span class="n">id</span><span class="p">)</span>
 <span class="p">);</span>
</code>
</pre>
</div>

Les balises HTML dans le Markdown

Mes fichiers Markdown contenaient des balises HTML pour quelques effets visuels, à savoir des encarts d’avertissement <div>, du surlignage <u> et de très (trop) nombreux exposants <sup> pour mes sources d’articles. Pour cet aspect, Hugo est plus restrictif que Jekyll et ignore tout bonnement les balises dans le rendu de ses pages.

<!-- raw HTML omitted -->

Pour le coup, je n’ai pas cherché s’il existait un paramètre de configuration qui me permettrait de lever la restriction. Ma solution de contournement fut d’utiliser les composants shortcodes pour mes quelques exceptions et la documentation était bien suffisante pour y parvenir sereinement.

Par exemple pour mes encarts, j’ai gagné en facilité de rédaction avec la méthode markdownify fourni par le système de rendu, et je n’écris plus que du Markdown dans mes fichiers !

<!-- layout/shortcodes/message.html -->
<div class="message">{{ .Inner | markdownify }}</div>

<!-- content/posts/exemple.md -->
{\{< message >}\}
Exemple de rendu avec un lien de [documentation][17].
{\{< /message >}\}

Ne pas s’attarder sur les \ qui ne servent qu’à échapper les accolades.

En bref

Au-delà des quelques paramètrages ou réécriture Markdown qui m’ont fait perdre du temps, Hugo présente bien plus de fonctionnalités natives que ne le fait Jekyll. Je dresse une liste non exhausitive des apports qui m’ont convaincu à passer le cap.

Pagination simple et intégrée
Temps estimé de lecture avec la variable .ReadingTime
Génération des pages nettement plus rapide
Portabilité du logiciel avec zéro dépendance système

Pour conclure, je me suis résolu à héberger le projet et le rendu des pages sur GitHub, en suivant les instructions détaillées. La bascule du nom de domaine a ainsi été opérée ce midi et je n’ai plus à me préoccuper de mon ancienne instance VPS ni du certificat à renouveller auprès de Let’s Encrypt.

La conviction du dimanche soir

Florent Jardin — Sun, 15 Dec 2019 08:00:00 +0100

Il y a parfois des projets qui émergent de nulle part, d’autres qui mûrissent d’années en années. Certains mêmes peuvent être déclenchés par l’heureuse rencontre de deux inconnus, ou alors par la simple volonté de combler un vide. Aussi, dimanche dernier, je me suis plongé dans la lecture d’un livre technique sans raison apparente et me suis donné pour nouvel objectif de réapprendre le langage C.

Incongru, n’est-ce pas ? Pourtant, l’idée n’est pas nouvelle, elle a germée paisiblement jusqu’à plusieurs récents épisodes de mon quotidien. Et si ce langage informatique, très bas niveau, dont font l’impasse de nombreux étudiants (dont moi durant ma licence), avait des choses à m’apprendre pour progresser dans ma compréhension du logiciel libre ?

Je ne sais pas, mais j’ai eu comme la conviction d’être passer à côté d’une évidence…

Le langage C fait partie des fondations de nos logiciels actuels. Il a émergé dans les années 1970 sous les mains de l’ingénieur Dennis Ritchie à l’occasion de la réécriture du système d’exploitation UNIX. Ce grand monsieur fut lauréat du prix Turing en 1983, rien que ça.

A l’instar du système UNIX qui permit la ramification actuelle que l’on connait avec GNU/Linux, MacOS/iOS et BSD, ce petit langage fut l’élan nécessaire pour l’apparition des générations suivantes des langages, tels que le PHP, Java, C++ et C#, principaux standards de l’industrie d’hier et d’aujourd’hui. Une telle prouesse avec peu de moyens, puisqu’à l’époque, la mémoire vive était de l’ordre d’une centaine d’octets, les architectures matérielles se faisaient une guerre acharnée (oui, Intel x86 n’était pas la référence) et l’Internet n’existait pas.

Mais alors, pourquoi (ré)apprendre le langage C en 2020 ?

Dans son livre, Zed A. Shaw apporte de premiers éléments de réflexion dont je me permets la traduction suivante :

Aujourd’hui, bien trop de programmeurs assument simplement que tout ce qu’ils écrivent fonctionne, mais qu’un jour tout échouera de façon catastrophique. C’est particulièrement vrai si vous êtes le genre de personne ayant appris la plupart des langages modernes qui résolvent beaucoup de problèmes à votre place.

Les manquements aux règles de sécurité moderne du langage C vous impose une plus grande vigilance et d’être plus conscient de ce qui se passe. Si vous parvenez à écrire du code C solide et sécurisé, vous pourrez en écrire dans n’importe quel autre langage.

Apprendre le C vous donne un accès direct à une montagne de code legacy et vous enseignera la syntaxe de base d’un grand nombre de langages. Une fois que vous apprenez le C, vous pourrez facilement apprendre C++, Java, Objective-C, Javascript et davantages encore.

C est réellement un langage élégant de bien des façons. Sa syntaxe est incroyablement concise pour la puissance qu’il offre. C’est pour cette raison que de nombreux autres langages le lui ont emprunté depuis plus de 45 ans.

C vous apporte aussi énormement avec peu de moyens technologiques. Lorsque vous achevez votre apprentissage du C, vous aurez une opinion plus fine de quelque chose qui est tout aussi élégant et déplaisant à la fois. Le langage C est vieux, de la même façon qu’un beau monument, il vous semblera fantastique à une distance de 20 pieds, mais si vous vous en approchez, vous vous apercevrez qu’il est recouvert de fissures et de défauts.

Si l’on s’attarde sur la popularité des langages dans le monde du logiciel libre, on constate que le langage C arrive en 11^ème position d’après l’enquête annuelle de StackOverflow et en 9^ème position dans le rapport de l’Octoverse Github.

Et oui. Rien de plus sexy que le JavaScript ou le Python de nos jours ! Mais pour toutes les raisons de design ou de sécurité citées plus haut, la présence du langage C dans les plus populaires des langages en 2019 révèle une certaine réalité de terrain.

Ce n’est pas anodin cependant que je me penche à nouveau sur le langage C. Mon intérêt pour le projet libre PostgreSQL me fait me questionner sur l’usage des langages de bas niveau pour les logiciels d’envergure. Pour de nombreux contributeurs, rien de plus fiable et de plus robuste qu’un projet qui repose sur des bases connues et reconnues par l’Institut national américain de normalisation (ANSI) depuis trois décennies.

Le C est absolument partout. Les systèmes d’exploitation, les sytèmes embarqués, les systèmes de bases de données. Mon dernier exemple en date remonte à ce matin, lorsque David Steele a annoncé sur Twitter que le projet pgBackRest venait de migrer intégralement en C pur, après des mois de réécriture.

Je n’ai pas de recul ni d’expérience pour avancer que la portabilité, la performance et la longévité impressionnante font de ce langage un choix opportun pour le logiciel, qu’il soit libre ou non.

Je ne sais pas, peut-être une intuition.

Reprenons sérieusement

Florent Jardin — Wed, 12 Jun 2019 10:30:00 +0100

La série d’articles que je souhaite publier dans les mois et années à venir s’intègre dans un engagement personnel envers un domaine qui accapare mes journées de professionnel.

J’ai pour projet d’apporter ma contribution dans le paysage open-source francophone en partageant du contenu sur des sujets qui me passionnent, à savoir le web (infrastructure, tendances, solutions spécialisées), les bases de données (postgresql, expériences personnelles) et diverses réflexions sur nos usages modernes de l’outil informatique (suprématie de GAFAM, souveraineté des données personnelles, IoT).

À l’heure de la rédaction de ce premier article, nous sommes en 2019, et je traverse ma troisième décennie avec une angoisse grandissante. Les crises politique, économique et écologique ont frappé aux portes du monde entier, et bien que l’on en parle depuis ma naissance, je ne m’y interesse que depuis l’année dernière. Entre de nombreux podcasts hétérogènes (Thinkerview, Café Craft, Moodstep, Les Carencés, Mediapart), je me suis projeté dans un avenir proche où nous serions tout·es contraints de modifier nos habitudes de consommation pour garantir un monde viable aux prochaines générations.

Ce défi est immense. Autant pour moi que pour toi, lecteur.

Pour ma part, plusieurs changements ont eu lieu depuis l’année écoulée. Et à chaque nouveau palier se découvrent de nouveaux challenges et de nouvelles évidences. Manger bio et local, déconsommer, réduire l’usage des emballages plastique, pratiquer le yoga et la course à pied.

Mon quotidien professionnel n’a pas été épargné avec un pont dans ma carrière entre les technologies Oracle Database et le produit communautaire PostgreSQL, dans une juste continuité de l’usage d’un outil, au service du plus grand nombre.

C’est en découvrant sur Twitter le courrier du hacker, une initiative de Carl Chenet, que m’est venue l’idée d’amorcer un blog plus sérieux que ceux déjà éparpillés dans mon existence. Le partage d’expériences et le plaisir de lire des nouvelles optimistes prennent alors tout leur sens dans une compilation d’articles hebdomadaire, que je vous invite chaudement à rejoindre pour découvrir une actualité fraîche et très souvent enrichissante !

Si vous souhaitez en savoir plus sur mon profil, je vous invite à consulter la page À Propos de ce site.