Nos retours sur Devoxx FR 2016

| 1 Comment | 20 minutes read

Olivier : C’est mon 4e devoxx et c’est toujours aussi bon, d’abord parce qu’on y voit d’anciens camarades de promos, d’anciens collègues et plein de gens de son écosystème. Ça permet de prendre un peu l’air du temps, de se rappeler le bon vieux temps et de partager. Une première pour moi cette année, j’ai assisté aux 3 jours.

Laurent : Après 3 devoxx BE, c’est mon premier devoxx FR et c’est mon premier devoxx en tant que speaker. Pour moi devoxx en quelques mots c’est : “Là où il faut être pour en prendre plein la tête” ; toujours très (et parfois trop) intense et en général de qualité. Il y a très peu de pauses entre les sessions (voire aucune si on va aux quickies). Il y a beaucoup de monde et les places sont chères ; encore ici il faut faire des choix : manger, discuter avec les intervenants d’un talk ou courir pour avoir une place dans le prochain slot ! Tout est enregistré et disponible sur YouTube sauf les Hands-on ; donc le ProTip c’est priorité aux hands-on si on arrive à avoir de la place !

1er jour

La blockchain en détail (Benoît Lafontaine – Yann Rouillard). Je suis pas un grand connaisseur du sujet, je voulais avoir une vue synthétique et c’était parfait. Le sujet est abordé par le fait que cette innovation technique pourrait avoir de forts impacts sur notre société. Ce qui est intéressant c’est que la technique elle même laisse place à des enjeux économiques et organisationnel en définissant les récompenses et la complexité de la participation à la création éléments d’information : les blocks.

De la notion de monnaie on passe à des notions de “smart contract” avec des blocks chain de type ethereum. Les cas d’application sont encore peu nombreux et limités par les temps de traitement et le coût mais on sent bien qu’il y a ici une opportunité de créer des applications “distribuées” et surtout ouverte et digne de confiance étant signée et infalsifiable.

La question qui reste entière c’est que la disruption apportée par cette notion de blockchain : “le tiers de confiance décentralisée” est aussi son plus grand enjeux. L’émergence de grands pools de traitement pour le bitcoins pose déjà la question d’une centralisation de la captation de valeur et du pouvoir de décision. D’autre part la course à l’échalote sur la puissance de calcul nécessaire (me) semble un peu problématique vis à vis des enjeux environnementaux.

Néanmoins sur ces deux aspects des alternatives existent pour modifier un peu la manière dont on peut contribuer à la chaine, le présentateur se risque même à dire que ces monnaies alternatives sont sans doute meilleures que bitcoin (l’audience est pas tout à fait d’accord et le laisse légèrement entendre).

Test Driven Infrastructure avec Docker (Séven Le Mesle). C’est un sujet que l’on regarde avec attention chez ekito lorsque l’on automatise la mise en place d’architecture avec Docker ou autre. Pour moi cela participe à la mouvance, “Tout est code” dans la réalisation des produits actuels :

  • Tests (Automatisation des tests)
  • Chaine d’intégration continue (Travis, Jenkins Pipeline)
  • Infrastructure (Chef, Puppet, Ansible ….).
  • Documentation

Bref on rajoute des tests automatisés sur notre code d’infrastructure et ça me semble toujours une bonne pratique. Bien sûr il faudra un peu de temps pour gagner de la maturité sur la technique et les pratiques.

3 heures pour développer un microservice avec les micro frameworks Java ( Laurent Baresse, Igor Laborie).  Je laisserai les participants mettre des commentaires sur ce Hands-on, mais voila le point de vue du speaker avec une salle quasi-pleine soit environ 80 participants. L’objectif de ce Hands-on est de présenter un cas d’étude dans un contexte microservice afin d’utiliser 2 micro-framework Java : Feign (pour écrire des clients REST) et SparkJava (pour écrire des serveurs REST). Le principe d’un Hands-on ce n’est pas d’écouter un speaker pendant 3h, mais de manipuler soit même ! Donc, à vos claviers !  Le bilan de ce Hands-on côté speaker, c’est que 3 heures ça passe super vite. Le niveau des participants est assez hétérogène mais la très grande majorité semble avoir réussi les exercices ou pour le moins réussi à appréhender les 2 micro-frameworks : Objectif atteint ! Pas mal de questions nous ont été posées en séance ou plus tard entre les sessions des jours suivants.

