Transcription

• Sylvain

  Bonjour à toutes et à tous et bienvenue dans ce nouvel épisode du podcast Punkin'Dev. Aujourd'hui, je reçois un nouvel invité qui n'est jamais passé sur le podcast. J'ai le plaisir de recevoir Lionel. Bonjour Lionel, comment tu vas ?

• Lionel

  Salut, ça va bien. Merci pour l'invite. C'est mon premier podcast.

• Sylvain

  Le plaisir est pour moi. Avant de rentrer dans le vif des sujets qu'on a envie d'aborder aujourd'hui, est-ce que tu voudrais bien te présenter, qui tu es, d'où tu viens, qu'est-ce que tu fais au quotidien ?

• Lionel

  Ouais donc je suis Lionel Armanet, je travaille sur Grenoble, je travaille dans une boîte qui s'appelle Salesforce. Je suis ingé développeur, crafteur, toute la journée. Je fais ce boulot depuis une petite vingtaine d'années je pense à peu près. Effectivement le craft ça a toujours été des sujets un peu de prédilection, un truc que j'ai bien aimé aborder. Et que j'ai abordé justement récemment, je pense que c'est de ça qu'on va parler aujourd'hui.

• Sylvain

  Ouais, on va parler de ça. Donc récemment, tu as participé au tremplin pour les néo-speakers de Snowcamp, Grenoble, qui est adossé à Craft Records. Et tu as présenté un sujet... Tu peux pas remettre le titre, j'ai peur de dire une bêtise. Tu peux nous représenter ce sujet-là. Un sujet que j'ai beaucoup apprécié, qui me parlait bien, moi, en tout cas.

• Lionel

  Ouais, le sujet, c'était Smalltalk. Voyage futuriste vers le passé. En deux mots, le pitch c'était de montrer un petit peu ce que les concepteurs du langage, plus que le langage d'ailleurs, Smalltalk, avaient pensé dans les années 70 et ô combien ça a influencé l'informatique moderne au niveau des OS, mais aussi au niveau de nos pratiques, et qu'en fait il y a beaucoup de choses qu'on trouve dans le craft qui puisent leurs racines dans ce qui a été inventé à l'époque. C'était assez marrant de faire ce parallèle, je trouve, dans un talk.

• Sylvain

  Donc si on reprend l'histoire, je trouve ça toujours marrant de remonter aussi loin. Donc pour les personnes qui ne connaissent pas, parce que ce n'est pas un truc moderne connu, tu dis Smalltalk, ça date des années 70. Tu peux en parler un peu de ce que c'est, d'où ça sort et ce que ça a amené ?

• Lionel

  Ouais donc en fait les années 70, alors j'étais pas né à l'époque, mais de ce que j'en ai compris, en fait fin des années 60 on est encore beaucoup dans les mainframes, donc c'est des grandes pièces avec plein d'appareils compliqués et des cartes perforées et ce genre de trucs. Il n'y a pas vraiment de notion d'interface homme-machine mais il y a pas mal de travaux de recherche sur le sujet. Donc il y a la souris qui a dû être inventée en 68 peut-être, quelque chose comme ça, mais on cherche encore son application. Et en fait, dans les années 70, il y a Xerox qui fonde le PARC. C'est le Palo Alto Research Center, en Californie, qui décide de travailler sur l'ordinateur moderne. Et en fait, ils créent une machine qui n'est pas un mainframe, où on n'a pas besoin d'une grande pièce de 100 mètres carrés, qui invente une machine qui tient sur un bureau, comme on a aujourd'hui, qui a un écran, une souris, un bureau virtuel sur lequel on a des fenêtres. sur laquelle il y a des fenêtres. C'est un environnement avec lequel on peut interagir, où on peut créer des formes, les manipuler, imprimer sur les imprimantes laser, qu'ils inventent aussi avec cette machine Alto. Ces machines sont en réseau, elles dialoguent sur Ethernet, qui est aussi inventé par Xerox. Ces mecs-là, ils inventent à peu près tout ce qu'on connaît aujourd'hui, en termes d'OS. Et en fait, ce système d'exploitation, il n'était pas driveé par des fichiers de conf. C'est-à-dire que tu n'allais pas modifier un fichier texte pour changer la police de caractère, par exemple. En fait, c'était customisé par du code. Et ce code, en fait, a été écrit dans le langage Smalltalk, qui est le premier langage de programmation orienté objet. Et en fait, l'idée, c'est que même les concepts de l'OS, une fenêtre, en fait, pouvait récupérer son instance et puis appeler des méthodes pour... changer finalement l'aspect d'une fenêtre ou ce genre de choses. Et donc tout l'OS était codé en Smalltalk et du coup on pouvait customiser l'intégralité de l'OS en Smalltalk et donc faire tourner son code Smalltalk comme faisant partie de l'OS. Et pour faire ça, ce qu'ils ont fait, c'est qu'ils ont inventé le concept de machine virtuelle en même temps, c'est-à-dire que tout le code fonctionnait dans une machine virtuelle qu'on démarrait finalement sur la machine. Donc c'est un peu tout ça qui est arrivé, ce que je dis, ça a été vraiment matérialisé en 1974, et ça, ça a couru la machine Alto et Smalltalk jusqu'à les années 80. Et puis après, c'est une autre partie de l'histoire, où c'est Steve Jobs qui se paye... une visite privée du labo de Palo Alto, du PARC. Donc ça, ça devait être début 80. Et il dit, mais c'est génial ce que vous avez fait. Vous avez vraiment inventé le futur, mais vous ne savez pas quoi en faire. Sachant qu'en plus, a priori, ce que j'ai compris, c'est qu'à l'époque, les mecs de Xerox, ils ont dû lui montrer 20% de ce qu'ils savaient faire. Mais Steve Jobs, lui, qui a quand même ce côté un peu marketing, en fait, il... il décide de lui-même commercialiser ces idées-là. Donc il fabrique, je crois que c'était la machine Lisa, qui est un échec commercial, mais qui est pareil, un écran, un clavier, une souris, un bureau virtuel avec des fenêtres, etc. Puis après, il crée le Macintosh, et puis on connaît un peu l'histoire qui s'ensuit. Ce qui est assez marrant, c'est que j'ai retrouvé une conversation de... Ce qui est marrant, c'est que j'ai retrouvé une conversation de Bill Gates qui dit à Steve Jobs C'est marrant parce que j'avais un peu l'impression de t'avoir tout piqué. Puis quand je suis venu pour te piquer tes idées, je me suis rendu compte que toi-même, tu les avais piquées chez les copains de Xerox. Ça devait être assez dingue. Ça s'est passé peut-être à 30 kilomètres à la ronde sur une dizaine d'années. C'est ça le contexte de Smalltalk.

