Petit compte-rendu de la soirée du 11 mai 2010 au Paris JUG. Le thème de ce soir est consacré au principe de DVCS avec une présentation de Sébastien Douche. Puis ensuite une introduction à Git par David Gageot, suivie d’une présentation Maven 3 par Arnaud Héritier et Nicolas de Loof. Enfin une présentation de l’outil DeployIt par Guillaume Bodet et Benoît Moussaud.

Le W3C
Alexandre Bertails nous a tout d’abord présenté en 15 minutes le W3C et son nouveau poste au sein de l’équipe Système. Avant tout, allez voir le site web du W3C. C’est un exemple de ce que l’on peut faire et qui respecte les standards du Web. Fondé en octobre 1994, le World Wide Web Consortium (W3C) est un organisme de standardisation, à but non lucratif, chargé de promouvoir et d’assurer la compatibilité des technologies comme HTML, XML, XHTML, RDF, SOAP ou CSS.
Avec 65 groupes, environ 400 membres, 18 bureaux à travers le monde, Alexandre explique que le travail au quotidien ne manque pas. Ses outils pour travailler ? Les standards du Web. Il utile d’ailleurs pendant la présentation des slides réalisés en HTML5 sur un simple navigateur. Depuis son arrivée au W3C, il travaille sur différents sujets. Il y a du Java bien sûr, avec les outils de validation HTML, qui tourne sur le moteur Jigsaw. Des sites du W3C reçoivent entre 1 et 5 millions de hits par jour. Certains services sont en Java, et ça tourne !
Alexandre sera là mardi 18 mai pour faire une présentation sur Scala lors de l’inauguration du Paris Scala User Groupe, en principe chez Xebia. Je vous tiens au courant, je suis inscrit et je compte bien y aller.

I. DVCS
Sébastien Douche a ensuite donné une très bonne présentation de son expérience avec DVCS. J’ai vraiment bien aimé. Sympa, détendu et un poil polémique histoire que nous nous endormions pas. Comme on dit : SEB c’est bien.

Il lance ses slides et commence par se présenter. A chaque fois qu’il vient au Paris JUG, Antonio l’appelle « Onon Palui« .
Il faut dire que Sébastien est un extraterrestre : c’est un expert Python, il ne fait pas de Java. Ce qui donne des bons échanges, parfois musclés, mais toujours sportifs.

Il nous propose de découvrir DVCS (le concept) et parle de DCVS (qui est un logiciel). Directeur technique d’une Startup, il raconte sa propre expérience. Pour lui, la gestion de version du code source est le premier filet de sécurité. Le deuxième étant les tests. Un développeur qui n’écrit pas de tests lorsqu’il écrit du code, n’est pas un développeur. Point à la ligne.

Avec son background, lorsqu’il prend le rôle de Tech Lead en 2007 dans son entreprise il arrive avec son package habituel : Trac et SVN. Comme nous, c’est quelqu’un qui fait du SVN depuis fort, fort, fort longtemps… et il a arrêté.

Le logiciel de sa Startup demande beaucoup de refactoring, à comparer avec la gestion du cycle de vie d’une application en maintenance. Il explique que pour une application avec 2 ou 3 ans de code, il y a des traces dans la neige pour skier. Son souci pour son produit, c’est que tout est à faire. Un peu comme descendre une piste de poudreuse la première fois. Le refactoring est important. Les développeurs ne sont pas toujours d’accord, les discussions fusent… et il commence à souffrir avec SVN.

Il se rend compte d’abord que SVN apporte de la souffrance. Les développeurs travaillent par « micro-commit/micro-merge ». Parfois même, ils font la course l’un, l’autre, afin de commiter avant l’autre… pour éviter le merge ! Cela nous fait rire car il a raison. Donc des commits très fréquents, sans parfois de réel intérêts pour le produit.

Après le micro-merge, il faut ensuite parfois faire des macro-merges. Vous vous dîtes : et les branches SVN ? Et bien tout le monde est d’accord pour dire que SVN traumatise. Faire des branches c’est compliqué. Il faut vraiment être motivé et avoir une personne dédiée pour cela… Quelle perte de temps.

Au final, Sébastien dit que SVN se transforme en outil de copie sophistiqué… pas en gestionnaire de code source. Il ne fait que de l’historisation.

Son souci c’est la valeur livrée. Il faut dire que c’est un passionné de l’Agilité. Il est l’un des organisateurs de la conférence Agile France qui aura lieu le 31 mai et le 1er juin à Paris.

Le but d’une équipe de développement logiciel est de livrer régulièrement de la valeur au client. Un logiciel qui marche, sur lequel il est possible de faire une démo à tout moment. Pour cela, il faut supprimer la douloureuse étape de l’intégration et de la livraison. Cela semble facile, mais c’est très difficile avec SVN.

La solution est simple : faire de l’isolation ! Au lieu d’avoir une vision « version par fichier » ou « vision par répertoire », le principe des DVCS est de travailler sur des petits incréments, sur les différences des fichiers au sens contenu.

Sébastien prévient tout le monde : vous avez fait du SVN ? Le passage à Git, à Mercurial ou à Bazaar sera difficile. J’ai fait mes premiers pas avec Bazaar, sur le framework Play! et c’est simple à comprendre. Le problème est que SVN nous a détruit le cerveau, et qu’il sera difficile de réapprendre.

La première notion importante dont parle Sébastien, c’est la notion de Workflow. Il existe plusieurs Workflows :
- votre manière de commiter à vous, le workflow personnel
- la manière de commiter/merger par rapport à vos collègues (inter-personnel)
- le workflow organisationnel, imposé par le projet ou l’organisation

Le premier intérêt de Git ou Mercurial : comme chacun dispose d’un repository local, avec l’ensemble du projet, vous pourrez commiter à votre rythme, comme vous voulez, localement. C’est votre workflow perso.

Ensuite, lorsque vient le temps d’intégrer, le workflow interpersonnel permet de construire le logiciel en isolant les incréments des autres développeurs, pour construire si j’ai bien compris, la version « commune ».

Les nouveaux workflows apportent du vocabulaire différent. Sébastien et David parlent de Cherry Picking, de la possibilité d’envoyer des patchs facilement, de bosser sur plusieurs repositories…

Dans le monde SVN, quelqu’un qui fait des commits toutes les 10 mn gène ses voisins, qui doivent s’adapter à son Workflow. Dans le monde DVCS ce n’est pas le cas.

La 2eme notion : les DVCS sont orientés contenu. SVN est orienté ChangeSet. DVCS en fait se fiche pas mal des noms des répertoires ou des fichiers. Le principe c’est de travailler sur le contenu et de s’échanger le contenu, pas le contenant.

Pour conclure, Sébastien (dont j’ai résumé ici la présentation) donne les points qui ont changé pour lui :
- Tout d’abord les développeurs sont focalisés sur le code, ils ne perdent pas de temps avec la gestion de source
- Git ou Mercurial sont très souples, et vivent leur vie en dehors de l’organisation, ce qui vous laisse toute la liberté nécessaire pour travailler.
- Les pushs de code se font vers un repo central ou vers le repo de ses voisins par fonction. C’est bien plus logique. Cela ressemble à une copie intelligente du code d’un poste de travail vers l’autre finalement
- Les revues de code sont faciles à faire, et systématique.
- Il est possible de faire des démos à tout moment, car la version commune marche forcément. Les démonstrations se font dès qu’une fonction est livrée.
- Il y a moins de stress dans l’équipe
- Le projet est beaucoup plus stable

Bref Sébastien nous encourage à regarder vers l’avenir et à nous remettre en question. Ce fut une présentation très sympa et bien animée.

II. Git, la gestion de configuration qui vous veut du bien
David Gageot est le CTO d’AlgoDeal.com. C’est un hedge fund qui recrute ses Quants sur Internet en proposant une plateforme de valorisation, pour pouvoir créer des algos de passage d’ordre automatique sur le marché. Le tout avec du Java, des technos sympathiques comme Voldermort par exemple.

Git est un outil de gestion de versions distribué créé par Linus Torvald (note : si tu ne connais pas Linus à 30 ans, tu as raté ta vie). Ecrit en C, c’est un outil bas niveau qui permet de gérer de manière décentralisée le code source d’un projet. En l’occurrence, le noyau Linux. Autant dire que c’est pas un truc de Mickey, et que le système est éprouvé. Mais pour Linux…

David comme Sébastien est très direct : oubliez SVN ! SVN pas bien ! SVN poubelle ! Celui qui fait repousser les cheveux, qui fait revenir l’être aimé, qui vous donne de beaux abdos c’est Git !

Lancé en avril 2005, suite à quelques différents autour de BitKeeper, Git est plutôt bien documenté. David cite le Git Community Book qui a été traduit en Français sur le site d’Alex Girard.

Du côté des outils, Git est fournit avec un client Tcl/Tk. David cite GitX pour Mac OS. Côté Windows il ne semble pas y avoir d’outils très performant pour l’instant.

Personne n’a parlé du support dans IDEA IntelliJ. Dommage car JetBrains explique que Git est supporté sans devoir installer un plugin… comme dans l’autre logiciel là… néclipseu… Enfin bref vous me comprenez.

Pour continuer, David montre 2 fonctions clés de Git qui permettent de gagner du temps. Tout d’abord Git bisect puis ensuite le principe du build incassable.

