new Blog( perso );

Seconde étape de la tournée bretonne Agile Tour, Vannes !
L'organisatrice a du passer quelques mauvaises nuits en cumulant une première sur cet évènement avec des grèves SNCF et les menaces de pénurie de carburant. Cependant, tous les speakers ont répondu présent à cette édition qui fut un grand succès.

Les thèmes abordés, sur 4 sessions simultanées, permettait à chacun de trouver son compte dans un large choix de sujets. Pour ma part, j'ai assisté ...

à une présentation de l'Holacracy, condensé de pratiques innovantes pour l'organisation d'une entreprise. Le principe clé est de comparer l'entreprise à un organisme vivant : chaque cellule à sa propre identité et un degré de liberté, mais elle participe à un organe, qui participe au fonctionnement global et inconscient du corps, qui lui même joue un rôle dans une société. Les fondamentaux du modèle hiérarchiques sont conservés, mais épaulés de nombreux mécanismes de feedback, d'équilibrage et d'autonomie à chaque niveau. La conférence a été perturbée par des réactions assez épidermiques lorsqu'on remet en cause les rôles bien établis de chacun dans l'organigramme de l'entreprise, comme quoi le refus du changement est présent partout, même sur l'Agile Tour ;).

à une démonstration de la table interactive "Surface" de Microsoft, très sympa pour la gestion de projet : vos post-its de tâche, bien que dématérialisés, restent quasiment des objets physiques manipulés à la main. Prochaine étape pour Microsoft : LigthSpace, qui utilise une simple projection et une détection de mouvement (même techno que sur la console X-Box ?). A n'en pas douter avec cette variante bien plus légère et riche en interactions, notre façon de travailler avec les outils de planification et de communication va évoluer à vitesse grand V. Démo est infos ici


à une présentation sur la place de l'architecture en agilité. Pour rompre avec la légende qui veut que l'architecture ne puisse pas rentrer dans un mode agile, itératif et incrémental, mais doit se faire en amont, jean-philippe gouigoux nous met en face d'une application développée en eXtrem Programming et applique au pied de la lettre les concepts de simplicité, test-driven et refactoring. D'un bout de code naïf on aboutit rapidement à une structure claire, élégante, sans redondance, et facilement extensible, c'est l'architecture émergente. La difficulté de cet exercice est de bien clarifier la notion de "simple" : simple à lire pour le novice qui connait mal les astuces du langage ? simple à lire en proposant à une personne du métier quelques classes qui résument tout son problème, en isolant les détails techniques ailleurs ?

Je n'ai pas pu assister aux autres sessions, dont le Coding Dojo TDD qui m'aurait bien tenté, car je participais à l'enregistrement des CastCodeurs #29, avec quelques difficultés techniques pour obtenir une liaison skype fiable ;)

En conclusion, une excellente journée, avec des rencontres enrichissantes et des sujets très variés. Si vous avez (encore?) raté l'AgileTour, il vous reste une séance de rattrapage à Nantes Jeudi 21 !

Tout est dans le titre,
Après des mois (des années) à attendre Maven "2.1", finalement renommé Maven 3, de nombreux (re)développements et une interminable suite de tests de non-régression, voici enfin venu le renouveau de Maven.

Quel changements pour l'utilisateur ? Aucun ou presque - à part un build plus rapide et moins consommateur de mémoire - car le premier objectif de Maven 3 est d'être compatible (à quelques détails près) avec son prédécesseur. Par contre, le socle technique est autrement plus propice à de futures évolutions, et à son intégration dans d'autres outils comme en témoignent polyglot, tycho, mvnShell ou m2eclipse, et les premiers plugins hudson maven3.

Le meilleur est à venir.

Pour sa seconde édition Rennaise, l'Agile Tour remporte un énorme succès, avec 200 inscrits (le max) et de nombreuses propositions de sujets. Il faut reconnaître que pour 20€ (contribution casse-croûte) c'est un évènement à ne pas manquer !

Après l'introduction, les sessions se répartissaient dans 4 salles, dont deux orientées ateliers. J'ai eu le plaisir d'ouvrir le feu, avec un public nombreux et de bonnes questions : l'interaction du public sur cette conférence est très bonne.

Entre autres sessions, j'ai beaucoup aimé celle de Sébastien Tanguy "Scrum vs XP (charue et boeufs)". Sébastien y a souligné la grande popularité de Scrum, orienté rôle, communication et processus, et son absence de solutions pour les dérives qu'il permet de constater dans la dégradation de la vélocité. XP est donc un complément indispensable pour l'agilité, et la conférence a permis de faire le point sur 4 pratiques XP, le TDD, le refactoring, le pair-programming et l'intégration continue. Détail notable : Sébastien a fait le lien avec des sessions de l'Agile Tour 2009 et celles proposés sur cette édition - dont la mienne ;) - ce qui est un point très positif pour les choix éditoriaux des organisateurs. Les références incontournables à Uncle Bob n'ont pas manquées, même si Sébastien a choisi de se limiter aux plus softs.

Pages Jaunes faisait un retour d'expérience sur son passage au tout agile pour sortir d'un "Time To Market" bien trop long. Ils sont passés de 12 à 4 mois, avec 10 versions mises en production par an - excusez du peu. De leur propre aveux, leur approche est encore perfectible et il manque des briques importantes dans l'outillage du projet pour soutenir efficacement le processus. Le secret de leur succès : impliquer tous les maillons de la chaîne, avec une généralisation des KanBan de l'expression de besoin marketing à la phase de maintenance. Un sujet particulièrement pointé du doigt est la difficulté de marier maintenance et développement, soit avec une équipe dédiée, soit en intégrant des tâches de maintenance. Les deux approches ont des défauts significatifs qui va obliger pagesjaunes à expérimenter d'autres organisations.

J'ai aussi suivi l'atelier rétrospective pendant lequel je me suis retrouvé transformé en Renne gréviste du père noël. Ce format atelier est très intéressant pour comprendre les processus de travail en équipe et les techniques proposées par l'agilité. Dans le cadre de la rétrospective, comment amener chaque participant à identifier les éléments positifs et négatifs et à envisager ensemble des axes d'amélioration de l'équipe, loin des règlements de compte et du classement dans l'armoire IQ d'un bilan de projet "traditionnel".

