Il y a deux semaines, une bonne partie de la team nantaise a participé au DevFest de Nantes. Pour l’occasion, les participants ont pris du temps pour revenir sur les conférences qui les ont le plus marqués. On laisse la parole à quelques-uns d’entre eux pour en parler :

• Retour de Hamza Ben Yahia :

De mon côté, j’ai beaucoup apprécié participer à trois conférences en particulier.

“Core Web Vitals : Mettez votre application sur orbite avec les meilleures pratiques” par Nicolas FRIZZARIN :

Il s’agissait d’une présentation générale des trois nouveaux signaux introduits par Google dans ses outils de performance et de métriques. Ces signaux permettent aux développeurs de mesurer la performance des applications web en attribuant des scores à différents aspects de l’application. Le speaker nous a montré comment interpréter les résultats de ces signaux et comment améliorer les points faibles identifiés.

Dans l’ensemble, le talk était plutôt bon. Une seule remarque que je peux faire concerne la démo, où Nicolas a choisi de nous montrer les analyses de ces signaux sur une application simple et bien développée. Les résultats n’étaient pas nécessairement explicites. Je pense que la démonstration aurait été plus pertinente si l’application choisie avait été de moindre qualité.

“Au secours, j’ai une personne handicapée dans mon équipe” par Emmanuelle ABOAF :

Le meilleur talk auquel j’ai assisté lors de la deuxième journée du DevFest portait sur la sensibilisation à l’intégration des personnes handicapées dans le milieu de travail. La speaker a débuté en nous présentant quelques stats sur le handicap en France, telles que le pourcentage des différents types de handicaps, le taux de chômage par rapport aux personnes non handicapées, etc. Ensuite, elle a abordé les moyens que l’on peut mettre en place pour faciliter l’intégration des personnes handicapées au sein des entreprises et des équipes.

Kudos to Emmanuelle pour son courage, sa bravoure et sa positivité. Elle a su rester forte face à certains commentaires que personne n’est censé entendre, qu’elle a reçu en raison de son handicap au cours de sa carrière professionnelle. Je profite de cette occasion pour partager son message : « N’ayez pas peur du handicap. Embauchez-nous. Formez-nous. Apprenez à nous connaître. Travaillez avec nous. »

“Je ne suis pas passionné(e) et alors ?!” par Helvira GOMA :

Helvira a réussi à impliquer son public lors de sa présentation, même si le sujet est complexe et difficile à cerner, surtout en ce qui concerne la définition de quelque chose d’aussi relatif que la passion (et non le fruit, comme Helvira l’a mentionné).

Parmi les points intéressants soulevés au cours de son talk, en s’appuyant sur des études il est apparu que la passion peut parfois avoir des conséquences négatives sur un développeur. En effet, il peut se retrouver à travailler davantage pour une rémunération toujours modeste, en justifiant cela par la satisfaction de vivre sa passion. Aussi, cela peut également être négatif à l’employeur car il risque de se retrouver avec un développeur épuisé, toujours en train de travailler, y compris les soirs et les week-ends.

En résumé, selon Helvira, que l’on soit passionné ou non, l’essentiel est de prendre du plaisir dans ce que l’on fait, de ressentir cette satisfaction qui vient de la résolution d’un bug après des heures de debug ou du sentiment d’accomplissement lorsqu’une tâche longue est enfin terminée.

J’ai aussi fait une quickie sous le nom « Comment les interfaces nous manipulent” par Flora Brochier mais j’étais un peu déçu du contenu malheureusement, la speaker nous a présenté (presque pendant toute la durée de sa présentation) les éléments des pages Amazon et comment ils nous influencent (je crois que tout le monde le sais déjà).

• Retour de Daniel Ahmed :

“Programmation Concurrent et Asynchrone : le point en Java 21” par José Paumard :

La présentation de José Paumard porte sur l’introduction des Virtual Threads dans Java 21. Elle met en évidence les différences entre les Virtual Threads et la programmation concurrente et asynchrone actuelle. L’accent est mis sur l’amélioration de la gestion des threads grâce à cette nouvelle fonctionnalité.

Un point clé est la capacité à créer un nombre considérable de Virtual Threads, jusqu’à 1 million, sur une machine standard par opposition aux problèmes de performance rencontrés avec un grand nombre de threads dans les versions précédentes de Java.

La présentation souligne également l’importance d’utiliser du code bloquant avec les Virtual Threads pour maintenir de bonnes performances. En d’autres termes, les Virtual Threads sont conçus pour gérer efficacement des opérations d’entrée/sortie et des blocages dans le code.

