DevLille 2025, le debrief du debrief

Les 12 et 13 juin, c’était DevLille à Lille Grand Palais. Édition particulière à bien des égards. Entre les bouleversements de notre métier, le marché tendu, je me demandais quelle ambiance y règnerait. Et franchement, l’une des meilleures éditions pour moi, l’une des plus humaines, paradoxalement, alors que le mot IA a été prononcé à chacune des conférences. J’ai vu pas mal de conférences, je ne vais pas revenir sur toutes, mais quelques messages à faire passer.

Les Keynotes

Première keynote par Typhaine D. Typhaine s’est définie comme comédienne, metteuse en scène, et féministe. Sa keynote était vraiment originale, usant d’une langue de son invention, la « féminine universelle », en féminisant tous les mots. Par ce biais, elle montre que la langue français d’aujourd’hui est le fruit de choix historiques, symboles d’une volonté d’oppression. L’approche était originale, et secoue.

La deuxième keynote, le vendredi, a été tenue par Julien Vidal. Julien, lui, se définit comme « Écologiste ». Il pose alors la question de ce qui nous vient en tête quand on pense à un écologiste. Dans l’assemblée, spontanément, on a entendu « anxiété », « contrainte »… Et pas grand chose d’enthousiasmant. C’est justement ce à quoi travaille quotidiennement Julien. Il est venu nous parler de son mouvement, les 2030 Glorieuses. Le but est de réfléchir à ce qui nous rendrait heureux, et de savoir comment lier ça aux limites planétaires, et d’arrêter de lier écologie à quelque chose de forcément négatif.

Ces deux keynotes n’avaient pas grand chose de technique, bien que les thématiques soient plutôt simples à raccrocher à notre quotidien de professionnels de la tech. Mais prendre 30min pour écouter des choses dont on n’a pas l’habitude, ça fait du bien, dans l’économie de l’attention que l’on connait bien. Alors merci de nous programmer (voir imposer) ces Keynotes. Cela demande du courage, je remercie l’équipe du Devlille et en particulier Fanny d’oser faire ça.

Les Confs

Comme tous les ans, le DevLille publie toutes les vidéos sur youtube, et ce en quelques jours. Suis admiratif du travail, bravo à l’équipe de captation ! Vous trouverez aussi les photos ici. Pour ma part j’ai assisté à une dizaine de conférences. J’avais à cœur de chercher un peu les tendances du moment et sans surprise, je n’ai pas assisté à une seule conférence sans que « Intelligence Artificielle » ne soit prononcé. Tout simplement bouleversant, bien éloigné de la simple hype.

La plus symptomatique de ce phénomène, c’est peut-être la conférence de Greg Lhotellier : « L’avenir des développeurs et des développeuses » (non publiée sur Youtube). Cette conférence, en plus d’avoir fait salle comble, a parfaitement reflété les inquiétudes du moment. Pour l’intervenant, on est passé d’un domaine en pénurie de professionnel.e.s, à un domaine saturé, et ça ne sera pas sans conséquence. Comment se démarquer? Par la spécialisation, le réseautage, et le dépassement de fonction. Au delà de la conférence, il y a eu pas mal d’échanges sur le temps des questions / réponses. Une question m’a interpellé, on a sous entendu qu’il serait peut-être temps pour la profession de se structurer un peu plus, et de se syndicaliser. Et pourquoi pas…

Deuxième conférence que j’ai apprécié, celle de Montaine Marteau, « La santé a-t-elle peur du cloud ?« . Montaine a une approche vraiment sympa, parlant du quotidien des praticiens hospitaliers et de la difficulté à recueillir de l’information exploitable pour la recherche scientifique. Que cela soit pour des questions de RGPD, du fait que les patients ne comprennent jamais vraiment ce qu’ils acceptent, du fait qu’il est très dur d’anonymiser des données médicales, et que dans tous les cas la normalisation des données reste un enfer. Si vous avez traité un jour des tableurs saisis par plusieurs personnes, avec des dates ou des unités, vous savez de quoi je parle, rien ne sera jamais écrit 2 fois de la même manière ! Bref, héberger, sécuriser, normaliser et exploiter les données médicales est un challenge métier et technique vraiment passionnant. Mon épouse faisant de la recherche dans un CHU, cette présentation m’a particulièrement parlé !

