• Le logiciel Greyball de Uber et l'éthique du développeur

Comment uber contourne les règles des villes dans lesquelles ils s'implante en détectant les "faux" utilisateurs qui souhaiteraient le démasquer.

---

Suite et surtout aprofondissements de l'épisode précédent sur les tests (#007).

Transcript par : Jérémy Lecour

Agathe : Bonjour à toutes et à tous. Vous écoutez Le Ruby Nouveau, épisode 9.

Le Ruby Nouveau, c’est votre rendez-vous hebdomadaire sur la tech, le web et Ruby en particulier. Nous enregistrons cet épisode en mars 2017 et à la table nos habitués et invités des différents terroirs du Ruby dans la francophonie.

À la table aujourd’hui nous avons Jérémy Lecour de Marseille

Jérémy : Bonjour Bonjour

Agathe : Et 3 personnes de Paris, Sylvain Abelard

Sylvain : Salut

Agathe : Michel Martens

Michel: Bonjour

Agathe : et moi-même Agathe Bégaud

Bonjour

Agathe : Dans cet épisode nous allons continuer la discussion sur les tests mais avant de rentrer dans le vif du sujet ; une petite actualité.

Sylvain : Alors l’actualité c’est toujours difficile à trouver mais désormais tout est permis, on peut tirer sur Über à boulets rouges et à bout portant, tout ce que vous voulez. Le scandale de plus, c’est le « greyballing ». C’est un bout de logiciel qu’ils ont rajouté — c’était une team un peu secrète — ils se sont rendu compte que dans plein de pays et surtout de villes ils étaient « illégaux ». Les gens ne les aimaient pas, etc. Et que fais une mairie quand elle veut vous chasser ou vous poser des problèmes, elle met des « clients mystère » ; des employés municipaux ou des policiers qui vont installer l’appli, qui vont commander des courses et quand ils vous chopent en flag, c’est bon vous allez pouvoir payer votre amende et on va pouvoir lancer des procédures. Et donc Über qu’est-ce qu’ils ont fait ? Ils ont été super malin. Quand des gens s’inscrivaient sur Über il y avait le logiciel greyball qui rentrait en action. La team greyball disait « ah mais attends, on est allé voir le profil du mec sur Facebook et il est employé de la Mairie ou policier ou tiens il a un comportement bizarre. notre algo a détecté qu’il ne se comporte pas comme nos clients habituels. » C’est cool, y’a du Machine Learning là dedans. Et là le mec se retrouve avec une fausse version de l’appli, qui lui présente des fausses voitures et qui n’aboutira jamais à faire des courses, comme ça tu ne te fera jamais prendre en flag. Donc dans ma tête c’est exactement comme le logiciel de VolksWagen ; « je détecte que je suis sur le banc de test et regarde je suis tout à fait en mode économie. » Là c’est « je détecte qu’il y a quelqu’un qui me veut du mal qui veut utiliser Über pour me faire un procès et ni vu ni connu, disparu ! ».

Jérémy : Genre on lui donne une version alternative de la réalité …

Sylvain : Exactement

Jérémy : … ou une autre réalité.

Sylvain : c’est à la fois très talentueux et très vicelard. Bien entendu, cette partie du logiciel a été avalisée par l’équipe « légale » de Über. Ce qui est aussi délicieux d’ironie.

Jérémy : C’est sorti comment, en terme d’info ?

Sylvain : J’avoue que je n’ai pas trop regardé. C’est sorti par plusieurs sources. je ne suis pas allé chercher à fond pour savoir qui a fait la fuite.

Agathe : Ah la vache, quand même. Et il y a des personnes qui se sont senties ciblées du coup ?

Sylvain : à désormais on ne pare plus vraiment de personnes, c’est juste les agissements de l’entreprise qui sont condamnés. Après bien entendu tu peux dire que c’est le top management qui a dit, qui a suggéré, qui a laissé faire. Les articles que j’ai lus étaient plutôt concentrés sur ce que c’est et « regardez c’est illégal » plutôt que sur « c’est lui, c’est lui ».

Agathe : Ah non, c’est pas vraiment des cibles comme ça dont je parlais, c’est plutôt est-ce qu’il y a des personnes qui se sont rendues compte que l’utilisation qu’elles avaient de Über était étrange ou que l’appli qu’elles utilisaient était étrange.

Sylvain : Alors je pense qu’ils ont du s’en rendre compte parce que quand ça leur donnait des voitures qui n’étaient pas là ou inversement ,quand ils voulaient réserver une course ça n’aboutissait pas. Il y a même des gens qui sont rentrés dans la voiture et au bout d’un moment le chauffeur recevait un appel du management de Über qui lui disait de les débarquer pour une obscure raison. Mais il n’y a pas spécialement de noms de gens à qui ça serait arrivé. Pour le coup je pense que c’est plus normal, tu vas protéger un peu la source.

Jérémy : Du coup ça me fait penser à un sujet qui serait super intéressant à discuter pour avoir les différentes opinions. La question de la responsabilité de l’ingénieur ou plus généralement du développeur autour de contextes applicatifs comme ça. Il y a un certain nombre de voix qui s’élèvent pour valoriser la question de la syndication ou bien d’avoir une forme d’Ordre des Ingénieurs ou en tous cas des développeurs qui pourrait permettre d’encadrer ces questions là, de conseiller les gens, voire de les punir lorsqu’ils ont des comportements qui sont vraiment contre une certaine charte de valeurs. On connait ça chez les médecins, les avocats et dans d’autres professions. Et certains pensent que c’est une solution possible et que globalement l’informatique échappe à tout ça. C’est un sujet qui m’intéresse parce que je ne suis pas forcément toujours très pro-syndicats mais il y aussi vraiment beaucoup de bon dans cette approche encadrante.

Sylvain : On en a un peu parlé dans l’épisode 2 sur « qu’est-ce qu’un développeur ? » avec de l’éthique, des trucs comme ça. On avait parlé des « Order of the Engineer ». Il y a plusieurs personnes qui ont fait ce genre de choses. Il y a des serments qui ont été publiés, un peu comme le serment d’Hypocrate qui ne sont pas trop mal. Je crois que j’avais commencé la traduction d’un des serments. je ne suis pas sûr de l’avoir publié. Il faudrait que je regarde.

Jérémy : Maintenant que tu le dis, effectivement je m’en rappelle l’avoir entendu …

Sylvain : cela-dit on l’a mentionné sans faire un épisode dessus

C’était tout pour l’actu, qui n’a pas besoin de ça pour être chargée mais bref.

Agathe : [coupure] Du coup, je vous propose de retourner sur le sujet de la soirée, qui est : quoi tester ? pourquoi est-ce qu’on en doit pas faire des tonnes de tests ? comment tester du code « legacy » ? et voir quelques autres modes de test.

Sylvain : On a essayé à chaque fois, depuis quelques épisodes de coller ça à une anecdote de quelqu’un au boulot. Je pense que tout le monde récupère du code legacy. Je pense aussi que certains sont ou ont rencontré des gens qui sont extrêmement strictes sur les tests — « il faut absolument les écrire en 1er ». D’autres qui sont un peu plus laxistes, voire qui n’en font pratiquement jamais. Et puis des gens qui ont un peu cette honte de se dire « tout le monde me dit que j’ai une code-base qui est testée à X%, moi je suis largement en dessous et je n’ose pas le dire.”

