J’aurai le plaisir avec mon collègue Philippe Guicheney de présenter une session sur l’intégration continue intitulée « Les nouveaux défis de l’intégration continue« . Nous aborderons … scrouitchhhhhhhhhhhhhhhhhhhh … désolé, il vous faudra venir pour en savoir plus

Au programme :

• Usabilité (ergonomie vs productivité ?, ergonomie et agilité, paper prototyping, l’iphone, tests d’IHM)
• Méthodologies (Boite à outils du manager, MOA et agilité)
• Technologies (Google, le cloud, les serveurs d’app, les tests, groovy, rails…)
• Gouvernance (Gestion de l’identité, SI multi-entités, …)

Le programme complet est ici.

Bonne USI.

Je ne vais pas m’étendre sur la première partie présentée par Erwan Alliaume et Cyrille Le Clerc de Xebia ainsi que Jean-Michel Bea de FastConnect, le touilleur a encore une fois fait un bon résumé. La session était dense mais très intéressante.

Javarebel

Je vais m’attarder un peu plus sur la deuxième partie (qui n’a duré qu’une demi heure) dont le sujet me correspond plus : la productivité des développements avec JavaRebel. C’est Toomas Römer de ZeroTurnaround qui nous présente l’outil.

La démo de l’outil est toujours aussi bluffante (dispo ici et là), d’autant que pressé par le temps, Toomas l’a déroulé assez vite, ajoutant du punch à la démo :

• Modification d’une jsp => rafraichissement instantané de la page web
• Modification d’un validator => rafraichissement instantané de la page web
• Ajout de méthode, de paramètres => rafraichissement instantané de la page web
• Ajout d’un bean spring et d’une jsp => rafraichissement instantané de la page web

Aucun repackaging, aucun redéploiement, aucune perte de temps ! C’est l’objectif de Javarebel : éviter de devoir recompiler, retester, repackager et surtout redéployer l’application à chaque modification du code.

La démo nous laisse à penser : « mais comment j’arrive à supporter mes builds Maven de plusieurs minutes ? » Probablement parce qu’on n’a pas goûté à ce plaisir…

A la fin de la session, on a le droit à une question intéressante qui est de savoir s’il (Toomas ndlr) n’avait pas peur que les développeurs ne prennent plus le temps de réfléchir à leur code (modélisation, archi…) mais se contentent de coder / tester / coder… pour se rendre compte au bout de plusieurs heures que leur code n’est pas bon. Ce à quoi Toomas a répondu que l’outil était là pour éviter de perdre du temps au redéploiement (10 minutes par ci, 10 minutes par là) et ne devait pas changer la manière dont travaillent les développeurs. Et Antonio d’ajouter qu’on ne pourrait plus prendre autant de pauses cafés !

A l’issue de la présentation, en discutant avec Erwan (qui avait blogué sur le sujet), il s’avère que l’outil n’est pas tout à fait aussi magique, tou au mions pas tout le temps. Notamment sur un gros projet, Javarebel rame et finit même par planter. Je présume qu’il doit bien s’appliquer sur des appli webs relativement simples.

En tout cas je suis persuadé que la démo plus quelques chiffres pourraient convaincre quelques managers de l’intérêt de l’outil.
Pensez donc : 10 développeurs qui redéploiement environ 10 fois par jours au prix de 5 minutes à chaque fois (maven + serveur d’app) : 500 minutes (8h), soit 1j.h perdu par jour ! Au regard du prix de la license (150 $ pour une entreprise), ca donne à réfléchir !

Si vous étiez au fin fond de l’Amazonie ou dans le Larzac ce 11 novembre, vous avez une excuse pour avoir loupé le rachat de G2One par SpringSource. Effectivement, nombreuses sont les annonces de ce rachat :

• L’annonce de SpringSource
• Le communiqué de presse
• Le post de Rod Johnson, créateur de Spring
• Le post de Guillaume Laforge, cofondateur de G2One et project manager de Groovy
• Le post de Graeme Rocher, cofondateur de G2One et project leader de Grails
• Valtech
• Le touilleur
• TSS
• Developpez.com
• Infoworld
• Pcworld
• et certainement beaucoup d’autres…

Sachant que Grails est déjà basé sur Spring, on ne peut que supposer un renforcement de ce duo et pourquoi pas la simplification de Spring MVC ? Concernant Groovy, nous verrons probablement apparaître un lien avec Spring Batch, afin de simplifier encore l’écriture de batchs… l’avenir nous le dira mais Spring continue son bonhomme de chemin.

Qui sera le prochain ? Personnellement, je verrai bien un framework Ajax (javascript & widgets) pour parfaire un peu nos interfaces (http://grails.org/Ajax ?).

En tout cas, félicitations à G2One (et à Guillaume, que je salue) qui en moins d’un an a réussi à se faire racheter par un gros poisson. À demain aux Rencontres Spring pour de nouvelles news !