• Sylvain

  C'est un peu savoureux le côté Je t'ai tout piqué, mais en fait, toi, tu avais déjà tout piqué. J'ai l'impression que c'est la... L'histoire se recommence, on a la même en ce moment avec OpenAI qui commence à râler que les chinois leur piquent des trucs, sachant qu'eux ils ont déjà piqué des trucs. Tout passe par du vol de propriétés, de concepts, de tout ce que tu veux, l'impression que c'est inévitable.

• Lionel

  Je sais pas, il y a un truc que j'ai pas dit je pense, c'est que les concepteurs de Smalltalk, je sais pas combien ils étaient mais ils étaient plusieurs, leur idée en fait c'est vraiment de créer un système ouvert. Un système aussi qui était accessible pour les enfants. Donc tous les gens qui ont continué à faire du Smalltalk, notamment Alan Kay, qui est un des créateurs de Smalltalk, il a fabriqué une distribution open source qui s'appelle Squeak, sur laquelle on peut faire programmer les enfants. Donc ils vont manipuler des concepts à l'écran, un peu comme Scratch, c'est le prédécesseur de Scratch. Et je pense qu'eux, en fait, commercialiser, c'était pas leur... Ils s'en fichaient, quoi. Leur idée, c'était vraiment de fournir quelque chose d'ouvert.

• Sylvain

  Yes. je vais essayer de revenir en arrière sur ce que t'as dit tu disais que Smalltalk c'était le premier langage orienté objet je pense il faut revenir sur la définition de orienté objet par rapport à ce qu'on entend aujourd'hui quand on parle d'orienté objet je pense si tu demandes à la plupart des devs c'est quoi pour toi de l'orienté objet ça va être de dire je peux faire de l'héritage et puis de la composition des trucs comme ça en général c'est les premières réponses qui viennent... Et de ce que j'ai vu, de ce que je connais de Smalltalk par ce que tu en as montré, c'est pas le concept de base le plus important, l'héritage ? Je sais pas si t'arriveras à en parler comme ça.

• Lionel

  Oui, on peut en parler, c'est assez fascinant. En fait, l'idée de Smalltalk, c'est que tout est simple, et le Smalltalk lui-même, c'est assez simple à définir. Donc Smalltalk, c'est un langage orienté objet, ça veut dire qu'on manipule des objets. L'idée des objets, c'est de modéliser le monde qui nous entoure. Par exemple, si je suis en train de modéliser une table, je vais avoir un objet qui est une instance d'une table. L'idée d'un objet, c'est assez simple, c'est qu'un objet encapsule ses données, premier fondamental, dans un objet on a des données, et un objet est capable d'envoyer un message à un autre objet ou à lui-même, et il est capable de répondre lui-même à un message. C'est les fameuses méthodes qui matérialisent un peu ces envois de messages, mais en fait, la programmation orientée objet, au départ, c'est que ça. En fait, c'est un... C'est un concept où on dit finalement, les fonctions qu'on applique aux données, une lambda fonction finalement, au lieu d'avoir la donnée d'un côté et les fonctions de l'autre, on va les mettre au même endroit, une sorte de petite micro-unité de travail, et puis je vais en avoir tout plein, et puis elles vont toutes dialoguer entre elles pour modéliser mon système. Et mon système, quand je vais le regarder, le nom des objets, ça va refléter le nom des concepts que je manipule. Donc typiquement... Par défaut, tu as un OS dans les mains, donc tes classes, tes objets sont des instances de classes, et les classes, elles sont nommées avec les concepts de l'OS, file system, file, window, browser, ce genre de choses. Et si toi, tu commences à créer ton logiciel, tu vas faire la même chose. Et donc l'idée c'était vraiment celle-là. Tu crées tes propres classes, qui sont finalement des templates d'objets, et puis ces objets vont communiquer entre eux. Et c'est tout. Il n'y a pas de notion de statique, il n'y a pas de notion de privé, public, tout ça, ça n'existe pas, tout est public. Et tout le monde interagit avec tout le monde.

• Sylvain

  Je pense que le mécanisme fondamental, c'est cette notion de message qui a été... J'allais dire qu'il a été élargi avec tout plein d'appels possibles de fonctions. Mais il n'y a pas de... Arrête-moi si je dis une bêtise, mais de ce que je comprends, tu n'as pas de méthode qui va renvoyer une donnée. C'est plus directement, j'envoie un message pour... Enfin, je ne sais pas si tu sauras l'expliquer mieux que moi, ça. Comment ça fonctionne vraiment ce système de messaging ? Oui. Est-ce que tu peux la...

• Lionel

  Alors, effectivement, il y a peut-être un truc que je n'ai pas dit, c'est que Smalltalk, c'est simple. En fait, le cœur de Smalltalk, c'est vraiment que ça. Avoir une instance, tu envoies un message, elle répond. Et après, tu t'en as parlé, il y a de l'héritage, il y a des méthodes. Tout ça est codé en Smalltalk. En fait, Smalltalk est codé lui-même avec Smalltalk. Et donc, comment ça fonctionne un envoi de message ? Donc, j'écris une instruction, par exemple, table ouvre tiroir. Je vais écrire une phrase comme ça, littéralement, c'est deux mots séparés par un espace. Ouvre un tiroir, donc ce qui va se passer c'est que Smalltalk va envoyer ça à l'objet, l'objet regarde sa classe et regarde dans le dictionnaire de méthode, est-ce que j'ai quelque chose qui s'appelle ouvre un tiroir. Si oui, la fonction va s'exécuter, peut retourner un résultat, ou pas d'ailleurs, comme les langages modernes, aujourd'hui je parle d'une fonction qui retourne un entier, ou qui retourne... rien, enfin unit, ça dépend du langage, ça peut être une void. Donc il va se passer ça. Mais si l'objet dans sa classe n'a pas la méthode en magasin, ce qui va se passer c'est que la classe va regarder si sa classe parente a la méthode. Et puis s'il y a la méthode, la méthode va s'exécuter. Et puis on va remonter comme ça en fait tout en haut, jusqu'à une classe qui est tout en haut, qui s'appelle... Je vais dire object pour simplifier, en fait elle s'appelle proto. Alors si vous connaissez la programmation prototypale, je pense que c'était un peu l'idée. Mais on va dire que ça remonte jusqu'à Object. Et si la méthode n'existe pas dans Object, c'est là que Smalltalk va dire Ah, je ne comprends pas le message Donc là, il y a une sorte de... Ce n'est pas une exception, il y a quelque chose dans le système qui va se passer qui dit Je n'ai pas compris Donc il y a une méthode does not understand qui se déclenche. Et voilà, ça c'est la mécanique d'envoi de messages et d'héritage. Et tout ça, c'est fait en Smalltalk. C'est-à-dire que tu peux trouver le code dans Smalltalk, dans l'OS. qui est en train d'aller demander aux parents d'aller regarder dans son dictionnaire de méthode. Et du coup, comme tout est objet, tout est classe, même ça, je peux le regarder. C'est-à-dire que je peux écrire du small talk pour aller regarder le dictionnaire de méthode d'une classe ou d'une classe parente. Donc c'est comme ça que le langage est pensé comme ça, en fait.

