Duchess France
A Duchess Community Blog for France

Le 22 novembre, le Lyon JUG propose une soirée autour des architectures Stateful et Stateless. Deux équipes vont donc s’affronter sur le ring du Lyon JUG. Du côté Stateful, Antoine Sabot-Durand nous fera une présentation intitulée “Stateful is Beautiful”, revenant aux sources de Java EE (CDI, EJB 3…), le tout articulé autour d’une démo! Et du côté Stateless, on retrouvera Philippe Charrière et Loïc Descotte, tous les deux co-auteurs de l’ebook Play.Rules qui nous parleront donc des concepts des architectures Stateless à travers une démo basée sur Play Framework!. Pour vous mettre l’eau à la bouche, voici un interview des speakers : les mêmes questions ont été posées à chaque équipe (à part la dernière), et elles n’ont évidemment pas eu accès aux réponses de l’équipe adverse avant la diffusion de cet interview.

Antoine Sabot-Durand est consultant et architecte Java EE chez Ippon Technologies. Il intervient sur toute sorte de missions : conceptions d’architecture applicative, audits d’applications existantes, formations. Il est également en charge de la capitalisation des savoir faire au sein de la société. Il a acquis une expertise sur Java EE et plus particulièrement sur EJB 3.X et CDI. Il est l’auteur de quelques articles ayant alimenté le débat sur les standards et les choix technologiques sur les développements Java comme “Les rendez-vous manqués de Spring” ou plus récemment une suite d’article sur Java EE 6. Il est également membre de l’Expert Group CDI 1.1 et technical Leader sur le module Seam Social du projet Open Source Seam 3. Vous pouvez suivre Antoine sur Twitter ou Google+.

Philippe Charrière s’est présenté lui-même comme suit : “Je suis “avant-vendeur” à Lyon chez Steria. Avant d’être “ingénieur informaticien” j’ai commencé à coder sur une TI57 (beaucoup ne doivent pas savoir ce que c’est, normal j’ai 42 ans (ça c’est geek)) et depuis la passion du code ne m’a plus quitté. J’ai fait différents métiers en passant par technico-commercial, développeur cobol, responsable informatique, chef de projet, architecte .Net (désolé), directeur de projet, responsable technique, avant-vendeur… et ce n’est certainement pas fini. Mais je n’ai jamais lâché “le code”, plutôt multi-techno, ça m’aide à faire des propositions commerciales qui tiennent la route et à la livrer avec des prototypes quand je peux. @Home, c’est Javascript, Coffeescript, Play!Framework, et tout ce qui touche au mobile (grosse passion pour les jouets Apple, mais bidouille aussi Android)”. Vous pouvez consulter le blog de Philippe ou le suivre sur Twitter ou Google+.

Loïc Descotte s’est également présenté lui-même : “JUG Leader à Grenoble (Alpes JUG) et développeur chez Kelkoo. Ce que j’aime particulièrement dans le métier/hobby de développeur c’est l’évolution permanente des technologies qui permet de découvrir sans cesse de nouvelles choses. Dès que j’ai un peu de temps j’essaie de parler un peu des frameworks que je teste sur mon blog CoffeeBean. J’ai découvert Play début 2010 grâce à une présentation de Guillaume Bort. J’ai tout de suite été séduit par la puissance, la simplicité de ce framework, qui contrairement a pas mal de ses concurrents côté Java (Wicket, JSF…) ne cherche pas à masquer les principes et le fonctionnement du Web.” Vous pouvez également le suivre sur Twitter ou Google+.

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG. Merci également à Cyril Lacôte de l’équipe du podcast Cast-IT pour son aide sur la relecture de cet interview.

Agnès & Cédric : Pour introduire un peu les concepts d’une architecture avec ou sans état, comment définiriez-vous ce qu’est un état ?

Loïc (Equipe Stateless): Dans une application il existe (presque) toujours un état. Lorsqu’on parle d’architecture sans état il s’agit souvent d’un raccourci pour dire qu’il n’y a pas d’état au niveau middleware (sur le serveur d’application par exemple). Dans ce contexte, l’état est un ensemble de données relatives à une session utilisateur à un instant t. Ces données peuvent comprendre les informations relatives à l’authentification et aux droits de l’utilisateur, un historique des actions effectuées durant cette session (sélection de paramètres d’affichage, sélection de produits sur un site marchand…)

Philippe (Equipe Stateless): Globalement, je dis “comme Loic”. plus spécifiquement, j’aurais tendance à “déshumaniser” le concept et à rattacher l’état à une page plutôt qu’à l’utilisateur, voire même de manière plus abstraite à une ressource (ex: client lourd à la place de la page). Et cet état existe côté client et côté serveur, pas forcément en même temps selon si l’on est en stateful ou en stateless :

• en stateful : la page/client a un état, dont la représentation/(persistance ?) côté serveur est une session en mémoire quasiment au même moment
• en stateless : la page/client a un état, dont la représentaion côté serveur est finalement très furtive puisqu’elle peut n’exister qu’au moment où l’on interroge le serveur.

Antoine (Equipe Stateful): Un état est une information temporaire gérée au sein d’une application pour un utilisateur donné ou l’application dans sa globalité. Cette information permet de conserver de manière transitoire des données concernant l’utilisation actuelle de l’application ou un statut d’avancement dans un processus donné de celle-ci.

Agnès & Cédric : Imaginez que vous atterrissiez sur une île déserte et que vous n’ayez la possibilité d’emmener avec vous qu’un seul framework Java de référence pour coder une application, lequel choisiriez-vous ?

Loïc (Equipe Stateless): Si on part du principe qu’il n’y a pas d’électricité sur une ile déserte, il va falloir faire le maximum de chose avec le temps de batterie qu’il nous restera sur notre laptop… Il nous faut donc un framework productif… ensuite je pense que vous vous doutez de la réponse

Philippe (Equipe Stateless): perso, je préférerais partir avec un manuel de construction navale et une canne à pêche. Sinon je partirais avec SL4A sur android + moteur beanshell parce que j’aurais plus de batterie sur mon smartphone que Loic sur son netbook. (Bon, ok, je prendrais Play! aussi parce que je peux utiliser TextMate et que ça consomme moins de ressource)

Antoine (Equipe Stateful): Pour coder : Java EE 6, parce que c’est la solution permettant le plus de choix d’architecture : Stateful ou Stateless, webapp ou client lourd. Sinon la bibliographie Spring est plus volumineuse et avantageuse si on souhaite faire des feux de camp!

Agnès & Cédric : Selon votre approche préférée (stateful/stateless), comment “suivre” et contrôler l’activité d’un client sur mon site? En prenant le fameux exemple d’un client faisant une commande sur un site marchand: comment puis-je lier entre elles les requêtes HTTP d’un même client? Comment je persiste son panier?

Loïc (Equipe Stateless): Si on prend l’exemple de Play, pour lier les requêtes HTTP d’un même client on dispose d’un objet d’accès à la session d’un utilisateur dans les contrôleurs. Cet objet est initialisé à l’aide un cookie sur le navigateur. Ce cookie est signé et crypté pour des raisons de sécurité. Si on veut stocker le contenu d’un panier dans la session utilisateur, on a plusieurs possibilités. La solution la plus pratique et qui sera bientôt la solution la plus standard est d’utiliser les API de stockage côté navigateur fournies par HTML5.

Philippe (Equipe Stateless): Facile! Comme Loïc. Bon je détaille un peu. Pour lier et persister : localstorage (donc il faut faire du js) est une super solution, facile à mettre en oeuvre. Beaucoup l’associe à HTML5, mais en fait la notion de localstorage existait avant, et il existe différents types de localstorage : SQLite, local storage (key-value), DOM Storage, user-data (anciennes versions de navigateurs). Pour plus d’infos : voir cet article “5 Obscure Facts About HTML5 LocalStorage“. Pour les navigateurs plus vétustes, il y a aussi la possibilité d’utiliser les fonctionnalités de storage de flash, il est très facile de discuter en js avec actionscript (et inversement). Pour les inquiets du JS, il existe de très bonnes librairies qui encapsulent et abstraient tout ça, une des plus connues est lawnchair.js de Brian Leroux (de chez Nitobi / Adobe / Phonegap) et qui fournit tous les adapters nécessaires en fonction des navigateurs. Un des plug-ins lawnchair fait du clé-valeur avec la base SQLite embarquée qui est plus rapide que la version clé-valeur de base (ça s’utilise par contre de manière asynchrone avec des callbacks). C’est aussi intéressant de se coder la sienne au moins pour comprendre les concepts.

Antoine (Equipe Stateful): [Pour lier les requêtes HTTP :] en les stockant dans un contexte session ou mieux conversation. Pas de persistance explicite. Le panier reste en mémoire, il sera sérialisé en cas de besoin (charge importante). Si j’attends une durée de vie plus importante, je peux mettre un listener à la fin de la session pour le stocker explicitement.

Agnès & Cédric : Comment je contrôle la conversation web de mon client : comment gérer par exemple le bouton back du navigateur?

Loïc (Equipe Stateless): Le problème du bouton back du navigateur se pose beaucoup moins avec un serveur stateless. Le principe d’architecture stateless est fortement lié à celui d’architecture RESTful : avec des URL bien définies, n’importe quelle étape de la navigation doit être bookmarkable. Si on revient sur une de ces étapes, le fait d’avoir un serveur stateless fera qu’on ne risque aucune incohérence d’état sur le serveur : la page s’affichera toujours correctement quel que soit le contexte. Si vous avez déjà utilisé des frameworks comme JSF vous savez que ce n’est pas toujours le cas quand vous devez tenir compte de l’état du serveur.

Philippe (Equipe Stateless): Pour le bouton back, cela peut se gérer côté client : toujours avec le localstorage, une solution peut être aussi de faire une application ‘monopage’ (webapp) et de jouer aussi avec les api de gestion de l’historique du navigateur , des hashtags (window.onhashchange), …

Antoine (Equipe Stateful): Plusieurs stratégies en fonction du contexte :

• Stocker l’état des vues précédentes pour gérer le back
• Demander à JSF de générer des URL Rest avec prettyface
• interdire au navigateur de cacher une page pour forcer son rafraîchissement
• gérer correctement les erreurs d’incohérence entre l’état serveur et l’état client
• Faire mon rendu en ajax : le bouton back me fera sortir de l’application

Agnès & Cédric : Est-ce possible de gérer plusieurs espaces de travail pour le client, à savoir plusieurs conversations avec la même application dans différents onglets de son navigateur?

