EuRuKo 2019 : Ruby 3 or not to be !

Ahoy ! Nous avons assisté à la conférence annuelle européenne de Ruby, EuRuKo, qui s’est déroulée le 20 et 21 juin 2019 à Rotterdam. A bord du SS Rotterdam, les speakers nous ont embarquées dans le monde magique de Ruby et de sa communauté, employant à tour de bras pour l’occasion les jeux de mots de type maritime. Nous avons voulu souligner quatre grands axes qui ont émergés de cette conférence : le futur de Ruby, la méthodologie, les expérimentations avec Ruby, et un écho par rapport à l’univers d’OCTO.

Le futur de Ruby

La grande thématique de cette conférence était bien entendu l’avenir de Ruby. Combien de fois avons-nous entendu, nous rubyistes, “Mais ça existe encore Ruby ?”, “mais c’est utilisé qu’au Japon non ?”, “y’a encore des boîtes qui utilisent Ruby ?”.

Alors si ces phrases proviennent de javascripteurs, de phpistes et autre pythonistas convaincus, force est d’admettre que Ruby a de sérieux concurrents face à lui.

Yukihiro Matsumoto : Functional future of Ruby

Yukihiro Matsumoto, “Matz” de son petit nom, créateur de Ruby, nous présente avec un enthousiasme prenant les avancées de la prochaine mineure, la 2.7, qui sortira en décembre 2019 mais surtout de la très attendue majeure la version 3.0, aujourd’hui prévue pour fin 2020.

Plusieurs chantiers sont actuellement en cours pour la version 3.0 : le typage, la performance et la concurrence.

Static analysis

Matz s’inspire actuellement de la programmation fonctionnelle pour résoudre les problèmes actuels. Ruby 3.0 sera typé mais le typage sera facultatif pour des soucis de rétrocompatibilité. En ce qui concerne le typage, Matz est dubitatif quant à la méthode à sélectionner : Typage statique ou annotation ? Aujourd’hui, il y a 2 solutions de static type checker afin de pouvoir typer son code Ruby : Sorbet et Steep. Le support .rbi vient d’arriver pour Sorbet de Stripe mais Steep est également une solution, plus flexible étant écrit en Ruby. Mais le premier “goulot d’étranglement” de Ruby est aujourd’hui la mémoire.

The 3x3 project

Et non, ce n’est pas un projet de Rubik’s cube mais bien une amélioration intéressante pour Ruby. La promesse de ce projet est de faire en sorte que Ruby 3.0 soit 3 fois plus rapide que Ruby 2.0. Afin d’arriver à ce résultat, l’une des tâches de la core team Ruby est de proposer un nouveau compilateur, plus léger_,_ le MJIT (Method Based Just-in-Time Compiler) pour Ruby 2.6. Mais si MJIT accélère le temps d’exécution d’une application Ruby, le code tourne 2,5 fois plus lentement sur une application Rails. L’avancée sur le compilateur MJIT est prometteur mais nécessite encore du travail afin d’améliorer les performances.

Concurrency

“I regret adding threads”, dit Matz, l’air grave. Si Matz regrette aujourd’hui d’avoir introduit les threads sur Ruby, c’est en raison de la difficulté à gagner en performance et pour le debug. Sur ce sujet, plusieurs solutions sont sur la table : utiliser Guilds pour les goulots d’étranglement du CPU ou Isolate. Il a également évoqué AutoFibers. Ou bien, tout simplement se débarrasser des threads, ajoute-t-il sur un ton amusé.

Eileen M. Uchitelle : Closing keynote - The Past, Present, and Future of Rails at GitHub

Eileen Uchitelle nous a proposé une rétrospective sur ses années au sein de l’équipe de Github et de membre de la core team de Rails. Github est l’emblème de Ruby on Rails, l’une des premières applications de grande ampleur open source à l’utiliser. Lorsqu’elle arriva chez Github en tant qu’architecte en 2017, ces derniers avaient forké Rails. En effet, lors du fork en 2009, Rails n’était pas totalement mature et ne correspondait pas encore aux besoins de Github.