Git bisect est un script qui permet de retrouver à quel moment votre logiciel a cassé. Pour illustrer cela, il prend un cas vécu : après Noël, il se rend compte que la commande « mvn eclipse:eclipse » ne marche plus sur son projet. En remontant sur d’anciennes versions, il se rend compte que c’est le cas depuis pas mal de temps… Mais impossible de trouver un commit évident.
Grâce à Git bisect, il va pouvoir ressortir les versions antérieurs de son projet, pouvoir lancer son script maven, et détecter quand exactement celui-ci a cassé le build. Ce fut assez bluffant.
La doc de Git Bisect est sur le site kernel.org. Déjà, cela fait plus sérieux qu’un site pingouin.com…

David parle ensuite du build incassable. Ce fut très intéressant. Pour illustrer cela, il nous montre son écran de contrôle Hudson : il est éteint. Et un gros sticker vert affiche « Build is Ok ». Car l’intégration continue de son projet ne casse jamais.

Pour ce faire, lorsqu’un développeur veut commiter, il va utiliser un petit script qui grâce à Git, va préparer une version dans un répertoire de travail sur le poste du développeur. Ensuite, le projet se compile, et si jamais le build fonctionne, alors Git termine le commit vers le serveur central. Et c’est tout !

David explique que dans l’ancien système basé sur SVN, il fallait parfois 11 minutes pour faire un « mvn clean install ». Et souvent, il allait prendre un café avec ses collègues. Aujourd’hui, plus besoin de perdre du temps, et il prend moins de café. Emmanuel Bernard me glisse à l’oreille : « Du coup, Git c’est un peu Anti-Social comme système : tu ne bois plus de café avec tes collègues  » LOL )))

Bref Git c’est pas forcément plus simple, sur Windows ça pique un peu les yeux. Mais qui développe encore sur Windows ?

Fin du show, moi j’ai beaucoup aimé. David redonnera la présentation complète à la conférence Agile France et aussi à l’USI 2010. A ce propos, il reste 3 places pour ceux qui sont intéressés.

Le moment du buffet

Après cette première heure, 220 geeks ont soif. Et lorsque le geek a soif, il descend prendre un verre. Pour l’accueillir : un buffet offert par l’eXpress-Board, le site d’offres d’emplois que j’ai lancé en mars dernier. Pour moi ce fut l’occasion de rencontrer des candidats, des gens intéressés par la partie technique, des annonceurs intéressés comme la société qui fait le lapin Nabaztag, un éditeur de logiciel dans la sécurité, et beaucoup de candidats intéressés. Le message que plusieurs m’ont dit : on veut pouvoir déposer un mini-CV et être contacté. Donc le message est reçu, et je vais travailler sur cette partie. L’une des personnes (Yann je crois) m’a donné quelques idées très sympathiques, bref ce fut très sympa.

Maven 3 et Deploy It
Ben là… désolé Arnaud et Nicolas… désolé Guillaume et Benoît… mais je n’étais pas là. J’ai passé une heure à discuter avec pas mal de monde et je n’ai pas assisté à la suite.

Enfin la 3ème mi-temps fut courte, c’est pas tout mais il y a du boulot.

Conclusion
DVCS et Git, très intéressant. On attend un peu de voir les outils, et de comprendre les concepts, mais cela semble prometteur. En même temps, je pense que SVN sera encore là pour longtemps… comme Java.

Merci aux gars qui étaient là ce soir et qui ont parlé de l’eXpress-Board à leur société. La petite cacahuète de la table 4 c’est Pierre, le méga gros fromage sur la table 1 c’est grâce à Paul, la bonne bouteille de Bordeaux c’est grâce à Geoffrey… Tout cela grâce à tout le monde.

Je crois au concept des annonces distribuées. Si nous devons faire une analogie avec SVN versus Git, voici ce que je dirai : SVN a besoin d’un serveur central pour fonctionner, comme un site d’offres d’emplois classique. Git au contraire vous permet de cloner en local le contenu et de travailler sans devoir subir un Workflow lourd.

Le site l’eXpress-Board c’est exactement pareil : les offres sont disponibles via un flux RSS comme un Blog. Vous pouvez donc les ajouter sur votre Google Reader et suivre celles-ci sans devoir venir sur le site. Vous pouvez même partager ces offres comme autant de billets de blogs sur votre interface Google Reader.

Je crois plus à la force du réseau et au bouche à oreille pour trouver un boulot. Les offres du site ne sont donc que les étincelles qui doivent ensuite amener les candidats à contacter les annonceurs. Enfin vous l’avez compris, en donnant votre avis sur les offres, vous encouragez les annonceurs qui sortent du lot. Et écrire une annonce différente est loin d’être facile.
Je conseille donc aux sociétés qui souhaitent passer une annonce de demander à leurs Geeks et à leurs développeurs. Cela prend 10 minutes, et c’est un projet passionnant.

En fait, si j’étais un responsable RH, je ferai un concours pour que mes gars préparent une annonce. Et ensuite, l’annonce la plus sympa est mise en ligne sur le site. Si un candidat signe et rejoint alors la société, et bien je verserai la prime de cooptation à la personne qui a écrit l’annonce.

C’est tout pour ce soir, à bientôt.

(le bonhomme au milieu c’est moi)

Rendez-vous donc le lundi 18 janvier, de 19h15 à 22h30 dans les locaux de la Sorbonne Paris IV, métro Ligne 3 Malesherbes.
N’oubliez pas de vous inscrire sur le site du Paris JUG.

Sinon le mardi 9 février aura lieu le deuxième anniversaire du Paris JUG avec une soirée exceptionnelle. Nous avons réservé une grande salle et un hall d’exposition, afin d’accueillir tout le monde. Comme vous le savez, les soirées du Paris JUG sont souvent complètes quelques jours avant celles-ci. Cette fois-ci c’est une salle de 500 places, un espace où nous vous offrirons un buffet, et très certainement quelques stands pour des exposants. Marquez-bien cette date dans votre agenda : mardi 9 février, à la Sorbonne aussi.

Retour express
Olivier Croisier de Zenika, auteur du blog « The Coder’s Breakfast » a publié un compte-rendu détaillé, ainsi que Mathieu Petitdent d’Object Direct. Du coup je ne vois pas trop l’utilité de vous resservir le même contenu, donc pas de retour cette fois-ci pour moi.

Emmanuel Bernard au Paris JUG
La soirée a été marquée cependant par la présence d’Emmanuel BERNARD, de JBoss RedHat, pour la première fois. Auteur du livre Hibernate Search in Action, et fondateur du Podcast « Les CastCodeurs« , Emmanuel a surtout annoncé la sortie le 8 octobre dernier d’Hibernate Validator 4.0. Il s’agit tout d’abord de l’implémentation de référence de la JSR-303.

Plutôt que de dupliquer du code de Validation au niveau de la vue, de la base de données ou des services métiers, l’idée de la JSR-303 est de proposer une validation au niveau du POJO. La JSR-314 (JSF 2.0) propose les Validators, mais plutôt que de dupliquer ce code de validation, l’idée de la JSR-303 est de proposer à JSF 2.0 un moteur de validation. De même avec JPA 2.0. A priori en décembre Emmanuel Bernard devrait nous en parler plus précisément, avec des exemples de code. Rendez-vous donc à la fin de cette année.

La troisième et la quatrième mi-temps
Changement de lieu, nous étions au Vavin. Service très pro, ambiance sympa et un peu bruyante. C’est toujours un plaisir de discuter avec tout le monde, de voir des têtes connues de la communauté parisienne, bref très sympa. Si vous voulez un teeshirt dédicacé d’Arnaud Héritier sur Maven2, une casquette JEE6 par Antonio Goncalves, ou un caleçon eXo Platform par Julien Viet, il faut venir au Paris JUG.

A propos des enrouleurs et du kakimono. Mardi soir nous avions 3 grands enrouleurs pour mettre en valeur nos sponsors Platinium. Même si j’ai réalisé les montages avec Adobe Illustrator, c’est grâce à l’aide de Karine VACCA de l’agence 3-2-1 idCom que nous avons eu de beaux enrouleurs, livrés à temps et de bonne qualité. Donc si vous cherchez une agence sympa pour faire de la communicaton, du marketing, organiser un événement comme une formation, ou un séminaire, contactez de ma part 3-2-1 idCom Travail sérieux et professionnel, encore merci pour son aide.

Articles du blog le Touilleur Express connexes
Vous pouvez relire 2 articles sur Emmanuel Bernard :
- Présentation à Jazoon sur Hibernate Search article de juin 2009.
- JSR-303, avez-vous validé votre Bean ? article de juin 2008.

1)Contrôle Qualité avec des outils open-source par François le Droff et Romain Pelisse

Romain Pelisse et François le Droff débutent par une bonne présentation afin passer en revue les outils open-sources. Romain est contributeur du projet PMD et leader du projet XRadar. François est contributeur sur XRadar. Tout d’abord, quelques mots sur la qualité. Mesurer la qualité de son logiciel, c’est d’abord contrôler sa complexité. Lorsque votre logiciel ne fonctionne plus, vous êtes victime d’une tragédie, pas d’une statistique. J’en profite pour vous parler d’un document de 1995 qui ne fait que 8 pages et qui résume plus globalement le Chaos du développement logiciel : The Chaos Report par the Standish Group Report. Bref la qualité c’est fun, et l’on peut même parler de Développement Piloté par la Qualité.

