15 mai 2012

Start me up

La grande majorité d'entre nous travaille en SSII. Ces sociétés, il y en a de tous types, de toutes tailles, comme les missions qu'elles proposent, et il me semble que c'est un bon moyen pour se construire un bon bagage technique via la diversité des projets proposés. Evidemment, ça reste du service, donc l'engagement qu'on peut avoir sur un projet se limite à la durée de la mission.

Passionnés (en tout cas, ceux qui perdent leur temps à lire des blogs comme le miens), nous rêvons tous de participer à un grand projet de son ébauche sur un coin de table au succès planétaire. Pour ça, il faut savoir sortir un moment de sa zone de confort et tenter sa chance dans une start-up. Ambitions, innovation, implication, mais aussi prise de risque - très modérée si on considère le scénario du pire : il suffira de re-postuler dans une SSII pour revenir à la case départ. Nous avons la chance dans notre milieu de pourvoir (re)trouver du boulot (après, du bon boulot, c'est un autre débat).


Pour concrétiser ce projet fou, il n'est pas indispensable d'aller s'expatrier dans la Silicon Valley (même si ça peut être une option), ni d'avoir eu comme binôme un crack du Web. Il existe en France, et pas seulement à Paris, de très nombreuses start-ups avec des projets plein la tête et des étincelles dans les yeux qui ne demandent qu'à s'épanouir. 

Alors bien sûr, on ne peut pas vous assurer la gloire, mais en tout cas un projet sur lequel vous investir, montrer votre talent, et être acteur à 200% de votre projet.


Comment, avec une poignée de bonnes volontés, monter le service du futur ? Si vous avez vu le film "The Social Network" vous avez sans doute apprécié les moments technico-hollywoodien où Mark Zukerberg monte un second server MySQL et patche ses pages PHP. Disposer de talents pour gérer l'infra, la complexité de votre applicatif, plus la communication et le businesss plan de la start-up c'est rare. 

Avant de rejoindre CloudBees j'ai fait la connaissance de Pod-programming, start-up Rennaise qui est en train de créer le service PodBox. C'est pour moi l'exemple type de la start-up à la Française : une techno innovante, une connaissance très pointue du domaine métier, une équipe soudée et très complémentaire, des moyens qui n'ont rien à voir avec une levée de fond à l'américaine, compensée par une gestion intelligente du projet et de sa dynamique. 

Nés dans la révolution Cloud, ils n'ont pas fait l'erreur de louer/acheter leur propres machines. Ils pensaient donc héberger leur service sur Amazon. Si vous avez déjà essayé d'estimer un coût d'hébergement Amazon vous comprenez le problème : à la question "combien d'I/O par mois" que répondez-vous ? Depuis ils ont choisi de se faire héberger sur un PaaS, en l'occurrence CloudBees vu le beau discours vendeur que je leur ai fait - ils ne m'ont pas encore lynché donc il faut croire que je n'ai pas trop embelli la réalité.

0 IT, 0 sysadmin, une plateforme qui montera en charge le moment venu, c'est autant de resources libérées pour se focaliser sur l'application et avancer vite. Et dans ce domaine, avancer vite c'est ce qui fait la différence entre la start-up qui va remporter le marché et celle qui va rester sur une bonne idée jamais concrétisée. La révolution du Cloud c'est surtout ça : libérer les idées en offrant un socle suffisamment élaboré pour que vous ne perdiez pas de temps sur les détails techniques - vous aurez bien le temps de créer votre propre DataCenter quand la boite sera valorisée en Milliards ;) 


Aujourd'hui, le projet PodBox continue d'avancer, si bien que la société recrute un développeur pour compléter l'équipe :

Le projet

Podbox est une plateforme cloud qui permet d'intégrer très facilement des données (cible les non-développeurs) provenant de différentes sources pour les nettoyer, les enrichir, les rassembler dans le but d'avoir une vue unifiée de l'ensemble de ses données. Elles sont consultables depuis un navigateur web et un mobile. Nous poursuivons la quête du Graal de l'intégration totale des données : all-in-one place. Le projet est basée sur la technologie POD, spécialité exclusive de la maison.

Le Poste

Un développeur Java (débutant ou jusqu'à 5 ans d'expérience), motivé par un projet innovant et à l'écoute des dernières nouvelles technologies et pratiques : Cloud, déploiement continu, GWT, REST, HTML5/CSS3, mobile, SCRUM.

Poste à pourvoir au plus vite, basé à Rennes (Betton)
Cerise sur la gâteau, à partir du mois de juillet on travaillera

Si l'aventure vous tente, contactez dom_at_podbox_dot_com de ma part ... (je prends 10% :P)



10 mai 2012

