new Blog( perso );

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é.

Retour avec Brian Goetz, cette fois pour comprendre comment les lambda sont implémentées. Comme je n'ai pas pris de photos de cette session, j'agrémente ce biller de quelques images prises au hasard :)

L’introduction des lambdas dans Java aurait pu se faire en introduisant un type « Function » dans la structure du bytecode. Cependant, ce genre d’évolution et les impacts en termes de compatibilité nécessitent de longs travaux, aussi une modification dans le compilateur est largement préférée !



On pratique déjà plus ou moins les lambda dans le code java avant la version 8 via les « interfaces fonctionnelles » n’ayant qu’une seule méthode (Runnable, Comparable, …). Première idée donc, simplement demander au compilo de convertir chaque lambda en inner class anonyme. On se retrouverait alors avec une classe par lambda dans le code, autant dire que le nombre de classe par fichier source java exploserait rapidement, et surtout un appel de constructeur par appel de lambda, et là vos perfs s'écroulent.

Seconde idée, utiliser les mécanisme d’invocation du bytecode pour convertir la lambda en méthode statique et l’invoquer. Idée intéressante mais dont les impacts sont peu évidents sans plus de recul, et n’oublions pas que ce genre d’évolution devra rester dans toutes les versions à venir de Java, pas le droit à l’erreur ! (voir l’article précédent sur les génériques pour vous en convaincre…)

Java 7 a cependant ajouté un truc bien sympa, le invokeDynamic qui profite déjà à Grovvy 2.0. Ce mécanisme permet d’attendre l’appel de méhode pour identifier la cible à invoquer, passerelle vers l’exécution rapide des langages dynamiques sans payer le prix de l’API de réflexion. Un MethodHandle peut ainsi être utilisé pour pointer vers la méthode à exécuter. Détail important, ce "pointeur" peut changer à chaque invocation, mais en pratique est souvent fixe, et peut donc être caché pour obtenir des performances proches d’une invocation directe.

L’ajout de invokedynamic, au départ pour ouvrir la porte aux langages dynamiques, profite ainsi aux lambdas. La JRE Java 8 propose ainsi une factory pour identifier le MethodHandle, et le conserve en cache tant que les types des arguments ne changent pas, ce qui est le cas pour la majorité des cas d'usage de lambdas. Cette factory peut au choix générer du bytecode, utiliser des wrappers, des proxies, ou des API internes, les lambdas sont « neutres » au niveau bytecode et laissent la porte ouverte pour de futures nouvelles stratégies ou améliorations, ou bien s’adapter en fonction du contexte : JRE embarqué par exemple.


Tout serait merveilleux, sans l’un des mécanisme les plus poluants que Java ai pu inventer : la sérialization.

Si ma JVM a généré du code, que je le sérialise, et qu’une autre JVM, basée sur une autre stratégie tente de le désérialiser, que va t-il se passer :-/ ? D’où … une factory pour la serialisation, dont le but est de capturer la « recette » de la lambda pour être capable de la reconstruire sur la JVM cible. Ce qui veut dire qu’il faut prévoir qu’un vilain programmeur pourrait construire à la volée un flux sérialisé comportant du code malicieux, et l’injecter par ce biais dans votre JVM, ce qui ne serait vraiment pas gentil …. Hum, ça donne envie, n’est-ce pas ?

Au final, une lambda est, en termes de performances, au pire équivalente à une inner classe, et dans de nombreux cas (pas de capture de variables du contexte) 5 à 20 fois plus rapide. Bref, pour une fois on pourrait bien avoir une évolution bien foutue dans Java !

Ce talk était un véritable show, entièrement réalisé en live coding. Speaker boosté aux stéroïdes, humour et contenu, une super session.
Dans le texte qui suit, je note les génériques avec des accolades carrées "[ ]" car blogger est une grosse bouse qui ne gère pas l'échappement des balises html. Je n'ai pas non plus réussi à éviter les &amps ... 



Les generics ont été introduites dans Java pour résoudre un problème qui n’existe QUE parce que le langage est statiquement typé. Cette version « simplifiée » des templates C++ a fait couler beaucoup d’encre, entre autre pour débattre de sa syntaxe particulièrement … pourrie.

Je vous passe la partie « good » de la présentation, les génériques permettant en substance d’écrire moins de code et d’éviter de se tromper en mettant des oranges dans un panier de bananes.

