60 lines
6.8 KiB
Markdown
60 lines
6.8 KiB
Markdown
Title: Lettre n°17 — 30 mars 2026
|
||
Date: 2026-03-30 09:00
|
||
Category: Newsletter
|
||
JsonLD: <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°17", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Mar 30 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/" } } </script>
|
||
<img class="logo" alt="Logo Craft Letter" src="{static}/images/craftletter.svg">
|
||
|
||
## Ce que les développeurs fonctionnels n’ont pas compris à propos des systèmes
|
||
|
||
Ian Duncan pense que les développeurs qui utilisent des langages fonctionnels fortement typés ont tendance à [confondre la correction du code avec celle du système](https://www.iankduncan.com/engineering/2026-02-09-what-functional-programmers-get-wrong-about-systems/)🇬🇧. Les garanties apportées par ces langages éliminent des classes entières d’erreurs. Mais cela ne suffit pas à certifier que les programmes se comporteront correctement en production —en tout cas pas dans le cas des services Web, sur lesquels porte l’article. En effet, ce qui doit fonctionner c’est le système complet, qui n’est pas limité à un programme : il peut en comporter plusieurs instances, ainsi qu’une base de données, des serveurs divers, etc.
|
||
|
||
Les développeurs qui utilisent d’autres langages souffrent du même travers, mais dans une moindre mesure, car ils ne peuvent pas avoir autant confiance dans le code vérifié par le compilateur.
|
||
|
||
## Pourquoi un thème clair est préférable à un thème sombre
|
||
|
||
Jben explique, de façon très détaillée, [pourquoi un thème clair est souvent préférable à un thème sombre](https://linuxfr.org/users/jben/journaux/je-hais-les-themes-sombres-et-je-peux-l-expliquer)🇫🇷. En bref : c’est plus facile à lire par les personnes souffrant d’astigmatisme ou de myopie, c’est-à-dire une large partie de la population. Et ça ne concerne pas que nos IDE, mais aussi les présentations.
|
||
|
||
Un contre-exemple est cité dans les commentaires, mais il est marginal : c’est celui d’un écran de contrôle consulté de nuit par des personnes qui ne peuvent pas en régler la luminosité.
|
||
## Des palettes de couleurs pour les personnes qui ne les voient pas bien
|
||
|
||
Une personne sur vingt souffre d’un problème de vision des couleurs. David Nichols met à disposition un outil simple qui permet de [s’assurer que les couleurs que vous avez choisies sont distinguables](https://davidmathlogic.com/colorblind/)🇬🇧 par toutes les personnes qui visitent votre site. Il fournit aussi quelques exemples de palettes prédéfinies qui prennent en compte ces problèmes.
|
||
|
||
## Ces détails qui rendent les interfaces plus agréables
|
||
|
||
Jakub Krehel fournit une liste d’astuces qui permettent de [peaufiner les IHM web](https://jakub.kr/writing/details-that-make-interfaces-feel-better)🇬🇧, avec des exemples interactifs.
|
||
|
||
La différence saute aux yeux pour certains exemples. Pour d’autres, c’est beaucoup plus subtil. À un point tel que je n’ai toujours pas compris l’exemple d’animation des icônes…
|
||
|
||
## Tansu
|
||
|
||
Peter Morgan a développé [Tansu](https://www.infoq.com/news/2026/03/tansu-stateless-kafka-compatible/)🇬🇧, un message broker alternatif à Kafka, qui en utilise le protocole, mais repose sur une architecture beaucoup plus simple. Tansu s’appuie sur des back-ends existants pour le stockage et la résilience, plutôt que de chercher à développer des workers résilients comme ceux de Kafka. Ces back-ends peuvent être des systèmes compatibles S3, Postgresql ou Sqlite. Contrairement à Kafka, Tansu vérifie le format des messages, plutôt que de déléguer cette tâche aux clients.
|
||
Tansu ne semble pas être tout à fait prêt pour la production, mais c’est un projet à suivre.
|
||
|
||
## Comment la Nasa conçoit des systèmes résilients
|
||
|
||
Lorsqu’on parle d’un appareil qui quitte le sol de notre planète, parfois pour s’en éloigner de plusieurs millions de kilomètres, [la gestion des défaillances matérielles et des erreurs logicielles](https://increment.com/software-architecture/in-space-no-one-can-hear-you-kernel-panic/)🇬🇧 prend une toute autre dimension. Surtout s’il s’agit d’une navette ou autre fusée qui embarque des humains à son bord.
|
||
|
||
|
||
## Les fichiers magiques de Git
|
||
|
||
Au-delà du bien connu `.gitignore`, [Git lit plusieurs autres fichiers de configuration](https://nesbitt.io/2026/02/05/git-magic-files.html)🇬🇧.
|
||
|
||
Ce que ne mentionne pas Andrew Nessbit dans cet article, c’est que vous pouvez avoir, en complétement de ces fichiers, des configurations personnelles, qui ne seront pas publiées sur le dépôt Git contrairement aux précédentes. Je les utilise pour ne pas polluer avec mes préférences les dépôts Git des projets auxquels je contribue.
|
||
|
||
Pour ignorer des fichiers dans tous vos projets suivis par Git, vous pouvez [définir un fichier .gitgnore global](https://gist.github.com/subfuzion/db7f57fff2fb6998a16c)🇬🇧. Je recommande d’y déclarer les fichiers ou répertoires générés par votre IDE. Cela garantit que ce sera fait lorsque vous démarrer un nouveau projet ; et cela évite d’ajouter dans `.gitignore` du contenu qui ne concerne qu’une personne dans l’équipe, car il peut y avoir autant d’IDEs que de contributeurs.
|
||
|
||
Pour ignorer du contenu spécifique à un clone d’un projet, il suffit de le déclarer dans `.git/info/exclude`, avec la même syntaxe que dans `.gitignore`. Vous voyez ce fichier que vous devez penser à ne pas inclure, à chaque fois que vous créez un commit ? C’est là qu’il faut le déclarer. Étant situé dans le dossier `.git`, le contenu du fichier `exclude` ne sera pas suivi par Git, contrairement à celui de `.gitignore`.
|
||
|
||
## Npmx
|
||
|
||
[Npmx](https://npmx.dev/blog/alpha-release)🇬🇧 est une nouvelle interface pour naviguer parmi les paquets NodeJS. Il s’agit d’une réponse aux frustrations de nombreux développeurs insatisfaits de leur expérience avec npm.
|
||
Npmx fournit des informations indisponibles sur Npm, sur les performances des modules par exemple. Npmx est encore en version alpha mais progresse rapidement.
|
||
|
||
|
||
## Écrire des extensions PHP en Rust
|
||
|
||
PHP suit la tendance mainstream en offrant la possibilité d’écrire des [extensions en Rust](https://github.com/extphprs/ext-php-rs)🇬🇧, et plus seulement en C.
|
||
|
||
## Paris Web 2026
|
||
|
||
Paris Web est un événement consacré, sans surprise, au développement Web. L’édition 2026 se tiendra du 24 au 26 septembre. [L’appel à sujets](https://www.paris-web.fr/actualites/appel-a-sujets-edition-2026-ouvert)🇫🇷 pour les conférences et les ateliers est ouvert jusqu’au 12 avril.
|