new Blog( perso );

Certains sont surpris de voir que j'ai écrit un livre sur Maven et qu'en même temps je le critique. Et oui, je ne suis pas un évangéliste tout blanc tout noir, pour moi Maven a apporté des choses très positives mais n'est pas l'outil parfait, loin s'en faut.

Les points principaux apportés par Maven sont (ahma) :

• la standardisation de la structure des projets, rappelez vous le plaisir de greffer des morceau de build Ant d'un projet à l'autre ...
• le concept de dépôt de bibliothèques et de gestion des dépendances, avec la construction progressive de central, aujourd'hui incontournable,
• le mécanisme de plugins pour enrichir un build, avec une isolation des plugins (ce que ne faisait pas maven 1)

Mais ... Maven c'est aussi des points qui me déplaisent :

Le cycle de vie est extrêmement rigide et très, très compliqué à modifier (nécessite un nouveau packaging). Or il m'est souvent arrivé de regretter qu'il manque une phase pour y greffer un plugin, ce qui aboutit souvent à déclarer le plugin sur une phase inadaptée comme contournement. Exemple type : le compresseur JavaScript placé en phase "test" pour que le war soit construit avec des scripts optimisés (depuis est arrivé prepare-package, mais vous avez l'idée générale). On en arrive à hacker l'ordre d'exécution des plugins pour obtenir ce qu'on désire.

Le déploiement n'est pas atomique, loin s'en faut. C'est même pire que ça, il a lieu de manière morcelée lors d'un build multi-module. Si ça plante au milieu, une partie des artefacts est déjà déployée. Les connaisseurs auront reconnu le rôle tenu par le RedeployPublisher de Jenkins ... Alors bien sûr, Nexus pro comme Artifactory (peut être même Achiva ;P) proposent des solutions de contournement. On compense une défaillance de l'outil par un autre outil.

La gestion "one-shot" des métadonnées. Combien de bibliothèque ont été publiées avec un POM tout pourri ? Si les choses ont un peu progressé, il aurait été plus efficace d'avoir un mécanisme de version sur ces méta-données, en plus de la version de l'artefact, quitte à figer cette version lors de la release. De ce point de vue, héberger un repo maven sous forme de dépôt svn n'aurait pas été idiot, et lors de la release on aurait juste indiqué qu'on fait référence au méta-données du dépôt @révision1234.

Le POM sert à la fois de méta-données et de support du build. Combien de POM déployés contiennent des profils, des paramètres liés au développement ou aux environnements de test. A cumuler ces deux rôles, le POM se tire une balle dans le pied. Il faudrait découpler le build (profils, plugins, etc) des méta-données (dépendances, license, pré-requis, ...)

L'identification du dépôt d'un artefact. Si aujourd'hui je dépends de Hibrenate 4, que j'obtiens depuis le dépôt jBoss, dans 6 mois en voulant reconstruire mon projet, peut être aura t-il été publié sur central, ou sur l'un des (nombreux ?) autres repos que je déclare dans mon POM. Qu'est ce qui me garantit que c'est bien le même ? Deux options pour cela :

• indiquer explicitement, via un attribut supplémentaire sur dependency, le repo d'où je désire obtenir l'artefact, ce qui accessoirement éviterait d'interroger 36 dépôts
• fournir le hash SHA de l'artefact que je veux utiliser. Ca pourrait d'ailleurs complètement remplacer le groupId:artifactId:version, bien que ce ne serait pas super pratique.

Non, Maven n'est pas la panacée, mais il faut reconnaitre que les alternatives viables ne sont pas légions. Chacun ira de son commentaire sur Gradle, Rake, BuildR, ou truc-chose, si des choses intéressantes sont proposées elles sont très loin d'atteindre la maturité et le support par l'outillage qu'à Maven.

Wait and See ... peut être un jour un petit nouveau dans la cours des grand pour bousculer tout ça ?


  ________              ____   ____                 
 /  _____/_______ _____ \   \ /   / ____    ____    
/   \  ___\_  _ \ \__  \ \   Y   /_/ __ \  /    \   
\    \_\  \|  | \/ / __ \_\     / \  ___/ |   |  \  
 \______  /|__|   (____  / \___/   \___  ]|___|  /  
        \/             \/              \/      \/   
                                                        v 0.0.0.2 

http://cfalguiere.wordpress.com/2011/09/17/le-jug-summer-camp-cest-fini-pour-cette-annee/
http://mimah35.blogspot.com/2011/09/jugsummercamp.html

Mon bouquin Apache Maven est sorti fin août sous une nouvelle robe avec un contenu révisé :

• reprise du texte pour les boulettes qui nous avaient été signalées;
• une mise à jour générale pour Maven 3. Les parties spécifiques sont signalées, ce livre couvre donc aussi bien le bon (?) vieux Maven 2 que son remplaçant;
• un nouveau chapitre sur OSGi - pour lequel je remercie Pascal Leclercq - et Java modules, pour lequel nous avons sorti la e-boulle de cristal;
• une reprise du chapitre sur les alternatives à Maven, où nous tappons moins sur Gradle et laissons (un peu) la parole à Grégory pour défendre son protégé;
• une mise à jour notre vision des rapports Apache / Sonatype d'après les rebondissement récents, moins angélique que pour la première édition. La difficulté ici a été que le discours de Sonatype a pas mal bougé pendant la rédaction;
• nous avons sans scrupule gardé la préface que Jason a plus ou moins relue, ou fait relire, a défaut de l'écrire;
• une couverture orange. C'était un gros défaut de la première version.

Ok, ce n'est sans doute pas une nouvelle de première fraîcheur pour tout ceux qui ont abandonné les plages ensoleillées (?) du mois d'août pour déposer les gosses à l'école lundi et retourner au taf, mais



C'est surtout la fin du calme relatif de cet été qui fait que ce blog etait bien silencieux et que je suis resté douillettement chez moi à bosser peinard loin des tumultes de la vie moderne. Mais ce monde de cinglé qui vit à 100 à l'heure me rattrape, aussi la rentrée va être chargée; jugez vous-même :

Le 16 septembre, rendez-vous au JugSummerCamp. Ne me dites pas que vous ne savez pas ce que c'est ou que vous avez oublié de vous inscrire, c'est la conférence à ne pas louper.


Le 22 septembre Ippon (en la personne de Julien Dubois) m'invite pour un IppEvent consacré à la forge logicielle, à la maison et dans le cloud, comprenez un condensé de mes sessions du JugSummerCamp 2010 et 2011 avec une démo si le Net fonctionne. Dépêchez-vous les places partent vite.


Le 23 septembre, tant qu'à être sur Paris me direz-vous, c'est l'OpenWorldForum qui m'accueille pour un talk sur Jenkins et son modèle open-source "à part". Si vous étiez au BreizhCamp vous connaissez ce sujet que j'avais préparé un peu à l'arrache, j'ai eu l'occasion depuis de le peaufiner en discutant avec Kohsuke.


Semaine 39, rien - non ? si !

Le 3 octobre, c'est la rentrée et l'anniversaire du BreizhJUG, avec une soirée Jenkins User Meeting. Au programme : des pipelines de build, des tests Selenium, un peu de CloudBees (!) et un cours de développement de plugin live ! Pour plus d'infos, inscrivez-vous à la liste de diffusion du JUG.


Le 6 octobre, hop hop on enchaine avec l'Agile Tour Rennes (les gars, faudra penser à changer de logo, on croirait une conf JBoss !). Encore du Jenkins, mais cette fois vu sous l'angle de l'agilité : adaptation, processus légers, cycles courts, et quelques réflexions dont j'aimerai débattre avec vous.

Le 20 octobre, en espérant avoir un peu de soleil - ce qui commence franchement à manquer; s'il ne pleut paraît-il que sur les cons, il faut croire que j'en tiens une couche - petit tour à Nice pour le RivieraDev. Cette fois je sors le grand jeu puisque je présenterais GWT2, CloudBees et que j'irais donner un coup de main à Grégory pour vous convaincre d'utiliser Gradle (ou pas).



Le 27 octobre, un petit tour à Lyon pour présenter Jenkins au FOSSa, selon un axe un peu différent : open-source et business, présentation de l'offre commerciale de CloudBees basée sur Jenkins et de la synergie avec la communauté.


Heureusement, en novembre j'aurais droit à une semaine de repos (?) à Devoxx.


Bref, vous l'aurez compris, si vous voulez me croiser pour avoir un autographe sur votre exemplaire de Apache Maven - seconde édition tout fraîchement sorti des presses que même moi je ne l'ai pas encore, ce n'est pas l'occasion qui manquera !

Les temps changent.
Lorsque je travaillais en SSII, mon CV était comme des milliers d'autres basé sur un ronflant titre d' "Expert Java EE confirmé" et incluait tous les mots clés (Spring | Hibernate | GWT | Maven, ...) qu'on retrouve aujourd'hui même sur les CV de débutants. Je pouvais me targuer de plus de 10 ans d'expérience, et bien sur appuyer mon expertise sur la publication de mon bouquin. Cependant, lorsque j'ai quitté Cap j'ai été surpris de voir que, malgré tous les points différenciateurs que j'essayais de mettre en avant, l'équation habituelle s'appliquait :

Lorsque j'ai postulé chez CloudBees, j'ai poussé le même CV. Etant rédigé en Français, je ne pense pas qu'il ait été transmis en interne (j'aurais du prendre le temps de le traduire mais c'est allé très vite). Arrivant pile au moment où un besoin se faisait sentir, les grandes lignes de mon expérience autour de Maven et de la forge logicielle ont suffit pour passer un entretien sur skype avec le responsable technique de DEV@Cloud. Autrement dit, j'aurais presque pu postuler par twitter :P

Lors de cet entretien, qui servait aussi à vérifier que mon niveau d'anglais scolaire ne poserait pas de problème par la suite, on m'a demandé si je connaissait les API Amazon, Ruby et si j'avais développé des plugins Jenkins. Trois réponses négatives, avouez que ça ne part pas très bien. Cependant, le contact est très bien passé et la question suivante était nettement plus intéressante :


Voilà un élément de différenciation qu'aucun CV ne peut remplacer. Vous pouvez être un expert de classe internationale de Hibernate+Spring, 1000 autres CV prétendront la même chose. Par contre, le code que vous rédigez est votre marque de fabrique. Dans mon cas, le plugin gwt-maven et Fonzie sont deux projets dont je suis fier et qui ont fait mouche. Ils sont avant tout la preuve de mon autonomie et de ma capacité à assimiler Amazon, Ruby, Jenkins et tout le reste lorsque le besoin se fera sentir.

Peut-on extrapoler ce cas particulier au contexte du recrutement en France ?

Le succès de l'express-board en est la preuve. Les candidats ne veulent plus être harcelés par les recruteurs des grandes SSII parce qu'ils ont mis "Java" sur leur profil Monster. Les recruteurs qui cherchent un profil pointu et passionné ne veulent pas perdre 4 mois à enchaîner les entretiens. D'autres critères sont nécessaires.

Ippon avait ouvert le bal en proposant un recrutement sur GitHub. Il fallait donc savoir faire un clone de leur repo, builder l'appli Maven pour avoir accès à l'adresse de recrutement. Ce filtre qui peut paraître simpliste a eu deux effets bénéfiques : d'une part le buzz (indispensable) d'autre part un premièr niveau de sélection.

Je citerais ici Kohsuke sur le mode de "recrutement" de Jenkins :
"Etre contacté par des développeurs qui arrivent à passer un build maven multi-module complexe et proposent un patch, c'est déjà la preuve qu'on a affaire à des personnes de qualité"

Le filtre est certes assez léger mais il n'est pas aussi insignifiant que vous autres, lecteurs de ce blog, pourriez le croire (savoir s'informer via les blogs est aussi un mode de filtrage qui sélectionne beaucoup).