Donc la question c’est, pour déculpabiliser les gens. Vous arrivez sur un projet qui n’est pas le vôtre, les gens d’avant ont tout fait mal bien entendu. Vous êtes là pour faire bien évidemment mais vous êtes aussi là pour livrer. Vous n’avez pas le temps de commencer par une couverture de test à 100% du legacy. Donc comment on fait ? Là on a un arbitrage : qu’est-ce qu’on teste ? Comment vous faites, vous, quand on vous refile un bébé comme ça ?

Jérémy : Je pense que la définition de « quoi tester ? » peut être éventuellement plus large que la question du code legacy, mais démarrons par là. Effectivement, ça me rappelle une des premières présentations de Katrina Owen qui est devenue assez rapidement d’ailleurs à la suite célèbre pour son approche de refactoring et de l’écriture de tests. Elle avait fait une présentation où elle montrait une fonction, une méthode en fait, qui faisait plein de choses, qui était en fonctionnement depuis des années, qui avait été plus ou moins validée. Il fallait modifier ce comportement etc. Evidemment elle avait très peur de modifier quoi que ce soit parce que c’était assez sensible et elle montrait comment – il me semble que le concept s’appelle les tests « Golden Master », mais il faudrait que je vérifie que je ne trompe pas. Le principe étant de ne surtout pas toucher le code, de commencer par lui injecter des données plus ou moins arbitraires, en tous cas imaginaires et de regarder ce qui sort de là et considérer que c’est la vérité, en tous cas quelque chose qui doit figer le comportement actuel du code. En faisant rentrer volontairement des choses qui ont l’air correct — le « happy path » — et puis éventuellement des choses qui on suspecte que ça pourrait poser des problèmes, pour tenter d’exercer le « sad path » ou des cas bizarres. Du coup en quelques minutes on peut réussir à construire une sorte de suite de tests qui va servir ensuite à valider le fait que les modifications que l’on apporte ne vont pas casser le comportement initial. Du coup là on va pouvoir faire du refactoring, du renommage, de l’extraction de méthode ou toute chose de l’ordre du refactoring. Moi ça m’a beaucoup aidé parce que ça m’est arrivé de le faire plusieurs fois, sur du code que je n’ai pas écrit, ou du code que j’avais écrit il y a longtemps et qui n’était pas sous tests. C’est assez intéressant. Il y a une vidéo tout à fait compréhensible (c’est en anglais bien sûr), qu’on peut suivre assez facilement.

Sylvain : Clairement si tu nous ressors le lien, on le mettra dans les notes de l’épisode.

Jérémy : Oui, je vais retrouver ça sans difficulté. Therapeutic Refactoring by Katrina Owen

Agathe : Ensuite, ça dépend du cas qu’on a. Par exemple si c’est du code legacy, que c’est un gros pâté , on ne sait pas vraiment ce qu’il fait, on peut comment par décomposer les parties de ce code en mini-méthodes et ensuite les tester au fur et à mesure. Comme ça, rendre ton code plus robuste. Un code que tu ne connaissais pas avant le rendre plus robuste en le décomposant. Ça évite de le modifier. On le décompose simplement sans modifier quoi que ce soit et on teste au fur et à mesure en fonction.

Jérémy : Alors je pense que ça c’est très vrai dans les grandes lignes. C’est pas simple, mais surtout pour moi c’est vrai « que dans les grandes lignes ». C’est la démarche de refactoring d’ailleurs, qu’il y ait des tests ou pas avant. Mais les soucis qu’on peut rencontrer dans une situation comme ça — c’est vrai en Ruby mais probablement aussi dans d’autres langages — c’est que rien que le fait d’extraire une méthode peut changer le contexte — le binding au sens Ruby — peut changer la portée d’une variable, peut changer des choses comme ça, qui subtilement peuvent changer le comportement. Du coup, partir tout de suite en se disant qu’on ne modifie pas le comportement, les lignes du code en elles-mêmes, mais simplement extaire et faire un appel de méthode, ça peut en soit introduire une régression ou un changement de comportement. c’est pour ça que je trouve que le conseil de prendre un petit peu de temps au départ pour créer une sorte de filet de sécurité autour de ce gros pâté pour en déterminer les contours — même si on ne comprends pas exactement. C’est là qu’on peut commencer à parler de « smoke test ». On va par exemple injecter des données à cette méthode, en regardant quels sont les paramètres, ce qui se passe si on les fourni ou si on les fourni pas, si on donne manifestement un String alors qu’il faudrait un Integer pour tel paramètre… de voir le comportement, voir ce qui est levé comme exception, ce qui est en sortie, ce qui est en effet de bord. À partir de là on peut passer à l’étape que tu cites, à savoir commencer l’extraction. Commencer la démarche de refactoring en se disant « j’ai un certain niveau de confiance, parce que du coup j’ai ce test là ». Et ces tests là tu éventuellement ensuite pouvoir les effacer, parce qu’ils n’auront de but — comme un filet de sécurité pour ce gros pâté.

Agathe : En effet, tu as raison.

Sylvain : J’imagine que c’est une question de niveau de saleté et de niveau de confiance. Est-ce qu’on doit vraiment se blinder de la manière dont Jérémy et le talk de Katrina Owen le décrit, parce que vraiment on ne sait vraiment pas ce qui se passe. Ou bien est-ce qu’on se dit quand même, « vu ce que j’ai sous les yeux j’ai confiance qu’il n’y a pas de la méta-programmation “che-lou”, j’ai confiance qu’il y a ci ou ça », et donc je peux commencer comme dit Agathe à extraire tout de suite au moins 2-3 des « sad path » et des trucs comme ça.

Agathe : Après, comme dit précédemment, ça dépend des cas. On ne peut pas avoir confiance de manière complètement aveugle dans certaines choses quand on ne comprend pas ce qu’on a sous les yeux. Donc je rejoindrais plutôt Jérémy à ce niveau là.

Sylvain : Donc là on a entendu parler de « smoke testing », donc l’idée d’injecter des trucs pour voir où ça sort. Ça me fait penser à un truc que j’ai fait à l’école et qui se fait aussi dans la sécu, c’est le « fuzzing ». L’idée est d’injecter des trucs un peu dégueulasses. Je crois que vous pouvez trouver sur GitHub, ça a un peu tourné sur Twitter, une liste de plein de chaînes de caractères des accents, des points d’exclamation, des point-virgules, des quotes, des caractères bizarres. En gros avec votre code vous allez tenter de créer un User ou une News avec chacune de ces chaines là et on voit ce qui pète. Dans la sécu ils font ça pareil avec des injections volontaires (du JS, du SQL, du PHP du Ruby, peu importe). C’est facile, ils ont un banc de test tout bête. Ils prennent l’appli et balancent plein de trucs dedans et voient ce qui passe, ce qui a été injecté et ce qui n’a pas été pris. Cette technique là c’est le « fuzzing ». Vous avez déjà utilisé ça ?