Dans les autres conférences, quelques félicitations pèle mêle…

• Aurélien Allienne qui a présenté « La GenAI au service du Retail« . Le retail, c’est le premier employeur de la région, et Aurélien nous projette dans toutes ces nouvelles fonctionnalités qui devraient envahir notre façon de faire pour la vente en ligne ou la gestion magasin.
• Olivier Wulveryck pour « Le Model Context Protocol : Les APIs du Futur pour le Développement d’Agents Autonomes« . MCP est devenu un standard en quelques mois, le protocole là pour étendre les possibilités de son LLM. Olivier est un speaker exceptionnel, et cette conférence a été plébiscitée. A ne pas rater.
• Audrey Wech pour « Développer une application mobile avec React Native : pourquoi Expo change la donne ?« . Sujet qui me touche particulièrement, puisque je l’ai vécu de l’intérieur. Audrey est développeuse chez Karnott. Du haut de ses jeunes années d’expérience, elle m’a convaincu de migrer notre application mobile de React Native à Expo. Puis, après être allé au bout de cette migration, elle s’est dit que faire un retour d’expérience avait de la valeur, et s’est donc inscrite au Ch’ti Tremplin 2025, où elle a été sélectionnée pour participer au Devlille (à juste titre, le rex est vraiment quali). Bref, bravo Audrey. 💪

La conf de debrief

Quand le CFP a ouvert, j’ai discuté avec l’équipe organisatrice de l’opportunité d’enregistrer un épisode de l’EstamiTech en clôture, pour débriefer de la conf, avec pour inspiration ce que peuvent faire les Cast Codeurs à chaque Devoxx France. Ils ont gentiment accepté, me proposant un des amphis… Mais plus l’événement approchait, et moins je me sentais à l’aise avec l’idée d’avoir uniquement quelques personnes sur scène donnant leur version du Devlille. Je voulais quelque chose de plus participatif avec le public. J’ai donc essayé de suivre une trame reprenant quelques unes de mes préoccupations actuelles, et j’ai demandé au public d’y répondre, à l’aide de Slido, et de plusieurs micros circulant dans la salle… En complément, Fanny a proposé au Ch’ti JUG de sponsoriser le moment avec quelques boissons, chose qu’ils ont tout de suite et gentiment accepté. Alors hop, petite ambiance estaminet…

1. Réflexe de Dev.e. Comment on trouve des réponses à nos blocages du quotidien ?
   
2. Comment on fait de la veille en 2025 ?
   
3. Qu’est ce qu’une bonne conf ? Avec la participations des gagnants du tremplin…
4. Vote pour sa conf préférée… Avec en top 3, en vote du public :
   • « Le Model Context Protocol : Les APIs du Futur pour le Développement d’Agents Autonomes » par Olivier Wulveryck dont je parle ci-dessus
   • « Code Case : les méthodes de la crim’ adaptées au code! » par Sylvain Coudert
   • « Le libre et l’open source » par Marie Dubremetz

Le Devlille est sur deux jours, termine le vendredi avec une dernière conf à 16h30, et il faut avouer qu’après 16h il n’y a déjà plus grand monde. Les stands sont démontés, et tout le monde part en week-end bien fatigué. Alors débriefer entre 17h30 et 18h30, ça aurait pu être un petit flop. Mais au final, on s’est retrouvé avec une petite centaine de personnes (102 d’après Slido), et dans une excellente ambiance (il faut dire que les ami.e.s étaient là, au soutien). L’exercice de la conf participative n’est pas simple. Il faut garder le rythme sur des sujets intéressants, et le plus dur : avoir une bonne gestion du temps, ne maitrisant pas trop le temps de chacune des interventions. J’ai trouvé ça bien plus dur qu’une simple conférence maitrisée de A à Z. En tout cas, tout le monde avait envie de participer, et je retiendrai que tous nos assistants IA ne tariront pas l’envie d’échanger entre techs. Je suis sorti de là rassuré sur l’avenir de notre métier… L’idée de faire un podcast ou une chaine DevTherapy en libre antenne a même germé. J’ai au final passé un excellent moment 🙂
Si vous souhaitez entendre nos débats, le replay est disponible ici

DevLille, à l’an prochain bien sûr.

L.B.

#ChTiJUG #Devlille #EstamiTech #JUG

[Commu du Nord] Le Ch’ti JUG

Nouvel épisode de Podcast L’EstamiTech !

Ma découverte des Meetups (qu’on n’appelait pas comme ça à l’époque) remonte à 2010 environ. A l’époque, on m’avait parlé du Java User Group (JUG) de Toulouse et j’y étais allé par curiosité. J’y ai découvert une multitude de personnes passionnées, toujours […]

#ChTiJUG #EstamiTech #Java #JUG #Podcast #ToulouseJUG

https://blog.bodul.fr/2024/07/19/commu-du-nord-le-chti-jug/

Ce soir, c’est session quickies avec trois talks assez rapides.

Kotlin pour le développement backend

Yassine va nous montrer l’intérêt de Kotlin pour le développement backend.

Kotlin ? Chez Github, le state of open source montre un intérêt croissant pour ce langage (presque à égalité avec Groovy). JetBrains montre aussi une augmentation de l’usage.

Quelles forces ? Multiplateforme, fullstack, très actif, et moderne dans son design.Pour le backend, vous pouvez faire du Spring ou Quarkus en Kotlin, mais vous pouvez aussi utiliser Ktor ou http4k, voire même compiler vers Javascript (donc développer dans Nodejs ou autre …​).

Quelles sont ses caractéristiques intéressantes ? Pour Yassine, le langage est concis. D’une façon intéressante, Yassine nous montre une classe simple …​ qui en java 21 est un record ! Pour rendre un champ immutable, on remplace var par val (un choix malavisé pour les développeurs à la vue vieilissante). Par ailleurs, les types Kotlin sont par défaut non nullables. Pour la compatibilité, on ajoute ? après le type et on peut utiliser la valeur avec un ?: (comme en Groovy). Il est également possible de créer des fonctions d’extension, qui viendront s’ajouter à la définition d’une classe existante. Ca permet par ailleurs de créer facilement des DSL (comme celui de Structurizr).

Comme la plupart des langages modernes, Kotlin fournit le support des coroutines. Et (comme Groovy), Kotlin est interopérable avec Java : on peut mélanger le code Java et Kotlin dans le même projet. Dans les évolutions récentes, il y a les collection literal (comme en Groovy). Yassine nous montre ensuite quelques exemples marrants. Restassured permet de créer des tests très agréables, avec une syntaxe given/when/then bien trouvée. On voit ensuite des exemples de code avec karibu, ktor, http4k, …​.Et finalement, le site officiel de Kotlin référence des exemples d’usage, souvent pour des nouveaux projets.

De l’injection de méthodes dans Spring à l’aide de Spring AOP

Fabrice a donc travaillé sur la refonte d’une Metadata API avec une approche contract first. Petite particularité : cette Metadata API utilise une base RDF, à laquelle l’application se connecte avec Sparql. Il va donc essayer de générer l’implémentation du contrôleur effectuant la requête Sparql au runtime (comme Spring data). Dans Spring, on peut utiliser un MethodReplacer, mais c’est utilisé, et incompatible avec le contrôle d’accès. On passe donc à Spring AOP. La programmation orientée aspect s’intéresse aux éléments transverses d’une application (comme par exemple les transactions) pour l’implémenter automatiquement dans tous les aspects. C’est implémenté dans Spring à travers la proxyfication fournie par cglib ou le proxy standard du JDK. Fabrice nous montre alors comment initialiser la configuration de Spring pour pouvoir ajouter des proxies par AOP. De mon moint de vue, c’est assez terrible. Conclusion ? Ca marche, mais la déclaration des pointcuts n’est pas très simple. Par ailleurs, il devrait être possible d’utiliser l’introspection pour mieux lier les requêtes http et sparql.

Onboarder dans une équipe en 5 minutes avec les devcontainers

(Rémi est un collègue)

Quand Rémi arrive dans une nouvelle équipe, il doit (comme tout le monde) configurer son environnement. Ca n’est pas toujours facile. Comment automatiser ça ? Rémi a vu Vagrant, Nix ou Gitpod.Et puis les DevContainers sont apparus.

Les devcontainers sont basées sur deux idées : créer des conteneurs Docker configurés à l’aide d’un fichier JSON. Ces conteneurs s’exécutent à distance et affichent leur résultat dans VSCode, intelliJ. Et Rémi nous montre le résultat dans un projet Java, dans lequel il n’a pas maven. Il existe un wizard dans VSCode pour créer le fichier JSON. Une fois la configuration terminée, Rémi relance VSCode en utilisant le devcontainer. Il a donc sur sa machine l’interface de VSCode, mais le code serveur s’exécute depuis le conteneur qui est démarré …​ quelque part.Et on peut aller plus loin. Dans un autre projet, Rémi a trois services qui doivent communiquer entre eux via des topics Kafka. Les développeurs ont déja un docker-compose.yml avec Kafka et akhq. Dans ce cas, DevContainer va créer un docker-copmpose.extend.yml important le précédent. Et le fichier de configuration json liera les deux docker-compose et ajoutera l’ensemble des propriétés de configuration.DevContainer est par ailleurs utilisé par GitHub Codespaces. Dans ce cas, VSCode est chargé dans le navigateur depuis les serveurs de GitHub. C’est un peu plus long.C’est plus long, mais tous les services sont facilement disponibles, et les interfaces d’administration peuvent même être redirigées pour être facilement visibles dans le navigateur.

https://riduidel.wordpress.com/2024/04/09/quickies-au-chtijug/

#chtijug #docker #kotlin #spring

Performance des threads virtuels

Question marrante du sponsor (Pürse) : est-ce que WebFlux sert encore à quelque chose (une question qu’on m’a déja posé par ailleurs) ? Et le sponsor a donc fait un test de performance avec du Spring Boot/PostgreSQL. Trois implémentations différentes ont été faites.

• Servlet/platform thread ⇒ 2.5 Krequêtes/sec
• Servlet/virtual thread ⇒ 4 Krequêtes/sec
• Reactor ⇒ 4.5 Krequêtes/sec

Et en fait, le plus important, c’est de tester dans votre contexte, les résultats seront peut-être différents chez vous.Le code est disponible sur GitHub

C’est parti pour la session Java 21! pic.twitter.com/HRRsmjdyYn

— Ch'ti JUG (@chtijug) November 14, 2023

Et c’est parti pour le show !

On va parler d’une partie de Java 21, parce que tout Java 21, ça fait trop pour une soirée.

Petit avertissement : Rémi peut dire des choses qui ne seront plus vraies … bientôt.

Simplification de l’onboarding

Java 21 fait en sorte que ce soit plus simple de commencer à coder :

void main() {     System.out.println("Java is cooler!");}

Bon, ce serait plus simple en Groovy, mais ça marche. Et Rémi fait la démonstration dans IntelliJ EAP. Et ça marche.

Comment ça marche ? Tout simplement parce que le compilateur rajoute une classe autour de la méthode main.

A noter que la méthode main() peut être static, mais ça n’est pas une obligation.

ASTUCE: En java, le premier paramètre d’une méthode peut s’appeler this, mais pas le deuxième, depuis Java 8.

Programmation orientée donnée

Si je déclare une interface MilitaryUnit implémentée par deux classes (ici, deux record, donc avec des getters écrits sans le get devant, à cause de sombres problèmes d’i18n), je vais avoir rapidement beaucoup de méthodes dans l’interface. En 2023, les objets ne sont plus forcément les éléments les plus importants. Ca paraît plus facile d’ajouter du code. Apparaît donc le … pattern matching ! Donc on peut faire des switch sur les objets qui rajoutent des valeurs. Comme son interface n’est pas scellée, le switch ne marche pas. Rémi rajoute donc le mot-clé sealed devant son nom d’interface …Et un permits avec la liste des classes autorisées.

QUESTION: Tout ça pour supprimer un default ? Oui, et pour faire en sorte que ça ne compile pas quand un pattern n’est pas géré.

Et Rémi se lance dans une justification de ce pattern en distinguant le code écrit dans les applications du code écrit dans les frameworks. Ca fait tout drôle d’avoir un langage distinguant le contexte dans lequel est écrit le code …

Si on ajoute une nouvelle implémentation, il faut d’abord l’ajouter dans la clause permits, puis l’ajouter dans chaque switch où cette classe est utilisée. On est vraiment dans une réimplémentation des visiteurs sous un autre nom.

Ca peut être une très bonne idée … Ou une sacrée difficulté.

Est-ce qu’on peut aller plus loin et faire en sorte que ça plante quand la liste des champs donnée our un objet n’est pas la bonne ? En un mot, oui. Parce quand on va déstructurer les données (en écrivant par exemple case Soldier(String name, int firepower) → …), le compilateur enverra une erreur si la liste des champs déstructurés n’est pas la liste des champs déclarés. Si le type d’un champ est inutile, on peut le remplacer par var. Et si le nom d’un champ est inutile, on peut mettre un <type> _. Voire même juste _ si ni le nom ni le type ne sont intéressants.

WARNING: Tout ça ne marche qu’avec les record, ce qui est compatible avec le fait que les records soient fondamentalement conçus pour stocker de la donnée.

Pour en revenir à notre record pattern (c’est le nom savant de ce case), on peut aussi restreindre les clauses avec case Soldier(_, int firepower) when firepower>100 → firepower*2. Mais dans ce cas, il faudra ajouter le cas alternatif (ou un default, mais Rémi recommande fortement de ne pas mettre de default dans ce genre de cas).

Je me rends compte, avec l’explication complémentaire de Rémi, que ce data oriented programming est en fait un sacré changement de paradigme. Le code que j’écris va commencer à avoir l’air bien daté.

String template processor

Rémi nous montre une ligne de code qui ressemble à

STR."""   firepower? \{ firepower(my_unit)}"""

Ca n’existait pas pour l’instant en java parce que le gros problème de l’interpolation de chaîne, c’est l’échappement des caractères. Donc Java va disposer de templates processors pour différents types de textes.

Bon, la syntaxe est très bizarre : STR n’est pas importé dans la classe, la chaîne n’est pas entre parenthèse, et \{ ne ressemble à rien. Malheureusement, ${ était déja utilisé par des tonnes de bibliothèques. Il fallait donc un caractère invalide dans une chaîne de caractère, et qui ne soit pas utilisé. D’où \{.

A côté de STR, on a également FMT qui permet de formatter comme printf (mais qui doit être importé). D’un point de vue performance, STR est aussi rapide que la compilation de chaîne de caractère avec +. FMT est beaucoup plus rapide que String.valueOf(…)

Evidement, on peut écrire son propre template processor. Mais je vous passe les détails … Pour l’instant, ça n’est pas rapide, mais ça va venir. Essentiellement parce que le compilateur reconnaît les appels à FMT ou à STR, et pas ceux à votre propre template processor.

Sequenced collections

Pour Rémi, chaque personne qui prend la responsabilité des collections a l’envie d’ajouter sa propre interface (par exemple NavigableSet ajouté en Java 6, que je n’ai jamais utilisé).

En Java 21, on a donc Collection#getFirst() et Collection#getLast(). On a aussi Collection#reversed() qui retourne une vue à l’envers de la collection initiale. On a aussi les interfaces associées : SequencedCollection, SequencedSet et SequencedMap.

Virtual threads

C’est la grosse fonctionnalité de Java 21. On en a parlé dès l’apparition de go. Petit problème des virtual threads : il a fallu reprendre tous les appels bloquants et les rendre non bloquants. Il a donc fallu réécrire java.io (un sacré travail).

Depuis les années 90, les locks entre thread sont gérés par l’application, alors que les threads sont gérés par l’OS. En Java 21, les threads sont gérés par l’application. De ce fait, le code est écrit de façon synchrone, mais exécuté de façon asynchrone. On peut ainsi créer des millions de thread avec peu de threads système. Et ce sont des threads beaucoup plus légers.

Comment ça marche ? Les threads virtuels vont tourner sur des threads de l’OS … sauf quand un appel bloquant au système est fait. A ce moment-là, le thread virtuel est mis de côté, et le thread système est libre pour une autre exécution. Quand l’appel système est fini, on reprend la première frame de notre thread virtuel qu’on remet sur le thread système, et l’exécution reprend.Pour créer un thread virtuel, on peut utiliser le Executors.newVirtualThreadPerTaskExecutor().

NOTE: C’est moins cher de créer un nouveau thread virtuel que de le recycler. Donc il n’y a pas de pools de threads virtuels.

Est-ce qu’on peut utiliser les threads virtuels ? Oui dans Spring 6, Helidon 4, Quarkus 3.5, Micronaut 4 (bientôt), oui dans Tomcat 10.1 et Jetty 12, mais non dans Netty. Parce que Netty fait des appels vers du code natif … ce qui n’est pas compatible avec les threads virtuels.

NOTE: Ca pose aussi des gros problèmes avec les blocs synchronized, parce qu’ils sont implémentés grâce à un pointeur sur la pile …Bon, c’est un problème pour les hautes performances, parce que ça veut simplement dire que le thread virtuel ne pourra pas être retiré du thread physique. Donc la performance ne sera limitée que pour ce thread là.

Platform integrity

Les modules de Java 9 (qui m’énervent beaucoup par ailleurs) ont permis de coder rapidement les threads virtuels, parce que loom avait besoin de l’introspection, qui a pu être réécrite parce que les modules interdisent l’accès à l’intérieur de l’introspection.

Les agents dynamiques posent certains problèmes (en changeant le code pendant l’exécution). Ca risque bientôt d’être interdit, ce qui impliquera de passer forcément les agents dans la ligne de commande.Dans le même ordre d’idée, JNI va être de plus en plus limité, justement parce que le code natif limite fortement les threads virtuels. Par ailleurs, JNI sera remplacé par une nouvelle API.

Conclusion

Dans tout ce qui a été montré, la partie qui va le plus changer la vie des développeurs applicatifs est sans doute le data oriented programming, qui renverse un paradigme vieux de 20 ans, et qui fait franchement ressembler le code Java à du code Rust. Et c’est intéressant de voir comment les record permettent d’injecter un ensemble de nouveautés dans le langage Java.

Toutefois, mon âme de vieux grincheux commence à se dire que quand on veut faire d’une carpe un lapin, c’est difficile d’enlever les écailles. Autrement dit, Java, qui ressemble déja à une espèce d’hybride, s’hybride encore plus. Et cette tentation d’être le langage de programmation en reprenant des fonctionnalités de toute part en fait de plus en plus un frankenlangage.

https://riduidel.wordpress.com/2023/11/15/java-21-va-mettre-des-paillettes-dans-ta-vie/

#évolution #chtijug #java #langage

Ce matin je me suis amusé à lister les prénoms des speakers de la #chtijug sur les 2 dernières années, et vous a savez quoi? Il y a plus de conférenciers qui s'appellent #Ludovic que de conférencières!
C'est étonnant non?
Voyez ce tableau:
https://cloud.fripost.org/s/C6JAT3Zob3dtpXf
A la communauté #Java de #Lille ca révèle un gros problème là: votre démographie a un biais contre les femmes et les personnes aux prénoms à consonnances étrangères. Que répondez-vous à cela? #JUG