Mais malgré le fait que l’application ait évolué en 8 ans, cette version forkée avait en 2017 déjà deux versions majeures de retard par rapport au repository de base. Elle devint responsable de l’équipe en charge de migrer leur version de Ruby on Rails vers la version la plus récente. En effet, ce retard constituait non seulement une faille de sécurité conséquente pour le logiciel de gestion de versions Git, ne prenant pas en compte des patchs de sécurité, mais rebutait également d’éventuels candidats pour l’entreprise, effrayés à l’idée de travailler avec une version faite-maison de Rails.

Il a fallu attendre 10 ans pour que Github finisse la migration Rails et rattrape son retard de version (© Eileen Uchitelle)

Même si cette migration Rails a pu mettre du temps (1 an et demi), Eileen estime que le temps passé était moins coûteux que la dette technique que Github avait accumulé durant toutes ces années. Plus les développeurs mettent du temps à migrer à la version suivante, plus le développement est complexe et les failles de sécurité critiques.

Eileen dément les rumeurs d’abandon de Rails par Github qui ont tant circulé sur l’internet.

Elle insiste à la fin de sa présentation sur l’importance de Github et de l’ensemble de la communauté Rails et Ruby à promouvoir Ruby. Si Github se défait de Rails, le framework Ruby le plus populaire, cela aurait un impact extrêmement néfaste pour l’avenir de Ruby. Il est ainsi du devoir de toute la communauté de promouvoir et de faire vivre le langage en participant à son amélioration ou tout simplement en continuant à l’utiliser.

Son conseil : Monter en version régulièrement, sinon on risque de devoir faire face à une fragilisation des dépendances, des failles de sécurité, un développement plus complexe et des difficultés pour recruter.

Méthodologie

Charity Majors : Keynote: Yes, I Test In Production... And So Should You

Charity Mayors est la CEO de Honeycomb (outil de monitoring pour les systèmes distribués) et est anciennement ingénieure de production chez Facebook.

Elle nous conseille de ne pas perdre trop de temps à imaginer des scénarios improbables lors de la création de tests ou lors des tests en démo. Pour elle, rien ne peut remplacer la production et seuls les utilisateurs finaux amènent le “chaos” à travers des comportements réellement imprévisibles. Elle relativise par rapport à son titre qui peut faire un peu peur en précisant qu’un script de déploiement est aussi un test en production.

Pour elle, chaque membre de l’équipe doit savoir :

• à quoi ressemble une situation normale en regardant les logs, afin de pouvoir détecter une anomalie lorsqu’il y en aura une,
• déployer l’application en production ou lancer un script de déploiement,
• faire un rollback en cas de soucis,
• faire du canary testing,
• débugger en production.

Sa règle fondamentale : tout et n'importe quoi peut casser tant que l'utilisateur final ne s'en rend pas compte !

Ses conseils :

Damir Svrtan : Surrounded by Microservices

Développeur senior chez Netflix, il s’occupe de la plateforme de pré-production des séries et autre médias de Netflix.  Cette plateforme permet la gestion de la chaîne en amont des différentes productions et n’est donc pas ouverte au public. Pour construire ce produit, les ingénieurs de Netflix étaient d’abord partis sur un monolithe en Rails, mais ont finalement changé d’avis et l’ont divisé en plusieurs microservices. Ils ont aussi choisi une architecture hexagonale leur permettant de séparer la logique métier des implémentations afin de réduire le risque lié aux prises de décision rapides.

Ses conseils :

Il nous parle du Project Paradox via le tweet de Tobias Fors : ce paradoxe qui fait que les choix les plus importants sont fait lorsque la connaissance du projet est au plus bas.

Il faut donc retarder le plus possible les prises de décision lorsque l’on commence un projet.

