Le défi de l'alignement des icônes avec le texte dans les listes est qu'une fois que le texte dépasse une ligne, l'icône centrée visuellement peut paraître décalée. L'approche initiale consistant à utiliser align-items: start dans Flexbox déplace l'icône au sommet du conteneur, ce qui n'est pas idéal en raison de l'espace de ligne par défaut.

Pour résoudre ce problème lorsque l'icône est un élément HTML, il est recommandé d'ajuster la position verticale de l'icône. L'utilisation d'une valeur fixe avec transform: translateY() s'avère instable lorsque la taille de la police, la taille de l'icône ou la largeur du conteneur changent. La solution la plus robuste consiste à utiliser l'unité lh (line-height) pour calculer un décalage dynamique, assurant ainsi un alignement constant quelle que soit la taille du texte ou de l'icône.

Lorsque l'icône est ajoutée via un pseudo-élément comme image de fond, le même principe de calcul d'un décalage relatif s'applique pour garantir un alignement cohérent avec la première ligne de texte, même lorsque le texte se prolonge sur plusieurs lignes.

L'auteur a migré de l'application Authy pour la double authentification vers Aegis Authenticator, un logiciel libre. Cette transition a été motivée par l'incompatibilité d'Authy avec le système d'exploitation Murena /e/OS, utilisé sur son nouveau Fairphone, en raison de restrictions de sécurité liées aux ROM personnalisées.

Aegis a été choisi pour sa nature logicielle libre et pour maintenir une séparation entre la gestion des mots de passe et celle des codes de double authentification, privilégiant ainsi une application dédiée et simple d'utilisation sur smartphone. Le processus de migration a impliqué une approche minutieuse de changement un par un des comptes, avec une désactivation puis réactivation du 2FA, la génération de nouveaux codes de secours, et une vérification systématique de la fonctionnalité avant de supprimer l'ancien enregistrement dans Authy.

Pour assurer une transition réussie et ne rien oublier, l'auteur a utilisé des tags dans son gestionnaire de mots de passe et un fichier tableur dédié au suivi de la migration de chaque service vers Aegis, jusqu'à ce que tous les codes Authy aient été remplacés.

L'article explore comment étendre un blog existant, construit avec le générateur de site statique Hugo, pour le rendre accessible via le protocole Gemini. Le protocole Gemini est présenté comme une alternative minimaliste et plus respectueuse de la vie privée au Web actuel, évitant des aspects comme les publicités, le pistage systématique et les feuilles de style complexes. L'objectif est de créer une "capsule Gemini" ou un "gemlog" qui héberge le contenu du blog.

La démarche consiste d'abord à utiliser les capacités natives d'Hugo pour générer le contenu au format Gemtext, un format simple attendu par le protocole Gemini. Cela implique de configurer Hugo pour qu'il génère des fichiers avec l'extension .gmi et d'ajouter des templates spécifiques pour transformer le contenu Markdown existant en ce nouveau format. Plusieurs autres projets et articles sont mentionnés comme références pour cette transition vers Gemini avec Hugo.

Pour rendre le blog Gemini accessible, la seconde étape consiste à mettre en place un serveur Gemini capable de servir les fichiers .gmi générés par Hugo. L'article promet ensuite de présenter des clients Gemini permettant de consulter ce nouveau blog accessible via le protocole gemini://.

Pour suivre l'évolution de fichiers publics, comme la liste des plateformes agréées de la DGFiP, qui ne fournissent pas de métadonnées de modification (Last-Modified ou ETag), il est nécessaire de mettre en place un système de collecte régulière. L'absence de ces informations rend impossible de déterminer si un fichier a été mis à jour sans le télécharger et le comparer, entraînant une perte d'historique pour chaque jour sans relevé.

La solution proposée consiste à télécharger le fichier quotidiennement et à utiliser Git comme système d'archivage pour conserver les versions successives. L'analyse des fichiers .xlsx est simplifiée en exploitant leur structure ZIP contenant des fichiers XML, sans avoir recours à des bibliothèques complexes. Le processus utilise des outils en ligne de commande comme unzip et une analyse des chaînes de caractères dans xl/sharedStrings.xml ainsi que du contenu des cellules dans xl/worksheets/sheet1.xml.

Cette méthode de parsing XML par expressions régulières est spécifiquement adaptée à des fichiers dont la structure est stable et connue, garantissant que toute modification du format par le producteur du fichier entraînera une défaillance du script. Il est donc crucial de lancer la collecte dès que possible, même avec un script imparfait, afin de ne pas perdre de données historiques.

