Cette semaine, c’est Devoxx France. Et pour la première fois depuis pas mal de temps, je sors de chez moi, et j’y vais !

Je vous écris ces mots dans le train de retour de la deuxième journée, pas de troisième pour moi cette année. J’ai assisté à quelques talks, j’ai pris des notes à certains, et pas à d’autre.

J’ai aussi donné un talk : Créer une extension Quarkus, le replay devrait être disponible dans quelque temps.

Devoxx fut surtout l’occasion d’échanger avec plein de monde : des collègues nantais, des membres de la communauté Quarkus avec qui je pouvais enfin échanger « en vrai », et plein d’autres personnes croisées sur des stands, dans des conf, ou dans la salle des speakers. Pour moi c’est ça l’âme de Devoxx : les échanges !

Pour ceux qui seraient intéressé, voici les talks auxquels j’ai assisté, et les notes que j’ai prises, quand j’en ai prises.

Microservices réactifs avec Quarkus – Clément ESCOFFIER et Stéphane ÉPARDAUD

Ma première conférence à Devoxx FR est l’université Quarkus, connaissant les deux speakers j’ai décidé d’y aller même si je connais déjà bien le sujet ;). On ne sait jamais, c’est toujours possible d’apprendre de nouvelles choses ;).
On commence par une présentation classique de Quarkus, il faut avouer que comme je la connais par cœur, je n’ai pas vraiment écouté, mais les speakers étant de qualité c’est toujours agréable à suivre, même de loin.

Quarkus est une pile pour construire des systèmes distribués, donc pour gérer les I/O. Il est donc nécessaire de s’interfacer avec les primitives offertes par les OS. Principe : un petit nombre d’I/O threads gèrent les I/O, et toutes les extensions, ainsi que votre application, s’interfacent avec le cœur réactif. Aujourd’hui, au-dessus de son cœur réactif, Quarkus offre plus de 400 extensions depuis code.quarkus.io pour s’interfacer avec un grand nombre de technologies et frameworks Java existants.

Après une introduction de 30mn et une première démo Hello World un peu laborieuse 😉 (effet démo, ça arrive); présentation du cheese shop qui va nous guider pendant toute la session : un magasin de fromage en ligne utilisant RESTEasy (JAX-RS), Hibernate ORM with Panache (JPA), MicroProfile REST Client et Kafka. On entre ici dans le vif du sujet, chaque couche applicative, et chaque extension, nous est présentée. Nous commençons ici avec les implémentations « classiques » ou « impératives » de ces frameworks. Le code est non trivial, surtout pour la ressource REST, ce qui est inhabituel dans ce type de démo, au risque de perdre un peu les gens lors de la présentation de celle-ci. J’imagine que c’est nécessaire pour montrer la puissance des fonctionnalités réactives à disposition dans Quarkus.

Présentation de ce qu’est le réactif, et de pourquoi on est arrivé à ce besoin : problématique des systèmes distribués et de l’accroissement des usages. Le réactif est une manière de « mieux » faire les systèmes distribués en utilisant de l' »asynchronous message passing » au lieu d’un appel synchrone entre les différents composants. Offre élasticité et résilience.

Après une petite pause de 15mn, nous voici revenu pour parler réactif, réactif, et Mutiny! On commence par une petite session de question, à chaque question posée, un fromage gagné servit par Stéphane, le maître fromager. Et comme Stéphane donne autant de fromage qu’il en mange, il faut se dépêcher ;).

On va un peu plus en profondeur dans le fonctionnement réactif et non-bloquant, ça commence à parler signaling, flow control et reactive stream. Puis présentation de Mutiny, une API réactive facile à utiliser, navigable, qui ne nécessite pas un doctorat en informatique ou une spécialisation en programmation fonctionnel pour l’utiliser.
Mutiny expose deux types : Multi et Uni, via un modèle de souscription. Mutiny est structuré par groupe d’API pour faciliter sa découverte, et a une logique d’événement (onItem, onFailure, …). Et là j’ai appris un petit trick utile : il existe un opérateur log() à Mutiny qui va logguer chaque étape du pipeline d’opération.

On reprend ensuite la démo avec la migration pas à pas de l’application cheese store d’un modèle impératif vers un modèle réactif.

Première étape : passage à Resteasy réactive qui utilise l’API JAX-RS mais avec moins de boilerplate : annotation dédiée (@RestPath et autre), sérialisation JSON par défaut, @Context facultatif ,déclaration des filtres et exception mappers plus simple.

Au build, RESTEasy reactive va généré le bytecode pour appeler le endpoint avec ses filtres et son serializer : pas d’étapes superflues, pas de réflexion. Un intercepter pas utilisé ne sera pas appelé.

Puis, présentation de Hibernate réactive : Hibernate avec les drivers réactifs de Vert.x, une nouvelle api Session et Query, et qui utilise Mutiny.
Hibernate reactive utilise les annotations JPA, donc les entités ne sont pas à modifier.

