Ninja Squad à Devoxx

Les deux ninjas Agnès Crépet et Cyril Lacôte effectuaient leur premier pèlerinage à Devoxx, la plus grande conférence Java européenne, qui se tient chaque année à Anvers. L’originale, celle sans suffixe.
Cyril remercie à ce propos grandement l’ElsassJUG, qui lui a offert la place via un concours de prose.

La première chose qui frappe quand on arrive à Devoxx, c’est que cette conférence n’usurpe pas sa réputation : c’est le luxe! Les salles sont incroyables : écrans géants de cinéma moderne, amphithéâtres pentus qui laissent une visibilité parfaite des speakers, fauteuils larges et confortables (ce qui n’est pas sans dangers après les courtes nuits communautaires qu’on passe à Anvers…). Et le lieu (un multiplexe) est globalement très agréable : plein d’espace pour ses 3000 participants, des boissons fraîches à disposition, des espaces de travail (commiter depuis Devoxx reste un must de snobisme geek).

Les sponsors déploient toute leur séduction dans les stands pour attirer : jeux, concours, goodies. Les moyens sont largement mis sur la table. Mais on notera que les geeks sont toujours plus attirés par des robots qui dansent et qui parlent que par des bimbos en mini-jupe qui sourient (I’m looking at you, Red Hat).

Impressions sur les sessions

Les sessions s’enchaînent rapidement. Nous ne ferons pas un compte-rendu exhaustif de toutes celles que nous avons suivies : elles seront prochainement sur Parleys. Nous préférons plutôt vous faire un retour subjectif sur celles qui nous ont marqués.

Atlassian : How to make good teams great

La session d’Atlassian (dont voici les slides) était consacrée aux trucs et astuces permettant à des développeurs de s’éclater.

Voici les 7 points :

1. Flowtime. Il est important de préserver la tranquillité des développeurs. Si l’organisation physique des bureaux ne le permet pas (open-space), Atlassian nous explique qu’ils ont mis en oeuvre la notion de Support Sheriff : à tour de rôle, une seule personne de l’équipe endosse la responsabilité de répondre aux sollicitations externes pour préserver la productivité du reste de l’équipe.
2. Feed your brain. Un bon développeur qui s’ennuie dans la routine ne sera pas un développeur heureux. Si suivre des conférences est trop couteux, il reste possible d’assurer des discussions techniques en dehors du temps de travail, notamment lors du déjeuner pour un brown bag (concept cher à notre ami David Gageot).
3. Say “well done!”. La reconnaissance est importante. Elle devrait être normale et publique. Et si ce sont des membres de l’équipe qui peuvent désigner les méritants, c’est encore mieux (votre boss n’a pas toujours une vision claire des mérites).
4. Report robot. Collecter des données (automatiquement) et les exposer publiquement est la meilleure façon de montrer votre travail souvent obscur au profane.
5. Eat your own dogfood. Utiliser les produits que vous développez est capital pour apprécier leur utilité. C’est aussi un des principes de Google, où chaque employé utilise forcément les versions alpha de tous leurs services.
6. Do a special day. Il y a souvent des choses qu’on n’aime pas faire (rédiger de la documentation, nettoyer des FIXME dans le code, faire des campagnes de test, …). Une façon de les traiter avec plaisir est d’organiser une journée spéciale, hors du sprint, où tout sera mis en oeuvre pour que la tâche soit facile et agréable.
7. Experimentation time. Donner l’occasion à vos développeurs d’innover librement lors d’hackaton apporte non seulement des innovations, mais surtout beaucoup de motivation.

Cette session sympathique, toute à la gloire des pratiques d’Atlassian (qui recrute…) était toujours un bon rappel de combien sont précieux les développeurs, et de combien cette vision peut être douloureuse pour la plupart des français en entreprise, où ils restent bien souvent le parent pauvre et méprisé. Si on insiste sur le sujet, c’est qu’on espère bien que Ninja Squad apportera sa modeste pierre à cet édifice de maturité, et que la France réalisera son décalage sur les anglo-saxons. Developers will one day take the power back!

“Crazy” Bob Lee : Square’s stack

Bob Lee avait oublié de se réveiller pour sa session (c’est donc ça une “rockstar”? :p).
Mais son talk a été replanifié en soirée, devant une salle déserte où quelques rares aficionados ont préféré l’écouter plutôt que manger des pizzas ou boire des bières.

