new Blog( perso );

Je viens de terminer le cours coursera sur scala, avec la satisfaction d'un 10/10 au dernier test - qui compense une grosse galère sur le précédent, que j'ai voulu faire à la cow-boy, regarder les vidéos m'aurait bien aidé, un peu comme si elles étaient faites pour ça, enfin bref.


Je ne sais pas si j'aurai beaucoup d'occasions de pratiquer - nous avons du Scala chez CloudBees, mais honnêtement je passe plus de temps dans le code de Jenkins ... ce qui est une autre affaire - cependant je voulais vous partager mes impressions :

les plus

• L'inférence de type est impressionnante. On ne déclare jamais un type de variable, un cast ou que sais-je d'inutile. L'évolution "diamond operator" de Java 7 pour simplifier (sic) les génériques fait bien rigoler à côté. J'espère que le compilo Java sera un jour aussi puissant, cela réduit considérablement la pollution du code
• Le plugin IntelliJ pour Scala est excellent. 
• Le cours était autant sur l'approche fonctionnelle que sur le langage Scala, étant mon premier langage fonctionnel c'était donc très enrichissant. De mon point de vue c'est un excellent complément à l'impératif, et ça vaut vraiment le coup de s'y pencher. Ce que j'aime c'est que Scala autorise le mix des deux, on a donc le meilleur des deux mondes
• On peut définir des abstractions vraiment puissantes, et encore j'effleure juste le potentiel de Scala, mais c'est plutôt plaisant.
• J'ai apprécié dans le cours que pour présenter un traitement, Martin Odersky propose une syntaxe plus "compacte", plus "fonctionnelle", en précisant que c'est à chacun d'utiliser celle qui lui parle le plus. C'est important à mon avis de ne pas tomber dans le terrorisme fonctionnel qu'on reproche à certains développeurs scala.
• Le plugin IntelliJ pour Scala est excellent. Sérieusement. J'ai fait les premières "semaines" avec vi mon MacBook étant en réparation, et le MacBook Air 2Gb trop léger pour supporter l'IDE. En même temps c'est formateur, mais retrouver un IDE super puissant aide énormément.

les moins

• La syntaxe est parfois déroutante. Elle permet des expressions très compactes, mais du même coup potentiellement obscures. Pour des cas simples ça se justifie, mais on a vite fait de se prendre soi-même au pièges, et je ne parle même pas de bosser avec des scala(f)istes chevronnés. Plus que dans un autre langage amha il faut être très vigilant sur la structuration de son code
• Il faut vraiment réfléchir à ce qu'on fait. C'est con, mais c'est fatigant. Développer un putain d'écran en struts, ça prend 3 jours mais y'a pas trop à se fatiguer la tête ;) Plus sérieusement, quand y'a un truc qui cloche on se creuse bien la tête pour démêler tout ça, il est donc important d'avoir une structuration très propre du code, avec méthodes bien ciblées et tests unitaires. Vous me direz, on fait déjà tous ça en Java, isn't it ?
• Les OOME:PermGen de SBT, c'est tout de même la misère cet outil. Je me demande ce qu'il donne sur un "gros" projet.
• J'ai vraiment eu du mal à me faire à la syntaxe des for {} yield. Au début j'ai préféré écrire les cas simples en Range.map() qui me semblaient plus clair. C'est sans doute une question d'habitude ?

ma conclusion

Très content d'avoir pu suivre ce cours, surtout qu'il est vraiment très bien fait (ne manquez pas le hands-on Scala au breizhcamp). J'ai appris une approche différente et apprécié certains aspects de Scala, qui me titillerons probablement dans du futur code Java, comme le fait déjà Groovy quand un peu de "dynamique" m'aiderait bien.


Scala est un bon langage, élégant (comme le montre la photo), puissant, très complet, souple (fonctionnel et impératif), mais je ne crois pas qu'il deviendra un langage mainstream : trop complexe et exigeant. Par contre, croire que Java 8  apportera un équivalent "fonctionnel" avec les lambdas est une vision bien simpliste des choses, cela permettra des choses mais ce sera le fonctionnel du pauvre. Surtout qu'apprendre Java 8 pour un junior aujourd'hui, avec les génériques, lambda, et 250 frameworks ce n'est pas un cadeau.

J'attends donc un (futur) langage, un Scala bridé mais plus accessible, un peu comme Java le fut à l'époque de C++.

J'étais la semaine dernière à Lyon pour Mix-IT, conférence que je ne connaissais pas encore. Et bien je suis jaloux par rapport au BreizhCamp :

