new Blog( perso );

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

Il n'y a pas qu'en informatique que le mouvement "DevOps" ferait du bien...

anecdote :
J'attends un colis depuis 15 jours. Le livreur a déjà laissé un message indiquant qu'il ne "me trouvait pas sur son GPS". J'appelle donc le service client qui planifie une nouvelle livraison.
Arrive donc le soir sans nouvelle du livreur, et j'apprend auprès du service client que "le livreur n'a encore pas trouvé, alors il a déposé le paquet chez une autre cliente du bourg, qui connait (ma) femme car elle a ses enfants dans la même école". Hum, génial. Faut-il préciser que, n'ayant pas le numéro de colis, il a fallu 10 minutes pour retrouver la référence.

On se dit évidement qu'on a affaire à des guignols, sauf qu'il s'agit d'Exapaq, un spécialiste de la "chaine logistique". Mon colis a donc traversé la france, un code barre collé dessus, avec une savante optimisation des délais et du taux de remplissage des camions. Tout ça pour finir dans les mains d'un livreur qui n'a que sa bite et son couteau, ou plutôt un GPS, pour me trouver. Aucune validation préalable de l'adresse. Le pire amha, c'est qu'après une première livraison manquée, l'adresse n'a pas été vérifiée pour assurer une amélioration du service, et on a donc le même blocage à la livraison. Il faut dire que mon lieu dit est identifiable sans soucis sur google maps ou pagesjaunes, et peut être normalisé par les services d'adresse de la poste, ce n'est donc pas une "colle" pour les livreurs (qui s'en sortent très bien d'habitude).



Ok, quel rapport avec DevOps ?

Et bien, cette petite mésaventure (j'espère que ma femme ne sera pas surprise de recevoir son cadeau d'anniversaire de la main d'une parent d'élève) me fait penser à la façon dont j'ai travaillé pendant quelques années :

En dev, on avait un déploiement continu sur la plateforme de qualification. En 20 minutes d'un build 100% automatisé, la "dernière version stable" était disponible pour validation par les équipes de test. Ca a duré plus d'un an et permis d'aller très vite. Et au final, on a fait un tar.gz avec un ficher csv dedans, fichier sensé servir de descripteur d'installation (sic). J'ose imaginer ce que les Ops ont pensé de notre soft lorsqu'ils ont du le mettre en prod.

Moi utilisateur, je me suis retrouvé en contact des deux "ops" : le livreur et le gars au bout du fil du service client. Le premier n'avait aucun outil autre que la démerde pour me livrer et continuer sa tournée calculée à la minute. Le second devait retrouver mon colis dans un SI qui ne connait que les codes barree. Pas de recherche par nom, code postal, etc. Si je n'avais pas retenu la date du coup de fil du livreur, qui a amené aux bons de retour, puis (enfin) à mon colis, on en serait encore à se demander ou le collier de perles véritables de ma femme est passé (non, je déconne).

Nos "Ops", ils ont un livrable dont il ne savent que faire, parce qu'il est conçu pour le silo des "Devs" en amont, dont le soucis est d'aiguiller des centaines de colis dans une armada de camions. Les outils qui leur permettraient à être efficaces dans leur boulot à eux, amener le colis au client dans les meilleurs délais, n'a pas été pensé. Le service client n'a même pas pu vérifier mon adresse qui n'est indiquée que sur le bon du livreur !

