4 cauchemars de dev : rm -rf, git perdu et autres horreurs - RÉPONDEUR SPÉCIAL HALLOWEEN

Matthieu Segret : Bonjour à toutes et à tous, je suis Matthieu et vous êtes bien sur le répondeur des Human Coders. Je suis content d'être avec vous dans cette nouvelle édition de ce podcast où l'on va parler techno, pratiques de dev ou de sujets plus généraux, mais toujours en lien avec l'informatique.

Le concept de ce podcast est assez simple : dans chaque épisode, je vous pose une question et vous pouvez me répondre par vocal. Aujourd'hui, on se retrouve pour un épisode un peu spécial parce que c'est Halloween. Quoi de mieux pour l'occasion que de parler de nos pires expériences de développeurs ?

Je me souviens, par exemple, d'un projet d'art génératif en WebGL sur lequel je travaillais avec Camille Roux. Il devait fonctionner sur mobile et, à quelques jours de la mise en ligne alors que tout fonctionnait très bien, on a fait un dernier test sur BrowserStack. Là, des pixels roses apparaissent un peu partout sur différents rendus, sur un tas de téléphones et notamment sur des modèles Samsung très utilisés.

On n'était vraiment pas loin du moment où on devait livrer le projet. Le debug était vraiment difficile et on avait moins d'un an d'expérience en WebGL. Le calcul se fait sur la carte graphique, donc on n'a pas de moyen d'avoir accès à une console ou de solutions simples pour inspecter le résultat du calcul de la couleur d'un pixel en particulier. On ne pouvait pas débugger en local et on n'avait pas accès aux LLM qui nous sauvent la vie aujourd'hui dans ce genre de cas. Avec Camille, on a passé un temps fou à comprendre d'où venait ce bug. Après avoir localisé le problème par dichotomie, impossible de comprendre ce qui produisait ce genre de résultat.

C'est finalement un développeur plus expérimenté sur Slack qui nous a mis sur la voie. En fait, cela venait d'un problème d'overflow dans certaines situations, qui était traité différemment selon les cartes graphiques des téléphones. Une vraie galère, pas fun du tout, sur laquelle on aurait aimé ne pas passer tout ce temps.

Alors pour cet épisode, je vous propose de partager les pires galères de développeur que vous avez eues : des bugs mystérieux qui surgissent sans prévenir, un piratage qui arrive au pire moment ou un projet maudit qui hante vos nuits. Dites-moi comment vous avez réussi à affronter ces moments difficiles et surtout, comment vous avez fini par en venir à bout. Est-ce que vous avez une anecdote terrifiante ou une expérience flippante à nous raconter ? Vous êtes bien sur le répondeur des Human Coders, laissez-nous un message après le bip.

Le consultant transformé en LLM

Eric Burel : Salut Matt, c'est Eric Burel, formateur Next.js et Astro chez Human Coders et aussi consultant indépendant à mes heures perdues. Je t'appelais parce que j'ai une histoire de consultant pour toi, une histoire à dormir debout, un peu étrange. L'histoire d'un consultant qui utilisait tellement de LLM qu'il a fini par se transformer en LLM.

Je t'explique la situation. Cette année, je travaille sur un dossier difficile : on doit faire une synthèse des travaux d'une entreprise sur l'année. Le délai est très court, le sujet est complexe, on a plein de documentation, le truc classique de consultant. On recrute un freelance en soutien pour nous épauler. Il dégrossit les dossiers, pose les bases du plan. Jusque-là, tout va bien.

Puis on lui demande d'ajouter des intros, des conclusions, des résumés, tout ce qui fait le liant d'un bon dossier dont on est fier. Et on s'est dit qu'il utilisait quand même beaucoup d'adverbes et d'adjectifs. On s'est dit : "Wouah, c'est un consultant qui a quand même beaucoup de vocabulaire et qui aime bien utiliser des adjectifs". Par exemple, quelqu'un qui va vous dire que React est une technologie qui facilite le développement d'applications web dynamiques et interactives. Jamais un adjectif tout seul.