• les speakers sont choyés, avec pré-réservation d'hotel et speaker dinner d'antologie
• ils accueillent pas moins de 350 participants
• les locaux sont superbes, prétés gracieusement par Supinfo - certes un peu loin du métro, mais avec ce qu'on s'est empiffrés la veille un peu de sport ne fait pas de mal
• il fait beau au moins 50% du temps
• ils reçoivent des speakers internationaux : Github, Travis, Cloudbees (ah non, c'est moi ça)
• au commande, une équipe de choc - et encore, avec une femme sur le point d'accoucher ils étaient en effectif réduit. Les étudiants de Supinfo participent activement et ça c'est chouette
• ils font une Mix-it Party le jeudi soir. C'est sur qu'après la débauche du speaker dinner il fallait bien ça pour se remettre. Je me suis retrouvé à coder g# ... 
• ils ont un super logo :P
• ça donne envie d'y retourner

Bon, je ne suis pas si jaloux que ça, parce que le Breizhcamp va être bien aussi

• les speakers seront choyés, avec un speaker dinner encore bien plus mégafestif
• on aura facile 10000 participants
• nos locaux sont grandioses, et encore ce n'est rien par rapport avec ceux qu'on trouvera pour l'édition 2014
• les 13 et 14 juins, ils fera beau à 200%
• nous aurons nos premiers speakers internationaux !
• au commande, on a pas de femme enceinte (au dernières nouvelles) mais on est tout de même toute une équipe. Je ne désespère pas de voir quelques étudiants cette année
• nous ferons une Breizh-Party jeudi soir en même temps que le speaker-dinner, en gros ceux qui voudrons nous rejoindre seront les bienvenus
• nous avons un chouette nouveau logo
• tous ceux qui sont venus ont envie de revenir
• NOUS avons de super goodies, nananèreu

Blague à part, Mix-IT est une très chouette conférence, qui me donne plein d'idées pour améliorer le BreizhC@mp, c'est ça qui est chouette avec ces conférences qui se développent en France, on se passe des tuyaux et on peu tenter appliquer les bonnes idées vues ailleurs.

Donc si vous aimez le breizhcamp, le jugsummercamp, et même devoxx, essayer de caser deux jours pour faire un tour à Mix-it l'an prochain, ça vaut le détour

Mon gamin a explosé l'écran de mon MacBook. Ca énerve un peu sur le coup, et puis bon, on va le garder quand même (le gamin) et faire réparer la bête (le MacBook).

Là commence l'épopée...

A Rennes, nous n'avons pas (encore) d'Apple Store officiel, aussi je me suis tourné vers un revendeur officiel, DXM - plutôt qu'un service d'échange sur Internet, qui aurait fait emporter ma machine pas UPS pour me la rendre quelques jours plus tard d'après la pub, mais j'ai préféré la solution locale (erreur?)

Je dépose donc ma machine le 3 avril, machine qui est prise en charge sur un joli tapis de mousse pour ne pas risquer de rayer l'objet vénéré des apple fan-boys, mais bon vous fatiguez pas il est déjà tout rayé et l'écran est mort. Un devis doit être établis pour la réparation. Quand ? "on est déjà mercredi, ce ne sera pas avant la semaine prochaine" - ouhlà, on sent les cadences infernales !

6 jours plus tard, je demande des nouvelles, et on m'informe que le technicien a rencontrer des problèmes avec ma machine - j'aimerais bien en savoir plus, c'est pas que je sois de nature inquiète, mais cette annonce n'est guère encourageante sans plus d'informations.

Le lendemain, le technicien me contacte.
J'apprends que mon écran est pété (sans blagues ?), que le lecteur CD est bloqué et que la sortie vidéo est morte. S'en suit une discussion homérique avec le technicien certifié Apple ++ qui n'a donc pas constaté que j'ai remplacé le lecteur optique par un second disque dur - un rond par un carré, c'est vrai qu'il faut avoir l'oeil aguerri - et que la sortie vidéo fonctionnait quelques jours avant, comme peuvent en témoigner ceux qui m'ont vu à Devoxx pour la session "3615 Cloud". Je finis par blaguer en disans que ma machine ne supporte pas les écrans Apple et est habituée à son Dell, auquel elle est connectée chaque jour, pour couper court à ce débat délirant, et que le technicien accepte de m'établir le devis tant attendu - on est J + 8

J+9, pas de devis, je contacte donc mon revendeur premium, pour m'entendre dire que c'est la faute de gMail, qui met toujours leurs mails en spam - mais oui bien sur, c'est gMail, qui d'ailleurs n'a rien reçu même en spam. Je demande donc l'envoi sur ma boite @cloudbees.com (qui est aussi un gmail), et je reçois 5 minutes plus tard le devis pdf attaché à un mail vide - qui se fait classer en spam :-/ Il serait peut être temps de creuser la question de votre système de messagerie, pas simple de contacter vos clients dans ces conditions ... Au passage, mes deux mails adressés à @dxm.fr sont restés sans réponse.

Je renvois le devis signé le vendredi, et je rappelle pour m'assurer que la pièce est commandée, histoire de ne pas perdre en plus le week-end en attente

J+12, le technicien me contacte pour m'informer qu'Apple n'a pas d'écran haute-résolution en SAV et ne peut me fournir une date de disponibilité. Super, ça vaut le coup de passer par un revendeur premium ++.

J+22 : un SMS me prévient que ma machine est disponible. Dommage pour moi je suis déjà en route pour Mix-IT...

Ce lundi, je passe enfin récupérer mon MacBook, et là, surprise, ce n'est pas la dalle d'écran mais TOUS le capot supérieur qui a été changé, parti donc l'autocollant Dark-vador sur mesure que ma femme m'avait offert ! Et re-surprise, la pièce changée n'est pas sur place, elle a été envoyée à Apple pour "échange". Autrement dit, le super revendeur Apple premium ++ est juste un démonteur, qui n'a pas de pièce en stock.

J'ai demandé la récupération de la pièce d'origine, car je tiens à cet autocollant, mais je doute qu'elle soit retrouvée un jour, probablement déjà partie en recyclage (en supposant qu'un Mac, volontairement indémontable par conception, soit recyclable).

Bref, si vous avez besoin du SAV Apple, vous savez au moins où ne pas aller...

Organiser une conférence, ça veut dire établir un programme, et pour cela la grande tendance c'est le "call for paper" : laisser les speakers venir à nous (en passant quelques petits mots incitatifs auprès des rocks stars).

Le breizhcamp a ainsi reçu 120 propositions, soit à peu près 2 fois le nombre de sessions. Le tri est donc assez facile comparé à une conférence comme Devoxx, avec 500 talks "conférence" pour 50 slots à pourvoir, et des notes du coup très serrées.

Car il y a aussi les notes : chaque membre du CfP vote pour les sujets en donnant une note de 1 à 5, selon des critères qui lui sont propres (speaker, sujet, ...) et sans connaître les notes de ses camarades. Il peut aussi bien sur ne pas voter pour les sujets sur lesquels il n'a pas d'avis, faute de connaître le domaine évoqué.

Pour gérer ces votes, nous (enfin, surtout Yan) avons développé une application pile poil pour gérer les votes, ce qui nous a permis de traiter le 120 sujets en quelques heures.

L'étape suivant c'est de dépouiller les résultats. Aussi nous nous sommes retrouvés pour appliquer l'algorithme suivant :



agree étant une fonction qui prend en paramètre l'équipe du CfP, passe par une étape de discussion récursive pour donner un résultat booléen.



L'idée est de remplir un tiers du programme en fonction des notes, puis de regarder dans ce qui reste ce qui est redondant, innovant, etc et qui mérite d'être sélectionné tout de même, ou bien de reclasser un sujet dans un autre format en fonction des informations que nous a fournis le speaker.


