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 )


20 novembre 2011

Ceylon - Ma session "Waaah" @ Devoxx

Et voilà, Devoxx c'est fini

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

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

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



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

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

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

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


BreizhCamp 2012

Bonjour à tous,

Le BreizhCamp l'an dernier a été une belle réussite, aussi je propose de réitérer l'événement. 
Cependant, la vie professionnelle étant ce qu'elle est, je ne pourrais pas assurer le même niveau d'engagement et je vais donc lancer un appel :



Je recherche donc quelques personnes ayant du temps libre et beaucoup de passion à dépenser dans cette organisation.
N'hésitez pas à transférer cette info autour de vous ...

L'organisation de l'équipe sera inspirée de Linux (prenons quelque chose qui a fait ses preuves)  :

 

  • Je conserve le rôle de Dictator (parce que hein, faut pas déconner)
  • J'ai besoin de quelques Lieutenants pour prendre en charge les divers aspects de la conférences (restauration, site web, pub&presse, matos ...)
  • J'ai besoin de pas mal de petites mains pour prendre en charge tous les détails, pas forcément à temps plein mais sans elles il n'y aura pas de conf ...

Si l'aventure vous tente, rejoignez le groupe https://groups.google.com/group/breizhcamp (envoyez un mail vide à breizhcamp+subscribe@googlegroups.com)


Je l'ai déjà dit mais je le répète, N'hésitez pas à passer cette info autour de vous ... 

18 novembre 2011

Devoxx party

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



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

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

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

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


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

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


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





16 novembre 2011

And now, Devoxx ... en France !

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


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

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

Plus d'excuse cette fois :

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

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




15 novembre 2011

Live from #Devoxx

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


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

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

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



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

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

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

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

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

11 novembre 2011

Atelier CloudBees @ Xebia

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


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

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


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

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

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

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

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

28 octobre 2011

Atelier CloudBees


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

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

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


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

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

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


10 octobre 2011

Puppet vs Chef, Fight

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

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

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

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

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

Option 2 : "la documentation exhaustive"

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

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

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

Option 4 : "installation scriptée"

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

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

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

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

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

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

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


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


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

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


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

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

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

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


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

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

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

Post scriptum : 

Je remarque comme beaucoup un parallèle avec le troll que fait Gradle pour se démarque de Maven : structure trop figée, trop restrictive, et qui montre vite ses limites sorti des cas simples. Si je n'ai aucun avis personnel sur Gradle (faute d'avoir essayé), j'admet que devoir passer par les plugins antrun ou groovy dans maven n'est pas super élégant pour répondre à certains cas tordus. Seulement, des cas tordus on en a tous plus ou moins...
En même temps, comme le souligne le blog d'Octo, se heurter à la "psychorigidité" de Puppet, comme à celle de Maven, peut être un signe de mauvaise pratique ou de faiblesse architecturale. 




07 octobre 2011

Maven WishList

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

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

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

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

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

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

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

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

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


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

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


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



02 octobre 2011

Play Framework Cookbook

Packt a sorti un ouvrage consacré à Play! framework, et me l'a proposé en relecture dans le cadre de la bibliothèque du BreizhJug. Détail amusant, la même bibliothèque est en train de s'outiller d'une application web sur mesure, développé par Sylvain ... en Play!

J'ai donc ouvert ce livre sans rien connaître de Play! en dehors de quelques essais express et de la présentation faite par Guillaume Bort au BreizhJug

Le format  cookbook consiste à découper le livre en cours chapitres qui présentent un objectif et sa mise en oeuvre avec le framework, accompagné de quelques liens ou idées pour aller plus loin. L'avantage de cette formule est qu'on peut rapidement piocher les réponses à un problème qu'on rencontre, par contre l'inconvénient est souvent que le livre est assez peu abordable pour le novice, sautant un peu du coq à l'âne. Et bien, pour cet ouvrage, je salue le talent de l'auteur qui a su ordonner ses recettes et leur donner un niveau de détail progressif qui permet tout aussi bien de lire le livre de manière séquentielle pour découvrir Play! et pratique rapidement l'utilisation du framework sur une application.

