Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• SpringSource : sortie par le haut
• Websphere: les derniers seront les premiers ?

Agilité

• Prioriser le Product Backlog
• Leçons de management par la NASA

RIA

• 10 choses à savoir sur Flex
• GraniteDs en version 1.1.0

Le coin de la technique

• JSR-277 : OSGi m’a tuer (Stanley Ho)

Evènements de notre communauté en France et à l’étranger

• Paris JUG : soirée OSGi

Actualité éditeurs / SSII

SpringSource : sortie par le haut

Comme nous l’annoncions succinctement mercredi, SpringSource a revu sa copie concernant sa nouvelle politique de maintenance abandonnant de ce fait les points les plus polémiques de celle-ci, dont sa fameuse règle des trois mois à l’origine des levées de boucliers de la communauté.

Dans son post de mardi dernier, Rod Johnson dévoile donc le nouveau fonctionnement de celle-ci : les releases seront disponibles pour la communauté jusqu’à la sortie d’une nouvelle version majeure. Ainsi, les binaires des versions 2.5.x du cœur du framework continueront d’être publiés tant que Spring 3.0 RC1 n’est pas disponible. SpringSource compte, par ce biais, inciter la communauté open-source à toujours coller aux dernières versions de son framework.

Websphere: les derniers seront les premiers ?

Dernier serveur certifié Java EE 5, Websphere ressort grand vainqueur d’une étude comparative des principaux serveurs d’application du marché, menée par Evans Data Corporation (rapport gratuit, mais enregistrement nécessaire).

Cette étude soulève déjà de nombreuses questions chez les concurrents (comme Rick Sharples, de JBoss), le marketing d’IBM n’allant pas se plaindre d’une si belle vitrine.
Rick émet 3 interrogations majeures :

• Comment comparer des serveurs d’application dont les communautés peuvent varier d’un noyau de type ‘niche’ (SAP) à des super-communautés mondiales (IBM, BEA, RedHat ou Microsoft) ?
• Pourquoi n’arrive t’on pas à corréler les résultats de cette étude avec ceux d’autres études publiques, voire internes, sur JBoss ?
• Pourquoi évalue t’on un serveur aussi confidentiel que Geronimo (lui aussi chez IBM) ?

Pour notre part, nous émettons un certain nombre de réserves :

• L’étude ayant été menée durant l’été 2008, elle ne peut nécessairement pas porter sur WAS 7.0, sorti officiellement en septembre (d’autant plus qu’un des points de l’étude porte sur le support, qui n’est pas assuré pour les versions beta). Cette étude porte donc plus globalement sur ‘les marques’, plutôt que sur les dernières versions des serveurs d’application cités.
• Les consultants Xebia ont l’habitude de travailler avec bon nombre de ces serveurs d’application, et au petit jeu des comparaisons directes (ce qui n’est pas le cas de cette étude), les avis sont loin d’être aussi tranchés.
• La rédaction du rapport est très orientée ‘marketing’, ce qui est étonnant au vu de la population consultée. Il est étonnant de lire des phrases telles que « WebSphere’s users obviously love this product. » venant de développeurs qui n’ont souvent pas le choix de leur serveur d’application (souvent dicté par les achats groupe ou l’exploitant) et qui ont tendance à ne faire que « subir » ses désavantages.

Alors, étude téléguidée par un éditeur ? Enième conflit d’intérêt pour un cabinet d’analyse dont les clients sont les premiers sujets de comparatifs ? La réponse est sûrement plus complexe et on peut tout au plus tirer quelques enseignements de ce travail :

• JBoss joue définitivement dans la cour des grands, et est un concurrent sérieux pour les « grands » serveurs d’application, même sur des applications à grande échelle.
• la communauté s’inquiète du rachat de BEA par Oracle (peut-être est-ce même la raison principale de cette 7ème place).
• Le « petit jeune », Glassfish, qui remporte l’adhésion des développeurs pour sa facilité de mise en oeuvre, n’est pas en reste sur les fonctions principales (performances, scalabilité) et vient titiller les vieux mastodontes.
• La comparaison objective de serveurs d’application, dans un environnement aussi hétéroclite que celui des SI du XXIeme siècle, avec des problématiques variées et complexes, est un exercice dangereux, qui porte rapidement à critique.

Agilité

Prioriser le Product Backlog