• Sylvain

  Et donc tout ça, on remet, tout ça a été inventé dans les années 70. Ça date pas des années 80, 90, voire 2000. Non, non, tout ça... Tout ça est déjà ancestral. C'est toujours marrant de remettre dans le contexte. Moi, j'ai découvert les premiers... Mon tout premier ordinateur, entre guillemets, ça date du, on va dire, milieu-fin des années 80. C'était un Commodore 64. On avait du basique. Ce n'était pas de l'orienté objet. On était sur du pur procédural. Et en fait, à ce moment-là, ça faisait déjà plus de 15 ans que l'orienté objet existait. avec des systèmes beaucoup plus puissants. Et je trouve ça toujours marrant à remettre dans ce contexte-là. La suite de l'histoire, parce qu'il y a toute une histoire avec Smalltalk, c'est que j'ai l'impression que la plupart des gens qui ont inspiré l'informatique, la programmation, telle qu'on la pratique aujourd'hui, En fait, tous ces gens-là, ils ont été formés à Smalltalk quand on commence à parcourir des bouquins. Je vais peut-être dire une bêtise, mais sur certains, je me tourne, derrière moi j'ai la bibliothèque, je dois avoir un refactoring de Fowler, si tu regardes chez les anciens, que ce soit Oncle Bob, que ce soit Ken Beck, j'ai l'impression qu'ils sont tous passés par Smalltalk dans leur jeunesse et que ça a grandement... j'allais dire formater et former leur façon de penser et du coup ce qu'ils ont amené après était largement prévisible en vue de Smalltalk c'est un peu ce que tu racontes toi dans ton talk justement

• Lionel

  Oui, alors il y a une sorte de continuité en fait. C'est-à-dire qu'on va prendre l'exemple de Ken Beck, parce que c'est ce que j'ai découvert en fait en préparant le talk finalement, ou j'ai redécouvert, je ne sais plus. Ce qui se passe, c'est que lui, il a écrit des bouquins dans les années 90, et il bossait sur Smalltalk dans ces années-là. Il a écrit un bouquin sur les design patterns, qui doit être assez fondamental, peut-être avant le Goff d'ailleurs, je pense, avec les exemples de code en Smalltalk, qui était inspiré de son expérience en Smalltalk. mais il a aussi écrit le premier framework sUnit, donc sUnit ça englobe tous les xUnit, jUnit, nUnit, etc. Donc c'est lui qui a écrit le premier framework qui s'appelait sUnit, et c'était sur Smalltalk. Et l'influence TDD, par exemple, Babystep, etc., quand tu codes en Smalltalk, en fait, tout à l'heure je disais l'histoire du Does Not Understand, ce qui se passe en Smalltalk, c'est que quand tu codes, tu commences par écrire... Tu travailles top-down, c'est-à-dire que tu commences par écrire le plus haut de ta fonctionnalité, tu écris finalement le code que tu as envie d'articuler, tu l'exécutes, et là il te dit does not understand parce que tu n'as pas encore écrit la méthode, par exemple. Et là, tu vas ouvrir le débuggeur, et tu vas implémenter ta méthode, tu vas dire ok, c'est bon, j'ai implémenté cette étape-là, baby-step, c'est fait, proceed et là, le compilo, il continue, et puis après, tu vas t'arrêter sur la prochaine méthode que tu as implémentée. Ce qui fait que, et ça je l'ai vécu parce que j'ai bossé dans un labo de recherche... Quand j'étais étudiant en stage, on bossait en small talk, et en fait, en gros, une fois qu'on fermait le débugger, on avait fini d'implémenter une feature. Et donc cette notion de travail itératif, baby step, est basée sur le fait d'utiliser finalement l'environnement que tu as comme un cahier de brouillon pour crafter tes API, tes classes, tes objets. C'était vraiment là aussi, et je pense que c'est ça qui inspire finalement ces personnes qui ont écrit des bouquins assez fondamentaux dans le craft. Je pense vraiment qu'il y a une influence parce que moi-même ayant vécu un petit peu de travailler avec ce langage, ça m'a largement aussi influencé dans ma manière de travailler. Donc je pense que c'est un peu ça. Donc Wackenbeck, c'est vrai. Oncle Bob, etc. Je n'ai pas regardé finalement.

• Sylvain

  Oncle Bob, je ne sais pas. J'ai balancé son blast parce qu'il est souvent associé à ça. Paul Fowler, dans son premier bouquin de refactoring, dans la vieille édition, dans la nouvelle, il a mis à jour les exemples. Il parle énormément de Smalltalk. La première fois que je l'ai lu, je ne comprenais pas de quoi il parlait. Je voyais les exemples étaient quand même pertinents, mais souvent dans les explications, dans le passif, il remontait oui, mais en Smalltalk on faisait ça, oui, mais en Smalltalk on faisait ça Donc c'est assez intéressant de voir d'où ça vient. Dans ce que tu dis, il y a deux trucs qui m'ont interpellé. Toi, déjà, tu as fait du small talk en tant qu'étudiant. Ce n'était pas dans les années 70. C'était beaucoup plus récent que ça. On fait encore du small talk de nos jours. Il y a encore du small talk en prod. C'est quoi ? C'est du travail de recherche ou il y a vraiment des applications, des apps qui tournent là-dessus ?

