13 décembre 2013

Rendez-vous à Devoxx France

Devoxx France a ouvert son Call for Paper début décembre, et se pose pour moi la question de quoi proposer.

L'an dernier j'ai mis tout ce que j'avais en magasin, au risque de passer pour un spam-bot. J'ai constaté que les sujets "cloud" ou "continuous delivery" qui me sont chers ne font pas rêver le comité de sélection - ou alors je ne suis pas bon vendeur.

Bref, suivant une suggestion de Nico Martignole, je lance un Google Moderator :

Quel sujet voudriez-vous me voir présenter à Devoxx 2014

A vous de jouer !

19 novembre 2013

être speaker à Devoxx

Devoxx a toujours été pour moi LA conférence. Les locaux inégalables, l'ambiance bon-enfant, la diversité et la fréquentation en font un événement sans équivalent.

J'ai présenté ma conférence "Cloud Patterns" pour la première fois à Mix-IT, ce qui m'a permis d'en caller la durée. J'ai pu l'expérimenter en version EN_fr à GeeCon, la re-jouer à SoftShake et CodeurEnSeine et en peaufiner les détails. J'ai eu le temps de me faire à Keynote pour agrémenter mes slides d'effets graphiques sympas. Bref, c'est un talk rodé.

J'ai été retenu à JavaOne. Très franchement, après l'expérience GeeCon je n'étais pas spécialement stressé de faire ce talk devant le public américain. JavaOne c'est beaucoup de monde mais surtout beaucoup de petites salles. Et comme j'étais prévu en dernier slot la question était plutôt de savoir si je serais tout seul dans la salle...

Et il y a eu Devoxx.

Mon talk a été retenu, et c'est une grande fierté. Et malgré le rodage préalable, faire cette conf à Devoxx a suscité un trac important. Je ne saurais pas dire précisément ce que cette conférence à de si particulier, mais elle est clairement à part.

D'une part, il n'y a pas de "speaker room" et c'est volontaire : les organisateurs désirent que les speakers se mélangent à la foule et soient accessibles. De grandes tables permettent aux geeks en tout genre de bosser/hacker entre deux sessions, beaucoup de speakers en profitent et sont ainsi disponibles pour des questions complémentaires. Bref, un speaker à Devoxx est un Devoxian comme les autres

Il n'y a pas de "petite salle". Si on met de côté les deux salles des BOFs, les immenses salles de cinéma du Métropolis accueillent de 400 à 800 personnes. Evidemment on est pas sur qu'elles soient pleines, mais ça fait un effet non négligeable sur le speaker tout seul en bas.

Il ya les copains. Devoxx c'est à 2h de Paris et les Français y sont nombreux. On en repère un ou deux dans la salle malgré les projecteurs en plein tronche et ça aide bien moralement.

Il y a Stephan et toute l'équipe Devoxx, ultra disponibles à toute heure. Stephan a eu la gentillesse de venir me dire un mot juste avant mon talk - en fait deux : "bonne chance" et "évite les photos compromettantes". J'ai presque tenu compte de ses conseils.

Bref, être à Devoxx comme speaker, c'est quelque chose de spécial. C'est à la fois se sentir comme à la maison et dans la plus prestigieuse conférence de l'univers. De quoi se sentir à l'aise pour donner son maximum.






09 novembre 2013

on est pourtant pas vendredi 13

J'enchaine les coups de stress ces temps ci

la semaine dernière, en plein pendant un week-end dans la famille, mon Galaxy S3 me fait le coup de la "mort subite". J'ai retiré 25 fois la batterie, épluché les forums ... en vain.


Bon, allez, y'a pas mort d'homme, et en plus voilà un prétexte tout trouvé pour commander le Nexus 5.

Lundi, allez hop soyons fou je migre mon MacBook sous Maverick. "upgrade gratuit" de la part d'Apple, j'aurais de me méfier. Aucun changement notable.

petite parenthèse : j'essaye "plan" vite fait, dont j'ai entendu tant de mal, et la photo aérienne de mon chez-moi est plus à jour et de bien meilleure qualité que google maps. Donc pour un gars qui vit dans sa campagne comme moi c'est plutôt positif ;)




Après l'ugrade, mon code d'accès à https (je bosse sur le plugin git jenkins) se met à planter - j'apprends qu'il faut réinstaller le java 6 Apple.

Bon, allez, y'a pas mort d'homme, c'est pas méchant ça m'a "juste" fait perdre une journée de taf, c'est pas comme si j'était grave à la bourre juste avant Devoxx.

Sinon R.A.S, ça reste un OSX quasiment tout pareil - ça m'aurait fait mal de payer un upgrade pour ça - jusqu'à ce que je décide de rebooter (quand git n'arrive plus à résoudre "github.com", c'est pas bon), après tout un reboot une fois par semestre ça peut pas faire de mal.