Un joli plaidoyer de Ploum pour ne pas utiliser l'IA dans la communication écrite : l'IA écrit de manière "vide" - il compare avec de la prose de "marketeux" - alors qu'une rédaction humaine, même maladroite, est incomparablement plus informative.

Le "seasonal slump" est une baisse saisonnière d'énergie, de concentration et d'enthousiasme qui survient généralement en automne avec la diminution des jours. Ce phénomène a une base biologique liée à la réduction de la lumière du jour qui perturbe l'horloge interne du corps.

La lumière du jour influence notre rythme circadien et la production de mélatonine, nous rendant plus somnolents et affectant nos niveaux de sérotonine, un messager chimique du cerveau lié à l'humeur. Cela, combiné à une tendance naturelle à moins bouger et à manger plus lourd, crée un cercle vicieux de baisse d'énergie.

Pour contrer ce phénomène, l'article propose six stratégies basées sur la science, axées sur l'exposition à la lumière naturelle dès le matin, l'activité physique (idéalement en extérieur), le maintien d'un horaire de sommeil régulier, la socialisation, la mise en place de projets motivants et une alimentation adaptée. Il est souligné que la dépression saisonnière est une condition distincte nécessitant un avis médical.

Ce billet décrit une approche pour renforcer la sécurité de Nginx Proxy Manager (NPM) dans un environnement Docker en utilisant CrowdSec. L'objectif est d'éviter de créer une image Docker personnalisée pour NPM, ce qui compliquerait les mises à jour. L'astuce consiste à faire tourner CrowdSec sur l'hôte et à lui permettre de lire les logs de NPM, sans modifier l'image officielle.

La solution proposée fait de CrowdSec un outil de détection et le firewall bouncer de CrowdSec une solution d'application des décisions. CrowdSec analyse l'activité de NPM, identifie les comportements malveillants, et le firewall bouncer utilise iptables pour bloquer les adresses IP incriminées au niveau du réseau, protégeant ainsi les services Docker exposés.

Cette méthode privilégie la simplicité et la maintenabilité, en conservant l'image NPM officielle et en évitant les dépendances à des images personnalisées moins suivies. Le filtrage s'opère au niveau du firewall plutôt qu'au niveau du serveur web lui-même, offrant une protection par blocage d'adresses sources pour les services Docker publiés.

Le projet Agojie vise à automatiser le jeu de société Dice Throne. Le développement a débuté par des décisions fondamentales avant même la première ligne de code, abordant la structure du modèle du jeu, la mécanique de défense des héros, la découpe des tâches de développement et le choix de la pile technologique. L'objectif initial est de modéliser le cœur du jeu en un contre un, en se concentrant sur la gestion des dés, avant d'intégrer les cartes et les effets de statut.

Trois idées d'architecture ont été envisagées dès le départ : la séparation entre la définition d'un héros et l'état d'une partie, la modélisation du jeu comme un "Aggregate" pour garantir l'intégrité des règles métier, et l'utilisation d'"Domain Events" pour enregistrer les faits importants du domaine. Cependant, ces idées n'ont pas été appliquées immédiatement, privilégiant une approche où les décisions sont justifiées par les règles du jeu et non par l'intuition.

Ce projet est structuré en quatre étapes principales : la mise en place du cœur du jeu sans cartes, le développement d'une interface utilisateur basique avec sauvegarde des parties, l'intégration de la couche de cartes pour influencer le jeu, et enfin la gestion des effets de statut qui affectent les héros. La première phase consiste en la rédaction d'une spécification détaillée des règles du jeu de Dice Throne, incluant des exemples concrets pour guider le développement du code.

Résumé pour Shaarli:

Le projet Agojie se lance dans l'automatisation de Dice Throne, un jeu de dés et de combat stratégique. Les premières étapes se concentrent sur les décisions architecturales et la modélisation des règles fondamentales, sans écrire de code. L'objectif est de développer le cœur du jeu, puis d'ajouter progressivement des fonctionnalités comme les cartes et les effets de statut, en s'appuyant sur des principes de conception logiciel rigoureux.

Le texte explore deux approches pour gérer les dépendances lors de tests locaux de services communiquant avec S3 dans une application Symfony. La première question technique concerne l'utilisation de class: versus alias: pour redéfinir un service. L'auteur illustre qu'un alias peut être préférable car il permet de pointer vers une autre définition de service sans pour autant le réinstancier directement, évitant ainsi des erreurs de construction comme le manque d'arguments.

