Radio Groovy & Grails eXchange London

Les 13 et 14 décembre, s’est tenue la conférence Groovy And Grails Exchange à Londres. Cet événement rassemble des développeurs venus de toute l’Europe pour y échanger sur Groovy et toutes les technologies basées sur ce merveilleux langage.

J’ai eu la joie d’y participer pour la première fois et je vais tenter de partager cette expérience avec vous. Bien entendu, n’ayant pas le don d’ubiquité, je n’ai pu assister à toutes les sessions. C’est bien dommage, car même avec seulement 2 tracks en parallèle, certains choix ont été déchirants. Cette année, la GGX était clairement placée sous le signe de Grails avec un nombre impressionnant de participants aux sessions dédiées à ce superbe outil, obligeant même les organisateurs à revoir l’attribution des salles en dernière minute.

Follow me…

Groovy Keynote

Comme c’est maintenant la tradition, la conférence est ouverte par Guillaume Laforge, leader du projet Groovy, avec une keynote résumant les dernières avancées du langage Groovy et la roadmap pour les mois à venir. L’actualité du langage en bref :

Décomposition de la librairie Groovy en ensemble de modules pour éviter de charger la planète Groovy en entier
Typage et compilation statique optionnels par annotations
Améliorations drastiques de performance
Nouveaux outils de customisation du compilateur Groovy
Composition d’alias d’annotation pour améliorer la lisibilité de votre code

La vidéo complète est ici.

Puis c’est le premier choix à faire, entre "Grails for Hipsters" et "Jumpstart Griffon". Ceux qui ont déjà lu certains de mes articles connaissent mon choix de cœur pour Grails. J’ai malgré tout du me rabattre sur Griffon: Grails a fait salle comble et l’idée de passer 45 minutes debout avec une mauvaise visibilité ne m’enchantait pas.

Jumpstart Griffon

J’ai donc suivi le "Jumpstart Griffon", présenté par Andres Almiray, et appris plein de choses sur ce sympathique framework. Il s’agit d’un projet très fortement inspiré de Grails (démarré quand Grails en était à sa version 1.0), qui applique les même principes aux applications desktop. Il est donc possible de créer très rapidement et facilement une application Griffon et de générer son applicatif client lourd en Swing, SWT, ou d’autres en fonction des plugins utilisés. Andres nous a fait un point d’avancement du projet avant de se lancer dans une session de live coding.

Pour ceux qui ont laissé de côté les applications Swing il y a un moment, rendez vous compte de ce que représente de pouvoir, grâce à Griffon, réaliser une petite application de gestion de contact from scratch, avec internationalisation et tests unitaires en… 30 minutes !

Griffon bénéficie comme Grails d’un système de plugins bien fourni. Vous aurez notamment accès aux plugins codenarc et coverage pour assurer la qualité de code de votre projet. La structure du projet est sensiblement identique à celle d’un projet Grails (contrôleurs, services, classes de domaines, datasources, etc), à ceci près que les vues, en GSP pour Grails, sont remplacées par une DSL Swing.

Pour les plus frileux, il est également possible de demander à Griffon de générer du code Java plutôt que du code Groovy. Même si je connaissais son existence avant, j’ai vraiment découvert le potentiel de ce framework avec cette session. Il est maintenant aussi simple de monter une application desktop avec Griffon, qu’une application web avec Grails.

Grails for Hipsters

Bien que n’ayant pas été là, je ne pouvais passer sous silence la session qui a certainement fait le record d’audience. Robert Fletcher, auteur de nombreux plugins Grails, a présenté une stack technique à la pointe du hype, en proposant une démonstration basée sur une architecture Grails, AngularJS, Vert.x, avec du server-push, de l’asynchrone, du PhantomJS et autres. C’est certainement la session qui a le plus fait parler et la vidéo complète est là.

Groovy as massive PaaSification

Amadeus, leader mondiale de transactions de voyages et tourisme, est ensuite venu nous parler de son utilisation de Groovy pour passer d’un mode SaaS à un mode PaaS pour leur offre technologique. Ils fournissent un mode SaaS à leur client, afin de leur livrer, clés en main, des sites d’agence complets. Mais la demande croissante en développement spécifique les a amenés à sentir le besoin d’un langage de scripting que leurs clients pourraient utiliser pour consommer plus directement les données de leurs backends. C’est là que Groovy entre en scène.

Grâce à toutes les possibilités de sandboxing du moteur de compilation et de scripting de Groovy, ils ont mis en place un système où leurs clients rédigent eux-mêmes des scripts Groovy, envoyés et interprétés par les serveurs Amadeus. Ils nous ont offert un aperçu large des différents points d’attention dans ce genre de contexte, comme la protection contre les boucles infinies ou le blacklisting de méthodes de la JVM (pour éviter qu’un client appelle System.exit()).