Bon bouquin en résumé pour prendre Play! en main, quelque soit votre niveau de connaissance du framework. On pourra juste (?) regretter l'absence de recettes sur l'utilisation de Scala, déjà très bien intégré dans Play! 1.x et qui sera au centre de Play! 2.

20 septembre 2011

JugSummerCamp 2011

Pour ceux qui n'y étaient pas, et bien vous avez raté un grand moment de geekitude : 
le JugSummerCamp 2011 était un très, très bon cru !

Malgré le grand pavois qui a tenté de nous voller la vedette (et 90% des chambres d'hotel), le PoitouCharentesJug a démontré sa totale maîtrise de l'organisation de ce qui devient un rendez-vous annuel incontournable. Les speakers sont chouchoutés, avec un gite qui leur est dédié et qui permet de discuter jusqu'à très, très tard des sujets les plus variés, dans une ambiance bon-enfant qui fait du bien, autour d'un verre de pineau et d'une raclette (il parait que c'est un plat traditionnel).

Après une courte nuit à refaire le monde et à dire du mal des absents (niarc niarc), direction le vieux port dont le cadre magnifique illumine cette journée conférence. Petit café et viennoiseries nous attendent, l'occasion de retrouver quelques connaissances de la grande famille java-geek, et on attaque cette journée qui va être dense.

Keynote 
Antonio Goncalves a passé sa nuit la veille à peaufiner ses slides, entre deux verres de pineau, et le résultat est réussi (est-ce grâce au pineau ?). Antonio retrace l'évolution de l'information, depuis les débuts de l'humanité jusqu'au chiffres hallucinants des datacenter Google. Son discours nous amène à réfléchir sur la maturité de notre domaine technique, et donc sur la nécessité de normes pour aller plus loin comme l'ont fait les autres activités humaines. Le Cloud est dont le buzz-word mais ne pourra devenir une option d'avenir qu'avec des standards, et JavaEE a son mot à dire. Antonio admet qu'il peut très bien se tromper, comme tant d'autres avant lui, mais nous promet un JavaEE @Cloud, même si le groupe d'expert qui pilote la norme n'est pas spécialement très pointu sur le sujet en dehors d'Oracle qui pousse fort dans ce sens et de la contribution de Spike Washburn (CloudBees). Pour conclure, Antonio continue dans l'esprit fresque temporelle pour remettre le cloud à l'échelle de l'histoire de l'univers (soit 23:59.999999999 rapporté à une journée de 24h) et nous encourage à faire la fête - philosophie simple mais bien accueillie par le public ;)

Architecture des applications de demain 
J'ai suivi la session de Michaël Figuière sur les nouvelles architectures. Je suis très content qu'il ai insisté d'abord sur les nouveaux usages, l'ergonomie, la valeur d'une application dans un milieu où il existe toujours un concurrent. Exemple poignant : les cercles de Google+ qui ont bluffé tout le monde et fait un buzz impressionnant, alors que le back-end doit lui aussi valoir le détour ... mais n'intéresse qu'une poignée de hard-core-nerds. Pensez donc d'abord aux usages et aux utilisateurs, à Mme Michu devant son écran, avant de vous lancer dans des bench noSQL. 
Michaël insiste ensuite sur la nécessité de profiter du buzz quand il vient enfin : deux mots à propos de votre site web sur Capital et c'est 100.000 visites sur le site dans les minutes qui suivent, iPad sur les genoux, juste par curiosité. Le site tombe ? Vous venez de rater la plus belle opportunité de votre vie !
La solution, c'est évidemment de profiter de l'élasticité du Cloud, et j'ai beaucoup apprécié que Michaël se démarque du discours évangéliste sur le 100% Cloud en nous montrant l'exemple du Guardian : le site principal (la charge nominale) est hébergé sur des plateforme privées. Amazon EC2 et Google App Engine sont mis à contributions pour les pics de charge (attentat en Norvège ou lancement de la tournée de Britney Spears). Une solution hybride très pragmatique et qui sera - amha - l'avenir proche pour le Cloud en entreprise.