En Scrum, il faut ordonner les éléments du Product Backlog pour que l’équipe sache quelles sont les fonctionnalités à implémenter en priorité.
Peter Stevens propose différentes stratégies pour prioriser le Product Backlog, à composer selon le contexte du projet :

• Ensemble minimum de fonctions : faire une liste minimum des fonctions à implémenter pour que le produit soit utilisable et accepté par les utilisateurs
• Valeur métier en premier : se concentrer sur les fonctions à haute valeur ajoutée métier. La valeur métier (typiquement avec un coefficient entre 1 et 100) est fixée par le Product Owner.
• En avoir pour son argent : semblable à la précédente approche, elle se concentre sur les éléments qui ont le meilleur rapport valeur métier/coût.
• Risques techniques en premier : préconisée par RUP, cette approche s’attaque aux points techniques difficiles en premier. Cela peut cependant conduire à un système trop complexe par rapport aux besoins.
• Reporter le risque : s’attaquer aux difficultés en dernier (ou jamais). Préférer les stories bien comprises, tout en investigant les stories plus risquées/coûteuses pour les décomposer.
• Votes des utilisateurs : demandez aux utilisateurs de voter parmi une liste de fonctionnalités potentielles.

Ce dernier point peut être accompli par une analyse de Kano comme le propose Mike Cohn dans sa présentation Prioritizing Your Product Backlog mise en ligne sur InfoQ. Le pdf est également disponible.
Mike Cohn y présente plusieurs techniques de priorisation, plus concrètes mais nécessitant plus de calculs :

• Analyse de Kano : distinguer les thèmes selon 3 types : fonctions obligatoires, linéaires, et attractives. Implémenter toutes les fonctions obligatoires, le plus de linéaires possible et quelques excitateurs pour la satisfaction utilisateur.
• Theme screening : noter les thèmes selon certains critères de sélection, par rapport à un thème de référence.
• Theme scoring : semblable au Theme screening en pondérant les critères de sélection
• Relative weighting : pour chaque thème, calculer le rapport entre sa valeur relative (aux autres thèmes du product backlog) et son coût relatif. Ce rapport donne la priorité du thème.

Ces techniques s’appliquent toutes au niveau thème, car descendre au niveau user story demanderait trop de travail sur un product backlog complet.

Leçons de management par la NASA

Jerry Madden, un ancien employé du Goddard Space Flight Center de la NASA, a collecté « 100 leçons » apprises auprès des managers qu’il a cotoyés.
Marios Alexandrou en a extrait les leçons qui collent le plus avec son expérience des projets web. Parmi les plus marquantes :

• Une réunion de travail devrait durer 5 minutes minimum (moins elle est inutile) et 1 heure maximum (plus c’est un marathon). Au-delà de 6 personnes, elle devrait être réservée au transfert d’information.
• Ne demandez jamais à vos chefs de prendre une décision que vous pouvez prendre vous-même, sauf si un document vous l’interdit.
• Ne supposez jamais que quelqu’un a fait quelque chose, demandez lui. Même le plus évident peut être oublié, surtout en période de stress.
• La documentation ne remplace pas la connaissance. Les documents restent des images statiques dans le temps et sont rapidement dépassés.
• Les projets nécessitent un travail d’équipe pour réussir. Rappelez-vous que la plupart des équipes ont un coach et non un boss, mais le coach doit parfois arbitrer certaines parties.
• Si un chef de projet est l’homme le plus intelligent de l’équipe, c’est qu’il a fait un mauvais travail de recrutement.
• Les principes de gestion sont toujours les mêmes. Seuls les outils changent. Vous devez toujours trouver les bonnes personnes pour faire le travail et rester à l’écart pour qu’ils puissent le faire.

Il est amusant de constater certaines similitudes avec les méthodes agiles. Les individus et leurs connaissances sont plus importants que la documentation. Le coach doit s’appuyer sur une équipe de personnes motivées, intelligentes, et responsables qui n’attendent pas d’ordre d’un patron. Leur collaboration est essentielle à la réussite du projet. Ces ressemblances sont logiques finalement, il s’agit simplement de bon sens.

RIA

10 choses à savoir sur Flex

Les articles recommandant Flex se succèdent. Après l’annonce d’Atos sur son blog Entreprise 2.0 du choix de Flex sur plusieurs projets pour de grands comptes et la « victoire » de Flex lors de notre RIA Contest, c’est au tour de Alaric Cole, l’auteur de « Learning Flex 3 » de lister 10 avantages à l’utilisation de Flex.

