Revue de Presse Xebia

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

Agilité

RIA

Le coin de la technique

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

Sacha Labourey au Paris JUG mardi pour une soirée JBoss

Agilité

Scrum et XP depuis les tranchées

Le livre référence de Henrik Kniberg, disponible sur InfoQ, vient d’être traduit en français (disponible en pdf ici).
Guillaume Mathias (Xebia) a participé à cette aventure aux côtés de Bruno Orsier, Emmanuel Etasse et Christophe Bunn.
Merci aux auteurs pour ce formidable don à la communauté Agile francophone.

Scrum de scrums

Une des questions récurrentes concernant l’adoption des démarches agiles sur une large échelle est celle de la synchronisation de nombreuses personnes. À ce sujet, InfoQ revient sur l’un des outils proposés par la méthode, le Scrum de Scrums. Allan Shalloway expose les problématiques d’un ‘grand’ projet Scrum, où plusieurs équipes interviennent sur la réalisation de modules inter connectés :

Problématique technique : adopter une démarche agile, c’est éviter de réaliser des fonctionnalités non nécessaires. Ainsi, si une sous équipe ‘A’ créé un service, dont l’équipe ‘B’ aura peut-être besoin dans une itération ultérieure, rien ne l’oblige à exposer ce service. Quand ‘B’ aura besoin du même type de service, plusieurs questions surgiront : ‘B’ est-il au courant de l’existence de ce service. Si oui, qui doit le modifier pour qu’ils répondent aux besoins de ‘A’ et de ‘B’ ?
Synchronisation d’équipe : les Scrums Masters et les Product Owners ne sont pas les mêmes pour les équipes ‘A’ et ‘B’. Les problématiques de synchronisation sont évidentes si on se place du point de vue du product owner (Cette fonctionnalité existe t’elle déjà ? Est elle est prévue ? …)
Intégration du produit final : il n’est pas simple de délivrer un produit final fonctionnant de bout en bout juste en accolant les composants développés par les différentes équipes.

C’est pour cela qu’a été pensé le Scrum of Scrums.
Allan Shalloway, dans le cadre de la rédaction de son livre « Lean Software Development: Scaling Agile to the Enterprise » a collecté les retours d’utilisateurs sur ce ‘super’ daily scrum.
Pour Mike Dwyer, le SoS sert à gérer la décomposition des users – stories afin de veiller à ce qu’une fonctionnalité ne soit pas réalisée en double.
Pour Ilja Preuß, le SoS permet d’identifier les points d’entraide possibles, les impacts des différentes équipes sur le système, mais surtout, cette réunion permet de renforcer le sentiment d’appartenance à un seul et même projet.
Christophe Louvion a utilisé le SoS pour gérer l’intégration des sous composants au jour le jour. Il a aussi utilisé le SoS pour maintenir une méta-équipe, composée de membres seniors de chacune des sous équipes, et chargée de gérer les problématiques transverses du projet (rédaction des normes, intégration end to end, revues d’architecture…)

Enfin, Walter Bodwell partage sa recette secrète pour un SoS pleinement opérationnel : il faut qu’il soit court (15 minutes), concis, centré autour de l’information qu’on veut communiquer aux autres. Toutes les problématiques particulières doivent être abordées dans des réunions en tête à tête. Le SoS doit permettre d’identifier les points bloquants, et de les rappeler à tous (tous les jours s’il le faut) jusqu’à leur résolution.
Enfin, comme la problématique des SoS est attenante à celle des équipes de développement distribuées, il peut être utile, afin de conserver au SoS une pertinence maximale, de préparer quelques notes pour la réunion.

RIA

FlexMonkey 0.5

Lors de l’une de nos revues de presse, nous vous présentions FlexMonkey (framework de tests automatisés OpenSource pour Flex).
Ce projet vient de voir arriver la version 0.5 et permet :

Une configuration afin de pouvoir lancer FlexMonkey par des systèmes de build (et plus particulièrement Ant).
Un refactoring de l’API afin de séparer l’UI et le core.
Une séparation entre la gestion des tests automatisés (FlexMonkey.swc) et le runner FlexUnit (FlexMonkeyUI.swc).

Pour un produit aussi jeune, ce dernier permet d’effectuer des tests convenables sous une application Flex. L’automatisation des tests sous Flex lève une barrière à son adoption, alors qu’attendez-vous ?

Sortie de SmartGWT