Inspection Continue / développement Cloud
J'ai séché cette session, le temps de préparer ma démo de l'après midi qui avait quelques défauts. Je me rattraperais en invitant Olivier Gaudin à Rennes pour une soirée Sonar

La pause déjeuner est un nouveau moment de convivialité, l'occasion de discuter avec des personnes de tous horizons. Comme toujours, l'équipe organisatrice fait un sans faute, on est tellement habitués que ça parait banal. 

Quickies
J'ai embarqué Arnaud dans un sketch qui ne sera pas diffusé sur Parleys, afin de nous éviter un procès en diffamation, mais qui a été un bon moment de rigolade et l'occasion d'offrir quelques exemplaires de notre livre. Nous l'avons donc eu entre les mains au moins un instant, je pense que vous l'aurez tous avant que je reçoive mes exemplaires auteur...

Ma forge on the Cloud
C'est le moment pour moi de vous présenter une suite à ma session de l'an dernier. On reprend ma jolie forge logicielle avec tout ce qu'il faut dedans, et on voit comment mettre ça en place de manière efficace. Entre les délais, les coûts, l'intégration et le manque de souplesse, une forge "faite main" est une solution bien lourde. 
On passe alors à la démo : partant d'Eclispe (désolé) et d'un compte CloudBees, nous poussons une application web sur SVN (encore plus désolé), elle est buildée automatiquement par Jenkins, déployée sur RUN@Cloud et mise sous la surveillance de NewRelic. Ce que j'ai voulu démontrer, c'est la force de l'intégration de ces outils/services qui donne un ensemble très fluide, en quelques clics seulement.

CDI-OSGi
OSGi ne fait pas beaucoup rêver, vu la complexité et la remise en cause que cela implique. Mathieu Ancelin nous présente donc CDI-OSGi, une extension qui permet de développer des composants OSGi en utilisant le bon vieux @Inject, annotation qui va devenir universelle. 
La démo est très sympa, il reste regrettable que les démos OSGi passent toujours par cette immonde console qui liste les dizaines de bundles en mode texte. Malgré ce point qui doit rebuter tout novice, j'ai vraiment aimé l'outil qui rapproche (enfin) OSGi des développements traditionnels. 
Par contre, l'aspect dynamique de ces injections de dépendances reste difficile à assimiler pour le développeur, et découvrir qu'une dépendance n'est pas satisfaite au moment de l'appel de méthode est très perturbant. J'aurais préféré une approche bloquante, ce qui est peut être supporté, il faudra creuser la question.

Hibernate vs le Cloud
Sujet présenté au BreizhCamp, Julien Dubois remet à plat l'accès aux données persistantes en épluchant le catalogue des options existantes : Hibernate + base de donnée relationnelle, base de données hors de prix répartie/répliquée, caches, caches distribués, ou bien stockage noSQL qui fait revenir par la fenêtre le pattern DAO que nous avions sorti à coup de pieds par la porte JPA. Julien détaille avantages et inconvénients de chaque solution, et fait voter la salle. 
Cette session est l'occasion de prendre un peu de recul sur nos habitudes de développement, où on est tenté de rajouter un outil pour compenser les défauts de ceux déjà en place. L'approche relationnelle ACID, rend les choses simples mais limite la scalabilité. Les solutions dédiées coutent un bras sans réellement résoudre le problème. Les caches apportent une solution en sacrifiant un peu de la pertinence de nos requêtes, et les solutions noSQL se focalisent sur une utilisation spécifique des données pour choisir leur mode de stockage. 
La morale de l'histoire, c'est que la solution à tout faire n'existe pas. La solution de stockage dépendra de notre utilisation des données, alors que le modèle relationnel nous encourage à penser avant tout structuration fiable puis à greffer nos requêtes dessus en fonction des besoins. 

