Toute bonne chose a une fin, Devoxx n’en est hélas pas l’exception. Voilà donc le dernier jour qui arrive, avec son lot de keynotes, conférences, rencontres…

Je vais très rapidement zapper la toute première keynote, d’IBM. C’est un concentré, en une petite demi-heure, de ce qu’il ne faut pas faire dans une conférence, surtout à Devoxx : commerciale, speaker plutôt mou, et à l’opposé des présentations zen (c’est-à-dire avec des slides bourrées de bullets points).
Il suffisait de lire les tweets postés pendant la présentation pour comprendre que ce n’était pas du goût de l’auditoire !

Portrait du développeur en « The Artist » par Patrick Chanezon

Le conférencier suivant a un CV déjà bien rempli : il a travaillé chez Accenture, Netscape en France, puis Sun, Google (API / GAE), et enfin VMWare (CloudFoundry) aux USA.
La première partie est consacrée à nous parler de la vie de George, à la façon « The Artist« .
George est un développeur talentueux, et très vite devient indispensable à son projet. Ses chefs se disent qu’il serait bien de le mettre comme chef de projet, puis finalement comme DSI de sa boite… Mais voilà, George aime la technique, et si son niveau de golf s’améliore, il n’arrive déjà plus à lancer Eclipse, et est très vite dépassé par toutes les nouvelles technologies.
Patrick nous explique finalement que si l’on souhaite conserver son niveau, il faudra rester proche de la technique, et toujours s’intéresser aux nouvelles technologies…

Abstraction Distractions for France par Neal Ford

Nous continuons avec une troisième keynote, elle aussi de très haut vol. Il faut dire que nous avons en face de nous Neal Ford, un architecte de ThoughtWorks, et plutôt talentueux conférencier.
Cette fois-ci, il nous parle d’abstraction et de distraction. Difficile de retranscrire ici sa prestation, je vous la recommande sur Parleys dès qu’elle sera disponible. La moitié de la salle a fini debout pour applaudir le Maitre !

TestNG, parce que vos tests le valent bien par moi-même

Je reviendrais un peu plus longuement dans un autre billet sur le Quickie que j’ai présenté.
Il s’agit ici de montrer que TestNG dispose de nombreux atouts pour remplacer JUnit comme librairie de tests unitaires…

CRaSH par Julien Viet

Julien Viet, de l’équipe d’eXo plateform, nous propose une petite démonstration de CRaSH, un shell qui permet de travailler directement avec / sur une JVM.
Le principe est très simple : une fois installé et démarré, l’outil va se connecter sur une JVM, et on pourra alors exécuter un certain nombre de commandes :

  • Lister les threads qui tournent sur la JVM ;
  • Utiliser CRaSH pour gérer les logs, en changeant par exemple dynamiquement le niveau des logs du serveur d’applications JBoss AS ;
  • Se connecter à la dataSource pour exécuter des requêtes SQL !

Puis Julien nous explique que les commandes sont écrites en Groovy et toute modification d’une commande est prise en compte dynamiquement. Il est d’ailleurs très simple d’ajouter soit-même de nouvelles commandes.
Bref, un bel outil, très extensible, qui mérite un coup d’oeil, même s’il ne faudra pas mettre cela entre toutes les mains !

Groovy 2.0 : quoi de neuf doc ?, par Guillaume Laforge et Cédric Champeau

Guillaume et Cédric nous font un récapitulatif des nouveautés de Groovy 2.0 (mais aussi un peu de Groovy 1.8).
En effet, déjà pas mal de choses ont été introduites par la version 1.8 du langage. Par exemple, les Command chains, rendant optionnelle l’écriture des . ou ( ), lorsque l’on chaine des appels.
Ainsi, ces codes :

turn left then right
check that: margarita tastes good // named-args
given {} when {} then {}
select all unique() from name // Pour une méthode sans argument, on garde les ()
take 3 cookies

sont équivalents à ceux-ci :

turn(left).then(right)
check(that: margarita).tastes(good) // named-args
given({})when({})then({})
select(all).unique().from(name)
take(3).cookies

Groovy intègre également GPars pour faire du parallélisme, de la concurrence.

Autre nouveauté : les Closure annotation parameters, ainsi que la memoization, c’est-à-dire que Groovy va se souvenir du dernier appel d’une closure pour cacher le résultat. Par exemple :

                def plus = { a, b -> sleep 1000; a + b}.memoize() // on "simule" un traitement lent avec le sleep...

                assert plus(1, 2) == 3 // Le retour sera fait après 1000ms
                assert plus(1, 2) == 3 // Ici, on utilise le cache, donc le retour est immédiat
                assert plus(2, 2) == 4 // Le retour sera fait après 1000ms, les paramètres étant différents.
                assert plus(2, 2) == 4 // Ici, retour immédiat

