L'auteur partage une réflexion sur le pragmatisme en développement logiciel, inspirée par le film "Whatever works" de Woody Allen. Il critique les dogmes et les débats stériles entre experts, souvent centrés sur des définitions, et plaide pour une approche plus flexible des bonnes pratiques. Il illustre son propos avec des exemples comme le TDD, la pyramide de tests et les tests en intégration continue, soulignant que l'essentiel est de s'adapter à la situation et aux besoins de l'équipe. Le temps et les résultats devraient être les seuls juges de paix, et le doute doit rester un moteur d'amélioration continue.

Dans cet article, Dryusdan explique comment automatiser la création et la gestion de passerelles pour ses réseaux privés dans son infrastructure. Il décrit l'utilisation de Packer pour créer des images de machines virtuelles configurées avec un script bash et des fichiers de configuration, permettant ainsi aux instances de ses réseaux privés d'accéder à Internet et d'être accessibles. Il aborde également la gestion des adresses IP via un serveur DHCP personnalisé et le stockage des images avec Incus, tout en partageant son expérience et les défis rencontrés avec Ansible.

Bartek Płotka partage son expérience avec lazygit, une interface utilisateur pour Git qu'il a découverte par accident en utilisant Neovim. Malgré son attachement à Goland pour le développement professionnel, il a été séduit par la simplicité, la rapidité et l'interactivité de lazygit, qu'il utilise désormais pour tous ses workflows Git. Dans cet article, il explique pourquoi lazygit est si spécial, comment il peut améliorer la productivité et ce que nous pouvons apprendre de son design et son expérience utilisateur. Il compare également différentes interfaces Git et souligne l'importance de maîtriser le CLI Git, surtout pour les nouveaux développeurs.

Ce tutoriel explique comment créer un registry Docker privé avec Podman et Quadlet, en mode rootless pour plus de sécurité. Après avoir installé Podman et créé un utilisateur dédié, on génère un certificat auto-signé et un fichier d’authentification (htpasswd). Le registry est lancé via un conteneur Docker officiel, puis configuré pour démarrer automatiquement avec un fichier registry.container dans ~/.config/containers/systemd/. Une redirection de port (443 → 5000) est configurée via firewalld, et un nettoyage automatique des fichiers temporaires est mis en place. Pour tester, on pousse une image (hello-world) depuis une machine cliente après avoir configuré l’accès en mode insecure dans /etc/containers/registries.conf. Une solution simple et locale pour héberger ses images conteneurisées.

Exemple de commande clé :

podman run -d --name registry -p 5000:5000 -v ~/podman-registry/data:/var/lib/registry:Z [...]

Scott H Young explore dans cet article les implications de l'IA sur l'apprentissage des compétences et le travail qualifié, en se concentrant sur le "vibe coding", une pratique où des agents IA écrivent du code à la place des programmeurs. Il souligne l'incertitude entourant les développements futurs de l'IA et les difficultés à prédire ses effets à long terme. Bien que les programmeurs professionnels expriment des scepticismes sur la qualité du code généré par IA, Young, en tant qu'amateur, adopte une approche plus neutre. Il partage ses expériences positives avec le vibe coding, ayant utilisé des agents IA pour créer des outils simples et utiles, comme un script pour étudier des vidéos en chinois. L'article questionne si cette technologie démocratise la programmation ou inonde le marché de code de mauvaise qualité.

Ce billet introduit l'architecture RAG (Récupération Augmentée par Génération) comme solution aux hallucinations des LLM (Large Language Models). Les hallucinations, résultant du fonctionnement probabiliste des LLM, sont des réponses inventées par l'IA en l'absence de données suffisantes. L'architecture RAG propose de remédier à ce problème en combinant la capacité des LLM à générer du texte avec une base de données fiable et contrôlée. Ainsi, l'IA peut générer des réponses plus précises et sourcées, évitant ainsi les inventions non fondées.

Un outil bien pratique

