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.

Cet article met en évidence la convergence architecturale entre des frameworks web populaires tels que Spring Boot (Java), Symfony et Laravel (PHP), ainsi que NestJS (Node.js). Malgré leurs langages distincts, ces outils partagent une philosophie commune visant à faciliter la maintenance des applications serveur sur le long terme. Ils s'appuient sur des concepts clés tels que l'injection de dépendances, le routage déclaratif, les patrons de conception de type "repository" et une gestion de configuration adaptable aux différents environnements.

L'auteur illustre cette similarité en comparant des exemples de contrôleurs dans chaque framework. Il observe que l'injection par constructeur, l'isolement des services métiers et la déclaration des routes directement dans le code de la méthode sont des pratiques récurrentes. Cette approche, notamment celle de Spring Boot avec ses "starters" qui simplifient la configuration initiale, rappelle des concepts déjà présents dans l'écosystème PHP, suggérant une influence mutuelle et une standardisation des solutions architecturales pour les applications web modernes.

Cet article relate le processus de migration d'un Fairphone 4 d'Android vers le système d'exploitation /e/OS. L'auteur, dans le cadre de son partenariat avec Commown, a rencontré plusieurs difficultés techniques lors de l'installation via l'installeur web, notamment des problèmes de connexion ADB et de verrouillage du bootloader. L'intervention du support technique de Commown a finalement permis de mener à bien l'installation en ligne de commande.

Ce récit détaille les étapes rencontrées lors de l'installation de /e/OS sur un Fairphone 4, incluant les défis liés à l'installeur web, aux messages d'erreur fréquents et à la nécessité d'une intervention manuelle via adb et fastboot. La collaboration avec le support Commown a été essentielle pour résoudre les blocages.

L'article révèle qu'une instance Yunohost initialement configurée pour être privée derrière une Freebox est devenue accessible publiquement sur Internet. Cette exposition inattendue n'était pas due à un bug des mises à jour de la Freebox ou à des problèmes de certificats.

La cause principale identifiée est l'activation du protocole UPnP IGD (Universal Plug and Play - Internet Gateway Device) sur la Freebox. Ce protocole, lorsqu'il est activé, permet aux appareils connectés d'ouvrir automatiquement les ports nécessaires, contournant ainsi les règles de NAT manuelles mises en place et rendant la machine Yunohost visible de tout Internet.

L'auteur a désactivé cette fonction UPnP IGD pour restaurer la restriction d'accès souhaitée. Il envisage désormais de placer sa machine Yunohost derrière un routeur dédié comme Pfsense ou Opnsense pour renforcer la sécurité.

L'article aborde le problème de la dépendance à des plateformes logicielles américaines comme GitHub, qui, au-delà de la simple gestion de code, représentent des réseaux sociaux et des usines logicielles. La concentration du marché, dominé par GitHub, soulève des questions de souveraineté et de sécurité des données, particulièrement à la lumière de lois américaines comme le Cloud Act et la FISA, qui peuvent contraindre ces plateformes à partager des informations sensibles avec les autorités américaines.

Face à ces risques, l'article explore les alternatives européennes. Il mentionne le self-hosting avec Forgejo, un fork de Gitea maintenu par l'organisation Codeberg, jugé comme la seule option viable dans ce domaine, bien que présentant des défis de maintenance. Pour les solutions hébergées, Codeberg.org est présenté comme une option pour les projets open source, tandis que Tangled.org est mentionné comme un projet prometteur s'appuyant sur ATProto.

En résumé, la dépendance vis-à-vis de GitHub pose des risques liés à la souveraineté des données et aux lois américaines. L'article propose des alternatives européennes comme Forgejo pour le self-hosting et explore des solutions hébergées, tout en soulignant leurs limitations actuelles pour les projets d'entreprise.

L'article explore le concept de "Agentic Coding" en comparant le développement de composants graphiques personnalisés à l'aide de primitives D3 et de la librairie Recharts. L'auteur a découvert que l'approche basée sur les primitives D3 a permis de satisfaire pleinement les exigences de conception complexes, y compris les animations et les comportements spécifiques, sans nécessiter de contournements coûteux.

En contraste, la librairie Recharts, bien que plus rapide pour les cas courants, a rapidement montré ses limites pour atteindre les 20% de personnalisation restants, obligeant à coder du SVG personnalisé et à désactiver des fonctionnalités comme les animations pour contourner des problèmes de compatibilité avec la pile React du projet.

L'auteur redéfinit l'abstraction non pas comme un coût nul, mais comme un travail d'implémentation pré-payé qui offre de la flexibilité en échange. L'histoire du développement web est vue comme une ascension progressive de cette échelle d'abstraction, où chaque étape convertit du travail humain coûteux en dépendances moins chères, mais où les besoins spécifiques finissent par révéler les contraintes de ces abstractions de haut niveau.