JS Bournival

Ok, maintenant on parle des vraies choses.

Design Patterns in Groovy (Neal Ford)

Ici l’orateur prend le sacro-saint livre des Design Patterns (GoF), et les déconstruit littéralement un à un. Pourquoi fait-il cela? Parce que, selon lui, les solutions apportées par le célèbre bouquin ont été pensées « to make C++ suck less ». Or nous sommes en 2008, nous avons dans notre boîte à outils un langage dynamique génial, Groovy, qui intrinsèquement solutionne plusieurs de ces problèmes. Rapidement on a qu’à penser au Command pattern qui s’implémente tranquillement avec de simples closures.

Par contre, une conclusion à tirer de ces enseignements est que la flexibilité qu’apporte Groovy, souvent vient avec un coût qui est de laisser tomber une certaine rigidité sécurisante. Par exemple, le Template Method pattern, qui stipule d’avoir une classe abstraite, avec un comportement qui est délégué à une éventuelle classe enfant. Groovy peut aisément, à l’aide de meta-programmation, implémenter ce pattern sans héritage, et simplement injecter le comportement voulu en assignant une closure à la méthode anciennement abstraite. Mais à partir de ce principe, on peut bidouiller une classe complètement, ce qu’on ne peut faire en implémentant le pattern en Java. Donc, comme dirais Peter Parker « With great powers, comes great responsibilities … ».

Entre les deux sessions, je me suis procuré le dernier bébé de Scott Davis, tout chaud encore des presses des programmeurs pragmatiques. Et comme personne ne va évacuer la groupie en moi, je vais le faire signer sans fautes demain.

Testing with Groovy (Venkat Subramaniam)

Le Dr. Subramaniam est un hyperactif, et il maîtrise drôlement son sujet. Ce fut une présentation sans diapo! Seulement du code! Fallait en avoir pas mal dans la culotte pour se présenter devant 150 personnes et bizouner des exemples pertinents, d’un rythme soutenu, tout en couvrant la totalité de son matériel. On est passé à travers pas mal de techniques pour tester du code Groovy, mais aussi du code Java, avec Groovy. Parmi ces techniques, citons le simple GroovyTestCase, les Mocks, et plusieurs trucs époustouflants avec les MetaClass.

Ensuite, il fut venu le temps de se restaurer. Pendant qu’on machouillait les dernières miettes de notre gâteau au fromage, un type de la compagnie Contegix nous a entretenu de leur utilisation des technologies Groovy et Grails. Distrayant mais sans plus. Son leitmotiv fut de nous dire qu’il rageait de supporter Rails dans son environnement parce que les déploiements, la maintenance, et la montée en charge sont encore problématiques, et bougent beaucoup trop. Grails, en revanche, se déploie à travers un WAR, sur une plateforme éprouvée, la JVM.

Finalement Graeme est venu nous faire un état des lieux du projet Grails. Il a abordé les prochaines fonctionnalités à être incluses dans une version 1.1, en plus de faire l’éloge des progrès du framework dans l’industrie. Seule note agaçante, il serait temps d’utiliser d’autres arguments que le trafic sur la liste de distribution pour démontrer l’intérêt des développeurs. Dans mon livre à moi, ceci n’est pas nécessairement un bon indicateur, m’enfin.

Grails Workshop: part one

J’ai usé mes derniers électrons (ainsi que ceux de mon Thinkpad) au sein d’un atelier de groupe sur Grails, où l’on prenait le temps de faire chaque étape, de poser les questions, de clarifier des choses. C’était bien, mais au nombre de personnes présentes, notre application n’a pas avancé, outre les 2 domain classes/controllers et un association one-to-many! Suite et fin de l’atelier demain soir …

Rrrrr … zzzz ….

JS.