new Blog( perso );

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 !

Deuxième journée de conférence, et surtout quatrième journée à dormir peu après une soirée mouvementée, j'accuse un peu le coup :)

Les keynote commencent avec l'annonce de JBoss de la "short-list" pour le nouveau nom de JBoss AS. J'ai d'abord cru à une blague mais ce sont bien les propositions retenues. On aura donc peut être droit à un "J-Béret by RedHat" :-/

On passe à la keynote de Google, présentant les nouveaux Nexus 4 et 10, l'intégration Jenkins (by Cloudbees, youpi!) dans AppEngine, et les dernières fonctionnalités "hype" de Chrome, sur fond de talk sur la "vie online" et notre responsabilité de développeurs et d'early-adopters pour mettre en place une vraie sécurité, du genre 2-step verification login, utilisation systématique de https, ... sans perdre de vue l'expérience utilisateur. On conclut rapidement sur l'utilisation d'OpenId et le "one click signup" qui se multiplie sur les sites web.

Je zappe la session suivante pour discutter un peu, avant de rejoindre les London-Jug guys présentant un talk sur les anti-patterns de développement,  sur le mode "gentil et méchant flic", très sympa et pleine d'humour.

Après le casse croute passé au côté de l'équipe CodeStory, je suis une session sur les test en Javascript. Le framework Jasmine y est mis en oeuvre pour modulariser une appli JS en fragments testables unitairement. Pour la partie graphique, après un premier essai utilisation Selenium (12 secondes pour exécuter 3 tests basiques), le speaker présente un runner JavaScript permettant d'exécuter les tests dans la JVM en mode émulation. Très rapide et avec feedback dans l'IDE on a donc un outil performant. Dernière option proposée : utiliser PhantomJS (browser headless basé sur webkit) plus proche de la réalité mais qui est plus délicat à intégrer (maven-exec) - amha un Custom Runner JUnit devrait pouvoir y remédier, si ça tente quelqu'un ;) Une combinaison de ces recettes permet donc de monter un CI Javascript très productif.

J'ai apprécié ce talk car j'avais été interpelé par l'équipe CodeStory qui utilise Mocha et Zombie pour obtenir des tests web rapides et fonctionner efficacement en full TDD. Avec le talks sur Testacular plus tôt cette semaine, je vois que l'écosystème JavaScript est toujours aussi prolifique et de mieux en mieux outillé.

Merci à Arnaud qui me prête un tournevis pour remettre en état mon MacBook qui souffre un peu (trop de bière, petite nature) avant de passer à une façon plus DevOps de gérer l'infrastructure, présentée par Patrick Debois himself. Initiée par CFEngine, puis Puppet et Chef, la catégorie des "Configuration Manager" adresse un besoin de traçabilité/reproductibilité que l'on connait bien dans le développement logiciel et qui s'applique aujourd'hui à l'identique dans le monde des Ops.

Patrick présente en parallèle Chef et Puppet en comparant les concepts avec leur équivalent en programmation java : class <-> definitions, héritage <-> attribut "cookbook", etc. Puppet et Chef se distinguent essentiellement par la culture qui les sous-tends. Le premier propose un DSL volontairement restreint, plutôt contraignant (pas de boucles !) - le second en permettant d'écrire n'importe quoi en Ruby ouvre la porte à des utilisations maladroites et ingérables. Puppet utilise par ailleurs un graphe des tâches à exécuter qui peut être interrogé alors que Chef exécute purement les cookbooks de manière séquentielle, mais ainsi de façon plus prédictible. 

Avec le développement de ces outils d'infrastructure as code, on voit apparaître de l'outillage (Gepetto, RubyMine), règles de codage, patterns et anti-patterns, gestion de dépendances, visualisation, debugging (encore naissant), testing qui nous sont familiers.

La taille relative de mes notes par rapport aux autres talks montrent à quel point ce talk m'a intéressé ;)

