new Blog( perso );

Vous connaissiez le ClassLoader hell, le ClassPath hell, je vous souhaite de ne jamais avoir à gérer le Backward Compatibility Hell.



Sur un malentendu, je me suis retrouvé maintainer du plugin Git pour Jenkins. Gratifiant parce que c'est l'un des plugins les plus installés, difficile parce que c'est plus un amas de pull-requests qu'un véritable plugin, et ça continue ...

J'ai donc voulu prendre le diable taureau par les cornes et entamer un début de tentative de refactoring du plugin, en commençant par isoler les opérations Git de bas niveau. Le plugin est conçu autour d'une GitAPI, qui a priori assure ce rôle, sauf que l'interface contient des fonctions hérétoclites et surtout fait un mix entre les aspects pur Jenkins et les spécificités Git. Entre autre, elle prenait parfois en charge la gestion des esclaves de build (remoting) mais pas toujours ...

Bref, le chat sur les genoux, voici un boulot digne d'un vendredi. Tous les testent passent, et hop, je lance une release -> 1.27

Ca c'était donc le vendredi soir, et dès le samedi je découvre une ignoble régression, parce que la suite de test ... est perfectible. -> 1.28

Lundi, je reçois quelques mails et contacts sur #irc par les maintainers d'autres plugins. En effet, ce code est aussi utilisé par le plugin gerrit, git-parameter, ou cloudbees validated-merge (et peut être d'autres ?).

Le soucis ici, c'est que les plugins Jenkins ne reposent pas sur un moteur de modularisation (genre OSGi, JigSaw, JBoss Modules ...) et donc TOUTE classe publique d'un plugin peut potentiellement être utilisée ailleurs et ne doit donc JAMAIS retirer quoi que ce soit. Sauf que, comme beaucoup de monde, les développeurs ont tendance à mettre public un peu tout, ne serait-ce que pour pouvoir dispatcher leurs classes dans des packages spécialisés par fonctionnalité (quid du "friend" en java ?)

Autant dire qu'on se traine pas mal de casseroles. -> 1.29.

Fort de cette boulette, j'ai passé ma journée de mardi à reprendre entièrement mon refactoring, à isoler proprement le code Git dans un nouveau plugin utilitaire "git-client", partagé avec les autres plugins, et à tester la compatibilité avec les autres plugins. Cela à nécessité de définir une nouvelle API toute propre :

• D'un côté un GitClient avec les méthodes supportées, contrôlées par une suite de test
• De l'autre la "vielle" GitAPI avec les autres méthodes, toutes dépréciées (sauf si un auteur de plugin se fait connaître)
• tout en retournant un systématiquement composant GitAPI, même si l'API ne promet qu'un GitClient, histoire de rester backward-compatible à l'exécution.

Après quelques pas mal d'heures, on arrive donc au couple Git-plugin 1.2.0 (ça valait bien un changement de version mineure) + Git-Client-plugin 1.0.2


A côté de ma participation à Jenkins, il y a aussi la partie Cloud de Cloudbees. Ici, pour savoir si un plugin est utilisé par l'un de nos clients, on fait l'équivalent d'un grep (en un peu plus long). On peut donc à loisir virer quelque chose, quitte à trouver un contournement pour les 2 pelés qui ont activé la fonction qu'il ne fallait pas.

Ma seconde conclusion est donc que, pour un développement productif et donc un Time-to-Market réduit, le mode SaaS est sans commune mesure avec l'approche "produit" traditionnelle.

La pré-qualification pour CodeStory s'est terminée il y a quelques jours, et je suis heureux de trouver dans les qualifiés quelques visages (enfin, en tout cas leur avatar) qui me sont chers.

D'une part il y a Michel, membre du BreizhJug, mais il y a aussi Yan, qui a certes quitté le BreizhJug pour lui préférer le NormandyJug (???) mais on ne lui en veut pas.

Il a d'ailleurs bloggé sur sa participation. D'abord sur le choix de la simplicité, et je ne lui en veux même pas de dire qu'il préfère un serveur géré à la main à une offre cloud - après tout si ça l'amuse. Du coup il a du se tapper une sauvegarde des logs en base alors qu'il aurait juste pu activer PaperTrail :P Non, je ne suis pas du tout aigri parce que je n'ai pas réussi à dépasser 8/20 au score de performance alors qu'il a tapé un 10000/20 ...

Oui, parce qu'en dehors de répondre correctement aux problèmes algorithmiques proposés par l'équipe de CodeStory, il fallait répondre vite, et ce pour des données qui devenaient très, très volumineuses. Un sacré test aux limites pour les algorithmes proposés. http://status.code-story.net/ donnait le résultat des scores chaque jour et permettait à chacun de revoir sa copie.

Je pourrais vous dire que j'ai manqué de temps pour améliorer ma solution mais en fait non, je n'ai pas eu d'idée précise pour faire mieux - en fait si, mais il aurait fallu y passer significativement plus de temps. On a tous un boulot à côté, donc la sélection était aussi un test d'efficacité à implémenter rapidement des optimisations. J'attends d'ailleurs avec impatience le billet de Yan sur cette phase.

Ensuite, il ne s'est pas contenté de participer, il a fait une version en Java, en Scala, et en Ceylon - au passage, on sait donc qu'il y a au moins une personne au monde qui fait du Ceylon.

Donc voila, pour ce qui me concerne j'ai mon poulain pour la suite du concours. J'espère le revoir à DevoxxFrance au côté de David et Jean-Laurent pour la finale !



Lisez son blog pour avoir tous les détails : www.ybonnel.fr

Plusieurs personne me l'ont demandé, voici donc un petit guide de la façon dont j'effectue le montage pour les vidéos du BreizhJUG sur Parleys.com.

Tout d'abord, il faut évidemment enregistrer la conférence. Nous utilisons un caméscope à disque dur, équipé d'un micro bluetooth, qui permet de capter la voix des speakers, même quand ils tournent la tête (contrairement au micro main/cravate), et évite de trop capter le son de la salle. Nous avions précédemment un micro canon, mais ce système fournit un bien meilleur résultat.

