S02E04 — 04-01-2026.
2.26, je compte sur toi.
jour 4.
2.26 année durant laquelle le monde va rendre des comptes, chaque individu va devoir rendre des comptes, envers soi-même, envers autrui, peu importe. L’année dernière, il me semble avoir dit haut et fort que j’allais créer mon language de programmation, qu’il fallait concevoir des logiciels vivants, et j’en passe.
Je vais devoir rendre des comptes face à mes promesses:
- zo — un language de programmation pour créer des applications de bureau.
- tree-sitter-zo — la grammaire du langage zo pour la bibliothèque tree-sitter.
- eazy — une bibliothèque pour créer des animations.
Ces projets sont officiellement disponible en open source. Il y a comme une sensation de satisfaction assez plaisante lorsque tu livres une création publiquement. Une partie de moi vit au milieu de ces lignes de codes. En parlant de code, j’ai dû m’assurer de la qualité de mon code pour cela j’ai pris la sage décision d’ajouté un CI/CD à mon dépot zo — C’EST UNE GALÈRE DE FOU ! Pas l’installation, mais à corriger l’ensemble des erreurs générer par une tâche.
Pour ceux qui se demande c’est quoi un CI/CD, c’est un diminutif provenant de l’anglais pour “Continous Integration” et “Continous Delivery”, c’est des étapes qui entre en jeux pour reproduire des scénarios de ton application dans des environnements particulier — CECI N’EST PAS UNE DÉFiNiTiON OFFiCiELLE. Prend l’image suivante: Avant de sortir de chez toi, tu dois toujours t’assurer d’avoir tes clés, ton téléphone, d’être un minimum présentable, etc. Bah c’est un peu ça que va faire la CI/CD, avant que tu ne livres ta base de code, on va lancer des tâches pour vérifier que le code est présentable, on va s’assurer que l’application est correctemnt tester en fonction de l’environnement pour Windows, pour Linux, pour MacOs, etc. Si il y a le moindre pépin, on lance une alerte pour signaler le problème. D’où l’importance d’avoir ça, parce que comme on développement souvent avec un seul environnement.
Cependant, j’étais en train de parler de la galère que c’était. Dans mon cas, c’était la première fois que je mettais ça en place dans un de mes projets. J’ai du passer 3-4 heures à débugger chaque messages d’alertes et d’erreurs pour finalement apprécier le vert de la CI/CD pour validé ton acharnement. Suite à cette exercice, je réalise qu’en faite, il faut mettre ça en place dès le premier jours et coder autour de ça. Maintenant que j’ai ça, je suis même rassuré ! Comme si, j’avais rendu mon projet plus sûre.
J’ai aussi rajouté des phases d’analyses lorsque je veux versionner mon code. Ce qui veut dire qu’avant chaque commit. J’ai un script qui est déclenché pour s’assurer que le nouveau code que j’essaye de sauvegarder est correct et ne casse rien. C’est grave stylé ! Ça aussi une fois que tu le mets en place, tu en ressors rassuré.
J’envisage d’utiliser lefthook et ajouter une analyse pour les fautes de frappes avec typos. Histoire de renforcer la qualité du code. Dorénavant, si je dois accompagner quelqu’un pour contribuer au projet, avec tout ceci en place, c’est tranquille Emile— vous êtes tous les deux rassurer. On doit même rendre des comptes à notre CI/CD. Décidément 2.26 sera l’année des règlements de compte.
TRiLU!