Plus récemment, Pod-Programming (start-up Rennaise pleine d'avenir) a posté une annonce sur l'Express-Board qui va plus loin : il ne s'agit pas juste de passer les difficultés techniques que le projet github proposé nous impose pour obtenir l'email de recrutement, cette fois il faut le forker et démontrer son talent. Pas exactement la page blanche, mais presque. Au final, seulement une poignée de candidats, mais avec un excellent niveau. Le recrutement a finalement permis de sélectionner Michel, co-organisateur du BreizhJug, vainqueur du concours Rennes OpenData, développeur de l'appli Android BreizhCamp, autrement dit un très bon choix :)

Du point de vue de la rentabilité du recrutement on ne peut espérer mieux. Du point de vue des candidats, on fait mieux que le CV anonyme : pas de diplôme ou de niveau d'expérience à prouver pour passer un entretien, il faut "juste" montrer qu'on est capable de faire le job.

Je ne crois pas que ces deux cas deviennent une généralité, mais il est clair qu'une façon de se démarquer est de devenir un développeur "public" : le code que vous produisez pour votre entreprise/client est

1. rarement publiable
2. dicté par des règles qui ne vous sont pas propres
3. généralement pas fondamentalement passionnant

a contrario, un projet open-source même insignifiant cumule les avantages d'être :

1. public et librement diffusable (par définition)
2. le reflet de vos capacités, niveau d'exigences
3. directement lié à ce qui vous plait

Ca tombe bien, de nombreuses "plateformes" proposent des mécanismes de plugins qui permet de proposer de la plus-value très ciblée sans devoir investir un temps fou à comprendre les rouages internes : plugin Jenkins, Maven ou Eclipse selon vos habitudes, il y a matière à s'exprimer.

S'exprimer, justement, c'est aussi un élément de différenciation. Avec l'explosion des JUGs en France (19 à ce jour), il devient presque "facile" de trouver un public pour présenter quelque chose. N'hésitez donc pas, ça aussi c'est un élément de différenciation et ça peut intéresser un recruteur : quelqu'un qui s'exprime en public peut évidement aider à vendre mon produit et à communiquer avec mes clients ;)

Le BreizhJug organisera par exemple en octobre un Jenkins User Meeting, sous forme de quickies : 15 à 20 minutes pour proposer un plugin, une utilisation, une réflexion, ce-que-vous-voulez autour de Hudson/Jenkins. 15 minutes c'est vite passé, et c'est l'occasion de présenter en public son savoir faire même si on est pas un caïd du sujet. Si ça vous intéresse, proposez un sujet à team@breizhjug.org

Moralité :

Nous verrons encore longtemps passer les annonces sur Monster "développeur Java/EE ...". Inutile de donner dans la surenchère des "Expert Sénior Avancé" qu'on voit fleurir dans le monde Java,  ou alors faites le avec humour : "Maître Jedi" par exemple. Mon rôle de "Senior Engineer" chez CloudBees me convient très bien pour caractériser mon profil.

Si vous espérez trouver le poste de rêve, motivant, dans une boîte innovante, tout ça, n'attendez pas que ça tombe tout cuit dans les annonces de ouest-job. Il faudra le moment venu savoir vous mettre en avant parmi des centaines de candidats potentiels. Même si vous n'y voyez qu'un investissement professionnel, rejoignez le monde opensource; vous y trouverez de toute façon tant de choses que le côté "CV" passera vite au second plan. Enfin, prenez la parole, en interne (coding dojo ?), au JUG, participez aux conférences, barcap, opencoffee - bref faites partie du mouvement actuel plutôt que de vous laisser encrouter dans un poste d'expert fonctionnel sur un projet pharaonique de 4 ans (un exemple juste pris au hasard comme ça).

Un mois après le BreizhCamp, il est temps de faire le bilan

Vous étiez prêt de 250 à vouloir vous inscrire, pour 200 places disponibles. Pour une première, c'est une belle réussite !
Une grand majorité d'entre vous venait du monde Java, avec tout de même une participation appréciable des autres communautés. 62% d'entre vous ont d'ailleurs déclaré participer à une communauté locale, et 8% à une communauté online en mal de se concrétiser IRL. Pour ceux-là, contactez le Granit ou la Cantine Numérique pour organiser un premier meeting, histoire de tenter le coup.

malgré cette domination "Java", vous avez tous joué le jeu d'aller voir si l'herbe est plus verte à côté, de découvrir ce que font les autres, de participer au brassage des connaissances :

Faire appel à Sébastien pour la keynote a semble t-il été une bonne pioche, en rapport avec vos attentes pour cette conférences. Ceux qui ont en plus suivi son "cours du soir de Git-itude" connaissent désormais l'étonnante capacité de Mr Douche pour tenir son public pendant des heures :P

A de rares exceptions, tous les sujets proposés on trouvé leur auditoire. Le breizhCamp est aussi l'occasion de découvrir des sujets plus inattendus par pure curiosité.
Le compte rendu de chaque tranche horaire ressemble d'ailleurs au graphique ci-dessous; votre retour est globalement très positif avec peu de déçus

La pause déjeuner, malgré le temps exécrable ("breton" diront les mauvaises langues, mais ce jours là il pleuvait sur tout le monde), vous a plutôt laissé un bon souvenir, bien qu'un petit creu.
Enfin, sur les pistes d'amélioration, je note que vous êtes tout aussi intéressés par des sessions plus courtes, plus longues, des périodes d'échanges plus longues ... il va donc falloir réfléchir à une formule plus modulaire

Pour ceux qui en ont marre de la vie en SSII, une start-up Rennaise propose un poste de Project-Lead / Guru Java, présenté sur l'express-board. Pour ce démarquer, ils ont choisi de lancer un concours, j'adore l'idée.


Je vous laisse le soin d'entrer en contact avec eux pour en savoir plus, mais pour être un peu dans la confidence (et oui, je sais tout je vois tout :P), le jeu en vaut la chandelle si vous chercher un boulot vraiment innovant et motivant.

Bonne chance !

Suivez les aussi sur @PodProg

Voilà une annonce pleine de bonnes intentions, mais qu'en est-il concrètement ?

Les démos, comme celle de Spring/VMWare lors de What's Next pour CloudFoundry ne nous montrent que l'abstraction faite sur la gestion des infrastructures, OS et middlewares : truc app dans une console, et hop j'ai une appli en ligne, truc db et hop, j'ai une base MySQL... Les utilisateurs de Heroku doivent bien rigoler de nous voir admiratifs devant ce spectacle !

Il y a un second aspect qui est nettement plus délicat à percevoir, qui du coup fait moins l'objet des démos, et qui sera - j'espère - au centre des discutions de l'expert group Java EE 7, que Spike Washburn (celui qui a conçu RUN@Cloud) va rejoindre : la gestion multi-tenant. Je fais mon savant là mais je n'ai compris ce concept que récemment lorsque mes collègues de CloudBees m'ont fait une explication de texte ;)

Pour expliquer ce concept, nous allons ensemble - virtuellement - construire un SaaS. Je vais donc dérouler les différentes variantes de ce que j'ai pu mettre en oeuvre.

1. Serveur mutualisé

Dans le but de réduire les coûts de mise en oeuvre et d'administration, c'est la première chose qu'on met en place. Dans mon cas, un proxy Internet pour les dépendances Maven. On réserve donc une bonne bécane et on installe un repository manager, Archiva dans mon cas (je participais à son développement à cette époque).

Avantage : une seule instance, c'est simple à comprendre et à administrer
Inconvénients : pollution mutuelle entre utilisateurs, qui ont tous une librairie machin à installer. En gros, on impose à tous une logique commune, ce qui fait préférer à certains d'avoir leur propre dépôt et de le gérer eux-même pour retrouver une certaine liberté même s'il faut payer le coup de mise en place.

Je ferais un parallèle avec SVN vs Git : le fonctionnement du système centralisé s'impose à tous et devient pénalisant.


2. Clonage de VM

Ici on met à disposition un environnement type qu'on est en mesure de mettre en place en quelques minutes. L'utilisateur peut alors adapter à ses besoins un canevas de base, qu'on aura éventuellement bridé si nécessaire, ou au moins préparé avec les pratiques généralement acceptées. Exemple type, une image VM Linux avec Git/svn + Nexus + Jenkins + Sonar + Java/Ant/Maven préinstallés.




3. Création automatisée des VM

On monte d'un cran et on exploite les outil de déploiement continu pour construire nos images de VM à partir de "recettes" (pour reprendre le vocabulaire de Chef). La mise à jour d'une recette se traduit par une mise à jour de toutes les instances, et l'élimination de la redondance dans les tâches d'administration. Autre avantage par rapport au clone, il est possible d'utiliser un OS différent vu qu'on a scripté l'installation.

Le BreizhCamp est déjà commencé avec l'atelier Git que Sébastien Douche anime en ce moment même, avec comme objectif simple de sauver le monde.

Surprise de la programmation des conférences de demain, et je vous jure que je n'y suis pour rien, j'animerais en fin de journée une session en concurrence avec celle de Julien Dubois, ce qui nous rappèle d'excellents souvenirs du JugSummerCamp 2010 !

Aura t-on droit à la revanche de Julien ? J'en doute, car sincèrement, qui irait voir une n-ième session barbante sur Hibernate, NoSQL et le Cloud, alors que vous pourriez conclure la conférence sur une présentation sur la gestion de projet atypique de Jenkins et quelques clés de son exceptionnel succès.

La réponse de Julien sur son blog ne devrait pas tarder ;)