Qui est responsable de la qualité ? Tout le monde. Du développeur au Chef de projet en passant par l’Architecte. Quand ? Tout le temps. La Qualité n’est pas une option que l’on ajoute à posteriori. C’est une démarche qui doit faire partie du cycle de compilation et de déploiement de votre logiciel. Comment mettre en place des outils d’analyse de la qualité ? L’intégration continue est un bon endroit pour mettre en place ces outils. Ce qui est intéressant par contre dans un produit comme SonarJ que l’on verra ensuite, c’est qu’il est possible de mettre en place ces outils dans l’environnement de développement. Un des points forts d’IDEA IntelliJ c’est l’intégration d’un moteur de qualité qui est présent au moment de l’écriture de votre code. C’est bien souvent quelque chose que les développeurs découvrent, alors que finalement cela devrait être obligatoire dans un IDE en 2009.

Il existe différents types d’outils pour l’analyse du code Java. Des outils d’analyse statique, du bytecode, des archives Java et d’autres comme l’analyse de la couverture de tests de votre code. PMD est un moteur d’analyse du code source Java, intégré avec un grand nombre d’IDE. Il permet d’identifier les bugs potentiels, le code mort, le code mal optimisé, le tout avec environ 250 règles. C’est un appareil de radiographie qui vous permet d’analyser du code de manière statique. Mon favori c’est aussi FindBugs, un projet qui ne paye pas de mine mais qui génère des statistiques vraiment intéressantes pour trouver des bugs dans votre code. Les outils d’analyse du bytecode sont un peu moins précis mais permettent de détecter des cas que l’analyse de code source ne peut pas trouver. L’analyse du bytecode permet de générer des métriques de package sur le nombre de classes concrètes, abstraites et publiques. Il permet de détecter les dépendances cycliques, de calculer le degré d’abstraction ou d’instabilité du package. Je pense que le produit XDepend dont je vous ai parlé il y a quelques mois, correspond à cette description. Il y a aussi des outils d’analyse des dépendances. Pratique afin de voir le sac de noeuds de votre projet Maven. Vous pouvez d’ailleurs retrouver une liste des outils d’analyse statique sur Wikipedia si vous cherchez un outil pour du C/C++/Java ou .NET.

En conclusion pour cette première présentation, c’était un sans faute. Rythme parfait, et après 30 minutes nous étions en plein dans le sujet.

La présentation complète est en ligne :

2)Sonar par Olivier Gaudin
Olivier est l’un cofondateur de la société SonarSource, éditeur du logiciel open-source Sonar. Sa présentation était construite autour de la définition des 7 péchés capitaux du développeur, et de la réponse de l’outil Sonar. Sonar permet de collecter, d’analyser et de générer des rapports de la qualité pour la plateforme Java. Intégré à Maven, l’outil permet de mettre en place et de suivre l’évolution dans le temps d’indicateurs de qualité.

Olivier commence sa présentation avec la phrase suivante : « A well-written program is a program where the cost of implementing a feature is constant throughout the program’s lifetime. » de Itay Maman. Ce sera d’ailleurs la même idée qui sera reprise ensuite avec la présentation de SonarJ. L’objectif de Sonar est de proposer un moyen de maîtriser l’érosion technique et de conserver un indicateur de la qualité, capable de remonter dans le temps.

Les métriques d’analyse de la complexité d’un logiciel ne sont pas neuves. La complexité cyclomatique, les standards de programmation, les tests unitaires, en fait tout ceci a bientôt 20 ans. Sonar propose de mesurer, de visualiser, d’agir et de suivre les améliorations dans le temps. Avant de commencer avec Sonar, Olivier appuie le fait qu’il soit indispensable de mettre en place un gestionnaire de code source, un environnement d’intégration continue, un moteur de construction du logiciel maîtrisé comme Maven et un gestionnaire d’incident comme Jira. Quelque part, la gestion des incidents devrait faire partie de Sonar pour moi. Ce serait aussi le moyen de mesurer les progrès réalisés non ?

Les 7 péchés capitaux s’appliquent très bien à ce que nous faisons, nous, les développeurs. Que ce soit l’avarice, l’envie ou la gourmandise, en effet on pense aux non-respect des standards de programmation, à la duplication de code, au manque de tests unitaires, aux mauvais commentaires, aux bugs potentiels, à la complexité du code, bref à tout ce qu’un développeur peut produire. Pour répondre à cela, Sonar propose un tableau de bord avec une vue synthétique plutôt bien pensée. Un indicateur vous donne ainsi le montant de votre dette technique en dollars. Ce montant est calculé si votre équipe devait fixer l’ensemble des problèmes identifiés, avec un prix unitaire par élément. Cela donne une idée du prix de la dette technique de votre logiciel.

Olivier termine par une démonstration de l’interface de Sonar. L’interface est plutôt bien pensée. Les indicateurs radars, les courbes d’évolution, tout ceci nous donne un sentiment de qualité sur le logiciel. Je pense que Sonar est un produit rapide et simple à mettre en oeuvre, et qu’il est dommage de s’en passer si votre projet est déjà en place avec Maven par exemple. La version 2.0 est prévue pour la fin de cette année

3)SonarJ

Frédéric Brachfeld présente ensuite le produit SonarJ, dont la version 5.0 vient justement de sortir. SonarJ est un produit dont j’ai déjà parlé plusieurs fois sur le Touilleur Express (ici et surtout là). C’est un produit qui se résume par une image : une ceinture de sécurité. Il permet de définir des règles d’architecture en se reposant sur le découpage par package Java, mais surtout via un plugin dans Eclipse, de s’assurer que ces règles sont respectées lors de l’édition du code et de la création de nouvelles classes. La démonstration s’est terminée un peu difficilement, ce que je regrette pour Frédéric. Moi j’ai vu ce produit, et j’ai vu une présentation de Frédéric chez mon ancien employeur qui m’avait bluffé. Vraiment l’effet « Wahouu » pendant la démonstration. Ce qu’il faut bien comprendre, c’est que c’est un moyen de rendre plus intelligent votre code source, pour un effort relativement simple. C’est aussi un outil qui vous permet de réorganiser votre code source. J’entendais des gens critiquer la séance de découpage des packages et dire « ouais dans la vraie vie les packages ne sont jamais si bien rangés »… ce qui est tout à fait vrai. Mais justement, cet outil permet de reprendre la main sur un sac de noeuds, il permet de reranger le code. Et surtout, il permet de s’assurer que le code ne redevient pas n’importe quoi en quelques semaines.

J’en parle comme si j’avais des actions chez SonarJ, ce qui n’est pas le cas. J’en parle car j’étais déçu que la démonstration ne se passe pas comme prévu. J’aurais aimé cet effet « Wahouu… ». Testez le produit, c’est le seul qui apporte de la Qualité non pas à posteriori mais à priori. Il vous aide au moment d’écrire votre code, pas une fois qu’il est commité dans Subversion.

Version open-source de SonarJ.

4)Squale
Enfin pour terminer, et là j’ai trouvé que la présentation venait conclure parfaitement la soirée, nous avons eu une présentation de Squale (Software QUALity Enhancement) par Fabrice Bellingard. La démarche du produit est de proposer une offre différente des produits existants. Squale analyse du code Java, du C, du C++ et du Cobol. Le point fort que Fabrice présente dès le début, c’est l’élaboration de modèles évolués. Je m’explique. Plutôt que de définir des métriques à effet de seuil, le moteur travaille avec des métriques linéaires. Là où un produit affiche un carré vert si la méthode doSomething fait 30 lignes, et un carré rouge si celle-ci fait 31 lignes, Squale propose une approche différente en lissant justement cet effet. Cela permet de rendre plus pertinent l’analyse et de donner des résultats plus précis afin de suivre la qualité de votre logiciel.

Squale s’adresse au développeur afin qu’il identifie les zones à risque. Il s’adresse au Chef de projet qui souhaite par exemple contractualiaser un niveau de qualité, et mettre en place des exigences en terme de tests afin de travailler avec un prestataire exterieur. Enfin il s’adresse aux responsables du produit, en offrant des indicateurs de plus haut niveau, afin de donner une idée de la complexité d’une application.

Les métriques dans le développement logiciel sont certainement aussi nombreuses que le nombre de langage existant. Mais l’un des indicateurs qui marche bien, c’est le « WTF per minut ». Lorsque vous lisez du code écrit par quelqu’un d’autre, combien de fois dites-vous à voix haute : « mais c’est quoi ce b… ? ». Plus sérieusement, Fabrice explique par contre que la recherche a validé avec des modèles des axiomes comme « la probabilité d’avoir un bug dans une méthode est proportionnel à la complexité cyclomatique de celle-ci ». Et c’est une des caracteristiques importantes de Squale.

Squale est aussi développé en collaboration avec l’Inria-Futurs de Lille et LIASD-Paris 8. Les modèles de qualité sont donc validés par des chercheurs. De plus, l’entreprise Qualixo qui développe le produit, travaille avec PSA et Air France afin d’utiliser de réels projets pour affiner les modèles. C’est aussi une caractéristique importante du produit.

Après cette présentation, Fabrice a effectué une démonstration du produit. L’approche de l’analyse s’effectue sur 4 niveaux. Tout d’abord la collecte des données brutes, ensuite l’analyse des pratiques (comme les règles de nommage), le respect de critères ensuite et enfin des facteurs qualitatifs comme l’estimation du coût de maintenance. L’interface Web de Squale permet en fait de naviguer dans son projet. Des indicateurs de ROI, en plus des indicateurs classiques de complexité du code, offrent aussi une vue plus pour les managers et les décideurs. Ainsi j’imagine qu’il sera possible de décider de ne pas refactorer un module de code, car sa dette technique est trop élevée.

L’interface gagnerait à être un peu plus jolie, et un ergonome pourrait aussi aider à classer l’information et à proposer un modèle de navigation. Les données par contre et le principe des modèles est le point fort du logiciel Squale. Une bonne présentation qui m’a intéressé, surtout lorsque l’on pense qu’il permet de supprimer cet effet de seuil « bien/pas bien » qui n’est pas très constructif sur les autres outils.

