Le Touilleur Express » groovy

Traitement du XML en Groovy

Nicolas Martignole — Sun, 14 Feb 2010 15:55:40 +0000

Groovy est un langage particulièrement adapté lorsqu’il s’agit de traiter des fichiers plats. Pour rédiger le 500ème billet du blog, j’ai exporté au format WXR (WordPress eXtended RSS) l’ensemble des billets. Cela donne un gros fichier XML de 75 762 lignes que vous pouvez télécharger ici.

Lire un fichier XML avec Groovy

Pour ouvrir et lire un fichier XML avec Groovy, rien de plus simple. Il existe 2 classes principales : XmlSlurper et XmlParser. Aujourd’hui nous ne verrons que le premier.
La structure du fichier XML utilise le format WXR (WordPress eXtended RSS format). J’ai dû adapter et corriger quelques coquilles pour que le fichier puisse être parsé correctement.

Voyons tout d’abord comment lire un fichier XML en Groovy :

def file = new File("wordpress.2010-02-14.xml")
def root=new XmlSlurper().parse(file)

Plutôt simple non ?

Si nous prenons cette structure XML par exemple :




	Le Touilleur Express
        ...
        
            // un article
        
        
            // un article

L’accès à un attribut est très simple en Groovy. Voici comment afficher le titre du blog et comment afficher le nombre d’items de la balise channel:

def file = new File("wordpress.2010-02-14.xml")
def root=new XmlSlurper().parse(file)

println "Blog title : "+root.channel['title']

println "Number of RSS items : "+root.channel.item.size()

nicolas@localhosr> groovy readXml.groovy
Blog title : Le Touilleur Express
Number of RSS items : 805

Itérer des noeuds

L’itération des noeuds XML s’effectue à l’aide de closure. La structure RSS de l’ensemble des articles est construite autour du noeud « item ». WordPress y ajoute un ensemble d’attributs, ce qui permet de distinguer les articles publiés des brouillons, de distinguer les images téléchargées des pages, etc.

Prenons cet exemple de code :

def file = new File("wordpress.2010-02-14.xml")
def root=new XmlSlurper().parse(file)

root.channel.item.each{it->
	if(it.post_type.text().equals("post")){
		if(it.status.text().equals("publish")){
			println (it.title.text(),"UTF-8")
		}
	}
}

L’élément CHANNEL est constitué d’une collection d’ITEM. Pour chacun de ces ITEMs je récupere la valeur de l’attribut TITLE. Enfin l’accesseur text() permet de récupérer le titre de l’article du Touilleur Express.
Le format d’entrée est UTF-8. Lors de l’exécution sur Mac, l’encoding de la plateforme étant par défaut MacRoman, les caractères accentués entre autre ne sont pas correctement affichés. Nous verrons tout à l’heure comment spécifier le format de sortie.

Générer un nouveau fichier au format HTML

Maintenant que vous savez lire un fichier XML, itérer des noeuds, pouvez-vous m’écrire quelques lignes pour générer une page HTML avec la liste des articles, un lien vers l’article et la date de publication ?

Voici le fichier d’entrée :





	Le Touilleur Express
		
			Article classique
			post
			publish
			http://www.touilleur-express.fr/2003/11/22/pourquoi-java-sappelle-java/
			Sat, 22 Nov 2003 09:28:40 +0000
		
		
			Article de brouillon
			post
			draft
			http://www.touilleur-express.fr/
			Sat, 22 Nov 2003 09:28:40 +0000
		
		
			Page wordpress
			page
			publish
			http://www.touilleur-express.fr/
			Sat, 22 Nov 2003 09:28:40 +0000

Votre script Groovy doit parser le fichier XML ci-dessus, et générer ce fichier HTML :



Le Touilleur Express articles



Article classique publié le Sat, 22 Nov 2003 09:28:40 +0000

Allez au boulot, à vous de travailler. Je vous posterai la réponse un peu plus tard.

Groovy++, une version typée statiquement de Groovy

Nicolas Martignole — Mon, 08 Feb 2010 09:45:29 +0000

Mi-décembre, Alex Tkachman et Eugene Vigdorchik ont lancé un projet appelé Groovy++ (prononcez Groovy Booster). L’idée de ce projet est de créer une version typée statiquement de Groovy afin d’obtenir de meilleures performances et la vérification à la compilation de votre programme, tout en gardant l’expressivité et la souplesse de Groovy. Cela donne aussi un boost en terme de performances, sachant que l’idée est aussi de générer du code optimisé capable d’utiliser finement les librairies Java existantes. Les auteurs parlent même de surpasser Java, ce qui semble un peu surprenant au premier abord.

Alex dit :

To make a long story short « statically typed Groovy » (aka Static Groovy, aka Groovy Booster, aka Groovy++) is an atempt to combine performace and compile-time checks with the expressiveness of the Groovy programming language and to develop high-performant runtime libraries utilizing this combination.

Il ne s’agit pas d’un nouveau langage, mais d’une option capable d’accélérer les applications Groovy comme Grails d’ailleurs. Pour cela il suffit d’ajouter un JAR et d’annoter ses classes Groovy avec @Typed pour bénéficier de l’effet Groovy++.

Voici un script Groovy écrit par Alex qui parcourt une arborescence de fichier, ouvre chacun des articles, compte le nombre d’occurence de différents mots et stocke le tout dans 2 fichiers triés par ordre croissant et décroissant. Il y a en fait 2 tâches : la collecte des mots d’une part, et le rangement d’autre part.


package org.mbte.groovypp.examples.wordcount

for (i in 0..<10) {
    t1 = System.currentTimeMillis()
    counts = [:]
    new File("./20_newsgroups").eachFileRecurse{ f ->
      if (!f.isDirectory() && !f.path.contains(".svn")) {
      f.text.toLowerCase().eachMatch(/\w+/) { w ->
          def c = counts[w] ?: 0
          counts[w] = c + 1 } } }
    new File("counts-descreasing-groovy").withWriter { out ->
      counts.sort { a, b -> b.value < => a.value }.each { k, v -> out < < "$k\t$v\n" } }
    new File("counts-alphabetical-groovy").withWriter { out ->
      counts.sort { it.key }.each { k, v -> out < < "$k\t$v\n" } }
    println "Finished in ${System.currentTimeMillis() - t1} millis"
}

D'après les tests d'Alex sur un MacBookPro, ce script tourne en moyenne en 55 secondes avec un volume de 25 Mb. Les détails et le code sont disponibles ici si vous voulez creuser un peu plus.

Avec Groovy il est possible de traiter en parrallèle la partie collecte des mots, et la partie comptage-reporting. Voici la version avec l'annotation @Type de Groovy++ qui s'exécute un peu plus rapidement, mais pas comme en 5.5 secondes comme dit Alex sur son blog. Je ne suis pas d'accord avec ses chiffres.

@Typed package org.mbte.groovypp.examples.wordcount

import java.util.concurrent.*
import groovy.util.concurrent.*

for (i in 0..<10) {

    def t1 = System.currentTimeMillis()
    def pool = Executors.newFixedThreadPool(30)
    def counts = new AtomicIntegerMap ()

    new File("./20_newsgroups").recurseFileIterator().filter{ file ->
        !file.directory && !file.path.contains(".svn")
    }.each(pool,4) { file ->
        file.charSequence.eachMatch(/\w+/) { String w -> w = w.toLowerCase()
            counts[w].incrementAndGet ()
        }
    }.whenBound {
        pool.execute {
            new File("counts-descreasing-groovy").withWriter { Writer out ->
              counts.asList().sort { a, b -> b.get() < => a.get() }.each { e -> out < < "$e.key\t${e.get()}\n" }
            }
        } {
            new File("counts-alphabetical-groovy").withWriter { Writer out ->
              counts.asList().sort { a, b -> b.key < => a.key }.each { e -> out < < "$e.key\t${e.get()}\n" }
            }
        }
        pool.shutdown()
    }

    pool.awaitTermination(30,TimeUnit.SECONDS)
    println "Finished in ${System.currentTimeMillis() - t1} millis"
}