CloudBees sera présent à la conférence JAX, fin juin à San José.


San José, c'est beau, mais c'est loin (comme dirait un ex-président bien connu), aussi ce n'est pas de la conférence que je vais vous parler mais du vote que les organisateurs proposent aux internautes sur http://vote.jax-awards.com/, destiné à élire la technologie, la compagnie et la personne la plus innovante de l'année dans le microcosme Java. Je n'ai aucune idée de la façon dont a été faite la short-list qui nous est proposée, mais je suis fier d'y trouver CloudBees, au côté de pointures comme Atlassian et RedHat.

Le système de vote n'utilise pas d'authentification des utilisateurs et pourrait donc faire l'objet de truandages  divers, mais il permet de voter sans laisser votre eMail dans une liste de spam. Votez si possible pour une société sympa, innovante et bourrée de mecs cools, mais bon je ne voudrais pas vous influencer ;)

Si vous n'arrivez pas à vous décider, vous pouvez aussi rejoindre Sacha Labourey lors d'un webinar mercredi prochain pour une présentation de CloudBees et une démo de la chaine code -> build -> tests -> run "dans le cloud". C'est en anglais, mais avec ce petit accent Frenchie si particulier que le monde entier nous envie :P

Plus que 10 jours pour moi avant de rejoindre l'équipe CloudBees, je trépigne d'impatience ! Des chantiers passionnants à affronter, mais sans doute le plus beau challenge qu'il m'ait été offert de relever.