Si on décompile un bout de code qui manipule une List[foo] on constate qu’il ne subsiste rien du paramètre de type dans le bytecode. Cet effacement, nécessaire pour assurer la compatibilité, fait des génériques un simple « sucre syntaxique » pour éviter au développeur de caster ses variables, opération qui sera bel et bien présente au final dans le bytecode (checkcast). Les choses se compliquent lorsque vous créez une méthode foo(List[fruit]) qui veut naivement ajouter une Orange dans le panier. Le compilo vous insulte. C’est là que l’on mesure l’intelligibilité de ces génériques, sur lequel Dr Odersky (qui créa Scala par la suite) a bossé, faut-il y voir une relation de cause à effet (#troll et mauvaise foi inside). 

Il faut donc écrire foo(List[? extends Fruit]), pour lequel le mot clé extends n’a RIEN à voir avec le sens classique du terme, comme si un mot clé plus spécifique n’avait pas pu être introduit ici, genre le compilo est très con il ne sait pas identifier un mot comme réservé lorsqu’il est dans une expression générique et le laisser libre dans les autres cas … j’ai toujours été ébahi que le mot clé « class » ne puissent être utilisé comme nom de variable, alors qu’il n’est utilisable dans le langage QUE pour des éléments très spécifiques et facilement identifiables. Ca montre que le compilo est basé sur une analyse lexicale puis sémantique à la grand papa, dommage.

On passe ensuite à la paramétrisation (ça se dit ça ?) des classes, et un petit rappel du principe de substitution de Liskow, qui nous amène à la conclusion qu’on ne devrait quasiment pas utiliser l’héritage et lui préférer la délégation, ce qu’on ne fait évidement jamais en java tellement il est simple d’écrire Foo extends Bar - à moins d'utiliser lombok et @Delegate, rendez-vous au prochain JUG pour en savoir plus. Après cette parenthèse, la leçon à retenir est que List[orange] n’étend pas List[fruit], certes à juste titre, mais qui crée en général des nœuds au cerveau pour les développeurs novices.

Pour copier les oranges d’un panier d’orange dans un panier de fruit il faudra donc écrire : copy(List[T] source, List[? super T] target)
une nouvelle fois en utilisant un mot clé existant dans un contexte ou son sens est complètement détourné et peu intelligible. Nos génériques, avec une syntaxe de m…, sont nées pour mourir à la compilation, ce qui porte le doux nom de Type Erasure. Confronté au même problème, C# a choisi de casser la compatibilité ascendante pour promouvoir la réification de type (essayez de placer ça dans la conversation, ça fait mec intelligent).

L’effacement de type n’est pas systématique tout de même, ainsi un [T extends Comparable] sera traduit dans le bytecode par un type Comparable. Par contre, un [T extends Comparable & Serializable] - et oui, on peut aussi faire ça, le saviez vous ? pas moi - ne verra plus aucune trace du Serializable dans le bytecode. Le « & » dans une expression générique n’est donc pas commutatif ! fun non (ou très con, selon les goûts) ?

On passe rapidement sur l’absence de support pour les types primitifs, qui nous collent ainsi du boxing/unboxing caché, source de NullPointerException, sans doute mon bug préféré. Un petit mot sur l’impossibilité de construire une instance du type paramétré (sauf à bricoler avec de la réflexion), et on enfonce le clou avec cet exemple : partant d’une interface :
EventListener[t] { void onEvent(T evt) }
vous ne pouvez pas créer une classe Foo implements EventListener[String], EventListener[number], car le code Type-Erasé subira une collision de méthode !

Pour conclure, on prend un exemple ou une classe paramétrée Foo[T] tente de maintenir un compteur statique de son nombre d’instance. Le compteur est alors global, et non par type considéré, et comble du bonheur on ne peut même pas écrire Foo[String].getCount() sans se faire insulter par le compilateur.



Bref, si certains arguments touchent à des utilisations peu communes des génériques, le talk aura proposé un tour assez complet de leurs impacts sur Java, aussi bien au runtime que dans le code source, et démontré la nécessité de toujours définir l’usage attendu des arguments de méthode lorsqu’il sont paramétrés, selon qu’on veut en extraire des données (extends) ou en ajouter (super).

Brian Goetz, que vous connaissez peut-être pour le livre « concurrency in java », présente l’historique et le rôle des lambda qui apparaitrons en java 8.

Java est le dernier langage majeur à ne pas disposer de « closures » - même C++ en a dans sa dernière mise à jour ! Si le concept pouvait paraître trop avancé à l’époque de java 1.0, qui visait à proposer une plateforme simple et accessible (comparée à C/C++), les temps ont changé et Java se doit de s’équiper de ce bagage devenu indispensable, comme nous allons le voir.


Une lambda est grosso-modo une méthode anonyme qui peut accéder au contexte lexical depuis lequel on l’invoque. La syntaxe a longtemps été débattue, et je ne suis pas super fan de celle que a été retenue - j’aimais bien #(params){ … } - mais comme pour le reste ce n’est qu’une question d’habitude.

Pour mettre en évidence le rôle des lambda, Brian part de l’exemple du traitement d’une collection par itération. Le foreach traditionnel, dit « itération externe », oblige le code client à interagir lourdement avec la « librairie » (java.util.collections). L’iterateur et ses méthodes hasNext() / next() montre d’ailleurs un soucis d’implémentation avec une inévitable duplication de code. Les lambda, bien au dela d’un simple changement de syntaxe, permettent de passer à une « itération interne », où on laisser à la librairie le soin de traiter l’itération et d’invoquer le code client au bon moment (un peu comme avec le pattern visitor).

Le traitement en parallèle d’un collection devient alors très simple à mettre en œuvre, en exposant simplement un mécanisme de Stream, et une approche fonctionnelle du code, avec des appels chainés de méthodes de filtrage, mapping ou aggregation, plutôt qu’impérative - il va falloir ressortir vos cours de Lisp :P. Ce petit pas vers la programmation fonctionnelle pourra aussi vous aider à mieux appréhender des langages fonctionnels comme scala et clojure, et donc à élargir votre panel de compétences.

Cette possibilité de prendre en charge le parallélisme du hardware avec un moindre impact sur le code est le principal argument qui a poussé la mise en œuvre des lambdas, afin de permettre à java de bénéficier de la multiplication des cœurs. Le « fork-join » de java 7 est en effet encore bien trop complexe, verbeux et différent d’une itération classique pour être significativement adopté en dehors de code très critique. Les lambdas ne suffisent cependant pas pour permettre à java de devenir un bon language multi-cœur, car il faut faire avec l’héritage en place, à savoir l’API collections.

L’évolution de JDBC a montré que l’ajout de nouvelles méthodes dans une interface est une erreur catastrophique (regardez le build de commons-dbcp pour vous en convaincre). Aussi les default methods ouvrent la voie à de nouveaux usages sans briser la compatibilité. Lambda et default methods ont donc été introduites dans Java 8 avec un objectif bien précis, et leur impact général est encore délicat à estimer.

Les default methods ont fait penser à l’arrivée de l’héritage multiple en java. Techniquement parlant cet héritage existe déjà, par contre il est restreint et ne permet pas l’héritage d’état. Cela s’apparente aux extensions method de C# pour ceux qui connaissent. En case de conflit sur une default method, si j’implémente Foo et Bar qui définissent toutes deux la default method blah(), le compilateur réclamera une redéfinition explicite. Ce mécanisme est donc prévisible et mentalement acceptable, ce qui n’est pas forcément le cas de l’héritage multiple dans d’autres langages qui nécessitent un esprit bien entrainé.

Cette session repositionne donc l'introduction des Lambda et des default methods dans java 8, avec un objectif précis au départ, et un potentiel évident sur de nombreux autres domaines. Il est intéressant de voir que ces évolutions sont parties d'un besoin spécifique, et pas juste d'une volonté d'apporter un nouvel élément de syntaxe à Java.

Pour la première journée de conférences de JavaOne (qui suit les keynotes du dimanche) j'attaque avec CON6256 - il y a tellement de conférences qu'organiser un planing est un challenge en soit !

Cette session, c'est tout simplement celle de mon collègue Kohsuke, sur l'utilisation avancée de Jenkins.  Il faut croire que je n'ai pas eu ma dose avec la JenkinsConf de la veille :P La salle est bien pleine, malgré l'heure matinale.

Kohsuke présentait donc en une heure l’utilisation de Jenkins pour l’automatisation du processus de développement, introduisant de manière progressive les plugins adaptés pour porter un « pipeline » complet.


En premier lieu, il présente les paramètres de job puis le parameterized build trigger plugin. Derrière ce nom à rallonge peu expressif se cache un plugin majeur qui permet de définir des jobs très génériques et de les chainer de manière efficace en jouant sur leurs paramètres. Après une rapide démo, Kohsuke présente le plugin join en insistant sur ses limites, utilisable uniquement pour les cas simples, et laissant le suspens pour la suite.

En jouant sur ces plugins, KK montre comment découper un job long en plus petits traitements plus faciles à paralléliser et à distribuer sur une infrastructure de machines « courantes ». Kohsuke présente ensuite la notion de promotion, utilisant cette fois le résultat du job comme déclencheur d’une promotion, qui active alors un processus de QA. Ce mécanisme permet de lier les jobs de deux équipes (Dévelopeurs et Qualiticiens) tout en laissant à chacun toute la liberté nécessaire sur la configuration du job.

Pour aller plus loin dans la mise en place d’un pipeline, KK aborde la problématique de la transmission d’un binaire entre jobs. Le plugin copy-artifact est présenté, il permet en effet de récupérer le binaire archivé par un job, sous sa forme de « dernier build stable » ou même de « résultat du build qui vient de déclencher ce job » (upstream). Il montre également l’utilisation des fingerprints pour identifier un binaire facilement dans l’instance jenkins et créer ainsi des références entre jobs sans configuration lourde. Kohsuke présente enfin le plugin maven-repository-server, qui transforme votre Jenkins en repository maven, permettant ainsi de faire facilement référence au binaire upstream de manière maven-compliant, ce qui est délicat avec le plugin copy-artifact. Je vous recommande également cet excellent plugin si vous ne le connaissez pas, afin de découper un job maven massivement multi-module comme certains les aiment en enchainement de jobs plus légers.
Petite anecdote : KK venait juste d’installer le plugin en question sur son instance de test avant le début de la session, ce qui amha était quelque peut risqué :). 