Nous arrivons ainsi au programme dont une version graphique sera publié dans quelques jours. Les speakers promus ont été notifiés, les autres devront se contenter de venir en spectateur.



Je sais la déception que peut être de ne pas être retenu à un CfP, la frustration d'avoir proposé un bon sujet qui n'est pourtant pas retenu, amis speakers ne nous en voulez pas, la tâche n'est pas facile et il faut bien trancher à un moment donné.

Coursera propose une seconde session de ses cours scala - vous pouvez encore rattrapper le cours, même si vous serez un peu hors délais pour faire un high-score, mais peut importe ça reste très intéressant.

Le principe de ces cours, c'est de proposer des sessions en vidéo et des exercices à réaliser et à soumettre pour validation.

La partie vidéo est génialissime. Très progressives, les "lectures" vous font découvrir peu à peu scala, et surtout la programmation fonctionnelle. On pourra trouver ces présentations excessivement théoriques, formalisées de manière très mathématique - elles restent cependant très didactiques, et j'adore l'option de vitesse de lecture, qui permet de passer en *1,25, *1,5 voir *2 pour des passages qu'on a déjà compris on qu'on trouve trop théoriques (ou bien quand on a pas trop de temps à leur consacrer :P). A quand la même fonctionnalité dans Parleys ?

Par ailleurs, les vidéos présentent les slides avec en filigrane le stylet de Martin Odersky, qui ajouter des schémas ou des petits bouts de code explicatifs.
Bref, coursera, c'est de la balle



La partie exercice est également parfaitement adaptée et bien préparée. On a assez peu de code à produire dans un squelette bien documenté qui nous guide vers la solution, il y a "juste" ce qu'il faut pour apprendre ce que l'exercice vise à nous faire comprendre.

Question temps, il faut compter 3 à 4h environ pour chaque semaine de cours. Pour ce qui me concerne j'ai fait le 1er sur une pause midi, le second "en tâche de fond" sur deux jours et le dernier hier soir, terminé ce matin parce que passé 23h je commençais à faire n'importe quoi.

Clairement, c'est consommateur de temps, mais bon, à étaler sur une semaine ce n'est pas si méchant que ça quand on considère la qualité du support didactique. Au moins, lors des prochains trolls anti-scala j'aurais de vrais arguments :)

et scala dans tout ça ?




Scala, c'est des fanboys, une armée de contradicteurs qui n'ont jamais regardé plus loin que le mal qu'on leur a dit de scala, et des trolls en pagaille, alors allons y :



Syntaxe 
Le premier contact est un peu rugueux : la syntaxe est déconcertante. Pour un langage qui cible la JVM et s'adresse aux développeurs Java voulant gouter à la programmation fonctionnelle, je ne comprend pas certains choix de syntaxe - ils ont sans doute une bonne raison d'être, mais ...

foo(x: Int): Boolean pour une méthode foo qui prend un entier et rends un booléen. Pourquoi donc avoir inversé l'ordre type / nom par rapport à Java ? A n'en pas douter il y a une bonne raison dans l'inférence de type ou que sais-je, mais c'est un frein à la lisibilité par le développeur Java.

import truc._ plutôt que import truc.* vous me direz que c'est un détail, mais pourquoi ne pas reprendre la même syntaxe ? Intention délibérée de se démarquer (inutilement) de Java ?

bon, évidemment on s'y fait et arrivée en "semaine 3" on n'y fait plus trop attention.

J'ai eu droit à ma plus belle volée de tweets (record absolu) en signalant mon désaccord sur la non-utilisation du return. Car, en java, pour un algorithme récursif j'aime utiliser return pour marquer la condition de sortie:


public int recurse(int x) {
    if (x == 0) return 1;
    recurse(x - 1)
}

ce qui peut se traduire en Scala sans soucis, mais les "bonnes pratiques" suggèrent plutôt


public int recurse(int x) {
    if (x == 0) 1
    else recurse(x - 1)
}

Profitant de mon passage à DevoxxFrance, j'ai pu avoir une longue discussion avec Stephan Janssen, le papa de Devoxx. Comme vous le savez, la structure du BreizhCamp est largement inspirée de cette conférence phare, et le rapprochement était donc inévitable.

Devoxx est une marque déposée, proposant aux versions Française et Londonienne une franchise. Cette formule permet à Stephan de garantir l'image de marque de la conférence qu'il a construite brique après brique depuis 12 ans.

J'ai le plaisir de vous annoncer que nous sommes arrivés à un accord et avons conclus la 4ème franchise Devoxx, car ce que vous avez connu sous le nom de BreizhCamp deviens :



Au programme :

• 4 tracks en parallèle,
• formats Universités, Hands-on, Tools in Action, Quickies, Conférences
• 50 talks, dont 25% en breton
• beaucoup de beurre salé

plus d'infos sur www.devoxx.bzh

Vos serveurs sont dans le Cloud, votre build est dans le Cloud, alors pourquoi pas votre IDE ?

J'ai passé pas mal d'années à gérer un document de "mise en place de l'environnement de développement", un pavé décrivant pas à pas comment installer Eclispe, Maven et tout ça, jamais à jour et lu en diagonale par les développeurs qui mettaient de toute façon plus d'une journée pour avoir quelque chose de carré.



J'ai ensuite tenté de simplifier et d'automatiser un peu les choses (genre, j'étais committer Maven à l'époque, vous voyez le liens ?). J'ai donc maintenu un gros ZIP avec un JDK, Subversion, Maven, Tomcat et Eclipse avec la conf qui va bien "prêt à l'emploi". C'était un peu mieux, mais ça restait compliqué. Au moins je passais moins de temps sous Word :P

De nos jours, je tenterais de gérer ça avec Chef ou Pupet, mais il faut avouer que, si ces outils font des merveilles sur des serveurs Linux, leur utilisation pour gérer les postes de développement Windows est encore un sujet de science fiction.