Keynote de cloture
Donnez les commandes à Nicolas Martignole, il vous emmène en 2021 pour regarder la Touilleur TV. Complètement déchaîné malgré une santé un peu fragile, Nicolas démontre sa capacité à étonner et à faire passer un message très sérieux dans un écrin d'humour.
Nicolas nous prédit donc de nouvelles fusions/rachats entre les grands de ce monde, un métier de développeur qui touche le fond, laminé par la masse de diplômés qui sortent des écoles indiennes et chinoises, mais avec comme espoir que les quelques développeurs talentueux qui tiennent bon gagnent des salaires de joueur de foot. Dans ce monde virtuel, Antonio écrit un nouveau livre "comment arrêter le développement" et on passe une certification chef de projet en deux jours.
Comme tout message de ce type, la réflexion se fait après la session, quand les images reviennent à vitesse normale. Bravo Nicolas, le prochain aura une sacré pression pour faire aussi bien ;)

Rendez-vous l'an prochain !


En attendant la diffusion sur Parleys, voir aussi les blogs de Claude et Michel :
http://cfalguiere.wordpress.com/2011/09/17/le-jug-summer-camp-cest-fini-pour-cette-annee/
http://mimah35.blogspot.com/2011/09/jugsummercamp.html

08 septembre 2011

Apache Maven II - la revanche

Mon bouquin Apache Maven est sorti fin août sous une nouvelle robe avec un contenu révisé :

 

Une fois encore, j'ai réussi à embarquer Arnaud Héritier dans cette aventure, son oeil aiguisé n'ayant pas d'équivalent pour trouver la faille dans ma prose parfois désarticulée. Petite particularité de cette seconde édition : vous l'aurez peut être entre les mains, vu que nous n'avons pas encore reçu nos exemplaires "auteur" et que, si Amazon ne nous l'avais pas dit, nous ne saurions même pas qu'il est déjà disponible en librairie (pan, ça c'est pour Pearson) :P

Au programme de cette seconde édition :
  • reprise du texte pour les boulettes qui nous avaient été signalées;
  • une mise à jour générale pour Maven 3. Les parties spécifiques sont signalées, ce livre couvre donc aussi bien le bon (?) vieux Maven 2 que son remplaçant;
  • un nouveau chapitre sur OSGi - pour lequel je remercie Pascal Leclercq - et Java modules, pour lequel nous avons sorti la e-boulle de cristal;
  • une reprise du chapitre sur les alternatives à Maven, où nous tappons moins sur Gradle et laissons (un peu) la parole à Grégory pour défendre son protégé;
  • une mise à jour notre vision des rapports Apache / Sonatype d'après les rebondissement récents, moins angélique que pour la première édition. La difficulté ici a été que le discours de Sonatype a pas mal bougé pendant la rédaction;
  • nous avons sans scrupule gardé la préface que Jason a plus ou moins relue, ou fait relire, a défaut de l'écrire;
  • une couverture orange. C'était un gros défaut de la première version.


Si vous avez déjà la première édition, faut-il acheter celle-ci ? 

Oui, évidemment ! D'une part parce que cela me rapportera 1€50, d'autre part parce qu'elle est vraiment beaucoup mieux, et enfin parce que nous refusons désormais de dédicacer la précédente édition !

Tous chez votre libraire !

C'est la rentrée !

Ok, ce n'est sans doute pas une nouvelle de première fraîcheur pour tout ceux qui ont abandonné les plages ensoleillées (?) du mois d'août pour déposer les gosses à l'école lundi et retourner au taf, mais

c'est la rentrée !


C'est surtout la fin du calme relatif de cet été qui fait que ce blog etait bien silencieux et que je suis resté douillettement chez moi à bosser peinard loin des tumultes de la vie moderne. Mais ce monde de cinglé qui vit à 100 à l'heure me rattrape, aussi la rentrée va être chargée; jugez vous-même :

Le 16 septembre, rendez-vous au JugSummerCamp. Ne me dites pas que vous ne savez pas ce que c'est ou que vous avez oublié de vous inscrire, c'est la conférence à ne pas louper.


