new Blog( perso );

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.

Je passe l'été en compagnie de jMeter, parce que la plage c'est ringard et qu'on y prend des coups de soleil.

jMeter est un outil bien rodé, mais qui cache tout de même mal son âge. Si on pardonne l'IHM Swing assez moche, la logique de manipulation des éléments de contrôle est assez étrange. En particulier, les temps d'attente qu'il faut attacher en fils pour qu'ils s'exécutent avant une requête, plutôt que de les mettre ... avant elle, c'est assez tordu. Ceci dit, une fois qu'on a pigé le truc on arrive à s'y faire (« c'est pas pire que de passer à Maven » diraient certains).

Si on regarde sous le capot, là aussi ça sent fort le old school, jMeter date tout de même de 1998 (regardez le code de vos projets de 1998 pour rigoler). Il y a clairement une dette technique sur ce projet, même si ça ne l'empêche pas de rester pertinent. Pour ma part j'ai du développer un Sampler qui récupère les métriques JMX (java.lang:type=Memory) de la JVM sous charge, ainsi qu'un Listener qui stocke les mesures brutes dans une base Derby plutôt qu'un fichier CSV (données plus faciles à exploiter par la suite avec BIRT par exemple, voir ici). Ca se fait sans grande difficulté, mais c'est pas du code magnifiquement découpé comme on en fait tous aujourd'hui (ah bon, pas vous ? :P)

Une astuce à connaître : Quand on capture un scénario avec le proxy HTTP, on peut regrouper toutes les requêtes liées à un clic sous un contrôleur, ce qui clarifie le scénario. En remplaçant ces contrôleurs "génériques" par des "Transaction Controller" (et là on est bien content que le script soit en XML) on obtient une métrique pour chaque page de l'appli web, ce qui reflète mieux la performance ressentie par l'utilisateur que les résultats HTTP bruts.

Gros gros bémol à l'utilisation de jMeter : le reporting en est quasiment absent, et on est donc obligé d'exporter les données brutes en CSV (ou en base dans mon cas) pour une consolidation externe. D'un autre côté, quand on voit les tarifs de LoadRunner ou même de NeoLoad, on se dit que c'est l'occasion de s'essayer au reporting BIRT...

Autre soucis : jMeter utilise un Thread par utilisateur virtuel. C'est nettement plus simple pour son implémentation interne, mais pour simuler des milliers d'utilisateurs, même si chacun ne fait qu'une requête par minute, ça pose de gros soucis : chaque Thread occupe de la mémoire (native+heap) et on est vite à cours de ressources, sans parler de la surcharge pour l'OS qui doit gérer en masse les changements de contexte de ces Threads, qui ne font pourtant pas grand chose. Je me lancerais bien dans un gros refactoring de jMeter mais ... euh ... bon, vous aurez compris.

Ceci dit, la question est de savoir ce qu'on désire faire avec jMeter. Dans un esprit "consulting", on lui demande de valider une SLA et de fournir de jolis graphes 3D pour mettre dans le joli rapport d'audit en couleur sous Office 2010. Dans un esprit "main dans le cambouis" on lui demande de charger l'appli qu'on aura mis préalablement sous monitoring / profiling pour en déceler les faiblesses et y remédier. Ce n'est donc pas un hasard si jMeter supporte une dizaine de protocoles, mais sort péniblement un graphe tout moche : il a choisit son camp.

En tout cas, et jusqu'à preuve du contraire, jMeter est le seul outil à se greffer facilement dans une intégration continue pour faire de l'analyse d'évolution de perf, ce qui est nettement mieux que d'attendre la pré-prod pour tester l'appli et se rendre compte d'un gros problème de conception ...

Depuis la sortie de mon bouquin, j'ai eu l'occasion de signer quelques dédicaces et c'est un plaisir de voir l'enthousiasme des lecteurs. C'est toujours délicat de mettre un petit mot qui soit un minimum personnalisé pour quelqu'un qu'on rencontre tout juste. C'est aussi délicat d'écrire à peu près proprement et de ne pas consteller la dédicace de fautes d'orthographe ;)

Dans mon palmarès des meilleures dédicaces, il y a eu celles que j'ai faites lors du ParisJug pour les duchesses, avec la bière l'inspiration s'emballe (mais nous sommes restés bons amis, rassurez vous).