Notez l'utilisation de la class Executors et de la mise en parrallèle du traitement. Une seule Thread principale démarre et itère chaque fichier. Une fois le traitement de celui-ci terminé, après compté le nombre de mot, la génération des rapports est déléguée à 4 threads en parrallèle. Sympa non ?

Voici enfin pour terminer la version Java:

public class JavaWordCount {
        public static void main(String[] args) throws IOException {

                for (int i = 0; i < 10; ++i) {
                        Comparator> sortByCount = new Comparator>() {
                                public int compare(Map.Entry o1, Map.Entry o2) {
                                        return o2.getValue() - o1.getValue();
                                }
                        };
                        Comparator> sortByElement = new Comparator>() {
                                public int compare(Map.Entry o1, Map.Entry o2) {
                                        return o1.getKey().compareTo(o2.getKey());
                                }
                        };
                        Long timeStart = System.currentTimeMillis();
                        Pattern wordPattern = Pattern.compile("\\w+");
                        File rootDir = new File("./20_newsgroups");
                        CountingSet counter = new CountingSet();
                        for (File groupDirectory : rootDir.listFiles()) {
                                if (groupDirectory.isDirectory() && !groupDirectory.getPath().contains(".svn")) {
                                        for (File f : groupDirectory.listFiles()) {
                                                if (f.isFile() && !f.getPath().contains(".svn")) {
                                                        BufferedReader reader = new BufferedReader(new FileReader(f));
                                                        String line;
                                                        while ((line = reader.readLine()) != null) {
                                                                Matcher matcher = wordPattern.matcher(line);
                                                                while (matcher.find()) {
                                                                        counter.add(matcher.group().toLowerCase());
                                                                }
                                                        }
                                                        reader.close();
                                                }
                                        }
                                }
                        }

                        Writer pw = new BufferedWriter(new PrintWriter("./counts-alphabetical-java.txt"));
                        sortAndDisplay(counter.entrySet(), sortByElement, pw);
                        pw.close();

                        pw = new BufferedWriter(new PrintWriter("./counts-decreasing-java.txt"));
                        sortAndDisplay(counter.entrySet(), sortByCount, pw);
                        pw.close();

                        System.out.println("Finished in " + (System.currentTimeMillis() - timeStart) + " ms");
                }
        }

        private static void sortAndDisplay(Set> set, Comparator> comp, Writer writer) throws IOException {
                List> list = new ArrayList>(set);
                Collections.sort(list, comp);
                display(list, writer);
        }

        private static void display(Iterable> list, Writer writer) throws IOException {
                for (Map.Entry entry : list) {
                        writer.write(entry.getKey() + " : " + entry.getValue() + "\n");
                }
        }

        private static class CountingSet extends LinkedHashMap {
                void add(String s) {
                        Integer i = get(s);
                        put(s, (i == null) ? Integer.valueOf(1) : Integer.valueOf(i + 1));
                }
        }
}

Le code Java n’est pas particulièrement optimisé, mais il a le mérite de montrer plusieurs choses. Tout d’abord l’utilisation des APIs Java, ensuite le fait que Java n’est pas adapté à ce type de traitement lorsque l’on regarde le code source. Oui cela fonctionne, mais ce n’est pas simple à lire.

Mes propres tests
Du côté des performances voici mes propres résultats avec une arborescence de fichiers Groovy d’un projet assez important.
Comptons tout d’abord sous Unix le nombre de fichiers :

nicolas@macbookpro> find . -type f  | wc -l
     2467

Cela représente un volume de 38 Mo de fichiers Java, Groovy, de pages JSP, bref un projet complet, tel qu’un outil de compilation comme Maven ou Graddle pourrait devoir traiter par exemple.

J’ai fait 3 tirs de la version Java. Chaque tir est une série de 10 tests. Le premier test est assez lent car le système fait réellement un accès disque pour charger les fichiers, le test s’exécute en 190ms en moyenne pour la version Java. J’ai donc supprimé à chaque fois pour l’ensemble de mes tests la valeur la plus lente et la valeur la plus rapide, afin de lisser les échantillons de tests.

Voici le script de la version Groovy++ que j’ai légèrement modifié :

@Typed(TypePolicy.MIXED)
package test
class Boosted {
    static main(args){
		for (i in 0..<10) {
		    def t1 = System.currentTimeMillis()
		    def counts = [:]
		    new File(".").eachFileRecurse
		    {
			  f ->
		      if (!f.isDirectory() && !f.path.contains(".svn"))
		      {
		        f.text.toLowerCase().eachMatch(/\w+/) { w ->
		          def c = counts[w] ?: 0
		          counts[w] = c + 1
		          }
		       }
		    }
		    new File("counts-descreasing-groovy").withWriter { out ->
		      counts.sort { a, b -> b.value < => a.value }.each { k, v -> out < < "$k\t$v\n" } }
		    new File("counts-alphabetical-groovy").withWriter { out ->
		      counts.sort { it.key }.each { k, v -> out < < "$k\t$v\n" } }
		    println "${System.currentTimeMillis() - t1}"
		}
  	}
}

Groovy++ est distribué sous la forme d’un ZIP. Il suffit de le décompresser, de remplacer sa variable GROOVY_HOME pour qu’elle pointe vers cette version, de mettre à jour son PATH et c’est tout. J’ai eu à augmenter les options Java pour résoudre un problème de OutOfMemory (export JAVA_OPTS= »-Xmx512m ») mais à part cela, c’est du Groovy classique.

Voici la moyenne des résultats ma machine (MacBookPro 2.4Ghz Intel Core 2 Duo, 4GB) pour la version Java, la verson Groovy et la version Groovy++

Java 1.6.0.17 64-bits : 58,71 ms Groovy 1.6.0 : 5839,58 ms Groovy ++ 0.1.12: 3858,75 ms

Mes propres tests montrent que la version Groovy++ est plus rapide de 34% par rapport à la version Groovy. Java reste largement plus rapide que la version Groovy et la version Groovy++. Tout ceci est fait avec un micro-test, ce qui n’est pas suffisant pour dire que l’un est plus rapide que l’autre. Mais cela me refait penser à Graddle, un outil de build Groovy, très sympa à utiliser, mais pour lequel j’avais une réserve à priori, sans avoir effectué de tests.

Voyons enfin ce que cela donne avec la version 4 Threads d’Alex. Le script est modifié afin d’effectuer la partie reporting en parrallèle.

@Typed(TypePolicy.MIXED)
package test

import java.util.concurrent.*
import groovy.util.concurrent.*

class BoostedOptimized {
    static main(args){
		for (i in 0..<10) {

		    def t1 = System.currentTimeMillis()
		    def pool = Executors.newFixedThreadPool(30)
		    def counts = new AtomicIntegerMap ()

		    new File(".").recurseFileIterator().filter{ file ->
		        !file.directory && !file.path.contains(".svn")
		    }.each(pool,4) { file ->
		        file.charSequence.eachMatch(/\w+/) { String w -> w = w.toLowerCase()
		            counts[w].incrementAndGet ()
		        }
		    }.whenBound {
		        pool.execute {
		            new File("counts-descreasing-groovy").withWriter { Writer out ->
		              counts.asList().sort { a, b -> b.get() <=> a.get() }.each { e -> out << "$e.key\t${e.get()}\n" }
		            }
		        } {
		            new File("counts-alphabetical-groovy").withWriter { Writer out ->
		              counts.asList().sort { a, b -> b.key <=> a.key }.each { e -> out << "$e.key\t${e.get()}\n" }
		            }
		        }
		        pool.shutdown()
		    }

		    pool.awaitTermination(30,TimeUnit.SECONDS)
		    println "${System.currentTimeMillis() - t1}"
		}
  	}
}

J’ai effectué 3 séries de 10 tests, voici la synthèse:
Java 1.6.0.17 64-bits : 58,71 ms
Groovy 1.6.0 : 5839,58 ms
Groovy ++ 0.1.12 : 3858,75 ms
Groovy++ 4 Threads : 2129,17ms

