banniere devoxx fr carre 2019 4001
< < Articles

Retour sur le 3ème jour de conférence de Devoxx 2019 [19/04]

05/07/2019

Marie Bonnissent, Fabien Thouraud, Lukas Cardot, Ingénieurs Java, Thomas Carsuzan, Architecte, Stéphane Leclercq, CTO reviennent sur le 3ème jour de conférence de l'édition 2019 de Devoxx.

Que se passe-t-il sous le capot ? Exploration au coeur de la JVM

Sylvain Wallez

Rédacteurs : Fabien Thouraud, Stéphane Leclercq

Au détour d’un article de blog, un soi-disant code optimisé pour gérer l’identification de cas d’erreur à partir d’une énumération. La solution mise en avant ? Sortir les cas nominaux dans un if / else et n’itérer qu’après sur les cas restants dans une boucle foreach à partir des values() de l’enum. Bien évidemment cette optimisation n’en est pas une, un test de performance rapide montre que le code est globalement encore plus lent !

Il y a deux grandes catégories de soucis de performance liés à la mémoire : L’allocation et le GC. En général, on utilise un profiler mais sur un tel exemple c’est un coup à détruire son serveur de prod ou sa machine locale quand vous allez chercher le dump de 90Go. Jmap est très bien comme outil de premier niveau.

Sur l’exemple de Sylvain, Jmap montre beaucoup d’activité liée au GC. Java mission control et Java flight recorder sont aujourd’hui de bons outils pour investiguer (et gratuits !). Côté ekino nous utilisons souvent Yourkit profiler.

“javap -c” est utilisé pour extraire le bytecode à des fins de lecture (IDEA supporte aussi cette fonctionnalité, mais pour démarrer et comprendre il faut toujours utiliser la ligne de commande !). Du bytecode vous dites ?! Oui !

Sylvain nous emmène au coeur et nous explique quelques concepts dont le ConstantPool et la façon de suivre les pointeurs afin de comprendre ce qu’il se passe (Il faut voir la vidéo du talk pour le détail !). “javap -c” fait le gros du travail afin de vous donner directement le résultat en tant que commentaire sur chaque ligne.

Un détour également un peu théorique sur le Type encoding afin de comprendre les chaînes barbares comme “(Ljava/lang/String;)v”

type encoding

Facile, non ?

JMH est alors utilisé pour faire quelques microbenchmarks. Il s’occupe du warmup, de la collection et récupération de statistiques, de l’intégration avec maven, etc. donc à privilégier par rapport à toute opération manuelle ou autre bricolage. Attention par contre, il est facile de se perdre dans de la micro optimisation qui ne sert pas à grand chose au global.

Sylvain nous montre quelques correspondances entre le code java et le bytecode. Ca a l’air limpide quand il en parle, mais on sent bien que c’est issu de pas mal d’heures d’exploration et que si on y met le nez on a intérêt à avoir un dimanche pluvieux devant nous ! Cela nous amène à découvrir un souci d’autoboxing visible uniquement dans le bytecode.

Enfin, on passe un peu de temps sur l’anatomie du source tree du JDK, énorme et complexe étant donné la maturité du langage, le nombre de versions et les orientations successives prises. On sent le poids des années et la grande marche à franchir pour ceux qui veulent s’y aventurer. De façon anecdotique on apprend que vmSymbols.hpp contient toutes les intrinsic methods que le JDK attrape au vol pour optimisation.

En guise de conclusion pour le plébéien développeur, méfions nous du Enum.values() car il effectue une copie défensive du tableau des valeurs de l’énumération.

La JVM et Docker, vers une symbiose parfaite !

David Delabassee

Rédacteur : Thomas Carsuzan

docker-oracle

Durant cette présentation, David a cherché à minimiser la taille d’une image Docker pour Java, avec plusieurs pistes, tout en pensant aux performances du startup et à la sécurité.

Plus une image sera petite, plus elle pourra être transférée rapidement. La première chose à faire est d’utiliser une JRE plutôt qu’un JDK. Ensuite, il est possible à l’aide de JLink de construire sa JRE avec seulement les modules nécessaires à notre application, et sans les headers.