Ensuite, on lui demande d'aller un peu plus loin, par exemple de faire une analyse des solutions existantes et de bien définir les termes. Pour ces définitions, il commençait à utiliser beaucoup de bullet points, toujours par trois. Par exemple, il nous disait que les avantages de React sont les composants réutilisables (point 1), le DOM virtuel (point 2) et le flux de données unidirectionnel (point 3). Toujours par trois. On s'est dit que c'était quelqu'un qui pensait de façon très structurée. Pourquoi pas, c'est clair et concis.

Puis on lui demande de rajouter quelques documentations écrites en anglais. En informatique, c'est évidemment inévitable. Et là, il s'est mis à traduire tous les mots en français, même des trucs que tu ne traduirais jamais de ta vie. Par exemple, c'était le genre de consultant qui disait "cadriciel" pour "framework". On a dû vérifier s'il n'était pas Québécois. On s'est dit que c'était quelqu'un qui aimait beaucoup la langue française, un vrai défenseur de l'Académie.

Mais avec tout ça, il a fallu qu'on réalise qu'il y avait un problème. Ce consultant ressemblait beaucoup à un LLM. On en est arrivés à la conclusion qu'il était peut-être en train de se transformer lui-même en LLM. Et je pense qu'on avait raison parce qu'on a fini par perdre complètement le contact. À la fin, il commençait toutes ses phrases par : "Je peux te fournir des informations et des conseils basés sur des connaissances variées, mais je ne remplace pas un consultant professionnel avec une expertise spécifique". Il est lui-même consultant, c'était quand même très bizarre. Il remâchait même en boucle les mêmes paragraphes en les reformulant de manière de moins en moins compréhensible pour en faire des tweets, par exemple. Bref, il partait complètement en hallucination.

Aujourd'hui, ce consultant ne travaille plus avec nous, mais on pense qu'il coule une vie heureuse quelque part dans un data center bourré de GPU à manger de la RAM virtuelle. Voilà, c'était l'histoire du consultant qui utilisait tellement de LLM qu'il a fini par se transformer en LLM. En espérant que tu ne le croises jamais au détour d'un dossier difficile.

Le frisson du rm -rf *

Jean-Philippe Baconnais : Hello, c'est Jean-Philippe Baconnais. Je suis chez Zenika Nantes en tant que consultant et je suis aussi co-organisateur des Human Talks à Nantes. Par rapport à ton message, oui, ça m'est déjà arrivé de faire des boulettes, que ce soit sur du code, sur des opérations en base de données ou tout simplement sur mon ordi. Je pense que je ne suis pas le seul.

J'ai plutôt une anecdote à vous raconter. Je pense que parmi celles et ceux qui nous écoutent, vous l'avez déjà fait : c'est autour du fameux rm -rf *, cette magnifique commande qui permet de faire des dégâts. Pour remettre un peu de contexte, j'étais dans une équipe où on avait des postes Windows depuis plusieurs années et on avait des contraintes d'installation de poste. Avec la conteneurisation, notamment, on a poussé pour avoir des ordis Linux pour avoir plus de liberté en termes d'installation et de configuration. On avait réussi à obtenir des ordis Linux, donc un vrai confort pour nous en tant que devs. La contrepartie, c'est qu'on était responsables de nos machines et de leur installation.

Après avoir installé Ubuntu, j'ai voulu installer pas mal d'outils. Pour moi, c'était quelque chose de nouveau. J'avais des Macs depuis pas mal d'années d'un point de vue perso, et ma dernière utilisation de Linux datait de mes études, donc ça remontait à quelques années. Mon ordi était quasi prêt, entièrement configuré, et j'ai voulu faire un peu de ménage parmi toutes les installations que je venais de faire.

Pour faire du ménage sous Linux, la commande rm permet de faire des choses sympas. Quand on met l'attribut -rf, cela permet d'aller récursivement et de forcer la suppression de choses. Puis derrière, on met le chemin. En pensant être dans un répertoire spécifique, j'ai fait un rm -rf *. Sauf qu'en fait, j'étais à la racine de mon ordi. Ça a commencé à tout supprimer et au fur et à mesure, sans que je m'en rende compte tout de suite, j'ai vu mon ordi qui se comportait un peu étrangement. Mon navigateur se fermait, des choses comme ça. Un comportement bizarre, mais au final ce n'était pas si bizarre : j'étais juste en train de supprimer tout ce que j'avais à la racine.

