Ma Geecon 2014 – premier jour

Pour ceux qui ne connaissent pas la Geecon, il s’agit d’une conférence autour de Java and friends organisée par les JUGs de Pologne. Cyrille Leclerc et Michael Figuière y avaient fait une présentation commune sur le NoSQL et les Datagrid in memory.  La Geecon c’est : 1 jour d’ateliers, 3 jours de conférences, 1100 participants par jour et 80 speakers venus du monde entier, le tout en anglais. Dans cet article, je vous propose de découvrir ma première journée sur place, les présentations que j’ai suivies : Rest Assured par Johan Haleby, Better performance for Java 8 par Kirk Pepperdin et The social Developper par Peter Van de Voord.

Commençons donc par un petit brin d’introduction pour vous décrire l’évènement. Je suis arrivé à Cracovie, dans un complexe cinéma de 15 salles, en début d’après-midi pour le premier jour de conférences. Bon, j’ai raté les Keynotes d’ouverture mais j’arrive alors que la conférence bat son plein. Petit détail pour cette fois : je vais directement trouver un organisateur en T-shirt jaune de circonstance qui me donne mon badge speaker, les goodies et le programme. Adam m’indique ensuite la salle réservée pour déposer les affaires, préparer les talks, discuter entre speakers et faire les derniers slides. Sur place rien de particulier à signaler. J’ai un peu l’impression d’entrer dans une fourmilière.

Je pars, pour ma première présentation et je choisis Johan Haleby dans la room 11 :

Feel at ease and REST Assured par Johan Haleby

Johan est l’auteur de quelques librairies connues comme PowerMock, Awaitility et Rest Assured qu’il vient présenter dans ce slot.

Rest assured est un DSL pour tester des services Rest en intégration.

[java]given().
parameters("login", "XXX", "password", "*****").
when().
post("/login").
then().
log().all().
assertThat().body("response.userId", equalTo("1"));[/java]

Johan nous code en live cet exemple, en lançant un petit serveur Rest construit en scalatra qui tourne sur le port 8080 de sa machine. Il exécute son test Junit et l’on voit les résultats de l’exécution dans les logs. Le test exécute une requête POST sur son serveur en fournissant un login et un mot de passe et vérifie ensuite le contenu du body de réponse.

Le DSL à outrance n’est pas franchement ma tasse de thé, je trouve quand même que c’est élégant, la syntaxe est du plus bel effet. La présentation est assez convaincante. Tout se passe entre l’IDE, le navigateur et les logs, ça a l’air facile. Johan nous fait faire le tour du propriétaire en creusant d’abord la configuration très fine du système :

• Mapper Json/ Jaxb.
• Matcher pour les assertions.
• Support du SSL.
• Client HTTP.
• Validation XSD / JSONSchema, OAUTH, etc.

Nous voyons ensuite les outils pour tester le contenu réel de la réponse. Nous avons la possibilité de traiter le body et les headers avec une grande flexibilité :
en mode texte, en XPATH / JSONPath / texte brut ou binaire.

Il est possible de faire du mapping objet à partir de la réponse pour réaliser les tests sur les beans. Nous pouvons utiliser du Groovy pour faciliter les assertions.
Pour éviter la duplication de code, Johan nous montre les spécifications qui permettent de définir un template pour la construction de la requête, sous la forme d’une spec que l’on aura construit avec une Response ou une RequestSpecBuilder. La specification pourra par exemple gérer le/les cookies, passer des paramètres, que l’on utilise dans tous les tests.
Cette première présentation m’a mis en appétit, je vais tester ça sur mon projet actuel.

Ayant par le passé organisé des évènements avec Kirk Pepperdin, je choisis tout naturellement d’enchainer avec sa présentation.

Looking for better concurrency in Java 8 par Kirk Pepperdin

Kirk commence par nous présenter un peu l’histoire des processeurs en partant d’une photo du premier processeur Intel. Les CPU contiennent maintenant plusieurs coeurs, des niveaux de caches, bref beaucoup de capacité. Mais sans contrôle, la puissance n’est rien. Pour Kirk, plus de CPU implique plus de pression sur le bus et les caches sont la clé du système. Car le CPU peut vite devenir une usine à rafraichir des caches, plutôt qu’un centre de calcul.

J’aime cet approche très factuelle, qui part du problème au niveau matériel pour aller vers les conséquences au niveau logiciel.

Kirk nous parle ensuite de la loi de Little :
la loi de Little dit que le nombre moyen N de clients dans un système stable est égal à leur fréquence moyenne d’arrivée Y multipliée par leur temps moyen T passé dans le système :
N  = Y * T
Dans notre cas Y = 1/4

Kirk passe ensuite à l’analyse des systèmes de lock de la JVM, avec des exemples de code et de thread dumps.
Le locking est toujours pessimiste et il s’avère inutile dans 99% des cas. Depuis Java 5 et le reentrant locking, les optimisations se succèdent de version en version. L’escape analysis permet de réduire le scope des locks au scope le plus petit. Mais cette analyse utilisée par la JVM doit être aidée.
Le Jdk8 a beaucoup amélioré le biased locking qui permet d’ignorer un lock inutile. Un exemple simple pour comprendre le principe : un programme exécute un traitement en boucle en passant par une méthode synchronized a chaque itération. Avec le biased locking, la JVM va tout simplement ignorer le block de synchronisation car il est mono-threadé.

