13 mars 2009

Grails rocks !

Sur mon projet actuel, d'une taille assez colossale, tout (et même le reste) est configurable, si bien qu'il faut une appli de gestion de la conf qui à elle toute seule est déjà une belle appli web.

Les données de configuration qui sont manipulées sont des entités JPA manipulées ailleurs. J'ai donc fait un essai du côté de Grails, que je n'avais fait qu'éffleurer précédement sans rentrer dans le vif du sujet. En quelques heures, j'ai une appli fonctionnelle pour gérer mes données JPA !

Grails permet de définir son modèle en Groovy mais s'accomode très bien d'un modèle "legacy". Les metadonnées Grails (selon une syntaxe de closure Groovy très compactes) peuvent en effet être déportées dans des classes compagnon suffixées "Constraints". Ma belle entité JPA Habilitation peut donc rester 100% java (Groovy fait encore un peu "geek") sans m'interdire de l'utiliser dans une belle application Grails.

Groovy fait son chemin dans le monde professionnel. Les IDE le supportent de mieux en mieux (même Eclipse s'y met, c'est dire :p), les frameworks et plugins pour Grails se multiplient. Reste à le rendre "acceptable" pour nos décideurs ... et paradoxalement ce n'est pas le plus facile. J'ai donc une astuce : plutôt que de coder en Groovy mon application JEE ultra-stratégique holala faut surtout pas prendre de risque avec un truc de geek, j'intégre le support de la JSR 241. C'est la même chose, je sais, mais bizarement ça ne sonne pas pareil ;)

12 mars 2009

A quoi bon ?

Dans le milieu des "architectes Java" on se targe d'appliquer des patterns, de structurer des architectures et d'offrir des applications flexibles, maintenables et évolutives.

Mais dans la vraie vie, ça donne quoi ? 

Des concepts abstraits qui perturbent les nouveaux arrivants, de longues heures de formation sur les design pattenrs qui ne laissent que bien peu de traces dans le code produit, un joli tas de voeux pieux qui n'aboutit à rien de concret, et une belle architecture, plus ou moins bien appliquée, mise à mal au moindre bug un peu bloquant qu'il faut corriger en urgence.

Alors à quoi bon. Après tout, du bon vieux code "Plain Old Spaghetti Code" (POSC, à ne pas confondre avec le code de PORC)  est-il vraiment si terrible ? De toute façon, d'ici six mois les besoins auront tellement évolués qu'il faudra tout reprendre et que notre magnifique "modèle objet du domaine" sera bon pour la casse - pardon, pour le "refactoring massif". D'ici un an, deux armées de stagiaires seront passées sur le code et auront massacré votre beau modèle en couche faute d'en comprendre les raffinements si subtils. D'ici deux ans, votre magnifique framework de [mettez-ici-le-pattern-que-vous-voulez] sera totalement obsolète. Alors pourquoi se tirer une balle dans le pied ?

Qu'est ce qu'on trouve à pas cher sur le marché ? Des gens pas très expérimentés qui rivalisent difficilement avec leur homologues indiens. Combien celà coute t-il d'en faire des experts à même de comprendre nos architectures hautement modulaires ? Quel bénéfice au final ?

Pourquoi ne pas considérer officiellement le modèle du code kleenex ? Tout pourri, mal ficelé, à peine fonctionnel, mais ça coute de toute façon moins cher de le refaire "from scratch" à bas cout d'ici deux ans que de le maintenir en l'état.

Quelle valeur ajoutée réelle pour nos belles usines à logiciel, toutes automatisées et bardées de contrôle qualité, si personne n'est au commandes ?

Bref je suis de plus en plus dubitatif. D'un côté je voudrais encore y croire, d'un autre côté la réalité est tellement loin de ce beau modèle de développement que je commence à voir venir le sciècle du "code discount" : pas cher, pas terrible, mais pas cher. 

Il me reste donc à aller élever des chêvres dans le Larzac ...

08 mars 2009

Des bugs partout !


Ce week-end j'organisais un "apéro Wii". On m'a donc gentillement prêté deux WiiMotes et un Wii Fit, et bien sur les jeux qui vont avec.

Après les 25 écrans de baratin du jeu Wii Fit on peut enfin faire deux trois mini-jeux rigolos. Autant le capteur est une originalité intéressante pour l'interaction, autant les jeux associés manquent cruellement de "fini". Je veux bien croire que la Wii n'a pas les possibilités 3D d'une PS3 mais tout de même...

Quand à Wii Play... à réserver au plus jeunes qui ont du mal à se servir de la WiiMote. Jeux basiques et graphismes à la limite de l'amateurisme.

A croire que Nintendo ne veut pas mettre la barre trop haut pour ne pas dégouter les développeurs ;p

Restait heureusement les lapins crétins pour me sauver la mise. Evidement, ce n'est pas le même public, mais le style comique et décallé du jeu donne à l'ensemble un style caractéristique bien agréable, très loin de l'aspect "c'est offert avec alors n'en demandez pas trop" des jeux Wii-* d'origine de la console.

Je me suis donc vengé en enchainant les mini-jeux des lapins crétins - les enfants aiment bien voir leur papa se trémousser en rythme devant son écran - avant de tomber sur l'impensable : un bug.

Dans le jeu des "radios sur la plage", on doit cogner sur les lapins (les règles sont assez simple) mais bizarement au bout d'un moment on a beau s'exploser le bras rien ne bouge. Il s'avère que c'est un bug qu'on peut corriger en configurant la Wii sur 60Hz :-/ Mais avant de découvrir ça on passe par une sacré suée à s'énnerver sur sa WiiMote.

Terrible pour un informaticien de voir que les bugs nous poursuivent même en week-end... est-ce que le code des lapins crétins est en opensource ? :D