Nous capturons aussi (parfois) la sortie VGA du speaker via un boitier vga2usb. La qualité est moyenne comparée à du matériel pro, mais bien meilleure que de filmer l'écran du vidéo-projecteur. Il existe aussi des soft à installer sur la machine du speaker pour capturer sa session, mais évidemment les speakers peuvent se montrer réticents, et on se demande toujours ce que ça va donner avec le double affichage.

Voilà, la session finie vous avez donc une (ou deux) vidéo à monter dans parleys, plus les slides du speaker (enfin, dans mon cas c'est plutôt quelque jours après car j'oublie toujours de les demander)

J'effectue le montage vidéo dans Adobe Première, parce que je connais pas trop mal ce (très bon) soft, et surtout parce que j'utilise le filtre "denoiser" pour retirer le bruit que je constate systématiquement sur la bande son.



Je ne sais pas pour vous, mais moi quand je regarde un talk en ligne, que la vidéo soit passable cela ne me dérange pas trop, mais si le son est pourri je crie au scandale.

Le montage sous Première me permet aussi de caler ma vidéo "vga" pour avoir la même bande son sur mes deux flux. Première me permet alors d'encoder tout ça en mp4, attention parleys n'accepte pas plus de 300Mo pour une session, aussi je suis souvent obligé de considérablement pousser les paramètres de l'encodeur pour tenir cette contrainte.

On passe ensuite dans le "publisher" parleys.

J'importe mes vidéos et les slides PDF par simple glisser / déposer. Publisher analyse les PDF et me propose chaque slide comme "asset".





Il ne reste plus qu'à placer les piste vidéos et à caller les slides un à un. Si on a une piste "vga", parleys dispose d'une identification des slides qui permet de faire ça en un tours de main (enfin, quand ça marche)



Il reste à choisir une image comme icone du talk, renseigner les métadonnées, puis uploader - le plus long avec l'encodage pour ce qui me concerne, depuis ma petite connection ADSL de campagne.

Et hop, en ligne.

Je rebondis sur un tweet de Julien Dubois pour verser une larme sur Java, et la façon dont la plateforme arrive à partir en sucette d'elle même.

Prenons un exemple excessivement simple : la gestion des status HTTP. Ca semble vraiment le truc de base, non ?

Le runtime Java SE propose HttpURLConnection. Déjà on se demande d'un point de vue puriste de l'OO pourquoi la "connection" porte ces constantes et pas une classe de constantes, mais bon, java 1.0 a été pondu à l'arrache, passons.

Arrive Java EE, sensé être basé sur Java SE (non ?), mais évidemment on a une autre classe parce que c'est vachement plus drôle HttpServletResponse. Ici les codes retour sont portés par un objet qui matérialise une réponse HTTP, c'est un tout petit peu plus logique, mais ça reste très con de dupliquer. Ne soyons pas médisant, cette classe ajoute d'indispensables constances :

• SC_CONTINUE
• SC_SWITCHING_PROTOCOLS
• SC_FOUND
• SC_TEMPORARY_REDIRECT
• SC_REQUESTED_RANGE_NOT_SATISFIABLE
• SC_EXPECTATION_FAILED

et aussi, redéfinit les constantes existantes avec des noms un peu plus explicites :  HTTP_REQ_TOO_LONG -> SC_REQUEST_URI_TOO_LONG. C'est juste un peu dommage d'avoir conservé ce préfixe "SC_" qui nous rappelle les règles de nommage du siècle dernier.

Mettons que Java EE a eu besoin de ces nouveaux codes, non prévus la Java SE. Pourquoi ne pas avoir ajouté au backlog Java SE "ajouter les codes manquants du standard HTTP  à HttpURLConnection" - je veux dire, il y a un spécification pour HTTP, ces codes ne sont pas juste issus d'un reverse engineering à la con !

D'ailleurs, de son côté, commons-http a créé sa propre classe de constantes HttpStatus avec références explicites aux RFC 1945 / 2518 / 2616 (HTTP 1.0, WebDAV et HTTP 1.1), tout en nous coltinant ce magnifique préfixe "SC_", nous avons donc sans doute affaire à des développeurs issus de la même formation ;P

Et bien sur, l'équipe Spring qui crache dans la soupe Java EE depuis tant d'année ne s'est pas privée de sa propre version HttpStatus, sans les références RFC mais aussi sans préfixes pourris.

Bref, cet exemple est révélateur de l'écosystème Java : Java SE et Java EE qui n'arrivent même pas à être cohérents, Apache qui a longtemps proposé des projets génériques (les fameux commons-*) venant compléter les manques de la plateforme, Spring qui ajoute son grain de sel...

Même sur un exemple aussi simpliste que la liste des codes prévus par une spécification officielle, c'est la misère. Alors pour un StringUtils ...

"Winter is coming"; l'hiver est même déjà bien installé, mais ce n'est pas encore assez pour un gars comme moi qui a des racines nordiques, aussi je serais :

• le 28 janvier au YaJug (le JUG du Luxembourg) pour une soirée conjointe Jenkins / Sonar, en compagnie d'Olivier Gaudin.

Le thème de la soirée sera donc comment passer d'une approche "cycle en V" (phase d'intégration, audit de code, etc) à une approche "continuous". En gros, comment donner vie à votre code

• les 2 et 3 février au Fosdem (Bruxelle) sur le stand Jenkins

CodeStory remet le couvert en 2013.
CodeStory, c'est le pari un peu fou de deux amoureux du code qui ont lancé l'an dernier un concours : prouver, en se frottant à une série de challenges qualificatifs, ses qualités de développeur. Après une phase ouverte à tous, des binômes ont été sélectionnés puis confrontés lors d'une finale en live au ParisJug et enfin mis à l'épreuve pendant DevoxxFrance, codant en direct, fàce à un public très attentif et participatif.