Quelle alternative ? Certains (ils se reconnaitront) essayent d'y répondre en virtualisant le poste de développement dans de VM, contraignant les développeurs à utiliser des outils bridés dans un environnement peu réactif.

L'autre piste, c'est l'IDE en mode Web - Codenvy explore cette piste.


Codenvy permet de connecter votre repository github à un IDE web Eclipse-like (histoire de ne pas dépayser le développeur lambda ?). Je l'ai testé avec mon projet codestory, histoire de voir.

L'import du projet maven se passe bien - mieux que sous Eclipse diront les médisants ! L'IDE réagit vite et bien. "Rich Internet Application" réalisée selon les bonnes pratiques, l'UI s'affiche très rapidement et les fonctionnalités sont chargées en tâche de fond. L'inverse du portail de support Zendesk que j'utilise tout les jours en fait ...



Evidemment, les actions proposées dans cet IDE sont loin de ce que permet Intelij Idea. En termes de refactoring par exemple, on ne me propose que de renommer ma classe. Cependant, pour un certains nombre de développeurs que je connais, c'est la seule fonction qu'ils utilisent, donc ça ne gènera pas :P


L'autre intérêt de l'IDE web est sa parfaite intégration avec Git d'une part, et avec la plateforme cible d'autre part. Les wizard Git sont très propres et prendront par la main les développeurs novices. Le déploiement vers un PaaS est également très bien pris en compte. Cet IDE cloud se calle donc parfaitement entre les services d'hébergement de code et les services d'hébergement d'applications.

Après quelques essais, l'IDE n'est pas super réactif mais raisonnablement utilisable. Disons que si j'avais un truc à corriger en express pendant Devoxx je pourrais prendre ma tablette et m'en servir pour corriger et pousser un correctif. Le build est lent et je n'ai pas réussi à lancer mes tests unitaires. Bref, je n'ai pas l'intention d'abandonner Idea.

Pour quel usage ? J'avoue que je me pose la question, car on est tout de même très loin du confort d'un IDE classique, dont la puissance de refactoring et d'assistance sera difficile à égaler (mais ça viendra). Cependant, il y a pas mal de scénarios qui m'ont été soufflés sur twitter :

• les corrections rapides, lorsqu'on qu'on veut "juste" corriger un petit truc vite fait. Le genre de chose qu'on fait actuellement sous Github sans aucune assistance, ici on a un compromis intéressant.
• les langages qui ne permettent ou ne nécessitent pas une foultitude de refactoring complexes.

Pour du développement Java bête et méchant, je reste sceptique à ce stade. Ce que j'aimerais sur un outil de ce type c'est un mix d'infinitest (test en continu) et de seleniumgrid (tests distribués) sur une infrastructure cloud. Autrement dit, à chaque modification les tests de mon project sont lancés en parallèle et j'ai du feedback en quelques secondes maximum.

Vous avez raté la finale de CodeStory,
et bien je vais vous éviter de mourir idiot, en vous proposant une séance de rattrapage, et en vous présentant au passage  ...

A la demande de Laurent Huet je vais animer un "12@13" sur CloudBees chez Softeam.  Il y a quelques années je participais chez Orange à des "Midi techniques", et encore avant j'organisait sur la pause déjeuner les "Tip of the week".



Cette pratique est finalement assez répandue dans les sociétés de service : comme il est délicat de dé-staffer les équipes pour des journées de formation technique, et qu'il est déjà délicat de motiver les gens pour suivre ce genre d'événements (sic!), une solution est de prendre sur la pause déjeuner pour organiser un rendez-vous technique, la boîte ayant le bon sens de payer les plateau repas pour que tout le monde s'y retrouve.

David a déjà proposé ses talents pour des "Brown Bag Lunch", et Laurent me fait découvrir le site associé, www.brownbaglunch.fr - il y a déjà un joli pannel de talents pour accompagner vos sandwiches :)

J'ai donc créé une entrée pour les événements bretons, et je me propose de venir dans votre entreprise vous présenter CloudBees et/ou Jenkins, le temps d'une pause déjeuner. Sur Rennes évidemment, mais aussi pourquoi pas plus largement sur la Bretagne (et apparentés), sous réserve que ce déplacement colle avec mon agenda.




contactez-moi si vous êtes intéressés.

Vous connaissiez le ClassLoader hell, le ClassPath hell, je vous souhaite de ne jamais avoir à gérer le Backward Compatibility Hell.



Sur un malentendu, je me suis retrouvé maintainer du plugin Git pour Jenkins. Gratifiant parce que c'est l'un des plugins les plus installés, difficile parce que c'est plus un amas de pull-requests qu'un véritable plugin, et ça continue ...

J'ai donc voulu prendre le diable taureau par les cornes et entamer un début de tentative de refactoring du plugin, en commençant par isoler les opérations Git de bas niveau. Le plugin est conçu autour d'une GitAPI, qui a priori assure ce rôle, sauf que l'interface contient des fonctions hérétoclites et surtout fait un mix entre les aspects pur Jenkins et les spécificités Git. Entre autre, elle prenait parfois en charge la gestion des esclaves de build (remoting) mais pas toujours ...

Bref, le chat sur les genoux, voici un boulot digne d'un vendredi. Tous les testent passent, et hop, je lance une release -> 1.27

Ca c'était donc le vendredi soir, et dès le samedi je découvre une ignoble régression, parce que la suite de test ... est perfectible. -> 1.28

Lundi, je reçois quelques mails et contacts sur #irc par les maintainers d'autres plugins. En effet, ce code est aussi utilisé par le plugin gerrit, git-parameter, ou cloudbees validated-merge (et peut être d'autres ?).

Le soucis ici, c'est que les plugins Jenkins ne reposent pas sur un moteur de modularisation (genre OSGi, JigSaw, JBoss Modules ...) et donc TOUTE classe publique d'un plugin peut potentiellement être utilisée ailleurs et ne doit donc JAMAIS retirer quoi que ce soit. Sauf que, comme beaucoup de monde, les développeurs ont tendance à mettre public un peu tout, ne serait-ce que pour pouvoir dispatcher leurs classes dans des packages spécialisés par fonctionnalité (quid du "friend" en java ?)