Voilà une petite boulette que j'ai arrêtée à temps, mais ça m'a permis de m'en souvenir. Ça remonte à plus de quatre ans et j'ai dû reconfigurer mon ordi. C'est une petite boulette que je voulais te partager. À plus tard, salut !

Hashtag Battle et les pics de charge

Camille Roux : Salut Mathieu. J'espère que tu vas bien. Je t'appelle pour te parler du thème extrêmement spooky du pic de charge non désiré. C'est une histoire qui remonte à 2011. Je suis co-organisateur du Startup Weekend de Nice Sophia Antipolis et le vendredi soir, on discute avec Franck Nouyrigat, l'un des trois créateurs de Startup Weekend. Il nous dit qu'il y a un autre Startup Weekend qui se passe à Lausanne. Il trouve ça assez sympa de faire des petites batailles comme ça sur les réseaux pour faire parler des deux événements.

Il nous propose de faire une bataille, de définir des hashtags qu'on poste sur Twitter. Twitter, à ce moment-là, c'est vraiment le réseau social pour ça. On essaye de voir celui qui va être le plus partagé sur les réseaux. À la fin de la discussion, je cherche un outil pour comparer le nombre de tweets et je n'en trouve pas. Je me souviens avoir vu dans ma veille techno des jours précédents une API qui s'appelait Topsy, qui a été rachetée par Apple depuis, et qui permet justement de faire ce compte. Je regarde si elle est payante : non, elle est gratuite.

Je décide de coder un proto le vendredi soir. Le samedi matin, je reviens avec un site où il y a zéro design, avec d'un côté le nombre de tweets depuis un jour sur le hashtag du Startup Weekend de Sophia Antipolis et la même chose pour Lausanne. Les gens s'amusent beaucoup avec ça. Pendant toute la journée, on me demande : "On ne pourrait pas mettre d'autres hashtags juste pour tester ? J'aimerais trop jouer avec ça".

Ce qui est incroyable à cette époque-là, c'est que l'API de Topsy est en libre accès, sans même besoin d'avoir une clé. L'API me donne le nombre de tweets postés avec la recherche que je lui donne, qui peut être complexe. J'ai le compte de tweets postés sur l'heure, le jour, la semaine, le mois et depuis la création de Twitter. Les stats sont live. Je peux taper sur l'API de manière live et il n'y a aucun problème.

Le site évolue. Je développe ce truc-là le samedi. Je sers une page statique qui, avec du JavaScript, va taper toutes les 10 ou 30 secondes sur l'API de Topsy pour chaque personne qui regarde. On a les stats live, c'est incroyable. Le samedi soir, je rencontre Damien Le Nouaille. Il me dit : "Ton site est super sympa mais il est moche". Pendant la nuit, il va m'aider à rendre le site plus agréable.

Le dimanche, on voit que les gens s'amusent beaucoup. Ça a l'effet escompté : les gens postent plus qu'ils ne l'auraient fait s'il n'y avait pas ce site. Assez rapidement, on a la presse qui s'en mêle. TechCrunch en parle, Presse-Citron, quelques blogs de l'époque. On passe même sur Gameblog. On ne leur a rien envoyé, il n'y a aucun communiqué de presse, c'est juste que le site est marrant.

Ça commence à être vachement utilisé dans les Startup Weekends à travers le monde. Presque toutes les semaines, on reçoit des photos de notre site sur grand écran dans différents lieux du monde. On comprend le concept : c'est utilisé pour des batailles de hashtags, donc c'est très événementiel. Assez vite, notre analytics devient vraiment aléatoire : il y a des jours où il ne se passe rien et puis d'un coup, on a des pics.

Je rappelle l'infra du site : elle est très basique, c'est un side project. C'est un site qui tourne sur Heroku, qui rend une page statique, et c'est le JS qui tape dans l'API. Et un beau jour, il y a une émission sur MTV aux US. Ils disent qu'ils lancent une hashtag battle. C'est le nom du site, on possède hashtagbattle.com. Mais ils ne pensent évidemment pas à nous. Pour eux, c'est juste une bataille de hashtags entre Justin Bieber, One Direction, Beyoncé, etc. Ils invitent les gens à voter.