Cet article présente les techniques de pagination des API pour les systèmes évolutifs, illustrées par des exemples concrets de Twitter (X) et Spotify. L'article explique pourquoi la pagination est nécessaire pour gérer efficacement de grands ensembles de données, en évitant les problèmes de lenteur, de consommation de bande passante et de mémoire. Il détaille deux méthodes principales : la pagination Limit-Offset, où le serveur divise les données en pages et renvoie un nombre limité de records en fonction d'un décalage (offset), et la pagination par curseur, qui utilise des identifiants uniques pour naviguer à travers les données. L'article met en avant les avantages et les inconvénients de chaque méthode, aidant les lecteurs à choisir la stratégie de pagination la plus adaptée à leurs besoins.

Dans cette BD, l'auteur explique que les bannières de cookies, bien que souvent associées au RGPD, ne sont pas imposées par ce règlement. Il détaille les cas où elles ne sont pas nécessaires et critique l'utilisation abusive de ces bannières, souvent liées à la transmission de données à des tiers. L'auteur propose des alternatives moins intrusives et compare la situation à l'expérimentation "Oui Pub". Une lecture éclairante pour comprendre les enjeux des cookies et du consentement en ligne.

Learn LaTeX propose un cours gratuit en ligne pour débutants, structuré en 16 leçons courtes et pratiques. Chaque leçon aborde des concepts essentiels de LaTeX, un système de préparation de documents, avec des exemples modifiables directement en ligne. Les sujets vont des bases de LaTeX à l'intégration d'images, en passant par les mathématiques, les bibliographies et la gestion des erreurs. Le site offre également des leçons complémentaires, comme l'utilisation de LaTeX en français, et des recommandations pour approfondir ses connaissances.

L'auteur décrit son infrastructure autohébergée basée sur un cluster Proxmox composé de trois machines identiques, choisies pour leur facilité de maintenance, leur faible coût et leur faible consommation électrique. Il explique les raisons de ce choix, notamment la gestion des pannes et la tolérance aux pannes réseau. Il mentionne également un nœud de test et un serveur de sauvegarde, ainsi qu'un NAS Synology utilisé pour les sauvegardes hors ligne. L'auteur souligne l'importance de documenter et de partager ce type d'infrastructure, qui est rarement décrit en détail.

Cet article propose des habitudes de productivité concrètes pour les ingénieurs. Il aborde trois stratégies principales : rester débloqué en parallélisant les implémentations (backend vs frontend par exemple) pour minimiser les temps d'inactivité, réduire le temps de débogage en comprenant la structure du code et en investissant dans la journalisation, et investir dans l'outillage, notamment dans le domaine de l'IA, pour automatiser les tâches répétitives. Ces habitudes visent à améliorer l'efficacité et à surmonter les défis courants dans le développement logiciel.

L'article explore les éléments clés pour concevoir une interface intuitive. Il souligne que la clarté ne se résume pas à un modèle prédéfini, mais résulte d'un travail systématique prenant en compte les objectifs business, le produit et la pensée des utilisateurs. Une interface intuitive doit être prévisible, mais aussi visuellement de qualité, cohérente et alignée avec les attentes des utilisateurs. Une mauvaise conception visuelle peut rendre même les structures les plus simples confuses. L'article met en avant l'importance de comprendre l'expérience utilisateur à travers le prisme de l'utilisateur, et non du designer.

Cet article traite des problèmes de performance d'IntelliSense dans les projets Nx et Turborepo, notamment dans les monorepos TypeScript. Les symptômes incluent des retards d'autocomplétion, des gels de l'éditeur et des erreurs fantômes. L'article explore quatre hypothèses possibles : une mauvaise configuration de Nx, des références manquantes dans TypeScript, des inclusions/exclusions trop larges dans tsconfig.json, et la complexité croissante du codebase. Une enquête approfondie est nécessaire pour identifier la cause racine de ces problèmes de performance.

Cet article de SitePoint explique l'importance des titres (headings) en HTML au-delà de leur simple aspect visuel. Les titres sont sémantiques et structurent le contenu d'une page, facilitant la navigation pour tous, y compris les utilisateurs d'aides technologiques. Ils aident également au référencement (SEO) et aux moteurs de recherche. L'article souligne l'importance d'utiliser les niveaux de titres correctement (de h1 à h6) pour créer une hiérarchie logique, et non pour le style, qui doit être géré par CSS. Une mauvaise utilisation des titres peut nuire à l'accessibilité et à la compréhension de la structure de la page.

