Une fuite de mémoire mystérieuse ralentissait notre application depuis des mois. Personne n'osait s'y attaquer. J'ai décidé de relever le défi. Vous connaissez ce sentiment ? Quand vous savez qu'un problème existe, mais personne ne prend le temps de le résoudre ? Armé de détermination et d'un bon café, j'ai plongé dans le code. Premier réflexe : ouvrir les DevTools et faire un Heap snapshot. Ce que j'ai découvert m'a surpris : Des d'objets mystérieux avec seulement deux propriétés, _𝗻𝘀_𝗻𝗮𝗺𝗲 et 𝗶𝗱. Mais surtout, chacun avait comme prototype un objet similaire qui lui même avait un prototype similaire qui lui même .... Bref tu vois le bye. La chaîne de prototypes était si longue que je n'arrivé pas à l'afficher entièrement dans le DevTools 🤯 Après plusieurs heures d'investigation acharnée, j'ai finalement identifié le coupable : la bibliothèque 𝗰𝗹𝘀-𝗵𝗼𝗼𝗸𝗲𝗱. Le problème se cachait dans sa fonction 𝗰𝗿𝗲𝗮𝘁𝗲𝗖𝗼𝗻𝘁𝗲𝘅𝘁 : 𝗹𝗲𝘁 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 = 𝗢𝗯𝗷𝗲𝗰𝘁.𝗰𝗿𝗲𝗮𝘁𝗲(𝘁𝗵𝗶𝘀.𝗮𝗰𝘁𝗶𝘃𝗲 ? 𝘁𝗵𝗶𝘀.𝗮𝗰𝘁𝗶𝘃𝗲 : 𝗢𝗯𝗷𝗲𝗰𝘁.𝗽𝗿𝗼𝘁𝗼𝘁𝘆𝗽𝗲); L'erreur ? À chaque nouvel appel, 𝘁𝗵𝗶𝘀.𝗮𝗰𝘁𝗶𝘃𝗲 n'était pas correctement nettoyé, créant ainsi un context qui pointait vers l'ancien. Une fuite de mémoire classique mais sournoise, qui accumulait des références sans jamais les libérer. Je décide de remplacer cette bibliothèque externe par l'API native de Node.js 𝗻𝗼𝗱𝗲:𝗮𝘀𝘆𝗻𝗰_𝗵𝗼𝗼𝗸𝘀. Résultat immédiat : fuite de mémoire éliminée, application plus rapide et plus stable. 💡 Question pour vous: quelle a été votre expérience de debugging la plus mémorable ?  Partagez vos histoires en commentaire ! P.S: Toi aussi tu aimes trier les biper? 😅

Je ne publie pas beaucoup sur LinkedIn. Parce que je préfère coder que poster. Mais aujourd’hui, je prends la parole pour une bonne raison : 👉 On vient de lancer une nouvelle fonctionnalité sur 𝗹𝗶𝗻𝗸𝘁𝗶𝗺𝗲. Le problème de LinkedIn, vous le connaissez : tu passes du temps à écrire… et 48h après, ton contenu disparaît. Avec Vianney, on voulait régler ça. Alors on a créé 𝘂𝗻 𝘀𝘆𝘀𝘁𝗲̀𝗺𝗲 𝗾𝘂𝗶 𝘁𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗲 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗾𝘂𝗲𝗺𝗲𝗻𝘁 𝘁𝗲𝘀 𝗽𝗼𝘀𝘁𝘀 𝗲𝗻 𝗺𝗶𝗻𝗶‑𝘀𝗶𝘁𝗲 𝗦𝗘𝗢. Résultat : Tes posts deviennent un 𝗽𝗼𝗿𝘁𝗳𝗼𝗹𝗶𝗼 𝘃𝗶𝘃𝗮𝗻𝘁 → ça montre ton expertise Ton contenu est 𝗶𝗻𝗱𝗲𝘅𝗲́ 𝘀𝘂𝗿 𝗚𝗼𝗼𝗴𝗹𝗲 → du trafic organique 🟢 Une newsletter intégrée → ton audience peut s’abonner et recevoir tes posts. Ton contenu ne meurt plus au bout de 48h. Il continue à travailler pour toi, pendant que toi tu codes, buildes, ou fais autre chose. 👉 Je vous mets un exemple en commentaires. ____________ 👋 𝘏𝘦𝘭𝘭𝘰, 𝘮𝘰𝘪 𝘤’𝘦𝘴𝘵 𝘍𝘳𝘢𝘯𝘤̧𝘰𝘪𝘴 — 𝘦𝘹 𝘤𝘰‑𝘧𝘰𝘶𝘯𝘥𝘦𝘳 𝘥𝘦 𝘓𝘦𝘮𝘭𝘪𝘴𝘵 (0 → $10𝘔 𝘈𝘙𝘙 𝘦𝘯 𝘣𝘰𝘰𝘵𝘴𝘵𝘳𝘢𝘱) 𝘦𝘵 𝘢𝘶𝘫𝘰𝘶𝘳𝘥’𝘩𝘶𝘪 𝘥𝘦 𝘭𝘪𝘯𝘬𝘵𝘪𝘮𝘦. 𝘑𝘦 𝘴𝘶𝘪𝘴 𝘱𝘢𝘴𝘴𝘪𝘰𝘯𝘯𝘦́ 𝘥𝘦 𝘵𝘦𝘤𝘩, 𝘫𝘦 𝘣𝘶𝘪𝘭𝘥 𝘥𝘦𝘴 𝘚𝘢𝘢𝘚, 𝘦𝘵 𝘫𝘦 𝘱𝘢𝘳𝘵𝘢𝘨𝘦 𝘪𝘤𝘪 𝘮𝘦𝘴 𝘢𝘱𝘱𝘳𝘦𝘯𝘵𝘪𝘴𝘴𝘢𝘨𝘦𝘴 𝘤𝘰̂𝘵𝘦́ 𝘱𝘳𝘰𝘥𝘶𝘪𝘵 & 𝘤𝘳𝘦́𝘢𝘵𝘪𝘰𝘯 𝘥𝘦 𝘣𝘰𝘪̂𝘵𝘦𝘴.

