Retour sur bdx.io 2015

Voici un retour sur la conférence bdx.io qui s’est tenue le 16 octobre 2015 à l’université des sciences de Bordeaux.

La keynote dont vous êtes le héros

Didier a inventé pour cette keynote le meilleur moyen de récupérer le téléphone portable de 500 développeurs ! Puisqu’il avait beaucoup de choses à dire en très peu de temps, il nous a demandé de voter par SMS au fur et à mesure de la présentation pour les différentes parties de sa présentation – à la manière des livres dont vous êtes le héros. Le sujet portait sur la manière dont la société de Didier – Sfeir – sélectionne chaque année les technologies sur lesquelles investir. Pour faire ce choix, il faut apprendre à attendre, à ne pas se jeter frénétiquement sur une nouvelle technologie. La notion de temporalité sur une technologie (innovateurs, early adopters, first majority, last majority et trainards) est importante pour qualifier la quantité de business qui peut être tiré. Sfeir va se positionner en partenariat avec un innovateur pour qualifier une technologie, puis conforter son positionnement avec des early adopters et éventuellement la première grosse majorité du marché.
Il nous a ensuite donné quelques indices sur la tendance actuelle : notamment le fait que côté back les langages et frameworks disponibles sont nombreux et fragmentent le marché. Au contraire côté front, un seul langage perdure depuis des années : Javascript. Or, dans nos projets, il est très fréquent selon Dider de passer 60% du temps sur l’interface. Donc selon lui le développeur front va prendre de plus en plus de place sur nos projets.
Autre fait marquant : le cloud est aujourd’hui incontournable et il faut absolument investir.
Une belle entrée en matière donc pour la suite de la journée de conférence au campus universitaire de Bordeaux.

A la découverte du nouveau javascript : ES6/2015

 

Mathieu avait énormément de choses à nous dire sur ECMAScript 2015 et pour cause : cela faisait de nombreuses années qu’une nouvelle version du langage n’était pas sortie.

Parmi les choses intéressantes de sa présentation, nous avons appris que ECMAScript est une spécification alors que JavaScript en est sa (principale) implémentation. Mathieu s’est concentré dans ce talk sur les évolutions du langage lui même mais pas du web, qui lui est piloté par le W3C.
Cela étant dit, Mathieu nous a présenté les nouvelles fonctionnalités du langage par ordre de priorité et c’est cet ordre qui est le plus intéressant car il est proposé par un développeur expérimenté.
Les trois choses qui vont clairement vous changer la vie sont

1. les modules qui arrivent directement dans le langage et non des librairies comme AsynchronousModuleDisplay ou Commonjs/Browserify.
2. les classes qui ne sont que du sucre syntaxique au dessus du prototype mais permettent de focaliser le développeur sur une déclaration plus conventionnelle
3. les promesses qui arrivent nativement dans le langage : évitent le fameux callback hell et permettent aux bibliothèques de proposer un fonctionnement asynchrone portable pour les clients

Les sept nouveautés qui vous simplifieront la vie sont

1. le string template multiligne vous évitant les traditionnelles concaténations de chaînes
2. les paramètres par défaut
3. le destructuring
4. les fonctions fat arrow => qui conservent le contexte de l’appelant, évitant ainsi les malheureusement trop connus var self = this.
5. le scope au niveau du block
6. les paramètres restants avec la notation ...rest qu’il était toutefois possible d’obtenir avant ECMAScript 2015 par des moyens détournés
7. le spreading qui est un peu l’inverse du destructuring

Enfin la nouveauté qui donne mal à la tête :

• les iterateurs et les générateurs

Cette présentation est donc une très belle entrée en matière pour le développeur qui souhaiterait approfondir les nouvelles fonctionnalités de ECMAScript 2015.

Stratégie de collaboration avec Git & Github