Le 22 septembre Ippon (en la personne de Julien Dubois) m'invite pour un IppEvent consacré à la forge logicielle, à la maison et dans le cloud, comprenez un condensé de mes sessions du JugSummerCamp 2010 et 2011 avec une démo si le Net fonctionne. Dépêchez-vous les places partent vite.
Ippon Technologies

Le 23 septembre, tant qu'à être sur Paris me direz-vous, c'est l'OpenWorldForum qui m'accueille pour un talk sur Jenkins et son modèle open-source "à part". Si vous étiez au BreizhCamp vous connaissez ce sujet que j'avais préparé un peu à l'arrache, j'ai eu l'occasion depuis de le peaufiner en discutant avec Kohsuke.
Open word office

Semaine 39, rien - non ? si !

Le 3 octobre, c'est la rentrée et l'anniversaire du BreizhJUG, avec une soirée Jenkins User Meeting. Au programme : des pipelines de build, des tests Selenium, un peu de CloudBees (!) et un cours de développement de plugin live ! Pour plus d'infos, inscrivez-vous à la liste de diffusion du JUG.
Logo

Le 6 octobre, hop hop on enchaine avec l'Agile Tour Rennes (les gars, faudra penser à changer de logo, on croirait une conf JBoss !). Encore du Jenkins, mais cette fois vu sous l'angle de l'agilité : adaptation, processus légers, cycles courts, et quelques réflexions dont j'aimerai débattre avec vous.

Le 20 octobre, en espérant avoir un peu de soleil - ce qui commence franchement à manquer; s'il ne pleut paraît-il que sur les cons, il faut croire que j'en tiens une couche - petit tour à Nice pour le RivieraDev. Cette fois je sors le grand jeu puisque je présenterais GWT2, CloudBees et que j'irais donner un coup de main à Grégory pour vous convaincre d'utiliser Gradle (ou pas).



Le 27 octobre, un petit tour à Lyon pour présenter Jenkins au FOSSa, selon un axe un peu différent : open-source et business, présentation de l'offre commerciale de CloudBees basée sur Jenkins et de la synergie avec la communauté.


Heureusement, en novembre j'aurais droit à une semaine de repos (?) à Devoxx.


Bref, vous l'aurez compris, si vous voulez me croiser pour avoir un autographe sur votre exemplaire de Apache Maven - seconde édition tout fraîchement sorti des presses que même moi je ne l'ai pas encore, ce n'est pas l'occasion qui manquera !

Apache Maven





03 août 2011

recrutement 2.0

Les temps changent.
Lorsque je travaillais en SSII, mon CV était comme des milliers d'autres basé sur un ronflant titre d' "Expert Java EE confirmé" et incluait tous les mots clés (Spring | Hibernate | GWT | Maven, ...) qu'on retrouve aujourd'hui même sur les CV de débutants. Je pouvais me targuer de plus de 10 ans d'expérience, et bien sur appuyer mon expertise sur la publication de mon bouquin. Cependant, lorsque j'ai quitté Cap j'ai été surpris de voir que, malgré tous les points différenciateurs que j'essayais de mettre en avant, l'équation habituelle s'appliquait :

Salaire = f( Diplôme, Ancienneté ) +/- 1%

Lorsque j'ai postulé chez CloudBees, j'ai poussé le même CV. Etant rédigé en Français, je ne pense pas qu'il ait été transmis en interne (j'aurais du prendre le temps de le traduire mais c'est allé très vite). Arrivant pile au moment où un besoin se faisait sentir, les grandes lignes de mon expérience autour de Maven et de la forge logicielle ont suffit pour passer un entretien sur skype avec le responsable technique de DEV@Cloud. Autrement dit, j'aurais presque pu postuler par twitter :P

Lors de cet entretien, qui servait aussi à vérifier que mon niveau d'anglais scolaire ne poserait pas de problème par la suite, on m'a demandé si je connaissait les API Amazon, Ruby et si j'avais développé des plugins Jenkins. Trois réponses négatives, avouez que ça ne part pas très bien. Cependant, le contact est très bien passé et la question suivante était nettement plus intéressante :

