Dans cet article, Milan Milanović partage les cinq livres qui ont marqué sa carrière d’ingénieur et son évolution vers le poste de CTO. Il explique comment "The Pragmatic Programmer" lui a appris à écrire du code professionnel, durable et adaptable, en insistant sur l’importance de l’itération rapide et de la responsabilité collective. "Designing Data-Intensive Applications" a transformé sa vision de l’architecture des systèmes, en mettant l’accent sur les compromis entre cohérence, disponibilité et tolérance au partitionnement, ainsi que sur la rigueur dans le choix des bases de données. "A Philosophy of Software Design" l’a aidé à lutter contre la complexité du code en privilégiant des modules profonds et bien conçus, faciles à maintenir. "Thinking, Fast and Slow" de Daniel Kahneman lui a révélé l’impact des biais cognitifs sur la prise de décision, l’incitant à adopter une approche plus analytique et moins intuitive. Enfin, "The 7 Habits of Highly Effective People" a renforcé ses compétences en leadership, en lui apprenant à se concentrer sur ce qu’il peut contrôler, à écouter activement et à investir dans son développement personnel. Ces ouvrages, au-delà des compétences techniques, lui ont offert des modèles mentaux essentiels pour devenir un meilleur architecte, décideur et leader. Une lecture inspirante pour quiconque souhaite allier expertise technique et croissance personnelle.

Un mémo des actions à faire pour passer de Debian 12 à 13

L'auteur présente 3 techniques pour déclencher un téléchargement de fichier :

• un attribut introduit en HTML5
• la simulation d'un clic en JavaScript, par exemple suite à une action utilisateur
• dans le cas du téléchargement de données générées dynamiquement, les transformer en Blob et utiliser la méthode précédente

Le débat entre monolithe et microservices évolue vers un équilibre pragmatique : la simplicité, l’expérience développeur et la maintenabilité deviennent prioritaires. Les entreprises, après avoir expérimenté les coûts élevés et la complexité des microservices, se tournent de plus en plus vers des architectures modulaires ou des monolithes bien structurés, comme en témoignent des exemples comme Amazon Prime Video, qui a réduit ses coûts de 90 % en revenant à une approche monolithique. La culture du "vibecoding" (optimisation du bien-être et de la productivité des développeurs) favorise aussi les monorepos et les architectures centralisées, tout en intégrant des outils modernes pour garder une flexibilité. L’enjeu n’est plus de choisir un camp, mais d’adapter l’architecture au contexte, en privilégiant la clarté, la résilience et l’alignement d’équipe, avec la possibilité de basculer entre les deux approches selon les besoins. Les outils comme Terraform, les devcontainers ou les CI/CD avancées permettent désormais de repenser les choix architecturaux avec plus d’intention et moins de dogmatisme.

Les branches divergentes : source de conflits en push/pull
Erreurs classiques :

! [rejected] main -> main (non fast-forward)
fatal: Need to specify how to reconcile divergent branches.

Qu’est-ce qu’une branche divergente ?
Local et distant ont chacun des commits que l’autre n’a pas.

4 états possibles avec une branche distante :

1. À jour
2. Besoin de pull
3. Besoin de push
4. Divergée (il faut choisir comment résoudre le conflit)

Comment détecter une divergence ?

git fetch
git status
# Exemple de sortie :
# "Your branch and ‘origin/main’ have diverged, and have 1 and 1 different commits each."

Solution rapide :

git pull --rebase

(Mais il existe d’autres options, comme merge.)

À retenir :

• git fetch récupère les derniers commits.
• git pull = git fetch + git merge (ou rebase).

Git affiche constamment des diffs – mais parfois, ils semblent étranges.

Pourquoi ?

• Git ne comprend pas les intentions : un renommage (git mv old.py new.py) est traité comme une suppression + ajout.
• L’algorithme de diff compare simplement deux versions et essaie de résumer les changements de façon lisible… mais pas toujours avec succès.

Astuce :

• Git propose plusieurs algorithmes de diff. Par exemple, pour mieux gérer les réorganisations de code :

  git diff --histogram

Git utilise un processus de commit en 2 étapes :