On peut dire que malgré une certaine appréhension à passer de l’autre côté de la barrière, c’est une expérience grisante et on oublie très vite les  heures passées à la préparation pour se dire qu’on va présenter un nouveau sujet lors de la prochaine édition (et pourquoi pas pour Devoxx BE en anglais).

Postgresql : la nouvelle base orientée document (Yan Bonnel) : Dans cette session le présentateur va nous présenter une fonctionnalité pas forcément bien connue de Postgresql à savoir la capacité de stocker et de faire des requêtes SQL sur les types JSON (non indexable) et JSONB (indexable) disponibles respectivement depuis la version 9.3 et 9.4. La démonstration en mode live-coding est très impressionnante, cependant je me pose encore quelques questions philosophiques en sortant : “Comment Postgresql peut adresser le problème des jointures que des bases spécialisées telles que MongoDB n’adressent pas ? Ou alors au détriment de quoi des perfs ? de la scalabilité ? Quid des transactions ? Et enfin, est-il souhaitable ou faisable de concevoir des modèles de stockage à la fois à la mode document et relationnel ?”. Dans tous les cas c’est une fonctionnalité à connaitre qui sûrement trouvera son application lorsque la volumétrie n’est pas trop importante. Voila quelques exemples de requêtes sur GitHub.

Communiquer en Bluetooth LE avec vos objets connectés, les pièges à éviter (Alexis Duque, Fabien Grenier) qui présente rapidement ce qu’est le protocole Bluetooth LE (à ne pas confondre à avec le protocole Bluetooth). Cette session est très orientée REX et très agréable à suivre. On repart avec des conseils sur comment aborder des développements autour de cette technologie et sur l’utilité des sniffers pour débugger les applications en analysant des paquets réellement émis par les devices et s’assurer qu’une gestion efficace est implémentée sur les devices afin de préserver leur pile. Les slides et le code est disponible sur Github.

Sécuriser ses applications back et front facilement avec Keycloak (Sebastien Blanc). Encore une fois ici, il s’agit d’une présentation intéressante d’un outil open-source développé par RedHat ayant la vocation d’externaliser la gestion de l’authentification et de la gestion des comptes utilisateurs pour des applications WEB et des services REST et par extension le SSO. Il y a une gestion des protocoles OAuth2, JWT ainsi que la gestion des Social Brokers tels que Google, Facebook, Twitter, … L’outil est agnostique par rapport aux technologies et des exemples nous ont été présentés sur une application J2EE, NodeJS, … et dispose d’un back-end clé-en-main pour la gestion des comptes utilisateurs. Différents workflows sont disponibles et activable en un clic (ex. gestion du mot de passe oublié). Un outil à regarder qui se positionne en concurrent des solutions de type SAAS (Security as a Service) telles que Auth0. Encore un outil à regarder même si je n’ai encore jamais vu d’intégration simple de la sécurité dans les projets où je suis intervenu…

2ème jour

Les keynotes

Pour la première fois depuis le début de devoxx je suis un peu déçu par ces keynotes, une des principales raisons  je crois c’est que je deviens super exigent sachant que j’aime bien ça et que c’est pour moi le moment d’éveiller nos consciences de “Développeur”. Mais là je crois que la prise de risque sur le thème “Informatique et société” qui est une bonne chose, s’accompagne parfois de désillusions, voilà voilà. A noter le “#JamaisSansElle” qui nous demande à nous les hommes de faire un acte féministe, j’aime bien cette proposition.

Les conférences

Pourquoi Maurice ne doit surtout pas coder en go (Jean-Laurent de Morlhon). Pas d’attaque sur le prénom, mais une référence que j’avais pas sur la pub :

Ben oui go pousse le bouchon un peu loin (Rigidité des concepts, formatage, …), un retour d’expérience intéressant de quelqu’un qui a fait du go sur un produit où cette technologie est stratégique (Docker). Du coup ben go, c’est bien pour faire des petits serveurs plutôt orientés infrastructure que métier ou des CLI pour des apis REST. (JFrog a développé un client go pour ces dépôts bintray et artifactory).