La version 4 Threads est donc 63,54% plus rapide que la version Groovy de base. Cependant je pense que c’est une erreur de les comparer, l’algo étant différent. Nous devons simplement retenir l’écart entre la version Groovy standard et la version exécutée avec Groovy Booster qui est de 33%. C’est déjà beaucoup.

Groovy++ est un projet intéressant, qui montre qu’il est possible d’accélérer Groovy. Je serai intéressé de savoir le retour de Guillaume Laforge sur le sujet. Il faut aussi noter qu’il y a quelques bémols, l’utilisation de Groovy++ empêche d’utiliser quelques mots clés comme l’opérateur de transtypage « as » (« -1″ as Integer par exemple).

Enfin pour terminer, d’après les billets que j’ai vu, la version Scala est exactement aussi rapide que la version Java, il n’y a aucunes différences. C’est aussi l’avantage d’un langage avec typage fort, nous reparlerons de Scala bientôt.

Les tableaux de résultat :

Sources
Mail d’Alex à la liste Grails
First preview of static compiler for Groovy is available
How come that Groovy++ overperform Java?

Gym avec Groovy, exercice 1

Nicolas Martignole — Tue, 26 Jan 2010 07:59:09 +0000

Merci de participer ce matin à notre petite série d’exercice sur Groovy. Après un échauffement, nous allons travailler les abdos-fixtures, faire quelques moulinets de Closures, s’étirer avec des astuces sur les fichiers, bref que du bon code pour débuter. Je vous prends en main cette semaine, avec chaque jour un petit exercice simple afin de vous réhabituer à un bon langage, léger
Après avoir pris votre tapis… de souris, venez vous assoir devant moi, et écouter attentivement. Les exercices sont adaptés du livre « Groovy Recipes » par Scott Davis pour ceux qui veulent pratiquer de leur côté.

La surchage pondérale d’opérateur

Grâce à Java, je sais que ce petit problème de surcharge pondérale n’était plus trop d’actualité. Pourtant nous allons voir ensemble qu’avec Groovy, la surcharge d’opérateur est une chose très pratique. Pour cela, nous allons travailler avec la date.

Notre série d’exercices se déroulera dans une salle toute neuve hébergée sur Google App Engine (prononcez eng-i-neu) développée avec Gaelyk par Guillaume Laforge. Ouvrez donc la Groovy Web Console et débutons par quelques exercices simples pour travailler la surcharge d’opérateur. Tapez simplement le texte ci-dessous puis appuyez sur « Execute script« . Je note avec le symbole « => » le résultat de l’opération.

def today=new Date()

=> Mon Jan 25 07:57:43 UTC 2010

La surcharge d’opérateur est une fonction très pratique en Groovy. Imaginons que vous souhaitez connaître la data dans 7 jours. L’opérateur ‘+’ étant surchargé dans le cas d’une Date, il est alors possible d’écrire ce code:

def today=new Date()
println today
=> Tue Jan 26 08:28:33 UTC 2010

def tomorrow=today.next()
println tomorrow
=> Wed Jan 27 08:28:33 UTC 2010

def nextWeek=tomorrow+7
println nextWeek
=> Wed Feb 03 08:28:33 UTC 2010

def yesterday=today.previous()
println yesterday
=> Mon Jan 25 08:28:33 UTC 2010

Derrière l’opérateur plus, Groovy appelle la fonction next(). Voici une liste des opérateurs et des méthodes correspondants à ces opérateurs en Groovy :

Opérateur		Méthode
a==b or a!=b	a.equals(b)
a + b	 		a.plus(b)
a - b			a.minus(b)
a * b			a.multiply(b)
a / b			a.div(b)
a % b			a.mod(b)
a++ ou ++a		a.next()
a-- ou --a		a.previous()
a & b			a.and(b)
a | b			a.or(b)

Les opérateurs suivants sont plus communs, surtout lors de la manipulation des Listes :

Opérateur		Méthode
a[b]			a.getAt(b)
a[b]=c			a.putAt(b,c)
a << b			a.leftShift(b)
a >> b			a.righShift(b)
a < b ou a > b 	a.compareTo(b)
a <= b / a >= b	a.compareTo(b)

La manipulation des listes est encore plus simple en Groovy qu’en Java. Il est donc possible d’écrire par exemple ce bout de code (tiré du livre Groovy Recipes par Scott Davis).


def today=new Date()

(1..7).each{
println today++
}

=>
Mon Jan 25 09:31:41 CET 2010
Tue Jan 26 09:31:41 CET 2010
Wed Jan 27 09:31:41 CET 2010
Thu Jan 28 09:31:41 CET 2010
Fri Jan 29 09:31:41 CET 2010
Sat Jan 30 09:31:41 CET 2010
Sun Jan 31 09:31:41 CET 2010

Note: Ce code ne marchera que sur votre machine en local en utilisant groovyConsole.

Passage sur le dos, parlons des listes

Avez-vous noté la notation (1..7) dans l’exercice précèdent ? C’est ce que l’on appelle une Range en Groovy. Pratique non ?

Passons à un exercice plus intéressant, et plus proche de ce que vous allez pratiquer avec Groovy d’ici quelques semaines : la manipulation des listes, des Maps et des Sets en Groovy.

Création d’une liste

La syntaxe est simple. Une liste est créé en utilisant les crochets. C’est une ArrayList simple, ni plus, ni moins.

def touilleurThemes=["Java","Apple","Scrum","Groovy"]

println touilleurThemes
=> [Java, Groovy, Scrum, Apple]

println touilleurThemes.size()
=> 4

touilleurThemes << "Web 2.0"
println touilleurThemes
=> [Java, Groovy, Scrum, Apple,Web 2.0]

// Récuperer le premier élement
println touilleurThemes.first()
=> Java
println touilleurThemes[0]
=> Java

Itérer une liste en Groovy

Les closures sont utilisées lors de l’itération d’une liste. Voici quelques exemples d’itérations de la liste :

// Itération simple
def touilleurThemes=["Java","Groovy","Scrum","Apple"]
touilleurThemes.each{nom->
 println nom
}
=>Java
Groovy
Scrum
Apple

// Verson simplifié, it est une variable implicite
// Itération encore plus simple
def touilleurThemes=["Java","Groovy","Scrum","Apple"]
touilleurThemes.each{
 println it
}

Il reste possible d’itérer la liste en utilisant la syntaxe de Java 5 si vous préférez celle-ci :

def touilleurThemes=["Java","Groovy","Scrum","Apple"]
for(String item : touilleurThemes) {
println item
}

=>Java
Groovy
Scrum
Apple

Trier, ranger, manipuler une liste

Les listes sont des objets facilement manipulables. Il est possible de les trier, de les découper, de dépiler un élément comme sur une Queue, de rechercher un pattern, bref de faire un grand nombre d’opérations très pratique. Plutôt qu’un long discours, regardez attentivement ces exemples de code. Vous me ferrez 2 séries de 10, avec une grande respiration entre chaque exercice.


// Trier une liste avec sort
// Le tri est permanent, la liste originale est triée
def languages=["Java","Groovy","Scala","Lisp","Clojure","Perl","Python"]
languages.sort()
languages.each{ println it }

=>Clojure
Groovy
Java
Lisp
Perl
Python
Scala

// Retourner une liste, cette fois-ci la liste originale
// ne sera pas modifiée.
def revertedList=languages.reverse()
revertedList.each{ println it }

=>
Scala
Python
Perl
Lisp
Java
Groovy
Clojure

// 3 Dépiler le dernier élément
def languages=["Java","Groovy","Scala","Lisp","Clojure","Perl","Python"]
println  languages.pop()
=> Python

// 4 Concatenation
def languages=["Java","Groovy","Scala","Lisp","Clojure","Perl","Python"]
def newLanguages=["Ruby","Goo","Javascript"]

languages+=newLanguages
println languages
=> [Java, Groovy, Scala, Lisp, Clojure, Perl, Python, Ruby, Goo, Javascript]

languages-=newLanguages
println languages
=> [Java, Groovy, Scala, Lisp, Clojure, Perl, Python]

Il est possible aussi de joindre une liste en une seule String, ou même de spécifier un séparateur par exemple. Très pratique lorsque vous souhaitez écrire une ligne au format CSV à partir d’une liste de résultats :