Dive est un outil qui permet de voir le poids de chacun des layers d’une image Docker. Pour son application, David arrive à avoir une image java de seulement 40 MB!

Ensuite, il nous a parlé de CDS (class data sharing, https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html) Cela permet d’avoir des temps de startup encore plus rapides, mais en échange l’image Docker sera un peu plus grosse.

Pour les very short live container, il est important de limiter voir d’annuler les effets du garbage collector. Pour cela il y a Epsilon GC (https://openjdk.java.net/jeps/318) mais Serial GC permet d’avoir des résultats quasi équivalents.

Afin d’utiliser openjdk sur une image Alpine qui a une lib c (musl) non compatible avec l’open jdk, il y a le projet Portola https://openjdk.java.net/projects/portola

Afin de bénéficier des dernières optimisations de la jvm à l’aide des flags ergonomics, il faut utiliser les versions récentes du runtime. Ainsi, la jvm essaiera de s’adapter automatiquement aux ressources du container.

Pour la sécurité de vos images, pensez à utiliser des outils tels que Snyk, Clair, ou Anchore, et supprimer l’ensemble des lib non utilisées afin de limiter la surface d’attaque (distroless image).

Votre API web passe-t-elle les 50 points du contrôle technique ?

Francois-Guillaume Ribreau

Rédacteurs : Stéphane Leclercq, Marie Bonnissent

Cette session récapitule les points essentiels d’une liste de plus de 70 “points de contrôle” qu’a catalogué au fil de l’eau Francois-Guillaume. Ces points de contrôle sont destinés à valider entre autres la maintenabilité, la sécurité, la robustesse et la performance de vos API lors de leurs développements ainsi que pendant leur exploitation. Une slide présente l’ensemble pour se faire une idée :

pointsdecontrole

Il vous faut une checklist

Le point essentiel est que lorsque vous développez une API, il vous faut une checklist. Que cette checklist soit explicite (documentation/wiki etc.) ou implicite/automatisée et faisant partie de votre chaîne d’intégration continue et de run, ne pas en avoir c’est l’assurance d’un développement amateur, vulnérable et inexploitable.

Votre checklist fait partie des développements

Le second point essentiel lié au premier est que cette liste doit être suivie et mise en oeuvre pendant les développements et non pas en fin de chaîne / quick fix avant la prod. De manière globale, il nous conseille de mettre le plus de contraintes possibles en amont car il est souvent difficile d'ajouter des comportements sur l'intégralité d'une API à posteriori.

Ayez un nommage clair

Un des premiers points à prendre en compte est le nommage du service, pour cela il faut aller au plus simple et au plus évident.

Appliquez “Zero Trust” à l’ensemble de vos développements

On n’est plus dans les années 90, les concepts de “trusted network” sont à bannir. Il faut segmenter au maximum les applications et sécuriser l’ensemble. Ce n’est plus “est-ce que je me vais me faire hacker ?” mais “quand est-ce que je vais me faire hacker ?” Sécurisez votre API en intégrant un IAM pour gérer les accès (Keycloak par exemple).

Votre API doit être versionnée et rétrocompatible

C’est une API, pas juste un ensemble de services pour votre front (sinon pourquoi vous vous cassez la tête à faire une vraie API ? Pour avoir l’air cool ou blinder votre CV pipeau ?). Afin d'assurer un meilleur suivi des modifications apportées, il faut gérer le versioning et être capable de produire des changelogs. Il faut également pouvoir gérer la compatibilité descendante et la garantir. Un outil populaire pour accélérer les tests de non régression de versions multiples d’API est Diffy. Cela ne suffit pas mais c’est un bon début.

Utilisez les outils comme S3 pour versionner vos objets/fichiers

C’est dispo out of the box, pourquoi recoder ? (à part pour avoir une excuse pour sortir Kafka et avoir l’air cool ou blinder votre CV pipeau).

Limitez la quantité de données

Il faut tout limiter dans l'espace (avec des projections et de la pagination) et dans le temps (avec des quota sur le nombre d'appels possibles sur une période donnée).

Améliorez votre gestion des déploiements.