Conclusion
Pour terminer finalement je repense à la première présentation, où faire de la qualité a été expliqué très simplement. C’est pour votre bien, c’est bon et c’est indispensable. Mesurer permet de contrôler, et d’évaluer aussi la quantité de travail en plus de la qualité. Il faut faire de la qualité, mettre en place ces outils sur vos projets.
Post-Scriptum:
1) Alexandre Boutin sur son blog pointe une conférence Agile 2009 sur le thème « Tout d’abord, tuer toutes les métriques » en anglais.
Je cite :

« L’approche proposée est assez intéressante puisqu’il s’agit de regarder les métriques sous un nouvel angle, celui du comportement. Pour chaque métrique il est intéressant de se poser les 3 questions suivantes : En quoi cette métrique génère un comportement positif ? En quoi elle génère un comportement négatif ? Quel type de comportement permet de contourner la métrique ?
Les orateurs ont également insisté sur le fait que le comportement ( »behaviour ») est émergent et changeant, donc ce qui est vrai à un instant ne l’est plus quelques mois après … et donc il faut être prêt à changer de métrique. [...]« 

2) Le Spag est une unité de mesure de la dette technique, présenté par James Shore. Encore merci au blog d’Alexandre qui est très complet.

Avant tout, merci à François le Droff et à Simon Ritter. Assurer une présentation avec un micro bricolé avec un ampli, cela a certainement cassé leur présentation, et on est désolé… La prochaine session se déroulera au Zenith avec Gogo-danseuses, et j’ai proposé que l’on investisse dans un micro HF type casque afin que nos speakers puissent utiliser leur PC tout en parlant. Ne loupez pas la saison 3 du Paris JUG et ses nouveaux épisodes, ça sera mieux.

Adobe Flex, BlazeDS, Spring Flex par François le Droff
François le Droff a un blog que j’ai commencé à lire il y a presque 6 ans, il est d’ailleurs dans la blogoliste en bas à gauche. Il est architecte Java, travaille chez Adobe France en tant que consultant. La présentation de ce soir sera sur les dernières nouveautés de Flex, un tour de LiveCycle Data Services ES, une présentation de Spring Flex et enfin pour terminer une rapide démo de Flash Catalyst. Après un rappel sur Flash, où l’on apprend que près de 700 millions de player flash sont installés, François explique que le moteur de Flash fonctionne avec une VM depuis la version 9, qui est une réécriture très importante du moteur de Flash. Flash 10 apporte encore plus de puissance, le support de fonctions de vidéos avancées, et on retient de cette partie que Flash est maintenant partout. Regardez YouTube! par exemple.

Après une présentation de l’offre d’Adobe, un peu marketing mais il faut bien cela pour comprendre la suite, François axe ensuite sa présentation sur la partie serveur, afin de nous présenter Adobe LiveCycle Data Sercices. Cette suite d’application pour entreprise est l’offre d’Adobe pour créer des applications type Software as a Service, en offrant des services utilisant Flex, PDF mais aussi XML, HTML et Ajax, pour offrir aux clients vos données et des applications riches. L’effort d’Adobe est de présenter des solutions pour que vos données d’entreprise deviennent des services pour vos clients externes sur Internet.

Côté client, 4 technologies : Adobe Acrobat Reader (PDF), Adobe Flash, HTML et Adobe AIR.
Au niveau conteneur de service, le moteur d’Adobe offre différents connecteurs techniques, et donc différents protocoles. Gestion des données, publication de message, générateur de formulaires et de documents PDF, sécurité et signature numérique, bref le socle de service permet d’externaliser les données avec différents formats, en utilisant différents protocoles, plus ou moins optimisé. De l’HTTP, de l’AMF qui est un protocole ouvert et libre, ou encore le protocole RTMP (real time media protocol) qui sont tous ouverts et donc que vous pouvez implémenter librement.

François explique les différences entre la version professionnelle et commerciale, Adobe LiveCycle DS, et le logiciel open-source BlazeDS. BlazeDS est un composant Java déployé du côté serveur qui permet d’exposer à un client type Flex très facilement des données, en offrant une couche d’échanges de messages. Fonctionne avec Adobe Flash Player ou Adobe AIR. BlazeDS permet de pousser des données vers le navigateur ou le client Adobe AIR en utilisant différentes technologies comme COMET ou du simple pooling HTTP. BlazeDS est un WAR que vous ajoutez à votre application pour facilement envoyer et recevoir des messages avec un client Flex.
La version LiveCycle DS offre plus de fonctions d’entreprise, avec le support de la sécurité, moins de limitation sur le nombre de Threads, mais je n’ai pas noté toutes les différences.

François aborde ensuite une partie pour nous, les geeks : Spring et Flex. Je ne vais pas pouvoir reprendre ici tout ce qu’il a montré, mais on retient au final que Flex s’intègre avec Spring de la manière suivante : nouvelles annotations qui vous permettent d’injecter le RemotingMessagingService de BlazeDS dans votre Bean Spring. Passage via la DispatcherServlet de Spring qui se charge de rerouter vers les composants serveurs de BlazeDS ce qui arrive. Je vous recommande de lire par exemple « Intégration de Flex 3, BlazeDS et Spring sous Flex Builder 3 » de Franck Ponchel sur Developpez.com pour comprendre le principe. A lire aussi, le tutorial de Sébastien Arbogast « Flex, Spring, BlazeDS full stack on Adobe Developer Connection« . Updated:Les liens pointent vers des articles de l’ancienne version. L’intégration entre Spring et Adobe Flex va beaucoup plus loin, allez voir plutôt l’article de François qui précise et corrige mes propos. Merci et désolé François !

François nous explique aussi que le compilateur Flex étant open-source, il est très facile d’intégrer maven2 et le compilateur Flex afin d’utiliser par exemple de l’intégration continue pour construire son projet. Il nous montre enfin quelques slides sur SpringFlex, le projet sponsorisé par SpringSource, et qui vous permet d’intégrer Adobe Flex très rapidement dans une application Spring.

En conclusion, une présentation plutôt technique comme nous aimons, nous les geeks. Il y avait quelques parties un peu longues à mon goût, et vue les conditions offertes à François ce n’était pas facile pour lui, et il s’en est bien sorti. Donc si vous faîtes du Flex, allez regardez sur le site communautaire d’Adobe : opensource.adobe.com.

Le buffet, le buffet, le buffet
Il y avait moins de monde ce soir au Paris JUG. 322 personnes selon les organisateurs au Falstaff à la troisième mi-temps, 152 personnes selon la police. Le buffet permet de croiser des têtes connues et de nouvelles personnes.

Venir au Paris JUG c’est aussi avec une relation sociale avec des gens comme vous. Je parle de ceux qui portent des teeshirts « Glassfish and Spring Rulez » et boivent du coca light en trempant une chips dedans avant de vous serrer la main. Le vieux geek se reconnaît à sa belle chemise, son costard, un MacBook Pro et un air fatigué. Il est fatigué car il a codé jusqu’à 4h du matin. Il trempe toujours ses chips dans son coca, c’est comme cela que je les repère lorsqu’en me serrant la main, un mélange de sucre et de sel vient recouvrir mes phalanges (que c’est beau…).

Le commercial a mis une cravate humoristique pour se fondre dans la masse. Il est super content d’être là, il y a une super ambiance, vous êtes super, dis-donc tu connais pas quelqu’un qui cherche une superbe boîte de super service pour super-pas-cher ? Super ! allez on s’appelle !

Le gars qui vous reconnaît car « VouZeteuLeTouyeur » ça c’est cool. J’aime bien. J’aime aussi la variante, plus marrante : le gars qui vous parle du Touilleur mais qui sait pas que c’est vous. C’est marrant.

Y’a le gars qui pense que vous êtes une bête parce que vous avez parlé une fois de Spring AOP sur votre blog. C’est le bonhomme qui m’embarque dans une discussion sur l’AOP et qui parle comme cela :
- Dis-moi le Touilleur, toi qui t’y connais, lorsque je déclare dans mon fichier de conf de bean un auto-proxy, est-ce que je mets bean class ‘égal’ DefaultAdvisorAutoProxyCreator ou pas ?  »
- euh… attends je reprends du coca et des chips »
- Est-ce que le tissage avec AspectJ n’est pas uniquement automatique ?
- (moi obligé de répondre) Spring par la pratique, page 141, je te cite de tête le chapitre : Avec AspectJ le tissage est uniquement automatique. Le seul contrôle dont dispose le développeur est de tisser ou non les aspects à base d’annoation via le tag aop:aspectj-autoproxy. [...] Le bean DefaultAdvisorAutoProxyCreator se déclare comme suit…
<bean class= »org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator »/>
- …gné ?
- « tiens passe moi encore du coca s’il te plait… et des chips…. Demande sinon à Antonio il doit savoir cela »

Donc ne me posez pas des questions de geek, j’en sais rien. Je suis là pour tremper mes chips dans mon coca-light et ensuite allez bénir avec mes mains le maximum de personnes. Qu’on se le dise !

JavaFx par Simon Ritter
Allez j’en garde pour la prochaine fois, je vous raconterai JavaFx un peu plus tard.
Suite au prochain numéro.

[Update 10 juillet]
J’ai remplacé LiveCycle ES par DS, j’ai confondu les deux. Pour plus de détails, et pour voir les slides, François a résumé la présentation, et il a partagé ses slides sur son blog. Merci.