Mais ce "record" est maintenant battu à plate couture : les collègues de Fabien ont en effet décidé de lui faire un cadeau geekesque pour son  mariage avec Julie,  en me demandant une dédicace "spéciale".


Tous mes voeux de bonheur à ce joli couple, en espérant qu'ils aient tant de choses à faire ensembles, que lorsqu'ils ouvriront enfin ce fameux bouquin pour le lire, il soit complètement obsolète !

Pour ce billet je ne vais pas me fouler, je vais juste reprendre la traduction proposée par Nicolas Martignole. En gros, Oracle continue d'absorber SUN et d'incorporer le contenu de son site web dans ses propres pages ... sauf que de toute évidence ils ont pris un webmaster stagiaire. En effet, je me fiche pas mal de savoir sur quel CD Oracle stocke les sauvegardes du site de SUN, et surtout j'aimerais ne pas avoir à mémoriser des URL aussi mal fichues.

"

Le départ de SUN/Oracle de Kohsuke Kawaguchi a laissé planner quelques interrogations sur l'avenir de Hudson.

SUN finançait les travaux de Kohsuke sur ce qui était initialement un outil interne du projet Glassfish, et n'a jamais remis en question son orientation opensource. Le passage chez Oracle a fait peur mais n'a eu aucun effet notable sur le projet. Par contre, le départ de Kohsuke pour monter sa propre société autour d'Hudson pose de nombreuses questions.

Que va devenir le projet Hudson sur java.net ? Sans que personne ne soit indispensable, il reste très lié à Kohsuke et donc à sa bonne volonté / son temps pour soutenir le projet en opensource. Quel modèle pour sa toute jeune société InfraDNA ? Le lancement d'un Hudson "certifié" donne des éléments de réponse :

