L’article de Stack Overflow souligne que le rôle d’un architecte logiciel ne se limite pas à écrire du code, mais consiste surtout à déployer des idées dans des systèmes humains : convaincre, aligner et faire collaborer des équipes aux perspectives variées. Pour cela, le principal outil de l’architecte n’est pas un langage de programmation, mais la rédaction de documents clairs et structurés.
Points clés :
- La documentation comme levier : Les architectes utilisent des documents (Confluence, Google Docs, Notion, etc.) pour formaliser des propositions, des designs techniques ou des analyses, et ainsi obtenir l’adhésion des parties prenantes.
- Principe de base : Privilégier la simplicité (bullet points, titres clairs) et l’utilité immédiate plutôt que la perfection formelle. Un document doit permettre à chacun de trouver rapidement l’information dont il a besoin.
- Types de documents impactants :
- Architecture overview : Schéma ou description des composants d’un système pour faciliter la compréhension et l’onboarding.
- Dev design : Détail des modifications prévues pour recueillir des feedbacks avant de coder.
- Project proposal : Argumentaire pour justifier l’allocation de ressources à un projet.
- Developer forecast : Alerte sur les risques potentiels d’une décision technique.
- Technology menu : Guide pour standardiser les choix technologiques.
- Problem statement : Cadre pour résoudre un problème complexe en équipe.
- Postmortem : Analyse blameless d’un incident pour éviter sa répétition.
Méthode recommandée :
- Organisation chronologique : Classer les documents par sprint/année plutôt que par thème, car la recherche textuelle est plus efficace que la navigation par dossiers.
- Culture de la documentation : Encourager l’écriture rapide et itérative, avec des relectures ciblées, plutôt que des mises à jour constantes.
- Objectif : Rendre les idées accessibles, actionnables et pérennes, même si le document devient obsolète.
En résumé, un architecte excelle moins par sa maîtrise technique que par sa capacité à structurer et communiquer des idées pour faire avancer les projets, en transformant les blocages humains en processus collaboratifs. Une compétence clé pour ceux qui veulent rester techniques tout en élargissant leur impact.
L’auteur partage son passage de BorgBackup à Restic pour ses sauvegardes personnelles sous Archlinux, séduit par sa simplicité, sa documentation claire et sa compatibilité avec SFTP. Il détaille une configuration minimaliste : sauvegardes incrémentales vers un serveur distant, planification via systemd (2x/jour en semaine), gestion des rétentions (3 mois de sauvegardes hebdomadaires), et montage des instantanés en local. Restic s’intègre même comme backend pour Déjà Dup (GNOME 49). Un outil efficace, moderne, et respectueux du principe 3-2-1.
L’article du blog Ippon explique comment personnaliser GitHub Copilot dans VS Code grâce aux custom instructions, afin d’adapter ses suggestions à vos conventions de code, frameworks et besoins spécifiques. Ces instructions, définies via des fichiers Markdown (comme .github/copilot-instructions.md), permettent de guider Copilot sur le style de code, les bibliothèques à utiliser, la structure des livrables, ou encore le niveau de détail des réponses. Trois types de règles existent : personnelles (globales), par dépôt (spécifiques à un projet), et organisationnelles (pour uniformiser les standards d’une équipe). L’article illustre l’impact de ces règles avec un exemple concret de widget Flutter, montrant comment Copilot génère un code plus aligné avec les attentes (design, localisation, gestion d’état) lorsqu’il est bien configuré. Il détaille aussi l’utilisation des prompt files pour des actions récurrentes et le mode Agent de Copilot, capable de modifier plusieurs fichiers ou d’exécuter des tâches complexes. Enfin, des bonnes pratiques et outils (comme la génération automatique de règles via VS Code) sont présentés pour optimiser l’intégration de Copilot dans un workflow, en évitant les contradictions et en maximisant la pertinence des suggestions. Une ressource utile pour transformer Copilot en un véritable partenaire de développement.
Ce guide pratique explique comment maîtriser les migrations de base de données avec Symfony 7 et Doctrine. Il couvre l'installation d'un projet Symfony, la création d'entités, la génération et l'application des migrations, ainsi que leur réversion. L'article détaille aussi la personnalisation des migrations (méthodes preUp, postUp, preDown, postDown, gestion des transactions, etc.), l'évolution des propriétés d'entités, et propose une solution pour éviter l'erreur récurrente de création du schéma public avec PostgreSQL. Un template personnalisé pour les migrations et un listener Doctrine sont présentés pour optimiser le workflow. Enfin, une cheatsheet récapitule les commandes utiles pour gérer les migrations efficacement. Idéal pour les développeurs souhaitant approfondir la gestion des schémas de base de données dans Symfony.
L’article explore les possibilités créatives offertes par la propriété CSS shape-outside, qui permet de faire épouser le flux de texte aux contours d’une image ou d’une forme personnalisée, au lieu de se limiter à un rectangle classique. L’auteur illustre son propos avec des exemples concrets, comme un site web pour une artiste de country fictive, Patty Meltt. Il montre comment utiliser shape-outside pour créer des mises en page dynamiques et immersives : text wrapping autour de portraits, d’instruments de musique, ou même de montages photo, en jouant avec les canaux alpha des images ou des clip-path. L’article détaille aussi des astuces pour simuler un centrage d’image ou contourner les limites des rotations CSS. L’objectif ? Rendre les longs contenus visuellement plus engageants et moins statiques, en intégrant images et texte dans une composition harmonieuse. Des exemples interactifs sont disponibles dans un lab en ligne pour expérimenter ces techniques. Une lecture inspirante pour les designers et développeurs web cherchant à ajouter du mouvement et de la personnalité à leurs layouts.
Cet article explique comment créer des décorateurs Python acceptant des arguments, en utilisant une structure à trois niveaux : une fonction externe pour les paramètres, une fonction intermédiaire pour le décorateur, et une fonction interne pour l'exécution. L'article illustre ce concept avec des exemples concrets comme un décorateur de logging configurable, un système de réessai, une validation de plage, et une limitation de débit. Il montre aussi comment gérer les arguments optionnels et comment implémenter des décorateurs sous forme de classes. L'idée clé est que les décorateurs avec arguments agissent comme des "fabriques de décorateurs", permettant une personnalisation fine du comportement des fonctions décorées. Une lecture utile pour maîtriser l'abstraction et la configuration avancée en Python.
Cet article explore en profondeur le Saga Pattern, une solution élégante pour gérer les transactions distribuées dans les architectures microservices en PHP. Il explique pourquoi les transactions ACID traditionnelles ne fonctionnent pas dans un contexte distribué et comment le Saga Pattern, basé sur des transactions compensatoires et une cohérence éventuelle, permet de contourner ces limites. L'article détaille deux approches d'implémentation (chorégraphie et orchestration), présente des exemples concrets de code, et aborde des défis avancés comme la gestion des timeouts, l'idempotence, les verrous sémantiques, ainsi que des modèles théoriques comme les sagas imbriquées ou parallèles. Une attention particulière est portée sur la persistance de l'état des sagas, la récupération après échec, et la surveillance pour assurer la fiabilité du système. Une lecture essentielle pour les développeurs PHP travaillant sur des systèmes distribués complexes.
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 propose une approche innovante de développement piloté par les spécifications (« spec-driven development ») en utilisant le Markdown comme langage de programmation, avec l’aide d’agents d’IA comme GitHub Copilot. L’idée est de décrire l’intégralité d’une application dans un fichier Markdown (par exemple main.md), qui sert à la fois de documentation et de spécification technique, puis de laisser l’IA générer le code source (ici en Go) à partir de ce fichier. Le workflow repose sur quatre fichiers clés : un README.md pour la documentation utilisateur, un main.md pour la spécification technique (incluant la logique métier, les schémas de base de données, et même des extraits GraphQL), et des prompts (compile.prompt.md, lint.prompt.md) pour guider l’IA dans la génération et l’optimisation du code.
L’avantage principal est de centraliser la logique et la documentation en un seul endroit, évitant les incohérences et facilitant les mises à jour. Le développeur édite le Markdown, demande à l’IA de « compiler » la spécification en code, puis teste l’application. Cette méthode permet une itération rapide et une meilleure synchronisation entre la documentation et l’implémentation. Cependant, la compilation peut ralentir à mesure que le projet grandit, et l’approche nécessite une description claire et précise des attentes. L’auteur envisage d’étendre cette méthode à d’autres langages et d’intégrer des tests automatisés. Une expérience prometteuse, surtout avec les progrès des agents IA, mais qui demande une rigueur dans la rédaction des spécifications.
Cet article compare les architectures standalone et haute disponibilité (HA) pour Kubernetes on-premise, en expliquant comment concevoir et opérer un cluster HA. L’article détaille l’importance de redonder les composants critiques (comme l’API Kubernetes) pour éviter les points de défaillance uniques (SPOF), même si cela peut introduire de nouveaux défis (ex. : un load balancer devant les control planes peut lui-même devenir un SPOF). Il présente aussi une solution de stockage HA avec TrueNAS (exposant des volumes bloc via iSCSI) et Longhorn pour orchestrer la réplication, les snapshots et la reconstruction automatique en cas de panne d’un nœud. L’auteur insiste sur la nécessité de bien dimensionner chaque couche (stockage, réseau, contrôle) pour garantir la résilience du cluster, tout en soulignant que la haute disponibilité commence par la redondance du plan de contrôle et une gestion fine des volumes persistants. Le billet s’inscrit dans une série technique explorant les bonnes pratiques pour opérer Kubernetes en production.
L'article introduit la commande Linux tc (traffic control), utilisée pour simuler et contrôler le trafic réseau. L’article montre comment ajouter un délai de 500 ms aux paquets avec tc qdisc add dev wlp3s0 root netem delay 500ms, puis supprimer cette règle avec tc qdisc del. L’outil netem permet aussi de perdre, dupliquer ou corrompre des paquets, idéal pour tester des conditions réseau difficiles. L’autrice mentionne qu’avec un routeur Linux, on peut même ralentir le trafic d’autres utilisateurs (comme celui d’un frère), et invite à explorer tc qdisc show pour voir les règles actuelles. Le zine complet et d’autres comics sont disponibles via abonnement ou sur le site.
L'article explique comment utiliser la commande ss (socket statistics) sous Linux pour identifier et gérer les processus utilisant un port réseau. L’article montre comment ss -tunapl permet de lister les serveurs en cours d’exécution et d’afficher les PID des processus, utile pour libérer un port occupé (comme le 8080). Les options comme -n (affichage des ports en numérique), -p (affichage des PID), et d’autres (-l, -t, -u) sont détaillées pour filtrer les sockets TCP, UDP ou Unix. L’autrice recommande ss plutôt que netstat, plus ancien et complexe, pour une utilisation plus simple et efficace. Le zine complet et d’autres ressources sont disponibles via abonnement ou sur le site.
Cet article explique la commande Linux ip, utilisée pour visualiser et modifier la configuration réseau. L’article détaille quelques sous-commandes utiles comme ip addr list (affiche les adresses IP des interfaces), ip route list (affiche la table de routage), et montre comment changer une adresse MAC pour contourner des restrictions réseau (par exemple dans les cafés). D’autres options comme ip link (gestion des interfaces), ip neigh (table ARP), et ip xfrm (pour IPsec) sont mentionnées, ainsi que des astuces comme l’utilisation de --color pour une sortie colorée ou --brief pour un résumé. Le zine complet et d’autres comics sont disponibles via un abonnement à la newsletter ou sur le site de l’autrice.
Le positionnement par ancre (anchor positioning) est une nouvelle fonctionnalité CSS qui permet de positionner visuellement un élément par rapport à un autre, indépendamment de leur place dans le DOM. Idéal pour les info-bulles, menus contextuels ou modales, il utilise anchor-name pour définir une ancre et position-anchor pour l’associer à un élément positionné (en absolute ou fixed). Le placement s’effectue via anchor() ou position-area, tandis que anchor-size() permet d’adapter les dimensions de l’élément en fonction de l’ancre. La propriété position-try gère les débordements en proposant des solutions de repli. Compatible avec les navigateurs modernes, cette technique offre une alternative flexible aux méthodes traditionnelles, tout en nécessitant une attention particulière à l’accessibilité. Des outils comme Anchor Tool et des démos pratiques illustrent son potentiel.
L’article explique comment transformer des prompts AI efficaces en assistants personnalisés et réutilisables, évitant ainsi de retaper ou copier-coller les mêmes instructions. L’auteur présente les avantages des assistants AI sur mesure (comme les CustomGPTs, Agents ou Gems) : gain de temps, cohérence, adaptation au contexte spécifique d’une équipe, et capitalisation de l’expertise. Il détaille aussi quand ne pas en créer (tâches ponctuelles, données sensibles, processus complexes, etc.).
Le processus MATCH (Map, Add knowledge, Tailor, Check, Hand off) est proposé pour concevoir un assistant, illustré par l’exemple d’un outil analysant des retours clients. L’article souligne l’importance de partir des besoins utilisateurs, d’ajouter des fichiers de connaissance, et de tester rigoureusement. Enfin, il encourage à créer ses propres assistants plutôt que d’utiliser des modèles publics, pour une meilleure adéquation avec ses workflows et son ton. Une lecture utile pour les équipes souhaitant optimiser leur usage de l’IA au quotidien.
Linear explique dans cet article pourquoi l’entreprise a adopté une politique « zéro bug » : chaque bug signalé est corrigé rapidement (sous 48h pour les priorités hautes, 7 jours pour les autres), sans accumulation dans un backlog. L’idée est née après qu’un bug signalé dans une autre application ait mis cinq ans à être résolu, illustrant l’inutilité de faire attendre les utilisateurs. Pour y parvenir, Linear a d’abord nettoyé son backlog existant (175 bugs en trois semaines), puis mis en place des processus stricts : chaque bug est soit corrigé immédiatement, soit marqué comme « ne sera pas corrigé ». Un tableau de bord permet de suivre les bugs ouverts et de rééquilibrer la charge entre les équipes. Cette approche améliore la qualité du produit, renforce la confiance des utilisateurs (qui voient leurs signalements résolus en un temps record) et influence la culture d’ingénierie, incitant à éviter les bugs dès le développement. Résultat : plus de 2 000 bugs corrigés en un an, et une relation client transformée en collaboration positive. Une politique devenue une valeur centrale, que personne ne souhaite abandonner.
Ce zine démystifie les permissions Unix de façon visuelle et accessible : chaque fichier a trois droits (lecture, écriture, exécution) pour trois catégories (utilisateur, groupe, autres), affichables via ls -l. Les permissions sont représentées en binaire (ex. rw- = 110 = 6), ce qui permet d’utiliser chmod 644 pour définir rapidement rw-r--r--. L’autrice explique aussi les bits spéciaux (setuid, setgid, sticky) et leurs effets, comme un exécutable qui s’exécute toujours en tant que root. Pour les dossiers, les droits changent de sens : r permet de lister, w de créer, et x d’y accéder.
Ce zine explique de façon claire et visuelle comment utiliser la commande ps sous Linux pour lister les processus en cours. L’autrice recommande d’utiliser ps aux pour afficher tous les processus avec leur utilisateur, et détaille des options utiles comme w (pour voir les arguments complets des commandes), e (pour afficher les variables d’environnement), ou encore f (pour un arbre ASCII des processus). Elle souligne aussi que ps supporte trois styles d’arguments (UNIX, BSD, GNU), ce qui peut rendre son utilisation un peu déroutante, et propose des astuces comme ps -eo user,pid,wchan,cmd pour personnaliser les colonnes affichées. Enfin, elle rappelle que des outils comme pstree peuvent compléter ps pour visualiser la hiérarchie des processus.
L’article partage l’expérience d’un lead développeur qui, submergé par la multiplication des responsabilités, a réalisé que son emploi du temps était aussi mal optimisé qu’un code truffé de bugs. Il propose une méthode inspirée du développement logiciel pour "refactorer" son agenda : diagnostiquer ses tâches (en les listant, évaluant leur importance et leur urgence via une matrice d’Eisenhower adaptée), prioriser en distinguant l’urgent de l’important, et planifier avec le time-blocking (réserver des plages fixes pour les tâches récurrentes et laisser 30% de temps libre pour les imprévus). L’auteur insiste sur l’importance de la weekly review pour ajuster son planning, déléguer davantage (comme en pair programming), et ainsi retrouver du temps pour l’essentiel : développer, faire de la veille, ou animer des ateliers. Une approche pragmatique pour éviter le syndrome de la "fonction qui fait tout" et réduire le stress, avec des outils concrets comme la matrice de priorisation et des créneaux sanctuarisés. À tester surtout quand on passe de dev à lead ou manager !
L’article s’intéresse à la fonctionnalité CSS la plus décriée selon le State of CSS 2025 : les fonctions trigonométriques, notamment sin() et cos(). Pourtant, ces fonctions offrent des usages pratiques et créatifs, comme la création de dispositions circulaires (placer des éléments autour d’un cercle), des layouts ondulés (effets de vagues ou entrelacs), ou encore des animations amorties (mouvements réalistes de ressorts ou de pendules). L’auteur explique leur principe via le cercle unité et montre comment les utiliser en CSS pour des effets visuels dynamiques, sans recourir à des valeurs magiques. L’objectif ? Réconcilier les développeurs avec ces outils souvent perçus comme complexes, mais en réalité puissants et accessibles. Une invitation à explorer leur potentiel au-delà des préjugés !