Loïc (Equipe Stateless) : Je ne suis pas du tout expert sur cette question, le cookie de session étant partagé entre les différents onglet (du moins sous Firefox et Chrome), en principe on ne peut pas avoir plusieurs sessions en même temps avec ce procédé. Après avec Play tout est possible, on peut très bien se contenter de créer une session côté client, encore une fois avec local storage, et associer une session à une instance de page à l’aide de JavaScript.

Philippe (Equipe Stateless): avec le module Secure de base de Play, ça va pas le faire (perso j’utilise différents navigateurs, ou mode incognito) pour les raisons expliquées par Loic. Quelles solutions ? -> faire sa propre solution d’authentification et passer des infos dans la requête (bof) -> faire avec -> quand tu es connecté sous google tu ne peux l’être qu’avec un seul user -> on perd en souplesse, on gagne en sécurité.

Loic (Equipe Stateless): En dernier recours il existe aussi des plugins pour les navigateurs qui permettent d’avoir des sessions distinctes dans différents onglets via une manipulation des cookies (voir exemple).

Philippe (Equipe Stateless): pour l’aspect “plusieurs espaces de travail” : le localstorage peut prendre plusieurs formes :

• accessible par l’ensemble des onglets du navigateur (ou par plusieurs instances du navigateurs), bon ok dans le cas de 2 navigateurs de marques différentes, faudra faire plus classique (on parle de localstorage)
• accessible uniquement sur la page en cours et uniquement pendant la session (on parle de sessionstorage)

Antoine (Equipe Stateful): Yep, CDI contient un scope conversation permettant de faire ça. Apache CODI l’étend en permettant de gérer des sous conversations (mise en pause d’une conversation, lancement d’une autre)

Agnès & Cédric : Puis-je définir facilement un workflow obligeant mon client à enchaîner plusieurs écrans pour une conversation donnée (le paiement par exemple)?

Loïc (Equipe Stateless): Pour gérer un workflow de navigation, il y a tout ce qu’il faut aujourd’hui dans les librairies côté client pour faire ça. On peut enregistrer les différentes étapes et y revenir avec l’history API HTML5 par exemple.

Antoine (Equipe Stateful): Concernant le worklfow, actuellement il existe à ma connaissance trois solutions stateful gérant ce besoin :

• Spring Webflow mais bon c’est spring
• Seam 2 pageflow mais pas compatible CDI
• Oracle ADF task flow qui sera standardisé dans JSF 2.2 (sortie été 2012)

Si tout ça ne convient pas, on peut déjà faire deux ou trois trucs avec le fichier de navigation JSF, mais ce n’est pas vraiment une machine à état.

Agnès & Cédric : Comment sont classiquement démarquées vos transactions (base de données) au sein de vos applications? Quelle est dans la majeure partie des cas la durée de vie de la transaction ?

Loïc (Equipe Stateless): La durée de vie de la transaction est liée à celle du cycle de la requête HTTP : si une erreur survient lors du traitement d’une requête, tout ce qui s’est passé entre la demande du client et l’envoi de la réponse est annulé (rollback). C’est un moyen de rendre atomique chaque traitement lié à une requête. Il n’y a pas besoin d’utiliser un pattern du type open session in view, avec ce procédé on accède à nos objets (et mêmes aux éléments à charger en “lazy”) durant tout le traitement de la requête, quelle que soit la couche dans laquelle on se trouve.

Philippe (Equipe Stateless): ben je crois que Loïc a répondu à la question!

Antoine (Equipe Stateful): Par défaut la durée de vie d’une transaction est liée à la requête HTTP. L’utilisation de l’extended persistence context permet de retarder la transaction après plusieurs écrans (un wizard).

Agnès & Cédric : Comment une architecture (avec/sans) état, répond elle aux problématiques de scalabilité, et de reprise sur activité en cas de panne ?

Philippe (Equipe Stateless): Pas d’état conversationnel : le serveur ne conserve aucune information entre 2 requêtes différentes d’un même client, du coup la 1ère requête pourrait être traitée par un serveur A, la 2ème par un serveur B, etc. … Mon “identité” existe côté client uniquement, donc on pourrait même imaginer que le serveur soit coupé entre les 2 requêtes.
-> côté serveur : pas de mémoire utilisée pour les sessions -> pas de problème de synchronisation de sessions entre plusieurs serveurs.

Loïc (Equipe Stateless): Il est plus simple d’assurer la scalabilité avec une architecture sans état : rien n’est partagé entre les serveurs. Si on veut ajouter un serveur derrière notre loadbalancer pour monter en charge on évite ainsi tout le paramétrage lié aux sessions que l’on trouve avec les architectures stateful : mise en place d’un cache de session distribué, duplication de sessions ou encore affinité des utilisateurs à un seul serveur… Pour gérer les pannes c’est également plus simple, si on coupe un serveur, l’utilisateur pourra continuer sur un autre serveur sans qu’on ait à se demander comment il va récupérer l’état qu’il avait stocké sur le premier serveur.

Antoine (Equipe Stateful): En stateful, la scalabilité c’est le cluster, mais c’est un sujet très vaste et souvent regardé que du point de vue du serveur d’application et pas de la base de données. La tolérance de panne est également assurée par le cluster bien que l’architecture de l’application soit primordiale pour limiter la perte d’information lors du basculement. Le sujet de la résilience des applications est également vaste.

Agnès & Cédric pour l’équipe “Stateless” : commençons par une question naïve : Quelle est la bonne pratique pour gérer la sécurité de l’application ? Où est stocké l’état si nécessaire ? Purement en base de données, purement côté client ?

Philippe (Equipe Stateless): Différentes solutions, oauth (f… je ne sais pas le prononcer) openid, … Play est fourni avec une “basic authentication”, il suffit de passer en mode SSL pour “renforcer” la mécanique. On peut aussi utiliser une “digest authentication” dans ce cas là, il faut se faire sa propre mécanique ou utiliser openid.

Loïc (Equipe Stateless): L’état doit être stocké sur le client, cette information doit être de taille minimale (loggé ou pas + rôle de l’utilisateur). C’est ce qui se passe lorsque vous êtes loggés sur GMail par exemple. Ceci n’empêche pas le mécanisme d’authentification d’être robuste (ex : oAuth, https…). Pour rappel le cookie de session est signé et crypté.

Agnès & Cédric pour l’équipe “Stateful” : Est-ce simple de tester une webapp stateful ?
Antoine (Equipe Stateful): Aujourd’hui oui grâce à JBoss Arquillian. J’en ferais une démo lors de ma prez

Merci Antoine, Loïc et Philippe!

Les inscriptions pour leur session au Lyon JUG le 22 novembre sont ouvertes! Rendez-vous sur le site du Lyon JUG.

Le Paris Jug organise mardi prochain (08/11) une soirée « Petites Librairies Java ». Comme d’habitude, les Duchess organisent l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.

Le Lyon JUG accueille le 18 octobre prochain Sacha Labourey pour un talk intitulé “Développement dans le cloud”. Sacha est CEO et fondateur de CloudBees, une plate-forme Java pour le Cloud qui couvre l’ensemble du cycle de vie d’une application : de son développement à sa mise en production. Elle permet notamment le stockage de code, d’artefacts Maven, l’exécution de builds et de tests basés sur Jenkins ainsi que le déploiement d’applications en production, le tout de manière intégrée.
Agnès Crépet et Alexis Hassler, tous deux membres de la team du Lyon JUG ont posé quelques questions à Sacha, pour vous mettre l’eau à la bouche avant sa session à Lyon !

Quand on demande à Sacha de se présenter voici ce qu’il nous répond : “Je suis né en 1975 à Neuchâtel, en Suisse. Après un bac socio-économique j’ai rejoint les rangs de l’École Polytechnique Fédérale de Lausanne où j’ai effectué un master en informatique. Durant mes études, j’ai créé ma première boîte, Cogito Informatique. J’avais pour but d’entrer dans le monde du travail mais également … de payer mes études ! Après mes études, j’ai continué à faire du consulting dans le middleware puis me suis focalisé en 2001 sur l’aventure JBoss. D’abord en tant que développeur du clustering, puis en devenant GM Europe de JBoss, et finalement CTO en 2005. Après l’acquisition de JBoss par RedHat, je suis devenu co-GM de la division middleware chez RedHat, société que j’ai quitté en avril 2009. Après quelques mois de repos pas du tout reposants, j’ai commencé à réfléchir à ce qui deviendra plus tard CloudBees, qui a été formellement démarré le 1er avril 2010. Je vis toujours à Neuchâtel et travaille avec une équipe répartie sur 6 pays et 3 continents, ce qui rend donc la question géographique très relative.”
Nous vous invitons pour découvrir un peu plus Sacha à aller visiter son blog, fort intéressant (avec beaucoup d’articles sur le cloud, vous l’aurez deviné !)

Agnès & Alexis: Quelle est la cible des clients de CloudBees ? S’agit-il d’entreprises de tailles moyennes ou de plus grande envergure, de sociétés de services, d’éditeurs, d’entreprise déjà sensibles à l’open source ?

Sacha: Nous avons des clients de taille très différente, notre solution n’est pas spécifique à certains types de sociétés. Néanmoins, étant donné que notre offre est uniquement disponible dans le cloud public aujourd’hui, il est évident que les projets n’ayant pas besoin d’accéder à des ressources se trouvant sur un réseau protégé (bases de données, mainframes, etc.) sont clairement avantagés, ce qui est statistiquement plus le cas pour les petites structures ou, dans un domaine particulier, les sociétés développant des applications pour mobiles par exemple.

Agnès & Alexis: Est-ce que CloudBees peut vraiment être concurrentiel sur son offre RUN@Cloud, vu la taille des autres concurrents PAAS (GAE, Amazon Beanstalk) ? Comment RUN@Cloud se démarque de ces mastodontes, mais également d’autres comme Cloud Foundry?

Sacha: Ces grosses sociétés ont évidemment l’avantage en terme de ressources et, du moins pour VMware et RedHat, elles disposent d’un accès privilégié aux développeurs Java. Néanmoins, ces sociétés ont également les inconvénients de leurs avantages : elles sont lourdes, innovent moins vite, sont moins focalisées sur les besoins des développeurs (et plus sur ceux des CIO), etc. Par ailleurs, ces sociétés disposent de revenus importants en entreprise et bien qu’il leur est relativement simple de proposer une offre dans le cloud qui soit gratuite et en béta – donc non concurrentielle – il leur est très difficile de transformer leur modèle économique en un modèle de type cloud: les modèles de ventes sont très différents, l’organisation interne doit être différente, il y a un fort désir de protéger les revenus existants, etc. Ceci représente l’un de leurs plus gros challenges. Il m’arrive régulièrement d’en discuter avec les vendeurs de ces sociétés: le modèle cloud représente un vrai danger pour elles.