On peut affiner la façon dont Groovy va cacher les résultats, en limitant par exemple le nombre de valeurs à retenir (.memoizeAtLeast(x), .memoizeAtMost(42)…).

Groovy ajoute désormais un support du JSON dans Groovy (avec les JsonSlurper, JsonBuilder et JsonOutput).

De nouvelle annotation (AST transformations) sont également à l’ordre du jour, comme par exemple @Log pour injecter automatiquement un logger.
Des annotations pour le controle d’exécution sont là : @ThreadInterrupt, @TimedInterrupt.
Les amateurs de Lombok seront aussi comblés, puisque Groovy intègre des annotations pour simplifier le code : @ToString (qui génère la méthode toString() automatiquement), @TupleConstructor (qui génère un constructeur avec les propriétés de la classe) ou encore @InheritConstructors (utile sur les exceptions où les constructeurs appelent juste des super).

Concernant Groovy 2.0, nous allons voir surtout la vérification stricte, ainsi que la compilation statique.
A noter aussi que cette version offre plus de modularité : ce n’est plus seulement un gros jar, mais plusieurs modules.
Groovy 2.0 s’adapte aussi à Java 7 :

  • project coin (écriture des nombres en binaire, avec des _)
  • multicatchs ;
  • opérateur diamand (pour écrire List list = new ArrayList<>(); plutôt que List list = new ArrayList();) ;
  • invokeDynamic.

Le @TypeChecked fait aussi son apparition. Cette annotation permet de vérifier beaucoup plus de chose lors de la compilation.
Par exemple :

@TypeChecked test() {  // On annote la classe ou la méthode
    metthhoood()           // Erreur à la compilation
    def name = "Guillaume"
    println                     // Erreur ici aussi !
}

Un autre exemple :

@TypeChecked test() {
    ["a", "b", "c"].collect(
        it.toUpperCase()
    )
}

ne compilera pas, car rien ne permettra d’assurer à Groovy que le it est bien un String (la méthode collect pourrait être alterée par exemple).
Du coup, pour que le compilateur soit content, il faut caster le it comme ceci :

@TypeChecked test() {
    ["a", "b", "c"].collect(
        String it ->
            it.toUpperCase()
    )
}

Dernier point apporté par Groovy 2.0, et non des moindres : la compilation statique. Celle-ci se dénote par l’annotation @CompileStatic.
Les avantages d’une compilation statique sont :

  • Les performances accrues, en particulier sur des JDK avant 7, ne disposant pas du invokeDynamic ;
  • Evite les problèmes liés au « Monkey patching« , c’est-à-dire que le code est « immunisé » contre la modification dynamique ;
  • Le bytecode généré sera bien plus petit.

Reste que la compilation statique fait perdre les fonctionnalités dynamiques de Groovy (du moins sur le code compilé statiquement). Mais là, rien de bien gênant…

Android, graphisme et performances par Romain Guy

Romain Guy est un développeur français parti chez Sun où il a d’abord travaillé sur Swing, et est désormais chez Google comme développeur Android.
Il nous donne sur cette conférence un aperçu des écueuils à éviter lorsque l’on développe sur Android, et en particulier de ce qu’il convient de faire pour avoir des applications performantes.
Bon, je dois l’admettre, je n’ai pas retenu grand chose de la présentation car je ne développe pas pour Android. Toutefois, on voit que Romain connait son sujet, et qu’il maitrise l’art de la conférence. Bref, c’était agréable à écouter…

Les CastCodeurs en direct de Devoxx France

Très bonne conclusion du Devoxx avec cet enregistrement en live des CastCodeurs.
Un récapitulatif dans la joie, la bonne humeur et la bière (merci Atlassian pour ça !)

Vous pouvez retrouver l’épisode spécial Devoxx France ici.

Conclusion

Devoxx France, c’est fini, mais qu’est-ce que c’était bien !
Des conférences de haut niveau, un public de geeks très nombreux et aussi de grande qualité, des rencontres vraiment sympas.
Le fait d’avoir aussi été choisi comme conférencier pour parler de JavaScript (dans une présentation qui a visiblement plû au delà de mes espérances), et de TestNG rend ces jours vraiment inoubliables…

Bref, encore mille bravos à toute l’équipe organisatrice !