Cette brique est maintenant une partie intégrante et critique de leur SI et ils comptent bâtir dessus en étendant le concept afin de fournir à leur clients une véritable plateforme sur laquelle développer leurs applications, revoir et simplifier les API, etc.

GPars vs. Wild

Après une pause déjeuner et une petite révision, j’ai moi-même présenté un sujet sur l’utilisation de la librairie GPars dans le dernier projet sur lequel j’ai travaillé pour Xebia. Nous avons eu recours à l’implémentation des Actors de GPars. J’ai détaillé la stratégie de design de notre architecture, notre méthode de tests bout en bout et donner mon retour d’expérience sur cette librairie. En bref ? C’est vraiment bien. GPars souffre de quelques manques par rapport à un Akka, qui a plus de kilomètres au compteur, notamment les Actors distribués sur le réseau. Mais si vous avez besoin d’une implémentation d’Actors, prenez le temps de tester GPars, la syntaxe est vraiment très légère et agréable. Un vrai plaisir.

Gradle, the innovation continues

Hans Dockter, le fondateur du projet Gradle et actuel CEO de Gradleware est venu nous parler du chemin parcouru depuis la version 1.0. Pour ceux qui l’ignorent encore, Gradle est un outil de build qui enterrera Maven (en toute objectivité bien sûr). Gradle apporte de l’innovation dans un secteur d’outillage qui ne bouge que très peu au fil des ans, Maven étant le standard de-facto et Ant la boite à outil universelle. Gradle a apporté, depuis juin :

L’exécution de tâches en parallèle
Des améliorations importantes sur l’analyse et le reporting des dépendances d’un projet
Le support Android
La compilation incrémentale Scala
Des outils de comparaison de build pour accompagner les montées de version de Gradle sur un projet

C’est presque gêné que Hans nous explique que Gradleware préfère accompagner le changement en le documentant et en fournissant des outils, plutôt que d’assurer à tous prix la compatibilité ascendante. C’est à mon sens très courageux d’être porteur d’innovation à ce point.

Hackergarten

La journée s’est terminée tranquillement par une discussion ouverte autour des technologies Groovy, et par un Hackergarten ou certains ont pu réfléchir aux prochains plugins Grails auquels ils souhaitaient contribuer, ou participer à une bugfix party sur d’autres projets.

Grails Keynote

La deuxième journée s’ouvre avec une Keynote par Graeme Rocher, le leader du projet Grails. Il est revenu sur l’état du projet. Il semble que Grails séduise de plus en plus de développeurs, puisque la fréquentation est en forte hausse aux conférence Groovy & Grails, particulièrement aux sessions Grails. Le projet tient ses promesses de release régulières, le site du projet a été refondu, toujours en Grails, pour améliorer le portail de plugins.

Le portail de plugins permet une plus grande participation de la communauté en offrant un espace review, pour faire des remarques aux porteurs des plugins. On sent une forte inclinaison vers la communauté des développeurs Grails pour mener le projet dans le sens préféré par les premiers concernés. En résumé, s’il ne fallait retenir que quelques informations par version de Grails :

2.0 : GORM API, l’ORM de Grails devient une API et voit arriver plusieurs implémentations en MongoDB, RIAK, Neo4J et d’autres bases NoSQL
2.1 : amélioration de l’intégration Maven, fortement demandée par les utilisateurs
2.2 : (actuellement en RC, dans les bacs avant fin janvier) arrivée de Groovy 2.0 et de la compilation statique dans le code de Grails, plus d’asynchrone
2.3 : (prévue pour 2013) plus d’intégration de Groovy 2.0, encore plus d’asynchrone
3.0 : intégration de Gradle

Le futur s’annonce radieux pour le projet, d’autant plus s’il se diffuse plus largement.

Contribute back to grails

Bobby Warner a présenté une session didactique sur "Comment contribuer au projet Grails". Il a commencé par décomplexer l’auditoire sur la définition de contribution :

Participer aux mailing lists
Remplir des rapports de bug
Écrire des billets de blogs
Donner du feedback
Mettre à jour la documentation

Tout cela est contribuer, au même titre que commiter du code sur le projet. Il a enchainé sur un screencast commenté montrant les différentes étapes pour faire des pull-request pour Grails, avant de se lancer dans des contributions en direct : 6 pull requests en 20 minutes. Une performance bien huilée. Nous avons même eu la surprise d’en voir une acceptée avant même la fin de la présentation. Une session très instructive qui rappelle, s’il en était besoin que contribuer n’est pas forcément un sacerdoce, mais qu’on peut aussi apporter sa petite pierre à l’édifice et ainsi appliquer la règle scout.