Jérémy : Personnellement je n’ai pas utilisé vraiment le « fuzzing » au sens des caractères bizarres au niveau UTF8 et des choses comme ça. Je me rappelle avoir vu ce dont tu parles. Par contre ce qu’avais déjà utilisé c’est une gem qui s’appelle Faker à laquelle on peut demander de générer des noms de villes, de personnes, de métier, des noms de plein de choses et qui va sortir aléatoirement des chaines de caractères qui sont crédibles pour l’usage qu’on veut en faire ; des n° de téléphone, des adresses mails, etc. et qui va permettre d’exécuter des tests ou de construire des fixtures… avec des données qui se ressemblent mais qui ne sont pas toujours les mêmes.

Michel: C’est très important de savoir quels sont les cas de bord de chaque méthode qu’on développe. Par exemple si tu as une fonction qui reçoit un entier, il faut tester avec 0, 1, un nombre négatif, une chaine, pour savoir comment elle va réagire

Jérémy : Et ça on est d’accord — vous l’avez évoqué dans l’épisode précédent sur les tests — c’est quelque chose qu’on fait au niveau test unitaire, pas au niveau test d’acceptation ?

Sylvain : Là aussi ça dépend de ton vocabulaire. Je pense à la partie sécu du truc. Tu as plusieurs approches. La sécu « blackbox » : l’équipe qui t’attaque ne connait rien de ton appli, ils doivent tout découvrir. Ensuite tous les niveaux de gris : tiens je te donne les URL d’accès principales, la doc de l’API, ou tiens je t’ai donné tout le code. Quand c’est un test de sécu où les gens ont plutôt moins d’info sur ton appli que tout le détail, on peut se dire que c’est une forme de test d’intégration, on n’en est pas à l’unitaire. Je pense que les 2 sont utiles.

Michel: On a dans toutes les applications des chemins critiques, par exemple le « signup »… et là aussi on peut avoir des cas de bord, par exemple du nom d’utilisateur avec une chaine vide ou très longue. Il faut tester tout ça.

Sylvain : C’est un peu triste parce qu’on est tous d’accord du coup.

Jérémy : Alors là on va peut-être être moins d’accord, éventuellement, c’est sur « quoi tester ? » en fait. Moi c’est une question que je me suis posée plein de fois et je n’ai pas du tout une réponse définitive et qui est valable plein de fois, mais je pense que c’est très subjectif. Ça dépend beaucoup du projet, de l’expérience de l’équipe de développeurs. Je pense qu’il y a matière à débat. Je dirais que j’ai été converti très tôt à l’utilité des tests mais très tard à l’utilisation des tests. Du coup c’est pas rentré vraiment complètement dans mon ADN, dans ma mémoire musculaire. Je suis convaincu que c’est bien, je l’ai pas mal pratiqué, mais peut-être moins que certains en tout cas tentent de donner comme impression. Je me suis toujours un peu raccroché à cette branche pour ne pas penser que j’étais trop le dernier des mauvais testeurs, sur le fait qu’il paraissait important de tester ce qui est critique. Critique est un mot qui est trop vague, mais par exemple ce qui peut poser un problème de sécurité, poser un problème avec de la circulation d’argent, poser un problème avec des données personnelles… Des choses qui peuvent — soit du point de vue des utilisateurs, soit du point de vue du projet ou du métier qu’il y a derrière — poser un problème si vraiment il y a quelque chose qui fonctionne mal. Par exemple si on a un système qui bug et qui produit 2 prélèvements ou un prélèvement en boucle sur un compte ; ça c’est absolument catastrophique. Il faut que ça soit testé, retesté, au niveau unitaire, au niveau général… Après, il y a d’autres choses qui le sont beaucoup moins, qui peuvent être éventuellement un peu plus laissées de côté. Je ne sais pas quel avis vous avez sur le sujet.

Sylvain : Il y a une phrase qui m’a beaucoup inspiré, c’est pour ça que j’ai suggéré les sujets de tests, c’est dans le podcast de « Andrzej on Software » — que je recommande. Il dit « quand je sens que mon archi n’est pas bien définie je vais tester très haut niveau », donc les tests d’intégration, les fonctionnalités principales… « Et plus je sens que mon design, ma conception se cristallise, plus je vais descendre vers les tests unitaires. ». c’est à dire qu’il ne va pas s’embêter. Déjà on est en train de créer du code donc on crée de la dette. On va faire de la maintenance, donc maintenir ces tests en plus. Il dit « je code, je vois où je vais, pour le besoin j’ai à peu près une idée, mais l’implémentation je ne sais pas où elle va aller, donc on ne s’embête pas à la tester au millimètre près. Quand c’est bien défini, que l’archi ne pas plus trop changer, alors on va commencer les tests unitaires sur les cas pourris. ». Je ne sais pas si c’est une approche qui vous parle beaucoup, moi c’est ce que je fais en général.

Jérémy : Ça me parle pas mal. Ça me fait même un peu penser aussi — il me semble que c’est Ronan qui disait ça, il parlait des « spikes », les petites sessions de code exploratoires. J’aime beaucoup cette idée que surtout si les tests sont perçus comme un encombrement, on va d’abord avoir une démarche purement créative, d’explorer un sujet, de voir quelle forme peut avoir le code, quel genre d’API on peut avoir au niveau des objets et des méthodes, pour essayer de comprendre un peu éventuellement quand il y a justement une partie « client-serveur » de coder les 2 parties même si c’est très bourin et que ça ne gère pas les cas limite… pour voir le périmètre. Ensuite on efface tout et on repart éventuellement sur une démarche TDD, après avoir compris quels étaient les éléments du domaine, quelles étaient les contraintes, où étaient les points critiques. Là du coup on se laisse guider par des tests plus ou moins fins. On retrouve la question de la double boucle. Est-ce qu’on part de la boucle extérieure qui est le test d’acceptation pour aller vers les tests unitaires ou d’autres variantes d’approche ? Mais je trouve ça pertinent, effectivement le fait de dire qu’on laisse de côté une forme de prototype qui m’a éventuellement inspiré, qui m’a surtout permis de dégager des choses considérées comme des fausses bonnes idées et repartir sur une feuille plus propre.

Agathe : Je trouve ça aussi très pertinent. C’est plus la direction dans laquelle je vais en général aussi.

Michel: Oui, moi aussi, mais pourtant je ne parle pas de TDD. Si on fait une « spike » c’est là qu’on fait le design de l’API, de ce qu’on va faire. Après on fait les tests et tout ça mais c’est pas TDD, je crois.

Par rapport à ce que Sylvain disait, dans mon cas c’est l’inverse. Je commence par les tests unitaires et mon but est d’arriver aux tests d’intégration. Avec ces tests d’intégration, je teste les chemins critiques de mon application.

Sylvain : Mais quand tu fais ça c’est que tu as déjà une bonne idée de l’archi que tu veux avoir.

Michel: Oui, en fait, je pense que c’est un peu différent. Admettons que je doive développer une application web, mon premier objectif est de pouvoir interagir avec cette application de 3 façons différentes : à partir d’un navigateur web, d’une console et d’un test. Cela signifie que mon application n’est ni juste une application web ou juste une application console. C’est plutôt un ensemble de composants qui accomplissent différentes tâches. Ces composants ne sont pas au courant de l’existence du navigateur web. Ils ne sont même pas conscients de l’existence d’une console IRB par exemple. Ils ne savent pas non plus qu’il y a des tests. Après bien sûr on aura une couche web, des tests, et on pourra utiliser l’application depuis IRB. Je trouve que si on conçoit l’application comme ça, ça va devenir très très facile à tester.