J'ai aussi suivi une conférence plus "outil" sur la mise en place de tests d'acceptance avec Concordion. Mis en place sur un projet wrokflow délicat à valider avant la recette, et qui faisait l'objet de nombreuses versions correctives, il a fallu 6 mois de lobbying pour passer du premier PoC à la généralisation, mais le succès est au rendez-vous et l'outil s'est progressivement propagé dans d'autres domaines du SI. Si le coût de maintenance des tests et des "fixtures" n'est pas nié, il s'avère "linéaire" en fonction des évolutions fonctionnelle, ce qui est un avantage majeur par rapport à une approche plus bas-niveau à base de jUnit.

Sans compter toutes les autres sessions pour lesquelles je n'ai pas pris de notes ou que je n'ai pas pu suivre, l'AgileTour Rennes 2010 était donc une réussite incontestable, avec une excellente ambiance et de très bons échanges entre participants. Si vous avez raté cet évènement,  il y a des dates programmés dans de nombreuses villes françaises dans les semaines à venir.

Comme de bons petit soldats, nous avons appris à définir nos attributs de classe en private et à générer des getter/setter pour y accéder. Nos classes se trouvent ainsi encombrées de ces méthodes sans grand intérêt. Après tout, pourquoi ne pas laisser nos attributs publics ? Pour l'encapsulation vous répondra maître Yoda, en ayant la possibilité (s'il le faut un jour) d'intervenir lors d'un accès aux données de la classe. OK, mais c'est bien dommage de polluer ainsi notre code :'(

On peut bien sûr utiliser exceptionnellement une syntaxe compacte, mais encore faut-il que le formateur de code et les règles Checkstyle de votre Q&A soient réglées en conséquence.

Des langages comme Groovy ou Scala disposent nativement du concept de propriété, qui permet d'intercepter les accès aux données de la classe via un getter/setter, mais seulement quand c'est nécessaire. Pour Java 7, le projet Coin proposait d'ajouter le concept de propriété dans le langage Java. Le sujet a fait débat et je ne suis même pas sur du statut de cette proposition.

Cependant, pour ceux qui aiment bien cette idée, il y a une alternative à attendre cette fonctionnalité dans Java 7 (ou 8 ? ou 9 ?) : lombok

Lombok utilise un hack de l'annotation processor de Java 6 : il vient modifier la structure du code source (la structure AST, pas le fichier .java) pour ajouter des getter et setter à chaque attribut annoté en conséquence. Votre .class comporte donc bien ces méthodes et votre IDE vous laissera les utiliser, mais elles resteront absentes du code source, tant que vous n'avez pas besoin de les définir vous même. Lombok peut faire même beaucoup plus, comme générer equals(), hashcode() et toString(), ou gérer les exceptions ou la synchronisation par simple apposition d'une annotation (dites "méta-programmation", ça fait plus classe). Si cette dernière option peut faire peur - mais rappeler vous la première fois que vous avez fait du spring-aop avec @Transactional - l'utilisation sur les getter/setter justifie l'outil à elle seule.

A tester d'urgence : http://projectlombok.org

Premiers retours sur ma migration sous Mac ...

Le hard
La machine est particulièrement bien finie, avec son habillage aluminium on est loin de certains PC en mauvais plastique. Le clavier typique, aux touches plates et carrées, rappelle celui du minitel, mais est pourtant très confortable. Par contre, les petits cachottiers d'Apple ont caché les touches utiles (pour un développeur) derrières des combinaisons : pas d'indication sur l'accolade "{" à moins d'avoir le petit guide du Mac-iste sous les yeux. Le pad est large et réactif, et on s'y fait très vite. Je le trouve par contre plutôt dur au clic, et je n'aime pas non plus le mode "frappe" pour cliquer.

L'OS
MacOS est basé sur un coeur FreeBSD, et a été fortement optimisé pour la plateforme 64 bits multi-coeurs. Je ne sais pas si c'est la seule explication, mais je constate que l'OS est très réactif et réparti très bien les ressources entre process. Je ne constate aucun de ces "gels" si fréquents sous Windows lorsqu'on lance une grosse appli (genre, un document Word :P ). L'installation d'application est simple comme bonjour (glisser, déposer), et a priori la désinstallation tout aussi triviale et propre. Je ne parle pas de l'esthétique qui est un élément pour lequel on connait le soin d'Apple.

Les applications
Le Mac est livré avec tout un tas d'applications de bonne facture, qu'on complétera avec quelques outils complémentaires selon le travail qu'on désire réaliser. Je regrette qu'iWork ne soit pas packagé. Il ne coûte que 79€ et serait un argument pour un système "tout compris", mais il n'y a pas de petit profit chez Apple, comme en témoigne le prix des accessoires, ou la sortie mini DisplayPort, qui oblige à acheter un adaptateur, alors qu'un port HDMI ou DVI ferait le job (mais nécessiterait à Appel de reverser 4cts par Mac !)

On s'habitue assez vite à la disposition du clavier et au pad (le passage régulier du Mac au PC est assez perturbant, on fait des trucs bizarres pendant quelques minutes). Pour ma part, je n'ai pas rencontré de problèmes insoluble, surtout avec l'aide du support en ligne 24/24 : @aheriter et @jollivetc !

Le côté obscur
MacOS est donc basé sur un socle Unix-BSD. C'est aussi ce qui en fait l'intérêt pour les développeurs ! Le passage de la barrière est cependant assez net. La console bash utilise les raccourcis propres à ce terminal, à savoir [Esc + B] pour revenir un mot en arrière. Ca rappelle l'apprentissage douloureux de VI, mais après tout c'est aussi un garde fou pour ceux qui ne devraient pas s'aventurer au delà de la partie graphique. Rassurez-vous, on peut définir ses propres combinaisons de touches pour améliorer la convivialité de cette console.

En conclusion, après quelques jours d'utilisation, je m'habitue bien à la bête et j'ai contourné les principales difficultés. Je ne suis pas encore aussi efficace que sous Windows et je me goure encore souvent de combinaisons de touches, mais ça vient vite. De là à savoir si ça justifie le tarif de ce jouet, je vous le dirait dans un prochain biller. Prochaine étape : intégrer le Mac dans mon environnement de travail (Exchange, Office Communicator, etc) et l'utiliser au quotidien...

Et bien voilà, j'ai franchi le pas et je viens de commander un MacBook Pro sur l'appleStore. Avec les -16% que j'ai obtenu sur le refurb, cela amènent la bête à à peine le double de ce que j'étais prêt à mettre dans un portable, soit 1700€ :-/ Si on ne rate pas l'heure des annonces du jour, le refurb est une bonne adresse pour avoir des machines à un prix moins déraisonnable.

Pour la petite histoire, j'ai craqué pour un 15" i5 2,53GHz avec écran Hi-Res anti-reflet. En ayant eu celui d'Arnaud sous le nez au ParisJug, le choix de la dalle était non négociable. Mais rassurez-vous, il me restera toujours mon super Dell Low-Res @boulot pour me rappeler ce que c'est que de programmer pour les gens normaux ;)

Réflexion comme ça au détour d'un article sur la cryptographie quantique (dossier de pour la science de cet été) :

L'autorisation d'utiliser un système de cryptage est soumis à diverses autorisations, généralement liées à la possibilité des états d'accéder en cas de besoin aux données. En france, le cryptage avec une clé de plus de 128 bits est ainsi autorisé sous réserve que le logiciel soit déclaré (mais il y a plusieurs décrets sur le sujet, je ne suis sans doute pas très à jour). Aux US, les oreilles de la NSA ne sont un secret pour personne.

Vous vous souvenez peut-être avoir répondu à un questionnaire étonnant lors du téléchargement de JCE (Java Cryptography Extensions), vous demandant si vous résidiez en Afghanistan ou un pays hostile aux Etats-Unis. Ca fait sourire mais ça résume bien l'importance des mécanismes juridiques en place pour être en mesure de surveiller les activités numériques.

Quid de l'information quantique ? Le jour ou l'Internet commencera à proposer des liens sécurisés quantiques (et ça ne va pas tarder, les premières expérimentations se font déjà sur quelques kilomètres), les états ne vont-il pas réclamer leur droit à l'écoute pour toutes les bonnes raisons que la sécurité nationale peut invoquer ? Et là point de salut : un flux crypté quantiquement est ... définitivement inviolable.

Le jeu de la cryptographie quantique est de "déléguer" la sécurité à un système physique inviolable par nature, et non à un algorithme "compliqué" qui nécessite des puissances de calcul inaccessible au commun des mortels - mais pas aux états. Un échange sécurisé par l'algorithme BB84 est totalement inviolable, à savoir que la présence d'une écoute est détectée sans contournement possible. L'information ne peut être copiée ou écoutée sans casser le lien et dénoncer l'espion. Même 007 n'y peut rien.

Si la NSA n'en est pas encore à revendre ses serveurs sur eBay, je m'interroge sur l'opportunité réelle de ces technologies émergentes et suivies de très très près par tous les investisseurs du domaine. Je doute que les US autorisent l'export hors de leur territoire d'une technologie sur laquelle ils n'auront pas de moyen de contrôle (d'où l'importance d'avoir des labos de recherches en Europe ;P ).

Si on est encore loin d'avoir des qBit sous le capot, la révolution quantique va changer la donne dans pas mal de domaines de l'informatique. Déjà qu'on a du mal à coder pour des multi-coeurs, ça va donner :-/

Lors de ma conférence au JugSummerCamp Emmanuel Bernard a soulevé une question pleine de bon sens :

C'est clair que Git est pénalisé par l'image de Geek qui lui colle à la peau : construit par Linus Torvald, utilisant la ligne de commande avec des options tortueuses, ...

FlashBack :

Quand j'ai commencé à bosser, on attaquait tous en telnet un serveur de dev, sur lequel code source et résultat de compilation était allègrement mélangés dans des répertoire ou tout le monde tapait son code sous vi/emacs, sans plus de gestion de version en dehors de la sauvegarde hebdomadaire sur bande.

Quelques années plus tard, première révolution avec Visual Age et son gestionnaire de version centralisé, basé sur la prise de verrous sur les fichiers. On entre dans un mode de concurrence et de gestion collaborative, où chacun dispose d'une copie de travail dédiée sur son poste de développement.

Plus tard, seconde révolution avec CVS puis SVN : l'absence de verrous permet de travailler sans "subir" les actions en cours des autres développeurs. La problématique des merge apparaît, mais l'outil est tout de même assez efficace pour les gérer, en particulier sous Eclipse qui devient notre environnement quotidien.

Aujourd'hui, les DVCS portent une nouvelle révolution : la séparation du workflow projet et de celui du développeur. Le travail local, basé sur des tentatives multiples, des retours arrière, des recherches dans l'historique, bénéficie pleinement d'un gestionnaire de version. Pour autant, le reste de l'équipe ne subit pas vos diverses branches et commits en tout genre. Le merge de branche devient étonnement efficace, le mot "branche" n'est plus synonyme de "galère".

Il ne fait aucun doute pour moi que les DVCS vont s'imposer, alors to Git or not to Git ?

D'une part, Git est nativement supporté dans Eclipse (bien que ce soit encore améliorable) ce qui devrait faciliter les choses. Les outils graphiques comme TortoiseGit facilitent aussi son utilisation. La ligne de commande reste le plus efficace, mais avec le temps et le murissement de ces outils, on devrait pouvoir s'en passer progressivement (enfin, pour ceux qui veulent).

Reste que les concepts sont encore neufs et qu'il va falloir ses les approprier. Pour ça il faut des précurseurs, qui porteront ainsi le reste de l'équipe et assureront le support de niveau 1 - et Git-svn va nous y aider.

Git-svn permet d'utiliser Git en local avec tous les avantages que cela implique, sans que la référence svn soit impactée. Ceux qui doivent effectuer des opérations non triviales (refacotring), ou bien passer souvent d'une tâche  à l'autre (corrections de bugs), ou encore qui ont une culture geek pourront le tester, l'apprivoiser, puis l'adopter. Contrairement aux autres "révolutions" que j'ai évoqué, celle-ci va se faire en douceur. Une fois que  l'équipe aura utilisé au moins une fois Git sur son poste, le remplacement de SVN sera naturel.

Après tout, il y a 13 ans (putain, 13 ans !) si j'avais parlé de faire une branche alors qu'on avait besoin d'éditer avec vi un même fichier depuis notre telnet, je serais passé pour un geek (en fait, c'était déjà le cas pour d'autres raisons). Je me rappelle aussi une discussion interminable avec un I.Q. lors du passage à CVS, lorsque j'expliquais qu'on travaillait à plusieurs sur le même fichier, sans mécanisme de verrou ...

Aucun DSI n'imposera Git à ses équipes, par contre les équipes qui y ont goûté le réclameront rapidement. Il y aura donc, comme toujours, les boîtes qui savent suivre le mouvement à temps et celles qui courent derrière le train. C'est aussi à toi, fidèle lecteur, de faire du lobbying, selon la catégorie dans laquelle tu veut entrer. Fais toi la main, parles en et montre le à tes collègues, râle un bon coup sur SVN, et le projet "pilote" pointera le bout de son nez.

En tant que JUG-Leader je suis confronté à un cas de conscience : j'ai des tonnes d'idées, mais pas assez de temps pour tout faire. En particulier, l'organisation de "grosses" soirées-conférence me bouffe la majorité de mon temps. Il existe pourtant une autre dimension dans un JUG : l'aspect communautaire, celui qui nous pousse à donner de notre temps pour recevoir autant sinon plus de la part des autres membres.

Au détour d'un ParisJug j'ai rencontré les JavaDuchess. Comme probablement une majorité d'entre vous je ne comprenais pas bien le sens de ce groupe. Défendre le droit des femmes dans un monde machiste ?

JavaDuchess n'est pas un mouvement féministe. Bien sûr il s'agit de montrer que les femmes aussi ont leur place dans un monde technique et de couper court à toutes ces petites réflexions qu'on a tous fait un jour ou l'autre, parfois sur le ton de la plaisanterie, parfois avec moins de tact.

Pour vous expliquer ce que représente JavaDuchess, la métaphore qui me vient à l'esprit c'est la "face B" :

Quand vous achetez le best-of de Sting and The Police, vous trouvez sur le premier CD les incontournables Roxane, Russians, Message in a bottle et compagnie. Mais à côté de ce CD dont les titres ont fait le succès du groupe et qui passent encore en boucle sur toutes les ondes, il y a le second CD, les "faces B". Tous les titres qui n'ont pas été retenu pour le "gros" album, des choses plus expérimentales, plus personnelles, plus intimistes, et dans pas mal de cas des petites perles qu'on écoute avec plaisir.

Les Duchess, c'est pour moi la face B des JUGs. Ce n'est pas un Virtual JUG à la développez.com, car la convivialité est un pilier du groupe, et les rencontres 'IRL" sont le meilleur moyen de souder l'équipe. Ce n'est pas non plus un JUG au sens traditionnel car il n'a pas de lieu physique précis et elles n'organisent pas des événements come ceux auquels vous êtes habitués. Par contre, en marge du JUG il y a de nombreuses actions qui profitent à tous et permettent aux Duchess de créer des liens forts et de prendre une place dans la communauté qu'elles n'auraient jamais obtenues individuellement (vous savez, le total supérieur à la somme des parties, tout ça).

Parmi les actions des Duchess que j'apprécie, (excusez moi les filles si j'oublie des trucs) :

• Les rencontres avant/après JUG ! Convivialité, rencontre, échanges. De ce point de vue la mixité est une force pour assurer une super ambiance - hé oui, les réunions des Duchess n'est pas réservé au filles!
• Le blog. Peu de gens ont le temps et la matière pour animer un blog et s'assurer un public significatif (pour en arriver là il faut troller à mort sur Maven vs Sonatype, et encore...). Ce que ne veut pas dire qu'ils n'aient rien à dire. Le blog des duchess est "collaboratif". Chacun(e) peut y publier un billet, demander de l'aide ou une relecture. Même si vous n'êtes pas technique, juste faire un compte rendu de la dernière conf c'est déjà très bien pour animer la communauté et "se lancer".
• L'agenda, qui recense les événements et permet de savoir ce qui se passe dans le coin. Tiens, une soirée Agile ? Tiens, Julien Dubois refait sa pres' Spring en production au SUG ? Seul regret : que l'agenda ne soit pas géolocalisé pour nous offrir une vue mixant planing temporel et proximité géographique (qui se lance pour nous faire un mashup Google Maps + Google Agenda ?)
• Les groupes de travail. Pour l'instant à ma connaissance uniquement autour de la certification SCJP, mais pourquoi pas d'autres sujets ? C'est toujours plus motivant de travailler à plusieurs.
• Le "covoiturage". C'est déjà pas facile d'être la seule fille dans une assemblée de 50 mecs, alors pour se motiver à aller à une conférence de techos ... sauf si on trouve du monde pour y aller à plusieurs, des "copines" rencontrées sur le Net. Le concept ne se limite pas qu'au filles d'ailleurs : combien d'entre vous sont le seul de la boîte à aller au soirées JUG ? Combien passent pour des allumés en expliquant ce concept geekesque aux collègues - "Tu n'as pas assez de ta journée de boulot ?"

Probablement plein d'autres idées (sans compter toutes celles que j'oublie) à fleurir de ce côté. Des tas de petites choses, qui ne fonctionnement que grace au groupe, mais qui en font que la communauté Java fonctionne dans les deux sens, et pas juste un rendez-vous mensuel de conférence où l'on vient consommer sa dose de technique, puis "salut, au mois prochain".