Afin de simplifier la configuration de la chaine de jobs qui commence à apparaître, KK présente le build-flow plugin, puis en fait une démo sans oublier de me faire un clin d’œil en passant mon nom comme paramètre du build.



J’apprécie la publicité gratuite, à moins que ce soit un encouragement pour que je prenne le temps pour faire avancer ce plugin dans le bon sens. Nous avons eu par la suite d’intéressantes discussions sur les possibles évolutions du plugin, tant en termes d’expérience utilisateur (validation du DSL) que d’extensibilité par d’autres plugins.
Kohsuke présente aussi le plugin Jenkow, déjà exposé à la JenkinsConf, qui utilise une approche différente, assynchrone à l’extrême, en déléguant tout le chainage des jobs à un moteur BPM. Avantage de ce plugin, la configuration du flux de jobs se fait en mode purement graphique dans Eclipse, puis le résultat est pushé dans jenkins via un repo git virutel. Idée intéressante à développer également pour le build-flow via l’introduction d’un fichier décrivant le DSL que l’IDE sait interpréter pour assister la saisie.

Enfin, Kohsuke aborde le problème de visualisation du résultat de tous ces jobs. Il présente d’une part la vue « project relationship » qui utilise les fingerprints pour tracer les relations entre job, ce qui peut devenir délicat avec un même binaire qui passe de job en job pendant les étapes du pipeline. Il présente également le plugin job dependency graph permettant de visualiser les liens entre jobs, et qui gère même les relations créées par le copy-artifact, puis le build-pipeline dont il fait une démonstration sur la base de son exemple précédent.