Agnès & Alexis: Je pense que l’intégration continue (IC) se prête complètement à une offre cloud : à certains moments de la journée, on peut avoir besoin d’un grand nombre de ressources de calcul, mais à d’autres moments on ne les utilise pas du tout. Votre offre Dev@Cloud peut être donc très appropriée pour les équipes de développement qui veulent faire de l’IC sans être en charge de la maintenance de l’environnement, et en ayant surtout à disposition un environnement toujours performant et stable. Je pense que les meilleurs clients de Dev@Cloud sont donc les développeurs eux-mêmes (j’ai tant rêvé moi-même à des environnement d’IC stables et disponibles !). Le problème que l’on rencontre souvent quand on présente ce type de solution à nos décideurs ou aux personnes de la production, c’est la problématique de l’hébergement du code dans le cloud qui leur fait peur… Comment peux-tu m’aider à convaincre mes décideurs si je suis à court d’arguments ?

Sacha: Il est toujours intéressant d’observer que ces mêmes décideurs n’ont généralement pas trop de problèmes à mettre dans le cloud (sur salesforce.com) l’ensemble de leur pipeline de vente, la liste de leurs prospects, les produits qui les intéressent, etc. Les ventes et le marketing seraient donc des données moins critiques que du logiciel ? Je suis intimement convaincu du contraire, à quelques rares exceptions près.
Par ailleurs, il y a ce sentiment de sécurité quand les données sont hébergées en interne: on peut voir la machine qui héberge les données, on connaît personnellement la personne qui s’en occupe, c’est rassurant. Hors, ces éléments sont justement ceux qui rendent une telle solution moins fiable à mon avis. Ainsi, la majorité des intrusions informatiques en entreprise sont liées à du “social hacking” (téléphonez à un employé en vous faisant passer pour l’IT et demandez-lui son mot de passe, etc.)
Je pense que les sociétés qui ont objectivement analysé la sécurité de leur propre installation, et non pas uniquement effectué une comparaison entre la sécurité estimée du cloud par rapport à une sécurité théorique maximale telle qu’on la trouve dans les livres, sont généralement beaucoup plus ouverts au cloud public. Par ailleurs, les sociétés du cloud, bien que pas infaillibles, sont extrêmement sensibles à ces problèmes, elles savent quelles pourraient être les conséquences d’une intrusion ou de pertes de données.
Beaucoup de travail reste bien évidemment à faire de la part des sociétés actives dans le cloud afin de rendre cette infrastructure publique encore plus sûre. Notamment, un grand travail de transparence, de communication et d’éducation est nécessaire.

Agnès & Alexis: Une solution Cloud peut être très bien appropriée également pour les tests de performances. Je n’ai à priori pas besoin en continu d’une plateforme pour de tels tests, je n’en aurais besoin par exemple qu’en fin d’itérations de développement. Et pour une entreprise le fait de disposer d’un tel environnement, à l’image de celui de la production, de le maintenir, coûte très cher. Quelles solutions propose CloudBees sur cette problématique des tests de performances et sur quelle stack technique (outils de tests de performance pour la montée en charge, le monitoring, la persistance des métriques?)

Sacha: Pour le monitoring, nous proposons NewRelic à l’heure actuelle. Quand aux tests de performances eux-mêmes, nous sommes actuellement en discussion avec un certain nombre de partenaires afin de proposer cette offre, de la même manière que nous proposons aujourd’hui une offre de test de UI avec saucelabs.com.

Agnès & Alexis: CloudBees propose sa propre version “entreprise” de Jenkins, du nom de Nectar. Quelles sont les fonctionnalités proposées en plus par rapport à Jenkins ? Du point de vue stratégique, pourquoi en avoir fait une offre propriétaire ? Quel rapport entre les cycles des releases des deux projets ?

Sacha: La différence tient en plusieurs points:

• Nectar est releasé tous les 6 mois et le passage d’une version à la suivante est testé et simplifié, ce qui intéresse fortement les entreprises qui n’arrivent pas à suivre avec les releases hebdomadaires actuelles.
• Nous testons un certain nombre de plugins FOSS types avec Nectar, afin que nos clients soient assurés que la migration vers une nouvelle version de Nectar ne leur posera pas de problème. La compatibilité plugin-core est régulièrement un problème pour les entreprises.
• Nous offrons un ensemble de plugins propriétaires qui intéressent particulièrement les entreprises, t.q. l’intégration avec VMware, le contrôle d’accès par rôles, etc.

A noter qu’un certain nombre de clients désirent conserver leur Jenkins pré-déployé actuel tout en profitant de ces plugins additionnels : ceci sera possible dès notre prochaine release de Nectar, dans quelques semaines.

Agnès & Alexis: [Cloud privé/Cloud public] Est-ce que le cloud public est économiquement viable ? Est-ce que ce ne serait pas pour beaucoup d’entreprise un moyen d’évaluer l’approche cloud avant d’acheter une solution cloud privé ?
Penses-tu que le cloud privé soit pérenne ? Ne serait-ce pas une période de transition avant le cloud public généralisé ?

Sacha: Peu de sociétés évaluent complètement le coût de leur hébergement actuel : superficie des locaux, travaux techniques, climatisation, électricité, personnel, matériel, logiciels, maintenance, etc. Quand le calcul est bien fait, je pense que le cloud public est d’ores et déjà plus concurrentiel qu’un hébergement privé pour bon nombre de sociétés et la différence ne va faire que s’accroître avec la compétition sur ce marché, les marges réduites, etc. Resteront ensuite les sociétés avec des besoins massifs et génériques de puissance de calcul i.e. des déploiements identiques sur des centaines de nœuds. Ceux-ci pourraient rester privés, mais ce sont des cas spécifiques.
Quand au cloud privé, et non pas uniquement de la virtualisation, celui-ci est encore très difficile à maîtriser en interne. J’ai notamment rencontré des banques qui effectuaient des déploiements privés de stacks IaaS: ceci était loin d’être simple pour arriver à en faire une vraie infrastructure “self-service” qui soit stable, déterministe, etc. Ces déploiements nécessitent des ingénieurs IT à la pointe du progrès. Hors ceux-ci ne sont rentables (notamment en mode 24/7) que pour des déploiements massifs.
Il ne faut pas oublier que le cloud public représente un risque fort pour bon nombre de professionnels de l’IT. Ceux-ci n’ont évidemment pas grand intérêt à accélérer l’adoption de clouds publics par leur entreprise. Qui veut noyer son chien, l’accuse de la rage

Agnès & Alexis: Est-ce que le cloud Paas Java est limité aux conteneurs Web, comme Tomcat ou Jetty ? Est-ce qu’un javaee@cloud est envisageable ? Si oui, quand pourrait-on en profiter chez CloudBees. Est-ce que le support Java EE Web Profile puis le support full Java EE sont envisagés (si oui sur quels serveurs ?) ? (question posée avant l’annonce officielle!)

Sacha: Le support de JavaEE6-WP est désormais disponible. Nous ne pensons pas fournir le support du profil complet mais nous ajouterons probablement un certain nombre de services additionnels (t.q. JMS) à l’offre actuelle. Pour le runtime du support JavaEE WP : JBoss 7 pour l’heure, mais ceci pourrait changer dans le futur. Nous essayons tant que possible de ne pas exposer l’implémentation du container – l’utilisateur ne devrait pas avoir à s’en soucier.

Merci Sacha!

Les inscriptions pour la session de Sacha au Lyon JUG le 18 octobre sont ouvertes !

Devoxx, c’est LA conférence européenne Java en Europe ! Elle a lieu du 14 au 18 novembre avec un panels assez large au niveau des sujets (java, perfs, android, nosql …), à chaque fois par des speakers reconnus !

Nous sommes déjà plusieurs duchess à y aller chaque année, c’est d’ailleurs là que tout à commencer ! Et nous proposons à l’une d’entre vous de nous y accompagner en vous offrant un pass conférence du 16 au 18 novembre !

Pour participer, rien de plus simple, inscrivez vous (uniquement votre mail) sur https://docs.google.com/spreadsheet/viewform?formkey=dE1fa1FObkstQ2RSZXFMRURHcm1DUUE6MQ , on tirera au sort samedi! Si vous hésitez, sachez que ça vaut largement le coup, c’est vraiment un bon moyen de se former sur des aspects divers de notre taff.

–EDIT : Félicitation à Marianne Julien qui a gagné la place et qui nous accompagnera a Devoxx !

Quelques liens :
Description des duchesses de Devoxx
Le site officiel

Pourquoi participer au Jug Summer Camp ? Parce que les conférences sont gratuites, en français, animées par des gens passionnés et dans ce cadre magnifique qu’est le vieux port de La Rochelle.
Arrivée la veille et après quelques tweets de diffusés nous nous retrouvâmes dans un restaurant pour dîner. C’est dans une ambiance très conviviale que nous faisons connaissance ou retrouvons des fidèles du Paris JUG, l’équipe du Bordeaux JUG et du ToulouseJUG, des enseignants et d’autres nouveaux juggers … Et pendant ce temps, c’est en bons élèves que les speakers réunis au gîte finalisent leur présentation.
Puis retour pour un repos mérité à l’hôtel en attendant LA grosse journée.

Le lendemain …

Après un petit déjeuner rapide, direction les salles de conférences pour toute la journée ! Et elle commence fort avec une keynote très vivante d’Antonio Goncalves retraçant toute l’histoire de l’information. Puis les conférences se succèdent et nouveauté cette année, une application mobile nous permet d’organiser notre journée. Parmi les conférences que nous (Isabelle et moi) avons vu :

• Java 7 par Julien Ponge : en plus de présenter les nouveautés qu’apportent le langage, il a aussi présenté les points de vigilance et les limites de ces nouveautés.
• Inspection Continue par Olivier Gaudin : qui nous a présenté les 7 pêchés capitaux du développeur et fournit plein de conseils de bon sens.
• Live Coding de David (Zucker-)Gageot : une bluffante séance de coding dojo pour développer un Kitten-Facemash (le début d’une success-story française ?).
• Weld-OSGi par Mathieu Ancelin : qui nous a fait une belle démo de réservation d’hôtel avec arrêt et redémarrage de modules.
• Optimisation pour Web Mobile par Romain Maton : une présentation riche en recommandations pour optimiser ses applications web pour tout support.

La journée est déjà finie …

