Cet épisode marathon sera découpé en deux morceaux pour éviter à vos oreilles une écoute marathon. Cette deuxième partie couvre des sujets d’architecture et de loi société et organisation ainsi que les conférences à venir. Logging, Migration Java 8 vers 11, Xerox Park, (manque de) sécurité, courbes elliptiques, sondage développeurs. Enregistré le 8 juillet 2022 Téléchargement de l’épisode LesCastCodeurs-Episode–282.mp3 News Architecture Pour ou contre le logging Contre puis pour tous les langages et plateformes utilisent les logs debugging, tracing, journaling, monitoring, and printing errors impact sur les performances (allocation supérieure sur un log que sur le code métier log = mémoire, CPU (GC), I/O risque de securité (dépendances et fonctionnalités sans besoin) format des log: pour lecture humaine main volume impose traitement automatique log level la bonne abstraction (souvent trop et pas ce que l’on veut à la fois debugging -> utiliser un debugger ; journaling -> event sourcing ou solution dédiée ; tracing > open tracing ; monitoring -> monitoring solution via metrics et health check bons usages de logging: en dev (println), fin de jobs automatiques, erreurs non récupérables ou innatendues, pas les erreurs utilisateur (logger les erreurs qui cachent un bug), dans les container, Sébastien utilise System.out et System.err vu que les logs sont gérés par la plateforme la réponse pour maintenant les logs peuvent etre structurés performance, on peut éviter les concatenations de String (parameterized logging), memory allocation est bien meilleure depuis 2012 (e.g. Shenandoah), vu des problèmes dans des cas plus rare de genre MDC.getCopyOfContextMap disk I/O: ok mais disque cape a 200 MiB/s donc bon…: si c;est le cas, sépare I/O log du reste (disque vs network par exemple) gros fan de logs structures via JSON ; log line sur console et JSON en fichier log plus de manière conditionelle tracing théoriquement bon mais limite dans son contexte métier et peu d’infos passables system.out problème de scalabilité d’usage, etc et appel blocant println (async usage n’est pas bon) LinkedIn et sa migration de Java 8 à 11 1000 apps sur 320k hosts Migration Java 8 vers 11 avec en vue G1 regardé depuis 2018 Jetty, Hadoop, Play, Samza: focalisé sur Jetty Mettre a jour le système de build, 2. Faire des tests de performance 3. Automatiser la migration mise. a jour vers gradle 5 G1 80% des applis CMS 20% pris 20 apps representatives focalisé sur les applications avec les tailles de piles les plus grosses de équipera jusquà 200% plus de latence et throughput: zones G1, Shenandoah et ZGC automatisé la migration du reste et tourné les builds de tests qui ont identifié les problèmes de migration quelques problèmes: suppression de certaines classes Java EE, changement du type de classloader par défaut, casting de classe plus stricte ils ont utilisé -release 8 et ont limité les usages des features Java 11 les options de CLI de la JVM ont beaucoup changé LinkedIn fait du microsercices ce qui veut dire que beaucoup de repositories sont liés à d’autre par un graphe de dépendance: euh c’est pas le principe des microservices d’éviter ça??? mise a jour de 500 librairies 3/4 de l’année Quelques challenges vus La JVM respecte groups et donc moins de thread GC sont crées aussi ils pouvaient piquer des cycles CPUs avant et plus maintenant Java 11 a un usage de mémoire hors pile plus important reduction de latence p99 par 10% et le throughput par 20% sans changer le type de GC C’est un bon retour qui sent le type de développement de la vrai vie Méthodologies Un article sur Xerox park et comment ils ont inventé le futur article de 1985 Xerox achète un constructeur de mainframe, et ils ont crée un lab de recherche pour aider les usages Macintosh et la souris et les fenêtres, les cartes météos colorées, imprimante laser, réseaux d’ordinateurs, lasers semi-conducteurs qui lisent les disques optiques, langages de programmation structurés developer l’archit