Et là, gros coup de stress : mot de passe refusé.



Donc chez Apple, ils ont décidé que maintenant, le clavier au démarrage serait en QWERTY, voilà comme ça. Il y a une icône à peine visible pour l'indiquer. C'est pas comme si l'avantage concurrentiel d'apple c'est de maitriser le hardware, donc on pourrait s'attendre à ce que l'OS sache quel variante du clavier est intégrée au MacBook. 

Bon, allez, y'a pas mort d'homme, j'ai juste appris quelques injures à mes gamins et pris 2 points de tension, en plus ça me rappelle de faire une sauvegarde time-machine.

quelques heures après, juste le temps de se détendre un peu (sic) je reçois un coup de fil sur mon nexus 5 tout neuf - un appel automatique du monitoring CloudBees - je raccroche, et j'ai un écran noir. Le téléphone ne répond plus à aucune touche (moralité, il ne faut pas répondre aux appels d'alerte du monitoring).

Panique à bord, avec un ++ vu que je n'ai même pas encore annoncé à Madame que j'ai acheté ce nouveau jouet. Twitter est ton amis et j'apprend donc à utiliser le power + volume bas (10 secondes) pour un reboot forcé.



A ce stade le week-end ne fait que commencer, mais j'ai mon compte. Je dois encore finir de préparer mes slides pour Devoxx, j'espère qu'on va en rester là.


Bon, allez, y'a pas mort d'homme. 

Mais vous savez à quelle point un Geek est dépendant de son attirail high-tech...






31 octobre 2013

Git sucks

Titre tapageur - serais-je un peu provocateur ?


Non, je ne vais pas faire l'apologie de Clearcase, je suis très content de Git en tant que développeur et je n'ai absolument pas l'intention de changer, même pour un autre DVCS.

Par contre, je suis mainteneur du plugin Git pour jenkins. J'ai hérité de ce plugin sans trop savoir comment, au départ en backportant des correctifs utilisés par CloudBees puis rapidement faute d'une mainteneur en place. Et j'ai rapidement compris pourquoi : ce plugin est un amalgame de pull-requests en tout genre.

Le problème de la pull-request, c'est


  1. quand on crée un patch, et donc une pull-request, on essaie de faire minimaliste. On ne fait pas un gros refactoring juste pour la beauté du geste. On va donc ajouter un "if (foo) { ... } else" dans le code existant. 25 pull requests plus tard la méthode fait 400 lignes et est incompréhensible.
  2. si c'est un mécanisme de revue de code formidable, en opensource la pull-request a ce désagréable effet de bord de permettre à un contributeur de "balancer" du code par dessus le mur, sans s'impliquer forcément dans le projet. D'où l'absence de continuté sur ce plugin.

Bon, ça c'est l'historique, qui n'aide pas, mais pas le coeur du problème.

L'un des principaux objectifs pour la version 2.0 du plugin Git était d'introduire le support de l'authentification via le plugin credentials.

L'option 1, c'était JGit. Il y a quelques temps le plugin Subversion est passé à svnkit plutôt que de piloter le client svn pour des raisons comparables. JGit prométait de faire de même. Sauf que JGit est encore loin du niveau de maturité nécessaire pour être utilisé dans le plugin jenkins. J'ai rapidement découvert la ... créativité des développeurs dans leur usage de Git, et le manque de documentation de JGit, ainsi que l'absence de fonctionnalités pourtant pas mineures. Quand je pense que les utilisateurs d'Eclipse se basent dessus j'ai un peu peur...

JGit reste donc une option expérimentale, et ça risque d'être le cas encore un bon moment.


L'option 2, c'était de conserver le pilotage de la ligne de commande git. Plusieurs problèmes majeurs, et c'est ce qui me fait dire que "Git - i.e., le client git en ligne de commande - sucks"

  1. le client git n'a pas de mode non-interactif. Il peut donc bloquer en demandant à l'utilisateur son username, ce qui bloque jenkins par la même occasion. Je ne connais pas d'outil en ligne de commande qui n'ai pas une option "batch", "quiet" ou "force", bref un truc prévu justement pour ce genre de cas de figure où il n'y a PAS d'utilisateur en face de la console.
  2. le client git ne fournit AUCUN moyen de passer les paramètres d'authentification. En http il se base éventuellement sur .netrc (un fichier prévu pour ftp soit dit en passant), et en ssh il se base sur le client ssh et vous laisse dans la m... StackOverflow regorge de hacks divers pour contourner ces problèmes, et même la doc officielle s'en lave les mains et vous dit de bricoler un script shell. 
To pass options to the program that you want to list in GIT_SSH you will need to wrap the program and options into a shell script, then set GIT_SSH to refer to the shell script.