Dans l’ordre du plus basique à l’avancé :

  • Déploiement par redémarrage simple
  • Déploiement blue/green
  • Déploiement sans coupure via des rolling updates. Attention c’est là où ça se corse et que vous devez réfléchir à être rétrocompatible à la version n-1. L’ensemble des plateformes cloud proposent ce service de rolling update maintenant
  • Déploiement progressif avec dark-launch, canaray release, et rolling updates. Mêmes prérequis mais plus poussés

Un très bon talk à voir et à revoir.

Gradle, je t'aime : moi non plus

Jeremie Martinez & David Wursteisen

Rédacteur : Stéphane Leclercq

Ce retour d'expérience sur Gradle contient principalement des tips, les speakers étant convaincus de l’utilité et pertinence de l’outil dans leurs projets. Le talk est destiné à ceux qui ont déjà de l’expérience avec Gradle. Ils avaient 3 profils qui utilisaient Gradle sur le projet

  • Developper
  • Script Maintainer
  • Build Master (multi projet / transverse à la société) : Pas dans le scope du talk

Le développeur

Utilisez le wrapper

Le wrapper Gradle permet de s’assurer que vous utilisez toujours la bonne version de Gradle pour votre projet, pas de surprise ou incompatibilité entre la version de Gradle et les scripts du projet, pas de risque de voir un développeur casser le build de tout le monde (sauf lui). J’ai ajouté un script simple venant de oh-my-zsh et qui permet de choisir automatiquement entre l’outil installé sur la machine et le wrapper s’il est présent (priorité au wrapper). Le script montre Maven mais pour Gradle il suffit de remplacer “mvn” par “gradle”. https://gist.github.com/sleclercq/2d5a17280b2029b37c9015cd55f48cc3

Dépendances des modules du projet

Un truc simple pour utiliser automatiquement toutes les dépendances d’un autre module du projet : compile(project(“:otherProject”))

Utilisez votre dépôt interne pour des packages spécifiques

Nexus sait le faire si vos proxies sont bien configurés, mais ce n’est pas toujours le cas. Vous avez également “flatdir” pour ce qui est buildé en local.