Alaric Cole est partie prenante, et on a déjà pu lire sur d’autres blogs les différents points cités, mais l’article a l’avantage de les regrouper :

1. Flex s’apparente aux standards d’une application Web : MXML est un langage de balises comparable à l’HTML, l’ActionScript est l’équivalent du JavaScript. Le tout customisable avec du CSS.
2. Flex = Flash : tout ce qui était possible en Flash l’est en Flex. Flex apporte cependant une couche de structuration/méthodologie par rapport à Flash
3. Une application Flex fonctionne sur tous les navigateurs et tous les OS (Linux 64bit ?). La seule contrainte est d’avoir déployé le plug-in d’exécution.
4. Le framework RIA d’Adobe accepte l’échange de données et propose des interfaces de communication avec plusieurs formats d’échange (SOAP, HTTP, AMF…)
5. Une application Web Flex aura un « Look And Feel » identique quelque soit l’OS client
6. Flex est léger et rapide grâce notamment aux améliorations du futur plug-in Flash 10. Par exemple, la fonctionnalité de « Framework Caching » permet de réduire à 100Ko la taille de l’application à télécharger
7. Les composants de Flex sont nativement construits pour être accessibles (loupe, internationalisation, raccourcis clavier…)
8. Le contenu d’une application Flex peut maintenant être indexé par un moteur de recherche
9. Le SDK Flex est maintenant OpenSource et gratuit mais attention l’IDE Flex Builder est payant.
10. Enfin, il rappelle la facilité d’apprentissage du langage. Pour un habitué de la Javadoc, l’accès au format ASDocs d’Adobe est cependant déroutant les premiers temps.

Même si l’ancienneté de Flex sur le marché, la couverture de déploiement de son plugin d’exécution et la solidité de son distributeur Adobe semblent placer Flex en tête du tournoi RIA, il est bon de rappeler que la compétition ne fait que commencer : 2 outsiders sérieux (Silverlight et JavaFx) vont bientôt s’élancer dans la course ! L’avance prise par Flex pourra t-elle être comblée ?

GraniteDs en version 1.1.0

GraniteDS est un framework opensource équivalent à BlazeDS, simplifiant le développement des communications entre un RIA Flex et un serveur J2EE. Cet article d’InfoQ nous présente les nouvelles fonctionnalités disponibles sur GraniteDS 1.1.0:

• Granite Eclipse Builder : un plugin Eclipse basé sur AS3 Generator permettant de générer le code ActionScript 3 associé aux JavaBeans. Ce plugin génère automatiquement du code lorsqu’un JavaBean est modifié.
• Tide : ce framework fournit des fonctionnalités telles que la mémorisation d’objets dans un contexte qui transite entre la partie cliente et la partie serveur, la pagination des données. Il permet également de gérer le lazy loading des collection en wrappant les collections et en les récupérant dés que c’est nécessaire.
• MXML Web Compiler : une compilation à la volée du code source MXML et ActionScript 3 sur le serveur d’application.

Avec cette nouvelle version, GraniteDS se positionne comme un concurrent sérieux de BlazeDS. La génération des JavaBeans, la gestion du lazy loading et la compilation à la volée sont des points forts qui séduiront très vite les développeurs. Cette nouvelle approche ne peut que faciliter et améliorer le développement d’applications Flex.

Le coin de la technique

JSR-277 : OSGi m’a tuer (Stanley Ho)

Stanley Ho a annoncé son départ de Sun Microsystems. Par la même occasion, il laisse les clés de la JSR-277 dont il était à la tête. C’est donc Alex Buckley qui reprend le flambeau, il était déjà responsable de la petite sœur, la JSR-294 : les superpackages.

Nous sommes en droit de nous demander si la création du prototype permettant l’interopérabilité entre Java Module System et OSGi qu’a amorcé Sun ces derniers mois a quelque chose à voir avec ce départ. Quoi qu’il en soit, le tournant est définitivement engagé pour le futur de Java Module System.

Evènements de notre communauté en France et à l’étranger

Paris JUG : soirée OSGi

Dernière piqûre de rappel pour la soirée OSGi de ce mardi 14 octobre au Paris JUG.

• Le programme est disponible ici : première partie ‘introduction à OSGi’, seconde partie : ‘OSGi appliqué’
• Les inscriptions sont gratuites et ouvertes à tous, enregistrez-vous ici
• La soirée aura lieu à l’ISEP, dont voici le plan d’accès

Nous vous y attendons nombreux.