def languages=["Java","Groovy","Scala","Lisp","Clojure","Perl","Python"]

println languages.join()
//JavaGroovyScalaLispClojurePerlPython

println languages.join(",")
//Java,Groovy,Scala,Lisp,Clojure,Perl,Python

Les closures peuvent aussi être utilisées pour rechercher un élément rapidement dans une liste. Imaginons que vous souhaitez retrouver l’ensemble des noms commençant par la lettre J :

def languages=["Java","Groovy","Scala","Lisp","Clojure","JRuby","Jython"]
def resultList = languages.findAll {it.startsWith("J")}
resultList.each{println it}

=>Java
JRuby
Jython

Les listes de chiffres sont faciles à manipuler, il est possible d’additionner la série, de rechercher la valeur maximum ou minimum :

def ages=[23,34,45,12,46,21,42,56,18]

println ages.max()
=> 56
println ages.min()
=> 12
println ages.sum()
=> 297
println "Moyenne: " + ages.sum()/ages.size()
=>33

La méthode collect permet de créer une nouvelle liste en concaténant un Objet à chacun des éléments de la liste initiale.

def ages=[23,34,45]
def resultList=ages.collect{ it += " ans"}
resultList.each{println it}

=>23 ans
34 ans
45 ans

L’opérateur Spread (*)

L’opérateur Spread (marqué avec une astérisque *) est un opérateur courant utilisé pour exécuter une méthode sur chacun des éléments d’une liste, ou pour aussi distribuer les éléments d’une liste à une méthode. Il y a 2 variantes. L’opérateur spread seul (*) et l’opérateur spread-dot (noté *.).
L’opérateur spread seul peut être utilisé pour passer une liste d’argument à une méthode. Il va itérer chacun des éléments et les passer un à un. C’est peu commun donc je n’en parlerai pas plus ici. L’opérateur spread-dot est plus courant. Dans l’exemple ci-dessous, le caractère *. signifie : prend chacun des éléments de la liste et effectue un appel à la méthode toUpperCase, stocke le tout dans une nouvelle liste.

def languages=["Java","Groovy","Goo"]

// L'opérateur Spread dot
def resultList=languages*.toUpperCase()

// Affiche la nouvelle liste
resultList.each{println it}

=> JAVA,
GROOVY,
GOO

Conclusion

Voilà c’est tout pour ce matin. Nous verrons la suite demain. Passez une bonne journée !

Grails en quelques mots

Nicolas Martignole — Fri, 18 Dec 2009 23:31:00 +0000

Je travaille depuis quelques mois avec le framework Web Grails. Cela fait quelques semaines que je m’en sers presque 8 heures par jour. Je vous propose un petit tour du propriétaire.

Grails est un framework Web basé sur le langage Groovy clairement orienté productivité. J’ai ramené 4 livres de Devoxx sur Groovy et Grails, et le meilleur ouvrage pour rentrer dedans reste « Grails in Action » de Glen Smith et Peter Ledbrook. 470 pages plus tard vous serez en mesure de construire une application industrielle, et il vous manquera un peu de détails sur Groovy, facilement couvert par exemple avec « Groovy Recipes » de Scott Davis.

Grails s’installe en 5 minutes, se découvre en 30 minutes et se maîtrise en une semaine. Je me dis que si mon aventure de Startup ne marche pas, je pourrai toujours écrire un livre sur le sujet en Français. C’est vous dire si j’ai envie de vous en parler.

Introduction à Grails
Grails m’est tombé dessus car j’avais besoin d’une solution pour démarrer rapidement, valider rapidement (et éventuellement me planter rapidement). Je me surprends à tester des bouts de code, à écrire des choses comme « Books.findByAuthor(‘Guillaume Laforge’) » et à voir que Grails génère le code de ce finder pour moi… Envie d’Ajax ? je transforme mes tags form en remoteForm et ça marche. Envie de faire un formulaire avec 4 écrans ? Spring Webflow est intégré, le flow est écrit en Groovy, rien de plus simple… Et c’est comme cela depuis 3 semaines… Je n’arrête pas de m’étonner de la maturité et de la puissance de ce framework Web.

Avec ou sans état ?
Grails comme Play! se classe dans la catégorie des frameworks Webs sans état. Il y a bien entendu une session, des scopes pour vous aider à travailler. Mais là où Wicket et JSF sont orientés composants, Grails est clairement orienté Web / HTTP. Il n’y a pas la notion d’Application et il n’y a pas la notion de composants comme en Wicket ou JSF2 par exemple. Nous pouvons donc dire que Grails est adapté pour la réalisation de projets plutôt Web, et il n’est pas forcément le plus adapté pour réaliser une application riche. Il y a pourtant des applications basées sur du Flex pour la couche de présentation qui travaillent avec une partie serveur en Grails pour les services. Cette alchimie fonctionne donc aussi.

Fan des conventions au lieu de la configuration
Grails tire ses origines du framework Rails du monde Ruby. Mais il utilise le langage Groovy qui tourne sur la JVM. Ses cousins ? JRuby on Rails, Clojure, le framework Lift du monde Scala, et Play! du monde Java. C’est un framework Web clairement orienté productivité et simplicité. Pour moi, il fait parti des frameworks webs de 4ème génération. Il y a d’abord eu les JSPs, les Servlets et les Applets. Puis ensuite Struts avec les premiers frameworks MVC de type 2. Ensuite l’apparition des RIAs (Rich Internet Applications) avec GWT, JSF, Wicket. Et donc maintenant je crois dur comme fer à ces nouveaux frameworks Webs, qui reviennent sur les bases du protocole HTTP pour offrir des performances et de la simplicité.

Grails est sorti en 2006. Il y a des sites en production comme Businessworld, Sky.com ou encore Escapeer. La page Testimonials donne une idée de quelques projets réalisés avec Grails et Groovy.

Groovy est le point fort de Grails. Je vous parlais de trouver des livres quelques lignes plus hauts. Vous pouvez aussi écrire des bouts de code comme par exemple:
Book.findAllByDatePublishedGreaterThanAndTitleLike(myDate,"Grails par le Touilleur Express")

Grails sera capable de générer le code Hibernate, Spring et Groovy afin de trouver tous les livres dont la date de publication est postérieure à une date, et dont le titre ressemble à ce que je précise… Lorsque je vous dis que vous allez gagner du temps, vous commencez à me croire ?

Grails utilise des standards
Grails utilise Groovy, et ensuite le couple Hibernate/Spring de base. Il est assez facile d’ajouter de nouvelles librairies grâce à des plugins. Dans mon projet par exemple j’utilise Drools. Je n’ai eu besoin que de 10 minutes pour créer un controleur simple et une règle Drools pour tester une idée.

Les idées de Grails
Ce qui suit est tiré du livre « Grails in Action ». Il y a 7 idées clés à comprendre pour adopter Grails:
- Convention au lieu de la Configuration
- Philosophie Agile
- Des fondations solides
- Scaffolding et moteur de template
- Intégration avec Java
- Une communauté et des plugins
- La Productivité améliore la qualité et réduit le risque d’erreur

Concernant l’aspect convention au lieu de configuration, cela revient à vous dire que pour gagner du temps, il faut suivre ce que dis le framework. J’ai juste un mot à dire aux gens qui font du Maven2, mais qui ne veulent pas ranger leurs fichiers dans src/main/java, qui désactivent les tests, qui veulent lancer des scripts Ant avec Maven : arrêtez Maven.
Vous n’avez rien compris à sa philosophie, vous pleurez car « Maveneu il rameuu » alors que si vous aviez pris le soin de lire l’excellent livre « Apache Maven », vous ne seriez pas comme un gosse avec le pantalon mouillé. Si vous commencez à bidouiller l’outil, c’est que vous n’avez pas lu la documentation, que vous n’avez pas écouté ce que vous disent les développeurs. A ce titre, je trouve que les livres que j’ai lu m’ont énormément aidés par rapport à la doc de Grails, qui ne distille pas assez la philosophie, à mon sens. Donc si vous voulez me suivre : achetez des livres sur Grails.