repositories {
    …
    maven {
        url = uri(“https://internal”)
        content {
            includeGroupByRegex(“com\\.mycompany.*”)
        }
    }
    flatDir { dirs(“libs”) }
}

C’est mieux que d’utiliser un “mavenLocal()” qui ne permet pas à Gradle d’optimiser le build. D’ailleurs si vous avez des dépendances critiques qui ne sont pas/plus sur votre repository maven interne, vous avez probablement un problème à résoudre avant que plus personne n’ait la dépendance sur son poste.

Vous pouvez également utiliser “compositeBuild” (dépendances sur disque) ou “dependencySource” (sur Github etc.). Très intéressant et composable.

Le Script Maintainer

De façon générale, les scripts Gradle doivent être le plus déclaratif possible. Pas une soupe de code. C’est un travers de Gradle dans lequel on peut facilement se retrouver car étant scriptable on a vite fait de bricoler.

Utilisez le dossier buildSrc

Pour regrouper vos divers scripts, plutôt que d’utiliser des noms de dossier génériques genre “scripts”, “tools”, “util” etc. Gradle a une convention : “buildSrc” à la racine du projet. C’est également reconnu par IDEA donc parfait !

Utilisez Kotlin

Désolé Groovy, mais le DSL Kotlin de Gradle permet aujourd’hui de faire des scripts plus explicites et déclaratifs que Groovy. Attention : Le support d’autocompletion d’IDEA est moins bon avec Kotlin qu’avec Groovy, donc si c’est la première fois que vous utilisez Gradle il vaut mieux rester sage et utiliser Groovy. Avec Groovy vous ne savez pas toujours si vous êtes face à une assignation de variable ou un appel de fonction. Avec Kotlin c’est explicite. Le pattern delegate dans Kotlin permet une syntaxe très compacte, déclarative, et externalise la logique qui s’y cache. Visuellement agréable

val commit by extra { Git.commit() }

Lorsque vous souhaitez convertir des scripts Gradle de Groovy vers Kotlin, démarrez avec le script du dossier racine et progressez au travers des modules/dépendances jusqu’aux feuilles en dernier.

Pour certaines tâches avancées Kotlin est beaucoup plus verbeux que Groovy, donc soyez attentifs si vos scripts sont complexes avant de vous décider à les migrer, évaluez la charge et le résultat potentiel.

Conclusion

Jérémie et David sont conquis par Gradle et le DSL Kotlin. Le talk se finit sur les principales features intéressantes de leur expérience (avancée) face aux autres outils de build :

  • L’utilisation de “buildSrc”
  • Le support des IDEs, surtout IDEA
  • La présence de nombreux plugins internes pour avancer plus vite et avoir une syntaxe explicite

En inconvénient, Gradle a une performance qui laisse encore un peu à désirer, et cela malgré les très nombreuses optimisations de build et caching déjà apportées au fil des versions. Pour des projets de taille “classique”, cela ne pose cependant pas de souci.

Comment se faire Hacker bien comme il faut !

Julien Topçu

Rédacteur : Stéphane Leclercq

Attention ça pique ! Julien nous montre dans cette présentation simple et rapide à quel point il est facile de laisser des trous de sécurité dans son application web. Le contexte est un classique site e-commerce.

On commence tranquillement avec des problèmes de sécurité que tout le monde connaît :

  • Injections SQL
  • Mots de passe en clair
  • Logins et mots de passe dans les logs
  • Hashage des mots de passe avec md5 (tip : utiliser BCryptPasswordEncoder dans Spring)
  • Mots de passe vulnérables aux attaques par dictionnaire

Pour ceux-là, cela devient difficile d’être vulnérable tant que vous utilisez les frameworks et librairies disponibles depuis plus de 10 ans et/ou que vous avez un linter type SonarQube.

Un point intéressant lié à RGPD : Utiliser le userId dans les logs maintenant plutôt que le username, c’est plus propre, plus légal, et ne révèle pas le login. Les comptes partagés posent problème également : Difficile à détecter, ne pas inciter ! Pouvoir faire plusieurs comptes administrateurs etc.

Ensuite on passe sur des failles un peu plus intéressantes et moins connues.

External XML entities

Lorsque les échanges sont fait en XML, si vous pouvez utiliser les entités XML externes, une faille permet de révéler à peu près ce que l’on veut. Exemple de requête :

<!DOCTYPE ItemsSelector [
    <!ENTITY file SYSTEM “classpath:application.yml”>
]>
<ItemsSelector>
    <categoryId>&file;</categoryId>
</ItemsSelector>

Oui ! Cela fera exactement ce que vous craignez dans la réponse ! Pour s’en prémunir, il faut désactiver les external entities lorsque vous créez un nouveau XMLMapper ou ObjectMapper (ceux créés par défaut dans Spring sont correctement configurés).

CORS et CSRF

Tout le monde connaît (?) CORS maintenant, ou devrait. Mais surprise : Il n’y a pas de preflight sur certaines requêtes pour certains browsers, donc ce n’est pas suffisant ! La solution est d’utiliser le support CSRF des frameworks. Il ne faut surtout pas le désactiver dans Spring Boot, et le configurer correctement pour Angular et autres. Exemple dans Spring Security :

@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
//
configureHttpSecurity(http);
}
```

#### Deserialisation vulnérable avec Spring Data Rest

Juste pour l’exemple car cela a été fixé après dans Spring Data Rest. Vous pouvez tout simplement envoyer ce genre de JSON à un endpoint :
```
[{ “op”: “replace”, “path”: “T(java.lang.Runtime).getRuntime().exec(\”calc.exe\”).x”, “value”: “Hacked!!!” }]

Et votre calculatrice favorite (si vous êtes sur Windows) apparaît. Imaginez ce que l’on peut faire sur un serveur !

Les conclusions à tirer :

  • Ne laissez rien au hasard, renseignez vous, OWASP Top 10 est un bon début et absolument essentiel si vous vous prétendez être un professionnel du web !
  • Utilisez systématiquement les frameworks et librairies mises à dispositions par la communauté. Ils ont été écrits par des gens 100 fois meilleurs que vous en sécurité et dont c’est le métier. Maintenez-les à jour, car ils ont parfois également des vulnérabilités, rien n’est parfait.
  • Comprenez les concepts et configurez correctement ce que vous utilisez. Un Spring Security peu/mal configuré ou trop permissif par confort ou ignorance ne vaut rien.