Cette semaine, vous n'avez pas pu y échapper, c'était What's Next. Je n'ai pas pris le temps de blogger sur le sujet parce que j'étais bien trop occupé à profiter à plein de ce grand moment organisé de main de maitre par Zenika, et à discuter avec les nombreux Geeks de notre microcosme. Si vous voulez en savoir plus lisez le blog de l'autre Nicolas, moi la nuit j'ai besoin de dormir au moins un peu ;)

Autant les conférences que les échanges très fertiles qu'on a lors de ces rencontres sont une véritable mine.
Il y a bien sur les aspects techniques : J'y ai, entre autre, découvert la commande Git ReReRe (j'ai d'abord cru que Benoît Courtine se foutait joyeusement de moi avant d'aller vérifier) qui m'a obligée à modifier en urgence ma présentation (voir plus bas).
Il y a aussi les aspects sociaux, avec toutes ces personnalités connues et moins connues qui font la richesse de notre milieu. Une idée d'ailleurs pour les prochaines conférences : en plus des noms , mettez le compte twitter des participants sur les badges, nous sommes nombreux à nous connaitre par ce biais sans le savoir.

Moralité : si vous n'y étiez pas, dites vous bien que vous avez raté un grand moment de geekitude et de techno-remise à niveau. Si j'ai du poser deux jours de congé pour en profiter je suis très loin de les regretter !