1. Ajouter les modifications à la zone de staging (git add, git rm, git mv).
2. Valider avec git commit.

La zone de staging, 3 noms pour une seule chose :

• staged (--staged)
• cache (--cached)
• index (--keep-index)

Astuces :

• git add -p permet de commiter seulement certaines parties d’un fichier.
• git diff ne montre que les modifications non staged :
  • git diff HEAD → toutes les modifications non commitées.
  • git diff --cached → seulement les modifications staged.
• git commit -a ne prend pas en compte les nouveaux fichiers (il faut les add avant).

Git n’a pas de bouton "Annuler"
Pas de unadd, uncommit, unmerge ou unrebase. À la place, il y a git reset – puissant, mais dangereux.

Comment fonctionne git reset ?

• La plupart des commandes Git avancent la branche (git commit, git merge, git pull).
• git reset peut déplacer la branche n’importe où : en arrière, en avant, ou "de côté".
• Exemple : git reset HEAD^ force la branche à pointer sur le commit parent, et déstage les changements.

Options clés :

• Par défaut : conserve les modifications dans le répertoire de travail.
• --hard : supprime les modifications non commitées (attention, irréversible !).

Risques :

• Facile de "perdre" des commits en reculant une branche.
• Avec --hard, perte définitive des changements non commités.

Le reflog Git, c’est quoi ?
Un historique de tous les IDs de commit qu’une branche, un tag ou HEAD a déjà pointés. Utile pour retrouver des commits "perdus".

Différences avec git log :

• Le reflog est local (non partagé entre dépôts).
• Il montre l’état des branches avant un rebase (contrairement à git log).
• Les entrées de plus de 90 jours peuvent être supprimées par git gc.

Comment l’utiliser ?

1. Lancer git reflog (ou git reflog BRANCH pour moins de bruit).
2. Chercher un message de commit pertinent.
3. Inspecter le commit avec git show $COMMIT_ID ou git log $COMMIT_ID.
4. Récupérer le commit avec git reset --hard $COMMIT_ID ou git branch $NAME $COMMIT_ID.

Limites :

• Le reflog d’une branche est supprimé si la branche l’est.
• Inutile pour récupérer un stash supprimé (git stash drop).
• Les entrées ne correspondent pas toujours aux commandes Git exécutées.

Dernier recours :
Si le commit n’est plus dans le reflog, utiliser git fsck pour lister les commits non référencés.

Exposer son localhost sur internet est indispensable pour tester des webhooks, partager des démos en direct, ou tester sur des appareils mobiles réels. L’outil open source Tunnelmole permet de créer un tunnel sécurisé entre un serveur local et une URL publique en quelques secondes. Après avoir lancé son serveur local (ex: localhost:3000), il suffit d’installer Tunnelmole (npm install -g tunnelmole ou via un script d’installation), puis de lancer tmole 3000 pour obtenir une URL publique HTTPS accessible partout. Idéal pour le développement, le débogage ou la collaboration, Tunnelmole est transparent, open source et permet même l’auto-hébergement pour plus de contrôle. Une solution simple et efficace pour sortir de l’isolement de localhost.

Ce dépôt propose une collection d’agents personnalisés pour Claude Code, conçus pour assister les développeurs dans diverses tâches.

Installation

• Pour un projet spécifique : Copier les agents dans .claude/agents/ à la racine du projet.
• Pour une utilisation globale : Copier les agents dans ~/.claude/agents/.

Agents disponibles

• code-refactorer : Aide au refactoring de code
• content-writer : Rédaction de contenu
• frontend-designer : Assistance en design frontend
• prd-writer : Rédaction de documents de spécifications produit
• project-task-planner : Planification de projets et découpage des tâches
• security-auditor : Audit de sécurité
• vibe-coding-coach : Coaching et guidance en codage

Utilisation
Une fois installés, Claude Code détecte et utilise automatiquement ces agents selon les besoins.

