Post de Max Lyon

Voici le genre de magie que l’on peut faire en combinant Notion & Make ✨ Ceux qui ont l’habitude de me lire savent combien je trouve Notion fantastique. Ce service m’a aidé à croire que je peux être organisé et productif en créant mon mode de fonctionnement. Depuis un moment je peux le dire : je range tout au bon endroit, j’ai une visibilité sur mon temps de travail et ma productivité, chaque client, tâche & projet est à sa place. 🔒 Une fois mon Notion optimisé, j’ai rencontré une autre problématique commune : la génération de documents. De manière si répétitive … Vas-y que je copie colle Et que j’ouvre un énième modèle de facture Que je change les informations Que j’exporte en PDF Que j’ouvre mes mails Que je copie-colle à nouveau Que j’envoie mon mail 😴 Je me ronfle dessus, zzzzz Parmi les innombrables automatisations possibles en #nocode, j’ai trouvé une solution gratuite pour générer des documents (devis, factures, bons de commande, reçus, images, ….). Je vous propose de vous construire cela en direct sur Twitch ! 📺 Vous pourrez me retrouver aujourd’hui-même, de 13h à 14h sur la chaîne de No-Code France - le lien dans le premier commentaire ! Vous venez ?

Le concept le plus sous-estimé par la majorité des développeurs : la gestion explicite des dépendances C’est un point qu’on néglige souvent, mais qui fait toute la différence entre un code fragile et un système robuste : comment gérer nos dépendances ? Beaucoup de développeurs pensent que c’est un simple détail technique. Pourtant, une mauvaise gestion des dépendances peut transformer ton projet en un monstre difficile à maintenir : Dépendances cachées : Des modules qui dépendent les uns des autres sans qu’on le sache clairement Couplage fort : Impossible de modifier une partie du code sans impacter tout le reste Rigidité : Ton code devient tellement lié à des frameworks ou outils spécifiques qu’il devient presque impossible de les remplacer Mais c’est quoi, bien gérer ses dépendances ? C’est appliquer des pratiques simples mais puissantes : 1️⃣ Lister clairement les dépendances Chaque classe ou module doit dépendre uniquement de ce qui est explicitement déclaré, idéalement via des abstractions (interfaces) 2️⃣ Favoriser l’injection de dépendances Au lieu de laisser une classe créer ses propres dépendances (ex. : new PaymentService()), passe-les-lui par le constructeur ou via une méthode. Ça facilite le remplacement et les tests 3️⃣ Inverser les dépendances Ton code métier doit définir les règles (abstractions) que les dépendances externes doivent suivre, et non l’inverse 5️⃣ Réduire le couplage Chaque module doit être autonome. Si ton code métier a besoin d’une base de données, il ne doit pas dépendre directement d’une bibliothèque SQL, mais d’une interface générique Toujours pas convaincu, je te fais une analogie simple Imagine que tu construis une voiture : La carrosserie (ton domaine métier) ne doit pas dépendre d’une marque de pneus spécifique. Elle doit juste spécifier “il me faut des roues de cette taille”. Peu importe si tu utilises des pneus Michelin ou Goodyear, la voiture fonctionne pareil Pourquoi c’est si important ? 1️⃣ Testabilité En isolant clairement les dépendances, tu peux facilement tester chaque partie de ton code sans avoir besoin de toute l’infrastructure 2️⃣ Flexibilité Tu veux remplacer PostgreSQL par MongoDB ? Ou passer d’une API externe à une autre ? Une bonne gestion des dépendances rend ça simple 3️⃣ Maintenance Ton code devient plus lisible, plus modulaire, et donc plus facile à maintenir Ce n’est pas un luxe, mais une nécessité que tu peux t’approprier Ne néglige pas la gestion explicite des dépendances. Ce n’est pas non plus un détail, c’est ce qui garantit la solidité et l’évolutivité de ton projet Et toi, quelles pratiques utilises-tu pour gérer tes dépendances ? Partage ton expérience en commentaire !