Ce qui, bien évidement, ne fonctionne que sur un système Unix-like (JENKINS-20356)


Je cherche toujours l'option 3. Il n'existe à ma connaissance pas d'autre client Git que je pourrais utiliser depuis du code Java (des suggestions ?).


Update:
Certains sont surpris. Après tout JGit est utilisé par EGit, mais aussi Gerrit, ou GitBlit; alors quoi, peut être que le plugin jenkins est juste codé avec les pieds - ce qui n'est pas faux mais bon je m'égare.
Je viens d'apprendre que le plugin git maven lui aussi souffre des limitations de JGit. Entre autre des file leaks sous windows, problème rapporté par de nombreux utilisateurs de git-plugin. 

De mon côté je lorgne sur libgit2, qui permettrait d'utiliser un client git natif. Mais évidemment il n'existe pas de binding Java :'(



18 octobre 2013

Configuration Management JSR

I recently discovered project to start a JSR for Configuration Management. Mike Keith introduced this project at JavaOne, you can download slides for his presentation here. I wasn't aware so didn't attend the live talk, but reviewing the slides I have few comments.

Proposal (afaik)

Scope for such a JSR is difficult to establish. If you want to embrace the existing tools, there is overlap with generic platform provisioning. I don't think this is a good idea to consider this until there's a reasonable consensus on application-level configuration management. Looks like this is also the diagnostic for this JSR.

The current state for JavaEE configuration is "JNDI" : if you need to inject some resources / parameter to an application, you have to provide some container-specific xml file in your WAR archive. This suppose Ops will unzip the WAR, edit xml to put production resource binding and credentials, then re-archive and deploy using container-specific commands. Nobody never did this. So this is a great idea to review this and provide something to better match actual practices and tools.

Also have to consider the DevOps impact on development/deployment practices.

Contract for configuration management is also complex to establish. Reviewing slides, the proposal seems to be to package application configuration in a CAR (configuration archive).


I think this is a very bad idea. For the same reason Ops don't unzip WAR to edit xml files, they won't do this to create CAR files. Ops tools and practices are based on scriptable solutions from system shell. I don't think we will see JavaEE apps packaged as RPM/DEB system packages, at least because Java is supposed to "run everywhere", not just on Linux distros. But a configuration management JSR must primarily focus on Ops practices, not on JavaEE developers. JSR use to define Java based API, I think this specific JSR must NOT use Java as primary language. My main concern with a java-based approach is that this will result in a new java.util.prefs.Preferences nobody is using.


My vision

I'd prefer the JSR to define a REST API application container (or platform as a service) have to expose to allow defining the configuration for an application. REST is neutral, well supported both from Java tooling and base script shell (using curl).

So, you can imagine a REST endpoint on your application server that let you define an "application" (unique ID) and bind server resources / configuration parameters to this application. Application server is responsible to implement actual persistence.

Deploying an application would then be :


  1. create the application with unique ID
  2. set application configuration 
    • resource bindings (JDBC DataSource, JavaMail session, JMS queues, etc)
    • simple parameters
    • structured parameters (? - see later)
  3. deploy WAR/EAR for application ID


Application configuration has to be persistent : it will survive application restart and redeployment, as long as application unique ID is unchanged. It's also idempotent: binding same resource twice don't result in a duplicated resource. This is a requirement for infrastructure automation tools (like Chef/Puppet) to work in this context.

Without any surprise, you probably notice how this proposal mimic CloudBees configuration management. We also support cloudbees-web.xml and some of us like it, but I consider this legacy. Using SDK to bind a Database to my application, whatever application server I'm using - Tomcat, JBoss, Glassfish, Jetty - and getting it injected as a JNDI DataSource is awesome.


How does application access configuration ?

Based on slides, JSR proposal defines a new API for application code to access configuration. So, you'll have to wait for all frameworks to be updated to benefit this API :-/

To workaround design issue for JavaEE to miss a configuration API, most framework rely on placeholders, the common denominator being support for system properties. I never have seen a JavaEE application to use String declared in JNDI, but I not a bunch of apps to get runtime settings from system properties. For adoption of a configuration management JSR, and immediate support on most frameworks, system properties must be considered as first-class citizens in configuration land.

Injecting a simple parameter in an application should result in getting the equivalent system property set. With system properties, you already can manage a bunch of use-cases. I'm not sure there's actual need for structured parameters. This could be addressed by JAXB / JSONB data binding anyway.

Conclusion

I'd be very happy to contribute this JSR. I've been looking for an "incubator" page for it but can't find this on jcp.org. I'm not sure then how expert group is established, but if I can join I'd be very happy to compare my point of view with others and help as much as possible to make this JSR a useful one.


29 septembre 2013