Pour finir, présentation du reactive REST client.
Celui-ci permet de définir un client REST via une interface et les annotations JAX-RS, comme le client standard. Ceci a l’avantage de ne pas devoir manipuler la couche HTTP.
La version réactive présente une api basée sur Mutiny et utilise des I/O non bloquants.

Conclusion, question, et distribution de fromage !

Une université dense et menée haut la main par deux speakers de talents et que j’apprécie énormément 😉

Profiling et monitoring avec le JDK – Jean-Michel DOUDOUX

J’ai hésité longtemps sur quelle conférence aller voir avant mon passage à Devoxx. Un de mes collègues me dit toujours qu’il faut profiter des conférences pour aller voir des sujets en dehors de sa zone de connaissance, pour s’ouvrir l’horizon. Il a tout à fait raison, mais n’ayant jamais vu JM Doudoux, et beaucoup de gens m’en ayant parlé, je choisis quand même d’aller voir son talk.
N’ayant plus de batterie à ce moment, je n’ai pas pris beaucoup de note, mais le talk fut agréable, très instructif et très technique : comme je les aime quoi 😉

JM nous as rappelé l’historique de JFR et de JMC, puis il a parcouru l’ensemble des fonctionnalités de JFR, y compris la possibilité de créer ses propres événement et la toute nouvelle streaming API. Il a ensuite parlé de l’écosystème existant ou en cours de développement (sans parler de Quickperf qu’il ne semble pas connaitre, c’est un projet auquel je contribue de temps en temps et qui a aussi une intégration avec JFR).

Pour finir, il nous a présenté JMC avec force screenshot et explications.

J’ai dû partir avant la fin pour me préparer (mentalement) pour mon propre talk.

Créer une extension Quarkus – Loïc MATHIEU

Vote serviteur au micro !

Après une courte introduction sur Quarkus et ses extensions, j’ai fait une démo pas à pas de la création d’une extension avec configuration, bean CDI, parcours de l’index de code, enregistrement de bean CDI, enregistrement d’information de reflection pour GraalVM, pour finir par de la génération de bytecode !

Ce fût dense, j’ai dû perdre quasiment tout le monde à la fin et, malgré le sujet très technique, j’ai eu pas mal de questions. Pourtant j’ai réussi à finir pile à l’heure, à la seconde, près pour éviter ça 😉

Parler à Devoxx est toujours une expérience et un challenge, même un tools in action dans une petite salle est un accomplissement ! Après tout, c’est la plus grande conférence de développeur de France !

Cela faisait aussi près de 2 ans que je n’avais pas pris le train, ni le métro, ni fait un talk en présentiel ! Et c’est comme le vélo, ça ne s’oublie pas. Bien sûr, il y a le trac qui est bien plus présent en présentiel qu’en remote. Mais une fois lancé dans ma présentation et ma démo, tout coulle sans soucis.

Bon, je ne suis pas super content de ma prestation, je n’ai pas fait assez de répétition. Je trouve que l’introduction était trop longue ,et la démo manquait un peu de « fil rouge », et n’a pas dû être facile à suivre. Si je dois redonner ce talk, il faudra que je le retravaille.

Benchmark HTTP grandeur nature – Julien VIET

Julien va nous parler du Techempower benchmark, de la position de Vert.x dans celui-ci et de comment ce benchmark a fait réfléchir la communauté Vert.x sur ses performances et le travail qui a été effectué pour les améliorer.

Techempower : ensemble de benchmarks HTTP des frameworks / plateformes depuis 2013. C’est un benchmark opensource disponible sous github. Plus de 400 frameworks dans 26 langages. Attention certains frameworks ont été écrit spécifiquement pour le benchmark, et ne sont pas réellement utilisable en condition réelle. Des runs du benchmark sont fait tout les 5 jours automatiquement.

En 2013, Vert.x est premier dans le benchmark PLAINTEXT, en 2017, il passe à la place 14 car Vert.x n’a pas tenu compte de l’évolution du benchmark et des compétiteurs. Vert.x est beaucoup plus loin que Netty sur lequel il se base.

Questionnement : est-ce que Vert.x a perdu en performance ou est-ce que le benchmark est mauvais.
Utilisation d’outils pour analyser ses performances : async-profier, perf/dtrace, JMC/JFR et analyse des logs du Just In Time compiler (JIT).

Explication du scénario du benchmark PLAINTEXT: Hello World avec HTTP pipelinning et un nombre de connexion important.

