Post de Fabrice G.

Quand je passe après un junior, je vois toujours les mêmes erreurs. Pourtant c’est des basiques 😱 En quelques mois, j’ai eu 3 missions assez similaires. Chaque fois, c’était un SaaS développé par un profil junior avec un code contenant beaucoup de bugs et difficile à faire évoluer. Pourquoi par un junior ? La raison est toujours la même: pas de budget pour un sénior en début de projet. Dans les 3 cas, j’ai vu les mêmes erreurs. Des erreurs relevant de basiques que tout développeur devrait connaître. 🤷🏻♂️ Peu d’usage de TypeScript Malgré que tout le projet soit en TypeScript, il y a peu de typage. Voir pas du tout. Le type any est légion. Je ne suis pas fan de l’inférence de type. Je préfère typer l’ensemble du code “à la main”. Plutôt qu’utiliser un type any bien sale, je préfère utiliser le type unknown. Il permet de gérer les rares cas où on ne connaît pas le type. 🔁 Asynchrone et boucle Un joli await dans une boucle for … C’est la preuve d’une grande méconnaissance de Node.js. Pour faire court et simplifié: la réponse de la requête asynchrone arrivera après la fin des itérations de la boucle. La solution est pourtant très simple: Un tableau de promesses + Promise.all(); Ou mieux: Promise.allSettled() pour gérer finement les erreurs. 🔍 Logs inexistants Là encore, typique du manque d’expérience. C’est pourtant l’un des piliers qui assure le succès du projet: La supervision. Savoir ce qui se passe à tout moment dans le SaaS est essentiel. Surtout quand c’est codé avec le 🍑 et qu’il y a plein de bugs 😅 On a des solutions très simple pour les logs de l’app. Je suis très fan de Winston. Sa communauté a dev’ plein de Transport: GCP, AWS, Elastic, … Plus simple et plus léger: Pino.js 🏗️ Manque de structure Forcément avec tout ça, le manque de structure dans le projet est évident. Pas de séparation entre l’API, la logique métier et la base de données. Des fonctions interminables. Du code spaghetti. Pas d’industrialisation. Pas de tests. La solution est radicale: un bon gros refactoring du projet 👌 Objectif: mise en place d’une Clean Architecture, respect des standards que qualité et mise en oeuvre des solutions pour augmenter l’efficience des développements. Je ne veux pas blâmer les juniors. Un sénior n’est qu’un junior avec 10 ans d’expérience. Et en soi … ils me donnent du travail indirectement 😅 Par contre, je ne comprendrais jamais cette décision des CEO. Car au final, leur projet leur coûte 3x plus cher que s’il avait été bien fait dès le début 💸

Il y a quelque temps, je vous parlais de mon virage vers de nouveaux horizons en changeant ma stack. Aujourd'hui, je suis de retour pour vous donner un aperçu de mes outils flambant neufs ! ⚒️ 🔄 Au revoir Symfony, Bonjour Ruby on Rails! Eh oui je suis passée de Symfony à Ruby on Rails, et laissez-moi vous dire, c'est un changement qui vaut la peine d'être exploré. 🚂 Ruby on Rails, est un framework de développement web assez simpliste. Sa structure et ses conventions judicieuses (qui m'ont d'ailleurs donné du mal😅) font gagner un temps précieux, permettant de se concentrer sur l'essentiel ! L'approche "#convention_over_configuration" de Rails offre une expérience de développement fluide et intuitive, réduisant la nécessité de configurations fastidieuses et permet d'éliminer une tonne de code. Ça peut surprendre, mais Rails et Symfony partagent quelques concepts! 🤯 Tant par leurs architecture tous deux basées sur du MVC, que leur gestion de base de données qui passe par les ORM... Ce changement d'outils est plus qu'une simple transition. C'est carrément une aventure où chaque difficulté surmontée devient une victoire! 👋 Si vous avez des conseils, des retours d'expérience, je suis toute ouïe! 🤓 #RubyOnRails #WebDevelopment #conventionOverConfiguration #Symfony #MVC #ORM

J’utilise Geckosocial🦎 pour tous les posts LinkedIn que j’écris, j’ai rarement vu un outil aussi bien léché. Du coup, double reco : • Si vous cherchez un dev fullstack React / Node, je ne peux que vous conseiller Antoine 🦎 Chalifour, vous serez ravi de son investissement dans les projets et la qualité qu’il y apporte. • Si vous cherchez un bon outil pour écrire vos posts sur les réseaux sociaux, Geckosocial c’est de la balle.