OSSGTP

Je viens d'être admis à l'OSSGTP




J'ai toujours cru que c'était un groupe de rencontre discussion entre Parisiens, une sorte de ParisJUG bien avant le ParisJUG, mais en fait c'est aussi (surtout ?) un club virtuel qui regroupe des gens de toutes provenances géographiques : même mon patron Suisse Sacha Labourey (mince, va pas falloir dire de conneries).

J'ai donc cherché un mentor (Arnaud) pour m'introduire me présenter au groupe, qui a ensuite voté pour savoir si j'étais assez, heu, bein en fait je ne connais pas les critères, mais bon "assez" pour faire partie du groupe.


Donc maintenant, on s'appelle entre nous "frère", on se serre les coude, on est super heureux tous ensemble et on va changer le monde.



En même temps que moi,  Mathilde Lemée est également intronisée et est la première fille du club ! Bientôt la parité ;?

J'avoue ne pas avoir encore tout compris mais en tout cas c'est plein de gens sympas :D


PS: dites les amis, on est vraiment obligé de boire dans des crânes ? Ca donne un drôle de gout à la bière...

Dans les gouttelettes du Cloud


CloudBees, CloudBees, CloudBeeeees, je vous en parle beaucoup aussi pourquoi ne pas passer à travers le nuage et voir sur quoi repose cette start-up ?

CloudBees dispose d’une infrastructure Cloud complète au travers de son DataCenter CB-FR-WEST, judicieusement placé dans une région ne manquant pas d’eau pour assurer le refroidissement des machines ni d’un climat chaleureux qui les ferait souffrir.

Suivant l’exemple d’OVH, nous avons opté pour un système de refroidissement innovant basé sur une circulation de fréon. Chaque serveur est implanté dans un rack conçu tout spécialement pour optimiser la densité des machines et l’efficacité énergétique (nous avons un R.U.E. AA+ d’après Darty).

Les alimentations des machines sont placées dans un compartiment sous le rack, disposant d’un refroidissement autonome (nous parlons de « bac »). Un dense réseau catégorie 6 relie toutes ces machines à notre système de routage.




Sur cette photo, vous voyez que nos serveurs sont, comme dans beaucoup de DataCenters, des machines low-cost de technologie « grand public » en grand nombre et non de grosses bécanes hors de prix. Ici deux de nos fameux « m1.large » (1) et un « m1.small » (2).

Chaque machine dispose d’un espace de stockage élastique (3), que nous pouvons à la demande faire grimper de 2 à 64 Giga-Octets. Celui-ci est sécurisé par une chaînette sur laquelle on peut accrocher des clés privées. Vous apercevez en haut à gauche  notre système de monitoring (4) qui permet de signaler par SMS toute défaillance d’une machine à nos ingénieurs.

Notez aussi les ailettes de refroidissement intégrées dans la structure du rack pour maximiser la captation de la température produite par les machines.

Ces machines sont reliées via un réseau catégorie 6 quadruplé (nous avons mis quatre paires torsadées dans chaque câble) à notre rack de routage. Celui-ci brasse le trafic réseau vers le point d’accès Internet à très haut débit. Ce rack dispose évidemment de sa propre alimentation, redondante pour assurer le fail-over par basculement sur un prise backup.





En bas de la photo, prise lors d’une intervention technique – le DataCenter n’est jamais visité le reste du temps - vous apercevez le routeur d’accès à Internet. Sur cette photo, le point rouge indique une défaillance qui sera totalement invisible pour vous grâce au basculement immédiat sur notre DataCenter CB-EIR-1, lui aussi en zone humide et fraiche.

Bon, blague à part je profite d’un moment de répit de ma pneumonie et de ma LiveBox qui délire à fond (moi aussi d’ailleurs, la Cortisone c’est puissant et ça fait un peu Extasy) pour vous indiquer :


  • Sacha Labourey sera Lundi 15 mai au Paris JUG pour une soirée Cloud. Ne le manquez pas.


  • Si vous le manquez quand même (!), n'ayant obtenu une des 187 places maxi et pas une de plus dont dispose le ParisJug, vous pourrez avoir ma version au NormandyJUG le 22 mai.


Voilà, passez une bonne nuit, il me reste encore 2, 3 heures avant que la Cortisone me laisse m’endormir et on repart pour une folle journée.



24 avril 2012

Devoxx France première édition

La semaine dernière la twittosphère était animée par le tag #devoxxFr, première édition de la conférence phare dans sa variante Francophone. 

Voici, comme il se doit, mon petit résumé perso de ces trois jours très, très denses, avec pour commencer un aperçu de la moquette du Marriott qui en a laissé plus d'un dubitatif :