Je m'offre un petit moment de calme avant d'aller découvrir les nouveautés de Groovy 2.0 (j'aime bien Groovy, il me permet de coder du Java comme d'hab tout faisant des trucs géniaux lorsque c'est utile). Les AST transformation en particulier me donnent envie de creuser le sujet. Je vous renvoie sur la chaîne Parleys du BreizhJug si vous voulez suivre ce talk en version FR

La journée aurait du se terminer ici, mais après le succès de son quickie, nous avons droit à un "replay" de Chet Haase présentant d'une manière délirante un nouveau process de développement. Un pur moment de délire qui fait du bien, avec un Chet qui arrive a garder un sérieux sans faille dans son costume de consultant d'un jour.

La fin de journée permet de joindre le BOF des JUG-Leaders, occasion annuelle de faire le point sur les relations entre JUGs, avant de rejoindre le NoX pour la Devoxx Party, qui permet de dépenser un peu des calories que la bière belge nous aura fait prendre cette semaine, et aussi de faire connaissance avec la gente féminine à péage qui occupe le night-club.

On attaque le gros morceau avec les journées "conférence"

La matinée est occupeé par les "keynotes" :

Le ton est donné avec une "danse" des robots Nao d'Aldebaran-Robotics. Bluffant !
Stephan Jansenn intervient alors pour accueillir les 1400 participants de la conf, les apostrophant sur ses robots-jouets de luxe qui pourraient être "le comodore 64 de la prochaine génération".
Restant sur le sujet, passe alors un vidéo présentant Devox4Kids, un programme super sympa sur la robotique pour les plus jeunes. S'il y en a que ça tente j'aimerais bien faire ce genre de chose à Rennes, bippez moi.

Suit l'annonce, toujours en vidéo, de DevoxxFrance du 27 au 29 mars, et un passage sur scène de Nicolas, José et Antonio (qui, mal réveillé, s'est trompé de couleur pour le polo DevoxxFrance :P). Suit alors une autre vidéo, extraite des Monthy Python, sur l'affrontement des chevaliers d'Arthur fàce aux français. La vidéo s'arrête sur "j'ai un plan" et l'équipe du LondonJug débarque habillée en chevalier et annonce ...

Devoxx UK les 26 et 27 mars (oui, il y a recouvrement) et invite les speakers à considérer les 2h30 d'Eurostar pour faire d'une pierre deux coups.

On passe ensuite à la keynote Oracle. J'en profite pour aller satisfaire un besoin naturel et consulter mes mails, et je reviens pour la dernière démo JavaFX (certains prétendent qu'il y a eu à Devoxx plus de sujets sur JavaFX que d'utilisateurs :P). A priori je n'ai pas raté grand chose.

Neal Ford présente ensuite "Geek Leak", ou "comment l'esprit geek transpire sur des activités non-informatique. Autant Neal est un super speaker, autant j'ai trouvé son show très moyen, complètement décousu.

Le marathon commence alors avec les Conférences, qui vont s'enchainer toute l'après midi jusqu'à 19h.

Je vais voir la conf sur AppEngine, avec un coup de main à  Ludovic Champenois pour mettre un peu d'huile dans sa démo de l'intégration de DEV@Cloud avec AppEngine. Google Execute Engine, concurrent direct d'Amazon EC2, est une bénédiction pour les dévelopeurs GAE qui doivent faire avec les contraintes de la plateforme. Par contre, ne pas oublier de tuer les instances après la démo sous peine de payer une grosse facture :)

Je fais une pause en allant voir l'équipe de CodeStory en action. Mal placés, ils doivent subir un environnement bruyant qui nuit à la qualité du show, qui est pourtant toujours aussi bluffant. Le public de Devoxx n'était pas aussi préparé que celui de DevoxxFrance, c'est dommage pour eux même si la performance est tout de même appréciée de tout ceux qui viennent "perdre" une heure à les suivre.