Un tour de force étonnant : agilité poussée (sprints de 20 minutes, binômage, TDD et refactoring, KISS), approche très didactique en interaction avec le public, tout ceux qui ont "sacrifié" une heure de Devoxx pour aller les voir en sont revenus ébahis.


Pour 2013, l'équipe remet le couvert et lance donc la première phase : inscription des candidats.

Cette année le concours va proposer à chaque participant de développer une application qui devra répondre à des "questions" via une interface web http. Le niveau 0 ("inscription") consiste à coder quelque chose qui répond à http://(serveur)/?q=Quelle+est+ton+adresse+email avec du texte brut indiquant  ... l'email du participant.

NB: Les niveaux suivant seront un peu plus durs :) Ceci dit, ça ne coute pas grand chose de tenter son coup juste par curiosité, alors viendez !

Chacun peu venir avec son langage / framework / outil préféré, faire au plus simple ou sortir l'artillerie lourde (mais ce n'est pas dit que cela plaise aux jury :P).

Comme je sais d'avance que je n'aurais pas trop de temps pour dépasser le niveau 1 ou 2 (ce qui me donne d'avance une excuse pour me planter) je propose à tout ceux que ça tente d'héberger leur application et leur CI sur cloudbees : https://codestory.ci.cloudbees.com/ ; j'ai ainsi ma super contribution perso déployée sur http://nicolas.codestory.cloudbees.net/?q=Quelle+est+ton+adresse+email (un simple tomcat, rien de bien hype).

L'avantage (pour vous) est d'avoir un service tout compris pour votre appli, l'avantage pour moi est que ça va permettre de tester sur CloudBees les stacks les plus tordues que vous allez vouloir mettre en oeuvre, comme ça je serais prêt à aider des clients avec de vrais projets et les même technos :D

-> contactez moi par email (si vous avez tout bien compris, vous savez ou trouver mon e-mail...)

Notre petit Sacha Noël est passé un peu en avance cette année, et vient d'officialiser le passage de CloudBees Genapp en open-source

kesako ?

Vous connaissez CloudBees pour le déploiement d'un WAR sous Tomcat, ce que vous ne savez sans doute pas c'est ce qui se passe en dessous. Depuis Octobre, notre architecture a été repensée pour être extensible, et repose sur une brique nommée "Genapp" - il s'agit du coeur d'exécution de RUN@Cloud.


Genapp est un moteur extensible d'approvisionnement et d'exécution d'applications,  il gère l'installation de vos applications sur des machines du Cloud et leur exécution. Il repose entièrement sur un mécanisme de plugins, en fait Genapp ne gère aucun conteneur par défaut.

Chaque plugin est chargé de préparer le runtime de l'application - une JVM et un serveur TomEE, ou bien un runtime Node.JS - et de fournir les scripts de démarrage et d'arrêt de l'application. CloudBees propose ses runtimes historiques Tomcat 6 et JBoss 7, et a ajouté une série de "clickstack" (dispos sur https://github.com/cloudbees-community/) pour divers environnements.


qu'est ce que j'en ai à ... ?

Ce mécanisme va vous permettre si vous le souhaitez de complètement customiser votre runtime, soit en créant de nouveaux plugins pour venir compléter une stack existante - c'est ainsi qu'est implémentée l'intégration de newRelic par exemple - pour venir greffer le service de votre choix dans les stacks existantes, soit de forker une stack pour venir y mettre votre grain de sel.

CloudBees ne sera donc plus une "boite noire".

Devoxx conference is much more than an annual event for Java Community. With DevoxxFrance, DevoxxUK and Devoxx4kids it's now a growing ecosystem of great community events.

Devoxx team used to host it's registration and call-for-paper applications on it's own hardware, and as I proposed to host it on CloudBees Platform as a Service, they were so enthusiastic I quickly understood being sysadmins on this infra to keep the apps up and running 24x7 isn't a fun job. They prefer to focus on making the conferences happen and be even better every year.

The interesting challenge is that those application haven't been designed to be hosted in the Cloud. They don't use a fully stateless web framework à la Play, They aren't split into small REST services invoked from a pure Angular javascript frontend, they are ... like 99,9% existing application, using common Java Frameworks.

Registration application was the simpler one to migrate. It's a very classic Servlet-based application, designed using Vaadin for web UI, and a Spring and MySQL backend. We just had to make some minor configuration changes so that the app can get a datasource injected by the platform, as well as SendGrid JavaMail session.


Most container require you to add a dedicated deployment descriptor to declare container resources (jboss-web.xml, weblogic-web.xml, etc). If you don’t want production information to be stored in SCM neither hard-wired within the artifact, you probably rely on an external properties file to be loaded by spring on startup, or comparable workaround.

CloudBees platform let you inject parameters and resources to an application, so that you can have the exact same binary WAR deployed on staging environment and then on production, with just the adequate Mysql DataSource bound and configuration parameters (secret credentials, ...) injected.

Thanks to this feature, the Devoxx team is able to have staging environment be an exact replica of production environment, just with less connected users :) Deployment process is also the exact same one, and is ran on every commit that successfully builds the WAR. With such an homogeneous infrastructure, they can be very confident when deploying to production.

Devoxx team quickly setup a continuous delivery pipeline. As they push code to bitbucket - they use Mercurial, sorry for that, read my previous post - Cloudbees DEV@Cloud Jenkins is building the app and automatically deploying to the staging environment.

They also enabled sonar add-on service, because continuous delivery don't prevent you to write ugly code :)

As the Platform handles concurrent versions deployment, the service isn't interrupted as you deploy a new app, the "old" application remains active until the "new" one is ready to handle requests, and then http traffic routing is switched. So, deployment to production isn't a stress anymore, with twitter announcement about temporary service black-out.

After some more testing, they can promote the build to production. A single click to deploy app in production, cool isn't it ?


This encourages rapid feedback, small change-sets between "releases", so small risks ... I won't explain you here what agile software development is !

