new Blog( perso );

CloudBees, en tant que sponsor du BreizhCamp, offre une place pour Devoxx France !



Pour gagner, il faut "juste" nous montrer vos talents de développeur.

Nous avons monté, pour afficher le programme du breizhcamp, une application minimaliste : http://app.breizhcamp.cloudbees.net

Cette application, c'est à vous de la faire évoluer pour apporter les fonctionnalités et éléments techniques qui lui manquent. Attention, il ne s'agit pas de faire un monstrueux refactoring pour la migrer en grails 2 avec un build SBT et un backend Mongo, mais de proposer des évolutions par pull-request qui apportent à la fois de la valeur aux administrateurs, utilisateurs ainsi que des qualités techniques. Chaque pull-request vous apportera de 0 à 5 points (en fonction du contenu et de notre évaluation), celui d'entre vous qui totalisera le plus de points reportera la place pour un Combi 3 jours à Devoxx France !

Le concours est ouvert jusqu'au 2 avril, ce qui vous laisse peu de temps pour montrer votre talent. Le vainqueur sera désigné lors de la soirée Cloud au breizhJug

Le code source est dispo sur https://github.com/cloudbees/breizhcamp, vous pouvez tester l'application en local via un mvn jetty:run

à vos marques, prêts, forkez !

Je reprend ici le titre d'un billet comparable du blod d'Arnaud


Jenkins est devenu au fil des années l'outil incontournable des forges logicielles. Si la base de tout reste (de mon point de vue) la souplesse de votre SCM, les capacités d'automatisation passent presque toujours par lui. Quelque soit votre langage de développement, votre outil de build, ou votre environnement cible, la richesse de Jenkins et de son écosystème de plugins ne vous aura pas échappé.

Après le succès l'an dernier de la Jenkins User Conférence à San Francisco, c'est désormais la tournée JenkinsConf qui va parcourir le monde avec 4 dates prévues, dont une chez nous, à Paris, le 17 avril - soit la veille de DevoxxFrance. Je ne doute pas que vous avez déjà bloqué cette semaine dans votre agenda pour ne pas rater la plus grande conférence Java de tous les temps (en Français), aussi pourquoi ne pas profiter de l'occasion pour élargir sa connaissance des pratiques et outils qui gravitent autour de Jenkins ?

Pour l'occasion, j'ai créé une super bannière, admirez mes talents de designer :


Jetez un oeil au programme pour vous convaincre et inscrivez-vous :

• des speakers rock-stars,
• des talks mains dans le cambouis,
• des retours d'expérience,
• des présentations d'outils,
• des ateliers pratiques,
• et accessoirement, le "social hours" - mon petit préféré

Je présenterais avec Mathieu Ancelin le plugin build-flow que nous développons ensemble, et qui a pour objectif de simplifier la configuration de chaines de jobs "build pipelines".  J'animerais aussi un atelier de prise en main de Jenkins / DEV@Cloud pour ceux qui veulent découvrir cet environnement.

Au fait, pourquoi mon petit préféré ?

Parce que Jenkins, c'est aussi (surtout ?) une communauté très vivante, très ouverte, avec des centaines de contributeurs et de cas d'utilisation complètement différents. Après une journée dense avec des sujets de pointe, les échanges vont être riches et probablement pleins d'enseignements précieux. Les contacts qu'on noue lors de ce genre de rencontre s'avèrent d'une grande efficacité plus tard pour résoudre des problèmes, en allant frapper à la bonne porte, et en étant plus qu'un anonyme sur IRC. Par ailleurs, vu que Devoxx sera en cours de préparation, il faudra bien se trouver un coin au chaud en attendant ... et puis, c'est pas impossible qu'il y ait un peu de bière offerte par les sponsors.

Aussi, je vous donne rendez-vous le 17 au soir, pour une soirée "Waiting for Devoxx" à refaire le monde.