J(enkins)UG
Non content de participer activement, comme toute l'équipe Zenika, à l'organisation (irréprochable) de What's Next, Grégory Boissinot nous a offert en cette fin de semaine un concentré de Jenkins. A peine remis de ces 2 jours de conférence plutôt denses, nous avons attaqué par un Jenkins User Meeting vendredi soir, en petit commité dans les locaux de Zenika. Sous forme de mini-conf nous avons ainsi pu présenter notre utilisation de Jenkins, nos bonnes pratiques, voir nos contributions pour certains. Un moment d'échange riche et plein d'enseignements.

Une idée sympa et ouverte à tous, à retenir pour des événements locaux.

Pour ma part j'ai présenté mon approche de l'intégration continue couplée aux multiples branches Git, en tentant une démo qui a été un vrai massacre à la bonaldi (sans quoi ce ne serait pas une démo me direz vous).  Mais l'événement de cette rencontre c'était la présence de Kohsuke Kawaguchi de passage à Paris, un gars étonnant, qui du haut de son mètre 90 vous parle d'une voix ultra grave, pas vraiment le Japonais des images d'épinal.

Après une courte nuit de repos, nous enchaînons par un hackathlon dans les locaux de Zenika. Le hackathlon, c'est quelques "hackers"ou apprentis-hackers (9 dans notre cas, on a perdu du monde en route semble t-il) qui se regroupent pour travailler sur des sujets communs et surtout s'entraider. En une petite journée j'ai appris de nombreux détails du développement Jenkins, avec les explications très précises de Kohsuke, tandis qu'Arnaud s'attaquait à une amélioration de l'intégration Maven, enchaînant les Pull Request, que Gregory et Frédéric discutaient sur la complémentarité de leurs plugins respectifs de gestion de configuration et que Dimitri prenait un cours particulier de développement Jenkins avant de se lancer dans une amélioration de l'usabilité (oh le joli mot) de l'outil.

Chacun à son niveau a beaucoup de chose à apprendre des autres et autant à leur apporter. J'ai ainsi aidé Dimitri à configurer son compte GitHub et à monter sa Pull Request tandis qu'il m'a déplombé la configuration i18n de mon editeur de Ressources sous Intellij Idea. Kohsuke était évidemment un acteur précieux de cette journée; accessible, toujours agréable et très ouvert à toute forme de discussions, il nous a ouvert les portes de son bébé tout en nous laissant une complète liberté de notre sujet.

Le modèle de gestion de la communauté Jenkins, unique à ma connaissance, à cette particularité : même le premier newbie venu (tiens, moi par exemple) peut demander les droits sur GitHub et voir où sa contribution pourrait être bénéfique. La plateforme Jenkins à un tel potentiel que chacun y trouve rapidement de quoi faire, quelque soit sont niveau technique. Etant donné le public déjà très limité prêt à se lancer dans l'exercice, nous donner ainsi carte blanche est finalement peu risqué car chacun de nous se sent alors responsabilisé et ne prend pas le risque de modifier quelque chose qu'il ne comprend pas sans demander un avis. C'est ainsi que Jenkins a monté sa très large communauté de plugins et de contributeurs, bien loin du modèle de nombreux autres projets opensource pour lequel le billet d'entrée est très sélectif et en décourage beaucoup. Et après tout, par définition le SCM permet au besoin de revenir en arrière et d'éliminer une maladresse, régression, indélicatesse ou grosse boulette.

En sortant de cette journée, on a la sensation d'appartenir pleinement à une communauté, avec des
liens étroits - twitter peut en témoigner - une grande complicité et des valeurs fortes; on a les réponses à de nombreuses questions, et surtout l'envie d'aller plus loin; on en arriverait presque à penser qu'un monde meilleur est possible :P

Conclusion
Chacun de nous a en tout cas apprécié ces moments étonnants et d'une richesse incroyable. Un grand merci à Zenika d'avoir organisé ce beau rassemblement, à Kohsuke pour sa disponibilité alors qu'il accumule le décalage horaire, et bien sur à tous les geeks qui font de notre communauté Java française un terreau fertile.