private, public, hybrid

Après mon talk "Cloud Patterns"et comme presque à chaque fois j'ai eu droit à des réactions étonnées sur ma position (ie. celle de CloudBees) sur l'approche "Private Cloud". Explications:

photo credit: Cici D



disclaimer: Je Bosse chez CloudBees. Je partage l'analyse de ma société, cependant libre à vous de considérer que je suis biaisé dans ma perception des choses.

1. Cloud != DataCenter

Première confusion, de nombreuses sociétés parlent de "Cloud Privé" pour le DataCenter dans lequel elles sont en train de mettre en place de la virtualisation. Soyons clair, je définit un "Cloud" comme :

  • ressources (quasi) illimitées, disponibles à la demande - ce qui ne veut pas dire sans quotas ni restrictions,
  • accès direct par API, sans passage par la case "formulaire bleu à envoyer à l'admin signé par le CdP",
  • mutualisation des ressources et facturation à l'usage,
  • délégation complète de la maintenance et du support.

De ce point de vue, nombreux sont les projets de "Cloud privé" qui sont en fait des migrations d'une IT basée sur du hardware dédié vers des solutions de type IaaS à la main. Je n'insisterais pas, mais lorsque je parle de Cloud je parle clairement de Plateforme as a Service.

le "Cloud" vu par de nombreuses sociétés en pleine mutation


Le dernier point, "délégation complète de la maintenance et du support", cher à CloudBees comme à Google AppEngine, est ce qui nous différencie de CloudFoundry et OpenShift. Nous considérons qu'il est la clé du concept même de Cloud, au delà de la virtualisation complète des ressources.

Mettre en place votre infra OpenStack est passionnant pour l'ingénierie, mais couteux en termes de formation des équipes de maintenance (voir ce témoignage). OpenStack ou autre est loin, très loin d'être une solution triviale, et s'assurer que l'hyperviseur est compatible et sera maintenu sur votre infra physique est une gageure. C'est d'ailleurs un nouveau marché pour les HP et autres Dell, de proposer du hardware labellisé pour ces usages.

La force d'amazon EC2 est justement le contrôle complet du hardware sur lequel tourne l'IaaS. La standardisation est la clé de la réduction de coût à grande échelle. Elle permet de monter rapidement de nouveaux services ou de blinder ceux qui existent, là ou des solutions ouvertes, malgré leur qualités indiscutables, s'imposent un gigantesque effort de suivi.

un exemple de standardisation : le hardware des datacenter Facebook

2. Private != Service

Installer la solution "private" de CloudPoireaux sur votre infra, c'est installer un soft; c'est du Platform-as-a-Software. C'est disposer d'une équipe infra à la hauteur. Nous avons l'habitude chez CloudBees de demander "produisez-vous votre propre électricité ?". Il y a un siècle, c'était le cas dans pas mal de grosses entreprises, avant que les tensions et la distribution se standardise et que la production ce concentre dans des usines spécialisées. L'informatique vit la même évolution. L'OS standard est un Linux sur architecture x86. L'étape qui suit est la concentration.

On évoque souvent des contraintes de sécurité. Ne croyez pas que CloudBees n'ait comme client que des start-ups, et que les banques et assurances nous boudent. 

La sécurité est un problème technique parfaitement géré. Le lancement d'Amazon Virtual Private Cloud est un signe: les clients d'Amazon sont de grosses, voir très grosses entités, qui déportent partiellement leur infra sur EC2. VPC leur assure une isolation techniquement sans appel.

amazon VPC : un bout de cloud dans votre réseau privé


Il reste ensuite le problème politique pour la direction IT de lâcher son emprise sur l'infra et évoluer vers un métier de niveau supérieur - le Cloud ne vous privant pas de boulot, avec d'intéressants challenges d'intégration de services. Problème de transformation interne que je vous laisse traiter :D

L'argument clé que nous avons chez CloudBees pour nos clients sceptiques c'est la mobilité. Certains de nos clients développent ainsi des applications mobiles pour leurs équipes sur le terrain. De fait, les données transitent déjà sur le réseau public. Le problème de la sécurité a donc forcément déjà été traité, reste à l'appliquer de manière plus globale. Amusant aussi de voire que ces mêmes entreprises ont leurs données client, données hautement stratégiques s'il en est, hébergées sur SalesForce, sans parler du commercial Microsoft qui se prépare à leur vendre du Office 365. De la politique donc.

3. Public Cloud + Private data = Hybrid 

L'hybridation private/public est une piste très prometteuse. En effet, le réel frein à la migration d'une société vers le Cloud est son coeur de métier, sa base d'information Oracle / SAP hébergée en interne et souvent volumineuse. Ces données ne migreront pas vers le Cloud, car cela impacterait trop d'applications legacy et le transfert de données auxquelles le SI accède en continu est délicat. 

