Ali Khil partage une habitude simple mais efficace pour préserver ses soirées en tant qu’ingénieur logiciel : au lieu de prolonger sa journée de travail en se disant « encore 20 minutes », il note les prochaines étapes à réaliser avant de partir. Cette pratique évite l’épuisement, permet de revenir le lendemain avec un esprit frais et une motivation intacte, tout en favorisant un meilleur équilibre entre vie professionnelle et personnelle. Une astuce inspirée par l’expérience, où l’envie de terminer une tâche sur le moment se transforme souvent en heures perdues et en frustration. À la clé, moins de surmenage et des idées nouvelles après une nuit de repos.

Ce shaarli explique comment utiliser Podman comme un substitut à Docker, en permettant l'exécution des commandes Docker habituelles avec Podman. L'article détaille l'installation du paquet podman-docker, qui fournit un script docker émulant les commandes Docker, ainsi que la suppression du message d'avertissement via la création du fichier /etc/containers/nodocker. Il aborde aussi la compatibilité avec docker-compose grâce à l'installation de podman-compose, et présente deux solutions pour gérer le démarrage automatique des conteneurs (via Quadlet ou en activant le service podman-restart). L'objectif est de faciliter la transition pour les utilisateurs habitués à Docker, tout en profitant des avantages de Podman, notamment son absence de démon.

L’auteur partage ses conseils pour en réaliser des efficaces. Le point clé : rien n’est trivial. Il insiste sur la nécessité d’expliquer chaque étape, même celles qui semblent évidentes, car le public peut ne pas maîtriser les bases (où lancer une commande, comment allumer un appareil, etc.). Il recommande de définir le vocabulaire technique, d’expliquer le pourquoi derrière chaque action (ex. : choix d’un outil, respect d’une température), et d’adapter le contenu au public visé (novice, intermédiaire, expert). La précision est essentielle : éviter les formulations vagues comme « suivez la procédure normale », et lister clairement les prérequis (matériel, logiciels, permissions). Autre astuce : tester son tuto en le suivant soi-même ou en le faisant essayer à un débutant pour repérer les oublis ou ambiguïtés. Enfin, il encourage à utiliser un vocabulaire rigoureux (ex. : la RFC 2119 pour distinguer « doit », « devrait », « peut ») et à justifier chaque étape pour éviter erreurs et frustrations. L’objectif ? Rendre le tutoriel accessible, reproductible et sans zone d’ombre, quel que soit le domaine (informatique, cuisine, aéronautique…).

Simon Willison explore dans ce billet la notion de "designing agentic loops", une compétence clé pour tirer parti des agents de codage comme Claude Code ou Codex CLI. Ces outils, capables d’exécuter du code, de corriger des erreurs et d’itérer vers une solution, ouvrent de nouvelles possibilités, mais aussi des risques (commandes dangereuses, exfiltration de données, attaques par rebond). Pour les utiliser efficacement, il recommande de les faire tourner en mode "YOLO" (sans demande de confirmation systématique), mais dans un environnement sécurisé comme GitHub Codespaces ou un conteneur Docker isolé. Il souligne l’importance de bien choisir les outils et les accès (par exemple, limiter les permissions et les budgets pour les API), et d’identifier les problèmes adaptés à cette approche : débogage, optimisation de performances, ou mise à jour de dépendances. L’automatisation des tests et la documentation claire des outils disponibles (via un fichier AGENTS.md) sont essentielles pour maximiser leur utilité. Une réflexion encore émergente, mais prometteuse pour accélérer le développement logiciel.

Cette chronique humoristique de Gee aborde le thème de l’inertie technologique, en prenant pour exemple le clavier, dont les dispositions (QWERTY, AZERTY) et certaines touches (comme "Inser") persistent malgré leur obsolescence ou leur manque d’optimisation. L’auteur souligne que ces choix datent de l’ère des machines à écrire et ne sont pas adaptés aux usages modernes, mais que le coût du changement (apprentissage, incompatibilité avec les autres claviers) freine toute évolution. Il évoque aussi les avantages des logiciels libres, comme GNU/Linux, qui permettent de contourner certaines limites matérielles grâce à des fonctionnalités logicielles (accès facilité aux majuscules accentuées, espaces insécables, etc.). Enfin, il invite à adopter le logiciel libre pour gagner en flexibilité et en modernité, tout en gardant un ton léger et critique envers les habitudes ancrées.

Ce tutoriel explique comment implémenter le Design Pattern Strategy dans Symfony, en partant d’une approche naïve avec des if/else pour aboutir à une solution professionnelle et maintenable. L’objectif est de créer un système d’analyse de céréales (blé, orge, tournesol, etc.) qui puisse s’étendre facilement sans modifier le code existant.

L’auteur détaille trois étapes :

1. Approche naïve avec des if/else ou match (PHP 8+), simple mais peu extensible et difficile à maintenir.
2. Solution optimale avec le Strategy Pattern : chaque type de céréale est géré par une classe indépendante (stratégie) implémentant une interface commune. Symfony utilise des attributs comme #[AutoconfigureTag] et #[AutowireIterator] pour injecter automatiquement les stratégies dans un manager, qui délègue l’analyse à la stratégie adaptée.
3. Avantages : respect du principe ouvert/fermé, testabilité, et extensibilité (ajouter une céréale = ajouter une classe).

Le tutoriel inclut des exemples concrets, des comparatifs, et un projet GitHub pour illustrer la mise en œuvre. Une ressource idéale pour comprendre comment structurer du code Symfony flexible et évolutif.