Devoxx team also wanted to test the scalability of the platform, and then hit an issue as vaadin is using HTTP session to store UI state, so you can't use round-robin load balancer. Hopefully, cloudbees platform can be configured to enable sticky session. This is something you have to consider to host your application on a Cloud platform, as most frameworks rely on this feature, and sometimes you even don't know (I think about you spring-security!). The other option is to enable session clustering around the nodes your application is running on.

The Call For Paper application required more changes to be "cloud-compliant". This application let speakers upload existing slide decks so the CFP team can review a proposal from existing content. The application used to store those files on file system, using a parameter to configure the local directory. How does this translate when running in the Cloud ? The app is running on multiple clustered nodes. It starts on fresh new nodes every time a new version is deployed. So, even local file-system can be used for temporary files during request processing, it is not persistent, neither replicated.

This is something CloudBees plan to address in 2013, but at this time there was no other option than changing the application code to use Amazon S3 to store files. JClouds API and S3 provider helped a lot to reduce the amount of time spent to fix this design issue, and the application was running on the staging environment after a few hours of coding.

The RUN@Cloud console gives general health and performance information about the applications, so the Team can monitor his application and - if necessary - change the platform configuration to use larger nodes, more nodes, or both. They also enabled NewRelic add-on to get fine grained analysis, that could help in case something wrong happes.

Devoxx Team officially announced registration for DevoxxFrance to be open, running on the new CloudBees infrastructure. CFP application has been migrated earlier today. So feel free to register to Devoxx and propose your talks, app is now running on a Platform-as-a-Service, with all CloudBees team ready to help in case anything goes wrong, and the Team can work on the real added-value : continue to make Devoxx the best conference ever.

Depuis que j'ai découvert Git j'ai du mal à m'en passer. Lorsque je suis contraint d'utiliser Subversion je passe par git-svn, ce n'est certes pas idéal mais c'est déjà d'un grand confort.

Pour aider l'équipe Devoxx à adapter leur application sur CloudBees, j'ai du utiliser Mercurial (Hg pour les intimes). Mercurial est très comparable à Git, mais un peu déroutantes pour un Git-iste car les commandes reprennent les même nom mais pour un usage différent (fetch devient pull, pull devient fetch pull, reset devient revert, revert devient backout, etc. Si vous devez faire l'exercice, garder ce tableau sous le coude.

Bref, j'ai eu la flemme d'apprendre Mercurial, ni d'utiliser SourceTree tout en mode graphique parce que... et bien la ligne de commande y'a que ça de vrai, n'est ce pas ?

Il faut savoir qu'il n'existe pas de passerelle officielle hg->git, contrairement à celle qui permet d'utiliser svn. Il existe par contre une passerelle inverse, très mature, qui permet aux utilisateurs de mercurial d'utiliser un repository git: hg-git. La raison de cette absence est apparemment philosophique, si j'ai bien tout suivi ...

Il existe donc pléthore de solution custom pour prendre en charge ce besoin. J'en ai donc testé quelques un pour finalement tomber sur git-remote-hg.

Comme expliqué sur le blog, comparée aux autres solution cette passerelle à l'avantage de se plugger dans les mécanisme de transport de git, et non de chercher à fournir des commands complémentaires du genre "git hg-clone". On travaille donc en pur git, mais avec un repository distant qui utilise le protocole "hg::*".

J'ai donc cloné le repo devoxx, tripatouillé deux trois fichiers de configuration, et voulu pousser tout ça dans bitbucket pour proposer une pull-request. J'ai alors eu un grand moment de solitude :


git-remote-hg fait apparaître les branches mercurial sous l'arborescence "branches", et la branche de développement du projet, équivalente du master git, est donc branches/default. J'ai passé un certain temps à tenter d'attacher mon master à la branche remote origin/branches/default sans succès. Tous les "--set-upstream"n'y ont rien changé. J'ai bien cru que j'allais devoir changer d'outil.

Au final, j'ai crée une branche locale branches/default (les branches git peuvent contenir le caractère '/', le saviez-vous ?) associée à la branche remote origine/branches/default, mergé mon master dedans, et j'ai (enfin) pu pousser tout ça sur bitbucket. Ouf!


Bizarrement, chaque push m'indique la création d'une nouvelle branche remote. Cela fonctionne donc mais l'intégration n'est pas encore parfaite.

Bref, si vous devez vous aussi jongler entre mercurial et git, cette solution semble intéressante, à condition de respecter du 1:1 avec les branches mercurial. Elle permet de synchroniser les repositories sans perte d'information, par exemple pour proposer un miroir Git d'un repo Hg, et vois évite de devoir choisir entre Git et Hg si vous en êtes à ce stade.

Au passage, au cours de mes tentatives j'ai découvert que Perforce venait tenter sa chance sur le territoire Git : http://www.perforce.com/blog/121001/improving-git-experience-everyone. De mon point de vue, question SCM, les jeux sont faits (en attendant le prochain :P)

La dernière journée de Devoxx est particulière. D'une part, on est quelque peu lessivés par la soirée au Nox une longue semaine de dur labeur. Par ailleurs, le planing est réduit à 4 salles en parallèle car de nombreux participants sont déjà partis (ou n'arrivent pas à se lever ?)

J'arrive pour ma part à être présent pour la première session du matin, présentant les évolutions des annotations dans Java 8. Nous aurons donc un peu plus de flexibilité dans les annotations, comme par exemple la possibilité de répéter une annotation sans devoir l'empaqueter dans une annotation plurielle (@Schedules( { @Schedule( "daily"), @Schedule( "weekly" ) })), mais au prix de certaines accrobaties dans le compilo. Ce simple changement nécessite en effet de considérer avec soin la compatibilité ascendante. Comme pour les lambda, ce problème est un énorme frein à l'évolution de Java, qui impose de mesurer avec soin les impacts et à privilégier des choix non définitifs (voir cet article). Une nouvelle API est également introduite, sur le modèle de ce qui est disponible dans les annotation processors (compilte-time), mais cette fois au runtime. Cela permettra d'avoir un niveau d'abstraction comparable entre un processor APT et du code runtime qui devait jusqu'ici passer par la réflexion.