Très vite, les gens vont taper "hashtag battle Justin Bieber" et ils vont tomber sur notre site parce qu'à ce moment-là, c'est quasiment le seul site pour faire des batailles de hashtags comme ça. On se retrouve à avoir des armées de fans de Justin Bieber et de One Direction qui vont mentionner notre site dans tous les sens. Ça prend une ampleur de fou. On se tape des pics de trafic avec des dizaines de milliers de visiteurs connectés en même temps. Il y a des milliers de tweets à l'heure postés sur ces différents hashtags. On commence à recevoir des alertes de Heroku comme quoi on dépasse le quota, alors qu'on ne fait que servir des pages statiques mises en cache.

On se tape des pics et des pics. Techniquement, ce n'est pas très intéressant parce qu'on ne fait que taper sur l'API de Topsy qui était incroyable. On va avoir ce site qui fonctionne avec très peu de ressources pendant très longtemps. Une autre fois, même chose, on reçoit des alertes de pics de trafic aberrants. En fait, la NHL a décidé de nous mettre en avant pour une finale entre deux équipes. Ils ont mis une iframe vers notre site, sans nous prévenir, sur les deux homepages des deux équipes qui sont en finale de la NHL. On est en plein match. Les stats étaient lunaires. Une iframe carrément !

Dans l'histoire de Hashtag Battle, on en aura plein des comme ça, jusqu'à ce qu'ils annoncent la fermeture de l'API de Topsy parce qu'elle a été rachetée par Apple. On a été très tristes de devoir fermer. On a essayé d'autres moyens de changer le business model, mais on n'a jamais trop trouvé. On s'est bien marrés, c'était une très belle histoire avec Damien. On a eu des pics de trafic gigantesques pour des trucs qu'on mettait du temps à comprendre parce que ce n'était pas notre culture ou pas dans notre pays. C'était mon histoire spooky pour Halloween. Excellente journée à toi.

Le cauchemar du Git Reset

Jérémy Dumaye : Salut Mathieu, tu vas bien ? C'est Jérémy Dumaye, formateur sur les technos Vue.js et Nuxt.js chez Human Coders. Je te laisse un petit message aujourd'hui qui, j'espère, te fera plaisir dans cette période d'Halloween. Une belle histoire terrifiante qui me fait déjà froid dans le dos rien qu'à y penser.

Tout commence sur le début d'un projet Vue.js, il y a un peu plus de cinq ans. Je prépare le socle d'une application web pour un client, je mets en place mes différentes routes API, web services divers, je commence à coder l'intégration et notamment la partie graphique. Une fois bien avancé, je me dis : "Est-ce que ça ne serait pas le moment pour commit tout ça sur le repo Git que m'avait donné mon client ?". Jusqu'ici, il était vierge. Je commite tout mon travail, je pushe. Bien entendu, je sais que je le fais un peu tardivement, mais j'ai avancé à fond, les délais étaient serrés. Je pushe donc mon premier commit, ça passe avec succès.

Je continue mon intégration, il me restait quelques pages à créer, des gabarits à réaliser, etc. Je finis ma tâche principale pour pouvoir ensuite tout présenter au client le lendemain. Et là, je décide de pusher la fin du travail d'une journée bien terminée sur le repo Git du client. Et là, j'ai une erreur. Bizarre, je n'arrive plus à pusher. J'ai une erreur de clé SSH avec un mail non reconnu. C'est passé avant, qu'est-ce qui se passe ?

J'étais à mes débuts dans l'univers Git en ligne de commande. Je connaissais les basiques mais là, je ne comprenais pas mon erreur. Je décide de rechercher un peu sur Internet. Je vois qu'il doit y avoir une erreur au niveau de la clé SSH et du mail associé. J'essaie de changer tout cela, je change le mail, je repointe vers un nouveau fichier de conf pour SSH. Je teste différentes solutions, ça ne marche pas. Je teste plein de lignes de commande que je trouve dans différents forums. Les heures passent, je commence un peu à m'énerver. J'entre des lignes de commande un peu diverses sans vraiment réfléchir.

