La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• A vos radars!

Le coin de la technique

• Gaelyk v1.0: Google App Engine en Groovy

Actualité éditeurs / SSII

A vos radars!

ThoughtWorks vient de publier une nouvelle édition de son Technology Radar et, comme à chaque publication de ce désormais célèbre baromètre technologique, l’analyse conjoncturelle qu’y proposent Rebecca Parsons et Martin Fowler est souvent avant-gardiste, quelquefois controversée, mais ne laisse jamais indifférent.

Cette nouvelle mouture se situe nettement dans la mouvance du Software Craftsmanship avec pour maîtres-mots l’automatisation, la simplicité et la qualité.

En effet, quand on plonge dans le détail de l’analyse, on s’aperçoit que la tendance côté techniques est à l’automatisation. Les cultures prônant l’automatisation totale ou quasi-totale de la chaîne de build, jusqu’à la mise en production, sont l’objet d’un gain d’intérêt considérable, passant pour certaines d’entre elles du stade de Trial (à tester) à celui d’Adopt (à adopter): citons d’une part le concept de « Continuous Delivery » — véritable fer de lance de ThoughtWorks dont nous avions déjà fait l’écho ici-même — et d’autre part la culture «  DevOps  », décidément de plus en plus en vogue.

Citons encore le concept de plus en plus répandu de infrastructure as code ou encore le concept novateur d’architecture évolutive (evolutionary architecture): il s’agit de promouvoir une architecture d’entreprise non pas chargée de prédire l’avenir mais constamment adaptée au besoin du moment; plutôt que de deviner comment un composant pourrait être réutilisé, il s’agit ici de prévoir son adaptabilité intrinsèque en favorisant un développement robuste, fondé sur les bonnes pratiques de code, les tests et l’intégration continue.

Côté performance et tests, ThoughtWorks estime que la problématique de la mise en cache des données et de son usage raisonné (thoughtful caching) est souvent négligée et reléguée au rang d’ajustement final, alors qu’il s’agirait d’un élément clé du succès d’une application. De même pour les tests de performance, qui gagneraient à être exécutés dès les phases initiales du projet et sur une base régulière; il n’est d’ailleurs pas nécessaire, pour cela, de faire appel à des frameworks lourds: un simple script peut suffire.

ThoughtWorks salue ensuite la maturité actuelle du développement mobile, en le faisant passer de Trial à Adopt. A l’aide d’outils comme jQuery Mobile et de Selenium (qui commence à se doter de quelques drivers pour mobiles), ainsi que des techniques comme le progressive enhancement (adaptation de l’application aux capacités du terminal mobile), il serait aujourd’hui aussi aisé de développer pour mobiles que pour des desktops. ThoughtWorks met en revanche en garde contre les kits de développement multi-plateformes qui engendreraient davantage de complexité qu’ils ne produisent de bénéfices.

En termes d’outils de développement, c’est sans doute Git et surtout GitHub qui sortent du lot, ce dernier passant d’un seul coup de Assess (à considérer) à Adopt. ThoughtWorks salue la rapidité et l’aisance de cet outil de contrôle de version, tout en récriminant contre des outils concurrents, comme ClearCase ou TFS, qui mettraient des freins à la productivité avec par exemple des contrôles de validité au moment du commit: décidément has been.

Parmi les langages de programmation, JRuby est à l’honneur: selon le radar, le couple Rails 3 + JRuby serait une « plateforme exceptionnelle » dont l’entreprise aurait tort de se priver. Clojure fait quant à lui son entrée dans le radar et se voit saluer une communauté vibrante et des librairies et outils toujours plus complets. Mais c’est HTML5 qui gagne en confiance en passant de Trial à Adopt, notamment grâce au stockage offline; selon ThoughtWorks, il s’agit d’un langage mûr malgré un standard encore sujet à évolution.

Un autre langage dont le radar vante les mérites est bien sûr JavaScript; mais ThoughtWorks met en garde contre un langage parfois trop puissant ou souvent mal maîtrisé, d’où la nécessité de le « cadrer » au travers d’outils de plus en plus répandus, comme Backbone.js (une implémentation du modèle MVC en JavaScript), ou même d’outils encore confidentiels, comme Coffeescript, un compilateur capable de compiler du « coffeescript » en javascript. (Nous nous permettons d’ailleurs d’ajouter à cette liste Require.js, un petit framework pour le chargement asynchrone de fichiers JavaScript.)

La simplicité et la facilité d’utilisation sont prônées un peu partout, notamment dans le domaine SOA, où REST et OAuth s’imposent face à SOAP et aux stacks WS-*; dans le domaine des frameworks web, où l’on voit Play! Framework prendre du galon au détriment de GWT ou des solutions de type portail, qui à force de masquer la complexité en finiraient par brider le développeur; ou encore lorsque ThoughtWorks sort le carton rouge pour les procédures stockées: trop lourdes, pas assez maintenables, elles ne seraient quasiment jamais une bonne solution.

Le cloud n’est pas oublié non plus et, d’une manière générale, le concept de PaaS (Platform as a Service) est à l’honneur: Amazon AWS passe au stade de Adopt tandis que Cloud Foundry fait son entrée dans le radar.

Enfin, la nécessité de métriques fiables et surtout consolidées et historisées de la qualité du code font enfin apparaître Sonar dans le radar: un comble!

Bref, on peut ne pas être d’accord sur tout, on peut mettre en doute l’impartialité du jugement, mais le Technology Radar reste une référence en matière d’analyse conjoncturelle et ses oracles sont de plus en plus suivis. Cette mouture ne préconise-t-elle pas d’ailleurs, assez ironiquement, que chaque entreprise conçoive son propre radar?

Le coin de la technique

Gaelyk v1.0: Google App Engine en Groovy

Guillaume Laforge, castcodeur émérite et surtout celui qui pousse le langage Groovy, nous apprend qu’il vient de sortir la version 1.0 de Gaelyk, son bébé. Démarré mi-2009, le framework se veut léger: il utilise la puissance de la syntaxe Groovy et tourne sur le cloud de Google. L’avantage, par rapport à Grails, est que Gaelyk est pensé des le départ pour tourner sur App Engine, alors que Grails y a souvent eu des problèmes. Bien sûr, on est limité à une version du Cloud, celui de Google, ce qui pose tout de même quelques limitations, mais il faut bien avouer que pour déployer rapidement une application Cloud bénéficiant de toute la puissance de Groovy (pour la syntaxe) et Java (pour les librairies), Gaelyk est très puissant.

La grosse nouveauté de cette version est sans conteste le tant attendu Query DSL qui permettra d’écrire des requêtes directement en Groovy. C’était vraiment la fonctionnalité qui était attendue depuis longtemps et permet au framework de combler le principal manque de manière à offrir une réelle uniformité.

Parmi les autres nouveautés, on notera l’ajout d’un fichier DSLD (descripteur utilisé par Eclipse pour permettre l’auto-complétion), des mises à jour des version de GAE et Groovy et quelques autres fix et ajouts, visibles sur le changelog.

A noter que Guillaume Laforge « eats his own dogfood » et cette release est l’occasion pour lui de migrer son propre blog sur Gaelyk. Il a annoncé qu’il utilisait pour cela un nouveau framework créé par ses soins pour l’occasion, Bloogaey, disponible pour tous sur Github.

Du coté de Grails, rappelons que la V2 se rapproche, nous vous avions annoncé la Milestone 1 la semaine dernière.

La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Jenkins : The Definitive Guide
• Java, Kotlin, Ceylon… Que d’îles !

Le coin de la technique

• Springsource: des nouveautés en pagaille
• Java en entretien technique
• Fork/Join: le multithread facile en Java 7
• Sortie de Groovy 1.8.1 et 1.9 beta 1
• Sortie de Google App Engine SDK 1.5.2
• Scala : vers une version « classique » 2.9.1 et une version .Net
• ClojureScript

Actualité éditeurs / SSII

Jenkins : The Definitive Guide

Wakaleo Consulting sort un ebook gratuitement téléchargeable : Jenkins The Definitive Guide. Comme son nom l’indique c’est un guide très complet sur le serveur d’intégration continue, ex-Hudson. Le guide couvre :

• installation et configuration
• sécurisation
• notifications email, IRC, Jabber, SMS et autres
• structuration des jobs
• promotions de bonnes pratiques de développement, via Checkstyle, PMD, FindBugs et autres plugins

Il est bien écrit (en anglais) et mérite d’y jeter un œil, que ce soit pour apprendre, approfondir ou réviser.

Java, Kotlin, Ceylon… Que d’îles !

Ces derniers temps furent très mouvementés dans le monde des langages alternatifs de la JVM.

On sait maintenant que Kotlin n’est plus seulement connu pour être une île perdue en Russie. C’est aussi un nouveau langage proposé par l’équipe de JetBrains censé tourner sur JVM (et encore un de plus, diront certains). Dans les particularités remarquables du langage, nous trouvons :

• les closures et les fonctions d’ordre supérieur,

fun  filter(Iterable items, predicate : fun(T) : boolean) : Iterable { … }
filteredPersons = filter(persons, { it.getAge() >= 18 });

• les fonctions d’extension qui permettent d’ajouter de nouvelles méthodes à des classes,
• le pattern matching,

when (x) {
  is Int => print(x)
  is List => print(x.sum())
  !is Number => print("Not even a number")
  else => print("can't do anything")
}

• La notion de tuple,
• La couche objet habituelle avec des classes finale par défaut,
• La réification des generics permettant de conserver les informations sur le type des arguments d’un type générique au runtime.

Ce langage, vous ne pouvez pas encore l’utiliser car il n’est actuellement disponible qu’à l’état de spécification. Un peu comme Ceylon, en fait, qui est aussi une île. Et d’ailleurs, comme Ceylon, il se veut être une simplification de Scala. Bien sûr, ce nouveau langage à créé le buzz auprès de la communauté des développeurs Java et Scala.

D’ailleurs Gavin King en a profité pour nous donner un rapport d’avancement sur Ceylon. Et bien… Il avance dans le travail de son compilateur. Mais il semble qu’après l’annonce de Kotlin, Gavin s’est malheureusement attiré à lui le buzz et la guerre pseudo-fratricide qui l’accompagne. La situation lui ayant échappé, Gavin a décidé de fermer les commentaires de son post.

Tous ces nouveaux langages ont donné envie à Stephen Colebourne d’écrire un essai (au sens littéraire du terme) sur deux notations utilisées dans la déclaration de type : la déclaration de type classique (comme en Java ou C) et la déclaration de type inversée (comme en Scala ou en Pascal). Stephen réalise sa démonstration au travers de différents langages : Java, Java avec les lambdas expressions en utilisant la proposition strawman, Java avec les lambdas expressions en utilisant la proposition BGGA, Ceylon, Fantom, Gosu, Kotlin et Scala. Nous vous laissons lire l’article et en tirer vos propre conclusions.

Le coin de la technique

Springsource: des nouveautés en pagaille

SpringSource nous fait le plein de nouveautés avec plusieurs sorties:

Spring Data JPA 1.0

Le projet Spring Data vise à faciliter les accès aux bases de données et à gagner encore et toujours en productivité. Au travers de cette API, il est possible d’utiliser aussi bien des bases NoSQL que des bases relationnelles.

L’API est pour l’instant relativement succincte. Il est possible de faire du CRUD et de l’interrogation sans écrire une seule requête grâce à un système de convention de nommage des méthodes.

L’interface de base se nomme Repository. Si votre interface UserRepository étend Repository et définit une méthode findByName(String name), vous pouvez directement l’utiliser pour rechercher vos éléments. Le framework, en fonction de l’environnement que vous avez, construira une requête sur l’entité User en cherchant celle qui a le nom donné en paramètre. Vous définissez le contrat, le framework s’occupe de l’implémentation.

Avec Spring Data JPA 1.0 qui arrive en release finale, il est possible d’utiliser JPA 2.0 au travers de l’abstraction fournie par Spring Data. En plus du CRUD, l’API Criteria de JPA a été portée avec son lot de prédicats. Il est aussi possible d’utiliser des Queries en JPQL et de les associer aux méthodes du Repository pour des implémentations personnalisées de certaines méthodes. Cette première version reste verbeuse, mais Spring assure vouloir réduire le code technique avec la maturité à venir de son nouveau produit.

Spring Data 1.1.0.M2

Spring Data Graph 1.1.0.M2 en version minestrone ajoute de nouvelles fonctionnalités sur la gestion de la base de données orientée graphe Neo4J. En plus de la correction de quelques bugs, l’API supporte maintenant la version 1.4. Tant que nous y sommes, si vous choisissez d’étudier les bases de données graphe, essayez Gephi pour la visualisation et l’exploration des données: c’est visuellement intéressant !

Spring Gemfire 1.1.0.M1

Spring Gemfire est arrivé en version 1.1.0.M1 la semaine dernière.

Les applications propulsées par Spring peuvent déjà se préparer à utiliser la version 6.6 du système de gestion de données réparti de VMWare. Il permet aussi d’utiliser l’abstraction de cache apportée par Spring 3.1. La connexion aux Cache Server de GemFire est rendue disponible (pour la réplication de session HTTP par exemple). Enfin, pour la création de requête, dites au revoir à la génération par chaînes de caractères (avec inclusion des paramètres), et bonjour au templating avec l’utilisation des paramètres variables.

Java en entretien technique

Ah les questions techniques lors d’un recrutement… Quel développeur n’a jamais eu peur de faire face à ces questions alors même qu’il estime bien connaître les méandres de la spec Java. Mais les points flous et d’incompréhension peuvent être nombreux !
Dans un récent post, Peter Lawrey revient sur certains de ces points et nous livre son analyse. Nous ne reparlerons pas (zut, trop tard !) de l’éternel « pass by value VS pass by reference » qui génère toujours beaucoup de commentaires, mais nous pourrons citer par exemple:

• Les modificateurs transient et volatile
• Overriding, overloading: lequel fait quoi ?
• que retourne boolean.class.getSuperclass() ?
• Rappelez moi la définition d’un Java Bean ?

Ainsi que quelques autres questions. Rien de bien nouveau mais une petite piqûre de rappel fait toujours du bien, même aux plus calés.

Tant que nous sommes sur les questions lors d’une entretien, n’oubliez pas que si vous avez à réaliser un bout de code mais pas vraiment l’envie de le faire, il est toujours possible de s’en sortir en utilisant la technique suivante. Dans celle-ci, l’auteur pousse l’exagération jusqu’à la mauvaise fois en demandant des spécification extrêmes sur ce qui lui est demandé de réaliser, une simple copie de fichiers. Notez qu’il est formellement déconseillé d’utiliser cette technique lors d’un entretien chez Xebia

Fork/Join: le multithread facile en Java 7

Alors que le nombre de core par CPU ne cesse de croître, il serait peut être temps que nous utilisions à bon escient les ressources disponibles sur nos serveurs, non ? Java sait depuis toujours faire du multi-threading (encore heureux !) mais il est généralement très compliqué de faire du code multi-threadé efficace et maintenable. Notamment, la synchronisation entre les différent Thread a toujours été source de problèmes. Java 5 puis 6 apportèrent d’importantes innovations, sous la forme du package java.util.concurrent qui fournit:

• les Executors, qui abstraient des pools de threads, ainsi que les Future et Callable
• des queues et Collections thread-safe
• le support de la déclaration de timeout sur les opérations
• des classes implémentant des patterns de synchronisation et d’exclusion mutuelle, comme les Barrier ou Countdown Latch (plus de détails chez O’Reilly)
• le package java.util.concurrent.atomic fournissant des wrappers pour des variables simples permettant des opérations de modification atomiques sur ces variables

Ces apports au langage étaient les bienvenus. Néanmoins, certains type de tâche, et notamment les algorithmes de type « diviser pour régner » ou « map/reduce », requièrent des fonctionnalités qui n’étaient pas offertes .

Julien Ponge nous gratifie d’un article sur Oracle Tech. Network avec l’exemple d’utilisation suivant: on désire compter le nombre d’occurrences d’un mot donné dans des fichiers répartis dans une arborescence du filesystem. Et ca tombe bien, Java 7 fournit justement une implémentation du principe fork/join au travers de la classe abstraite ForkJoinTask et de ses sous-classes. Le filesystem est parcouru grâce à des tâches récursives, mais parallèles. Initialement on a une tâche de type FolderSearchTask qui étend RecursiveTask et crée:

• pour chaque répertoire, une nouvelle tâche FolderSearchTask
• pour chaque document, une DocumentSearchTask qui étend aussi RecursiveTask et compte le nombre d’occurrences du mot recherché

Au final l’algorithme est rendu quasi-trivial avec l’utilisation du nouveau Framework, alors qu’il n’en aurait pas été de même avant Java 7. En effet celui-ci permet de résoudre des problèmes récursifs dont ne ne connaît à priori pas la taille. Dans le cas exposé le comptage débute alors qu’on ne sait pas quelle sera la profondeur du système de fichiers ni le nombre de documents qui sera rencontré.

Une image valant mieux qu’un long discours, voici une illustration assez explicite accompagnant l’article dont nous vous conseillons fortement la lecture:

Sortie de Groovy 1.8.1 et 1.9 beta 1

Le projet Groovy continue à avancer et sort la première version corrective de la branche 1.8 et sa nouvelle beta de la 1.9.

Au menu pour la 1.8.1 :

• plus de 40 bugfixes.
• amélioration du JSonBuilder avec un mode streaming.
• la suite du chantier sur les performances des opérations arithmétiques sur type primitifs.

Pour la 1.9 beta 1 :

• plus de 20 bugfixes
• intégration des nouveautés Java 7 liées au Project Coin

Pour le détail complet, voir l’annonce sur DZone ou les release notes JIRA des versions 1.8.1 et 1.9 beta 1.

Sortie de Google App Engine SDK 1.5.2

Une nouvelle version 1.5.2 du SDK de Google App Engine vient de sortir. Pour rappel, GAE est une plateforme as a service (PaaS) permettant d’héberger dans le cloud des applications web Java et Python ( et prochainement Go, le nouveau langage développé par Google).

En plus de quelques bogues corrigés, cette release apporte quelques nouveautés intéressantes, comme :

• Des paramètres pour ajuster le ratio coût/performance de l’application: Possibilité de définir le nombre minimale d’instances au repos, et la latence minimale d’attente, qui permet d’ajuster le temps minimum qu’une requête doit attendre dans la queue avant d’être traitée par une instance.
• Suppression de la contrainte de créer des index explosés pour « les big entities » et réduction des index personnalisés.
• Les statistiques du Datastore peuvent être regroupées par espace de nom.
• Des informations supplémentaires ont été ajoutés à la page d’administration des Task Queue.
• La limitation de la taille de la Pull Task est passée à 1MB.

Pour plus d’infos, voir la release note.

Force est de constater que la plateforme de Google s’enrichit de release en release. De nombreuses limitations se réduisent voire disparaissent au fur et à mesure. Les possibilités de monitoring, de tuning, et d’administration des backends commencent à bien s’étoffer.

Scala : vers une version « classique » 2.9.1 et une version .Net

Scala va bientôt une version 2.9.1 qui est maintenant disponible en première Release Candidate. Cette version devrait corriger un certain nombre de bug et mettre en place des améliorations en particulier au niveau de l’interpréteur.

Par ailleurs, Miguel Garcia, de l’équipe Scala à l’EPFL, vient d’annoncer une avancée majeure dans l’adaptation du langage de Martin Odersky à la plateforme .NET. Dans ce projet financé par Microsoft, l’adaptation a été rendue possible grâce au projet IKVM.NET. IKVM est un projet mature et toujours en activité qui implémente un framework Java dédié aux plateformes Mono et .NET. On y trouve :

• la JVM compilée pour .NET,
• une implémentation .NET de bibliothèques Java,
• et un convertisseur JAR vers DLL.

Miguel a mis en place un plugin apppelé jdk2ikvm pour le compilateur Scala qui permet de convertir un programme Scala pour JDK en programme Scala pour IKVM et donc .NET. Les développements ne sont actuellement pas complètement stabilisés, mais ils sont utilisables aux dires de l’auteur. Parmi les développements futurs, Miguel prévoit de développer un plugin Scala pour l’IDE Visual Studio et l’adaptation des collections concurrentes aux modèle de gestion de thread de .NET.

ClojureScript

Du côté de Clojure, l’annonce a été faite par Rich Hickey en personne (le créateur de Clojure) lors du Clojure NYC Meetup de juillet. Rich nous a appris la sortie de ClojureScript (voir la vidéo). ClojureScript est une adaptation de Clojure non pas à la plateforme .NET, mais à la plateforme JavaScript. Vous écrivez vos programmes en Clojure et ça vous le compile en JavaScript. La motivation derrière ce projet vient du fait que JavaScript est un langage donnant un accès un scope d’applications de plus en plus large, allant du client au service. Cependant, les développeurs de ClojureScript considèrent que la langage JavaScript possède un certain nombre de faiblesses, notamment pour la construction d’applications robustes qui nécessite de la discipline et le respect de conventions. C’est sur ce point que ClojureScript compte apporter des solutions. Il est possible récupérer une version depuis GitHub.

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.

Du 17 au 19 mai se tiendra à Copenhague la grand-messe des technologies Groovy en Europe : la GR8Conf. Xebia France y sera pour couvrir l’évènement.

Parmi les sujets abordés :

• Groovy : à tout seigneur, tout honneur
• Grails : et notamment son adoption en entreprise
• Gradle : l’outil de build qui monte
• Gaelyk : la boite à outil Groovy pour Google AppEngine
• Griffon : le framework inspiré de Grails pour les applications de bureau
• GPars : la librairie Groovy orientée concurrence, Actors, fork-join, etc

De nombreux speakers seront présents, notamment Guillaume Laforge, Burt Beckwith, Dierk König, et bien d’autres. Comme toujours dans ces grosses conférences, il faudra choisir entre des sessions en parallèle, mais nous essaierons de vous informer sur les plus intéressantes, pour dresser l’état de l’art et le futur des technologies Groovy en 2011.

Les 3 jours de conférence se découpent en :

• une journée « University », où les participants pourront réviser les bases du Groovy, de Grails et coder comme des fous au HackerGarten.
• 2 jours de conférence plus « classique » avec différents acteurs du monde Groovy