Jérémy : Ce que tu décris Michel, ça me fait penser au concept d’architecture hexagonale.

Michel: Oui tout à fait.

Jérémy : Moi je trouve ça fascinant. Je n’ai pas réussi à l’appliquer aussi loin que ce que j’aurais aimé. Pourtant j’ai essayé un petit peu. D’ailleurs j’ai trouvé beaucoup de résistance de la part de Rails en tant que framefork pour faire ça. Rails va vouloir toucher à toutes les couches et apporte une forme de résistance à ces séparations d’épaisseurs, de différences de noyau. Mais je trouve ça très pertinent parce qu’effectivement quand tu as un cœur applicatif qui n’a conscience que de sa responsabilité, ensuite tu as des connecteurs d’accès aux données, d’accès à l’extérieur ; comme tu disais la console, le teste, le navigateur. Dans une optique comme celle là, Rails devient la partie qui va brancher le navigateur à l’application et servir d’interface HTTP. Il va servir également pour le déclenchement des tests, à l’accès aux données… Et là il y a un sujet sur Rails vs. autres framework comme Hanami ou autres approches encore plus modulaires, mais là on n’est plus dans les tests.

Michel: Oui tout à fait. On peut créer ce qu’on appelle des « service objects » et ça c’est très très découplé de Rails.

Jérémy : Et c’est super facile à tester du coup.

Michel: Oui super facile.

Jérémy : Mes plus gros pics de satisfaction et de plaisir autour des tests, c’était quand j’ai réussi à exploiter ces types de pattern et pouvoir facilement mettre des tests autour, facilement les faire bouger car du coup ce sont des choses dont les responsabilités sont très ciblées et du coup l’écriture des tests est triviale, et satisfaisante. Ça se déroule à une vitesse pas possible. Grosse satisfaction là !

Michel: Je n’utilise pas Rails, je ne sais pas comment intégrer des “service objects” mais j’imagine que ça ne doit pas être très difficile.

Jérémy : L’utilisation de n’importe quel autre objet, d’ailleurs on dit souvent des « Plain Old Ruby Objects », donc des objets à l’ancienne. Du coup ; inclusion, appels et instanciations.

Michel: En plus, si on fait le contraire et que c’est impossible de séparer le noyau de l’application et le web, pour tester un projet on est obligé de tester la couche web à chaque fois. Donc si pour démarrer Rails ça prend — hier quelqu’un disait qu’il lui faut 2 minutes pour démarrer Rails — ça ne donne pas envie de tester.

Jérémy : Il doit y avoir un paquet de dépendances pour mettre 2 minutes à démarrer Rails quand même.

Sylvain : Ça disait même 20 minutes.

Michel: Mais même, je crois que même si ça prend 20 secondes à démarrer, c’est trop.

Jérémy : Non, Sylvain ; 20 minutes !?

Sylvain : Ah oui, je confirme.

Jérémy : C’était pas du Java ?

Sylvain : Non, il dit 20 minutes. Et ils ont amélioré les choses depuis, mais ça reste dans un « ballpark ». On reste plus à compter en minutes qu’en secondes. En fait justement c’est une question qui me turlupine depuis tout à l’heure. Je vois vos deux approches et celle qui aujourd’hui me semble naturelle. Je me dis que je suis vraiment d’accord. Mais je me dit qu’aujourd’hui j’ai peut-être ce recul là mais quand j’étais junior je ne savais pas. Si j’avais pris vos conseils au tout début de ma carrière, je suis sûr que je les aurais appliqué de travers.

Jérémy : Oui, tu te serais peut-être perdu.

Sylvain : C’est aussi l’un des raisons pour lesquelles je voulais qu’on fasse des épisodes sur les tests. Tout sait qu’il faut en faire. Surtout quand on est junior on se le fait répéter par les blogs, par les vieux… on se le fait matraquer dans la figure. Mais quand on essaie de les faire on ne les fait même pas comme il faut.. C’est un peu dommage. Michel, je conçois que tu aies une certaine pratique de l’architecture, un certain talent, mais surtout beaucoup beaucoup de pratique. Dès le début ton appli web tu la vois comme des morceaux qui seront appelés de 3 manières différentes. C’est sûr que quand tu as ça dans la tête … moi j’ai la maison et le mur dans la tête, je vois déjà les briques qu’on va mettre et dans quel ordre et donc je peux commencer par n’importe quel morceau, je sais que je vais retomber sur mes pattes. Mais c’est vrai que si vous arrivez à vous rappeler comment vous étiez en tout début de carrière, qu’est-ce qui vous a raté, qu’est-ce que vous auriez aimé faire différemment et qui vous semble évident aujourd’hui ? C’est peut-être trop loin. Même moi j’ai du mal à me projeter dans le truc.

Jérémy : Honnêtement je ne sais pas bien me souvenir. Par contre ce dont je me souviens c’est ce qui m’a fait progresser finalement. C’est ressentir la difficulté, la frustration. J’espère ne pas me tromper, je crois que c’est Céline dans l’épisode précédent qui disait qu’elle s’était mise à écrire des tests automatisés parce qu’elle en avait marre de perdre du temps à faire de manière répétitive des tests manuels. Ça c’est clairement une souffrance que beaucoup de monde ressent et c’est une très très bonne motivation pour améliorer les choses ; à la fois en terme de qualité mais surtout en terme d’outillage. Moi j’ai ressenti clairement ça. J’ai ressenti aussi la nécessité, en étant sur des projets qui étaient de plus en plus critiques, pour lesquels il y avait de moins de place pour des graves erreurs. Alors qu’est-ce qui m’a ensuite permis de progresser au delà de la simplement pure expérience et amélioration tout seul dans mon coin, finalement c’est beaucoup de lecture, beaucoup de podcasts, de vidéos, de présentations dans des conférences qui ont illustré finalement des gens qui ont fait des retours sur leur expérience, sur leurs difficultés et les solutions apportées, des questions d’outils, d’approche, de design. je pense que tout ça s’entre-mêle et que si on est — a fortiori si on est autodidacte, ce qui est complètement mon cas d’ailleurs — c’est s’imprégner au maximum de ce que les autres peuvent avoir comme expérience à partager, avoir la propre sienne et mélanger tout ça.

Sylvain : C’est pareil, là t’en as our 10 ans. Je suis junior, j’entends ce conseil là, c’est pas demain que je vais faire du bon code et des bons tests.