Et pour clôturer cette magnifique journée, une keynote de fermeture réalisée par Nicolas Martignole sur l’avenir de notre métier de développeur. Une projection 10 ans en avant, à voir absolument en vidéo ! Le bilan de cette journée : 170 participants heureux et des présentations vraiment accessibles à tous mais malheureusement, personne n’a pu se dédoubler pour voir toutes les sessions . Heureusement, les vidéos seront bientôt disponibles sur Parleys ! Et nous vous tiendrons informés !

Maintenant c’est le week end !

Après un dîner entre juggers, nous avons tout le week end pour profiter de cette magnifique ville qu’est la Rochelle. Petit tour en bateau pour visiter les îles environnantes, dégustation de glace, découverte de l’aquarium et promenade sur le port, malgré de la pluie par intermittence, le week end fut excellent

Un GRAND MERCI à l’équipe du Jug Summer Camp

L’équipe des Duchess tenait à remercier encore une fois toute l’équipe pour l’organisation, l’accueil et cette bonne ambiance qui nous a été offert dès notre arrivée. Je leur souhaite bonne continuation et à l’année prochaine !

Quelques liens

Si vous avez raté la conférence, vous pouvez vous rattraper avec les excellents retours qui suivent :

Sur le blog de Claude Falguière : http://cfalguiere.wordpress.com/2011/09/17/le-jug-summer-camp-cest-fini-pour-cette-annee/
Une série d’articles sur le Touilleur Express :

• http://www.touilleur-express.fr/2011/09/21/de-retour-du-jug-summer-camp-2/
• http://www.touilleur-express.fr/2011/09/21/jug-summer-camp-2-alexis-mp-oracle-ange-ou-demon/
• http://www.touilleur-express.fr/2011/09/21/jug-summer-camp-2-mfiguiere/

Le retour de Nicolas De Loof : http://blog.loof.fr/2011/09/jugsummercamp-2011.html
Et les slides de Romain Maton : http://www.web-tambouille.fr/2011/09/18/optimiser-votre-site-web-sur-mobile-jug-summer-camp-2011-slides.html

Vous avez d’autres liens sur des retours du Jug Summer Camp ? Alors postez les dans un commentaire

Merci à Eric Siber et Claude Falguière pour les photos . Cet article a été co-écrit avec Isabelle Blasquez.

Les 3 et 4 octobre auront lieu à Genève la deuxième édition de SoftShake ! L’idée est simple, un peu d’agilité, de Java, de dev mobile, de Microsoft et hop, voilà SoftShake !

L’idée a germé au sein de l’équipe de l’Agile Tour Genève, à la recherche d’un nouveau public. Ils se sont associés à deux autres associations, le Geneva JUG et le groupe des Développeurs iPhone de Suisse romande. Les avantages sont nombreux, les échanges entre des communautés qui n’ont pas pour habitude de se rencontrer dénotent dans le panorama des conférences java européenne où l’on retrouve souvent les mêmes présentations et les mêmes personnes.

Outre les quatre thèmes principaux (Java, Agilité, iPhone, Microsoft), un cinquième est toujours là : c’est l’incubateur qui permettra de tester des sujets qui mériterons peut-être une session spécifique l’année prochaine (NoSQL, Cloud Computing, Node.js).

Les conférences sont majoritairement en français (3/4) et pour l’instant assez techniques, même si dans les prochaines éditions, le but sera d’avoir autant de sessions pour les décideurs que pour les techniciens.

Au niveau pratique, une fois encore les frais d’entrée sont très modérés et il est possible de dormir pas loin de la conférence ou de faire l’allée retour dans la journée (75€ l’A/R avec EasyJet au départ de Paris)  !

Nous serons quelques unes à y aller et nous iront y animer quelques conférences :

Mettre en place un atelier avec iOs par Claude Falguiere et Sylvain Rousseau

Présentation rapide de l’usine logicielle mise en place sur nos projets.

• faire un petit projet XCode en TDD
• mettre en place le repository Git
• faire un makefile et l’intégrer dans Jenkins
• mettre en place un déploiement OverTheAir via notre serveur de déploiement

Présentation Node.js par Mathilde Lemée et Romain Maton

Alors qu’on a vu ces dernières années fleurir des frameworks cherchant a masquer le javascript pour les développeurs (notamment GWT ou Vaadin), avoir un serveur web en Javascript peut surprendre. C’est pourtant ce que propose Node.js qui fait indéniablement le buzz depuis plusieurs mois.

Vous découvrirez les bases de ce framework, ses atouts et ses faiblesses.

Hands on Node.js par Mathilde Lemée et Romain Maton

La théorie, c’est bien, la pratique … aussi !

Venez nous rejoindre pour découvrir les profondeurs de Node.js !

Nous nous servirons d’un exemple pratique pour vous permettre d’avoir une premiere experience complete autour de Node.js et de vous permettre de vous forger un avis sur ce serveur Javascript qui fait parler de lui !

Pour plus d’infos c’est par ici : Le site officiel

Le 20 septembre prochain, le Lyon JUG propose une session sur Git, animée par Sébastien Douche. Il proposera également le lendemain, toujours à Lyon, un coding dojo pour vous fournir une initiation pratique à Git!

Quand on demande à Sébastien de se présenter voici ce qu’il nous répond : “Je m’appelle Sébastien Douche, 36 ans, j’ai commencé à tater des ordis avec les jeux vidéos il y’a 30 ans au Japon. Je me suis mis à la programmation assez jeune (C et assembleur x86) sous MS-Dos (ah le compilateur Watcom). La découverte d’Internet en 95 a bouleversé mon existence de geek, avec Linux et les Logiciels Libres, ainsi que pas mal de langages comme Eiffel, D, Erlang, Ada, Objective C, Smalltalk, Forth, REBOL et tant d’autres. Mais mon profil est assez atypique car je me suis vite intéressé à d’autres domaines comme l’agilité, l’administration système, le coaching et enfin la gestion d’organisation car je ne comprenais pas pourquoi je me sentais aussi mal dans les entreprises où je travaillais. Depuis 4 ans, je peux mélanger toutes ces passions dans mon activité professionnelle chez un éditeur logiciel Français.”

Puisque Sébastien et le Lyon JUG avaient envie de vous faire plaisir, vous avez le droit à cet interview mais également très bientôt à un nouvel opus du podcast Cast-IT, qui sortira peu après le 20 septembre (le temps du montage!). Si vous ne connaissez pas ce podcast émanant de la team du Lyon JUG, Cast-IT, allez vite écouter les premiers épisodes de ce nouveau podcast participatif sur l’écosystème Java, certes, mais ouvert également à des sujets comme l’Agilité ou d’autres langages. Ça tombe bien, même si Sébastien va nous parler de Git pour sa session au Lyon JUG, on voit dans sa présentation qu’il a bien d’autres centres d’intérêts : on va donc parler de Git bien sûr, mais aussi aborder avec lui d’autres de ses sujets de prédilection, notamment l’Agilité!

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG.

Agnès & Cédric: Tu proposes un talk sur Git, un système de gestion de version décentralisé (DVCS). Étant depuis longtemps présent dans les communautés des logiciels libres, peux-tu nous dire en quoi les DVCS ont été bénéfiques pour ces communautés ?

Sébastien: Les DVCS ont permis d’améliorer grandement la gestion de projet, raison pour laquelle beaucoup de projets Libres ont sauté le pas. Torvalds avait compris dès 2002 l’intérêt de BitKeeper (le 1er DVCS) et refusait catégoriquement d’utiliser CVS. Il faut dire qu’avec 10 ans d’expérience de management du plus gros projet Libre, il commençait à avoir de la bouteille. Dans un projet Libre, on passe beaucoup de temps à tester et à intégrer du code, et la souplesse offerte par l’outil de gestion de source est importante. Or, SVN impose de par sa conception un management restrictif, seules les personnes habilitées ont droit de commit, donc de travailler avec l’outil. Pire, chaque développeur ne peut pas choisir librement sa méthode de travail sans impacter les autres développeurs, voir la stabilité du projet. C’est pour cela qu’il faut bien souvent montrer patte blanche avant de réellement participer, alors que la facilité d’immersion dans un projet Libre est fondamentale pour sa réussite.

Dans ces conditions, le DVCS est un atout majeur en décorellant la façon de gérer le projet des envies ou besoins des développeurs. Chacun pouvant donc, à son niveau, définir sa méthode de travail. C’est ce que j’appelle workflow organisationnel (le management de projet) et workflow personnel (la méthode de travail du développeur). Voici un exemple avec le projet Python : le responsable projet demande un commit unique par fonctionnalité si je suis core développeur ou un patch sur le bugtracker dans le cas contraire. Cette contrainte n’impose pas une quelconque façon de travailler sur ma machine, mais seulement ma relation avec le projet. Par une IHM bien pensée et des fonctionnalités intéressantes, des sites comme GitHub ou Bitbucket abaissent encore plus le coût de participation.

De plus les DVCS sont bien mieux pensées. SVN croule sous le poids des années. Il faut rappeler qu’il est sorti en 2001 comme une amélioration de CVS sorti en 1990, lui même étant une amélioration de RCS sorti en 1982, lui même un portage Unix de SCCS sorti en 1972 (ouf !). On a beaucoup appris en 30 ans. Je pense notamment au graphe des commits (que l’on appelle le DAG) des DVCS et son équivalent atrophié SVN, qui impose cette façon si peu efficace de gérer les branches. Tellement peu efficace qu’elles sont rarement utilisées, voir interdites.

Agnès & Cédric: Naïvement, on peut facilement voir l’intérêt d’un DVCS pour des personnes travaillant en mode distant, mais au sein d’une entreprise, ce type d’outil a t’il vraiment des plus-values? Si oui lesquelles? En quoi une entreprise doit-elle être vigilante avant de passer à un outil comme Git ?

Sébastien: Le terme distribué est trompeur, car on pense «déconnecté» ou «distant» alors qu’il faut lire «autonome». La possibilité de télétravailler chez soit ou dans le train n’est qu’une conséquence d’une architecture qui me permet avant tout de travailler localement, sans fil à la patte. Je suis autonome et je décide ce que je veux partager : le développeur devient un producteur de contenu. C’est la distinction des workflows de ma réponse précédente. En tant que responsable, la possibilité de définir le workflow organisationnel est un atout majeur pour améliorer la qualité du projet. Et pour le développeur, un confort incomparable de disposer de sa méthode de travail. Pour rien au monde je ne reviendrais à SVN et pour tout dire je refuserais un poste si je devais travailler avec. Pour citer ma présentation DVCS au ParisJUG, le dernier slide dit «si vous devez apprendre une chose en 2010, ce n’est pas (je liste les technos Java à la mode) mais un DVCS». A part virer Windows, je ne crois pas avoir vu un gain de productivité aussi notable avec un simple changement d’outil. Et c’est le développeur, le coach, le responsable R&D et le directeur technique qui parlent .