Comment stocker ses dates dans un projet ? Bon déjà la gestion des dates dans n'importe quel langage de programmation c'est RELOU ! 😅 Comme ça je pose les bases ! Il y a bien longtemps, je stockais les dates naïvement sur le format FR, c.-à-d. d/m/y (ex : 31/12/2024)... J'étais si naïf 🤣 Mea culpa, à gérer humainement, c'est ce qui a de plus simple... Mais dans un projet... Ce n'est pas la même limonade 🥤 Effectivement, quand on va vouloir traiter cette date en aval, on va devoir par exemple comparer cette date avec d'autres... Et c'est là que les ennuis commence. Si j'utilise strtotime() sur une chaine "31/01/2024" ça devrait passer... Mais si je fais cette même fonction sur la date "02/01/2024", php comprendra cette date comme le premier février 2024 🫠 OUI, j'ai dit au début que c'était RELOU ! Nos amis anglophones, ne lisent pas les dates de la même façon que nous... Ou c'est nous qui faisons différemment d'eux 🤔 (question philosophique). Je m'égare 😅 Mais Jamy quelle est la solution ? L'unix solution (jeux de mot de geek), ou du moins la meilleur selon moi, c'est d'utiliser l'Unix timestamp ! L'heure Unix ou heure Posix est une mesure du temps fondée sur le nombre de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC (merci wikipédia). Par exemple, la date "2021-01-26" devient 1611615600 en UNIX timestamp. Ce format est top, car on supprime la notion de fuseau horaire au passage (encore un autre sujet relou) et on peut très facilement comparer des dates vu que l'on est sûr des valeurs numériques. Et bonus sur WordPress on a la fonction php wp_date() qui nous permet de formater un timetamp Unix en une date lisible tout en prenant en compte le fuseau horaire réglé dans votre installation WordPress. À ce stade de mon poste, il doit rester 2 ou 3 passionnés de code 🫣 Tu gères comment tes dates toi ?

Salut les amis ! Le week-end dernier, je me suis lancé un petit défi et j'ai réalisé un blog avec un nouveau framework que j'ai appris : AdonisJs. Pour ceux qui ne connaissent pas, c’est un framework Backend JS totalement TypeSafe et super populaire en ce moment. Et bah franchement, j'ai kiffé apprendre ce framework et de mettre rapidement en pratique ce que j’ai appris en créant mon blog. Ce qui est génial avec AdonisJs, c’est qu’il utilise TypeScript, donc tout est TypeSafe. Alors, qu’est-ce que j’ai fait exactement ? Voici le topo : Authentification Login et Register : J’ai mis en place un système d'authentification simple, mais aussi avec les réseaux sociaux. Parce que oui, on aime bien se connecter avec Facebook ou Google ! Mot de passe oublié : Pour ceux qui oublient tout le temps leurs mots de passe (comme moi 😆), j’ai ajouté une fonctionnalité pour les récupérer facilement. Système CRUD : Les auteurs sur la plateforme peuvent ajouter, modifier et supprimer leurs articles. Un vrai couteau suisse pour gérer leur contenu. Rendu dynamique : J’ai intégré une librairie pour rendre le blog aussi dynamique que si c’était du VueJs. Si vous ne faites pas gaffe, vous ne verrez même pas la différence 🤣. Gestion des utilisateurs : Et bien sûr, j’ai ajouté une gestion des utilisateurs pour organiser tout ce petit monde. En gros, voilà ce que j’ai fait du vendredi soir dernier au lundi 😊. Trois jours de taf intense, mais ça valait le coup ! Un des gros avantages d’AdonisJs, c’est que je peux l'utiliser facilement à la place de Laravel, mon framework PHP préféré, surtout quand je veux faire un projet avec un backend et un frontend séparés. Ça me permet de faire du JavaScript partout, en backend et en frontend, sans souci de changement radical quand je passe de l'un à l'autre. Si vous connaissez d'autres avantages ou avez des astuces à partager, n’hésitez pas à en parler dans les commentaires pour aider les juniors comme moi. Merci ! Allez, bisous les gars et à la prochaine !

🔍 Récemment, j'ai publié une roadmap complète pour devenir Fullstack JS 🚀 Cependant, être développeur Fullstack ne se limite pas à maîtriser le frontend et le backend. Il y a bien plus à apprendre pour être vraiment polyvalent. Voici les compétences supplémentaires qui vous rendront incontournable en 2024 ! 💪

Réflexions sur la gestion des dépendances avec Node.js : un appel à la simplicité En tant que développeur senior en Golang, j’ai souvent eu l’occasion de travailler avec différentes technologies et langages. Récemment, j’ai eu une expérience qui m’a amené à réfléchir à la gestion des dépendances, en particulier dans l'écosystème Node.js. Il est indéniable que Node.js a révolutionné le développement web, offrant des possibilités infinies grâce à sa vaste bibliothèque de modules. Cependant, j’ai constaté que la gestion de ces dépendances, en particulier le dossier `node_modules`, peut rapidement devenir un véritable casse-tête. Imaginez passer la majeure partie de votre matinée à essayer de mettre à jour vos bibliothèques. On vous recommande d’utiliser `ncu -u` pour effectuer cette tâche en toute sécurité. Pourtant, le résultat est souvent frustrant : des conflits de version, des erreurs de compilation et, au final, une perte de temps précieuse. À la fin de la matinée, vous êtes épuisé, et votre code ne fonctionne toujours pas. Ce constat soulève une question pertinente : pourquoi la communauté Node.js n'a-t-elle pas réussi à produire un outil efficace pour gérer ces mises à jour de manière fluide et sans heurts ? La complexité de `node_modules` semble être une plaie ouverte, laissant les développeurs se débattre dans un océan de dépendances. Dans mon parcours avec Golang, j'apprécie la simplicité et la clarté des outils de gestion de dépendances. Une approche plus intuitive et moins sujette à des casse-têtes peut véritablement améliorer notre productivité. En tant que développeurs, nous devons nous concentrer sur la création de valeur et non sur des tâches de maintenance épuisantes. Je pense qu'il est temps pour la communauté de Node.js de réfléchir à des solutions plus élégantes pour la gestion des dépendances. Après tout, le développement devrait être un processus créatif et stimulant, et non une lutte contre des outils qui devraient nous faciliter la vie.