ICHCI (c'est son petit nom) répond à une préoccupation légitime de tout gestionnaire de forge logicielle : quelle version de Hudson installer, sachant qu'on a une release chaque semaine. Le temps de qualifier une version, la suivante est dans les bacs ! Une fois la version choisie, quels plugins activer ? Il y en a pour à peu près tout et n'importe quoi dans des états variables, du early-draft au plugin parfaitement stabilisé. L'idée d'IHCI est donc de ralentir la vitesse extravagante de développement d'Hudson pour en fournir une version "stabilisée" - comprendre testée en profondeur - accompagnée d'une sélection soigneuses de plugins, et bénéficiant d'un support dédié.

Selon un modèle assez classique opensource/pro, ICHCI se base sur la forte pénétration de Hudson et de l'intégration continue en général pour monnayer ce service. Ceux qui veulent/peuvent construire leur forge avec leur petite main le feront en opensource, ceux qui préfèrent ne pas dépenser des jours sur ce qui devient un élément courant de l'infrastructure projet feront un chèque.

Des plugins spécifiques propriétaires accompagnent cette version professionnalisée d'Hudson. Ils sont la valeur ajoutée qui permet d'afficher une plus value autre que le seul support (et s'adresse donc au techos que je suis, le DSI ayant été convaincu par l'offre de support :P). La communauté Hudson étant très, très active, ces plugins pourraient à terme avoir des équivalents opensource, ou bien InfraDNA pourrait ouvrir ses plugins en fonction de l'avance qu'il arrive à maintenir - comme Sonatype l'a fait avec le plugin LDAP pour Nexus.

Bref, ça bouge, c'est bien. Hudson a de l'avenir, aussi bien en opensource qu'en outil pro. Vous pouvez ranger votre CruiseControl.

L'informaticien, pour son numéro d'été, publie sur 4 pages un chapitre entier de mon bouquin "Apache Maven". Je suis tenté par trois hypothèses :

• ils ont trouvé le livre exceptionnel et il semblait plus efficace d'en publier un long extrait que d'en dire quelques mots dans la rubrique "à lire" ;
• Pearson, (<lêche>) en plus d'être le plus gentil éditeur de tous les temps (</lêche>), a un service de presse d'une efficacité redoutable ;
• ils manquaient d'inspiration pour boucler l'édition d'été, 4 pages blanches ça faisait désordre, à moins de coller des pubs supplémentaires pour Windev...

Quoi qu'il en soit, et si vous n'avez pas encore eu le livre entre les mains, jetez un oeil sur le magazine chez votre marchand de journaux préféré pour vous faire une idée du ton que nous lui avons donné. Il ne vous en coutera que 3€ si vous voulez le lire tranquillement chez vous, 3€ qui ne vous seront absolument pas remboursés si au final vous achetez le livre, faut pas rêver non plus :P

Après 13 années, je change lundi de job. C'est parti pour de nouvelles aventures !
Bon courage à ceux qui restent, ainsi qu'à ceux qui vont devoir me supporter.

Pour donner un cours à l'Epitech de Rennes, je me suis enregistré comme auto-entrepreneur. Comme promis par ce statut, l'enregistrement se fait en quelques clics et est effectif sous quelques jours sans formalité supplémentaire, ce qui tranche avec le tour des agences telle qu'il fallait le pratiquer il y a encore quelques années pour créer une entreprise.

Je reçois alors un courrier d'Inforegistre, un formulaire à case bien administratif avec la seule entête "à retourner sous 15 jours avec son règlement de 87,04€" (avec ces couleurs). Une rapide recherche sur Google montre que cet enregistrement sur Inforegistre, société qui gère un base de données pour le registre du commerce et de l'industrie, n'est absolument pas obligatoire. C'est donc une nouvelle forme de télé-vente : après les mails de spam, les coups de fil à 20h pour nous vendre des radiateurs ou un abonnement ADSL, voici le combiné publicité + facture. Je me dis qu'il doit y en avoir plus d'un à se faire avoir...

Après des années à trainer sur la mailing list de Maven, j'ai été invité dans la communauté Mojo qui héberge une large panoplie de plugins Maven "non stratégiques" - comprendre non supportés par le projet Maven lui-même. J'y ai lancé les javascript-maven-tools (à l'état dormant depuis) et repris le flambeau sur le plugin GWT. Ce projet, relativement ouvert aux nouveaux contributeurs, fonctionne sur ce modèle : proposer, supporter, passer la main. Un plugin n'y vit que si des développeurs sont là pour le soutenir, développeurs qui sont souvent ses premiers utilisateurs.

Je suis ensuite passé dans le code d'Archiva pour des besoins internes. Ayant du temps plus ou moins officiellement dégagé sur cette tâche j'ai pu m'investir et faire des évolutions intéressantes, créer des liens forts avec les développeurs, qui m'on finalement invités à rejoindre le projet Maven - à l'époque non différenciée d'Archiva. Nous sommes fin 2007.

Depuis cette date, j'ai continué à oeuvrer sur le plugin Mojo GWT et j'ai quelquefois apporté ma pierre à l'édifice Maven, via quelques contributions mineures (release:stage, c'est moi). Mes tentatives pour rentrer dans le "core" se sont soldées par un échec : soit j'ai clairement fait des boulettes et j'ai été vite renvoyé dans les cordes [svn rollback], soit mes propositions sont restées sur le pavé. En 30 mois je n'ai donc rien committé de concret dans le svn Maven.

Par contre, j'ai activement participé à la com' sur Maven, à travers les JUGs et ce fameux bouquin dans lequel j'ai réussi à embarquer Arnaud. Tout ça c'est du temps libre, ça ne rapporte rien en dehors de l'estime de la communauté - ce qui est déjà beaucoup.

Mon activité pro ne consiste pas à développer Maven, déjà que contribuer à corriger des bugs ou à améliorer quelques plugins ne soit pas une tâche tout à fait officielle. Mon temps libre est déjà largement amputé par l'organisation du BreizhJug. Je n'ai plus le temps pour élaborer des idées, développer un POC et le faire challenger par ceux qui passent leurs journées sur le projet. Même si cela parait nécessaire le coût est trop important pour un simple contributeur comme moi.

J'ai donc fait le choix symbolique de me retirer de la liste des développeurs Maven. Cela ne me retire pas le droit de commit, rassurez-vous, je pourrais donc encore venir appliquer quelques patchs intéressants pour corriger un bug que je rencontre dans mon boulot de tous les jours. Par contre je ne compte plus m'impliquer dans le développement de Maven.

Hudson utilise un modèle assez étrange au premier abord : pour devenir committer, il suffit de montrer patte blanche. "Bonjour, j'ai écrit un patch pour l'ano ###" (et/ou) "J'ai écrit un plugin rigolo boite-à-meuh-hudson-plugin". La réponse ne tarde pas : "Quel est ton ID java.net, comme ça tu pourras le committer toi même". Hudson fonctionne sur la confiance : ceux qui participent sont déjà une toute petite sous-catégorie de gens motivés, il ne faut surtout pas les freiner. Un plugin hudson ne vit que parce qu'un ou deux développeurs le supportent, et le projet a besoin de sang neuf pour vivre et s'épanouir.
C'est vrai que lorsqu'on regarde sous SVN, Hudson paraît particulièrement bordélique. C'est un effet de bord totalement assumé ! Obliger les développeurs à suivre des conventions trop rigides c'est créer une barrière aux contributeurs. Si un plugin est proposé, même dans un état discutable, mais avec de la motivation et du temps pour s'en occuper, alors feu vert. S'il devient vraiment utile et attire d'autres développeurs il sera toujours temps pour le "nettoyer". Jusqu'ici, le projet n'a pas eu à souffrir de ce qui ressemble a priori à un manque de rigueur. Les versions se succèdent à un bon rythme, avec des corrections rapides et de nouvelles idées.

Deux approches opposées,

• le modèle Apache Maven : les règles et les consensus à la Apache, et un pilotage "business-driven", 
• le modèle Hudson : "open-bar" ouvert à toutes les bonnes volontés. 

Les deux outils ont fait leurs preuves et sont devenus l'un comme l'autre des incontournables, avec un excellent niveau de stabilité. Comme quoi tout n'est pas gravé dans le marbre

Nicolas Romanetti m'a fait l'autre jour une remarque sur un manque dans mon livre Apache Maven concernant le chapitre sur JavaEE : Dans le modèle JavaEE (pré-6), on met les classes et les ressources dans un WAR, lui même dans un EAR, et on balance tout ça sur le serveur. Où placer la configuration de l'application ?

Si on lit la spec JavaEE, elle prévoit un rôle d'assembleur d'application, qui va prendre l'EAR, éditer ses fichiers de déploiement XML pour faire le lien entre les ressources de son serveur (DataSource, files JMS, ...) et l'application. Personnellement je n'ai jamais rencontré ce cas de figure, et mes clients attendent plutôt une application prête à fonctionner avec au plus un fichier de configuration properties externe à l'EAR.

Option 1 : embarquer la conf en fonction de l'environnement cible

Si on veut suivre l'esprit JavaEE on peut utiliser des profils Maven pour packager dans le WAR les ressources associées à l'environnement cible :

<profile>
      <id>dev</id>
      <build>
        <resources>
          <resource>
            <directory>${basedir}/src/env/dev</directory>
          </resource>
        </resources>
      </build>
    </profile>
    <profile>
      <id>prod</id>
      <build>
        <resources>
          <resource>
            <directory>${basedir}/src/env/prod</directory>
          </resource>
        </resources>
      </build>
    </profile>

il suffit donc d'ajouter un petit "-Pprod" pour générer l'application dans sa configuration de production. Par contre, la configuration ne peut pas être éditée simplement une fois l'application installée.

Option 2 : passer par le JNDI

L'autre option respectant l'esprit JavaEE est de se baser sur les ressources JNDI, et donc d'accéder à une donnée d'environnement de type URL ou String qui pointe vers notre fichier de properties. Dans le web.xml j'ajoute donc un petit :

<env-entry>
      <description>Chemin de la configuration locale</description>
      <env-entry-name>appli.home</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>/valeur/par/defaut</env-entry-value>
    </env-entry>

Je n'ai plus qu'à définir cette ressource dans le JNDI de mon serveur d'application, ce qui va par contre être spécifique à chaque serveur - Tomcat par exemple ne permet pas de définir une ressource URL, alors que Websphère le supporte (pas classique de dire du bien de celui-là, n'est ce pas ?).