La deuxième question aborde une décision d'architecture : privilégier un "double maison jetable" (un faux service temporaire redirigeant vers le système de fichiers local) plutôt qu'une solution comme MinIO (un conteneur S3-compatible). Cette approche est motivée par la simplicité et la réversibilité, rendant la modification facilement identifiable et supprimable après les tests, notamment grâce au bloc when@dev de Symfony qui permet de scoper la configuration à un environnement spécifique.

En résumé, le choix entre une configuration via class: ou alias: pour substituer un service en environnement de développement, et le type de fausse dépendance utilisé, sont des décisions d'ingénierie qui doivent être adaptées au contexte et aux besoins de réversibilité du processus de développement. L'utilisation de blocs de configuration conditionnels comme when@dev facilite l'intégration et la suppression temporaire de ces adaptations pour les besoins de recettes et de tests.

Le composant Symfony ObjectMapper simplifie la conversion entre différents objets, notamment pour transformer des DTOs (Data Transfer Objects) en entités ou vice versa. Cette approche permet de découpler les données d'entrée et de sortie d'une API des modèles internes, ce qui est particulièrement utile lors de la gestion de code existant ou de l'implémentation d'architectures hexagonales.

L'ObjectMapper agit comme un traducteur, prenant les données d'un objet source et les convertissant directement dans le format d'un objet cible, sans passer par une étape intermédiaire sous forme de tableau. Cette méthode est plus simple et efficace que l'utilisation du composant Serializer de Symfony, qui nécessitait une normalisation en tableau puis une dénormalisation, impliquant potentiellement plus de configuration.

L'utilisation de DTOs est recommandée pour séparer clairement les responsabilités. Tandis que les entités sont liées à la logique métier et à la persistance, les DTOs définissent les données à exposer ou à recevoir à une interface spécifique, offrant ainsi un contrôle sur ce qui traverse les frontières de l'application et améliorant la maintenabilité.

L'application Symfony a souffert d'épuisement de mémoire, provoquant des plantages de conteneurs nocturnes. Le développeur a d'abord suspecté une fuite de mémoire, mais l'analyse a révélé que le problème provenait de requêtes gourmandes en ressources, chacune consommant jusqu'à 512 Mo. Ces requêtes saturaient rapidement le pool de travailleurs PHP-FPM, entraînant l'indisponibilité du site.

Face à l'augmentation du contenu, le développeur a mis en place des outils de surveillance pour identifier les routes problématiques. Il a découvert cinq schémas récurrents dans Doctrine, tous contribuant à la consommation excessive de mémoire. La première cause identifiée était une hydratation complète des entités Doctrine lorsque seules quelques colonnes étaient nécessaires, comme dans le cas de la génération du sitemap.

Cette surconsommation de mémoire a été résolue en optimisant le code pour éviter l'hydratation inutile des entités. Le développeur a instrumenté son application avant de toucher au code, ce qui lui a permis de cibler précisément les problèmes. L'objectif était de réduire la quantité de données chargées et traitées par chaque requête, afin de prévenir l'épuisement de la mémoire.

L'application Symfony a rencontré des problèmes de mémoire dus à des requêtes gourmandes, saturant le pool de workers. Après analyse, cinq schémas récurrents dans Doctrine ont été identifiés comme responsables, notamment une hydratation complète des entités là où seule une partie des données était nécessaire. L'optimisation du code pour réduire la consommation de mémoire par requête a permis de résoudre le problème.

L'article aborde le conflit entre le principe d'immuabilité de l'event sourcing et le droit à l'effacement du RGPD. Les approches traditionnelles comme la réécriture ou la suppression physique des événements sont jugées destructrices pour l'intégrité du système.

La solution proposée repose sur le concept de "forgettable payloads" : les données personnelles ne sont plus stockées directement dans les événements immuables, mais dans un espace de stockage séparé et mutable. L'événement conserve son identité et une référence vers ces données, mais la suppression du compte utilisateur implique de rendre ces données inaccessibles, sans altérer le flux d'événements.

Cette inaccessibilité est concrètement réalisée par le "crypto-shredding" des données : chaque charge utile est chiffrée avec une clé unique, et le processus d'effacement consiste à détruire cette clé. Si aucune copie de clé ou donnée en clair ne subsiste ailleurs, les données chiffrées deviennent indéchiffrables, honorant ainsi la demande d'effacement sans compromettre l'historique des événements.

Le composant Symfony Runtime, introduit dans Symfony 5.3, a modernisé le démarrage des applications PHP en séparant la logique d'initialisation de celle du contrôleur frontal. Auparavant, le fichier public/index.php contenait une grande partie de l'infrastructure de l'application, ce qui posait des problèmes de maintenance et de propagation des mises à jour du code de démarrage.