En tant que responsable R&D, j’ai vécu le changement SVN vers Mercurial, puis Git. Il y a deux difficultés :

1. bien comprendre les concepts des DVCS, et de Git en particulier qui est à l’opposé de SVN tant vous êtes libre de faire ce que vous voulez avec. C’est pour cela que ma conférence est avant tout structurée pour assimiler les concepts, et non les commandes comme je le vois malheureusement trop souvent.
2. il faut expliquer aux développeurs et aux responsables projets les différents workflows pour les aider à en adopter un. C’est le deuxième objectif de la conférence, mais l’avantage de l’atelier est ici évident car on peut pratiquer et en parler assez longuement.

Si je dois résumer, je dirais que l’on passe d’un mode de travail rudimentaire à une liberté totale. C’est banal à dire, mais la liberté est une chose merveilleuse et on se demande comment on a pu être aussi stupide de se laisser enfermer. Mais cette liberté exige discipline et responsabilisation. Et ne rêvez pas, vous ne deviendrez pas magiquement un meilleur développeur pour autant .

Agnès & Cédric: Utilises-tu un système de workflow avec Git ? As-tu des astuces pour simplifier la migration et l’adoption en entreprise ?

Sébastien: On a toujours un workflow, même sans le savoir . Voici mon workflow personnel pour chaque fonctionnalité que je dois coder :

• je commite énormément et de toutes petites modifications.
• j’utilise beaucoup de branches de travail (comme wip, backup, step1, step2) comme marqueur pour identifier chaque étape et y revenir si besoin.
• une fois le travail terminé, je pousse tout dans la branche principale de la fonctionnalité nouvellement créée et je la nettoie si cela est nécessaire : fusion et ré-ordonnancement des commits, décomposition d’un commit en plusieurs si j’ai mélangé plusieurs modifications sans lien entre elles et ré-écriture des messages de commit si besoin. J’appelle cela une branche «propre», un historique agréable à lire et facile à comprendre pour un relecteur, avec des commits «unitaires», c’est à dire cohérents et compréhensibles par eux-même.
• je pousse sur le serveur principal pour revue de code.
• quand la revue est validée, je rebase avec la branche master et je merge en non fast-forward.
• je supprime toutes les branches locales ainsi que la branche sur le serveur.

Nous avons eu plusieurs workflows organisationnels dans le temps. Par exemple avec Mercurial, j’étais l’intégrateur : les développeurs envoyaient un patch une fois la revue terminée et j’intégrais. C’est un workflow qu’utilisent beaucoup de projets Libres. Actuellement avec Git, nous avons la branche master, la branche par fonctionnalité, une branche pour chaque étape de développement de cette fonctionnalité et enfin une branche de maintenance par version majeure. Mais nous n’avons pas de branche d’intégration générale (lisez git-flow si cela ne vous semble pas clair ou venez à une de mes conférences ).

Agnès & Cédric: Tu as essayé d’autres DVCS que Git, tu dis être passé de Mercurial à Git par exemple. Qu’est-ce qui t’as poussé à changer de DVCS. As-tu des retours sur d’autres DVCS moins répandus comme Veracity de SourceGear proposant un certain nombre de features en plus de Git ?

Sébastien: J’ai utilisé Mercurial (Hg) deux années au taff et un peu joué avec Monotone et Darcs, deux DVCS de première génération. Faisant beaucoup de veille, je reste à l’affût de toute nouveauté, et j’ai quelques fonctionnalités en tête que j’aimerais bien voir dans Git. Nous sommes passé de Hg à Git pour deux raisons : la curiosité intellectuelle, et parce que la gestion des branches dans Hg est assez simpliste, il faut cloner le dépôt quand on veut travailler temporairement sur une branche ce qui est loin d’être convivial (je crois que les développeurs de Hg travaillent là dessus). Notez qu’on aurait pu rester sur Hg, mais je suis très heureux d’avoir basculé.

Pour Veracity, je suis circonspect. Un outil qui intègre DVCS, wiki, bugtracker et Burndown Chart donne l’impression d’un outil qui se veut certes accessible pour l’entreprise, mais bien trop intégré à mon goût. C’est l’opposé de ma philosophie qui vient d’Unix : un bon outil pour une tâche donnée. Je n’aime pas les outils intégrés, surtout si c’est une brique d’infrastructure. Il a fallu une semaine pour passer de Hg à Git et adapter nos outils, que se passe t’il si je veux quitter Veracity ? Mais il est intéressant de noter que les nouveaux outils (Veracity, Fossil) sont des DVCS. Ceci dit, je mets *tout* dans un dépôt Git: code, données, binaire, fichier de configuration, documents (vive le format texte comme le rst ou le markdown), blog, site web et j’attends un bugtracker et un wiki digne de ce nom avec un backend Git. Il faut noter que Git, Mercurial et Bzr partagent une conception assez proche et les migrations entre DVCS sont simples, et on trouve d’ailleurs des projets Libres en dépôt Git et Hg.

La seule fonctionnalité intéressante que j’ai pu voir dans les DVCS récents est l’autosync de Fossil, permettant de “simuler SVN”, utile pour ceux qui débarquent dans le monde du DVCS. Sinon j’apprécie la facilité du cherry-picking de Darcs et les tags locaux de Hg. Mais pour moi l’avancée marquante sera un outil graphique de visualisation du graphe des commits puissant. Je suis certes un amoureux de Git, mais je n’hésiterais pas à changer si je trouve un outil plus intéressant. Il est important de ne pas se scléroser mentalement.

Agnès & Cédric: Tu viens d’écrire un article “L’Agile est mort” dans l’été, qui a engendré pas mal de discussions/commentaires… A la fin de l’article tu proposes de regarder d’autres méthodes ou outils : tu parles notamment de Kanban. Peux-tu nous dire ce que Kanban t’a apporté ces dernières années ?

Sébastien: Pour être précis, j’ai dit que le modèle Agile, inventé pour vendre du service, doit mourir. Nous progressons régulièrement dans la compréhension de notre métier et il est ridicule de continuer à pratiquer un management de 2001 parce qu’il est «bankable». C’est une problématique de consultants, pas des gens qui produisent. Toyota, Google ou Apple ne font pas du Lean truc ou du Scrum machin, ils font ce qui est utile et bon pour eux. Il est illusoire de déléguer à des consultants le management de son projet ou de son organisation, c’est *votre* travail. C’est l’objet de mon prochain billet sur le management qui s’intitule “N’écoutez pas les consultants”, et j’avoue que cela me démange de taper sur quelques personnes connues (françaises et internationales) qui disent n’importe quoi pour vendre leurs sauces. La montée en puissance du Kanban est un bon exemple, ou l’on retrouve régulièrement des sessions qui expliquent comment faire du «Scrum + Kanban», ce qui est assez pitoyable et montre soit l’incompétence, soit une volonté de protéger son business, mais en aucun cas de proposer l’état de l’art au client. Faire du business ok, mais il faut avoir une éthique. Un mec comme Schwaber me faire vomir tant il ne s’intéresse qu’au fric et je me bats contre Scrum car ce n’est qu’une marque.

Pour revenir au modèle, c’est je crois le défaut de tout modèle générique quel que soit sa qualité intrinsèque, il suffit de voir les dégâts de CMMi ou de RUP par exemple. Il faut toujours se rappeler que la ruée vers l’or a surtout enrichi… les vendeurs de pioches.

Pour le Kanban que j’utilise depuis plus de 3 ans, c’est à la suite de l’échec rapide dans mon contexte du mode de management agile «traditionnel». La tactique que l’on utilise en agilité est de limiter le travail en segmentant la vie du projet en «itération», étape où l’équipe doit produire un logiciel fonctionnel. Cette itération est fixe, au niveau du temps comme du travail à produire, préalablement choisi avec le responsable projet à l’aide d’une métrique appelée vélocité. Un dashboard permet de visualiser l’avancée de l’itération. Je pense que tout le monde est maintenant familier avec tout cela, je n’irais donc pas plus loin.

J’ai commencé par une itération de 15 jours pour finir avec une itération de 5 jours, du déploiement continu et des phases de Q/A important lors des releases officielles (une par trimestre, mais on release chaque mois en interne). J’ai trouvé plusieurs lacunes graves à ce mode de management :

• la vélocité est une métrique boiteuse, sorte de moyenne des estimations des développeurs. Sans compter qu’on passait 1/8 de notre temps en planning poker.
• le dashboard n’est pas assez précis, il ne permet pas de comprendre finement le «système» (la R&D dans mon contexte).

Parallèlement je demandais depuis longtemps tant au responsable produit qu’au développeur de découper les tâches de plus en plus petites car je voulais une sortie rapide du système (un développement rapide), ce que le Lean appelle «cycle time». Et en modifiant petit à petit le management du projet pour combler les lacunes apparentes, je me suis rendu compte que la notion de flux était puissante. Je venais par petite touche de me rapprocher du Kanban. Depuis j’ai abandonné les estimations et les itérations pour une approche plus fine et souple avec une intégration des fonctionnalités quand elles sont prêtes (merci la gestion des branches des DVCS), des phases différentes selon qu’on release officiellement ou non (une release officielle demande des docs, une synchro avec le marketing et le commerce, etc), des «classes de service», c’est à dire des priorités différentes selon les demandes. Je modélise aussi bien les demandes fonctionnelles, de correction de bugs que de modification de l’infrastructure de création de doc. Je suis ravi de ces changements, je suis sorti d’un carcan pour créer une environnement adapté au business de la société. Entre temps, j’ai fait la relation avec mes lectures passées (le Lean et la théorie des contraintes) et découvert le Kanban, la plus proche émanation de la théorie des flux dans le contexte de développement logiciel. Bien que cela puisse paraître récent, c’est en fait assez vieux : la théorie des files d’attente du mathématicien Erlang, le travail du professeur du MIT John Little, la théorie des contraintes, l’efficacité des batchs, on parle des années 1920 à 1970 ! On utilise ces théories dans beaucoup de domaines et Toyota l’a par exemple bien compris depuis longtemps. Après l’agilité, le Kanban représente pour moi une nouvelle avancée marquante dans le management de projet. Plus besoin de triturer son itération, et je rigole souvent quand j’entends les retours d’expérience de Scrumistes qui déforment leur pratique managériale pour faire tenir les demandes. Sans compter le puéril débat Scrum / Scrumbut qui ne fait que mettre en exergue le carcan qu’impose les soit disant experts. Dernier point, notre dashboard (un énorme tableau blanc avec des fiches cartonnées) permet de connaître à tout instant l’état exact du système, cela est très intéressant.

