- Développement
- Université
- 2h00
Rendez vos tests Spring Boot rapides,robustes et maintenables
Date mercredi
Horaire 14h00 à 16h00
Salle Amphi A
Description
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
Orateur·ices
Thomas Piscitelli
Rennais de cœur et développeur passionné, j'ai pu expérimenter le delivery dans un contexte d'ESN ou d'éditeur logiciel. J'aspire à mettre les équipes au centre des process afin de leur simplifier la vie et leur permettre de lever les différents freins qu'elles peuvent rencontrer. Je suis particulièrement intéressé par toutes les solutions permettant de favoriser la communication, la qualité de code, la sécurité applicative, la qualité des entrants, la gestion de la dette technique, le test...
Actions rapides
Les sessions futures sur le même thème
- Développement
- Conférence
HTMX, de manière simplix !
**Résumé**: On a beaucoup parlé d'HTMX, maintenant, il serait temps de s'y mettre. Et c'est exactement ce que Thomas et moi avons fait ! Nous nous sommes mis à la place d'une équipe technique qui décide d'effectuer une migration d'une application SPA (React, Angular, etc.) vers une "Hypermedia Driven Application", grâce à HTMX (https://htmx.org) ! **À qui ça s'adresse**: À qui s'intéresse au développement Web, aux frameworks FrontEnd, ou bien au contraire qui avait fait une croix sur tout ça parce que "c'est devenu trop compliqué". Bonne nouvelle ! Non seulement ça ne l'est pas, mais en plus on va vous expliquer pourquoi ! **Plan**: - On part d'un exemple concret, un bon vieux CRUD implémenté en React (https://github.com/mutoe/preact-realworld-example-app), et on migre progressivement ce paradigme SPA+JSON vers une version HDA+HTMX - Point de ToDo-List simpliste ici, on va prendre un vrai cas métier: un clone de Medium, le site de gestion/publication d'articles de blog : https://realworld-docs.netlify.app/ - Comment qu'on migre ? Graduellement ! On va Jouer sur le Content-Type pour renvoyer soit du JSON, soit du HTML, ce qui nous permettra de jouer sur les deux tableaux afin de comparer les deux approches. On prendra donc un ensemble de composants plus ou moins complexes pour les convertir. - À chaque étape, on aborde un aspect du développement Web et ses conséquences : SPA vs HDA, WebComponents, la gestion des APIs des "Back-For-Front" et la transition JSON->HTML - La grande force des SPA, ce sont leurs composants "réactifs". Voyons comment on a fait la même chose avec https://lit.dev/ pour créer des WebComponents équivalents, notamment grâce à HTMX
Jeudi
8h30 à 9h25 - Amphi C- 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.
Jeudi
8h30 à 9h25 - Amphi D- Développement
- Quicky
Parce qu’un bon Commit vaut mille lignes de commentaires
Dans le premier projet dans ma carrière professionnelle en tant que développeur, les membres de l’équipe ont souvent changé durant la durée de vie du projet d’une douzaine d'années. Étant arrivé vers la fin du projet, j’ai pu rapidement comprendre les choix techniques du projet, et apprécier la qualité de maintenabilité de la base de code. Très peu de dettes de connaissances étaient présentes car tous les changements étaient bien retranscrits en utilisant une pratique de commits atomiques au sein de l’outil de versionning Git. Dans mon projet actuel, les développeurs n’utilisent pas cette même pratique. Les difficultés sont donc multiples. Ma présentation a pour but de faire un retex sur les gains et la mise en place de cette pratique de commits atomiques Voici ce que vous apprendrez dans la conférence: Définir ce qu'est un commit atomique et les types de changements rencontrés Structuration du commit: Choisir une convention de nommage des commits. Utilisation de la nomenclature de commit conventionnels S'attacher au “pourquoi” plutôt qu'au “quoi” “comment” dans le message de commit Réécrire son historique Git avec le rebase interactif A la fin de cette conférence, les spectateurs pourront eux mêmes appliquer cette méthode et en tirer les bénéfices suivants Tracer et documenter des choix techniques sans utiliser des commentaires directement dans le code Réduire le temps passer à faire des relectures & le nombre de commentaires pour comprendre la visée de certains changements Identifier plus rapidement l’introduction de bugs au sein du code avec l’utilisation de la commande “git bisect”
Jeudi
11h05 à 11h20 - Amphi E