- Développement
- Conférence
- Introduction
- 55 min
G1, ZGC, Shenandoah... Chez Java, ils sont gentils avec tous leurs GCs mais moi je choisis lequel ?
Date mercredi
Horaire 15h00 Ă 15h55
Salle Amphi D
Description
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.
Orateur·ices
Antoine Dessaigne
Antoine est développeur Java depuis une vingtaine d'années. Depuis 2012 il travaille sur un logiciel d'analytics chez Axway, un éditeur français de logiciels. Il fait ses premiers pas en tant que développeur puis devient architecte sur le projet. Depuis 6 ans le focus est mis sur l'amélioration des performances et sur la migration vers un environnement cloud.
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
- 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
- Développement
- Conférence
Jointures et agrégats en SQL : piÚges classiques et fonctionnalités méconnues
Jointures et agrĂ©gats : deux piliers du SQL qui, malgrĂ© leur symĂ©trie fonctionnelle (passer dâun enregistrement Ă plusieurs, ou inversement), cachent des mĂ©canismes et des piĂšges radicalement diffĂ©rents. Les jointures vous jouent des tours ? Doublons inattendus dans vos rĂ©sultats paginĂ©s, choix cornĂ©lien entre INNER ou LEFT JOIN⊠Et cĂŽtĂ© agrĂ©gats, les classiques SUM, MAX ou MIN ne suffisent plus ? DĂ©couvrez comment exploiter les window functions, les CUBE/ROLLUP/GROUPING SETS, et mĂȘme les agrĂ©gats avancĂ©s de PostgreSQL (JSON, XML) pour transformer vos requĂȘtes en outils ultra-puissants. Si vous utilisez SQL, cette confĂ©rence vous donnera les clĂ©s pour Ă©crire du SQL expressif et "moderne". PrĂȘt Ă passer Ă la vitesse supĂ©rieure ?
Jeudi 11h30 Ă 12h25 - Amphi E