Migrer un tel existant est à la fois techniquement et politiquement complexe. Inutile de commencer pas le plus difficile lorsqu'il existe des solutions simples et fiables de contournement.

L'hybridation entre des applications sur Cloud public, bénéficiant d'une plateforme standardisée, supportée, et élastique, couplée aux données privées via VPC/VPN, permet de mettre en place des solutions très élégantes avec un cycle de développement extrêmement court. 


un zorse (zébrule en bon français), hybride zèbre/jument à l'élégance rare :P

CloudBees propose depuis 2011 une solution hybride inverse, à savoir installer la base technique CloudBees sur votre IaaS privé (VMWare, OpenStack) tout en conservant le pilotage depuis le Cloud public cloudbees.com. Cette approche "AnyCloud" n'a pas révolutionné la donne à ce jour, entre autre parce qu'elle impose de disposer d'une équipe IaaS privée qui réduit sensiblement les bénéfices du Cloud, et qu'il manque alors à vos applications tout l'écosystème de service qui, eux, restent sur Amazon.

un zonkey (zébrâne), autre hybride sympathique



N'hésitez pas à me toper à l'occasion d'une conférence si vous voulez en discuter :)



18 septembre 2013

Write a Book

J'ai écrit deux bouquins (enfin trois, ça dépend comment on compte)

Le premier, Apache Maven pour Pearson, a été mon premier pas dans le monde de l'édition. J'ai découvert le template word imposé par l'éditeur, le long travail de marquage du texte pour générer l'index. Bref, la rédaction n'est qu'une petite partie du travail au final. Nous (Arnaud et moi, co-auteurs) travaillions avec un partage Dropbox, ce qui a permis d'aller assez vite dans la mise au point du contenu. Le travail a été très supérieur à ce que j'estimais, aussi - au vue du gain financier - il est clair qu'on fait ce genre d'exercice pour la gloire, pas pour la fortune.

Nous n'avions qu'un seul interlocuteur, ça c'est donc suffisamment bien passé pour que nous plongions une seconde fois. Cette seconde édition a eu lieu pendant un jeu de chaise musicales chez Pearson et donc un manque de suivi assez désastreux. Bref, la seconde édition est sortie sans aucune intention de faire un v3 - encore faudrait-il qu'il y ai de quoi d'ailleurs vu le contenu des nouveautés de Maven 3.1, mais c'est un autre débat.

Je me suis lancé dans un autre livre, plus court et en Anglais, pour Packt. Il s'agit d'un livre sur CloudBees, guide du développeur, donc en plein dans mon sujet. Packt ne m'épargne pas le template maison, bien pire que celui déjà lourd de Pearson. J'en pleure encore. Je suis secondé d'un relecteur non technique chargé de valider mon english pas très fluent et de corriger la mise en forme. Il a tenté de m'expliquer 10 fois les règles fort intéressantes de formatage des textes, mais j'ai autre chose à faire donc je lui ai laissé le plaisir de le faire pour moi - après tout, lui est salarié de Packt, moi je fais ça sur le temps libre que j'arrive à trouver.

La revue des chapitres est sensée se faire par échange de mails. Bienvenu en 2013. J'ai pu imposer un dropbox, surtout que les relecteurs techniques sont sans surprise mes collègues de CloudBees. Ca limite les dégâts, mais au final je passe quelques heures à approuver des changements de style dans le doc.


Accessoirement, Packt impose un planning ultra serré, un chapitre par semaine, je suis donc à 8 semaines de dépassement :P Ils m'ont aussi envoyé de nombreux formulaires word pour indiquer mes coordonnées, ma bio, mes références, et dernièrement un document "très urgent" visant à fournir au marketing des phrases type pour faire la promo du livre. Super, après avoir fait le boulot de la PAO, voilà que je dois faire celui du marketing. A ce rythme ils vont me demander de livrer les bouquins moi-même.

Bref, je ne suis pas prêt de replonger, et je vous déconseille l'expérience si vous êtes tenté de faire connaitre votre projet open-source ou de mettre en avant votre expertise. Pour le gains financier ridicule par rapport au travail, préférez une doc en markdown ou n'importe quel autre format léger, avec un bon script d'export PDF et auto-publiez-vous. Un exemple parfait amha est le livre Pro Git, hébergé sur GitHub  ce qui n'a pas empêché APress de le publier.

08 août 2013

Deux plugins pour le prix d'un

J'ai enfin trouvé le temps de publier la première release du plugin Jenkins "build graph view". Ce plugin permet de visualiser de manière graphique les builds impliqués par un build initial. La mise en place d'un workflow complexe sur Jenkins implique en effet souvent de distribuer le travail dans plusieurs jobs, liés les uns aux autre par des relations "upstream-downstream" orchestrées par une série de plugins.

