Rapport sur LA conférence Groovy européenne : la GR8Conf

gr8conf_logo

Comme annoncé, Xebia était présent pour la 3e édition du plus important rassemblement européen de la communauté Groovy : la GR8Conf de Copenhague (prononcez « Great Conf »). Pour tous ceux qui auraient voulu y être et n’ont pas pu, je vais tenter de vous résumer les sessions auxquelles j’ai assisté et vous donner la tendance du clan Groovy (en Europe tout du moins). Commençons par quelques chiffres :

3 jours
25 speakers
plus de 100 participants
4 workshops
28 sessions
2421305344 octets de technologie Groovy sur clé USB (dans le pack de bienvenue)

La conférence s’est tenue dans les locaux de la IT University of Copenhagen, qui a prêté un amphithéâtre et une grande salle de cours pour l’occasion.

Toutes les sessions ont été filmées (je vous donnerai les liens dès qu’ils seront publiés). Je n’ai malheureusement pas pu assister à la première journée : « l’université ». Ce premier jour, les participants ont eu droit à une mise à niveau sur le langage Groovy et le framework Grails, puis ont enchaîné une après-midi de code pour apporter des contributions à certains projets open-source. Certaines features codées pendant ces workshops ont même été intégrées le soir même et utilisées pour les démonstrations des 2 jours de conférence qui ont suivis.

Groovy update

Après un rapide accueil de Søren Berg Glasius, la première journée de conférence commence par un retour sur les dernières nouveautés du langage Groovy, par Guillaume Laforge. Il ouvre la session avec quelques statistiques sur Groovy 1.7 :

185 000 téléchargements le premier mois suivant la sortie,
177 000 pour le 2e mois,
une communauté de développeurs estimée à 362 000 (sans doute sous estimée puisque les téléchargements via le repository maven ne sont pas monitorés).

Puis il enchaîne en revenant en détail sur les principales nouveautés de Groovy 1.8 :

command chain expression : pour des DSL plus proches du langage naturel. À utiliser avec rigueur pour ne pas se perdre entre ce qu’on passe comme paramètre et l’appel de la méthode suivante,
GPars fait maintenant partie du core de Groovy, ce qui offre de façon directe actors, fork-join, dataflow et autres joyeusetés,
Le support de JSON par défaut dans le langage.

Il y a également beaucoup d’annotations très pratiques comme @Log, @Singleton, @WithReadLock, @WithWriteLock. Pour le détail complet, rendez vous sur Slideshare.

Enfin, une perspective sur les chantiers prévus pour la prochaine version majeure :

Utilisation de InvokeDynamic du JDK7,
Amélioration de la modularité de Groovy pour permettre de n’embarquer que les modules utiles,
Réécriture de la grammaire antlr3, prévue pendant le prochain Google Summer of Code,
Remplacement du compilateur Joint par celui d’Eclipse,
Multicatch (IOException | NullPointer e),
et d’autres apports de syntaxe, comme l’intégration du projet Coin et le support des séparateurs pour améliorer la lisibilité des grands nombres.

Grails update

Dans la foulée des nouvelles, Peter Ledbrook nous a dressé le bilan de la branche 1.3 de Grails, avant de faire miroiter à l’auditoire les nouveautés qui se préparent pour la version 1.4. L’année écoulée a été celle de la version 1.3, avec énormément de nouveaux plugins, notamment pour fournir à l’abstraction GORM des implémentations sur NoSQL (comme Redis, MongoDB, Riak, Neo4j et d’autres). Il a également cité quelques gros comptes utilisant Grails comme framework de premier ordre dans leurs projets, comme Vodafone Music, par exemple.

La version 1.4 de Grails donne vraiment envie. Parmi les nombreuses améliorations attendues, on peut noter :

Groovy 1.8,
Mise à jour de Spring vers la 3.1,
Mise à jour de Hibernate vers la 3.6,
L’utilisation de Tomcat 7 en mode développement,
Baptême de JQuery comme librairie Javascript de base,
Améliorations des templates par défaut lors de génération de pages GSP, appliquant les bonnes pratiques HTML5.

Le but premier de cette version est d’améliorer encore l’expérience utilisateur (c’est à dire celle des développeurs). Ceux qui l’ont essayé peuvent en témoigner : Grails est déjà un framework très agréable. Espérons qu’ils arrivent à faire encore mieux. Il y aura également un système de feedbacks pour que, si les développeurs l’acceptent, leur installation de Grails puisse remonter chez SpringSource des données sur la version utilisée, les plugins installés, etc. Ces statistiques devraient permettre d’y voir plus clair dans le portail de plugins (qui a passé les 600 plugins), et ainsi connaître ceux qui servent et ceux qui dorment.