Sanjiv Jivan, ex-auteur de GWT-Ext a annoncé hier la sortie de SmartGWT, un nouveau Wrapper GWT au dessus d’un Framework Javascript très complet : SmartClient.

Les plus de SmartGWT par rapport à GWT-Ext :

La richesse des composants fournis par l’api.
L’amélioration des performances (peu de temps de latence, utilisation de l’asynchrone systématique …).
Un code Java plus léger et plus consistant.
Une intégration avec des services REST et à base de WSDL.

Les moins :

Un style visuel par défaut moins attrayant que celui de son rival.
Le niveau d’abstraction est le même que sur GWT-Ext. Dès qu’on souhaite customiser un composant ou créer un comportement différent, il faut la plupart du temps mettre le nez dans le code Javascript.

Le code source du projet est fourni sous licence LGPL.
Une démo de SmartGWT en action est disponible.
Notons aussi, pour cette occasion, un petit jeu de questions / réponses chez InfoQ.

Le coin de la technique

Améliorez la testabilité de votre code

Misko Hevery, coach Agile à Google, partage sur son blog quelques-unes des recommandations et alertes que Google suggère à ses développeurs afin de garder le code le plus propre et le plus testable possible. Rien de bien étonnant, la majorité des points abordés sont connus et relèvent du bon sens. Cependant, une piqûre de rappel ne fait jamais de mal.

Misko a donc regroupé ceux-ci en ‘fléaux’. Ces 4 thèmes permettent de vérifier ou d’améliorer simplement la testabilité d’une application (la liste ne se veut pas exhaustive) :

Assurez-vous que vos constructeurs n’effectuent aucun véritable traitement. Alertes : utilisation du mot clé new, appel à des méthodes statiques, présence de conditions ou de boucles, utilisation de blocs d’initialisation, initialisation trop complexe.
Contentez-vous d’utiliser les objets attributs de vos classes. Alertes : invocations chaînées trop profondes du type getObject1().getObject2().getObject3(). Objets avec des noms suspects comme ‘context’, ‘environnement’, ou ‘manager’.
Utilisez les objets stateful à bon escient. Alertes : utilisation d’un singleton, utilisation d’un champ ou d’une méthode statique, présence de bloc statique d’initialisation. Misko est d’ailleurs l’auteur d’un projet sur Google Code permettant de détecter différents types de singletons.
Découpez votre code, évitez les classes trop volumineuses. Alertes : les objets qui ont plusieurs fonctions distinctes, les classes difficiles à comprendre rapidement, les classes possédant des attributs qui ne sont utilisés dans aucune méthode.

Misko est également l’auteur d’un autre projet permettant l’analyse de la testabilité de votre projet à partir de son bytecode. Il a d’ailleurs passé celui-ci sur quelques-uns des frameworks Open Source de votre quotidien et regroupé les résultats sur son site dédié : Testability Explorer.

Nexus pour chercher dans les repositories Maven

On avait l’habitude d’utiliser http://www.mvnrepository.com (ou google, ou le plugin m2eclipse) lorsque l’on partait à la recherche de son jar favori, Sonatype (dont le fondateur et CTO est Jason Van Zyl, le père de Maven) a mis à disposition une instance publique de Nexus, son manager de repository Maven : http://repository.sonatype.org.

L’interface est propre, facile à utiliser, et est développée à l’aide du framework Ext JS.

Distribuez vos tests JUnit avec GridGain

Tester une application déployée sur plusieurs machines : quelle galère ! N’avez-vous jamais eu besoin d’effectuer des tests en environnement distribué ? Comment effectuez-vous vos tests d’intégration impliquant des communications clients-serveur ? Cet article nous propose une solution originale pour effectuer ce type de tests multi-jvm utilisant certaines fonctionnalités de GridGain, framework Open Source permettant la création d’applications distribuées de type grid computing. L’auteur de l’article n’utilise pour faire ses tests qu’une des fonctionnalités offertes par ce framework : la distribution des tests sur plusieurs nœuds.

Pour ce faire, vous aurez besoin, en plus de vos tests, de 3 ‘TestSuite’ configurées avec des annotations et runners GridGain :

Une première ‘Remote TestSuite’ chargée de lancer les tests sur le serveur. Les tests de cette suite seront exécutés sur la grille.
Une seconde ‘Local TestSuite’ pour lancer les tests sur le client local.
Une troisième et dernière ‘Distributed TestSuite’ servant de point d’entrée unique au lancement de deux premières séries de tests.