Day 1 : universités 

La première journée de Devoxx est consacrée aux "universités", des sessions longues : 3 heures (avec pause) pour couvrir en profondeur un sujet. Le sujet que j'avais proposé était en "backup", et j'ai donc attendu qu'un speaker rate une marche dans l'escalier. Au final, je suis bien content que tout le monde soit sain et sauf, un sujet de 3h étant tout de même assez délicat à préparer en une nuit ... 

Je suis allé voir la présentation des 5 mercenaires du DevOps, bien menée, dans un esprit de saine camaraderie, sur la base d'une petite histoire romancée d'un projet qui se "DevOps-ifie". Insistant sur les changements de comportements et d'organisation nécessaires, bien plus que sur l'outillage indispensable mais secondaire, la session était (amha) une très bonne présentation de la tendance DevOps, qui inspirera j'espère ceux qui l'auront suivie.

Henri Gomez étant de la partie, ils ont évidement dépassé le temps imparti, mais en tout cas j'ai apprécié ce sujet et je n'ai pas vu le temps passer pendant cette session. On pourra regretté de ne pas avoir eu une jolie démo de vagrant et puppet, mais bon, il fallait faire un choix pour rester dans le cadre de ces 3h d'universités: virer puppet ou virer Henri :D Par ailleurs, DevOps est trop souvent réduit à ces outils, qui sont particulièrement puissants et utiles, mais masquent le fond du sujet, aussi +1 pour ce talk.



En début d'après midi, je rejoins le hackerGarten, qui propose de contribuer à un projet open-source en présence de contributeurs prestigieux : Emmanuel Bernard, Guillaume Laforge, Vincent Massol, Arnaud Héritier, ... La salle prévue a été complètement débordée par le succès de la session, et on a donc squatté le hall. Je n'ai malheureusement pas pu rester bien longtemps, mais j'espère avoir modestement contribué au succès de cette rencontre


L'après midi et la soirée étaient consacrée pour moi à une réunion CloudBees avec nos partenaires, puis à une soirée entre collègues pour fêter les 2 ans de CloudBees - et oui, je suis à Devoxx pour le boulot ;)

J'ai aussi profité de la journée pour faire un peu de pub discrète (mais si, mais si, j'aurais pu faire pire) pour le breizhcamp. Si les organisateurs ne peuvent autoriser n'importe qui à transformer la conférence en mur de petites annonces, porte ouverte à toutes les dérives, les exposants se sont montrés particulièrement réceptifs : ceux qui nous sponsorisent comme FastConnect ne se sont pas privés d'afficher leur soutien sur leur stand, d'autres comme Sfeir ne se sont pas trop formalisés de voir le logo de leurs concurrents sur les flyers que je leur ai laissé. 




Day 2 : conférences 

La matinée commence par les keynotes (plénières), pour laquelle l'équipe DevoxxFrance présente la conférence, une petite rétrospective du chemin parcouru depuis la première réunion du ParisJug dans une salle de 25 places (pour 40 présents) à l'organisation de DevoxxFrance, qui a fait salle comble avec 1450 participants. Détail amusant, sur toutes les photos présentées, il y a un gars en chemise orange :)


Stephan Jansen, Papa de Devoxx World (nouveau nom de Devoxx à Anvers), a ensuite présenté la plateforme Parleys à un public déjà conquis.

On change alors de registre pour une présentation de l'initiative "Fier d'être développeur", dans laquelle nous sommes nombreux à nous reconnaître, portée ici par Pierre Pezziardi, Boss chez Octo mais avant tout Geek et Développeur. Cette fierté, elle passe aussi par une remise en question de notre nombrilisme de développeur, fier de notre code et de ses détails technique, et à des kilomètres des besoins de l'utilisateur. Je n'en dit pas plus, rendez-vous au BreizhCamp, où ce sujet sera présenté en keynote ;)


Ben Evans et Martijn Veburg du LondonJug mettent ensuite en scène l'avenir de Java dans un monde paradisiaque, avant de se grimer en bad-boys pour nous montrer la version infernale des mêmes prédictions, pour conclure sur notre rôle dans l'avenir de la plateforme : OpenJDK 7 a connu quelques déboires à sa sortie suite à des incompatibilités avec des projets open-source majeurs (Lucene entre autres). Pourtant, les builds de test du JDK étaient dispo de longue date et auraient pu éviter ce souci. Le programme AdoptOpenJDK a pour objectif de ne pas reproduire cette erreur pour Java 8.