Alors tu t’es inscrit pour la soirée Domain-Driven-Design organisée par le Paris JUG. Tu es arrivé à l’heure, c’est bien. Saches que tu étais 111 personnes ce soir. Qu’il y avait 168 inscrits. Et note cher lecteur que nous avons mobilisé ces 168 personnes en 4 jours. Merci Twitter, merci aux blogs qui ont fait suivre l’information (SFEIR, Xebia, Zenika) et surtour un grand merci à l’EPITA qui nous a reçu.

Antonio a eu vent de la venue d’Eric mardi dernier. Nous en avons discuté mardi soir entre l’équipe, le canal historique (Antonio, David et Zouher) et les dissidents, dit « la Crew » à savoir Tanguy, Charles, José et moi-même. Et motivé comme pas deux, nous voilà engagé pour trouver une salle pour 180 personnes, ce qui fut possible grâce à Tanguy Bayard de SFEIR et Nicolas le Coz de Xebia, ancien de l’EPITA.

Arrivé tôt, me voilà déguisé en videur, pendant que Tanguy colle les affiches partout dans l’EPITA pour guider nos juggeurs vers l’amphi A04. Quand je dis déguisé en videur, je me retrouve à t’accueillir, toi cher Jugeur qui est venu, pas comme les 58 qui n’ont pas pu venir. Cela me permet aussi de démontrer un certain talent à reconnaître les gens, avec un « Salut Laurent » ou un « Salut Claire, Salut Claude » du plus belle effet. C’est ça d’être un bloggeur, à force on connait beaucoup de monde, même si le monde ne vous connaît pas en retour. Le déguisement de videur sans doute… Bref passons.

Début

La séance commence. Soyons un peu plus sérieux pour parler contenu. Eric Evans nous présente ce soir Domain Driven Design. L’objectif de la présentation sera de présenter la conception pilotée par le domaine. Aucuns frameworks, pas de mots techniques, du bon sens comme dit mon voisin du Coder’s Breakfast sur Twitter. Mais du bon sens sacrément intelligent, ce qui vaut le coup de passer 2 heures avec Eric.

Passons rapidement sur le style. C’est vrai qu’il a un côté un peu mou, ce qui rend un peu long la présentation. C’est le fond qui est intéressant. A l’issue de la présentation je suis partagé. Je ne peux pas dire que j’ai été complètement emballé, ce serait faux. J’ai entendu quelques concepts intéressants qui me donnent envie d’aller plus loin.

Eric a écrit un livre de 560 pages appelé « Domain Driven Design, Tackling Complexity in the Heart of Software« . La présentation dure 2 heures. L’article du Touilleur doit faire environ 1500 caractères… Bref tu l’auras compris cher lecteur, il sera difficile de te résumer ici tout ce que j’ai vu. Allez bonne soirée à demain.

Non soyons sérieux… Voici ce que j’ai entendu et que je dois te raconter. La définition du « domaine » pour commencer, est la sphère de connaissance qui influence notre activité d’après Eric. Tout d’abord il explique qu’il faut se faire aider et encadrer d’expert métier pour comprendre le métier, et donc le modèle de votre logiciel.
Il débute la présentation par l’exemple d’un Cargo, qui transporte des containeurs de Hong-Kong vers San Francisco. Il nous demande : comment modéliser ce transport de marchandise ?

La première approche classique, avec une Entité Cargo, est de stocker en base une ligne par parcours. Ce qui l’embête dans cette approche c’est que le Business n’a pas forcément envie d’entendre parler de base de données. Il dit même qu’en travaillant de la sorte, un jour votre MOA débarque avec un schéma de base de données au lieu de vous expliquer le besoin… pas faux.

Soit un Cargo qui a une relation de n « Stop ». Chaque stop a une date de chargement et de déchargement. Ok ce modèle fonctionne. Prenons ensuite un Cargo qui a une Leg, ou parcours. Ce parcours a un point de départ et un point d’arrivée. Cela marche aussi.

Dès le départ, il explique que le modèle dans la conception Objet est une projection déformée de la réalité. Pour illustrer son propos, il prend l’exemple d’une carte du monde. On voit dans le premier slide une carte Chinoise. La Chine est représentée au milieu, le reste autour. Ensuite une projection de Mercator avec les USA en plein milieu. Le message passe : quelque soit le vrai domaine, le domaine objet est une projection qui apporte nécessairement une déformation.

Pour lui, un modèle est donc un système d’abstractions qui peut être utilisé pour résoudre un problème.

Ensuite vient l’utilisabilité. Un modèle n’a de sens que s’il est possible de l’utiliser. Il nous explique qu’il est inutile de tenter de créer un modèle exhaustif, qui sera forcément trop compliqué. Il nous conseille de travailler par itération, et la suite de la présentation va donc s’axer sur la technique de conception de ce modèle.

Tout d’abord posez vous cette question « Qu’est-ce qui est le plus utile ?« . Prenez quelques scénarii réels de votre client pour piloter votre conception. C’est ce qu’il va faire dans la suite de sa démonstration.

Alors vous avez conçu votre Cargo et vos routes, votre bateau est parti de Hong-Kong vers San Francisco. Maintenant prenons le cas où le client décide de changer de destination alors que le bateau est au milieu du Pacifique. Comment votre modèle va-t-il gérer cela ? Il s’avère que le modèle construit sur les Legs (les routes) sera le plus adapté au problème du reroutage là où un modèle conçu avec des « Stops » ne sera pas adapté au changement facile.

Eric Evans en profite alors pour nous parler de ce qu’il appelle « ubiquitous language ». Lors de la conception objet, il nous demande d’utiliser un langage qui sera compris par tout le monde. Pour illustrer cela, il dit : « si demain vous démarrez un projet avec des Indiens, vous êtes d’accord pour parler et écrire uniquement en anglais non ? alors faites de même pour le design de votre modèle : utilisez un langage universel ».

Après avoir vu différents diagrammes, il complexifie encore la chose en ajoutant une troisième demande du métier : « Je veux la route la moins chère ou la route la plus rapide pour mon bateau ». Il reprend le modèle pour nous montrer que rapidement, ce modèle ne sera pas capable de résoudre cette demande. Cela lui permet alors de nous faire prendre conscience de quelque chose : un modèle n’a de sens qu’avec le Contexte qui l’utilise. Le calcul du « plus rapide » ou du « moins cher » se modélise avec des Arcs, des Routes, du calcul par graphe. Rien à voir avec le modèle du transport, un simple modèle père-enfants relativement simple.
Il nous demande alors d’isoler nos modèles selon le contexte, afin de nous garantir de la surcomplexité. De sa propre expérience, la tentation est grande de n’utiliser qu’un seul modèle pour faire tout, ce qui conduit à une architecture pilotée par la technique, au lieu d’une architecture métier.

Le prérequis pour un modèle objet complexe est donc la disponibilité d’experts métiers, une écriture par itération, une définition des frontières du modèle très claire et une définition du contexte pour l’utilisation de ce modèle.

Lors de la séance des questions réponses, il dira qu’en effet le terme « Business Driven Design » est aussi une bonne représentation de ses idées.

Conclusion
Nous restons un peu sur notre faim. D’un point de vue conception, je vous avoue qu’il est très difficile de te retranscrire ici ce que j’ai entendu. A titre personnel j’ai appris ce soir à voir le modèle à sa juste place, avec une prise de conscience du contexte. Ne pas chercher à être exhaustif, à créer des cas d’utilisations qui n’existent pas. Attention à ne pas aussi faire de la modélisation pilotée par la technique. Vous devez être en mesure d’exprimer toutes vos contraintes avec le code.
Il cite pour terminer le framework Qi4J dont Florent Ramière de Jaxio et Sébastien Letélié m’ont déjà parlé. Quand 2 geeks vous parlent d’un sujet, il faut se renseigner. Voir à ce sujet les articles écrits par Sébastien comme celui-ci par exemple.

Off
La soirée se termine, tu rentres chez toi cher lecteur. Cela me permet de discuter avec des têtes connues ou pas, de rencontrer Patrice Lamarque d’eXo Platform et de discuter de la fusion JBoss Portal / eXo Portal, de parler avec Didier Girard d’une idée pour cette été, pour enfin terminer dans une Brasserie avec les Juggeurs, quelques têtes connues comme Eric « Bob » Mignot et Eric Evans.

Il est temps de prendre mon RER A garé en double file, et d’aller dormir. A bientôt, à jeudi soir pour les Scrumistes et au 7 juillet pour les Juggeurs.

La soirée s’est déroulée autour de 3 présentations. Philippe Prados d’Atos Origin, qui publie régulièrement dans différents magazines comme PROgrammez.com ou GNU/Linux Magazine France par exemple. Ensuite Denis Ah-Kang d’Atos Origin, Open Source Center. Et enfin Alexandre Bertails d’Atos Origin, qui a la chance de repasser ce soir après la soirée Web Sémantique du 11 mars dernier.

Les Annotations et la JSR-269

Durant la première partie, Philippe Prados nous a présenté les Annotations en Java 5, puis ensuite la JSR-269 qui permet de créer des Annotations utilisées lors de la compilation du code source vers le bytecode. La JSR-269 « Pluggable Annotation Processing API » est donc une spécification d’annotation qui permet de déclarer des annotations au niveau de la source. Elle ne date pas d’aujourd’hui puisqu’elle est disponible depuis 2006. C’est peut-être inquiétant d’ailleurs de voir que les articles autour de cette spécification ne sont pas très frais comme sur Developpez.com ou TheServerSide.