Symfony 7 utilise les attributes PHP (syntaxe #[...]) pour remplacer les annotations et déclarer des métadonnées directement dans le code. L’article montre comment créer des attributes sur mesure (ex : #[Audit] pour le logging, #[FeatureToggle] pour gérer des fonctionnalités, #[RequiresRole] pour la sécurité, #[Throttle] pour limiter les requêtes) et les exploiter via des event listeners. Ces outils simplifient la maintenance, évitent la duplication de code et rendent le comportement du code plus explicite. Les attributes peuvent aussi cibler des classes et être packagés en bundles réutilisables. Une fonctionnalité puissante pour structurer vos applications Symfony de manière déclarative et élégante.

L'auteur explique pourquoi repenser les architectures logicielles en privilégiant les événements plutôt que les requêtes synchrones. Au lieu de s’appuyer sur le modèle classique « demande/réponse », l’approche event-driven (EDA) émet des faits immuables (ex : UserSignedUp, OrderPlaced) via des brokers (Kafka, RabbitMQ, etc.), permettant un découplage total, une scalabilité asynchrone et une observabilité native. Les avantages sont majeurs : flexibilité, extensibilité sans modifier les sources, et traçabilité des actions. Des géants comme Shopify, Netflix ou Stripe l’utilisent pour synchroniser des services, déclencher des workflows ou alimenter l’analytics. Attention cependant aux pièges : surcharge des payloads, absence d’idempotence, ou manque de versioning. L’EDA n’est pas une solution universelle (coûts, complexité accrue), mais elle transforme la résilience et l’évolutivité des systèmes — à condition d’adopter une discipline rigoureuse et de traiter les événements comme des contrats versionnés.

6 semaines avec Claude Code : Orta Therox (Puzzmo) raconte comment cet outil d’IA a révolutionné sa productivité, lui permettant de réaliser en solo des mois de tech debt (migrations, tests, refactoring, etc.) en quelques semaines, sans surcharge. Claude Code agit comme un pair programmer ultra-rapide, accélérant prototypage et maintenance, tout en laissant l’humain garder le contrôle et la responsabilité finale. Une avancée majeure, mais qui pose question sur l’évolution du métier de dev.

Balises <strong>, <b>, <em>, <i> : quand et pourquoi les utiliser ?
En HTML, le choix entre ces balises dépend avant tout de la sémantique : <strong> et <em> apportent du sens (importance ou emphase, utiles pour les lecteurs d’écran), tandis que <b> et <i> servent à une distinction visuelle ou typographique sans valeur sémantique. <strong> souligne un contenu crucial (avertissements, instructions), <em> modifie le sens d’une phrase par l’emphase. <b> attire l’attention sans importance particulière, et <i> s’emploie pour des termes techniques, noms d’œuvres ou mots étrangers. Pour un style purement décoratif, privilégiez le CSS avec <span>. L’objectif : séparer structure (HTML) et présentation (CSS) pour un code propre et accessible.

Points clés

1. L’internationalisation, bien plus que la traduction

L’i18n ne se limite pas à traduire du texte : elle inclut aussi le formatage des dates, des nombres, des listes, la pluralisation, etc., selon les attentes culturelles de chaque locale. L’API Intl de JavaScript offre une solution native, performante et standardisée pour gérer ces aspects, sans dépendre de bibliothèques tierces lourdes.

2. Qu’est-ce qu’une locale ?

Une locale (en-US, fr-FR, ja-JP, etc.) définit non seulement la langue, mais aussi la région, le script, et d’autres préférences culturelles. Elle permet d’adapter finement l’affichage des données.

3. Les principaux outils de l’API Intl

• Intl.DateTimeFormat : Formate les dates et heures selon les conventions locales (ex. : 27/06/2025 vs June 27, 2025).
• Intl.NumberFormat : Affiche les nombres, devises et unités avec les séparateurs et symboles locaux (ex. : 123,456.79 $ vs 123.456,79 €).
• Intl.ListFormat : Génère des listes naturelles avec les conjonctions adaptées (ex. : « pommes, oranges et bananes » vs « apples, oranges, and bananas »).
• Intl.RelativeTimeFormat : Affiche des expressions temporelles relatives (« hier », « dans 3 mois ») de manière localisée.
• Intl.PluralRules : Détermine la catégorie de pluralisation (singulier/pluriel, mais aussi « zero », « one », « two », etc. pour l’arabe).
• Intl.DisplayNames : Fournit les noms localisés des langues, régions ou scripts (ex. : « French » vs « français »).

4. Avantages

• Natif : Intégré à tous les navigateurs modernes, sans besoin de polyfills.
• Performant : Réduit la taille des bundles et améliore les performances.
• Flexible : Permet de surcharger la locale par défaut (via navigator.language ou un attribut lang en HTML).

5. Cas d’usage

• Afficher des prix, dates ou listes adaptés à l’utilisateur.
• Gérer la pluralisation complexe (ex. : arabe, russe).
• Éviter les solutions maison ou les bibliothèques externes.

6. Limites

L’API Intl gère le formatage des données, mais pas la traduction de contenu, la typographie RTL/LTR, ou les nuances culturelles profondes.

7. Ressources utiles

• Documentation MDN sur Intl
• Spécification ECMA-402

Pourquoi l’utiliser ?
L’API Intl simplifie l’internationalisation tout en respectant les standards du web. Idéal pour des applications multilingues légères et maintenables.

L’article met en lumière un piège courant en JavaScript : l’utilisation de Array.includes dans une boucle (comme source.some(item => target.includes(item))) peut devenir extrêmement coûteuse en performance avec des tableaux volumineux, car la complexité algorithmique passe à *O(nm). Par exemple, avec des tableaux de 60 000 éléments, l’exécution peut prendre plusieurs secondes. La solution consiste à utiliser des structures de données optimisées pour des recherches en temps constant, comme un objet, une Map, ou mieux, un Set (new Set(target)), réduisant la complexité à O(n + m)** et rendant le code quasi instantané même pour de très grands jeux de données. Une astuce simple, mais cruciale pour éviter des goulots d’étranglement inattendus dans le code JavaScript.

L'article explique pourquoi privilégier l’immuabilité en programmation orientée objet permet d’éviter des bugs subtils liés à l’état partagé. L’auteur illustre le problème avec un exemple en PHP où la mutation d’un objet DateTime affecte involontairement une autre partie du code, rendant le débogage difficile. Les objets immuables (comme DateTimeImmutable) évitent ce genre de piège en retournant une nouvelle instance à chaque modification, plutôt que de modifier l’original. Les avantages incluent une meilleure prévisibilité du code, une réduction des effets de bord et une gestion plus sûre de la concurrence. Cependant, l’immuabilité peut introduire un surcoût en performance et n’est pas toujours adaptée (ex. : objets builders éphémères). L’article conclut en encourageant à adopter l’immuabilité par défaut, sauf besoin contraire, pour un code plus robuste et maintenable.

Ce comic explique simplement ce qu’est un dépôt distant (remote) dans Git : un autre dépôt vers lequel on pousse (push) ou depuis lequel on tire (pull) du code. Un remote peut être hébergé sur GitHub, GitLab, un serveur personnel, ou même un dossier local. La syntaxe git push origin main signifie "pousser la branche main vers le remote nommé origin". Les remotes sont configurés dans .git/config avec un nom et une URL, et peuvent utiliser différents protocoles (HTTP, SSH, ou local). Les remotes sont aussi le lieu de "drames" typiques, comme les conflits lors d’un git pull après qu’un·e collègue a réécrit un fichier. Astuce : activer push.autoSetupRemote true pour simplifier le suivi des branches. Une introduction claire et pratique pour comprendre l’interaction entre dépôts locaux et distants !

Ce comic illustre comment des commits peuvent se "perdre" dans Git, même s’ils restent souvent stockés quelque part. Les causes fréquentes : git commit --amend, git rebase, la suppression d’une branche non fusionnée ou git stash drop. Trois niveaux de gravité sont décrits : "énervant" (le commit n’est plus référencé par une branche/étiquette mais reste facile à retrouver), "cauchemar" (il faut fouiller tous les commits), et "catastrophe" (le commit est supprimé). Heureusement, Git conserve généralement les commits "perdus" : on peut les retrouver via le reflog pour les cas simples, ou git fsck pour les situations plus complexes. Une bonne raison de ne pas paniquer et de connaître ces outils de récupération !