Le plugin build-flow comporte une tentative (pour l’instant pas très concluante) de visualiser les relations entre build, dans l’idée que deux exécutions successives peuvent faire intervenir des jobs très différentes - contrairement à ce que le build-pipeline présuppose. Je vais probablement extraire ce code dans un plugin dédié et le rendre générique. J'utilise pour l'instant jsPlumb qui permet de tracer simplement les liens entre jobs, et je regarde du côté de JGraphx pour l'algorithme de layout permettant de positionner les jobs -- s’il y en a parmi vous que cela intéresse et/ou qui connaissent bien le tracé de graphes acycliques orientés :) …

JavaOne commence dès le dimanche avec une grande keynote en guise de tour de chauffe, mais pour ma part j'étais évidemment aux côté de l'équipe CloudBees pour l'organisation de la seconde Jenkins User Conférence dans la silicon valley.


Pour l'occasion, André avait mis le paquet pour se fondre dans l'ambience de l'événement :)

Avec deux tracks en parallèle, la journée a été riche en informations. Elle a été aussi riche en échanges et en longues discussions avec les trois members du board jenkins-ci.org, et la large communauté à avoir fait le déplacement (250 participants).

J'ai particulièrement apprécié deux sessions consacrées au développement de plugins Jenkins et à expliquer les concepts et pratiques associées. J'avais ébauché une documentation du développeur newbie, il semble que la motivation revienne pour m'y remettre, avec de nouvelles idées et peut être même un peu d'aide :)