Julien Ponge et Frederic Le Mouel présentaient l'un des côtés obscurs de la JVM : la manipulation de bytecode. Après avoir montré la structure générale de ce langage intermédiaire, ASM est présenté pour la production de bytecode à la volée (javassist est nettement plus facile à utiliser si vous voulez tenter l'expérience). C'est ensuite AspectJ puis byteman qui nous est proposé pour modifier le code exécutée par la JVM, suivi d'un projet de recherche encore en développement, JooFlux qui exploite invokeDynamic pour customiser les appels de méthode à la demande et à chaud. Salle comble pour un sujet qui passionne toujours les geeks, à mi chemin entre technologie avancée et magie noire.

Tous ceux qui voulaient découvrir le sujet en ont eu pour leur argent et sont repartis avec une liste d'outils à tester qui devrait les occuper jusqu'au prochain Devoxx. Et pour ceux qui en voulaient encore, la session InvokeDynamic qui suivait (et que je n'ai pas vue) était d'après ce qu'on m'en a dit encore plus "velue" :)


Julien Dubois présentait le développement d'une application "nouvelle technos", avec un regard intéressant : pas question ici de prendre toutes les technos Buzz-word du moment, mais juste ce qu'elles proposent d'intéressant et de mature. L'application en question est Tatami, un twitter intranet, dispo sur le github d'Ippon et qui a donné lieu à un concours de forks, et a permis à l'heureux gagnant de participer à Devoxx.

Une IHM en Twitter bootstrap, exploitant HTML5 pour ses aspects les plus matures et les plus "entreprise" (pas de 3D ici, ni de websocket qui ne passent pas le proxy). Le backend est développé en Spring pour son côté universellement connu des développeurs java, avec du Spring MVC+REST qui permet d'exposer rapidement le modèle métier. Avantage certain ici : même si les endpoints REST se multiplient, un designer Web/JS peut travailler facilement avec un Java-iste backend. Le stockage est confié à une base cassandra, dont la distribution et les performances sont un atout pour une appli de ce type. Enfin, la mobilité est assurée avec les mêmes API REST mais un frontend HTML5 orienté mobile, et packagé avec PhoneGap en application native.

Une session sympa, avec une vision pragmatique de l'adoption des nouvelles technos, et surtout une mine d'information sur le github Tatami et ses différents forks, pour découvrir d'autres approches (par exemple, une variante full JavaEE6)


Petite pause pour moi sur le stand Google à me goinfrer de barres glacées et à vous préparer une surprise - je n'en dirais pas plus (sinon ce ne serait pas une surprise !).


Ayant un peu discuté avec Petra Cross sur le stand, je n'ai pas été voir son talk sur les méthodes de développement de Google, sujet qui a fait salle comble (note: elle sera également présente à Mix-IT). J'ai été voir Sacha Labourey qui présentait la reprise du pouvoir par les développeurs, ou une introduction au PaaS (Platform as a Service). Là où DevOps cherche à réduire les murs entre les Devs et l'IT, le Cloud permet tout simplement d'éliminer le second acteur. Les équipes de développement peuvent alors bénéficier d'une liberté qui leur permet de répondre en un temps record aux demandes toujours plus urgentes, focalisés sur un niveau d'abstraction qui leur est propre, et non sur celui nettement plus bas qui est le quotidien de la production.

Exemple parlant : LooseIt, 2 millions d'utilisateurs, des pics de charge à 2500 requêtes/s, et ... 4 personnes pour porter l'entreprise ! Mettez vous dans la peau de Weight-Watchers, et demandez vous, avec votre IT traditionnelle, ses coûts de fonctionnement et ses délais de réaction, comment vous survivrez ?

Sacha en profite pour détourner les affiches électorales, histoire d'être en phase avec l'actualité :D

  

La journée se termine avec la soirée "meet and greet", qui - DevoxxFrance oblige - ne tourne pas à la bière / frite mais au vin rouge / fromage :) Je reprends ici quelques instants ma casquette CloudBees (sponsor de la soirée avec SonarSource et Atlassian) pour assister mes collègues sur le stand, avant de rejoindre une trentaine de user-groups présents pour les BOFs. "Birds Of a Feather (eat together)" : profitons d'être tous présents à Devoxx pour prendre 1h et discuter ensemble. Pendant le BOF JUG-leaders, la question récurrente des relations avec Oracle ("qui", "comment", "pourquoi") n'avance pas vraiment, et nous glissons vers des discussions sur nos besoins d'échange d'info.


Pas de décision tranchée au final, mais des initiatives pour "fluidifier" les échanges entre JUGs sont possibles. Dans les autres salles, les Android-addicts, Javascript-istes, Scala-mens ou JDuchess profitaient de ce moment pour discuter de leurs communautés respectives.