Pour y accéder, il faut faire un lookup JNIDI ce qui n'est pas léger léger, et si on veut passer par Spring et ses PlaceHolder ${truc} on regardera du côté de SPR-3030.

Option 3 : passer par une propriété système

Dernière option, la version "light" : dans de nombreux cas, je constat que le serveur d'application n'héberge qu'une seule instance de l'application, aussi on peut positionner des variables systèmes au niveau de la JVM pour lui passer un paramètre, typiquement notre appli.home. Et là, rien de spécial à faire pour activer le configuration Spring en dehors d'activer le SYSTEM_PROPERTIES_MODE_OVERRIDE.
Dans le même esprit, on peut externaliser la configuration log4j en ajoutant un -Dlog4j.configuration=file:///monlog4j.xml.

Perso je préfère cette dernière variante, la plus légère à mettre en oeuvre et la plus simple à expliquer aux développeurs. JNDI reste un truc assez mystérieux, qui plus est avec des variations pour sa configuration en fonction des serveurs d'application. L'accès au DirContext se fait trop souvent via un mauvais copier-coller qui référence les classes du serveur d'application (alors que justement le but est de s'en découpler !) et/ou en ajoutant au petit bonheur la chance des java:comp/env ... peut être le sujet d'un autre billet :)

Option 4: compléter le classpath du serveur