PS : je suis désormais membre des Duchess moi aussi, si vous avez des idées pour mettre en place un truc à Rennes mais que vous avez besoin d'un coup de pouce, vous savez où me trouver.

Pour ceux qui n'auront pas pu suivre l'excellente session "Spring 3 en production" de Julien, sans doute meilleure que la mienne ;), une séance de rattrapage est organisée au Paris Spring User Group le 16 septembre  !

Un grand merci à Julien pour avoir bien voulu participer avec moi à cette petite guerre par blogs interposés :) Bien entendu, c'était une blague, comme vous pourrez également le constater.





Rendez-vous ce soir sur le port de La Rochelle pour fêter la fin de la conférence !

Le JugSummerCamp, je ne le présente plus, va vous poser un réel défit : faire un choix dans le programme entre les deux tracks de conférences.

En particulier, aux alentours de 15h ça va être très compliqué, pour choisir entre ma session "Maven 3 au coeur de la Forge Logicielle" et la présentation de Julien Dubois "Spring 3 en production" alors voici des pistes pour vous guider :

• Spring c'est complètement has been, maintenant qu'on a JavaEE 6. Plus rien dans le tuyau, passez votre chemin ;
• La session de Julien ne va pas vous apprendre grand chose vu que tout est déjà disponible dans le livre blanc publié par SpringSource ;
• Julien ne vient pas pour donner une conférence sérieuse mais juste pour retrouver tous ses anciens potes de La Rochelle, alors il n'a rien préparé à part le programme des festivités nocturnes, et ça va être un grand n'importe quoi ;
• Dans l'hypothèse où vous voudriez apprendre quelque chose sur Spring 3, il serait plus rentable de consulter le livre "Spring par la Pratique" et le site web associé ;
• Et si vous avez des questions sur Spring et la mise en production, posez les plutôt sur Responcia ça sera plus efficace.