Grails est simple : une entité Survey est toujours stockée dans le répertoire domain. Cela permet à Grails de gérer l’object via Hibernate pour vous. Un controlleur est nommé SurveyController, et il est placé lui-aussi dans un endroit attendu par Grails. Si vous ajouter une méthode « completeSurvey », celle-ci est alors accessible automatiquement via une url comme « /survey/completeSurvey ». Si vous créez une nouvelle entité « Answer », Grails se charge de créer la table en base de données. Vous n’avez pas généré de fichiers pour tout ce qui est CRUD ? Grails le fait tout seul. Pour l’affichage des pages, il suffit de créez un fichier « /views/survey/completeSurvey.gsp » et il sera alors automatiquement chargé…

C’est bien de la Convention par dessus la Configuration et surtout pas de la Convention « au lieu de » la Configuration. Si vous voulez utiliser vos fichiers de mapping Hibernate : oui c’est possible. Mais par défaut : vous n’en n’avez pas besoin. Tout ce qu’il est possible de faire de manière répétitive et générique, c’est offert. Et comme vous aurez besoin de mettre le nez dedans, vous pouvez aussi le faire.

J’en suis à 16 classes pour mon domaine, à 2700 lignes de codes, 19 contrôleurs, et en 3 semaines j’ai déjà une application qui tourne… Je vous assure que je vous montrerai tout cela dans une vidéo très bientôt.

Grails est adapté au développement Agile. En fait je pense même que l’on peut dire que c’est un framework Web Agile. Les tests unitaires comme les tests fonctionnels sont faciles à écrire. Le fait de pouvoir créer un War, c’est aussi très pratique. Je vous explique cela : j’ai installé un Tomcat sur une machine, avec une base MySQL. Sur mon Mac, en ligne de commande il suffit que je tappe « grails war production » pour que cela me construise un fichier WAR, qu’il me suffit de déployer ensuite sur Tomcat pour la version en production. A aucuns moments je n’ai eu besoin de mettre le nez dans un quelconque fichier web.xml…
Au quotidien je ne construis pas de WAR. Je tappe simplement « grails run-app » et un serveur Jetty démarre, intégré à Grails. Lorsque je code, je n’arrête presque pas le serveur. En fait, lorsque vous changez un bout de page GSP, celle-ci se rafraîchit tout en gardant votre session. Si vous ajoutez une nouvelle méthode dans votre contrôleur, l’url est disponible et vous pouvez continuer à coder. Il n’y a qu’en cas de plantages que je relance parfois le serveur, lorsque ma session est pourrie. Je trouve que la remontée d’erreur pourrait encore faire des progrès par rapport à Play! mais c’est déjà pas mal.

Grails est basé sur des fondations solides. Spring et Hibernate. Spring 3 depuis la toute dernière version 1.2.RC2 que je teste en ce moment. En fait vous ne voyez pas Hibernate et Spring, mais vous savez que vous pouvez aller voir si nécessaire. Le moteur de scheduling ? C’est Quartz. Le moteur de recherche ? Lucene et Compass pour les entités. Le moteur de construction ? SiteMesh… Bref il n’y a pas d’innovations. Nous parlons bien de techniques que vous connaissez déjà. Imaginez simplement ceci : écrire moins de code, travailler plus vite.