Adopter Grails

Après cela, Klaus Baumecker, architecte chez HP, est venu nous parler de l’adoption de Grails dans une équipe de développement interne.
Le cadre du projet :

2 équipes qui développent la prochaine version d’un produit, l’une en Grails, l’autre en J2EE standard,
Modèle de données commun géré par Hibernate,
Approche agile (SCRUM-like),
Frontal Flex.

Le speaker nous a énuméré les principaux obstacles techniques qui se sont dressés sur la route, notamment l’intégration de BlazeDS, qui s’est révélée moins triviale qu’au premier coup d’œil. Mais chaque obstacle a trouvé sa solution et le projet a été une réussite. Il a terminé en résumant l’expérience tirée sous forme de bonnes pratiques pour l’adoption de Grails :

Parlez des bénéfices techniques du framework, pas seulement des « cool stuff ». Il a notamment insisté sur la flexibilité de Grails, qui a permis de contourner rapidement beaucoup de contraintes techniques,
Ne soyez pas trop enthousiaste : ça peut donner un aspect « fanboy » à votre argumentaire, là où vous voudriez être pris au sérieux,
Créez une communauté locale, en convaincant en premier lieu vos collègues avant d’aller voir vos responsables,
Appuyez vous sur la communauté Grails et aidez les gens autour de vous grâce à elle : se référer aux mailing lists, forums, IRC et autres blogs permet de fournir des points d’entrée utiles sur le long terme aux débutants,
Apportez vos outils : parlez des plugins, des outils d’analyse statique, des IDE,
Trouvez des situations dans lesquelles Grails fait une vrai différence : notamment quand on compare un ‘grails run-app’ par rapport à un redéploiement d’application classique,
Restez dans la zone de confort du framework : même si le framework est flexible, rester dans les conventions permet aux débutants de s’y retrouver plus facilement en se référant aux ressources du web,
Soyez disponible : si vous tentez d’introduire Grails, c’est surement que vous avez un peu plus de connaissance que le reste de votre équipe. Apportez votre aide autant que possible, proposez de faire des revues de code, du pair programming, tout pour accompagner vos collègues sur le chemin de la lumière.

Je ne saurais trop vous conseiller d’appliquer ces conseils pour tenter d’implanter Grails dans vos projets.

Grails en entreprise

Peter Ledbrook a assuré une 2e session sur l’intégration de Grails dans le monde de l’entreprise, plus précisément dans les processus de développement logiciel déjà en place. Il a débuté en nous parlant des 2 outils de build les plus implantés dans l’écosystème Java : Ant et Maven. Pour pouvoir dire que Grails s’intègre correctement à l’existant, il est indispensable de pouvoir construire un projet Grails avec ces 2 outils.

Pour Ant, le problème est assez simple, dans la mesure où le système de build propre à Grails est Gant, c’est à dire Ant, manipulé grâce à Groovy. Une commande Grails permet de générer build.xml et ivy.xml : grails integrate-with --ant. De cette façon, on peut construire son projet directement avec Ant.

Pour Maven, des plugins existent pour brancher les scripts Grails dans les phases d’un build Maven standard. Cependant, l’intégration avec Maven pose plus de problèmes. De base Grails gère ses dépendances grâce à Ivy, alors que Maven le fait lui même. De plus, le côté rigide d’un build Maven provoque des frictions avec celui, très flexible, des build Gant. Si vous pouvez vous le permettre, utilisez Gant et les conventions Grails.

À noter que pour la roadmap Grails 2.0, il est prévu de passer à Gradle, tout en conservant et améliorant les intégration Ant et Maven.

Peter a également axé une partie de sa présentation sur l’adaptabilité d’une application Grails à une base de données existante. Il est tout à fait possible de reprendre une base de données existante, par plusieurs stratégies:

utilisation directe de fichiers de mapping Hibernate existant
mapping fin (table, colonnes, clé primaire, …) d’entités définies dans l’application
mixer les deux en fonction des besoins

Pour finir, il nous a parlé de déploiement. les mécanismes de customisation du contenu du war permettent de satisfaire toutes les fantaisies des différents serveurs d’application. Pour la production, il conseille fortement de s’appuyer sur les datasources JNDI et sur les mécanismes permettant d’externaliser la configuration (voir ce tips).

Puis il a terminé son exposé par quelques conseils d’ordre général sur les projets Grails :

