Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Thoughtworks murmure la sortie de Mingle 3.0
• Spring 3.0 enfin finalisé !

Agilité

• Quand le ScrumMaster est un obsctacle
• Kanban ou Scrum ? Kanban et Scrum !

SOA

• Gouvernance implicite et explicite dans une SOA

Le coin de la technique

• Les optimisations se succèdent sur OpenJDK 7

Actualité éditeurs / SSII

Thoughtworks murmure la sortie de Mingle 3.0

Thoughtworks Studios, la partie éditeur de logiciels de Thoughtworks, annonce la sortie d’une nouvelle version majeure de son outil de gestion de projet agile : Mingle.

« Les nouvelles fonctionnalités de Mingle 3.0 permettent de transformer des échanges non structurés en mine d’informations à utiliser pour le développement… » annonce Chad Wathington (vice président de Thoughtworks Studios) :

• Amélioration de la collaboration à l’intérieur de l’équipe : Mingle intègre une nouvelle plate-forme de communication appelée Murmurs.

Les échanges informels (du type messages instantanés ou emails) autour du développement d’une fonctionnalité sont associés en temps réel à une card Mingle. Ainsi tous les échanges sont conservés et aucune information n’est perdue dans les différents canaux de communication. L’intégration avec Jabber Chat est fournie.

• Une fonctionnalité autour de la collaboration fait effet d’annonce. Thougtworks Studios propose une intégration avec le tout dernier moyen d’échanger des informations : Google Wave. Il sera alors possible de manipuler des cards (créer, changer de statuts…) directement depuis une Wave et de référencer du contenu de Wave pour le retrouver directement dans Mingle. Attention cependant, cette fonctionnalité sera seulement disponible courant 2010 (les bas de page sont, dans ce cas, à lire attentivement).

Les autres évolutions apportent de la flexibilité et des outils pour les grosses structures :

• Pour le reporting et l’extraction de données, cette version fournit au manager une vision agrégée et multi-projets pour faciliter par exemple l’affectation des ressources ou encore la copie de Cards entre différents projets.
• Dans la même voie, Mingle améliore sa boite à outils de développement de macro afin de proposer la recherche de données multi-projets ainsi qu’une macro d’exemple.
• Mingle 3.0 supporte dorénavant le clustering pour les organisations de grosse taille.
• Amélioration de l’intégration avec des applications extérieures en fournissant des API plus complètes pour manipuler les données de Mingle et une mise à jour du connecteur Subversion pour supporter la version 1.6.5

Mingle est déjà mature en version 2.3.1, et il se présente comme un des meilleurs outils de gestion de projet agile (gestion façon Kanban des user stories, customisation du workflow de développement, extraction de données simple, reporting…).
En tant qu’utilisateurs de Mingle, l’agrégation des échanges informels nous semble cependant une avancée intéressante : ils deviennent un canal privilégié d’échange (surtout dans dans le cadre d’équipes distribuées) et sont souvent à l’origine de bonnes idées. En assurer le suivi et l’indexation au sein de l’outil principal de gestion du projet apporte indubitablement de la valeur ajoutée.

Spring 3.0 enfin finalisé !

Deux mois après un communiqué de presse qui avait semé la confusion lors de la conférence SpringOne G2X, SpringSource a finalement livré la version finale du framework Spring 3.0. Cette version se rapproche des standards Java, ou les standards se rapprochent de Spring ;) comme vous préférez !

Plus sérieusement, c’est un pas important pour cette version de Spring qui est maintenant compatible Java EE 6.

De plus, Spring supporte plusieurs standards :

• JSR-250 @ManagedBean, annotation permettant de scanner les composants annotés et ainsi injecter des ressources, gérer les intercepteurs et callbacks attachés
• JSR-303 pour la validation du modèle par annotation
• JSR-330 @Inject standardisation de l’injection de dépendances par annotation

Il y a de nombreuses nouveautés, en voici un panel :

• Spring Expression Language (SpEL) (inspiré de Seam) est un langage EL (Expression Language) étendu comme on peut le trouver dans nos chères JSP.
• Enrichissement des annotations, ce qui devrait calmer les détracteurs de Spring qui reprochaient la surconfiguration XML
• Support REST (client et serveur) dans Spring MVC
• etc …

Voici un exemple intéressant des capacités de SpEL, dans le fichier de configuration XML de Spring :

ou en java :

@Repository
public class RewardsTestDatabase {

@Value("#{systemProperties.databaseName}")
public void setDatabaseName(String dbName) { ... }

@Value("#{strategyBean.databaseKeyGenerator}")
public void setKeyGenerator(KeyGenerator kg) { ... }
}

Autre élément important, Spring ne supporte plus Java 1.4. En effet Spring couvre les environnements Java 1.5 et 1.6 et Servlet 2.4 et plus, soit Tomcat 5.x et 6.x, ainsi que WebSphere 6.1 et WebLogic 9.2 (qui sont officiellement toujours basés sur J2EE 1.4).

Donc en résumé rien de révolutionnaire, mais il y a quand même beaucoup de nouveautés qui méritent un coup d’oeil. N’hésitez pas à lire la documentation officielle de Spring pour toutes les découvrir .

Agilité

Quand le ScrumMaster est un obsctacle

Cette semaine, Vikas Hazrati, un de nos collègues indiens, nous gratifie (sur InfoQ) d’un article délicieusement subversif : et si le Scrum Master était un obstacle – un impediment pour utiliser un anglicisme barbare – majeur.
Reprenant plusieurs fils de discussions, InfoQ distingue trois types de ScrumMaster problématiques :