🔗 Dépendances circulaires = casse-tête garanti ! Voici comment l'ADP peut t’aider Si tu t'es déjà retrouvé dans un casse-tête de dépendances circulaires en code, tu sais à quel point cela peut rendre le développement complexe et frustrant 😓. Pourquoi ? Parce qu'un cycle de dépendance entre plusieurs modules (A → B → C → A) crée un enchevêtrement difficile à maintenir. Changer un composant en impacte alors d'autres de façon imprévisible 🚨. Cela complique aussi la compréhension et les tests. 👉 𝗟'𝗔𝗗𝗣 (𝗔𝗰𝘆𝗰𝗹𝗶𝗰 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲) 𝗽𝗿𝗲́𝗰𝗼𝗻𝗶𝘀𝗲 𝗱𝗲 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗿 𝗹𝗲𝘀 𝗱𝗲́𝗽𝗲𝗻𝗱𝗮𝗻𝗰𝗲𝘀 𝗱𝗲 𝗺𝗮𝗻𝗶𝗲̀𝗿𝗲 𝗮̀ 𝗳𝗼𝗿𝗺𝗲𝗿 𝘂𝗻 𝗴𝗿𝗮𝗽𝗵𝗲 𝗼𝗿𝗶𝗲𝗻𝘁𝗲́ 𝗮𝗰𝘆𝗰𝗹𝗶𝗾𝘂𝗲, ce qui signifie qu'aucun composant ne devrait dépendre d'un autre qui finit par dépendre de lui-même. Cela permet de garder une 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗺𝗼𝗱𝘂𝗹𝗮𝗶𝗿𝗲, 𝗳𝗮𝗰𝗶𝗹𝗲 𝗮̀ 𝗳𝗮𝗶𝗿𝗲 𝗲́𝘃𝗼𝗹𝘂𝗲𝗿 et à tester, tout en réduisant les risques de répercussions en cascade lors de changements. En pratique, si un cycle de dépendances est détecté, tu peux : 1. Ajouter une abstraction (interface ou classe abstraite) pour briser le cycle. 2. Créer un nouveau composant intermédiaire. 💡 En bref : respecter l'ADP, c'est t'assurer une structure évolutive et robuste dans tes projets. Cela te permet de rester agile et de maîtriser les changements dans ton code sans risque d’effet domino. As-tu déjà fait face à des dépendances circulaires dans tes projets ? Comment les as-tu résolues ? Partage ton expérience en commentaire 👇

