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

Les thèmes de la soirée : Spring Test Driven Development présenté par Octo, puis ensuite présentation de Spring Source, Spring Security 2 et de SpringSource Application Platform par Julien Dubois et Michaël Isvy de la société SpringSource France.

Après une introduction par Antonio, qui rappelle l’importance des sponsors pour le ParisJUG, Jean-François Hélie et Christian Blavier s’installent pour la démonstration du développement piloté par test sur Spring 2.5. Test Driven Development en anglais dans le texte.
Le projet sera le suivant : écrire en 45 minutes une application de Blog simple capable de lister et poster des articles. Jean-François est aux commandes d’Eclipse sur son MacBook (yeah Mac rulez…) et Christian fait les commentaires. Jeff a réalisé un exercice loin d’être évident devant tant de monde : il a codé sous nos yeux l’application en appliquant simplement les principes du TDD.

Christian explique que l’on commence par un test JUnit qui nous sert de cahier des charges. Dans ce test, le nom de la méthode exprime l’intention que l’on souhaite développer. En l’occurrence pour ce premier test, une méthode « shouldListArticles » si ma mémoire est bonne. Pour cela, Jean-François implémente un BlogDAOTest dans lequel il place son premier test. Ce que l’on voit est très technique. Un interlocuteur dans la salle qui n’est pas développeur décroche forcément. En même temps je me dis que c’est un excellent moyen de montrer à une personne peut-être moins technique cette méthode d’implémentation pilotée par les tests.

Impossible ici de reprendre le code complet de Jean-François. En une petite heure il aura écrit un DAO, un bean BlogService et son test et enfin un BlogController avec son test. L’accès à la base de données Hypersonic s’effectue à travers Hibernate. La partie rendu web est gérée par Spring MVC.

