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








24 janvier 2012

Bref, j'ai restauré OSX

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.




du Ruby sous OSX

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

un petit café plus tard, retour à l'installation de ruby, auquel il faudra ajouter des arguments --with-xx-dir pour préciser le chemin d'installation de ces dépendances. Nouveau problème, nouveau paquet manquant (libiconv), et cette fois l'astuce macport ne suffit pas. On va donc demander à RVM de résoudre le problème lui même :

rvm pck install iconv

et enfin, 

rvm install 1.9.3 -C --with-readline-dir=/opt/local/lib --with-libxml2-dir=/opt/local/lib --with-iconv-dir=/Users/nicolas/.rvm/usr

et voilà ! Reste plus qu'à choisir cette version comme interpreteur Ruby par défaut (rvm --default use 1.9.3) et on est fin prêt pour utiliser ruby dans une version récente, et installer des paquets Gem sans être root.

Tiens au passage, un petit troll, histoire de ne pas renier mes racines :

{troll:on}
à ceux qui se plaignent de Maven, le gestionnaire de paquets Gem va vous plaire : installation systématique les docs (deux pour le prix d'une : ri et rdoc), conflits de versions - je n'arrivais pas à installer veewee sur mon vagrant avant un downgrade de ce dernier) - etc.
{troll:off}


Ceci dit, je ne connais aucun système de gestion de paquets/dépendance qui ai résolu de manière définitive ce problème :D

30 décembre 2011

Android avec un K

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".
Kouign Amann ou pas, on échappera au moins à ça :

(pour les moins de 30 ans, il s'agit de K-9, le chien de Dr Who )