Cela vous déplaît certainement d’utiliser un tel framework uniquement pour une de ses plus petites fonctionnalités, et vous avez probablement raison. Maintenant quelles autres options aussi puissantes et rapides à mettre en place proposeriez-vous en remplacement ?

Tomcat : Trucs et astuces des pros de SpringSource

SpringSource continue sa série de webinars sur Tomcat avec Apache Tomcat Tips and Tricks from the Pros (cf. Tuning et optimisation de Tomcat : mod_jk est mort ! Longue vie à mod_proxy_http ! et Améliorer les performances de Tomcat en production). Nous avons cette fois retenu :

setEnv(.sh|.bat) est le fichier à utiliser pour configurer le lancement de Tomcat (afin de préciser le JDK, les options de la JVM, etc). startup.sh et catalina.sh peuvent le plus souvent rester inchangés.

JAVA_HOME=/usr/local/jdk_1.6.0.10/
CATALINA_OPTS=-Xmx512m
CATALINA_HOME=/usr/local/apache-tomcat-6.0.18
CATALINA_BASE=/usr/local/tomcat-instance-01
CATALINA_PID=$CATALINA_BASE/logs/tomcat.pid

Dans cet exemple, un JDK 1.6.0.10 avec 512 Mo de Heap démarre un Tomcat 6.0.18 avec une configuration située sous /usr/local/tomcat-instance-01 ; le pid sera stocké sous /logs/tomcat.pid.

Le port de shutdown de Tomcat existe pour des raisons historiques [1] et présente une faille inutile de sécurité. Il doit être désactivé en précisant le port « -1 ». On remplacera alors shutdown.sh et catalina.sh stop par le classique kill unix.

L’Access Log Valve permet de générer des logs d’accès similaires à celles d’Apache. Ces informations sont très importantes pour la supervision et le troubleshooting. L’ExtendedAccessLogValve supporte le W3C Extended Log File Format et surtout facilite le troubleshooting en permettant d’afficher les paramètres et les attributs de requête (même en POST).

Le fichier catalina.properties permet d’utiliser des variables de substitution. Exemple avec une variable engine.jvm-route :

Tomcat offre plusieurs méthodes pour déployer les applications (définition de <context> dans server.xml, auto deploy de .war/répertoires/context.xml, déploiement scripté). Si toutes ces options sont utilisables en production, il est important de n’en utiliser qu’une seule pour éviter les collisions.

[1] Les JDK 1.0, 1.1 et 1.2 n’offraient pas de graceful shutdown. Depuis, le mécanisme de Shutdown Hook des JVM permet un arrêt élégant de Tomcat sur commande kill.

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

Sacha Labourey au Paris JUG mardi pour une soirée JBoss

Sacha Labourey, CTO de JBoss et General Manager de JBoss Europe, présentera JBoss AS 5.0 à la soirée JBoss du Paris JUG mardi 2 décembre. Saheb Malik, JBoss France, présentera ensuite JBoss Seam.
C’est l’occasion rêvée de mieux comprendre l’agenda de JBoss. Nous avons notamment en tête les questions suivantes :

JBoss MicroContainer et OSGi : quel positionnement tenir quand Sun a mis en retrait HK2 au profit d’Apache Felix.
JBoss Messaging vs. RedHat MRG : quelles synergies ? Interopérables à l’instar de Websphere MQ (aka MQ Series) et Websphere Embedded Messaging Engine ? AMQP plaît à RedHat, JBoss est-il aussi intéressé ?
JBoss AS 5 : comment le précurseur des implémentations EJB 3 et JPA se retrouve t’il parmi les retardataires des certifiés Java EE 5 ? Le chantier de refonte a-t-il été trop ambitieux ?
Data Grids : pourquoi JGroups, le coeur de communication de JBoss Cache est-il un projet extérieur à JBoss ? Les Data Grids font-elles parties des priorités de JBoss ?
JBoss, Fondation Apache et brique HTTP de JBoss AS : JBoss semble moins impliqué qu’auparavant dans Tomcat et vient de lancer son mod_cluster à l’extérieur du projet Apache HTTP Server et de son mod_proxy_balancer. À l’heure où les architectures Comet imposent des évolutions importantes des moteurs de Servlet, JBoss compte-t-il s’éloigner de Tomcat ?