Le plugin build-pipeline existe déjà sur ce créneau et est très populaire, mais se limite à des exécutions statiques, comprenez que les jobs impliqués sont toujours les mêmes à chaque exécution.
Dans de nombreux cas, cet ordre peut évoluer, certains jobs étant lancés de manière conditionnelle, et on peut aboutir à des chemins d'exécution complètement différents. Build Graph View plugin aborde donc le problème en proposant un graphe dédié à chaque exécution :
Ce n'est "qu'une" 1.0, ce qui signifie que de nombreux liens entre builds ne sont pas supportés à ce stade (plugin join, copy-artifact, promoted builds...). Cependant elle couvre déjà pas mal de cas, et le plugin est facilement extensible, contributions are welcome ;)


Le code de ce plugin est issue d'un autre de mes plugin, le build-flow. Ayant enfin pu finaliser l'extraction dans un plugin dédié, en ajouté les bouts de code qui assurent la complémentarité entre ces deux plugins, j'enchaine avec la release 0.10 de celui-ci. Build Flow va dans le même sens, en constatant que définir un workflow complexe dans Jenkins est bien compliqué, à base de plugins en tout genre pour gérer le passage de paramètres, l'exécution concurrente, etc. L'orchestration des jobs est donc confiée à un DSL, chargé de lancer les jobs. On a ainsi une séparation entre les tâches élémentaires et le wrokflow de plus haut niveau, sans que ce dernier soit dispatché un peu partout et difficile à gérer.

Rien de fondamentalement nouveau dans cette release, désolé pour ceux qui espéraient de grand changements, et surtout pour ceux qui espéraient que cette version soit une 1.0, car on en est pas là ... Ce qui manque au build flow ?

  • Un sandboxing du DSL groovy. En effet, les droits "RUN_SCRIPT" (administrateur) sont nécessaire pour éditer le DSL, sans quoi un utilisateur standard pourrait accéder aux API Jenkins et à la JVM sans contrôle ... ce qui rend le plugin assez inutilisable dans un contexte d'entreprise avec un Jenkins mutualisé. A part un SecurityManager bien trempé je ne vois pas de solution viable pour le moment
    =>  JENKINS-16980.

  • L'exécution asynchrone du DSL. Actuellement, le DSL est lancé comme un simple script, et de ce fait ne peut être interrompu ou relancé. Groovy ne propose pas de "Continuations" qui permettraient de capturer la call-stack pour la relance plus tard. La piste que j'envisage pour le moment est de rendre le script "rejouable" à volonté, les étapes déjà exécutées se transformant alors en NOP. Autre solution pas triviale, utiliser les AST Transformation pour convertir le script impératif dans un format CPS ... Si vous avez la super solution idée du siècle, je suis preneur.
    => JENKINS-19118

24 juillet 2013

BreizhJUG Coding Challenge

Les plages de sable fin, le soleil étincelant, la mer turquoise ... quoi de plus banal après tout, et l'ennui risque vite de vous submerger cette été. Heureusement, il y a le grand concours de développement du BreizhJug !

Fort des 9h de conférences consacrées au web html5 / javascript que vous avez toutes suivies pendant le dernier BreizhCamp, il ne vous manque qu'un prétexte pour vous y mettre ? C'est le moment !


Le site www.breizhjug.org est une misère, aussi nous avons comme ambition d'en faire un nouveau, tout beau tout moderne tout chouette, et nous allons faire appel à vos talents.

Notre github propose un squelette d'application angularJS, ainsi qu'une liste de fonctionnalités à développer. Nous n'attendons plus que vos pull-requests ! Chaque item peut rapporter un certain nombre de points (indiqués dans le tracker). A noter que certains items sont indispensables pour démarrer quoi que ce soit, et donnent donc droit à un bonus pour vous encourager ;)

Qu'est ce qu'on gagne ?
  • notre reconnaissance !
  • une bonne bière à l'anniversaire du JUG pour le gagant
  • les noms de chaque contributeur sur le site, par ordre de mérite

Si vous voulez participer, ou simplement en discuter et/ou proposer de nouvelles fonctionnalités, rejoignez le google group du BreizhJUG




29 juin 2013

BreizhCamp 2013

Le BreizhCamp 2013 a été un événement magnifique, et je remercie chaleureusement l'équipe qui m'a accompagnée dans ce challenge et a relevé tous les défis, par ordre psuedo-aléatoire :

Nicolas LedezLaurent HuetGuillaume Collic, Yan BonnelSébastien BrousseMichel DavidHoracio GonzalezSylvain GuernionAlex ThomazoJulien Coste

ansi que Quang Hung et Jean-François Garreau qui nous ont accompagnés côté sponsors.