Retour sur le stand CloudBees, mince ce n'est pas moi qui gagne la tablette Android - en même temps, on me dit à l'oreillette que je n'avais pas le droit de jouer... Un petit verre de vin rouge, et on part chercher un resto qui accepte 25 geeks bruyants pour terminer la soirée.

Devoxx c'est aussi - beaucoup - surtout ? - des rencontres, et des liens à construire dans notre communauté. Nicolas Martignole citait le jour ou il s'est trouvé à manger un morceau à Anvers à côté d'un gars, responsable des APIs chez Google (Patrick Chanezon) ... une rencontre inattendue, et une soirée inoubliable. Ce genre de rencontres, on en a tous à raconter, avec parfois des demandes en mariage.

Day 3 


La journée commence à nouveau par les keynotes. La première, par Monsieur X d'IBM (qui préfère rester anonyme) a été un carnage. Slideware indigeste et un discours sans intérêt. De toute évidence préparée sans réaliser le public à qui elle s'adressait, les twitts se sont multipliés pendant ces 30 minutes de souffrance, écroulant complètement le réseau 3G dans le secteur, et obligeant l'équipe à annoncer une panne du twittwall pour ne pas mettre le speaker en mauvaise posture devant des messages de plus en plus virulents.

Patrick Chanezon prend alors la parole (après avoir furtivement affiché son client twitter, petit cachotier) et nous fait respirer un grand bol d'air frais et salvateur avec une présentation, à nouveau dans l'esprit "fier d'être développeur", mais cette fois mise en scène sur la trame du film the Artist, pour aboutir sur la révolution Cloud en marche qui redonne le pouvoir aux développeurs.


-> http://www.slideshare.net/chanezon/devoxx-france-2012-portrait-du-developeur-en-the-artist

Enfin, Neal Ford a pris la parole pour nous expliquer en quoi les abstractions que nous empilons en couches successives peuvent biaiser voir condamner notre travail, comme par exemple l'icône "disquette" pour la sauvegarde sous Word 2010, ou ... Maven (sic). Une maîtrise complète de l'art de la présentation et de Keynote fait de ce show un régal pour les yeux

Maven, rigide et dogmatique ? Ca se saurait !

J'ai ensuite rejoint le temps d'une itération l'équipe de CodeStory, dont la salle n'a pas désemplie pendant deux jours, et qui a donné à tous ceux qui sont passés une redoutable leçon de bonnes pratiques de développement et d'agilité, du genre qui va faire mal lundi en retournant au boulot. Si nous avions affaire à la crème du développeur, sélectionnée par les étapes successives du challenge CodeStory, il y avait là une source d'inspiration démesurée sur tout ce qu'on peut mettre en place pour améliorer nos développements au quotidien. Sortant de cette session, il me semble INDISPENSABLE qu'on mette en place un coding dojo à Rennes, si l'aventure vous tente ...



Seul quickie auquel j'ai assisté, la session d'Arquilian d'Alexis Hassler était, optimisée pour placer deux démos dans ce format difficile de 15 minutes, et m'a conforté dans mon choix de l'inviter au BreihzJug le 14 mai ! Je n'en dirait donc pas plus ...

Google présentait ensuite Guava, au cours d'une session d'introduction bien rodée et rythmée, qui m'a parmi de découvrir cet outil qui vient compenser de nombreux manques du JDK. A inclure d'urgence dans votre boite à outil.

Didier Girard et Ludovic Champenois présentaient Google AppEngine, réutilisant l'application développée en codeLab mardi. GAE est un conteneur de Servlet adapté spécifiquement au contexte Cloud, et ne faisant aucun compromis. Il fournit de nombreuses API certes propriétaires, mais optimisées pour un usage dans ce contexte et qui permettent de développer des application performantes et complètement scalable.

Alors que j'ai lancé un script JMeter bourrin sur l'appli pendant la session, le pic de charge montré en live était en effet parfaitement absorbé par l'application. Après ce test pirate, Ludo risque de recevoir une facture ... de quelques cents, car le cloud c'est aussi une réduction drastique des coûts.

Si la polémique sur le changement de tarif à fait du bruit dans la blogosphère, l'attrait pour la plateforme n'a pas faiblit. Une architecture correctement pensée pour limiter les accès au storage permet de rester dans des coûts ridicules : le coût d'exploitation de l'appli "A bon entendeur"  de Didier, c'est deux cafés par jour !

-> slides
info : Didier sera présent au BreizhCamp pour rejouer le codeLab et co-animer avec Guillaume Laforge et votre serviteur une université Cloud

Après cette dernière session (pour ce qui me concerne), j'ai eu le plaisir de constater que mon score sur le stand Infine n'avait pas été battu et je peux donc rédiger ce blog depuis un Macbook Air flambant neuf ;)