N’oubliez pas que Grails, c’est du Spring. Par conséquent, on bénéficie de tous les connecteurs du monde Spring, notamment JMS, ESB, AMQP, etc.
Utilisez le plugin app-info, qui vous donnera des vues sur les entrailles de votre application. De la configuration de la datasource à l’utilisation mémoire en live.
Réutilisez vos classes de domaines au maximum. Si une classe de domaine peut servir à plusieurs applications, mettez la dans un plugin et utilisez le.

La somme de toutes ces pistes et de tous ces conseils, c’est que Grails est intégrable à, virtuellement, tous les processus de développement logiciel en place. Il faut se donner un peu de peine, mais les outils sont là pour vous faciliter la tâche (à l’extrême).

CodeNarc & GMetrics

Tandis que se tenait la session de mise à niveau sur Griffon, j’ai assisté à une présentation de Hubert Klein Ikkink alias MrHaKi, l’auteur de billets Groovy Goodness sur son blog, véritable mine d’or de trucs et astuces techniques.

Il est venu parler de CodeNarc et de GMetrics, 2 outils d’analyse statique de code Groovy. Le premier permet de détecter les mauvaises pratiques d’utilisation du langage, comme des appels explicites là où Groovy ferait implicitement le travail. Au total,174 autres règles sont fournies. Quant à GMetrics, son domaine concerne le calcul de la complexité cyclomatique de votre code.

CodeNarc a été cité dans beaucoup d’autres sessions pendant la GR8Conf, voici ce qu’il faut en retenir :

Utilisez le !
Configurez le pour coller à vos bonnes pratiques maisons.
Ecrivez vos propres règles, et si elles sont génériques, reversez les au projet.

Pour les détails techniques, je vous encourage à vous pencher sur les documentations respectives de CodeNarc et GMetrics.

Grails Application Tuning

Voilà l’une des sessions pour lesquelles j’ai eu envie de faire le déplacement jusqu’au Danemark… Je n’ai pas été déçu. En une heure, Peter Ledbrook, dans sa 3ème prestation de la journée, a peiné à faire tenir tous les conseils sur l’optimisation en Grails. La plupart des aspect d’optimisation sont d’ailleurs communs à toute application web Java.

Premier conseil à graver au dessus de votre écran :

Evitez toute optimisation prématurée : Profilez, optimisez, répétez.

Grails est basé sur une stack très classique, donc tous les outils de profiling fonctionnent.

Outils côté serveur

Voici quelques outils pour profilez le fonctionnement de votre application côté serveur :

Spring Insight : avec STS, vous pouvez démarrer votre application Grails dans un tcServer et bénéficier de l’analyse live de chaque requête sur votre application.
Le plugin profiler : qui facilite la collecte de temps d’exécution sur votre code.
Le plugin p6spy : installe un proxy JDBC qui vous donnera la détail de toutes les requêtes en base.
Les plugins app-info et hibernate-stats : qui vous donneront beaucoup d’informations sur les fonctionnements internes de votre application.

Tout cela devrait vous permettre de trouver plus rapidement les goulots d’étranglement dans votre code.

En vrac, voici un ensemble de pistes exploitables pour optimiser vos application Grails (ou autre d’ailleurs).

Outils navigateurs

Google Spring Tracer, qui peut également s’intégrer à Spring Insight.
YSlow, il nécessite Firebug donc l’utilisation de Firefox, mais il est très pratique.

Performance base de données

Réduire le nombre de requête
Analyser les requêtes et ajouter les index utiles
Optimiser vos requêtes, notamment en utilisant des requêtes Criteria nommées.
Faire attention aux stratégies de fetching
N’hésitez pas à changer le modèle pour gagner en performance de requêtage.
Dans certains cas, le chargement Eager peut être avantageux, n’hésitez pas à vous en servir (à bon escient).
Utiliser un cache, surtout dans le cas où il y a plus de lecture que d’écriture. Pour info, Ehcache est disponible dans la stack Grails.

Performance sur les traitements métier

Cachez les appels de méthodes de service idempotentes avec le plugin Springcache.
Faites de l’asynchrone partout où c’est possible, par exemple en utilisant le plugin Spring Events.
Utilisez le plugin Routing pour le messaging
Utilisez Groovy++ pour vous affranchir du surcoût du dynamisme de Groovy quand c’est possible.
Pour les tâches qui font beaucoup de calcul numérique, préférez le Java pur.

Optimisation réseau et navigateur web

Utiliser les capacités de caching de contenu du plugin Springcache partout où c’est possible, pour éviter de recalculer les pages qui ne changent pas souvent.
Définissez correctement vos header HTTP Expires.
Packager vos css et votre javascript, un fichier unique pour chaque permet de diminuer le nombre de requête.
Utiliser le spriting CSS plutôt que de multiples images.
Minifier votre Javascript.
Compresser vos données.

