Paris.rb : contexte

Jeudi 28 et Vendredi 29 juin 2018 se déroulait la Paris.rb. Une conférence organisée par Thibaut Assus et son équipe dans les locaux de l’Efrei avec des invités très prestigieux dans l’univers Ruby et Ruby on Rails comme Rafael França et Eileen M. Uchitelle membres de la Core Team Rails, Hiroshi Shibata de la Core Team Ruby et bien d’autres.

À Leikir, nous y sommes allés le vendredi en tant que spectateurs, cet article est l’occasion de revenir sur les conférences qui m’ont le plus marqué.

Event Sourcing for Everyone

Paris.rb

Talk de Jenna Blumenthal sur l’Event Sourcing

La présentation de Jenna Blumenthal, backend developer à Shopify, proposait une solution au problème suivant :

Dans une application qui stocke et met à jour des données, il est facile de récupérer l’état actuel d’une donnée. Mais quelles sont les différentes évolutions que cette donnée a subit pour arriver dans son état actuel ?

Une solution simple que nous avons déjà mis en place à Leikir est de faire un snapshot de la donnée avant chaque modification, que nous stockons en base de données. Cette solution est très facile à mettre en place en utilisant la gem paper_trail et ne nécessite que quelques lignes de configuration. La gem propose aussi des fonctionnalités pour revenir à une version antérieure d’une donnée.

Jenna a une approche différente, elle propose de stocker des événements qui ne contiennent que le changement effectué sur la donnée plutôt que de faire un snapshot de la donnée entière.
Ainsi, quand on veut lire la donnée, on va rejouer tous ses évènements pour récupérer son état actuel.
Tous les x jours / semaines / mois, on fait un snapshot de l’état actuel de la donnée et on fait partir les nouveaux événements de cette base-là, permettant de ne plus conserver tous les anciens événements.

Je trouve personnellement cette réflexion très intéressante en repensant à des cas où j’ai implémenté la solution paper_trail. Il n’était pas vraiment utile de garder toutes les versions d’une donnée après x temps et donc de stocker autant de données.

Cerise sur le gâteau: https://github.com/jennaleeb/event_sourcing_for_everyone, un repository git avec des sources et références sur l’Event Sourcing ainsi qu’un exemple d’implémentation.

Crystal

crystal

Luis Lavena, un contributeur Ruby, a présenté Crystal, un langage compilé que son slogan décrit très bien: « Fast as C, slick as Ruby » .

Facile à prendre en main pour un Ruby-ist, par sa syntaxe très similaire, le langage introduit quelques notions comme le typage (non obligatoire) des variables ainsi que l’obligation de devoir gérer les possibles valeurs nil dans son code sans quoi la compilation ne se fait pas.

Il nous a expliqué comment être passé sur Crystal l’a fait évoluer dans sa façon de coder en Ruby. Notamment en faisant beaucoup plus attention sur la possibilité que ses variables, d’une façon ou d’une autre, pouvaient avoir la valeur nil en l’anticipant.

Suite à cette présentation, je me suis pris d’intérêt pour Crystal. J’ai transformé un petit programme que nous avions écrit en Ruby. Résultat : c’est un vrai régal d’allier vitesse d’exécution au plaisir de coder avec tous les atouts de Ruby.

Le langage est encore en phase de développement mais évolue rapidement, c’est donc à suivre dans les prochains mois.

99 problems of slow tests

Paris.rb

Talk de Vladimir Dementyev sur les problèmes de performances des suites de tests (©Crédit photo : Benoit Tigeot)

Vladimir Dementyev, nous a présenté test-prof, une suite d’outils permettant de réduire les problèmes de performances des suites de tests.

C’est un problème qui survient dans tout projet qui prend de l’ampleur. La suite de tests grossi et le temps de s’en rendre compte, les tests prennent déjà trop de temps. Cela arrive car en tant que développeur, on a moins tendance à optimiser les tests que ce qu’on peut faire pour le code applicatif.

Quelles solutions nous propose Vladimir ?

  • L’utilisation d’outils de profiling (RubyProf, StackProf, rbspy) pour repérer d’où viennent les problèmes de lenteur.
  • Bien configurer son environnement de test. Par exemple vérifier son niveau de logs en phase de test car ça ne sert à rien de tout logger.
  • L’utilisation de sa suite d’outils test-prof afin d’identifier et répondre à des lenteurs provenant du database cleaner, du boot time, de cascades de factory, de la génération de data répétitive et autres.

Cette présentation est celle qui m’a le plus captivé car ce sujet est certainement celui qui nous touche le plus dans notre travail quotidien. Et plus que l’identification des problèmes, la suite test-prof propose de vraies solutions pour accélérer drastiquement sa suite de tests.

En conclusion

Cette journée à la Paris.rb était très instructive. Je n’ai parlé que de ces 3 présentations, car ce sont celles qui m’impactent le plus sur mon utilisation quotidienne de Ruby. Cependant toute la journée fut très enrichissante et c’est avec plaisir que je reviendrai à de prochaines éditions.