Google Doc de l’unconference, avec les sujets abordés :
https://docs.google.com/spreadsheets/d/1cp8posM1qQhnEFAQZlZHhnLb_XcspdprLiMlu8LQ2YA/edit#gid=619580251
-
Fused with my bye bye fundamentals, I am a "only tools" user
-
Intro and pitch by Maurice: "are we just AWS users?"
-
base de code AWS trop importante, personne ne pourrait la redévelopper
-
tout le monde l’utilise donc sans se poser de question…
-
-
José : conseille de lire l’avis d’Uncle Bob sur le métier d’architecte (voir son livre Clean Architecture)
Pas le temps de finir le sujet, on a dérivé sur le métier de développeur avec un focus sur la France
-
Record components are not modifiable
-
You cannot have more fields (that initially decided) in a Record
-
Contrary to Beans, Records do have constructors
-
-
pas de field initializer dans un Record, tout vient du constructor
-
field assignments is done by the compiler
-
-
Records are always static (like enums)
-
JFR marche avec Mission Control
-
libéré (Open Source) par Oracle avec Java 11
-
Jean-Philippe : designer pour éviter les overhead
-
n’arrête pas les threads comme c’est le cas pour YourKit, JProfiler ou VisualVM
-
la techno est directement intégrée dans la JVM, ce n’est pas rajouté "à côté"
-
on peut ajouter ses propres évènements
-
-
limitations du sampling à 5 threads (4 Java et 1 natif)
-
les évènements sont déclenchés par la JVM à des moments bien précis (plus précis que JMX)
-
-
DataDog (Jean-Philippe bosse pour eux) se base sur JFR pour le profiling
-
Jean (Bisutti) s’en sert pour le produit QuickPerf auquel il participe
→ la doc sur les évènements de JFR n’est encore très fournie, ni très facile à trouver.
Il y aurait matière à communiquer sur le produit pour améliorer tout ça.
-
Voir InfoQ : monitoring-jdk-jfr (@MikaelVidstedt)
→ La vidéo montre comment créer les évènements -
Présentation du même style au Fosdem : Jie Kang (JMC & JFR)
-
Jean-Philippe : Zulu a déjà backporté le support de JFR dans sa version (JDK) 8 (et, rappel, Zulu peut être utilisée librement en DEV comme en PROD)
-
José : Marcus a fait dernièrement une prez très complète de Java Mission Control (JMC) à CodeOne.
-
Jean-Philippe : JFR démarre après le "pre-main", il ne permet donc pas de profiler les agents (ce que permet par contre
async-profiler)
-
Rémi : actuellement, l’OpenJDK est en train de passer sur GitHub
-
actuellement, les sources sont sur Mercurial
-
Cf Rémi : extrêmement facile à builder (2 commandes à lancer, marche aussi bien sur Mac, Windows, Linux)
-
tout est expliqué dans un répertoire "doc"
-
C’était très compliqué à builder jusqu’à la version 8 comprise (après un suédois a réécrit le script de build, et depuis ça marche)
-
-
José : a fait un tool in action au dernier Devoxx France et Belgium sur comment builder l’OpenJDK en 10 étapes
-
Rémi : a sur son GitHub un builder en Travis pour builder plusieurs versions de l’OpenJDK
-
-
-
Rémi : il y a bugs.openjdk.net qui est un Jira permettant d’accéder aux bugs ouverts
-
par contre, la catégorisation des bugs "pour débutant" n’est pas faite très souvent (tous les 1,5 ans quelqu’un râle sur "il n’y a pas assez de JEUNES contributeurs" et catégorisent les issues pour débutants)
-
quand on souhaite commencer à contribuer, il faut tout d’abord signer un clause côté Oracle (voir "openjdk wiki" (wiki.openjdk.xxx))
-
-
Dalybor TOPIC : pour obtenir les droits de créer une issue (quand on a un outil qui ne marche pas suite à un bug de l’OpenJDK)
-
Rémi : le plus simple pour contribuer au début : aller dans le Jira, trouver un bug le plus petit possible
-
pour que son code soit accepté, il faut soit :
-
un sponsor et 2 reviewers
-
Conseil de Rémi : avant de se lancer dans le code du patch, dire que l’on souhaite s’attaquer au pb, et obtenir les conseils des anciens ("c’est plus compliqué qu’il n’y paraît, fais gaffe…")
-
-
commencer par un sujet autour de l’OpenJDK (comme Loom)
-
-
JTREG : pour les tests de non régression (\~300 000), très long à faire tourner (de 40 min à 1h sur Travis)
-
les tests sont organisés commes les mailing lists (associés à 1 sujet)
-
les tests sont plus faciles à faire tourner sur sa machine que sur 1 CI (à cause des tests Swing qui nécessitent un environnement graphique)
-
finalement, peu de diff entre les tests de JTREG et les tests du TCK, mais seul ce dernier permet d’appeler son code "Java"
-
si on dérive les sources de l’OpenJDK, pas besoin de payer le TCK (c’est ce qui se passe pour Zuul, Coretto, etc. Ils ne payent pas)
-
-
-
-
"CSR" dans le Jira des bugs : groupe qui s’occupe de la compatibilité des API (en fait le CSR est un doc garant de la backward compatibility)
-
s’assurer que les signatures restent les mêmes, que la javadoc soit correcte, etc.
-
derrière le CSR il y a un groupe de personnes qui ne sont PAS d’Oracle
-
-
les gens qui sont partis et ne contribuent plus sont marqués "inactive"
-
Paul SANDOZ, de retour récémment chez Oracle (après passage éclair chez Amazon et Netflix), a écrit 80% de Stream
-
-
José : le JDK n’est pas du tout un exemple de Clean Code
-
Rémi : une raison pour laquelle les patchs sont rejetés sont les perfs (pas mal de tests JMH, mais ce n’est pas nous qui les lançons)
-
-
Rémi : c’est simple de contribuer, mais c’est "hyper dur" de modifier un algo
-
du fait des intrinsèques, comme c’est le cas pour la classe String par exemple
-
Donc, pour des pbs de perfs, ce n’est pas la peine de chercher à modifier String, ArrayList, etc. (le code que l’on écrit ne correspond pas à celui exécuté du fait de l’intrinsèque)
-
-
-
Rémi :
-
1) s’inscrire à la mailing list (voir openJDK.net, les mailing list sont les "groups" dans le menu de gauche)
-
2) dire à la mailing que l’on souhaite s’attaquer à telle ou telle issue
-
-
José : à lister certaines ressources (livres) sur le software craftsmanship sur son GitHub
-
importance des harckergarten pour passer la porte de certains projets (à savoir comment commencer à contribuer sur ces derniers)
-
José : unconf "Hack Commit Push", journée dédiée aux contributions Open Source
-
Thomas : siou plaît, mettez à jour le site d’Aurélie Vache sur GitHub (liste des conférences techniques : https://github.com/scraly/developers-conferences-agenda)
-
-
Voir sur son GitHub (ou un de RedHat) The Cloud Ready Postit application
-
Sun : en 1) relance de la version libre pour avoir des retours sur le produit, puis 2) release new version de la version RedHat Enterprise de Eclipse CHE
-
Via le fichier de conf de l’IDE, on définit quels containers on va utiliser (qu’ils tournent en local ou sur un Cloud)
-
je rattrape mon retard : RedHat soutient maintenant le projet Theia, qui est l’une des interfaces graphiques pouvant être utilisée par Eclipse CHE
-
au début de CHE, il y avait un frontend spécifique, fait en GWT, qui a fini par poser problème (long à rebuilder / mettre à jour) et être abandonné.
→ c’est la version que j’avais testée
-
-
Dans CHE, on a, en même temps, les containers de l’environnement CHE, ET ceux de l’application que l’on développe / fait tourner.
-
CHE adresse la problématique de "comment développer correctement pour Kubernetes".
→ Réponse : "en commençant par développer DANS Kubernetes", ce que permet CHE -
fonctionne avec OpenShift, ET bien d’autres solution Cloud
-
dont des solutions locales comme MiniKube
-
-
par défaut, pour 1 workspace, tous les containers sont dans le même pod
|
📎
|
Jean Christophe confirme que le mode collaboratif (édition à plusieurs d’un même code) de VS code marche vraiment très bien. Par contre, cf la licence Microsoft, il y a une limitation à ce niveau, qui limite son usage aux seuls produits Microsoft (???) |
-
Twitter
-
faire gaffe à ne pas suivre trop de personnes
-
utiliser les listes pour faire des catégories
-
-
sites web
-
blogs des SSII / ESN "sérieuses" (Xebia, Octo, SFEIR, Ippon, etc.)
-
grands sites d’infos (DZone, InfoQ, Dev.to, Medium, etc.)
-
les organiser via Feedly (ou autres même si pas trop d’alternatives)
-
-
YouTube
-
toutes les grandes conf publient maintenant les vidéos de leurs talks sur la plateforme
-
tellement de tutos dessus maintenant
-
-
podcast
-
permettent d’être consultés en "off"
-
Cast Codeurs, BigData Hebdo, Tech Café
-
mais aussi BFM Tech & Co (le côté politique / économique étant également bon à connaître : exemple avec MapR qui met la clé sous la porte, gaffe si on utilise la techno pour le support à venir par exemple)
-
-
MOOC
-
Coursera, Udemy, Pluralsight
-
-
de manière générale, importance de cibler ses combats
-
regarder les stars du GitHub
-
jeter un oeil à Google Trends de temps en temps
-
-
Jean Christophe : côté finance, le coût de la place ne paye que "le café", le reste (locaux & Co) vient des sponsors
-
penser aux personnes à mobilité réduite
-
question à poser dès le début
-
José : marge de manoeuvre limité à ce niveau pour une petite asso
-
c’est malheureux, mais cela reste du "best effort"
-
-
-
Agathe : pour le Commit Push
-
Google Doc pour le partage
-
point toutes les semaines (surtout, importance de la régularité)
-
-
Jean-Christophe
-
Hang-out pour la comm
-
-
José : Paris JUG : budget était de 15 à 20 000€ / an
-
José : importance de la "neutralité" de l’asso, la liste des membres est figée → aucune grosse SSII qui la sponsoriserait ne doit pouvoir la fagociter
-
le contenu éditorial ne peut PAS être décidé par les sponsors
-
-
Devoxx France : salle 250 000€ (je ne sais pas si Mariott ou Paais des Congrès), fiscalement les choses changent
-
à partir d’un certain budget, il est bon de prendre un expert comptable
-
-
José : penser au coût du package pour les sponsors
-
que le prix d’un stand avec places offertes
-
-
Pour le problème épineux des repas, on ne peut pas satisfaire tous les différents (et nombreux) régimes alimentaires
-
comme compromis, les plats végétariens semblent un bon choix (en tout cas, le "moins pire")
-
il n’y a pas de solution parfaite, mais montrer que l’on y a pensé, et que l’on a fait un effort, doit aider à satisfaire le plus grand nombre.
-
-
-
Assurance
-
José : assurance responsabilité civile obligatoire
-
Jean-Christophe : en fait non, obligatoire que pour les asso sportives ou d’utilité publique
-
José : l’ESIEA l’avait demandé pour le ParisJUG pour les locaux, et Jean-Christophe indique que Station F l’a également demandé
-
-
José : on peut prendre des assurances spécifiques pour 1 évènement
-
José : consultation chez l’expert comptable \~150€
-
José : cabinet d’expert comptable pour Devoxx, 500 à 600€ à l’année
-