La présentation était très complète, quoiqu’un peu rapide dans le rythme. Ce que j’ai retenu : ce système d’annotation permet d’ajouter du code comme une interface à une classe existante, il permet en quelques sortes d’écrire des ressources comme un fichier Web.xml automatiquement. C’est donc intéressant dans un premier temps pour la génération de ressources. J’ai ensuite vu une démonstration de génération de code. Difficile de trouver un use-case, de l’aveu même du présentateur. Mais intéressant… pour se dire que cela ressemble un peu trop à de la science-fiction.
Je suis resté plus dubitatif durant la partie sur le pattern Decorator. L’intérêt d’un Dynamix Proxy en Java est justement d’avoir une classe qui implémente des interfaces connues à l’exécution, principe utilisé depuis longtemps en Java… Il faudra que je rédige un truc là-dessus.
A propos des patterns justement, l’un des 23 patterns du Gang Of Four s’appelle Proxy ou Procuration en Français, il appartient à la catégorie patterns structuraux. Le principe de ce pattern est d’envelopper un Objet dans un mandataire et d’utiliser ce mandataire à la place de l’objet original.

Deuxième présentation : java.util.concurrent

Ensuite la deuxième présentation était sur l’api java.util.concurrent. Présenté par Denis Ah-Kang d’Atos Origin. Dans un premier temps, après avoir rappelé les bases de la synchronisation et des problèmes connus en Java, Denis demande la signification de « volatile » à la salle. Grand silence, quelques mains courageuses se lèvent, les réponses arrivent péniblement… ce qui montre aussi que l’on parle d’un mot clé très peu utilisé en Java.
Est-ce que « volatile » n’est pas un mot clé pour indiquer que cette variable est un poulet ? non ce n’est pas cela, dommage José Rien à voir avec la grippe aviaire.
La bonne réponse : le mot clé volatile est un marqueur pour indiquer à la JVM que la variable sera accédée par plusieurs Threads. Par conséquence, la variable ne sera jamais caché dans le cache de chaque Thread, la valeur sera lue à chaque fois par les différentes Threads en mémoire. Et c’est là que l’on apprend que les Threads ont des caches de variables…
Plus intéressant, lorsque vous mettez ce mot clé « volatile », l’accès à la variable sera effectué dans un bloc synchronized utilisant l’instance. Un simple « synchronized(this) » finalement, comme on le voit lorsque l’on décompile le code avec javap (et pas javac).
Sinon quoi d’autre ? volatile s’utilise sur des objets mais aussi sur des variables simples type « int ». Cela permet de rendre atomique par exemple l’incrémentation d’une variable de type « int i++ », car sachez-le, par défaut un simple « i++ » n’est pas atomique en Java…
Denis montre ensuite justement ce cas précis avec un bout de code simple, où l’on constate que les accès concurrents ne s’effectuent pas correctement.

Dans la suite de la présentation il aborde plus le côté API, la JSR-166 de Doug Lea entre autre. Je vous conseille de lire tranquillement sur internet, sur les différents blogs que vous rencontrez, il y a toujours quelques trucs à savoir. On oublie pas les 12 classes du package « java.util.concurrent.atomic » par exemple, qui vous éviterons des soucis de synchronisation par exemple. La documentation sur ce sujet se trouve dans la javadoc de Java 5.

Sinon pour la suite, je vous renvoie au meilleur article du monde entier cité par les plus grands de ce monde, soyons modeste, hop je suis comme cela : Brillez en société avec votre BlockingDeque. Si Asterix et Obelix n’ont pas lu cet article, ils pourront optimiser leur campagne de chasse.

La pause buffet
Le temps de prendre un peu de quoi boire, je croise pas mal de monde. A chaque fois, ces buffets sont trop courts. En fait nous devrions faire des buffets de 3h et une pause avec une présentation de 30 minutes. Qu’en pensez-vous ?
Et si par exemple j’avais envie de ne faire que la présentation #1 pour ensuite discuter et boire un coup avec d’autres personnes ? Ah l’idée ne vient pas de moi, et cela permettrait même de faire entrer les gens qui ne souhaitent assister QUE à la deuxième présentation… Oh là je mets le souk là.
Dites, vous en pensez quoi vous ?

Vous pouvez laisser un commentaire en dessous ?
Je sais qu’il faut s’inscrire sur le Touilleur Express pour soumettre un commentaire. Je fais cela pour deux raisons : éviter le spam bien entendu, et ensuite revendre 3000$ votre adresse à tout le monde. Certaines adresses ne valent pas un clou sois-dit en passant.

Dernière présentation sur le Typage et la Généricité
J’ai du boulot… Alexandre a fait une grosse présentation, une qui demande 3 heures de travail pour restituer le tout. Je vais faire plus court. Alexandre part d’un message passé par Emmanuel Bernard sur Twitter, en galère avec les templates et la généricité. Exemple que je n’ai pas sous les yeux bien entendu.

Petit rappel d’Alexandre, la différence entre le Typage Statique et le typage Dynamique, entre le Type fort et le typage faible, entre l’Heritage et le Sous-Typage, afin de suivre la suite.

Je retiens tout d’abord que bien que Java soit plutôt « Typage Statique », le bytecode généré est du « Typage Dynamique ». Lorsque les Génériques ont été ajouté à la version 5 de Java, le choix de conserver une compatibilité au niveau du bytecode entraîne des choses pas très belles dans le bytecode.

Pour illustrer ce propos, je vais tenter de refaire l’exemple d’Alexandre (je sens que je suis encore parti pour écrire un billet de 10 pages)

Voici tout d’abord un bout de code Java 1.4 simple

import java.util.*;

public class Test {
	public static void main(String args[]) throws Exception {

		List l=new ArrayList();
		l.add(new Integer(123));
		Integer i=(Integer)l.get(0); // notez ici le cast explicite
		System.out.println(i);   // affiche 123

	}
}

Je compile puis je décompile ma classe :

javac Test.java
javap -c Test

Voici le byte code généré :

Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."":()V
   4:	return

public static void main(java.lang.String[])   throws java.lang.Exception;
  Code:
   0:	new	#2; //class java/util/ArrayList
   3:	dup
   4:	invokespecial	#3; //Method java/util/ArrayList."":()V
   7:	astore_1
   8:	aload_1
   9:	new	#4; //class java/lang/Integer
   12:	dup
   13:	bipush	123
   15:	invokespecial	#5; //Method java/lang/Integer."":(I)V
   18:	invokeinterface	#6,  2; //InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
   23:	pop
   24:	aload_1
   25:	iconst_0
   26:	invokeinterface	#7,  2; //InterfaceMethod java/util/List.get:(I)Ljava/lang/Object;
   31:	checkcast	#4; //class java/lang/Integer
   34:	astore_2
   35:	getstatic	#8; //Field java/lang/System.out:Ljava/io/PrintStream;
   38:	aload_2
   39:	invokevirtual	#9; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   42:	return

}

On voit notre constructeur par défaut. Le plus intéressant (alexandre tu me corriges si je me trompe) c’est la ligne 18 lorsque l’on ajoute l’Integer dans la liste. L’ajout dans la liste de l’élément de type Integer s’effectue avec l’appel à l’interface de List, qui ici ne sait pas qu’il s’agit d’un Integer. Tout va bien.
A la ligne 26 on dépile l’élément et à la ligne 31 on s’assure que le type retourné est bien un Integer.

Voyons maintenant la version Java 5 du même code, avec les génériques. Je change la valeur stockée pour enregistrer 456 au lieu de 123, pour le reste vous connaissez.

Le code Java tout d’abord

import java.util.*;

public class Test {
	public static void main(String args[]) throws Exception {

		List<Integer$gt; l=new ArrayList<Integer>();
		l.add(new Integer(456));
		Integer i=l.get(0); // plus besoin de cast
		System.out.println(i);

	}
}

Voyons si vous suviez… regardez ce code et dîtes-moi ce que vous en pensez :

Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."":()V
   4:	return

public static void main(java.lang.String[])   throws java.lang.Exception;
  Code:
   0:	new	#2; //class java/util/ArrayList
   3:	dup
   4:	invokespecial	#3; //Method java/util/ArrayList."":()V
   7:	astore_1
   8:	aload_1
   9:	new	#4; //class java/lang/Integer
   12:	dup
   13:	sipush	456
   16:	invokespecial	#5; //Method java/lang/Integer."":(I)V
   19:	invokeinterface	#6,  2; //InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
   24:	pop
   25:	aload_1
   26:	iconst_0
   27:	invokeinterface	#7,  2; //InterfaceMethod java/util/List.get:(I)Ljava/lang/Object;
   32:	checkcast	#4; //class java/lang/Integer
   35:	astore_2
   36:	getstatic	#8; //Field java/lang/System.out:Ljava/io/PrintStream;
   39:	aload_2
   40:	invokevirtual	#9; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   43:	return

}

A part un sipush au lieu d’un bipush ligne 13… c’est la même chose.

Java 5 et 6 ayant gardé une compatibilité descendante au nivea du bytecode, les Generiques ne sont pas exprimés dans le bytecode. Nous retrouvons simplement un « checkcast » ligne 32 afin de vérifier l’object retourné. Et ce, parce que les types des arguments d’une méthode Java sont invariants. C’est pour cette raison qu’à la ligne 19 l’ajout dans la liste est générique, on ajoute un Object dans la liste.

Ce que l’on retiendra donc : les génériques sont là pour nous aider lors de l’écriture du code, mais au final dans le bytecode, on retrouve les mécanismes de cast pour vérifier le type. Intéressant non ?