Damir Svrtan nous avertit également du danger de la fatigue des alarmes (“alarm fatigue” en anglais), le syndrome d’épuisement qui intervient lorsqu’on est constamment exposé à un grand nombre d’alarmes. Cette expression, venant des milieux hospitaliers, se retrouve dans le milieu tech de nos jours où nous loggons tout, jusqu’à épuisement de l’attention. Ce qui fait qu’on peut facilement passer à côté d’un problème important.

Bilawal Maheed : How We’re Making Tech Documentation Better, Easier, And Less Boring

Développeur chez Spotify, il nous parle de l’importance d’une bonne documentation technique. Le plus dur est de maintenir cette documentation et de la mettre à jour pour qu’elle suive les évolutions du code.

Le “Technical writer”, qui est garant du maintien de la doc technique, est un métier à part entière qui n’existe presque plus dans les équipes de développeurs. Spotify a donc développé sa propre solution pour écrire de la documentation technique plus digeste et plus fun. Ils se sont inspirés de Readme.com et ont créé leur outil interne "Techdoc" en une semaine. Malheureusement, ce dernier n’est pas open source.

Bilawal ne nous a pas vraiment donné de conseil pour écrire de la documentation technique moins ennuyeuse mais a cité quelques phrases intéressantes que je vais laisser en anglais, car plus percutantes :

• "Good documentation is a love letter to your future self"
• "Documentation is a part of the answer to the imposter syndrom"
• "Educate/Advocate that a good documentation is part of tech health"

Melanie Keatley : It's very effective; using Pokemon to catch all code smells

Mélanie Keatley est développeuse chez YoungCapital, une entreprise qui permet de booster la carrière de jeunes talents en leur offrant des opportunités de travailler à l’étranger. Mélanie était journaliste avant d’être développeuse.

Elle a essayé de trouver un moyen mnémotechnique de mettre en avant les “bad code smells”, ces parties du code qui témoignent d’un problème d’implémentation, et qui peuvent être assez facilement repérés. Mélanie Keatley a donc trouvé un moyen visuel de représenter les bad smells du code, en s’inspirant des fameux monstres de poche, les Pokémons. Pourquoi Pokémon ? Parce qu'ils appartiennent à des familles partageants certaines caractéristiques et ont chacun une ou des faiblesses qu'on peut exploiter pour les anéantir. A travers des dessins très simples et des surnoms percutants, Mélanie Keatley représente un univers bien connu.

Exemples de familles :

1. 1. 1. 1. Dispensables : Chatcula - Containeron - Copyfree - Sleepzon - Maybeuse - Change Preventers - Dominotron - Shootoïd  2. Couplers : Fency  - Grabbyte - Chainron

“C’est super efficace !”, nous sommes nous dit, en voyant les différents “Pokémon” de Melanie Keatley

Ses conseils :

• utiliser le plus d’images possible, car un grand nombre de la population a une mémoire visuelle,
• ne pas avoir peur de se lancer dans des idées créatives au boulot

Expérimentations avec Ruby

Torsten Schönebaum : Building bricks with MRuby: A journey to MRuby on LEGO robots

Torsten est un développeur logiciel pour Sage, mais aussi un papa bricoleur. Il s'est amusé à modifier le programme interne d'un robot Lego Mindstorm ev3 pour lui faire faire des actions customisées.

Il a eu besoin :

• d’un robot Mindstorm (celui sus-nommé),
• du logiciel ev3dev, l'OS qui tourne sur certains robots Mindstorm,
• d'une carte micro SD d'au moins 2GB,
• de l’interpréteur Ruby, MRuby, pour réécrire le programme initial.

Torsten Schönebaum a choisi le MRuby pour sa légèreté mais a dû faire face au manque de documentation et a dû créer ses propres gems mrbgem. Voici le lien vers son projet.  La marque Lego essaye de susciter l'intérêt des jeunes et des moins jeunes pour la programmation, via sa ligne de robots Mindstorm mais aussi son programme Lego Education qui permet une initiation à la programmation grâce au langage Scratch.