Stack Overflow behind the scenes – how it’s made (Oded Coster). Tout le monde connaît Stack Overflow… mais comment s’est fait ? Peut-être beaucoup moins de mode. Tout d’abord des chiffres pour un seul jour (19 février 2016) chez Stack Overflow on a :

 Les chiffres…  L’infrastructure…
  • 209 420 973 requêtes reçues sur leurs Load-Balancers
  • 66 294 789 des requêtes sont des chargements de pages
  • 1,24 TB de trafic HTTP envoyé
  • 504 816 843 requêtes SQL (issues des requêtes HTTP)
  • 5 831 683 114 hits sur Redis
  • 17 158 874 recherches sur ElasticSearch
  • 3 661 134 requêtes sur le Tag Engine
  • 22,74 ms en moyenne pour le chargement des pages
  • 4 Microsoft SQL Servers
  • 11 IIS Web Servers
  • 2 Redis
  • 3 Tag Engine Servers
  • 3 Elastic Search
  • 4 HAProxy Load Balancers
  • 2 Networks
  • 2 Firewall
  • 4 Routers

Les langages mis en œuvres sont C#, ASP.NET/MVC principalement. Il s’agit d’une société non centralisée qui utilise les outils suivants pour travailler : GoogleDocs, Trello, Stack Chat et Google Hangouts, des Chat Bots pour les tâches de builds. Leurs outils de monitoring et d’alerting sont : OPServer, Grafana et Bosun.

La philosophie chez Stack Overflow est la recherche permanente de la performance au moyen de caches, de requête SQL optimisées. Un blog post pour aller plus en détail.

Intégration et déploiement en continu @ Github (Alain Hélaïli). Après Stack Overflow, nous voilà chez GitHub. Cela commence par une brève présentation de la société et sur comment les fondateurs de GitHub ont pivoté en voyant que l’outil qu’ils avaient développé pour leur besoin dans une philosophie de promotion de l’OpenSource est devenu plus rentable que leur projet industriel initial. La première caractéristique de GitHub est la répartition géographique de ses employés tout autour de la planète. Ils ne peuvent matériellement pas travailler ensemble de manière synchrone.

GitHub a mis en place le « continous deployment » et réalise plus 40 déploiements en production tous les jours. Ils n’ont pas les moyens de mettre en place des environnements de pré-production représentatifs des conditions opérationnelles. De ce fait, ils mettent en production et garantissent une très forte réactivité en cas de problème pour revenir en arrière ou pour fixer les éventuels problèmes. Leur répartition géographique leur permet de garantir ce service en H24 et 7 jours sur 7.

Pour réaliser 40 mises en productions par jour, ils ont mis en place le « GitHub Flow » qui est extrêmement simple. On ouvre une « feature branche » depuis « master » et on commence à travailler. Très rapidement (au bout de quelques commits) une « pull-request » est ouverte afin que l’équipe distribuée puisse échanger de manière asynchrone et persistante autour du code. Lorsque la feature est terminée, la « Pull-request » est mergée dans « master » et « that’s it ! ». On est très loin des workflows à la « Git Flow » et des pratiques telles que : je n’ouvre une Pull-Request qu’à la fin du développement de ma feature soit dans certain cas après plusieurs semaines de travail en mode sous-marin !

Leur meilleur employé est Hubot. Il s’agit d’un Bot permettant de réaliser des tâches de builds (y compris l’audit de code) et de déploiement de manière automatisé. Hubot est entièrement OpenSource et disponible sur GitHub.  Chez GitHub Hubot est couplé avec Slack mais la communauté a réalisé des connecteurs vers la majorité des outils de Chat de type Slack. Vraiment une très bonne présentation.

