Ruby on Rails RailsConf Portland 2013

RailsConf what ?

Ayant rejoint l’équipe de PayrollHero basée à Whistler, BC, Canada au début du mois d’Avril 2013, j’ai eu la chance de joindre l’équipe pour aller à la méga conférence RailsConf à Portland, Oregon, USA !

L'équipe Payroll Hero

L’équipe Payroll Hero

Je ne suis pas à la base un développeur Ruby/Ruby on Rails mais JavaScript. Un des principaux avantages qui m’ont donné envie de venir travailler chez Payrollhero est de pouvoir justement cottoyer les développeurs senior RoR et d’apprendre le language et le framework.

Les 1500 places ont toutes été vendues, la conférence est sold-out depuis longtemps : c’est la seule grosse conférence officielle organisée par la communauté et où viennent s’exprimer @dhh, créateur de Ruby On Rails et de Basecamp, ou encore @wycats, core contributeur et créateur de @emberjs.

Voici un résumé des talks auxquels j’ai assisté. Il y a beaucoup de conférences au même moment, il faut donc choisir ceux qui intéressent le plus, et rattraper les autres retransmis en vidéo sur le net.

Résumé des talks

How Shopify Scales Rails

How Shopify Scales Rails - RailsConf 2013

How Shopify Scales Rails – RailsConf 2013

Shopify est une très grosse startup maintenant, développant un écosystème permettant de facilement vendre ses produits sur internet en générant des sites e-commerces et mobiles.  Ils sont historiquement basé au Canada. Leur croissance a été exponentielle, ce qui amène a se poser des questions quant à la scalabilité, c’est à dire adapter les infrastructures à la demande. Bien qu’ayant gardé leur codebase originelle, ils ont continuellement migré les applications aux dernières versions, tout en optimisant.

La clé du talk est en fait de monitorer tout, littéralement tout. Par exemple, se construire un service qui traque le temps de chargement des pages principales (dans leur cas, le store et la page de checkout). Cela permet de savoir où on se positionne, et également de lever des alertes quand le niveau est différent de la moyenne habituelle.

Qu’est-ce qui ralentit une application web ? Principalement, les appels externes sont les plus consommateurs. C’est sur ceux-là qu’on à pas la main pour optimiser, et qu’on est dépendant du tiers.

Comment optimiser ? Mettre le maximum en cache est une des solutions, c’est à dire du cache serveur mais également client, tout en faisant transiter le contenu en GZIP permettant un accès plus rapide (sur les navigateurs le supportant). Egalement, séparer tous ses services en applications standalone est une bonne idée, cela permet de se concentrer sur chacune d’entre elles et de les optimiser une par une. Il a également appuyé sur le fait qu’il ne faut pas penser à l’optimiser avant d’avoir pu étudier les plateformes, c’est à dire qu’il faut optimiser après avoir implémenté.

Nobody will Train You but You

Nothing will train you but you - RailsConf 2013

Nothing will train you but you – RailsConf 2013

Cet autre talk était moins technique, et plus orienté éducation. Une chose dont nous nous rendons peut être pas compte, est que nous recherchons souvent les mêmes choses sur Google ou Stackoverflow: un bout de code pour faire tel ou tel chose, une syntaxe.. Tout ce temps perdu à rechercher la même solution n’est pas optimisé. Néanmoins, il ne faut pas se dire que tout est à apprendre par coeur. Seulement ce qui est rapide, et surtout répétitif. La morale de ce talk est en fait de continuer à rechercher intensivement, mais de façon intelligente.

Egalement, se trouver un « mentor » ou quelqu’un de techniquement très bon et en lequel nous avons confiance est une bonne idée, et suivre ses actualités (twitter, blog..) permet de se nourrir de contenu de qualité.

Monitoring the Health of Your App