• Lionel

  J'avais fait quelques recherches avant le talk. Il y a encore des entreprises qui font du Smalltalk, mais je pense que c'est plutôt du legacy software, pour ce que j'ai pu lire. Après, il y a des distributions professionnelles de Smalltalk qui existent toujours. Il y a Syncom Visual Works, si ma mémoire est exacte. C'est la distribution avec laquelle je travaillais de manière un peu professionnelle. Je bossais dans un labo dans lequel il y avait une entreprise attachée. Et donc, nous, on livrait des images. C'est ça qui est un peu déroutant, c'est que quand tu livres ton code, tu livres une image dans laquelle le code est en clair. C'est un peu un concept open source, on va dire, avant l'heure. Après, ce qu'on faisait, par exemple, c'est qu'il y avait des outils qui permettaient de compiler ça en binaire. Et du coup, tout le côté does not understand ne pouvait plus exister parce que tu as enlevé tout le côté dynamique. Ça faisait un peu du tree-shaking, en fait, si tu veux. Mais ça, c'est des choses qu'on était amené à faire pour livrer un exécutable qui était un client lourd, qui se connectait à un serveur et qui faisait de l'affichage un peu riche. Après, il y a toujours la distribution pharo, qui est... qui est toujours en cours de développement. Cette distribution pharo est beaucoup plus moderne que le langage Moltock initial, dans lequel on a par exemple le support des traits. Les traits, c'est quelque chose qui est utilisé en Scala, par exemple, et ça a été écrit par un chercheur français, je pense, de ce que j'ai vu. Alors, il faudrait que je vérifie l'exactitude de ce que je vais dire. Mais quand j'ai refait un petit peu la biblio, en fait, il y a un chercheur français qui est très actif sur ce Moltock, qui s'appelle Stéphane Ducasse, que j'ai vu en présentation, je pourrais en reparler, sur un framework web. en Smalltalk, et qui lui en fait a écrit un papier sur les traits. Je ne sais pas si c'est lui qui l'a inventé, mais en tout cas, il l'a écrit et ça a été intégré dans Smalltalk Faro. Donc voilà, c'est des distributions que tu peux utiliser aujourd'hui, télécharger, exécuter. Moi-même, je faisais une démo end zone pendant le talk là. J'ai utilisé une distribution qui était beaucoup plus simple que Faro, qui ressemblait beaucoup plus à ce que j'avais connu de Smalltalk. Et oui tu peux exécuter du code, tu peux installer des librairies pour appeler des serveurs, il y a un framework web qui permet de faire du push que j'ai vu exécuté en 2004, donc les architectures réactives je l'ai vu en 2004 en small talk avec un chercheur qui te montre un truc, là t'es là, t'es scotché par rapport à ton appli PHP, t'as du mal à faire, voilà. Donc oui ça existe toujours, je pense que c'est pas très utilisé mais...

• Sylvain

  Ouais presque, j'allais dire c'est dommage faut vivre avec son temps aussi, on va pas faire les vieux les vieux cons ah t'es mieux avant mais c'est quand même intéressant de voir que c'est pas parce que c'est vieux que c'est plus utilisé il y a des trucs qui sont moins vieux et on aimerait bien que ça soit bientôt que ce soit bientôt crevé mais il y a des trucs qui méritent qu'on y revienne le truc que tu disais à un moment euh... Tu parlais de Ken Beck quand il a fait émerger le premier framework de test et les premières briques quelque part de TDD. Je trouve ça intéressant, c'est qu'aujourd'hui, il y a beaucoup de gens qui parlent de TDD plus ou moins bien et on se focalise très souvent sur il faut écrire les tests avant Et c'est marrant, dans la description que tu en as donnée, ce n'était pas ça l'important. C'était la dimension de Babystep, c'était de décrire ton intention de comment tu veux utiliser ton truc. Ça compile pas, t'as pas de test là-dedans. Enfin, quelque part, c'est juste une première... T'écris déjà une impléme de prod, mais qui est pas encore comprise par le système. Et ensuite, tu crées l'implémentation finale, et quelque part, c'est une démarche de TDD. sans avoir test mais ça empêche pas de le faire puisque c'est batté toujours sur des steps qui sont très courtes sur une approche itérative et et du coup je voulais te le faire dire mais du coup je les redis mes excuses Mais ouais je trouve ça intéressant de revenir à cette origine là et que et que faire du tdd c'est pas c'est pas c'est pas pisser des tests au kilomètre avant d'écrire des impléments ça suffit pas Il me semble, je sais pas, tu vas me confirmer que même la colorimétrie de tes DD, le red green, il y a déjà un truc dans Smalltalk, je crois, dans la démo que tu faisais, tu passes vraiment par une étape rouge, visuellement rouge, je crois, quand tu compiles pas, le Dante Understan, il est rouge. Ouais, ouais. C'est ça ?

• Lionel

  Ouais, c'est assez marrant. Alors ça dépend des distributions, je pense.

• Sylvain

  Ah.

• Lionel

  À l'époque, c'était en noir et blanc, donc t'avais pas forcément de rouge ou de vert, c'était un écran en noir et blanc.

• Sylvain

  Oui, c'est vrai, il faut remettre ça aussi.

• Lionel

  Oui, voilà, à l'époque, c'est pas rapide, l'écran, c'est pas du 20, enfin, c'est pas du 60 images par seconde. Il y a des vidéos qui traînent, franchement, ça vaut le coup de regarder ce qui se passe. Pour ta question, Le debugger s'affiche, c'est quand même un événement. Quand tu développes, ça te sort vraiment de ton flux. T'es vraiment sûr. Je pense qu'il y a un point important, et c'est ça dont t'es l'aider, c'est les baby steps. Je commence à crafter un petit truc, un baby step qui fait un truc vraiment tout simple. Je le lance, et après je rentre dans une phase où je dois l'implémenter le plus rapidement possible, et puis après je vais le refactorer. Et ce qui est cool, c'est que dans Smalltalk, comme tu lances le truc, et là t'as le debugger qui se met en plein écran et qui dit Voilà ! Does not understand qu'est-ce qu'on fait. Voilà où ça s'arrête. En fait, ça te force vraiment à être dans ce flot de travail. C'est vraiment... Au-delà des tests, c'est le flot de travail, comme tu le dis, qui est intéressant. Je pense même d'ailleurs que Ken Beck, quand il nomme TDD test-driven development, je pense que ce n'est pas vraiment ce qu'il voulait dire. À la rigueur, le test, c'est un effet de bord, mais ce qui est intéressant dans la démarche, c'est de se dire qu'on va y aller progressivement, itérativement, et... Et c'est le code qui va parler, je vais le crafter, je vais l'amener quelque part, je vais le découvrir, je vais le faire émerger. C'est vraiment le... Moi j'utilise TDD très souvent, et moi c'est vraiment comme ça que je l'utilise, parce que ça me ramène à comment je travaillais en small talk en fait. Dès que j'ai... Je pense que j'avais fait un coding dojo en TDD pour apprendre la méthode O, et là c'est pareil, tu vois, je fais la méthode O, je dis Oh ! Ah mais ouais, mais moi je travaillais comme ça en fait ! Sauf que c'était pas des tests, c'était un debugger, mais ouais, ça me rappelle un truc. Et du coup, clac ! Je me suis remis à travailler comme avant.