Container, VMs, Processes … Isolation, performances, I/O… (Quentin Adam). Bon déjà j’aime bien le speaker Quentin Adam, il faut aimer le gif animé, le troll et le ton un peu direct, moi j’aime. En plus il éclaire une grosse polémique sur Docker vis à vis de la virtualisation. Alors bien sur on peut disserter des heures sur ces sujets, il donne un bon aperçu du sujet en reprenant à la base des technologies linux derrière le “container”. C’est technique, on comprend bien les enjeux. Je retiens deux points en particulier :

  • Faire tourner des applications Docker de gens qui ne se connaissent pas sur le même serveur c’est le mal.
  • C’est quoi DevOps ?
    • Moi le “dev” je travaille avec les “ops” et donc on bosse dans des mondes de plus en plus proches (Infrastructure as code, Gestion de conf pour les artéfacts d’infrastructure), de manière de plus en plus synchrone (disponibilité des environnements de développements de staging et bien sur de production)
    • Moi le “dev” je fait le travaille des “ops” parcequ’ il est impossible de travailler avec eux (la verve de Quentin est un peu plus fleurie 🙂

J’aime beaucoup cette piqure de rappel sur DevOps et surtout dans cette vague d’adoption de Docker.
Moi le premier, la rapidité de mise en oeuvre et de prototypage de l’archictecture m’a parfois transformé en soit disant ops. Mais je n’en suis pas un, je croie que c’est cette notion de “Infrastructure as code” qui est l’essentiel et qui permet de rapprocher ces deux métiers.

Paris est résilient (Eric Horesnyi) : Une métaphore sur l’architecture traditionnelle et l’architecture logicielle REST. Comment Hausmann aurait pu inventer REST. J’ai bien aimé la présentation pour la réflexion sur qu’est ce qu’une architecture logicielle. Sujet au combien à la mode avec nos amis les micros services.

Get Hip with Jhipster (Matt Raible) : Matt Raible fait parti de ces orateurs qu’on va aussi regarder pour le show. Le nouveau Java Champion nous a régalé sur ce plan là. J’ai trouvé la présentation vraiment bien construite, elle m’a permise de me mettre rapidement à jour sur ce framework. Il fait parti des comitters Jhipster et en a laissé tomber son propre framework AppFuse en indiquant que Grails et JHipster sont plus efficace. Un super évangéliste en tout cas, bravo à lui pour son nouveau statut.

Modular monoliths (Simon Brown) : Un peu à contre courant de la vague microservices Simon Brown nous présente les enjeux de l’architecture pour éviter le “big ball of mud” plus connu en français sous la forme de “code spaghetti”. En particulier il pense que la mise en place des microservices risque de créer des “Distributed big balls of mud” ne rajoutant qu’une couche de complexité sur un software avec une forte complexité accidentelle comme on dit. Je suis assez fan de Simon et la présentation était vraiment clair, bien argumentée avec en particulier un petit tacle sur les tests, et en particulier les tests unitaires. C’est pas tout à fait mon point de vue, mais en tout cas le fait de proner pour l’efficacité des tests (rapport cout/valeur) me semble vraiment intéressant.

Il a quand même reussi à créer une polémique lorsque au détour d’un slide il a dit que l’architecture hexagonale était une architecture en couche.

En tout cas ses concepts d’alignement entre l’architecture et le code sont très intéressant et font pour moi écho à l’alignement entre le métier et le code (Ubiquitous language du Domain Driven  Design). Si on ajoute à ça la notion d’ “Infrastructure as code” on a vraiment la capacité à fédérer les équipes produits autour des différents axes du développement (Architecture, Métier, Code).

Et pour le dessert une petite gourmandise avec Entrer dans les entrailles de Git (Alexandre Garnier). Alexandre Garnier nous explique simplement les parties simples de la gestion de l’historique git dans le système de ficher.

Rancher, le (petit) orchestrateur Docker qui vous veut du bien (Christophe Furmaniak). Rancher est outil qui permet de gérer l’orchestration des conteneurs docker. C’est un concurrent de Mesos ou Kubernetes qui semble très simple d’accès. Il fourni une IHM Web ou bien une interface en mode ligne de commande. Une démonstration de montée de version a été réalisé suivant les 2 pratiques classique du « rolling upgrade » et « upgrade blue/green ». Dans la première les conteneurs sont mis à jour les uns après les autres en montant des conteneurs de secours pour garantir le maintient en condition opérationnelle de l’application. Dans la seconde, le déploiement de la nouvelle version est réalisé en parallèle de l’ancienne version et une fois la nouvelle version disponible il suffit de changer l’alias qui servait l’ancienne version pour le faire pointer vers la nouvelle.

3ème jour

Les Keynotes

Les soirées parisiennes commencent un peu à peser, du coup ben pas d’amphi bleu pour moi mais les écrans des salles overflow. J’ai préféré cette session même “télévisée” à celle de la veille. J’ai bien aimé l’explication sur la distance entre politique, justice et innovation numérique (Software development, responsibility and ethics: the coming crisis, Algorithmes, les nouveaux pouvoirs du développeur). J’aime bien quand on nous rappelle que nous les développeurs on peut influencer la transformation plutôt que de la subir. Si nous voulons être mieux considérer nous devons prendre en compte les devoirs que nous avons vis à vis de la société.

Dans cette session il y avait “Action publique et numérique”, et là l’état français nous a montré que même en retard sur les états unis (18f) ou l’angleterre (gov.uk) l’état pouvait aussi adopter une posture d’innovation. Alors je me dis que ben finalement les politiques viendront peut être à comprendre les enjeux si on utilise les outils qu’ils nous donnent pour leur montrer la valeur ajoutée. A suivre….

Les conférences

Baptême du feu avec Rx (Alexandre Victoor, Florent Le Gall) dont le but sera de manipuler pendant 3 heures, la librairie RxJava et RXJS (en TypeScript) dans le cadre d’un TP autour d’une application de type bancaire.

La préparation de Hands-on est exemplaire et les intervenants très disponibles et très clairs dans leurs explications. Ils ont découpé classiquement leurs Hands-on en 4 parties, la première consacrée à la présentation de l’API à mettre en œuvre dans la seconde, une pause facultative pour le repas et suivi d’une séance d’explications pour se terminer avec la dernière période de manipulation.

Maintenant que je suis du côté des participants, les 3 heures passent aussi vite sinon plus du côté des speakers. Les exercices sont très bien réalisés et très progressifs. Je les enchaine mais je ne parviendrai pas à tous les terminer faute de temps. Cependant, tout est disponible sur GitHub et sur des clés USB données gracieusement à l’ensemble des participants. Chapeau bas messieurs !

Gradle: Harder, Better, Stronger, Faster (Andres Almiray), une bonne présentation pour comprendre ce qu’amène gradle dans l’environnement des outils de build. Aujourd’hui c’est clairement mon outil de build préféré, Andres Almiray a su expliquer les qualités de gradle, sa simplicité, l’élégance de son modèle qui en fait le coeur de son extensibilité. Un peu de maven bashing au passage, mais il est clair que la concision de DSL groovy est pour moi l’un des grand plus de gradle par rapport à Maven.

Après je me suis fais une bonne session spring, j’avoue que pour moi vieux développeur java, jeune développeur js sur nodejs c’est un sujet particulièrement intéressant en ce moment. Et je dois dire que pour spring boot relance largement le débat. Les présentations que j’ai vu concernaient principalement la partie spring cloud (Exploring Spring Cloud Implementations (Spencer Gibb)) que je connaissais peu. Je suis bleuffé par la technologie, mais aussi par la simplicité de l’équipe spring et sa focalisation sur l’expérience utilisateur développeur (En particulier lors du BOF Spring). Après que dire du show man Josh Long dans The Bootiful Microservice (Josh Long), j’adore le live coding mais là c’est un maitre.

En me retournant vers mon vieux pote de promo j’ai pa pu retenir un “quand tu penses comment on devait faire dans le temps pour monter une architecture comme ça …” enfin bref c’est impressionnant. Alors bien sur le live coding passe sur plein de problématiques de configuration qui prennent un peu de temps mais quand même chapeau bas spring.

Et pour finir une belle présentations sur le DDD, DDD: et si on reprenait l’histoire par le bon bout ? (Thomas Pierrain, Jérémie Grodziski). Très bonne présentation j’ai découvert que j’étais pas le seul à avoir des grands moments de solitude pendant la lecture du “blue book” de Eric Evans. Ensuite ils ont bien dit que c’est pas facile à adopter, que c’est une belle boite à outil mais que ça change vraiment pas mal de chose sur le développement logiciel. Une excellente ininiative à mon sens #REBOOTDDD, la création d’une communauté pour aider à représenter, démystifier cette pratique de développement. Je vais voir si je peux aider.

Conclusion

Voilà c’est fini, c’était vraiment bien aller dans des conférences c’est faire un bon en avant dans plein de domaine. J’aime bien Devoxx FR france parce qu’il y a une vrai philosophie “Fièr(e) d’être développeur”. C’est notre métier, développer des logiciels, que dis-je des produits …. mais ceci est une autre histoire.

Tiens un truc qui m’a surpris, il y a pas mal de “vieux” comme moi dans ces conférences comme quoi c’est pas forcément nous les moins curieux … ou comme on me l’a dit c’est à nous qu’on paye ce genre de choses ….

Bref vivement la prochaine conférence et surtout merci Devoxx FR

Share Button

Olivier Bearn Author: Olivier Bearn

Artisan développeur, passionné d'architecture logicielle, je cherche à optimiser la communication au sein des équipes produits.

J'aime tester de nouvelles choses et transmettre mes connaissances.


#DDD #VALUE #DEV #DEVOPS #DELIVERY #TEST #AGILE

What do you think ?

One Comment

  1. Bonjour,

    Merci pour ce compte rendu très complet sur Devoxx !
    Vivement le 2017 😉

Leave a Reply

Required fields are marked *.


CommentLuv badge