@wycats a fait une présentation sur une idée que nous devons éviter lorsque nous étudions les statistiques : utiliser la moyenne de nos mesures et nous concentrer sur celle-ci. Je passe sur la démonstration mathématiques des probabilités mais l’idée conducteur est que, par exemple, pour le temps de réponse de notre application, la courbe n’est pas simplement concentrée sur le centre, la moyenne (mean average). Elle est très diverse, c’est à dire que dans la majorité du temps, vous allez avoir un temps de réponse inférieur à X, et dans la minorité, un temps très largement supérieur. La moyenne est donc située à un endroit où personne n’a en fait reçu (long-tail model). Il faut donc se concentrer sur optimiser les zones extrêmes et non pas se concentrer sur une zone vide. Pour ça, il a présenté son nouveau produit, Tilde, qui permet d’enregistrer ces données et d’en tirer des statistiques avancées.

Egalement, enregistrer des données dites « habituelles » permet de lever des alertes lorsqu’elle ne le sont plus, que ce soit en développement, pour tester si nous allons mettre en prod une fonctionnalité qui va changer ça, ou en production.

Front-end Testing for Skeptics

Front-end testing for skeptics - RailsConf 2013

Front-end testing for skeptics – RailsConf 2013

Ce talk était un des plus intéressant de la journée. Partant du principe, souvent vrai, que les développeurs back-end/serveur ne sont pas intéressé par le côté client, Luke Francl a évoqué le fait que tester son client-side est impératif, mais que il n’est pas nécessaire de le faire avec des tests suites clientes comme Jasmine ou Mocha. En Ruby, et sous Ruby On Rails, il est possible d’intégrer une suite toute entière en Ruby, c’est à dire que vos tests sont écris en Ruby mais testent bien des réactions de l’interface !

Grâce a PhantomJS, qui est un moteur de rendu webkit headless, c’est à dire sans interface visuelle mais tournant dans la ligne de commande, il est possible de simuler des scénarios et de capturer des résultats en le combinant avec Capybara, suite connue par les devs Ruby On Rails. Vous pouvez retrouver son talk ici.

Real-Time Rails

Real Time Rails - RailsConf 2013

Real Time Rails – RailsConf 2013

Ce talk était intéressant avec mon point de vue de développeur JavaScript. Le « temps réel » est quelque chose de très simple à implémenter avec node.js et les websockets, surtout avec le module socket.io. Avec Ruby On Rails, c’est pas la même chose. Le framework n’est pas de base prévu pour réagir à des évements externes, contrairement au JavaScript qui est orienté événementiel. Néanmoins, avec Ruby On Rails 4.0 qui ajoute la compatibilité Stream HTTP, il est possible d’envoyer au navigateur des données en continu. Combiné a un système pub/sub et au événements envoyé par le serveur, nous pouvons construire une application qui aurait le même comportement que les websockets.

You’ve got a Sinatra on your Rails

You've got a Sinatra on your Rails - RailsConf 2013

You’ve got a Sinatra on your Rails – RailsConf 2013

Sinatra est un autre framework web écrit en Ruby, c’est un très gros concurrent de Ruby On Rails. Il existe de super applications écrites avec Sinatra (Comme Dashing de Shopify). @josevalim, membre de Rails Core, a montré comment combiner les deux frameworks web ruby pour tirer le maximum des deux. Bien que techniquement intéressant, rien de concret n’est vraiment à en tirer, il est rare (et déconseillé!) de surcharger une app faite avec un framework par un autre…

Ending Keynote par Michael Loop

@rands est une star. Une super star du monde des startups. Et le dernier talk de la journée étant le sien, cela nous a permis de nous dégager un peu de Ruby et de parler entreprenariat, travail en équipe et management de produit. Sa présentation était excellente, il nous a fait réfléchir sur les différents mode d’esprit des développeurs, des managers, et de ce qui faut pour qu’un produit soit assez innovant pour être intéressant, mais également assez fini pour être livré à temps. Je vous conseille fortement (très fortement) de revoir son talk !

  • scicasoft

    Bonjour,
    merci pour le résumé de l’event.

    Juste pour te dire que je ne suis pas d’accord quand tu dis que Sinatra est un très gros concurrent de Ruby On Rails.

    • Oui, c’est quand même pas mal moins utilisé que Rails je suis d’accord. Mais à la conférence le nombre de personnes l’uilisant était assez important quand même, pour des projets moins web app et plus statiques.