Grâce à Runtime, le code d'amorçage est désormais géré par un composant Composer dédié, permettant ainsi des mises à jour plus fluides via la gestion des dépendances. Cette architecture découplée est particulièrement avantageuse car elle permet aux applications Symfony de s'exécuter dans divers environnements, qu'il s'agisse des serveurs PHP traditionnels (PHP-FPM) ou de solutions plus modernes comme FrankenPHP, Swoole ou ReactPHP, sans modifier le contrôleur frontal.

Le principal avantage architectural de Symfony Runtime réside dans sa capacité à désolidariser le processus de démarrage de l'application de son modèle d'exécution. Cela signifie qu'une même application peut s'adapter à différents types d'environnements d'exécution, y compris les processus PHP à longue durée de vie, sans nécessiter de réécrire sa logique d'initialisation. Cette flexibilité ouvre la voie à une portabilité accrue des applications Symfony sur une gamme plus large de plateformes.

Symfony 8.1 introduit la variable d'environnement FRANKENPHP_RESET_KERNEL pour résoudre un problème de fuite d'état dans les applications PHP fonctionnant en mode "worker" avec FrankenPHP. Ce mode maintient le processus PHP en vie entre les requêtes pour améliorer les performances, mais crée un risque que l'état de services persistants ne soit pas correctement réinitialisé, ce qui peut entraîner une incohérence ou une exposition involontaire de données entre les requêtes.

Traditionnellement, chaque requête HTTP dans PHP démarrait avec un environnement isolé, garantissant que l'état de l'application était remis à zéro. Le mode worker de FrankenPHP, quant à lui, réutilise le noyau et les services Symfony, offrant un gain de vitesse significatif mais introduisant le risque de propagation d'état non désiré si les services ne sont pas explicitement réinitialisés.

Pour pallier ce risque, Symfony propose l'interface ResetInterface qui permet aux services de vider leur état entre les requêtes. Cependant, cette approche dépend de la bonne implémentation par tous les services, y compris ceux de tiers ou le code hérité. FRANKENPHP_RESET_KERNEL agit comme une mesure de sécurité supplémentaire, garantissant que le noyau est réinitialisé automatiquement, ce qui renforce la robustesse et la sécurité des applications PHP en mode worker.

Le nouveau command symfony lsp:check résout un problème courant de typographie dans les noms de routes Symfony que les outils d'analyse statique comme PHPStan ne peuvent pas détecter. Ces erreurs, souvent des fautes de frappe minimes, peuvent passer inaperçues lors des revues de code ou des tests automatisés, menant à des bugs en production. Le command analyse les routes, les templates, les traductions et la configuration pour identifier ces erreurs spécifiques à Symfony.

Le command symfony lsp:check est une version autonome des diagnostics déjà présents dans les extensions de langage Symfony pour les éditeurs. Il fonctionne en démarrant l'application dans l'environnement sélectionné pour analyser la configuration et les routes réelles, offrant ainsi une détection précise des erreurs. Il couvre un large éventail de problèmes, incluant les routes inexistantes, les templates manquants, les clés de traduction erronées et les configurations invalides, avec la possibilité de basculer vers une analyse statique si l'exécution du code n'est pas possible en CI.

Visa et Mastercard sont des réseaux de cartes, et non les émetteurs de cartes ou les banques qui fournissent ces cartes aux consommateurs. Ils ne s'occupent pas non plus des processeurs de paiement qui gèrent les transactions sur les terminaux ou en ligne, ni de l'intégration des commerçants.

Leur rôle principal est de relier les titulaires de cartes et les émetteurs aux commerçants et aux acquéreurs afin de faciliter les transactions par carte. Ils exploitent l'infrastructure de télécommunication nécessaire au routage des messages de transaction, coordonnent le transfert de fonds et règlent les transactions entre les parties concernées.

En outre, ces réseaux définissent les règles qui régissent leur écosystème, y compris les procédures de règlement des litiges, et mettent en place des incitations pour encourager l'utilisation de leurs réseaux. Leur infrastructure est conçue pour être hautement sécurisée et résiliente afin d'assurer la fiabilité des transactions.

