Tu n’écris pas de compte rendu sur la soirée Emmanuel Bernard. C’est Emmanuel Bernard qui écrit le compte-rendu. Tu ne vas pas à la soirée Emmanuel Bernard, c’est lui qui t’invite (ou pas). Tu ne lis pas ce compte-rendu, Emmanuel te lit son compte rendu.
Sur le thème des ChuckNorris facts, Emmanuel a envoyé à l’équipe du Paris JUG son propre pitch pour la soirée d’hier soir. S’en est suivi plusieurs Emmanuel’s facts sur la liste de diffusion du Paris JUG, ce qui était très sympa pour donner un style fun pour une très bonne soirée.
Encore 210 personnes ce soir, sans problèmes. Quelques nouveaux sponsors pour le Paris JUG, comme Ippon Technologies qui devient sponsor Gold par exemple. Le buffet de ce soir est offert par la société DRiMS. Ils ont organisé un tirage au sort entre les 2 présentations afin de faire gagner quelques cadeaux aux juggeurs, ainsi que leur aide pour le buffet. Drims intervient dans différents secteurs sur les pôles MOA, MOE et le décisionnel. Nous sommes toujours content d’avoir de l’aide ponctuellement pour les Buffets, ce qui permet de recevoir 200 personnes et d’animer la soirée.
JDuchess
La soirée débute avec l’arrivée sur scène des JDuchess France. A l’initiative de Mathilde Lemée (Indépendante/blog Java-Freelance.fr) et d’Ellène Dijoux (Xebia France) qui avaient rencontré lors de Devoxx 2009 les JDuchess hollandaises, elles se sont regroupées avec Laure Némée (Leetchi[Updated]) et Claude Falguière (Valtech).
L’objectif du groupe JDuchess France est de proposer un groupe de rencontre aux femmes dans la communauté Java. Mesdames, que vous soyez développeur, architecte, ou autre, vous pouvez venir aux soirées du Paris JUG et être assurée d’être accueillie par une communauté sympa. Mathilde explique que le groupe JDuchess compte 158 membres dans le monde. Pour rappel, il y a 15 user groups en France, plus de 440 dans le monde. Et l’initiative de proposer un site communautaire, et des événements pour les femmes est une très bonne idée.
Enfin c’est encore un succès pour la communauté et pour les Users Groups. Donc si vous êtes une femme intéressée par Java, et que vous êtes sur Paris, n’hésitez pas à vous inscrire sur le site communautaire de JDuchess. Il y a 8 membres pour l’instant, j’espère que cet article fera venir du monde dans le groupe.
Hibernate Search
Emmanuel a présenté Hibernate Search ce soir. J’avais vu cette présentation à Jazoon, je vous invite à relire ce que j’écrivais à l’époque. J’ai revu et réécouté celle-ci avec plaisir, Emmanuel ayant ajouté quelques points intéressants.
Sur la présentation, je pense que la partie code a satisfait ceux qui regrettent parfois le niveau trop général des présentations du JUG. Ce soir nous avons vraiment mis le nez dans le moteur. Pendant une heure, tout le monde a découvert la notion de recherche, l’indexation, la construction et l’interrogation des indexes Lucene.
J’aurai aimé un peu plus tard entendre Emmanuel sur le positionnement d’Hibernate Search par rapport au Cloud et JPA. Sur Google App Engine pour mon projet-toujours-pas-terminé « Geek Date » j’avais utilisé Compass. Cela me permet d’indexer les événements à la création et de proposer une zone de recherche full-text multi-critère sur la page d’accueil.
Et le Buffet !
Une soirée JUG c’est 2 conférences et bien entendu, le Buffet. Au sondage pour l’anniversaire du Paris JUG, vous aviez été 70 personnes à répondre, et la place du buffet est très importante pour vous. Charles pourra vous détailler les chiffres, mais voici 2 indicateurs intéressants :
Si je vous parle du buffet c’est pour vous faire passer une information. Ce soir encore, quelqu’un m’a dit qu’il cherchait un nouveau boulot. Fraichement arrivé à Paris, il lit régulièrement les différents blogs. Il m’a confié qu’il a envoyé son CV aux différents sponsors du Paris JUG car pour lui, ces boîtes représentent les entreprises où il souhaite travailler. C’est-ti pas beau comme histoire ?
Moi je dis +25 points de Bisounours pour le Paris JUG qui contribue à un meilleur monde.
Travailler sur l’écriture d’une API
Emmanuel Bernard présente ensuite un sujet intéressant, et pas forcément évident au premier abord : quelles sont les difficultés et les particularités à prendre en compte lorsque l’on écrit une API ?
Il nous fait partager son expérience tirée du travail en tant que Spec Lead sur la JSR-303 (Bean Validation) et de ses années sur Hibernate Search. L’objectif est de présenter la notion d’API, les difficultés rencontrées, et de nous faire partager son boulot. Ce fut très intéressant, pour une présentation qu’il donnait pour la première fois.
Ecrire une API est un travail de longue haleine. Il y a toujours des personnes mécontentes, et apporter un changement à posteriori est difficile. Lorsqu’il explique ceci, nous prenons tout de suite conscience qu’il s’agit d’un travail à part entière, bien distinct de l’écriture de sa bonne grosse appli de gestion (BGAG). La difficulté de figer à un instant T un ensemble de méthodes et d’objets force celui qui écrit à travailler 5 fois plus qu’un projet classique. C’est donc non pas le volume, mais la qualité du code que l’on recherche ici.
Emmanuel explique que le temps passé est important aussi car une API est destinée… à des êtres humains. Elle doit donc être orientée utilisabilité. Le développement TDD ne suffit pas à assurer une qualité et une cohérence. Il semble que l’itératif soit obligatoire pour réussir.
Ecrire une API vous force à monter en compétences. La notion de DSL apparaît rapidement dans la présentation d’Emmanuel. Il s’agit bien d’utiliser l’expressivité de Java pour décrire comment faire quelque chose. D’ailleurs, la gymnastique sur les Annotations dans Hibernate Search en a surpris plus d’un.
J’ai demandé à Emmanuel s’il avait regardé Scala plus tard dans la soirée. En effet, il parle à la fin de sa présentation de l’avantage des classes Abstraites par rapport aux interfaces. C’est justement la notion de Trait que l’on trouve dans Scala. Le temps de terminer mon deuxième article, vous verrez cela d’ici à la fin de cette semaine.
Pour revenir en arrière, écrire une API est un exercice sportif. Il parle de chuter plusieurs fois pour progresser, comme en Snow board. Il faut mettre en place une stratégie pour proposer à l’utilisateur de nouvelles fonctions, tout en gérant le cas où vous n’êtes pas certain de vous… ce qui arrive souvent. Il faut donc prévenir le développeur que vous êtes susceptible de modifier certaines fonctions.
Emmanuel présente ensuite quelques exemples de patterns utilisés lors de l’écriture d’API. La partie sur l’utilisation des annotations a certainement comblé le geek le plus obscurantiste de la salle. Il a cependant évité l’effet jantes-alliages tuning avec « regardez mes belles annotations« . Les explications sur le changement des APIs de Mapping étaient vraiment intéressantes. On retient que l’écriture d’API reste un sport de haut niveau, où la maîtrise de Java est vraiment importante.
Emmanuel termine sa présentation en donnant quelques bonnes pratiques. Tout d’abord, si vous écrivez une API sur un projet, il est indispensable de la faire vivre sur des exemples d’intégration. Les tests unitaires ne suffisent pas.
Lors des choix des verbes et des noms de méthodes ou d’objets, travaillez à plusieurs sur vos choix de mots. Car une fois ceux-ci à l’intérieur de l’API, il est difficile de changer. Je pense que sans le savoir, Emmanuel parle de Domain Driven Design. Dans cette pratique, nous travaillons sur la définition de l’Ubiquitous Language. C’est un exercice qui permet de créer une langue commune entre les gens du métier et les développeurs. Dans le cadre du travail sur une API, il faudrait lister les verbes, les noms, dessiner une MindMap de ce que fait l’API. Cela permettrait de s’assurer que les mots sont correctement choisis.
Emmanuel encourage l’utilisation de DSL interne afin de rendre plus facile l’utilisation de l’API. A propos de DSL externe, le plus connu que vous avez tous utilisé sans le savoir est… le langage SQL. Il nous montre l’enchainement de verbes d’actions et d’adjectifs pour la définition de la configuration dans Hibernate Search. Je crois qu’il s’agit du pattern Builder si je ne dis pas de bêtises. Plus facile à mettre en oeuvre avec Groovy que Java.
Une astuce aussi pour l’API est de penser « comportement par défaut ». Ne demandez pas à vos utilisateurs de déclarer trop de paramètres qui ne changent pas ou peu. Il montre un exemple avec Hibernate Search où l’API s’arrange pour se configurer avec un comportement par défaut, afin d’alléger la quantité de code. Cela rend l’API plus Agile.
Conclusion et 3ème mi-temps
Emmanuel a bien animé la soirée. Les 2 sujets étaient intéressants. C’est un bon speaker qui fait passer son message, sans fioritures. Il a même répondu aux questions posés sur la Wave d’Olivier Croisier lorsque nous étions au restaurant. C’était vraiment sympa de sa part.
Si j’avais un truc à demander à Emmanuel, ce serait d’ajouter quelques images dans ses slides pour appuyer ses idées.
Documentez l’utilisation de votre API
Pensez au pattern Adaptor
Votre API doit être simple à utiliser
Note : les photos de cet article sont en licence Commons Creatives, trouvées sur FlickR.
0 no like
Partage à propos du recrutement que tu mentionnes au début de l’article : je confirme, étant dans la même situation, je n’avais d’abord pas restreint mes recherches aux sponsors de JUG et il s’avère que finalement, après avoir réuni l’ensemble de mes critères de recherche (from companies c where c.passion=true and c.size < 1000 …) , la majorité des sociétés (à une exception près) sont investies de près ou de loin dans les JUG (sponsor, speaker).
Les JUG (plus généralement la communauté) ont donc bien droit aux points bisounours dans la mesure où ils permettent de faire se rencontrer des personnes aux intérêts communs 🙂 et ça c'est cool!