Bravo en tout cas à l'équipe de DevoxxFrance pour un dévouement et un engagement énorme, qui remonte bien au delà de cette seule semaine à être sur le pied de guerre chaque jour à 6h, et qui a su garder le sourire tout le long de la conférence, gérant les inévitables grains de sables dans les rouages dont les participants n'ont pas imaginé l'existence. Une petite pensée pour leurs familles qu'ils ont embarquées dans cette folle aventure.


Merci à tous, et après un succès de cette ampleur, rendez-vous en 2013 !

Les photos sont extraites des albums de Pierre-Antoine, Arnaud et Claude


22 avril 2012

Jenkins User Conference Paris

La semaine a été marquée par le succès de Devoxx France, mais je tiens tout de même à revenir sur la Jenkins User Conference qui avait lieu mardi, et qui a attiré un peu plus de 100 personnes.

Cette journée, focalisée sur Jenkins, était l'occasion de découvrir des pratiques avancées, de nouveaux plugins, ou tout simplement de rencontrer les principaux committers du projet.


Pour ma part, je présentais avec Mathieu Ancelin le plugin build-flow - dont je vous reparlerais prochainement sur ce blog - en mode live démo, et j'apportais ma contribution au workshop animé par Stephen Connolly - ici en train de nous dire les trois seules phrases qu'il connait en Français, dont "la souris est sous la table" - l'équivalent pour nous de "Where is Bryan ? He's in the kitchen".



Pour la petite histoire, la couleur du T-Shirt officiel était bleue, mais mes collègues me connaissant bien m'en ont commandé un orange, + un second violet (qui est ma seconde couleur préférée) - je suis donc en possession de deux collectors ;)

De nombreux contributeurs (Grégory Boissinot, Henri Gomez, Arnaud Héritier, Olivier Lamy, ...) présentaient un sujet, avec un programme riche dont vous pourrez retrouver le contenu en ligne prochainement (laissez nous le temps de faire le montage :P)

A l'exception du talk (très intéressant) sur le couplage Tycho + Jenkins + Sonar + JaCoCo pour les développements Eclipse RCP, qui a subi des soucis de Wifi, heureusement sans impacter le contenu du talk, tout s'est déroulé sans accroc et la conférence a été un grand succès. De nombreux échanges très enrichissants et de délicieux petits fours on conclus cette belle journée.

Prochaine étape du JUC-Tour : New York

Si vous voulez organiser près de chez vous un "Jenkins User Meeting" en soirée dans un JUG ou équivalent, contactez-moi.

Jetez un oeil à l'album photo de Pierre-Antoine Grégoire , et ou explorer la timeline twitter #jenkinsconf pour vous faire une idée de ce que vous avez manqué ;)

20 avril 2012

YEAHHHHH!

En attendant de vous proposer de lire un résumé de DevoxxFrance, je tiens à remercier

Inifine organisait (en plus de nous offrir une bonne bière) un concours sous forme de 5 fragments de code à corriger en un temps limité. J'ai réussi un super score (tôt le matin, sous l'influence d'un thé earl-grey, peut être plus propice à cet exercice que la bière) qui a tennu le haut du classement jusqu'au compte à rebours fatal. J'ai même résisté à maître Gageot (sans doute un peu éprouvé par sa performance magistrale sur codestory).

Le niveau du quiz était parfaitement ajusté à l'auditoire, certains ayant eu du mal à finir dans les temps, et moi même j'ai du renoncer sur un test à la solution "propre" pour une version naïve mais fonctionnelle - poum, prends ça dans ton égo. Cela rejoint d'ailleurs la keynote "fier d'être développeur" qui nous apprenait à rester humble et à penser à quoi notre code sert avant tout : à contenter checkstyle ou bien à ... gagner un MacBook Air !

Quand je vous le disais qu'il FALLAIT venir à Devoxx ;)

Merci donc à l'équipe Infine qui a animé le stand avec un enthousiasme bien sympa. Entre les carrambars, les litres de bière et le gros lot, je pense que j'ai absorbé une part importante de leur budget Devoxx ;)

01 avril 2012

1er avril

Cette année je n'ai rien préparé pour le premier avril et je n'ai pas d'idée pour une bonne blague.

Aussi, SVP retournez-vous, et venez coller votre dos contre l'écran, merci


31 mars 2012

503 Service Temporarily Unavailable

Quand on parle de Cloud, se pose inévitablement la question du la disponibilité. Dans l'actualité de la semaine vous aurez peut-être entendu parler d'une panne sur Amazon Web Service, qui a fermé les portes de plusieurs services web (dont CloudBees, pour certain services) pendant quelques heures.

