Cela faisait quelques temps que je n’étais pas allé à un apéro ruby et je n’ai pas été déçu. 3 présentations au programme que je vous détaille tout de suite.
En premier lieu Yann nous a montré comment faire tourner Rails avec Docker. Étant donné que l’on utilise Docker depuis mi 2015 chez Synbioz et qu’on l’a systématisé l’an passé sur tous nos projets (rails ou pas) j’avoue que je pensais m’ennuyer un peu.
J’avais tout faux, Yann a su rendre ça très intéressant et concret, en partant d’une codebase classique qu’il a progressivement «dockerisée». J’y ai au passage découvert dinghy qui facilite la création d’une machine virtuelle utilisant l’hyperviseur de base d’OSX (en lieu et place de VirtualBox), couplé à un partage NFS pour les volumes.
Au final je n’ai pas gardé dinghy mais je me suis repenché sur Xhyve (qui possède un driver docker-machine et le partage NFS en experimental). Les performances sont très prometteuses et l’usage de NFS permet de propager les événements du système de fichiers hôte vers le conteneur, ce qui fonctionne mal à travers VirtualBox et oblige à lancer les serveurs avec des commandes de polling.
Au delà de conteneuriser une application en développement uniquement, Yann est allé jusqu’à la production et nous a présenté à l’occasion Kontena.
Il s’agit là d’une plateforme qui va permettre de gérer toute la chaine classique des conteneurs : stockage (registre), gestion des stacks, gestion des variables d’environnement, orchestration etc…
Autre point appréciable, la plateforme est agnostique en terme d’IAAS car compatible avec Azure, AWS, Google Cloud et plein d’autres.
Étant en plein dans le sujet en ce moment avec Rancher, cela tombait à point nommé pour le mettre en concurrence.
Bob quant à lui nous a parlé de ses déboires avec Draper lors de sa migration d’une application vers Rails 5.
En effet, il s’est retrouvé face à des erreurs un peu absconses avant de se rendre compte qu’elles venaient de Draper, une gem non compatible avec Rails 5.
S’en est suivi l’éternelle question : est-ce que je bascule sur un fork, est-ce que j’attends une éventuelle mise à jour ? Et ce d’autant plus que le code à modifier pour re-faire fonctionner la gem était vraiment limité.
Puis avec un peu de recul plusieurs questions de fond apparaissent : comment s’assurer que ma gem sera maintenue dans le temps ? Y investir du temps et/ou de l’argent peut être une solution mais dans ce cas précis le mainteneur semblait juste avoir déserté, ce qui arrive plus souvent qu’on ne le pense.
Vient donc la question naturelle suivante : est-ce que j’ai vraiment besoin de cette gem ? Fait-elle vraiment énormément de choses que je ne pourrais pas faire moi-même ?
Bob a fini par répondre par la négative à cette question et a donc implémenté le pattern decorator à sa sauce, en utilisant SimpleDelegator.
En conclusion : gardez vos Gemfile les plus fins possibles et choisissez vos gem avec précaution.
Enfin David nous a retracé le couple Rails / assets (aka «je t’aime moi non plus») depuis la version 3 de Rails.
De la logique de «Je mets tout dans public/assets et basta» (pre Rails 3.1), en passant par les gems rails-* qui ont du mal à suivre les cycles de mise à jour des paquets npm (sans compter que le projet rails-assets a failli mourir), le vendor/assets et lib/assets pour en arriver à Sprockets.
La présentation retrace tout ce que gère Sprockets (processeurs, transformeurs, compresseurs, directives, env, manifest, pipeline, etc).
Pour simplifier le tout, Rails 5.1 utilisera Yarn et Webpack. David nous a donc présenté dans les grandes lignes, son fonctionnement et son intégration dans Rails.
Au final un vrai bon cru Ruby Nord, merci à tous ceux qui l’ont rendu possible.
L’équipe Synbioz.
Libres d’être ensemble.