Jérémy : Oui mais en même temps c’est aussi ça qui fait tu ne vas pas appliquer bêtement des choses qu’on va t’avoir enseignées. Tu vas aussi l’avoir vécu. Tu vas avoir été dans les tranchées. Du coup ça rend les choses beaucoup plus solides. On est beaucoup plus convaincu que si on récite une leçon. Même si elle nous parait bonne. je pense que finalement il n’y a pas de secret. Ce dicton que c’est à partir de dix mille heures de pratique d’une chose qu’on arrive à la maitriser … il n’y a pas beaucoup de secrets, il faut en passer par là. Prétendre qu’au bout de 3 ans de carrière on est un expert, un senior, c’est une illusion. Je fais du dev web depuis on va dire le tout début des années 2000, fin 90, et j’ai l’impression d’être à peine moyen, tellement il y a de choses et tellement je me rends compte de choses que je ne comprends pas, que je ne maitrise pas, des erreurs de débutant que je fais. Le chemin est long. Et ça fait partie du plaisir, de la passion, que de se rendre compte de ce qu’on arrive à acquérir au fur et à mesure. SI on se dit je suis au bout, on n’a plus rien à acquérir.

Sylvain : C’est difficile de reprendre après ça, c’est très beau et je suis tout à fait d’accord.

Agathe : Et si on reprend à ce qui nous a amené à commencer à faire des tests, de mon côté je me rappelle que ça n’était pas tant le fait d’en avoir marre, de faire de répéter de nouveau des tests à la main. C’était plus la frustration de na pas avoir de confiance dans mon code. J’avais peur de ce qui pouvait se passer par rapport aux actions que je faisais et du coup c’est comme ça que je me suis mise à faire des tests au fur et à mesure. Au début je faisais des tests pour tout et n’importe quoi, comme tout débutant. Et après j’ai peaufiné au fur et à mesure en me disant qu’est-ce qui a le plus d’importance, qu’est-ce qui est une fonctionnalité vraiment importante, quelles sont les lignes directives de ma méthode, de ma fonctionnalité et après j’ai fini par passer sur une réflexion plus, “globalement qu’est-ce que je dois tester ?”, ensuite réflexion sur la conception et enfin tests unitaires comme ce dont on parlait tout à l’heure.

Sylvain : On parle aussi du sysadmin fainéant. Il est fainéant parce qu’il n’a pas envie qu’on le réveille au milieu de la nuit, donc il travaille très dur toute la journée pour ne pas qu’on l’embête au milieu de la nuit. Je pense que c’est aussi de là qu’est venue une partie de mes envies de tester. J’ai pris plusieurs projets où le correctif de bug était gratuit, du coup l’un de mes intérêts était de ne pas avoir de bug du tout. Ça m’a aussi très vite appris que du coup dans les tickets d’anomalie tu avais plein de demandes d’évolutions et aussi plein de gens qui ne comprennent pas pourquoi la spec bien déroulée a cette conséquence là et qu’il faut aussi ajouter de la documentation.

Jérémy : À partir de quand on dit qu’on teste trop ? Agathe tu disais « tester tout et n’importe quoi ». Je pense que ça a un très grand intérêt, surtout quand on découvre une technique, une approche, une méthode, une architecture. Ça me parait vachement bien de la pousser très très loin, jusqu’au moment où on se rend compte qu’on a dépassé la limite et qu’il faut revenir un peu. J’ai plein de fois fini par supprimer des tests, des pans entiers de tests parce qu’en fait ils devenaient redondants. Je pense que chacun a une opinion différente, mais à partir de quand est-ce que c’est trop de tests ?

Sylvain : Alors moi j’ai une opinion facile, c’est à partir du moment où c’est contre-productif. Tu dois coder un truc, tu le codes, tu ne le testes pas, il plante, et ben tu as été contre-productif, il fallait tester plus. Tu écris un truc, tu le codes, tu fais des tonnes de test, avant ou après d’ailleurs, et finalement il marche très bien et tu te dis que tu aurais pu zapper une partie des test. Tu as été anti-productif, tu as trop testé. Il y a un peu de pratique pour savoir où on en est au milieu. Je pense que quand Agathe au début de sa carrière testait plein de trucs, moi aussi, on appelait même pas ça des tests, on dit « je vais essayer un truc, ah ben flute, encore raté, encore raté ». Et du coup au début de carrière, quand on teste un peu tout, c’est pas trop tester, parce que finalement on est en train de coder des trucs sur lesquels on n’est pas trop sûr de notre coup. Donc c’est le bon niveau. Quand après on progresse, on finit par avoir l’habitude. Sur le nombre on sort de plus en plus de trucs corrects du premier coup, là on teste un peu moins, peut-être.

Agathe : Plus on acquiert en perception de ce qu’on va faire après moins on a besoin de faire ces tests un peu bruyants. On sait exactement où on va aller, quels sont les tests qui vont être importants, et on n’a pas besoin de faire toute cette recherche en amont en faisant ces tests un peu inutiles et bruyants qu’on faisait au début.

Sylvain : C’est comme si je te disais à partir de quel moment on a trop de roues sur un vélo. Au dessus de 2 roues, c’est trop de roues pour un vélo, mais en même temps pour les petits enfants qui apprennent, les roulettes c’est pas de trop. Et il n’y a pas de honte avec ça, ça marche très bien.

Jérémy : Je pense qu’il y a aussi un indicateur de trop de tests quand la maintenance des tests devient un problème, un fardeau. Quand par exemple dès qu’on va changer la moindre chose dans une implémentation, ça va casser, bon probablement les tests qui testent cette implémentation là, mais éventuellement aussi d’autres choses alentour qui ne sont pas forcément liées. J’ai trouvé que des fois c’était une des raisons pour lesquelles j’ai supprimé tout un tas de choses, parce que parano, j’avais fait trop trop de choses, trop trop de tests.

Agathe : Alors j’ai déjà rencontré ce problème mais c’était en général un problème de conception des tests pour le coup. Maintenant je fais en sorte d’éviter que le fait de changer un test ou une certaine fonctionnalité impacte des tests dans mon application qui n’ont tien à voir avec cette fonctionnalité là ou avec ces tests là.

Jérémy : Oui, c’est de toutes façons un indicateur qu’il y a un problème de conception, ça c’est clair.

Sylvain : C’est pareil, quand tu refais ta conception et que tu refactores un truc et que tu le fais « plus générique » … les modules A et B finissent par marcher de la même manière, tu ne fais plus qu’un seul module A, tous les tests de B deviennent redondants et c’est tant mieux, éventuellement tu en rajoutes quelques uns dans A. Enfin je ne sais pas si je suis super clair. Au bout d’un moment dans ton appli quand elle est grosse, tu fais des petites fonctions redondantes un peu partout et au bout d’un moment tu te rends compte, si tu as un peu de chance et que tu fais un peu gaffe, que c’est la même chose et tes tests c’est pareil. Soit parce que tu t’es rendu compte que le code c’était la même choses, donc les tests aussi. Soit parce que tu te rends compte que tes tests testent la même chose et sans changer ton code tu changes tes tests.

Jérémy : J’ai une question un peu différente, toujours dans l’univers des tests. Est-ce que vous testez des choses en prod ?

Sylvain : Parfois.

Jérémy : Qu’est-ce que tu testes en prod ?

Sylvain : Alors déjà un truc tout bête : le « penny test ». Dès que tu fais un truc avec de l’argent, tu peux faire toutes les plateformes que tu veux, c’est bien ficelé, tu as des contrats, tu paies ta plateforme de pré-prod et recette. Tu vas dire que tuas tel flux, tel machin, tel fichier, tel appel d’API qui arrive et puis tu as fait tous tes tests dans ta pré-prod, tu es super content. En production on suppose que ça va marcher, mais n’empêche qu’au début tu fais ce qu’on appelle un « penny-test ». Il y a quelqu’un qui va mettre 1 centime de son argent juste pour voir si tous les flux bancaires sont au carré.