Pour cette édition, nous avons tenté en fin de journée d'organiser le "governance meeting" à la fois sur #IRC et en direct, pour permettre aux participants de découvrir son fonctionnement et d'interagir plus naturellement. Je ne suis pas sur que ceux qui ont suivi cela depuis la console IRC on tout compris, mais le format, à la "castcodeurs live" était très sympa. De nombreuses personnes semble grace à cela intéressées pour participer plus activement à la communauté en se joignant à ce rendez-vous bimensuel.

Retrouvez quelques images de cette conférence sur mon album Google+

Arrivé vendredi dans l’après midi, j’ai pour une fois une journée complète pour visiter la ville, ce qui m’évitera d’avoir fait 14h d’avion pour ne voir que l’aéroport et la salle de conférence, comme cela m’arrive souvent. Me voici prêt à explorer la ville dès 6h, jet lag aidant.

Je commence par remonter Van Ness, large avenue au bord d’une zone d’habitation bourgeoise. L’architecture typique se retrouve dans chaque bâtiment du quartier : entrée avec porche à colonnes, fenêtres en bow-window, façade largement décorée de moulures mises en couleur.


Je rejoind fisherman's wharft, autrement dit les anciens quais qui sont pour beaucoup convertis en lieux chics ou touristiques. Un vieux tramway en bois, soigneusement entretenu pour conservé le cachet de ce secteur très prisé, me permet de rejoindre le centre en longeant la côte jusqu’à l’embarcadero, qui débouche sur Market Street, grande avenue qui ouvre l’accès au centre ville.


Gratte-ciels et palaces de luxe, nous voici au cœur de la city à l’américaine, où les taxis jaunes se frayent un chemin dans une circulation dense. Je passe au Hilton Union Square, récupérer mon badge « presse » pour JavaOne. Pays de tout les contrastes, au pied même de cet immense hotel de luxe on croise tous les dix mètres un homeless, souvent handicapé, que le système social libéral n’a pas épargné, et qui subit les prix ahurissants de cette ville symbole de la silicon valley.


Je remonte à travers le centre pour rejoindre Union Square, privatisé par Oracle pour installer les tentes de ses animations VIP. Je monte dans un de ces fameux cable car, sorte de funiculaire héritage de l’histoire de la ville, et qui on survécu grâce au tourisme. Le charme et la mécanique basique de ces engins ravis les touristes qui sont nombreux à faire la queue.


Accroché au cable qui court sous la chaussée, l’engin de fer et de bois attaque la pente de russian hill qui délimite le nord de la ville. On est content de ne pas être à pied ! San Francisco à quelque chose d’une ville de montagne par endroit, avec des rues à 45° très impressionnantes. Dont la célèbre « lombard street », dont la pente est si extrème que la ligne droite aurait été suicidaire.



A nouveau au nord, je longe fort Mason en face de la célèbre prison d’alcatraz pour attraper un bus qui m’emmène tenter ma chance pour prendre le golden gate en photo. Le climat très particulier de SF se confirme : le pont est noyé dans une brume épaisse. San Francisco est la ville qui bénéficie d’un micro-climat différent dans chaque block. Quand il fait grand soleil et 35° sur San José, le centre pointe à 28° sous un petit vent frais et la plage pacifique de SF est noyée dans la brume et peine à dépasser les 20°.
Mark Twain aurait dit « Mon plus dur hiver a été un été à SanFrancisco ».



Histoire de m’oxygéner, je reviens à pied en remontant la Presidio Promenade, dans ce quartier étonnant préservé de l’urbanisme galopant qui règne partout ailleurs sur la péninsule.


Les épaisses pelouses verdoyantes contrastent avec le sol plutôt asséché que j’avais aperçu en arrivant de l’aéroport depuis le BART. Dans les quartiers moins chics du sud de SF, l’immensité et le mimétisme géométrique de l’urbanisme retire toute âme au lieu, sans même parler de ces rues, nues de toute trace végétale, qui sont « juste » numérotées de 1 à 42, et donnent à l’ensemble un aspect sans saveur.