• Le ScrumMaster développeur : il agit comme un membre de l’équipe de développement, s’implique fortement dans la réalisation du backlog. L’équipe devient alors spectatrice de l’avancée du projet.
• Le ScrumMaster chef de projet : il dirige les travaux de l’équipe, qui devient totalement dépendante de ses consignes.
• Le ScrumMaster tampon : il gère toutes les communications entre les développeurs et les products owners et / ou clients. Il devient rapidement un goulot d’étranglement. C’est un cas fréquent dans les projets Scrum distribués.

D’autres mauvaises habitudes se dégagent de ces discussions :

• le manque d’anticipation : le ScrumMaster tient le journal des difficultés rencontrées, et même si il les lève, il ne fait rien pour les anticiper.
• l’expertise à tout prix : le ScrumMaster s’implique dans toutes les tâches délicates et l’équipe devient dépendante de son aide. Rapidement, il est contraint par un manque de temps et devient un obstacle à la réalisation du sprint.
• toucher à tout, et oublier son rôle : le ScrumMaster est majoritairement là pour aider l’équipe à avancer dans la réalisation des sprints. Toute tâche annexe à celle ci est consommatrice de temps et empêche l’accomplissement de sa mission principale.

Malgré toutes ces analyses pertinentes, si nous ne devions en conserver qu’une, ce serait celle de Tobias Mayer : donner à quelqu’un le titre de ScrumMaster ne suffit pas à ce qu’il en devienne un.

Kanban ou Scrum ? Kanban et Scrum !

InfoQ nous propose en téléchargement gratuit le livre Kanban et Scrum – making the most of both par Henrik Kinberg et Mattias Skarin.
L’objectif du livre est que vous puissiez comprendre (si ce n’est pas déjà fait) comment Kanban et Scrum pourraient être utiles dans votre environnement.
La première partie se consacre à une brève description de Kanban et Scrum (rôles, itérations…). Ils sont ensuite comparer directement mais aussi comparer à d’autres méthodes agiles. La deuxième partie est une étude de cas avec des questions, des réponses et beaucoup d’exemples : pourquoi changer ? Par où commencer ? Démarrage des équipes ? Comment estimer ? etc…
Pour la version papier, cela se passe par ici.

SOA

Gouvernance implicite et explicite dans une SOA

Andrej Koelewijn ouvre cette semaine une discussion intéressante sur la gouvernance dans une SOA. Il commence par expliquer le rôle incontournable qu’à la gouvernance dans le cadre de l’évolution correcte des services. Puis il explique qu’il y a, selon lui, deux manières d’aborder cette gouvernance, toutes deux étant idéalement appliquées conjointement :

• La gouvernance explicite est celle dont il est en général question, il s’agit d’une personne ou d’un groupe de personnes en charge de s’assurer de la cohérence des services exposés dans la SOA au fil du temps. Ils ont alors le pouvoir de contraindre les équipes projets à se conformer aux règles définies en cas d’écart.
• La gouvernance implicite ne passe pas par le contrôle effectué par une équipe ou une personne tierce mais par des choix architecturaux contraignant ou tendant à diriger naturellement vers les choix idéaux.

A titre d’exemple il cite ainsi l’affectation d’une base de données propre à chaque service de bas niveau, afin d’assurer un partitionnement fonctionnel strict ; des services de plus haut niveau peuvent alors couvrir plusieurs domaines fonctionnels en procédant par agrégation. Toujours dans le but d’assurer ce découpage propre, il suggère la mise en place d’équipes en charge de fonctionnalités, qui seront amenées à développer des services de haut niveau, collaborant avec des équipes en charge de services de bas niveau, qui, elles, font évoluer les services dont elles ont la charge aux fur et à mesure que les besoins sont exprimés.

Ces suggestions, imprégnées par l’expérience pratique, sont dans l’alignement des présentations actuelles sur SOA telles que celle de Nicolai Josuttis à Devoxx 09, dans lesquelles SOA y apparaît comme ayant dépassé le hype pour atteindre la maturité.

Le coin de la technique

Les optimisations se succèdent sur OpenJDK 7

Rémi Forax discute sur son blog de l’arrivée d’une nouvelle optimisation majeure au sein d’OpenJDK 7 : l’optimisation des tail calls » >tail calls. Cette apparition fait suite à l’ajout récent de l’escape analysis et de la compression de pointeurs.

Un tail call est une invocation positionnée en fin de bytecode d’une méthode, juste avant un return. En pratique, pour le développeur Java, il s’agit d’une ligne du type return m(data), où la valeur retournée est fonction d’une méthode tierce.

Lors de l’invocation d’une méthode, outre le saut de code nécessaire, la JVM doit également recréer un stackframe pour la nouvelle méthode en y copiant ses arguments. L’optimisation des tail calls consiste alors à supprimer cette opération sur la stack en réduisant l’invocation à un simple saut dans le code. Dans la mesure où cette simplification nécessite tout de même certaines précautions, une instruction de bytecode doit marquer l’invocation optimisée en tant que tail call auprès de la JVM.

Dans certaines applications présentant un grand nombre d’invocations de ce type, un gain de performance pourra apparaître lorsque cette optimisation sera activée. Celle-ci s’inscrit ainsi dans la continuité d’une présentation que Brian Goetz avait donnée lors de Devoxx 09 où il expliquait qu’un très grand nombre d’optimisations élaborées étaient effectuées par la JVM afin de réduire, ou de supprimer, le surcoût lié aux constructions courantes des langages objets.