Agathe : pour tester la configuration, au minimum

Sylvain : ne serait-ce que la config de prod.

Jérémy : Et ça c’est plutôt quelque chose que tu considères comme un test manuel que tu fais une fois ou rarement, ou bien quelque chose qui peut être potentiellement automatisé, fortement répétitif ?

Sylvain : Dans mon cas, quand c’est critique comme ça je me débrouille pour le monitorer et je le fais la première fois ou à chaque grosse échéance, quand on sent qu’on n’est pas au taquet, ou qu’on sent qu’on aimerait être rassuré. On fait ce genre d’astuce.

Jérémy : Je te rejoins, parce que j’ai travaillé, une des dernières grosses applications sur laquelle j’ai travaillé a des flux financiers et effectivement à chaque fois qu’on touchait au cœur de ce qui pouvait toucher les flux financiers, on faisait des équivalents de « penny test ».

Après j’ai un exemple, un cas, toujours pour cette même application, on avait des sortes d’impératifs — qu’on s’était fixés nous-mêmes — de performance mais aussi de configuration de sécurité, d’optimisation. C’est assez large mais en gros on testait — pour le coup avec une tache Rake exécutée depuis n’importe quel serveur mais vers les serveurs de prod plusieurs fois par jour ou au moins une fois par jour. Elle allait tester des choses très variées : par exemple est-ce que sur toutes les pages, ou les pages clés, ma configuration SSL était correcte. Est-ce que je rejette SSLv3 mais accepte bien TLSv1? Est-ce que mon certificat est valide, correct, pas expiré avant X dizaines de jours, encore que ça on peut le tester différemment ? J’avais aussi des tests de cookies par exemple. Evidemment sur des pages authentifiées il y a des cookies qui ont besoin d’être placés, on a besoin d’être identifié, mais sur des pages purement statiques, pour des raisons de performance, par exemple si on utilise un proxy comme Varnish ou autre, on va essayer qu’il n’y ait pas de cookie, garantir que Rails ne va pas renvoyer un cookie sur telle page. On avait aussi des choses comme le fait de tester les en-têtes HTTP qui vont influencer les caches de proxy, de navigateurs… Il y a tout un tas d’en-tête HTTP qui servent à ça, donc vérifier que sur telle et telle page on avait bien la bonne configuration sur les délais d’expiration… Encore un autre exemple ; toutes les ressources graphiques, est-ce qu’elles avaient bien les bonnes dates d’expiration, les bonnes infos de cache, etc. Et j’ai utilisé pour ça Minitest, des tâches Rake… et on avait comme ça une sécurité quotidienne sur le fait qu’on n’avait pas intégré une régression sur le fait d’avoir des cookies partout alors qu’on n’en avait pas, qu’on avait contredit un en-tête HTTP crucial pour le cache.

Sylvain : Je ne fais pas trop ça. Dans mes équipes ça se fait surement un peu, mais dans notre tête on n’a pas en tête que c’est des tests. C’est juste qu’on va vérifier que ça marche bien.

Jérémy : Le truc c’est que pour nous c’était pareil. Au départ on le faisait post mise en production quand on faisait un changement majeur, mais en fait on s’est brûlé. Surtout quand avec un framework comme Rails qui va apporter beaucoup de primitives de gestion d’en-tête de cache, etc. c’est facile de se contredire, surtout lorsqu’on fait des choses assez avancées, entre le cache interne, le cache externe, quand est-ce qu’on renvoie un code 304, les Last-Modified. C’était pas une nouveauté mais on a passé beaucoup d’heures là dessus. Plusieurs fois on s’est cassé la figure, à se rendre compte que notre proxy ne servait plus à rien parce qu’il n’y avait plus de cache qui était possible, à cause d’une bêtise.

Sylvain : C’est vrai. Je ne me rappelle plus des noms des boîtes mais j’ai rencontré 2 boîtes lors des meetups à Paris — pas ParisRb mais d’autres — où leur produit entier c’est ça ; du test automatisé de ta prod. Ils sont spécialisés sur les boîtes de e-commerce, parce qu’évidemment quand ton panier plante, voilà. Je crois même qu’à la base c’était une boite d’hébergement de trucs genre Prestashop et du coup quand il y a un bug c’est OK Corral, tout le monde dit « Ah non, c’est l’hébergeur. Ah non, c’est les codeurs. Ah non c’est les clients qui ont mal configuré. » Et du coup ils ont un truc qui passe toutes les 10 minutes ou toutes les heures et qui va regarder quasiment jusqu’à la page d’achat de tel bouquin. J’avais trouvé ça marrant. c’est un besoin. Je comprends qu’on peut l’avoir. Moi je ne l’ai pas forcément parce qu’on fait différemment, mais c’est intéressant.

Jérémy : Effectivement, je te confirme qu’aujourd’hui je travaille dans une équipe qui fait surtout de la prod et de l’hébergement et de l’infogérance, etc. et des clients qui font du e-commerce et qui disent « Ah, le site est lent, ça doit être le serveur » et puis on se rend compte que finalement ils ont fichu en l’air des index dans la base de données ou ils font des « joins » de dingue, ou alors ils ont carrément justement enlevé des en-têtes ou des choses comme ça. Ça arrive vraiment.

Sylvain : Puisqu’on a parlé de Ops, d’hébergement… je voulais parler rapidement … je ne sais pas si c’est des tests ou du monitoring, il y a quand même le nom : des tests de charge. Il commence à être assez tard, donc on va peut-être commencer à plier l’épisode, mais c’est Christophe de Bruxelles qui nous a suggéré de parler un petit peu de ça. Il a mis “stress, vs. load vs. performance”. Je ne sais pas s’il y a des grosses nuances à ça.

Jérémy : Performance avec les 2 autres, je pourrais les différencier en disant qu’un test de perf n’aura pas besoin de monter très haut dans le nombre de requêtes simultanées. Il va juste par exemple tester que sur la page d’accueil le 1er octet récupéré se fait en moins de 200ms ou le DOM-ready en moins d’1,5 seconde, ou bien le 1er appel sans cache d’une CSS se fait dans tel temps, etc. Donc là on va pouvoir avoir du test de perf ; l’appel à une ressource, en combien de temps elle aboutit. Après sur le stress et le load, je ne sais pas trop faire la différence mais la du coup c’est plus, on va bouriner un service et voir à partir de quand ça commence à s’effondrer. Soit les temps de réponses deviennent beaucoup plus lents ou alors carrément on a des codes d’erreur, 500 ou autres. Autant je pense que les tests de performance on peut les faire presqu’au fil de l’eau comme je faisais mes tests de « sécurité ». Autant les tests de charge on ne peut évidemment pas les faire sur une plateforme de prod en permanence. Par contre, j’ai dans mes clients des gros sites qui nous demandent à peu près 2 fois par an de reproduire le même scénario à chaque fois. On utilise des outils comme Gatling et aussi Tsung qui est assez connu. On défini des scénarios qui peuvent être très très simples comme taper sur la page d’accueil. Mais ça peut aussi être des scénarios d’identification, de panier, d’achat, etc. Il le fait de manière plus ou moins intelligente, avec une montée progressive en charge du nombre d’utilisateurs connectés ou d’une montée en charge du nombre de requêtes simultanées et qui fait un rapport ensuite. Il dit que par exemple les 300 premières connexions simultanées se passent très bien, c’est linéaire, voire stable, puis après ça explose. Mais ça, il faut le faire de temps en temps en vrai, en prod. Comme on dit toujours qu’il faut tester ses backups au moins une fois de temps en temps pour s’assurer que ça marche. Mais évidemment ça a un impact, car quand on commence à faire envoyer des erreur 500 sur la prod, les utilisateurs les ont aussi.