• Sylvain

  C'est marrant, on fait du neuf avec du vieux. C'est un peu la morale du truc. Moi, j'ai d'autres anecdotes là-dessus. J'aimerais bien avoir des gens qui s'y connaissent. Il y a plein de gens qui découvrent des trucs qui viennent de la programmation fonctionnelle, qui découvrent ça aujourd'hui. J'en fais partie. J'ai découvert... J'utilise un petit peu du pattern matching, des types optionnels et des trucs qui viennent... fondamentalement du paradigme et de la programmation fonctionnelle. Et j'ai même fait une presse il y a quelques temps, il y a peut-être un an ou deux, où j'explique que... Alors, c'est Scott Lasching qui a formalisé ça sous forme de Railway Programming. Et en gros, tu encapsules toutes tes réponses de fonction, tu encapsules ça dans un type résultat, et puis tu as un résultat qui porte la donnée que tu veux, ou alors qui porte l'erreur, suite au fait que tu as... ta fonction s'est pas bien déroulée ou t'es dans un cas d'erreur qui est décrit dans le métier. Et donc ça, moi je viens de.NET, j'ai fait du Java, des langages orientés à l'objet moderne, et ces types résultats, je les ai réimplémentés, j'ai créé les fonctions qui me permettent de matcher tout ça. Et en présentation, un jour, on nous a dit Ouais, vous auriez pu dire que ça vient de Rust, ce truc-là Alors, oui, Rust l'a introduit en natif dans le langage, mais Rust, c'est un bébé langage, c'est tout nouveau. Lisp avait déjà ça, pareil, il y a 50 ans. Donc je ne suis pas expert Lisp, je n'ai jamais mis là-dedans. Mais c'est du fonctionnel et je trouve ça amusant que plus je progresse dans le métier, plus je croise des gens qui se sont amusés à aller voir aux origines du truc. Et en fait... Tout existe déjà, on renomme juste des concepts, on remet au goût du jour des trucs. Et avec ça, j'ai envie de dire, quand tu t'y connais en histoire, tu peux peut-être deviner la prochaine hype sur les pratiques qui pourraient arriver. Qu'est-ce qui va nous tomber dessus ? Je crois que c'est Cyril Martraire qui a des bouts de sujets comme ça. Qu'est-ce que le futur du craft nous réserve ? Il n'y a qu'à voir qu'est-ce qu'on faisait il y a 40 ans. Du coup, toi, tu n'as pas de pronostic ?

• Lionel

  Non, je n'ai pas de prono. Je ne sais pas si la prochaine distribution de Kotlin va m'ouvrir le débuggeur. Non, je ne pense pas. Non, je ne sais pas. C'est vrai que j'ai plutôt une démarche lazy, une démarche paresseuse sur le travail. En fait, tout ce talk, je l'ai fait parce que... En fait, moi, quand j'ai démarré mon taf... Quand j'ai démarré, j'ai fait du Java. Je me suis retrouvé à faire des services qui étaient des classes toutes moches, remplies de méthodes. Et puis je me suis dit, c'est marrant, je croyais que Java c'était un langage orienté objet, mais je me retrouve à faire du duropascal, du procédural, fonction 1 appelle fonction 2, avec des paramètres dans tous les sens. Puis on m'explique un petit peu que je suis jeune et que je ne connais pas la vie. Et puis que c'est comme ça qu'on doit faire. Bon, peut-être. Et puis, dans une des boîtes dans laquelle je bosse, on embauche un stagiaire qui vient, et le premier jour, il ramène un bouquin, c'est programmé proprement, c'est une traduction du Lincoln. Le nom est très très maladroit, mais nous, on regarde ça d'un oeil avec nos yeux de seigneur, on se dit bon, on est d'accord. Puis bon, je m'intéresse un petit peu au bouquin, je me suis dit, si tu veux, on fait du père. Moi, j'ai un apprend de TDD, donc je te montre comment on fait, puis toi, tu me montres ce qu'il y a dans ton bouquin. Donc on fait le truc, et là, je me suis dit, mais ton bouquin, c'est mon cours de Svolto. Parce qu'en fait c'était ça, se dire bah ouais, faut mettre les méthodes avec les données au même endroit, bah oui, ça c'est ce que je disais, le fondamentaux dans Smalltalk, c'était un objet, il est tout petit, il a quelques données et quelques méthodes. Et en fait, tu lis Solide, c'est pareil, bah oui, effectivement, quand on a une classe qui a un contrat, si je la remplace, elle n'a pas le droit de dire je serai une exception parce que je ne supporte pas une partie du contrat. Donc en fait, à chaque fois que je... je reviens et puis je fais un peu de veille et puis je prends un principe Kraft, j'arrive toujours à me ramener à ces trucs qui ont 50 balais. Tu parlais de la programmation fonctionnelle, toutes les monades dont on parle justement, tout ça, c'est dans la théorie des langages fonctionnels, mais tu vas même la trouver dans la théorie mathématique en fait. Au final, si tu reviens vraiment aux fondamentaux, en fait, si tu prends une approche mathématique et où tu essaies d'écrire ton code toujours d'une manière systémique, sans cas spécifiques, en fait, tu vas te retrouver... à revenir à ses fondamentaux et te rendre compte que ces langages, ils étaient faits comme ça, parce que je pense qu'ils avaient un peu cette couleur de matheux, en fait, derrière, qui avait influencé ces langages, quoi.

• Sylvain

  Ouais, il y a un talk assez sympa là-dessus sur les... C'est Émilien Pécoule et Romain Berton qui ont fait ça d'Evox il y a quelques années. Ils ont appelé ça la théorie des catégories, vous la connaissez déjà. Justement, ils reviennent sur tous ces fondamentaux-là de mathématiques. qui ont amené plein de pratiques de code aujourd'hui qu'on connaît, qui fait que quand on utilise les streams en Java ou LinkQ en.NET, pour les stacks que je connais, ça vient de là. On s'en sert au quotidien. Et en fait, le base de leur explication, c'est ça, vous l'utilisez. En fait, ça vient de là, ça s'appelle comme ça dans le langage mathématique. C'est un talk que je trouve assez intéressant et qui a le mérite de... de mettre des mots sur des trucs qu'a priori, ouais, on connaît déjà, ça... Alors c'était osé de balancer un talk en disant Bonjour, vous n'allez absolument rien apprendre aujourd'hui, mais on va vous montrer qu'en fait, il y a plein de choses que vous connaissez déjà, et ça se valorisait pas mal. Et je trouvais ça plutôt, déjà marrant comme approche, et quand même intéressant, parce qu'on apprend quand même toujours des trucs à revenir aux fondamentaux, et à essayer de réappliquer, même si, je t'avouerais que le terme de monade, j'ai une espèce d'allergie, je... Je refuse d'employer ce terme, je ne suis pas sûr de comprendre de quoi je parle à chaque fois. J'ai plein de collègues qui m'ont expliqué dix mille fois, mais si, c'est facile, voyons, une Ausha, c'est... Et j'arrête là.

• Lionel

  C'est ça.

• Sylvain

  Donc, tu as osé l'employer, tu as tout mon respect. Moi, j'évite ce terme-là. Du coup, tu parlais de ce talk-là. Pardon, c'est un peu sans transition. Comment ça t'est venu, toi, de vouloir parler de ça spécifiquement ? Tu nous as pas dit ça fait combien de temps que tu codes pour compte trop de l'argent j'allais dire ?

• Lionel

  Ça fait une vingtaine d'années que j'ai démarré ma carrière pro.