Après plus de 3 mois de développement, linktime est enfin prêt. Nous le lançons sur producthunt 🚀 Envoyer nous un peut de force 💪

Est-ce que vous vous êtes déjà demandé s'il y avait une solution facile pour faire des Pool de Promise afin de limiter le nombre d'exécution asynchrone? Je ne sais pas vous mais il m'arrive parfois de devoir faire beaucoup de fetch asynchrone. Par exemple lorsque je fetch une API qui me retourne une liste de resources et que j'ai besoin de récupérer chacun de ces ressources. Dans ce cas les solutions simple sont de faire les fetch les uns après les autres. Ça fonctionne mais ça peut être lent. L'autre solution c'est de faire tout les fetch en parallèle. Si il n'y en a pas trop pas de soucis mais si tu as beaucoup de resources à récupérer tu risques d'attendre la limit de fetch que l'API t'autorise. La solution optimale serait de faire le fetch en parallèle mais qu'un nombre restreint de fetch à la fois. Bien sûr tu as des libs pour faire ça comme par exemple es6-promise-pool, mais en cherchant je suis tombé sur une solutions simple qui te permet de te faire ton propre PromisePool. L'idée c'est qu'un iterator peut être consumé par plusieurs boucle. Voici les étapes a suivre: 1. Créé un iterator. Si tu as un tableau d'url il te suffit d'appeler la method 𝘷𝘢𝘭𝘶𝘦𝘴. 𝚌𝚘𝚗𝚜𝚝 𝚞𝚛𝚕𝙸𝚝𝚎𝚛𝚊𝚝𝚘𝚛 = 𝚞𝚛𝚕𝚜.𝚟𝚊𝚕𝚞𝚎𝚜(); 2. Puis tu créer un tableau de la taille du nombre de fetch que tu veux en parallèle et tu le remplis avec ton iterator. 𝚌𝚘𝚗𝚜𝚝 𝚙𝚘𝚘𝚕𝚜 = 𝙰𝚛𝚛𝚊𝚢(2).𝚏𝚒𝚕𝚕(𝚞𝚛𝚕𝙸𝚝𝚎𝚛𝚊𝚝𝚘𝚛); 3. Pour convertir ton tableau d'iterator en tableau de promise qui consume ton iterator 𝚌𝚘𝚗𝚜𝚝 𝚠𝚘𝚛𝚔𝚎𝚛𝚜 = 𝚙𝚘𝚘𝚕𝚜.𝚖𝚊𝚙(𝚊𝚜𝚢𝚗𝚌 𝚏𝚞𝚗𝚌𝚝𝚒𝚘𝚗 (𝚞𝚛𝚕𝙸𝚝𝚎𝚛𝚊𝚝𝚘𝚛) { 𝚌𝚘𝚗𝚜𝚝 𝚛𝚎𝚜𝚞𝚕𝚝𝚜 = [ ]; 𝚏𝚘𝚛 (𝚌𝚘𝚗𝚜𝚝 𝚞𝚛𝚕 𝚘𝚏 𝚞𝚛𝚕𝙸𝚝𝚎𝚛𝚊𝚝𝚘𝚛) { 𝚛𝚎𝚜𝚞𝚕𝚝𝚜.𝚙𝚞𝚜𝚑(𝚊𝚠𝚊𝚒𝚝 𝚏𝚎𝚝𝚌𝚑(𝚞𝚛𝚕)); } 𝚛𝚎𝚝𝚞𝚛𝚗 𝚛𝚎𝚜𝚞𝚕𝚝𝚜; }); 4. Enfin tu as plus qu'a attendre que les pools se résolve. 𝙿𝚛𝚘𝚖𝚒𝚜𝚎.𝚊𝚕𝚕𝚂𝚎𝚝𝚝𝚕𝚎𝚍(𝚠𝚘𝚛𝚔𝚎𝚛𝚜).𝚝𝚑𝚎𝚗(𝚌𝚘𝚗𝚜𝚘𝚕𝚎.𝚕𝚘𝚐.𝚋𝚒𝚗𝚍(𝚗𝚞𝚕𝚕, '𝚍𝚘𝚗𝚎')) Voila. J'espère que ça t'a été utile et que tu as appris quelque chose. Je mets en commentaire le lien vers la solution stackoverflow qui j'espère t'apportera un complément d'information.

Faut-il vraiment publier tous les jours pour exister sur LinkedIn ? 🤔 On entend souvent qu'il faut absolument créer du contenu, faire du "𝗽𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗯𝗿𝗮𝗻𝗱𝗶𝗻𝗴" et poster sans arrêt pour saisir des opportunités. Je viens de lire cet article du Journal du Net et je suis en 𝘁𝗼𝘁𝗮𝗹 𝗮𝗰𝗰𝗼𝗿𝗱 avec leur analyse. Il est tout à fait possible de développer son réseau et de trouver des opportunités sans jamais écrire un seul post. La clé ? L'optimisation du profil, la pertinence des commentaires et la qualité des échanges en message privé. Cela fait du bien de lire une perspective qui valorise la qualité de la relation plutôt que la course aux likes ! 👇 Et vous, vous êtes plutôt "créateur de contenu" ou "force tranquille" ? https://lnkd.in/ePhf6f36