Autant dire qu'on se traine pas mal de casseroles. -> 1.29.

Fort de cette boulette, j'ai passé ma journée de mardi à reprendre entièrement mon refactoring, à isoler proprement le code Git dans un nouveau plugin utilitaire "git-client", partagé avec les autres plugins, et à tester la compatibilité avec les autres plugins. Cela à nécessité de définir une nouvelle API toute propre :

• D'un côté un GitClient avec les méthodes supportées, contrôlées par une suite de test
• De l'autre la "vielle" GitAPI avec les autres méthodes, toutes dépréciées (sauf si un auteur de plugin se fait connaître)
• tout en retournant un systématiquement composant GitAPI, même si l'API ne promet qu'un GitClient, histoire de rester backward-compatible à l'exécution.

Après quelques pas mal d'heures, on arrive donc au couple Git-plugin 1.2.0 (ça valait bien un changement de version mineure) + Git-Client-plugin 1.0.2


A côté de ma participation à Jenkins, il y a aussi la partie Cloud de Cloudbees. Ici, pour savoir si un plugin est utilisé par l'un de nos clients, on fait l'équivalent d'un grep (en un peu plus long). On peut donc à loisir virer quelque chose, quitte à trouver un contournement pour les 2 pelés qui ont activé la fonction qu'il ne fallait pas.

Ma seconde conclusion est donc que, pour un développement productif et donc un Time-to-Market réduit, le mode SaaS est sans commune mesure avec l'approche "produit" traditionnelle.

La pré-qualification pour CodeStory s'est terminée il y a quelques jours, et je suis heureux de trouver dans les qualifiés quelques visages (enfin, en tout cas leur avatar) qui me sont chers.

D'une part il y a Michel, membre du BreizhJug, mais il y a aussi Yan, qui a certes quitté le BreizhJug pour lui préférer le NormandyJug (???) mais on ne lui en veut pas.

Il a d'ailleurs bloggé sur sa participation. D'abord sur le choix de la simplicité, et je ne lui en veux même pas de dire qu'il préfère un serveur géré à la main à une offre cloud - après tout si ça l'amuse. Du coup il a du se tapper une sauvegarde des logs en base alors qu'il aurait juste pu activer PaperTrail :P Non, je ne suis pas du tout aigri parce que je n'ai pas réussi à dépasser 8/20 au score de performance alors qu'il a tapé un 10000/20 ...

Oui, parce qu'en dehors de répondre correctement aux problèmes algorithmiques proposés par l'équipe de CodeStory, il fallait répondre vite, et ce pour des données qui devenaient très, très volumineuses. Un sacré test aux limites pour les algorithmes proposés. http://status.code-story.net/ donnait le résultat des scores chaque jour et permettait à chacun de revoir sa copie.

Je pourrais vous dire que j'ai manqué de temps pour améliorer ma solution mais en fait non, je n'ai pas eu d'idée précise pour faire mieux - en fait si, mais il aurait fallu y passer significativement plus de temps. On a tous un boulot à côté, donc la sélection était aussi un test d'efficacité à implémenter rapidement des optimisations. J'attends d'ailleurs avec impatience le billet de Yan sur cette phase.

Ensuite, il ne s'est pas contenté de participer, il a fait une version en Java, en Scala, et en Ceylon - au passage, on sait donc qu'il y a au moins une personne au monde qui fait du Ceylon.

Donc voila, pour ce qui me concerne j'ai mon poulain pour la suite du concours. J'espère le revoir à DevoxxFrance au côté de David et Jean-Laurent pour la finale !



Lisez son blog pour avoir tous les détails : www.ybonnel.fr

Plusieurs personne me l'ont demandé, voici donc un petit guide de la façon dont j'effectue le montage pour les vidéos du BreizhJUG sur Parleys.com.

Tout d'abord, il faut évidemment enregistrer la conférence. Nous utilisons un caméscope à disque dur, équipé d'un micro bluetooth, qui permet de capter la voix des speakers, même quand ils tournent la tête (contrairement au micro main/cravate), et évite de trop capter le son de la salle. Nous avions précédemment un micro canon, mais ce système fournit un bien meilleur résultat.

Nous capturons aussi (parfois) la sortie VGA du speaker via un boitier vga2usb. La qualité est moyenne comparée à du matériel pro, mais bien meilleure que de filmer l'écran du vidéo-projecteur. Il existe aussi des soft à installer sur la machine du speaker pour capturer sa session, mais évidemment les speakers peuvent se montrer réticents, et on se demande toujours ce que ça va donner avec le double affichage.

Voilà, la session finie vous avez donc une (ou deux) vidéo à monter dans parleys, plus les slides du speaker (enfin, dans mon cas c'est plutôt quelque jours après car j'oublie toujours de les demander)

J'effectue le montage vidéo dans Adobe Première, parce que je connais pas trop mal ce (très bon) soft, et surtout parce que j'utilise le filtre "denoiser" pour retirer le bruit que je constate systématiquement sur la bande son.



Je ne sais pas pour vous, mais moi quand je regarde un talk en ligne, que la vidéo soit passable cela ne me dérange pas trop, mais si le son est pourri je crie au scandale.

Le montage sous Première me permet aussi de caler ma vidéo "vga" pour avoir la même bande son sur mes deux flux. Première me permet alors d'encoder tout ça en mp4, attention parleys n'accepte pas plus de 300Mo pour une session, aussi je suis souvent obligé de considérablement pousser les paramètres de l'encodeur pour tenir cette contrainte.

On passe ensuite dans le "publisher" parleys.

J'importe mes vidéos et les slides PDF par simple glisser / déposer. Publisher analyse les PDF et me propose chaque slide comme "asset".





Il ne reste plus qu'à placer les piste vidéos et à caller les slides un à un. Si on a une piste "vga", parleys dispose d'une identification des slides qui permet de faire ça en un tours de main (enfin, quand ça marche)



Il reste à choisir une image comme icone du talk, renseigner les métadonnées, puis uploader - le plus long avec l'encodage pour ce qui me concerne, depuis ma petite connection ADSL de campagne.

Et hop, en ligne.