3 Techniques faciles de manipulation

Marie Viley

Rédacteur : Stéphane Leclercq

Dans ce quickie résolument non technique, Marie nous parle de techniques couramment utilisées pour nous faire faire quelque chose que nous n’aurions pas fait dans d’autres circonstances. L’objectif n’est pas forcément de les utiliser mais plutôt d’être en mesure de les détecter. Attention pour autant ce n’est pas parce que vous avez l’impression d’être manipulé que votre interlocuteur est en train de le faire, cela peut être complètement accidentel et n’est pas le but du quickie, il ne faut pas sombrer dans la paranoïa. Il s’agit uniquement d���outils pour vous permettre de quitter le terrain de la discussion émotionnelle pour retourner sur le terrain de la discussion objective et prendre des décisions réfléchies qui vous correspondent.

L’engagement et la cohérence

La première technique repose sur l’engagement progressif de quelqu’un à accomplir une action en le gardant dans la même direction tout au long de la conversation. Cela se fait généralement via une série de questions ou d’actes.

  • “Salut, ca va ?”
  • “Oui et toi ?”
  • “Ca va, ton projet va bien ?”
  • “Oui ca se passe bien”
  • “On a passé l’audit de sécurité ?”
  • “Oui, sans souci”
  • “Il va sortir à temps à ton avis ?”
  • “Oui c’est bien parti pour”
  • “Tu pourrais venir m’aider à déménager mon armoire normande ce weekend ?”
  • “Oui bien sûr” Narrateur “Et c’est ainsi que Michael se retrouva à Melun un dimanche à 7h du matin”

Je rajoute que la technique est assez proche de “Sunken cost fallacy” (concept de coût irrécupérable) dans lequel on s’est investi (temps, argent, émotion, etc.) dans une direction et on n’ose pas changer le cap dans l’espoir de récupérer à terme ce qui a été investi.

Règle de la réciprocité

L’idée est que si vous faites quelque chose pour quelqu’un (un service, de l’argent, etc.), il devient très difficile pour cette personne de ne pas vous rendre la pareille d’une manière ou d’une autre.

favor

Les premiers à utiliser cela sont… les enfants ! Ils vous vident le lave vaisselle d’eux-mêmes (qu’ils sont mignons !) juste avant de vous demander de jouer à la Switch. Cet effet donnant-donnant fait tellement partie de notre ADN social qu’on le voit partout : Les offres gratuites, les cadeaux de Noël, l’aide technique, etc. mais c’est également comme cela que l’on tisse des liens forts et que l’on peut compter sur les autres. En bonus Marie parle de combiner avec la technique consistant à demander la lune (refusé) pour accéder plus facilement à une demande qui apparaît comme raisonnable.

Preuve sociale

Très proche de l’effet mouton de panurge : Si tout le monde le fait, c’est normal de le faire aussi, ça donne même envie ! Les restaurants utilisent cette technique en remplissant en premier les tables à l’avant, les concerts et diverses opérations marketing via l’effet de pénurie (scarcity effect), les “produits de l’année”, les partenaires populaires, influenceurs instagram/youtubeurs, etc. C’est également très utile pour se faire apprécier de quelqu’un : par exemple si vous connaissez le patron du restaurant et que vous lui serrez la main, vous êtes automatiquement considéré comme quelqu’un de bien par ceux qui ne vous connaissent pas.

Très bon quickie informatif, de quoi rendre tout le monde un peu paranoïaque !

Le refactoring le plus difficile de ma carrière

Jérôme Petazzoni

Rédacteur : Stéphane Leclercq

Dans cette Keynote, Jérôme nous parle de burnout et dépression, des sujets malheureusement trop communs dans notre industrie, souvent méconnus, et encore moins gérés par la plupart des sociétés.

Il ouvre avec une slide choc qui annonce qu’au moins “Une personne sur cinq” en ce moment même souffre d’un trouble mental. Levez la tête, regardez vos collègues, faites-vous une première idée et un premier coup de flippe au passage.

