Quotidien Shaarli
January 19, 2026
L’article « Tests & Cluedo : enquêtez sur votre code » utilise une métaphore policière pour expliquer les différents types de tests en développement logiciel. Le test unitaire isole une classe (comme un interrogatoire en salle blanche) en utilisant des doublures (mocks) pour éliminer les dépendances externes, permettant de cibler précisément la source d’un bug. Le test fonctionnel reconstitue le crime en testant l’intégration des composants (router, controller, service, template) dans un environnement réel, mais sans interface graphique. Enfin, le test End-to-End (E2E) simule l’expérience utilisateur complète avec un vrai navigateur, utile pour les parcours critiques, mais coûteux en temps et en maintenance. L’auteur recommande une stratégie en pyramide : privilégier les tests unitaires (rapides et précis), compléter avec des tests fonctionnels, et réserver les tests E2E aux fonctionnalités clés. L’approche proactive du TDD (Test Driven Development) est encouragée pour anticiper les bugs plutôt que de les chasser après coup. Un guide pratique et imagé pour bien structurer ses tests avec PHPUnit.
L'auteur partage son expérience d'obtention des cinq certifications officielles Kubernetes de la CNCF, un parcours initié en 2025 et aboutissant au titre de Kubestronaut. Il détaille les certifications (KCNA, KCSA, CKA, CKAD, CKS), les coûts initiaux élevés (plus de 1500€) et les stratégies pour les réduire (promotions, bundles), ainsi que les défis rencontrés. Il conclut par une réflexion sur la valeur de ces certifications et partage des ressources supplémentaires. Un retour d'expérience utile pour ceux intéressés par la certification Kubernetes.
En 2026, l'utilisation d'outils d'IA comme Copilot ou ChatGPT pour générer du code crée des "zones mortes" de 5 à 15 secondes dans le flux de travail des ingénieurs, fragmentant leur journée et réduisant leur productivité. Ces micro-pauses invitent aux distractions, brisant la concentration et le travail en profondeur. L'article propose un protocole "AI Detox" pour maintenir l'état de flux et éviter le coût caché du changement de contexte, qui inclut la perte de temps et la détérioration de la qualité du code.
Biome est une nouvelle toolchain écrite en Rust qui promet de remplacer ESLint, un outil de linting pour JavaScript, en offrant des performances bien supérieures. Contrairement à ESLint qui tourne sur Node.js, un langage interprété et single-threaded, Biome est un binaire natif, compilé et optimisé, utilisant une architecture parallèle. Il intègre également un formatter et un organiseur d'imports, réduisant ainsi la fragmentation des outils actuels. De plus, Biome peut être intégré dans des projets PHP via Composer, sans nécessiter Node.js. L'adoption de Biome est justifiée par son efficacité, faisant le même travail 100 fois plus vite et consommant 10 fois moins de mémoire.
Le FOUC (Flash of Unstyled Content) n'est pas un simple bug graphique mais une faille d'architecture frontend qui impacte l'expérience utilisateur et le référencement. Ce phénomène se manifeste par un clignotement de contenu non stylisé avant l'affichage final, ce qui peut être particulièrement problématique avec les thèmes sombres. Pour l'éviter, il est crucial de maîtriser le Critical Rendering Path en injectant un script synchrone dans le <head> pour appliquer immédiatement le thème approprié, garantissant ainsi un premier affichage correct sans flash.
Ce billet de blog décrit la configuration d'un Mini PC en tant que serveur domestique sous NixOS, centralisant plusieurs services précédemment dispersés sur différents appareils. L'auteur, insatisfait de la complexité et du manque de cohérence de son ancien système, a opté pour une solution plus intégrée et mieux documentée. Le serveur héberge désormais des services comme Pihole, Syncthing, Jellyfin, Home Assistant et Music Assistant. Le choix de NixOS permet une gestion simplifiée et déclarative des configurations, évitant les manipulations manuelles et les configurations éparses. L'auteur partage son expérience et les avantages de cette approche, tout en mentionnant les limitations de ses anciens appareils.
Ce billet explique comment sécuriser une application Symfony avec une double authentification (2FA) robuste en utilisant le bundle SchebTwoFactorBundle. L'auteur décrit une architecture sécurisée où le secret TOTP est géré côté backend, avec une implémentation stricte utilisant des classes anonymes en lecture seule pour encapsuler la configuration TOTP. Il met en avant l'importance de ne pas réinventer la crypto et de déléguer la gestion de la 2FA à une bibliothèque éprouvée pour éviter les failles d'implémentation. L'article détaille également la configuration du bundle et les bonnes pratiques à adopter pour une sécurité optimale.
Ce billet technique explore la transition des annotations vers les attributs PHP dans l'écosystème Symfony, soulignant les avantages des métadonnées natives introduites avec PHP 8. Les annotations, basées sur des commentaires DocBlocks, posaient des problèmes structurels comme l'absence de validation en temps réel, des performances médiocres et un refactoring risqué. Les attributs, en revanche, sont du code typé et performant, intégrés au langage et accessibles via la Reflection API. Symfony 8 utilise ces attributs pour simplifier l'injection de dépendances (Autowire), l'hydratation d'entités (MapEntity), la validation de payloads (MapRequestPayload) et la gestion de l'héritage (Override), réduisant ainsi la complexité du code et améliorant la maintenabilité.
L’article présente une sélection d’essais influents qui ont marqué la pensée et les pratiques de l’auteur en tant qu’ingénieur logiciel. Parmi les textes cités, on retrouve des classiques comme « Choose Boring Technology » de Dan McKinley, qui prône l’utilisation de technologies éprouvées pour éviter les risques inutiles, « Parse, Don’t Validate » d’Alexis King, qui encourage à transformer les données en types riches pour éliminer les états invalides, ou « Things You Should Never Do, Part I » de Joel Spolsky, mettant en garde contre les réécritures complètes de code. D’autres essais, comme « The Majestic Monolith » de DHH ou « The Rise of ‘Worse is Better’ » de Richard P. Gabriel, remettent en question les tendances architecturales (microservices, perfectionnisme) au profit de solutions pragmatiques et adaptées au contexte. L’auteur souligne aussi l’importance de la qualité (« Software Quality at Top Speed » de Steve McConnell) et de la valeur métier (« Don’t Call Yourself a Programmer » de Patrick McKenzie). Enfin, des conseils plus larges, comme « How To Become a Better Programmer by Not Programming » de Jeff Atwood, rappellent que les compétences techniques ne suffisent pas : comprendre le domaine, communiquer et éviter la complexité inutile sont tout aussi cruciaux. Une lecture inspirante pour repenser sa pratique du développement.