Pour rester sur le côté "DevOps", si on ajoute dans l'équation l'assurance qualité, j'aimerais demander à Exapaq à qui je dois indiquer mon mécontentement sur les délais et le déroulement de cette livraison, sachant que lors du premier appel j'avais clairement indiqué ne PAS vouloir que le colis soit déposé chez quelqu'un d'autre (on m'a même proposé de le laisser à la boulangerie), sachant que j'e n'avais pas du tout l'intention de me lâcher sur le service client qui a fait tout son possible pour m'assister (ça doit être de bosser moi-même au support qui me donne ce réflexe). Ce sera donc par ce billet que j'espère qu'ils apprendront à s'améliorer et à considérer la "chaîne logistique" dans son ensemble.

Amusant, le site web http://www.exapaq.com/  nous montre un gentil livreur qui apporte le colis, pas une armé de manutentionnaires dans un grand hangar ...


Capilotracté ?

"Maven télécharge tout l'Internet", ça doit être la phrase la plus couramment utilisée par les développeur Java (juste après "Eclipse est encore planté"). En bossant chez CloudBees j'ai le plaisir (?) de découvrir des outils de builds en tout genre que nos utilisateurs veulent mettre en oeuvre sur DEV@Cloud, ou même notre propre équipé d'ingé qui - semble t-il - a pour règle d'utiliser exclusivement des langages de programmation que Sacha (notre CEO) ne pourra pas comprendre, histoire d'avoir la paix.



Avec Maven 2 on avait donc le plaisir de télécharger 4 ou 5 versions de commons-lang, Maven partant du principe que si le plugin P demande la version V, il faut le faire tourner avec la version V dans son classpath, et pas avec la version N demandée par le plugin Q. PV != QN, pas compliqué et assez logique.

Maven 3 ajoute une gestion avancée des méta-données et trace de quel repository vient telle dépendance pour s'assurer que votre projet ne va pas utiliser la version Q alors qu'elle n'existe pas dans les repositories que vous déclarez. Logique, mais déjà plus compliqué, et la connection au Net chauffe un peu au passage.

Regardons un peu ce qui se fait ailleurs :

En PHP, le gestionnaire s'appelle PEAR et est un petit rigolo.
pour installer le paquet "timer", on fait pear install phpunit/PHP_Timer. Simple et de bon gout. Si le paquet a des dépendances, on ajouter --alldeps pour qu'il les installe au passage. Jusqu'ici, ça va - c'est ce qu'on dit quand on saute du 50ème étage. Arrive le moment où on a un conflit de version, et le paquet "phpqatools" par exemple qui nécessite timer en version >= 1.0.4. En local, pour diverser raisons j'ai déjà ce paquet en version 1.0.2.




Pas cool. Il n'existe aucune option pour forcer un upgrade des dépendances.

La doc officielle indique même que la commande install ne va pas faire d'upgrade si le paquet est déjà présent, ce qui n'est pas mon cas :




Vous me direz, s'il faut que la doc soit à jour, ... Mettons. Bon alors moi, naïvement, je me dit je vais lancer un pear upgrade pour être sur d'avoir les dernières version installées, comme ça je suis tranquille. Et bien, la bonne blague c'est que cette commande réinstalle les librairies, même celle qui sont à jour. Super pratique pour écrire des recettes de gestion de l'infra qui vont être rejouées en boucle.

Allez, y'a plus rigolo :

En Erlang, le gestionnaire de paquet s'appelle Rebar. Alors là, on se fait pas chier : pour obtenir une dépendance, on clone son repo git. Si la dépendance a elle aussi un fichier rebar, on fait la même chose en mode récursif. Hop, voilà, c'est tellement plus simple de tout recompiler from scratch.


La différence avec Java, c'est que le compilo Erlang est très rapide, aussi ce n'est pas pénalisant, mais ce serait fun un outil de build java qui récupère les sources apache commons, spring, bidule et chose et recompile le tout. Ca tente quelqu'un ?

La dernière journée commence par la « community keynote », qui malgré les événements de la veille fait salle comble, et quelle salle ! L’ouverture est consacrée à une légitime autocongratulation des organisateurs, il faut avouer que préparer tout ceci doit les occuper quelques heures… Nos chauffeurs de sales connaissent leur affaire et s’offrent dont une ola (l’interminable salle s’y prêtant très bien) après quelques bonnes blagues, dont une sur ces bandeaux accolés aux badges JavaOne, et catégorisant votre place dans la communauté. Sharat Chander ("JavaOne Community Chairperson", i.e. organisateur de JavaOne) porte ainsi plus une cravate qu’un badge, avec une bonne douzaine de ces bandeaux !


Suit un panel de discussion sur le rôle de Java dans l’industrie, avec le témoignage de représentants d’Eucalyptus, Cloudera et Twitter. Sans grand intérêt, on y apprend que Java c’est génial, que c’est l’avenir, et que la communauté y’a que ça de vrai. Le représentant de Twitter est quasiment le seul à souligner qu’il fait partie de ceux qui aimerait voir la plateforme avancer plus vite, tout en assurant qu’une release régulière tout les 2 ans c’est déjà nettement mieux que les 4 années de misère qui ont séparé java5 et 6.

On a ensuite une présentation des travaux d'AMD pour apporter à Java le support des GPU, d'abord via une API spécifique, puis à termes directement dans le JDK avec l'aide des lambda et du traitement parallèle dans les collections. A suivre...

On enchaine avec une présentation de l’initiative du London-Jug concernant la participation de la communauté au JCP. Sur un ton plus décallé que ce qui a précédé, le discours reste tout de même assez bisounoursien, bien que l’idée de voir un JUG prendre en charge une JSR (programme « Adopt a JSR ») puis devenir membre exécutif du JCP est assez étonnante, et montre tout de même une évolution intéressante vers plus d’ouverture. Je reste cependant assez sceptique par rapport à un processus très lourd et à un manque évident de « culture opensource ». Une idée intéressante a été soulevé lors du panel précédent (comme quoi, il y avait tout de même du contenu) était d’exposer les spécification en cours d’élaboration sur github, comme le parlement allemand vient de le faire pour ses textes législatifs, afin de favoriser les commentaires et contributions de la communauté.

Suit une présentation d’un robot sensé être un truc avant-gardiste piloté en Java. La bestiole avance au pas et fait demi-tour devant le présentateur qui peine à nous convaincre qu’il est impressionné, avant de s’approcher du bord de la scène et de « bugger » à faire des demi-tours en série sans savoir se dépêtrer de cet obstacle. Je pense que la même chose peut être faite en mieux avec des légo Mindstrom, et surtout que pendant ce temps là Google obtient l’autorisation de circulation pour sa GoogleCar… Si c’est ça « make the futur java », on est pas rendu. Comble du ridicule, ils nous présentent alors un "capteur de pensée" qui est sensé détecter les ondes cervicales via un capteur sur le front et "lire" la volonté du pilote pour diriger le robot. Evidement ça ne donne rien, super démo les gars.



Après de nombreux effet de scène, blagues longuement préparées et questions lues sur les fiches, on a (enfin) un rebondissement pas complètement téléphoné avec l’arrivée de James Golsing qui vient présenter ses petits bateaux qui vont sur l’eau. Ont-ils des jambes ? non, des ailes, pour « nager » alimenté par le mouvement des vagues. Rien de très nouveau poru ceux qui ont déjà eu écho de ce projet, juste une démo de l’interface graphique permettant de suivre la position des robots sur un globe terrestre, envoyant au passage une pique à html5 sur la faisabilité de cette interface avec un technologie non client-lourd, basées sur des arguments complètement bidon (la réduction du nombre de points à tracer en fonction de l’échelle).



On conclut avec la présentation du nouveau Mr JavaOne, Stephen Chin , qui prend le relais de Sharat Chander après des années de bons et loyaux services, et qui va comencer en sillonnant l’europe sur sa moto avant Devoxx pour interviewer quelques figures de la communauté.
Pour ce qui me concerne, la fatigue commençant à bien se faire sentir, je n’ai pas le courage de suivre les sessions de la fin de matinée, et je préfère donc rejoindre tranquillement l’aéroport pour un voyage de « seulement » 24h : il est 20h en France et je devrais arriver @home à peut prêt à cette même heure … demain.



JavaOne est une conférence étonnante, impressionnante par sa dimension, déroutante par sa logistique (3 hôtels, des salles un peu partout), incontournable pour les entreprises du secteur (l’exhibition floor n’a pas désemplis avec de très nombreuses annonces), et une expérience mémorable pour ce qui me concerne. Je lui préfère néanmoins Devoxx dont la taille est plus « humaine » pour un contenu et des rock-stars finalement équivalentes. Disons que JavaOne est à la hauteur de la démesure américaine qu’on peu en attendre, sachant que d’après les habitués ce auquel j’ai assisté n’est qu’un pâle reflet des « grands » JavaOne d’il y a quelques années.



Quoi qu’il en soit, si vous avez l’opportunité de vous rendre à JavaOne 2013 je ne peux que vous le recommander, ne serait-ce que pour visiter la fameuse silicon-valley, mais aussi pour voir ce que l’écosystème Java représente dans notre industrie, et à quoi peut ressembler une conférence qui touche un écosystème aussi large que le notre.

Le retrait de jigsaw de la roadmap de Java 9 avait précédé JavaOne, aussi j’ai voulu voir ce qui serait présenté lors de cette session. On commence par un rappel : le JRE, c’est 50Mb de classes dont un bon paquet de legacy que votre application n’utilisera jamais. S’ajoute à cela le « jar hell » avec des classpath comportant plusieurs dizaines de librairies.

Le but de la modularisation de Java est double : assainir le JRE et fournir un mécanisme d’approvisionnement des dépendances runtime digne de ce que proposent les OS avec les paquets rpm/deb. Jigsaw utilise une pseudo-classe module-info.java pour déclarer les classes d’un module et les règles de visibilité. Cela évite qu’une classe d’implémentation, déclarée publique nécessaire pour les appels inter-package, soit tout aussi publique pour le reste du monde et bloque l’évolution des implémentations dans les bibliothèques.

Les principes de jigsaw semblent solides, assez proches d’OSGi qui lui fait concurrence en apparence. Le second élément clé de la modularité en Java concerne le JRE lui même. Avant les travaux sur ce sujet, utiliser java.lang.* « tirait » une série de dépendances qui amenait quelques aberrations comme logging ou … corba - ce qui amuse même Mark Reinhold, qui regrette d'avoir tardé à introduire la modularité dans Java et devoir cravacher aujourd'hui pour rattrapper le temps perdu. Le diagramme des dépendance ressemble à un plat de spaghetti trop cuit, ça donne l'impression que Java 1.0 a été sorti à l'arrache, une pratique courante en informatique :)