Retour au centre en bus et passage par ChinaTown, véritable ville dans la ville, bouillonnante de vie. Un resto chinois me permet de préparer l’après midi, avec un plat dont la générosité aurait probablement pu nourrir une ou deux autres personnes (ce qui contrastera avec les sandwich de javaOne).


Un rapide passage par le financial district, puis, lassé de ce centre ville, je prends un bus pour rejoindre l’ouest de la ville et Golden Gate Park (perdant au passage 5°). La géométrie de la ville a au moins l’avantage qu’on a pas vraiment besoin de plan pour s’y retrouver, il suffit de compter les rue, encore que SF innove avec la Market Street qui passe à 30° des autres :P


Golden Gate Park est une appréciable bouffée d’oxygène, où les habitants sont nombreux à venir profiter des grands espaces verts et des rues fermées à la circulation pendant le week-end.

Au centre de Stow Lake, Strawberry Hill est une étonnante colline aux pentes raides et à la végétation exubérante, au milieu d’un quartier qui semble par ailleurs assez plat (si si, il y a de quartiers plats à SF). La vue aurait sans doute été intéressante sans la brume maritime qui envahi maintenant l’horizon.



Je m’offre la visite du Japanease Tea Garden, magnifique jardin au style asiatique (n’y connaissant rien je ne préciserait pas si c’est Zen, Thao ou juste Californien) qui permet de prendre un bon bol de vert et de se ressourcer un peu au calme.


Un peu plus loin l’académie des sciences et le Young Museum, deux imposants bâtiments à l’architecture antinomique, attirent un public nombreux. Le premier expose ses colonnes et ses moulures, le second se cache derrière sa cuirasse métallique.

Je remonte ensuite le parc, qui semble être le lieu obligé pour fêter les événements familiaux autour de grands piques-niques - il faut dire que les jardins privés on l’air particulièrement exigus). Je me retrouve alors au milieu d’une impressionnante rencontre de customs et voitures de collection - et oui, on est au US tout de même :P

Je passe le dutch windwheel qui marque le bout du parc cet j’arrive enfin à l’océan, sur une place au sable fin (mais gris) noyée dans la brume, ce qui ne semble pas décourager les surfers. Il ne me reste plus qu’à reprendre un bus qui remonte une des ces interminables streets qui traversent SF de part en part, pour rejoindre le 21th amendment, lieu de rendez-vous pour quelques participants à la JenkinsConf du lendemain.



Bien que courte, cette visite de SF a été une belle journée pour moi, pleine d’étonnement. Cette ville est vraiment un lieu à part, qui peut, en moins d’une heure – ou en se déplaçant de quelques blocks, passer d’un beau soleil à un hiver sibérien.

PlexusCipher _cipher = new DefaultPlexusCipher();
String bare = _cipher.unDecorate( "{...=}" );
String master = _cipher.decryptDecorated("{...=}", SYSTEM_PROPERTY_SEC_LOCATION);
System.out.println( _cipher.decrypt(bare, master) );