Son conseil pour donner envie aux jeunes de faire de la programmation : utiliser aussi le site MakeCode, qui s'utilise directement dans le navigateur, qui fonctionne avec Javascript, et surtout qui est très visuel.  Ce site propose pleins de tutoriels pour fabriquer des montres, des jeux, des guitares à partir de presque rien, il vaut le coup de détour !

Jan Krutisch : The musical Ruby

Jan Krutisch nous a fait une démonstration musicale de l'utilisation de Ruby. Il explique sur son site https://ruby-synth.fun/ comment utiliser SonicPi pour faire de la musique sans instrument, en reproduisant virtuellement les fréquences de chaque instrument. On a donc vu la décomposition du son d'une cymbale, d'une grosse caisse, d'une ligne de basse etc pour finalement créer une petite musique house.

Cette vidéo de présentation montre chaque morceau de code et son interprétation musicale.

Un écho de l’univers d’OCTO ?

Tout au long de la conférence de nombreux sujets ont résonnés par rapport au discours d’OCTO :

• Diversité : Avant le premier talk, les organisateurs ont présenté le Code Of Conduct de la conférence. Quatre membres de l'organisation se sont présentés comme “référents” à aller voir en cas de problème, ce qui démontre le respect de la communauté Ruby. Des toilettes non genrées étaient aussi à disposition. Chaque participant a aussi pu choisir un collier et un badge soit de couleur rose pour indiquer qu’il était d’accord pour être pris en photo, soit de couleur bleue pour indiquer l’inverse. Le nombre de femmes, tant dans les speakers que dans les participants, était notable. Nous avons d’ailleurs bénéficié de “diversity tickets”.
• Syndrome de l’imposteur :  L’expression “syndrome de l’imposteur” a été utilisé par plusieurs speakers et speakeuses, pourtant chevronnés. Ceci résonne tout particulièrement avec le discours d’OCTO, qui travaille à nous rassurer par rapport à ce syndrome.
• Boite à outil OCTO : Clean Code, principes SOLID, tests, documentation technique, management visuel, un max de fun, des jeux de mots en cavalcade, etc. Tout l’univers de la Skool et d’OCTO en général s’est retrouvé dans cette conférence. On s’y sentait comme à la maison !
• Proximité et bienveillance : Tous les speakers, organisateurs, membres des différentes core team et participants étaient très abordables. Nous avons même pu discuter avec Yukihiro Matsumoto (alias Matz), le créateur de Ruby, de manière très simple :

Notre avis :

EuRuKo est l’occasion de rencontrer les membres de la communauté Ruby. Discuter avec ces gens qui font le même travail que nous a été très stimulant.

Malgré une communauté des plus motivées et l’élégance du langage, le plus grand défi à relever est celui de la performance pour rester dans la compétition. Cela s’est vu dans la structure même de la conférence, en ouverture, la conférence de Yukihiro Matsumoto sur les avancées des prochaines versions de Ruby et en clôture, la conférence de Eileen Uchitelle parlant de l’avenir de Ruby et de l’importance du soutien de la communauté.

Mais une chose est sûre : Ruby’s not dead.

On voit bien que les rubyistes s’emparent du langage afin de l’utiliser à d’autres fins comme la robotique ou la musique par exemple. L’équilibre entre les conférences techniques et les conférences plus méthodologiques était plaisant et le fait qu’il n’y ait qu’une seule track nous a permis de suivre toutes les conférences.

EuRuKo est de plus en plus connu et cela s’est ressenti lors de la vente des tickets. Trouver des places a été compliqué, la deuxième phase de vente a été sold-out en 3 minutes, on se serait crues sur la plateforme du Hellfest.

Pour finir, comme l’a si bien énoncé l’organisateur de la conférence EuRuKo 2020 qui aura lieu à Helsinki, “EuRuKo is finished, but next year, EuRuKo will be finnish !”.

Olivia Salas Elsa Touzeau