Suite au commentaire de Sylvain François, une 4ème option, comparable au system properties : ajouter au Classpath de l'application le chemin d'un répertoire contenant les fichiers de conf. En jouant sur l'ordre de chargement du ClassPath on peut ainsi surchager les fichiers de conf "par défaut" présents dans le WAR/EAR.

Ces deux dernière options sont assez comparables et leur mise en ouvre va dépendre de la liberté qu'on a pour configurer le serveur d'application. Certaines équipes d'exploit' donnent la main sur la commande de lancement de la JVM, d'autres préfèrent la blinder mais laissent libre accès aux répertoires de libs ...

Qu'en pensez vous ? Donnez votre avis : http://doodle.com/d4qdxc87w76i524c

Lors du dernier ParisJug, toute l'équipe du JUG Rennais à fait le déplacement, prétextant l'organisation de son Assemblée Générale. Occasion bien choisie, vu que nous revenons après une conf d'exception de Mme "Docteur" Holly Cummins, première speakeuse invitée au ParisJug, avec en bonus clé USB et casquette offertes par IBM - on a pas gagné l'iPad, faut pas rêver non plus.

Seul bémol de la soirée, arrosée avec abondance de champagne par la générosité d'octo pour un buffet démesuré, qui a eu ses effets pervers : les bouteilles circulant dans la salle lors de la seconde conférence, l'ambiance s'est vite échauffée pour devenir un peu débordante - votre serviteur ne montrant pas le meilleur exemple.

Il en résulte un état à la sortie de la session qui ressemblait plus à une fin de 3ème mi-temps qu'à une fin de conférence, avec les effets très négatifs que cela pourrait  avoir sur les relations du ParisJug avec l'école qui les accueille gracieusement, avec les sponsors qui payent le déplacement d'un speaker depuis Londres, et bien sûr avec l'invitée d'honneur du jour qui n'avait sans doute pas prévue de présenter OGSi devant une bande de pochtrons.

Je présente mes excuses pour mon attitude excessive auprès de tout ceux que cela a pu choquer, blesser, ou simplement déranger. J'ai promis à Antonio de faire le prochain JUG au diabolo-menthe (en tout cas, avant la 3ème mi-temps). Je présente aussi mes excuses aux sponsors qui s'impliquent pour faire des JUGs des rendez-vous d'exception. Je réserve enfin mes plus plates excuses à Holly Cummins, qui avait sans doute déjà entendu parler du "French Touch" mais n'avait sans doute pas mesuré l'ampleur de la chose.


Bizarrement, je n'arrive plus à me connecter au site du ParisJug, j'ai systématiquement une

406 Not Acceptable

Lors de la conf "Maven3" au ParisJug avec Arnaud Héritier, nous avons indiqué que le remplacement du coeur de Maven (Plexus) par Google Guice était repoussé à une version 3.1 de Maven. Les choses semblent cependant s'accélerer.

Pour les besoins de Nexus, Sonatype a développé une couche d'abstraction "Spice" qui permet d'utiliser la syntaxe Plexus avec un conteneur autre, typiquement Google Guice qui est le nouveau moteur de Nexus. Cette expérience réussie donne une sérieuse crédibilité à cette option de migration en douceur.

La même approche a été testée par Sonatype pour Maven3, et Olivier Lamy a importé ces modifications dans une branche du SVN Apache. Ce code passe déjà les tests IT de Maven, même s'il reste quelques incompatibilités liées à de mauvaises pratiques dans certains plugins (modification des composants internes de Maven) que ce nouveau moteur n'autorise plus. Ces signaux plutôt positifs pourraient aider à faire passer Guice comme moteur de Maven dès la version 3.0, ce qui aurait de nombreux effets bénéfiques :

