rossi.oddet@dev-institut.fr
Formation Groovy/Grails à Bruxelles
Du 11 au 20 mars, j’ai eu une enveloppe de 5 jours pour permettre à une équipe de monter en compétence sur la stack Groovy/Grails à Bruxelles.
Il s’agissait d’une équipe de 8 personnes ayant des connaissances en Java.
Groovy ?
Groovy est un langage dynamique et fortement typé qui tourne sur la machine virtuelle Java. Il ressemble au premier contact à du sucre syntaxique pour Java. Cette vision simpliste de Groovy s’estompe assez vite lorsqu’on prend la mesure de tout ce que offre le langage.
Groovy fait partie des langages dits “moderne” qui offre d’excellentes options en terme de :
- Scalabilité du code : il est possible d’écrire un script de quelques lignes dans un fichier Groovy ou de développer une application web conséquente
- Support de DSL (Domain Specific Language). Groovy permet de définir de “nouveaux langages” que des experts fonctionnels peuvent prendre en main.
- Surchage des opérateurs. Il possible de redéfinir le comportement des opérateurs usuels (+, -, *, …). Par exemple, vous pouvez créer une entité Tarif (montant, monnaie) et additionner avec l’opérateur + deux objets Tarifs. Cela évite d’avoir à définir des méthodes “additionner”, “soustraire”, …
- Construction simplifié d’objets. Groovy évite au développeur d’avoir à réécrire les traditionnels Getters/Setters, offre un support d’écrire des méthodes toString, equals, hashcode, …
- Injecter du comportement via la notion de closure.
- Et bien d’autres bonus
Grails ?
Grails fait partie de la famille des frameworks dits “productifs” dont le précurseur est Ruby on Rails. Le principe directeur est d’offrir au développeur un cadre de développement regroupant toutes les bonnes pratiques de développement d’une application Web.
Grails est construit autour des briques applicatives Java éprouvées : Spring Framework, Hibernate, …
5 jours pour apprendre Groovy & Grails ?
Beaucoup de formations sur le marché minimise la partie Groovy pour se concentrer sur Grails. Je pense au contraire que la partie Groovy et aussi importante que celle de Grails.
Il est important de pouvoir faire la part des choses entre les fonctionnalités du langage, de celles du frameworks. Cela évite, comme nous pouvons le voir un peu trop souvent, des développeurs qui écrivent du Java dans Grails.
J’ai donc organisé la formation ainsi :
- 2 jours sur le langage Groovy (des basiques à la métaprogrammation en passant par le support des tests unitaires)
- 3 jours sur Grails
Dans l’apprentissage du langage Groovy, nous développons une petite application Swing. Même si Swing n’est plus une technologie très “hype”, il permet de montrer l’intérêt d’un langage comme Groovy pour gérer l’asynchronisme et l’événementiel. Cela donne des idées pour ceux qui voudrait faire du Groovy sur Android.
Après ces 5 jours de formation, les participants trouvent Groovy & Grails “magique” et GGTS (Groovy/Grails Tool Suite) très décevant.
La magie de Groovy et Grails
Le mot “magique” revient souvent pour qualifier Groovy & Grails. Voici quelques exemples de magie :
Vous créer une classe sans getter/setter et vous y avez tout de même accès
Vous déposer une classe “banale” dans le répertoire “domain” de Grails et ça y est vous avez :
- mapper un classe à table
- à disposition des méthodes de CRUD (save, get, …) directement sur les objets de votre classe
- une recherche via l’invocation de méthodes qui n’existent pas (findByNameAndPriceBetween par exemple).
Vous créer une classe dans le répertoire “services” de Grails et toutes les méthodes de cette classe vont être transactionnelles
Cette magie est, de mon point de vue, à la fois une force et une faiblesse de cet écosystème.
En tant que développeur, nous apprécions la magie quand elle fonctionne et nous la détestons lorsque les choses ne se passent pas comme prévues. Débugger quelque chose de magique n’est jamais simple :)
GGTS… Oops
En tant que formateur, j’ai besoin d’un IDE open source et gratuit pour enseigner une technologie. GGTS est le choix naturelle pour un objectif pédagogique.
Ecrire du Groovy dans GGTS me fait penser à écrire du code Javascript dans un éditeur de texte. Oui j’exagère :)
La complétion n’est vraiment pas fiable et souvent trompeuse même pour des constructions simples.
Les participants ont rencontré de nombreux bugs durant la formation, ce qui ne donnent pas une bonne image de l’écosystème.
GSP (Groovy Server Page) pas très séduisant
Dans Grails, les participants ont apprécié toutes les fonctionnalités sauf les vues GSP… La génération de pages web côté serveur vieillit et ce n’est plus trop beau à voir.
Regarder par exemple comment faire un lien qui fait un appel AJAX et met à jour une div.
1 | <div id="message"></div> |
Pour un développeur qui a mis ses pieds dans des technologies front-end, ce code est tout simplement …
En somme
Groovy et Grails ont de beaux atouts de séduction. J’espère que les nouvelles orientations de gouvernance en cours vont permettre de poursuivre les efforts effectués jusqu’ici.
J’ai pris note de quelques bugs dans Grails 2.4.4 concernant le scaffolding dynamique et la définition de layout, je vais vérifier si ces bugs sont bien ouverts dans le JIRA du projet.