L’utilisation du plugin resources permet d’automatiser beaucoup de choses. Ce plugin très prometteur fera partie intégrante de Grails dès la version 1.4. Il permet notamment :

de modulariser les ressources statiques.
de les packager par type.
définir les header HTTP Expires et de changer le nom des packages de ressources en cas de modification, ce qui forcera le rechargement par les navigateurs.
de placer le Javascript toujours en bas de page pour un chargement plus rapide des éléments visuels.

Ciblez en priorité les victoires faciles. Il faut bien faire attention de ne pas investir trop de temps sur une petite optimisation. On ne vise pas les économies de bouts de chandelle. Une session très chargée et très intéressante. Peter a revendiqué le droit à une sieste après ce 3ème slot de la journée.

Effective Groovy

Pour clore la journée, Hamlet D’Arcy a présenté ses conseils pour être efficace dans l’usage du langage Groovy. Sa session était organisée autour d’une sélection de conseils tirés du livre culte Effective Java et appliqué au monde Groovy. Le speaker est à l’aise et captive son auditoire. Certaines vagues sur Twitter pendant sa présentation ont émis l’idée d’écrire un livre « Effective Groovy ». Parmi les conseils les plus utiles, vous pouvez noter :

Utilisez Codenarc : pour détecter les erreurs les plus courantes, mais aussi pour écrire vos propres règles et les faire respecter au sein de votre équipe.
Dans le cas où vous avez des appels de constructeurs avec un grand nombre de paramètres, utilisez des arguments nommés pour garder un code lisible.
Utiliser GPars pour toute programmation conccurente.
Apprendre à utilise Grab pour gérer les dépendances Groovy de ses scripts.

Les conseils prodigués ont tous été très bien justifiés mais il faudrait un article entier pour tout restranscrire ici. La racine commune à toutes ces bonnes pratiques est : utiliser le langage. Cela peut paraître simpliste mais c’est très vrai. Toute cette présentation ciblait les pratiques héritées du langage Java pur. Groovy, et à plus fort titre avec la version 1.8, fourni de nombreuses syntaxes et annotations permettant de gagner beaucoup de temps et de rendre le code plus lisible. Il faut s’en servir, à fond.

Les slides complet ici.

Conclusion de la première journée : Meet & Greet

Après cette journée bien remplie, tous les participants, speakers et spectateurs, se sont retrouvés autour de bières belges et danoises aux couleurs de la conférence. Ce temps de détente a été l’occasion de discuter des outils, de l’adoption de Groovy dans les entreprises de chacun, de la qualité de la bière danoise… Certains ont même réussi à coincer Peter Ledbrook dans un coin pour une séance de pair programming sur un bug dans le plugin Maven pour Grails. Pendant ce temps d’échange, j’ai eu le plaisir de faire la connaissance de Franck Silvestre, qui participe à la réalisation de l’un des plus gros projet Grails en France : Lilie. C’est un projet destiné au secteur de l’enseignement et sous licence open-source, à voir absolument.

Deuxième journée, rester motivé : Grails Infinispan plugin

Après quelques agapes entre participants la veille, la 2ème journée démarre sur les chapeaux de roues, avec un exposé sur le plugin Grails pour Infinispan, la grille de données estampillée JBoss. Thomas Fuller nous présente des cas d’utilisation qui peuvent pousser à se servir d’une datagrid et quels gains on peut en retirer. Puis il fait le tour du plugin Grails pour s’interfacer avec Infinispan. Les exemples de code donnés sont d’une simplicité à toute épreuve, l’architecture de plugin de Grails est exploité à fond pour le confort du développeur.

Bien évidemment, ce n’est pas n’importe quel projet qui peut avoir besoin d’une datagrid, mais il est bon de savoir que des plugins existent déjà et sont utilisés et maintenus. Je regrette un peu trop de temps passé sur la première partie et la justification de l’utilité d’Infinispan. Le sujet était intéressant et j’aurais aimé voir plus de code que le strict minimum.

Groovy 1.8 Performance Improvements

Ensuite, Jochen Theodorou, alias Blackdrag vient nous parler des optimisations de performances apportées par la version 1.8 de Groovy. Il semble que les gens de chez SpringSource en ai assez de se faire ridiculiser dans les micro benchmarks qu’on peut trouver sur le net. Ils ont donc placé leur effort sur la satisfaction des fétichistes du micro-bench.