Voici un exemple que j’espère compréhensible : un jour, un des développeurs de l’équipe qui n’avait rien à faire prend une fiche de très basse priorité (les fiches importantes sont bloquées pour diverses raisons). Cela part d’un bon sentiment, il n’est pas payé à ne rien faire. Mais alors que la fiche semblait simple, cela à pris plus de temps que prévu. Pire la fiche a fait 2 aller/retour (la revue de code est obligatoire chez nous), elle a pris du temps à la R&D et une fiche plus prioritaire fut retardée. Du point de vue du développeur, il a occupé son temps à 100%, c’est donc positif. Mais du point de vue du système on est perdant, la fiche prioritaire est retardée. Une conséquence possible aurait pu être la non intégration de la fonctionnalité impactée pour la release du mois, ou pour la livraison d’un POC (test en avant vente) très important pour la société. Le Kanban a montré très facilement cela : on écrit la date quand on déplace de colonne la fiche (rappel, une colonne = un type de tâche), on peut ainsi voir le temps qu’elle a mis dans le système (temps du commencement du dev jusqu’à l’intégration dans la branche principale). On note aussi les aller / retour entre la colonne dev et la colonne revue. Il fut donc facile de constater que la fiche dite “facile” a passé 2 jours dans le système, avec 2 A/R. La fiche importante ayant du coup pris 1 jour de délais supplémentaire dans le système (alors qu’on avait prévu de finir assez facilement la veille). Si le développeur avait attendu au lieu de travailler, il aurait revue la fiche prioritaire 1h après et elle sortait rapidement. Autrement dit, il aurait mieux fallu qu’il glande au lieu de bosser ! Étonnant non ? Mais du point de vue du système, c’était la meilleure solution. Depuis, les développeurs n’ont plus honte d’utiliser le «slack time», temps où on ne peut rien faire et qu’on met a profit pour, par exemple, faire de la veille.

Il y a tant à dire sur le sujet que cela dépasse largement le cadre de cet interview. J’ai peur que beaucoup de lecteur se disent «encore un truc de manager» ou pire «c’est pour mettre encore plus de pression». Le meilleur moyen de faire baisser la pression et de travailler sereinement, c’est d’être efficace et sûrement pas de finir la mise en prod le vendredi à 22h ! Je suis devenu manager pour créer un environnement que le développeur que j’étais aurait aimé avoir, loin des environnements pourris qu’il a connu. Je vais bientôt proposer une conférence sur le sujet tellement je suis émerveillé. Mais la théorie des flux ne fait pas tout, cela rentre dans un cadre plus global de recherche de marché, d’analyse marketing produit, de gestion des hommes et de pratiques de développement logiciel. Je souris toujours quand je repense au geek qui ne pensait qu’a coder seul devant sa machine, mais tous ces domaines sont passionnants et surtout importants pour la réussite d’un projet. Développer un produit logiciel est fascinant.

Agnès & Cédric: Comment se déroule l’une de tes journées types ? As-tu le temps de faire de la veille techno et de mettre les mains dans le code ? Ou es-tu maintenant plus passionné par l’agilité et le coaching ?

Sébastien: Je fais environ une heure de veille par jour depuis que je travaille, ceux qui me suivent sur Twitter le croiront sans mal . J’ai cumulé beaucoup de casquettes pendant longtemps : directeur technique, admin système & réseau, responsable R&D, coach agile, coach organisationnel, testeur, responsable projet, responsable support, responsable logistique (nous vendons logiciel + matériel), release manager, développeur. On a fini d’optimiser certains process assez lourds comme la logistique et j’ai délégué certaines tâches comme le support, je peux donc revenir plus vers du code commun avec les développeurs. Mais avec mon emploi du temps, il est impossible de travailler sur du besoin métier, qui exige de gros blocs de temps sans interruption (ce qui est rarement le cas d’un manager) et surtout de travailler de concert avec les autres développeurs. Je m’occupe donc plus de projets d’infrastructure comme développer des outils internes, revoir nos techniques de tests, refactorer les couches techniques, simplifier la configuration du serveur d’application, extraire le code métier du code technique, repackager le code… Bref, baisser la complexité générale et éliminer les points techniques qui posent problème.

Cela permet d’apprendre beaucoup car on touche à tout sauf malheureusement au code métier. La couche système est ma seule implication de bout en bout car je suis un peu plus expérimenté que les autres.

La semaine dernière par exemple, j’ai transformé notre guide utilisateur OpenOffice en document Sphinx ce qui permet de publier en plusieurs formats dont le HTML afin de l’intégrer aux sondes et d’utiliser Git comme backend. Et je suis en train de me replonger dans Latex pour modifier le format PDF. J’ai modifié notre socle pour faire du support par clé modem 3G et ainsi aider nos avant ventes chez des clients un peu parano qui n’acceptent pas le VPN par Internet (ce qui m’a demandé de refaire un nouveau kernel Linux, de transformer un usbstorage en usbserial, et de configurer ppp). Et j’ai testé plusieurs logiciels car je dois revoir notre pratique de tests fonctionnels. Bref, Je suis bien loin du manager qui fait du Powerpoint. J’ai d’ailleurs horreur des outils bureautiques, mes pres. comme mes blogs ou les documents que je produis sont aux format rst ou Markdown .