Rendez-vous au breizhCamp pour certains, au JugSummerCamp et/ou à Devoxx pour les autres, en tout cas ne laissez plus passer ce type d'événement "juste" parce que ca tombe avant un week-end et qu'il y a un barbecue de prévu chez tonton André. Remontez-vous le moral et le niveau technique après une journée de m... sur un projet en TMA en développant sur quelques minutes de temps libre votre propre plugin jenkins/maven/graddle/idea/Androïd ou que sais-je, au moins pour être fier d'un truc sympa, dans une techno innovante, et qui pourrait même vous mettre faire entrer dans ce qu'on commence à appeler la  "french Mafia" (terme que l'on doit à @olamy il me semble), avec son accent inimitable quand elle s'exprime en anglais - soyons en fiers et faisons la grossir.

D'ici quelques semaines, je quitterais mon poste au sein d'Orange Business Services (date non encore fixée). J'y ai rencontré des gens passionnés et passionnants, mais je vais donner une tournure nouvelle à ma carrière professionnelle en m'installant dans les nuages.

• Avec RUN@Cloud, CloudBees se trouve coude à coude avec VMWare CloudFoundry, Amazon Elastic BeansTalk, RedHat OpenShift ou encore Google AppEngine.

• Avec DEV@Cloud, CloudBees propose de virtualiser la forge logicielle. Son produit phare, articulation de la forge, c'est l'intégration continue Jenkins "as a Service". Des plugins spécifiques permettent de tirer parti de la virtualisation (exécuteurs à la demande par exemple) et des partenariats permettent de l'enrichir avec des offres d'inspection continue Sonar "as a Service" ou des tests Selenium (SauceLabs) "as a Service", et bien plus encore à l'avenir. 

• Enfin, une offre commerciale plus classique pour un Jenkins custom enrichis de plugins maison (Nectar) maintenu par Kohsuke Kawaguchi en personne, en concurrence directe avec le Hudson Profesionnal de Sonatype.

Mon poste sera majoritairement focalisé sur le support, en contact direct avec l'engineering, mais aussi avec de nombreuses autres casquettes dans le développement (le temps de rentrer dans le code), du consulting, de l'assurance qualité, de la formation ... bref, un poste "couteau suisse" qui colle très bien à mon passif.

Particularité de CloudBees, la société elle même est dans le nuage : je travaillerais donc à domicile la majorité du temps, en collaboration avec mes collègues répartis de la west coast jusqu'en nouvelle zélande - l'occasion aussi de renforcer mon Anglais qui manque cruellement de pratique.

J'espère avoir le plaisir de vous rencontrer comme client, partenaire, lors du BreizhCamp, de What'sNext ou Devoxx, ou simplement à l'occasion d'un JUG sur un sujet "forge logicielle", qui devient donc définitivement ma marque de fabrique ;)

Dans l'épisode précédent, Sonatype s'était allié à Oracle pour supporter Hudson, tandis que la rébellion s'organisait pour développer Jenkins avec le succès qu'on a pu constater.

Aujourd'hui, Oracle annonce vouloir donner Hudson à la fondation Eclipse (avec le soutien de Sonatype et VMWare), acceptant ainsi au final les conditions qui étaient réclamées par la communauté lors de la "crise" :

• disposer d'un modèle de gouvernance sans prédominance d'une société
• libérer le nom "hudson" de toute emprise en le léguant à un organisme indépendant

Ces conditions, à l'époque, se sont heurtées à un "non" sans appel de la part d'Oracle. Aujourd'hui, sans doute calmé par le succès de Jenkins fàce à un Hudson qui a du mal à exister autre part que sur le blog de Sonatype qui met en avant sa version "pro", Oracle change son fusil d'épaule.

On pourrait presque imaginer les deux branches fusionner à nouveau dans un grand moment de réconciliation, mais c'est assez peu probable.

D'une part, cette décision arrive bien tard. Jenkins a évolué depuis la scission, la communauté a pris ses aises et choisi son modèle de gouvernance. Il n'est pas du tout évident que celui de la fondation Eclipse soit aussi souple :P

D'autre part, la querelle avec Oracle a laissé des cicatrices; s'il ne s'agit pas de régler ses comptes, les principaux acteurs se voient mal travailler main dans la main comme si de rien n'était.