"peux tu m'envoyer un exemple du code que tu as produit ?"

Voilà un élément de différenciation qu'aucun CV ne peut remplacer. Vous pouvez être un expert de classe internationale de Hibernate+Spring, 1000 autres CV prétendront la même chose. Par contre, le code que vous rédigez est votre marque de fabrique. Dans mon cas, le plugin gwt-maven et Fonzie sont deux projets dont je suis fier et qui ont fait mouche. Ils sont avant tout la preuve de mon autonomie et de ma capacité à assimiler Amazon, Ruby, Jenkins et tout le reste lorsque le besoin se fera sentir.

Peut-on extrapoler ce cas particulier au contexte du recrutement en France ?

Le succès de l'express-board en est la preuve. Les candidats ne veulent plus être harcelés par les recruteurs des grandes SSII parce qu'ils ont mis "Java" sur leur profil Monster. Les recruteurs qui cherchent un profil pointu et passionné ne veulent pas perdre 4 mois à enchaîner les entretiens. D'autres critères sont nécessaires.

Ippon avait ouvert le bal en proposant un recrutement sur GitHub. Il fallait donc savoir faire un clone de leur repo, builder l'appli Maven pour avoir accès à l'adresse de recrutement. Ce filtre qui peut paraître simpliste a eu deux effets bénéfiques : d'une part le buzz (indispensable) d'autre part un premièr niveau de sélection.

Je citerais ici Kohsuke sur le mode de "recrutement" de Jenkins :
"Etre contacté par des développeurs qui arrivent à passer un build maven multi-module complexe et proposent un patch, c'est déjà la preuve qu'on a affaire à des personnes de qualité"

Le filtre est certes assez léger mais il n'est pas aussi insignifiant que vous autres, lecteurs de ce blog, pourriez le croire (savoir s'informer via les blogs est aussi un mode de filtrage qui sélectionne beaucoup).