L’un des problèmes majeur de performance rencontré sur les CPU est le cache miss. Imaginez : votre application est manifestement au maximum de ses performances puisque le processeur tourne à 100%. Mais en fait, non ! Le processeur passe son temps à invalider ses caches, il faut superviser les cache miss. Il peut s’agir d’un « false sharing » : grossièrement, les données sont montées en ligne dans les caches mais les threads invalident en permanence le cache des autres. Vos threads travaillent sur un même objet avec de la lecture et un champs régulièrement écrit. Dans ce cas, chaque écriture sur le bloc forcera l’invalidation du cache des autres threads. La solution est de sortir le champs en question dans un bloc de données séparé qui pourra éviter le cache. C’est ce que fait l’annotation @Contended.

Avec un nouvel exemple de code, il nous présente une amélioration de facteur 10 sur le nombre de traitement réalisé avec l’annotation.
La présentation continue en listant d’autres nouveautés du Jdk8 :

• StampedLock : permet de passer au lock optimiste mais est compliqué a utiliser.
• ReadMostlyVector : fournit une liste synchronisée améliorée pour faire du lock optimiste.
• Spliterator : pour faciliter le forkJoin.
• Méthode « parallel » des streams, pour paralléliser les traitements.

La conférence prend fin avec quelques questions : quels outils pour analyser les threads dumps ? Comment faire du micro-benchmarking ? Etc.

Vous l’aurez compris, j’ai aimé cette deuxième présentation très technique.

Pendant le break entre ces deux conférences, j’ai un peu discuté avec Peter Van de Voorde qui m’a vendu sa présentation. Le titre et la conversation, m’ayant intéressé, je décide d’aller voir de quoi il retourne.

The social developper – Peter Van de Voorde

Les slides sont une succession de belles images en plein écran et c’est tout. C’est un format de présentation que j’affectionne, j’aime quand le speaker a plus de chose à dire que ses slides. Ça commence bien, Peter est convaincant et le sujet m’intéresse. Tout d’abord, il nous parle de ses règles pour réussir en tant que développeur :

• Hunt for flow, cherchez le mouvement, ne soyez pas bloqués.
• Autonomy – mastery – purpose,  la motivation d’une équipe est liée à l’autonomie, la maîtrise et l’intérêt de chacun.
• Invest in yourself, il faut croire en soi, ne pas hésiter à réaliser des choses.
• Be assertive not aggressive, cela vous est-il déjà arrivé ? Vous ou un collègue, s’énerve sur un code écrit par quelqu’un d’autre ?
• Get out of your comfort zone, sortez de votre zone de confort ! Son exemple : lui-même l’a appliqué pour finir speaker à JavaOne.
• You have 2 ears and one mouth, use them, soyez attentifs et exprimez les choses. Pour qu’elles soient prises en compte les idées doivent être exprimées.

Je dois reconnaître que ces assertions me parlent. Même si elles paraissent évidentes, elles méritent d’être entendues. Voilà en quelques phrases ses points clés pour être un développeur social. Peter enchaîne ensuite avec les équipes : qu’est-ce qu’une équipe ? Pour peter les équipes sont des Avengers, chacun est spécialisé et travail en équipe. Tout le monde a des compétences, il faut les utiliser. Faîtes travailler les gens dans leur spécialité.
Un élément essentiel dans le travail d’une équipe est le maintient de l’intérêt. Notre travail n’est pas toujours passionnant, il est donc important de prendre du temps pour entreprendre. Peter nous cite quelques pratique d’entreprise :

• ROWE – Result Only Work Environment, dans ces organisations le travail des équipes ne tient compte que du résultat, pas du temps de travail.
• 20% de temps libre de Google.
• ShipIt Days Atlassian, 24 heures pour livrer un projet.

Si votre entreprise ne fait rien de tout ça, vous pouvez toujours organiser entre vous des brown bag lunch par exemple. Petit à petit, Peter égraine ses conseils pour le travail en équipe :

• Invest in people, il faut investir sur les personnes, fournir du temps, des formations, etc.
• Find your own incentives – Trouvez vos propres intérêts.
• Be a leader, Not a boss – Soyez un leader pas un chef. Que j’interprète comme n’imposez pas les décisions, le travail est toujours meilleur lorsque l’on est convaincu.
• Strive for more than mediocrity – Trop souvent, les équipes visent les solutions les « moins pire », le message de Peter et de viser l’excellence. Si vous n’échouez pas, c’est que vous n’essayez pas assez.
• Do the beer test – Peter nous parle de recrutement ou plutôt d’identifier les personnes avec qui vous pouvez boire une bière. Pour pouvoir travailler dans de bonnes condition, nous avons besoin de se sentir proche des autres, alors posez-vous la question:  est-ce que je prendrais une bière avec lui/elle ?

C’est déjà la fin de la présentation qui clôt cette première journée à la Geecon. J’ai vraiment aimé ce slot. Les conseils sont bons et justes.

Il est temps pour moi de retourner à l’hôtel avant de passer à la soirée Geecon organisée dans un bar de Cracovie.

Fin de journée

Pour conclure cette journée, voici ce que je retiendrais. Tout d’abord, il pleut. A la question, comment trouves-tu la Pologne ? Ma réponse fut : « le pays est très vert ». Fort heureusement, la météo n’est pas l’élément essentiel.  Sur place, l’équipe d’organisation est très active. La machine est bien rodée pour cette sixième édition. Pendant les pauses dans le hall, il y a du monde mais suffisamment d’espace pour circuler. Par contre, les couloirs du cinéma sont trop petits pour la foule. Les 10 minutes de pause entre les présentations ne sont pas de trop pour réussir à circuler. J’ai appris quelque chose à chacune des présentations, j’en sors avec soif de savoir et de bière.