Enfin, si de nombreux efforts sont faits pour corriger le tir, c'est un peu dommage de se rendre compte aujourd'hui qu'il peut être utile d'utiliser une même annotation deux fois :-/

La session suivant c'est l'enregistrement de l'épisode 68 des cast-codeurs, en public. Tous les frenchies sont au rendez-vous, ce qui permet de constater que DevoxxFrance ne les a pas fait déserter leur rendez-vous annuel en terre flamande (moi j'ai une excuse, c'est la terre de mes aïeux). Quelques sujets sérieux, d'autres moins, d'autres pas du tout.

José et David se sont emballés sur un point qui mérite en effet qu'on s'y attarde, la "nouvelle" syntaxe des parallel collection, introduites plus ou moins en douce. L'an dernier, quand on nous a présenté les parallel collection, on nous a promis ceci :

for (Foo foo : bar.filter( blah ).map( buzz )) { // je traite des foo }

Java 8 étant trop bien fait, il nous permettait donc de faire du filter/map/reduce sur des collections et de profiter du parallélisme lorsque c'était utile. Sauf qu'au final cela va plutôt ressembler à ça :


for (Foo foo : bar.stream().filter( blah ).map( buzz ).toList() ) { // je traite des foo }

autrement dit, il faudra explicitement demander le mode "parallel collection" et revenir au mode "séquentiel" à la fin du traitement. On arrive ainsi à une syntaxe merdique d'une part, mais surtout à l'absence de filter/map/reduce sur les collections en standard, sauf à s'obliger à utiliser un algo conçu pour traiter des BigData sur du multi-core. Les explications demandé par José aux personnes intéressées ont jusqu'ici été de la forme "c'était compliqué à implémenter". Non-officiel bien sur, mais attention Java 8 sort l'été prochain, aussi si rien n'ai fait les choses seront entérinées sous cette forme et on se les coltinera 15 ans - ou plutôt, on utilisera guava ou autre plutôt que les collections standard ...

Atlassian offrait ensuite des pizzas (attaquer des bières à 10h30 aurait été un peu violent) pour conclure ce très beau Devoxx 2012, et nous avons été quelques-uns à aller faire un dernier repas ensemble avant de prendre le Thalys.

J'espère que ces billets sur Devoxx vous auront donné envie, rendez-vous en 2013 (ne vous y prenez pas trop tard, les places partent vite), et/ou pour Devoxx UK puis Devoxx France !

Deuxième journée de conférence, et surtout quatrième journée à dormir peu après une soirée mouvementée, j'accuse un peu le coup :)

Les keynote commencent avec l'annonce de JBoss de la "short-list" pour le nouveau nom de JBoss AS. J'ai d'abord cru à une blague mais ce sont bien les propositions retenues. On aura donc peut être droit à un "J-Béret by RedHat" :-/

On passe à la keynote de Google, présentant les nouveaux Nexus 4 et 10, l'intégration Jenkins (by Cloudbees, youpi!) dans AppEngine, et les dernières fonctionnalités "hype" de Chrome, sur fond de talk sur la "vie online" et notre responsabilité de développeurs et d'early-adopters pour mettre en place une vraie sécurité, du genre 2-step verification login, utilisation systématique de https, ... sans perdre de vue l'expérience utilisateur. On conclut rapidement sur l'utilisation d'OpenId et le "one click signup" qui se multiplie sur les sites web.

Je zappe la session suivante pour discutter un peu, avant de rejoindre les London-Jug guys présentant un talk sur les anti-patterns de développement,  sur le mode "gentil et méchant flic", très sympa et pleine d'humour.

Après le casse croute passé au côté de l'équipe CodeStory, je suis une session sur les test en Javascript. Le framework Jasmine y est mis en oeuvre pour modulariser une appli JS en fragments testables unitairement. Pour la partie graphique, après un premier essai utilisation Selenium (12 secondes pour exécuter 3 tests basiques), le speaker présente un runner JavaScript permettant d'exécuter les tests dans la JVM en mode émulation. Très rapide et avec feedback dans l'IDE on a donc un outil performant. Dernière option proposée : utiliser PhantomJS (browser headless basé sur webkit) plus proche de la réalité mais qui est plus délicat à intégrer (maven-exec) - amha un Custom Runner JUnit devrait pouvoir y remédier, si ça tente quelqu'un ;) Une combinaison de ces recettes permet donc de monter un CI Javascript très productif.

J'ai apprécié ce talk car j'avais été interpelé par l'équipe CodeStory qui utilise Mocha et Zombie pour obtenir des tests web rapides et fonctionner efficacement en full TDD. Avec le talks sur Testacular plus tôt cette semaine, je vois que l'écosystème JavaScript est toujours aussi prolifique et de mieux en mieux outillé.

Merci à Arnaud qui me prête un tournevis pour remettre en état mon MacBook qui souffre un peu (trop de bière, petite nature) avant de passer à une façon plus DevOps de gérer l'infrastructure, présentée par Patrick Debois himself. Initiée par CFEngine, puis Puppet et Chef, la catégorie des "Configuration Manager" adresse un besoin de traçabilité/reproductibilité que l'on connait bien dans le développement logiciel et qui s'applique aujourd'hui à l'identique dans le monde des Ops.

Patrick présente en parallèle Chef et Puppet en comparant les concepts avec leur équivalent en programmation java : class <-> definitions, héritage <-> attribut "cookbook", etc. Puppet et Chef se distinguent essentiellement par la culture qui les sous-tends. Le premier propose un DSL volontairement restreint, plutôt contraignant (pas de boucles !) - le second en permettant d'écrire n'importe quoi en Ruby ouvre la porte à des utilisations maladroites et ingérables. Puppet utilise par ailleurs un graphe des tâches à exécuter qui peut être interrogé alors que Chef exécute purement les cookbooks de manière séquentielle, mais ainsi de façon plus prédictible. 

Avec le développement de ces outils d'infrastructure as code, on voit apparaître de l'outillage (Gepetto, RubyMine), règles de codage, patterns et anti-patterns, gestion de dépendances, visualisation, debugging (encore naissant), testing qui nous sont familiers.

La taille relative de mes notes par rapport aux autres talks montrent à quel point ce talk m'a intéressé ;)

Je m'offre un petit moment de calme avant d'aller découvrir les nouveautés de Groovy 2.0 (j'aime bien Groovy, il me permet de coder du Java comme d'hab tout faisant des trucs géniaux lorsque c'est utile). Les AST transformation en particulier me donnent envie de creuser le sujet. Je vous renvoie sur la chaîne Parleys du BreizhJug si vous voulez suivre ce talk en version FR

La journée aurait du se terminer ici, mais après le succès de son quickie, nous avons droit à un "replay" de Chet Haase présentant d'une manière délirante un nouveau process de développement. Un pur moment de délire qui fait du bien, avec un Chet qui arrive a garder un sérieux sans faille dans son costume de consultant d'un jour.

La fin de journée permet de joindre le BOF des JUG-Leaders, occasion annuelle de faire le point sur les relations entre JUGs, avant de rejoindre le NoX pour la Devoxx Party, qui permet de dépenser un peu des calories que la bière belge nous aura fait prendre cette semaine, et aussi de faire connaissance avec la gente féminine à péage qui occupe le night-club.

On attaque le gros morceau avec les journées "conférence"

La matinée est occupeé par les "keynotes" :

Le ton est donné avec une "danse" des robots Nao d'Aldebaran-Robotics. Bluffant !
Stephan Jansenn intervient alors pour accueillir les 1400 participants de la conf, les apostrophant sur ses robots-jouets de luxe qui pourraient être "le comodore 64 de la prochaine génération".
Restant sur le sujet, passe alors un vidéo présentant Devox4Kids, un programme super sympa sur la robotique pour les plus jeunes. S'il y en a que ça tente j'aimerais bien faire ce genre de chose à Rennes, bippez moi.

Suit l'annonce, toujours en vidéo, de DevoxxFrance du 27 au 29 mars, et un passage sur scène de Nicolas, José et Antonio (qui, mal réveillé, s'est trompé de couleur pour le polo DevoxxFrance :P). Suit alors une autre vidéo, extraite des Monthy Python, sur l'affrontement des chevaliers d'Arthur fàce aux français. La vidéo s'arrête sur "j'ai un plan" et l'équipe du LondonJug débarque habillée en chevalier et annonce ...

Devoxx UK les 26 et 27 mars (oui, il y a recouvrement) et invite les speakers à considérer les 2h30 d'Eurostar pour faire d'une pierre deux coups.

On passe ensuite à la keynote Oracle. J'en profite pour aller satisfaire un besoin naturel et consulter mes mails, et je reviens pour la dernière démo JavaFX (certains prétendent qu'il y a eu à Devoxx plus de sujets sur JavaFX que d'utilisateurs :P). A priori je n'ai pas raté grand chose.

Neal Ford présente ensuite "Geek Leak", ou "comment l'esprit geek transpire sur des activités non-informatique. Autant Neal est un super speaker, autant j'ai trouvé son show très moyen, complètement décousu.

Le marathon commence alors avec les Conférences, qui vont s'enchainer toute l'après midi jusqu'à 19h.

Je vais voir la conf sur AppEngine, avec un coup de main à  Ludovic Champenois pour mettre un peu d'huile dans sa démo de l'intégration de DEV@Cloud avec AppEngine. Google Execute Engine, concurrent direct d'Amazon EC2, est une bénédiction pour les dévelopeurs GAE qui doivent faire avec les contraintes de la plateforme. Par contre, ne pas oublier de tuer les instances après la démo sous peine de payer une grosse facture :)

Je fais une pause en allant voir l'équipe de CodeStory en action. Mal placés, ils doivent subir un environnement bruyant qui nuit à la qualité du show, qui est pourtant toujours aussi bluffant. Le public de Devoxx n'était pas aussi préparé que celui de DevoxxFrance, c'est dommage pour eux même si la performance est tout de même appréciée de tout ceux qui viennent "perdre" une heure à les suivre.

Je vais ensuite à une présentation sur Vert.X, qui m'a déçue. Beaucoup de théorie pas super intéressante que j'aurais préféré voir remplacée par des démos. Pendant ce temps, Arnaud suit la conf sur Nao et a bien du mal pour se retenir de faire un gros chèque à Aldébaran-Robotics pour remplacer son Karotz.

Après la pause j'enchaine avec un talk sur Dart, qui manquait un peu de peps mais était tout de même très bien mené, avec beaucoup d'exemples. Je reste TRES perplexe sur les web components, qui permettront à termes de "pluger" de nouvelles balises HTML riches. En l'absence de namespace, l'usage est de préfixer ces tags custom : . Seulement, apparaitront inévitablement des librairies de web composants, et donc des possibles conflits de noms de tags. Pourquoi ne pas avoir repris les namespaces xml ? A priori, c'est juste "trop tôt" pour être un problème :-/

Je zappe la dernière session qui m'inspire modérément pour aller "socializer" sur le stand Google, puis rejoindre les J/GT- User Group leaders qui sont invités par le géant du web pour un meeting dans le pub d'à côté. La soirée se finit inévitablement au Kelly's, lieu de toutes les débauches mais dont je ne dirais rien : "ce qui se passe à Devoxx reste à Devoxx" :D

Pour la seconde journée de Devoxx j'ai suivi le début de la session de John Smart sur l'automatisation des tests d'acceptance et son outil thucydide. J'avoue avoir un peu décroché, le début de la session étant un peu "lent" à mon gout, aussi je vous renvoie sur Parleys pour vous en faire une meilleure opinion :) J'ai donc profité de la pause pour rejoindre le hackergarten, occupé en force par l'équipe JBoss. Ce format est vraiment super intéressant, permettant aux technical lead d'inspirer de nouveaux contributeurs et d'interagir directement avec leur communauté, et aux participants d'avoir des réponses de premier choix à toutes leurs questions techniques, plus la fierté de contribuer efficacement à leur projet préféré.