Le questionnaire que nous avons diffusé donne des résultats intéressants sur vos attentes :
Premier point, cette troisième édition vous a plu. C'est déjà un très bon point, mais nous ne sommes pas encore au 100% de satisfaction, aussi nous allons chercher à faire encore mieux.



Les nombreuses sessions "hands-on" de la première journée on été appréciées, et d'après vos retours il n'en faut pas nécessairement plus - ou en tout cas être rigoureux sur la sélection pour ne proposer que des sujets bien préparés.



La diversité des sujets a été appréciée, même si elle est encore améliorable. Sans surprise, le call for paper nous a amené essentiellement des sujets Java et HTML5/JavaScript, aucun sujet PHP, un seul sur Python, pas grand chose dans le monde Microsoft. Il faut que nous travaillions avec les communautés pour attirer ces speakers et démontrer l'intérêt de voir "ce qui se fait ailleurs".

... car vous jouez le jeu de sortir de votre zone de confort pour aller voir ce qui se passe dans le pré d'à côté, et c'est le but de la conférence donc j'en suis ravi.


Votre réaction fàce aux quelques sujets hardware est intéressante. Une moitié à globalement apprécié sans plus, un quart sont enthousiastes, l'autre quart n'en voient pas l'intérêt. Il y a donc clairement deux populations ici, une qui aime les talks où l'informatique rencontre le monde physique - dans 10 à 20 ans, le moindre objet sera connecté et communiquant - et une qui est sans doute plus pragmatique sur ses pratiques professionnelle et ne vois pas d'intérêt dans une raspberry pi autre que le côté gadget - je fais des applis de gestion, alors un minitel je ne vois pas bien l'intérêt.


Nos sponsors cette année ont été très présents, et leur implication pour animer la conférence a été appréciée. Tant mieux, car ils ne sont pas que nos financiers dans cette aventure, ils sont nos partenaires et il est important qu'ils prennent part à l'événement et que les participants y trouvent leur compte.



Notre buffet a été apprécié pour sa qualité, mais les quantités on posé problème. Avec les quickies sur la pause déjeuner, et l'enthousiasme des premiers arrivés à gouter à tout, certains on du se contenter d'un repas léger. Il est clair que nous corrigerons le tir sur les prochaines éditions.


L'absence de WiFi pour les participants, lié aux contraintes du campus universitaire, est de plus en plus contraignante pour vous. Malgré plusieurs mois de préparation, les solutions de replis mises en place dans deux salles pendant les hands-on n'ont couvert qu'une partie du besoin. Par ailleurs, nous devrons à l'avenir être vigilant pour les propositions de Hands-on, en insistant auprès de nos speakers pour expliciter les pré-requis dans la présentation de leur talk et toujours prévoir un "plan B" en cas de défaillance de l'infrastructure.

Enfin, 50% d'entre vous est prêt à revenir de manière inconditionnelle, 90% une fois le programme publié, voici des chiffres qui nous font honneur. 50% font d'ailleurs déjà du lobbying actif pour motiver leur collègues - si par la même occasion vous pensez pouvoir transmettre notre dossier de sponsoring 2014 contactez-nous - et si on considère que vous connaissez presque tous une personne qui n'a pas pu participer il semble évident que nous devons augmenter notre capacité d'accueil.



Quand à vos nombreuses suggestions ... laissez nous un peu de temps pour les éplucher :P

Merci en tout cas pour tous vos messages d'encouragement, et rendez-vous après l'été pour la rentrée du BreizhJUG, et l'inauguration du GDG-Rennes !


11 mai 2013

Scala, 7 semaines plus tard

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


29 avril 2013

Mix IT

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

Bonne adresse

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


18 avril 2013

Call for Paper ...

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 :


def selection( format: String, talks: List[talk] ) : List[talk] = 
        check(talks). // relecture des propositions
        sort( talk => talk.note ). // tri par note
        filter( talk => agree )


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


14 avril 2013

1, 2, 3, scala

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)
}

il paraît que c'est plus "fonctionnel", que ça ne brise pas la logique, ... bon on a enlevé un return pour mettre un else, perso je ne vois pas en quoi c'est plus élégant. J'ai eu le même genre de débat en java sur le return qui devait être unique dans une méthode, quitte à imbriquer des if en pagaille ... débat sans fin. Je sens que ce billet va avoir quelques commentaires :) Bon ça aussi on s'y fait vite

Slooooooow
Scala, c'est aussi une machine à genoux. Pour lancer le premier tutorial "hello world", j'ai du définir quelques -XX dans mon JAVA_OPTS sous peine de OutOfMemoryException. Désolé, je n'ai qu'un MacBook Air 2Gb - mon MacBook est en réparation