Jérôme nous parle de son expérience chez Docker : Environ 100 talks en une seule année avec le “Docker tour de France” et quasiment le “Docker tour du monde”. De façon macro, c’est beaucoup, mais au quotidien on ne s’en rend pas forcément compte et cela paraît ou devient normal. Par exemple : Qui a géré une centaine de crises sur son projet l’année dernière ?

Les symptômes de burnout sont variés mais des grands “classiques” se détectent maintenant facilement pour peu qu’on y prête attention :

  • Au travail : L’inaction (à ne pas confondre avec l’inactivité), la procrastination, et l’incapacité à vous forcer à être productif.
  • En dehors du travail : L’absence d’intérêt et l’ennui pour des activités qui étaient historiquement intéressantes pour vous et qui de toute évidence devraient continuer à vous intéresser. Jérôme prend l’exemple personnel de vacances en famille au bord de la mer.
  • Lorsque la situation s’installe ou s’aggrave, les symptômes deviennent physiques : Sensibilité au bruit, insomnies…

Ok, on est en situation de burnout ou de dépression (et non pas de déprime passagère). Que faire ?

La première chose est de s’occuper des symptômes, car si on ne traite pas les symptômes il sera très difficile d’être en capacité de traiter la source du problème. Il fait un plaidoyer pour les substances que les médecins peuvent nous prescrire : Si cela peut aider à nous sortir du trou, comme des béquilles, il faut les utiliser. Personne ne dit qu’il ne faut pas toucher au café, pourtant cela agit sur le cerveau et a des symptômes de sevrage. Les mentalités ont évolué ces dernières années sur le sujet notamment avec les modes de la Silicon Valley sur le microdosing et les stacks de suppléments, donc je pense que l’auditoire était assez réceptif. Il expose plusieurs substances dont il a lui-même fait l'expérience (Attention ! Il ne parle que de son expérience et ce n’est absolument pas un avis médical ou quoi que ce soit qui s’en rapproche) :

  • Prozac : inutile pour lui,
  • Mirtazapine : fonctionne mais trop d’effets secondaires pour lui (vertiges, etc.),
  • Duloxetine : a fonctionné pour lui sans effets secondaires. Encore une fois, si vous souhaitez prendre cette route, consultez votre médecin plutôt que de lire un article sur internet.

Une fois la situation gérable, il faut absolument changer son mode de vie pour ne pas retourner aussi sec dans les mêmes problèmes. Pour cela, Jérôme expose plusieurs pistes qu’il qualifie globalement de “self-care” :

  • Prendre soin de son corps : faire du sport, ne pas boire d’alcool… j’ai envie d’ajouter ne pas utiliser de drogues récréatives, dormir beaucoup, et arrêter de manger n’importe quoi. On notera que l’ensemble revient à avoir un minimum de self-control sur sa vie.
  • Prendre soin de son mental : avoir un ou des hobbies, des choses qu’on aimait faire lorsqu’on était enfant, etc. et aménager du temps pour. Cela n’a aucun sens d’attendre la retraite pour s’inscrire à un cours de guitare, découvrir l’escalade ou passer quelques jours à l’autre bout du monde.
  • Prendre soin de son social : les humains sont des êtres sociaux, ne négligez pas le social, si on n’a pas de social on devient fou et/ou on en meurt. Je rajoute qu’être introverti ou aimer faire des activités dans son coin (très commun dans notre industrie) n’a rien à voir avec la nécessité d’avoir un tissu social.

Malgré ces changements, Jérôme souffrait toujours de burnout et s’en est rendu compte à force de regarder des études sur le sujet. Il a alors changé son mode de vie de façon plus drastique, a quitté sa société et a fait une “pause” de 6 mois. Résultat : Il allait enfin mieux ! Mais parfois la bête revient donc il faut toujours avoir une réserve de “self-care” pour la garder à distance ou s’en occuper immédiatement.

On réalise que ce qu’a fait Jérôme n’est pas possible pour tout le monde : certaines situations financières ne permettent pas de s’arrêter ou même de diminuer drastiquement son niveau de rémunération. Cependant, chacun doit trouver sa solution car on parle bien d’un problème grave.