Du côté des tests, nous avons vu que Spring permet d’alléger la quantité de code à écrire, en particulier dans la partie « plomberie ». Quelques annotations comme @InjectIntoByType, @Mock, @TestedObject, @Service ou @Repository permettent de marquer le code et d’écrire des tests d’intégration simplement.
Nous avons vu l’utilisation de bouchon dans les tests. Jean-François parle d’Unitils (http://www.unitils.org/). Cette librairie open-source de tests unitaires facilite l’écriture de tests unitaires et d’intégrations. En particulier lorsque vous souhaitez tester des DAO sans faire d’accès à la base de données.

Durant la présentation, je pense à Seam. En fait je m’imagine à la place de Jean-François entrain de réaliser exactement le même exercice avec Seam Framework (JBoss Seam). La chose qui manque pour l’instant à Spring c’est une couche de rendu Web plus puissante. C’est ce qu’offre déjà Seam avec l’intégration d’IceFaces et de RichFaces, ainsi que de Facelets pour la gestion propre des pages. Cependant Julien Dubois expliquera plus tard dans la soirée qu’il y a des projets chez Spring afin d’y intégrer un moteur Ajax puissant d’ici à la fin de cette année. J’ai vu que Spring Web Flow propose une intégration avec JSF, ce qui en fait répond à mes interrogations.

En conclusion pour cette partie, avant tout bravo à Jean-François et Christian. La présentation était pointue, concrète et donne envie de suivre ce chemin pour l’implémentation d’applications webs autour de Spring 2.5

Après un petit break d’une quinzaine de minutes où j’ai croisé pas mal de monde, Julien Dubois et Michaël Isvy de SpringSource ont pris la parole. Julien est responsable de SpringSource pour la France et membre de l’OSSGTP. Il est aussi le coauteur de « Spring par la pratique » aux éditions Eyrolles dont j’ai parlé dans plusieurs articles sur le Touilleur. Michaël Isvy est formateur et consultant chez SpringSource, ainsi que contributeur sur Spring Security 2.

Spring c’est 2.5 millions de téléchargement par mois. Les offres d’emplois avec « Spring » dépassent les offres purement J2EE aux USA. Julien résume assez bien la philosophie de Spring : « dites-nous de quoi vous avez besoin, nous vous le fournirons » qui tranche un peu avec « voilà tout ce que vous pouvez faire, à vous de ne prendre que ce dont vous avez besoin ». D’ailleurs un excellent petit clin d’œil aux « vieux » éditeurs J2EE qui vivent d’une rente établie en 2000 avec l’architecture J2EE EJB 2.1. J’ai vu deux personnes de BEA dans la salle qui rigolaient et qui donc semblaient d’accord. Et j’ai gagné un superbe tee-shirt dans la série questions-réponses sur Spring.

Ce matin sur Monster.fr j’ai fait un test assez simple. J’ai tapé simplement un mot clé sur la zone de recherche et j’ai listé les résultats.
Dites-moi ce que vous en pensez :

Mot clé Nombre d’offre d’emplois affichés :

Spring..............145
EJB..................84
Seam..................1
JBoss................83
J2EE................634
Websphere...........201
TDD...................2
RIA..................11
Weblogic............157
.NET................600
Java...............1097
C++.................609
Scrum................17
Agile................48

Source: Le Touilleur Express sur Monster.fr mercredi 11 juin 2008

Premier constat : il y a plus d’offres d’emploi contenant le mot clé Spring que le mot clé EJB sur Monster.fr. On constate que Java arrive en tête devant .NET, ce qui me rassure et me fait très plaisir. J’aime bien .NET mais si vous voulez, mon truc c’est plutôt Java.

Après la présentation de la société SpringSource, qui assure des formations, du support et des missions de consulting en France, Michaël Isvy présente Spring Security 2. Première information pour moi, béotien de Spring pour l’instant, c’est que Spring Security 2 était connu sous le nom de… Acegi Security 1.0. Spring Security 2 c’est donc Acegi 2 si vous voulez.
Ce module de Spring couvre les manques de l’architecture J2EE actuelle sur la sécurité sans cependant introduire des dépendances avec un serveur d’application. Spring Security est développé par Ben ALEX et Luke TAYLOR. La version 2.0.2 est sortie le 5 juin dernier. Parmi les fonctionnalités de Spring Security j’ai noté
- support de l’authentification par cookie
- possibilité de bloquer 2 authentifications simultanées avec le même profil
- Support d’OpenID (Google, SUN, IBM…)
- Support de la JSR 250 (EJB3) et donc de la partie sécurité des EJB 3.
- WS-Security pour les Web Services

Voir le site pour plus de détails : http://static.springframework.org/spring-security/site/
Nous avons vu quelques exemples qui donnent envie de s’intéresser à Spring Security 2 pour les applications webs.

Ensuite Julien a présenté SpringSource Application Platform. Il s’agit d’un moteur d’exécution (PAS d’un serveur d’application) basé sur Tomcat, Spring et OSGi. Il permet de faire fonctionner une application Spring en utilisant le moteur de modules d’OSGi. D’ailleurs j’ai noté un jeu de mots de julien « OS-JEE-Aïe… » pour OSGi.

A mon sens c’est une grosse annonce, un gros projet et qui va faire bouger l’écosystème des éditeurs J2EE. S2AP (SpringSource Application Platform) a décidé de prendre le système de modules d’OSGi car celui-ci est mature et c’est ce que le marché demande.

Julien Dubois explique ensuite qu’entre les membres d’OSGi et les membres de la JSR 277, il y a des discussions assez franches. La spécification JSR 277 porte sur Java Module System. La JSR 316 de JEE6 regroupe 27 spécifications comme l’explique Antonio. Les discussions portent sur le fait qu’OSGi qui est aussi une JSR et la JSR 277, certaines parties sont identiques. OSGi est déjà en production puisqu’Eclipse s’en sert alors que la JSR 277 est encore en phase de définition. Julien explique que le Java Community Process (JCP) n’est pas le seul groupe à avoir le droit de faire des spécifications contrairement à ce que l’on pense. La fondation OSGi est aussi autorisée à proposer ses propres spécifications. C’est ce qu’elle a fait avec la JSR 291 justement… Et cela provoque des frictions entre les 2 groupes d’expert de chacune de ces 2 JSR.

SpringSource Application Framework met un coup de pied dans la fourmilière. Sa licence GPL v3 provoque des débats riches et passionnés dans la communauté Spring. Julien explique cependant que même si la licence est GPL v3, une application web déployée sur le conteneur S2AP n’est pas obligée de devenir GPL à son tour. C’est clairement expliqué dans la GPL v3. Un site internet qui tourne sur un serveur GPL v3 n’est pas obligé d’être lui-même en GPL. Par contre, un développement pour ajouter une fonction particulière à un serveur d’application ne pourra pas être propriétaire et doit être rendu à la communauté open-source. J’avoue que je suis perplexe mais que je pense que tout ceci est plutôt positif pour nous, en tant que développeur et intégrateur. N’étant pas moi non plu avocat, je ne m’avancerai pas trop dans le débat pour l’instant.

Sinon pour continuer, j’ai lu sur InfoQ que l’an passé, Sun a voté contre la JSR-291 (OSGi) et propose de prendre la JSR-277 qui quoique plus ancienne, est encore en phase béta. La JSR-291 est en production, la 4ème implémentation de référence est disponible. Si vous codez avec Eclipse, vous vous en servez sans le savoir. Cependant Sun (enfin une partie de Sun) soutient la JSR-277 car celle-ci propose une modularisation au niveau de Java SE lui-même, là où la JSR-291 se présente comme un module fonctionnel à la maven en quelques sortes. Il semble aussi que les membres de l’OSGi sont assez inquiets ou furieux que la JSR-277 ne reprenne pas stricto sensu leurs idées déjà implémentées dans OSGi…

J’imagine que si l’expert group de JPA n’avait pas travaillé avec Hibernate, que la spécification WebBeans n’était pas la suite de SeamFramework, nous aurions les mêmes discussions animées. Mais au-delà de ces discussions, le fait que Spring propose en plus maintenant un vrai serveur basé sur OSGi fait que l’on risque un schisme entre les pro-JSR277-SUN et les pro-JSR291-OSGi-Spring…

Les dernières discussions chaudes du côté de la JSR-277 : Peter Kriens membre de la JSR-277 explique que SUN pilote dans son coin cette spécification et que l’Expert Group de la JSR est là pour valider à postériori, sans aucuns débats. Il explique que la proposition des modules Java (JAM) n’est pas une bonne proposition et qu’il serait plus logique de reprendre les propositions de la JSR-291… Ambiance…
(voir http://www.infoq.com/news/2008/05/jsr277-osgi)

Bon pour revenir à nos moutons, car là je m’éloigne, Julien a expliqué que S2AP propose un système modulaire (OSGi donc) qui permet à un développeur de ne redéployer qu’une partie de son application. Par exemple il sera possible de ne mettre à jour que le Contrôleur d’une application Web, sans devoir mettre à jour le reste de l’application. Cela répond à des besoins exprimés par les développeurs : facilité de déploiement, moins d’attente et possibilité en production de changer à chaud qu’une partie de l’application. En effet c’est un vrai cas industriel, même si les développeurs dans la salle semblaient sceptiques. Bon j’avoue que chez nous c’est encore l’âge de pierre, et que l’histoire de ne changer qu’une partie de l’application, j’attends de voir. Certains développeurs fonctionnels ne savent pas se servir de Weblogic ou compiler en mode « exploded » pour travailler avec un JBoss. Par contre je vous explique une chose : ils vous mettent une petite claque en finance et en modélisation des données du marché. Donc chacun son boulot. Mais du coup, j’avoue être sceptique pour l’histoire de « je ne déploie qu’une partie de mon code qui a changé » même si cela semble plus simple. Julien explique que nous pourrons arrêter à jouer à la sauce de JAR dans le WAR pour faire tout et n’importe quoi.

La beauté de S2AP est qu’il n’y aura pas de dépendances dans notre code sur OSGi. La complexité d’OSGi est gérée par S2AP. Nous nous concentrons sur le code métier et pas sur la plomberie. « Dites-nous de quoi vous avez besoin et on s’en occupe ».

Je passe une discussion sur JEE 6 et les 3 profils (A, B et C). Mais clairement S2AP vise la compatibilité avec les profils A et B de JEE6, pas le profil C qui contient des dinosaures comme EJB 1 et 2/x.

La béta 6 de S2AP est disponible et SpringSource annoncera la sortie de la version 1.0 très bientôt. Malgré mes clins d’œil pour que Julien lâche une date, il a répondu « désolé Nicolas, tu ne pourras pas bloguer dessus ce soir… ».
En même temps avec la tenue aujourd’hui et demain de SpringOne à Anvers, je pense que nous devrions avoir une petite annonce très bientôt !

Pour plus d’informations :
http://www.springsource.com/products/suite/applicationplatform

J’ai noté ensuite les questions/réponses mais nous sommes plus dans le débat qu’une vraie discussion de fond. Je crois qu’il faudra que je vous présente les idées d’OSGi dans un prochain article car il y a pas mal de choses à dire.

Pour faire simple et expliquer OSGi : les modules sont la représentation à l’exécution de ce que Maven2 propose à la compilation. Un package applicatif qui tourne dans un moteur OSGi isole ses dépendances de ses voisins. Chaque partie de votre application web pourra par exemple utiliser sa version d’un parseur XML sans problèmes.

Sur ce je vous laisse, je crois que je vais finir par acheter un Pulse SmartPen de LiveScribe.com pour prendre des notes.

Je rentre juste de la soirée du PJUG organisée ce soir autour de la présentation de Kirk Pepperdine sur Java et les performances. Je vous livre donc en vrac ce que j’ai vu, ce que j’ai entendu et aussi mes rencontres de la soirée.

Tout d’abord au niveau logistique, nous étions une bonne centaine ce soir… Un peu de math à calculer le nombre de personnes par rangées, multiplié par le nombre de rangées… oui il devait y avoir au moins 80 personnes. Des personnes sont restées debout. Le buffet était offert ce soir par la société Jaxio. Un nouveau sponsor était présent car j’ai reconnu une personne de Valtech qui était passée chez nous faire un audit performance. Il y avait aussi des personnes de Xebia.

La présentation de Kirk était du caviar pour les geeks dans la salle. J’ai eu peur parfois qu’en allant trop dans les détails, il fasse décrocher l’assemblée. Mais les gens ont suivi, et la participation a été bonne. A propos on passera sous silence mon aller-retour au tableau, où je n’ai pas décroché un livre ou un tee-shirt… Cela m’apprendra à sortir du bois.

La présentation était vraiment dynamique, et Kirk est un orateur surprenant qui n’est pas là pour nous vendre de la soupe, mais pour nous donner des nouvelles du front… Et il y a du boulot qui nous attend.

Kirk Pepperdine a aussi donné son avis sur les bases de données. De son point de vue, le prix de la mémoire et les évolutions technologiques (mémoires de type NAND ou Flash) font que d’ici quelques temps l’utilité d’une base de donnée se pose. On se force à utiliser un monde relationnel qui n’est pas familier au monde objet Java. Vous êtes vous déjà rendu compte de la différence entre un modèle Java, avec héritage, et un modèle relationnel en base ?

Il a aussi conseillé pour les malheureux condamnés à travailler sur Windows de faire l’expérience de désactiver le Swap disque puis de lancer Eclipse… Oh mais comme c’est rapide… Dingue non ? L’explication est que la gestion de la mémoire Java ne peut pas déterminer si un élément paginé est stocké dans la mémoire vive ou sur le disque. Donc si vous avez des comportements bizarres avec Eclipse vous pouvez tenter de désactiver le swap de Windows, vous pouvez passer au Mac (très bonne idée) et vous pouvez aussi passer à IDEA IntelliJ qui est l’éditeur qu’utilise Kirk… J’ai eu envie de dire à tout le monde : jetez Eclipse, dépensez de l’argent et achetez IDEA IntelliJ… On est en 2008 et il y a la télé couleur aussi dans le monde des éditeurs. Mais finalement je suis resté assis. J’ai été ridicule une fois, j’allais pas remettre cela. Je vous donnerai un cours la prochaine fois sur le fait qu’une String Java, contrairement à ce que vous croyez, n’est pas un objet immuable… On peut changer sa valeur sans problèmes… Je me réserve un billet là dessus.

Revenons à nos moutons. J’ai retenu durant sa présentation qu’avec l’arrivée des processeurs multi-coeurs, les choses vont changer. Java est le premier langage à proposer un système de virtualisation du code, avant même que l’on ne parle de virtualisation de machine. Il ajoute une abstraction entre le code machine et le code du logiciel. Ce faisant, les éditeurs de JVM ont optimisé et tiré parti de l’architecture matériel sous-jacente. Une JVM génère au final un bytecode qui sera adapté au processeur, à l’architecture et au système d’exploitation qui fait tourner la class Java. C’est faisable aussi en C++ ou en C, au prix d’une optimisation et d’un travail qui est à la charge du développeur.
Cependant, et c’est ce qu’il a tenu à faire passer, avec l’arrivée des processeurs multi-coeurs nous risquons de voir surgir de nouveaux soucis apportés par l’architecture parrallèle. En effet, il n’existe pas encore dans le langage Java de quoi délimiter du code afin d’aider la JVM ou même le processeur, à exécuter en parrallèle des bouts de code. Enfin il nous a cependant montré que sur Java 7, des marqueurs ainsi que des mots clés de la JVM permettront de modifier le comportement et de l’optimiser… J’ai l’impression de ressortir des soucis qui n’existaient pas il y a quelques années…
De son point de vue, le matériel est maintenant quelque chose que nous devons à nouveau prendre en compte dès l’écriture de code, lorsque nous cherchons les meilleurs performances… Cela me fait penser qu’aujourd’hui nous arrivons à peine à faire écrire du code correctement et que des outils comme JProfiler se vendent très bien pour identifier et corriger les erreurs de codage…
Donc je ne sais pas. C’est à réflechir.

Nous étions ce soir en face d’une personne dont le coeur de métier est la performance. Il a distillé des réflexions très intéressantes sur la manière de prendre des mesures. Qu’est-ce qu’après tout, effectuer un benchmark ? Qu’entends-t-on par audit et mesures de performances ?
C’est un vrai métier, et si j’avais un conseil à donner à mon big boss, c’est d’appeler un vrai médecin pour soigner le malade. Pas de faire du bricolage avec 3 graphes… Je referme la parenthèse.

Revenons à Kirk. Je vous laisse un lien à lire car je crois que chaque développeur Java devrait l’avoir lu une fois. Cela vous donnera une description fine du fonctionnement de la JVM.
http://www.jucs.org/jucs_11_7/an_experimental_evaluation_of/jucs_11_7_1291_1310_faustino.html

La page des options de réglage de la JVM de SUN, toujours utile lorsque vous faîtes des micro-benchmarks afin de voir comment désactiver le Garbage collector en augmentant la taille de la heap.

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

Bon, et donc je terminerai par une petite private joke :
« Franck »
…
« Franck »
« is »
« very sad about immutable String »
…
true
false
…
« very sad about immutable String »

On en parle la prochaine fois…

Bonne nuit ou bonne journée

Vous pourrez retrouver sur son blog des billets intéressants sur l’évaluation des performances sur la plateforme Java. Kirk tiendra aussi une conférence à JavaOne en mai, autant dire que nous verrons ce soir un grand monsieur.

J’aurai des tonnes de billets à écrire sur les performances et les légendes urbaines autour de Java et de ses performances. Je ne compte pas le nombre de fois où j’ai été tenté de vous repeindre le Touilleur avec des articles sur les performances. J’ai arrêté de me battre car je me suis rendu compte que finalement les causes de ces discussions sont souvent:
– une grosse méconnaissance de la plateforme Java,
– une ignorance de l’écosystème open-source autour de Java
– un désert d’objectivité
– deux ou trois idées vieilles de 10 ans basées sur le Java de cette époque

… et la liste est longue. C’est dommage car le langage lui-même ne représente que 50% de ce qu’une personne qui fait du Java doit connaître. Je mettrai dans les 50% restant une connaissance des outils de développement, de gestion de projet, de moteur applicatif ou de serveurs d’applications, qui font partis pour moi maintenant de la boîte de survie du développeur Java.

Imaginez un monde sans Ant, Maven, ApacheTomcat, Eclipse, Hibernate, JBoss Application Server, Spring, JSF, Log4J, Xerces, Xalan, Struts, Wicket…

Allez je vois que je suis déjà parti sur un autre sujet… j’en garde pour un autre billet.

Pour revenir à la soirée PJUG, si vous venez ce soir, faites-vous connaitre, je serai content de discuter avec vous.

Hop une petite photo pour m’identifier :

A mardi soir

Le principe des Java User Groups est de permettre à des passionnés de Java de se rencontrer. Avant tout un moyen convivial de rencontrer de nouvelles personnes et de discuter autour de Java et des technologies Open-Source. Comme l’a expliqué Antonio, curieusement il n’y avait pas encore de groupe en France. Voyez vous-même sur la carte ci-dessous:

. Il y a 15 groupes en Italie, dont la Sardaigne, et rien en Espagne par exemple. La Belgique est plus dynamique aussi, avec quelques grands JUGs. Enfin depuis ce soir, c’est parti. Il y a maintenant un groupe de passionné de Java qui se réunira les deuxièmes mardi de chaque mois à Paris. Au programme: présentation puis ensuite apéritif. Le tout sponsorisé par des sociétés. Merci pour ce soir à SUN, ainsi que le buffet offert par la société Anéo.

Après la présentation, le buffet convivial m’a permis de faire connaissance avec quelques personnes. J’ai bien discuté avec Jérôme Grodziski autour du métier d’indépendant et du fonctionnement du marché lorsque l’on décide de se mettre à son compte. Ensuite j’ai fait la connaissance d’Alexander von Zitzewitz, fondateur et directeur de la société Hello2MORROW, éditeur de SonarJ, ainsi que de son distributeur en France, Frédéric Brachfeld. SonarJ est un outil d’analyse de code capable de calculer des statistiques de couverte de code ainsi que de qualité. Il peut calculer la complexité cyclomatique d’une classe par exemple. Integré à Maven ou ANT, SonarJ est donc un outil d’analyse de qualité du code.

J’ai ensuite rencontré Cyril Le Clerc et une autre personne de Xebia. Enfin des Xebia-boys en live ! Nous avons parlé du jeu-concours XebiaPoker de Xebia, puis de l’organisation de Xebia. Vraiment intéressant comme rencontre. En principe si tout va bien je dois participer à la formation Scrum Master fin mars. J’aurai donc l’occasion d’aller à la rencontre de Xebia. Sinon pour le jeu XebiaPoker, j’ai remonté de 17 places, et ce soir je suis 43ème… Snif laissez-moi repasser le tests de performances que j’ai planté en répondant trop vite et le test J2SE advanced qui a planté par contre (message « connection time-out » avec le serveur dans la page Flash).

Enfin j’ai retrouvé une vieille connaissance de Coplanet: Florent Ramière. Cela remonte à 1998 je crois du temps où il était en stage de fin d’étude de l’EPITA. Il est aujourd’hui co-fondateur et responsable de Jaxio. Jaxio est l’éditeur d’une solution de génération de code source Java qui permet de générer du code utilisant les dernières technologies Java en partant du modèle de base de données. L’intérêt est de s’affranchir du code spaghettis sans valeur ajouté et bien souvent non suffisamment testé pour se concentrer sur la vraie valeur d’un logiciel.

Soirée sympa, où l’on peut rencontrer des personnes passionnées de Java qui sont venues pour partager un moment avec d’autres fans. Si vous souhaitez venir à la prochaine réunion, rendez-vous sur le site http://www.parisjug.org/