Pourquoi prenez-vous tant de temps sur vos projets ? "La première version de la plateforme doit être achevée cette semaine, fais de ton mieux pour finir", m'avait-on dit. Je savais que j’étais seul à développer la plateforme et que le temps que j’avais à y consacrer était insuffisant. Néanmoins, je n'avais pas d'autre choix, les dés étaient déjà jetés. En effet, on m'avait confié la lourde responsabilité de travailler sur le développement complet d'un macro-logiciel de gestion intégré pour un client. Habituellement, j'ai tendance à envisager les choses avec une vue un peu trop avancée, à accorder de l'importance aux détails et à avoir des exigences élevées en termes de travail. Cependant, je me suis résolu à respecter le délai qui m'avait été imparti. J'ai donc commencé par examiner l'ensemble des fonctionnalités à développer, puis j'ai dégagé les fonctionnalités prioritaires et urgentes à présenter en premier. Je me suis concentré sur celles-ci, les ai développées, puis j'ai planifié les autres fonctionnalités pour les travaux à réaliser ultérieurement. En réfléchissant à cette situation, une seule chose me vient à l'esprit : le fondement de la loi de Pareto affirme que 80 % des résultats proviennent de 20 % des actions. En fait, j'ai été contraint de dégager les 20 % des fonctionnalités importantes qui donneraient 80 % des résultats, et j'ai commencé par les traiter en priorité. Ainsi, la prochaine fois que vous aurez quelque chose à faire, commencez par les 20 % qui auront le plus d'impact. Je suis Rabelais Mahugnon KPECHEKOU, créateur de contenus, architecte logiciel et développeur web (je suis également écrivain béninois à titre semi-professionnel, auteur d'un recueil de nouvelles intitulé Wanilo). Jour 04 #UneHistoireUneDecouverte #loipareto #semainedeslogiciels

🔥 “Quand la mise à jour dégénère… et que je finis par tout réécrire moi-même en 1h” 🔥 Alors, ça t’est déjà arrivé aussi ? J’étais en train de faire une montée de version Angular, tranquille, tout allait bien… jusqu’à ce que je tombe sur un petit coup de Trafalgar : mon carousel avait explosé. Rien ne fonctionnait. Plus de sliders, plus de transitions. C’était le vide intersidéral. Bon, je tente la correction en mode « réparateur de fortune ». Mais impossible de remettre d’aplomb cette lib qui, clairement, n’était plus dans le coup. Et là, le pire dans tout ça ? Elle était utilisée à un seul endroit. 🙃 👉 Ni une, ni deux, j’ai fait ce qu’un dev pragmatique ferait : j’ai dégagé la lib et je me suis lancé dans un carousel fait maison. Bilan : en 1h et à peine 40 lignes de code (HTML/CSS, un peu de sauce maison), j’avais mon carousel qui tournait. Résultat ? Plus de lib inutile, code léger, performance améliorée, et maintenance simplifiée. Juste moi et un code clean, sans ressources qui se traînent. Et en prime, impact RSE : moins de dépendances, c’est aussi moins de charge côté serveur. ( c'est Arnaud Liotard qui va être content ) Moralité ? Parfois, la meilleure optimisation, c’est de revenir à l’essentiel. Qui ici a déjà dégagé une lib pour la remplacer par du code maison ? Partage tes expériences en commentaire ! 👇

Aujourd'hui, c’est le rodage de ma formation sur l’archi hexagonal et le DDD tactique. Le but ? Vous donner les outils pour travailler sur des applications complexes et métiers. Fini les apps CRUD livrées en 2 mois… et on passe sur des gros projets avec du challenge. Première session demain pour tester le contenu et les exercices. Grâce au feedback, je pourrai ajuster tout ça. Petite particularité de la session : on le fait en remote sur Gather ! On va voir si ça casse vraiment la distance et si ça évite la lourdeur des visios. Mon objectif ? Que tout soit au top pour la première session officielle ! Tu veux en savoir plus sur la formation ? Toutes les infos dans les commentaires. 👇 --------------------------------------- Je suis Arnaud Langlade, artisan logiciel. Je t’aide à livrer des logiciels pérennes et évolutifs. 1️⃣ Des difficultés à livrer ? Je coach tes équipes tech ou je t’aide à poser les fondations de ton logiciel pour améliorer les livraisons en production. 2️⃣ ️Besoin de former tes équipes ? Je forme tes équipes pour qu'elles livrent du code de qualité. Check ma bio pour plus d’info.

Vous avez certainement déjà été ce développeur. Celui qui se dit : "Ça va ! Pas besoin de commenter, mon code est clair !" Celui qui, trois mois plus tard, ouvre son propre fichier et s’interroge : "Qu’est-ce que j’ai voulu faire, là ?" Ou encore celui qui se retrouve à déchiffrer les hiéroglyphes laissés par un collègue pressé (ou négligent). Pour ceux qui ne savent pas de quoi je parle, quand on fait du code, il est fortement conseillé de laisser des indications sur ce qu’on veut faire avec une section de code. Parce qu’un code non commenté, c’est un cadeau empoisonné pour le vous du futur ou pour la personne qui reprendra votre travail. Mais bien souvent, on ne le fait pas... Parce que oui, commenter demande du temps. Oui, ça coupe parfois votre élan. Mais c’est pas idiot d’expliquer que la fonction addUser() ne se limite pas à ajouter un utilisateur, mais vérifie aussi ses 12 derniers mois d’activité et appelle une API. Commenter son code, c’est un peu comme poser des panneaux de signalisation. Ça évite à celui qui suit de finir de se planter, ou pire ! De s’égarer dans une jungle de boucles interminables. Et non, c’est pas une excuse valable de dire : "Mon code est suffisamment clair, je n’ai pas besoin de commentaires." C’est peut-être vrai aujourd’hui, mais dans six mois ? Quand vous aurez travaillé sur trois autres projets, adopté de nouvelles approches, et que la syntaxe qui vous semblait évidente deviendra un véritable casse-tête ? Un bon commentaire, c’est pas un roman. C’est une simple annotation, bien placée, qui explique : "Cette fonction sert à ça", ou "Ce paramètre a cette utilité". Un commentaire bien pensé, c’est un cadeau que vous vous offrez, et que vous faites également à ceux qui croiseront votre chemin 😅 Alors, faites-vous ce cadeau 😉

Qualité applicative : parlons-en, mais sans se prendre la tête ! Quand on parle de qualité avec les développeurs ou les clients, c'est un peu comme discuter de la météo : tout le monde a un avis, mais personne ne veut vraiment se mouiller. Pourtant, c'est un sujet crucial, surtout quand on lance un nouveau projet. Pourquoi la qualité, c'est important ? - Pour les développeurs : ça évite de se retrouver avec un code spaghetti, impossible à démêler. 🍝 - Pour les clients : un produit de qualité, c'est une app qui marche, mais c'est ce qui était demandé implicitement, non ? Les signes qui montrent qu'il y a un problème : - Les développeurs commencent à avoir l'air un peu perdus 😔.  - ⌚ Les délais s'allongent plus vite qu'une file d'attente pour manger une entrecôte à Bordeaux.  - L'application plante après une 🌻 mise en production 🌻.  - L'équipe technique commence à ressembler à 🔥 des pompiers qui courent partout pour éteindre des incendies 🔥. Et le client dans tout ça ? Le client, lui, il veut juste un bouton qui fonctionne, d'après lui « c'est simple ! » Un bouton qui résout tous ses problèmes.  Mais la réalité, c'est que même un bouton a besoin d'être bien conçu pour durer dans le temps. Comment convaincre un client de l'importance de la qualité ? - Parler clair : éviter le jargon technique, et pour autant expliquer qu'il y a des orientations ou des actions qui sont intrinsèques à la bonne réalisation.  - Utiliser des exemples concrets : montrer les conséquences d'une mauvaise qualité... « Humm, oui c'est difficile de faire de la maçonnerie sans ciment et joints entre les briques… »  - Être patient : changer les habitudes, faire comprendre un savoir-faire non tangible, non visible, ça prend du temps, beaucoup de temps, mais c’est un investissement ! Finalement, la qualité, c'est un peu comme la santé : on s'en rend compte quand on ne l'a plus. Alors autant y penser dès le début !!! Et si on doit choisir entre un produit rapide et un produit bien fait, la réponse est simple : On prend le temps de bien faire les choses. Après tout, le client était en attente d'un bouton qui marche, non ? 😎

Cher réseau, j'ai démarré il y a quelques jours un nouveau projet qui permet de calculer son indice de masse corporelle. Si je n'ai pas ajouté de nouvelles fonctionnalités, je ne suis pas resté inactif bien au contraire, j'ai refactorisé mon code afin qu'il soit plus lisible et maintenable. En effet, j'avais un composant énorme avec des conditions dans tous les sens, et je me suis dit que si je devais y revenir dans une semaine, j'aurai beaucoup de mal à m'y retrouvé. J'ai donc scindé ce composant en composants plus petits et plus facile a lire et surtout à maintenir. J'ai donc passé certaines informations à mon composant parent en utilisant des props, concept que j'ai eu dû mal à saisir au début, mais qui devient de plus en plus "limpide" (oui j'ai encore du boulot à faire là-dessus ^^). J'ai également externalisé certaines fonctions, afin de déplacé ma logique et pouvoir modifier mes fonctions plus aisément. J'ai également retiré deux fonctions qui étaient en fait deux énormes if else en une seule plus petite et plus simple. Il y a sûrement d'autres fonctionnalités que je pourrai ajouter, mais ce qui est sûr, c'est que j'ai encore franchi un palier dans mon évolution. Je me pose moins de questions, je fais de moins en moins appel à l'IA pour m'aider à résoudre mes problèmes (non l'IA ne code pas à ma place c'est juste un outil qui m'épaule au cas je bloque complètement ^^), mon raisonnement est plus fluide et je me sens de plus en plus capable lorsque je dois intégrer une nouvelle feature. Pour celles et ceux qui auraient envie de voir le code, je vous laisse le lien du repo ici : https://lnkd.in/e-Fj7rPx. Et pour celles et ceux qui veulent tester voici le lien de l'application : https://lnkd.in/edK2xHKp Je vous souhaite une belle journée et à très bientôt pour de nouvelles aventures ! Prenez soin de vous !

🚀 Utiliser les Observers pour surveiller les événements des modèles en laravel Les Observers te permettent d'écouter les événements du cycle de vie d'un modèle (création, mise à jour, suppression, etc.) et de déclencher des actions en conséquence. C'est un excellent moyen de séparer la logique métier de ton modèle.