diff --git a/Makefile b/Makefile deleted file mode 100644 index 31db304..0000000 --- a/Makefile +++ /dev/null @@ -1,79 +0,0 @@ -PY?= -PELICAN?=pelican -PELICANOPTS= - -BASEDIR=$(CURDIR) -INPUTDIR=$(BASEDIR)/content -OUTPUTDIR=$(BASEDIR)/output -CONFFILE=$(BASEDIR)/pelicanconf.py -PUBLISHCONF=$(BASEDIR)/publishconf.py - - -DEBUG ?= 0 -ifeq ($(DEBUG), 1) - PELICANOPTS += -D -endif - -RELATIVE ?= 0 -ifeq ($(RELATIVE), 1) - PELICANOPTS += --relative-urls -endif - -SERVER ?= "0.0.0.0" - -PORT ?= 0 -ifneq ($(PORT), 0) - PELICANOPTS += -p $(PORT) -endif - - -help: - @echo 'Makefile for a pelican Web site ' - @echo ' ' - @echo 'Usage: ' - @echo ' make html (re)generate the web site ' - @echo ' make clean remove the generated files ' - @echo ' make regenerate regenerate files upon modification ' - @echo ' make publish generate using production settings ' - @echo ' make serve [PORT=8000] serve site at http://localhost:8000' - @echo ' make serve-global [SERVER=0.0.0.0] serve (as root) to $(SERVER):80 ' - @echo ' make devserver [PORT=8000] serve and regenerate together ' - @echo ' make devserver-global regenerate and serve on 0.0.0.0 ' - @echo ' make mail file=FILEPATH generate HTML email ' - @echo ' ' - @echo 'Set the DEBUG variable to 1 to enable debugging, e.g. make DEBUG=1 html ' - @echo 'Set the RELATIVE variable to 1 to enable relative urls ' - @echo ' ' - -html: - "$(PELICAN)" "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(CONFFILE)" $(PELICANOPTS) - -clean: - [ ! -d "$(OUTPUTDIR)" ] || rm -rf "$(OUTPUTDIR)" - -regenerate: - "$(PELICAN)" -r "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(CONFFILE)" $(PELICANOPTS) - -serve: - "$(PELICAN)" -l "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(CONFFILE)" $(PELICANOPTS) - -serve-global: - "$(PELICAN)" -l "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(CONFFILE)" $(PELICANOPTS) -b $(SERVER) - -devserver: - "$(PELICAN)" -lr "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(CONFFILE)" $(PELICANOPTS) - -devserver-global: - "$(PELICAN)" -lr "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(CONFFILE)" $(PELICANOPTS) -b 0.0.0.0 - -publish: - "$(PELICAN)" "$(INPUTDIR)" -o "$(OUTPUTDIR)" -s "$(PUBLISHCONF)" $(PELICANOPTS) - rsync -e ssh -av --delete-after /Users/pascal/Documents/craft-letter/output/ craftletter@ssh-craftletter.alwaysdata.net:/home/craftletter/www - -ssh: - ssh craftletter@ssh-craftletter.alwaysdata.net - -mail: - PYTHONPATH=PWD venv/bin/python ./prepare_email.py $(file) - -.PHONY: html help clean regenerate serve serve-global devserver devserver-global publish mail diff --git a/content/.DS_Store b/content/.DS_Store index 0538521..c377800 100644 Binary files a/content/.DS_Store and b/content/.DS_Store differ diff --git a/content/images/.DS_Store b/content/images/.DS_Store new file mode 100644 index 0000000..5008ddf Binary files /dev/null and b/content/images/.DS_Store differ diff --git a/content/images/LogoCraftLetter-800px.png b/content/images/LogoCraftLetter-800px.png index c412230..4c39b7a 100644 Binary files a/content/images/LogoCraftLetter-800px.png and b/content/images/LogoCraftLetter-800px.png differ diff --git a/content/images/craftletter-vertical.png b/content/images/craftletter-vertical.png new file mode 100644 index 0000000..ecbb47a Binary files /dev/null and b/content/images/craftletter-vertical.png differ diff --git a/content/images/craftletter.svg b/content/images/craftletter.svg index 0f300a0..2a71a83 100644 --- a/content/images/craftletter.svg +++ b/content/images/craftletter.svg @@ -1,70 +1,157 @@ - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/images/favicon.svg b/content/images/favicon.svg new file mode 100644 index 0000000..2fde9d7 --- /dev/null +++ b/content/images/favicon.svg @@ -0,0 +1,85 @@ + + + + + + + + + + + + + + + + + + + + diff --git a/content/newsletter/craft-letter-1.md b/content/newsletter/craft-letter-1.md index 6634a78..974bf86 100644 --- a/content/newsletter/craft-letter-1.md +++ b/content/newsletter/craft-letter-1.md @@ -1,24 +1,7 @@ Title: Lettre n°1 - 8 Décembre 2025 Date: 2025-12-08 10:20 Category: Newsletter - - +JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°1", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Dec 08 2025 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } diff --git a/content/newsletter/craft-letter-10.md b/content/newsletter/craft-letter-10.md new file mode 100644 index 0000000..d6ed7d1 --- /dev/null +++ b/content/newsletter/craft-letter-10.md @@ -0,0 +1,66 @@ +Title: Lettre n°10 — 09 février 2026 +Date: 2026-02-09 09:00 +Category: Newsletter +JsonLD: + + + +## Swift n’est pas le langage que vous croyez + +Dans un article qui date de 2023, Naman Goel compare [Swift et Rust](https://nmn.sh/blog/2023-10-02-swift-is-the-more-convenient-rust) 🇬🇧. Selon lui on retrouve des concepts de Rust dans Swift, comme le pattern matching ou la gestion des valeurs nulles, avec une syntaxe plus familière. Les [énumérations en Swift ](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/enumerations)🇬🇧 sont des [types algébriques](https://fr-academic.com/dic.nsf/frwiki/1669687) 🇫🇷, c’est-à-dire qu’ils combinent plusieurs autres types, pas seulement des constantes. C’est un autre concept issu de la programmation fonctionnelle. + +Swift est un langage multi paradigme : impératif, orienté objet et fonctionnel. La gestion de la mémoire est basée sur le [comptage de références](https://fr.wikipedia.org/wiki/Comptage_de_r%C3%A9f%C3%A9rences)🇫🇷. Il n’utilise pas de ramasse-miettes (*garbage collector*) pour libérer la mémoire, ce qui évite les pauses dans l’exécution du code. Il est compilé en code machine à l’aide de LLVM, ce qui lui permet de générer des applications pour toutes les plateformes supportées par ce dernier. + +L’affirmation selon laquelle Swift serait un Rust plus simple ne me convainc pas —il y a bien des points communs entre ces langages, mais aussi pas mal de différences. Ce qui m’a plus intéressé, et que j’ai découvert grâce à cet article, c’est que Swift n’est plus limité à l’écosystème Apple. En effet, depuis 2020. Il peut générer des programmes pour Windows ou Linux, et la génération d’application d’Android est sur le point d’arriver. + +D’ailleurs, [Apple veut étendre son utilisation au cloud](https://www.infoq.com/presentations/swift-apps-services/) 🇬🇧. + +## JQ Quest + +Jq est un outil bien connu pour manipuler du JSON en ligne de commande. Il peut vous éviter d’écrire un script qui doit transformer ou filtrer des données. [JQ Quest](https://codeberg.org/gturri/jq-quest) 🇬🇧 est une série d’exercice pour apprendre à vous servir de JQ. + +## State Of Js 2025 + +Si vous vous êtes curieux·se de connaître les outils à la mode dans l’écosystème JavaScript, +vous pouvez consulter les résultats du sondage [State of JS 2025](https://2025.stateofjs.com/en-US) 🇬🇧. Ils sont en ligne —même si la page d’accueil ne l’indique pas encore à l’heure où je rédige cette neswletter... Oups. + +Quelques points qui m’ont interpelés : + +* Angular est toujours aussi peu apprécié : plus d’une personne sur deux qui l’a essayé n’a pas aimé l’expérience. +* Le taux de satisfaction des utilisateurs de HTMX est en baisse (de 84% en 2016 à 69% en 2025) ; je soupçonne que cela correspond à la découverte des limitations de ce framework quand les applications deviennent plus complexes. Datastar, dont je vous parlais dans [la lettre n°7](http://127.0.0.1:8000/lettre-ndeg7-19-janvier-2026.html), n’apparait pas dans ce sondage, c’est dommage, car j’aurais bien aimé découvrir les retours d’expérience à son sujet. +* La satisfaction des utilisateurs de React est également en baisse régulière (de 92% en 2016 à 72% en 2025). +* Cypress (Tests End-to-end), autrefois très populaire, a perdu de sa superbe, puisque à peine plus de la moitié des utilisateurs ont envie de le réutiliser. +* À l’inverse, Playwright (tests End-to-end), Vitest (tests unitaires), Vite (build), Astro (framework pour créer des sites de contenu), Bun (alternative à NodeJs), Hono et Fastify (frameworks Web) sont appréciés par une large majorité de ceux qui les ont utilisés. +* Solid (Framework Front-end) maintient depuis 2021 un taux de satisfaction autour de 90% ; il mériterait sans doute plus d’attention. + +## ReliCSS : un outil pour faire de l’archéologie dans le Front-End + +[ReliCSS](https://www.alwaystwisted.com/articles/introducing-relicss-a-tool-for-front-end-archaeology)🇬🇧 est un nouvel outil qui identifie les directives obsolètes dans les feuilles de style CSS ❤️. Il n’est disponible que sous la forme d’une application Web pour l’instant, mais une version en ligne de commande est prévue. + +## Réviser les concepts des API REST + +Datacamp a publié une [synthèse sur les API REST](https://www.datacamp.com/blog/rest-api-interview-questions) 🇬🇧. Simple et efficace, j’aime beaucoup la forme ! +## Turso : une réécriture de SQLite en Rust + +[Turso](https://kerkour.com/turso-sqlite)🇬🇧 est une réécriture de SqLite en Rust, mais pas seulement. +En plus des spécificités de Rust, qui devraient permettre d’éviter les bugs liés à la gestion de la mémoire qui affectent certaines versions de SqlLite, Turso apporte de nouvelles fonctionnalités : le support des connexions via le réseau et les accès concurrents, comme Postgresql. +## Performances de NodeJS + +Les [performances de NodeJs](https://www.repoflow.io/blog/node-js-16-to-25-benchmarks-how-performance-evolved-over-time)🇬🇧 ont été améliorées régulièrement de la version 16 à la version 25. Si vous n’utilisez pas encore la dernière version, la mettre à jour serait un moyen pas trop coûteux de faire un peu d’écoconception. +## Oubliez la dette technique + +Derrière un titre un brin provocateur, Uwe Friedrichsen déroule [une réflexion intéressante sur la dette technique](https://www.ufried.com/blog/forget_technical_debt/)🇬🇧. Il en donne sa propre définition, qui n’est pas celle de Ward Cunningham (l’inventeur du concept) : pour lui c’est tout ce qui augmente la charge cognitive des développeurs. Il essaie d’identifier les causes de cette dette, qui sont d’après lui plus souvent organisationnelles que techniques. Il en mentionne aussi ses conséquences : le développement des fonctionnalités est ralenti, et les problèmes en production sont plus nombreux. +Selon lui, réduire la dette sans s’attaquer à ses causes racines serait insuffisant, car elle s’accumule plus vite qu’on ne peut la réduire. + +À propos de dette technique, je vous suggère de (ré)écouter la conférence d’Arnaud Lemaire "[Dette technique et entropie du logiciel](https://www.youtube.com/watch?v=VKe9EE4MUxk)"🇫🇷. Il commence par expliquer la notion de dette technique telle que Ward Cunningham l’a définie, avant d’en venir à ce que désigne plus communément par ce terme, et qu’il appelle "pourriture logicielle". Ce talk, qui ensuite aborde bien d’autres sujets, reste toujours pertinent et intéressant, malgré son ton provocateur. + +## Images docker durcies (bis) + +Docker n’est pas le seul à proposer des images durcies : le [projet minimal](https://github.com/rtvkiz/minimal) le fait aussi (à une moins grande échelle). Une image durcie est une image Docker dans laquelle tout ce qui n’est pas indispensable a été supprimé, dans le but de réduire la surface d’attaque (autrement dit les failles de sécurité potentielles). +## Devoxx France 2026 + +La plus grosse conférence Française consacrée au développement logiciel sera de retour du 22 au 24 Avril. [La billetterie est ouverte](https://reg.devoxx.fr/#w). Conseil d’ami : n’y allez pas pour la nourriture, vous seriez déçu·e 😉. + +-------- + +Voilà, c’est toute pour cette semaine ! diff --git a/content/newsletter/craft-letter-2.md b/content/newsletter/craft-letter-2.md index 509af4d..5531382 100644 --- a/content/newsletter/craft-letter-2.md +++ b/content/newsletter/craft-letter-2.md @@ -1,25 +1,7 @@ Title: Lettre n°2 - 15 Décembre 2025 Date: 2025-12-15 09:00 Category: Newsletter - - - +JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°2", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Dec 08 2025 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } diff --git a/content/newsletter/craft-letter-3.md b/content/newsletter/craft-letter-3.md index 17aeb8f..c351d58 100644 --- a/content/newsletter/craft-letter-3.md +++ b/content/newsletter/craft-letter-3.md @@ -1,24 +1,7 @@ Title: Lettre n°3 - 22 Décembre 2025 Date: 2025-12-22 08:20 Category: Newsletter - - +JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°3 - 22 Decembre 2025", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Dec 08 2025 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } diff --git a/content/newsletter/craft-letter-4.md b/content/newsletter/craft-letter-4.md index 1f05eba..dc917ef 100644 --- a/content/newsletter/craft-letter-4.md +++ b/content/newsletter/craft-letter-4.md @@ -1,24 +1,7 @@ Title: Lettre n°4 - 29 Décembre 2025 Date: 2025-12-29 09:00 Category: Newsletter - - +JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°4 - 29 Décembre 2025", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Dec 29 2025 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } diff --git a/content/newsletter/craft-letter-4.txt b/content/newsletter/craft-letter-4.txt deleted file mode 100644 index 4a260d3..0000000 --- a/content/newsletter/craft-letter-4.txt +++ /dev/null @@ -1,94 +0,0 @@ -Title: Lettre n°4 - 29 Décembre 2025 -Date: 2025-12-29 09:00 -Category: Newsletter - -} - -# Craft Letter n°4 - -## Édito - -Cette semaine encore, le contenu de cette newsletter est varié. Je vais en effet vous parler d'outillage, de langages fonctionnels, de recrutement, de sécurité, d'apprentissage ou de révision, et, pour finir, d'architecture basée sur des cellules. Concernant les langages fonctionnels, ceux que j'évoquerai sont mes deux langages favoris : ils associent la simplicité à un système de type qui élimine des classes entières d'erreurs. Le tout accompagné d'une expérience développeur particulièrment agréable. - -Passez de bonnes fêtes de fin d'année, et bonne lecture ! - -## ty - - -Après ruff (https://github.com/astral-sh/ruff) (linter et formateur) et uv (https://github.com/astral-sh/uv) (un gestionnaire de dépendances), Astral (https://astral.sh/) nous propose un troisième outil pour Python : ty (https://docs.astral.sh/ty/), un vérificateur de types (_type checker_) et serveur de langage. Comme ruff et uv, ty est écrit en Rust, et bénéficie de performances bien meilleures que celles des outils concurrents. ruff et uv étant des réussites, ty mérite qu'on le regarde de près. - -## Visualiser des logs avec HL - - - -hl (https://github.com/pamburus/hl?tab=readme-ov-file#performing-complex-queries%5D) est un outil de visualisation de log, écrit en Rust —c'est devenu un argument marketing. Il est capable de capable visualiser, filtrer et requêter rapidement des fichiers de plusieurs gigaoctets. - -## Une liste d'outils autour de Jujutsu - - -Jujutsu (https://www.jj-vcs.dev/) —jj— est une alternative à Git, à la fois plus puissant et plus simple d’utilisation. Il utilise Git comme back-end, ce qui veut dire que vous pouvez l’utiliser de façon transparente sur un projet dont les autres contributeurs utilisent Git. Awesome JJ (https://github.com/Necior/awesome-jj) liste des outils de l’écosystème naissant autour de cet outil. - -J’utilise Jujutsu depuis 8 mois, sur des projets personnels pour l’instant, et je le préfère largement à Git. Le nommage des commandes et options est bien plus clair, ce qui fait qu’on les retient ou retrouve plus facilement. Le workflow est plus simple —car il y a moins de concepts. Malgré cela, il est plus puissant que Git. Par exemple, il ne requiert de résoudre qu'une seule fois les conflits lors d'un rebase, là où Git peut vous demander de les résoudre à plusieurs reprises. - -## Comment trouver des développeurs pour un langage fonctionnel - - -Dans sa keynote lors des Scala Days 2025 🇬🇧 (https://www.youtube.com/watch?v=9OtN4iiFBsQ), Evan Czaplicki explique comment Elm (https://www.youtube.com/watch?v=9OtN4iiFBsQ), le langage qu'il a créé il y a bientôt 14 ans, peut servir de porte d'entrée pour des langages fonctionnels plus complexes, comme Haskell ou Scala. Elm est volontairement simple : les concepts y sont limités au strict minimum. Malgré une syntaxe qui peut intimider au départ, l'apprentissage est rapide, notamment parce que l'expérience développeur est vraiment agréable. Vous trouvez sympathiques les messages d'erreur de Rust ? Ils sont inspirés de ceux de Elm. - -Evan partage dans cette keynote les stratégies de recrutement d'entreprises florissantes qui utilisent Elm. Certaines recrutent les développeurs ou développeuses de modules populaires. D'autres embauchent des débutants et les forment. Les qualités du langage font que ces juniors sont opérationnels et productifs en quelques semaines seulement —n'allez pas croire que c'est exagéré, mon expérience avec Elm me confirme que c'est une réalité. Recruter des débutants disposés à se former est une manière de s'assurer qu'ils ont la culture adéquate : leur volonté d'apprendre sera utile par la suite sur d'autres sujets. Cela répond aussi à l'inquiétude de nombreux managers : comment recruter pour une techno de niche ? - -## Gleam attire l'attention des développeurs - -À propos de langages fonctionnels, Gleam (https://gleam.run/) est le second langage le plus admiré (https://survey.stackoverflow.co/2025/technology#admired-and-desired) par les répondants au dernier sondage de Stack Overflow, juste derrière Rust. Rust truste le sommet de ce classement depuis plusieurs années, ce n'est donc pas une surprise de le retrouver en tête. Gleam, qui est beaucoup plus récent, entre directement à la seconde place de ce sondage, et c'est une vraie surprise pour moi. En effet, je ne m'attendais pas à ce qu'autant de monde connaisse ce langage. Par contre, ses qualités font que je ne suis pas étonné qu'il soit aussi apprécié. Si vous voulez en savoir plus sur Gleam, je vous renvoie vers la conférence que j'ai donnée (https://www.youtube.com/watch?v=nTzNDM-dvRc) 🇫🇷 l'an dernier à ce sujet (27 minutes). - -## Filtrer les candidats en remote - -Jose Zarazua utilise une astuce pour distinguer instantanément les candidats 🇬🇧 (https://josezarazua.com/im-a-former-cto-here-is-the-15-sec-coding-test-i-used-to-instantly-filter-out-50-of-unqualified-applicants) qui réfléchissent et les autres, lors d'un test de recrutement à distance. - -## Des images docker durcies - - - -Des centaines d'images Docker durcies (https://hub.docker.com/hardened-images/catalog), auparavant payantes, sont dorénavant mises à disposition gratuitement (https://www.docker.com/blog/docker-hardened-images-for-every-developer) 🇬🇧 par Docker Inc. Une image durcie est une image dont la sécurité est renforcée, en éliminant tout ce qui n’est pas indispensable, ce qui réduit la surface d’attaque. - -Les images en question sont basées sur Debian et Alpine. Des charts Helm (https://blog.stephane-robert.info/docs/conteneurs/orchestrateurs/outils/helm/) 🇫🇷 sont également disponibles aux mêmes conditions. Un chart Helm décrit le déploiement et la configuration d’une application sous Kubernetes. Les charts, comme les images, sont durcis, et mis à jour en moins d’une semaine quand une faille de sécurité est détectée. Ces images et charts sont sous llicense Apache 2, une license bien connue et très permissive, donc il n'y a pas de mauvaise surprise à attendre de ce côté là. - -## Exposition involontaire de données avec Supabase - -Si vous utilisez Supabase (https://supabase.com/) (Base de données SAAS), vous devriez vérifier que les données des utilisateurs ne sont pas accessibles librement. Supabase ne met pas suffisamment en garde contre ce risque 🇬🇧 (https://skilldeliver.com/your-supabase-is-public). - -Cet article me rappelle des problèmes similaires avec Redis (https://www.tenable.com/plugins/nessus/100634) et MongoDB (https://satoricyber.com/mongodb-security/6-mongodb-authentication-features-you-must-know-about/#how-to-enable-authentication-in-mongodb), pour lesquels l'authentification n'est pas activée par défaut. - -## Apprendre ou réviser une techno en quelques minutes - -Jean-Pierre Liégeois (jeune lecteur du Var) Erwan (https://www.linkedin.com/in/erwannedellec/) m'a rappelé l'existence du site Learn X in Y minutes (https://learnxinyminutes.com). -Plutôt que de s'en servir pour apprendre une nouvelle technologie, il l'utilise pour se rafraichir la mémoire lorsqu'il doit utiliser un langage qu'il n'a pas pratiqué depuis longtemps. - -A cette occasion, j'ai découvert que les fiches proposées par ce site ne se limitent pas à des langages de programmation. Certaines concernent en effet des formats de données (JSON, XML, YAML, Cue...), des langages de balisage légers (Markdown, Restructured Text...), des shells (Bash, Fish), des frameworks et bibliothèques (Jquery, OpenCV...), des outils (Git, Docker), etc. - -## Architecture basée sur des cellules - -Une cellule est un ensemble de microservices et des services dont ils dépendent (cache, base de données, stockage...). Ils forment un ensemble cohérent et (idéalement) autonome —c'est-à-dire qui n'a pas ou peu de dépendances externes. - -Dans une architecture basée sur des cellules (_cell based architecture_), chaque cellule est répliquée à l'identique autant de fois que nécessaire pour supporter la charge (scalabilité). Ces cellules sont déployées dans des régions différentes afin d'assurer la résilience du service. - - Benjamin Cane (https://bencane.com/about) explique dans Cell Boundaries: Defining the Scope of a Cell in Cell-based Architecture (https://itnext.io/cell-boundaries-defining-the-scope-of-a-cell-f76c5c4a52dc) 🇬🇧 comment définir le contenu d'une cellule. - ---- - -Et voilà, c'est tout pour cette semaine ! - - -Retrouvez les numéros précédents sur le site web Craft Letter (https://www.craftletter.fr) 🇫🇷. - - -Si vous n'avez pas reçu cette lettre par email, ou si elle vous a été transmise par un tiers, vous pouvez vous abonner sur le site. - -Pascal Le Merrer - ---- - -Web Version: [webversion] - -Unsubscribe: [unsubscribe] - diff --git a/content/newsletter/craft-letter-5.md b/content/newsletter/craft-letter-5.md index c5c5c89..64ad813 100644 --- a/content/newsletter/craft-letter-5.md +++ b/content/newsletter/craft-letter-5.md @@ -1,24 +1,7 @@ Title: Lettre n°5 - 5 Janvier 2026 Date: 2026-01-05 09:00 Category: Newsletter - - +JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°5 - 5 Janvier 2026", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Jan 05 2026 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } @@ -48,7 +31,7 @@ Par exemple, le requêtage des éléments des pages HTML se base essentiellement ## Podcast Code Garage -Le [podcast Code Garage](https://code-garage.com/podcast?tab=classic) 🇫🇷 est celui du site du même nom, qui propose des cours en ligne. +Le [podcast Code Garage](https://code-garage.com/podcast?tab=classic) 🇫🇷 est celui du site du même nom, qui propose des cours en ligne. Dans des épisodes dont la plupart sont courts (moins de quinze minutes en général), Nicolas Brondin-Bernard explique les bases d'une techno, ou son historique. Quelques épisodes plus longs sont consacrés à des interviews. @@ -61,8 +44,7 @@ Plus de 150 épisodes sont disponibles à ce jour. ## Le coût caché des buzzwords dans la tech -Jernej Klancic raconte quelques anecdotes dans lesquelles [l'adoption irréfléchie d'une techno ou d'un principe qui faisait le buzz](https://engineering.leanix.net/blog/trade-offs/) 🇬🇧 lui a jouée de mauvais tours. -Il a établi une liste de questions à se poser avant de prendre une décision de ce type. +Jernej Klancic raconte quelques anecdotes dans lesquelles [l'adoption irréfléchie d'une techno ou d'un principe qui faisait le buzz](https://engineering.leanix.net/blog/trade-offs/) 🇬🇧 lui a jouée de mauvais tours. Il a établi une liste de questions à se poser avant de prendre une décision de ce type. J'ajoute ma propre recommandation : quand ces décisions impactent l'architecture du logiciel que vous développez, je vous invite à les tracer dans un [Architecture Decision Record](https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file#what-is-an-architecture-decision-record) (ADR) 🇬🇧, en explicitant les avantages et inconvénients de la techno choisie. C'est un document simple, idéalement au format markdown, qui est suivi sous Git, à côté du code. Dans ce document vous décrivez un problème à résoudre, les solutions que vous avez envisagées, celle que vous avez retenue et pourquoi. Vous notez aussi les conséquences de ce choix, qu'elles soient positives ou négatives. Pourquoi faire ça ? D'une part cela oblige à se poser un minimum de questions lors d'un choix d'architecture, et cela permet de partager ses réflexions avec le reste de l'équipe. D'autre part, cela permet de garder une trace, qui pourra s'avérer utile à l'avenir : quand dans quelques années, quelqu'un se demandera pourquoi telle techno a été choisie, il en trouvera les raisons dans un ADR ; et pourra ainsi juger s'il est pertinent ou pas de remettre en cause ce choix. diff --git a/content/newsletter/craft-letter-6.md b/content/newsletter/craft-letter-6.md new file mode 100644 index 0000000..a11c770 --- /dev/null +++ b/content/newsletter/craft-letter-6.md @@ -0,0 +1,88 @@ +Title: Lettre n°6 - 12 janvier 2026 +Date: 2026-01-12 09:00 +Category: Newsletter +JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°6 - 12 Janvier 2026", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Jan 12 2026 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } + + + + +## Utiliser des graphiques pour tirer un meilleur parti des métriques DORA + +Egor Savochkin explique comment identifier, à l'aide de graphiques, [l'impact des changements de pratiques et d'organisation](https://www.infoq.com/articles/DORA-metrics-PBCs/) 🇬🇧 sur la performance d'une équipe de développement. + +La performance est mesurée par [les métriques DORA](https://blog.stephane-robert.info/docs/devops/dora/) 🇫🇷, telles que décrites dans [Accelerate](https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment) 🇬🇧 : + +* la durée entre la création d'un _commit_ et sa mise en production +* la fréquence de mise en production ; +* le pourcentage des déploiements qui causent un incident en production ; +* le temps requis pour restaurer le service après un incident. + +Suivre l'évolution de ces métriques sur des graphiques "process comportement" (PBC) permet de distinguer les évènements exceptionnels des changements qui ont un impact durable. Cela confirme —ou infirme— l'efficacité des expérimentations menées par les équipes, au lieu de se baser sur des ressentis. + +Il rappelle que les métriques sont un instrument de mesure, pas un objectif. L'absence de récompense liées aux métriques assure qu'il n'y aura pas de tricherie. + +## Langage C3 + +Le [langage C3](https://c3-lang.org/) se base sur le C, et peut être mêlé avec du C, comme le Typescript avec du JavaScript. Il apporte de nombreuses fonctionnalités par rapport à son aîné : génériques, programmation par contrats, type Option pour la gestion de valeurs nulles, etc. + +## Des livres d'intro à Git, Bash, SQL, Docker, Laravel... + + +Bobby Iliev a écrit [une série de livres](https://github.com/bobbyiliev) 🇬🇧, dont certains sont disponibles en open source, au format électronique : + +- 📖   Introduction to Bash Scripting +- 📗   Introduction to Git and GitHub +- 📕   Introduction to SQL +- 🐳   Introduction to Docker +- 💡   Laravel tips and tricks + +Pour les deux premiers, une partie des chapitres est aussi disponible sous forme de vidéo. + +Il a aussi publié des livres qui ne sont pas disponibles gratuitement : + +- 🌍   Introduction to Terraform +- 🐧   Introduction to Linux + + +## Les problèmes posés par la relecture de code + +L'usage des Pull Requests (PR) de Github ou leur équivalent Gitlab, les Merge Requests, est la norme pour la plupart des équipes de développement. Ces pratiques visent à détecter des bugs et à ce que les standards de l'équipe soient respectés. Elles ont pour conséquence une diffusion de la connaissance du code. + +Toutefois elles ne sont pas sans défaut. Un problème fréquent, posé par la dépendance envers les collègues sollicités pour la relecture, est qu'ils/elles mettent parfois plusieurs jours à faire leurs retours. Un autre problème, qui peut être la cause du précédent, c'est la taille trop importante de certaines PR —symptôme révélateur d'une durée de vie trop longue de la branche. Personne n'a envie de relire des PR de plusieurs milliers de lignes. A l'inverse, une PR au contenu trivial ne justifie pas que l'on sollicite des collègues pour une relecture —qui, si elle est rendue obligatoire, n'a pas vraiment de sens dans ce cas. Tous ces problèmes nuisent à la productivité des équipes. + +Une première solution est décrite par MartinFowler dans [Ship / Show / Ask](https://martinfowler.com/articles/ship-show-ask.html) 🇬🇧. Il propose d'adopter des processus différents en fonction de la nature de la PR. + +Une solution plus radicale consiste à passer au [Trunk Based Development](https://thinkinglabs.io/articles/2025/07/21/on-the-benefits-of-trunk-based-development.html) 🇬🇧, dans lequel les branches ont une durée de vie maximale d'une journée, et sont relues, si besoin, après leur fusion dans la branche principale. C'est une des pratiques employées par les équipes les plus performantes, d'après Accelerate. + + +## Les chiffres que devraient connaître les développeurs Python + +Michael Kennedy a effectué une série de benchmarks, dont il livre [les résultats](https://mkennedy.codes/posts/python-numbers-every-programmer-should-know/) 🇬🇧 de façon synthétique. On y découvre que la consommation mémoire d'un processus Python vide est de 16 Mo, tandis qu'importer FastAPI est 500 fois plus long qu'écrire sur disque un fichier d'un Mo. + +## JuJutsu pour les utilisateurs de Git + +JJ, dont je vous ai parlé dans [la lettre n° 4](https://www.craftletter.fr/lettre-ndeg4-29-decembre-2025.html), est une alternative à Git, avec qui il est compatible. +[jj cheatsheet for Git users](https://gist.github.com/elithrar/4a09ef750af5624b729a6f1d87a0431c) 🇬🇧 est un aide mémoire qui m'a été utile ces derniers jours. + +## JuJutsu, pre-commit et Prek + +[pre-commit](https://pre-commit.com/) est un outil qui permet d'exécuter une série de vérifications sur le code avant de le commiter. Les contrôles de base, que vous pouvez choisir d'activer ou pas, sont extensibles au moyen de plugins. Certains peuvent corriger automatiquement les problèmes qu'ils détectent. Il va par exemple vérifier le formatage du code, l'absence d'instructions de debug, le respect de bonnes pratiques du langage, etc. Plus d'une douzaine de langages de programmation sont supportés, ainsi que les Dockerfile. + +Il s'enregistre comme un hook Git, ce qui fait qu'il se déclenche automatiquement quand vous tentez de commiter du code. Si certaines de vérifications ne sont pas satisfaites, le commit échoue. + +JJ n'est pas compatible, pour l'instant, avec pre-commit. Mais il existe une solution : [jj-pre-push](https://pypi.org/project/jj-pre-push/). +pre-commit est écrit en Python. Malgré cela, son exécution est plutôt rapide, car il ne traite, par défaut, que les fichiers que vous avez modifiés. C'est toutefois une bonne idée de l'exécuter dans les pipelines de CI avec pre-commit run --all, de façon à vérifier l'intégralité du code. Non seulement cela garantit que tout votre code respecte les standards que vous avez définis, mais aussi cela permet de pallier au fait que certains développeurs peuvent ne pas l'exécuter sur leur poste. + +Si pre-commit n'est pas assez rapide pour vous, il existe une réécriture en Rust, nommée [Prek](https://prek.j178.dev/). + +## L'open source en danger ? + +Tailwind Labs, malgré le succès croissant de son framework CSS, a vu ses revenus s'effondrer depuis 2 ans. [Les trois quarts des membres de l'équipe technique viennent d'être été licenciés](https://loud-technology.com/blog/tailwind-labs-ia-menace-modele-economique-open-source/) 🇫🇷. En cause : les LLM, qui ont détruit le modèle économique de l'entreprise. Leur usage massif remet en cause la pérennité de nombreux projets open source. + +## Les bases de données en 2025 + +Andy Pavlo publie sa [rétrospective annuelle sur les bases de données](https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html) 🇬🇧. Il évoque la domination de Postgresql, le procès intenté par MongoDB .inc à l'encontre de Ferret .inc, les formats des fichiers de données... + +## Rétro-ingénierie de jeux vidéo + +Fabien Sanglard a écrit plusieurs livres qui sont devenus des références en matière de rétro-ingénierie de jeux vidéo. [Le premier est consacré à Wolfenstein 3D](https://fabiensanglard.net/gebbwolf3d/) 🇬🇧, l'ancêtre de DOOM. [Le second](https://fabiensanglard.net/gebbdoom/) 🇬🇧 décortique le code et les algorithmes de DOOM, qui était une révolution technique en son temps, ainsi que le matériel sur lequel il tournait dans les années 90 (ordinateurs et consoles). [Le dernier](https://fabiensanglard.net/cpsb/) 🇬🇧 couvre le matériel et le logiciel utilisés par CAPCOM pour faire tourner sur des bornes d'arcade des jeux comme Street Fighter II, Ghouls’n Ghosts, ou Final Fight. diff --git a/content/newsletter/craft-letter-7.md b/content/newsletter/craft-letter-7.md new file mode 100644 index 0000000..7a22973 --- /dev/null +++ b/content/newsletter/craft-letter-7.md @@ -0,0 +1,70 @@ +Title: Lettre n°7 - 19 janvier 2026 +Date: 2026-01-19 09:00 +Category: Newsletter +JsonLD: + + +# Lettre N°7 + +Voici quelques articles qui m’ont marqué ces derniers jours. + +Bonne lecture ! + +--- + +## DataStar + +Vous avez probablement déjà entendu parler de [HTMX](https://htmx.org/). C’est un framework JS léger, qui vise à fournir une expérience proche de celle des Single Page Applications, mais en écrivant pas ou peu de JavaScript. Les interactions avec l’application déclenchent l’envoi de fragments HTML par le serveur, de façon à mettre à jour la page. Il n’y a pas d’échange de JSON comme avec React, Vue, Angular, Elm ou équivalent. L’état de l’application, et sa logique, sont gérés côté serveur, dans un langage au choix (Java, PHP, Go…) + +[DataStar](https://data-star.dev/) a le même objectif, mais corrige les défauts de HTMX. En effet, ce dernier montre ses limites quand les fonctionnalités des applications s’enrichissent. Il faut ajouter du JavaScript, et la complexité du code HTMX augmente significativement. DataStar résout ces problèmes : le code back-end seul suffit à la réalisation d’applications riches. De plus, en se basant sur les SSE (Server Side Events), il simplifie le développement d’applications collaboratives. Cerise sur le gâteau, il cumule légèreté et performances, ce qui est parfait pour une démarche d’éco-conception et résulte en une bonne expérience utilisateur. + +## Les frameworks Python en production + +Dans [ce podcast](https://talkpython.fm/episodes/show/533/web-frameworks-in-prod-by-their-creators), les créateurs de framerworks Python (Flask, Django, FastAPI, Litestat et Quart) partagent leurs recommandations en terme de stack, de performances, d’asynchronisme, . d’auto-hébergement… Une synthèse écrite est disponible. + +Quelques points en particulier ont retenu mon attention : + +* [uvloop](https://github.com/MagicStack/uvloop) fournit une boucle d’événements deux fois plus rapide que celle d’asyncio ; +* [orjson](https://github.com/ijl/orjson) est plus rapide que le module JSON de la bibliothèque standard de Python, tout en assurant la sérialisation de types non supportés par ce dernier ; +* un unique appel de fonction bloquant suffit à bloquer l’intégralité d’une application pendant son exécution. En pratique, il ne faut déclarer comme asynchrone que les fonctions dont nous sommes certains qu’elles ne comportent que des appels non-bloquants. + +Les participants mentionnent aussi leur intérêt pour certaines technos dont je vous ai parlé récemment : HTMX, DataStar et [Sqlite](https://www.craftletter.fr/lettre-ndeg2-15-decembre-2025.html). + +## SoCraTes Rennes + +*Pour être transparent, je me dois de préciser que je suis organisateur de cet évènement.* + +La sixième édition de [SoCraTes Rennes](https://socrates-rennes.github.io/) aura lieu le 31 mars 2026. Il s’agit de la déclinaison, sur une journée, des non-conférences SoCraTes telles que [SoCraTes France](https://socrates-fr.github.io/). SoCraTes signifie "SOftware Craft and Testing". Le néologisme "non-conférence" retranscrit le fait que ce n’est pas l’équipe d’organisation qui définit le programme. Ce sont les participant·e·s qui ont la possibilité de proposer des sujets, sur place. Ce que j’aime dans ce type d’évènement c’est la richesse des échanges, bien supérieure à celle des conférences traditionnelles. + +Si vous souhaitez donner de la visibilité à votre entreprise, il est encore possible de [sponsoriser cette journée](https://socrates-rennes.frama.space/s/oGgqEkSADLBYaX8). Parlez-en à votre employeur 😉 + +## Comment fonctionne un terminal ? + +Si vous voulez savoir comment fonctionne un terminal, voici [la réponse](https://how-terminals-work.vercel.app/), sous forme interactive. + +## Se lancer dans l’open source + +[Contrib.FYI](https://k-dash.github.io/contrib-fyi/) liste des tâches à réaliser sur des projets open-source Ces tâches sont adaptées à une première contribution. Elles sont affichées par ordre chronologique, dans le but de faciliter des découvertes par sérendipité. + +## L’efficacité du pair-programming + +Thierry De Pauw [débunke un post critique à l’égard du pair-programming](https://thinkinglabs.io/articles/2026/01/13/on-the-effectiveness-of-pair-programming.html). Il explique pourquoi, contrairement à une croyance répandue, il coûte moins cher de travailler à deux plutôt que seul sur les sujets exploratoires. Il évoque aussi des avantages comme la diffusion de la connaissance et l’impact positif sur le moral de l’équipe. Il conclut en mentionnant que le Software Teaming (aussi appelé Mob Programming ou Ensemble Programming) est encore plus efficace que le Pair Programming. + +Ce sujet me parle, puisque j’ai donné [une conférence](https://devconf.net/talk/pair-programming-et-si-on-gagnait-du-temps-pascal-le-merrer) qui développait des arguments similaires. + +## Combien y a-t-il de moteurs JavaScript ? + +Le nombre de [moteurs qui permettent d’exécuter du code JavaScript](https://zoo.js.org/) est étonnant. + +## Stratégie européenne pour un écosystème numérique ouvert + +La Commission Européenne commence enfin à prendre conscience de l’importance de l’Open Source, et de notre dépendance excessive aux solutions États-Uniennes. Si ces sujets vous préoccupent, vous pouvez [donner votre avis](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16213-Ecosystemes-numeriques-ouverts-europeens_fr), en espérant qu’il sera pris en compte dans de futures lois. + +## Docker veut simplifier les déploiements en production + +Docker Compose est adapté au développement d’applications, pas à leur déploiement en production. Ce dernier passe souvent par des outils complexes, tels que Helm ou Kustomize, configurés à grand renfort de fichiers YAML. +Docker a lancé [un nouvel outil nommé Kanvas](https://www.infoq.com/news/2026/01/docker-kanvas-cloud-deployment/), qui utilise la syntaxe familière de Docker Compose, et revendique une plus grande simplicité que ses concurrents. Il génère aussi une représentation graphique détaillée de l’architecture, qui peut s’avérer utile aussi bien pour communiquer que pour débugger. + +---- + +C’est tout pour cette semaine ! diff --git a/content/newsletter/craft-letter-8.md b/content/newsletter/craft-letter-8.md new file mode 100644 index 0000000..5ea7dec --- /dev/null +++ b/content/newsletter/craft-letter-8.md @@ -0,0 +1,74 @@ +Title: Lettre n°8 — 26 janvier 2026 +Date: 2026-01-26 09:00 +Category: Newsletter +JsonLD: + + +# Lettre n° 8 + + +## Tendances de la tech en 2025 + +InfoQ a rassemblé dans un *ebook* leurs articles de synthèse sur [les tendances de la tech 2025](https://www.infoq.com/minibooks/2025-infoq-trends-reports-emag/) 🇬🇧. Ils y détaillent pour 5 domaines leur vision (subjective) de l’adoption de certaines technologies et pratiques : + +* Architecture logicielle et conception ; +* Culture et méthodes ; +* AI, ML et Data Engineering ; +* Cloud et Devops ; +* Java (au sens large : cela inclut divers langages qui fonctionnent sur la JVM, comme Kotlin, Scala, Clojure…). + +À chaque fois, ils positionnent l’adoption de ces technologies et pratiques selon des paliers inspirés de la théorie de la diffusion de l’innovation, d’Everett Rogers : + +* innovateurs, +* primo-adoptants, +* majorité précoce, +* majorité tardive. + +Cette classification est établie et commentée par les rédacteurs qui contribuent à InfoQ tout au long de l’année dans ces différents domaines. + +## Plakar + +Tar est un format d’archivage qui date de 1979. À cette époque, les données étaient enregistrées sur bande magnétique. C’est un format simple, qui se contente de concaténer le contenu de plusieurs fichiers, sans même les compresser. + +[Plakar](https://github.com/PlakarKorp/plakar) 🇬🇧 est un format récent, qui se veut un remplaçant de Tar. Par rapport à ce dernier, il ajoute de la compression, de la déduplication, du chiffrement, du versionnement… De plus, les données sont consultables sans être extraites entièrement, et il est beaucoup plus rapide grâce à la parallélisation. + +## Pourquoi Zig est-il si cool ? + +Nilo Stolte est _très_ expérimenté. Il explique pourquoi [Zig est un langage dont certaines fonctionnalités l’impressionnent](https://nilostolte.github.io/tech/articles/ZigCool.html)🇬🇧. En particulier des fonctionnalités qu’il pensait réservées aux langages interprétés, qu'il présente dans un tutoriel d'introduction au langage. + +## JQuery n’est pas mort ! + +JQuery fête ses vingt ans en publiant une [nouvelle version majeure](https://blog.jquery.com/2026/01/17/jquery-4-0-0/)🇬🇧 ! C’est une surprise, car, avec les *Single Page Applications* et les progrès des navigateurs, il faut avouer que cette bibliothèque omniprésente dans les projets Web du début des années 2000 a pris un gros coup de vieux. + +## Détection de fuite mémoire dans les navigateurs avec Memlab + +Facebook a publié en open source [MemLab](https://github.com/facebook/memlab)🇬🇧, un outil pour détecter les fuites de mémoire causées par du code JavaScript exécuté par un navigateur. Il s’appuie sur Puppeteer, un outil d’automatisation des tests. Il est utilisé ici pour décrire les scénarios à exécuter dans le navigateur, et pour lesquels MemLab va rechercher d’éventuelles fuites de mémoire. + +## Les challenges du Soft Delete + +Au lieu d’effacer des données d’une base, vous pouvez ajouter une colonne qui indique quand elles ont été archivées, afin de pouvoir annuler cet "effacement", ou à des fins de traçabilité. C’est ce qu’on appelle un *soft delete*. Cette approche peut avoir des conséquences gênantes, mais [il existe des alternatives](https://atlas9.dev/blog/soft-delete.html)🇬🇧. + +## Pourquoi est-il difficile d’être fainéant ? + +SpeakEZ Technology explique comment sont gérées, dans différents langages, [les variables ou expressions *lazy*](https://speakez.tech/blog/why-lazy-is-hard/)🇬🇧. *Lazy* signifie ici qu’elles ne sont évaluées que lorsqu’on y accède pour la première fois. Le terme employé en français, *initialisation tardive*, est bien plus clair. + +## Supprimer Rust pour améliorer les performances + +Souvent, pour améliorer les performances, une réécriture de la totalité ou d’une partie du code en Rust est une bonne piste. Mais chez Prisma, qui développe un ORM en TypeScript, c’est l’inverse qui s’est produit : la [réécriture d’un module Rust en TypeScript](https://www.prisma.io/blog/announcing-prisma-orm-7-0-0#moving-away-from-rust)🇬🇧 a rendu les requêtes trois fois plus rapides ! + +## Serendipitech + +Anne-Laure Gros vient de lancer [Serendipitech](https://www.serendipitech.fr/)🇫🇷, un site qui recense des conférences Agiles, Craft et Tech, et vous informe des ouvertures / fermetures de CFP. + +## Le CFP du Breizhcamp est ouvert + +Le [CFP du Breizhcamp](https://sessionize.com/breizhcamp-2026)🇫🇷, la conférence tech Rennaise qui aura lieu du 24 au 26 juin prochains, est ouvert. + +## Rennes Tech + +Pour continuer dans l’actualité tech Rennaise, le site [Rennes Tech](https://rennes.tech/)🇫🇷, qui recense l’actualité des communautés techniques de la ville, renait de ses cendres. + + +---- + +C’est tout pour cette semaine ! diff --git a/content/newsletter/craft-letter-9.md b/content/newsletter/craft-letter-9.md new file mode 100644 index 0000000..f9a237e --- /dev/null +++ b/content/newsletter/craft-letter-9.md @@ -0,0 +1,72 @@ +Title: Lettre n°9 - 02 février 2026 +Date: 2026-02-02 09:00 +Category: Newsletter +JsonLD: + + +## Écoute le vieux sage… + +Addy Osmany n’est pas si vieux, mais partage sa sagesse à travers [des leçons qu’il a tirées de son expérience chez Google](https://addyosmani.com/blog/21-lessons/)🇬🇧. Elles me paraissent pertinentes, même si bien entendu tout n’est pas nouveau dans ce qu’il écrit. Comme la [loi de Goodhart](https://fr.wikipedia.org/wiki/Loi_de_Goodhart)🇫🇷, qu’il cite sans la nommer. + +## Choisir des icônes + +Stéphanie Walter donne une série de recommandations sur la façon de [choisir des icônes](https://stephaniewalter.design/blog/tips-on-how-to-pick-the-right-icons-for-your-website-with-icons8) 🇫🇷. Elle s’adresse à des personnes qui n’ont pas ou peu de notions de design. + +## Git bisect + +Si je devais classer les commandes Git par utilité, [git bisect](https://engineering.leanix.net/blog/git-bisect/)🇬🇧 serait probablement dans le trio de tête. Elle permet de retrouver rapidement le commit à l’origine d’un bug. Mais pour qu’elle soit efficace, il est indispensable de faire de petits commits. Savoir qu’un problème a été introduit par une modification de mille lignes de code ne serait pas très utile. + +## Outils de développement et tests d’API + +Vous connaissez probablement [Postman](https://www.postman.com/), un outil pour stocker et jouer des requêtes HTTP, très utile quand on développe une API. Cet outil open source populaire [s’est dégradé](https://readmedium.com/enshittification-of-a-beloved-open-source-tool-postman-24e0837bcff7)🇬🇧 au fil du temps. Le stockage des requêtes, depuis qu’il se fait sur les serveurs de l’entreprise derrière Postman, pose des problèmes de confidentialité. + +J’ai utilisé [Bruno](https://www.usebruno.com/), un outil similaire. Je viens de découvrir qu’il était maintenant au centre d’une offre payante. Je n’ai rien contre le principe, il me parait normal d’essayer de vivre de son travail. J’espère juste que cela ne se traduira pas par une évolution comparable à celle de Postman —ce n’est pas le cas pour l’instant. + +[Posting](https://posting.sh/) : qui propose des fonctionnalités similaires, mais dans le terminal. La roadmap, définie par la communauté, est toutefois un peu surprenante : avoir un fond de fenêtre transparent y est plus urgent que pouvoir modifier les paramètres ou en-têtes des requêtes 🤔 + +Il existe d’autres outils de ce type, comme [Hoppscotch](https://docs.hoppscotch.io/), qui est proposé en SAAS, mais aussi en auto-hébergement. + +## {JSON} Placeholder + +[{JSON} Placeholder](https://jsonplaceholder.typicode.com/) expose une API que vous pouvez utiliser quand vous avez besoin d’une API rapidement, mais qui n’a finalement que peu d’importance pour vous. Elle peut servir dans le cadre d’une formation, d’un kata de code, d’une démo, d’une présentation… Elle expose des endpoints pour gérer des posts, des commentaires, des albums, des photos, des listes de tâches, et des utilisateurs. + +## Les logs, ça craint + +Beaucoup de logs sont inutiles, parce qu’ils manquent de contexte. Le problème n’est pas nouveau, loin de là, mais il est encore d’actualité. De plus, rechercher l’origine d’un bug dans les logs d’un site à fort trafic s’apparente à chercher une aiguille dans une botte de foin. Boris Tane explique [comment les Wide Events aident à résoudre ces problèmes](https://loggingsucks.com/). + +## Un livre gratuit sur l’accessibilité + +[Accessibility for Everyone](https://accessibilityforeveryone.site/) de Laura Kalbag n’est pas récent, il date de 2017, mais n’est pas complètement obsolète non plus. Si les outils ont changé, les principes qu’il décrit restent valides. Il est dorénavant disponible gratuitement. + +## Forum Ruby + +Un nouveau [forum](https://www.rubyforum.org)🇬🇧 pour la communauté Ruby est en ligne. Il est dédié aux échanges entre développeurs/développeuses, quel que soit leur niveau ; de façon surprenante pour moi, les offres d’emploi n’y sont pas les bienvenues. + +## Comment les LLM sabotent les pratiques de programmation en privatisant un bien public + +Michiel Buddingh explique comment les entreprises qui créent des LLM sont en train de nous faire [revenir à la situation qui prévalait avant l’avènement du Web](https://michiel.buddingh.eu/enclosure-feedback-loop)🇬🇧 : l’accès à la connaissance était payant. + +## Quand refactorer votre code ? + +Nick Cosentino liste des signes révélateurs de la [nécessité de refactorer votre code](https://www.devleader.ca/2023/11/24/when-to-refactor-code-how-to-maximize-efficiency-and-minimizing-tech-debt/)🇬🇧. +Il cite aussi quelques techniques de refactoring. J’ai regretté, à la lecture de cet article, qu’il recommande de définir des métriques pour mesurer l’efficacité du refactoring, sans en mentionner. + +## Créer des applications Python pour le terminal + +[Rich](https://rich.readthedocs.io/en/stable/introduction.html) est une bibliothèque bien connue du monde Python, pour améliorer l’affichage des données dans le terminal. [Textual](https://www.textualize.io/) va plus loin, car il s’agit d’un framework pour créer de véritables applications. [Typer](https://typer.tiangolo.com/), bien qu’il se présente comme un équivalent, me semble moins riche fonctionnellement. Par contre son haut niveau d’abstraction fait qu’il peut être intéressant pour ce qui est de parser les arguments de la ligne de commande. + + +## Elm serait-il un bon choix pour votre équipe ? + +Brian Dukes détaille les raisons qui font qu’une techno de niche comme Elm peut [être, ou ne pas être, un bon choix](https://engagesoftware.com/posts/is-elm-the-right-choice-for-your-team/)🇬🇧 pour votre équipe. Elm est un langage fonctionnel dédié à la création de *Single Page Applications*. + +## Alpes Craft 2026 + +[Alpes Craft](https://www.alpescraft.fr/)🇫🇷 aura lieu les 4 et 5 juin prochain. Cet évènement cumule une conférence classique, le premier jour, avec une non-conférence, le lendemain. Si vous ne connaissez pas les non-conférences, je vous invite à relire la courte description que j’en ai faite dans [la lettre N°7](https://www.craftletter.fr/lettre-ndeg7-19-janvier-2026.html)🇫🇷, dans la partie consacrée à [SoCraTes Rennes](https://socrates-rennes.github.io/)🇫🇷. + +Comme l’indique son nom, Alpes Craft est consacré à la tech, mais pas à une technologie particulière. + +--- + +C’est tout pour cette semaine ! + diff --git a/content/pages/index.md b/content/pages/index.md index 795effa..662a13b 100644 --- a/content/pages/index.md +++ b/content/pages/index.md @@ -1,26 +1,9 @@ Title: Accueil -Date: 2025-01-05 09:00 +Date: 2026-02-09 09:00 URL: save_as: index.html Category: Home - - +JsonLD: { "@context": "https://schema.org", "@type": "WebPage", "name": "Accueil", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Feb 09 2026 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } @@ -51,6 +34,11 @@ Pour savoir qui je suis, ou pourquoi j'écris cette lettre, je vous invite à vo # Archives +* [Lettre n°10]({filename}/newsletter/craft-letter-10.md) +* [Lettre n°9]({filename}/newsletter/craft-letter-9.md) +* [Lettre n°8]({filename}/newsletter/craft-letter-8.md) +* [Lettre n°7]({filename}/newsletter/craft-letter-7.md) +* [Lettre n°6]({filename}/newsletter/craft-letter-6.md) * [Lettre n°5]({filename}/newsletter/craft-letter-5.md) * [Lettre n°4]({filename}/newsletter/craft-letter-4.md) * [Lettre n°3]({filename}/newsletter/craft-letter-3.md) diff --git a/justfile b/justfile new file mode 100644 index 0000000..c5fb0f5 --- /dev/null +++ b/justfile @@ -0,0 +1,59 @@ +CONFFILE := "pelicanconf.py" +PUBLISHCONF := "publishconf.py" +PELICANOPTS := "" +SERVER := "localhost" + +default: + just --list + +help: + @echo 'Set the DEBUG variable to 1 to enable debugging, e.g. make DEBUG=1 html ' + @echo 'Set the RELATIVE variable to 1 to enable relative urls ' + + +# (re)generate the web site +html: + pelican content -o output -s "{{CONFFILE}}" {{PELICANOPTS}} + +# remove the generated files +clean: + [ ! -d "output" ] || rm -rf output + +# regenerate files upon modification +regenerate: + pelican -r content -o output -s "{{CONFFILE}}" {{PELICANOPTS}} + +# serve site at http://localhost:8000 +serve: + pelican -l content -o output -s "{{CONFFILE}}" {{PELICANOPTS}} + +# serve (as root) to {{SERVER}}:80 +serve-global: + pelican -l content -o output -s "{{CONFFILE}}" {{PELICANOPTS}} -b {{SERVER}} + +# serve and regenerate together +devserver: + pelican -lr content -o output -s "{{CONFFILE}}" {{PELICANOPTS}} + +# regenerate and serve on 0.0.0.0 +devserver-global: + pelican -lr content -o output -s "{{CONFFILE}}" {{PELICANOPTS}} -b 0.0.0.0 + +# generate using production settings +publish: + pelican content -o output -s "{{PUBLISHCONF}}" {{PELICANOPTS}} + rsync -e ssh -av --delete-after /Users/pascal/Documents/craft-letter/output/ craftletter@ssh-craftletter.alwaysdata.net:/home/craftletter/www + +# connect to production server +ssh: + ssh craftletter@ssh-craftletter.alwaysdata.net + +# Create the skeleton for a new issue of the newsletter, and reference it into the home page +new number: + PYTHONPATH=PWD venv/bin/python ./scripts/create_newsletter.py --number={{number}} + +# generate HTML email +mail file: + echo {{file}} + PYTHONPATH=PWD venv/bin/python ./scripts/prepare_email.py {{file}} + diff --git a/logo/craftletter-vertical.psd b/logo/craftletter-vertical.psd new file mode 100644 index 0000000..a632589 Binary files /dev/null and b/logo/craftletter-vertical.psd differ diff --git a/logo/craftletter.psd b/logo/craftletter.psd new file mode 100644 index 0000000..3768484 Binary files /dev/null and b/logo/craftletter.psd differ diff --git a/mdtosendy_config/styles.css b/mdtosendy_config/styles.css index c8e62f9..248ca40 100644 --- a/mdtosendy_config/styles.css +++ b/mdtosendy_config/styles.css @@ -238,3 +238,8 @@ i { display: block; } +hr { + color: #CCCCCC; + margin-top: 40px; + margin-bottom: 40px; +} diff --git a/scripts/create_newsletter.py b/scripts/create_newsletter.py new file mode 100644 index 0000000..9a8202c --- /dev/null +++ b/scripts/create_newsletter.py @@ -0,0 +1,72 @@ +import argparse +import locale +from pathlib import Path +from datetime import datetime, timedelta + +MONDAY = 0 # 0 = Monday, 1=Tuesday, 2=Wednesday... + + +def get_next_weekday(d, weekday): + days_ahead = weekday - d.weekday() + if days_ahead <= 0: # Target day already happened this week + days_ahead += 7 + return d + timedelta(days_ahead) + + +def set_publication_date_for_humans(text: str, publication_date: datetime) -> str: + locale.setlocale(locale.LC_TIME, "fr_FR") + date = publication_date.strftime("%d %B %Y") + return text.replace("{DATE}", date) + + +def set_publication_date_for_pelican(text: str, publication_date: datetime) -> str: + date_digits = publication_date.isoformat()[0:10] + return text.replace("{DATE_DIGITS}", date_digits) + + +def set_publication_date_for_seo(text: str, publication_date: datetime) -> str: + locale.setlocale(locale.LC_TIME, "en_US") + date_utc = publication_date.strftime("%a %b %d %Y") + return text.replace("{DATE_UTC}", date_utc) + + +# Parse the command line arguments +parser = argparse.ArgumentParser() +parser.add_argument("-n", "--number", required=True, type=int, help="Newsletter number") +args = parser.parse_args() + +# Load the newsletter template +template = Path("./template/newsletter.md") +content = template.read_text() + + +new_content = content.replace("{LETTER_NUMBER}", str(args.number)) + +today = datetime.today() +next_monday = get_next_weekday(today, MONDAY) + +new_content = set_publication_date_for_humans(new_content, next_monday) + +new_content = set_publication_date_for_pelican(new_content, next_monday) + +new_content = set_publication_date_for_seo(new_content, next_monday) + +# Create the new file +destination = Path(f"./content/newsletter/craft-letter-{args.number}.md") +destination.write_text(new_content) + +# Load the homepage template +template = Path("./template/index.md") +content = template.read_text() + +new_content = set_publication_date_for_pelican(content, next_monday) + +new_content = set_publication_date_for_seo(new_content, next_monday) + +for i in reversed(range(args.number)): + link = f"* [Lettre n°{i + 1}]({{filename}}/newsletter/craft-letter-{i + 1}.md)\n" + new_content += link + +# Update the index page +destination = Path("./content/pages/index.md") +destination.write_text(new_content) diff --git a/prepare_email.py b/scripts/prepare_email.py similarity index 100% rename from prepare_email.py rename to scripts/prepare_email.py diff --git a/template/index.md b/template/index.md new file mode 100644 index 0000000..5953e07 --- /dev/null +++ b/template/index.md @@ -0,0 +1,36 @@ +Title: Accueil +Date: {DATE_DIGITS} 09:00 +URL: +save_as: index.html +Category: Home +JsonLD: { "@context": "https://schema.org", "@type": "WebPage", "name": "Accueil", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "{DATE_UTC} 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } + + + +La Craft Letter est une newsletter hebdomadaire dans laquelle je partage des articles +issues de ma veille technologique. Vous y trouverez des articles relatifs au développement logiciel d'une façon générale, qu'il soit front-end, back-end ou autre. Mais aussi des articles consacrés à l'architecture logicielle, la méthodologie, les outils, des projets open source, des conférences... + +Pour savoir qui je suis, ou pourquoi j'écris cette lettre, je vous invite à vous lire l'édito du [premier numéro]({filename}/newsletter/craft-letter-1.md). + + + + +
+ +--- + +# Archives + diff --git a/template/newsletter.md b/template/newsletter.md index 721b199..6ea09ad 100644 --- a/template/newsletter.md +++ b/template/newsletter.md @@ -1,25 +1,5 @@ Title: Lettre n°{LETTER_NUMBER} - {DATE} -Date: {DATETIME} +Date: {DATE_DIGITS} 09:00 Category: Newsletter - - - +JsonLD: - -