L'après midi, je me dépêche de rejoindre avec 20 minutes d'avance le lab Angular.JS qui promet d'avoir un grand succès, et je me retrouve au fond en bout de table. La salle est comble, le lab est un succès énorme. Pendant 2h30 nous développons donc pas à pas une application en partant d'un design html statique, ce qui permet d'introduire progressivement les concepts d'Angular ainsi que l'outillage associé. Vous pouvez d'ailleurs rejouer le lab chez vous. Super framework, qui me réconcilie avec JavaScript, j'en profite d'ailleurs pour découvrir l'excellent support de JavaScript et d'Angular dans Intellij Idea.
Un framework que vous découvrirez au BreizhJug en 2013 :-)

A nouveau la journée "university" se termine par des Tools in Action. J'en profite pour découvrir Testacular, outil de CI javascript développé par Google. Le talk manquait clairement de préparation et a été un semi-bide mais l'outil reste extrêmement intéressant. Les 15 minutes "utiles" que j'ai pu tirer de cette session m'ont donné une très bonne impression sur le potentiel de l'outil, pour sortir du mode "je code, je refesh mon browser" et passer à du vrai TDD en javascript.

On enchaine avec le "Maven Dependency Puzzler", qui nous expose quelques POM maven avec des cas de dépendances bien merdiques et la gestion de conflit parfois "non-intuitive" de Maven. Les trois premier gagnant une bière je commence la soirée très fort et j'enchaine ensuite sur le stand Oracle où la tireuse coule à flot, avant de rejoindre les frenchies au resto asiatique du coin qui sera content de ne pas nous revoir avant l'an prochain ;)