Pour les utilisateurs ou développeurs de plugin, ce changement n'apporte rien de visible, sinon des logs plus clairs quand la configuration est incorrecte - ce qui, avec Plexus, donne parfois le signal de départ pour de longues heures d'analyse. A plus long terme, l'utilisation de Guice permet d'envisager une migration plus profonde des "bons usages" de développement de plugins Maven vers les annotations @Inject (JSR330). Ceci supposera cependant que les plugins qui suivent cette voie soient dédiés Maven3, ce qui promet de longues discutions sur la liste de dev :)

Pour ceux qui veulent embarquer Maven3 dans un autre outil par contre, ce changement est significatif. La configuration de Guice dans ce mode est nettement plus simple. L'intégration de Maven 3 sur Hudson nécessite ce genre d'acrobatie, et Guice sera le bienvenu pour ne pas inutilement compliquer la tâche.

Maven 3 est donc bien en mouvement, mais avec sa très large base d'utilisateurs il ne peut pas se permettre de changements brutaux sans fournir de harnais de sécurité. C'est ce qui le différencie de quelques concurrents comme Gradle, qui apportent de nouvelles idées, mais ont surtout la liberté de tout casser s'ils ont pris une mauvaise orientation.

Lors du premier anniversaire du ParisJug, j'avais annoncé qu'un de mes objectifs pour cette année serait d'organiser Devoxx à Rennes.

En dehors de la boutade adressée à Stephan Jansen présent exceptionnellement ce soir là, j'ai l'impression que l'idée n'est pas tombé dans l'oreille d'un sourd : Le PoitouCharentesJug organise le vendredi 10 septembre le JugSummerCamp !


