RivieraDev 2024 : We were here

Kosmik - Jul 11 - - Dev Community

Départ 8h28 de Bordeaux, arrivée 17h30 à Antibes.

Vue de la verrière de la gare de Bordeaux Saint-Jean

En plus de nous laisser tout le temps de répéter une dernière fois nos talks, le choix du train nous laisse tout le temps d'admirer les très beaux paysages qui relient le sud-ouest au sud-est de la France.

Nous sommes quand même très heureux d'arriver après un peu plus de 9h de trajet (en comptant le dernier pit-stop jusqu'au lieu de la conférence) à notre hôtel, pour repartir immédiatement au repas des speakers… sur la plage ! L'accueil était vraiment aux petits oignons, c'est le cas de le dire aux vues des spécialités culinaires niçoises. Commençons donc par un très grand merci aux organisateurs qui font un travail de dingue toute l'année, bénévolement, pour rendre possible cet événement.

La plage

Pour rappel, RivieraDev c'est 700 participants, 50 conférences, 30 ateliers, 95 speakers, et une des plus impressionnantes concentration de Java Champion français : KatiaAresti, Emmanuel Bernard, Sébastien Blanc, Jean-Michel Doudoux, Guillaume Laforge.

Evidemment entre nos conférences et les tracks en parallèles nous n'avons pas eu le temps d'aller voir toutes les conférences et c'est donc en totale impartialité qu'avec Damien et Ivan on vous propose notre sélection spéciale.

Quarkus et Infinispan : Multiples solutions, un duo gagnant par Katia Aresti.

La première partie de la conférence est abordée sous le prisme des cinq caractéristiques importantes d'une application du point de vue :

  • des utilisateurs
  • des dev et ops qui la développent et déploient
  • de l'entreprise qui la finance

Pour chacune des caractéristiques qui se recoupent, comme par exemple, la performance, fiabilité, maintenabilité, scalabilité, etc., Katia nous explique comment Infinispan répond à ces besoins.

On apprend qu'il est déjà utilisé dans divers scénarios tels que le mode cluster de JBoss, le caching et la réplication multi-site de Keycloak ou encore Camel. Il s'intègre très bien avec Quarkus et Spring Boot.

Il peut être déployé comme un cache volatile ou stockage persistant.

Elle enchaîne ensuite sur trois démonstrations qui illustrent les cas d'utilisation suivants :

  • cache de données, avec interface permettant de visualiser le contenu et invalider les caches
  • hot replacement de redis car Infinispan implémente une grande partie des commandes du protocole Redis (RESP)
  • déploiement multi cluster avec mis en place d'un backup de cache

Une masterclass bien construite et très intéressante pour découvrir Infinispan et ses possibilités. Le tout bien rythmé et avec beaucoup d'humour.

Développer des macros en Rust par Logan Mauzaize

Rust est sans doute le langage du moment. Performant, riche et relativement haut niveau, c'est la coqueluche des développeurs backend. Logan nous a proposé une introduction à la métaprogrammation avec la rédaction de macros.

Grâce à l'ajout d'une librairie ad hoc, il est possible -et presque facile- de créer sa macro en quelques lignes de code. À travers la manipulation du flux de token pre-AST, on apprend ainsi à ajouter des fonctionnalités à notre code à la compilation, tout en bénéficiant de la puissance du Rust.

La conférence et les démos sont disponibles en intégralité sur le dépôt de Logan, ce qui permettra aux plus courageux de se lancer dans le monde passionnant des macros Rust.

The art of Java language pattern matching par Simon Ritter

Dire que Simon Ritter est un spécialiste de l'écosystème Java est un euphémisme. Ingénieur chez Sun dès la fin des années 90, il est un témoin privilégié de l'évolution des fonctionnalités du langage.
Au cours d'un talk dynamique, il nous a présenté les évolutions du pattern matching à travers les différentes JDK Enhancement Proposals (JEPs) :

  • Pattern matching for instanceof (JEP 433)
  • Pattern matching for switch (JEP 441)
  • Record patterns (JEP 440)
  • Unnamed patterns and variables (JEP 456) - Primitive types in patterns, instanceof and switch (JEP 455)

Cette conférence est un incontournable pour tout développeur Java soucieux de mettre à profit les dernières technologies du langage et rédiger le plus impeccable des control flow !
https://www.youtube.com/watch?v=u1TonLmxz1E

🔎 Anatomie d’une d’architecture Event driven & CQRS » par Paul Le Guillou et Sébastien Keller

Paul et Sébastien viennent nous narrer l'histoire d'une migration, de plus en plus courante et à la mode : "Et si on passait d'un monolithe à du microservice !".
Ils nous emmènent par la main, sur ce chemin semé de buches (dédicace à la star de la vie 🕶️) :

  1. Le monolithe distribué : Remplaçons nos appels de méthodes en mémoire, par des appels HTTP.
  2. Le découplage au moyen d'un bus de message et le début d'une toute nouvelle classe de problématique: la consistance.

Ils nous font donc un bon rappel des différents niveaux existants : at most once, at least once, indempotency, avec de bons rappels des patterns disponibles pour répondre à chaque niveau mis en place pour y répondre, et notamment le plus connu, le outbox pattern.

Ils en profitent également pour nous montrer des cas d'utilisation de kafka stream et kafka connect.

Un bon rappel si on a déjà abordé le sujet et une bonne introduction si on est un béotien sur le sujet.

Pulumi : Gérer son infrastructure avec son langage de programmation préféré par Julien Briault

Après un rapide rappel sur les différentes solutions existantes qui permettent de faire de l'IAC (Infrastructure As Code), Julien nous raconte l'histoire de la création de Pulumi.

TL;DR;: après avoir appris des erreurs des autres, Pulumi fait mieux!

Il nous présente son éco-système, le confort de travailler de l'infra as code avec son langage de programmation préféré. Pulumi marque également sa différence par sa capacité d'abstraction de la complexité, un peu comme celle qu'on pourrait trouver via les Custom resource definition dans Kubernetes.

Ça donne envie de s'y mettre.

La conférence à Mixit.

Ecrit à 6 mains avec les géniaux

dlucasd image

dlucasd

et
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .