- Développement
- Université
- Standard
- 2h00
Atelier Micronaut : on code, on compare, on décortique
Date mercredi
Horaire 11h30 à 13h30
Salle Amphi A
Description
Envie de découvrir un framework qui démarre en un éclair, consomme trois fois rien et simplifie la vie des développeurs de microservices ? Bienvenue dans cet atelier 100% pratique consacré à Micronaut, le framework JVM pensé pour la performance, la modularité… et la sérénité en production. Pendant deux heures, nous construirons une application complète intégrant plusieurs interfaces : - une API REST, - une consommation/production Kafka, - une persistence via base de données, Nous plongerons ensuite dans la réalité du terrain : 👉 quelles difficultés rencontre‑t‑on lorsqu’on vient de frameworks plus classiques comme Spring ? 👉 pourquoi certaines habitudes ne fonctionnent pas ici ? 👉 quelles limitations et pièges faut‑il anticiper ? 👉 et surtout : en quoi les choix techniques de Micronaut changent‑ils la donne (performance, GraalVM, légèreté, prédictibilité…) ? Cet atelier s’adresse autant aux curieux qu’aux développeurs expérimentés souhaitant se faire un avis sur Micronaut… et si cela pourrait devenir un allié de choix dans leurs futures architectures. Venez les mains sur le clavier : on code, on teste, on compare, et on repart avec une application fonctionnelle et un regard neuf sur un framework qui gagne à être connu.
Orateur·ices
Guillaume Yan
Développeur Java depuis plus de 10ans, j'ai travaillé pour différents clients (OBS, Page Jaunes, Yves Rocher, Ouest France, SFR...). Certifié Spring depuis 2019, je continue de travailler sur ces technos depuis mes débuts
Actions rapides
Les sessions futures sur le même thème
- Développement
- Université
Rendez vos tests Spring Boot rapides,robustes et maintenables
Si Spring Boot propose un arsenal d'outils complet pour tester nos applications, il n'est pas si évident de les utiliser efficacement. Trop souvent, les suites de tests deviennent un frein : lentes, fragiles et trop liées à l'implémentation technique plutôt qu'au sens métier. Cet atelier de 2h propose d'échanger autour de nos pratiques à travers un exercice concret de refactoring des tests d'une application existante. L'objectif est d'apprendre à concevoir des tests rapides, compréhensibles et qui expriment pleinement le sens du code métier. Si vous ne savez pas ce qu'est le slice testing, si vous pensez que les tests containers ne sont que pour des tests d'intégration, si vous voulez réduire l'impact sur vos tests à chaque modification du code métier, cet atelier est pour vous PRÉREQUIS : - Java 25 (JDK) - Docker et Docker Compose — daemon Docker lancé - Git - Un IDE Java— IntelliJ IDEA (recommande) ou votre IDE préféré pour faire du java
Mercredi
14h00 à 16h00 - Amphi A- Développement
- Université
Arrêtez de miser sur vos Tests Unitaires !
Vous en avez assez de voir vos Tests Unitaires passer... alors que votre application plante en production ? Fatigué de devoir adapter des dizaines de mocks à chaque refactorisation ? Il est temps de passer aux Tests d'Intégration ! Dans ce codelab, nous explorerons comment tester efficacement une application Spring Boot en simulant les dépendances externes : * WireMock pour simuler vos appels API, * Testcontainers pour tester une vraie base de données dans un environnement isolé, * LocalStack pour reproduire vos intégrations AWS. Repartez avec une application plus robuste, des tests plus fiables… et moins de surprises en production !
Mercredi
14h00 à 16h00 - Amphi B- Développement
- Conférence
G1, ZGC, Shenandoah... Chez Java, ils sont gentils avec tous leurs GCs mais moi je choisis lequel ?
On a l'impression qu'avec chaque version de Java il y a de plus en plus de Garbage Collectors (GCs) avec de plus en plus d'options. On entend des phrases cryptiques telles que "Oh trop bien ZGC est devenu générationnel alors que Shenandoah ne l'est pas" ou "T'as vu chez Netflix ils ont réduit leurs tail latencies avec ZGC". Du coup on se pose tout plein de questions: * qu'est-ce qu'ils racontent ? * ZGC c'est quoi ? * si ce ZGC est si magique, pourquoi il y a d'autres GCs dans Java, hein ? * pourquoi on ne parle toujours que des différents GCs de Java mais jamais pour Go ou JavaScript ? chez Java ils ne sont pas capables d'en choisir un ? * et en natif, on a besoin d'un GC ? Dev Java ou simples curieuses et curieux, tout le monde est bienvenu. On va repartir des bases, en commençant il y a 30 ans lors de la création de Java jusqu'à maintenant pour comprendre pourquoi on a toujours besoin d'un GC et pourquoi ce n'est pas un problème résolu (comme l'API Collection). On fera aussi un tour des GCs, de leurs évolutions, de pourquoi on en est arrivé là, de leurs forces et de leurs faiblesses. (spoiler alert: ZGC n'est pas le GC qui les remplacera tous) À l'issue de ce talk vous saurez quand utiliser quel GC afin de trouver le plus adapté à chaque projet, chaque application, chaque environnement.
Mercredi
15h00 à 15h55 - Amphi D