Le moteur de scaffolding et de templating. J’adore Spring MVC. Je m’en suis servi l’été dernier pour mon projet sur Google App Engine (http://touilleur.appspot.com), projet que je ne finirai pas faute de temps. Grails est assez radical par rapport à Spring MVC. Là où vous auriez quelques beans annotés, des fichiers de configuration, un peu d’Hibernate et une configuration avec la base, Grails fait la même chose en quelques minutes.
grails create-app myapp ... ... grails run-app
Ouvrez votre navigateur : http://localhost:8080/myapp, c’est prêt. Ensuite si vous voulez ajouter un nouveau contrôler :
grails create-controller MonControleur
C’est tout !

Lorsque vous créez une nouvelle entité, un nouvel objet du domaine, il est facile aussi pour Grails de vous générez automatiquement tout ce qui est CRUD. C’est ce que l’on appelle le scaffolding. Ce n’est pas destiné à remplacer votre application. En fait voici comment je travaille : je génère d’abord mes entités avec des idées à tester. Ensuite je crée un controleur pour cette entité en mode « scaffold ». Cela me permet de tester mon objet, de valider les relations one-to-one, one-to-many, many-to-many et de m’assurer que tout marche. Enfin, je refais un vrai contrôleur pour mon application finale, et je ne touche pas à ce que Grails m’a généré. Je recopie quelques petits bouts de code pour gagner du temps, mais c’est là que je code vraiment mon application. Cela me fait gagner un temps fou.

L’intégration avec Java est là pour rassurer les bons pères de famille. Il y a un répertoire Java. Vous pouvez y placer ce que vous voulez. Pour peu qu’une librairie de votre ERP soit en Java, et qu’il soit nécessaire d’écrire un peu de code orienté Service, Grails vous aménage un espace dédié pour le faire, et se débrouille pour injecter vos services Java dans les contrôleurs Grails… C’est très pratique. Je m’en suis servi pour une partie avec du Drools, que j’ai migré vers du Groovy car finalement, c’est plus simple.

Grails a une communauté. C’est bête, mais lorsque le lundi matin vous êtes seul dans votre bureau de 7m2, croyez-moi vous êtes super content de voir qu’il y a pleins de gens qui se servent de Grails sur Internet. Google est ton ami. La documentation est bonne. Le produit vit, et la liste de diffusion users est très active. J’ai appris beaucoup en lisant les échanges ces dernières semaines. Enfin côté livre je vous le disais tout à l’heure, il y a de très bons livres en Anglais. Si j’avais le temps et le courage, je me lancerai bien dans l’écriture d’un livre en Français. Mais je suis trop bavard… Pas possible pour moi.

Enfin pour terminer, le 7e point noté par les auteurs de Grails in Action, c’est l’aspect de productivité et la possibilité de valider ou non ses idées très rapidement. Pour notre projet qui sera en ligne l’été prochain, je me remercie chaque jour d’avoir pris Grails pour gagner du temps, faire des démonstrations qui marchent chaque semaine, jeter sans souci du code écrit en 3 jours au lieu de 2 semaines, bref je peux dormir tranquillement la nuit. Est-ce que tu comprends que je peux virer des idées foireuses car elles ne m’ont coutés que 2 jours au lieu de 2 semaines ? Un vrai projet de Startup c’est beaucoup d’essais. Personne ne vous dira si ce que vous faîtes c’est bien ou pas. Il faut avoir cette possibilité de changer de cap très rapidement, encore une fois dans le cadre d’une Startup pour moi.

Conclusion
Pour terminer, je vous laisse ici ce soir. Je vous montrerai un peu de Grails, du vrai code, pas un « Hello World », plutôt une application écrite en quelques heures, afin de vous faire comprendre ce qui a retenu mon attention.

Je pense aussi que nous, développeurs Javas, devons nous remettre en question d’urgence. En voyant des projets sur PHP ou Ruby on Rails, j’ai un peu la gueule de bois avec mon Java. Je pense que pour le développement d’applications Webs, il faut revoir notre manière de penser, notre manière de travailler. J’ai même du mal à croire au succès de Struts hier, de Wicket/Tapestry/JSF en ce moment… Comment pouvons-nous rouler des mécaniques alors que d’autres langages sont bien meilleurs pour faire du développement webs ? Que d’autres frameworks sont bien mieux pensés et bien moins prétentieux que ce que nous vendons depuis 3-4 ans à nos clients ? Comment avons-nous pu vendre des développements avec du Struts, des JSPs à des clients finaux ? Comment ?

Imaginez-vous entrain d’expliquer aux clients que les développeurs sur certains projets doivent construire un WAR, arrêter et relancer leur serveur d’application avant de voir leur résultat… alors que c’est inutile avec Grails (et d’autres)…

Et encore, je ne vous ai même pas encore dit que j’étais aussi tombé amoureux de Groovy…

J’en garde pour la prochaine fois.

Jazoon : Gradle la présentation qui aura lieu jeudi soir…

Nicolas Martignole — Tue, 23 Jun 2009 22:24:20 +0000

Cher lecteur du Touilleur Express. Après avoir publié comme tu le sais de nombreuses fois à 2h du matin pour que tu aies ton numéro du Touilleur à lire au petit matin, sache que j’ai un nouveau concept à te présenter. J’ai assisté à la présentation qui va avoir lieu ce jeudi à Paris chez Zenika. Et donc tu peux soit attendre jeudi et te faire ta propre opinion, soit lire et voir tout le mal que je pense du speaker. Note que je viens de spoiler un peu… mince.

Alors sur le fond tout d’abord, je garde la forme pour la suite. Hans Dockter est le responsable du projet Gradle, un ancien commiter de JBoss IDE, et un formateur chez Skill Matters. La présentation sera animée, avec du code et un exemple intéressant à suivre.
Tout d’abord la première question : pourquoi Gradle ?
Ah il y a une autre question avant dans la salle : c’est quoi Gradle ?
Gradle est un système de build écrit en Groovy qui permet de construire une application, de la packager, de gérer les releases, la version sur le repository du code source, bref de faire ce que fait Ant/Maven. Il utilise d’ailleurs les dépendances de Maven sans problèmes (qui a dit « pas comme maven » ?)

Hans Dockter a présenté Gradle en axant dans sa première partie les défauts des autres outils comme Ant ou Maven. Là où il a tout à fait raison, c’est que Ant est bien trop simple. Il demande ainsi à la salle si nous avons une idée du nombre d’éléments de la DTD d’un script Ant ? la réponse est 5 : Tasks, Properties, et j’ai oublié les 3 autres… Bref cela fait que pour des tâches répétitives, il faut systématiquement définir ses tâches, comme JUnit. Bon ok.

Gradle vise à rendre l’impossible, possible. A rendre le possible -> facile. Et le facile -> élégant. Il explique que le modèle des scripts Ant date des années 97-2000, que depuis nous avons besoin d’une solution plus souple. Alors ensuite Maven.

Maven 2 offre beaucoup de fonctionnalités supplémentaires, voir peut-être trop d’après lui. Le support des plugins, des dépendances transitives, le build-by convention, bref tout ceci fait que Maven est plutôt un bon système. Il reproche simplement la verbosité du XML, le fait qu’il soit difficile de n’exécuter que certaines tâches, la complexité de certains plugins, le manque de consolidation dans la manière de gérer et configurer les plugins, bref trois fois rien…

Alors arrive Gradle. A cet instant de la présentation cher lecteur, je suis un peu dubitatif. J’ai horreur des gens qui vendent un médicament en critiquant les autres médicaments au lieu de parler de la maladie. J’étais donc assez fatigué d’entendre depuis 15mn du vent sur « Ant il est tout pourri » et « Maven nous emmène jamais au heaven« … A ma gauche j’ai quand même Vincent Massol de XWiki, l’un des CastCodeurs, mais surtout l’un des auteurs de Maven: A Developer’s Notebook, livre à lire d’urgence. Et je sens que Vincent n’est pas traversé par le saint-esprit de Gradle. Je me trompe Vincent ?

Hans Docket ouvre (enfin) son IDE favori (IDEA IntelliJ) sur sa machine favorite (Mac Book Pro) et il est temps de voir la tête d’un script Gradle.

task hello < < {
    println 'Hello world!'
}

Après avoir défini une "task", comme il l'explique rapidement : un script Gradle est un script... Groovy. Cela donne accès à toute l'API, ce que je trouve bien. Disons que vous souhaitez afficher l'heure dans votre build, nul besoin d'écrire un quelconque plugin, un simple println ladate et c'est tout.

La gestion des dépendances entre Task est limpide :

task hello < < {
    println 'Hello world!'
}
task intro(dependsOn: hello) << {
    println "I'm Gradle from Jazoon"
}

Si j'exécute ce code voici ce que cela donne :

> gradle -q intro
Hello world!
I'm Gradle from Jazoon

Prenons ensuite un script build.gradle complet pour vous montrer ce que cela donne :

usePlugin 'java'

sourceCompatibility = 1.5
version = '1.0'
manifest.mainAttributes(
    'Implementation-Title': 'Gradle Quickstart',
    'Implementation-Version': version
)

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

test {
    options.systemProperties['property'] = 'value'
}

uploadArchives {
    repositories {
       flatDir(dirs: file('repos'))
    }
}

On est d’accord pour dire que c’est clairement moins verbeux qu’un script Ant ou Maven.
Simple et efficace.

Par la suite il explique que Gradle est construit par Gradle, que la documentation par exemple est testée. Les exemples de code qui sont dans le manuel de Gradle sont testés par Gradle ! La documentation est ainsi mise à jour sur le site Internet de Gradle automatiquement, la classe non ?

La critique, la critique, la critique
Sans langue de bois : mauvais speaker. Un peu fouillis, on sens que Gradle vaut le coup d’être regardé mais ce n’est pas la bonne personne pour en parler. Les exemples de scripts m’ont donné cependant envie d’y jeter un oeil, et il a de bons arguments intéressants… mais bon, voilà.

Du côté de Gradle lui-même j’ai un truc qui ne m’a pas plus : la lenteur. Son script HelloWorld démarre poussivement en 2 secondes. Désolé mais mon système de build doit être rapide. Si je vois que ce système qui me fait remplacer 1 fichier pom.xml de 60 lignes par un script de 20 lignes multiplie par 3 le temps de compilation : poubelle.

Allez voir jeudi soir la présentation chez Zenika, et prenez une autre opinion que la mienne, qui est très personnelle. On est sur un blog personnel, je peux largement me planter, mais je ne crois pas à Gradle pour l’instant.

Jazoon : Groovy seven usage patterns

Nicolas Martignole — Tue, 23 Jun 2009 16:02:08 +0000

Première conférence : Groovy, Seven Usage Patterns par Dierk König.

L’objectif de cette présentation est de nous montrer 7 cas d’utilisations réels de Groovy dans le monde de l’entreprise. Voici une photo prise durant la séance :

#1 SuperGlue
Groovy permet de créer rapidement des applications simples en utilisant l’API de base. Dierk nous montre cela en écrivant en quelques lignes un lecteur de flux RSS qui affiche dans une fenêtre de type Swing la liste des derniers billets. Groovy est un moyen rapide de créer de l’assemblage. Il montre la lecture d’un flux XML et le traitement du DOM, puis ensuite la partie Swing. Vraiment intéressant.

#2 Liquid Heart
Ce pattern d’usage vise à nous montrer comment réutiliser la couche métier d’une application existante pour réutiliser les services avec du Groovy. La démonstration nous montre comment retirer du code métier écrit en dur pour le remplacer par du script Groovy. Chez mon client actuel nous nous en servons pour le calcul du risk par exemple. Ici Dierk nous montre comment externaliser le calcul de bonus d’un salarié dans un script Groovy chargé par Java à l’exécution, et évalué selon les paramètres. Cela vous permet de rendre très configurable certaines parties de votre couche métier.

#3 Keyhole Surgery
Ce pattern discutable vise à ouvrir une porte cachée dans l’application afin d’exécuter du Groovy. Il montre ainsi une application Web Java classique avec des utilisateurs. Une servlet sécurisée (hem…) permet d’exécuter du code Groovy directement via le navigateur. Dans l’exemple qu’il montre, il s’en sert pour remettre à zéro des paniers d’utilisateurs qui sont invalides.
Groovy étant un langage de script, il est possible d’intervenir dans votre application Web à distance.

#4 Smart Configuration
Groovy est bien plus intelligent que des fichiers de configuration XML. L’un des cas d’usage qu’il nous montre ensuite est donc la configuration d’une application en script Groovy. L’injection et la configuration en devienne plus facile.

#5 Unlimited Openness
Plus qu’un pattern, Dierk parle maintenant de l’accès au code. Il nous recommande dans la mesure du possible de laisser le code ouvert, quoiqu’en Groovy je crois que de toutes les façons c’est le cas. Il nous montre l’exemple d’un moteur de blog écrit en Groovy, que sa société (Canoo) a porté facilement, car le code est accessible. Chaque besoin client étant spécifique, pourquoi ne pas laisser le code ?

#6 House-Elf Scripts
Pour la suite de sa présentation il s’appuie sur les Elfs de maison d’Harry Potter. Ce sont ces petits gars qui font le sale boulot pour vous, qui ne rechignent pas à la tâche. Groovy est parfait pour automatiser les tâches répétitives comme l’intégration, la construction, la gestion de release. Il nous encourage à aller regarder de ce côté. Cela tombe bien, je compte aller voir Graddle cet après-midi.

#7 Prototype
Enfin pour terminer, Groovy est un langage particulièrement adapté pour la création de prototype. L’interface Swing se fait rapidement avec Griffon, une application Web se fait rapidement avec Grails, c’est l’essence même de Groovy.

Au final en sortant j’ai appris encore de nouvelles choses sur Groovy. Lorsque Dierk tapait cependant son programme en Groovy, j’ai vu qu’il s’en sortait car il maîtrise son API à la perfection. L’aspect dynamique doit cependant vous faire prendre conscience que la maîtrise de Groovy demande un peu plus de temps.

Premiers pas avec Grails 1.1.1 et Google AppEngine

Nicolas Martignole — Tue, 09 Jun 2009 12:05:24 +0000

Ah là là… dire qu’à la fin de la lecture de ce billet j’aurai complètement changé votre vision du Web… Je comprends mieux maintenant Didier Girard de SFEIR, il y a un avant et un après Google AppEngine… Mais bon, soyons patient et voyons ce que nous pouvons faire aujourd’hui. Ce qui suit est inspiré, pour ne pas dire affreusement copié sur ce que Guillaume Laforge a présenté le 28 mai dernier lors de la conférence Google I/O à San Francisco. J’ai simplement adapté la présentation en français, je l’ai fait fonctionner, pour le reste tout le crédit va à Guillaume.

Guillaume Laforge Google IO 2009

A la fin de cet article vous serez en mesure de déployer sur Google AppEngine une petite application simple.

Installer Grails
Téléchargez et installer Grails 1.1.1. Pour ma part, sur Mac OS j’ai ensuite édité mon fichier .bash_profile afin de déclarer le chemin d’installation de Grails, et fixer la version de Java à la version 5 pour éviter quelques soucis plus tard avec Google AppEngine et DataNucleus.
Voici le contenu du fichier $HOME/.bash_profile

export M2_HOME=/usr/share/maven
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
export GRAILS_HOME=/Users/nicolas/Dev/grails/grails-1.1.1
export APPENGINE_HOME=/Users/nicolas/Dev/appengine-java-sdk-1.2.1
export PATH=$PATH:$GRAILS_HOME/bin

Vérifiez que Grails est correctement installé avant d’aller plus loin:

macbook-pro-de-nicolas-martignole:~ nicolas$ export GRAILS_HOME=/Users/nicolas/Dev/grails/grails-1.1.1
macbook-pro-de-nicolas-martignole:~ nicolas$ export PATH=$PATH:$GRAILS_HOME/bin
macbook-pro-de-nicolas-martignole:~ nicolas$ grails -version
Welcome to Grails 1.1.1 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /Users/nicolas/Dev/grails/grails-1.1.1

Base Directory: /Users/nicolas
Running pre-compiled script
Script not found: Version
macbook-pro-de-nicolas-martignole:~ nicolas$

Les observateurs ont remarqué certainement la variable APPENGINE_HOME. Il est temps de télécharger Google AppEngine, après avoir demandé un compte. Suivez attentivement les explications de la page principale de Google AppEngine. Une fois le téléchargement effectué, j’ai simplement décompressé l’archive tar.gz dans un répertoire, puis ensuite j’ai configuré la variable APPENGINE_HOME afin qu’elle pointe vers le répertoire de GAE (Google AppEngine).

Créer sa première application Grails
Grails vous permet de créer rapidement une application et de la tester. Allons-y, placez-vous dans un nouveau répertoire vide et créez votre première application grails, appelée ici gaetex:

grails create-app gaetex

Lorsque nous utilisons Google AppEngine, nous devons désinstaller le plugin JPA et désinstaller le plugin Hibernate. Le plugin JPA génère un fichier persistence.xml qui vient en conflit avec celui utilisé par le mode JPA du plugin Google AppEngine. Concernant Hibernate, nous n’en avons pas besoin ici.
Pour cela il suffit d’exécuter les 2 commandes Grails suivantes en vous mettant d’abord dans le répertoire gaetex que nous venons de créer :

cd gaetex
grails uninstall-plugin hibernate
grails uninstall-plugin jpa

Notez qu’en principe, le plugin jpa n’est pas installé, j’ai ajouté cette commande au cas où vous l’auriez installé aussi.

Installer Google AppEngine
L’installation de Google AppEngine est simple. Assurez-vous simplement que la variable APPENGINE_HOME pointe vers votre répertoire d’installation de GAE puis lancer la commande d’installation du plugin App-Engine :

grails install-plugin app-engine

Ce qui donne sur ma machine:

macbook-pro-de-nicolas-martignole:gaetex nicolas$ echo $APPENGINE_HOME
/Users/nicolas/Dev/appengine-java-sdk-1.2.1
macbook-pro-de-nicolas-martignole:gaetex nicolas$ grails install-plugin app-engine
...
...

Tester le tout
Vérifions que tout fonctionne en démarrant le serveur Jetty intégré à Grails. Dans le répertoire gaetex, lancez grails:

grails app-engine

Connectez-vous à votre machine (http://localhost:8080/) et vous devriez voir votre première page Grails s’afficher.

Créer une première entité
Nous allons maintenant créer une entité Book, et générer ensuite la partie vue et contrôleur. Avec Google AppEngine, il n’est pas possible de placer ses Entités directement dans le répertoire « grails-app/domain ». Il est nécessaire d’utiliser un package. J’ai donc fait comme Guillaume durant sa démonstration, j’ai créé une entité Book dans le package « demo » avec la commande suivante :

grails create-domain-class demo.Book

Il serait intéressant maintenant d’ajouter deux attributs « title » et « author » à notre Book.

Editez le fichier gaetex/grails-app/domain/demo/Book.groovy avec un éditeur de texte, et ajoutez simplement 2 attributs pour le titre et l’auteur du livre :

package demo

import javax.persistence.*;
// import com.google.appengine.api.datastore.Key;

@Entity
class Book {

    @Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	Long id

	// Added by Nicolas Martignole
	String title
	String author

    static constraints = {
    	id visible:false
	}
}

Avec ces deux attributs en place, nous allons maintenant générer un controlleur et tester à nouveau notre application.
Lancez la commande de génération du controleur et des vues:

grails generate-all demo.Book

Puis relancez ensuite le serveur Grails :

grails app-engine

Voici ce que cela donne après avoir créé quelques livres (au logo prêt) :

Vous pouvez retrouver la même chose avec la voix de Guillaume à partir de la minute 50 sur la vidéo YouTube de la présentation.

Déployer son application Grails sur Google AppEngine
Voici la liste des étapes:
1) créer une application sur Google AppEngine
2) modifier le fichier grails-app/conf/Config.groovy et ajouter une ligne avec le nom de votre application
3) packager et préparer l’application
4) effacer un fichier parasite (probleme à résoudre)
5) utiliser le script appCfg.sh pour fournir votre email et votre mot-de-passe Google
6) ensuite simplement mettre à jour avec le plugin google-app-engine de Grails