Enfin, passer le code de Hudson dans la fondation Eclipse ne se fera pas en deux minutes. Le processus d'incubation de la fondation est très strict (pour ne pas dire lourdingue), en particulier sur les aspects propriété du code et compatibilité des licences. C'est pour cela d'ailleurs que l'IDE Eclipse n'a pas de support SVN natif, l'implémentation Java SvnKit étant sous licence LGPL. Sans parler d'ailleurs du code pour lequel Oracle n'a pas a priori la propriété intellectuelle (pensez aux contributions de Kohsuke après qu'il ai quitté Oracle).

L'idée de voir Jenkins hébergé par la fondation Apache a été évoqué à un moment pour donner plus de visibilité au projet et lui assurer un cadre juridique solide. De la même façon, Jenkins devrait passer par l'incubateur Apache et résoudre les mêmes soucis de propriété intellectuelle et de licences.

Au final, cette contre-attaque est délicate à pronostiquer. Avec les moyens de Oracle + Sonatype + VMWare et la force de communication liée à l'aura de la fondation, Hudson peut rester sur les rails et progresser de manière intéressante. Dans le même temps, Jenkins démontre sa capacité à avancer vite et bien, avec :

• un nouveau processus de release à deux vitesses, avec une version "stabilisé" par tranche de 3 mois n'incluant que les corrections majeures
• plus de soin dans la gestion de la compatibilité, avec un mécanisme de test des plugins sur la version N+1 (action menée par notre compatriote Frédéric Camblor)

Il nous reste à attendre le prochain épisode. Je ne pense pas que le Jedi veuille bien revenir pour détruire l'étoile noire, et les deux outils continueront probablement à vivre côte à côte pendant longtemps. En tout cas, nous aurons assisté à un formidable gâchis depuis l'intervention de l'empire et de son allié dark vador (je vous laisse mettre des noms en fàce par vous même).

C'est aujourd'hui que s'ouvre l'inscription du BreizhCamp

La salle qui nous accueille étant strictement limitée à 200 places, nous sommes contraints de mettre en place un système d'inscription. Si les Rennais ne sont pas coutumiers de ce principe, nos amis Parisiens savent que les places pour ce type d'événement partent très très vite, aussi ne trainez pas trop ...

Et si votre employeur rechigne à vous libérer une journée, vous pouvez faire valoir votre D.I.F pour nous rejoindre.

infos et programme : http://www.breizhcamp.org/
inscription : http://jugevents.org/jugevents/event/36125

Ceux qui suivent ce blog connaissent déjà Fonzie, mon petit hack pour éliminer l'écriture de toute la couche persistance d'une application JavaEE dans le cas des requêtes simples, qui constituent d'après le projet sur lequel il a été utilisé plus de 90% des cas d'utilisation.

Avec une API puissante, JPA nous permet de construire des requêtes et du code d'accès à la base pour quasiment tous les cas de figure (bien sûr il reste quelques exceptions, sinon le groupe de travail JPA 2.1 serait au chômage). Seulement, cette API est parfois surdimensionnée pour des requêtes simples, de la forme select * from Truc where bibi = 'foc'

Fonzie était inspiré par Grails (GORM), mais n'est pas, loin s'en faut, la seule tentative de simplifier le codage des accès à la base de données. Il y avait déjà Hades, présenté il y a deux ans à Devoxx, qui permet de déclarer un Repository sous forme d'interface et de laisser le framework analyser les noms de méthodes pour en déduire les requêtes. Il y a depuis peu Spring-Data et son module JPA qui reprend la même idée avec la force de frappe de SpringSource/VMWare.

C'est bien, mais certains (j'en suis) regretterons que tous ces facilitateurs ne valident pas les requêtes définies par les programmeurs. Il faut attendre l'exécution pour que le framework nous indique qu'une méthode ne peut être interprétée. Un refactoring de trop et hop, tout plante.

Pour répondre à cette attente il y a donc, depuis JPA 2.0, l'API Criteria. Contrairement à Hibernate Criteria, celle-ci est totalement type-safe et valide la construction des requêtes dès la compilation. C'est donc une très bonne chose a priori. Sauf que ... Criteria s'impose de couvrir 100% des capacités de JPQL, et aboutit à une syntaxe extrêmement lourde et très peu lisible; jugez plutôt, pour la même requête pourtant triviale :

CriteriaBuilder cb = em.getCriteriaBuilder();
        CriteriaQuery<truc> query = cb.createQuery(Truc.class);

        Root<truc> truc = query.from(Truc.class);
        query.where(cb.eq( truc.<string>get( Truc_.bibi ), "foc" ));

        TypedQuery<truc> tq = em.createQuery(query);

L'informatique semble avoir horreur du vide, aussi un framework se propose de combler ce manque de lisibilité. L'idée est de générer (avec un annotation processor Java6) un métamodel qui soit spécifique aux requêtes QueryDSL (les classes Q*), et pas juste le métamodel "neutre" défini par JPA (mais qui par contre pourait servir à d'autres frameworks ... si l'API était sortie du package javax.persistence). QueryDSL, qui d'ailleurs peut accéder à bien plus que JPA, propose de construire des requêtes avec une excellente lisibilité, et 100% type-safe :

import static QTruc.truc;

   public List<Truc> getBibiFoc() {
        return from( truc )
              .where( truc.bibi.eq( "foc" ) )
              .list( truc );
   }

C'est pas beau ça ? Aux parenthèses près, on se croirait sous .Net en train de coder avec LINQ !
Alors, évidemment, il est probable qu'en creusant un peu queryDSL ne supporte pas 100% de JPQL, et ne permette pas de faire un LEFT OUTER JOIN sur une Map d' Embeddable, mais en même temps, le jour où j'aurais vraiment besoin de ça, ce n'est pas de coder le Repository qui exécute cette requête qui va me coûter mais plutôt de comprendre comment on a pu pondre un modèle pareil...

Si vous me suivez sur twitter (@ndeloof) vous savez que je suis papa pour la troisième fois. Oui, annoncer une naissance sur twitter c'est bien un truc de geek, je suis d'accord avec vous, mais je me sens moins seul quand je vois vos messages de félicitation. Celui de Laurent m'a bien fait rire :

public class HuitiemeMerveilleDuMonde implements Bebe {
 
    @Override
    public String getNom() { return "DE LOOF"; }
 
    @Override
    public String getPrenom() { return "Mat :-)"; }
 
    @Override
    public Sexe getSexe() { return Sexe.GARCON; }
 
    @Override
    public double getTaille() { return 53.0d; }
 
    @Override
    public double getPoids() { return 3.400d; }

    @Override
    public String getFelicitations() { 
        return "BRAVO au papa et bon repos à la maman..."; 
    }
 }

Ceci dit, nous sommes ici sur un blog technique, et Laurent se désole de ne pouvoir faire de l'héritage multiple. Je lui propose donc d'utiliser l'AOP !

@Aspect
public class Nananere {

    @Before(" execution( +Parent.dormir() )" )
    public void ouin_ouin() {}
}

Merci à tous

PS: non, très bizarrement, nous ne l'avons pas appelé "Jason"...