Agathe : [coupure et reprise] Concernant le test de résistance au stress, on peut le diviser au moins en 3 parties. Je vois 3 parties qui sont par exemple tout ce qui est test de capacité. On peut tester au niveau d’un système le nombre maximum d’utilisateurs connectés sur ce système. On peut aussi voir pour un cas où on a une capacité de mémoire inférieure à ce qu’on imaginait, monter le système dans des conditions extrêmes et faire ce test de stress pour voir jusqu’où il peut aller. Et on peut aussi imaginer, combien de temps un système peut supporter un stress donné, avec toujours un type de conditions spécifiques en fonction des tests.

Jérémy : Très très bonne illustration. Ça me donne plein d’idées.

Sylvain : Soit on remballe soit on parle un petit peu de « mutation testing ».

Jérémy : Il faut au moins qu’on l’évoque un petit peu

Agathe : je ne sais pas du tout ce que c’est.

Jérémy : Sylvain tu vas nous faire une petite présentation des tests de mutation.

Sylvain : On va dire que tu es super forte dans les tests Agathe. Ton code est 100% testé. Chaque ligne de code, chaque fonctionnalité, tu as des tests qui vont derrière, t’es nickel. La question est, est-ce qu’on a vraiment besoin de tout tes tests et est-ce que tes tests servent à quelque chose ? Est-ce qu’ils n’ont rien oublié ? Ça tu ne peux pas trop le dire. Du coup il y a des gens un peu fous qui se sont dit que le code est mutant. On a une sorte d’outil magique qui prend ton code et qui dit que la variable ne s’appelle plus pareil, ou le « if » change de sens, des trucs comme ça. Ça veut dire que ton code va changer drastiquement et il est censé faire n’importe quoi. Le mutation testing c’est se dire que quand le code mute, il doit péter un truc, c’est obligé. Dans la « test suite » quelque part il y a un truc qui pète. Sinon ça veut dire que ce « if », qu’il soit dans un sens ou dans l’autre, il ne sert à rien. Il devrait y avoir un cas d’erreur et on ne l’a pas chopé. C’est ça le « mutation testing », de ce que j’en ai compris. Est-ce que quelqu’un veut améliorer ?

Jérémy : Je suis assez d’accord avec ce que tu décris. je compléterais en disant que l’outil va faire une analyse syntaxique du code — l’implémentation, pas le test, a priori — et il va détecter que tu as un « if » ou une structure conditionnelle. Il va l’inverser. Il n’en fera qu’une à chaque fois et si il n’y a pas un test qui casse, il va considérer que c’est pas bon. Soit il y a un problème dans le test, soit il y a un problème dans le code. Je répète ce que tu dis, mais c’est ça. Ça va le faire avec tout un tas de combinaisons et pouvoir te cibler ensuite, parce qu’il y a une analyse syntaxique au départ, ça va dire « c’est là, il y a un truc inutile ». Ou alors c’est qu’un truc n’est pas testé.

Sylvain : L’idée c’est que tu as testé tout ton code, mais comment tu pourrais garantir que tes tests servent à quelque chose et que tu n’as rien oublié ; c’est le mutation testing.

Jérémy : [bêtise, à rayer]

Sylvain : Sinon, il y a un problème avec les tests de mutation. Il n’y a qu’un ou deux gems, une ou deux approches et les gens ne l’ont quasiment pas documentée. Vous allez sur GitHub, vous trouvez le machin, ils ne vous expliquent même pas comment on fait. Et la documentation c’est genre « si vous voulez vous y mettre contactez nous on vous expliquera mais on n’a pas fait de doc ».

Jérémy : Est-ce que tu te souviens le nom des gems ? je crois me souvenir qu’il y a la bande à Piotr Solnica etc. ceux qui avaient fait cet ORM très différent d’ActiveRecord. Ils utilisaient beaucoup ça pour tester leurs bibliothèques, mais j’avoue que je ne m’en rappelle pas.

Sylvain : Je pense que c’est ça, mais je ne saurais pas en dire beaucoup plus. Sur GitHub c’est « mbj/mutant » .

Jérémy : Oui c’est ça, « mbj », mais je ne me rappelle plus le nom de cette personne. « Markus Schirp », oui c’est ça.

Agathe : On mettra tout ça dans la description du podcast de toutes façons.

Sylvain : Carrément.

Agathe : Du coup je vous remercie pour ces explications, puis merci à tout le monde pour cette bonne sessions. Avant de passer aux découvertes de la semaine, nous tenons à remercier notre hébergeur et amis Scalingo. Merci beaucoup.

[coupe]

Michel, tu nous partages ta découverte ?

Michel: Oui. C’est un outil de test que j’utilise depuis 7 ans qui s’appelle Cutest. Avec Cutest chaque fichier de test est exécuté dans un processus bifurqué. On dit comme ça ? Forked ?

Sylvain : Oui, on dit « forké » par abus de langage.

Jérémy : Moi j’aime bien franciser quand il y a des mots qui existent. Un processus bifurqué, j’adore.

Michel: Comme ça on évite l’état partagé entre les tests. Quand il trouve une erreur il montre le détail de l’erreur, le rapport. Le reste du fichier est ignoré. Ça veut dire qu’il s’arrête à la première erreur, comme ça la « feedback loop » est plus rapide.

Agathe : Merci pour cette découverte.

Sylvain : Un peu extrême. J’étais noté comme ça à l’école comme ça des fois.

Jérémy : Ça me fait penser aussi à la manière dont Minitest (et après Rspec s’est mis à le faire aussi) exécute les méthodes de test dans le désordre, justement pour essayer de mettre en évidence qu’un test n’est pas dépendant de l’état qui a été laissé par la méthode précédente, mais avec la possibilité grâce à un « seed » de le rejouer dans le même ordre. Ça va moins loin, mais c’est un peu dans la même veine.

Agathe : [coupure] Ok, merci Michel pour cette découverte. Jérémy de ton côté, qu’est-ce que tu as à nous proposer ?