Alexandre aborde ensuite des sujets comme la JSR-303 « Bean Validation » qui souhaite ajouter des validateurs sur les POJO. Par exemple, une annotation @NonNull. J’en ai parlé il y a un an exactement sur le Touilleur Express dans cet article si cela vous intéresse.

Avec ce que vous avez lu plus haut, et je pense qu’Emmanuel Bernard nous expliquerait cela certainement mieux, comment sera implémenter ce @NonNull dans le bytecode ?
Je pense simplement avec du code que nous aurions écrit autrement, avec un if(objArg!=null)… L’implémentation de ces annotations utilise-t-elle la JSR-269 que nous avons vu au début ? Ou utilise-t-elle un moteur d’enrichissement du bytecode comme ASM ou BCEL ?

Lisez les articles très intéressants sur le blog d’Emmanuel Bernard :
- Constraint composition proposal in Bean Validation (JSR 303)
- Bean Validation (JSR 303) hits proposed final draft

La conclusion d’Alexandre est que les quelques soucis de Typages dans Java font que des langages dynamiques comme Groovy (qui génère du bytecode java) ont le vent en poupe. Alexandre est un fan de Scala, où les problèmes de typages sont résolus dans le langage et où le typage statique est utilisé à sa juste valeur.

Je m’arrête là car il est impossible de tout restituer ici sur le blog, vous verrez la présentation en vidéo dès que nous aurons terminé le montage.

La conclusion de la soirée
Lors de la troisième mi-temps au Falstaff, nous avons finalement pas mal discuté entre les personnes qui font parties de l’organisation du Paris JUG. Je vous laisse quelques photos et aussi quelques vidéos. Spéciale dédicace pour Denis et ses problèmes de « Queue ».

Pour terminer quelques photos et une petite vidéo faite à l’arrache :

A bientôt

PS: dédicace à ma mon épouse qui rentre de l’assemblée générale des copropriétaires pendant que je blogue…

La deuxième partie de la soirée a été animée par Guillaume Bodet, Directeur Technique de Xebia. L’objectif de la présentation est de répondre aux questions souvent posées par les clients que Guillaume rencontre, lors de la mise en place de Scrum. Le plan de la présentation :
- Trouver le product owner
- D’où vient le product backlog ?
- Et mon planning ?
- Mon projet est trop gros !
- Et l’architecture alors ?

Dans un premier temps, la difficulté est de trouver le Product Owner. Rappel de la théorie : il est le propriétaire du produit, il doit porter la vision du produit, il est en charge du ROI, du budget et du planning de livraison. Guillaume présente le meilleur Product Owner au monde : Steve Jobs !
Mais comment faire lorsqu’on a pas un Steve Jobs sous la main ? Tout d’abord il n’est pas forcément seul. Il doit par contre être responsable de tout et avoir une vision de ce que le projet ou le produit doit être.
Guillaume liste dans un slide une liste des rôles existants dans les structures qui font de bons product owner :
- Chez les Editeurs de Logiciels -> Responsable Produit
- Web -> Le Directeur Marketing
- Banque -> Chef de projet utilisateurs
- Industrie -> AMOA + users groups

Guillaume Bodet aborde ensuite le Product Backlog. D’où vient ce PB ? Selon la littérature Agile, il émerge un peu par magie, sans finalement donner des repères assez solides pour commencer. Par son expérience, il explique que le démarrage d’un projet peut se faire avec un document d’une dizaine de pages, avec des critères d’estimation de la taille du projet, une présentation du ROI, l’évaluation du risque et la définition d’une équipe. Lorsqu’il explique cela, je pense alors à un Business Plan. C’est clairement un document synthétique qui donne la vision d’un projet d’entreprise, qui présente la partie budget, les équipes, sans chercher à définir en détails le produit.
Il explique ensuite que les équipes de Xebia mettent en place des spécifications exécutables (TDD,TDR) afin d’aider le client à formaliser ses demandes. Contrairement à une idée reçue, Scrum ne supprime pas les documents de spécifications techniques ou fonctionnelles. Simplement, on cherche à être moins exhaustif sur les points qui ne seront pas développés en premier.

Le planning est important. Nous devons rendre compte de l’avancement. Il nous explique tout d’abord ce que les chefs de projets font en principe avec Microsoft Project et les diagrammes de Gantt. L’objectif d’un diagramme de Gantt est d’effectuer un ordonnancement des tâches, afin de communiquer un planning. C’est ensuite un outil qui permet d’assurer le suivi de l’avancement. Il parle d’un dérapage souvent rencontré en conduite de projet :
- vous définissez avec beaucoup d’efforts un planning type diagramme Gantt
- chaque jour vous collectez le temps passé par chacun des développeurs. Problème : que se passe-t-il lorsque le temps estimé déborde ? vous devez alors réadapter le diagramme afin de faire « rentrer » cette mise à jour
- vous perdez du temps pendant une heure à remettre à jour ce diagramme, pendant ce temps là vous ne faites rien de productif
- ensuite vous êtes débordé, donc un assistant chef de projet se charge de mettre à jour ce machin. Bravo vous faites preuve de délégation.

Bref le planning classique est parfois une souffrance, voire une grosse perte de temps. A cela, l’Agile répond : on ne fait pas de planning, ce qui n’est pas forcément mieux. Guillaume explique que scrum propose de faire des plannings de release, afin de s’assurer que le développement d’un produit ou d’un logiciel suit une roadmap, respecte la vision du product owner.

Guillaume parle aussi parfois de nous, praticiens de Scrum, qui tentont de vendre le Burndown Chart comme une prévision de l’avenir… ce qui n’est pas le cas. Il explique que c’est un outil destiné avant tout à faciliter la communication entre le Product Owner et l’équipe, ni plus ni moins. Pour terminer, j’ai apprecié sa vision de la plannification. Il y a 5 niveaux de plannification :
- au niveau quotidien, défini lors du stand-up meeting du matin
- au niveau de l’itération (sprint planning)
- au niveau de la release (release planning)
- au niveau de la vision du produit (roadmap)
- au niveau de la vision annuelle

Il rappelle qu’un plan fixe des objectifs, la planification permet ensuite d’adapter ce plan à la vraie vie. Pour preuves, il parle de la démarche d’Einsenhower, général durant la 2ème guerre mondiale et 34ème président des Etats-unis qui a juste réussi le plus gros projet de notre histoire : l’opération Overlord.

Les estimations et la plannification : c’est un sujet qui me passionne. J’ai bien aimé l’évocation de Cocomo II mais bon, il y a d’autres méthodes moins hype, je vous prépare un billet sur ce que je suis entrain de faire avec mon équipe en ce moment.
J’en profite pour vous proposer de relire un billet de décembre dernier : Devoxx les estimations de temps.

Ensuite Guillaume parle du cas des projets qui ne pourraient pas faire de Scrum car « ils sont trop gros »
Il partage tout d’abord l’expérience du Projet ProRail PUB, la refonte du SI du système des chemins de fer hollandais. Avec un budget supérieur au million, 25 personnes ont réalisé en 8 mois une première version. La v1 était opérationnelle. De nouvelles versions continues à être mise en production tous les 3 mois. Les gros projets se divisent en plusieurs équipes. La mise en place de Scrum of Scrum permet de coordonner le développement d’une plateforme. C’est donc possible, en conservant une taille respectable d’équipe (<15 personnes).

L’architecture ensuite est importante. Il casse le mythe des Agilistes qui vous disent que « l’architecture émerge » tel un iceberg… C’est faux. C’est au prix d’un travail d’analyse, de spécifications, d’études de faisabilité que les projets se construisent une architecture. Il a une pensée émue aussi pour les équipes d’Architecture transverse qui sont parfois déconnectées des équipes de terrain. Un architecte internet doit faire partie d’une équipe Scrum. L’architecture se pilote par le besoin, comme dit Scott Ambler. La modélisation doit se faire à plusieurs, il ne faut pas laisser à une seule personne le soin de décider d’une architecture : c’est bien trop dangereux. Enfin il rappelle l’importance de rester simple (et humble) et de penser qu’il est plus important de livrer un produit qui fonctionne, qu’une documentation exhaustive qui ne fait pas gagner d’argent.

En conclusion, j’ai trouvé que la présentation de Guillaume complétait bien la première partie.

Merci à l’équipe du Paris JUG de nous avoir donné l’occasion de faire 2 heures sur Scrum et les méthodes Agile !

Annonces et informations
En début de soirée, Tanguy Bayard a fait une présentation de 10 minutes vraiment sympa. Il a présenté le principe du Paris JUG à l’équipe de direction de SFEIR. Grâce à lui, SFEIR est devenu sponsor annuel du Paris JUG ! Franchement bravo et merci à SFEIR.

Oxiane est aussi un nouveau sponsor, vous pouvez lire leur blog très sympa, merci à Gabriel Kastenbaum.

Enfin Antonio a parlé du podcast « Les Cast Codeurs » dont je vous parlerai dans un autre billet.

The 3ème mi-temps
Enfin en 3ème partie de soirée, entouré de Florent Ramière, de David Gagot, de Jean-Michel Bea, de Sébastien Douche, de Cyrille Leclerc et de Thomas nous avons pas mal discuté de Google App Engine. Je pense qu’il y a beaucoup de restrictions et que de parler de Java alors qu’il y a tant de limitations, c’est un point important à ne pas négliger. David explique qu’en même temps nous parlons d’une version béta de ce support. Qu’avec le temps d’ici 6 mois nous aurons aussi apprivoisé ce nouveau système. Je demande à Florent si pour SpringFuse il serait prêt à basculer d’Amazon EC2 à Google App Engine (GAE). A vue de nez oui, maintenant en perdant une base de données ou un système de fichier, cela fonctionnera en utilisant le moteur BigTable. Il va y réfléchir, même si ce serait plus pour tester que pour vraiment s’en servir.
David et Florent parlent ensuite de Mockito versus EasyMock, après une discussion sur Citcon très intéressante. C’est sans doute la bonne bière qui m’a aussi convaincu de m’inscrire pour mi septembre ! Avec Thomas et Florent nous parlons aussi pas mal sur Google et le dernier Barcamp. Florent parle aussi des premiers retours des clients de SpringFuse, avec un démarrage très fort sur un gros projet entre autre.