1. d'éviter que vos mots de passe apparaissent en clair, par exemple lorsque vous ouvrez votre fichier settings.xml en plein pendant une démo lors d'une conférence (non, ça ne m'est pas arrivé :P)
2. de vous permettre de séparer l'accès à vos mots de passe en deux fichiers. Un attaquant opportuniste qui vous piquerait l'un des deux éléments ne serait pas plus avancé.

Une fois n'est pas coutume, pour être lisible de mes hôtes je rédige ce billet en pseudo-anglais (c'est comme le pseudo-code, ça ne compile pas mais ça donne l'idée générale)


Last week, praqma was organizing in Copenhague a "Jenkins User Event". A User Event, compared to JenkinsConf, is a lighter meeting with (suposed to be) reduced costs organized by volunteers. Praqma got sponsorship from both CloudBees and Programing Research so that they can book a high quality conference room and prepare a nice meeting with all commodities.

That was my first travel to Danemark. I enjoyed the winds-farm on northern sea as well as the duty-free lego shop at airport, but didn't have much time to discover the city - so will have to come back next year ;)


Thursday was about a Jenkins Code Camp (aka "hackathon"), that I joined late at 2pm due to flight being delayed. 20 geeks were talking about some technical issues, new features, implementation strategies for a large set of topics. I contribute a group to solve an integration issue by creating a new extension point in jenkins-core. Those already confident with jenkins development helped to write this code, some discovered the extension point design as well as way to contribute to jenkins (github pull request, etc), some were looking at jenkins source code for first time so learned a lot.



Day ended with beer then a chinese restaurant (typical Danish food :P), with lots of fun and nice discussions.

Ajouter une légende

Friday was the Jenkins User Event. To reduce costs for such an event, compared to other Jenkins Conferences organized by CloudBees this year, lunch was not provided and conference program was "packed" into afternoon. This let praqma get a "reasonable" cost for this nice event, but still have a high quality conference, with printed programs, goodies, and coffee break. All praqma team was involved to make this event as pleasant as possible for all attendees, thanks a lot to them for contributing !

Conference was sold-out on friday morning, with 80 attendees.

After Lars Kruse welcome speak, and CloudBees to announce partnership with Praqma for DK, the conference started with two options : either an introduction to Jenkins, or an open-space discussion (~barcamp-like) for those that already know it well. I joined a small group first discussing about pre-tested commit, and then we divert speaking about best-practices, job and test performances issues, etc. Was a great exchange with interesting feedback.

The rest of the conference was single-track.


1rst session was about "facilitate strategic reuse of software" using jenkins CI. This session exposed how a industrial company changed it's internal software development practices and team organization to share components and be more efficient. This for sure introduced some coordinations and integration costs but resulted in a significant productivity improvement. This talk was interesting as it demonstrate that highly industrial companies (here, a low energy consuming water pumps producer) today follow development practice to share component and use continuous integration practice to help. I just wondered speaker said "Clearcase facilitated" sharing components  -I wouldn't expected those two words in same sentence :P

"Tales from the trenches" was a funny session explaining how Nokia came from stone age (manual integration with code freezes) to modern development practices. After reinventing the wheel with ~15 home made, perl-script based CI tools, they switched to Jenkins and Git as common tooling. Explanation on Git selection, evaluating multiple DVCS popularity, then migration from ClearCase, helping a lot early adopters, and later evaluating benefits (1 day / week / developer) was very interesting. Conclusion was that, "some tools a radically better" and "deep process renewal depends heavily on tools renewal".

"Continuous Code Inspection" talk explained use of industrial C++ coding standard and normative coding convention, with dedicated analysis tools. After explanation on those rules and tooling, a dedicated jenkins plugin was demonstrated. Such jenkins integration makes QA mostly a single checkbox to enable, and provide history graphs, reports, and external tools integration. Introduction was a little slow imho but content was demonstrating the power of jenkins plugin model to adapt software factory to specific industrial needs.


Coffee break with delicious Danish chocolates ...

Sony was presenting its "Huge Jenkins Cluster", with 4 master, some of them handling up to 6000 jobs, 300 slaves, 7000 builds a day an executing 175,000 tests a day for android platforms. Development teams use a dedicated slave machine with android devices connected through USB.

Such a build farm requires a dedicated support team and monitoring/maintenance tooling. IT only provides the computer and maintain the OS, but all Jenkins stuff is under the hands of a dedicated team. They evaluate plugins and core upgrades, educate teams, and analyse errors.

With 45Gb for a single full android build, they have to monitor available disk space, and developed maintenance scripts to delete old build artifacts and cleanup /tmp. They also use a local git mirror to speed-up cloning, and integrated with CFEngine-managed infrastructure to ensure no update occurs as a slave is running a build. They also significantly optimized build speed by switching from NFS to SAN, and are now evaluating XFS.

Remaining issue is about jenkins build queue (subject discussed on Jenkins Code Camp) because a 9 in the morning, thousand users connect to jenkins master and the UI widget to expose the queue status hits the queue synchronisation bottleneck.


Next talk was mine, exposing Jenkins Enterprise and demonstrating one ouf our Enterprise plugins. I'm not pleased by my talk, both because my english is crappy (maybe you already noticed?) and also because I was not confident with the standard JE slides. Assuming I jad more time to prepare this talk, and as a tribute to this Danish event, I'd have used a bunch of lego bricks pictures to present Cloudbee plugins. So I quickly left the slides to run a demo, setting-up Jenkins Enterprise to run pre-tested commits. Hope you enjoyed the talk.

Last talk was Lars one, exposing praqma "Corporate approach to opensource". This light, generalist talk was welcome as last one after a heavy-technical afternoon. Lars exposed reason to switch to open-source :

• costs - for sure, 
• but also open standards and interoperability, 
• and contribution to public good. 

This last point distinguish "innovators" that create new content and contribute to the oss project, and "free riders" that only want to save money and consume other efforts. Lars didn't went deeper into what "contributing" can be about, but spending some time joining the mailing lists, exposing detailled bug report, or writing blogs or documentation about the issues you encounter is already a huge contribution to opensource. Organizing such a great user event also is ;)



Meeting ended with a "socialize" time, sponsored by Pragmatic Research, with beer and sandwiches. A nice time to discuss with speakers, know a face to match an #irc nickname, discuss about everything geeks like to discuss about, and round off this pleasant day.

So, back in France, and hope we can find volunteers, sponsors, and a low-cost location to get a comparable Jenkins User Event in Paris the day before Devoxx France 2013, stay tunned !

mail daté du 21 août, juste avant mon départ en vacances, autant dire qu'il est grand temps de s'organiser pour un départ aux "States" fin septembre.

Etape 1 : négocier avec mon employeur préféré pour une semaine quasiment chômée au support CloudBees (rassurez-vous, mes collègues assurent dans ces cas là). CloudBees étant sponsor de JavaOne, l'équipe marketing est ravie de pouvoir compter sur moi pour donner un coup de main.

Etape 2 : trouver un vol pas cher et un hotel ... et là  c'est pas le plus facile vu que JavaOne crée un véritable vide dans l'offre d'hébergement à San Francisco. Je serais finalement au Kabuki, raisonnablement pas trop cher et bien placé (1 mile). L'hotel, un peu moins cher, que j'avais trouvé sur booking n'a pas accepté mon paiement par carte bancaire !

Etape 3 : gérer les formalités administratives ... et là évidement mon passeport n'étant plus valide, ça se complique. A savoir que la préfecture met 1 mois et demi en moyenne pour produire ce document, aussi on passe par la case "lettre justificative de l'employeur" pour demander un passeport en urgence pour raison professionnelle. Dispo 10 jours plus tard. Reste à remplir le formulaire de visa "êtes vous un terroriste ? oui - non"...

Etape 4 : changer la date de la session de rentrée du BreizhJug, justement prévue le 1er octobre. Heureusement, Julien Dubois qui viendra pour cette occasion à Rennes est assez souple sur son agenda. Je dois aussi annuler ma proposition pour Agile Tour.

Etape 5 : annoncer à madame qu'elle va devoir gérer les 3 délinquants juvéniles pendant une semaine. Sachant que je pars déjà à Copenhague (Jenkins User Event) puis à la Rochelle (JugSummerCamp), juste pendant la rentrée scolaire, je sens qu'il va falloir être très très gentil, et que je lève le pied en Octobre pour la préparer psychologiquement à rempiler pendant Devoxx ...

La suite ... bientôt ! J'essayerais de vous faire vivre JavaOne en live sur ce blog (vu que c'est tout de même ce qui me donne mon billet, il va bien falloir faire le boulot).