Après son expérience, Jérôme revient ensuite sur le diagnostic d’une dépression. La dépression et le burnout sont différents mais pas très éloignés. Ce sont des maladies et doivent être considérées par tous commes telles. On ne demande pas à quelqu’un ayant la grippe de “faire un effort”. Comme certaines personnes ont besoin de sport dans leur vie car elles sont trop sédentaires (nous par exemple), d’autres ont besoin de psychothérapie et ca n’a rien d’anormal. Idem pour les traitements.

On ne peut pas facilement diagnostiquer une dépression car il est difficile de mesurer les niveaux de dopamine, sérotonine, etc. dans le cerveau. Le diagnostic est donc la plupart du temps fait de façon subjective à partir de symptômes et de l’histoire personnelle du patient. Des outils sont disponibles pour tenter d’évaluer si vous êtes en burnout comme le Maslash Burnout Inventory (attention, voyez un médecin si vous avez un doute bien sûr).

Enfin, il mentionne que certains contextes rendent le diagnostic personnel plus difficile : par exemple, en startup il y a moins de moyens, de personnes, et de points de comparaison pour savoir si la situation est normale ou non.

En conclusion, Jérôme nous invite à prêter attention à trois points essentiels liés à votre entourage :

  • Ayez un bon manager. Son rôle est vital et il doit être la première ligne de défense contre le burnout.
  • Connaissez vos collègues, soyez bienveillants entre vous. “T’as l’air crevé” est un bon début.
  • Ne vous isolez pas : pas trop de travail en solo ou en remote, prenez votre déjeuner avec les collègues, etc.

A la découverte de Bazel

Paul (Spring) Boutes

Rédacteur : Lukas Cardot

A travers une application utilisant Bazel comme outil de build, Paul nous fait découvrir son concept, ses différentes fonctionnalités et ses avantages.

Donc, qu’est-ce que Bazel ? Utilisé comme outil de build à l’interne chez Google depuis de nombreuses années, Bazel est devenu open source en 2015. Comparable à des outils de build tels que Gradle, Maven ou Make, il utilise une syntaxe plutôt simple et lisible, et assez high-level. Bazel est ‘language- agnostic’ en supportant les langages sur la JVM, C++, JS, Python, et beaucoup d’autres. Un des arguments de vente de Bazel est sa grande scalabilité sur de gros projets avec un codebase important et maintenus par une grande quantité de personnes (ce n’était pas un outil interne de Google pour rien). Bazel se veut aussi très rapide grâce à son cache et sa gestion des builds incrémentaux.

Conceptuellement, on peut trouver quelques similarités avec le modèle d’exécution de Gradle. Bazel construit un ‘build graph’ représentant les actions à performer, les artefacts de builds et les interrelations et interactions entre eux. Paul précise qu’une action est une unité logique, en gros une fonction, que l’on définit dans nos fichiers de build, acceptant un ou des éléments en entrée et produisant un résultat. Ce ‘graph’ permet à Bazel de gérer efficacement les différentes relations entre les actions afin de ne lancer que ce qui est nécessaire, de cacher ce qui est possible, et d’être déterministe dans les résultats produits. Pour scripter les différentes étapes de build, Bazel utilise le langage Starlark, un dialecte de Python.

Personnellement, après cette présentation je ne vois pas ce que Bazel apporte de plus face à Gradle. Le paragraphe précédent peut aussi être utilisé afin de donner une description basique de Gradle. Leur modèle est très similaire, mais Gradle garde un outil de scripting qui me semble plus human-friendly que Starlark, grâce notamment à la montée en puissance du DSL Kotlin. Néanmoins, il serait intéressant de voir ce que permet Bazel sur un imposant projet, car il faut se rappeler que Bazel tourne depuis plusieurs années sur l’immense codebase de Google. Nous n’avons pas vu voir concrètement ce que donnaient les performances.

Pro tip : Je ne vois pas un projet ekino utiliser Bazel de sitôt, mais c’est tout de même un sujet intéressant de retour car très concret et peu exploré.