Ce talk contient un aperçu des stratégies de collaboration que l’on peut mettre en place avec Github mais regorge également de petites pépites anecdotiques. Par exemple la genèse de la création de github et son business modèle. Au départ, les fondateurs de github n’avaient aucun business modèle. Quand une entreprise leur a demandé le coût pour leur mettre en place un service de repository privé, ils ont simplement demandé le même tarif que le coût d’hébergement des fichiers sur Dropbox : 7$. Ce tarif est encore appliqué aujourd’hui.

Chez github, ils utilisent le github flow qui est à bien des égards unique : ils déploient en moyenne 40 fois en production par jour !

1. créer une feature branch
2. créer une pull request tout de suite
3. faire des revues de code
4. deployer en prod
5. merger avec master

Ce qui devrait vous étonner avec l’enchaînement de ces étapes, c’est que le déploiement en production s’effectue avant même d’avoir mergé sur master. Ils préfèrent pouvoir annuler rapidement la mise en production d’une petite fonctionnalité sur un sous-ensemble de leurs machines plutôt que de pousser sur master quelque chose qui n’aurait pas subit l’épreuve de la production.

Évidemment, cela est possible car le produit qu’ils conçoivent est un site web unique (dans le sens où il n’y a qu’un seul github.com et que le produit n’est pas releasé/déployé chez les clients). Leur infrastructure et leur monitoring leur offrent également un niveau de maturité et de feedback suffisant pour prendre les bonnes décisions :

1. un robot de chat nommé hubot qui déploie automatiquement et à la demande une branche en production
2. la page de status

D’autres flow ont été décrits : fork and pull flow (modèle open source majoritairement adopté grâce à github), dictator and lieutenant flow (celui de Linux), le secret flow (pas encouragé par le speaker), le git flow (pour gérer différentes versions en parallèle).

La fonctionnalité de code review est très importante chez Github. Couplée aux pull requests, cela permet à chaque équipe de s’auto-organiser sur un certain nombre de conventions (nombre de relecteurs, qui fait le merge, etc.). D’autres outils existent pour enrichir la fonctionnalité de base : reviewninja, gitcolony.

Vous avez également la possibilité de renseigner vos bugs et demandes d’évolutions dans github. Là encore des services tiers viennent compléter le besoin comme avec le plugin chrome ZenHub.io qui vous permet de visualiser vos issues dans un kanban.

Enfin quelques nouveautés sont apparues comme les protected branch. Alain vous encourage à lire le blog GitHub Engineering pour avoir plus d’informations sur ce que font les développeurs chez github.

Aux frontières des frameworks

L’introduction est assez intéressante : Arnaud nous parle du problème des 9 points où il faut savoir sortir du cadre (thinking outside the box) pour le résoudre. Ce qu’il veux nous faire comprendre avec cette image, c’est que lorsqu’on conçoit une solution, on a tendance à se limiter.

Un autre point intéressant de l’introduction est la notion de complexité. Sa définition est la suivante dans notre domaine : maintenir sous contrôle la complexité intellectuelle des systèmes logiciels. Or il existe deux types de complexités :

• complexité essentielle : celle des problèmes que nos clients nous posent et que l’on tente d’automatiser
• complexité accidentelle : celle imposée par la technique et les outils que nous utilisons pour nous simplifier la vie

Nous avons souvent tendance à être fiers de notre complexité. Selon Arnaud, il n’y a pas de quoi être fier et minimiser la complexité accidentelle devrait être très important pour nous. La complexité est fonction de la quantité de code & du couplage de nos systèmes. Nous devrions à tout prix arrêter de passer du temps sur des choses que l’on met en place au cas où (YAGNI).

La question de l’entropie est également abordée : d’où vient la dette technique ? En réalité tout système tend vers le désordre dès qu’on y touche. L’entropie est la première source de décomposition du logiciel et elle est accélérée par la complexité.

Il y a quelques années, nous étions souvent confrontés à des projets d’industrialisation : selon Arnaud, appliquer l’industrialisation au développement logiciel n’est pas adéquat.