Le JugSummerCamp 2012 vient d'annoncer son programme. Je ne m'attarderais pas à essayer de vous convaincre de la nécessité de vous joindre à cette merveilleuse conférence, qui a su doser à la perfection décontraction et excellence technique pour une rencontre inoubliable (bref, un peu comme le BreizhCamp quoi :P)



Par contre, vous aurez peut être remarqué dans le programme la session de Julien Dubois. Voici donc 10 raisons pour ne pas perdre votre temps avec cette session :

1. C'est le sujet qu'il a présenté à Devoxx, et que vous avez peut être déjà vu ou que vous pouvez consulter sur Parleys.
2. Ca parle de Spring, HTML5, Rest, Cassandra, bref rien que des technologies sans grand intérêt.
3. C'est programmé juste après le repas, autant dire qu'à cette heure là avec la digestion ça va être dur d'encaisser un cours magistral sur NoSQL
4. Le sujet est l'application Tatami, le Twitter-like de Ippon. Tout le monde sait bien que ça ne sert à rien twitter, surtout en entreprise - d'où la configuration du proxy qui le bloque d'ailleurs.
5. Julien sera au BreizhJug le 1er Octobre pour nous présenter ce même sujet avec plus de temps pour répondre à toutes vos questions, alors autant attendre un peu.
6. A la même heure il y a une excellente session que je vous recommande vivement.
7. Julien a un gros nez.