Si je dois faire l’exercice de l’ascenseur à un recruteur, je dirais : vous gérer le commerce, le marketing et les finances, je m’occupe du reste ! Avoir autant de casquettes n’est pas facile et j’ai même failli devenir schizo, mais cela à un avantage indéniable : la prise de décision est fort simple . En gros je fais ce que je veux, c’est la raison pour laquelle 99% de ce que j’ai mis en place depuis 4 ans était nouveau pour moi : je trouve quelque chose d’intéressant, quelques heures ou jours après c’est mis en place et appliqué, car je n’ai pas à convaincre un client ou mon chef. Résultat, une courbe d’apprentissage exceptionnelle, j’ai appris ces 4 dernières années 100x plus qu’en 8 ans de SSII. Pire, je me suis aperçu que mon expérience était faible et que je ne savais vraiment pas grand chose (j’en sais un poil plus maintenant . De plus, je trouve le métier d’éditeur logiciel est bien plus intéressant et passionnant que de travailler en SSII, le business model étant plus contraignant : vous ne gagnez de l’argent qu’une fois le produit fini, et encore si le client en veut ! L’efficacité est primordiale, surtout si vous êtes une startup avec peu d’argent.

Agnès & Cédric: Fais-tu quand même un peu de Java (on te sait assidu au ParisJUG) ? Quel regard as-tu sur cette plateforme et cette communauté par rapport à Python ?

Sébastien: Il y a beaucoup à dire, notamment sur ce que j’appelle le «prisme Java», c’est à dire la déformation que vous avez à force de vivre dans cet écosystème. Je déteste Java (je suis devenu admin en 2001 pour ne pas faire du Java ou du PHP, véridique !), et si j’avais la moindre velléité d’en faire quand je suis arrivé au ParisJUG, ils m’ont définitivement dégoûtés . L’objectif initial était d’aller vers des communautés de développeurs pour m’enrichir d’autres regards et pratiques sur le développement, et je côtoie toujours beaucoup de communautés. La rencontre avec des Javaistes fut… comment dire… difficile. Le monde Java est assez fermé (avec des œillères bien solides), possédant sa propre novlangue. Je ne comprenais rien (et je ne comprends toujours pas grand chose) des Javaistes quand ils parlent ! De mon point de vue, il y a 3 soucis majeurs dans le monde Java :

1. Une culture fortement dominée par des entreprises commerciales et cela se ressent, tant du coté des fournisseurs de solutions que des prestataires. Sans compter que 80% des développeurs Java que je vois travaillent pour des grands comptes, c’est fortement structurant.
2. Je n’apprécie pas du tout le système de typage, avec l’extrème verbosité d’un typage explicite et des NullPointerException au runtime par exemple. De mon point de vue, Haskell, OCaml ou C# sont bien plus intéressants sur ce point si on est intéressé par le typage statique. Scala est sur ce point une avancée intéressante. D’où aussi l’utilisation presque obligatoire d’un IDE.
3. Un langage rustique par certains cotés, qui a mal évolué, avec des lacunes. Quand je vois qu’il faut attendre Java 7 pour avoir la gestion des contextes (le try-statement) la gestion de plusieurs exceptions à la fois ou une librairie I/O potable, je rêve un peu. On gardera un voile pudique sur des errements comme la gestion des classpath . Alors que de l’autre coté, le manuel de référence fait plus de 800 pages ! Par comparaison, Python en fait 120.

Pour moi, c’est la JVM qui sauve Java. Je trouve le langage en lui même assez médiocre. Mais le pire est que je constate souvent qu’un développeur Java passe 70% de son temps à régler des problèmes Java et non des problèmes métiers, d’où le surnom que je vous donne : «Mario», et l’expert Java «Super Mario». La complexité moyenne d’un projet est absolument incroyable ! Le développeur Java passe son temps à câbler des librairies (qui pour la plupart comblent les errements du langage) et à faire fonctionner des frameworks ensemble, c’est ennuyeux à mourir. Je suis impressionné par le niveau de connaissance nécessaire pour mener à bien un projet. Malheureusement la grande majorité des informations que vous emmagasinez n’a aucun intérêt pour moi. La conséquence est que votre échelle de complexité est maintenant complètement biaisée, et ce que vous appelez simplicité est pour moi bien trop complexe. Pire, ma simplicité est suspecte pour un développeur Java ! J’ai halluciné de lire un jour le résultat d’un questionnaire qui montrait qu’un développeur passait 14% à 28% de son temps à… attendre que le serveur d’application se lance ! Ou qu’un développeur lambda écrivait tout autant de xml que de Java. Le besoin de productivité, le fameux «time to market», ne permet plus de dépenser autant d’argent pour des résultats aussi faibles.

Mais depuis 3 ans les choses changent : la déception du rachat par Oracle, les 5 ans pour avoir 8 fonctionnalités, l’arrivée de Clojure, Scala, Groovy et surtout la prise de pouvoir du monde Web, philosophiquement assez éloigné du monde Java ont changé la donne.

Mais la raison essentielle de ma présence aux 3ème mi-temps (celle ou l’on boit, tu ne me verras pas souvent aux confs), c’est de se confronter à d’autres opinions, d’autres regards, car il est important de ne pas se figer dans ses croyances, de permettre de réfléchir à son propre prisme, ses propres blocages, ses propres lacunes. Ma conférence sur les langages dynamiques est par exemple une conséquence d’une réflexion sur ma relation avec la programmation qui fait suite à des discussions au ParisJUG. Et puis discuter entre passionnés autour d’une bière, j’adore. Que l’on parle moto, mécanique, photo, programmation, coaching, organisation, méthodo, rencontrer des gens est vital pour moi, j’ai besoin des autres pour initier et enrichir ma réflexion. Je suis trop stupide pour penser seul dans mon coin, j’ai besoin d’input .

Pour Python, c’est bien différent :

• d’abord par l’aspect communautaire, très proche du Libre, que l’on retrouve dans beaucoup de langages. Il n’a pas des annonces tous les 2 mois de la techno géniale X qui va révolutionner le monde, j’apprends les sorties car je suis… le flux RSS du serveur qui centralise les composants Python.
• C’est un langage accessible, raison de sa popularité en tant qu’outil de formation à l’algorithmie dans de nombreuses universités. L’abandon de Scheme par Python au MIT à fait grand bruit d’ailleurs (le livre Scheme utilisé depuis 30 ans est un best-seller).
• Une productivité assez impressionnante par son expressivité et des axiomes puissants, qui vous rend accro très vite. Il partage avec Git et Unix une conception orthogonale : il existe un petit nombre de concepts mais qui donne une belle puissance quand ils sont additionnés. De plus il est cohérent, vous n’avez pas à lire la doc toute les 5 min pour comprendre ce qui se passe. Je ne parle pas du first class object, la facilité d’introspection, ou la grosse librairie standard.
• Le langage est développé par une petite équipe (bien qu’on doit atteindre les 100 développeurs maintenant) qui fait cela sur leurs temps libres, ils ne se battent pas pour imposer telle ou telle lib (suivez mon regard), mais veillent avant tout à une cohérence d’ensemble. Et de toute façon on a un dictateur bienveillant qui tranche régulièrement. Malgré la faible taille, Le projet est fortement structuré (un exemple : l’équivalent du JSR appelé PEP est utilisé depuis 2000) et un management solide qui me laisse de temps en temps un poil baba. Python 3 est un bel exemple, notamment si on le compare avec PHP 6 et Perl 6.
• Ensuite, j’apprécie fortement le codage par «Duck Typing», beaucoup moins contraignant que le typage statique en Java. Lisez un code Java et dites vous quelles sont les lignes qui sont utiles pour le métier. En Java, c’est assez consternant. En Python, vous êtes proche du pseudo-code, tout en gardant une forte lisibilité. Cela n’a pas que des avantages bien sûr (Haskell ou OCaml ont bien plus d’intérêt), mais associé à la simplicité et l’expressivité du langage, l’équilibre général du langage est très intéressant.
• La communauté est dynamique, compétente et accueillante. Que ce soit celle des utilisateurs ou des core developers. Il existe une liste de diffusion pour débuter en programmation, de tutorat pour devenir core developer par exemple. Il existe beaucoup de projets impressionnants par leur maturité technique. On est loin de la communauté PHP avec ses logiciels phares codés avec les pieds.
• Et enfin le projet PyPy (VM avec un JIT) est très prometteur. La version en cours de développement est presque 5x plus rapide que l’interpréteur de référence CPython et ce n’est pas fini. Il existe même des implémentations de PHP ou de Smalltak et des backends .NET et JVM. Ce projet va sûrement rendre Python encore bien plus attractif.

Mais comme je le répète souvent, chaque langage est une vision du développement, et tout est question d’équilibre entre facilité et contrainte. Le saint Graal que représente la fusion du bon coté des langages dynamiques (le fun) et du bon coté des langages statiques (la performance et la plus grande sécurité) n’est pas encore atteint malgré quelques tentatives comme OCaml. En ce moment je suis beaucoup le langage Go et j’attends une stabilisation du projet pour m’y remettre. Je suis déçu par Scala qui manque d’accessibilité tant dans la syntaxe que la sémantique. C’est un langage puissant mais trop «brute de fonderie». Je garde ma préférence à Python car non seulement je me sens très productif tout en gardant une qualité de code certaine, mais aussi parce que le plaisir de coder est largement présent. Et ça, c’est essentiel.

Merci Sébastien!

Les inscriptions pour la session de Sébastien au Lyon JUG le 20 juillet sont ouvertes! De plus nous vous proposons un coding dojo, pour vous fournir une initiation pratique et gratuite à Git. Celui-ci sera animé par Sébastien Douche lui-même et se déroulera mercredi 21 septembre de 19h à 21h à l’Epitech et se limitera à 20 personnes. Le Lyon JUG offrira les pizzas ! Rendez-vous sur le site du Lyon JUG.

Le Paris Jug organise mardi prochain (13/09) une soirée rétrospective sur le Challenge USI 2011 dont le sujet était  « Et si vous codiez une application qui supporte 1 milliard d’utilisateurs ? ». Plusieurs équipes (dont les finalistes) viendront présenter leurs architectures.

Pas de changement, les Duchess organisent l’AvantJUG au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations évidentes, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin.

A bientôt !
Crew Duchess France

Le 21 juillet prochain, le Lyon JUG propose une soirée spéciale à l’occasion de la sortie de Java 7. Partout dans le monde d’autres événements de ce type auront lieu au mois de juillet. Vous pouvez récupérer les slides Oracle et des exemples de code présentant les nouveautés de Java 7 et également visionner le webcast officiel “MOVING JAVA FORWARD” proposé par Oracle pour la sortie de Java 7. Le Lyon JUG a donc choisi pour l’événement d’accueillir un de ses fidèles, Julien Ponge, mais également Alexis Moussine-Pouchkine.

Alexis Moussine-Pouchkine était ambassadeur, chez Sun Microsystems du projet Iibre, GlassFish. Il continue actuellement à travailler sur ce serveur d’application Java EE de nouvelle génération en tant que GlassFish community manager chez Oracle. Ceci lui permet de rencontrer lors de réunions ou de conférences de nombreux développeurs Java et autres utilisateurs de technologies libres. Il anime depuis peu une conférence intitulée “Oracle ange ou démon?”, vous pourrez notamment assister à cette session au JUG Summer Camp à la rentrée. Il blogue régulièrement sur Bistro! ou TheAquarium et participe à plusieurs communautés open source. Il traduit également en français des ouvrages techniques autour de Java ou XML. Vous pouvez suivre Alexis sur Twitter ou l’écouter sur le podcast Java Spotlight auquel il participe régulièrement.

Julien Ponge est un artisan de longue date de l’opensource. Il a créé le framework IzPack et a participé à plusieurs autres projets, notamment à GlassFish en collaboration avec Sun Microsystems. Titulaire d’un doctorat en informatique, il est actuellement professeur agrégé en informatique à l’INSA de Lyon, et un chercheur dans le cadre de l’INRIA Amazones / équipe CITI. Ses centres d’intérêts de recherche concernent une approche combinée des langages de programmation, les machines virtuelles et des middlewares. Parlant à la fois le langage industriel et le langage académique, il œuvre pour développer des synergies entre ces mondes. Vous pouvez suivre Julien sur Twitter.

Puisque la team du Lyon JUG est généreuse, vous avez le droit pour l’occasion à un interview des speakers mais également à un nouvel opus de son podcast Cast-IT qui sortira peu après le 21 juillet (le temps du montage!). Si vous ne connaissez pas Cast-IT, allez vite écouter les premiers épisodes de ce nouveau podcast participatif sur l’écosystème Java, certes, mais ouvert également à des sujets comme l’Agilité ou d’autres langages. Et pour vous donner tout de suite un avant-goût de la soirée, allons à la rencontre des speakers de la soirée (Bon, on a donné des jokers à Julien : il ne s’est pas exprimé sur les questions touchant directement à Oracle!). Puisque la team du Lyon JUG est également joueuse, sachez que chacun d’entre eux n’a pas eu accès aux réponses de l’autre interviewé avant la sortie de l’interview! Que la partie commence…

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG. Merci également à Thierry Chantier et Anne-Laure Rigaudon pour leur aide sur la préparation de cet interview.

Agnès & Cédric: Quelles sont, selon toi, les nouveautés syntaxiques les plus intéressantes apportées par Java 7 ? Penses-tu que certaines nouveautés peuvent bénéficier à GlassFish ?
Alexis: Je trouve que Project Coin propose des améliorations du langage Java qui me font penser à la “nouvelle” boucle for apparue dans le JDK 5 et qu’elles forment un tout très cohérent mais j’aime particulièrement le bloc ARM (Automatic Resource Management, aussi parfois appelé try-with-resources).
Quant à l’intérêt de Java 7 pour GlassFish, je pense que les chaînes de caractères dans les switch, les blocs ARM (notamment avec JDBC 4.1), le multi-catch (SQL, gestion de fluxs, …) et la notation diamond sont tous applicables dans un contexte Java EE, mais c’est des développeurs GlassFish que j’attends le plus et en particulier de leur utilisation de nio 2 et peut-être même de fork/join. Nul doute que les APIs de Java EE 7 tireront partie de Java SE 7 qui sera un pré-requis. Enfin, on peut noter que GlassFish 3.1.1 sera certifié sur Java 7 d’ici quelques semaines ce qui proposera les améliorations de performances inhérentes à toute nouvelle version du JDK.
Julien: Les chaînes de caractères dans les switch ou les underscores dans les littéraux numériques sont des évolutions mineures mais néanmoins utiles. Le multi-catch apporte une concision salutaire lorsqu’on manipule des APIs déclarant beaucoup d’exceptions tandis que le traitement de celles-ci reste commun à de nombreux cas. Classiquement on utilisait un type d’exception très générique (Exception, Throwable, …), ce qui n’est pas toujours une bonne idée. Le multi-catch est un compromis idéal entre concision et expression de types complète.
L’inférence de types paramétrés avec le diamond ainsi que le try-with-resources sont pour moi les 2 vraies nouveautés majeures et notables de Java 7. J’adore en particulier le dernier. Tout le monde se plante en écrivant du code qui manipule des ressources, souvent sans en avoir conscience. Sur des applications serveur cela peut nécessiter des redémarrages fréquents. Traiter tous les cas d’erreurs possibles est complexe, aussi déléguer la génération d’un code correct au compilateur est salvateur. Cf http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html

Agnès & Cédric: Peux-tu nous en dire un peu plus sur le projet OpenJDK?
Alexis: Depuis qu’Oracle a réaffirmé l’aspect stratégique d’OpenJDK (et depuis que cela devenait l’implémentation de référence de Java SE), on a vu IBM et Apple rejoindre le projet (RedHat l’avait fait à l’époque de Sun) ce qui lui assure des ressources importantes et de qualité et donc un avenir à long terme. Il reste encore beaucoup à faire et j’attends en particulier avec impatience les contributions issues de JRockit (annoncées par Oracle).
Enfin, à défaut d’avoir toute la transparence espérée dans JCP (les progrès sont en cours), OpenJDK est une communauté ouverte qui permet de suivre de très près l’évolution de la principale implémentation JavaSE et de permettre aux utilisateurs Mac OS X d’avoir des binaires fournis par la communauté (Henri Gomez) en attendant une version officielle d’Oracle.
Julien: C’est l’implémentation de référence de Java SE 7 qui est sous licence GPLv2 + classpath exception.
A titre personnel je suis ce qui se passe sur certaines listes de diffusion et en particulier le port macosx. On y voit des ingénieurs Oracle, IBM ou Apple y discuter ouvertement, avec des extérieurs qui se greffent aisément aux conversations. A titre d’exemple Henri Gomez qui s’occupe d’un packaging non-officiel du port macosx est très actif (http://code.google.com/p/openjdk-osx-build).
OpenJDK c’est “le vrai Java”, et vous pouvez facilement récupérer le code source, l’étudier, et le compiler… et le modifier. Il n’y a pas de barrière particulière à l’entrée.

Agnès & Cédric: Est-ce que tu penses que Java est attractif pour les jeunes développeurs? Vois-tu Oracle encore innovateur pour Java et son écosystème? Penses-tu qu’il soit nécessaire de ressusciter l’intérêt de la communauté? Si oui, comment?
Alexis: Il y a beaucoup de manière d’innover. Comparé à d’autres langages qui ont moins d’historique (moins d’utilisateurs) et d’autres approches (typage dynamique par exemple), Java peut apparaître comme en retard. Ceci dit on peut être très productif en Java de nos jours avec des versions récentes d’API (Java EE 6 coté serveur par exemple) et le rôle langage devient alors moins important. En fait son typage statique et son expressivité deviennent même une garantie de survie dans le temps, Java est un langage ou la (re)lecture est plus importante que l’écriture. C’est donc un excellent candidat pour l’apprentissage de l’informatique – pragmatique et *très* utilisé en entreprise, il n’en est pas moins indépendant de toute solution technique ou produit. On notera d’ailleurs que toutes les solutions de cloud que l’on voit apparaître sont basées sur Java.
Ceci dit, Java 7 n’est qu’une étape et Project Coin (comme le jeu de mots sur le nom du projet l’indique) ne propose que de relativement “petites” évolutions du langage. Java 8 (attendu dans environ 18 mois) sera plus ambitieux avec les expressions lambda (closures), et surtout à mon sens la modularisation tant attendue.
Le nouveau bytecode “invokedynamic” est une innovation qui passe un peu inaperçue. Elle devrait permettre à de nombreux langages s’exécutant sur la JVM d’améliorer leur performance et de simplifier leur implémentation. En fait ce bytecode sera même utilisé dans Java 8 pour l’implémentation des expressions lambda. Une place de choix est donc faite aux amateurs d’autres langages, même si je ne crois pas un instant Scala ou Groovy puissent détrôner Java tant son spectre et son utilisation sont larges.
D’autre innovations coté Oracle viendront sur les aspects monitoring et management avec en particulier le portage de JRockit Mission Control sur HotSpot ou la suppression pure et simple de la PermGen dans un update de Java 7.
Il reste beaucoup de chose à faire: simplifier JNI, meilleure interop entre langages s’exécutant sur la JVM, isolats (multi-tenancy), meilleure intégration aux systèmes de persistance, etc.
Mes première impressions suite au lancement de Java 7 sont que l’arrivée même d’une version majeure de Java est une source importante de motivation dans la communauté. J’espère qu’une cadence régulière d’innovations (toutes ne viendront pas d’Oracle heureusement) va donner un nouveau souffle à Java. En fait je trouve incroyable que la communauté ait continué à s’étendre pendant cette période de troubles. L’avenir ne peut apporter que de bonnes surprises.
Julien: Plusieurs questions en une
Oui Java est attractif pour les jeunes développeurs. Le langage en lui même reste simple mais pas simpliste. Mais c’est avant tout l’écosystème Java qui est attractif : une machine virtuelle de premier choix, des bibliothèques et frameworks à foison, des langages qui fleurtent avec des paradigmes différents de Java… sans oublier une communauté large et active. Le succès des JUGs et des conférences du monde Java en sont la preuve flagrante. Enfin il faut noter que l’univers Java n’a jamais été hermétique aux autres communautés (Ruby, Python, etc).
Clairement Oracle n’a pas la même culture que feu Sun Microsystems. Les débuts ont été difficiles en terme de communication, mais force est de constater qu’Oracle fait de gros efforts pour comprendre comment dialoguer positivement avec la communauté Java au sens large. Ils investissent massivement dans la technologie et ont réussi le coup de force de fédérer IBM, Apple et maintenant SAP autour de OpenJDK.
Certains ont un bénéfice stratégique à mettre de l’huile sur le feu et à guetter le moindre faux-pas d’Oracle. Jugeons plutôt cette entreprise sur les faits que sur les titres d’articles sulfureux qui fleurissent ci et là. De mon point de vue la tendance est bonne. Java possède un steward principal qui a les reins solides et la sortie de Java 7 marque la fin des errements de calendrier. Reste pour Oracle à poursuivre ses efforts.
Enfin je ne pense pas qu’il y ait besoin de “ressusciter l’intérêt de la communauté”. Les conférences sont sold-out en peu de temps, les JUGs tournent très bien… Java is not dying

Agnès & Cédric: Comment se déroule une de tes journées standards ? As tu le temps de faire de la veille, d’observer les produits concurrents ? As tu le temps de faire du Groovy, Scala ou Clojure ? Que penses tu de ces langages alternatifs sur la JVM ?
Alexis: Je passe en effet pas mal de temps à observer ce qui se passe dans la communauté (et je crois connaître assez bien la concurrence). Je passe aussi du temps à alimenter le blog No. 1 chez Oracle: TheAquarium et je voyage assez fréquemment pour participer à des conférences ou effectuer des visites aux JUGs.
Coté langages “alternatifs”, je suis vieux jeu! Je pense qu’ils ont des domaines d’application restreints: DSL encore peu utilisés, services en ligne massifs (combien d’architecture à la twitter?), et besoin de parallélisme bien traités par un Scala encore réservé à une élite. Coté informatique de gestion les avantages de ces langages ne sont pas évidents, sauf peut-être pour du développement rapide et jetable.
Julien: Je fais un métier qui n’a pas de journée type. Être chercheur suppose naturellement de regarder l’état de l’art, expérimenter, se positionner… donc une activité dite de veille est naturelle.
Je suis un fervent défenseur du “polyglot programming”, j’utilise donc des langages et combinaisons de langages en fonction des usages visés. Je ne rentrerai donc pas dans une guerre Groovy vs Scala vs Clojure vs Ruby vs Python vs JavaScript Il m’est même arrivé de programmer une application node.js !
La JVM est en passe de devenir le champ d’expérimentation #1 pour les nouveaux langages tant statiques que dynamiques (cf invokedynamic). Ce bouillonnement est une force, sauf pour les architectes frileux qui détestent avoir à effectuer des choix sur des critères purement techniques… [troll assumé]

Agnès & Cédric: Tu présentes une session en ce moment (à venir au JUG Summer Camp) intitulé “Oracle, ange ou démon?”… Quels sont les premiers retours de cette conférence?
Alexis: L’idée de cette présentation est partie de mon impression que si environ 50% de la communauté donnait le bénéfice du doute à Sun Microsystems (non, pas plus, beaucoup ont idéalisé Sun depuis le rachat), personne ou presque ne fait confiance aveuglément à Oracle. En particulier il est facile de donner le rôle du vilain à Oracle dès qu’il y a une polémique. Mon but est donc de retracer les événements, principalement dans le monde Java, depuis le rachat et de laisser l’audience se forger une opinion sur la base des actes d’Oracle. Clairement personne n’en ressort avec la conclusion qu’Oracle est un ange!

Agnès & Cédric: En quoi le rapprochement des équipes JRockit et HotSpot a été bénéfique pour JavaSE?
Alexis: Il y a presque deux fois plus d’ingénieurs travaillant maintenant sur la JVM par rapport aux dernières années chez Sun. C’est pour moi le principal avantage à court terme. A plus long terme, l’intégration des fonctionnalités unique de JRockit sur la base HotSpot sont très prometteuses, en particulier Flight Recorder et Real-Time.
Julien: D”un point de vue externe, ces deux équipes ayant produit des avancées significatives dans la conception de machines virtuelles, leur rapprochement ne peut qu’être bénéfique !

Agnès & Cédric: Comment se passe la collaboration avec les equipes de WebLogic ? Avez-vous mutualisé certains efforts ? Quel est l’intérêt pour Oracle à maintenir 2 serveurs Java EE ?
Alexis:
Les premières collaborations datent d’avant le rachat: WebLogic utilise Mojarra, l’implémentation JSF de GlassFish, Metro (stack Web Services) alors que GlassFish utilise depuis sa version 1.0 l’implémentation TopLink/EclipseLink développée par Oracle. Avec le rachat, les équipes GlassFish et WebLogic sont regroupées et les collaborations renforcées.
Ceci dit il est fondamental de ne pas perdre de vue l’objectif principal de WebLogic qui est de servir de socle pour le middleware Fusion, les Fusion Applications et les applications critiques développées par ses utilisateurs depuis des années. De la même manière il est fondamental de continuer à fournir avec GlassFish un produit open source de qualité (production-quality comme disent les américains) qui implémente la toute dernière spécification JavaEE sans oublier le clustering et une admin centralisée. Les rythmes de développement sont donc nécessairement différents.
En tout cas les efforts (et les ressources) consentis par Oracle sur GlassFish sont en soit une belle marque de succès pour l’équipe avec entre autre des embauches régulières et l’adoption de plusieurs fonctionnalités clés du produit dans les prochaines versions de WebLogic.

Merci Alexis et Julien!

Les inscriptions pour la session d’Alexis et Julien au Lyon JUG le 21 juillet sont ouvertes! Rendez-vous sur le site du Lyon JUG.

Le Paris Jug organise mardi prochain une soirée « La mode cloud, collections d’été ». Elle sera animée par Patrick Chanezon, français d’origine parti travailler chez Google USA. Il dirige l’équipe en charge de la promotion des services Google dans le nuage (App Engine, Storage, Prediction, BigQuery, Go) et des outils (GWT).

Comme d’habitude, les Duchess organisent l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.