Je rebondis sur un tweet de Julien Dubois pour verser une larme sur Java, et la façon dont la plateforme arrive à partir en sucette d'elle même.

Prenons un exemple excessivement simple : la gestion des status HTTP. Ca semble vraiment le truc de base, non ?

Le runtime Java SE propose HttpURLConnection. Déjà on se demande d'un point de vue puriste de l'OO pourquoi la "connection" porte ces constantes et pas une classe de constantes, mais bon, java 1.0 a été pondu à l'arrache, passons.

Arrive Java EE, sensé être basé sur Java SE (non ?), mais évidemment on a une autre classe parce que c'est vachement plus drôle HttpServletResponse. Ici les codes retour sont portés par un objet qui matérialise une réponse HTTP, c'est un tout petit peu plus logique, mais ça reste très con de dupliquer. Ne soyons pas médisant, cette classe ajoute d'indispensables constances :

• SC_CONTINUE
• SC_SWITCHING_PROTOCOLS
• SC_FOUND
• SC_TEMPORARY_REDIRECT
• SC_REQUESTED_RANGE_NOT_SATISFIABLE
• SC_EXPECTATION_FAILED

et aussi, redéfinit les constantes existantes avec des noms un peu plus explicites :  HTTP_REQ_TOO_LONG -> SC_REQUEST_URI_TOO_LONG. C'est juste un peu dommage d'avoir conservé ce préfixe "SC_" qui nous rappelle les règles de nommage du siècle dernier.

Mettons que Java EE a eu besoin de ces nouveaux codes, non prévus la Java SE. Pourquoi ne pas avoir ajouté au backlog Java SE "ajouter les codes manquants du standard HTTP  à HttpURLConnection" - je veux dire, il y a un spécification pour HTTP, ces codes ne sont pas juste issus d'un reverse engineering à la con !

D'ailleurs, de son côté, commons-http a créé sa propre classe de constantes HttpStatus avec références explicites aux RFC 1945 / 2518 / 2616 (HTTP 1.0, WebDAV et HTTP 1.1), tout en nous coltinant ce magnifique préfixe "SC_", nous avons donc sans doute affaire à des développeurs issus de la même formation ;P

Et bien sur, l'équipe Spring qui crache dans la soupe Java EE depuis tant d'année ne s'est pas privée de sa propre version HttpStatus, sans les références RFC mais aussi sans préfixes pourris.

Bref, cet exemple est révélateur de l'écosystème Java : Java SE et Java EE qui n'arrivent même pas à être cohérents, Apache qui a longtemps proposé des projets génériques (les fameux commons-*) venant compléter les manques de la plateforme, Spring qui ajoute son grain de sel...

Même sur un exemple aussi simpliste que la liste des codes prévus par une spécification officielle, c'est la misère. Alors pour un StringUtils ...

"Winter is coming"; l'hiver est même déjà bien installé, mais ce n'est pas encore assez pour un gars comme moi qui a des racines nordiques, aussi je serais :

• le 28 janvier au YaJug (le JUG du Luxembourg) pour une soirée conjointe Jenkins / Sonar, en compagnie d'Olivier Gaudin.

Le thème de la soirée sera donc comment passer d'une approche "cycle en V" (phase d'intégration, audit de code, etc) à une approche "continuous". En gros, comment donner vie à votre code

• les 2 et 3 février au Fosdem (Bruxelle) sur le stand Jenkins

CodeStory remet le couvert en 2013.
CodeStory, c'est le pari un peu fou de deux amoureux du code qui ont lancé l'an dernier un concours : prouver, en se frottant à une série de challenges qualificatifs, ses qualités de développeur. Après une phase ouverte à tous, des binômes ont été sélectionnés puis confrontés lors d'une finale en live au ParisJug et enfin mis à l'épreuve pendant DevoxxFrance, codant en direct, fàce à un public très attentif et participatif.

Un tour de force étonnant : agilité poussée (sprints de 20 minutes, binômage, TDD et refactoring, KISS), approche très didactique en interaction avec le public, tout ceux qui ont "sacrifié" une heure de Devoxx pour aller les voir en sont revenus ébahis.


Pour 2013, l'équipe remet le couvert et lance donc la première phase : inscription des candidats.

Cette année le concours va proposer à chaque participant de développer une application qui devra répondre à des "questions" via une interface web http. Le niveau 0 ("inscription") consiste à coder quelque chose qui répond à http://(serveur)/?q=Quelle+est+ton+adresse+email avec du texte brut indiquant  ... l'email du participant.

NB: Les niveaux suivant seront un peu plus durs :) Ceci dit, ça ne coute pas grand chose de tenter son coup juste par curiosité, alors viendez !

Chacun peu venir avec son langage / framework / outil préféré, faire au plus simple ou sortir l'artillerie lourde (mais ce n'est pas dit que cela plaise aux jury :P).