Vous trouverez le programme complet ici.

Actualité éditeurs / SSII

• Sortie de la version 1.8 de Groovy

RIA

• Flex 4.5 SDK, Flash Builder 4.5 et Flash Catalyst CS 5.5 enfin disponibles

Le coin de la technique

• Gavin King persiste et signe… 9 billets sur Ceylon

Actualité éditeurs / SSII

Sortie de la version 1.8 de Groovy

Guillaume Laforge, le chef de projet de Groovy, vient d’annoncer sur son blog la sortie de la version 1.8 du célèbre langage de scripting pour la JVM.

Le millésime semble de qualité avec de nombreuses fonctionnalités nouvelles et améliorations – certaines fonctionnalités très populaires ont d’ailleurs été backportées sur la version 1.7. A noter également que, comme le signale Burt Beckwith sur son blog, Grails 1.4 a été mis à jour pour supporter cette nouvelle version.

Nous vous proposons ici un bref aperçu des principales nouveautés; les exemples sont tirés ou inspirés des notes de version, très complètes. Signalons encore une série d’articles publiés très récemment par Mr. Haki sur son blog et qui donnent une description encore plus détaillée de certaines nouveautés de Groovy 1.8.

Support de JSON

De même que pour l’XML, Groovy supporte désormais nativement le langage JSON. Il est ainsi possible, grâce à la classe JsonSlurper, de parser un contenu JSON, de même qu’il est possible d’écrire du code JSON grâce à la classe JsonBuilder:

import groovy.json.*
def json = new JsonBuilder()
json.person {
    name "Guillaume"
    age 33
    pets "Hector", "Felix"
}
println json.toString()

Ce code produit en effet la sortie JSON suivante:

{"person":{"name":"Guillaume","age":33,"pets":["Hector","Felix"]}}

Processus de compilation et transformations de l’Arbre Syntaxique Abstrait

Tout d’abord, une nouveauté prometteuse nous est offerte sous la forme des compilation optimizers: ces « optimiseurs de compilation » permettent de modifier – de façon globale – le comportement du compilateur Groovy; plus précisement, il est possible d’agir sur les niveaux suivants:

1. ImportCustomizer: ajouter des imports « par défaut »;
2. SecureASTCustomizer: filtrage par classe afin d’autoriser ou de prohiber l’utilisation de certaines classes, ce qui permet de sécuriser le code à compiler;
3. ASTTransformationCustomizer: appliquer des transformations AST sur toutes les classes à compiler.

D’autre part, de nouvelles transformations de l’AST sont disponbiles. En voici quelques-unes:

• Il est possible d’injecter un logger dans une classe grâce aux annotations @Log (pour java.util.logging), @Commons (pour commons-logging, @Log4j (pour Log4J) et @Slf4j (pour SLF4J).
• Les annotations @ToString et @EqualsAndHashCode permettent de générer facilement des implémentations de toString(), equals() et hashCode().
• L’annotation @AutoClone permet quant à elle de générer une redéfinition de la méthode clone() et de rendre la classe annotée Cloneable. Différentes stratégies d’implémentation sont possibles: appel de super.clone(), clonage des propriétés de l’objet, appel d’un constructeur par copie, ou encore sérialisation (si l’objet implémente Serializable).
• Les annotations @ThreadInterrupt, @TimedInterrupt et @ConditionalInterrupt permettent respectivement de vérifier qu’un thread a été interrompu, d’interrompre un thread au bout d’un laps de temps et de l’interrompre sous condition.
• Les annotations @WithReadLock et @WithWriteLock permettent de gérer l’accès à une ressource partagée avec une granularité plus fine que celle proposée par la transformation @Synchronized, en utilisant un moniteur de type java.util.concurrent.locks.ReentrantReadWriteLock.

Des descriptions plus détaillées de ces nouvelles transformations sont disponibles ici et ici.

APIs pour la programmation concurrente

Groovy est désormais packagé avec GPars, une puissante et flexible librairie – elle-même en Groovy – proposant de nombreuses APIs pour l’exécution concurrente, asynchrone et/ou distribuée de tâches écrites en Java ou en Groovy. Tous les patterns les plus connus, du Fork/Join au Map/Reduce en passant par les Agents et Actors, sont désormais à la disposition du développeur Groovy.

Ecriture de langages dédiés

L’écriture de langages dédiés ou DSLs (Domain Specific Languages) avec Groovy gagnera en lisibilité grâce à la possibilité de supprimer les parenthèses et les points lors d’un chaînage d’appels de méthodes. Il devient possible d’écrire dans un style fluide très proche du langage naturel; l’exemple suivant est particulièrement frappant:

show = { println it }
square_root = { Math.sqrt(it) }
def please(action) {
  [the: { what ->
    [of: { n -> action(what(n)) }]
  }]
}
//version allégée
please show the square_root of 100
//version classique
please(show).the(square_root).of(100)

Dans un autre post, Guillaume Laforge s’offre même le luxe de concocter une recette de cuisine plutôt lisible:

Recipe.instructions {
   take medium_bowl
   combine soy_sauce, vinegar, chili_powder, garlic
   place chicken into sauce
   turn once to coat
   marinate 30.minutes at room_temperature
}

Closures

Rien de révolutionnaire, mais quelques améliorations notables:

• Il est désormais possible de spécifier des closures comme arguments d’annotations. Ceci ouvre des perpectives intéressantes notamment dans le cadre d’une programmation par contrat, qui pourrait tirer parti de cette nouvelle fonctionnalité pour spécifier sous forme d’annotations des invariants de classe, des pré et post-conditions, etc. Ce genre d’artifice ressemblerait à ceci:

//invariant
@Retention(RetentionPolicy.RUNTIME)
@interface Invariant {
    Class value() // stocke la closure
}
//utilisation de l'invariant
@Invariant({ number >= 0 })
class Distance {
    float number
    String unit
}

L’annotation @Invariant, définie par l’utilisateur, utilise une closure pour spécifier de façon élégante et concise un invariant de classe.

Lorsqu’il s’agit de vérifier l’invariant, cependant, on peut regretter que le code ne soit pas tout aussi trivial, en raison – apparemment – de problèmes de compatibilité:

def d = new Distance(number: 10, unit: "meters")
def anno = Distance.getAnnotation(Invariant)
def check = anno.value().newInstance(d, d)
assert check(d)

• Les nouveaux opérateurs >> et << permettent d'alléger l'écriture des closures composées:

def plus2  = { it + 2 }
def fois3 = { it <strong> 3 }
//version longue
fois3plus2 = { x -> plus2(fois3(x)) }
//version courte
fois3plus2 = plus2 << fois3

• L'utilisation du trampolining permet d'éviter les dépassements de pile (stack overflows) en transformant la récursion terminale de certains algorithmes en code itératif. Alors que le code suivant produit un dépassement de pile à l'exécution:

​def factorial
factorial = { int n, BigInteger accu = 1G ->
    if (n < 2) return accu
    factorial(n - 1, n </strong> accu)
}
println factorial(1000) ​//java.lang.StackOverflowError
​

La version "en trampoline" du même algorithme s'exécute sans problème:

def factorial
factorial = { int n, BigInteger accu = 1G ->
    if (n < 2) return accu
    factorial.trampoline(n - 1, n * accu)
}
factorial = factorial.trampoline()
println factorial(1000)

Grâce à l'appel de la méthode trampoline() qui enveloppe les appels récursifs dans des wrappers de type TrampolineClosure, tant que le "trampoline" appelant reçoit en retour des instances de TrampolineClosure, il continue d'invoquer itérativement la fonction sous-jacente, ne s'arrêtant que lorsque l'objet de retour n'est plus un trampoline. La pile d'appels ne grossit donc pas de façon incontrôlée.

• Le support de la mémoization permet désormais aux closures effectuant de lourds calculs de mettre en cache le résultat des appels en fonction des arguments en entrée.

• La curryfication est désormais possible aussi en partant de la droite, voire même en désignant de façon arbitraire un argument par sa position dans la liste d'arguments.

Autres sucres syntaxiques

• Support du diamond operator de Java 7:

List<List<String>> list1 = new ArrayList<>()

• Nouvelles méthodes DGM (Default Groovy Methods), toujours pratiques, par exemple countBy qui, dans l'exemple suivant, compte le nombre d'occurrences de nombres pairs et impairs dans une liste d'entiers:

assert [0:2, 1:3] == [1,2,3,4,5].countBy{ it % 2 }

• Les slashy strings sont désormais multilignes:

def poem = /
to be
or
not to be
/

• Une nouvelle variante des slashy strings appelée dollar slashy string permet de définir une GString multiligne dans laquelle il n'est pas nécessaire d'échapper le backslash; pratique pour noter du XML ou bien des chemins de fichiers Windows:

def dir = $/C:temp/$

Performances

Enfin, il faut noter que la version 1.8 de Groovy inaugure des chantiers sur les performances du langage. Avec deux améliorations profitables :

• Sur les opérations basiques sur les entiers (additions, soustractions, multiplications, divisions, incréments, décréments et comparaisons). Il faut cependant se rappeler que les optimisations de cette version ne s'appliquent que sur des opérations d'un type unique. Si vous mixez, par exemple, additions et soustractions dans une même ligne de code, vous n'en profiterez pas.

• Sur les appels de méthodes directs. Si un appel de méthode est lancé sur this et que le prototype correspond à une méthode présente (aux types près), Groovy passera outre ses mécanismes de réfléxion standard. Là aussi, faites bien attention aux restrictions pour en tirer parti.

Cela peut paraître maigre mais ce n'est que le début de plus gros chantiers de performances qui auront lieu au cours de la vie de la branche 1.8. Peut-être la fin de la politique "fast enough" de Groovy ?

RIA

Flex 4.5 SDK, Flash Builder 4.5 et Flash Catalyst CS 5.5 enfin disponibles

Bonne nouvelle pour la communauté Flex: aujourd'hui, sort officiellement Flex 4.5 SDK , Flash Builder 4.5 et Flash Catalyst CS 5.5. Après quelques mois en pré-release, disponible en téléchargement privé, la team Flex a profité des retours des utilisateurs qui ont testé les produits. Plus axées sur le développement mobile, ces nouvelles versions permettent de développer des applications riches autant pour le web que pour le desktop ou pour d'autres supports comme les mobiles et les tablettes.

Dans cette nouvelle version de Flash Builder, seul le déploiement sur Android est prévu. Mais une nouvelle version disponible en juin vous permettra de déployer vos applications sur iOS et Blackberry Tablet OS. Parmi les autres nouveautés : un Flash Builder permettant de développer plus rapidement et un workflow amélioré entre Flash Builder et Flash Catalyst : vous pourrez maintenant passer du premier au second sans difficulté pour retravailler le design.

Le coin de la technique

Gavin King persiste et signe... 9 billets sur Ceylon

Il y a à peine deux semaines on évoquait ici-même la présentation qu'avait faite Gavin King du nouveau langage Ceylon, et de l'accueil plutôt mitigé que la communauté lui avait réservé.

Sans doute piqué au vif, Gavin King a publié cette semaine une série de neuf articles (d'autres sont peut-être encore à venir) où il présente le langage avec beaucoup plus de détails et de finesse.

A travers notamment les commentaires des lecteurs, on remarque au fil des billets un certain regain d'intérêt pour ce langage, au fur et à mesure que les contours s'en précisent et que certaines questions trouvent leur réponse. Malgré tout, le langage semble encore souffrir d'un caractère quelque peu confidentiel, et les échanges tournent parfois au débat d'experts. Il faut également noter que la volonté affichée de réécrire un SDK complet pour Ceylon semble laisser certains observateurs sceptiques.

Sans revenir sur les caractéristiques du langage lui-même – nous laissons à nos lecteurs le soin de parcourir ces billets – nous avons concocté un résumé des échanges entre Gavin et ses lecteurs sous la forme de questions-réponses:

Qui travaille dans le projet Ceylon?

S'il admet être le seul à y travailler à temps complet, Gavin révèle tout de même que l'équipe Ceylon compte parmi ses membres quelques blogueurs de In Relation To, parmi lesquels Emmanuel Bernard, Aleš Justin, Jason Greene, Max Handersen et Pete Muir – nous sommes donc bien dans la mouvance Hibernate - Red Hat - JBoss. Toujours d'après Gavin, certains membres de l'équipe OpenJDK (Andrew Haley et Gary Benson) y travailleraient aussi, et enfin, quelques personnes de chez Red Hat (Andrew Dinn, David LLoyd et surtout Mark Little).

Quel est l'état d'avancement du projet?

Gavin admet que l'écriture du parseur ANTLR ne fut pas une partie de plaisir et lui a demandé des mois de travail; cependant, le parsing et la génération de l'AST sont d'après lui terminés et il travaille désormais sur le compilateur: le typechecker est en bon état d'avancement, mais la génération du bytecode aurait pris du retard.

Quel degré d’interopérabilité avec Java?

Il y aura une certaine interopérabilité, mais celle-ci sera mise à mal en raison de l'inexistence de wildcard types et de surcharge de méthodes en Ceylon. Concernant la surcharge, Gavin envisage d'utiliser le principe des GADT (Generalized Algebraic Data Types), inspirés d'Haskell, pour "unifier" les surcharges de méthodes.

Mais plutôt que parler de portage de frameworks Java en Ceylon, Gavin préfère tabler sur l'apparition spontanée de nouveaux frameworks en Ceylon qui viendraient remplacer les frameworks Java à la mode. L'ambition de Ceylon à cet égard semble en effet un point marquant du nouveau langage. Gavin est formel: "nous avons comme but explicite de créer un nouveau SDK (et par là nous entendons vraiment une série de modules que nous allons écrire nous-mêmes)".

Et Gavin de lister les modules sur lesquels il souhaite se concentrer dans l'immédiat:

• ceylon.language - types de base pour le support des fonctionnalités inhérentes au langage
• ceylon.module - le runtime assurant la modularité (basé sur JBoss Modules)
• ceylon.collection - le framework de collections (l'implémentation sous-jacente serait fournie par le framework Java équivalent)
• ceylon.datetime - support des dates et heures (probablement basé sur la JSR-310)
• ceylon.security - API sécurité
• ceylon.io - Utilitaires d'entrée-sortie (implémentés en utilisant java.io)
• ceylon.concurrent - API pour la programmation concurrente "de bas niveau" (basée sur JSR-166)
• ceylon.http - client et serveur HTTP (peut-être fondé sur Netty)
• ceylon.html - le "Kit de construction" HTML

Par ailleurs, Gavin précise que le compilateur Ceylon est conçu pour s'intégrer avec OpenJDK et pour pouvoir compiler simultanément du code Java et du code Ceylon. Cependant la version initiale (alpha) du compilateur ne contiendra que les modules du langage lui-même.

La modularité

Gavin confirme que la notion de module – une sorte de "super package" avec ses propres portées de visibilité – sera bâtie au sein du langage. Mais il ne s'arrête pas là: il envisage également une entité plus large encore que le module, qu'il baptise assembly. Ceci porte à trois le nombre de niveaux de modularité:

1. package
2. module, matérialisé notamment par une archive dans un format précis, éventuellement déployable sur un dépôt de modules
3. assembly: agrégation de différents modules

Le compilateur ne produirait d'ailleurs pas de fichiers ".class", mais plutôt des archives déployables sur un dépôt local ou distant. De même, il saurait retrouver des dépendances requises depuis ces dépôts.

Quant au runtime, il s'agirait bien de JBoss Modules. Celui-ci saurait gérer les archives et les problématiques de class loading et aussi rechercher et exécuter les modules définis dans sa configuration.

Le mécanisme de validation de Grails est basé sur l’API Spring Validator. Il existe dans Grails un ensemble de validateurs permettant de couvrir la plupart des besoins simples, tels que champs obligatoires, taille mini/maxi, valeurs min/max pour les nombres, etc. Cependant, il arrive souvent d’avoir besoin de validateurs sur mesure, plus adaptés au métier de l’application. Aujourd’hui nous allons voir les différentes méthodes de validation avancées des classes du domaine qui s’offrent aux utilisateurs de ce framework web magique :

• Retour sur la contrainte validator
• Faire une contrainte réutilisable
• Le plugin Constraints

Suivez le guide…

Validation sur mesure

Il existe 16 contraintes applicables sur les attributs des classes de domaine dans une application Grails. Ces contraintes permettent de s’assurer de la validité du contenu de nos entités avant de les envoyer en base. Elles vont de la vérification de la nullité, de la taille d’une chaîne, à la correspondance à une expression régulière, et j’en passe.

Mais parfois, il est indispensable de valider nos attributs en fonction de critères plus fins, ou liés à des logiques métiers complexes. C’est alors que la 17ème contrainte livrée avec Grails peut servir : validator.

Grâce à cette contrainte, on peut glisser une closure qui sera exécutée lors de la validation de l’entité. Voici la page de la documentation officielle qui détaille son utilisation. Pour ceux qui n’ont pas le temps d’aller lire la documentation voilà un exemple assez parlant :

class User {
  String login
  String autreChamp
  static constraints = {
    login(validator: { val, obj ->
      return (val.length != 0 && obj.properties['autreChamp'] != 'magicString')
    })
  }
}

Dans cet exemple, si la contrainte n’est pas respectée, alors le message d’erreur associé sera, par convention : user.login.validator.invalid.

Ce mécanisme est très pratique et flexible, mais oblige à dupliquer du code si on souhaite utiliser la même contrainte complexe sur plusieurs classes de domaine. Poussons plus loin l’investigation.

Faire mieux, à la main

Il est possible d’écrire ses propres classes de contrainte et de les réutiliser plusieurs fois. Cet article décrit très bien la méthode à suivre. Je vais vous en tracer les grandes lignes ici, en français dans le texte.

Pour écrire un validateur réutilisable, il suffit d’étendre la classe AbstractConstraint et d’implémenter la méthode processValidate. En voici un exemple :

package myapp
import org.codehaus.groovy.grails.validation.AbstractConstraint
import org.springframework.validation.Errors
class LowerCaseConstraint extends AbstractConstraint {
// nom à utiliser dans les classes de domaine
    static NAME = 'lowerCase'
    String getName() {
        NAME
    }
// si le validateur ne s'applique qu'à certaines classes, cette méthode permet de filtrer l'application de la contrainte
    boolean supports(Class type) {
        true
    }
// code de la logique de validation
    protected void processValidate(Object target, Object value, Errors errors) {
        if (constraintParameter && value =~ /[A-Z]/)
            rejectValue target, errors, "default.invalid.${name}.message", "${name}.invalid",
                [constraintPropertyName, constraintOwningClass, value] as Object[]
    }
}

La place idéale dans votre arborescence projet pour cette classe se trouve dans le répertoire src/groovy. Une fois votre classe de contrainte terminée, il faut l’enregistrer auprès du framework pour que Grails sache où la retrouver. Pour ce faire, ajoutez cette ligne dans votre fichier grails-app/conf/Config.groovy :

org.codehaus.groovy.grails.validation.ConstrainedProperty.registerNewConstraint myapp.LowerCaseConstraint.NAME, myapp.LowerCaseConstraint.class

Il ne reste plus qu’à vous en servir dans vos classes de domaine :

static constraints = {
    myProperty size: 1..20, lowerCase: true
}

Le plugin existe déjà : Constraints Plugin

Mais comme souvent quand on parle de Grails : il y a un plugin pour ça ! Le plugin Constraints fourni des scripts pour générer des classes de contraintes réutilisables. En deux lignes de commandes, le tour est joué, installation et création de contrainte :

grails install-plugin constraints
grails create-constraint my.package.ContrainteSurMesure

Dans la classe générée, il ne vous restera plus qu’à coder une closure de validation, comme on l’aurait fait dans la première solution. Un grand merci à Geoff Lane qui s’est donné la peine de coder ce plugin. Il est possible de configurer certains comportements de ce plugin, mais je vous laisse consulter la documentation pour découvrir dans quelle mesure.

Conclusion

L’usage du plugin Constraint est très simple et permet beaucoup de choses. N’hésitez pas à vous en servir. Je vous encourage également à exploiter au maximum la formidable extensibilité de Grails. Pourquoi ne pas coder vos validateurs dans un nouveau plugin qui s’appuiera sur le plugin Constraints ? Ainsi vous disposerez d’un paquetage de validateur sur mesure, à installer en claquant des doigts dans tout nouveau projet Grails démarrant chez vous.

What else ?

Grails, c’est bien. Ça permet des développements rapides, simples et efficaces. Mais à moins de faire du jetable pour tester, un jour, il faut livrer. Se pose alors, souvent tard, la question de la configuration de l’application au runtime.

Nous allons voir ensemble quelques solutions pour externaliser proprement les clés de configuration pour un projet basé sur Grails.

Out of the box

Grails, par défaut, nous offre la possibilité de charger des fichiers de configuration externe de façon assez simple. Le chargement s’effectue suivant une logique simple :

• Tout ce qui se trouve dans le fichier Config.groovy vient en premier
• Toutes les clés présentes dans les fichiers externes viennent s’ajouter à la configuration, ou surcharger les valeurs de Config.groovy.

Ce mécanisme est documenté et très simple à mettre en œuvre. Il suffit de placer les quelques lignes suivantes au début du fichier grails-app/conf/Config.groovy :

grails.config.locations = [ "classpath:${appName}-config.properties",
                            "classpath:${appName}-config.groovy",
                            "file:${userHome}/.grails/${appName}-config.properties",
                            "file:${userHome}/.grails/${appName}-config.groovy" ]

Comme on peut le voir dans cet exemple tiré de la documentation, on peut même utiliser des variables dans les chemins spécifiés. Plutôt simple, n’est-il pas ? Le problème est réglé ? Ça conviendra très bien à la plupart des petits projets montés en local, cependant, l’utilisation de chemins en dur (ou modulo certaines variables) directement dans le Config.groovy est un peu rigide. Il est souvent problématique de livrer un war à un exploitant en lui expliquant que le fichier de configuration doit se placer à tel chemin et pas un autre.

Voyons si on peut trouver mieux…

Par variable d’environnement ou propriété JVM

L’idéal serait de pouvoir définir le chemin vers le fichier de configuration depuis l’extérieur du war. Pour faire cela, on peut se baser sur des variables d’environnement. Le fichier Config.groovy est, avant toute chose, un script Groovy ! Par conséquent, aucun problème pour inclure un peu de code dedans et récupérer des valeurs depuis le système.

On pourrait par exemple remplacer l’exemple du précédent paragraphe par :

// On fixe le nom de la variable d'environnement qui nous intéresse
def ENV_NAME = "APPNAME_CONFIG"
// Si la liste grails.config.location n'existe pas, on l'instancie
if(!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []
}
// Si la variable est présente dans l'environnement ...
if(System.getenv(ENV_NAME)) {
  // ... on inclut sa valeur dans les configuration à charger
  println "Including configuration file specified in environment: " + System.getenv(ENV_NAME);
  grails.config.locations << "file:" + System.getenv(ENV_NAME)
} else if (System.getProperty(ENV_NAME)) {
  // Sinon on regarde dans les propriétés JVM et on l'inclut si elle est présente
  println "Including configuration file specified on command line: " + System.getProperty(ENV_NAME);
  grails.config.locations << "file:" + System.getProperty(ENV_NAME)
} else {
  // Si vraiment on ne trouve rien, on le dit quand même, parce que ça se fait.
  println "No external configuration file defined."
}

Extrait de cet article et commenté maison

Si vos administrateurs sont complaisants, cette méthode peut être votre solution. Mais beaucoup rechigneront à toucher à leur environnement système pour faire plaisir à votre code chéri (du moins c’était le cas parmi ceux que j’ai rencontrés). Cela risque également de poser des problèmes dans le cas où l’on souhaite faire tourner plusieurs instances de notre application sur le même serveur avec des configurations différentes. Dans ce cas, la grimace de l’administrateur devant son environnement système se remplissant de toute une famille de variables vaut le coup d’œil.

Poussons donc un peu plus loin…

Par entrée JNDI

Plutôt que de toucher à l’environnement du système, nous pouvons nous contenter de toucher à l’environnement d’exécution de notre application. JNDI arrive à la rescousse. En s’appuyant non pas sur des variables système mais sur des variables JNDI, on cantonne nos modifications au serveur d’applications. Le lien entre l’instance et son fichier de configuration est plus étroit et donc plus évident à manipuler.

Modifions une dernière fois notre en-tête de chargement de configuration (toujours dans Config.groovy) :

import javax.naming.InitialContext
// Si la liste grails.config.location n'existe pas, on l'instancie
if(!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []
}
try {
  // On tente de récupérer la variable d'environnement JNDI
  String extConfFile = (String) new InitialContext().lookup("java:comp/env/myAppInstanceConfig")
  // Si on trouve notre valeur, on l'ajoute aux fichiers à charger
  if (extConfFile) {
    grails.config.locations << extConfFile
    println "External configuration file loaded : ${extConfFile}"
  }
} catch (Exception e) {
  // En cas d'absence de la variable, on log
  println "Unable to load external configuration, using default."
}

Il suffira pour appliquer une configuration particulière, de définir la variable JNDI pour notre déploiement. Si on prend un serveur d’applications au hasard, Tomcat par exemple (oui, le hasard fait bien les choses), cela donnerait un fichier de contexte ressemblant à ceci:

<Context path="/myAppInstance1" debug="0" docBase="/the/full/path/to/myApp.war">
  <Environment name="myAppInstanceConfig" type="java.lang.String" override="false"
               value="file:/the/full/path/to/myApp-instance1-config.properties"/>
</Context>

Conclusions

Même si toutes ces méthodes sont valides, j’avoue ma préférence pour la dernière. Elle présente à mon sens de multiples avantages:

• pas d’impact sur le système
• possibilité de multiplier les instances avec des configurations différentes
• lien fort entre l’instance d’application et le chemin vers son fichier de configuration

Ce qu’il faut retenir de ces propositions, c’est surtout que Config.groovy est avant tout un script. Il est donc très facile d’ajouter sa propre logique de récupération des fichiers de configuration à charger. On pourrait en imaginer d’autres, comme d’aller parser un fichier centralisé sur le système ou de se connecter à une base de données pour récupérer des clés de configuration.

Le système de configuration incrémentale sur lequel est basé Grails et la configuration par scripting, permettent une très grande flexibilité, ou comme dirait les Perlistes: Tim Toady!.

Ressources

• Documentation Grails, section configuration externe
• ConfigSlurper, l’aggrégateur de configuration
• Developing JNDI-based Application, notamment la section Declaring Environment Variables

Actualité éditeurs / SSII

• Amazon Appstore
• Jackson 1.7

Le coin de la technique

• Ecosystème Groovy/Grails
• Version majeure de JRuby : 1.6 en release candidate

Actualité éditeurs / SSII

Amazon Appstore

Amazon a annoncé le lancement du portail Appstore Developper – https://developer.amazon.com/ – qui ouvre la voie au prochain Appstore pour Android (à terme d’autres plateformes seront peut-être aussi supportées). Amazon se lance pour avoir sa part du gâteau dans le marché des applications mobiles. Contrairement à Google, qui laisse la liberté de soumettre n’importe quelle application et de la vendre, Amazon vérifiera si le contenu est approprié et validera selon des standards de qualité minimale. Ce modèle se rapproche de celui d’Apple pour l’AppStore, par exemple le contenu très explicite pour adultes seront interdits.

Ce processus de validation affectera le délai de mise en vente, mais Amazon promet de ne pas dépasser une semaine pour le délai d’approbation des applications. D’après Amazon, l’objectif principal du filtre est d’améliorer la qualité des applications qu’on peut acheter sur le portail en offrant un minimum de garanties aux utilisateurs.

La différence majeure par rapport à ses concurrents, Google et Apple, est le système de prix qui sera similaire à celui des livres et restera sous le contrôle d’Amazon. Les développeurs pourront choisir le prix de départ de l’application dans une liste, mais celui-ci variera dans le temps, pour s’adapter au marché et afin de rentabiliser au maximum ses ventes et bénéfices. L’un des aspects le plus attractif pour le développeur est la façon dont Amazon propose aux utilisateurs des produits auxquels ils pourront être intéressés grâce à leur système de suivi.

Concernant les prix du service, la première année est gratuite pour le développeur et passe ensuite à 99 dollars / an. L’Appstore Amazon ouvrira d’abord aux Etats-Unis, et même si aucune date d’ouverture n’a été annoncée, tous les yeux sont rivés vers cet été 2011.

Jackson 1.7

Quelques mois après la sortie de la version 1.6, cette nouvelle mouture apporte quelques petites évolutions techniques et elle est totalement compatible avec la version précédente. La grande nouveauté vient de l’abstraction des modules qui facilite l’ajout de serializers/deserializers. Pour cela il suffira d’étendre la classe abstraite Module:

public abstract class Module
{
    public abstract String getModuleName();
    public abstract Version version();
    public abstract void setupModule(SetupContext context);
}

Outre la personalisation des serializers/deserializers, le module pourra modifier ou ajouter ses propres annotations ou avoir accès à des configurations de sérialisations. Voici quelques idées de librairies qui pourrait être de bons candidats à une adaptation spécifiques, proposés sur le site de Jackson:

• Joda Time
• Google guava pour sa partie sur les collections surtout
• Hibernate, pour par exemple gérer le lazy loading
• Apache commons
• des types de donnée propre à des langages de la JVM hors Java comme Scala, Groovy ou Clojure

Une page regroupe certains de ces modules. De plus il est possible en ajoutant le jar jackson-xml-databind d’utiliser le format XML pour la sérialisation grâce au nouveau mapper XmlMapper.

Reconnu comme l’outil le plus performant sur le format JSON, Jackson tente d’étendre ses fonctionnalités et d’améliorer sa modularité, et c’est plutôt une bonne nouvelle.

Le coin de la technique

Ecosystème Groovy/Grails

Pour ceux qui suivent l’actualité Grails, beaucoup de mouvements cette semaine. Burt Beckwith, committer sur le projet, en fait une liste exhaustive sur son blog. Plus d’une vingtaine de plugins ont été mis à jour, parmi lesquels :

• Liquibase
• Fixtures
• Webtest
• JQuery
• et d’autres …

Vous trouverez également un tutoriel vidéo pour recoder un Twitter-like en 90 minutes, et un autre pour coder un gestionnaire de contact en 8 minutes, le tout grâce à Grails.

L’outil de build Gradle est sorti en version 0.9.1, vous trouverez sur ce blog une stratégie intéressante pour migrer vos scripts ant en douceur et ainsi apporter plus de flexibilité à votre processus de construction de projet.

Pour plus de détails sur l’activité Grails de la semaine, faites un tour sur le blog de Burt.

Version majeure de JRuby : 1.6 en release candidate

Information de dernière minute : JRuby vient de sortir en version 1.6 RC1 ! Il s’agit là d’une version majeure à plusieurs égards puisqu’elle apporte la compatibilité avec Ruby 1.9.2 ! Le support des extensions Ruby compilées en C est également disponible, mais en mode expérimental. Pour plus de détails, voir les release notes. Plus de 265 problèmes solutionnés depuis la dernière version en 2000 commits sur 9 mois, soit une moyenne de 10 commits par jour ouvré ! Un grand bravo à l’équipe pour ce joli bébé !

Il va maintenant falloir tester tout ça pour permettre de valider la version. La compatibilité avec Ruby 1.9.2 est l’effort de test le plus grandement recherché par le projet. Avis aux amateurs…

Avec un peu de retard sur les autres, voici le cinquième article de cette série sur Grails. Nous allons parler ici de :

• Tests unitaires
• Tests d’intégration
• Mesures de qualité de code
• Intégration continue

En appliquant le tout à notre projet test bien aimé : NoThunes.

Tout code sera testé, sinon par vous, alors par vos utilisateurs …

La nécessité de tester notre code, quel qu’il soit, a été largement décrite, soutenue et argumentée. Par conséquent, nous ne reviendrons pas dessus dans cet article. Je tiens à m’excuser pour avoir placé en dernier lieu l’activité qui devrait ouvrir le bal dans la rédaction d’une application (le TDD c’est bon, mangez-en). Cela m’a paru plus attractif de mettre les mains dans le cambouis de suite. Mais maintenant nous allons passer aux choses sérieuses : les Tests.

Scott Davis, sur le blog d’IBM, a rédigé une série d’articles Mastering Grails dont 2 nous concernent plus particulièrement ici :

• Mock Testing with Grails
• Testing your Grails application

Les tests à la mode Grails sont largement bien décrits dans ces 2 articles. Je vais donc vous fournir ici mon retour d’expérience sur l’application en conditions réelles de ces conseils. Les tests unitaires au sens propre sont très bien décrits dans ces 2 articles, nous allons donc directement sauter aux tests d’intégration.

Tests d’intégration Grails dans la pratique

Durant la phase des tests d’intégration, l’application est chargée entièrement, dans un mode test. C’est l’équivalent du lancement de grails test run-app. Par conséquent nous disposons d’une base de données et de tous nos composants.

D’après Burt Beckwith, membre de la team Grails, il ne faut pas utiliser le framework de mock de Grails pour tester les classes de domaine. Sinon, tout ce qui est testé, c’est le framework de mock en lui-même et il ne supporte pas toutes les fonctionnalités de GORM (comme les closures withCriteria par exemple !). Pour les classes de domaine, il faut donc utiliser uniquement des tests d’intégration. L’exception à cette règle concerne les tests de méthode n’impliquant ni GORM, ni la base de données, comme les tests de validation de contraintes (regarder du côté de mockForConstraintsTests() pour ça).

Cette méthode est un peu radicale et suppose que, dès qu’on fait usage, à un quelconque endroit, de requêtes nommées ou de closures Criteria, on se retrouve obligé de ne coder que des tests d’intégration. Une alternative consiste à utiliser GMock pour combler les manques actuels de Grails.

Jeux de données

Lorsqu’on code des tests d’intégration il est important de connaitre le contenu de la base de données avant chaque test. Il est donc utile de pouvoir se baser sur des jeux de données pour initialiser la base. Parmi les nombreuses solutions qui s’offrent à nous, voici celles qui ont retenu mon attention :

• Utiliser la classe de configuration Bootstrap.groovy : Cela suppose de charger l’intégralité des données utiles pour tous les tests d’intégration, ce qui peut vite devenir encombrant. De plus le code nécessaire à instancier, lier et sauver toutes les instances utiles est assez verbeux.
• Le plugin DbUnit Operator : Permet d’injecter à la demande des jeux de données écrits en XML. Ce plugin est basé sur la librairie du même nom. C’est robuste et souple à la fois. L’inconvénient est que le modèle XML est centré sur le schéma de la base et va nécessiter une maintenance non négligeable.
• Le couple de plugin Fixtures/BuildTestData : Fixtures permet de créer des jeux de données et de les sauvegarder en base rapidement avec une syntaxe concise. C’est la solution qui m’a semblée la plus pratique. L’association avec le plugin BuildTestData autorise à raccourcir encore la définition d’entités. Les champs non remplis manuellement dans une fixture peuvent être remplis automatiquement par BuildTestData.

Après expérimentation, la dernière solution s’est révélée la plus simple et efficace. La documentation du plugin est un peu succincte et ne décrit pas de façon explicite tous les cas d’utilisation. En exclusivité, je vais prendre comme exemple un cas non documenté, sous vos yeux ébahis : l’utilisation conjointe des 2 plugins dans une fixture externe. Commençons par l’installation :

grails install-plugin fixtures
grails install-plugin build-test-data

L’installation du plugin Fixtures entraine l’apparition d’un répertoire fixtures/ à la racine du projet. Tous les fichiers de fixtures déposés dedans seront rendus accessible pour être chargé dans le code de nos tests. Il est possible de mettre directement les fixtures dans notre code (comme décrit dans la documentation) mais j’ai préféré l’option de chargement de fichiers externes pour éviter d’introduire du bruit dans le code. Voici une fixture appliquée à notre modèle :

fixtures/initialDev.groovy

import fr.xebia.nothunes.domain.*
import fr.xebia.nothunes.security.*
def member = User.findByUsername('user')
member.confirmPasswd = member.passwd
build {
  rtnp(Band) {
    name = 'RTNP'
    webSite = 'http://rtnp.org'
    owner = member
  }
  promotionCanape(Album) {
    name = "Promotion Canapé"
    band = rtnp
  }
  zombieNow(Track) {
    name = "Zombie Now"
    album = promotionCanape
  }
}

Décryptons ce fichier. Nous commençons par récupérer une instance de compte utilisateur en base, pour lui attribuer un Band. Cet utilisateur a été inséré dans la base via la classe de configuration Bootstrap, on peut donc compter dessus. La closures build sera interprétée par Fixtures pour créer les objets et les sauver en base. Fixture permet d’utiliser une closure build, qui s’appuie sur le plugin BuildTestsData, qui remplira automatiquement les champs non definis dans la fixture, de façon à ce que l’instance créée respecte ses contraintes d’intégrité.

Il est important de noter que les liens tissés entre les objets de la fixture sont écrits de façon directe. Par exemple la propriété band de notre instance promotionCanape est directement le nom de l’instance décrite juste au dessus. Pas besoin de sauvegarde intermédiaire, ce qui fait gagner pas mal de temps d’écriture.

Maintenant que nous disposons d’un petit jeu de données, pour le charger dans un test, il suffit de faire comme ceci :

package fr.xebia.nothunes.domain
import grails.test.*
import fr.xebia.nothunes.domain.*
import fr.xebia.nothunes.security.*
class TrackIntegTests extends GrailsUnitTestCase {
  // definition de l'attribut fixtureLoader pour injection automatique
  def fixtureLoader
  protected void setUp() {
    super.setUp()
  }
  protected void tearDown() {
    super.tearDown()
  }
  void testLoadFixture() {
    // chargement du fichier fixtures/initialDev.groovy
    def fixture = fixtureLoader.load('initialDev')
    def result = Track.listOrderByName()
    assertEquals 1, result.size()
    assertEquals 'Zombie Now', result[0].name
  }
  void testNotLoadedFixture() {
    def result = Track.listOrderByName()
    assertEquals 0, result.size()
  }
}

Comme on peut le voir, la durée de vie des données en base ne dépasse pas la méthode de test. Ce comportement est plutôt pratique pour éviter que nos tests d’intégration se polluent les uns les autres.

Test fonctionnels

Pour aller encore un peu plus loin dans les tests, il faut monter encore d’un cran et passer aux tests d’IHM. Une référence dans le monde du web en Java : Selenium. C’est le premier nom qui m’est venu et j’ai donc cherché un plugin Grails. Il existe bel et bien mais la documentation initiale m’a fait faire demi-tour. Les tests peuvent être rédigés en trois formats différents, je vous colle des exemple de chacun pour que vous puissiez juger :

• HTML :

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>test1</title>
</head>
<body>
<table cellpadding="1" cellspacing="1" border="1">
<thead>
<tr><td colspan="3">test1</td></tr>
</thead><tbody>
<tr><td>open</td><td>/selenium-test/</td><td></td></tr>
<tr><td>clickAndWait</td><td>link=BookController</td><td></td></tr>
<tr><td>clickAndWait</td><td>link=New Book</td><td></td></tr>
<tr><td>type</td><td>title</td><td>book1</td></tr>
<tr><td>clickAndWait</td> <td>//input[@value='Create']</td> <td></td></tr>
<tr><td>clickAndWait</td> <td>link=Book List</td> <td></td></tr>
<tr><td>verifyTextPresent</td> <td>book1</td> <td></td></tr>
</tbody></table>
</body>
</html>

• Pipe separated values :

open|/selenium-test
clickAndWait|link=BookController
clickAndWait|link=New Book
type|title|book2
clickAndWait|//input[@value='Create']
clickAndWait|link=Book List
verifyTextPresent|book2

• Groovy Server Pages :

<g:set var="bookTitle" value="book0d"/>
<sel:test name="MyTest">
<sel:row command="open" target="${request.contextPath}"/>
<sel:row line="clickAndWait|link=BookController"/>
<sel:row line="clickAndWait|link=New Book"/>
<sel:row command="type" target="title" value="${bookTitle}"/>
<sel:row line="clickAndWait|//input[@value='Create']"/>
<sel:row line="clickAndWait|link=Book List"/>
<sel:row line="verifyTextPresent|${bookTitle}"/>
</sel:test>

Si l’une de ces syntaxes vous emballe, faites en bon usage. Personnellement j’ai été refroidi par l’aspect très compact et plutôt dur à relire. J’ai donc continué mes investigations, et suis finalement tombé sur le plugin WebTest, basé sur la librairie de Canoo. Une librairie beaucoup plus orienté Groovy que ne l’est le plugin Selenium. De plus WebTest fourni également de jolis rapports HTML plein de couleurs attrayantes, faciles à interpréter. Voici un exemple de ce que peut donner le code d’un test simpliste avec cette librairie :

package nothunes
import nothunes.common.WebTestsNoThunes
class BandWebTests extends WebTestsNoThunes {
  def fixtureLoader
  void testLogin() {
    invoke(url:'login')
    verifyText(text:'Please Login..')
    def fixture = fixtureLoader.load('initialDev')
    invoke(url:'/navigation')
    verifyText(text:'RTNP')
  }
}

Les actions sont basiques, l’API est nativement en Groovy, et pour ceux qui ont déjà utilisé Selenium sur des projets Java, ce n’est vraiment pas dépaysant. La facilité de prise en main et les rapports parlants en font ma préférence pour l’automatisation de tests d’IHM web.

Analyse statique du code

Outre la pose d’un filet de sécurité autour des fonctionnalités de l’application, il est également intéressant d’affiner la qualité du code source produit. L’analyse statique de code est une méthode rodée chez les développeurs Java pour permettre de trouver des duplications de code, des bugs éventuels, évaluer la complexité, etc. Du coté du langage Groovy, l’outillage est un peu moins riche mais on trouve quand même quelques petites choses intéressantes.

CodeNarc

Tout d’abord : CodeNarc. Ce programme permet de valider du code Groovy en regard de règles de programmation établie. Un jeu de règle est proposé par défaut mais il est possible de définir ses propres règles. Un packaging sous forme de plugin Grails existe également, pour permettre une installation et une utilisation simplifiées :

grails install-plugin codenarc
grails codenarc

Cela va lancer l’analyse et générer un rapport détaillé de toutes les violations de règles, au format HTML :

Extrait de CodeNarcReport.html

La présentation est spartiate, mais ça tourne ! Le rapport commence par une vision macro avec la consolidation des erreurs par package, puis viens la liste détaillée de chacun des packages concernés, et enfin la description de chaque type de violation rencontré.
On peut également écrire soit même des règles de programmation à respecter. Il est donc aisé de se baser sur cet outil pour faire respecter les normes de votre choix. Pour ceux d’entre vous qui l’utilise déjà, sachez que la dernière version (la 0.11) est sortie le 13 novembre avec notamment 50 règles supplémentaires.

GMetrics

GMetrics, quant à lui, est centré sur le calcul et la présentation de métriques. Le projet assure le calcul :

• de complexité cyclomatique
• du nombre de lignes par méthode
• du nombre de lignes par classe

Selon le même principe que CodeNarc, l’installation de cette librairie se fait comme un plugin au projet : il se lance simplement et génère un rapport HTML :

grails install-plugin gmetrics
grails gmetrics

Extrait d’un rapport GMetrics

GMetrics est encore assez léger dans les métriques collectées, mais il offre une excellente base de développement pour collecter ses propres métriques. Si par hasard vous en écrivez pour un projet, n’hésitez pas à en faire profiter la communauté.

Conclusions

Il y aurait de quoi écrire un livre entier sur le seul sujet des tests dans le cadre de Grails. Comme d’habitude, les affinités entre le langage Groovy et le Java font que beaucoup d’outils Java sont déjà pluginizé ou ne coûterai pas cher à l’être. Longtemps cantonné aux scripting Java, le langage Groovy trouve ses lettre de noblesse avec Grails. Il est agréable de voir se développer pour le langage Groovy des outils de qualité qui apportent tant au langage Java. En quelques recherches, un projet peut se doter de tout ce qu’il faut pour développer des tests unitaires, d’intégration, fonctionnels mais aussi tests d’acceptance (avec Fitnesse ou EasyB), ou même des tests de vos fonctions Javascript avec JsUnit.

Dans le framework Grails, les tests sont disponibles pour tous les goûts, toutes les tailles. Le véritable défi consiste à séparer le bon grain de l’ivraie au milieu du foisonnement de plugins disponibles (sans compter qu’il est toujours possible d’intégrer soit même des librairies Java). J’espère vous avoir apporté, sinon La réponse, au moins l’éclairage de mon expérience personnelle sur le sujet. Maintenant il ne reste plus qu’à trouver votre propre style de tests Grails.

Ressources :

• Tests unitaires sur le site Grails
• Section Testing de la documentation officielle
• Mock Testing with Grails
• Testing your Grails application
• NoThunes sur GitHub

• En tant qu’internaute, je dois pouvoir écouter un morceau
• En tant qu’internaute, je dois pouvoir rechercher des morceaux par mots-clés

Pour cela, nous passerons par l’utilisation de 2 plugins très pratiques :

• Sound Manager, qui offre des tags GSP pour ajouter facilement des fonctions de media player dans les vues
• Searchable, qui apporte des fonctionnalités de recherche basées sur Compass (et donc indirectement sur le moteur Lucene)

Suivez le guide …

En tant qu’internaute, je dois pouvoir écouter un morceau

Pour rappel, dans les épisodes précédents, nous avons offerts :

• aux utilisateurs membres : la possibilité d’uploader des morceaux de musique.
• aux internautes : la possibilité de naviguer dans les morceaux disponibles en filtrant par Band et Album, et de les télécharger.

Aujourd’hui nous allons leur permettre d’écouter les morceaux avant de les télécharger. Précisons tout d’abord cette User Story un peu vague. Il s’agit ici de fournir une fonctionnalité très minimaliste, permettant de jouer un morceaux directement dans l’interface de navigation, pour « goûter » avant de télécharger.

Le périmètre de notre besoin est très restreint et il se trouve qu’un plugin Grails le comble parfaitement : sound-manager. Ce plugin permet de transformer n’importe quel lien pointant vers un fichier mp3 dans la page en un mini lecteur audio flash.

Commençons donc par installer le plugin :

grails install-plugin sound-manager

Si vous avez une bonne mémoire, vous vous rappelez de notre GSP grails-app/views/navigation/_trackList.gsp qui sert à afficher la liste des Tracks recherchés. Il nous suffit d’ajouter en tête de ce fichier :

<head>
  <sm:inlinePlayer/>
</head>

Ce tag va, à chaque chargement de la page, rechercher les liens pointant vers des fichiers mp3 et les « entourer » avec un peu de sound-manager pour obtenir un mini flash-player dédié au lien.

Comme nous avons mis une image dans le lien vers le mp3, il reste possible de télécharger le morceaux en cliquant sur l’icône plutôt que sur le bouton Play.

And voilà ! 100% de notre petit besoin est rempli, et l’opération a dû prendre 20 minutes en comptant :

• la recherche du plugin sur le portail Grails.
• la lecture de la documentation.
• l’installation.
• la mise en œuvre.

C’est presque allé trop vite pour en goûter toute la saveur.

Pour ceux qui veulent aller plus loin, sachez que ce plugin est basé sur la librairie du même nom, et qu’il est donc également possible d’utiliser l’intégralité de l’API, qui est très complète, pour obtenir un lecteur plus riche, éventuellement en HTML5.

En tant qu’internaute, je dois pouvoir rechercher des morceaux par mots-clés

Passons maintenant au moteur de recherche de notre navigation. Le but est ici d’ajouter un formulaire de recherche sur la page de navigation et de lancer la recherche sur les noms des Bands, Albums et Tracks existant en base. Là il y a un peu plus à faire. Tout d’abord, installons le plugin Searchable :

grails install-plugin searchable

Ce plugin est basé sur Compass, qui est lui même basé sur Apache Lucene, le moteur de recherche full-text Java Open Source le plus utilisé (notamment par Twitter depuis peu). Le première étape est de déterminer sur quelles données nous souhaitons baser nos recherches. Dans notre cas, nous avons choisi les champs name des classes de domaines Band, Album et Track.

Pour renseigner l’index du moteur Lucene, il suffit de rajouter cette ligne dans nos classes :

static searchable = [only: ['name']]

Si vous souhaitez faire des mappings plus complexes, il existe de nombreuses possibilités : regardez du coté de la section Mappings de la documentation.

Notre index est maintenant renseigné. Il nous faut une nouvelle méthode de contrôleur pour l’interroger. Pour plus de simplicité, nous la plaçons dans le NavigationController. Fait notable : la recherche par l’index Lucene remonte des entités incomplètes. Seuls les champs indexés sont renseignés. Par conséquent, pour l’affichage final, il faut interroger la base pour avoir tous les champs. Il faut également penser à modifier la chaîne de recherche pour la rendre compréhensible par Lucene. Nous utilisons ici une technique très basique, mais les query Lucene peuvent être autrement plus puissantes. Pour plus de détails, voir la documentation du moteur.

grails-app/controllers/fr/xebia/nothunes/domain/NavigationController.groovy

  /**
    * Methode d'instrumentation pour transformer la chaine de recherche du formulaire en query Lucene-compliant
    * @param query Chaine de recherche
    */
   def instrument(String query) {
      return query+"*"
   }
   /**
    * Methode de recherche full-text
    */
   def search = {
      String searchQuery = instrument(params.searchQuery)
      log.debug "search query is ${searchQuery}"
      def result = searchableService.search(searchQuery)
      // Les *.searchEvery remontent des entités incomplètes, il faudra les récupérer en base pour avoir tous les champs
      def albumResult = Album.searchEvery(searchQuery)
      def bandResult = Band.searchEvery(searchQuery)
      def trackResult = Track.searchEvery(searchQuery)
      def trackList = [] as Set
      def bandList = [] as Set
      def albumList = [] as Set
      // filtrage des tracks pour n'afficher que ceux qui ont un fichier audio
      trackResult.each {
         def fullTrack = Track.get(it.id)
         if (fullTrack.audioPath) {
            trackList.add(fullTrack)
            albumList.add(fullTrack.album)
            bandList.add(fullTrack.album.band)
         }
      }
      // filtrage des albums pour afficher uniquement ceux qui ont au moins un track avec un fichier audio
      albumResult.each {
         def hasOneCompleteTrack = false
         def fullAlbum = Album.get(it.id)
         fullAlbum.tracks.each { aTrack ->
            if (aTrack.audioPath) {
               trackList.add(aTrack)
               hasOneCompleteTrack = true
            }
         }
         if (hasOneCompleteTrack)  {
            albumList.add(fullAlbum)
            bandList.add(fullAlbum.band)
         }
      }
      bandResult.each {
         def fullBand = Band.get(it.id)
         fullBand.albums.each {anAlbum ->
            def hasOneCompleteTrack = false
            anAlbum.tracks.each { aTrack ->
               if (aTrack.audioPath) {
                  trackList.add(aTrack)
                  hasOneCompleteTrack = true
               }
            }
            if (hasOneCompleteTrack)  {
               bandList.add(fullBand)
               albumList.add(anAlbum)
            }
         }
      }
      // Rendu de la vue
      render (view:'list', model: [bandList: bandList, albumList: albumList, trackList: trackList, searchQuery: params.searchQuery])
   }

Dernière chose à ajouter : le formulaire de recherche dans la vue :

grails-app/views/navigation/list.gsp

<g:form action="search">
   <input type="text" id="searchQuery" name="searchQuery" value="${searchQuery}"/>
   <g:actionSubmit  value="Search" />
</g:form>

La chaine est maintenant complète et nous pouvons lancer des requêtes pour interroger notre base.

Conclusion

L’ajout de ces deux fonctionnalités a été assez rapide. Si l’on possède les bons points d’entrée et que l’on prend la peine de fouiller le repository de plugins de Grails, il y a de fortes chances de trouver son bonheur rapidement. Il va de soit que les exemples donnés ici sont des usages basique. Les librairies tirées par les plugins sont plus complètes et permettent d’aller beaucoup plus loin.

Je me permet ici personnel, mais l’utilisation de Grails me remplit de joie . C’est rapide, c’est concis, et si j’en veux plus, je peux. Le chemin vers le code qui fonctionne est bien tracé par les documentations.

Dans le prochain épisode, nous verrons comment tester notre code et contrôler sa qualité.

Ressources

• NoThunes version 0.4 sur GitHub
• Grails SoundManager Plugin
• Grails Searchable Plugin
• Compass SearchEngine Framework

Retour sur notre plateforme de musique en ligne préférée. Comme promis, dans ce chapitre, nous allons ajouter une pincée de 2.0 à notre application. Nous allons donc nous pencher sur la mise en oeuvre d’AJAX à la mode de Grails.

• Listes déroulantes dynamiques avec JSON
• Mise à jour de fragments de page avec modèles GSP

Vous allez pouvoir découvrir l’intégration d’AJAX dans Grails, et à quel point la vie du développeur est facilitée. Les exemples d’utilisation sont simples mais déclinables à l’infini.

Sprint Backlog détaillé

Gestion des Tracks

Nous sautons tout ce qui concerne la mise en place du CRUD et de la gestion de l’upload de fichier mp3. La méthode employée est foncièrement identique au travail déjà fait pour les classes Band et Album. Comme d’habitude le détail est dans le GitHub.

Attardons nous, par contre, sur un point particulier du formulaire de création de Track : l’attribution à un Album. Chaque Track appartient à un Album (par un lien belongsTo). Pour une meilleure ergonomie, nous avons choisi de proposer à l’utilisateur de sélectionner d’abord un Band dans un <select ../> et, dynamiquement, nous proposons les Albums de ce groupe dans un second <select ../>. Enfin un peu d’AJAX dans notre projet !

Pour ceux qui n’ont pas fait de veille techologique depuis plusieurs années, voici un petit rappel sur AJAX.

Nous commençons par outiller nos pages avec ce qu’il faut de Javascript :

grails-app/views/layouts/main.gsp

<html>
    <head>
...
      <g:javascript library="application" />
      <g:javascript library="prototype" />
    </head>
...

Ces tags ajoutent dans toutes les pages l’import de la librairie Prototype, fournie par défaut avec Grails, et du fichier web-app/js/application.js. Ce dernier est destiné à recevoir le code Javascript spécifique à notre appli. Ensuite nous créons une méthode dans notre BandController pour renvoyer, au format JSON, la liste des albums appartenant au groupe dont l’id est passé en paramètre :

grails-app/controllers/fr/xebia/nothunes/domain/BandController

...
// Pensez bien à faire cet import
import grails.converters.*
...
def ajaxGetAlbums = {
   render Band.get(params.id).albums as JSON
}

Comme on peut le voir le package grails.converters nous offre une méthode plus que simple pour la conversion d’objets en JSON. A noter que, dans la même famille il est possible d’utiliser as XML.

Maintenant il faut que nous lancions un appel AJAX vers cette méthode, lors de la sélection d’un groupe. Grails a prévu pour nous la méthode remoteFunction qui va générer le Javascript nécessaire.

grails-app/views/tracks/create.gsp

...
<tr class="prop">
  <td valign="top" class="name">
    <label for="band.id">
      <g:message code="track.album.band.label" default="Band" />
    </label>
  </td>
  <td valign="top" class="value">
    <g:select name="band"
              from="${bandList}"
              value="${band?.id}"
              noSelection="['':'---Choose a band---']"
              optionValue="name"
              optionKey="id"
              onchange="${remoteFunction(
                  controller:'band',
                  action:'ajaxGetAlbums',
                  params:''id=' + escape(this.value)',
                  onComplete:'updateSelectAlbumWithJSON(e,'albums')')}"
    />
  </td>
</tr>
...

Les paramètres de remoteFunction sont assez explicites :

• controller, action : le contrôleur et l’action ciblée
• params : les paramètres de la requête
• onComplete : la méthode javascript callback de l’appel AJAX

Il ne reste plus qu’à rédiger la méthode Javascript pour mettre à jour le select des Albums :

web-app/js/application.js

function updateSelectAlbumWithJSON(e, albumListId) {
   var rselect = $(albumListId)
   // Vidage du select
   var l = rselect.length
   while (l > 0) {
      l--
      rselect.remove(l)
   }
   // Evaluation du JSON retourné par le serveur
   var albums = eval("(" + e.responseText + ")")
   if (albums) {
   // Remplissage du select avec les nouvelles options
      addOption(rselect, '---Choose an album---', '')
      for (var i=0; i < albums.length; i++) {
         addOption (rselect, albums[i].name, albums[i].id)
      }
   }
}
function addOption(selectId, text, value) {
   var opt = new Element('option');
   opt.text = text
   opt.value = value
   try {
      selectId.add(opt,null) // Standard, ne fonctionne pas avec IE
   }
   catch(ex) {
      selectId.add(opt) // seulement pour IE
   }
}

En mode développement, c’est certainement superflu, mais au cas où le listing des albums deviendrait un peu long, il est possible d’ajouter un gif d’attente. Cette image est gracieusement fournie par Grails. Ça n’a l’air de rien, d’ailleurs ce n’est rien, mais ça fait plaisir quand même !
Juste à coté du tag <g:select/> des Albums on peut ajouter un petit :

grails-app/views/tracks/create.gsp

<div id="waitingGif"><img src="${resource(dir:'images',file:'spinner.gif')}" alt="${message(code:'spinner.alt',default:'Loading...')}" /></div>

Et dans le javascript, ajouter du $('waitingGif').show() et $('waitingGif').hide(). Ca fait toujours plus joli après tout.

Ça y est, pas besoin de plus ! Pour la page d’édition d’une instance existante, la méthode est pratiquement la même. il faut juste ajouter dans le trackcontroller le chargement de la liste des albums pour que les 2 select soient remplis au chargement. les gentils membres ont maintenant toutes les fonctionnalités pour alimenter notre plateforme de musique en contenu dûment étiquetté.

Navigation pour les internautes

Il faut maintenant penser aux internautes moyens, avides de pouvoir accéder au contenu des membres. Nous allons donc attaquer la navigation publique. Pour éviter de surcharger les contrôleurs existant, nous créons un NavigationController, qui sera dédié à la page de navigation destinée aux internautes lambdas, ainsi qu’une page GSP associée à l’action list (donc dans le fichier grails-app/views/navigation/list.gsp).

La sélection d’un Band doit déclencher le filtrage de la liste des Albums et des Tracks, et la sélection d’un Album doit déclencher le filtrage de la liste des Tracks uniquement. Le filtrage des Albums est identique au cas précédent, puisque c’est un select. Le tableau des Tracks, un peu plus riche, mérite qu’on s’y attarde un peu.

Le principe est globalement le même, à ceci près qu’on va utiliser un modèle GSP pour créer le fragment HTML qui servira à remplacer dynamiquement la liste des Tracks. Zoomons un peu sur la mécanique de notre page list.gsp :

<html>
   <head>
      <!-- ... -->
      <g:javascript>
         // Fonction de filtrage du select des Albums et de la liste des Track, à partir d'un id de Band
         function filterByBand() {
            var bandId = $F('bandSelect');
            <g:remoteFunction action="ajaxFilterTrackByBand" params="'id=' + bandId" onComplete="updateTrackList(e)"/>
            <g:remoteFunction action="ajaxFilterAlbumByBand" params="'id=' + bandId" onComplete="updateAlbums(e)"/>
         }
         // Fonction de filtrage de la liste des Track, à partir d'un id d'Album
         function filterByAlbum() {
            var albumId = $F('albumSelect');
            <g:remoteFunction action="ajaxFilterTrackByAlbum" params="'id=' + albumId" onComplete="updateTrackList(e)"/>
         }
         // Fonction de mise à jour de la liste des Track avec la réponse (au format HTML) de la requête AJAX.
         function updateTrackList(e) {
            $('navTrack').innerHTML = e.responseText;
         }
         // Fonction de mise à jour du select des Albums avec la réponse (au format JSON) de la requête AJAX.
         function updateAlbums(e) {
            // Le code est identique à l'exemple donné pour la
            // mise à jour de select du paragraphe précédent
         }
      </g:javascript>
   </head>
   <body>
      <div class="body">
         <h1>Navigation</h1>
         <div class="navigation">
            <!-- ... -->
            <!-- Selection de Band, le onchange déclenche le javascript de filtrage -->
            <g:select id="bandSelect" name="band" class="navigationSelect"
                  from="${bandList}"
                  noSelection="['':'All']" optionValue="name"
                  optionKey="id" size="30" onchange="filterByBand()"/>
            <!-- ... -->
            <!-- Selection d'Album, le onchange déclenche le javascript de filtrage -->
            <g:select id="albumSelect" name="album" class="navigationSelect"
                  from="${albumList}"
                  noSelection="['':'All']" optionValue="name"
                  optionKey="id" size="30" onchange="filterByAlbum()"/>
            <!-- ... -->
            <!-- Selection de Track, encapsulé dans une div pour pouvoir mettre a jour facilement son contenu -->
            <div id="navTrack" class="list">
               <!-- on charge le fragment contenant la liste des Track, pour qu'elle apparaissent dès le premier chargement -->
               <g:render template="/navigation/trackList"/>
            </div>
         </div>
      </div>
   </body>
</html>

Dans le tag <g:render .../> en fin de l’exemple, on voit qu’on fait appel au modèle GSP qui contient la liste formatée des Tracks. Passons à sa rédaction. Il faut penser à nommer le fragment qui servira de modèle en commençant par un caractère ‘_’, c’est la convention. Notez que dans la colonne Download on réutilise le DlController créé à l’épisode 2.

grails-app/views/navigation/_trackList.gsp

<table>
   <thead class="fixedHeader">
      <tr>
         <th>${message(code: 'track.name.label', default: 'Name')}  </th>
         <th>${message(code: 'band.name.label', default: 'Band')}   </th>
         <th>${message(code: 'album.name.label', default: 'Album')} </th>
         <th style="width: 50px; text-align: center;">Download      </th>
      </tr>
   </thead>
   <tbody class="navigationTable">
      <g:each in="${trackList}" status="i" var="trackInstance">
         <tr class="${(i % 2) == 0 ? 'odd' : 'even'}">
            <td>
            ${fieldValue(bean: trackInstance, field: "name")}
            </td>
            <td><g:link url="${trackInstance.album.band.webSite}">
               ${fieldValue(bean: trackInstance, field: "album.band.name")}
            </g:link></td>
            <td>
            ${fieldValue(bean: trackInstance, field: "album.name")}
            </td>
            <td style="width: 50px; text-align: center;"><a
               href="${createLink(controller:'dl', action:'audio', params: [id: trackInstance.audioPath])}">
            <img src="${resource(dir:'images',file:'filesave.png')}"
               border="0" /> </a></td>
         </tr>
      </g:each>
   </tbody>
</table>

Enfin, dans notre méthode du contrôleur on pourra faire usage de render comme ceci :

grails-app/controllers/fr/xebia/nothunes/domain/NavigationController.groovy

...
   def ajaxFilterTrackByAlbum = {
      def trackList = Track.withCriteria {
         ne('audioPath', 'empty')
         if (params.id) {
            album {
               eq('id', new Long(params.id))
               if (params.band) {
                  band {
                     eq('id', new Long(params.band))
                  }
               }
            }
         }
      }
      render (view:'_trackList', model: [trackList: trackList])
   }
...

Ça y est nos internautes peuvent naviguer dans les morceaux uploadés par nos gentils membres, et les télécharger à leur guise.

Sprint Review

Nous avons pu voir dans cet épisode que la mise en place de méthodes AJAX est relativement intuitive et rapide. Les 2 cas décrits ici sont déclinables à l’infini pour répondre à beaucoup de besoins. L’API Grails est correctement documentée, et la librairie Prototype embarquée par défaut offre des outils plus que suffisant pour manipuler le DOM de la page. Pour ceux qui préférent, il existe les plugins JQuery et JQuery-UI pour installer en une commande tous les fichiers au bon endroit.

Le programme du prochain épisode :

Stay (no)tuned …

Ressources

• Tag v0.3 du projet NoThunes sur GitHub
• Grails : AJAX
• Grails : AJAX driven select

Continuons le montage de notre projet OpenSource propulsé par Grails. Au dernier épisode, nous avions démarré le projet, façonné les styles CSS, mis en place la sécurité, mais aussi et surtout, rédigé les classes du modèle de données. Aujourd’hui nous allons leur donner vie en ajoutant des fonctionnalités aux utilisateurs membres.

Nous nous attarderons sur :

• la gestion du profil utilisateur
• la génération des écrans CRUD de nos données
• leur adaptation à nos ‘règles métier’
• la gestion des upload et download

Ces étapes peuvent paraître triviales à ceux qui ont déjà une expérience de Grails. Cependant, j’ai choisi de les traiter malgré tout. J’ai moi-même perdu trop de temps à chercher des exemples concrets et simples sur la toile pour oser faire l’impasse dessus. Donc, toi qui débute sur Grails, sois le bienvenu.

Sprint backlog détaillé

Gestion du profil utilisateur

Confirmation des modifications de mot de passe

Lorsque nos membres pourront mettre à jour leur profil, ils pourront également modifier leur mot de passe. Pour commencer, il faut donc que nous fassions des adaptations pour ajouter la confirmation du mot de passe dans la gestion des comptes utilisateurs. En deux coups de cuillère à pot, cela donne :

• Ajout d’un champ confirmPasswd dans la classe de domaine User, et d’un validateur associé :

grails-app/domain/fr/xebia/nothunes/security/User.groovy

class User {
   ...
   static transients = ['confirmPasswd']
   ...
   String confirmPasswd
   static constraints = {
      ...
      confirmPasswd(validator :{val, obj ->
         if (obj.properties['passwd'] != val) {
            return 'default.invalid.confirmPasswd.message'
         }
      })
   }
}

Le champ nouvellement créé est passé en transient pour éviter que sa valeur ne soit persistée en base. Notez que la valeur retournée par le validateur est un String correspondant au message d’erreur à afficher. Par conséquent, il faut ajouter ce message dans les fichiers messages.properties pour avoir l’affichage de l’erreur dans les GSP :

grails-app/i18n/messages.properties

default.invalid.confirmPasswd.message=Bad password confirmation

• Modification du UserController :

Pour que le champ confirmPasswd soit correctement renseigné avant la validation, il faut aller modifier la classe UserController. Dans les méthodes save() et update(), le champ passwd est chiffré avant sauvegarde en base. Il faut appliquer le même traitement au champ confirmPasswd. De cette façon le validateur fait la comparaison entre les deux champs chiffrés. Si les versions chiffrées sont identiques alors la confirmation du mot de passe est valide, CQFD.

grails-app/controllers/UserController.groovy

...
// à chaque occurence du chiffrage du champ 'passwd' ...
person.passwd = authenticateService.encodePassword(params.passwd)
// on ajoute le chiffrage du champ 'confirmPasswd'
person.confirmPasswd = authenticateService.encodePassword(params.confirmPasswd)
...

• Modification des formulaires de création et d’édition d’un User :

Pour l’instant les formulaires de création et d’édition des User ne contiennent pas de champ pour confirmPasswd donc le validateur renvoie toujours une erreur. Il suffit d’ajouter un champ texte, initialisé avec la valeur du mot de passe.

grails-app/views/user/create.gsp ET grails-app/views/user/edit.gsp

...
<tr class="prop">
   <td valign="top" class="name"><label for="passwd">Password:</label></td>
   <td valign="top" class="value ${hasErrors(bean:person,field:'passwd','errors')}">
      <input type="password" id="passwd" name="passwd" value="${person.passwd?.encodeAsHTML()}"/>
   </td>
</tr>
<!-- on ajoute notre champ -->
<tr class="prop">
   <td valign="top" class="name"><label for="confirmPasswd">Confirm password:</label></td>
   <td valign="top" class="value ${hasErrors(bean:person,field:'confirmPasswd','errors')}">
      <input type="password" id="confirmPasswd" name="confirmPasswd" value="${person.passwd?.encodeAsHTML()}"/>
   </td>
</tr>
...

Création d’un contrôleur dédié à l’affichage et la mise à jour du profil

Maintenant que nous disposons d’une validation correcte pour la mise à jour des mots de passe, nous pouvons attaquer le cœur du sujet. Pour cela, on crée un nouveau contrôleur grâce à la commande :

grails create-controller fr.xebia.nothunes.profile.Profile

Cela génère une coquille vide nommée ProfileController. Le but de ce contrôleur est de permettre d’afficher le profil de l’utilisateur courant et de le mettre à jour. Par conséquent il faut créer les méthodes :

• index : qu’on redirigera vers show. Dans le cas où le contrôleur est appelé sans méthode particulière, c’est index() qui sera lancé.
• show : pour récupérer le compte de l’utilisateur courant en base et l’afficher.
• edit : pour récupérer le compte de l’utilisateur courant en base et afficher le formulaire d’édition.
• update : pour persister en base un envoi de formulaire d’édition. Si la sauvegarde se passe bien, à la fin on redirige vers show() avec un message de succès ; sinon on redirige vers edit() avec un message d’erreur.

Conjointement, il nous faut 2 vues :

• profile/show.gsp : pour afficher le profil. Elle contient un bouton pour passer en édition.
• profile/edit.gsp : pour éditer le profil. Elle contient un formulaire qui pointe sur la méthode update du contrôleur.

Afin de ne pas trop alourdir ce billet, je vous renvoie au GitHub pour le détail des vues et du contrôleur. Le code est très fortement inspiré de ce qui existe déjà dans le UserController et ses vues.

• grails-app/controllers/fr/xebia/nothunes/profile/ProfileController.groovy
• grails-app/views/profile/show.gsp
• grails-app/views/profile/edit.gsp

Pour être sûr que l’utilisateur est authentifié quand il accède au contrôleur, on ajoute dans les règles de sécurité la protection de /profile/* directement dans le bootstrap de l’application :

grails-app/conf/BootStrap.groovy

class BootStrap {
   def init = { servletContext ->
      ...
      def protectUserProfileManaging = new RequestMap(url: '/profile/*', configAttribute: 'ROLE_ADMIN,ROLE_USER').save()
   }
   ...
}

Une fois tout ceci fait, il suffit de rajouter le lien vers l’affichage du profil dans la GSP qui contient le menu pour les membres :

grails-app/views/menu/_user.gsp

...
   <h1>Member manages ...</h1>
   <ul>
      <li><g:link controller="profile">your profile</g:link></li>
   </ul>
...

On redémarre notre application et le tour est joué !

Gestion des CRUD métiers : les classes Band et Album

Attaquons maintenant la gestion des CRUD de nos objets métiers. Premier de la liste : Band. Pour rappel, cette classe représente un groupe de musique géré par un utilisateur membre. Un membre doit pouvoir créer des groupes et modifier uniquement ceux qu’il a créé. Pour avoir un petit rappel sur le contenu de la classe Band, voir sur le GitHub. Grails nous offre un démarrage rapide en générant les vues et le contrôleur à partir de la classe de domaine avec la commande :

grails generate-all fr.xebia.nothunes.domain.Band

Le contrôleur et les vues générés sont génériques et doivent être adaptés pour nos besoins particuliers. Ces fonctionnalités doivent être réservées aux membres, donc on ajoute dans le bootstrap les règles de sécurité pour protéger le contrôleur :

grails-app/conf/BootStrap.groovy

class BootStrap {
   def init = { servletContext ->
      ...
      def protectUserProfileManaging = new RequestMap(url: '/band/*', configAttribute: 'ROLE_ADMIN,ROLE_USER').save()
   }
   ...
}

Ensuite il faut rajouter des contrôles métier pour permettre aux membres de ne lister, visualiser et modifier que les Band qu’ils ont créés. Pour cela, on va s’appuyer sur l’appartenance de la classe Band à un User (lien belongsTo). Pour commencer, la méthode list ne doit afficher que les groupes dont l’utilisateur est propriétaire :

grails-app/controllers/fr/xebia/nothunes/domain/BandController.groovy

...
def list = {
   params.max = Math.min(params.max ? params.int('max') : 10, 100)
   def owner = User.get(authenticateService.userDomain().id)
   [bandInstanceList: Band.findAllByOwner(owner, params), bandInstanceTotal: Band.count()]
}
...

Ensuite, lors d’une sauvegarde, on doit définir le propriétaire du Band avant la sauvegarde

grails-app/controllers/fr/xebia/nothunes/domain/BandController.groovy

...
def save = {
   def bandInstance = new Band(params)
   // on définit le propriétaire du Band
   bandInstance.owner = User.get(authenticateService.userDomain().id)
   ...
}
...

Enfin, à l’entrée des méthodes show, edit et update du BandController on teste la légitimité de l’utilisateur courant à agir sur le Band demandé de la façon suivante :

grails-app/controllers/fr/xebia/nothunes/domain/BandController.groovy

...
def show = {
   def bandInstance = Band.get(params.id)
   // on recupere le user courant
   def currentUser = User.get(authenticateService.userDomain().id)
   // s'il existe et qu'il est propriétaire du Band demandé, on autorise la suite
   if (bandInstance && currentUser && bandInstance.owner == currentUser) {
      [bandInstance: bandInstance]
   } else {
   // sinon on affiche un message et on le renvoie sur la liste de ses propres groupes
      flash.message = "${message(code: 'default.not.found.message', args: [message(code: 'band.label', default: 'Band'), params.id])}"
      redirect(action: "list")
   }
}
...

Et, touche finale, on ajoute le lien vers la gestion des Band dans le menu utilisateur :

grails-app/views/menu/_user.gsp

...
   <h1>Member manages ...</h1>
   <ul>
      <li><g:link controller="profile">your profile</g:link></li>
      <li><g:link controller="band">your bands</g:link></li>
   </ul>
...

La technique est la même pour les Albums :

• génération des vues et du contrôleur
• protection par les règles de sécurité
• ajout de contrôles métier pour filtrer les actions utilisateurs

Pour le détail du code tournant autour des Albums, faites un tour par le GitHub.

Upload d’une image logo pour les Band

Pour rendre notre gestion de Band un peu plus sexy, on y ajoute l’upload d’une image qui servira de logo. Rien de plus facile. Nous commençons par ajouter dans la configuration de l’application un chemin vers un répertoire de stockage :

grails-app/conf/Config.groovy

...
storage.image.directory='/tmp/nothunes_images/'
...

Pour pouvoir réutiliser la méthode d’upload de fichier, on crée un service grails dédié :

grails create-service fr.xebia.nothunes.upload.Upload

Puis on crée une méthode saveImage, qui s’occupe de vérifier le type mime du fichier soumis, et de le stocker dans le répertoire défini dans la Config de l’application.

class UploadService {
   def authorizedImageContentType = [ 'image/jpeg' :'jpg', 'image/gif' :'gif', 'image/png' :'png']
   def grailsApplication
   def saveImageFile(anImageFile, name) {
      if (!anImageFile.empty) {
         FileNameMap fileNameMap = URLConnection.getFileNameMap();
         def contentType = fileNameMap.getContentTypeFor(anImageFile.originalFilename)
         if ( authorizedImageContentType.keySet().contains(contentType) ) {
            File storageDir = new File(grailsApplication.config.storage.image.directory)
            if (!storageDir.exists()) {
               if (!storageDir.mkdir()) {
                  log.error 'Directory does not exist and cannot be created '+grailsApplication.config.storage.image.directory
                  return false
               }
            }
            // Pour un minimum de standardisation, on génère le nom du fichier à enregistré à partir du paramètre
            // 'name' et du type mime
            def targetFilename = name + '_logo.' + authorizedImageContentType[contentType]
            // sauvegarde du fichier
            anImageFile.transferTo( new File(grailsApplication.config.storage.image.directory + targetFilename) )
            return targetFilename
         } else {
            log.debug 'Someone tried to upload a non-image file : '+contentType
            return false
         }
      } else {
         return false
      }
   }
}

Ensuite on modifie nos GSP de création et d’édition pour ajouter un champ de type file et faire des formulaires multipart :

grails-app/views/band/create.gsp ET grails-app/views/band/edit.gsp

<!-- Ici on rajoute le enctype -->
<g:form action="save" method="post" enctype="multipart/form-data">
...
   <tr class="prop">
      <td valign="top" class="name">
         <label for="logoPath"><g:message code="band.logoPath.label" default="Logo Path" /></label>
      </td>
      <td valign="top" class="value ${hasErrors(bean: bandInstance, field: 'logoPath', 'errors')}">
         <!-- et là un input file -->
         <input type="file" name="logoFile"/>
      </td>
   </tr>
...
</g:form>

A la soumission du formulaire, on peut désormais récupérer le fichier et le passer à notre service de sauvegarde en appelant :

uploadService.saveImageFile(request.getFile('logoFile'), bandInstance.name)

Le paramètre passé à la méthode request.getFile() correspond à l’attribut name du champ input de notre formulaire. Encore une fois pour le code complet, voir le GitHub. Il va de soi que ce code n’est pas en l’état complet, et qu’il faut lui ajouter des fonctionnalités techniques. Par exemple, pour supprimer les fichiers lors d’un changement d’image, ou dans d’autres cas tordus. La plupart de ces cas sont traités dans le code du projet. Je vous laisse lire le détail de l’implémentation directement dans le code, cet article étant déjà assez (trop ?) verbeux.

Contrôleur de téléchargement

Nos images sont maintenant dans le répertoire dédié au stockage, mais on ne peut pas les afficher en faisant un lien directement dans nos pages, puisqu’elles sont en dehors de l’arborescence du site. Pour pallier ce problème, on crée un nouveau contrôleur, dédié au téléchargement des images. Le but est de pouvoir insérer dans nos GSP des tag <img/> avec un attribut src="..." pointant sur notre contrôleur. Encore une fois la méthode est assez directe :

• création d’un DlController :

grails create-controller fr.xebia.nothunes.Dl

• création d’une méthode images pour servir l’image en fonction des paramètres de requête :

class DlController {
   def images = {
      String filename = params.id
      log.debug "dl image file : ${filename}"
      def file = new File(grailsApplication.config.storage.image.directory + filename)
      if (file.exists()) {
         response.setContentType("application/octet-stream")
         response.setHeader("Content-Disposition", "attachment; filename=${filename}")
         response.setContentLength(file.readBytes().size())
         response.getOutputStream() << file.readBytes()
      }
      response.flush()
   }
}

Nous pouvons maintenant afficher l’image en créant un lien vers ce contrôleur :

grails-app/views/band/show.gsp

...
<img src="${createLink(controller:'dl', action:'images', params: [id: bandInstance.logoPath])}"/>
...

Sprint review

Comme je l’avais annoncé dans l’intro, ce billet est certainement plus intéressant pour ceux qui débutent avec Grails. Nous avons pu voir une méthode de création d’un contrôleur de bout en bout, et une façon simple de stocker et servir des fichiers à l’extérieur de l’arborescence du site. Retenez que les vues et contrôleurs générés par Grails sont très ouverts, il faut donc bien se souvenir de systématiquement :

• les protéger en rajoutant de filtres URL dans le bootstrap
• ajouter les contrôles métiers si besoin dans le code du contrôleur
• nettoyer les vues des informations techniques, superflues pour les utilisateurs

Mission accomplie : le sprint backlog est bouclé et notre projet est livrable à la fin du sprint, ce qui reste un point crucial. Au prochain épisode, on va s’occuper des classes Tracks et de la navigation pour les internautes, le tout en utilisant massivement AJAX.

Ressources

• Dépôt GitHub du projet, version 0.2
• Grails File upload

Les exemples de prise en main du framework Grails ne manquent pas sur la toile. Nous allons tenter de dépasser les Getting started en déroulant la réalisation d’une application web de bout en bout :

• Conception
• Réalisation
• Mise en production
• Evolutions et maintenance

Parce qu’il est toujours plus agréable de travailler sur du concret, nous allons réaliser pas à pas une plateforme de musique libre en ligne, que nous baptisons : Projet NoThunes, en clin d’oeil à une autre célèbre plateforme de musique payante. Tout le code du projet est disponible sur GitHub. Ce projet est donc Open Source mais aussi « Open méthode » puisque je vous ferai partager toutes les étapes de conception/réalisation au travers d’une série d’article. Chaque article sera associé à un tag du dépôt GitHub, pour que tout le monde puisse savoir à quelle version on se réfère.

Bien évidemment il y a plus d’une bonne façon de faire. Ce projet est mené dans une optique d’amélioration personnelle et de partage donc n’hésitez pas à discuter les choix techniques et à fournir des solutions alternatives en commentaire.

Dans ce premier billet, nous allons :

• définir le product backlog du projet
• présenter les classes du modèle
• démarrer notre projet
• mettre en place la sécurité et les classes du modèle
• créer un menu dynamique, différencié par rôle utilisateur

Note technique

Le projet est réalisé avec Grails v1.3.3.

Product Backlog

On distingue 3 rôles utilisateurs :

• les administrateurs : par définition omnipotents sur le site pour gérer les comptes utilisateurs, les règles de sécurité, etc.
• les internautes : les visiteurs lambda de notre site.
• les membres : des internautes qui se seront enregistrés pour accéder à plus de fonctionnalités.

En sachant qu’un membre, s’il est authentifié, doit conserver l’accès à toutes les fonctionnalités des internautes, et qu’un administrateur doit aussi avoir accès aux fonctionnalités des membres.

Le product backlog est trié par business value décroissante. Je vous épargne le chiffrage agile et les fioritures de Scrum.

Présentation du modèle de données

Il s’agit d’un cas d’école donc nous simplifions à l’extrême le modèle de données à gérer. Le but n’est pas (encore ) de concurrencer les plateformes en place. On considère donc les objets :

Les attributs de chacun de ces objets sont volontairement simplistes. Cela nous donne le modèle suivant :

Démarrage du projet

Comme tous ceux qui ont déjà survolé Grails le savent, un nouveau projet démarre toujours par le lancement de la commande :

grails create-app nothunes

qui va générer l’arborescence initiale du projet. Comme c’est toujours plus confortable, l’étape suivante sera d’importer ce projet dans votre IDE favori. Pour travailler avec Grails le choix est limité et le support inégal : NetBeans, SpringSource Tool Suite ou IntelliJ IDEA. Au pire un bon vieux vim suffira.

Mise en place de la sécurité

Le plugin de sécurité officiel du projet Grails est depuis peu le Spring Security Core Plugin, couplé au plugin Spring Security UI pour la génération des écrans de CRUD concernant les rôles et utilisateurs. Malgré cela, je lui préfère encore pour quelques temps son prédécesseur : Acegi Plugin, dont le développement a été stoppé, mais qui est plus complet et plus simple à mettre en place. D’autre part, le côté stable du plugin Acegi, comparé au développement hyperactif des plugins Spring Security est assez confortable pour notre projet.

Je vous renvoie donc au précédent article que j’ai écrit sur le sujet. Le package de base à utiliser est : fr.xebia.nothunes.

Création des classes du modèle

Maintenant que nous avons les classes utiles pour la gestion des utilisateurs et de la sécurité, ajoutons un peu de métier dans tout ça. Pour cela on utilise la commande grails create-domain-class pour chacune des entités qu’on souhaite obtenir, puis on passe en édition dessus pour ajouter les attributs. Je trouve dommage de n’avoir pas plus poussé la ressemblance avec Ruby on Rails en autorisant l’ajout des attributs directement en paramètre de la ligne de commande.

Parmi les attributs que l’on donne à chaque classe, il y en a 2 qui sont partout et bien utiles : lastUpdated et dateCreated. Ces 2 attributs indiquent à GORM qu’il faut gérer le timestamping automatique des objets qui les possèdent.

Dynamisons le menu

La documentation du plugin Acegi n’en parle pas mais si vous téléchargez les sources du plugin et que vous allez voir le fichier grails-app/taglib/org/grails/plugins/springsecurity/taglib/AuthorizeTagLib.groovy vous tombez alors sur une taglib tout à fait disponible dès que vous faites usage de ce plugin dans votre projet, et qui offre les tags suivants :

• ifAllGranted
• ifNotGranted
• ifAnyGranted
• loggedInUserInfo
• isLoggedIn
• isNotLoggedIn
• loggedInUsername

Nous allons baser la différenciation des menus sur ces tags qui permettent de tester, directement dans les GSP si l’utilisateur courant possède un rôle donné ou non.

La première étape est de séparer le contenu du menu dans un fichier GSP à part. Pour l’instant notre application est telle que générée par grails. Dans le fichier grails-app/views/index.gsp se trouve la page d’accueil par défaut. Elle contient une balise <div id="nav"/> qui encapsule le menu de gauche de la page d’accueil de l’application.

Pour ajouter plus de flexibilité, on sort cette div dans un nouveau fichier qu’on va placer dans grails-app/views/menu/_nav.gsp (après avoir créé le répertoire menu bien sûr), puis on remplace dans index.gsp la présence de cette div par un tag

<g:render template="menu/nav"/>

Si vous lancez un grails run-app et que vous allez voir la page d’accueil vous remarquerez que rien n’a changé. Le paramètre passé au tag render indique d’inclure le code du fichier GSP situé dans le répertoire menu/ et nommé _nav.gsp (le caractère est indispensable en début de nom).

Ce découpage, allié aux tags du plugin Acegi, nous conduit à un joli découpage propre :

grails-app/views/menu/_nav.gsp

<div id="nav">
<ul>
	<li>Welcome,</li>
	<li>Logout</li>
	<li>Login</li>
	<li>No account ? : Register</li>
</ul>
<div class="homePagePanel">
<div class="panelBody"></div>
</div>
</div>

grails-app/views/menu/_admin.gsp

<h1>Admin manages ...</h1>
<ul>
	<li>roles</li>
	<li>users</li>
	<li>requestMaps</li>
</ul>

grails-app/views/menu/_user.gsp

<h1>Member manages ...</h1>
<ul>
	<li>...</li>
</ul>

grails-app/views/menu/_all.gsp

<h1>Menu</h1>
<ul>
	<li><a href="${createLinkTo(dir:'')}">Home</a></li>
</ul>

Maintenant il suffira d’utiliser le tag <g:render template="menu/nav" /> directement dans le layout global pour appliquer le menu sur toute notre application, et on a maintenant un fichier GSP par section de menu avec juste ce qu’il faut de tag de sécurité pour gérer l’affichage contextuel.

Après ce découpage, j’ai travaillé un peu le layout et la css afin d’avoir toutes les pages aux couleurs du projet, c’est toujours plus agréable pour travailler. Pour éviter de surcharger cet article, si vous voulez voir le détail complet du travail de mise en forme, reportez vous au GitHub du projet.

Debriefing

Voilà un bon démarrage pour notre plateforme de musique. Le projet est lancé et nous pouvons travailler dans de bonnes conditions pour la suite. L’état du product backlog :

Notre projet est déjà livrable en production avec ces fonctionnalités.

A bientôt pour le prochain épisode :

Ressources

• Site officiel de Grails
• Dépôt GitHub du projet NoThunes
• Tag de la version décrite dans ce billet

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d’Helios pour incarner la version annuelle d’Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le « Install new software… », un lien direct vers le Marketplace permet très facilement d’installer ces plugins, un peu à la manière d’un plugin Firefox (tout comme le redémarrage obligatoire). L’ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l’implémentation full java utilisée également sur d’autre projets alors qu’EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d’une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l’ajout d’une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d’Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l’application Xtext qui permet d’écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l’offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L’application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu’elles soient installées au sein de l’infrastructure propre de l’entreprise ou dans le Cloud. L’ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l’application, notamment l’utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l’application, rien de plus simple il suffit de se rendre sur l’App Store, directement depuis son mobile, ou sur iTunes à l’adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu’un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d’un article en 2 parties intitulé « GroovierSpring ». Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l’on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique… C’est d’ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n’importe quel bean Java défini plus classiquement. Le fait que les beans soient à l’origine en Groovy est complètement transparent à l’application.
La seconde partie de l’article va plus loin en explorant le rechargement à chaud des beans Groovy. C’est une plus-value importante: qui n’a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l’article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n’est pas toujours évident d’accéder au système de fichier des applications en production. C’est une idée assez peu conventionnelle ! D’ailleurs, le paragraphe de fin, intitulé « When Groovy scripts go bad », constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s’intitule « GORM Gotchas (Part 1) ». Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d’Hibernate n’apprendront pas grand choses, mais l’article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l’utiliser sans expérience préalable d’Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à « save() », et pourquoi ils le sont parfois en l’absence d’appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s’appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l’éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d’un top 10 sélectif, chez des clients qui avaient conscience d’avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu’il est bon de toujours avoir à l’esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d’expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d’appels.
• un mauvais usage des frameworks de mapping objet – relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l’utilisation la plus hors de propos de la librairie.
• l’existence de fuite mémoire (mais pourquoi ce point n’a t’il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d’introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta…
• une mauvaise utilisation des ressources machine (CPU, I/O…). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d’augmenter, mais ce n’est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c’est le Garbage Collector qui vous rappellera à l’ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d’objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c’est en partie la raison de vivre d’un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C’est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l’envie de partager avec vous cette nouvelle d’importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l’utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d’un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p’tits gars !

Actualité éditeurs / SSII

• SpringSource se dote d’un cache distribué

Le coin de la technique

• Jarlsberg, la sécurité en s’amusant
• Multi-Catch confirmé dans le projet Coin

Evènements de notre communauté en France et à l’étranger

• C’est le printemps, les User Groups fleurissent

Actualité éditeurs / SSII

SpringSource se dote d’un cache distribué

VMware vient de faire l’acquisition de la société GemStone Systems, éditeur de la solution de cache distribué GemFire. Elle sera gérée désormais sous la houlette de SpringSource. Ce nouveau rapprochement s’inscrit dans la stratégie affichée de la firme de fournir une plateforme complète de cloud destinée aux applications Java.

Par ailleurs, dans une interview donnée à InfoQ, Rod Johnson affirme que le framework Spring développera les abstractions nécessaires à l’intégration de ce type de produit, comme c’est déjà le cas pour les RDBMS, les broker JMS, etc via les Templates Spring, et pourrait permettre l’intégration d’autres solutions de data-grid comme Oracle Coherence ou encore Terracotta.

Le coin de la technique

Jarlsberg, la sécurité en s’amusant

Xss, DoS, Xsrf… Des acronymes barbares qui désignent des failles de sécurité courantes dans nos applications Web. Si vous voulez mieux les connaitre, et ainsi vous en protéger, le nouveau projet de Google Labs, Jarlsberg (fromage norvégien), est pour vous.
Et comme le meilleur moyen d’apprendre est de faire, Google met à votre disposition un site truffé de failles de sécurité que vous pourrez hacker à loisir.
Les failles sont organisées en fonction de leur type :

• Cross-site Scripting (XSS)
• Cross-site Request Forgery (XSRF)
• Cross-site Script Inclusion (CSSI)
• Manipulation de l’état du client
• Traversée d’arborescence
• Déni de Service (DoS)
• Exécution de code
• Vulnérabilité de la configuration
• Vulnérabilités AJAX

Pour venir à bout de ces failles, il existe trois types de tests :

• Tests boite noire : l’utilisateur ne connait pas le fonctionnement interne du site, il tente de hacker le site en passant par les pages exposées
• Tests boite blanche : le code de l’application en python est connu par le hacker
• Tests boite grise : un panaché des deux précédentes méthodes

Ces tests sont servis pour une large variété d’outils de hacker :

• Snippets HTML
• Upload de fichier
• Administration du site
• création de nouveaux comptes utilisateur
• Language de templating Jarlsberg
• Injection AJAX

L’approche est très pédagogique, avec une succession de challenges à résoudre. Par exemple, le premier de ceux ci : pouvez vous uploader sur le site un fichier qui vous permettra d’exécuter un script sur le serveur d’application ? Chaque challenge propose des indices, une manière d’exploiter la faille et une correction.
Une plongée passionnante dans l’univers des hackers.

Avant de vous lancer dans ce Google Lab, nous vous conseillons la lecture de l’article de Christian Heilmann.

Bien sûr, ces trucs et astuces ne doivent pas être reproduits à la maison, vous pourriez tomber sous le coup de la loi.

Multi-Catch confirmé dans le projet Coin

Finalement, après plusieurs hésitations, Joe Darcy confirme la possibilité de rassembler plusieurs catch d’exceptions dans une même clause dans Java 7. Ainsi il sera possible d’écrire:

try{
// code
} catch (ExceptionA|ExceptionB ex){
// code
}

Les discussions portaient sur la deuxième partie de cette proposition, le renvoi ( rethrow ) des exceptions. En effet il peut arriver qu’une exception soit renvoyée après avoir été attrapée. Dans ce cas elle doit apparaître dans la signature si c’est une exception vérifiée ( checked ). Par exemple :

public void myMethod() throws Exception {
try{
// A hérite d'Exception
throw new A();
} catch (Exception e){
// code: par exemple un log
throw e;
}
}

Ce que propose le projet Coin, c’est de vérifier les exceptions possibles dans le bloc try et de donner la possibilité dans la signature de la méthode de renvoyer le type précis des exceptions. Pour cela on utilise le modifier final. Ce qui donne :

public void myMethod() throws A {
try{
// A hérite d'Exception
throw new A();
} catch (final Exception e){
// code: par exemple un log
throw e;
}
}

Ceci permet d’avoir une signature plus précise et de pouvoir remonter une exception facilement. Les difficultés de cette proposition ont tourné autour du type d’exception qui se trouve dans la clause catch dans le cas où le type n’est connu qu’au Runtime.

Cette proposition en ravira plus d’un mais fera aussi sourire ceux qui prônent la suppression des exceptions vérifiées. Pour finir, un petit cas limite amusant de cette proposition, relevé par Stephen Colebourne :

public void myMethod() {
try{
//  du code sans exception
} catch (final Exception e){
// on envoie une exception vérifiée qui n'est pas dans la signature!
throw e;
}
}

Evènements de notre communauté en France et à l’étranger

C’est le printemps, les User Groups fleurissent

Avec notre plateforme de prédilection, Java, qui s’ouvre de plus en plus à de nouveaux langages, il fallait bien que la communauté suive. Nous assistons donc ces derniers temps à l’éclosion de nouveaux User Groups. Le premier à bourgeonner fut le Scala User Group (attention, pas « SUG » car le nom est déjà pris) qui a pris ses racines lors de la soirée Scala organisée par le Paris JUG. Cette semaine, c’est Guillaume Laforge, Groovy project lead et Cast Codeur émérite, qui a annoncé sur la mailing liste du Paris JUG la création du Groovy User Group. La première rencontre est d’ores et déjà prévue le 10 juin.
Ces nouveautés s’inscrivent dans la lignée de ce que nous avons déjà observé avec la multiplication des JUGs: la communauté s’organise pour partager, lier connaissance et évoluer. Après les différents JUGs centrés sur Java, il n’est pas étonnant de voir des User Groups se créer pour rassembler les personnes intéressées par les nouveaux langages de cette plateforme.
Par la suite, ces langages resteront-ils sous la coupe des divers JUGs ou allons nous assister à la création du « Marseille Groovy User Group » ou du « Lyon Scala User Group » ?

Je vous propose donc un petit tutoriel pour mettre en place une gestion des utilisateurs, avec gestion des rôles, filtres URL/Rôles, formulaire de souscription de compte. Pour cela, nous allons nous appuyer sur le Spring Security Plugin de Grails. C’est une étape incontournable de la création d’application, et nous allons pouvoir constater à quel point l’utilisation de Grails booste la productivité.

Béni soit le scaffolding

Commençons par créer l’application BookStore qui nous servira de base, ainsi qu’une classe de domaine Book.

grails create-app BookStore
cd BookStore
grail create-domain-class fr.xebia.bookstore.common.Book

Apportons quelques modifications à notre classe pour qu’elle soit un peu plus parlante dans la suite des exemples :

grails-app/domain/fr/xebia/bookstore/common/Book.groovy

package fr.xebia.bookstore.common
class Book {
    String titre
    String auteur
    Date premierePublication
    static constraints = {
        titre(nullable:false)
        auteur(nullable:false)
    }
}

Maintenant nous générons le CRUD autour de notre classe Book.

grails generate-all fr.xebia.bookstore.common.Book

Installation du plugin Spring Security. Pas de panique, acegi est toujours le nom du plugin, c’est un héritage de l’histoire

grails install-plugin acegi

Creation des classes de domaines pour la gestion de la sécurité, Utilisateur, roles et mapping de security et génération des managers associés

grails create-auth-domains
      fr.xebia.bookstore.security.User
      fr.xebia.bookstore.security.Role
      fr.xebia.bookstore.security.RequestMap
grails generate-manager

Maintenant nous générons les composants nécessaires à la souscription d’un compte par un internaute.

grails generate-registration

A ce stade, nous disposons des contrôleurs suivants (et des vues qui vont avec) :

• CaptchaController : permet de générer des images captcha pour éviter que des robots ne viennent créer des comptes utilisateurs
• fr.xebia.bookstore.common.BookController : CRUD de gestion de la classe Book
• LoginController : Contrôleur de connexion
• LogoutController : Contrôleur de déconnexion
• RegisterController : Contrôleur d’enregistrement d’un compte utilisateur par un internaute
• RequestMapController : CRUD de gestion des règles de sécurité
• RoleController : CRUD de gestion des rôles
• UserController : CRUD de gestion des utilisateurs, destiné à notre espace d’administration

On peut déjà démarrer l’application avec un grails run-app et voir ce que ça donne :

Configuration et sécurisation

Cela fait déjà beaucoup de matières à exploiter en un temps relativement court. Mais en l’état c’est encore un peu brut de fonderie pour ressembler à une vraie application. Nous allons donc faire un peu de configuration et de rangement autour de tout ce code parachuté par Grails. Pour atteindre notre objectif, nous allons maintenant procéder à la sécurisation des écrans de :

• CRUD complet des utilisateurs
• CRUD complet des rôles
• CRUD complet des mappings de sécurité
• Création de Book

Tout est déjà en place pour cela grâce au code que nous avons généré. Commençons par utiliser le RoleController pour créer un rôle utilisateur et un rôle administrateur :

Maintenant que nous avons des rôles, il faut créer un compte utilisateur avec le rôle ROLE_ADMIN pour éviter de se retrouver bloqué quand on posera les mappings de sécurité. Cette fois, c’est du coté des écrans du UserController que ça se passe :

Et pour finir, on pose des mappings de sécurité sur les URL qui nous intéressent, avec la liste des rôles autorisés à accéder. Pour cela, nous utilisons le RequestMapController :

Et voilà ! Notre application répond déjà mieux à nos attentes en terme de sécurité :

• tout le monde peut voir la liste des Book présents en base.
• seuls les utilisateur ayant le rôle ROLE_USER ou ROLE_ADMIN peuvent insérer de nouveaux Book
• seuls les utilisateur ayant le rôle ROLE_ADMIN peuvent créer des utilisateurs, des rôles et modifier les règles de sécurité

Si un utilisateur non authentifié tente d’accéder à une URL protégée, il sera automatiquement redirigé vers un écran de login avant d’accéder à la page désirée.

Adaptations de confort

Par défaut, une application Grails utilise HSQLDB et démarre avec une base vierge à chaque lancement. Nous allons donc changer cela pour intégrer directement à chaque démarrage les rôles, mappings de sécurité et un compte administrateur :

grails-app/conf/BootStrap.groovy

import fr.xebia.bookstore.security.User
import fr.xebia.bookstore.security.Role
import fr.xebia.bookstore.security.RequestMap
class BootStrap {
    def authenticateService
    def init = { servletContext ->
        def roleAdmin = new Role(authority: 'ROLE_ADMIN', description: 'Administrateur').save()
        def roleUser = new Role(authority: 'ROLE_USER', description: 'Utilisateur').save()
        def userAdmin = new User(username: 'admin', userRealName: 'ATTAN Charles',
            passwd: authenticateService.encodePassword('admin'),
            enabled: true, email: 'admin@bookstore.fr')
        userAdmin.addToAuthorities(roleAdmin)
        userAdmin.save()
        def protectBookCreation = new RequestMap(url: '/book/create*', configAttribute: 'ROLE_ADMIN,ROLE_USER').save()
        def protectUserManaging = new RequestMap(url: '/user/*', configAttribute: 'ROLE_ADMIN').save()
        def protectRoleManaging = new RequestMap(url: '/role/*', configAttribute: 'ROLE_ADMIN').save()
        def protectSecurityMappingManaging = new RequestMap(url: '/requestMap/*', configAttribute: 'ROLE_ADMIN').save()
    }
    def destroy = {
    }
}

Voilà, au prochain démarrage nous retrouverons toutes nos chères données directement en base. Ensuite, nous pouvons nous attaquer à l’enregistrement des internautes en tant qu’utilisateur standard. Par défaut, le formulaire lié au RegisterController crée des utilisateurs sans rôle, ce qui ne nous convient pas du tout. De plus, comme il serait agréable pour les nouveaux utilisateurs de recevoir un mail de confirmation de leur inscription, on va le mettre en place dans la foulée :

grails-app/conf/SecurityConfig.groovy

security {
	active = true
	loginUserDomainClass    = "fr.xebia.bookstore.security.User"
	authorityDomainClass    = "fr.xebia.bookstore.security.Role"
	requestMapClass         = "fr.xebia.bookstore.security.RequestMap"
        defaultRole             = 'ROLE_USER'   // Role par defaut des nouveaux utilisateurs
        useMail                 = true          // specifie d'envoyer un mail à l'enregistrement d'un compte
        mailHost                = 'localhost'   // serveur d'envoi de mails
        mailProtocol            = 'smtp'        // nom du protocole JavaMail
        mailFrom                = 'no.reply@bookstore.fr'   // adresse de l'envoyeur du mail
        mailPort                = 25            // port de connexion au serveur de mail
}

Avec ces modifications, tous les internautes qui créeront des comptes par le formulaire obtiendrons le rôle ROLE_USER et recevront un mail comme ceci :

Si vous souhaitez adapter un peu le format du mail, le code associé est situé vers la ligne 170 du code de RegisterController :

extrait de grails-app/controllers/RegisterController.groovy

[...]
if (config.security.useMail) {
                String emailContent = """You have signed up for an account at:
 ${request.scheme}://${request.serverName}:${request.serverPort}${request.contextPath}
 Here are the details of your account:
 -------------------------------------
 LoginName: ${person.username}
 Email: ${person.email}
 Full Name: ${person.userRealName}
 Password: ${params.passwd}
"""
                def email = [
                    to: [person.email], // 'to' expects a List, NOT a single email address
                    subject: "[${request.contextPath}] Account Signed Up",
                    text: emailContent // 'text' is the email body
                ]
                emailerService.sendEmails([email])
            }
[...]

Et voilà comment en quelques minutes on peut avoir une application, basique certes… mais sécurisée !

Pour aller plus loin

Le plugin Grails Spring Security possède de nombreuses autres options. Je n’ai développé ici que la stratégie de stockage des règles de sécurité dans la base, mais il est également possible de les définir directement dans le fichier SecurityConfig, ou par annotations des méthodes des contrôleurs.

On peut appuyer la sécurité sur OpenID, LDAP, CAS, NTLM ou même utiliser une connexion FaceBook Connect. On peut changer l’algorithme de cryptage des mots de passe, les possibilités sont assez étendues.

Et si vraiment Spring Security ne vous convient pas, il existe d’autres solutions de sécurité à base de plugins comme Shiro ou Stark, qui feront peut-être l’objet d’autres articles dans le futur.

Conclusion

L’utilisation du plugin Grails Spring Security permet de mettre le pied à l’étrier très rapidement, en s’appuyant sur un standard des frameworks de sécurité en Java. J’ai personnellement beaucoup apprécié la simplicité de prise en main et les exemples fournis dans la documentation officielle. Je vous invite d’ailleurs à la parcourir, elle contient d’autres tutoriels notamment pour l’utilisation de OpenID et LDAP.

Nota Bene : Cet article est fortement inspiré de celui-ci, mais il méritait des précisions à mon goût.

Ressources :

• Le projet Grails
• Grails Spring Security Plugin
• Tutoriels officiels Spring Security Plugin

Actualité éditeurs / SSII

• Kenaï, fermera, fermera pas ?

Le coin de la technique

• Groovy++: bientôt dans votre JVM ?
• InfoQ sort un ebook gratuit sur Grails
• Maven vers une injection de dépendances via Guice

Actualité éditeurs / SSII

Kenaï, fermera, fermera pas ?

Comme il fallait le prévoir au vu de l’engouement d’Oracle pour les projets communautaires, la ferme de projets Kenaï vit ses derniers jours en tant que service public. La plateforme lancée en 2008 et construite autour de JRuby, Glassfish et MySQL fournissait un environnement de suivi de projet complet avec la gestion de version, des wikis, des mailing lists et que sais-je encore. Avec NetBeans 6.7, il est même possible de maintenir entièrement son projet depuis son IDE. Le site héberge encore aujourd’hui quelques 40 000 projets communautaires parmi lesquels on retiendra JRuby et Hudson. Oracle a d’abord annoncé la fermeture du site sous 60 jours afin de permettre aux projets de migrer vers d’autres solutions. L’idée de départ devait être de ré-utiliser la plateforme en interne mais plus du tout ouverte au public.
Faut il y voir les effets de la réaction d’une communauté importante ou un gros problème de communication : Oracle change son fusil d’épaule à travers la voix de Ted Farrell qui a clarifié l’avenir de la plateforme en annonçant que ce serait finalement une migration vers java.net. Dans son annonce, Farrell laisse entendre que tous les efforts seront poussés sur java.net et que la communauté Kenaï pourrait continuer à travailler sans perte sur la nouvelle version de cette ancienne plateforme de développement hosté.
Comme le dit la chanson, trois pas en avant, trois pas en arrière, …

• Kenaï to close sur InfoQ
• Le post de Ted Farrell

Le coin de la technique

Groovy++: bientôt dans votre JVM ?

Nous avons éhontément passé sous silence nombre de news du monde Groovy récemment:

• Groovy 1.7
• Grails 1.2
• La sortie du plugin Groovy Eclipse en version 2.0
• La sortie de nouvelles versions de Griffon, le framework pour clients lourds qui reprend les idées de Grails

Alors pour nous rattraper, nous ne passerons pas à coté de la nouvelle suivante : le développement de Groovy++ ! Alex Tkachman, l’initiateur du projet nous explique dans une interview de quoi il retourne et Roshan Dawrani nous explique ce qu’il retient du projet. En fait, malgré tous ses avantages, Groovy est encore assez lent. En tout cas beaucoup plus que Java, à cause de son coté dynamique. L’idée de Groovy++ est de continuer à utiliser Groovy normalement, mais en pluggant un compilateur spécial pour certaines parties du code annotées avec @Typed. Le code ainsi annoté devra respecter de légères contraintes (contraintes par rapport au laxisme de Groovy, mais légères par rapport au typage fort de Java). Le compilateur pourra donc effectuer des optimisations, notamment grâce à l’inférence de type, et nettement améliorer les performances. Les premiers résultats semblent encourageant en tout cas : 197 fois plus rapide d’après ce micro-bench et 33% plus rapide d’après cet article lu sur le Touilleur Express.

Alors ce Groovy++, une révolution ? Difficile à dire ! En effet, d’un coté Groovy est de plus en plus utilisé (notamment à travers Grails) et un coup de boost ne peut pas lui faire de mal. Mais d’un autre coté, l’interaction de Groovy et Java étant très avancée, on peut se contenter d’écrire en Java les parties du programme nécessitant des performances optimales. On peut aussi voir en Groovy++ l’ajout d’une énième librairie dans le développement, avec ses contraintes, ses bugs… D’autant que, pour des problèmes de licence sur certaines parties de code, le compilateur n’est pas encore OpenSource (ce qui est prévu pour la suite). Donc, si vous sous sentez l’âme d’un aventurier ou que vous avez désespérément besoin de gains de performances tout en gardant la « Groovy attitude », n’hésitez pas à nous faire vos retours sur l’utilisation de Grovvy++ !

InfoQ sort un ebook gratuit sur Grails

InfoQ vient de sortir, dans sa série « Minibooks » la seconde version de son « Getting started with Grails ». La première version, datant d’il y a déjà 3 ans, était basée sur Grails 0.3.1 alors que celle-ci s’appuie sur le tout récent 1.2. Le principe reste identique : les auteurs s’appuient sur une application de gestion de course de chevaux pour nous faire découvrir au fur et à mesure nombre des possibilités offertes par le framework. A la vue du sommaire, largement remanié, on peut penser que les changements ont été profonds. Sans avoir encore lu cette seconde édition, nous pouvons d’ores et déjà la recommander chaudement à toute personne qui s’intéresse à Grails et voudrait rapidement avoir un éventail clair des possibilités qu’il offre (si elle est dans la même veine que la précédente). D’autant qu’au format électronique, le livre est gratuit (juste besoin de s’inscrire à InfoQ)!

Maven vers une injection de dépendances via Guice

Sonatype (via InfoQ) a annoncé la migration progressive de Maven vers une injection de dépendances gérée par Google Guice. Ce qui signifie l’abandon à moyen terme de Plexus, le framework quelque peu obsolète (et abscons, faute de documentation) utilisé depuis les débuts du framework de build. Dans un premier temps, la migration sera gérée via un bridge créé sous Guice.
De plus, l’introduction de Guice devrait se faire via les annotations de la JSR 330, ce qui rendra Maven moins adhérent à Guice dans le cas d’une nouvelle migration vers un autre framework d’IoC.
Cette nouvelle devrait réjouir les développeurs de plugins, qui n’auront plus à maitriser les arcanes de Plexus. Autre conséquence, plus directe, les développeurs Maven n’auront plus à jouer les comitters Plexus pour débugger et ou faire avancer cet outil (qui devrait rapidement se diriger vers une fin de vie en l’absence de ce soutien de poids).
On peut noter que Jason van Zyl, le créateur de Maven, et Bob Lee, l’un des principaux artisans de Guice, avaient œuvré ensemble à imposer la JSR 330 face à la JSR 299 (la fameuse bataille @Inject contre WebBeans).

Qu’est-ce que le scaffolding ?

Le scaffolding (« l’échafaudage » pour les puristes francologues), c’est l’effet « magique » de Grails, ou « comment générer toute une application CRUD à partir de quelques classes métier ». Voyons de plus près comment le scaffolding fonctionne.
…LE scaffolding !? LES scaffolding plutôt. Car Grails propose deux approches différentes pour générer les écrans à partir des classes métier : statique ou dynamique.

Regardons d’abord le scaffold statique.

Scaffolding statique

Commençons par créer 2 classes métier (domain en grails) :

grails create-app bookstore
grails create-domain-class Book

Ajoutons les attributs suivants à la classe créée :

class Book {
    String title
    String author
    static constraints = {}
}

Puis générons les écrans CRUD avec la commande suivante :

grails generate-all Book

Cela génère le controller (BookController) et les pages dans views/book : create.gsp, edit.gsp, list.gsp, show.gsp.

Admirez le résultat en lançant l’application :

grails run-app

Ce scaffolding statique est finalement juste un générateur de code comme on peut en trouver dans beaucoup de frameworks. Et comme tout générateur de code, son intérêt est assez limité puisqu’à la moindre évolution de la classe Book (ajout d’un attribut par exemple), il faudra tout regénérer.

C’est là que vient le scaffold dynamique ! Recommençons depuis la création de la classe Book.

Scaffolding dynamique

Après l’object domain, créons le controller. Manuellement (dans grails-app/controllers) ou avec la commande :

grails create-controller Book

Ouvrons la classe générée BookController et ajoutons l’attribut scaffold :

class BookController {
    def scaffold = true
}

Lancez l’application et admirez de nouveau : le résultat est identique. Mais quel est l’intérêt alors ? L’intérêt n’est pas visible mais il est pourtant de taille pour nous les développeurs : la maintenance ! Nous avons ici une solution beaucoup plus souple qui va s’adapter aux modifications de l’objet métier.

Reprenons la classe Book et ajoutons un attribut description :

class Book {
    String title
    String author
    String description
    static constraints = {}
}

Relancez l’application et vous pouvez voir le nouveau champ.

Personnalisation du scaffolding

Comme vous l’avez peut-être remarqué, les champs du formulaire de création ne sont pas forcément dans l’ordre le plus intuitif (author avant title) et le champ description est un peu court.
Heureusement, le scaffolding est suffisamment intelligent et se base sur les constraints de l’objet métier.

Pour changer l’ordre d’affichage des champs, il suffit de déclarer les contraintes de ces champs dans l’ordre désiré :

class Book {
    String title
    String author
    String description
    static constraints = {
        title()
        author()
        description()
    }
}

Mais ce n’est pas tout, ajoutons quelques attributs pour illustrer les capacités du scaffolding :

class Book {
    String title
    String author
    Date publicationDate
    String category
    String description
    boolean available
    static constraints = {
    	title(blank:false)
    	author()
    	publicationDate()
    	category(inList:['Groovy', 'Java', '.Net'])
    	description(widget:'textarea')
    	available()
    }
}

Regardons les contraintes :

• « blank:false » rend le champ obligatoire
• « inList » génère un élément <select> avec les valeurs spécifiées
• « widget:’textarea’ » génère un élément HTML <textarea>

Static vs dynamic

Le scaffold statique fonctionne comme n’importe quel générateur de code. Vous concevez votre objet métier puis vous générez le controller et les vues. Mais à chaque modification de l’objet renommer un attribut par exemple vous devrez mettre à jour les méthodes du controller et les 4 pages gsp. Beaucoup de travail pour une si petite modification.
Or les objets métier sont modifiés très souvent durant la vie d’un projet (surtout dans un développement agile).

Le scaffold dynamique permet d’éviter cette perte de temps puisque les modifications de l’objet métier sont automatiquement répercutées sur les vues au démarrage de l’application. Le gain de temps est donc énorme !

Conclusion

La différence entre le scaffolding statique et le scaffolding dynamique se résume au moment du cycle de développement où le code est généré. Le code statique est généré par le développeur alors que le code dynamique est généré au runtime. Mais cette petite différence a un énorme impact en terme de maintenance : le scaffold dynamique permet de se concentrer sur le code métier, alors que le scaffold statique oblige à maintenir inutilement les vues et le controller générés.

Grails possède donc avec le scaffolding dynamique un atout précieux qui permet réellement d’augmenter la productivité. Cette fonctionnalité risque à l’avenir de se retrouver dans un grand nombre de frameworks tant elle est bénéfique.

En étant honnête, les écrans CRUD ne pourront que rarement être exposés tels quels au grand public. Mais dans toutes les applications de gestion, la plus grosse partie est la partie immergée, le back-office. Et là, il est tout à fait envisageable d’exposer ces écrans en interne dans l’entreprise.

On peut regretter toutefois que la liste du CRUD ne propose pas de possibilités de recherche ou de filtre, car une liste même paginée devient vite inutilisable dès qu’on dépasse 3 pages. On peut aussi reprocher quelques lacunes niveau ergonomie mais on peut espérer que le scaffold va s’améliorer au fur et à mesure des versions de Grails.

Sinon, Grails offre la possibilité de modifier complètement les templates utilisés pour générer le code, mais ça ce sera pour la prochaine fois !

Car oui : JSF 2.0 annonce la couleur et souhaite faire participer la communauté. Dans cet esprit, les speakers nous présentent le topic twitter #jsf2next pour partager autour des évolutions futures de JSF, souhaitées ou non. Ils enchaînent ensuite avec un trombinoscope de toutes les personnes qui se trouvent derrière JSF 2.0 (on reconnaîtra quelques visages au passage) :

L’aspect communautaire sera rappelé tout au long de la session et on sent vraiment que JSF met le paquet pour être apprécié des développeurs. Les speakers insisteront beaucoup sur le tag JSF2.next avec des slides spécifiques pour donner quelques idées internes ou remontées par la communauté pour (déjà) améliorer JSF 2.0.

La présentation fût découpée en 3 parties : Vue, Contrôleur et Modèle (approximativement 1h pour chaque partie), ce qui nous donne ainsi un bon aperçu de tous les changements de chaque couche du MVC. Une session de BOF spéciale JSF 2.0, qui a eu lieu le soir même, apportera quelques précisions sur certaines fonctionnalités non évoquées lors de la conférence.

Vue

Premier rappel côté Vue et déjà quelques tacles à la gorge : JSP avec ses points faibles (dont certains sont assez discutables…) :

• la complexité de développer une librairie,
• l’état stateful des tags qui impose de faire des appels à release sur les objets tags pour les réinitialiser,
• l’obligation d’une phase de compilation lors du premier affichage,
• le mélange de la présentation avec la couche métier
• le fait que JSP soit orienté contenu (et non composant).

Facelets arrive ainsi avec ses XHTML tags, stateless par défaut, des librairies plus simples à développer, du templating et plus de compilation Java. Et, première bonne nouvelle pour les fans de Facelets, la librairie est incluse dans la spécification avec les mêmes fonctionnalités et quelques améliorations. Elle inclura aussi Gracelets (Groovy pour JSF / Facelets).
La présentation se focalise ensuite sur un des points noirs de JSF : la création de composant… Vous savez, les composants pour lesquels il faut coder un UIComponent, un Renderer, tag/tld, le (ugly) faces-config.xml…

La création de composants est simplifiée dans JSF 2.0 : soit en utilisant les annotations et le fichier taglibs.xml (configuration ainsi simplifiée) soit les Composite Components, une des grosses nouveautés de cette version. Nous avons ainsi les tags composite:interface et composite:implementation pour définir le composite et l’implémentation.

Ces composites sont accessibles directement dans la webapp ou dans un JAR, avec la possibilité d’ajouter des listeners et converters, de plugger un resource bundle…

L’Ajax n’est pas en reste avec un composant embarqué dans JSF 2.0 : jsf.ajax.request(), utilisable par le tag <f:ajax> qui peut-être soit nested soit wrapping.

Contrôleur

Comme la plupart des frameworks web du moment (Wicket pour ne citer que lui), JSF 2.0 pourra enfin se targuer de supporter… GET (pas de sarcasme svp ) ! La conséquence directe est que nous allons enfin pouvoir bookmarker nos URLs. Un exemple avant/après :

<h:link outcome="product" value="View">
    <f:param name="id" value="#{product.id}" />
</h:link>
// qui donnera :
<a href="/product.jsf ?id=3">View</a>

Côté événement, le nouveau SystemEvent fonctionne en mode publish/subscribe avec des événements de type PostAddToViewEvent (après la création du composant) et PreRenderViewEvent (avant le rendering du composant).

Une autre partie intéressante est la gestion des ressources dans l’application avec 2 possibilités de récupération selon que la ressource soit présente dans un dossier de la webapp ou dans un JAR :

// Web root
<h:graphicImage name="hello.png" />
// Classpath of myimages.jar
<h:graphicImage name="hello.png" library="myimages" />
<h:graphicImage value="#{resources['myimages:hello.png']}" />

Modèle

Pour la partie modèle, ce sera surtout une présentation des différentes technologies JEE 6 avec leur intégration dans JSF 2.0 : Managed Beans (partie de JSR-316), Contexts and Dependency Injection (JSR-299), Bean-Validation (JSR-303) et JAX-RS (JSR-311).

Outre les fameuses annotations @Inject (CDI) et @Named (EL), la présentation fera la part belle à Bean-Validation avec l’ajout d’une annotation au niveau de notre POJO qui validera côté Data, Business mais surtout, ce qui nous intéresse, Client.

On se retrouve donc avec les exemples suivants qui sont nativement gérés par JSF 2.0 dans nos pages JSF :

public class User {
   ...
   @NotNull @Size(min=3, max=25)
   public String getUsername() {return username;}
   @NotNull @Email
   public String getEmail() {return email;}
}

Il sera toutefois possible, côté JSF, de désactiver certaines validations, soit par paquet soit au cas par cas.

A noter une bonne gestion du null dans un champ (null ou String vide) avec la possibilité de valider ou non le champ si une annotation Bean-Validation est présente ou si le context-param suivant est présent :

<context-param>
   <param-name>javax.faces.VALIDATE_EMPTY_FIELDS</param-name>
   <param-value>true</param- value >
</context-param>

Mais, il est aussi possible de forcer le champ vide à null avec le paramètre assez explicite suivant :

<context-param>
   <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
   <param-value>true</param- value >
</context-param>

Dernier point abordé, la validation multiple avec plusieurs approches :

• Avant la construction du modèle avec un test de tous les champs sur un événement PostValidateEvent ;
• Après la construction du modèle avec Bean-Validation (mais un objet a déjà été construit… à vous de vous faire votre idée).

BOF

Au niveau des sujets esquivés en conférence, quid d’un projet comme Spring Web Flow pour la gestion d’un flow de page qui est supporté par Seam mais pas par JSF ? Une des réponses est que le projet est plutôt complexe et mériterait peut-être une spécification plus globale pour définir ce qu’est un flow de page, les événements autour de ce flow… Il n’en reste pas moins que JSF 2.0 supporte parfaitement le mode Stateless mais pour l’instant le Stateful ne l’est pas…

Au niveau des tags ajax embarqués, il devrait être assez simple de brancher un jQuery ou un Script.aculo.us sur JSF 2.0 et profiter d’une expérience Ajax complète. Reste à voir l’intégration avec des Composite Components.

Conclusion

Une présentation très rythmée avec beaucoup de slides (peut-être trop) qui ne laissent donc que très peu de temps pour la prise de note. Dommage car certains sujets, non évoqués dans cet article, auraient aussi mérité leur place. Mais ce n’est que partie remise pour un prochain article !

En tout cas, force est de constater que JSF 2.0 tend vraiment à une simplification d’utilisation, orienté annotation et zero-XML. Des Composite Component simples à écrire, une intégration gracieuse avec Bean-Validation… en bref, beaucoup de bons points !

SOA

• SOA Manifesto : pragmatisme utopique ?
• WADL devient une Submission W3C

Le coin de la technique

• Play! Framework 1.0
• Mise à jour de VisualVM en 1.2
• Comment concevoir un datacenter, … par Google
• Ca bouge dans la communauté Groovy/Grails
• Votre application web est elle vulnérable ?
• Artifactory : évolutions et mode SaaS

SOA

SOA Manifesto : pragmatisme utopique ?

La communauté SOA vient de publier son SOA Manifesto. Les valeurs sont très consensuelles, on pourrait même les trouver trop lisses quand on a vécu un naufrage SOA (avec l’oubli des objectifs métier, sa perfection naïve initiale, ses services faussement partagés qui finalement ne satisfont même pas le premier consommateur et autres ESB passe-plats).

Saluons tout de même cette initiative. SOA est une réalité. Les projets utopistes sont aujourd’hui minoritaires face à tous les projets qui intègrent des web services pour interconnecter les applications.
Le Manifeste SOA en français :
Valeur métier plutôt que stratégie technique,
Objectifs stratégiques plutôt que bénéfices spécifiques à un projet,
Interopérabilité intrinsèque plutôt qu’intégration propriétaire,
Services partagés plutôt qu’implémentation spécifique à un besoin particulier,
Flexibilité plutôt qu’optimisation,
Amélioration incrémentale plutôt que recherche de la perfection initiale.

Et rassurons-nous, ce n’est pas un manifesto qui empêchera les zélotes SOA de se déchirer. La guerre SOAP versus REST bat (toujours) son plein .

Ils parlent du SOA Manifesto : InfoQ SOA Manifesto, Stefan Tilkov’s Weblog : Comments on SOA Manifesto.

Allez, je retourne à mes web services Contract First avec CXF .

WADL devient une Submission W3C

Marc Hadley, auteur de la spécification WADL et spec-lead de la JSR-311 (JAX-RS), a annoncé que WADL venait d’être accepté en tant que Submission W3C.

Cette spécification portée par Sun a pour but de définir un format XML de description de services REST. Il s’agit donc d’un équivalent à WSDL pour REST. Alors que REST-*, porté par JBoss, a récemment relancé le débat sur la tendance récurrente à vouloir intégrer dans REST les fonctionnalités des très controversés WS-*, la soumission de WADL au W3C fait réapparaître la question de l’intérêt de définir des contrats pour des services REST.

Joe Gregorio s’opposait vivement à l’initiative WADL il y a deux ans déjà. Il reprochait principalement :

• l’insuffisance de WADL pour définir élégamment tous les types de services REST
• la fragilité du client qui ne fonctionne plus lorsque le contrat change comme c’est déjà le cas avec WSDL
• le manque de réalisme de l’approche WADL2Java qui ne permettrait pas la pleine exploitation de REST. Il préférait donc une approche d’écriture du client REST manuelle, en se basant sur un socle commun.

Toutefois, l’approche « REST avec un contrat » est séduisante pour les applications d’entreprise dont les services sont souvent aussi nombreux que les consommateurs variés.
C’est dans cette logique que de nombreux projets lèvent les ambiguïtés de leurs services REST en préférant XSD à JSON. Les URL et paramètres d’appel restant alors décrits uniquement dans une documentation annexe.

Par ailleurs, on peut regretter que WADL n’ait pas mieux adressé que WSDL des problèmes aussi important que le versioning des services alors qu’un projet comme Apache Thrift a su être innovant sur le sujet.

La soumission de WADL au W3C n’implique donc pas forcément son succès à venir. La disponibilité en masse d’outils et de frameworks permettant de gérer ce format pourrait en revanche attirer une partie des adeptes de SOAP.

Le coin de la technique

Play! Framework 1.0

The Server Side nous annonce la sortie de Play! Framework en version 1.0.

Play! est un framework web de haute productivité (tout comme Grails ou Spring Roo) qui simplifie la création et le développement d’applications Web en langage Java. Ce framework full stack inclut tout une batterie de composants tels que Groovy (pour le templating), Apache Mina mais aussi Hibernate. Quant à l’architecture de vos projets Play!, elle sera de type RESTful.

Cette vidéo nous donne un bon aperçu du produit, surtout en ce qui concerne le fameux Fix the bug and hit reload ! c’est à dire pas de compilation, de déploiement ou de redémarrage serveur suite à la modification de vos classes Java, juste un rafraîchissement de votre navigateur pour voir vos modifications.

A noter que l’équipe travaille déjà sur la version 1.1 et, entre autres, sur le support de Scala

Pour les liens utiles, la documentation complète du produit se trouve sur cette page. Le téléchargement se passe par ici. Et, comme le rappelle TSS, n’oubliez pas la présentation Play! framework in practice à Devoxx, en tous cas nous y serons !

Mise à jour de VisualVM en 1.2

8 mois après la sortie de la version 1.1, l’équipe nous gratifie d’une nouvelle version de son outil de monitoring de JVM. Avec un passage de 1.1.1 à 1.2, il ne faut pas s’attendre à de grandes révolutions. Une liste de 31 bugs corrigés, suivie de quelques nouvelles fonctionnalités notables:

• Un sampling profiler CPU et mémoire
• Support de plusieurs instances de JStatd
• Amélioration de l’API de génération de graphes
• Sauvegarde d’un snapshot de l’application dans un fichier nps pouvant-être utilisé plus tard pour analyse

Nous vous passons les améliorations de GUI et le support des proxys qui peut toujours s’avérer utile pour les analyses à distance. La vraie grande nouveauté c’est le plugin permettant de profiler l’application par sampling. Il ne faut pas s’attendre à la précision des outils instrumentant l’application comme JXInsight. Cependant, cela permettra une analyse assez poussée sans impact sur les performances.

Comment concevoir un datacenter, … par Google

Lors de la conférence Ladis 2009 (Large Scale Distributed Systems and Middleware), Jeff Dean, du groupe infrastructure chez Google, a présenté les manières de concevoir un système distribué.

Il passe en revue différentes problématiques :

• Infrastructure
• Stockage
• Clustering
• Échange de données sur le réseau
• Communication entre applications
• Construction d’application sur de telles infrastructures

Il est intéressant de voir les problématiques posées et les solutions proposées, sur des problématiques que nous avons trop tendance à oublier en tant que développeurs. Citons entre autres :

• Latence réseau : un critère important, car difficile à optimiser
• Bande passante du réseau
• Capacité de stockage (mémoire et disque)

Il est donc très important même pour un développeur d’avoir ces chiffres en tête.

Par retour d’expérience, Jeff Dean montre les joies d’interagir avec du matériel physique. Les applications ne doivent pas supposer que le matériel est infaillible, il y a différentes erreurs que nos applications doivent gérer. Quand on voit les nombres d’occurrences de ce type de problème et leur nature, leur gestion par l’application n’est pas aussi triviale qu’il y parait :

• Problème DNS
• Plantage de serveur
• Perte de connections
• …

Cette présentation est très riche, et elle permet de voir les tenants et aboutissants d’une bonne infrastructure mais aussi les impacts que cela peut avoir dans nos développements de tous les jours.

Les contraintes que s’est imposé Google en terme de disponibilité, dimensionnement, … ont amené plusieurs innovations technologiques en terme d’infrastructure qui ont des impacts sur le développement applicatif :

• Protocol Buffer
• MapReduce
• Google File System
• Big Table

Les lecteurs intéressés par les innovations mises en place par Google sur ses infrastructures noteront que Gregor Hohpe (auteur de Enterprise Integration Patterns) présentera à Devoxx une session Distributed Programming the Google Way.

Ca bouge dans la communauté Groovy/Grails

Pour commencer, on peut noter la longue présentation de Grails faite par Graeme Rocher sur InfoQ. Le « papa » de Grails revient sur de nombreux points relatifs à ce très bon framework permettant de créer des applications web rapidement en bénéficiant de la puissance de Java, Groovy, Hibernate, Spring…

Ensuite, et c’est la rançon du succès, il y a beaucoup de discussions et d’interrogations autour des besoins auxquels répondent Groovy et Grails. Sur son blog, Peter Delahunty précise par exemple que, pour lui, Grails n’est l’arme absolue que si on a une bonne connaissance des technologies sous-jacentes (Spring, Hibernate…). Il ne faut pas débuter par Grails sans s’attendre à bloquer sur des problèmes relatifs à ces technologies.

Cet article va dans le même sens et rappelle qu’à partir du moment où l’on parle de « la magie Groovy » il faut être conscient que des choses qui n’ont rien de magique (cela reste du code !) se passent. Les « dynamic finders », le MOP (Meta Object Protocol) et la magie des closures font rêver mais s’expliquent bel et bien ! Ensuite, il y est noté que la proximité de Groovy et Java fait que de nombreuses personnes pensent que l’on peut passer de Java à Groovy sans formation particulière. Si l’on ne comprend pas les principes de ces choses magiques et que l’on se contente de les accepter comme tels, on s’expose tôt ou tard à des retours de flamme sévères qui se matérialisent généralement sous la forme de StackTraces incompréhensibles. Enfin, le manque de support professionnel pour Groovy/Grails est évoqué. Sur ce point, je pense que l’auteur se trompe. On note en effet que Springsource semble fournir un support commercial pour ces technologies. Mais, il y a peu, Groovy et Grails n’étaient pas encore dans le giron de Springsource et l’on devait « se contenter » du support de la communauté. Néanmoins, celui-ci a toujours été assez réactif et de bon niveau.

Toujours concernant Groovy, on peut noter la version Community Edition de l’IDE IntelliJ, tout récemment publiée, semble bien lotie au niveau du support de ce langage. Malheureusement, le support de Grails, lui, n’est pas présent dans cette version.

Votre application web est elle vulnérable ?

Le Web Application Security Consortium (WASC) estime que 87% des applications de la toile sont vulnérables. Tout le monde ne peut pas s’offrir les services d’un expert en sécurité, et un développeur ne peut pas écrire du code sécurisé s’il ne connaît ou ne comprends pas les risques auxquels il s’expose. C’est pour cette raison que DeveloperWorks revient sur les principales failles de sécurité qui nous guettent, et quelques outils simples pour analyser notre code.
Les points de faiblesse les plus connus sont :

• le cross site scripting : le pirate injecte, via un autre site (de type forum par exemple), un script (de type javascript) vers le site visé. Ce script lui permet de récupérer des informations de connexion, des cookies…
• l’injection de SQL : le pirate saisit du code SQL dans un formulaire web. Celui-ci est poussé jusqu’à la base, exécuté et donne (le plus souvent) accès à la base ‘en direct’ au pirate (l’un des exemples le plus connus est l’injection de OR 1=1- dans un formulaire d’authentification, qui retourne alors toujours TRUE).

Et l’on reparle de l’OWASP, qui propose un outil open source pour détecter ces erreurs de conception : WebScarab. WebScarab s’utilise comme un proxy HTTP (qui se place entre votre browser et votre serveur d’applications, par simple redirection des ports). Ensuite, un simple fichier .txt permet d’injecter votre site avec quelques-uns des plus célèbres cas de cross site scripting ou d’injection SQL. Un autre outil open source est présenté, d’un fonctionnement similaire, Paros Proxy.
Reste ensuite à détecter les faux positifs, opération généralement manuelle.

On notera que la section Ressources de l’article original est richement fournie, et permet de réellement comprendre les risques auxquels sont exposées les applications accessibles sur internet.

Saurez-vous trouver les failles du site de test Webgoat ?

Artifactory : évolutions et mode SaaS

Artifactory est un repository Maven dont la principale particularité est de s’appuyer sur Java Content Repository (JCR) pour assurer le stockage des artefacts. Le choix de JCR plutôt qu’un simple système de fichiers n’avait pas fait l’unanimité car il rend les tâches courantes d’administration plus délicates. En effet, lorsque l’on veut supprimer, remplacer ou déplacer un ensemble d’artefacts, l’action est triviale lorsque le système de fichier est utilisé alors qu’elle devient plus complexe avec JCR, qui n’est pas aussi directement manipulable.

Conscient de ce problème JFrog, l’éditeur derrière Artifactory, a peu à peu intégré un certain nombre de fonctionnalités permettant d’effectuer ces tâches courantes d’administration des artefacts directement depuis l’interface Web. Ainsi, la dernière version du projet permet même le déplacement d’artefacts entre plusieurs repository.

Début septembre, JFrog a également lancé ArtifactoryOnline, un service d’hébergement de repository Maven Artifactory en mode SaaS (Software as a Service). Ce type d’offre répond clairement à un besoin puisque la présence d’un repository Maven est souhaitable pour de nombreux cas d’utilisation et que cette infrastructure nécessite du temps et du matériel dont ne disposent pas toujours les équipes de taille réduite.

Par ces innovations, le repository Maven de JFrog saura sûrement séduire les utilisateurs déçus par les solutions concurrentes que sont Nexus et Archiva.

Article mis à jour le 26/10/2009 à 21h25

RIA

• Mockito-Flex

Le coin de la technique

• JPA implementation patterns
• HadoopDB : un hybride entre MapReduce et DBMS
• Gaelyk ou Groovy sur AppEngine
• PostGIS, le SIG Open Source qui monte

Evènements de notre communauté en France et à l’étranger

• Enquête JavaEE 6

RIA

Mockito-Flex

Un mois après la sortie de la version 1.0, Mockito-Flex se met à jour en 1.0.1. Une release mineure donc mais qui apporte toutefois son petit lot de nouveautés (matchers anyOf(type:Class), notNull() …).

Les utilisateurs de Mockito ne seront pas perdus, le code Flex étant très similaire au code Java que ce soit pour les assertions ou pour le verify:

var list:ArrayCollection = ArrayCollection(mock(ArrayCollection, "collection", [[]]));
given(list.getItemAt(1)).willReturn("A");
assertEquals("A", list.getItemAt(1));
assertNull(list.getItemAt(2));
...
var array:Array = mock(Array) as Array;
array.push("1");
array.pop();
verify().that(array.push("1"));
verify().that(array.pop());

Le projet est très récent et néanmoins en bonne voie : article sur InfoQ, mailing-list, tutoriel… Comme toujours, rendez-vous est pris dans la section téléchargements.

Le coin de la technique

JPA implementation patterns

Vincent Partington, collègue de Xebia Hollande, a réalisé une série d’articles autour de la spécification JPA. Ses articles sont un complément à la documentation existante afin de faire le tour sur les fondamentaux et les faux-amis de JPA :

• Dao générique
• Persister, retrouver, effacer une entité
• Pattern d’architecture : Pour ou contre les DAO, DTO ou facade service, …
• Et bien d’autres patterns …

JPA et ses implémentations (telle qu’Hibernate) restent une technologie difficile à maitriser, et ces articles vous aideront à prendre des décisions techniques importantes pour vos projets.

HadoopDB : un hybride entre MapReduce et DBMS

Daniel Abadi a présenté HadoopDB, un projet issu des universités de Yale et de Brown, qu’il qualifie d’hybride entre MapReduce et DBMS classique. Il s’agit d’une extension pour Hadoop et Hive qui permet d’utiliser une base de données en remplacement de HDFS, le file system distribué utilisé par Hadoop.

Concrètement chaque nœud Hadoop embarque son propre serveur de base de données. HadoopDB reçoit des requêtes SQL qu’il analyse, traduit en tâches MapReduce qui seront envoyées sur chacun des nœuds du cluster Hadoop, puis retraduites en SQL pour être finalement exécutées par la base de données sous-jacente (SQL to MapReduce to SQL Planner).

L’ensemble du projet est décrit dans la publication qui lui est consacrée. Celle-ci présente en détail les réflexions qui ont accompagné la conception d’HadoopDB et les performances obtenues faces à des DBMS parallèles dédiés à l’analyse de données tels que Vertica. Si les performances mesurées d’HadoopDB sont en léger retrait face à Vertica, l’auteur met en avant que sa solution repose uniquement sur des technologies Open Source et qu’une base de données relationnelle (PostgreSQL) a été utilisée : il espère de meilleurs résultats en utilisant une base de données orientée colonnes.

Gaelyk ou Groovy sur AppEngine

Parmi les sujets traités régulièrement sur notre blog, on retrouve Groovy et Google AppEngine (GAE). Qu’obtient-on en mélangeant ? Et bien le dernier projet de Marcel Overdijk et de Guillaume Laforge à savoir Gaelyk (annonce).

Le toolkit s’appuie sur Groovlets et Groovy Template, et permet de déployer rapidement de petites applications sur GAE. Les auteurs rappellent en effet que pour de plus grosses applications, il vaut mieux se tourner vers Grails.

Le tutoriel très complet permet de faire un rapide tour d’horizon de Gaelyk.
Celui-ci décrit l’arborescence d’un projet Gaelyk, la configuration du web.xml et du appengine-web.xml.
La partie vues et contrôleurs s’intéresse :

• aux variables implicites mises en place par la servlet principale (eager avec request, response, context, session… et lazy avec out, html...),
• aux Groovy Templates, avec plusieurs exemples de gtpl, gestion des incude et redirect,
• aux Groovlets, avec là aussi plusieurs exemples de scripts.

Enfin, une dernière partie détaille les ajouts de syntaxes/méthodes spécifiques à Google AppEngine (envoi de mails, Entity, withTransaction()…) et explique comment déployer son application.
Un exemple d’application qui utilise Gaelyk est la Groovy Web Console, ou l’écriture de code Groovy live. Alors, un petit HelloWorld ?

PostGIS, le SIG Open Source qui monte

Les SIG (Systèmes d’Information Géographique) prennent de nos jours une nouvelle dimension avec la généralisation progressive de terminaux mobiles connectés à Internet et capables de se géolocaliser ou encore avec les sites Web riches proposant des cartes, des calculs d’itinéraires ou des recherches du plus proche point de vente. A travers cette évolution, un plus grand nombre d’entreprises peut potentiellement être intéressé par les SIG.

Alors que pendant un temps les principaux acteurs sur ce marché étaient des produits commerciaux, on trouve désormais une offre Open Source : MySQL Spacial, H2Spacial, SpacialLite et PostGIS.
Au sein de cette offre, PostGIS, une extension de PostgreSQL qui a fait son apparition il y a 4 ans, se distingue par sa maturité et sa popularité. Ainsi, l’éditeur Manning a récemment annoncé un ouvrage qui lui sera consacré pour début 2010.

Le site du projet vient d’annoncer la disponibilité de la version 1.4 de PostGIS apportant son lot d’améliorations et de corrections. Le driver JDBC dédié, composé principalement d’extensions à l’API JDBC standard, est lui aussi mis à jour, on le trouve dans la même archive que PostGIS.

Evènements de notre communauté en France et à l’étranger

Enquête JavaEE 6

Sun, via TheServerSide, relance la communauté Java pour ses cinq enquêtes à thème auprès des développeurs JavaEE6. Ces enquêtes doivent servir à optimiser les cours et les certifications JavaEE 6. Si vous êtes prêts à donner cinq minutes de votre temps à l’amélioration de la formation Java, n’attendez plus, vous avez jusqu’au 31 juillet.

Et pour changer, l’opening keynote n’était pas tenue par Sun, mais par Adrian Colyer, CTO de SpringSource. Et le moins que l’on puisse dire, c’est que le changement de ton a été radical.

Par une analogie avec la forêt primaire, A. Colyer a annoncé la chute de Sun, et la très prochaine émergence de nouvelles firmes leader dans le monde JEE (on imagine bien que SpringSource fait partie de ces nouvelles pousses).
Il a expliqué la chute de Sun sous un angle différent de celui du pur rachat financier : selon lui, les acteurs du monde JEE ne veulent plus suivre les recommandations (dogmes) énoncés par Sun, et c’est pour cela que nous voyons apparaitre de nouveaux langages, mais aussi de nouvelles volontés de modulariser la monolithique stack JEE.

Il a ensuite donné sa vision du futur. Sur les langages dynamiques d’abord, et en prenant un fort pari sur l’avenir (comme Neal Ford l’avait fait avec Clojure). Dans les candidats au « java.next » langage, il a cité Erlang, JRuby, Groovy, Clojure, Scala, Jython et Ruby. Il a rapidement éliminé tous ceux qui ne tournent pas sur une JVM (lui aussi pense que la force de Java est sa JVM, un thème récurrent durant ce Jazoon).
Restent donc 4 candidats : deux orientés fortement syntaxe et framework (Groovy et JRuby), et deux orientés gestion de la concurrence (Scala et Clojure). Selon Adrian, le prochain langage star devra, pour bénéficier d’une adoption large et rapide, avoir une syntaxe proche de Java, ce qui élimine rapidement Clojure et Scala. Attention cependant, cela ne signifie pas que ces langages sont plus faibles, mais simplement qu’ils ont moins de chances d’être largement adoptés.
Restent donc Groovy/Grails face à JRuby/Rails.
La deuxième force que devront posséder ces langages est leur capacité à se mélanger avec Java (en ayant des interactions bidirectionnelles), car les millions de programmes Java actuellement en production ne risquent pas de disparaitre du jour au lendemain. Dans ce domaine, Adrian donne l’avantage à Groovy, d’autant plus que Grails interagit avec un framework très largement adopté : Spring.

Le CTO de SpringSource a réussi ensuite une belle pirouette : à ceux qui vont lui reprocher de mettre en avant deux poulains de l’écurie SpringSource (Groovy et Grails), il répond que si ils font partie de sa firme, c’est bien parce qu’il croit qu’ils sont l’avenir… Imparable.

Autre sujet, les frameworks qui vont se développer autour de ces nouveaux langages. Il cite Grails, Rails, Lift (framework pour Scala) et Spring ROO. Ils sont l’avenir, car même si ils demandent de sacrifier un peu de liberté, ils offrent une nette augmentation de productivité (avec notamment la notion de scaffolding).

Sujet suivant, le nécessaire besoin de modularité dans la pile JEE. Avec OSGI bien sûr, mais surtout avec le seul serveur d’application qui expose OSGI à ses utilisateurs, à savoir le produit maison dmServer et sa notion de service BluePrint.

Enfin, et c’est une vision qu’on voyait clairement se dessiner depuis quelques mois, Adrian Colyer prévoit un changement de paradigme pour les techniciens que nous sommes : à l’avenir, il ne sera plus question de se concentrer uniquement sur la phase de développement dans le cycle de vie d’une application, mais d’embrasser la totalité de ce cycle, en particulier les phases de déploiement et de supervision (on se souvient des annonces faites lors du rachat de Hyperic). Il a mis en avant la notion de BluePrint de déploiement : un déploiement, c’est une injection de références (l’adresse de la DB), une injection de configuration (la taille du pool de la dataSource) et des considérations transverses (sécurité, …). Bref, cela est très similaire à une configuration SpringCore, et il n’y a donc pas de raison que la stack Spring ne puisse pas s’en occuper !

Bref, les changements interviennent aujourd’hui à de très nombreux niveaux … Et une chose est sûre, le futur arrive, que nous soyons prêt ou pas. Cette vague arrive, et la seule chose importante pour pouvoir la surfer est d’être dans l’eau au moment où elle arrivera. Il est donc important, dans ces temps troublés, d’expérimenter et de prendre du plaisir, avant l’arrivée d’une autre période stable.

Nous retiendrons deux choses de cette keynote : comme tous les speakers qui ont donné ces conférences d’ouverture, Adrian Colyer est un orateur né, et il a une vision très précise du futur qu’il envisage. Deuxième enseignement, pour lui, Sun est à terre et il est temps que de nouveaux acteurs s’avancent pour prendre la place du grand arbre.

Dierk König (Canoo) a commencé la matinée en présentant « sept patterns d’utilisation de Groovy » sur les projets.
On a bien apprécié la concision du « reader RSS en swing » et le « script ant musical » (en faisant jouer jfugue quelques notes au début et fin du build). Vous pouvez retrouver les 7 points très bien résumés sur le blog du Touilleur Express.
Pour l’anecdote, les extraits de code étaient tapés dans une console Groovy, recopiés caractère par caractère par … un script Groovy ! (la classe, non ?)

Neal Ford (ThoughtWorks) a enchainé avec les « design patterns » dans les langages dynamiques : il a pris quelques patterns du GoF et a montré en quoi les langages dynamiques – comme Ruby ou Groovy – sont plus adaptés pour résoudre les problèmes posés par ces patterns.

Après un salade/saucisse/cornetto (bon appétit) rapidement avalé, ce fut le tour de Gradle. Il s’agit d’un système de build qui élève Ant grâce à la puissance de Groovy. Il se veut plus souple que Maven et apporte les capacités de programmation des scripts Groovy (boucles, conditions, etc).
Dommage que la présentation se soit contentée d’exemples du style « hello world », c’est du coup assez difficile de juger le potentiel de l’outil. Néanmoins, ça a l’air prometteur.

Pour finir avec Groovy, Jetbrains nous a fait une démo très séduisante du support Groovy/Grails sur IntelliJ IDEA. C’est définitivement le (seul) meilleur outil pour coder en Groovy !

Jazoon nous confirme que les langages dynamiques gagnent du terrain, et Groovy est le grand représentant de ces langages dans la sphère Java.

Actualité éditeurs / SSII

• Sun veut créer un Java App Store
• MySQL forké par son fondateur

RIA

• FlexBuilder devient FlashBuilder

Le coin de la technique

• Nos IDEs se corrigent
• Les nouveautés de JDO 2.3

Evènements de notre communauté en France et à l’étranger

• Retour sur la Gr8, la Conférence Groovy

Actualité éditeurs / SSII

Sun veut créer un Java App Store

Jonathan Schwartz, CEO de Sun Microsystems, vient d’annoncer sur son blog son intention de créer un Java App Store sur le même modèle que l’iPhone App Store. Aucun détail précis n’est fourni au-delà de l’annonce.

Ryan Paul fait une analyse réaliste de ce projet en rappelant qu’il n’existe pas, selon lui, en dehors d’Azureus et Eclipse, d’applications Java pour PC très populaires et doute, par conséquent, du marché qui s’ouvrirait à cet App Store.

Reste qu’il s’agirait là d’un modèle de distribution d’application inédit sur PC qui pourrait séduire certains utilisateurs souhaitant obtenir facilement et rapidement des applications dont le niveau de qualité serait garanti par Sun, alors qu’actuellement les filières Open Source restent le principal vecteur de diffusion d’applications Java.

MySQL forké par son fondateur

Monty Program Ab est une société créé par Michael Widenius, le fondateur de MySQL. Son but est de maintenir le projet MariaDB, un fork de MySQL estampillé ‘Open’ et ‘Libre’, et d’offrir des services autour de ce projet. En collaboration avec Percona, une autre entreprise offrant de l’expertise MySQL, ils viennent de créer l’Open Database Alliance afin de former une entité unique derrière l’ensemble des développements MySQL libres.

Plusieurs réactions et analyses ont suivi l’annonce :

• Josh Berkus émet l’hypothèse que l’équipe MySQL actuellement chez Sun soit embauchée par Monty Program Ab.
• Matthew Aslett s’inquiète des limitations qu’imposeront la licence GPL de MariaDB quant à l’inclusion d’un éventuel storage engine qui ne suivrait pas cette licence.
• Ryan Paul met en avant l’ambiguïté de cette annonce en raison de l’absence de définition du type de relation entre l’Alliance et Sun / Oracle.

Dès lors, comme sur de nombreux autres sujets, il sera nécessaire d’attendre de connaître le positionnement d’Oracle sur la question MySQL pour pouvoir établir des certitudes quant à l’avenir de ce SGBDR.

RIA

FlexBuilder devient FlashBuilder

Une nouvelle qui fait réagir la communauté Flex depuis plus d’une semaine est l’annonce du nouveau nom de l’IDE FlexBuilder qui, dans sa version 4, se nommera désormais FlashBuilder.

Les flasheurs / flexeurs, que l’on pourra lire sur The Flash Blog, Adobe Flex Tutorial ou bien Code moi un mouton, se réjouissent de la standardisation du terme Flash (il faut rappeler qu’au final, une application Flex est compilé en SWF donc du Flash lisible par Flash Player). Toutefois, quelques craintes subsistent chez certains concernant ce nouveau terme Flash, qui selon eux ferrait moins professionnel / entreprise. Au moins, maintenant tout est clair : avec FlashBuilder, vous allez créer des applications Flash pour Flash Player !

Pour le reste, rien ne change. Flex, c’est un framework Actionscript qui s’appuiera sur le Flex SDK. Le plugin sera toujours un plugin Eclipse. Et le développeur Flex restera un développeur Flex ! Et vous, que pensez-vous de ce changement de nom ?

Le coin de la technique

Nos IDEs se corrigent

C’est le mot d’ordre actuel. Peu, voir pas de nouvelles fonctionnalités mais de nombreuses corrections de bugs pour Eclipse IDE et IntelliJ IDEA.

Ainsi, Eclipse nous annonce fièrement la correction de 341 bugs (rien que ça !) pour son IDE en version 3.5 RC1, mais pas de nouvelles fonctionnalités. Du côté de chez IntelliJ, c’est plus d’une cinquantaine de bugs et exceptions corrigés pour la version IDEA 8.1.2, avec quelques optimisations de performance (éditeurs de fichiers Java et SQL) et 2 nouvelles fonctionnalités (au niveau du debugger et des raccourcis).

Le téléchargement d’Eclipse 3.5 RC1 se passe par ici et pour IntelliJ IDEA 8.1.2 c’est par là.

Les nouveautés de JDO 2.3

JDO (Java Data Objects), longtemps délaissé au profit d’Hibernate, puis de JPA, a été récemment remis en avant par le support Java de Google App Engine qui préconise l’utilisation de cette API pour assurer la persistance des données dans les applications qu’il héberge.

Andy Jefferson, co-fondateur du projet DataNucleus, vient de poster un tour d’horizon des nouveautés de JDO 2.3 dont l’API est actuellement disponible en early access. Ces nouveautés sont :

• Metadata API : la définition des classes à persister pouvait jusqu’alors se faire par XML ou par annotations. Cette JDO 2.3 vient ajouter une troisième possibilité avec cette API permettant de définir dynamiquement des classes persistables.
• Enhancer API : cette API vient en complément de la précédente. En effet dans la mesure où les implémentations de JDO s’appuient sur du bytecode enhancement des classes persistables, il est nécessaire d’offrir aux développeurs un moyen d’invoquer l’enhancer après avoir déclaré dynamiquement une nouvelle classes via la Metadata API.
• Timeout et annulation de requêtes : dans le monde JPA, ces deux fonctionnalités ne sont pas supportées par la spécification mais seulement en tant qu’extensions propriétaires.
• Contrôle des verrous en lecture des objets : permet un contrôle fin des objets qui doivent être verrouillés automatiquement lors de la lecture, évitant ainsi d’opérer un verrouillage global.

Répondant à des besoins modernes, ces changements devraient être appréciés par les développeurs. Reste que l’avenir de JDO est flou : ne pouvant rivaliser avec la popularité de JPA, JDO pourrait se maintenir dans des cas d’utilisation particuliers et ainsi perdurer dans les années à venir tout en restant marginal.

Evènements de notre communauté en France et à l’étranger

Retour sur la Gr8, la Conférence Groovy

La première édition de la Gr8 Conference vient de se terminer. Il s’agit d’une conférence entièrement dédiée au langage Groovy et aux frameworks gravitant autour. On trouve de nombreux compte rendu sur Internet, Peter Bell en signe le plus complet. Parmi les points les plus intéressants on compte :

• Jim Shingler qui a présenté une introduction à Griffon, un framework Groovy visant à faciliter la production de clients lourds en Swing
• Une session portant sur la création de plugins pour Grails
• Graeme Rocher qui a fait une présentation au titre très explicite ‘Building a Twitter Clone in Grails’

Par ailleurs les cas d’utilisation de Groovy ont été passés en revue par Dierk Konig :

• Utilisation en tant que glue et création d’infrastructure des applications
• Ecriture des règles métiers complexes évoluant régulièrement
• Utilisation pour les hot fixes, en s’appuyant sur le fait que Groovy peut être utilisé de manière interprété
• Définition de fichiers de configuration basés sur la syntaxe Groovy
• Utilisation de Groovy comme unique langage sur un projet de taille réduite ou moyenne
• Utilisation de Groovy comme langage de script pour les tâches courantes (automatisation, installation, déploiement).

Les organisateurs ont annoncé que l’ensemble des sessions de cette conférence seront disponibles sur Parleys dès que possible.