Andy Clarke explore dans cet article comment les animations ambiantes, discrètes et lentes, peuvent enrichir l’identité visuelle et la narration d’un site web sans distraire l’utilisateur. À travers trois études de cas (Reuven Herman, Mike Worth et EPD), il illustre des techniques concrètes : morphing de chemins SVG, superposition de mouvements pour créer de la profondeur, interactions subtiles et respect des préférences d’accessibilité (comme prefers-reduced-motion). Ces animations, réalisées avec CSS ou GSAP, transforment des éléments statiques en expériences vivantes, tout en restant en arrière-plan. L’article met l’accent sur l’optimisation des SVGs, la performance et l’intégration harmonieuse du mouvement dans le design, prouvant que même dans des secteurs traditionnels, l’animation peut renforcer une marque sans dominer le contenu.

Une application en ligne de commande (TUI) pour gérer le WIFI sous Linux

Ce billet explique comment configurer Coolify et Traefik pour gérer des certificats SSL wildcard sur des sous-domaines dynamiques (comme user1.monapp.com, user2.monapp.com, etc.). L’auteur détaille d’abord le problème : avec des sous-domaines dynamiques, la validation HTTP classique de Let’s Encrypt ne fonctionne pas, car les domaines n’existent pas encore au moment de la demande de certificat. La solution passe par le DNS challenge, qui consiste à prouver le contrôle du domaine en ajoutant un enregistrement TXT dans la zone DNS, plutôt qu’un fichier sur le serveur.

Le guide décrit la configuration d’un résolveur de certificats dans Traefik (via Coolify) en utilisant l’API d’un fournisseur DNS compatible (comme bunny.net), puis montre comment appliquer ce résolveur à une application. Enfin, il aborde la gestion des custom domains, où l’utilisateur peut utiliser son propre domaine, en combinant un routeur Traefik avec une règle HostRegexp pour capturer tout le trafic inconnu et générer automatiquement les certificats via HTTP challenge. Un retour d’expérience utile pour qui veut automatiser la gestion du SSL sur des architectures multi-tenants.

Zellij est un espace de travail terminal moderne, conçu pour offrir une expérience utilisateur riche et modulable directement dans le terminal. Il permet de diviser l’écran en plusieurs panneaux, onglets et sessions, avec des fonctionnalités avancées comme le partage de panneau entre plusieurs sessions, la personnalisation poussée via des thèmes et des plugins, et une gestion intuitive via des raccourcis clavier ou la souris. Le projet met l’accent sur la productivité et la flexibilité, en intégrant nativement des outils comme le multiplexage de terminaux, la recherche dans l’historique, et même la possibilité de lancer une démo en ligne sans installation. Idéal pour les développeurs et les utilisateurs avancés, Zellij se distingue par sa simplicité d’utilisation et sa capacité à s’adapter à des workflows complexes.

L’article présente plusieurs alternatives "local-first" à Postman, idéales pour les développeurs souhaitant éviter les comptes en ligne et les dépendances cloud. Parmi les solutions proposées : Bruno (open source, stockage local en fichiers .bru, compatible Git), Hoppscotch (léger, fonctionne dans le navigateur, self-hostable), ApiCat (hors ligne, gestion des environnements et variables), Yaak (multiplateforme, approche local-first, intégration Git), Kreya (pour REST, gRPC et WebSocket, données locales), et Posting.sh (en ligne de commande, fichiers YAML). Pour les utilisateurs de VS Code, des extensions comme REST Client, Thunder Client et RapidAPI Client offrent aussi des fonctionnalités similaires directement dans l’éditeur. Ces outils répondent aux besoins de confidentialité, de légèreté et de travail hors-ligne, tout en proposant des interfaces modernes et des fonctionnalités avancées.

L’article explique pourquoi il n’est plus nécessaire de développer des APIs REST à partir de zéro en 2025. Il met en avant des frameworks modernes comme tRPC, Fastify et Hono, qui permettent de réduire la quantité de code répétitif grâce à une approche basée sur les schémas, améliorant ainsi la rapidité et la sécurité des développements. L’idée centrale est d’utiliser ces outils pour automatiser et standardiser la création d’APIs, plutôt que de tout coder manuellement. Une lecture utile pour les développeurs souhaitant optimiser leur workflow et adopter des pratiques plus efficaces.

L’article explore l’univers des terminaux et shells sous Linux, en soulignant leur importance persistante en 2025 pour la gestion de fichiers, le développement, l’administration système et bien plus. Il commence par rappeler la distinction entre TTY et pts/pty, puis détaille l’évolution des shells (Bash, Zsh, Fish, etc.), leurs spécificités et leurs usages, ainsi que les multiplexeurs comme GNU Screen ou Tmux. L’article passe ensuite en revue une multitude de terminaux disponibles, qu’ils soient intégrés aux environnements de bureau (GNOME Console, Konsole, xfce-terminal), liés à des éditeurs de texte (Emacs, Vim), ou indépendants (Alacritty, Kitty, Wezterm, Warp, etc.), en mettant en avant leurs fonctionnalités, philosophies et particularités techniques. Il évoque aussi des solutions innovantes ou controversées, comme les terminaux intégrant l’IA (Warp, Waveterm). Une ressource utile pour découvrir ou comparer les outils de ligne de commande adaptés à ses besoins.

Ce billet explore le pattern Backend-for-Frontend (BFF), une solution architecturale pour les applications modernes où plusieurs frontends (web, mobile, TV) consomment les mêmes services backend. Le BFF agit comme une couche de traduction dédiée à chaque client, agrégeant les appels API, transformant les données et gérant la logique spécifique (cache, authentification, etc.), le tout possédé et maintenu par l’équipe frontend.

Les signes qu’un BFF pourrait être utile incluent des problèmes de performance (appels multiples, sur/sous-récupération de données), une lenteur de développement (dépendances entre équipes, duplication de logique) ou des frictions organisationnelles (API mal adaptées aux besoins UX). Le BFF permet d’aligner les priorités des équipes, d’améliorer les performances (notamment sur mobile) et d’accélérer la livraison de fonctionnalités.

Cependant, le BFF n’est pas une solution universelle : il ajoute de la complexité opérationnelle et peut être excessif pour des applications simples ou des petites équipes. Des alternatives existent (GraphQL, API Gateway, refonte backend). L’article souligne l’importance d’un pilote pour évaluer son impact avant une adoption large, et rappelle que le succès dépend d’une appropriation par les équipes frontend et d’une approche itérative.