Après un refactoring des implémentations de certaines classes, le JRE devient quelque chose de nettement plus propre qui permet de ne charger qu’un sous-ensemble du JRE pour les utilisations courantes. L'histoire ne dit pas s'ils ont fait appel à David Gageot au cours de cet exercice périlleux...



Suit une démo, c’est là qu’on commence à rigoler. Partant d’un environnement vierge, quelques commandes assez touchy permettent d’approvisionner les modules nécessaires à l’application de démo puis à la lancer … lancement qui crache avec une magnifique stacktrace bien immonde. Seconde tentative selon la « other way to do it » (c’est rassurant, il y a plusieurs façons de provisionner son JRE, on a pas fini de troller sur la "bonne façon").


Le lancement de l’appli (un remake du conference-scheduler de javaone) est alors instantané, ce qui montre bien le bénéfice de cette modularisation (la JRE de base ne fait que 10Mb). Par contre, ce crash de la démo, après un premier bide du genre lors de la keynote de dimanche, ainsi que la complexité des commandes, montrent qu’il y a encore du boulot pour obtenir une implémentation robuste et utilisable par une JRE « mainstream ».

Jigsaw est une évolution réellement intéressante de Java, qui permettra de faire de la vraie Deprecation sur les vielles classes de Java. Notre JRE contient ainsi de nombreuses classes marquées @Deprecated mais qui resteront ad vitam pour assurer la compatibilité. Avec Jigsaw, ces classes pourront être mise au placard dans un module poubelle dont aucune application moderne ne dépendra, tout en assurant le fonctionnement du code plus ancien (ou mal écrit :P). Avec les default implementation sur les interfaces, Java aura ainsi les outils pour évoluer de manière concrète sans payer sans fin pour les erreur du passé tout en préservant la compatibilité.