Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Xavier Nobre, Xavier bonjour.
Bonjour Benoît.
Pendant qu'on préparait cet épisode, tu me parlais de ta découverte de Rust.
Et d'abord c'est cool parce que j'en avais peut-être entendu parler mais ça m'avait pas imprégné.
Mais surtout ce que j'ai trouvé intéressant c'est que tu vois moi je pars un peu en lutte
contre tous ces recruteurs, ces RH qui cherchent absolument un développeur
qui ait une connaissance précise et si possible l'experte de leur stack.
Avec cette a priori qu'un vieux développeur, et je pense qu'on peut dire que tous les deux on est des vieux développeurs.
Je sais pas à partir de combien d'années mais je pense qu'à partir de 10-15 ans d'EVE,
comment ça être des vieux développeurs.
Ouais, vous voulez de choses sur la tête mais...
En fait finalement à un moment donné, le langage et le framework n'ont plus vraiment beaucoup d'importance.
On a acquis tellement d'expertises, de recul, de manière de penser qu'on est capable finalement d'aborder et d'absorber
n'importe quel langage et framework tenter qu'il nous inspire un petit peu.
Et du coup je suis curieux de comment est-ce que tu es entré dans Rust.
Tu avais ce challenge, tu me racontais, est-ce que tu peux nous expliquer un petit peu le contexte
dans lequel tu t'es plongé là-dedans parce que c'était assez...
C'était un peu court comme timing quoi, donc c'était...
Trouvais vachement intéressant.
Oui, alors donc le contexte, je suis dans une start-up où on veut développer un produit,
différents produits en interagissant avec une blockchain.
Et cette blockchain est accessible, on peut l'utiliser avec un SDK.
Un SDK qui a dans sa partie hôte plusieurs wrappers dans différents langages.
Java, Node, Python, Rust.
Et en dessous, toute une stack, enfin deux, trois couches, tout écrit en Rust.
Donc moi je suis arrivé l'été dernier, donc il y a huit mois dans cette start-up
et ce qui a été cool pour moi, c'était de voir qu'il y avait du Node.
C'était le langage finalement où j'étais plus à l'aise
et où je sais que je pouvais développer rapidement des choses.
Donc du coup j'ai attaqué très vite à faire du Node,
mais en sachant qu'en dessous il y avait du Rust.
Donc dans tout ça, il y a de la blockchain, il y a de la crypto
et puis en creusant dans nos besoins, récemment émergé un besoin lié à de la crypto.
Donc moi je n'y connais pas grand chose, mais je suis allé donc,
j'ai été une première fois confronté à devoir aller chercher dans le code Rust
et essayer de comprendre comment était ancrité des données qui nous intéressaient.
Donc j'ai commencé à avoir du code Rust.
Donc au début ça fait un peu bizarre.
Ça fait un peu comme du C, mais avec des trucs en plus,
des haies ou des symboles un peu bizarres de partout.
Donc j'avais un peu Rust qui est arrivé comme ça dans mon champ de vision.
Je suis allé à Snocamp où il y a un gars qui a proposé un atelier sympa,
il y avait du Rust.
Donc il y avait plusieurs langages possibles dont Rust.
Et je me suis dit avec mon bidon, c'est cool, on fait du Rust.
Et à ce moment là le gars nous dit,
si vous êtes courageux, le plus dur c'est Rust.
Donc on a un peu laissé tomber.
Mais voilà Rust qui revenait un peu.
Et puis mon collègue, une fois entre midi et 2, je lui dis,
écoute, si ça dit, moi j'ai envie de voir un peu ce que c'est.
Entre midi et 2, j'ai trouvé un petit readme, Springt0 sur Rust.
On commence à regarder.
Donc on a commencé à lire ça, à jouer dans un playbook,
à faire un peu du Rust et au bout d'une demi-heure ça a commencé un peu à piquer.
On a un peu décroché, c'était pas si facile.
Donc voilà, j'en étais là.
Et puis la semaine dernière, est revenue sur le tapis,
une fonctionnalité qu'on aimerait qu'il n'y a pas dans le SDK qu'on utilise.
Et donc notre product honneur qui nous dit,
c'est vraiment cool et tout ça.
Et qui me met un peu le challenge de,
est-ce qu'on peut pas réussir à faire quelque chose.
Moi je dis, je vais essayer.
Donc lundi dernier, c'est tout récent.
Lundi matin, je me suis attaqué à ça.
Et je me suis dit, ok, comment je m'y prends ?
Il y a un gros bazar là, etc.
J'avais vu qu'il y avait des tests.
Donc je me suis dit, bah c'est cool, il y a l'air d'avoir des tests et je vais jouer ces tests.
Donc du coup, j'ai lancé le runeur de test,
qui a l'air assez bien intégré dans Rust.
Alors bon, un peu me reste surpris,
c'est que ça m'a quand même beaucoup de temps à compiler.
J'ai discuté hier avec des gens qui connaissaient un peu,
qui m'ont dit qu'effectivement c'est un peu le problème actuellement,
c'est le temps de compilation.
Et je joue tous mes tests et 24 tests en échec.
Je me dis, bah c'est pas cool, j'ai en récupéré un dépôt,
il y a des tests en échec.
Bon, je relance une deuxième fois 36 tests en échec.
Donc là, je me dis, il y a un problème.
Et j'ai mis 2 heures à trouver qu'il fallait rajouter une option pour lui dire MonoSred,
pour pas qu'il lance les tests en parallèle.
Par défaut, c'est génial, par défaut, il lance les tests en parallèle.
Sauf que le projet Open Source qu'on utilise et sur lequel je voulais contribuer,
a Pléthor de test, il y en a beaucoup, j'aime plus combien,
mais sauf que malheureusement, première mode de cette pratique,
ces tests sont dépendants les uns des autres.
Donc tu ne peux pas les lancer en parallèle.
Bon, la solution c'est les lancer avec cette option,
alors par contre ça prend beaucoup plus de temps.
Donc pendant ce temps là, c'est bien, le temps que ça tourne,
j'ai eu le temps de chercher,
il y a des syntaxes qui permettent de cibler soit un module,
pour pas lancer tous les tests, voire même un test en particulier.
Je me suis dit ça, ça va me servir quand je vais écrire moi mon premier test.
Et là, mauvaise surprise, il restait un test qui ne passait pas.
Alors j'ai cherché, j'ai posé question sur le forum,
heureusement, il y a un gars qui m'a répondu,
qui m'a dit, ah, mais il faut que tu aies une blockchain qui tourne à côté.
Et là, deuxième mauvaise pratique, test unitaire,
qui nécessite d'avoir un système extérieur qui tourne.
Et en plus, un système extérieur,
ça a une blockchain à côté,
qui tourne avec des adresses IP particulières, etc.
Donc ça, j'ai trouvé ça pas cool,
et c'est là que tu te dis, bon, c'est bien d'avoir des tests unitaires sur un système.
C'est bien aussi de respecter des bonnes pratiques,
d'indépendance des tests, les imparables pour eux autres,
et puis d'avoir des tests indépendants de l'extérieur,
ou alors de l'outillage qui te permet de faire ça.
Mais une fois que tu as passé la galère de les faire passer ces tests,
est-ce que du coup ça a fait sa fonction de documentation
et ça t'a permis de rentrer plus vite dans le SDK que tu étais en train de t'approprier ?
Alors là, effectivement, ça me suis dit, ok, ça a fini par marcher,
je dis bon, c'est cool, je vais pouvoir regarder les tests.
Donc j'ai assez vite trouvé des tests qui avaient l'air assez haut niveau comme je voulais,
c'est-à-dire en gros, je prends un message, je l'encripe, je le décrypte,
et je vérifie que j'ai mon message d'origine.
Et nous, c'est un peu là-dessus qu'on voulait travailler.
Donc je me dis c'est cool, je regarde ces tests, ils sont l'air bien,
et je cherche dans la librairie où était ces tests,
où était la méthode appelée.
Et bon, les surprises, je la trouve pas.
Et en fait, la méthode, elle était dans le wrapeur Rust,
c'est-à-dire qu'en dehors de la librairie,
il y a tous les wrapeurs dont j'ai parlé tout à l'heure,
dont le wrapeur Rust.
En fait, les tests qui sont dans la librairie
utilisent des méthodes du wrapeur qui lui s'appuient sur la librairie.
Bon, donc troisième mauvaise pratique que je n'ai pas trouvé super cool.
Mais bon, effectivement, j'ai réussi à faire, à passer tout ça.
Donc c'est quand même, je voulais quand même partager ça avec toi
sur le fait que des fois, on instiste sur des bonnes pratiques.
De faire des tests unitaires c'est bien, mais de les faire bien,
en respectant certaines bonnes pratiques, c'est quand même mieux.
Ce que je trouve fort dans ce que tu dis,
c'est que finalement, en ayant eu ces galères-là,
tu as quand même réussi en l'espace de 24 heures
à mettre en place ce que tu voulais,
c'est-à-dire que tu aurais pu aller encore plus vite,
en fait, si les tests t'avaient pas eu toutes ces galères.
Oui, j'aurais pu aller plus vite,
et puis c'était un peu une déconvenue pour moi
qui suis fan des tests unitaires de me dire c'est génial.
Un projet open source, il y a des tests et tout, c'est cool.
Et puis tu vas de galère en galère,
parce qu'il y a juste des mauvaises pratiques,
des bonnes pratiques qui n'ont pas été respectées.
Donc moi je voulais partager ça avec toi et avec nos auditeurs.
C'est vrai que c'est des choses qui, si elles sont prises dès le début,
avec l'idée, en fait, et ce projet,
puis par en tête, j'y ai contribué,
j'y avais déjà contribué à cet projet-là
sans rentrer dans la partie REST,
mais sur des scripts d'exemples, etc.
et j'avais notamment contribué à doccuriser certaines parties,
toujours avec cette idée de quelqu'un de nouveau qui arrive
et c'est valable quand tu as un projet en interne
de toujours prendre ce, moi j'aime bien me dire,
le jour où il y a un nouveau développeur qui va arriver
de faire en sorte que ce soit le plus simple pour lui d'arriver,
de monter en compétence sur le projet,
et notamment de vite pouvoir démarrer l'application
sans avoir à installer 36 choses sur sa machine,
et là, doccur peut aider beaucoup,
et d'avoir des tests unitaires qui vont être sources de documentation,
comme tu disais, source de documentation, d'exemples,
mais des tests unitaires qui marchent du premier coup
et qui soient rapides à exécuter, qui soient indépendants de l'extérieur.
C'est dommage parce que ces tests n'étant pas indépendants les uns des autres,
on ne peut pas les lancer en parallèle, du coup c'est très long.
Et quand je te dis c'est très long, je ne sais plus,
je n'ai pas mesuré, mais je suis allé prendre un café
et discuter avec un collègue, je suis revenu,
les tests n'étaient pas encore finis.
C'est vraiment long, donc je trouve que vraiment c'est important
de se dire que dès le début, c'est un investissement,
c'est un investissement mais un investissement qui est rentable
pour le projet, pour les nouveaux qui vont venir sur le projet
ou quand on va revenir sur ce projet-là.
Et encore plus quand c'est de l'open source,
où là tu ne sais vraiment pas qui va venir interagir
et en général tu veux que les gens viennent sur ton projet.
Et s'il est compliqué à appréhender et c'est compliqué de rentrer dedans,
ça ne va pas favoriser l'adoption.
Écoute Xavier, je te remercie pour tout ça, je te propose que ce soit le mot de la fin.
Si les gens veulent en savoir un petit peu plus sur ce que tu fais,
le travail que tu fais et est-ce que tu publie peuvent venir où ?
Le mieux c'est de taper mon nom sur un moteur de recherche
et puis on peut trouver plein de ressources me concernant,
mon blog, mon Twitter, etc.
Je te remercie d'être venu aujourd'hui.
Merci à toi Benoît.
Quant à toi cher auditeur, je t'invite à nous rejoindre
sur artisan-developer.fr et je te dis à demain.