new Blog( perso );

Et voila, fin de SpringOne'07. Reste a faire du tri dans mes notes !

Prochain évènements du même ordre,

• TheSpringExperience en floride, mais je ne pense pas que mon patron me paye le billet !
• JavaPolis organisé comme SpringOne par le très actif "Belgium Java User Grup".

Ca me laisse tout juste le temps de prendre quelques cours d'anglais...

Petite discution entre quelques "core-developers" de Spring ce matin, sur ... l'art de modifier le mapping des touches du clavier QWERTY pour rendre la frappe plus rapide ! L'un d'entre eux met par exemple le "." à la place du Q et le ";" à la place du "A", remplace [CapsLock] par par "{", etc.
Après quoi ils enchaînent sur une comparaison du modèle mémoire de Java et d'Erlang pour la synchronisation des threads...

Et après, on vient me dire que je suis un "geek" ?

La présentation d'OSGi était plus qu'aléchante : plus de problèmes de classloaders (voir commons-logging ou xerces sous WebSphere 5...), possibilité de mise à jour a chaud, de reconfiguration, séparation explicite de la partie "publique" d'un module et de son implémentation...

La plateforme OSGi est disponible depuis longtemps puisqu'Eclipse est basé dessus, aussi ça fait un peu mal au coeur de penser qu'on galère avec les déploiements JEE. L'équipe de Spring a fait un travail impressionnant pour mettre en place un modèle "POJO" sur OSGi :

• Codage totalement indépendant de l'API OSGi -> test unitaires simples
• Support complet pour les tests d'intégration (déploiement d'un vrai conteneur OSGi)
• Toute une série de à utiliser dans le contexte Spring pour accéder aux autres modules, comme à n'importe quel autre bean, sans aucun changement dans le code.

Ca donne vraiment envie... il y a cet AM une présentation "pratique" sur l'écriture d'une appli OSGi s'exécutant sur un serveur d'application.

Les développeurs de Spring n'aiment définitivement pas maven. Il faut dire que leur code doit être compilé à la fois pour Java 1.4, Java5 et Java6, avec de multiples rafinements. Ce n'est tout simplement pas possible actuellement avec maven !

Leur argument principal : sur un petit projet, maven peut proposer des conventions bien pratiques, mais dés que les choses se compliquent, le volume du fichier XML explose.

Par ailleurs, il préfèrent largement ivy pour la gestion des dépendances, car ses méta-données sont d'une bien meilleure qualité, et évitent bien des déboires.

Ils préfèrent InteliJ IDEA à Eclipse, car sa gestion des fichiers source de tout type est bien mieux intégrée : le renommage d'une classe met à jour tous les fichiers XML ou properties. On peut faire du refactoring dans les JSP, pages HTML, CSS... quelque chose qui n'a aucun équivalent sous Eclipse.

Enfin, ils préfèrent JIRA et BAMBOO comme infrastructure qualité. Jira est quasi-universellement utilisé sur les projets opensource (license offerte!) et particulièrement efficace. Bamboo semble beaucoup plus souple et sympa que CruiseControl ou Continuum...

Ca vaudrait peut être le coup de revoir ma "stratégie" outils, car je me casse souvent les dents sur la conf de maven, sans parler de sa non-intégration sous Eclipse !

Une citation qui résume asse bien les choses (traduction approximative) : "maven, c'est comme acheter un écran plasma HD, et une fois à la maison, on à une image en noir et blanc". Un peu dur, mais pas totalement faux...

Après les sessions de Springone, un "BOF" (table ronde) était organisé entre les "core developers" de Spring et les utilisateurs. Plein de questions sur les bons usages, les annotations, l'avenir de Spring, de JEE, la place d'Osgi face à JEE...

Pas facile à suivre avec mon piètre niveau d'anglais, mais j'ai tout de même apris plein de choses sur ce que pourrait (?) devenir le développement Java côté serveur ... enfin dès que mon client favori aura accépté de larger son vieux WebSphere 5.0 et sa JRE Java 1.3 ! Alors quand on m'annonce le support de Java 6 ou des JSP 2.1, je ne me sens pas tellement concerné.

Lors de la conférence sur l'utilisation avancée de l'AOP avec AspectJ, Chris Richardon (Mr POJO) s'est permi une question provocatrive : "un POJO avec des annotations est-il toujours un POJO ?". C'est vrai qu'un objet métier "POJO" avec des annotations Hibernate, Acegy-security et Spring n'a plus vraiment l'air "Plain Old Java" !

La réponse courte : Un POJO annoté "@Entity" signale juste ce qu'il est, pas ce qu'on doit faire avec, c'est donc tout à fait acceptable (comme @Sensible pour la classe Document par exemple).