rendez-vous demain :D

C'est donc reparti pour 5 jours à Devoxx, La conférence java à ne pas manquer.

Premier jour, je suis l'université "Scala" pour en savoir un peu plus sur ce langage qui est autant défendu bec et ongles par ses fans que décriée par ses détracteurs. Pendant 2h30, les constructions de base du langage sont présentées en expliquant comment le compilateur interprète la syntaxe et la transcrit en invocations de méthodes. Pédagogiquement parlant, le talk est un régal. J'adore l'approche qui consiste à d'abord montrer un concept avec une approche très procédurale, puis à refactorer pour donner plus de "fonctionnel" et introduire les simplification de syntaxe, pour aboutir à du "beau" code scala, et dans les exemples qui suivent à toujours rappeler l'opération inverse, par exemple que "2 + 3" est interprété par le compilo comme "(2).+(3)" - évidemment, hors contexte ça fait un peu zarbi :)

Session intéressante qui donne (presque) envie de s'y mettre :D

Pendant l'après midi j'ai suivi la session "from syncrhonized() to parallel()" de Jausé Paumard. Après des rappels présentés avec précision sur le multi-threading et le pourquoi du "le double check ne fonctionne pas", José nous montre comment les librairies low-level utilisent des hacks pour contourner les problèmes de synchronisation du cache L1 (padding de la ligne de cache). On passe ensuite au niveau framework avec les SMT et le framework Akka, et enfin à l'évolution de Java avec le fork-join de Java 7 et les parallel collections de Java 8. J'ai adoré la conclusion du talk : après avoir vu pendant 2 heures les technos de paralélisation, José nous expose les conclusions d'un concours sur du calcul de suite de Fibonacci. Le record absolu est obtenu avec un algo séquentiel sur mono-coeur, en optimisant les éléments de bas niveau et l'algorithmique. Rien ne sert d'avoir 128 coeurs avec un algo pourri, et tous les algorithmes ne se paralélisent pas bien, nous sommes donc au début d'une nouvelle aire de l'algorithmique où nous allons devoir (ré)inventer des algorithmes pour tirer partie d'une informatique toujours plus distribuée.

La journée continue avec les Tools in Action, dont celui de Julien Viet sur CRaSH, le shell de votre JVM, que j'aimerais bien intégrer dans un plugin Jenkins pour faire du deboggage de builds - une idée pour le hackergarten du mardi ?

Fin de journée autour de quelques bières à échanger nos souvenirs de vieux geeks, mais bon, il faut être sage on est que lundi ...