Sa présentation pourrait se résumer ainsi : “back to basics”. En expliquant les problèmes soulevés par les use cases critiques de Square (le paiement, via des terminaux et des applications mobiles), il nous exhortait à sortir de nos schémas de pensées et solutions habituelles avec des frameworks obèses. Un peu d’astuce, d'espièglerie de connaissances fondamentales en algorithmie, pouvaient répondre à beaucoup de nos problèmes. Square a ainsi open-sourcé une tonne de petit projets modestes mais efficaces, dont Dagger, le successeur (?) de Guice dont Bob Lee était déjà le créateur, du temps où il bossait chez Google.

Vert.X

Tim Fox est venu nous présenter son bébé Vert.x. Ce n’est pas son premier bébé, rappelons qu’il est créateur d’HornetQ et qu’il a travaillé dans l’équipe de RabbitMQ. Il commence sa session en expliquant la principale motivation : capitaliser sur la JVM, notre joyau, le moteur le plus optimisé du moment, pour améliorer Node.JS sur le principe d’une plateforme d’événements asynchrones non bloquants.

Contrairement à Node.JS où un seul thread assure l’event loop (Reactor Pattern), Vert.x peut fonctionner en multi-thread, et bénéficier des performances de nos processeurs multi-coeurs. Et quand ce mode est activé, Vert.x assure gratuitement le load balancing entre les différentes instances.

Autre différence majeure avec Node.JS : Vert.x est polyglotte. On peut déjà programmer en JavaScript, Ruby, Java, ou Groovy, et très prochainement en Clojure, Scala et Python.

Sur ce bus événementiel, Vert.x ajoute un système d’actor proche d’Akka pour assurer la scalabilité et la concurrence sans prise de tête : chaque acteur (Verticle dans la terminologie Vert.x) est intrinsèquement single-threadé, immuable, distribué sur n’importe quelle instance, et communique par échange de message.

Cette introduction était bien séduisante. Ce système a l’air prometteur, reprenant et améliorant les bonnes idées de Node.JS. Reste à voir s’il prendra.

Angular.JS

Miško Hevery et Igor Minar venaient nous présenter Angular.JS, le nouveau framework JS (pléonasme) de présentation créé par Google. Sur le fond, cette présentation n’avait rien d’extraordinaire : ils présentaient le tutorial officiel, le passage obligé de tout framework JS MVC : une TODO liste. Mais la forme de la session était d’une maîtrise exemplaire : du pair live coding. Miško avait les mains sur le clavier, expliquait ce qu’il voulait implémenter, et Igor lui répondait, donnait les solutions, et surtout, expliquait quels choix avait fait Angular.JS.

Pour Google, c’est plus qu’un framework de présentation. C’est pour eux ce que devrait être l’évolution du DOM, s’il était construit aujourd’hui comme une plateforme applicative. Ils se servent donc de ce framework qui fonctionne avec les technologies actuelles pour encourager la mutation du DOM, et poussent ainsi des spécifications comme Web Components et Model Driven Views.

La salle était pleine à craquer, et on sentait les vibrations des auditeurs. Cela n’était pas seulement du au talent des speakers. Angular.JS, sur le papier, est une technologie bluffante.

Si vous voulez en savoir plus, notre chaleureux ami Alexis Moussine-Pouchkine (qui est désormais LE Developer Advocate dédié à la France chez Google) a publié une interview de ces deux speakers.

Google et Tim Bray

Tim Bray était là aussi pour faire le maître de cérémonie d’une keynote Google, qui bien que sympathique était très marketing. Il nous rappelait que le public devrait toujours se demander ce qu’un porte parole d’une grosse compagnie vient nous vendre. Dans son cas : nous voir tous vivre sur Internet. Mais Internet étant dangereux, mieux vaut penser à la sécurité. Il assurait ainsi par la suite une session sur OAuth, son dada actuel.
Elle était une bonne introduction à ce protocole mouvant et instable, mais ses illustrations n’utilisaient que l’implémentation du client officiel Google, certes simple et efficace, mais qui n’est pas encore standard tant que la spécification n’est pas sèche.

Rien d’exceptionnel, mais cette grosse compagnie a le mérite de faire plus rêver qu’une autre multinationale qui est censée nous montrer le chemin.

Trisha Gee.