Comme je sais d'avance que je n'aurais pas trop de temps pour dépasser le niveau 1 ou 2 (ce qui me donne d'avance une excuse pour me planter) je propose à tout ceux que ça tente d'héberger leur application et leur CI sur cloudbees : https://codestory.ci.cloudbees.com/ ; j'ai ainsi ma super contribution perso déployée sur http://nicolas.codestory.cloudbees.net/?q=Quelle+est+ton+adresse+email (un simple tomcat, rien de bien hype).

L'avantage (pour vous) est d'avoir un service tout compris pour votre appli, l'avantage pour moi est que ça va permettre de tester sur CloudBees les stacks les plus tordues que vous allez vouloir mettre en oeuvre, comme ça je serais prêt à aider des clients avec de vrais projets et les même technos :D

-> contactez moi par email (si vous avez tout bien compris, vous savez ou trouver mon e-mail...)

Notre petit Sacha Noël est passé un peu en avance cette année, et vient d'officialiser le passage de CloudBees Genapp en open-source

kesako ?

Vous connaissez CloudBees pour le déploiement d'un WAR sous Tomcat, ce que vous ne savez sans doute pas c'est ce qui se passe en dessous. Depuis Octobre, notre architecture a été repensée pour être extensible, et repose sur une brique nommée "Genapp" - il s'agit du coeur d'exécution de RUN@Cloud.


Genapp est un moteur extensible d'approvisionnement et d'exécution d'applications,  il gère l'installation de vos applications sur des machines du Cloud et leur exécution. Il repose entièrement sur un mécanisme de plugins, en fait Genapp ne gère aucun conteneur par défaut.

Chaque plugin est chargé de préparer le runtime de l'application - une JVM et un serveur TomEE, ou bien un runtime Node.JS - et de fournir les scripts de démarrage et d'arrêt de l'application. CloudBees propose ses runtimes historiques Tomcat 6 et JBoss 7, et a ajouté une série de "clickstack" (dispos sur https://github.com/cloudbees-community/) pour divers environnements.


qu'est ce que j'en ai à ... ?

Ce mécanisme va vous permettre si vous le souhaitez de complètement customiser votre runtime, soit en créant de nouveaux plugins pour venir compléter une stack existante - c'est ainsi qu'est implémentée l'intégration de newRelic par exemple - pour venir greffer le service de votre choix dans les stacks existantes, soit de forker une stack pour venir y mettre votre grain de sel.

CloudBees ne sera donc plus une "boite noire".

Devoxx conference is much more than an annual event for Java Community. With DevoxxFrance, DevoxxUK and Devoxx4kids it's now a growing ecosystem of great community events.

Devoxx team used to host it's registration and call-for-paper applications on it's own hardware, and as I proposed to host it on CloudBees Platform as a Service, they were so enthusiastic I quickly understood being sysadmins on this infra to keep the apps up and running 24x7 isn't a fun job. They prefer to focus on making the conferences happen and be even better every year.

The interesting challenge is that those application haven't been designed to be hosted in the Cloud. They don't use a fully stateless web framework à la Play, They aren't split into small REST services invoked from a pure Angular javascript frontend, they are ... like 99,9% existing application, using common Java Frameworks.

Registration application was the simpler one to migrate. It's a very classic Servlet-based application, designed using Vaadin for web UI, and a Spring and MySQL backend. We just had to make some minor configuration changes so that the app can get a datasource injected by the platform, as well as SendGrid JavaMail session.


Most container require you to add a dedicated deployment descriptor to declare container resources (jboss-web.xml, weblogic-web.xml, etc). If you don’t want production information to be stored in SCM neither hard-wired within the artifact, you probably rely on an external properties file to be loaded by spring on startup, or comparable workaround.

CloudBees platform let you inject parameters and resources to an application, so that you can have the exact same binary WAR deployed on staging environment and then on production, with just the adequate Mysql DataSource bound and configuration parameters (secret credentials, ...) injected.

Thanks to this feature, the Devoxx team is able to have staging environment be an exact replica of production environment, just with less connected users :) Deployment process is also the exact same one, and is ran on every commit that successfully builds the WAR. With such an homogeneous infrastructure, they can be very confident when deploying to production.

Devoxx team quickly setup a continuous delivery pipeline. As they push code to bitbucket - they use Mercurial, sorry for that, read my previous post - Cloudbees DEV@Cloud Jenkins is building the app and automatically deploying to the staging environment.

They also enabled sonar add-on service, because continuous delivery don't prevent you to write ugly code :)

As the Platform handles concurrent versions deployment, the service isn't interrupted as you deploy a new app, the "old" application remains active until the "new" one is ready to handle requests, and then http traffic routing is switched. So, deployment to production isn't a stress anymore, with twitter announcement about temporary service black-out.

After some more testing, they can promote the build to production. A single click to deploy app in production, cool isn't it ?


This encourages rapid feedback, small change-sets between "releases", so small risks ... I won't explain you here what agile software development is !

Devoxx team also wanted to test the scalability of the platform, and then hit an issue as vaadin is using HTTP session to store UI state, so you can't use round-robin load balancer. Hopefully, cloudbees platform can be configured to enable sticky session. This is something you have to consider to host your application on a Cloud platform, as most frameworks rely on this feature, and sometimes you even don't know (I think about you spring-security!). The other option is to enable session clustering around the nodes your application is running on.

The Call For Paper application required more changes to be "cloud-compliant". This application let speakers upload existing slide decks so the CFP team can review a proposal from existing content. The application used to store those files on file system, using a parameter to configure the local directory. How does this translate when running in the Cloud ? The app is running on multiple clustered nodes. It starts on fresh new nodes every time a new version is deployed. So, even local file-system can be used for temporary files during request processing, it is not persistent, neither replicated.

This is something CloudBees plan to address in 2013, but at this time there was no other option than changing the application code to use Amazon S3 to store files. JClouds API and S3 provider helped a lot to reduce the amount of time spent to fix this design issue, and the application was running on the staging environment after a few hours of coding.

The RUN@Cloud console gives general health and performance information about the applications, so the Team can monitor his application and - if necessary - change the platform configuration to use larger nodes, more nodes, or both. They also enabled NewRelic add-on to get fine grained analysis, that could help in case something wrong happes.

Devoxx Team officially announced registration for DevoxxFrance to be open, running on the new CloudBees infrastructure. CFP application has been migrated earlier today. So feel free to register to Devoxx and propose your talks, app is now running on a Platform-as-a-Service, with all CloudBees team ready to help in case anything goes wrong, and the Team can work on the real added-value : continue to make Devoxx the best conference ever.

Depuis que j'ai découvert Git j'ai du mal à m'en passer. Lorsque je suis contraint d'utiliser Subversion je passe par git-svn, ce n'est certes pas idéal mais c'est déjà d'un grand confort.