Par contre, une annotation du type @Tracable montre ce que la classe attend, à savoir d'être logguée par un framework externe, même s'il n'est pas explicitement défini. Cela crée donc un couplage indirect qui est contraire à l'esprit POJO.

J'en ai profité pour lui poser quelques questions sur son mini-framework "arid". Celui-ci permet de définir les méthodes de recherche hibernate du genre "findByNameOrderByAge" dans une interface Dao, l'implémentation étant produite à la volée par analyse du nom de la méthode, comme c'est le cas avec Ruby-on-rails ou Grails.
D'après mes mesures sur un projet réel, 90% des "finders" Hibernate sont de type findById ou findBy. Cela pourrait donc être un réel gain de productivité.

Spring 2.0 introduisait le support d'AspectJ, spring 2.1 pousse le bouchon encore un peu plus loin. L'AOP semble arriver à complète maturité après 10 ans (!) de développement. Quelque exemples montrent que l'AOP ne se limite pas à la démarcation transactionnelle :

• Contrôle de règles d'architecture (Design Level Assertion), du genre "la couche web ne fait pas d'appel direct à hibernate ou JDBC" (ça c'est vu)
• Ajout des fonctionnalités transverses (log détaillé sur exception, monitoring, ...)
• Gestion de l'architecture (reprise sur échec, basculement à chaud...)
• Intégration au modèle...
  

Il y a probablement plein de bonnes choses à tirer de l'AOP, en particulier pour simplifier le code et éliminer les copier/coller. Il faut jute l'ajouter à la trousse à outil et y penser à chaque fois qu'un problème "transverse" est identifié.

Adrian Coyler (développeur d'ApectJ) a fait une présentation "technique", présentant les langages dynamiques (jRuby, ...) et le fameux "DuckTyping" ... sauf qu'il a une vision très originale et animée du duck-typing, à grand renfort de volailles et de clavier waterproof. Heureusement qu'ils sont plus sérieux lorsqu'ils codent chez Interface21 !

Lors de la conférence de ce matin, le staff dirigeant d'Interface21 était assis sur la rangée de sièges juste devant moi : 5 portables ouverts sur les genoux pour préparer l'annonce officielle de certification de Spring par IBM sur toutes les versions de Websphere (Mainframes compris).

Amusant de voir les responsables de la société qui devient incontournable animer un blog et bosser sur une chaise pliante, portable sur les genoux, au mileu d'une foule dense, et préparer une annonce stratégique. J'imagine assez mal Serge Kampf et consors dans la même posture ! Qui a parlé de culture start-up ?

Eric Evans (le papa du "Domain Driven Desing") faisait ce matin une présentation sur les stratégie de modélisation du domaine métier, et en particulier sur la reprise d'application existantes mal strucutrées.

• Option 1 : On jette et on reconstruit un code propre. Il n'a jamais vu cela fonctionner, c'est extrèmement couteux, et on a au final un code qui marche a peine aussi bien que le précédent en ayant couté le double et en étant pas plus simple à maintenir
• Option 2 : refactoring intensif. Intéressant car il ne gèle pas les évolutions de l'existant, mais potentiellement très imparfait, et surtout pas visible en terme de retour sur investissement (le fameux "qui paye pour ça ?".
  
• Option 3 : le "hack" du code existant pour venir piocher le "core model". Pas vraiment très satisfaisant
• Option 4 : dédier un modèle à chaque contexte, et créer des couches de médiation. Ca rejoint un peu la problématique SOA (transformation des données XML d'un système à l'autre).
  

D'après lui c'est LA solution fiable, à condition d'accepter deux points :

1. Une application ne peut pas être totalement propre
2. Il n'y a pas un modèle, mais N modèles associés à N contextes

Je reste convaincu par le refactoring, mais il faut bien reconnaître qu'il a ses limites sur du code vraiment très volumineux ou totalement monolithique.

La première soirée de Springone est consacrée à une rencontre informelle avec l'équipe de développement de Spring au complet. BEA fournit la tireuse pour la biere (belge), Oracle les petits fours, et l'ambiance chauffe assez vite.
Mon niveau d'anglais montre vite ses limites dans le bruit ambiant et l'allégresse générale, mais j'ai tout de même eu quelques discutions intéressantes sur les méthode de travail préconisées par Interface21 et sur les moyens d'améliorer la productivité.

Après une bonne nuit de repos, on remet ça ce soir, mais de manière plus formelle cette fois lors des Birds Of a Feather (table ronde), et probablement plus facile à suivre.

Après le fichier XML en pagaille, on voit fleurir le annotation à tout faire. ApectJ, Hibernate, JPA, Spring, EJB3, ... n'en jettez plus !

Le code source risque de devenir rapidement un foutoir d'annotations. Pourtant il est vrai qu'il est plus naturel de déclaré qu'une référence à la datasource est @Autowired (injectée automatiquement par Spring) que d'aller chercher le bon fichier XML pour l'éditer...

Il faudra apprendre a trouver le juste équilibre. Lors de la conférence sur JPA (persistence des données) le présentateur à clairement différencié les méta-données modèle (tel attribut est la clé primaire, tel autre une FK) qu'il aime déclarer comme annotations et les méta-données de persistance (tel attribut correspond à telle colonne en base) qu'il préfère laisser dans le XML, ne serait-ce que pour se laisser la liberté d'avoir plusieurs bases pour un même modèle.

"Plain Old Java Object", soit "à mort les EJB!" et retour à la programmation orientée objet.
Un coup d'oeil à notre code : des classes "métier" vides et des "services" de milliers de lignes.

Une démo de refactoring complet migrant d'un vilain "transactional script" vers un tout beau modèle OO démontre que ce n'est pas une fatalité et qu'il y a toujours moyen d'améliorer le code. Quand au coût de cette pratique

1. L'appoche étant incrémentale (refactoring sans aucun impact fonctionnel) on peut investir dessus par petites touches
2. Un code léger et lisible est évolutif, donc moins couteux a maintenir, mais surtout plus lisible. Combien coute de devoir maintenir un "expert" historique du projet juste parce qu'on ne comprend rien au code en place ?

Ca fait partie des choses "à mettre en place dés lundi matin"...

Spring a démontré la force de son modèle POJO dans la simplification des developpements, ainsi que ses qualités techniques. les éditeurs suivent en force:

• Bea Welogic 10 est basé sur spring 2.0 en interne
• IBM certifie Spring sur Websphere, et en particulier sur ces mainframes zOs
  
• Oracle propose une intégration avancée dans son serveur OC4J
• etc...

Interface21 (qui développe Spring) a reçu un investissement de 10 Mon $ pour assurer son développement. La conférence d'introduction de Springone a porté sur l'utilisation de cette somme, et pour rassurer sur le maintien de l'orientation opensource + simplification des devs java. L'équipe support se renforce (ils proposent même un contrat de support avec pénalités !), une équipe commerciale dédiée est montée pour ne pas gèner les "core developers", et 9 personnes sont maintenant dédiées à plein temps sur le développement de Spring (dont 5 sur la partie web).

Et ce ne sont pas les idées qui leur manque. Au dernières nouvelles :

• L'utilisation des annotations à la place des fichiers XML (on peut utiliser les deux) pour simplifier la conf
• Le pojet spring-batch (en collaboration avec Accenture) pour l'écriture de batchs Java de qualité, facilement reconfigurables (exécution en parallèle, ...)
  

J'ai pu discuter avec un "core developer" de spring sur un sujet qui lui a chatouillé les neurones : comment effectue des tests fonctionnels (tests d'interface web) reproductibles sur une application qui dépend au niveau métier d'un serveur distante (MQ, Tuxedo, ...) ?