Enfin voilà, fin de la 14ème soirée du Paris JUG. L’occasion encore de discuter entre geeks et passionnés, de voir que presque 200 personnes sont venues nous écouter présenter Scrum avec Eric.

Eric, merci à toi d’être venu. Départ le lendemain pour Bordeaux, tu étais la semaine dernière au Canada, je sais que tu bouges beaucoup mais merci d’être passé nous parler de Scrum.

Je vous prépare un podcast avec l’enregistrement de la soirée avec mon histoire de machine à laver

Pierre lit comme chaque matin le blog le Touilleur Express, une tasse de café à la main :

Un rapide tour des différents acteurs du marché de notre secteur montre que les pages de recrutement sont encore plutôt bien remplies. OCTO Technology a publié un communiqué de presse le 30 mars dernier afin d’annoncer le désir de recruter jusqu’à 40 personnes (sur 100 collaborateurs actuellement) d’ici à fin 2009. La crise actuelle ne nous a pas fait oublier ce qu’il se passait il y a deux ans : les profils Java avec 2 à 4 ans d’expérience étaient rares et difficiles à intéresser. Quand le marché se tend, c’est aussi l’occasion de ré-équilibrer la relation candidat-employeur. Il y a deux ou trois ans, nous parlions de speed-dating, de soirée Poker afin de séduire des candidats. Aujourd’hui le vent a tourné.

Il est bien gentil, mais je ne trouve pas grand chose de neuf pour lancer ma chasse… Notre entreprise a décidé de se repositionner sur la plateforme Java. Nous souhaitons profiter de ce début d’année afin d’engager rapidement 3 développeurs Java.
Je prends mon cahier et commence à lister mes pistes pour trouver quelques potentiels :
- cooptation et réseau d’anciens
- réseaux sociaux
- annonce sur sites classiques comme Monster.fr
- chasseur de tête
- …

Ok, voyons d’abord la cooptation.
Le plan chez nous est que chaque salarié touche jusqu’à 2000 EUR, si son coopté passe avec succès la période d’essai. L’an passé sur nos 550 collaborateurs nous avons ainsi recruté… attendez où est ce powerpoint ? ah c’est là !!! 4 personnes.

Bon pas un franc succès… Que raconte le Touilleur là dessus ?

[...] Ce réseau quelque part je le trouve assez plat. Avez-vous envie de recruter 2 Paul Durand promo 97 ? pas forcément. Du côté des anciens collègues, le mercato entre SSII est « réglementé ». Afin de suivre un système éthique, les acteurs des différents cabinets responsables s’accordent afin de ne pas se piquer les consultants les uns les autres. Il est donc parfois difficile de contacter d’anciens collègues [...]

Bref je peux faire passer un email en interne afin de relancer la machine, peut-être organiser un concours et faire gagner une participation à un salon professionnel… A réflechir…. Je mets donc 4×2000 = 8000 EUR de budget sur la première ligne de mon cahier et je passe à la suivante.

Les réseaux sociaux…

Mes assistantes de recrutement sont toutes inscrites sur Viadeo, LinkedIn, MySpaces, Facebook… mais je trouve que le résultat ne va pas dans mon sens : RECRUTER ! L’an passé nous avons par contre décidé d’utiliser systématiquement Viadeo et LinkedIn pour « profiler » nos candidats, détecter et valider les profils. Je ne me suis pas privé de téléphoner à quelques personnes de mon réseau pour me renseigner sur mes candidats, ce qui m’a aussi permis de repêcher des profils mal vendus sur LinkedIn…
Dingue comment cet outil peut être aussi tranchant lorsqu’il est mal utilisé.

Le deuxième souci c’est que mon réseau ne voit pas ces candidats. Nous avons beaucoup de mal à nous connecter à eux. En effet, moi j’ai mis mes amis DRH du réseau « DRH User Group » mais à part eux, j’avoue que je n’ai pas de contacts intéressants…

Bon je mets 0 candidat directement, par contre je prends un abonnement professionnel à Viadeo et LinkedIn pour toute l’équipe, hop, 5000 EUR.

Voyons ce que dit le Touilleur ensuite sur les annonces classiques sur Monster.fr ou Lesjeudi.com….

[...] Les annonces sur les sites classiques me font penser à du chalutage en règle. Une campagne de 15 jours coûte 560 EUR pour une seule annonce sur Monster.fr en mars 2009. Pour ce prix, avec quelques mots clés bateaux comme J2EE et Struts, vous êtes certain en tant que recruteur de ramasser un peu tout ce qui traine. Pas de soucis ensuite si vous pouvez recevoir 50 CV, peut-être plus aujourd’hui, et que vous avez moyen de trier rapidement les poissons…

Ah.
Mais d’où il sort ces chiffres ? aaah je vois cela sur la page Entreprise de Monster.fr Bigre il a raison…
Voyons si je mets 3 annonces pour 30 jours… 1515 EUR HT.
Ok je note cela dans ma ligne, c’est le prix.

Là où il a raison c’est le coût caché. Je me souviens l’an passé, nous avons publié une annonce mal rédigée par un chef de projet débordé. Il avait mis Sturts au lieu de Struts… Nous ne savions pas que c’était pas bon… Hop une annonce pour rien. Et cette autre annonce où nous avons reçu un nombre impressionnant de CV, c’est le travail de Sandrine à plein temps… Appeler les candidats qui ont trouvé entre temps, vérifier les CV, les références… Et au final je ne suis toujours pas certain de trouver les meilleurs candidats.

Rien sur les chasseurs de têtes… Mais est-ce que je suis prêt à payer une chasse pour 3 profils de développeur Java ? Voyons combien m’avait coûté la chasse de ce chef d’équipe. Salaire annuel : 75 000 EUR avec primes, et nous avions versé 10% au chasseur, soit 7500. C’est un excellent élément mais je ne suis pas certain de pouvoir faire la même chose pour 3 candidats, avec une fourchette de salaire allant de 35 à 55 k EUR…
J’abandonne cette idée.

Bon que raconte le Touilleur Express ?

[...] les recrutements seront peut-être moins dynamiques, mais nous sortons d’une période qui était exceptionnelle. Il faut donc continuer à renforcer son CV et à se faire connaître des recruteurs en venant par exemple au Paris JUG.
A mardi prochain !

Bon, j’avoue que je n’ai toujours pas trouvé de nouvelles idées pour recruter. Je vais essayer de contacter Nicolas pour voir…

- Salut Nicolas, c’est Pierre de GrosEditeurQueTuConnais,
- Salut Pierre
[longues discussions sur pleins de sujets]
- Et sinon, tu as des idées pour trouver de nouveaux candidats ? des gens bons en Java, sympathiques, motivés ?
- Et bien tu as la réponse à la fin de l’article, relis-bien
- … désolé je ne vois pas
- Paris JUG
- … ?
- C’est une association qui permet à des passionnés de Java de se retrouver chaque mois, qui fonctionne grâce à des sponsors.
- Et en quoi cela va-t-il m’aider moi GrosEditeurQueToutLeMondeConnais ?
- Tu peux te faire connaître de la communauté, avec un budget raisonnable tu peux avoir accès aux personnes les plus geeks de la communauté Java, qui elles-mêmes connaissent d’autres personnes
- Bah si c’est pour payer de la bière à 10 personnes
- Pas du tout, c’est très sérieux. Il y a plus de 180 personnes à chaque fois, les réunions sur Paris sont courues par le tout-paris, les geeks les plus connus de la communauté open-source Java.
- Comment cela fonctionne-t-il ?
- Tu peux devenir sponsor à l’année. J’ai en tête le cabinet Zenika qui s’est fait connaître au même niveau que Xebia ou Valtech par exemple, et qui organise aussi ses événements
- … et si je souhaite simplement participer une fois ?
- et bien tu peux devenir sponsor de la soirée seulement. Cela te permet déjà de communiquer.
- Wow… et ça marche ?
- Je ne dis pas que ça fait repousser les cheveux, mais tu as accès à une mine d’or, que peu de personnes connaissent… Ensuite à toi aussi de participer et de proposer à tes équipes de faire une présentation par exemple
- Ok, je contacte qui maintenant ?
- Tu envoies un email à team@parisjug.org de ma part ou sinon sur le site du ParisJUG
- Merci Nicolas !
- De rien !

La semaine suivante à Paris aura lieu l’inauguration du French Scrum User Group. Le French SUG est une nouvelle association libre et ouverte à tous. Elle a pour objectif la promotion des pratiques de Scrum en France. Jeudi 19 mars, la soirée inaugurale sera placée sous le parrainage exceptionnel de Jeff Sutherland, l’un des cofondateurs de Scrum. 

Les détails de la soirée sont sur la page MeetUp. Il y a déjà plus de 130 personnes inscrites, ce qui promet un événement exceptionnel. Enfin avec 250 personnes inscrites sur le groupe MeetUp, c’est un vrai plébiscite. 

A mardi ou à  jeudi prochain pour ceux qui lisent le Touilleur Express.