Nous oublions souvent que nous sommes payés pour résoudre le problème métier de quelqu’un d’autre. Or les frameworks sont conçus pour résoudre des problèmes techniques. Pourquoi nous obstinerions nous donc à appliquer nos cas métiers dans le cadre d’un outil qui ne résout pas nos problèmes ? Ce qui a pour conséquence de rendre le métier moins lisible car il est enfoui dans la technique. Tout peut-être résumé par Hollywood : don’t call us, we call you. Plus sérieusement il s’agit de l’inversion de contrôle : le framework appelle votre code alors que c’est vous qui appelez la bibliothèque. Si vous utilisez des bibliothèques, vous pourrez plus facilement en changer et organiser le code tel que le problème du métier se pose. Arrêtez avec les prototypes techniques : ils partent toujours en production.

Arnaud cite un excellent article d’Uncle Bob : arrêtons de nous jeter sur tout ce brille et focalisons notre apprentissage sur les concepts. Notre veille n’en sera que meilleure.

La suite du talk parle de techniques pour être moins dépendant des frameworks : le découplage par l’orchestrator, le bridge ou le command bus.

En conclusion : à quoi sert le framework finalement ? Il ne sert qu’à gérer les IO web !

Sécurité Frontend

Dans cette excellente présentation de Pauline Galvao et Jérémy Pinsolle, il nous est décrit de nombreuses les failles de sécurité et comment s’en prémunir.

Les navigateurs nous offrent l’illusion de la sécurité mais on va voir que ce n’est finalement que du marketing. Les exemples de failles sont toutes démontrées avec un petit site e-commerce développé pour l’occasion :

1. l’injection SQL (il en existe d’autre) qu’on prévient avec de l’échappement, des regexp, la cannonisation (sans caractères interdits), les requêtes paramétrées (pour précompiler la requête en base) ;
2. l’injection XSS (js) : le navigateur va exécuter un script injecté par le hacker. On peut s’en prémunir grâce à des échappements de caractères par exemple ou utiliser CSP pour restreindre l’origine du contenu à un certain nombre de sites de confiances ;
3. le CSRF (Cross-Site Request Forgery) dont on se protège en utilisant des token (qu’on peut générer à chaque requête ou à chaque formulaire ou à chaque session), des captcha ou des re-authentifications ;
4. L’exploitation d’informations divulguées (pages d’erreur 404 non configurées, header Server dans les entêtes, commentaires HTML) ;
5. L’insecure redirect object reference (exemple : id du produit dans l’url) dont on peut se protéger en vérifiant que l’utilisateur a les droits sur la donnée ou en utilisant une référence indirecte.

Pour aller plus loin, on pourra consulter les failles recensées par l’OWASP (top 10, webgoat project, zed attack proxy) et utiliser des outils de détection automatiques comme map, skipfish ou  wapiti.

La présentation se termine par une démo de zap.

Kubernetes : pourquoi et comment ?

Dans cette excellente présentation, Gérôme et Jean-Baptiste nous expliquent tous les composants de l’infrastructure de Kubernetes, leurs rôles et leurs interactions.

Après un rapide historique du projet Kubernetes chez Google, Gérôme et Jean-Baptiste nous ont présenté les concepts et le vocabulaire de l’outil :

• Pour l’organisation du cluster : le master et les nodes ainsi que leurs différents composants
• Pour la partie container : les pods permettent une séparation en unité logique de notre application
• Les replication controller permettent d’instancier les pods et de garantir l’exécution d’un nombre défini d’instances
• Les services vont être les points d’entrées de nos applications et servir de load balancer entre les différentes instances d’un logiciel

Une démonstration basée sur Google Container Engine a permis de voir en pratique ces différents concepts et de découvrir l’API offerte par Kubernetes.

En conclusion : Nous avons constaté que toute l’infrastructure est opérationnelle et que Kubernetes est prêt pour la production.

Conclusion

Cette seconde édition est encore une fois une réussite par la diversité des sujets présentés, les lieux spacieux et propices à des conférences de qualité sur la forme. Vous pouvez retrouver un autre retour de la conférence. Nous n’attendons plus que les vidéos des talks.