Je vais ensuite à une présentation sur Vert.X, qui m'a déçue. Beaucoup de théorie pas super intéressante que j'aurais préféré voir remplacée par des démos. Pendant ce temps, Arnaud suit la conf sur Nao et a bien du mal pour se retenir de faire un gros chèque à Aldébaran-Robotics pour remplacer son Karotz.

Après la pause j'enchaine avec un talk sur Dart, qui manquait un peu de peps mais était tout de même très bien mené, avec beaucoup d'exemples. Je reste TRES perplexe sur les web components, qui permettront à termes de "pluger" de nouvelles balises HTML riches. En l'absence de namespace, l'usage est de préfixer ces tags custom : . Seulement, apparaitront inévitablement des librairies de web composants, et donc des possibles conflits de noms de tags. Pourquoi ne pas avoir repris les namespaces xml ? A priori, c'est juste "trop tôt" pour être un problème :-/

Je zappe la dernière session qui m'inspire modérément pour aller "socializer" sur le stand Google, puis rejoindre les J/GT- User Group leaders qui sont invités par le géant du web pour un meeting dans le pub d'à côté. La soirée se finit inévitablement au Kelly's, lieu de toutes les débauches mais dont je ne dirais rien : "ce qui se passe à Devoxx reste à Devoxx" :D

Pour la seconde journée de Devoxx j'ai suivi le début de la session de John Smart sur l'automatisation des tests d'acceptance et son outil thucydide. J'avoue avoir un peu décroché, le début de la session étant un peu "lent" à mon gout, aussi je vous renvoie sur Parleys pour vous en faire une meilleure opinion :) J'ai donc profité de la pause pour rejoindre le hackergarten, occupé en force par l'équipe JBoss. Ce format est vraiment super intéressant, permettant aux technical lead d'inspirer de nouveaux contributeurs et d'interagir directement avec leur communauté, et aux participants d'avoir des réponses de premier choix à toutes leurs questions techniques, plus la fierté de contribuer efficacement à leur projet préféré.

L'après midi, je me dépêche de rejoindre avec 20 minutes d'avance le lab Angular.JS qui promet d'avoir un grand succès, et je me retrouve au fond en bout de table. La salle est comble, le lab est un succès énorme. Pendant 2h30 nous développons donc pas à pas une application en partant d'un design html statique, ce qui permet d'introduire progressivement les concepts d'Angular ainsi que l'outillage associé. Vous pouvez d'ailleurs rejouer le lab chez vous. Super framework, qui me réconcilie avec JavaScript, j'en profite d'ailleurs pour découvrir l'excellent support de JavaScript et d'Angular dans Intellij Idea.
Un framework que vous découvrirez au BreizhJug en 2013 :-)

A nouveau la journée "university" se termine par des Tools in Action. J'en profite pour découvrir Testacular, outil de CI javascript développé par Google. Le talk manquait clairement de préparation et a été un semi-bide mais l'outil reste extrêmement intéressant. Les 15 minutes "utiles" que j'ai pu tirer de cette session m'ont donné une très bonne impression sur le potentiel de l'outil, pour sortir du mode "je code, je refesh mon browser" et passer à du vrai TDD en javascript.

On enchaine avec le "Maven Dependency Puzzler", qui nous expose quelques POM maven avec des cas de dépendances bien merdiques et la gestion de conflit parfois "non-intuitive" de Maven. Les trois premier gagnant une bière je commence la soirée très fort et j'enchaine ensuite sur le stand Oracle où la tireuse coule à flot, avant de rejoindre les frenchies au resto asiatique du coin qui sera content de ne pas nous revoir avant l'an prochain ;)

rendez-vous demain :D

C'est donc reparti pour 5 jours à Devoxx, La conférence java à ne pas manquer.