“Expand your view of your application performance with OpenTelemetry” par Damien Raude-Morvan : 

J’ai initialement hésité à assister à la présentation de Damien Raude-Morvan mais je n’ai finalement aucun regret d’y avoir participé. Mon travail porte sur des microservices et je me suis toujours demandé quelle approche serait la plus efficace pour déboguer nos applications. Jusqu’à présent, nous utilisions un système de « corrélation ID » pour essayer de suivre les données entre nos différents microservices.

Avec l’avènement des architectures microservices, le débogage devient plus difficile. La complexité de cette architecture nécessite des outils spécifiques pour collecter et analyser les données d’observabilité de manière cohérente.

C’est là qu’intervient OpenTelemetry, un framework d’observabilité présenté par Damien Raude-Morvan, Staff Engineer chez Decathlon Digital. OpenTelemetry permet une collecte homogène des données générées par les différentes applications, simplifiant ainsi la surveillance, la corrélation des données, et la résolution des problèmes dans un environnement microservices.

• Le retour de Pierre Bozon :

L’une des conférences que j’ai le plus appréciée était sur le thème « Mais au fait, que se passe-t-il quand je mets en ligne une vidéo ? » mené par Antoine Wacheux. Dans cette conférence, Antoine Wacheux, Solution Architect chez AWS et passionné d’IT avant tout, nous a présenté certaines grandes étapes de la mise en ligne d’une vidéo.

En réalité, nous sommes partis à plus haut niveau en parlant de la composante même d’une vidéo, c’est-à-dire une suite d’images fixes défilant au rythme de 25 par seconde pour tromper notre cerveau dans une hallucination de mouvement virtuel (les frères Lumière seraient fiers !).

Oui mais voilà, chaque pixel d’une image porte l’information des 3 couleurs primaires (Rouge, Vert, Bleu, ça rappelle nos meilleures heures d’art plastique) et une image haute définition est composée de 1920 ‘fois’ 1080 pixels. Sachant qu’il en faut 25 par seconde, on atteint très vite plusieurs TeraBytes de données pour une heure de vidéo (la valeur exacte est donnée dans la conférence). Bien plus que ne pourrait supporter la meilleure des fibres optiques en plein Paris. Alors il va falloir être malin. Et Antoine nous a expliqué comment être malin ou plutôt à quel point les ingénieurs qui nous ont précédés ont déjà été d’une ingéniosité mathématique rare pour optimiser l’encodage d’une vidéo et nous permettre de regarder des vidéos de petits chats mignons même au fin fond du Cantal avec une connexion 3g hasardeuse (parce que les potits chats, c’est important !).

Ainsi on a appris à réduire drastiquement le poids d’une vidéo mais également à adapter le flux à la vitesse de connexion en temps réel (si vous passez dans un tunnel, votre potit chat risque de devenir tout pixelisé mais il continuera de chasser la malheureuse souris sans interruption). Malheureusement, à toute médaille son revers, à tout yin son yang, à tout Harry son Tom (un peu technique celle là), cette technologie sert également à insérer des publicités dans nos programmes préférés (les potits chats) donnant beaucoup de fil à retordre aux différentes solutions anti-spam du marché. Au jeu du chat et de la souris (vous l’avez ?), on se demande encore qui sera le plus malin.

• Le retour d’Abdelkebir Abbassi :

Comme chaque année, le DevFest prouve que l’IT est toujours au cœur du développement des écosystèmes. Avec plus de 3000 participants, 100 speakers et 71 conférences, j’ai pu assister durant la journée du 19 Octobre 2023 à certaines d’entre elles dont l’une qui portait sur la concurrence en Java et quelques nouveautés introduites avec le projet LOOM.

Problématiques :

• Les architectes du JDK ont toujours été préoccupés par la gestion de la concurrence en Java.
• Au début, on avait les threads classiques (Thread, Runnable, Synchronized blocs).
• Jdk 1.5 : introduction du framework Executor (package java.util.conccurent) pour invoquer/ordonnancer/lancer/contrôler les tâches asynchrones, on a aussi la notion des locks (verrous).
• Jdk 7 : ajout du framework fork/join (parallélisme)
• Jdk 8 : Classe CompletableFutute : ceci a permet de simplifier l’exécution des tâches asynchrones en veillant à la gestion des exceptions.

De la programmation impérative à la programmation réactive :

