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.
L’article explique comment moderniser un système de logging dans Symfony en remplaçant les déclencheurs (triggers) traditionnels par les événements Doctrine, une approche plus flexible et maintenable. L’auteure, Jinal Solanki, détaille les limites des triggers (dépendance à la base de données, manque de souplesse) et propose une solution basée sur les listeners Doctrine pour intercepter les opérations CRUD (Create, Read, Update, Delete) directement dans le code PHP. Cette méthode permet de centraliser la logique de logging, de faciliter les tests unitaires et d’éviter les effets de bord liés aux triggers SQL. Elle illustre la mise en œuvre avec des exemples concrets : création d’un EventSubscriber pour écouter les événements prePersist, preUpdate et preRemove, puis enregistrement des changements dans une table dédiée. L’avantage principal est une meilleure intégration avec le code métier, une maintenance simplifiée et une indépendance vis-à-vis du SGBD. Une solution idéale pour rendre le logging évolutif et cohérent dans une architecture Symfony.
L’article présente l’utilisation de Make pour simplifier et standardiser les commandes courantes dans un projet Symfony, surtout en environnement Docker. L’auteur partage ses Makefiles personnalisés, qui permettent de lancer des tâches comme l’installation des dépendances (make composer), l’exécution des tests (make test), l’analyse statique (make static-analysis), ou encore la gestion de la base de données (make db-reset), le tout avec des paramètres optionnels pour l’environnement (env=prod) ou des arguments supplémentaires (arg=--testdox). Grâce à Make, les commandes Docker complexes deviennent simples et documentées (ex: make qa pour lancer la vérification de code, l’analyse statique et les tests en une seule commande). L’article propose trois versions de Makefile : pour Docker Compose, Docker seul, et PHP natif, inspirées du projet symfony-docker. L’objectif est d’améliorer la productivité en évitant de retaper des commandes longues et en centralisant la documentation des tâches disponibles. Une solution élégante pour uniformiser les workflows entre projets Symfony.
L'auteur explore dans son article les valeurs méconnues de l’attribut href des liens HTML. Par exemple, href="#" fait défiler vers le haut (sauf si un élément id="top" existe), tandis que href="" recharge la page en gardant les paramètres de recherche mais supprime le fragment. Avec href=".", la page est rechargée en supprimant à la fois les paramètres et le fragment, mais attention à la structure de l’URL pour éviter des comportements inattendus. href="?" efface les paramètres et le fragment, mais conserve le ?. On peut aussi utiliser href="data:" pour créer des liens vers des données encodées directement dans l’URL, ou href="video.mp4#t=10,20" pour cibler une plage temporelle dans un média. L’article rappelle aussi l’existence des protocoles comme mailto: ou tel:, ainsi que les fragments de texte (#:~:text=foo). Une lecture utile pour exploiter pleinement les possibilités des liens en HTML.
Il s'agit d'une liste organisée de commandes slash, de fichiers CLAUDE.md, d'outils CLI, d'autres ressources et guides pour améliorer votre flux de travailavec Claude Code. Claude Code est un assistant de codage et un agent de pointe basé sur CLI auquel vous pouvez accéder dans votre terminal ou IDE. C'est un outil en évolution rapide qui offre un certain nombre de capacités puissantes, et permet de beaucoup de configuration, de nombreuses manières différentes.
L’attribut HTML hidden="until-found" permet de masquer du contenu tout en le rendant accessible via la recherche dans la page (Ctrl+F). Contrairement à display: none ou visibility: hidden, il utilise content-visibility: hidden en interne, ce qui cache visuellement le contenu sans l’exclure des résultats de recherche. Utile pour des cas comme des accordéons ou des sections cachées, il est déjà supporté par Chrome, Firefox et bientôt Safari. Une alternative à <details> pour des contenus masqués mais "trouvables", avec des polyfills possibles via le Shadow DOM en attendant une adoption universelle. Une future pseudo-classe ::search-text pourrait même permettre de styliser les correspondances de recherche.
L’article explore l’utilisation de Claude Code, un outil basé sur des modèles de langage avancés, pour développer des applications complètes en "vibe coding" — une méthode où l’on crée du logiciel presque exclusivement en dialoguant avec une IA, sans éditer manuellement le code. L’auteur illustre cette approche en générant un clone simplifié de Splitwise en une seule requête, montrant comment une spécification claire et concise (comme un fichier SPEC.md) permet d’obtenir une application fonctionnelle en PHP, sans framework ni dépendances lourdes, contrairement à une version JavaScript surchargée et dysfonctionnelle. Il souligne l’importance de la qualité de l’input et de la simplicité technique pour maximiser l’efficacité de l’IA. L’article va plus loin en décrivant des expériences d’automatisation poussée : création d’une startup autonome sur un VPS, migration d’un projet Laravel en production, et développement rapide de petits outils (plugin HackerNews, générateur de posters, renommage de fichiers bancaires). Malgré des limites (incohérences, blocages par les politiques d’usage), l’auteur souligne le potentiel révolutionnaire de ces outils pour accélérer le développement, réduire la charge mentale et rendre la création logicielle accessible à tous, tout en rappelant que l’IA reste un "calculateur de mots" nécessitant une supervision humaine pour les tâches complexes ou créatives.
Pourquoi les super-riches sont inévitables explique, via le "Yard-sale model" (modèle de la vente de garage), comment une économie de marché libre, même avec des échanges équitables et aléatoires, finit par concentrer la richesse entre les mains d’une infime minorité. À travers une simulation de jeux de pile ou face où chaque joueur mise un pourcentage fixe de sa fortune, on observe que les perdants perdent progressivement leur capacité à regagner ce qu’ils ont perdu, tandis que les gagnants accumulent toujours plus. Résultat : sans redistribution, un seul individu finit par posséder presque toute la richesse, purement par effet mécanique et chance. Le modèle, issu de l’éconophysique, illustre ainsi comment l’inégalité économique peut émerger naturellement, et suggère que seule une redistribution (comme les impôts) peut limiter ce phénomène. Une réflexion frappante sur les limites du "mérite" et les dynamiques structurelles de l’inégalité.
L’IA est un outil puissant pour accélérer et optimiser le développement, pas pour remplacer les devs. L’article illustre comment intégrer l’IA à chaque étape d’un projet (ex. : un site de location de voitures) : planification (génération de briefs et wireframes en quelques minutes), design (création d’interfaces et de code HTML/CSS via des outils comme v0.dev), boilerplate (conversion rapide en React/TypeScript avec des prompts précis), et amélioration (refactoring collaboratif pour rendre le code scalable et propre). L’IA automatise les tâches répétitives (recherche, design, code basique), mais c’est au développeur de superviser, architecturer et corriger les imperfections (logique métier, réutilisabilité). L’enjeu ? Travailler plus intelligemment, en utilisant l’IA comme un "pair programmer" pour se concentrer sur les défis complexes (architecture, UX, performance). À condition de rester critique : l’IA génère du code, mais c’est à vous d’en garantir la qualité et l’éthique. "Un dev qui maîtrise l’IA aura toujours un avantage."
L’article démystifie les différences entre piles (jetables, non rechargeables), accumulateurs (rechargeables, souvent appelés à tort "piles rechargeables") et batteries (assemblages de cellules). Il explique les formats standardisés (AA, AAA, 18650, etc.), les technologies (alcaline, NiMH, lithium-ion, sodium-ion), et leurs avantages/inconvénients : les piles alcalines peuvent fuir, les lithium-ion offrent de hautes performances mais sont inflammables, tandis que le sodium-ion émerge comme une alternative plus écologique et sûre. Le choix entre piles et accumulateurs dépend de l’usage : les accumulateurs sont recommandés pour les appareils gourmands en énergie ou critiques, mais leur coût et leur gestion (éviter de mélanger les modèles, surveiller la capacité) peuvent limiter leur intérêt pour un usage occasionnel. L’article donne aussi des conseils pour choisir des marques, des chargeurs (privilégier les modèles USB-C avec mesure de capacité) et optimiser la durée de vie des batteries (éviter les charges/décharges extrêmes, privilégier la charge lente). Une ressource utile pour y voir plus clair et faire des choix éclairés, tant pour l’environnement que pour le portefeuille.