Amazon propose une sécurisation a priori treès avancée de son hébergement, via la répartition de ses DataCenter : Amazon est découpé en "régions" réparties sur le globe (Europe, Asie, US-Est, ...). Répliquer une application entre régions est en principe le plus haut niveau de High-Availability que vous pourriez mettre en oeuvre, mais introduit évidemment des latences et des coûts réseau élevés. Amazon divise alors chaque région en "availability zones", chaque zone étant indépendante : datacenter géographiquement séparé, alimentation électrique différence, accès réseau différent, etc... tout en ayant une inter-connexion réseau à très haut débit. D'après la documentation Amazon, répartir une application sur plusieurs zone est donc la solution garantissant une disponibilité quasi infaillible.


Plus d'infos ici si le sujet vous intéresse, et par exemple cet article sur l'utilisation des zones pour mettre en place une architecture "designed to fail".

Sauf que "quasi infaillible", ce n'est pas une garantie totale. Il y a quelques jours, comme c'est déjà arrivé en début d'année dernière, les différents datacenter d'une zone sont tombés ensembles, réduisant à néant toutes les stratégies de failover.

Voici la réponse d'Amazon :

6:09 PM PDT We want to provide some additional information on the Internet connectivity interruption that impacted our US-East Region last night. A networking router bug caused a defective route to the Internet to be advertised within the network. This resulted in a 22 minute Internet connectivity interruption for instances in the region. During this time, connectivity between instances in the region and to other AWS services was not interrupted. Given the extensive experience that we have running this router in this configuration, we know this bug is rare and unlikely to reoccur. That said, we have identified and are in the process of deploying a mitigation that will prevent a reoccurrence of this bug from affecting network connectivity. 

Un putain de bug tordu dans un routeur ... aucun doute qu'Amazon va tirer des leçons de ces soucis et apporter une solution pour rendre ses zone (encore) plus indépendantes. Aucun doute aussi que de nombreux services Cloud vont apprendre de ces expériences et renforcer leur fiabilité et la redondance de leur architecture.

Quoi qu'il en soit, si beaucoup pointent du doigt une défaillance du Cloud qui promettait monts et merveilles, on oublie que ces pannes démontrent surtout une disponibilité à 99,99% et une grande efficacité dans la rétablissement du service. A comparer avec le niveau de service que vous pouvez obtenir avec un hébergement traditionnel, et aux coûts associés...

Par contre, ceux qui sont déjà dans le Cloud se posent la question de la validité du modèle de zones d'Amazon, puisqu'en 12 mois on a déjà eu deux pannes majeures de ce modèle (voir par exemple http://www.networkworld.com/news/2011/042111-amazon-ec2-zones.html). 


Lors de mes présentations sur le Cloud dans les Java User Group, je ne cherche pas à occulter la réalité de cette nouvelle approche de l'informatique. Non, le Cloud n'est pas la silver-bullet qui va résoudre tous vos soucis. D'où l'importance d'y aller aujourd'hui, même avec de petites applications de test, pour vous faire votre propre expérience des contraintes techniques, de la qualité de service, des offres de chaque fournisseur et des coûts associés.

Pour les utilisateurs de CloudBees, nous n'avons pas de solution officielle clé en main pour assurer du 99,9999999999%. Par contre, depuis l'annonce AnyCloud, qui vous permet de déployer votre application sur plusieurs DataCenter, éventuellement via des fournisseurs différents, rien ne vous interdit de mettre en oeuvre votre propre architecture hautement redondante. Nul doute, après cette nouvelle panne d'Amazon, 1er fournisseur IaaS du Cloud, qu'on trouvera rapidement des témoignages très intéressants sur le sujet.

27 mars 2012

SSD

J'ai installé un disque SSD dans mon Mac, via un adaptateur qui libère l'emplacement du lecteur DVD (déplacé dans un boitier USB externe). Si la manip' vous intéresse je vous laisse googler pour trouver les détails largement détaillés sur le Net.


Le disque "legacy" est ensuite cloné sur le SSD avant de redémarrer sur ce dernier, et un petit liens symbolique me permet de conserver mon "home" sur le HD pour profiter d'un espace confortable. Autrement dit, le SSD héberge le système et les applications, le HD tout mes fichiers utilisateur

Le web fournit de nombreuses vidéos montrant la différence de temps de démarrage de l'OS entre ces deux configuration, ce que je confirme, mais évidemment ce n'est pas super pertinent sur un OS qu'on ne redémarre qu'à titre exceptionnel...

Au quotidien, depuis quelques semaines que je l'utilise, je constate un gain de temps flagrant au démarrage des applications. Voire la barre de progression du splash-screen d'Idea défiler en quelques secondes est un réel bonheur. Ceci dit, on ne démarre pas une application toutes les trois minutes non plus. J'ai également déplacé mon repo local maven sur le SSD, ce qui doit réduire leur temps de chargement, même si je n'ai pas fait de bench pour le vérifier.

Est-ce que le jeux en vaut la chandelle ?

A mon avis oui, et je ne regrette pas les 300€ investis (surtout que CloudBees me les rembourse :P), car on gagne tout de même sensiblement en fluidité du système. Par rapport à une migration full SSD, je ne bénéficie pas du même gain de performance ou d'autonomie, vu que mon HD reste soumis à des sollicitations permanentes.

Si vous avez la possibilité de procéder au même upgrade, je ne peux donc que vous encourager.


23 mars 2012

Gagnez une place pour Devoxx

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 !

  




Jenkins pose ses valises à Paris

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.



06 mars 2012

BreizhCamp, GO !


Et oui, le BreizhCamp, c'est PARTI !




Les inscriptions sont ouvertes, et nous avons déjà quelques inscrits qui n'ont pas attendu le début de l'annonce d'un hypothétique programme pour s'assurer une place

La Call For Paper est ouvert jusqu'au 15 avril, n'hésitez pas à proposer un sujet, sous l'un des formats proposés :
  • 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)