Moralité, ne perdez pas votre temps, n'écoutez pas les balivernes de Julien et venez plutôt à ma session !

Developping gwt-maven-plugin was a pain. GWT was clearly not designed with Maven conventions in mind and we had to find many hacks and workarounds. Google Eclipse Plugin didn't made things simplier as it came with some hard-coded path and we had then to satisfy 3 conflicting points of view...

But things change

With 2.1 release, GWT Team is looking to nicelly integrate with Maven. We are in contact to see what changes could occur on GWT side to better fit into Maven. The first visible effort is a new "-maven" option in webAppCreator script to generate a maven compliant project structure and the adequate POM.

The maven plugin allready includes an archetype for same purpose. I'll upgrade it to match the webAppCreator one, with some improvements (including Google Eclipse configuration). I've sent the GWT / Google Eclipse Team a list of feature requests to make Maven / Eclipse / GWT work better together.

As a result, I expect to release a 2.1.0 preview releases of gwt-maven plugin for next GWT Milestones, so that the plugin could benefict from changes made on Google side, and the POM generated by webAppCreator could also use those new features.

I also called for a vote on Mojo Dev List to change the development process so that new release of he plugin match a GWT release, and don't support anymore all SDK history. This will make things technically simplier and will drop a large set of obsolete parameters.

