Ajouter la GeoIP à Nginx Proxy Manager (NPM 2.12+) permet de bloquer ou logger les visiteurs par pays. Il suffit d’activer les modules GeoIP via root_top.conf, de télécharger les bases GeoLite2 de Maxmind (gratuites, après inscription), et de configurer les règles de blocage dans http_top.conf. Les logs peuvent aussi être enrichis avec les infos géographiques.
Un éditeur markdown WYSIWYG léger
Suite de https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/ , Eric Meyer explore dans ce billet les comportements inattendus et parfois incohérents entre navigateurs (Safari, Chrome, Firefox) lors de l’utilisation du mot-clé CSS infinity dans des calculs (calc()). Il teste son impact sur des propriétés comme text-indent, word-spacing, letter-spacing, z-index ou encore animation-duration. Résultat : selon le navigateur, les valeurs calculées varient énormément (de 33 millions de pixels à des nombres astronomiques), et certaines propriétés, comme z-index, voient leur valeur plafonner à 2147483647, rendant impossible un "au-delà de l’infini". Les animations avec une durée infinie deviennent inutilisables, surtout sur Safari, tandis que diviser un nombre fini par l’infini donne systématiquement 0, une rare harmonie entre les navigateurs. Une plongée ludique et technique dans les limites (ou leur absence) de CSS ! [
Les entreprises ne se soucient ni de la productivité ni du management moderne, seulement du contrôle et des cours boursiers. Malgré les preuves accumulées (bureaux ouverts nuisibles, télétravail bénéfique pour le sommeil et les coûts, etc.), les dirigeants ignorent les théories managériales éprouvées (comme celles de Deming) au profit de la surveillance et de l’autoritarisme. Même si les outils d’IA générative promettent des gains de productivité, leur variabilité et leurs coûts cachés (verrouillage, impact environnemental, risques politiques) en font un pari dangereux, surtout couplés à des licenciements. Pire, leur adoption reflète souvent une logique de bulle spéculative, où les avertissements rationnels sont ignorés — comme avant l’éclatement de la bulle immobilière de 2008. En réalité, ces outils, en augmentant la variabilité des tâches, risquent de paralyser les organisations en surchargeant les processus et en réduisant la capacité réelle de travail. Résultat : une course à l’abîme, où seuls comptent le contrôle et l’illusion de l’innovation, au mépris de l’efficacité et du bien-être. Une analyse systémique révèle leur toxicité, mais personne n’écoute : ceux qui en ont les moyens fuient déjà la bulle, les autres subissent.
Gonzalo Ayuso partage un projet d’agent IA personnalisé pour recommander des films, développé avec Python et Strands Agents. L’objectif ? Automatiser le choix de son film du samedi après-midi en croisant les horaires des cinémas locaux (via SadeCines.com), ses notes et préférences personnelles (Letterboxd), ainsi que les critiques (IMDb/Metacritic). L’agent utilise des outils comme un navigateur sandboxé pour scraper le web, un interpréteur de code Python sécurisé pour traiter les données, et des prompts détaillés pour affiner les recommandations selon ses goûts (action, science-fiction, comédie) et exclusions (films familiaux, drames). Le code, simple et basé sur AWS Bedrock, illustre le potentiel des agents multi-outils, même si l’auteur reconnaît un certain over-engineering pour un usage individuel. Le projet, open source, montre comment combiner LLM, scraping et exécution de code de manière sécurisée pour créer un assistant sur mesure.
Eric Meyer, au détour d'un message sur Mastodon, est tombé sur une règle CSS intrigante : width: calc(infinity * 1px); Il a décidé de mener des tests avec Chrome, Safari et Firefox afin de voir quelles valeurs sont réellement utilisées, ce qui a donné des résultats assez étonnants.
L’article relate l’expérience d’un ingénieur utilisant Claude Code pour automatiser des tâches de développement (refactoring, correction de bugs, écriture de tests). Si l’outil excelle pour des corrections ponctuelles, il génère souvent des PRs volumineuses et illisibles, rendant la revue de code difficile. La solution trouvée : apprendre à Claude à structurer son travail en "stacked PRs" (séries de petites PRs ciblées et indépendantes), comme le feraient des humains expérimentés. En guidant l’IA avec des instructions précises et en utilisant l’outil GT MCP de Graphite, l’auteur parvient à obtenir des PRs claires, testables et faciles à relire. Résultat : une intégration plus fluide de l’IA dans le workflow, permettant de construire des fonctionnalités complètes, de corriger des bugs complexes et d’ajouter des tests, tout en gardant un code maintenable et collaboratif.
Un concurrent de ngrok ?
Il s'agiç d'une bibliothèque de composants pour Vue.js basée sur Tailwind et PrimeVue
Le « vibe coding » permet-il de créer une app iPhone sans coder ? Ludovic Toinel partage son expérience : grâce à GitHub Copilot (avec Claude 3.7) et ChatGPT (GPT-4o), il a développé Contactidy, une app utilitaire pour normaliser les contacts, en une soirée. Si l’IA a généré la majorité du code, du design et même les traductions, des corrections manuelles (refactoring, gestion du Info.plist, bindings SwiftUI) ont été nécessaires pour obtenir un résultat propre et fonctionnel. Malgré quelques limites (code parfois complexe, temps de réponse), l’approche s’avère très efficace pour des projets simples, à condition d’avoir un minimum de connaissances techniques pour guider et corriger l’IA. L’app est disponible sur l’App Store. Une méthode prometteuse, mais pas encore magique !
Le Backend For Frontend (BFF) est un pattern architectural qui agit comme une couche intermédiaire entre les applications frontend (web, mobile, etc.) et les API ou microservices. Son objectif est de simplifier la récupération et la transformation des données en centralisant la logique d’agrégation et d’adaptation des données côté serveur, plutôt que de la laisser aux clients. Cela évite de surcharger les applications frontend avec des tâches complexes et permet d’offrir une réponse sur mesure, optimisée pour chaque type de client (mobile, web, etc.). Contrairement à une API Gateway, le BFF est dédié à un type spécifique de client, ce qui permet de mieux répondre à ses besoins en termes de format de données, gestion d’erreurs ou authentification. Ce pattern est particulièrement utile dans un contexte MACH (Micro Services, API-first, Cloud Native, Headless) ou lorsque les besoins des utilisateurs varient selon le type d’application, mais il ajoute une couche supplémentaire à maintenir et nécessite des compétences fullstack. Son adoption se justifie surtout si l’expérience utilisateur doit être différente selon les plateformes.
Ce dépôt présente les principaux design patterns avec des exemples en JavaScript
Il s'agit d'un comparatif de différentes bibliothèques de composants UI pour Vue / Nuxt
Résumé pour Shaarli :
Le Domain-Driven Design (DDD) peut sembler complexe pour les développeurs backend habitués à une approche "data-first" (comme avec Laravel ou Symfony), car il inverse la logique : au lieu de partir des données ou des outils, on organise le code autour du métier et de ses règles. Le DDD introduit des frontières claires (Domain, Application, Infrastructure) et un langage ubiquitaire pour aligner code et besoins business, ce qui casse les habitudes de développement procédural ou centré sur le framework. Les concepts clés comme les Bounded Contexts, Entities, Value Objects et Repositories aident à structurer le code pour le rendre plus maintenable et testable. La courbe d’apprentissage est raide car elle demande de passer d’une pensée technique à une pensée métier, mais même une adoption progressive apporte plus de clarté et de modularité. L’article propose une approche "DDD-lite" avec une structure de projet simple et suggère d’utiliser le BDD pour faciliter la transition en collaborant avec les experts métier. En résumé : le DDD, c’est avant tout des frontières et du vocabulaire partagé, pas de la magie architecturale.
EventCatalog est un outil open source qui comble un manque crucial dans les architectures orientées événements : la documentation claire et maintenable. En adoptant une approche "documentation-as-code", il permet de décrire et visualiser les messages (événements, commandes, requêtes), les canaux de communication, les domaines, services et entités (inspirés du Domain-Driven Design), ainsi que les équipes et le langage ubiquitaire. Intégrable avec des registres de schémas (OpenAPI, AsyncAPI, JSON, Avro), il automatise la génération de documentation interactive, facilitant la compréhension et la maintenance des systèmes asynchrones. Grâce à des fonctionnalités comme les graphes de dépendances, la visualisation des schémas et la gestion des équipes, EventCatalog rend accessible et vivante la complexité des architectures événementielles, tout en restant simple à déployer et à mettre à jour. Une solution idéale pour aligner documentation et développement, surtout dans des écosystèmes distribués.
Alexandre Touret partage son retour d’expérience sur un atelier d’Architecture Kata organisé lors de la Riviera Dev, où plus de soixante participants ont planché sur la conception d’une plateforme numérique dédiée au tourisme solidaire et durable. L’objectif était de proposer une solution intégrant profils utilisateurs éco-responsables, tableau de bord d’empreinte carbone, gamification et gestion d’activités locales, avec des contraintes techniques et métiers variées. L’article présente trois approches distinctes : deux propositions d’équipes (dont une très détaillée avec des diagrammes Structurizr) et la sienne, soulignant l’importance de clarifier les besoins métiers, de prioriser les flux principaux et d’externaliser les fonctions critiques (comme les paiements). L’exercice illustre la diversité des solutions possibles selon l’expérience des participants et rappelle que la pratique régulière des katas permet d’améliorer la prise de décision, la communication et l’adaptabilité en architecture logicielle. Une ressource utile pour quiconque s’intéresse à l’amélioration des compétences en design système.
La dette technique est inévitable dans tout projet logiciel, mais la clé réside dans sa gestion stratégique plutôt que dans son élimination totale. Cet article explique comment évaluer quand il est judicieux de réécrire du code (par exemple, avant d’ajouter une nouvelle fonctionnalité ou en cas de risques majeurs) et quand il vaut mieux la tolérer temporairement (lorsque le coût dépasse les bénéfices immédiats). L’auteur propose une matrice décisionnelle et des conseils pour convaincre les parties prenantes en traduisant l’impact technique en arguments business : gain de temps, réduction des risques, et amélioration de la vélocité d’équipe. L’objectif ? Équilibrer pression court terme et santé long terme du code, sans tomber dans le piège de la quête de perfection.
Sean Goedecke y explique que le bon design système repose sur la simplicité, la minimisation de l’état (state) et l’utilisation judicieuse de composants éprouvés (bases de données, caches, files d’attente, etc.). Un bon design se remarque surtout par son absence de problèmes et sa discrétion : si tout fonctionne sans accroc et semble plus simple que prévu, c’est souvent signe de réussite. L’auteur insiste sur l’importance de centraliser la gestion de l’état (via une base de données bien structurée et indexée), d’éviter la complexité inutile, et de privilégier des solutions robustes plutôt que des astuces sophistiquées. Les opérations lentes doivent être déléguées à des tâches en arrière-plan, et le cache utilisé avec parcimonie. Enfin, il souligne que les "hot paths" (chemins critiques) méritent une attention particulière, tout comme la journalisation et la gestion des échecs (killswitches, retries). En résumé, un bon design système est souvent invisible, mais efficace et maintenable sur le long terme.
Ce guide démystifie l’élément <path> en SVG, souvent perçu comme complexe. À travers des exemples interactifs, il explique comment utiliser les commandes (M, L, Q, C, A, etc.) pour dessiner des lignes, courbes de Bézier et arcs elliptiques, en enchaînant des instructions comme avec un stylo. Le guide couvre aussi les astuces (fermeture de chemin, commandes relatives) et montre comment créer des formes avancées, utiles pour le design et les animations web.
DuckDB est un système de gestion de base de données relationnelle (SGBD) en code ouvert, conçu pour être léger, rapide et analytique, optimisé pour les requêtes complexes sur des jeux de données de taille moyenne à grande directement depuis un seul fichier. Contrairement aux bases de données traditionnelles comme PostgreSQL ou MySQL, DuckDB fonctionne en mode embarqué (sans serveur), ce qui le rend idéal pour les analyses locales, les applications intégrées ou les environnements où la simplicité et la performance sont cruciales. Il prend en charge le langage SQL standard, offre des fonctionnalités avancées comme les jointures, les agrégations, les fenêtres analytiques, et intègre des extensions pour le traitement de données par lots ou en mémoire. Particulièrement apprécié dans les domaines de la science des données et de l’analyse interactive, DuckDB se distingue par sa capacité à traiter efficacement des fichiers Parquet ou CSV, tout en restant portable et facile à déployer. Son architecture sans dépendance externe et sa compatibilité avec de nombreux langages (Python, R, Java, etc.) en font un outil polyvalent pour les développeurs et les analystes cherchant à manipuler des données sans infrastructure lourde.