• Quicky : 15 minute pour présenter un projet perso
• Tools in action : 30 minutes pour faire la démo d'un outil sympa
• Conférence : session "classique" de une heure
• Université : 3 heures (avec pauses) pour aller jusqu'au bout d'un sujet (n'hésitez pas à vous mettre à plusieurs)
• Labs : démos, dojos, ateliers, openspace, challenges ... tout formats inhabituels (préciser la durée)

Si vous n'avez pas votre affiche, rendez-vous au prochain BreizhJug le 2 avril. Nous avons aussi plein de flyers, alors n'hésitez pas. Le succès du breizhcamp passe par vous !

Ceux qui ont eu la chance (?) de bosser avec moi savent que, en termes d'architecture des applications Java, je défends le concept de modèle métier riche, par opposition au Anemic Model Domain.

L'idée part d'un constat simple : on a souvent un beau modèle objet du domaine métier, bien adapté pour accueillir les données de l'application, et on déporte toute la logique de leur gestion dans des classes techniques spécialisées, qu'on appelle des "services" parce que c'est un mot qui peut dire tout et n'importe quoi alors pourquoi se priver ?

On se retrouve donc avec un modèle métier qui ne fait rien, noyé dans des couches de services métier, de services web, de services techniques (celui-là je l'adore) et de DAO (qu'on a pas appelé service pour une fois).

Avec JPA et ses annotations, on peut rapidement réduire la couche DAO à peu de choses, voir l'éliminer purement et simplement comme je l'ai fait avec Fonzie (un jour, promis, je reprendrai le développement ce projet ... quand j'aurais le temps). JPA étant déjà une abstraction de la persistance, je ne vois aucun intérêt à rajouter une couche DAO pour faire une requête JPA. En quoi se faire injecter un DAO est plus "propre" que se faire injecter un PersistenceContext et utiliser des NamedQueries ?

Pour aller plus loin, c'est à dire faire que nos objets métier portent eux-même la logique métier, on est rapidement confronté à un problème : nos objets ont besoin de faire appel à d'autres objets "collaborateurs" pour faire autre chose que de la conversion franc-euro. Spring propose depuis 2006 une solution via l'annotation @Configurable et l'instrumentation par AspectJ. Pour l'avoir utilisé sur un gros projet qui se reconnaitra, ça marche bien mais c'est un peu encombrant pour les développeurs (oui, AJDT, je pense à toi). Depuis, Java EE 6 est sorti et propose CDI.

Pour des besoins internes, j'ai développé une application d'intégration de services REST déployée sur RUN@Cloud. N'en déplaise à mes collègues, pas de Scala, d'Erlang ou de Ruby ici, mais du Java EE 6 brut de spécification, histoire de vérifier si Antonio raconte des bobards pendant ses conférences.

J'ai un objet métier Ticket, que je veux exposer avec JAX-RS :

@Path("/ticket/{id}")
public class Ticket {

    private int id;

    public Ticket(@PathParam("id") int it) {
        this.id = id;
        // Load data from id;
    }
}

Cela fonctionne très bien tant qu'il s'agit de faire un System.out, maintenant j'aimerais faire des choses plus concrètes, nécessitant l'utilisation d'un autre composant.

Après quelques errements, et avec l'aide de Paul, j'ai compris comment activer CDI pour obtenir l'injection de mes dépendances. Comme j'ai peur de ne pas m'en souvenir pour la prochaine fois, et que ça peut servir à d'autres, voici la recette : d'abord placer le fameux fichier bean.xml vide sous WEB-INF, puis modifier mon code pour CDI-fier ma classe JAX-RS :

@Path("/ticket/{id}")
@RequestScoped
public class Ticket {

    @PathParam("id")
    private int id;

    @Inject
    private AnotherComponent foobar;

    @PostConstruct
    public void load() throws IOException {
        // Load data from id;
    }

    @POST
    @Produces("text/plain")
    public String notify() throws Exception {
        foobar.sendNotification(id, getEmail());
        return "ok";
    } 
}

petite explication :
Dans un premier temps j'avais utilisé un constructeur prenant en paramètre l'ID du chemin REST et chargeant les données. Couplé avec CDI, je dois annoter ce constructeur @Inject pour qu'il soit utilisé à la place du constructeur par défaut, mais CDI dans ce cas cherche à m'injecter l'ID. Je ne sais pas si c'est un bug de RestEasy-cdi dans JBoss, toujours est-il que j'ai du suivre le plan B.


Je récupère donc l'ID par injection d'attribut depuis la requête REST. L'initialisation du bean est confiée à un @PostConstruct, ce qui en termes de gestion du cycle de vie est nettement plus explicite que de tout mettre dans le constructeur.


Et voila, mon Ticket est désormais un objet de mon domaine métier, exposé comme service REST, qui sur un POST gère un traitement métier via des composants avec qui il collabore et qu'il obtient par injection de dépendance. Pas besoin de TicketService, TicketResource ou autre classe purement artificielle juste introduite pour respecter un joli modèle en couches.

La loi de Moore, tout la monde la connait sans la connaitre. On la cite souvent en disant que la puissance des processeur double tous les 18 mois, alors qu'elle concerne la densité de transistors sur une puce de silicium.


Cela a longtemps été équivalent, mais vous savez que la fréquence de nos puces se heurte à des limites physiques (depuis ~2004 déjà), et que la solution est le "scaling out" : multiplier le nombre d'unités de calcul plutôt que d'en avoir des plus rapides, voie même avoir beaucoup de "coeurs" de (relativement) faible complexité  et consommation (donc dissipation thermique). Même sur une machine grand public, il est courant d'avoir 4 ou 8 coeurs, et les CPU de serveurs en affichent parfois 128, sans parler de ce que les labs nous préparent, et cela arrive aujourd'hui également dans les appareils portatifs que sont nos smartphones (le savez-vous ? on peut même téléphoner avec !).

Twitter attire ce matin mon attention sur cet article, qui présente un transistor réalisé en labo avec un seul atome. Si cette technologie va mettre un peu de temps à arriver sur le PC de Mme Michu, c'est la première fois que l'industrie du silicium va se heurter à une limite physique infranchissable. Pendant des années, malgré les difficultés techniques et les effets de l'ultra-miniaturisation, ils ont réussi à descendre toujours plus sous le nanomètre. Cette fois-ci, il n'y aura pas d'échappatoire, et la loi de Moore s'arrêtera brutalement sur un palier définitif.



Je vous laisse imaginer la complexité de réalisation et le niveau de traitement des impuretés qui sont nécessaires à une telle réalisation ...


Et le transistor quantique ? Il pourrait prendre le relais, mais nécessite pas conception un traitement parallèle pour être utile (et sans doute tout un tas d'autres "détails" algorithmiques).

Quoi qu'il en soit, on y échappera pas, il va falloir apprendre à coder "concurrent", et ce n'est pas faute de vous avoir prévenu. Et que faisons nous, encore et toujours : du code purement séquentiel.

Le Cloud (désolé, je baigne un peu dedans en ce moment) n'échappe pas à cette règle : faire du scale-out sur des machines relativement peu puissantes / peu couteuses est très efficace si le problème est correctement pris en charge lors de la conception. Prennes l'exemple de Facebook qui a envisagé de construire un DataCenter basé sur des processeurs ARM, dont le principal intérêt est la très faible consommation.

Fork-join en Java 7, Concurrent collections prévues dans Java 8, Akka nous apporte le paradigme d'acteur pour une nouvelle conception, certains langages alternatifs intègrent de base ces concepts de parallélisme pour une plus grande efficacité.


Et vous ? Avez-vous déjà codé au moins une fois un algorithme de traitement non-séquentiel ? Pour ma part, en regardant en arrière 15 années de développement, ça a été rarissime, et je suis souvent passé pour un dangereux geek en évoquant cette option (peut être aussi pour d'autres raisons). Faites moi part de votre expérience !

Un Mac, c'est beau, ça marche (presque) tout seul, et des fois ... y'a un soucis.

Dan mon cas, c'est Aperçu, la visionneuse à tout faire, qui a commencé à bagotter : cet outil permet de reprendre rapidement une image pour la re-cadrer / re-dimensionner, ce qui est très pratique quand on a 30 photos à intégrer dans des slides. Sans raison évidente, Aperçu a décidé qu'il ne voulait plus sauvegarder (sous OSX Lion, la sauvegarde est automatique et incrementale, couplée à Time-Machine). En soit ce n'était pas super gênant, juste un peu pénible de devoir lancer un soft de retouche d'image rien que pour ça.

Hier soir, faute de solution proposées par mon amis Google (faut dire, faire une recherche sur "Preview" c'est pas simple) j'ai donc tenté la restauration TimeMachine.


TimeMachine c'est un soft intégré à OSX qui réalise des sauvegarde du système en tâche de fond sur un disque dur externe. Bien plus que les "points de restauration" de Windows, TimeMachine permet de revenir en arrière dans tous vos documents avec une belle interface comme Apple sait les faire. Ici c'est l'utilisation brute-force qui m'intéresser : restaurer tous le système tel qu'il était il y a 15 jours.

Au démarrage, [Cmd +R] fournit le menu de maintenance et l'outil de restauration. La mauvaise surprise c'est que cette restauration se fait en mode override : tout le disque est écrasé, soit 500Go à faire passer par le cable USB, autant dire que je n'ai pas beaucoup bossé hier après midi...

Toujours est-il que dans la soirée j'ai retrouvé OSX en état de marche, et DropBox m'a restauré mon travail en cours. Je ne regrette donc pas les quelques euros dépensés dans ce disque dur externe, et si vous n'utilisez pas TimeMachine (ou un équivalent sous Windows ?) ... bein vous devriez.

Les outils DevOps sont quasiment tous basés sur Ruby, ce langage ayant à la fois la force d'un langage de haut niveau - au moins autant que Java en ayant une syntaxe bien plus compactes - et le potentiel d'un langage proche de l'OS, de nombreux paquets 'gem' nécessitant des extensions système re-compilées à l'installation - essayez de faire un lien symbolique en Java...


Sous Mac OS, comme pour de nombreux autres outils, Ruby est installé par défaut, mais évidemment dans une version un peu ancienne et customisée par Apple. Cela permet de faire immédiatement tourner des outils Ruby mais cela veut aussi dire qu'on risque à un moment ou un autre d'être coincé par une spécificité de la plateforme au barreaux dorés.

J'ai donc voulu installer RVM, qui est un gestionnaire de version de Ruby, permettant accessoirement de rester en mode utilisateur sans accès root. L'installation de RVM en elle même n'est pas un soucis :

bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

par la suite, on va y installer des versions de ruby et/ou de ses variantes (jRuby par exemple) - et là, ça se complique, d'où ce blog pour vous éviter d'avoir comme moi à éplucher les réponses de Google.

D'abord, il va falloir compiler Ruby lors de l'installation - je vous l'ai dit, Ruby est fortement lié à l'OS et se recompile lors de l'installation, il n'est pas distribué sous forme d'un paquet dmg installable par glisser / déposer comme les autres logiciels Mac - donc disposer d'un compilateur, ce qui dans le monde Mac signifie télécharger et installer les quelques Go de XCode ... bon, ensuite :

There has been an error while running make. Halting the installation.

Il manque à Ruby deux librairies systèmes : readline et libxml2. OSX étant basé sur BSD, on peut lui ajouter de nombreux paquets Gnu/Linux via des portages - j'utilise MacPorts.

sudo port install readline libxml2

rvm pck install iconv

Le savez-vous, les versions d'Android, l'OS pour mobile, tablettes et maintenant TVs, portent un petit nom basé sur un ordre alphabétique et des noms de sucreries : Cupcake, Donut, Eclair, Froyo, Gingerbread, Honneycomb, Ice Scream Sandwich, Jelly bean ... les informaticiens ne manquent pas d'imagination pour donner des noms à leur oeuvres (vous pouvez aussi lire ceci).

On arrive donc à la lettre "K", et là, tous les bretonnants s'émeuvent et s'organisent pour défendre la cause du Kouign-amann (recherchez #k4kouign sur twitter, Google+, facebook et autre pour vous en faire une idée).



En tant que président du BreizhJug, on me demande de prendre position, alors allons-y : je dois reconnaitre que ça serait plus fun que "stewed Kiwis" ou "Kahula mousse", donc rien que pour ça j'ai donnée mon +1 sur la page http://www.k4kouign.eu/. Je n'irais pas plus loin, et je ne profiterais pas de ma relation amoureuse avec Romain Guy pour influencer le choix (bon, en vrai je m'en fout un peu n'étant ni breton ni développeur Android :P). Reste à obtenir l'extension de domaine .bzh et la bretagne sera au premières loges de l'ère numérique.

Blague à part, la cause du kouign-amann prend de l'ampleur au point que quelques boulangeries de San Francisco commencent à en proposer (question : est-il conforme à l'original ou est-ce une pâle imitation ?) et que les geeks de tout poils de ce secteur se ruent dessus - au risque de prendre quelques livres supplémentaires. Nul doute que le gateau breton va s'inviter à la cantine Google et passera entre les mains de Serguey et Larry. Dire que l'avenir du prochain Android repose dans la présence ou nom d'un morceau d'essuie-tout à ce moment fatidique !

Si vous êtes plus passionnés que moi par Android et/ou l'identité bretonne vue de la Silicon Valley, n'hésitez pas à relayer le message et à contribuer. [#troll] De toute façon, d'ici là le procès Oracle vs Google aura enterré la plateforme [/#troll]. Et oui, n'oublions pas que l'enjeux principal pour Android en 2012 ne sera pas de faire la promotion du savoir faire culinaire mais bien de contrer cette attaque sur le terrain juridique.

update : 
on me dit dans l'oreillette que, juste avant Cupecake, Android a connu une version "Petit Four", ainsi que deux versions non publiques "Astro" et "Bender".

Et voilà, Devoxx c'est fini

Je ne vous ferais pas un compte rendu des sujets qui ont été présentés, pour ça vous pouvez fureter sur le net et/ou prendre un abonnement Parleys. Par contre, un petit coup de projecteur...

En général, il y a toujours une session qui fait un effet "Waaah" pendant cette (longue) semaine de conférence. Celle de John Smart sur le continuous delivery pourrait quasiment remplir ce rôle, non pas parce qu'il a parlé de CloudBees auquel cas vous m'accuseriez de ne pas être objectif, mais parce que le sujet était très bien amené, entrecoupé de démos, avec un speaker dynamique et très bien préparé, et tout ça avec le fameux petit problème technique qui donne du piment et montre bien qu'on est dans le "live".

J'aurais pu terminer Devoxx sur cette impression, mais il y a eu LA session :



Le dernier jour, dernière session, Emmanuel Bernard et Stéphane Epardaud présentent Ceylon, devant un public atomisé par 5 jours de conférence intensive + une nuit agitée au Noxx. Si la réaction du public à chaud n'a pas été bien vaillante, la présentation était super sympa, pleine d'humour, très concrète, avec une magnifique démo de l'IDE Ceylon (développé par David Festal de Serli, cocorico). Je n'avais pas du tout regardé Ceylon avant cette prez, j'ai bien compris les concepts qu'ils ont exposés, découvert un langage bien construit et réfléchi pour dépasser les bases devenues contraignantes de Java.

En plus du contenu, vous mettez un Stephane obligé de faire une démo sur Mac et de jongler avec son clavier si particulier (démontrant involontairement l'aboutissement impressionnant de l'IDE et la correction/suggestion automatique), un Emmanuel qui ne se prive pas de quelques bons mots, des slides clairs et des explications précises sur le pourquoi de Ceylon, plus que sur le comment.

J'ai retenu que Ceylon est vraiment facile à comprendre et très homogène, avec des choix techniques qui vont au delà des contraintes de Java sans ouvrir la boite de pandore du truc qui sais tout faire mais que personne ne comprend. Evidemment, on a pas encore toute la pile de frameworks qui ferait de Ceylon une solution à utiliser immédiatement en entreprise, ni même un langage complètement terminé. Cependant, je sors de cette prez avec l'impression qu'on va reparler de ce nouveau langage, et probablement pas uniquement pendant la dernière session de Devoxx.

Il y a un ans, Play! faisait tout juste son entrée sur une petite session de Devoxx 2010, cette année il y avait trois sujets majeurs qui lui étaient consacrés. Java tente de se renouveler, et les bonnes idées ne manquent pas. Pour ma part, je vais aller regarder du côté de http://www.ceylon-lang.org/

Bonjour à tous,

Devoxx fête ses 10 ans, et fait les choses en grand en réservant la plus grande boite de nuit d'europe, le Noxx qui est à deux pas de la salle de conférence (coincidence intéressante).



Il est donc 3h du matin quand je rentre à l'hotel pour rédiger ce billet, légèrement éméché après quelques verre de la boisson locale généreusement offerte sur place. La soirée a fini en ville avec quelques survivants, à la recherche d'un bar encore ouvert (même le Kelly's nous à lâché), pour finalement renoncer et aller sagement se coucher en attendant la keynote de demain matin.

Un petit bémol sur une particularité locale ...

Ce soir, il y avait le BOF de JDuchess, pendant lequel nous avons évoqué une réaction involontaire que nous connaissons tous de considérer que la belle blonde qui arrive sur le stand est au mieux une responsable marketing, au pire une "animatrice", mais certainement pas une développeuse.

Quelques heures plus tard, aux Noxx, la soirée était "animée" par trois danseuses en tenue "légère" qui avaient l'air de trouver un grand épanouissement dans leur profession. Désolé, la photo n'est pas terrible mais vous avez l'idée.


Par ailleurs, dans cette boîte, quelques "hôtesse" qui n'avait pas trouvé de robe à leur taille faisaient le tour de la piste  à la recherche d'un bon client. On a beau ne pas être très loin d'amsterdam, ça fait une drôle d'effet.

Si la soirée était globalement très réussie et qu'on s'est bien marrés, cela a jeté un froid pour les quelques geek-esses qui nous accompagnaient. Ce n'est pas comme ça qu'on va renverser la tendance de 95% de mecs dans notre profession ...


Enfin bon, à ce dérapage près, jusqu'ici Devoxx est un sans faute et un moment inoubliable. Reste encore la matinée de demain, pour laquelle nous préparons une petite surprise à Emanuel Bernard ... wait & see

Pour la keynote d'ouverture de Devoxx, Stephan Janssen nous a préparé une petite surprise :


Oui, en 2012, nous aurons un Devoxx en France, du 18 au 20 avril, sous un format comparable :

Cool mais sérieux, trois jours de conférences, "tools in action" et universités, tout ce qui fait la recette Devoxx et son incroyable succès. Le nombre de place, sans atteindre les 3200 participants du Devoxx "original", devrait permettre de satisfaire le public français et frontalier (enfin, ne tardez pas trop pour vous inscrire tout de même ...).

Plus d'excuse cette fois :

• Pas de long trajet pour "monter" en belgique
• Pas de problème avec la langue de shakespeare (pour une partie des sessions en tout cas)

Félicitation à l'équipe du ParisJug pour cette initiative, et pour avoir réussi à garder le secret pour un bel effet d'annonce. Toutes les infos sur twitter @devoxxfrance et www.devoxx.fr

Je suis cette semaine à Devoxx, et non, je ne vous ferais pas comme l'an dernier un reportage live : je profite de la conférence pour rencontrer du monde et de toute façon je n'arrive pas à faire marcher le Wi-fi de l'hôtel, donc voilà, vous n'aviez qu'à venir :P

Cette année, Devoxx est aux couleurs d'Android et d'HTML5. Cela n'empêche pas d'avoir quelques sessions sur tout un tas d'autres sujets. Comme chaque année, le choix d'une salle est toujours un moment délicat, parfois de regrets. On a eu un "tools in action" sur Gerrit qui s'est vite révélé être un "slides in action". On a aussi eu une "university" de 3 heures pour laquelle le speaker annonce dès le début qu'il n'a pas matière à tenir la durée annoncée... Mais on a aussi d'excellents talks. On a un tools in action sur Arquillian avec deux slides torchés en 2 minutes puis 28 minutes de pure démo. On a une université sur l'évolution de Java (java7, langages dynamiques, fonctionnels, concurrence) très vivante et bien menée.

Pour en savoir plus sur les sujets, ils vous suffit de suivre #devoxx sur twitter ou les blogs des nombreux francophones qui ont fait le déplacement.

Devoxx c'est aussi de nombreuses rencontres et des échanges riches avec la communauté. C'est l'occasion de discuter avec l'équipe de développement de Terracota ou de Jetbrains, de débattre de l'adoption du Cloud avec les speakers de CloudFoundry.



C'est aussi l'occasion de quelques bières avec les membres des diverses communautés qu'on a pas l'occasion de croiser au cours de l'année. Les frenchies deviennent si nombreux qu'on est presque obligés de ne pas se donner rendez-vous trop explicitement via twitter au risque de se retrouver à 40 à l'entrée du resto.

Et puis, Devoxx c'est surtout la 10ème édition de la plus grosse conférence Java en europe tout en restant indépendante et bon-enfant. Ici, les speakers peuvent se permettre de développer live une application "Duct Tape Store" montrant pendant 3 heures l'utilisation de Java EE 6 pour afficher des femmes habillées d'un simple morceau de scotch d'emballage, mélangeant démonstration techno et légèreté. Ici on mange un casse-dale en compagnie de speakers prestigieux et on fait comme eux la queue au stand pour tenter de gagner un iPad.

Ce savant mélange, il est bien difficile à décrire, aussi ... vous n'aviez qu'à venir, na!

Update : quelques liens pour suivre en détail le déroulement de la conférence

http://finistjug.fr/2011/11/14/devoxx-jour-1-i/
http://www.touilleur-express.fr/2011/11/15/devoxx-2011-who-are-those-angels/

Mercredi dernier, Xebia organisait un atelier CloudBees avec Jean-Louis Rigau comme maître des clés et votre serviteur pour expliquer le pourquoi du comment. François Dechery, responsable Services de CloudBees était également présent pour appuyer mes réponses de geek d'une vision de plus haut niveau sur le rôle du Cloud dans notre métier.


Pendant les deux mois qui ont précédés l'atelier, Jean-Louis et ces petits camarades ont fait chauffer leur compte CloudBees pour préparer un atelier très complet et parfaitement documenté. Je suis bluffé par la qualité du résultat (surtout si on considère que les UI ont changé quelques jours avant l'atelier et qu'ils ont du refaire toutes les captures d'écran !).

L'atelier en lui même avait trois gros points forts :

• D'une part, découvrir la plateforme CloudBees - sans blague ? et oui, mais pas que. Non content de mettre en place de l'intégration continue sur DEV@Cloud et de déployer et faire monter en charge une application sur RUN@Cloud, l'atelier met à profit l'écosystème CloudBees. Pendant les deux heures de manipulation, nous avons utilisé Sonar, SauceLabs pour les tests Selenium, NewRelic pour le monitoring, PaperTrail pour la surveillance des logs. Le tour du propriétaire était donc plus que complet.
• Mettre en place et comprendre les pratiques de continuous delivery. Ce terme un peut buzzesque prend ici tout son sens avec un processus complet de qualification et de mise en production 100% instrumenté. La facilité de mettre en place les briques de la forge logicielle sur CloudBees est l'occasion de montrer qu'un tel processus n'est pas juste une vue de l'esprit mais peu être implémenté de manière très convaincante en moins de 2 heures.
• Manipuler vaut mieux que tous les discours. J'ai fait une courte intro de 15 minutes (bon, j'ai évidement un peu débordé du timing prévu) histoire de situer un peu les choses. Cependant, ce discours sur notre vision du PaaS et du Cloud ne vient que compléter tout ceux que vous pouvez entendre/lire partout. On ne comprend réellement le bouleversement que cela implique que lorsqu'on manipule la chose. Parmi les 14 binômes présents, quelques-un ont déployé leur application sur RUN au bout d'à peine 20 minutes, et faisait des tests de montée en charge du clustering avec jMeter dès la première heure. Evidement, il y a eu aussi quelques couacs et j'étais bien content d'avoir mes collègues sur IRC pour débloquer le Jenkins qui pédalait avec 22 builds en simultanés - note pour le prochain atelier : augmenter la mémoire de la JVM.

Le 23 novembre, Sacha Labourey (mon Boss) sera présent pour une session consacré à notre vision du Cloud, du PaaS, et sur les transformations qui vont suivre. Ce sera certes moins "mains dans le cambouis" mais attendez vous a des réponses bien tranchées sur les questions que le Cloud met sur toutes les lèvres.

Le 30 novembre, Jean-Louis et moi remettons le couvert pour un second atelier. Ayant essuyé les plâtres de la première édition, ce second opus devrait être un sans-faute ;)

Si vous n'avez pas l'occasion de vous joindre à nous, vous pouvez si vous le souhaitez suivre ce document chez vous avec un compte CloudBees FREE. Tout ne sera pas accessible, mais vous aurez tout de même une idée concrète de ce dont il s'agit.

En tout cas, j'ai pris un grand plaisir à participer à cet événement (qui c'est prolongé bien tard avec énormément de questions...) et je remercie Xebia pour cette initiative très pertinente et Jean-Louis et son équipe pour l'énorme travail de préparation.

Xebia organise mercredi 9 novembre une soirée atelier pour découvrir la plateforme CloudBees.

Votre serviteur vous servira de guide pour explorer le concept du PaaS, tel que nous le voyons chez CloudBees : une plateforme complète pour le développeur Java, de l'hébergement de son code à la mise en production, en passant par une chaîne complète de compilation, test et qualification, tout en respectant l'extrême diversité des outils de build et de test employés dans notre écosystème.

Au programme, après une courte introduction pour se mettre en appétit, nous mettrons pendant deux heures les mains dans le cambouis.


Chaque participant disposera d'un compte CloudBees pour manipuler à sa guise. Nous allons déployer l'application Spring PetClinic sur CloudBees, en explorant les stratégies de build, de qualification et de release, puis en stressant l'application pour vérifier la promesse d'élasticité du Cloud, ainsi que les outils mis à notre disposition. Ne vous attendez donc pas à une soirée - conférence à grand coup de PowerPoint, ici on va tapper des commandes Git, lancer des jobs, et tripoter du Jenkins (en tout bien, tout honneur) pendant deux heures ! Pas de discours bisounours sur le Cloud, que du concret, et ça c'est chouette.

La soirée se terminera par une séance questions/réponse, histoire de debriefer correctement l'atelier, suivi d'un buffet pour discuter plus librement.

Cette soirée est à effectif réduit, aussi ne tardez pas trop si vous voulez faire partie des privilégiés à en profiter http://blog.xebia.fr/2011/10/28/atelier-java-paas-et-continuous-deployment-avec-cloudbees/

Titre tapageur pour faire écho à ce billet, qui compare Opscode Chef à Puppet, deux outils de gestion de parc.

Gestion de quoi ? Bon, commençons par le commencement : nous allons utiliser un petit cas concret pour illuster la chose. Supposons que vous bossez dans une grande SSII en tant que référant "intégration continue" et qu'on vous sollicite donc régulièrement pour mettre en place des forges logicielles sur projet au forfait - toute ressemblance avec une personne existante ou ayant existée, bla bla bla

Option 1 : "la [bip] et le couteau"

Pour chaque projet, fort de votre expérience, vous installez maven + jenkins + nexus + svn/git + sonar + mysql + oracleExpress + lespluginsquivontbient

Comme vous êtes trop trop fort ça ne vous prend que un ou deux jours maximum pour que tout soit carré, et avec l'expérience ça doit même pouvoir se faire dans la journée - si on oublie qu'il a fallu attendre 3 mois la commande de la machine

Option 2 : "la documentation exhaustive"

Jouons la carte ISO-9002 et écrivons ce que nous faisons avant de faire ce que nous avons écrit, voici donc le manuel d'installation d'une forge logiciel, document de 148pages détaillant les commandes d'installation, oh que c'est beau et ... jamais à jour, vu qu'une nouvelle version de Jenkins sort chaque semaine, que chaque plugin évolue et remet tout en cause, et que les pratiques d'une projet ne sont pas nécessairement celles d'un autre.
Accessoirement, en copiant la commande indiquée, on se plante inévitablement à un moment ou à un autre, surtout avec la tendance qu'à Word de remplacer les "-" par des "–".

Option 3 : "Ctrl+C / Ctrl+V"

Partant d'une forge qui marche bien, maintenue avec amour avec tous les bon softs bien configurés, il suffit à chaque nouveau projet de cloner le système, ce qui est d'autant plus facile si tout cela tourne dans un environnement virtualisé.
Un nouveau projet ? Click, la forge est prête
Seul soucis ... dans 6 mois le projet en question aura toujours un Jenkins 1.430 avec des plugins obsolètes et se cassera les dents sur un bug maven à la c.. alors que c'est corrigé depuis longtemps. Il manque un élément crucial : la maintenance

Option 4 : "installation scriptée"

Même concept que l'option 2 , mais cette fois on est malin, plutôt que de décrire l'installation de la forge dans un document word on va le faire dans des shells d'installation automatique. C'est une plutôt bonne idée à priori mais c'est très, très vite galère. La faute au shell, qui est tout de même un outil de très bas niveau, surtout si on veut remédier aux soucis de l'option 3 et gérer non seulement l'installation mais aussi la mise à jour des outils.

Option 4+ : "installation scriptée avec un outil adapté"

On y arrive : un outil adapté, dédié aux installation et (re)configuration d'outils, avec un niveau d'abstraction supérieur au simple shell. Pour un exemple plus concret, je vous renvoi à ce billet d'Octo qui présente Puppet

Ce qui est important de comprendre ici, c'est que même pour une installation unique, un outil de ce type peut avoir son intérêt. Si la démarche est évidemment intéressante pour un déploiement sur un gros datacenter (Chef a été développé par des gars d'Amazon...), une fois les concepts maîtrisés il peut prendre du sens sur des installations plus modestes, vois ouvrir de nouvelles opportunités :

si vous avez automatisé le déploiement de votre appli, il devient possible de mettre en place un déploiement continu sur une infrastructure de test et de faire du test fonctionnel ou de performance en continu. Le même script sera utilisé lors du déploiement en production, script répété des centaines de fois, et en qui vous avez une totale confiance. Est-ce le cas avec votre manuel d'installation.doc ?

Après il y a même quelques allumés qui gèrent leur station de travail avec Chef, et peuvent potentiellement la répliquer ou la restaurer sur une autre machine. Si ça peut paraître un peu délirant, c'est une façon d'adresser une autre problème : la mise en place des environnements de développement. Un nouveau qui arrive sur le projet ? Hop, un coup de Puppet/Chef et il a tous les outils qui vont bien.

Ok, alors Puppet ou Chef (ou...) ?


Les deux outils sont très, très similaires. En dehors des différences de taille de communauté et de documentation, qui ne sont pas énormes, la différence majeure est sur la liberté proposée par le DSL utilisé.
Puppet définit un DSL relativement figé, dans lequel on déclare des éléments de pilotage de l'outil, comme par exemple cet extrait de la recette d'installation de tomcat qui se charge de télécharger+désarchiver tomcat sous /opt :

  common::archive::tar-gz{"/opt/apache-tomcat-${tomcat_version}/.installed":
    source => $tomcaturl,
    target => "/opt",
  }

C'est super concis et très abstrait, exactement ce qu'on cherche pour ce type d'outil.


La même définition avec Chef est assez comparable :

  remote_file "#{params[:location]}/apache-tomcat-#{version}.zip" do
    source "http://archive.apache.org/dist/tomcat/tomcat-6/v#{version}/bin/apache-tomcat-#{version}.tar.gz"
    checksum "2d19ea2b0f3bb"
  end

  execute "unzip-#{params[:location]}-tomcat" do
    cwd params[:location]
    command "/usr/bin/tar xzf #{params[:location]}/apache-tomcat-#{version}.zip"
    creates "#{params[:location]}/apache-tomcat-#{version}"
  end

Ne vous fiez pas au nombre de lignes, ce sont des exemples pompés au hasard sans grande valeur de comparaison. Considérez juste la syntaxe et la compréhension immédiate des actions réalisées

Il y a ici une nuance importante : le script ".pp" de Puppet est un pur DSL, alors que celui de Chef est fichier ruby, qu'on peut donc instrumenter programmatiquement. C'est l'argument avancé par les pro-Chef car il leur permet de gérer simplement des cas de figure un peu moins triviaux, alors que Puppet - étant verrouillé par son DSL - ne leur donne aucune solution simple.

CloudBees utilise Chef, et les quelques scripts/recettes que j'ai écrites jusqu'ici ne me permettent pas vraiment de juger. L'approche "moins" DSL de Chef ne m'a pas gêné pour rédiger mes recettes, ça aurait pu être un argument en faveur de Pupet pour le débutant. Quand à la syntaxe Ruby, on ne peut pas dire que ce soit un frein vu qu'on ne fait qu'effleurer le langage.

Pour l'instant ces outils sont encore peu utilisés, ou considérés avec intérêt sans franchir le pas, aussi plutôt que leurs différences, c'est la démarche qu'ils proposent qu'il nous faut intégrer. C'est un élément clé pour la mise en place d'une chaîne DevOps, de pratiques continuous-*, aussi je vous encourage à y consacrer quelques % de votre temps "veille technologique". Quelque soit l'outil retenu et ses éventuelles limites,  le potentiel offert par cette approche est énorme et mérite d'être exploré.

Post scriptum : 

Je remarque comme beaucoup un parallèle avec le troll que fait Gradle pour se démarque de Maven : structure trop figée, trop restrictive, et qui montre vite ses limites sorti des cas simples. Si je n'ai aucun avis personnel sur Gradle (faute d'avoir essayé), j'admet que devoir passer par les plugins antrun ou groovy dans maven n'est pas super élégant pour répondre à certains cas tordus. Seulement, des cas tordus on en a tous plus ou moins...

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

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

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

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

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

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

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

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

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

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

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

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


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