• Sylvain

  Et donc ça fait 20 ans que tu es développeur et tu as attendu 20 ans pour faire un premier talk. Et du coup alors pourquoi avoir attendu aussi longtemps et pourquoi ce sujet là en particulier ? C'était quoi le déclencheur, si tu sais ? Ouais, ouais,

• Lionel

  ouais. Le déclencheur, c'est ce stagiaire que je rencontre en entreprise, qui d'ailleurs a maintenant monté une startup dans l'IA, valorisée, enfin... C'était pas la... Voilà, t'es cool, ça, c'est-à-dire. Et en fait, c'est cette idée de me dire, mais finalement, en fait, c'était un peu me dire, mais j'ai un peu suivi ce qu'on m'a dit de faire, mais finalement, ce que j'avais appris, c'était pas déconnant, et si j'avais continué de faire ce que j'avais appris, donc pas de faire du small talk, mais de continuer sur les fondamentaux, je pense que j'aurais écrit des trucs qui étaient mieux gaulés, ou qui auraient mieux fonctionné, etc. Donc ça déjà, ça a été un apprentissage dans ma carrière. Et je sais pas, après j'ai eu pas mal d'expériences diverses dans des boîtes où du coup, cette espèce de... comment dire... Cette espèce de manière de travailler qui était pas normale, de faire du procédural dans l'objet, en fait j'ai arrêté de le faire. Je me suis dit, bah non, en fait, je vais pas faire ça. Quand je vais argumenter pourquoi je le fais pas, bah c'est facile. c'est écrit sur la boîte, le langage n'est pas fait pour ça, donc en plus, en ne l'utilisant pas comme il est prévu de l'utiliser, il va mal fonctionner, il va mal être optimisé par le compilateur, donc j'ai commencé à me construire tout un argumentaire basé sur les fondamentaux et les pratiques modernes, que j'ai continué à utiliser, puis après j'ai pris un peu de grade dans mes différentes expériences, un peu l'ide technique, un peu archi, etc. Et puis au bout d'un moment, je me suis dit, c'est marrant, parce que ce retour d'expérience où... J'avais oublié finalement que les fondamentaux c'était ça l'important, peut-être que ça peut servir à quelqu'un d'autre. Alors je me suis dit, je vais en faire un talk, et puis je vais en parler, ma rencontre avec Régis, ce fameux stagiaire, cette rencontre avec mes propres connaissances, cette rencontre avec le craft, et puis de venir et de dire finalement, faites-vous confiance, quand il y a des trucs que vous ne trouvez pas normaux, parlez-en, essayez de revenir un peu à l'essence même de votre travail. C'est des choses qu'on ne nous dit pas quand on démarre. Pas dans toutes les boîtes, j'ai peut-être pas eu de bol en démarrant, mais en tout cas, je sais que j'ai vécu ça en étant junior, et j'ai vécu dans des boîtes où on disait aux juniors de toute façon, tu n'as pas l'expérience donc tu ne peux pas parler mais en fait, c'est une vaste connerie. Donc voilà, c'était un peu ça l'idée. Pourquoi plus tard ? Je ne sais pas. Je n'ai pas eu le temps, je n'ai pas voulu prendre le temps, je n'étais pas prêt.

• Sylvain

  Non mais après c'est cool, c'était juste pour dire qu'il n'est jamais ni trop tôt ni trop tard pour se lancer dans la production de conf comme ça, même si c'est qu'une fois pour dire de l'avoir fait, c'est ok. Moi j'incite plein de gens à essayer de passer ce pas, au moins pour essayer. Il y en a qui ont essayé, qui se retrouvent en fait non j'aime pas trop ça, mais c'est bien parce que c'est des personnes qui ont contenté et qui peuvent dire après, qui savent pourquoi elles y retournent pas. J'aime bien aussi ce que tu racontes sur les postures. Toi, tu étais junior, on t'a dit vas-y, tais-toi, t'es junior Alors, t'es pas le seul à avoir vécu ça. Je pense que malheureusement, c'est extrêmement répandu. Et le problème, c'est que c'est un travers qui s'auto-alimente. Parce qu'il y a plein de juniors qui ont vécu ça et qui du coup finissent par être d'accord. Ils intègrent que oui, ils étaient juniors, ils n'avaient rien à dire. Du coup, quand ils se retrouvent seniors et qu'il y a des juniors qui arrivent, ils refont pareil. sans trop savoir pourquoi, c'est un comportement qui est intégré. Et c'est chouette parce qu'a priori, toi, t'as su en sortir parce qu'il y a un stagiaire qui est arrivé avec un bouquin et qui avait l'air de vouloir faire des trucs différemment. T'es pas arrivé avec l'approche tais-toi jeune, moi je sais T'es arrivé avec l'approche ça a l'air cool ton truc, vas-y on essaye, on se met à deux et on essaye Et t'as eu raison parce que ça se trouve, t'aurais eu une posture de… de vieux cons, à dire Range-moi ça, t'as rien compris. Peut-être qu'il n'aurait pas pu s'épanouir aussi bien et il ne serait peut-être pas à fonder des startups sur l'IA de nos jours. Donc, merci pour toi, merci pour lui. Mais c'est une bonne morale, ça, d'écouter les juniors, tous les profils, en fait, ont des trucs à raconter. Alors, ça ne veut pas dire que les juniors disent tout le temps des trucs bien.

• Lionel

  Moi, j'ai eu...

• Sylvain

  J'ai eu cette phase où j'étais un peu plus junior, j'avais un architecte derrière, et je partais au charbon régulièrement. En disant non, je suis pas d'accord, il m'a jamais dit tais-toi, t'es junior, tu sais pas. Il m'alignait ses arguments. Alors souvent, ses arguments étaient meilleurs que les miens, parce que moi j'avais 5 ans de métier et lui il en avait 30. Mais du coup, je trouvais ça cool de pouvoir discuter et de me faire quelque part, j'allais entre guillemets perdre, mais sur une ligne argumentaire, pas sur une ligne autoritaire, c'est quand même beaucoup plus engageant. Je ne l'ai pas eu à chaque fois, je ne l'ai pas eu dans toutes les équipes. Mais ouais, d'avoir des seniors qui jouent leur rôle de seniors. Je pense qu'il faut faire comme ça. T'es pas d'accord ? Ok, on se pose, on discute. Pourquoi t'es pas d'accord ? Et spoiler, de temps en temps, je gagnais, ils disaient Ah ouais, ouais, si, t'as peut-être raison, on va peut-être trouver un truc. Ma décision était peut-être pas la meilleure, on peut peut-être optimiser. Merci du truc. Et je trouvais ça cool.