Voyons en détail chaque étape:

1) Rendez-vous sur « Google AppEngine » afin de faire une demande, puis ensuite de créer votre application. L’application id doit être unique, ce pourra être par exemple testgrails1234
2) Ouvrir le fichier Config.groovy se trouvant dans votre application et définissez l’application id que vous venez de mettre

google.appengine.application="touilleur"

3) Lancer la création du package avec les commandes suivantes:
Il faut fixer la version à un nombre entier car GAE n’accepte pas les numéros de version type x.y.z

grails set-version 1
grails app-engine package

4) Effacer le fichier « datastore-indexes.xml » sans quoi voici l’erreur que vous rencontrerez:

macbook-pro-de-nicolas-martignole:gaetex nicolas$ /Users/nicolas/Dev/appengine-java-sdk-1.2.1/bin/appcfg.sh update target/war
Reading application configuration data...
Bad configuration: XML error validating target/war/WEB-INF/datastore-indexes.xml against /Users/nicolas/Dev/appengine-java-sdk-1.2.1/docs/datastore-indexes.xsd
  Caused by: cvc-elt.1: Cannot find the declaration of element 'datastore-indexes'.
Please see the logs [/tmp/appcfg16875.log] for further information.

Pour résoudre ce problème, effacez le fichier datastore-indexes.xml avant de relancer la commande appcfg.sh (voir étape suivante)