• Optim 1 : Vert.x flush sur l’OS les requêtes une par une, même si avec le pipelinning HTTP, il les reçoit 16 par 16. Analyse d’un flamegraph : 46% du CPU en appel système. Implémentation d’un flush par buffer, donc un toutes les 16 requêtes du pipelinning : on voit alors que le temps CPU OS tombe.
• Optim 2 : Garder ses méthodes petites pour faciliter l’inlining du JIT. Suite à une modification dans le traitement des erreurs, une méthode du hot path n’est plus inlinée induisant une pénalité de 3% ! Détecté avec perf, car il colore différemment les méthodes inlinées et celles qui ne le sont pas.
• Optim 3 : une capturing lambda existait avec une implémentation sans utilisation du paramètre. Une capturing lambda est instanciée à chaque appel, alors qu’une lambda non-capturing ne l’est qu’une fois. En ajoutant une méthode permettant de passer une lambda sans paramètre on a encore gagné quelques %.

Au lancement suivant, le 15, les performances de Vert.x arrivent dorénavant juste après celles de Netty. Donc au maximum de ce qu’elles peuvent être.

Benchmark BDD : mauvais résultat car erreur dans l’implémentation du benchmark : exemple, manque d’index sur Mongo.

Après correction du benchmark, l’idée est venue d’implémenter du pipelining pour les requêtes Postgres dans le reactive client : marche très bien pour des requêtes très petite. Suite à ça, passage #1 sur le benchmark BDD ! La plupart des concurrent implémenté en Java qui ont de très bonne performances utilisent le client reactive de Vert.x suite à ça 😉

Explication amusante sur une discussion sur la mailing liste de techempower sur la méthode de pipelining de requête BDD : autorisé ou pas ?

Conclusion : les protocoles JDBC ont été créés il y a 30 ans, et ne sont plus à jour avec les besoins actuels : analogies : sont resté à l’état de HTTP 1 car ne supportent pas le multiplexage comme le font la plupart des BDD NoSQL. Protocol matters !

Full-remote : comment réussir à travailler en équipe ? – Lise QUESNEL

Lise, collègue nantaise, nous parle de son expérience de full-remote dans une équipe mixte présentielle / distancielle. Sujet très intéressant et bien présenté par Lise.

Je n’ai pas pris de note, mais voilà ce que j’en ai retiré.

Le plus important est la confiance et la communication, l’un allant pas sans l’autre, c’est la communication qui créé la confiance. Elle introduit ensuite la pyramide de la communication allant du texte à la discussion en présentiel, en expliquant que chaque étage amène du contexte et facilite la communication.

Elle a ensuite présenté les outils et les processus à mettre en place pour communiquer efficacement (slack, visio, board, …). Le plus important étant de communiquer souvent, en utilisant les outils visio pour les choses importante, et en ayant des rituels comme le bonjour ou le au revoir le matin et le soir sur slack.

C’était intéressant car ça a fait écho avec comment l’équipe dans laquelle je suis à communiqué pendant la pandémie, et continue encore de le faire, deux de ses membres étant en full remote.

Les Méthodes Synthétiques Rêvent-elles à des Switch Expressions Électriques ? – José PAUMARD et Remi FORAX

Suivant de près les nouveautés du langage Java, via entre autre les listes de diffusion amber et core-lib-dev, je ne m’attends pas à apprendre beaucoup de choses, mais je ne peux m’empêcher d’aller à l’université sur les nouveautés du langage Java, rien que pour le plaisir de voir ces deux speakers de renom.

Là encore, je n’ai pris aucune note, donc je ne vais pas en parler beaucoup, mais le duo est assez entraînant et la présentation via du code est assez sympa.

Dans la première partie de l’université, José parcours un ensemble de nouveautés du langage, et Rémi commente (ou parfois corrige) au fur et à mesure avec pas mal d’informations sur comment ça marche et pourquoi ça a été implémenté de cette manière. Avec parfois quelques anecdote marrantes et toujours un ton très libre.

J’ai séché la deuxième partie pour papoter 😉

Cryptographie, hachage, chiffrement sans les maths ! – Cedric GATAY

Denier talk auquel j’ai assisté. Cédric nous parle algorithme de cryptographie, en les replaçant dans leurs histoires. C’est un parcours didactique qui commence au code de César, et qui fini par les toutes dernières classes d’algorithme utilisées dans TLS 1.3.

Je n’ai pas pris de note (oui, j’ai été pas mal fainéant cette année), mais comme j’ai tout compris à ce sujet assez complexe, on peut dire que le sujet a été très bien expliqué, et pourtant j’ai appris pas mal de nouvelles choses car il a été en profondeur sur certains sujets.

Un très bon talk.

Conclusion

Pas de troisième jour Devoxx pour moi cette année, passons donc à la conclusion.

Devoxx, pour moi, c’est avant tout la possibilité de croiser pleins de gens, d’échanger et de se retrouver. J’ai eu le plaisir de croiser des collègues parisien et nantais, des contributeurs Quarkus avec lesquels je contribue régulièrement. Et de voir « en vrai » des gens que je n’avais vu que via une caméra et un écran !