L'article soutient que la tendance actuelle à diviser les systèmes d'IA en de multiples agents spécialisés, à l'instar des microservices, peut être prématurée et coûteuse. Il souligne que de nombreux agents médiocres ne surpassent pas un seul agent performant, et que la complexité croissante d'un agent unique conduit à une dégradation progressive. Les problèmes majeurs incluent la difficulté de sélectionner le bon outil parmi une liste étendue, la contradiction des instructions dans un unique prompt, et la difficulté de modifier le système sans affecter l'ensemble.

Le moment idéal pour opérer une scission en agents multiples est lorsque ces difficultés deviennent mesurables et nuisibles, et non sur la base d'une esthétique ou d'une tendance. La solution proposée est le schéma "supervisor pattern", où un agent superviseur centralise la classification et le routage des requêtes vers des agents spécialisés. Chaque agent spécialiste est confiné à un domaine unique, disposant de son propre prompt clair, d'un ensemble d'outils limité et distinct, et gérant son propre état de conversation.

Ce modèle permet de retrouver la précision dans le choix des outils et d'éviter les conflits d'instructions, offrant ainsi une meilleure maintenabilité et évolutivité. L'idée principale est de ne pas commencer avec une architecture multi-agents avant que la nécessité ne soit clairement établie par des problèmes concrets liés à la complexité d'un agent unique, puis d'adopter une approche structurée avec un superviseur et des spécialistes.

L'implémentation de Page Objects dans Playwright est une approche pour améliorer la maintenabilité et la réutilisabilité du code de test automatisé. Plutôt que d'interagir directement avec les éléments de l'interface utilisateur dans chaque scénario de test, les Page Objects encapsulent les sélecteurs d'éléments et les actions associées à une page spécifique de l'application web. Cela permet de centraliser la logique de localisation des éléments, rendant les tests plus robustes face aux changements de structure du site.

Playwright propose deux styles de Page Objects : un pour les suites de tests utilisant le runner intégré de Playwright, et un autre destiné à l'intégration dans des frameworks de test externes comme Jest ou Cucumber. Les deux approches s'appuient sur les concepts de fixtures de test, notamment la fixture Page qui fournit un objet pour interagir avec une seule page du navigateur et la notion de Locator pour trouver des éléments de manière fiable grâce aux mécanismes d'attente automatique de Playwright.

La mise en place d'un Page Object implique généralement d'importer les types Locator et Page de la bibliothèque Playwright Test. Ces objets fournissent des méthodes pour sélectionner et manipuler les éléments de l'interface, assurant que les tests sont moins susceptibles de devenir obsolètes en cas de modifications mineures du code HTML de l'application.

Pour mieux comprendre les systèmes complexes, l'auteur a développé une approche utilisant des agents d'IA pour agréger des connaissances réparties entre le code, la documentation et le savoir tacite des équipes. L'objectif est de supprimer la nécessité de réunir plusieurs personnes pour décortiquer le fonctionnement d'un système.

La première tentative consistait en un agent général connecté à des outils comme Notion et GitHub. Bien qu'utile pour des périmètres restreints, cette approche a montré ses limites en matière de fiabilité et de capacité à traverser les frontières des différents domaines d'expertise. Face à ces difficultés, l'auteur a décidé de construire une solution plus robuste et personnalisée.

La seconde tentative, nommée "ruche", implique la création d'un dépôt centralisé regroupant les dépôts de code pertinents via des sous-modules Git. Chaque sous-module est accompagné d'un fichier AGENTS.md fournissant un contexte, formant ainsi une "ruche" d'agents capables d'accéder et de traiter l'information de manière plus efficace.

L'hébergement de son propre serveur de messagerie est désormais réalisable, y compris depuis son domicile, malgré les réticences fréquentes liées aux problèmes de spam et de livraison. L'idée principale est de reprendre le contrôle de ses données et de favoriser la décentralisation d'Internet, en évitant que quelques grandes entreprises ne concentrent toutes les informations.

Pour un hébergement à domicile, certaines conditions techniques sont nécessaires : une adresse IP statique IPv4 non blacklistée, ne pas être derrière un CGNAT, pouvoir modifier le enregistrement PTR de son IP et ouvrir les ports couramment utilisés par les serveurs de messagerie. Les interruptions de service internet sont généralement bien gérées par le système de relai des e-mails, le destinataire ne perdant donc pas de messages lors de courtes indisponibilités.

Plusieurs solutions logicielles existent pour mettre en place un serveur de messagerie, comme docker-mailserver, Stalwart ou Mailcow, offrant différentes approches pour le déploiement. Il est également crucial de configurer correctement les enregistrements DNS (SPF, DKIM, DMARC, MX) de son domaine pour assurer une bonne délivrabilité des e-mails et prévenir le spoofing.