Plus récemment, Pod-Programming (start-up Rennaise pleine d'avenir) a posté une annonce sur l'Express-Board qui va plus loin : il ne s'agit pas juste de passer les difficultés techniques que le projet github proposé nous impose pour obtenir l'email de recrutement, cette fois il faut le forker et démontrer son talent. Pas exactement la page blanche, mais presque. Au final, seulement une poignée de candidats, mais avec un excellent niveau. Le recrutement a finalement permis de sélectionner Michel, co-organisateur du BreizhJug, vainqueur du concours Rennes OpenData, développeur de l'appli Android BreizhCamp, autrement dit un très bon choix :)

Du point de vue de la rentabilité du recrutement on ne peut espérer mieux. Du point de vue des candidats, on fait mieux que le CV anonyme : pas de diplôme ou de niveau d'expérience à prouver pour passer un entretien, il faut "juste" montrer qu'on est capable de faire le job.

Je ne crois pas que ces deux cas deviennent une généralité, mais il est clair qu'une façon de se démarquer est de devenir un développeur "public" : le code que vous produisez pour votre entreprise/client est

  1. rarement publiable
  2. dicté par des règles qui ne vous sont pas propres
  3. généralement pas fondamentalement passionnant

a contrario, un projet open-source même insignifiant cumule les avantages d'être :

  1. public et librement diffusable (par définition)
  2. le reflet de vos capacités, niveau d'exigences
  3. directement lié à ce qui vous plait

Ca tombe bien, de nombreuses "plateformes" proposent des mécanismes de plugins qui permet de proposer de la plus-value très ciblée sans devoir investir un temps fou à comprendre les rouages internes : plugin Jenkins, Maven ou Eclipse selon vos habitudes, il y a matière à s'exprimer.

S'exprimer, justement, c'est aussi un élément de différenciation. Avec l'explosion des JUGs en France (19 à ce jour), il devient presque "facile" de trouver un public pour présenter quelque chose. N'hésitez donc pas, ça aussi c'est un élément de différenciation et ça peut intéresser un recruteur : quelqu'un qui s'exprime en public peut évidement aider à vendre mon produit et à communiquer avec mes clients ;)

Le BreizhJug organisera par exemple en octobre un Jenkins User Meeting, sous forme de quickies : 15 à 20 minutes pour proposer un plugin, une utilisation, une réflexion, ce-que-vous-voulez autour de Hudson/Jenkins. 15 minutes c'est vite passé, et c'est l'occasion de présenter en public son savoir faire même si on est pas un caïd du sujet. Si ça vous intéresse, proposez un sujet à team@breizhjug.org

Moralité :

Nous verrons encore longtemps passer les annonces sur Monster "développeur Java/EE ...". Inutile de donner dans la surenchère des "Expert Sénior Avancé" qu'on voit fleurir dans le monde Java,  ou alors faites le avec humour : "Maître Jedi" par exemple. Mon rôle de "Senior Engineer" chez CloudBees me convient très bien pour caractériser mon profil.

Si vous espérez trouver le poste de rêve, motivant, dans une boîte innovante, tout ça, n'attendez pas que ça tombe tout cuit dans les annonces de ouest-job. Il faudra le moment venu savoir vous mettre en avant parmi des centaines de candidats potentiels. Même si vous n'y voyez qu'un investissement professionnel, rejoignez le monde opensource; vous y trouverez de toute façon tant de choses que le côté "CV" passera vite au second plan. Enfin, prenez la parole, en interne (coding dojo ?), au JUG, participez aux conférences, barcap, opencoffee - bref faites partie du mouvement actuel plutôt que de vous laisser encrouter dans un poste d'expert fonctionnel sur un projet pharaonique de 4 ans (un exemple juste pris au hasard comme ça).

25 juillet 2011

BreizhCamp, le bilan

Un mois après le BreizhCamp, il est temps de faire le bilan

Vous étiez prêt de 250 à vouloir vous inscrire, pour 200 places disponibles. Pour une première, c'est une belle réussite !
Une grand majorité d'entre vous venait du monde Java, avec tout de même une participation appréciable des autres communautés. 62% d'entre vous ont d'ailleurs déclaré participer à une communauté locale, et 8% à une communauté online en mal de se concrétiser IRL. Pour ceux-là, contactez le Granit ou la Cantine Numérique pour organiser un premier meeting, histoire de tenter le coup.
communauté présentes

malgré cette domination "Java", vous avez tous joué le jeu d'aller voir si l'herbe est plus verte à côté, de découvrir ce que font les autres, de participer au brassage des connaissances :
session suivies

Faire appel à Sébastien pour la keynote a semble t-il été une bonne pioche, en rapport avec vos attentes pour cette conférences. Ceux qui ont en plus suivi son "cours du soir de Git-itude" connaissent désormais l'étonnante capacité de Mr Douche pour tenir son public pendant des heures :P

A de rares exceptions, tous les sujets proposés on trouvé leur auditoire. Le breizhCamp est aussi l'occasion de découvrir des sujets plus inattendus par pure curiosité.
Le compte rendu de chaque tranche horaire ressemble d'ailleurs au graphique ci-dessous; votre retour est globalement très positif avec peu de déçus

La pause déjeuner, malgré le temps exécrable ("breton" diront les mauvaises langues, mais ce jours là il pleuvait sur tout le monde), vous a plutôt laissé un bon souvenir, bien qu'un petit creu.
 
Enfin, sur les pistes d'amélioration, je note que vous êtes tout aussi intéressés par des sessions plus courtes, plus longues, des périodes d'échanges plus longues ... il va donc falloir réfléchir à une formule plus modulaire

Enfin, parmi vos remerciements et encouragements, de nombreuses bonnes idées sont à retenir pour un prochain événement - comme par exemple une deuxième galette-saucisse :D

Merci à tous pour vos retours, et merci surtout à nos sponsors sans qui tout ceci n'aurait jamais été possible, ainsi bien sûr qu'à l'ISTIC qui nous à accueilli gracieusement.

Bon été à tous, et rendez-vous en septembre au BreizhJUG !