Et là, le commit commence à déconner et je m'aperçois que je fais un reset fatal en entrant diverses commandes Git qui, malheureusement, me suppriment tout. En plus de ça, j'essaie de récupérer le code et je m'aperçois qu'en fait je suis "iso" avec le repo Git et que moi-même j'ai tout perdu en local. Grosse goutte de sueur. Le stress est à son maximum, je suis en plein dans un film d'horreur. Qu'est-ce que j'ai fait ? Je n'ai pas été bon parce qu'en plus je n'ai pas commité dès le début et aux différentes étapes.

Je sais que je vais devoir tout refaire. J'ai perdu plein de jours de taf. Le lendemain, j'ai mon client qui attend la démo avec diverses personnes. Qu'est-ce que je vais présenter ? Je suis très mal. Je me dis : "Allez, on ne se démoralise pas". Je me fais une raison, je checke un peu l'historique de VS Code. J'arrive à récupérer certaines choses même si j'ai perdu pas mal de choses. Je commence à récupérer le code comme je peux. Je récupère un ou deux fichiers, je me dis que ça va être super long. On est à la fin de la journée, je n'ai pas envie de faire une nuit blanche.

Je décide de contacter une connaissance qui a un peu plus d'expérience là-dessus. C'est toujours bon de bien s'entourer, c'est un conseil que je donne maintenant à pas mal de personnes, notamment dans mes formations. Je me dis que cette personne va peut-être m'aider. Et là, elle me dit : "Bah non, tu as fait un reset, ça a été fatal". Je m'acharne, je me dis que c'est bizarre, je suis sûr que c'était passé, il doit bien rester une trace. Il me dit : "Bah vu que tu as reset, tu as tout supprimé, il n'y a plus de trace". Il regarde quand même avec moi le repo et là, par chance, on retrouve par je ne sais quel moyen encore aujourd'hui une trace de ce commit perdu qui comportait tout le code. Alléluia ! Le code est là, on récupère le H (le hash). J'arrive à récupérer ce commit, je le reprends en local, je checke un peu, ça fonctionne, j'ai bien les dernières versions.

Cette fois-ci, de mon côté, j'avais le bon mail associé à la clé SSH. Je refais un commit, je pushe, ça passe et le code est sur le repo Git. Ouf, happy end ! Le boss de fin de ce film d'horreur n'a pas gagné. Je suis ultra soulagé. Je vais pouvoir présenter le lendemain l'application web. Je ne vais pas faire de nuit blanche. Je vais même avoir ma soirée de libre. Je me sors les pop-corn et je me fais un petit Carpenter pour rester dans le thème.

Le lendemain, la présentation s'est super bien passée, le client était content. Moralité de cette histoire : toujours committer dès le départ et surtout à intervalle régulier. Peu importe si on veut que ce soit clean ou pas, ou si on n'a pas assez avancé. Je le dis à tous mes élèves maintenant : on commite à intervalle régulier, début de journée, fin de journée, milieu de journée s'il y a eu des choses importantes. Et surtout, ne pas faire confiance à toutes les lignes de commande qu'on voit sur les forums. Quand on voit une commande qui a l'air bien, il faut regarder toutes les subtilités et la dangerosité de la chose. La vérifier sur d'autres forums. Si on n'a personne à qui en parler, on la teste en faisant une sauvegarde à côté de son côté.

Cette erreur remonte à plus de cinq ans mais je m'en souviens encore comme si c'était hier. J'ai déjà les gouttes au front rien qu'en y repensant. Mais bon, j'ai été bien vacciné de tout ça, ça ne m'est plus jamais arrivé. Allez, je te laisse, j'espère que tu auras aimé ma petite histoire. Joyeux Halloween, une belle journée et je te dis à bientôt. Ciao Matthieu !

Matthieu Segret : Merci encore pour vos messages. J'espère que vous avez eu autant de plaisir que moi à les écouter. Si vous avez aimé ce podcast, n'hésitez pas à liker ou à nous suivre sur Spotify ou Apple Podcasts. Nous construisons ce podcast avec vous, donc n'hésitez pas à nous proposer des idées pour les prochains sujets ou encore à participer aux prochains épisodes sur humancoders.com/podcast. D'ici là, prenez soin de vous et je vous dis à bientôt dans un prochain épisode !