Lors de cette journée (éligible au DIF, si votre employeur ne voit pas son intérêt de vous y envoyer d'office) ce sont les top-speakers francophone qui vont enchaîner des sessions. La crème de la crème du super poid lourd :

• Emmanuel Bernard
• Julien Dubois
• Alexis Moussine-Pouchkine
• Christophe Jollivet
• Damien Gouyette "c'est pas dur"
• Jérôme Benois

sans oublier (le meilleur pour la fin, en toute modestie)

• Nicolas De loof

Tout ça gratuitement, dans un cadre particulièrement agréable : la rochelle ! Voilà qui promet une pause repas à la plage et une belle after beach-volley (speakers vs groopies ?)

Pour résumer : une journée au top, en français, pas loin, imputable en formation, gratuite, et avec un peu de bol on aura du soleil en plus. Alors qu'est ce que vous attendez pour vous inscrire ?

Vous en avez une belle console comme ça vous ? Si avec ça on est pas submergé de propositions par les speakers de la terre entière, je ne sais plus ce qu'il faut faire ;)

En rachetant SUN, Oracle a par la même occasion hérité de pas mal de choses dont il ne sait que faire. Entre autre, la très large communauté des Java User Groups.
SUN a toujours été très fair-play avec ses User-Group. Pas de contrainte significative pour être accepté comme JUG (on pouvait même éventuellement créer plusieurs JUG pour la même ville!), et le soutien complet de SUN - y compris matériel avec un joli kit de lancement de JUG - sans aucune exigence de leur part.

Oracle, de son côté, à déjà des Oracle User Group, mais en dehors des deux dernières lettre de l'acronyme la comparaison s'arrête là. Les OUG sont des "Product" User Group, où sont présentés les produits Oracle avec la bénédiction, le soutien matériel, mais aussi l'avis parfois un peu intrusif de l'éditeur. De l'aveu même du responsable d'Oracle qui se récupère le bébé, il n'ont pas l'expérience des "Technology" User Groups - c'est déjà bien de savoir faire la différence.

Après une période de flou, Oracle nous propose maintenant son modèle : trois catégories de groupes,

1. les gros gros, plus de 1000 membres et un statut juridique : un soutien en force d'Oracle
2. les moyens, moins de membres et pas forcément de statut : soutien d'Oracle
3. les petits : on vous aime bien

En dehors des quelques JUGs dont l'adhésion est payante, tous les autres n'ont pas une notion de "membre" qui permet de trouver sa place dans ce modèle. Par ailleurs, les JUG français sont souvent des associations loi 1901 alors que de gros JUG peuvent ne pas avoir de statut juridique explicite. Le ParisJug par exemple peut compter 3 membres légaux, 200 "visiteurs" par session, et 2000 adresses enregistrées. Alors, catégorie 1, 2 ou  3 ?

Ensuite, Oracle demande que les JUG ne s'affilient pas entre eux, et tendent à se regrouper par secteur géographique. Hors, depuis un an, on constate l'inverse : des umbrella-JUG se sont formés pour aider le développement de plus petits JUGs locaux (JUG-USA, JUG-AFRICA, JUG-ASIA, JUR.RU ...) en fournissant un cadre juridique et organisationnel.  L'idée pour Oracle semble d'avoir un minimum d'interlocuteurs (pour dispenser la bonne parole ?), et de faire entrer les JUG-Leaders sélectionnés dans un Nième niveau hiérarchique, le Oracle User Group Community. La liste des JUG-Leaders hébergée par java.net suffisait à SUN pour cela, quel intérêt pour nous ? pour eux ?

Enfin, et c'est ce qui passe le plus mal, Oracle veut nous faire rentrer dans un moule - peut être pour doser ses contributions en fonction de la taille du moule ? L'intérêt des JUG est pourtant leur liberté et leur diversité. Certains prennent en charge l'organisation d'événements majeurs (Devoxx), d'autres se contentent de faire vivre une communauté locale entre potes sans se prendre la tête. Est-ce qu'on s'apprête à tuer les "petits" ?

Quoi qu'il en soit, les JUG continueront d'exister avec ou sans le soutien d'Oracle, mais voilà bien des remous qui n'étaient pas du tout nécessaires.

Aaron, revient !

Au cours de ses deux années d'activité, le BreizhJug s'est équipé en matos audio-vidéo, en particulier suite à de nombreux déboires avec les salles "tout équipées" qu'on nous prête : micro HS, piles essoufflées, ...

Je profite donc de ce beau grand week-end - pendant lequel je suis bloqué à la maison pour garder les enfants pour cause de concours hippique - pour mettre un peu d'ordre dans tout ça avec un flight-case : tout le matos bien à l'abri et pré-branché pour fonctionner out-of-the-box. Moins de prise de tête à chaque session du Jug et de risque d'oublier un truc (mais où j'ai mis ce %#@! de câble USB ?).

Un petit détour par Leroy-Merlin et SonoWest et c'est parti !

Step 1 : Assemblage du socle du flight-case dans les règles de l'art pour contenir le matos

(les cales sur la photo serviront à fixer le récepteur du micro sans-fil qui est au format rack 19")



Step 2 : Ajustage du couvercle pour une fermeture fiable et solide
Le couvercle ferme la caisse en plaquant les éléments via des blocs de mousse, paré pour les risques du transport. Les fermetures "papillon" assure une fermeture à toute épreuve. Les poignées sont dés modèles de cuisine, plus pratique que les modèles "Flight" standard (j'ai de mauvais souvenir de mon époque Sono-Supélec avec la régie de 30kg...)

Dire que j'ai failli acheter une boite de 50 rivets en pensant que ça suffirait... 108 rivets de posés !
(et il en manque ...)

Step 3 : Aménagement pour l'installation à poste fixe du matos


de droite à gauche :

• récepteur 4 micros HF 
• console de mixage 6 voies
• boitier de capture VGA
• (manque) switch VGA deux caneaux (pour basculer d'un speaker à l'autre sans débrancher le câble et donc interrompre la capture)

Au fond à gauche la zone "alims", loin du micro HF et des câbles audio (-> "bzzzz").
A l'arrière la zone "stockage" pour les accessoires mobiles (micros main et serre-tête).

La disposition est bien, reste à faire une cloison de séparation AV/AR, de belles découpes dans une mousse "qui va bien" pour les accessoires, trouver une astuce de rangement pour les câbles, et fixer le tout.

Step 4 : Soigner les finitions (TODO)

• pose d'une couche de moquette en fond comme amortisseur + esthétique plus "finie", 
• colliers plastique pour bloquer les cables en position, 
• casiers en mousse découpée "pile poil" pour le stockage des objets mobiles. NB : la mousse pour flight case est hors de prix, on va essayer de trouver un équivalent pas trop cher.
• 
  
  
  coinceurs pour les câbles afin qu'ils ne s'emmêlent pas pendant le transport : de bonnes vielles pinces à linge !

Step 5 : Tester en "live"

Rendez-vous le 7 juin pour la soirée Terracotta ! Et comme bon développeur, je laisse le soin à Julien de béta-tester ;)

Quand on manipule des services web, des schémas XSD et des louches entières de XML, on rencontre des développeurs qui sont complètement perdus dans les concepts de namespaces. Une idée trop largement répandue est que le namespace donne l'emplacement du schéma considéré, idée basée sur l'utilisation courante d'URL pour définir ces namespaces, lesquelles pointent effectivement assez souvent sur le schéma considéré.

Petit rappel donc.

En XML, les namespaces permettent de mixer plusieurs grammaires dans un même document, on associe donc un identifie chaque grammaire (schéma XSD) un namespace, auquel on associe un préfixe utilisé dans les balises du document XML.

Le namespace est un identifiant de la grammaire XSD. Techniquement parlant, c'est une URI, soit un identifiant unique répondant à des contraintes assez simple, mais en aucun cas un lien pour la consulter.

Une URI (Uniform Resource Identifier [FR]) est juste un formalisme commun pour l'écriture d'identifiants portables. La principale chose à en retenir est qu'elle commencent pas "préfixe:", ce que la norme appelle le 'scheme" -- "programme" , ou "plan", d'après google translate, parfois traduit par nom de shéma, mais alors on peut confondre avec le schéma XSD ...

Les URL (Uniform Resource Locator) sont une forme particulière d'URI qui permettent de définir une localisation pour une ressource (les fameux liens hypertexte du web). On PEUT donc les utiliser comme identifiant pour les namespace XML, et c'est d'ailleurs pratique pour faciliter la vie des développeurs si ce lien pointe en effet vers le schéma XSD, seulement rien ne l'impose.

Une autre option, ce sont les URN (Uniform Resource Name), une autre variante des URI qui permettent de définir un nom, et non un emplacement, qui par définition peut changer.

Que choisir ?

L'intérêt apparent des URL comme namespace introduit une incompréhension qui n'est pas bénéfique. Par ailleurs, le risque de voir l'URL ne plus pointer vers le schéma pour X raison (changement d'hébergement, changement de nom de domaine ...) est perturbant.

Les URN sont a priori plus adaptées, mais pas très courantes. Il est pourtant plus sain de définir un schéma comme
  urn:schema:monprojet.org:Domaine/1.0
que comme
  http://monhebergementpourlemoment.free.fr/xsd/Domaine_1.0.xsd

Pour aider le développeur (via son éditeur XML préféré) il suffit d'exploiter le mécanisme de localisation des schémas lui aussi prévu par la norme :


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schema:monprojet.org:Domaine/1.0
                    http://qqpart.org/xsd/Domaine_1.0.xsd"

Vous noterez en passant que les namespaces choisis pour les normes XML sont des URL, ce qui participe très activement à la confusion...


Pas convaincu ? lisez cette (traduction de la) note officielle du W3C : http://www.yoyodesign.org/doc/w3c/uri-clarification/

Java 5 apporte son lot de nouveautés, entre autre l'autoBoxing. Sauf qu'il ne s'agit pas d'une évolution au sein de la JVM mais uniquement au niveau de la syntaxe et du compilateur, donc écrire :

Double d = ...;
truc.setValue( d ); // signature : public void setValue( double );

se traduit (en pseudo-code) dans le .class compilé par

Double d = ...;
truc.setValue( d.doubleValue() );

Je serais le 11 mai au ParisJug pour présenter en compagnie de mon Arnaud Héritier préféré une synthèse rapide des nouveautés de Maven 3. Rapide parce que le ParisJug ne nous laisse que 30 minutes, aussi nous avons choisi pour notre sujet une formule ... inhabituelle.

Si vous avez aimé le bouquin, le ton que nous allons (essayer de) donner à cette intervention devrait vous plaire. Et pour ceux qui ne peuvent se contenter de 30 minutes, un petit détour par la troisième mi-temps devra combler ce manque.

Infos, inscriptions, et toute ce genre de choses sur ParisJug.org.