Pour aider l'équipe Devoxx à adapter leur application sur CloudBees, j'ai du utiliser Mercurial (Hg pour les intimes). Mercurial est très comparable à Git, mais un peu déroutantes pour un Git-iste car les commandes reprennent les même nom mais pour un usage différent (fetch devient pull, pull devient fetch pull, reset devient revert, revert devient backout, etc. Si vous devez faire l'exercice, garder ce tableau sous le coude.

Bref, j'ai eu la flemme d'apprendre Mercurial, ni d'utiliser SourceTree tout en mode graphique parce que... et bien la ligne de commande y'a que ça de vrai, n'est ce pas ?

Il faut savoir qu'il n'existe pas de passerelle officielle hg->git, contrairement à celle qui permet d'utiliser svn. Il existe par contre une passerelle inverse, très mature, qui permet aux utilisateurs de mercurial d'utiliser un repository git: hg-git. La raison de cette absence est apparemment philosophique, si j'ai bien tout suivi ...

Il existe donc pléthore de solution custom pour prendre en charge ce besoin. J'en ai donc testé quelques un pour finalement tomber sur git-remote-hg.

Comme expliqué sur le blog, comparée aux autres solution cette passerelle à l'avantage de se plugger dans les mécanisme de transport de git, et non de chercher à fournir des commands complémentaires du genre "git hg-clone". On travaille donc en pur git, mais avec un repository distant qui utilise le protocole "hg::*".

J'ai donc cloné le repo devoxx, tripatouillé deux trois fichiers de configuration, et voulu pousser tout ça dans bitbucket pour proposer une pull-request. J'ai alors eu un grand moment de solitude :


git-remote-hg fait apparaître les branches mercurial sous l'arborescence "branches", et la branche de développement du projet, équivalente du master git, est donc branches/default. J'ai passé un certain temps à tenter d'attacher mon master à la branche remote origin/branches/default sans succès. Tous les "--set-upstream"n'y ont rien changé. J'ai bien cru que j'allais devoir changer d'outil.

Au final, j'ai crée une branche locale branches/default (les branches git peuvent contenir le caractère '/', le saviez-vous ?) associée à la branche remote origine/branches/default, mergé mon master dedans, et j'ai (enfin) pu pousser tout ça sur bitbucket. Ouf!


Bizarrement, chaque push m'indique la création d'une nouvelle branche remote. Cela fonctionne donc mais l'intégration n'est pas encore parfaite.

Bref, si vous devez vous aussi jongler entre mercurial et git, cette solution semble intéressante, à condition de respecter du 1:1 avec les branches mercurial. Elle permet de synchroniser les repositories sans perte d'information, par exemple pour proposer un miroir Git d'un repo Hg, et vois évite de devoir choisir entre Git et Hg si vous en êtes à ce stade.

Au passage, au cours de mes tentatives j'ai découvert que Perforce venait tenter sa chance sur le territoire Git : http://www.perforce.com/blog/121001/improving-git-experience-everyone. De mon point de vue, question SCM, les jeux sont faits (en attendant le prochain :P)

La dernière journée de Devoxx est particulière. D'une part, on est quelque peu lessivés par la soirée au Nox une longue semaine de dur labeur. Par ailleurs, le planing est réduit à 4 salles en parallèle car de nombreux participants sont déjà partis (ou n'arrivent pas à se lever ?)

J'arrive pour ma part à être présent pour la première session du matin, présentant les évolutions des annotations dans Java 8. Nous aurons donc un peu plus de flexibilité dans les annotations, comme par exemple la possibilité de répéter une annotation sans devoir l'empaqueter dans une annotation plurielle (@Schedules( { @Schedule( "daily"), @Schedule( "weekly" ) })), mais au prix de certaines accrobaties dans le compilo. Ce simple changement nécessite en effet de considérer avec soin la compatibilité ascendante. Comme pour les lambda, ce problème est un énorme frein à l'évolution de Java, qui impose de mesurer avec soin les impacts et à privilégier des choix non définitifs (voir cet article). Une nouvelle API est également introduite, sur le modèle de ce qui est disponible dans les annotation processors (compilte-time), mais cette fois au runtime. Cela permettra d'avoir un niveau d'abstraction comparable entre un processor APT et du code runtime qui devait jusqu'ici passer par la réflexion.

Enfin, si de nombreux efforts sont faits pour corriger le tir, c'est un peu dommage de se rendre compte aujourd'hui qu'il peut être utile d'utiliser une même annotation deux fois :-/

La session suivant c'est l'enregistrement de l'épisode 68 des cast-codeurs, en public. Tous les frenchies sont au rendez-vous, ce qui permet de constater que DevoxxFrance ne les a pas fait déserter leur rendez-vous annuel en terre flamande (moi j'ai une excuse, c'est la terre de mes aïeux). Quelques sujets sérieux, d'autres moins, d'autres pas du tout.

José et David se sont emballés sur un point qui mérite en effet qu'on s'y attarde, la "nouvelle" syntaxe des parallel collection, introduites plus ou moins en douce. L'an dernier, quand on nous a présenté les parallel collection, on nous a promis ceci :

for (Foo foo : bar.filter( blah ).map( buzz )) { // je traite des foo }

Java 8 étant trop bien fait, il nous permettait donc de faire du filter/map/reduce sur des collections et de profiter du parallélisme lorsque c'était utile. Sauf qu'au final cela va plutôt ressembler à ça :


for (Foo foo : bar.stream().filter( blah ).map( buzz ).toList() ) { // je traite des foo }

autrement dit, il faudra explicitement demander le mode "parallel collection" et revenir au mode "séquentiel" à la fin du traitement. On arrive ainsi à une syntaxe merdique d'une part, mais surtout à l'absence de filter/map/reduce sur les collections en standard, sauf à s'obliger à utiliser un algo conçu pour traiter des BigData sur du multi-core. Les explications demandé par José aux personnes intéressées ont jusqu'ici été de la forme "c'était compliqué à implémenter". Non-officiel bien sur, mais attention Java 8 sort l'été prochain, aussi si rien n'ai fait les choses seront entérinées sous cette forme et on se les coltinera 15 ans - ou plutôt, on utilisera guava ou autre plutôt que les collections standard ...

Atlassian offrait ensuite des pizzas (attaquer des bières à 10h30 aurait été un peu violent) pour conclure ce très beau Devoxx 2012, et nous avons été quelques-uns à aller faire un dernier repas ensemble avant de prendre le Thalys.

J'espère que ces billets sur Devoxx vous auront donné envie, rendez-vous en 2013 (ne vous y prenez pas trop tard, les places partent vite), et/ou pour Devoxx UK puis Devoxx France !