Good days Maven users, GWT will become your favorite toolkit in near future !

Update :
You can test a first preview early-adopter draft SNAPSHOT.
Doc is deployed at http://people.apache.org/~nicolas/gwt-maven-plugin-2.1/ (much cleanup needed)
same URL is a maven repo to get the plugin. Test it using (as a single line) :

mvn archetype:generate -DarchetypeRepository=http://people.apache.org/~nicolas/gwt-maven-plugin-2.1 \
 -DarchetypeGroupId=org.codehaus.mojo \
 -DarchetypeArtifactId=gwt-maven-plugin _\
 -DarchetypeVersion=2.1-SNAPSHOT  

Vous le savez forcément déjà, mais j'en remet une couche : le 10 septembre aura lieu à La Rochelle le JugSummerCamp, un concentré de JUG dans une journée de conférence, gratuit et indispensable, avec un week-end à la plage à embrayer pour ceux qui veulent bien finir l'été.

Pour ce qui me concerne, j'y vais avec la bénédiction de mon chef, pour défendre les couleurs d'Orange Business Services IT&Labs, youkaïdi. Pour l'occasion je pourrais mettre un T-Shirt orange, ça me changera...

Et comme mon chef est aussi un artiste passionné (et oui, on peut faire autre chose de sa vie que de l'informatique !), en guise de réponse à la question "est-ce que tu me sponsorise pour le JugSummerCamp ?", il m'a peint une toile !

Vous en avez, vous, un chef comme ça ?

Pas facile de suivre l'évolution de GWT, dont la version 2.1 poursuit son chemin de Milestone en Milestone...

En 2009, lors de la conférence Google I/O, la session Best Practices for GWT nous présentait les patterns MVP et Event Bus, et leur application en GWT. S'en est suivi une poignée d'implémentations opensource sur googlecode (ici, là ou là) pour mettre en pratique ces bons conseils.

Pour 2010, la roadmap GWT nous annonçait un MVP "officiel", d'où de nombreuses interrogations de la part de ces communautés et une grosse attente du côté du forum des utilisateurs. Vient alors la wave de "design collaboratif" de Ray Rayan, qui sème un sérieux trouble. On y parle de data-binding, d'une nouvelle mécanique client serveur, et pas tellement de MVP ... en tout cas pas dans les termes de 2009 !

Voici qu'arrive bikeshed et sa démo Expense. L'analyse du code de l'exemple montre une véritable usine à gaz dont on comprend mal les rouages, avec pléthore de classes techniques. On comprend rapidement que cette infrastructure doit in fine être générée par l'outillage. Tiens, justement, Google annonce son rapprochement avec Spring Roo sur ce sujet !

Et hier, poum, la nouvelle tombe : bikeshed est mis au placard et retiré du trunk - ce nom étrange était-il prémonitoire ? Il n'en reste que le mécanisme d'échange avec le serveur RequestFactory (basé sur JSON) permettant de faire le lien entre un backend JPA et des DTO utilisés dans l'IHM GWT, et la génération de squelette est déportée dans Spring Roo.

bikeshed était très - trop - ambitieux et complexe. Si un socle MVP fait bien sont apparition dans GWT 2.1 (com.google.gwt.app) il ne reprend pas le vocabulaire de la session Google I/O 2009 et manque cruellement de documentation, en étant de plus marqué "Expérimental". Je regrette que l'équipe GWT se soit embarquée sur un terrain aussi glissant, plutôt que d'inclure un développement externe qui a déjà fait ses preuves et porté par une communauté, comme ils l'ont fait au préalable avec l'incubateur. Les diverses approches MVP proposées en opensource ont fait leur preuves et ne vont même pas souffrir de la concurrence d'un framework mal documenté et expérimental, même intégré au SDK.

Je ne pense pas que cela empêche l'innovation : de très bonnes extensions comme gwt-fx ou gwt-dnd proposent des fonctionnalités qui étendent le scope de GWT vers plus d'interactivité. Flex comme Java/Fx proposent un mécanisme de data-binding pour lier le modèle à la vue en une ligne de code, ce que nous devons faire à grand coup de Handlers et d'événements sur l'Event-Bus en GWT. Des solutions de binding GWT existent pourtant de longue date en opensource : le support des ProperyChangeListeners JavaBean - élément clé du DataBinding - a été proposé dès GWT 1.4, mais le sujet reste non-prioritaire

Wait & See comme on dit ...

Vous l'aurez compris, Git est mon nouveau dada. Avec toutes ces années de "centralisé" j'ai tout de même du mal à me sortir de mes habitudes sous Subversion. Voici donc un petit pense bête pour ceux qui sont dans le même cas que moi, et qui ont du mal avec les innombrables options de Git, surtout si on le couple avec le SVN de l'équipe.


Git va faire une update svn puis rejouer toutes les modifs committées en local. Attention de partir d'une environnement propre (cf git slash plus loin)

Ces deux commandes sont assez peu naturelles, l'équivalent sur un repo Git étant git push / pull, mais bon.

Le travail en local

C'est là que Git va montrer son intérêt : Git nous sert à structurer notre façon de bosser là où jusqu'ici on était  obligé, soit d'avoir plusieurs workspaces, soit de "pousser" notre workflow sur le SVN commun, soit d'avoir plein de travaux en cours dans le même workspace et de commiter un peu tout et n'importe quoi (suivi de quelques commits "fix").

On va donc bénéficier d'une gestion de version très puissante et performante en local, plutôt que d'un foutoir plus ou moins organisé.

Démarrer une nouvelle tâche :
git checkout -b maTache


le "-b" crée la branche locale à la volée
faire sa tambouille, je suppose que vous utilisez eGit ou équivalent : add, commit, etc

Faire une pause et passer en urgence sur une autre tâche :
git stash
git checkout monAncienneTache
// correction et tout ça sur monAncienneTache
"stash", c'est la boite à idées de Git, la pile où on met tous les trucs en cours, en attente de "plus tard, quand j'aurais le temps"

Intégrer une branche dans le master une fois que tout marche comme sur des roulettes :
git merge maTache master


supprimer la branche une fois le boulot terminé / validé / livré :
git branch -d maTache 

Je me lance dans un gros refactoring de sauvage, pour lequel un module maven doit être splitté en trois, avec des changements de packages en tout genre et j'en passe.

Pour avoir fait ce genre de manip plus d'une fois, celà se traduit généralement par :

• L'impossibilité de faire l'opération en un seul commit SVN (en tout cas, j'y suis jamais arrivé) : des fichiers déjà modifiés doivent être déplacés ou renommés, et le couple SVN+Eclipse ne gère pas du tout bien la manip
• L'impossibilité totale d'envisager un merge de modifications apparues en cours de route. Le fichier à changé de place et de nom, SVN ne s'y retrouve pas.

Au final, l'opération se fait sur la pause de midi ou - dans mon cas parce que ça ne me dérange pas - tôt le matin, avec deux ou trois échanges de mail pour alerter tout le monde et bloquer les commits.

Cette fois, je tente la manipulation avec Git. 

Tout d'abord, un git svn clone me fournit un repo Git à l'image du SVN projet.

Ensuite, après un premier essai pas très concluant, j'installe un nightly-build du plugin EGit pour contourner ce bug, qui rend EGit quasiment inexploitable (il veut tout le temps committer les target).

C'est parti pour une séance de "bouge ton code". Mettez à fond "I like to move it" et balancez la sauce...

Je ne vous cache pas que j'ai un peu merdé sur mes premières commandes Git. En gros, pendant la première demi-heure on se demande dans quoi on s'est embarqué, et même avec mon ami Google les commandes restent assez obscures. Pendant cette phase d'appropriation de l'outil, ayez le réflexe de garder sous le coude la refcard Git, ainsi que l'excellent open-livre ProGit :P

Après ces premiers faux pas, les réflexes commencent à venir, et je dois bien avouer que la question devient vite "pourquoi n'ai-je pas essayé plus tôt ?"

Pourquoi Git est-il différent ?
La première différence, liée à  l'aspect décentralisé, est de disposer en local d'un repo très rapide pour committer, brancher, revenir en arrière, etc. Pensez au nombreuses fois où vous avez eu recours à l'historique local d'Eclipse pour rattraper une boulette. Et bien là c'est toute la puissance d'un SCM qui est au bout du clavier. Le switch de branche étant quasi instantané, on en profite (on en abuse même) alors que sous SVN c'était l'horreur.

La seconde différence, c'est que la structure de Git se base sur un unique répertoire .git, et pas une invasion de .svn à tous les niveaux. Ca n'a l'air de rien, mais une conséquence immédiate est que les performances I/O du système (dénaturé par une surcouche MacAffee) s'en trouvent bien meilleures. Lorsqu'on déplace un répertoire entier avec SVN, la première erreur consiste à utiliser l'explorateur. Les fichiers .svn n'étant pas mis à jour il n'y à rien à committer. Après s'être fait avoir 2 ou 3 fois, on apprend à faire un "refactor > move" qui se traduit par une série de Remove + Add au niveau SVN, et au prochain merge c'est l'enfer.

Dernière différence significative : en l'absence de .svn pour marquer chaque répertoire/fichier, Git doit retrouver l'identité de chaque fichier modifié lors d'un commit. Il va comparer les fichiers par rapport à son index, et sera capable d'identifier un déplacement, malgré les déclaration "package" ou d'import qui changent. En gros, le fichier le plus "similaire" dans l'index est celui qui a été déplacé. C'est une solution empirique, mais qui marche bougrement bien. D'ailleurs, tout est empirique dans Git, comme les identifiants de commit qui sont des empruntes SHA1 - mathématiquement parlant il y a un microscopique risque de doublon, mais en attendant ça fonctionne très, très bien ! Résultat, le SCM est très souple et les merges ne sont plus un soucis !

Pourquoi Git fait-il peur ?

• Git c'est nouveau, c'est geek, donc forcément ça fait un peu peur.
• Git c'est très "ligne de commande", et quelle ligne ! Même si on s'y fait finalement assez vite, voir quelqu'un travailler avec Git fait penser qu'on est passé du côté obscur.
• Git est mal intégré dans Windows; msysgit est très correct, mais reste une solution ligne de commande, avec quelques outils graphiques bienvenus. TortoiseGit ne m'a pas convaincu, et j'utilise EGit sous Eclipse en complément de la console GitBash.

L'autre raison qui fait que Git va mettre un peu de temps à rentrer dans les moeurs, c'est son aspect décentralisé : le concept est encore assez neuf, et vient en contradiction avec des années d'habitude centralisatrices.

My 2 cents...

Comment bien aborder Git ? Le couplage avec SVN permet de l'expérimenter localement sans impacter le reste de l'équipe (en dehors des fichiers .gitignore qui vont fleurir dans SVN). Ensuite, il faut considérer votre mode de travail local, votre "workflow", indépendamment de celui de l'équipe qui est formaté par SVN.

Sur le poste de développement, on fait plein de choses en parallèle : on revient en arrière, on teste un truc, on change de tâche. On se retrouve donc à committer quelques fichiers par-ci par là, à commiter un item par petites touches. Autrement dit, on pollue le projet de travaux pas finis, et on est sous-outillé en local pour séparer nos diverses activités. Git est un outil qui vient soutenir ces démarches de manière active, il va structurer et assister notre travail quotidien.

Une fois l'habitude de Git en locale prise, les derniers récalcitrants convertis, le passage du point de centralisation sous Git parait une évidence. Avec lui une autre façon d'envisager le projet peut émerger : comment isoler chaque fonctionnalité et les "merger" au dernier moment ? Comment intégrer les correctifs à la demande ? etc...

Que ce soit Git, ou Mercurial (apparemment plus structurant, je n'ai pas testé) ou un autre candidat, les SCM décentralisés vont bouleverser notre façon de travailler.

Les récents remous sur la ML Maven-dev, que je vous ai rapportés à chaud, m'amènent à m'interroger sur la stratégie de Sonatype.

Tout d'abord une mise au point : l'avenir de Maven n'est pas, mais alors pas du tout remis en question. Au contraire, l'activité supersonique de Sonatype sur le sujet et les réactions des committers montrent que l'intérêt pour le projet est bien vivant, que les idées et les bonnes volontés ne manquent pas. En témoigne le premier bug OutOfMemory identifié par Arnaud et les nombreux commentaires techniques qu'on peut lire entre deux trolls.

Ce qui crée la prise de tête, ce sont des aspects purement politico-phylosophiques, entre Jason qui veut aller vite, très vite avec la dream-team qu'il s'est créé, le clan des bisounours Apache-forever qui défendent bec et ongle le modèle du consensus, et la majorité de ceux qui veulent juste que le train avance sans perdre trop de wagons en chemin (1).

Ceci étant dit, on est en droit de s'interroger sur la stratégie de Sonatype. Plusieurs hypothèses :

Scénario 1 : Santa barbara
Brian est parti avec Jason, et du coup Brett lui en veut à mort, alors il s'est associé à Maria pour le lui faire payer. Comment va réagir Stephen ? Vous le saurez en suivant le prochain épisode de votre feuilleton de l'été. Pas convaincu ?



Scénario 2 : L'apocalyspe
Jason est l'antéchrist et Sonatype son église. Ils veulent détruire l'informatique de l'intérieur. Heuresement, les valeureux Apachistes défendent la terre promise de ses assauts. Bon, on passe.



Scénario 3 : Le complot
Une société secrète s'en montée et tente de nous dégouter de Maven, malgré les tentatives de Sonatype de sortir le projet de ses culs-de-sac techniques. Gradle tirerait les ficelles dans l'ombre et aurait prévu le coup de longue date en mettant de nombreux committers historiques sous hypnose. Improbable.

Scénario 4 : L'OPA
Sonatype veut fagociter Maven, pour suivre le modèle d'un JBoss, SpringSource, et autre eXoPlatform qui ouvrent leur source tout en gardant la main sur la roadmap. Comme tous les committers ne sont pas à vendre, la seule solution qui reste est le fork, et dans cet objectif il faut construire une cause acceptable : l'immobilisme face aux forces innovantes par exemple ?

J'avoue que j'ai pas mal penché pour cette hypothèse, mais ça c'était avant de croiser Jason à Devoxx pour sa conférence sur Maven 3...

Scénario 5 : Les Geeks en action
Jason est un gars dont les capacités de communication et de diplomatie sont inversement proportionnelles à son talent de programmeur; et c'est un excellent programmeur. Son objectif est de faire vivre sa boite avec le projet qu'il a créé de ses mains, et de le développer à sa guise sans qu'on vienne lui casser les pieds. Si le succès de Maven ne peut lui être attribué seul, son influence n'a jamais faibli.

C'est le pur Geek qui ne s'intéresse qu'au code et n'a que peu de complaisance pour les interminables discussions philosophiques sur la façon de faire telle ou telle chose; "Montre moi du code qui marche et on verra". Avec cet éclairage, accrochages et prises de bec avec les autres committers deviennent inévitables, mais cela ne retire rien à la pertinence de ses propositions.

Vous l'aurez compris, cette dernière explication est la bonne. Ne cherchez pas à dénigrer Maven en pointant du doigt son développement mouvementé. Soyez plutôt jaloux de voir autant de monde impliqué, et même une société qui vit et investit corps et âme sur son développement.

(1) avez-vous noté le subtil jeu de mot ? Wagon est l'un des composants de Maven qui va être remisé avec l'arrivée d'Aether :P

Après quelques jours de débats plus ou moins houleux, quelques uns ont tenté de désamorce le conflit, pour permettre l'inclusion de Spice et Aether dans Maven 3.

Petit rappel : Spice permet à Maven3 (comme Nexus) d'exploiter Google Guice à la place de Plexus, sans modification des API (c'est donc une couche Adapter). Aether quand à lui est un redéveloppement de la gestion des Artefacts, des dépendances transitives et du repository - autrement dit le remplaçant du mort-né Mercury qui remplaçait lui-même un code historique dont tout le monde s'accorde pour dire qu'il était un boulet pour Maven.

Sauf que, en dehors de la forme employée par Sonatype et en particulier son patron Jason Van Zyl pour imposer cette évolution, les tentatives de conciliations se sont globalement heurtées à un mur.  La proposition plutôt équilibrée d'Arnaud de sortir une beta 2 avec le code actuel, suivie d'une beta 3 incluant Spice et Aether, ce qui permettrait de tester avec et sans Aether et de valider rapidement une éventuelle régression (et il y en a), a été rejetée d'un trait, comme de nombreuses autres
- "c'est ça ou merde" (j'exagère à peine le ton).


Le soucis, c'est que Aether reprend un pan entier des fonctionnalités supportées par Maven. Celui-ci deviendrait une coquille demi-vide qui exécute juste des plugins dans l'ordre. Ralph Goers ne s'y est pas trompé et menace de voter "-1", ce qui en langage Apache veut dire "toi même". Cas historique à ma connaissance. Son autre option serait de forker de force le code d'Aether dans le SVN Apache (ce qu'autorise la licence), pas vraiment mieux. Ralph accuser clairement Sonatype de vouloir s'approprier le projet Maven, ce qui - je l'ai déjà dit - ne me choquerais pas nécessairement, mais à condition de le faire ouvertement et pas par des tours de passe-passe de ce genre.

Hors sujet, mais notez le nombre de lois impopulaires qui sont votées en plein été, pendant que personne n'est là pour gueuler. Coïncidence ou stratégie ? 

De nombreux membres historiques du projet, réveillés par ce débat, se sentent dépossédés. L'argument de Jason est qu'il ne contribuent plus au code et donc n'ont plus droit à la parole. Pourtant ils contribuent activement au succès de Maven, par des conférences, formations, articles, support, etc en plus d'avoir une vision de l'historique et de l'esprit du projet, qui a tout son sens. Les bonnes volontés ne manquent pourtant pas pour s'intéresser à l'API, essayer ce nouveau composant, ou proposer des modèles intermédiaires laissant dans Maven ce qui lui est spécifique (l'un des objectifs d'Aether est de supporter aussi les repository Eclipse P2).

OK, Sonatype a besoin de faire avancer Maven pour gagner sa croute, avancer vite et dans le sens qu'il veut lui donner, mais il y'a des façons moins brutales de faire.

Ca sent mauvais tout ça. Bien malin celui qui dira comment ça va se terminer.

La contribution de Sonatype au développement de Maven 3 est proche de 100%, aussi il ne faut pas s'étonner qu'il soit difficile de suivre ce qu'ils font depuis l'extérieur ... mais quelque fois ça devient plus que difficile.

Je vous ai déjà parlé de l'intégration de Guice comme conteneur de Maven 3. L'idée a été poussée par Olivier Lamy qui tente d'intégrer correctement Maven 3 dans Hudson, ce qui est nettement plus simple avec la branche Guice qu'avec le code historique Plexus. Fin de non recevoir, avec renvoi dans les cordes comme quoi ce code n'est pas suffisamment testé et que nous (pauvres développeurs indépendants) sommes mal placé pour juger de sa stabilité.

Et voilà un petit message amusant sur la Mailing List Maven :

Les réactions n'ont pas tardé. En effet, ces développements se sont fait purement en interne chez Sonatype, en particulier pour Aether. Le meilleur moyen pour se tenir au courant était alors de suivre le twitter de Jason, et le PMC (Project Management Committee) Maven est donc quasiment le dernier consulté.

Perso je ne comprend pas pourquoi Sonatype ne prend pas tout simplement les commandes de Maven 3 "hors Apache", comme SpringSource le fait de son framework ou JBoss de son serveur d'applications, ce qui ne nous empêche pas de les utiliser sans plus de questions.

Maven est déjà largement utilisé et n'a plus besoin de l'aura "Apache" pour se faire connaître. Dans le pire des cas ça pourrait être un fork dans la douleur, mais vu l'avance de Sonatype sur le sujet ça ne changerait pas grand chose. iBatis a quitté la fondation Apache dans des conditions moins politiquement correctes sans que ça fasse plus de vagues, et de toute façon la base des utilisateurs s'en moque.

Update :

"
Jason van Zyl
During the course of development of Maven 3.x development only Kristian and Olivier have dug in. I honestly don't believe droves of people here are going to all of a sudden start making huge contributions to the effort. 
( ... ) Having several people who haven't been even remotely involved in the project over the last year tell me what we should do with the code we wrote doesn't sit very well with me philosophically to be perfectly frank. You do the work, you earn the merit, and therefore the right to decide the fate of the code.
"


Si la philosophie de la fondation Apache, pour laquelle un PMC conserve son poste ad vitam même s'il ne contribue plus au code (il y a bien d'autres façons de contribuer), ne convient pas ... alors pourquoi s'encombrer avec cette fondation ?


à suivre.