Trisha est développeuse chez 10Gen, la société éditrice de MongoDB. Nous avons vu deux présentations de Trisha. Son premier talk “Agile ++: When Agile Goes Well” était co-animé avec un de ses anciens collègues, Israel Boza Rodriguez, et portait sur les problématiques de l’évolution des pratiques agiles au sein d’une équipe. Ils nous ont expliqué comment le déploiement de l’agilité a progressé dans leur équipe, les points qui fonctionnaient mal au début, comment ils ont pu fluidifier le process et quelles ont été les pratiques qui se sont révelées efficaces. Rien de transcendant dans leur talk, il ne révolutionnera pas les pratiques des Ninjas, mais Trisha reste une excellente speakeuse.

Le deuxième talk animé cette fois-ci par Trisha seule s’intitulait “The Problem With Women: A Technical Approach”… et ne traitait presque pas des femmes! Talk très interactif avec le public. Trisha a proposé de faire une rétrospective avec la salle sur notre métier : quels sont les point positifs, négatifs du métier de développeur. Elle a montré que d’autres problèmes existaient dans nos contextes professionnels : oui il y a peu de femmes, mais il y a aussi peu de personnes de couleur!
Ce qui était pertinent dans son approche était justement de ne pas se focaliser sur la problématique de la faible représentation des femmes dans l’IT, mais d’ouvrir plus largement la question sur le peu de mixité dans nos métiers.

Adam Bien : JEE

Certes Adam Bien porte des sujets relatifs à JavaEE qui en feraient fuir plus d’un (les technologies web innovantes sont plutôt les thèmes qui attirent dans ce genre de conférences) mais quelle bouffée d’air frais de voir un architecte aussi pragmatique! Quand on pense aux nombreux architectes que l’on croise dans nos DSI françaises qui vous montent des architectures à 10 couches en vous traitant de Padawans quand vous tentez d’expliquer que parfois un seul module suffit et qu’on peut se passer de tout interfacer! Adam nous explique également que 30% de couverture de code sur vos tests unitaires peuvent être tout à fait acceptables : il est plus important d’être vigilants sur leur pertinence, plutôt que sur le seul pourcentage de couverture global. L’essentiel est qu’ils couvrent le code métier intelligent.
Bref, grand plaisir à suivre le talk de ce Java Champion aux multiples casquettes et à forte expérience : il travaille sur les technologies Java depuis le JDK 1.0, il est l’auteur de nombreux ouvrages (notamment sur Java EE et les Patterns associés à la plateforme (voir son blog) et est membre du groupe d’experts pour les JSRs Java EE 6 EJB 3.1 et JPA 2.0.

Process, process, process

Mais la session qui nous aura le plus plu ne fut pas technique, contre toute attente. Chet Haase, l’acolyte de notre charmant compatriote Romain Guy avec qui il présenta de multiples sessions sur Android (leur activité chez Google), assura également une session incroyablement drôle intitulée : “The Future of Software Development Process Methodology Effectiveness”. Il y racontait, sur le ton caricatural d’un consultant organisationnel (vous savez, ceux qui sont payés trois fois plus cher que vous pour expliquer et formaliser comment travailler sans à avoir à le faire), différentes méthodologies avancées de développement, avec moult diagrammes justifiant par leur complexité combien elles sont plus efficaces.
En attendant de trouver l’enregistrement vidéo sur Parleys, vous pouvez remercier Pierre-Antoine Grégoire de nous en fournir un screener pirate, qui vous permettra d’apprécier combien Chet Haase maîtrise l’art du stand-up, avec lequel il a adapté un de ses anciens articles de blog “Crystal Meth-odology, a blog article by Chet Haase”.

Les soirées

En soirée, des BOFs en comité réduit permettent aux différentes communautés de se retrouver et d’échanger. Agnès a pu ainsi croiser l’essentiel de ses amies Duchess.

Les JUGs leaders peuvent également y retrouver des responsables Oracle pour améliorer l’organisation et remonter leurs problèmes.

Et quand Devoxx est fini, de nombreuses soirées plus ou moins officielles mais dans tous les cas fortement arrosées de bière se déroulent dans les différents pubs alentours ou du centre-ville. Mais on peut aussi aller profiter des merveilles architecturales de la ville d’Anvers.

Devoxx est donc vraiment le raout incontournable de la communauté Java, le point névralgique où tout le monde converge pendant une semaine. Vous y avez l’opportunité de discuter avec les gens qui la constituent, de suivre les talks de nos stars, et de vous perdre dans des discussions techniques jusque tard dans la nuit.

On y retournera très certainement l’année prochaine, et on ne peut que vous encourager à faire de même!