Le problème : comment contrôller

1. que l'infrastructure est en place (queues MQ, simulateurs configurés...)
2. que le simulateur effectue le traitement exact prévu par le test

le tout sans se prendre la tête avec 2 tones de conf et de frameworks...

Une idée : l'application est lancée en utilisant la classe de test elle-même comme objet "mock" à la place de l'invocation du serveur distant. Le code de test est alors à la fois dans la JVM de l'application web (comme simulateur du service) et dans la JVM qui pilote le test. L'écriture du test est donc très simple et à la portée d'un "junior developer".

Il suffit alors de prévoir dans le "setup" du test de contrôler le serveur pour le faire utiliser la classe de test comme simulateur du service, chose qui n'est pas très compliquée par JMX interposé. Reste a package cette partie pour que n'apparaisse que le strict minimum aux développeurs et pas tous les rafinements techniques que nous aimons tous...

Bref, ça commence dur cette édition 2007 de Springone ! J'espère qu'ils auront encore tout plein de bonnes idées à me passer.

Après ma visite l'année dernière che nos voisins belges pour la première de Spring'one, je récidive avec l'édition 2007. Le programme est chargé (3 jours de conférences en 3 sessions parallèles). Je vais particulièrement m'attarder sur les points suivants :

• utilisation de la programmation orientée aspect (AOP). Nous l'utilisons de manière triviale pour le transactionnel, mais on peut faire bien plus de choses...
• intégration avec les "nouveaux" outils web - google web toolkit en tête
• programmation d'un modèle objet riche, dans l'esprit "Domain Driven Design". Tous les projets sur lesquels j'ai travaillé restent enracinés dans une appoche "services" avec des gros pavés de code, et un modèle qui sert juste de boi-boites à données. Du coup, ou est la structuration objet ?
• et probablement, plen de surprises que je n'anticipe pas...