Premier jour, je suis l'université "Scala" pour en savoir un peu plus sur ce langage qui est autant défendu bec et ongles par ses fans que décriée par ses détracteurs. Pendant 2h30, les constructions de base du langage sont présentées en expliquant comment le compilateur interprète la syntaxe et la transcrit en invocations de méthodes. Pédagogiquement parlant, le talk est un régal. J'adore l'approche qui consiste à d'abord montrer un concept avec une approche très procédurale, puis à refactorer pour donner plus de "fonctionnel" et introduire les simplification de syntaxe, pour aboutir à du "beau" code scala, et dans les exemples qui suivent à toujours rappeler l'opération inverse, par exemple que "2 + 3" est interprété par le compilo comme "(2).+(3)" - évidemment, hors contexte ça fait un peu zarbi :)

Session intéressante qui donne (presque) envie de s'y mettre :D

Pendant l'après midi j'ai suivi la session "from syncrhonized() to parallel()" de Jausé Paumard. Après des rappels présentés avec précision sur le multi-threading et le pourquoi du "le double check ne fonctionne pas", José nous montre comment les librairies low-level utilisent des hacks pour contourner les problèmes de synchronisation du cache L1 (padding de la ligne de cache). On passe ensuite au niveau framework avec les SMT et le framework Akka, et enfin à l'évolution de Java avec le fork-join de Java 7 et les parallel collections de Java 8. J'ai adoré la conclusion du talk : après avoir vu pendant 2 heures les technos de paralélisation, José nous expose les conclusions d'un concours sur du calcul de suite de Fibonacci. Le record absolu est obtenu avec un algo séquentiel sur mono-coeur, en optimisant les éléments de bas niveau et l'algorithmique. Rien ne sert d'avoir 128 coeurs avec un algo pourri, et tous les algorithmes ne se paralélisent pas bien, nous sommes donc au début d'une nouvelle aire de l'algorithmique où nous allons devoir (ré)inventer des algorithmes pour tirer partie d'une informatique toujours plus distribuée.

La journée continue avec les Tools in Action, dont celui de Julien Viet sur CRaSH, le shell de votre JVM, que j'aimerais bien intégrer dans un plugin Jenkins pour faire du deboggage de builds - une idée pour le hackergarten du mardi ?

Fin de journée autour de quelques bières à échanger nos souvenirs de vieux geeks, mais bon, il faut être sage on est que lundi ...

Ce billet est plus un mémo pour moi-même afin de ne pas chercher à chaque fois comment effectuer une conversion svn -> Git. (billet fortement inspiré de http://john.albin.net/git/convert-subversion-to-git)

Le but ici n'est pas "juste" de migrer vers git mais de maintenir un lien entre les deux repositories, autrement dit de créer un miroir git du repo subversion.

1. lister les committers

Il peut être nécessaire de faire un peu de ménage dans le fichier généré

2. faire un clone git du repo svn

L'an dernier, à la même période, je bloggais un appel à volontaire pour m'aider à organiser le breizhcamp.

J'ai porté quasiment seul la première édition de cette conférence, profitant d'une période charnière dans ma vie professionelle qui me laissait pas mal de temps libre - comprenez, ma démission d'Orange. L'exercice est enrichissant et très formateur, mais particulièrement éprouvant. Disons qu'il faut avoir les reins solides pour prolonger ce mode de fonctionnement.




Pour la seconde édition, j'ai voulu m'entourer de lieutenants, chacun se chargeant d'un "silo" et me soulageant de ce poids. Avantage pour moi : garder le contrôle dans le role du "dictateur". Inconvénient, lorsqu'un lieutenant ne peut pas assurer pour diverses raisons, je suis seul apte à venir jouer les pompiers, ayant une vision globale de l'organisation. Au final, entre les contraintes de chacun, je me suis retrouvé à gérer bien plus de choses que prévu. Par ailleurs, difficile de motiver les gens si on ne leur laisse pas voix au chapitre.