🏅🥈🥉 Top 5 des gestionnaires d'état en React "Si seulement j'avais un moyen de communiquer mes données d'un composant à un autre..." — Une phrase souvent entendue chez les développeurs front-end débutants. Ils se débattent avec props et callbacks pour synchroniser les états. La solution ? Les gestionnaires d'état. Ils stockent les données hors des composants, dans un état global. Ainsi, tous les composants peuvent y accéder ou les modifier, et ceux qui en dépendent se mettent à jour automatiquement. Un exemple ? Dans un site e-commerce, le composant "Produit" ajoute un article au panier. Grâce au gestionnaire d'état, le "Panier" (en haut à droite) se met à jour tout seul 🎯. Maintenant, un petit tour d’horizon des principaux state managers, du 5e au 1er. 🔥 5. Jotai Minimaliste et léger, il permet de créer des "atoms" partagés entre composants. 🚀 4. Recoil Créé par Facebook, il offre une gestion d'état fine avec des "atoms" comme unités de base. ⚡ 3. MobX Réactif, il met à jour les composants automatiquement avec des changements d'état. 🧠 2. Zustand Léger mais flexible, il s’intègre bien avec les hooks de React pour les projets de taille moyenne. 🏆 1. Redux Le champion incontournable, particulièrement puissant pour les projets massifs, surtout avec Redux Toolkit, qui simplifie son utilisation. 💡 En résumé : Chaque state manager a ses forces et faiblesses. Pour des projets légers, vous pouvez opter pour Zustand ou Jotai, tandis que Redux reste l'outil incontournable pour des applications massives. Le choix dépend toujours de la taille de l’application et des besoins spécifiques du projet ! Quel gestionnaire préférez-vous et pourquoi ? Partagez vos expériences dans les commentaires ! 💬 N'arrêtez jamais d'être curieux ! 🔎 Louis 🐺 👉 Retrouvez-moi sur Malt : https://lnkd.in/g5YWdGdX 👉 Mon boilerplate React avec Redux (en TypeScript) : https://lnkd.in/gJT8SVwv PS : Désolé pour l'alternance Français-Anglais 🙈

Le package.json ce n'est pas juste une liste de dépendances ❌ J'ai publié un court article sur le Mindsers Blog pour parler du fichier package.json J'y montre comment je l'utilise pour remplacer l'automatisme des tasks runners sur les petits projets sans complexités C'est un article plutôt à destination des juniors, mais si tu es sénior et que tu ne vois pas de quoi je parle, n'hésite pas à le lire ! (le lien est dans les commentaires) Dites-moi ensuite ce que vous en pensez en commentaires. J'ai hâte de découvrir vos contre-arguments 🫣 J'ai pas de "strong opinion" sur le sujet, mais j'aime bien l'idée de ne pas utiliser un bazooka pour tuer une mouche 😂 #dev #npm #nodejs

Eh oui, cela fait quelques jours que j'ai dû adopter un profil plus bas sur les réseaux, même si je n'étais pas aussi actif en réalité.🤏 En fait, étant en quête des atouts de la stack MEN, je me suis lancé le défi de réaliser des choses qui dépassent mes limites 😅🤭... je plaisante. Pour dire vrai, j'ai dû cerner tout ce qu'il fallait pour produire une bonne API sécurisée avec Express, Node.js et le nouveau bijou MongoDB (j'ai été épargné des migrations 😅😅). N'oublions pas non plus le package npm que j'utilisais. De ce fait, je me suis dit qu'il me fallait une API qui fait tout 😅, oui, qui fait tout. Vous allez vous demander : "Il raconte quoi ?" 😴... et oui, c'est ça. L'objectif est de réaliser des endpoints de tout genre que je peux réutiliser à tout moment dans n'importe quel projet, sans avoir à réfléchir à comment le faire. En d'autres termes, des bouts de code réutilisables que je vais faire évoluer en fonction des mises à jour des packages... Oui, je suis un gros gros paresseux 😅😅😴. De ce fait, chaque chose qui me préoccupait avant 🤔, c'est le moment de les régler. En tout cas, pour l'instant, j'ai fait pas mal de progrès là-dedans 🤭. Il y a des modules à implémenter, mais bon, je ne me presse pas trop car tout y sera 🚀. La bibliothèque magique, je vais l'appeler 🤭. La prochaine étape ? Vous verrez 😅. #Peace ❤️