UPDATE:
J'apprend à l'instant que ce billet n'est qu'un vague réchauffé de celui-ci. Désolé, je n'ai pas pris le temps de vérifier mes sources pour une fois

Mon twitter (1) me pousse cet article très intéressant : http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/

On y découvre le mode de fonctionnement de Facebook, ou comme le géant du web utilise la culture geek pour piloter ses développements. Ce que je note, c'est l'importance et la liberté données aux ingénieurs, et la contrepartie : l'engagement qu'on leur réclame.

Je vais tenter de résumer l'article en quelques lignes (en tout cas, les points qui on retenu mon attention...)

Facebook ce sont des ingénieurs, triés sur le volet, qui bossent en totale autonomie sur le sujet qui leur plait, avec éventuellement un Product Manager qui essaie de leur souffler des idées. Un PM pour 7 à 10 développeurs, ça me laisse rêveur - on aurait presque l'inverse en France parfois. Chaque développeur a une semaine pour monter son truc, de l'UI au backend. Les premières semaines dans la boite, le "bootcamp", leur permet de découvrir tous les rouages du site et d'être autonome par la suite - pour ceux qui arrivent à suivre. Quand on vous dit "triés sur le volet"...

Cette liberté totale et le manque d'emprise des PM sur le projet est à contre courant de tout ce que j'ai pu rencontrer jusqu'ici :) D'un autre côté, avec un cycle de release très rapide, ça ne doit pas être aussi anarchique qu'on pourrait le croire a priori. Sur des projets de 6 mois évidemment ce serait ingérable, mais si on compte en jours ?

La contre-partie de cette très grande liberté est que les développeurs sont ici partie prenante du projet avec une très lourde responsabilité. Sans doute facilité par une connaissance de l'ensemble du SI et pas juste d'une brique isolée, les ingénieurs assurent le reporting, ils sont le contact direct pour toutes les questions relative au projet. Autrement dit, ils incarnent implicitement le rôle de PM. D'autre part, il y a le mardi.

Le mardi, c'est le jour de la mise en prod - oui, une par semaine, ça surprend toujours tant cette notion  est lourde dans nos contextes traditionnels. Tout les développeurs qui ont introduit du code doivent être présents sur site et disponibles. Ne pas répondre aux demandes des Ops et/ou ne pas supporter un bug détecté dans son code est un motif de licenciement. Et avec 60.000 serveurs à mettre à jour, il doit y en avoir quelques unes des demandes de la part des Ops !

On rentre dans une logique différente, un esprit de responsabilité que la culture MOA/MOE, forfait, prestataire nous a fait perdre : on ne développe pas juste du code, on développe du code qui doit tourner en production. La logique DevOps semble particulièrement mise en pratique chez Facebook.

Pourrait-on appliquer cela ailleurs ? 

Je vous vois venir, je ne parlerais pas de mon cas personnel. Par contre, globalement il y a des lessons à retenir :

• On ne motive pas des développeurs en les infantilisant. Les ingénieurs ont besoin de créer quelque chose, d'en être fier, et de le porter au yeux de leurs pairs. Arrêtons de leur affecter des tâches, de leur imposer des roadmaps à plusieurs mois. Evidemment, cela passe par un raccourcissement des cycles de production. Compter en mois (voir en années) cela impose une planification. Compter en semaines cela permet de tenter des choses, de laisser une part d'inconnu, d'expérimenter sans faire de gros frais.
• La culture DevOps a encore du chemin à faire. On ne crée pas de l'engagement en les mettant dans des silos. On pourra faire toute l'agilité qu'on veut, si le développeur n'est pas directement responsable des bugs constatés en production et du client qui gueule au bout du fil, il continura à délaisser sa stratégie de test pour passer à quelque chose de plus "intéressant".

Pour moi, le premier point à traiter est notre cycle de release. Il ne s'agit pas juste de créer tous les 30 jours un "logiciel potentiellement livrable" comme nous le suggère Scrum, il s'agit de mettre à l'épreuve toute notre chaine de production aussi souvent que possible. Le liens vers DevOps est alors évident et rapidement indispensable.

Comment vendre cette évolution à nos Managers ? 

Un seul argument à vous proposer (je vous laisse trouver les vôtres) : combien de temps faut-il pour fournir une évolution ou un correctif sans désorganiser l'équipe (je ne parle donc pas du gros bug critique "stop the line") ? Avec un cycle tel que celui de Facebook, cela peut être juste une semaine, sans créer le moindre stress supplémentaire. Avec une approche traditionnelle, en 13 ans, je n'ai connu aucun projet qui faisait des mises en production à moins de quelques mois d'intervalle. Le time-to-market est le nerfs de la concurrence, et de ce point de vue tous les CMMi du monde n'ont rien à nous proposer.

(1) pour ceux qui en doutent, twitter est aussi un outil de veille technologique et de support. Comme tout réseau social, il peut porter des choses totalement futiles ou des infos pertinentes, le tout est de mettre en place les bon filtres.

Il y avait le BreizhJUG, et ses soirées Java.
Il y avait AgileRennes, et ses soirées agiles.
Il y avait Rennes-on-Rails, et ses rencontres Ruby.
Il y avait le club .Net-ouest, et ses sujets .Net
Il y avait aussi les Flex-istes, Python-istes, PHP-istes, JavaScript-istes, pas spécialement structurés mais bien présents

Maintenant, il y a le BreizhCamp, une rencontre "par des techos, pour des techos", inter communautés. Une journée complète de conférence, 4 tracks sur des sujets d'actualité, 27 sessions par des speakers de tous horizons.

Les inscriptions ne sont pas encore ouvertes, et le programme pas encore finalisé, mais préparez vous pour rafler l'une des 200 places disponibles.