Why Groovy when Java8, Scala or whatever

Russel Winder est un orateur de premier ordre. Si un jour vous avez l’occasion, allez voir une de ses présentations, ça vaut le coup d’oeil. Après avoir introduit son sujet avec War Pigs de Black Sabbath, il nous a décrit le champ de bataille entre les langages typés statiquement et les langages typés dynamiquement. Mettant en regard les ressemblances entre les idiômes de traitement parallèles dans les 2 camps. Groovy se place au centre de ce champ de bataille, puisqu’il offre maintenant un choix entre typage dynamique et statique, dans la même base de code.

Il a lourdement insisté sur l’urgence à passer à Java 8, car Java 6 est mourant et Java 7 n’aura pas beaucoup de temps à vivre. Il a mis en garde la communauté Groovy sur l’importance de promouvoir Groovy pour ses qualités car l’arrivée de Java 8 pourrait conforter les gens dans le fait qu’ils n’ont qu’un unique langage à maitriser : Java lui-même. La syntaxe, l’écosystème, la communauté, tout pousse à rendre ce langage attrayant. Cependant, les réticents seront surement tentés de se passer des raffinements de Groovy si Java8 leur offre une partie des innovations de Groovy sans sortir de la langue natale de la JVM.

Un bon conseil à mon avis : Groovy c’est bon, mangez-en.

Building e-commerce website with GR8 techs

Pour terminer la conférence en beauté, Domingo Suarez est venu de son lointain Mexique pour nous parler d’une success story basée sur les technologies Groovy. ClickOnero est une plateforme d’e-commerce sur le même principe qu’Amazon. Ils ciblent les marché d’Amérique centrale, Amérique du sud, et Europe centrale, avec des déploiements en "marques grises" locales.

Développé, en Grails, et sous pression, en 2 mois à 4 développeurs répartis sur la planète, la première version remplit le job mais ne les satisfait pas tout à fait : trop peu de tests, des requêtes pas optimisées, des performances moyennes.

Le plugin JavaMelody, utilisé en production, leur a permis d’identifier les principaux goulots d’étranglements dans leur code et d’avoir un point de départ pour optimiser.

Ils ont poussé le refactoring jusqu’à une architecture basée sur 3 piliers :

une application ChaplinJS, baptisée HipStore, servie par un serveur Apache
une application Grails servant de backend JSON, consommé par HipStore et les partenaires de ClickOnero
une application Grails d’administration

Comme souvent, avec les applications JavaScript single-page, s’est posé le problème du référencement par les moteurs de recherche. La solution adoptée ici a été de faire passé les modifications de contenu par l’application d’administration, qui envoie un message via RabbitMQ à une application NodeJS, qui déclenche des scripts ZombieJS pour crawler les nouvelles pages et enregistrer le HTML généré sous forme de fichiers statiques intégrés au serveur Apache. De cette façon, chaque URL gérée par HipStore, si elle est accédée directement, fourni un fichier statique complet indexable.

Vous pouvez voir sur la photo l’impact à la baisse sur le taux de rebond de leur site, et à la hausse sur la durée de vie moyenne des sessions utilisateurs. Impressionnant !

La solution actuelle de clickOnero tourne en production sur 3 serveurs dual-quadcore avec 24G de RAM et 300G de stockage NAS chacun, hébérgés en dédiés chez RackSpace. Cette configuration encaisse honorablement les 1.5M de visites quotidiennes avec 80 000 utilisateurs concurrents et une base de 5M d’utilisateurs. ClickOnero a été sacrée "Ecommerce company of the year" au Mexique. La solution a été déclinée également sous d’autres marques en Amérique du sud et Europe centrale.

Une bien belle histoire, merci à Domingo d’avoir fait le déplacement pour nous la raconter.

See you soon

Parmi les session dont je n’ai pas relaté le détail, il y avait également :

du Vert.x, le NodeJS killer
du Spock, le framework de test qui enterre JUnit
des techniques DSL avancées
de la sécurité en Grails

Je vous invite à vous rendre sur le planning complet de la conférence, toutes les sessions ont été filmées et sont accessibles.

Encore un grand merci à SkillsMatter et à son équipe pour l’hébergement de cet événement et à SpringSource pour le sponsoring. Durant cette conférence, j’ai rencontré des gens brillants, motivés et actifs dans la communauté. J’ai découvert le potentiel de nouveaux outils, et approfondi ma connaissance de ceux que j’utilise déjà.

Je conseille fortement à tous les gens motivés de participer à la prochaine instance, cette conférence vaut le déplacement. Si vous n’avez jamais fait de Groovy, vous avez le temps de tester d’ici là, ou de venir pour partager la lumière.