Jérémy : Alors moi je vais vous parler des plantes. Parce que j’ai découvert grâce à un de mes collègues … c’est basé sur un « Ted talk », une présentation Ted qui est très courte, faite par une personne de nationalité Indienne qui s’est fait diagnostiquer une très grave allergie respiratoire, qui vit à Delhi, donc l’air est extraordinairement pollué et qui s’est penché sur comment pour que les gens qui travaille dans le même bâtiment que lui — c’est un entrepreneur qui a une grosse entreprise — comment faire pour qu’on puisse respirer sainement, pour que lui-même puisse rester en vie finalement, et ne pas vivre dans un caisson . Il s’est rendu compte en compilant différentes études botaniques et scientifiques qu’en prenant 3 plantes finalement assez courantes, en les combinant bien ensemble et dans les bonnes quantités et bons ratios entre le nombre de personnes, la taille du bâtiment, etc. finalement on pouvait vivre en autarcie complète, c’est à dire sans aucun recyclage mécanique de l’air, et ça 24 heures sur 24. C’est assez intéressant car ce sont des plantes qui sont très simples, qui ne nécessitent pas un arrosage très intensif et qui sont très tolérantes aux écarts de température et de lumière. Du coup sans aller forcément jusqu’à se mettre en autarcie respiratoire, on peut quand même éventuellement améliorer l’air qu’on respire à la fois dans nos maisons et dans nos bureaux. J’ai le plan tout à fait détaillé dans le temps pour très rapidement acheter ces plantes là, à la fois pour chez moi et pour mon bureau. Je suis assez sensible, en tous cas dans le principe à la bonne qualité de l’air qu’on respire.

Sylvain : Pas mal !

Agathe : Super intéressant même. Je regarderais avec plaisir ce talk là.

Jérémy : Surtout que ça dure vraiment quelques minutes et c’est très précis, très convainquant. D’ailleurs le site ted.com a ce gros avantage qu’il propose ses vidéos avec des dizaines de langues de sous-titres. Donc même si on ne parle pas bien la langue de l’orateur, on a quand même une transcription qu’on peut bien suivre. je collerai le lien vers la vidéo et aussi un lien direct vers des pages botaniques sur les 3 plantes pour facilement les retrouver.

Sylvain : Cool, merci.

Agathe : De mon côté, je voulais vous faire partager une petite découverte que j’ai faite, qui existe depuis longtemps et que je viens juste de découvrir. Ça s’appelle Huggin. C’est un outil qui permet de créer des agents pour faire de l’automatisation de tâches, par rapport à des choses sur le net. Ça vous permet de surveiller, de lire le web en fait, par exemple surveiller la météo, surveiller le planning des bus ou toute autre chose. Ça permet aussi en lisant le web d’écouter et d’attendre certains événements pour ensuite effectuer des tâches. Les événements qu’on peut imaginer c’est l’envoi d’e-mail s’il pleut, ou un envoi d’e-mail si on a un problème sur la ligne de bus tout simplement. C’est assez chouette car c’est fait en Rails tout simplement. Je vous mettrai le lien dans la description.

Jérémy : Ça fait un peu penser à IFTTT et Boxcar.

Agathe : Carrément, c’est un petit mélange d’IFTTT et de Yahoo Pipes plutôt. c’est un peu ça.

Sylvain : Moi, ma découverte de la semaine c’est assez vieux en fait. Jai eu la chance de ressortir un peu mes jeux de société. J’ai découvert que chez les développeurs et développeuses et principalement dans la communauté ParisRb il y avait plein de gens qui aiment les jeux de société. Il y a des bons joueurs, des mauvais joueurs. Il y a des jeux qui sont en mode compétition. On connait tous le « Monopoly » où c’est pas drôle parce qu’au bout d’un moment vous êtes juste rincés, vous êtes en train de perdre et ça ne risque pas trop de changer, pas comme Mario Kart, vous n’aurez pas des bonus cadeau. Du coup il y a des jeux de société collaboratifs où finalement c’est tous les joueurs ensemble contre le système de jeu. Quand on gagne on est content d’avoir gagné. Quand on perd on s’est bien battus ensemble. On est très aigri contre le système du jeu, les règles sont clairement là pour nous embêter, nous faire perdre, mais quelque part hormis le fait de se mettre d’accord pour dire qu’on n’a rien vu et qu’on va « bypasser » les règles, on va tricher, et bien il n’y a pas vraiment de triche d’un joueur contre un autre. Communiquer, changer de stratégie… c’est open. Et donc dans ces jeux collaboratifs, j’en connais 4 ou 5, il y a « Pandémie » qui n’est pas mal. Il y a un plateau, des maladies qui se développent et les joueurs sont des médecins qui ont des pouvoirs qui se développent pour limiter les maladies, se déplacer, trouver des vaccins, c’est cool. Il y a des jeux très proches : « L’Île Interdite » et « Le Désert Interdit ». Ces 3 jeux là se ressemblent énormément. Et il y a un tout petit jeu assez formidable qui s’appelle « Hanabi ». Ça veut dire « feu d’artifice » en japonais. C’est un jeu de cartes où il faut poser les 5 feux d’artifice de 1 à 5. La complexité du jeu c’est qu’on ne voit pas ses propres cartes, puisqu’on les tient à l’envers. Vos collègues et amis voient vos cartes mais vous n’en savez rien. Il y a un système assez limité pour se donner des infos les uns aux autres. Ça donne un jeu assez formidable. On est tous en train de se dire « Moi je sais, lui il sait, mais lui ne sait pas. Qui a vu mes cartes ? Quelles sont les cartes intéressantes ? » C’est vraiment un jeu « prise de tête » mais c’est vraiment un grand plaisir de jouer ça avec des gens qui sont un peu analytiques.

Jérémy : J’avais entendu parler d’Hanabi quand je cherchais aux alentours de Noël des cadeaux pour mes enfants et celui là m’avait bien plu. J’ai hâte d’essayer.

Sylvain : N’hésite pas, franchement, j’aime beaucoup. C’est un peu « prise de tête » mais j’aime beaucoup.

Jérémy : Je suis comme toi, j’aime beaucoup aussi les jeux de société. C’est moins collaboratif mais j’ai découvert il n’y a pas longtemps « Settlers of Catan ». C’est moins agressif que certains jeux mais pas totalement collaboratif. J’adore ce jeu.

Sylvain : Si tu as un peu de temps n’hésite pas à te mettre à « Aventuriers du Rail ».

Jérémy : Je le connais aussi. j’ai joué avec des copains.

Sylvain : C’est pas agressif non plus mais il y a quand même des bons blocages.

Jérémy : Je suis bien d’accord. J’ai testé ça aussi.

Et « Seven Wonders » aussi, dans une veine plus proche de Catan, mais bien sympa aussi.

Agathe : Après cette suite de jeux de société qui m’ont l’air fort intéressants, on peut conclure l’épisode.

C’est la fin. N’hésitez pas à le partager dans vos communautés et à nous laisser vos commentaires et remarques en allant sur notre site LeRubyNouveau.fr ou sur Twitter @LeRubyNouveau. Un grand merci à tous nos participants et à bientôt.

---

Découvertes des invités

• Sylvain Abélard

Jeu de société collaboratif pour contrer une pandémie mondiale – Pandémie

Les joueurs de ce jeu de société incarnent des artificiers qui coopèrent afin de composer 5 feux d’artifice de couleurs différentes. – Hanabi

• Michel Martens

Systeme de test qui isole chaque test dans un processus bifurqué. – Cutest

• Jérémy Lecour

Ted Talk sur la purification de l'air par les plantes dans un système autonome. – Kamal Meattle : faites pousser votre propre air pur

• Agathe Begault

Outil permettant de gérer des agents pour l'automatisation de taches sur le web. – Huginn