Ploum explore le concept de calendar.txt, un fichier texte simple pour gérer son emploi du temps, et partage comment il l'a intégré dans son workflow Unix. Il apprécie la simplicité et l'efficacité des commandes basées sur le texte pour afficher les événements du jour, ajouter des événements récurrents, et gérer les invitations, contrastant cela avec la lourdeur des interfaces web et les "redesigns" constants. Il voit en calendar.txt un exemple parfait de la puissance des outils Unix pour créer des solutions personnalisées et élégantes, loin des plateformes commerciales complexes.

Ce partage explique comment utiliser Symfony 7 et Mercure pour créer une session live réactive sans WebSocket. L'auteur, Jean-Sébastien Christophe, explore l'intégration de Mercure, un protocole de Server-Sent Events (SSE), pour gérer des états de session en temps réel, comme la présence des utilisateurs, sans nécessiter de requêtes répétées ou de boucles côté client. Il détaille la stack technique utilisée (Symfony 7.3, PHP 8.4, Docker, PostgreSQL, MailCatcher) et les avantages de Mercure pour des applications temps réel, tout en prévoyant une future intégration avec FrankenPHP pour optimiser les performances et la sécurité.

L’article explore la distinction cruciale entre User Need (besoin utilisateur) et Product Need (besoin produit) dans le développement de produits digitaux. Un User Need exprime un problème ou une frustration perçue par l’utilisateur, souvent formulée comme une solution concrète (ex. : « Je veux un bouton plus gros »). Le Product Need, en revanche, est le problème business sous-jacent identifié après analyse (ex. : « Assurer une découvrabilité optimale des actions principales »). L’auteur souligne l’importance de ne pas confondre les deux : écouter une demande utilisateur, c’est entendre une solution proposée, tandis que comprendre un besoin, c’est identifier le problème réel à résoudre. Pour y parvenir, des outils comme la méthode des 5 Pourquoi ou l’observation terrain permettent de creuser au-delà des demandes apparentes et d’éviter des solutions techniques inutiles. L’objectif ? Créer des produits qui répondent à des besoins profonds, et non à des demandes superficielles, en alignant valeur utilisateur et objectifs business.

Exemple marquant : Un livreur demandant un vélo plus léger cache en réalité un besoin d’optimisation logistique.

L’article plaide pour une utilisation plus réfléchie et minimaliste des animations dans les interfaces numériques. Plutôt que de multiplier les effets visuels pour séduire, il invite à privilégier la retenue et l’intention : chaque animation doit avoir un but clair (guider, confirmer une action, expliquer une fonctionnalité) et ne pas alourdir l’expérience utilisateur. Les interfaces les plus efficaces sont celles qui se font oublier, en minimisant les frictions. L’auteur souligne l’importance de la performance perçue (idéalement sous 300 ms par animation), du respect des préférences utilisateur (comme l’option « réduire les animations »), et de l’inclusivité, notamment pour les personnes neuroatypiques. L’objectif ? Créer des expériences calmes, prévisibles et accessibles, où le mouvement sert l’utilisateur sans le distraire. Une question clé à se poser : « Pourquoi cette animation ? »—et si la réponse est « juste pour faire joli », mieux vaut s’en passer.

Matter et Thread révolutionnent la domotique en apportant interopérabilité et simplicité. Matter est un protocole open source qui unifie la communication entre objets connectés (Wi-Fi, Ethernet, Thread), permettant à un appareil de fonctionner avec n’importe quelle plateforme (Apple Home, Google Home, Alexa) sans cloud ni passerelle dédiée. Thread, quant à lui, est un réseau maillé IPv6 (basé sur IEEE 802.15.4) qui assure un transport fiable et local des données. Ensemble, ils permettent une intégration directe des appareils dans les écosystèmes existants, sans dépendre des applications ou hubs propriétaires. Résultat : plus de compatibilité entre marques, une installation simplifiée, et une communication sécurisée en local. Les solutions comme Home Assistant (via Matter Server) ou Jeedom (en cours d’adaptation) s’appuient sur ces standards pour centraliser la gestion. En bref, Matter et Thread promettent une domotique universelle, locale et sans silos, comme l’USB-C pour les objets connectés.