• Lionel

  Ouais, effectivement. Je pense qu'en fait, il y a un truc qu'on oublie d'expliquer aux techniques qui prennent du grade de la séniorité, c'est que quand on devient un senior et qu'on commence à encadrer d'autres personnes, en fait, on fait du management. On ne nous le dit pas, on ne nous forme pas, mais faire progresser les autres sur des sujets, ou faire que ça s'organise, ou faire que quelqu'un peut amener une idée et puis essayer de lui créer une zone où il peut essayer son idée, et s'il se plante, l'aider à pivoter. Tout ça... c'est ultra opérationnel parce que ça peut être sur du code, sur la qualité de code par exemple, donc voilà. Mais en même temps t'as un humain en face de toi qui va essayer quelque chose, qui va peut-être se planter et derrière tu vois, en fonction des caractères ça peut être difficile des fois de se dire ça a pas marché. Et je trouve que c'est ça en fait peut-être un peu le le mensonge de notre métier quoi, c'est que c'est On me dit maintenant que tu es lead technique, et puis toi tu dis que tu dois avoir réponse à tout, mais en fait pas du tout. Tu es un bon lead technique quand tu ne sers plus à rien. Je pense que ce talk aussi, c'est ça que j'aime bien, c'est venir non pas en vieux con ou en évangéliste de la bonne parole et de la propreté du con, mais plutôt de se dire que finalement tout le monde peut apprendre. Moi j'avais 5 ans de bouteille à l'époque. j'écoute quoi, puisqu'on me propose des arguments et que je ne les connais pas, donc il faut bien que j'aille regarder. Et puis en fait, ça me ramène à des trucs où je les ai moi-même vécus. Donc tu vois, finalement, rien n'est impossible tant qu'on est ouvert.

• Sylvain

  Je pense que je vais garder cette punchline que tu as dit plus ou moins en ces termes, mais le tech lead est un manager. Enfin, être tech lead, c'est du management. Et je pense que si on le présente comme ça, au grand jour, il y en a plein qui vont plus vouloir le faire effectivement c'est un travers du métier j'ai l'impression qu'on a beaucoup d'être lead dev, tech lead mets le nom que tu veux c'est beaucoup une guerre d'ego c'est moi qui m'y connais le mieux donc c'est moi qui vais récupérer cette casquette et avec ça je vais pouvoir négo un salaire un peu plus gros alors au delà de la justification tout à fait légitime de vouloir palper un peu plus, je n'ai pas de critique là dessus bien au contraire hum Mais effectivement, ça amène des postures qui parfois sont délétères, et je l'ai vécu avec certaines personnes. C'est moi le lead, c'est moi qui ai plus d'XP, donc c'est moi qui décide comment on fait, et puis vous, vous obéissez alors que le lead est a priori un manager, qui va permettre de faire en sorte de tirer le meilleur possible des autres profils, et de les mettre en sécurité. J'allais lire affective en sécurité émotionnelle pour justement avoir... T'as le droit de te planter, c'est pas grave. Ou alors dire, sur ce passage-là, on n'a pas le droit de se planter, donc on va y aller autrement. On va pas essayer 13 000 trucs, on va faire différemment. Et j'aime bien ta vision du... J'aime bien ta vision de l'encadrement, de la séniorité. Ça recoupe un peu le dernier épisode du podcast où il y avait Edouard et Colin qui discutaient... et coaching. Alors eux, c'était la discussion coaching sportif versus coaching technique. Est-ce qu'il y a des liens et des ponts à faire ? C'était assez marrant à les écouter. Mais clairement, le rôle de technique, c'est un rôle de coaching d'une équipe de devs, de 1, 2, 3, 4, 5 devs, selon combien il y en a. Mais effectivement, c'est ce Ausha. Et c'est pas déconnant de le... C'est pas déconnant de le rappeler. Et c'est marrant, je m'attendais pas du tout à ce qu'on arrive sur ce sujet-là, c'est cool.

• Lionel

  Oui, je pense que ça revient à la question du pourquoi, en fait. Moi, j'ai une mécanique d'apprentissage qui est entièrement par l'erreur, donc ces erreurs d'être le tech lead et de vouloir prendre trop de décisions, je les ai faites, comme beaucoup de gens, je pense. Mais du coup, je l'ai compris, et c'est ça aussi, en fait, l'idée de ce talk. J'avais mis ça comme message à la fin, c'est vraiment... écouter tout le monde, à la fin c'est du code quand même, donc c'est pas non plus... Voilà, c'est du code, c'est une instruction qu'une machine va comprendre, donc il n'y a pas besoin de trop se prendre le chou non plus, trop prendre d'ego, enfin voilà, il faut arrêter un peu.

• Sylvain

  Oui, là on pourrait faire un long plaidoyer sur l'égoless programming, parce que enlever l'ego des individus dans le dev c'est pas mal, c'est un sujet qui revient beaucoup dans mon... Enfin, autour de moi, c'est peut-être parce que je le génère, je sais pas trop, mais la notion d'essayer d'enlever de... d'enlever un peu d'ego dans ce qu'on fait au quotidien, ça ne fait pas de mal et ça ne ferait pas de mal d'en enlever encore un peu plus. Et je dis ça, je ne m'exclus pas de cette démarche-là. Je me vexe toujours quand j'ai un truc qui ne marche pas. C'est stupide. Je me suis gouré, j'ai oublié un cas de test, j'ai pushé un truc trop vite, je n'ai pas forcément bien respecté mes baby steps, même si... 80% de mon métier, c'est d'expliquer aux gens qu'il faut le faire comme il faut. Des fois, je me plante et je me vexe vachement. Des fois, je m'auto-énerve. Des fois, il y a des collègues qui peuvent croire que je m'énerve contre eux. En général, c'est contre moi. C'est un sérieux j'ai fait ça, mais ce n'est pas possible Bon, écoute. Mais il y aurait peut-être tout un épisode à faire à parler des problématiques d'ego dans le dev. Mais ça, c'est intéressant. Je ne sais pas, toi, si tu as encore beaucoup de choses à raconter, puisque ça fait déjà un petit moment qu'on cause. Juste, la petite question que je me posais. Donc, toi, tu disais que tu es arrivé dans la tech par Java. Tu as connu Smalltalk. À un moment, tu as parlé de Kotlin. Tu as parlé aussi de PHP. C'est tous des stacks que tu as traversés. Aujourd'hui, tu fais quoi ? Tu as quoi comme stack principal ? Et c'est quoi l'influence de tout ça sur ta pratique dans ta stack ? Ça va avec.