Les threads Java actuels où une tâche est affectée à un seul thread (appelés Threads plateform parce qu’ils se basent sur les threads de l’OS) passent leurs temps à être bloqués en attente d’opérations IO (ex : requête http et donc la carte réseau en attente d’entrées / sorties). La solution était de multiplier les threads et donc une fois qu’un thread est bloqué, c’est un autre qui prend le relais car il a besoin de ressources (CPU, mémoire…). MAIS le problème c’est qu’il n’est pas possible de multiplier le nombre de threads à l’infini…ça coûte très cher !

Avec la programmation réactive, on tend à maximiser l’utilisation des ressources, plus particulièrement le CPU. On va utiliser un pool de threads qui s’occupe de l’exécution d’une liste de tâches l’une après l’autre et, à l’inverse de ce qui se passe avant, quand une opération IO va être demandée par une tâche A, le thread n’est pas bloqué mais on désassocie juste la tâche A du thread (qui peut maintenant exécuter une autre tâche B) et on la rappelle (tâche A) une fois le résultat de l’opération IO est arrivé.

La programmation réactive présente aussi un inconvénient majeur dans ce cadre, les programmes existants doivent être réécris pour devenir asynchrones, c’est un changement radical de manière de programmer, le code devient plus difficile à lire, à tester et plus compliqué lors du débogage.

Exemple en asynchrone avec (CompletableFutute ) :

En débogage, la logique du traitement est éclatée en morceaux exécutés sur des threads différents, compliqué à déboguer par exemple la méthode findUserIdByName().

Bref, la programmation impérative est simple, mais utilise mal les ressources lors des opérations IO. La programmation réactive quant à elle, est bien adaptée à un haut niveau de concurrence MAIS présente l’inconvénient de la complexité et la nécessité de réécrire le code selon cette approche.

LOOM a vu le jour en 2017. Il s’agit d’un nouveau modèle d’exécution des threads : les Threads virtuels accompagnés d’un modèle de concurrence (Structured Concurency – JEP 453, Scoped Values – JEP 446).

Pourquoi ne pas écrire du code impératif pour qu’il s’exécute sans bloquer le thread principal, comme s’il est écrit en approche asynchrone avec des fonctions de callback ?

Un thread virtuel est un thread qui peut être associé / désaccosté du thread système principal (système), son principe est le suivant :

• Le thread virtuel a besoin d’une opération IO
• Il est mis en pause et détaché du thread système
• Le thread système devient libre et peut exécuter un autre thread virtuel
• Le résultat de l’opération IO arrive, le thread virtuel est rattaché à un thread système pour la suite de son exécution (mécanisme de callback géré par la JVM). Au niveau du code, c’est du code purement impératif et séquentiel est écrit.

Exemple du code précédent :

Et en débogage :

Conclusion :

• Le pattern Structured Concurrency est utilisé pour mieux gérer la multiplication des threads virtuels qui pourront être exécutés en parallèle de manière concurrente.
• Loom n’a jamais eu pour objectif de réaliser de gros gains de performance avec les threads virtuels (voir les rubriques non-goals des JEP 425 et 436)
• Il faudra découper l’exécution des threads existants en plus petites unités pouvant être exécutées de manière concurrente. Ce n’est qu’alors, en passant de milliers de threads plateforms à des millions de threads virtuels que des gains substantiels pourront être observés

Une question fréquemment posée à l’issue du talk : est-ce qu’un jour on parlera plus de Thread local (classe Thread) ?

=> Jamais, toutes ces fonctionnalités reposent sur la même fondation : les threads Java introduits dès 1995.

Quelques références concernant ce sujet :

• Présentation et live coding lors du Devoxx FR 2022 de José Paumard & Remi Forax sur Loom et la gestion des threads : Loom nous Protègera-t-il du Braquage Temporel ? (José Paumard, Remi Forax) – YouTube
• Virtual Threads: New Foundations for High-Scale Java Applications
• Java 20 sneak peek

• Et on termine sur quelques mots de Ladislas Bryla :

Comme l’année dernière, beaucoup de monde déambulant sur les différents stands. Des hotdogs, de la bière, des huîtres, des pizzas et j’en passe. C’est toujours un plaisir de voir les anciens collègues sur les stands et pendant les conférences. De bonnes conférences jeudi avec notamment le REX de la directrice graphique de la SGIB sur leur design system, mais aussi une présentation très animée de Chrome devtool. C’est toujours un plaisir d’assister au DevFest !

Pour retrouver le replay du DevFest, c’est par là que ça se passe : https://www.youtube.com/@GDGFrance