Ce billet est plus un mémo pour moi-même afin de ne pas chercher à chaque fois comment effectuer une conversion svn -> Git. (billet fortement inspiré de http://john.albin.net/git/convert-subversion-to-git)

Le but ici n'est pas "juste" de migrer vers git mais de maintenir un lien entre les deux repositories, autrement dit de créer un miroir git du repo subversion.

1. lister les committers

Il peut être nécessaire de faire un peu de ménage dans le fichier généré

2. faire un clone git du repo svn

L'an dernier, à la même période, je bloggais un appel à volontaire pour m'aider à organiser le breizhcamp.

J'ai porté quasiment seul la première édition de cette conférence, profitant d'une période charnière dans ma vie professionelle qui me laissait pas mal de temps libre - comprenez, ma démission d'Orange. L'exercice est enrichissant et très formateur, mais particulièrement éprouvant. Disons qu'il faut avoir les reins solides pour prolonger ce mode de fonctionnement.




Pour la seconde édition, j'ai voulu m'entourer de lieutenants, chacun se chargeant d'un "silo" et me soulageant de ce poids. Avantage pour moi : garder le contrôle dans le role du "dictateur". Inconvénient, lorsqu'un lieutenant ne peut pas assurer pour diverses raisons, je suis seul apte à venir jouer les pompiers, ayant une vision globale de l'organisation. Au final, entre les contraintes de chacun, je me suis retrouvé à gérer bien plus de choses que prévu. Par ailleurs, difficile de motiver les gens si on ne leur laisse pas voix au chapitre.

Le point fort de Jenkins c'est son incroyable écosystème de plugins. Le système est entièrement bâti sur des points d'extensions et de nombreux composants qui viennent y contribuer.

Un soucis que je rencontre parfois chez des clients c'est qu'un plugin apporte une fonctionnalité intéressante, mais aussi une implémentation d'un point d'extension qui s'avère contre-productive dans un contexte spécifique.

Exemple avec JENKINS-15440 : le plugin subversion contribue au point d'extension "MailAddressResolver" en cherchant dans les projets SVN de l'instance si l'un d'eux pointerait vers sourceforge ou java.net, ce qui permet de déduire l'e-mail du committer. On sent l'idée initiale, mais sur une grosse instance Jenkins d'entreprise :

1. le code n'est jamais sur sourceforge ou java.net. D'ailleurs de nos jours plus personne n'utilise ces services, ce code est donc purement là pour garantir la compatibilité
2. ce parcours de tous les projets pénalise les performances sur une instance avec des centaines de jobs.

La solution ? Ne pas utiliser subversion et le plugin associé ! C'est d'ailleurs pour cela qu'on ne l'intègre pas dans Jenkins Enterprise - non je déconne, c'est à cause de la license de svnkit.

Il y a évidement plusieurs façons de corriger ce bug, mais en attendant j'ai pensé à un contournement qui s'applique à de nombreux autres cas. Ce genre de "fonctionnalité" n'a pas forcément de sens pour tout le monde, peut être pénalisante ou dangereuse selon l'utilisation qu'on a de Jenkins. Il existe pourtant un point d'extension qui permet de filtrer les extensions (attention, StackOverflowError en vue).

Comme "Project Of The Day" j'ai donc crée le plugin Extension Filter (whaou, mais où donc vais-je chercher tout ces noms super originaux ?) qui permet de configurer les extensions et descripteurs à désactiver sur une instance Jenkins.

Ce plugin permet donc d'alléger Jenkins des points d'extension que vous n'utilisez pas et qui peuvent pénaliser votre instance. Il permet aussi d'inhiber des composants selon leur contexte. Par exemple, retirer de la configuration globale hudson.plugins.mercurial.MercurialInstallation, pour empêcher vos utilisateurs de configurer Mercurial et les obliger à passer sous Git, ou bien interdire à hudson.task.Maven$DescriptorImpl de proposer un BuildStep dans les projets de type free-style, pour imposer l'utilisation de jobs maven. On peut même désactiver la configuration du plugin lui-même comme ça personne ne pourra plus changer la conf :)

Je vous laisse imaginer des cas d'usage un peu plus sérieux pour des éléments de configuration que vous considérez superflu ou "dangereux" pour vos utilisateurs.

JavaOne, plus gros événement pour la communauté Java, se déroule en fait en marge d'un événement bien plus important : Oracle Open World ("oow" pour les intimes). Ayant un pass "Press" j'ai le privilège de pouvoir m'y promener, je suis donc aller voir de quoi il s'agissait.

OOW occupe les trois centres Moscone de San-Francisco, immenses centres de conférences, plus l'avenue qui les sépare et qui est recouverte par une tente/expo pour des démonstrations et salons privés.

Imaginez un peu le parc des expo porte de Versailles entièrement recouvert aux couleurs d'Oracle. Tous les hotels a proximités sont pré-réservés pour la conférence - a 1000$ la nuit. Le "petit" carré rouge en haut sur la carte c'est Union Square, qui est également annexé par Oracle pour installer un scène et des tentes VIP. le "petit" groupe violet/vert/bleu ciel en haut, c'est JavaOne.


Vous l'aurez compris, on ne parle pas des même dimensions. Une armée de bus fait la navette pour amener les conférenciers de leurs hotels au centre de conférence. L'une d'elle s'arrêtait devant mon hotel, la Kabuki à JapanTown, cependant j'ai vite compris qu'il valait mieux pour moi prendre les transports publics 20 mètres plus loin qui s'arrêtent pile devant le Hilton de JavaOne, plutôt que de poireauter 30 minutes pour ce bus climatisé qui passe d'abord par les Moscone - question de priorité !


 Le hall d'accueil de ces trois centres de conférence est à la hauteur de l'événement, entièrement recouvert d'affichages aux couleurs d'Oracle. Pénurie de peinture rouge à prévoir dans la vallée pendant quelques semaines.


 Dans le hall d'expo, énorme déception. Je pensais, vu l'étendue et la démesure de certains stands, qu'on aurait droit à de super goodies hors norme. Que nenni, un stylo à bille Accenture et un bonbon à la mente EMC, rien de plus.


Par contre, à ma grande surprise les exposants de ce "Oracle World" vont très au delà du monde informatique. On retrouve donc les partenaires techniques d'Oracle (éditeurs, service, ...) mais aussi tout ce qui va avec la population "Executive" qui se presse dans ces allées, comme par exemple un stand Emirates qui vous fait essayer le siège de la première classe de ses nouveaux A380 ! C'est comme si pour Devoxx on avait un stand "fnac" qui vous propose le tout dernier clavier ergonomique.

Dans le genre, le plus comique concerne le badge de Sacha Labourey, CEO de CloudBees. Avec son titre, il a eu droit à un badge "Executive Edge", qui lui permet :

• d'avoir accès à Union Square pour les repas. A noter que, même depuis JavaOne, ça fait une trote et ça monte raide, alors qu'on mange tous les sandwich certes moins bons de J1, mais dispos sur place
• d'être invité à un tournois de mini-golf sur le stand Adidas avec un sac de golf garni à la clé.

Dans mes précédents billets, je vous ai parlé de JavaOne côté technique, mais il y a un autre aspect de la conférence que vous pouvez plus difficilement vendre à votre patron pour obtenir votre billet, et qui pourtant fait pleinement partie de l'événement : les Parties ! (attention à ne pas confondre avec un autre type d'activité annexes).

Premier exemple du genre : invité par Ludovic Poitou pour un "apéro Forgerock", je viens donc prendre un verre dans un pub proche de la conférence, privatise pour l'occasion. L'occasion de rencontrer des gens en tout genre, dont quelques têtes connues