Le plupart des micro-bench Groovy contre Java qu’on peut trouver sont basés sur des calculs arithmétiques, comme le célèbre calcul de la suite de Fibonacci. Mais Groovy est un langage dynamique, par conséquent, toutes les opérations mathématiques sont en fait des appels de fonction, ce qui fait l’impasse sur les capacités de la JVM en calcul sur primitives. Les améliorations de performances de la 1.8 sont restreintes aux calculs sur entier et sont encore assez fragiles. Vous n’en profiterez que si vous travaillez sur des entiers sans mélanger les types d’opérations. Si vous lancer un a = b c d, vous êtes dans la zone verte. Si vous lancez a = b + c – d, vous êtes dans la zone rouge.

Pour les prochaines versions de Groovy, Springsource mettra l’accent sur la stabilisation et la généralisation de ces améliorations. A plus long terme, il est prévu de s’appuyer sur le InvokeDynamic fourni par le JDK7.

Les 2 conseils à retenir :

Pour du calcul mathématique, préférez le Java pur
Ne faites pas de micro benchmarks, préférez le prototypage d’application. Il est important de mettre tous les facteurs dans la balance : Confort et rapidité de développment, expérience développeur, statisfaction sur le produit fini.

GORM Optimisations

Burt Beckwith est venu nous parlé des différentes techniques pour optimiser GORM. Il est également auteur des billets « GORM Gotchas » sur le blog de Springsource, à lire absolument pour éviter certains pièges.

Parmi les techniques intéressantes je retiens :

L’utilisation de classes de domaine avec mapping fin pour pointer sur des vues en base.
D’une façon générale, il ne faut pas hésiter à utiliser des classes de domaines contenant en attribut un sous-ensemble des colonnes de la table requêtée. De cette façon, on s’assure de ne remonter ou de mettre à jour que les données utiles.
Définir finement ses mappings dans les classes de domaines permet de customiser au mieux le schéma de la base de données.

De nombreux exemples de cas d’application ont été passés en revue. Une session très intéressante.

Grails Webflow

Pour clore la matinée, Ivo Houbrechts nous a parlé du plugin Grails WebFlow. Il a commencé par une petite démonstration (avec Grails 1.4 SNAPSHOT, derniers commit de la veille au soir). Comme son nom l’indique, ce plugin intègre Spring WebFlow à Grails. Il permet notamment d’obtenir sans effort :

un flow de formulaire, ce qui encourage le découpage en formulaires simples plutôt qu’un unique formulaire énorme.
un fil d’ariane des étapes déjà effectuée, très pratique.
la gestion de la double soumission en cas d’utilisation du bouton ‘Back’ du navigateur

Quelques limitations par rapport à Spring WebFlow :

l’héritage de flow n’est pas supporté
les transisition globales non plus

La DSL de configuration est simple au départ mais peu vite devenir illisible si vous tentez des flow complexes (surtout si vous passez beaucoup de closures en paramètre). Restez autant que possible dans des cas flow simples pour éviter cela.

Grails and Neo4J

La dernière session que j’ai pu suivre a eu pour sujet le plugin Neo4J pour Grails. Stefan Armbruster a commencé par nous rappeler les bénéfices du paysage NoSQL parmi les options de stockage de données. Puis nous a expliqué de quelle façon GORM appliquait le mapping des classes de domaines à une base de données orientée graphes.

Le gros avantage de ce plugin est de s’intégrer de façon transparente avec GORM, ce qui ne rajoute aucune complexité et permet même de tester les résultats d’un remplacement de votre base par Neo4J sans effort. Pour les enthousiastes, faites bien attention à la licence de Neo4J avant de la faire adopter chez vous.

Conclusion

J’ai ensuite dû courir à l’aéroport pour rentrer au pays, en ratant les 2 dernières sessions de la journée. Ces deux journées ont été très riches en enseignement technique mais aussi humain. C’était pour moi une première immersion dans la communauté Groovy et j’en suis revenu convaincu par le langage, les librairies, les outils et la communauté. Il me paraît opportun de conclure en citant les « idées GR8Conf à emporter » (« GR8conf takeaway »), twittées par Dierk König le dernier jour :

Groovy est une place d’innovation
L’outillage Groovy est mature et activement maintenu par des équipes compétentes
Groovy est mainstream, avec un nombre de téléchargement comparable à Spring
La communauté Groovy est accueillante
La communauté Groovy a une attitude orientée « Getting things done » (prouvée par le Hackgarten)

Je ne peux que tomber d’accord. Un grand merci aux courageux qui ont lu jusqu’à la fin. Groovy rocks ! ;-)

Dernière minute : les slides de toutes les conférences sont maintenant disponibles sur SlideShare.