La réputation de scala de ce côté semble fondée. Idem pour ses lenteurs de compilation : plusieurs longues secondes à attendre pour compiler les 3 classes de l'exercise, je n'ose pas imaginer un projet de grande ampleur. Je suis surtout étonné que le compilo puisse être lent à ce point. Je n'ai jamais écrit de compilateur, donc je suis mal placé pour me prononcer, mais sur une syntaxe tout de même assez simple et déterministe que peut bien foutre le compilateur à mouliner pendant tout ce temps ? (-> quelques éléments de réponse) A part celui de GWT, je ne vois pas pire...

Ou alors, c'est que scalac est écrit lui-même en scala (attention, #troll inside). Car si la programmation fonctionnelle est une façon intéressante de structurer un programme, avec une approche orthogonale à la programmation impérative, j'ai de grosses interrogations lorsque j'écris un algo sur les performances finales. Immutabilité oblige, mes graphes de données vont être répliqués de nombreuses fois, créant miriades d'objets en mémoire. Ca a de nombreux avantages en termes de structure du code, de logique, de concurrence, mais avec un tel niveau d'abstraction que je ne sais fichtrement pas dire si ce que j'ai écrit à une chance d'être performant - déjà que je ne suis pas forcément sur de pouvoir garantir que mes récursions convergent ...

L'outil de build sbt est aussi ... "étonnant", il va falloir que je creuse un peu : les projets d'exemple ont tous un répertoire "project" plein de scripts scala. A priori ce sont des "plugins" sbt. Sauf que si on doit les copier coller dans chaque projet, ce ne sont pas des "plugins" au sens maven/eclispe, partagé et réutilisables, mais des "copié-collés" ... ou au mieux des git-submodules comme on le fait avec les cookbooks puppet. A creuser
update : je suis rassuré, il y a de "vrais" plugins SBT, les exos de coursera ont juste fait "au plus vite" sur ce point. C'est un peu dommage, ça suggère de mauvaises pratiques du coup

J'attends la suite
Bref, je n'en suis qu'à la semaine 3, avec encore pas mal de boulot, et (j'espère) le temps de continuer parce que c'est vraiment trop bien fait et très intéressant. Je reste cependant encore sceptique. Je vois mal Scala être largement adopté par les développeurs lambda.

D'une part, et vous en avez certainement autour de vous, certains développeurs ont décidé de mettre leur cerveau à la retraite lorsqu'ils ont obtenu leur diplôme d'ingénieur. Ceux là ne pourront pas faire de scala, trop besoin de réfléchir.

De l'autre côté, vous avez les enthousiastes qui - eux au contraire - sont content de pouvoir enfin se servir de leurs neurones, plutôt que d'écrire 200 lignes de code pour valider un formulaire.

Ces deux populations on les connaissait déjà (avec toute une palette intermédiaire) mais je trouve qu'un langage comme scala exacerbe ces différences. Dans un contexte de start-up avec des équipes réduites et triées sur le volet ça a du sens (cloudbees a pas mal de code scala pour faire tourner la boutique, cause première de mon inscription sur coursera). Dans un contexte de SSII (pardon ESN), projet au forfait, "resources" pas cher et offshore, j'ai plus de mal à imaginer ce que ça peut donner.

Conclusion
Je suis content d'avoir l'occasion de découvrir un langage fonctionnel, qui apporte une vision nouvelle et me sera certainement profitable, au moins pour bien utiliser les lambdas en Java 8 (9?). J'attends avec impatience la suite des cours. Je souhaite à scala que quelqu'un se penche activement sur son compilateur et son outil de build, pour qu'il ne laissent pas au newbies come moi une sensation étrange de "wtf ?". 500M de mémoire et 5 secondes pour un hello world ? Même ruby fait mieux

(L'avez vous remarqué, quelques trolls se sont glissés dans ce billet. Si vous les trouvez tous, vous pouvez gagner une place au BreizhCamp)



01 avril 2013

Après BE, FR, UK voici Devoxx BZH


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

26 février 2013

Codenvy, l'IDE dans le Cloud

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.



25 février 2013

CodeStory & CodeCast

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


CodeCast, "le podcast avec du code dedans"


Code-Cast, c'est un podcast vidéo que je vais tenter de faire vivre au fil des événements ou des speakers qui voudront bien se prêter au jeu. L'idée est de filmer une interview, ou un événement techo-geek, et de faire au passage une capture vidéo des écrans pour pouvoir collecter au passage des démos, morceau de code, etc. Il est en effet beaucoup plus simple d'expliquer ce qu'est la syntaxe d'Erlang avec quelques exemples qu'en faisant de grand gestes devant un micro :P

Pour vous donner une idée du ton, voici donc : "CodeStory, il n'est restera qu'un"