Cet article explique les language tags, un concept clé pour l'internationalisation (i18n) et la localisation (l10n) des applications web. Il définit ces termes selon le W3C et détaille les standards du Web (RFC 5646, BCP 47) qui régissent les language tags. Ces tags, composés de subtags séparés par des tirets, permettent d'identifier précisément une langue, une écriture, une région ou d'autres variantes. L'article fournit des exemples et des explications sur la syntaxe des language tags, offrant ainsi une compréhension claire de leur utilisation pour adapter les applications à différents marchés linguistiques et culturels.
Ploum exprime son inconfort face aux excuses pour les réponses tardives aux emails, soulignant que les échanges par email sont asynchrones et ne devraient pas générer de pression. Il encourage à ne pas s'excuser pour les délais de réponse, à ne pas justifier les retards par des détails personnels, et à ne répondre que si cela apporte une réelle valeur. Il propose même de reporter la réponse ou de ne pas répondre du tout, surtout si l'email initial n'était pas urgent ou important.
Ce guide pratique oppose logs et métriques pour une meilleure observabilité des systèmes. Les métriques indiquent qu'un problème existe, tandis que les logs expliquent quoi. Les logs, coûteux mais détaillés, sont utiles pour le débogage et la conformité, tandis que les métriques, économiques et rapides, servent aux alertes et aux tableaux de bord. Les logs structurés sont préférables pour leur recherche facilitée. Les quatre signaux clés de Google (latence, trafic, erreurs, saturation) sont essentiels pour surveiller la santé d'un service. Le choix entre logs et métriques dépend de l'objectif et des ressources disponibles.
L'article explore l'importance de la mise en cache au niveau de l'application, en se concentrant sur les pools de cache, les tags et l'invalidation. À travers un projet Symfony réaliste, l'auteur montre comment introduire progressivement la mise en cache, identifier les problèmes en production et améliorer la conception du cache. Les exemples illustrent l'évolution de la mise en cache, en commençant par une approche naïve et en introduisant des techniques plus avancées comme les pools de cache dédiés et l'invalidation fine-grained à l'aide de tags. L'objectif est de montrer comment concevoir un cache fiable en production, en abordant les problèmes courants et les solutions applicables au-delà d'un seul framework.
Ce guide explique comment renforcer la validation des données dans SQLite, une base de données permissive par défaut. Il propose d'utiliser des clés primaires de type INTEGER PRIMARY KEY NOT NULL, de spécifier explicitement si les colonnes acceptent des valeurs NULL, et d'utiliser le mot-clé STRICT dans les déclarations de tables pour activer des vérifications de type strictes. Le guide aborde également l'utilisation des contraintes CHECK() pour des validations supplémentaires. Idéal pour ceux qui veulent éviter les erreurs de données et les problèmes ultérieurs.
L’article explique pourquoi les leaders tech doivent maîtriser la résolution de problèmes, une compétence clé selon le World Economic Forum. Il propose une méthode rigoureuse en 4 étapes (PDCA : Plan, Do, Check, Act) pour transformer les obstacles en opportunités d’apprentissage. L’accent est mis sur l’importance de bien définir le problème (écart entre situation actuelle et souhaitée), d’identifier les causes racines (via la technique des "5 pourquoi"), de tester des contre-mesures, et d’ancrer les apprentissages. L’auteur souligne les pièges à éviter, comme le fingerpointing ou l’attente passive, et encourage à impliquer toute l’équipe pour développer une culture d’amélioration continue. Une approche inspirée du lean management, adaptée au software engineering.
Ce billet explique l'impact souvent méconnu des délimiteurs Twig sur l'espace blanc dans le HTML généré, causant des problèmes de mise en page, des diffs Git bruyants et des réponses HTTP plus lourdes. L'auteur partage son expérience et détaille comment maîtriser ces délimiteurs ({{-}, {%-}, etc.) pour contrôler précisément l'espace blanc et améliorer la qualité du code. Une lecture essentielle pour les développeurs Symfony souhaitant optimiser leurs templates.
L'article critique l'organisation typique des projets informatiques, où les fichiers sont regroupés par type (Commandes, Contrôleurs, Formulaires, Entités, etc.) plutôt que par fonctionnalité. L'auteur illustre comment cette approche, bien que pratique au début, devient problématique à mesure que le projet grandit, entraînant une dispersion des fonctionnalités et un codebase difficile à maintenir. Il suggère une organisation par domaine ou fonctionnalité pour faciliter l'évolution et l'entretien du projet.
Ce billet explique comment générer des PDF à partir de HTML et CSS en utilisant Weasyprint, un outil Python. L'auteur, insatisfait par LaTeX, préfère utiliser des langages qu'il maîtrise mieux. Le tutoriel commence par un exemple simple de conversion HTML en PDF, en passant par l'ajout de styles CSS et diverses astuces pour personnaliser les documents. Il met l'accent sur l'importance des métadonnées et de l'accessibilité des PDF. J'ai découvert des astuces étonnantes : les types de page (page: xxx), la récupération du décompte (target-counter, non documentée dans la MDN !), les sélecteurs de page (:left :right), les règles de marge (@bottom-left @bottom-right), la position "running", etc.
L'article explore l'utilisation pratique des outils de codage basés sur l'IA pour les développeurs responsables. Il met en lumière comment des outils comme Copilot, Cursor, Claude et ChatGPT peuvent améliorer le flux de travail en gérant des tâches fastidieuses, en aidant à naviguer dans des codebases complexes et en facilitant l'implémentation de fonctionnalités dans des langages inconnus. L'auteur partage des techniques concrètes pour utiliser ces outils de manière responsable, en insistant sur la qualité du code, la sécurité, la confidentialité et l'approbation des outils par l'employeur. L'article se concentre sur des applications pratiques, notamment la compréhension de codebases inconnus et la gestion des changements de rupture lors des mises à niveau.
Ce billet explore des techniques Git avancées pour optimiser votre workflow de développement. Il met en lumière l'importance de maintenir un historique Git logique et cohérent, en utilisant des outils comme git rebase -i pour réécrire l'histoire avant de partager vos commits. Il aborde également l'utilisation efficace du staging area avec git add -p pour créer des commits atomiques, et le workflow "fixup" pour corriger des erreurs sans encombrer l'historique. Enfin, il souligne l'importance de travailler avec des branches éphémères et de les rebaser régulièrement pour éviter les conflits et maintenir un historique propre.
L’article explique que dans le développement logiciel, l’ego des développeurs est souvent la vraie source de dysfonctionnements en équipe car il transforme les débats techniques en combats de personnalité et freine l’amélioration collective; l’egoless programming consiste à laisser le problème guider les décisions plutôt que la défense de ses propres idées, en restant ouvert aux idées des autres, en acceptant les retours sans défensivité et en dissociant sa valeur personnelle de la qualité du code, ce qui améliore collaboration, innovation et résultats produit.
Le dépôt GitHub "awesome-cursorrules" de PatrickJS propose des fichiers de configuration pour personnaliser et améliorer l'expérience avec l'éditeur de code AI Cursor. Ces fichiers, nommés ".cursorrules", permettent de définir des règles et comportements spécifiques pour adapter l'IA aux besoins particuliers de chaque projet. Les avantages incluent une personnalisation du comportement de l'IA, une cohérence dans le respect des standards de codage, une meilleure prise en compte du contexte du projet, une productivité accrue, une meilleure cohésion d'équipe et une intégration de connaissances spécifiques au projet. Le dépôt contient des règles pour divers frameworks, bibliothèques, outils de développement et langages de programmation.
L'article explore comment optimiser l'utilisation des agents de codage (comme Claude Code ou GitHub Copilot) pour améliorer la productivité des développeurs. Basé sur des retours d'expérience, il propose plus de 40 bonnes pratiques pour rendre les bases de code plus "agent-friendly". Parmi les conseils clés : intégrer la connaissance du domaine dans le code (via des fichiers dédiés, des commentaires, des noms explicites), améliorer la "SEO" du code pour faciliter la recherche, et suivre des conventions claires. L'objectif est de permettre aux agents de travailler de manière autonome et efficace sur des tâches complexes.
Atomic Design est un modèle de composition d'interfaces utilisateur (UI) bien connu, mais souvent mal utilisé comme architecture d'application complète. Cet article explique que Atomic Design excelle dans l'organisation de l'UI, mais ne répond pas aux questions de domaine, d'orchestration des flux applicatifs ou de gestion de l'état métier. Il propose de séparer clairement la composition de l'UI (où Atomic Design a sa place) de l'architecture applicative, avec des règles strictes pour éviter le couplage caché et maintenir la réutilisabilité des composants. Les features deviennent ainsi l'unité architecturale principale, contenant la logique métier et l'orchestration. Cette séparation améliore également la stratégie de test, avec des tests visuels pour l'UI et des tests d'intégration pour les features.
Cet article de Wanadev Digital explique comment utiliser l'Event Bus de Symfony Messenger pour créer une architecture découplée. Il compare l'EventDispatcher et l'Event Bus, soulignant leurs différences fondamentales : synchrone vs asynchrone, couplage faible vs fort, et scalabilité. L'Event Bus permet un traitement asynchrone, une sérialisation des messages, et une meilleure traçabilité. L'article guide pas à pas pour configurer et utiliser l'Event Bus, idéal pour des tâches comme l'envoi d'emails ou la génération de PDF. Prérequis : comprendre les concepts de Commands et Queries.
L'auteur propose une alternative à la "Ralph loop", appelée "Eric loop", inspirée par le personnage calculateur et manipulateur d'Eric Cartman de South Park. Contrairement à la Ralph loop, la boucle Eric implique une séparation des tâches en plusieurs étapes (planification, exécution, vérification, review) et une formalisation des tâches par une IA. L'auteur illustre ce concept en créant un projet nommé Tiny-till, une application de caisse simple pour marchands ambulants, en utilisant un outil appelé Task-o-matic. L'idée est de mieux contrôler et optimiser l'utilisation des modèles d'IA en séparant les préoccupations et en adaptant les prompts à chaque phase de l'exécution des tâches.
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’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.
Ce guide pratique propose des bonnes pratiques pour sécuriser un serveur Apache2 sous Debian/Ubuntu. Il couvre des aspects essentiels comme masquer la version d'Apache et de l'OS, désactiver le listing des répertoires, configurer des en-têtes de sécurité, désactiver les méthodes HTTP inutiles, et utiliser Fail2Ban pour bloquer les attaques par force brute. Des exemples de configurations et des explications détaillées sont fournis pour chaque étape, avec une conclusion rappelant l'importance de maintenir les mises à jour régulières pour une sécurité continue.