En attendant qu'un programme officiel se dégage, la campagne de promotion est lancée, et ce sont les utilisateurs qui sont nos meilleurs ambassadeurs :





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 !

22 février 2012

JAX-RS et CDI sont dans un bateau...


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.

20 février 2012

La fin de Moore

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.

(source : wikipedia)

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

Note :
Définitif ... peut être pas, car les fondeurs ont plus d'un atout dans leur manche ! Mettre les pistes sur la tranche ou empiler les couches de transistors sur une même puce, à l'assault de la troisième dimension, en prévoyant soigneusement des "canaux" de dissipation des calories produites.

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 !




02 février 2012

Merci Stephan

Ca commence, pour moi, peu avant 2006
Lorsque sur le forum des développeurs apache 
Une vidéo étrange, circule entre deux patch
Offre à mes yeux curieux l'étrange JavaPolis
~
Je n'y suis pas allé, peut être un peu trop geek
Pour que ma hiérarchie accepte de m'envoyer
Dans ces contrées du nord, sans doute alcoolisées
Où même les cuillères ont des moeurs pathétiques
~
C'est donc plus tard, en Juin, pour le premier Spring'One
Que je prend un billet pour joindre MetroPolis
A quelques pas de Rennes, en deux heures de Thalys
Me voilà chez les geeks, moi jeune Padawan
~
J'y apprends tant de choses, conforte mes idées
Débat avec certains des bienfaits de Maven (...)
Echange un ou deux verres avec Rod et Juergen
Et découvre que la bière fait mieux parler anglais :P
~
J'y rencontre également quelques compatriotes
Ils sont venus, comme moi, élargir l'horizon
Parfois un peu terni par un boulot bidon
Ce sont devenus depuis mes meilleurs java-potes
~
De cette belle expérience, je reviens plein de rêves
Celui d'avoir à Rennes moi aussi un beau JUG
Avec des sponsors, mon logo sur un Mug
Echanger quelques bières lorsque la conf' s'achève
~
Il m'a fallu deux ans, trois séjours à Anvers
Pour franchir le pas, me lancer dans l'arène
Pour faire de cette idée : un JUG ici, à Rennes
Plus qu'un projet lointain, une bouteille à la mer
~
Devoxx nous à offert un lieu de ralliement,
Où d'autres, comme moi, voulaient bouger les choses
Il y aurait tant à dire, en vers ou bien en prose
Sur cette communauté et ses encouragements
~
Toujours est-il qu'un jour, le ParisJug démarre
Entrainant avec lui comme une trainée de poudre
Toutes les bonnes volontés qui voulait en découdre
Pour que la France, aussi, de Java ait sa part
~
Rennes fut le troisième, nous sommes aujourd'hui vingt
Enchaînant les soirées, conférences, ateliers
Pour que chacun y trouve chaussure à son pied
Notre mission : vous offrir un rêve pour demain
~
Trois ans, et le BreizhJug a tennu son pari
J'ai mon Devoxx a moi, et nous sommes ambitieux
Il s'appelle BreizhCamp, des rêves pleins les yeux 
Et je ne suis pas peu fier de ce que j'ai fait ici 
~
Tout cela, je te le dois, toi qui a insufflé
L'envie de me lancer, bien qu'étant isolé
Bien plus qu'un compte gratuit offert sur ton Parleys
Je te dois, du BreizhJug, un bonne part du succès
~
Merci Stephan