rm target/war/WEB-INF/datastore-indexes.xml

5) Lancer la première fois seulement la mise à jour avec l’utilitaire appcfg.sh de Google AppEngine comme suit:

$APPENGINE_HOME/bin/appcfg.sh update target/war

Renseigner votre adresse mail Google ainsi que votre mot de passe. Il suffit de mettre son login en fait (mdupont et pas mdupont@gmail.com).

6) Ensuite à chaque fois que vous souhaitez mettre à jour votre application vous pourrez utiliser le plugin de Gae dans Grails, plugin qui ne marche pas la première fois avec l’authentification en se plantant. C’est pour cette raison qu’il faut utiliser l’utilitaire appcfg.sh la première fois.

grails app-engine deploy

Si tout se déroule sans problèmes vous devriez alors mettre en ligne votre première application !!!

L’url de votre application sera http://.appspot.com

Si vous voulez tester un exemple d’application : PetClinic with Grails

Conclusion
Comptez 1h la première fois, puis ensuite 10 minutes pour refaire cet exercice. J’ai été vraiment séduit par la simplicité de Grails, et cette intégration avec Google App Engine. Celui-ci est gratuit jusqu’à un certain nombre de requêtes par jour, et croyez-moi vous avez largement de quoi tester votre code sans devoir payer, toujours dans l’esprit Google.
Je crois vraiment à un nouveau type de développement rapide d’applications, à la monétisation de compétences en Groovy et en Grails. Pour ma part je travaille en ce moment sur une application pour le Touilleur Express, un mix de LinkedIn avec une touche de Google Calendar, un esprit de Geek et bien entendu, toujours la pâte Touilleur Express.

Guillaume Laforge travaille aussi sur Gaelyk, un framework léger qui facilite l’intégration de Google App Engine si vous souhaitez n’écrire qu’en Groovy votre application Web, sans utiliser Grails. Il cite aussi le framework iUI qui est un framework Javascript destiné à faciliter l’écriture d’application pour l’iphone, hébergé sur Internet. Cela revient à ne pas passer par l’AppleStore, à simplement offrir un service type iPhone mais hébergé sur Internet directement.

Références
- Page d’accueil Google App Engine
- Page pour créer sa première application GAE
- Plugin GAE Grails le site à surveiller
- Groovy Web Console permet de taper du Groovy, application Google App Engine
- My Own Groovy par Guillaume Laforge avec quelques applications pour tester
- Portail des applications Google App Engine

Problèmes connus
Il y a un certain nombre de soucis pour l’instant sur le plugin Google App Engine pour Grails au moment où j’écris ces lignes (juin 2009). Ne vous lancez pas dans ce test si vous ne maîtrisez pas un minimum Grails. Je n’ai testé que la version JPA, je ne sais pas si la version JDO est plus ou moins stable.

Pour terminer je vous recommande de regarder la présentation de Guillaume Laforge sur YouTube:

Java et Groovy 1.6.1 supportés sur Google AppEngine

Nicolas Martignole — Wed, 08 Apr 2009 05:35:06 +0000

Ce matin la nouvelle s’est propagée via Twitter en quelques heures. @DidierGirard a annoncé ce matin vers 06h00 l’information, j’ai vu aussi que les JavaPosses avaient assisté à un événement (@DickWall). C’est surtout Guillaume Laforge qui est fier d’annoncer que Groovy sera supporté par Google AppEngine. SpringSource a publié ce matin un tutorial en anglais pour écrire sa première Groovlet et la déployer sur GoogleAppEngine, qui est un serveur d’application déployé en cloud-computing. D’ici une semaine nous devrions avoir un Gwitter, twitter écrit en Groovy au rythme où vont les choses !

Didier a déjà publié une news sur son blog, je le laisse donc passer devant, le Touilleur Express vous donnera d’autres informations demain dans la soirée.

Stay Tuned !
Il y a encore d’autres choses à venir.

Voir :
L’annonce sur le blog SpringSource du support de Groovy
http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

Nouveau : un podcast le Touilleur Express

Nicolas Martignole — Sat, 15 Nov 2008 11:23:48 +0000

N.Martignole et G.Laforge

C’est fait, le premier podcast du Touilleur Express est en ligne sur sa page dédiée. Le premier épisode vous propose d’écouter Guillaume Laforge, le chef de projet du langage Groovy. SpringSource a annoncé le 11 novembre dernier le rachat de sa société, G2One.inc. A l’occasion de la journée « Les Rencontres Spring » nous avons été invité par SFEIR à rencontrer plusieurs personnes de SpringSource. J’ai enregistré une petite interview de guillaume avec Olivier Croisier, auteur du blog « The Coder’s Breakfast« .

Voici des pointeurs vers des sujets abordés dans le podcast :

A venir prochainement : interview avec Peter Cooper-Ellis. La qualité n’étant pas assez bonne, je vous proposerai une transcription de notre rencontre avec Peter prochainement.

En attendant voici une photo prise chez SFEIR, avec donc de gauche à droite : Peter Cooper-Ellis, moi-même et enfin Olivier Croisier.

Interview Peter Cooper-Ellis avec Nicolas Martignole et Olivier Croisier

La rentrée : groovy

Nicolas Martignole — Tue, 02 Sep 2008 11:28:43 +0000

Un peu d’actualité sur Paris et quelques liens à regarder.

La prochaine soirée du Paris Java User Group aura lieu mardi soir prochain à Paris à l’ISEP à partir de 19h15 autour du langage Groovy présenté par Guillaume Laforge, chef de projet de Groovy et membre de l’OSSGTP. L’intérêt de Groovy est à mon avis de dépasser l’étape de langage de script pour vraiment apporter à la plateforme Java un langage dynamique. Guillaume est aussi spec-lead de la JSR-241 qui vise à standardiser Groovy au sein de la plateforme Java. Groovy permet de retirer pas mal de code d’assemblage et de s’approcher de la mouvance des langages de script amorcée avec Java 6.

On ne peut pas parler de Groovy sans parler de Grails, le framework MVC basé sur Groovy. La deuxième partie de la soirée sera donc consacrée à la présentation de Grails par Fabrice Robini, architecte chez Octo.
J’attends avec impatience de voir un peu une présentation en live de Grails. J’espère que Fabrice pourra refaire ce que Jean-François Hélie et Christian Blavier nous avaient proposé en juin dernier.

Le 18 septembre se déroulera aussi le Google Developer Day 2008 à l’ENSA. Les sessions sur GWT et sur AppEngine pourraient intéresser pas mal de monde. Je ne manquerai pas de vous en faire un petit compte-rendu.

Si vous voulez vous regarder quelques petites vidéos sympathiques, je vous conseille de regarder les vidéos de Jazoon 2008 une conférence dont je vous avais parlé il y a quelques mois déjà.

A propos de vidéo, si vous souhaitez regarder tranquillement un screencast de votre MacBook Pro préféré, le site Parleys.Com héberge un certain nombre de vidéo sur l’écosystème Java, Spring, Mule, JBoss et compagnie. Je vous recommande par exemple la présentation de Mule 2 de Ross Masson ou l’intervention de Rod Johnson sur Spring 2.
Au passage on note que le site a été réalisé avec Adobe Flex et qu’il existe même une version AIR. Pas mal non ?