• Lionel

  J'ai traversé pas mal de stacks, j'ai fait du PHP de manière professionnelle déjà dans ma carrière, du Java, du.NET. Aujourd'hui on fait du Kotlin sur la JVM dans un projet sur lequel je bosse. On peut faire du JavaScript ou du TypeScript, ça dépend en fait, c'est en fonction un petit peu de ce que fait la boîte, ce qu'il y a besoin de faire. Je ne suis pas vraiment attaché à des frameworks en particulier. Dans mon boulot aujourd'hui, une partie des problèmes que j'ai à résoudre, il faut que j'écrive un framework moi-même par exemple, parce que ce sont des problèmes qui ne sont pas aujourd'hui traités par des frameworks. Ça peut être ce type d'approche. Donc là, le langage, c'est plutôt une question de qu'est-ce qu'il y a de disponible dans l'infrastructure dans laquelle je peux déployer ? Mes collègues, qu'est-ce qu'ils ont envie de faire aussi ? Par exemple, le démarrage sur Kotlin, on l'a fait, c'était un choix d'équipe en disant Là, on a le choix. Vous avez envie de faire quoi ? Du Node, du Kotlin, du Java ? On a regardé le support qu'on avait, parce que Salesforce, c'est une grosse boîte, donc forcément, tu as de la sécurité, tu as tout un tas de trucs qui viennent avec. Quand tu déploies, tu déploies avec un certain nombre de choses qui sont faites pour toi, faites pour la sécurité et la préservation des données de nos clients. Du coup, quand tu utilises un langage, il est mieux supporté que l'autre.

• Sylvain

  et souvent c'est les langages de la JVM donc après on drive un peu comme ça aussi sur ces choix là cette question de la souplesse des devs autour de la stack je crois que ça va être mon fil rouge de l'année sur le podcast en fait parce que j'ai d'autres personnes que j'ai prévues je sais pas si je vais y arriver mais que j'ai prévues d'inviter pour parler un peu de ça j'ai aussi moi une série d'épisodes où je parle de mon changement de stack où j'ai fait 15 ans de.NET et je suis passé sur une stack Java j'ai présenté un talk à ce sujet là une première fois il y a quelques jours et on a eu des sujets des discussions très très intéressantes sur ce sujet là justement en termes d'ego en venant d'une stack.NET passée sur du Java j'ai plein de critiques à faire sur Java parce qu'il y a des trucs qui me manquent il y a des trucs auxquels je ne suis pas habitué et des trucs cools que je n'avais pas avant et il y a plein de personnes qui prennent la mouche quand je dis ça mais non c'est pas Java le problème c'est que les gens font n'importe quoi non mais c'est pas grave tu as le droit d'entendre que ta stack sur laquelle tu t'es spécialisé depuis tant d'années est perfectible donc c'est assez marrant et j'en reviens je pense que c'est une conclusion que je redirais en fait quand je regarde les devs autour de moi qui m'impressionnent, qui m'inspirent que je trouve un peu qu'ils sortent vraiment du lot Ce n'est pas des gens qui sont ultra spécialisés sur leur stack. C'est des gens qui peuvent changer de stack en un claquement de doigts, qui ont déjà vu tellement de trucs et qui sont tellement solides sur les fondamentaux, les mêmes fondamentaux dont tu parlais, qui existaient déjà dans Smalltalk, dans l'ISP ou dans tout ce que tu veux, dans tous ces vieux fondamentaux. Ils sont tellement solides dessus que passer d'une stack à l'autre, en fait, c'est une anecdote, c'est juste un peu de syntaxe à remettre. Et quelque part, apprendre une syntaxe, ça va assez vite. Alors après, il y a les écosystèmes, les frameworks, un autre débat. Mais passer d'un langage à l'autre, en fait, plus tu en fais et plus ça devient un non-événement. Et ton parcours confirme encore ce constat-là. Tu es passé par des stacks qui ne sont pas forcément très éloignés. C'est tout. Je veux dire, c'est de l'orienter objet. PHP, tu en as peut-être fait une époque où il n'y avait pas d'objet encore dedans. T'as peut-être fait du PHP avant 5 ? Non, il y avait des classes. Ah, il y avait déjà des classes ? Ouais. Moi, j'en ai fait un tout petit peu, mais j'ai connu PHP 4, il n'y avait pas de classe. Mais bon, enfin voilà, c'est très intéressant. J'aime beaucoup ça. Je ne sais pas si tu as d'autres trucs à dire, mais sinon, je te propose qu'on clôture un peu avec ça. Je ne sais pas si tu as proposé ton talk sur d'autres confs depuis le tremplin, si tu as osé faire SPA. Oui,

• Lionel

  j'ai essayé. Je l'ai proposé au MixIT, mais ça n'a pas été pris. Je l'ai envoyé au Devox et je n'ai pas eu de réponse.

• Sylvain

  Devox n'est pas encore arrivé.

• Lionel

  À Montpellier aussi.

• Sylvain

  Il y a SunnyTech à Montpellier. MixIT, c'est difficile d'être pris. Il y a des gens qui sont pris. Moi, je n'ai toujours pas réussi. Après tant d'années, j'ai réussi à parler dans plein de confs en France. Je suis plutôt centré sur Lyon et je n'ai toujours pas réussi à parler dans la principale conf de dev sur Lyon. J'espère que tu seras appris sur d'autres confs. Protips, il y a d'autres là. Au moment où on enregistre, je crois que DevLil est encore ouvert. Et puis, il me semble qu'il y en avait une autre. Je ne sais pas, je te retrouverai ça en off. Mais il y a d'autres. Il y a d'autres confs qui sont ouvertes. Donc voilà. En tout cas, merci beaucoup d'être venu dans le podcast. Si un de ces quatre a un autre sujet dont tu as envie de parler, je serais ravi de te recevoir à nouveau. C'était très agréable. Je passe un bon moment. Et puis, j'apprends des trucs. Ça me rappelle des trucs que je savais que j'avais oubliés. Donc, merci beaucoup. Ah oui, est-ce que... Je ne sais pas. À part ta conf, je ne sais pas si tu es présent sur des réseaux où les gens peuvent te contacter s'ils ont envie. Si tu as envie, toi, d'aller te contacter, d'ailleurs.

• Lionel

  Je ne suis pas trop. Je ne suis plus trop Twitter, etc. J'ai un compte LinkedIn. Je peux me trouver avec mon nom. Lionel Armanet. Ce n'est pas très sexy comme réseau. Après, j'ai un compte GitHub. Mon nom de scène, c'est Lionel. Mais ça s'écrit L-I-O-8-N-E-L.

• Sylvain

  OK. Après, je peux remettre des liens. Merci. Il y a des gens qui sont curieux de voir. Ils pourront te retrouver.

• Lionel

  Oui, je pense qu'on peut me retrouver. Je te filerai des liens.

• Sylvain

  Ça marche.

• Lionel

  Et merci aussi pour ton invitation. C'était très cool. C'est le premier podcast de ma life.

• Sylvain

  Donc, oui, c'était chouette. Eh bien, peut-être la suite dans de prochains. Il y en a d'autres, des podcasts. Il n'y a pas que le mien. Si jamais tu as envie, n'hésite pas à pinger d'autres gens. et donc une dernière fois merci et quant à vous qui nous avez écouté jusqu'ici il me reste à vous souhaiter une excellente fin de semaine à la prochaine pour un nouvel épisode et d'ici là geekez bien et codez bien