Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Saga Oracle/BEA: secrets de polichinelles

Agilité

• Agile survey 2008
• Agile et Lean
• La chasse au gaspillage

RIA

• Sun et LWUIT
• Sortie GWT 1.5

Le coin de la technique

• Les six commandements de l’architecte
• Réplication avec Subversion 1.5

Actualité éditeurs / SSII

Saga Oracle/BEA: secrets de polichinelles

Dès l’annonce du rachat de BEA par Oracle, tout un chacun s’est amusé à parier sur les survies respectives des briques logicielles Oracle ou BEA qui s’avéraient redondantes dans l’offre middleware d’Oracle. 01 INFORMATIQUE version papier du 28 Août nous confirme ce que nous supputions.
Après les JO de Pekin, voici le podium des vainqueurs dans les labs d’Oracle.

• Dans la catégorie Serveur d’applications, le grand gagnant est WLS (OAS était à 100 contre 1 les chez meilleurs bookmakers de la Silicon Valley)
• Dans la catégorie JVM, le gagnant est JRockit (y avait il un compétiteur côté Oracle ?).
• Dans la catégorie ESB, le gagnant est ALSB.
• Dans la catégorie BPM, le gagnant est BPEL Process Manager d’Oracle
• Dans la catégorie Portail, le gagnant est Webcenter Suite et Webcenter Framework (étonnant !).
• Dans la catégorie Moniteur TP, gagnant catégorie est Tuxedo (mais existe t-il une alternative ?).
• Dans la catégorie IDE, JDeveloper et Workshop vont regroupés dans un pack Eclipse (bon courage !).

Mais chut !!! tout cela est officieux car officiellement tous les produits cohabiteront et perdureront.

Agilité

Agile survey 2008

Une pluie de chiffres sur l’agilité vient de tomber, VersionOne vient de publier sa troisième enquête annuelle sur l’état du développement Agile. Celle-ci regroupe les résultats de 3000 participants d’entreprises de tailles variées provenant de 80 pays. Même si tous les profils y sont regroupés, les participants à cette enquête ont, dans la majorité des cas, une certaine expérience (2 à 5 ans) dans la pratique du développement Agile.

À partir de ce panel, il est intéressant de noter ces quelques points :

• l’introduction des méthodes agiles s’est effectuée dans 36% des cas lors de cette dernière année
• 40% des personnes sondées ont ou comptent adopter les méthodes agiles pour des développements outsourcés.
• La réduction du time-to-market et la capacité de gérer l’évolution des priorités sont les principaux moteurs à l’introduction des méthodes agiles
• Scrum est sans conteste la méthodologie agile la plus utilisée (49% full Scrum, 22% hybride Scrum/XP contre seulement 8% XP seul)
• C’est également sans surprise que les barrières les plus répandues à l’adoption des méthodes agiles sont liées aux cultures d’entreprise et la résistance au changement de celles-ci.

Agile et Lean

David Anderson a présenté lors de la conférence Agile 2008 les orientations futures de l’Agile. Claude Aubry résume la vidéo disponible sur InfoQ (1h30) : « l’Agile doit s’ouvrir à l’extérieur, prendre en compte le Lean, se placer au niveau de l’entreprise et s’appuyer sur une notion de maturité des organisations » en s’appuyant sur 3 pratiques : le Kanban, les Real options et CMMI.
Le Lean est encore souvent comparé à l’Agile. À la question Agile vs Lean, Martin Fowler répond que ce débat n’a pas de sens. Il rappelle que les méthodes agiles ont été largement influencées par le Lean (développé chez Toyota dans les années 50) et que les deux courants sont tellement entremêles que « si vous faites des méthodes agiles, vous faites du Lean et vice-versa ».

La chasse au gaspillage

Jean Claude Grosjean énumère les principes fondateurs du Lean Software Development et détaille le 1er d’entre eux : éliminer les sources de gaspillage.
La chasse au gaspillage était déjà lancée par Joshua Kerievsky qui considère que les estimations sont inefficaces. Partant du constat que l’on arrive pas à mesurer la productivité dans l’ingénierie logicielle (notamment à cause de la confusion entre les différentes unités d’estimation des stories), Joshua propose de se passer des estimations et de fonctionner en micro-releases. Les micro-releases regroupent un petit ensemble cohérent de stories, dont la sélection détermine la date de fin de release. Elles ont donc une durée variable (généralement 1 à 6 jours) et leur cycle de vie est détaché de celui des itérations. Elles permettent de livrer le produit plus souvent à la façon just-in-time sans gaspiller du temps à faire des estimations. La principale difficulté dans la mise en oeuvre d’un tel processus est lié à la capacité à décomposer les stories en éléments plus petits mais toujours consistants.
Autre source potentielle de gaspillage selon Przemyslaw Bielicki, les tests unitaires. Tester tout est du gaspillage (tester les getters et setters n’a pas grand intérêt) et il faut savoir interpréter le taux de couverture des tests. Il ne faut pas chercher à atteindre 100% de couverture mais faire preuve de bon sens en testant les composants sensibles, en commençant toujours par le niveau d’abstraction le plus haut.

RIA

Sun et LWUIT

Dans cet article de R.J. Lorimer, celui-ci nous parle de l’annonce de Sun de la librairie LWUIT (Lightweight UI Toolkit) qui vient de passer en licence GPLv2. Pour rappel, cette librairie, présentée lors du JavaOne 2008, fournit des composants graphiques pour le développement d’applications mobiles (Java ME). Se basant sur la philosophie Swing, LWUIT permet de gérer des animations et autres effets avec un ensemble de widgets. Le site du projet nous montre des vidéos assez alléchantes.
A noter une activité grandissante autour de cette librairie comme le témoigne le forum actif, ou bien encore le blog de l’un des développeurs Shai Almog.
Par ailleurs, lors de l’une de nos revue de presse, nous vous parlions de l’Open Screen Project d’Adobe qui avait décidé de s’ouvrir à la téléphonie mobile (et plus généralement à tous les devices). Cela témoigne ainsi de la volonté de Sun de vouloir s’engager sur le même terrain qu’Adobe et de vouloir s’imposer sur ce marché afin de faire tourner des applications JavaFX sur Java ME.
Enfin à noter le portage de LWUIT sur Androïd, à suivre…

Sortie GWT 1.5

Bruce Johnson tech lead du Google Web Toolkit annonce, 1 an après la sortie de la version 1.4 et deux semaines après la RC 2, l’arrivée de GWT 1.5. Pour mémoire GWT est un framework client-centric permettant de générer la partie client (Html et Javascript) à partir d’un code entièrement écrit en Java. Pour cela, GWT dispose d’une bibliothèque permettant d’émuler le fonctionnement d’une mini-JRE.
La liste des nouveautés arrivant avec cette nouvelle version est plutôt alléchante :

• GWT offre enfin une compatibilité avec Java 5 : l’utilisation des génériques, de l’autoboxing, des énumérations … est maintenant rendue possible.
• GWT en a profité pour étoffer les fonctionnalités de son emulated JRE en ajoutant le support des classes aussi populaires que StringBuilder, TreeMap.
• L’interopérabilité avec des classes écrites manuellement en Javascript ou JSon est également simplifiée.
• Ces nouveautés s’accompagnent d’une première gestion de l’accessibilité du Web
• La gestion des performances est accrue.

Malgré le retard de cette release (environ 5 mois), celle-ci offre un lot de nouvelles fonctionnalités intéressantes. Encore faut-il que ce mode de développement un peu particulier ne vous rebute pas.

• Annonce de la sortie de GWT 1.5 sur le blog de Bruce Johnson
• Démarrez avec GWT : Quick start, Tutorial
• Application GWT qui présente les widgets natifs

Le coin de la technique

Les six commandements de l’architecte

Tim High présente dans Architect Commandments les six qualités essentielles d’un architecte :
1) Se concentrer sur la valeur métier : bien que nous ayons parfois tendance à l’oublier, l’informatique est au service du métier. Et les projets ne doivent pas servir à mettre en avant les technologies que nous maitrisons, ou que nous aimerions découvrir.
2) Remettre en question et clarifier les suppositions : les projets informatiques regorgent de choix imputés à d’obscures raisons historiques ou à des rumeurs, aussi bien fonctionnelles que techniques. Il est important de toutes les tracer : être à l’écoute des nouvelles technologies les plus pertinentes par rapport aux projets en cours, les décisions reposant sur des suppositions, afin de pouvoir justifier et/ou remettre en question ces choix ‘historiques’.
3) Donner le pouvoir à l’équipe : vos décisions d’architecture sont mises en œuvre par une équipe de développeurs. Vous devez donc aussi vous comporter en leader, et donner : être un leader, mais pas au sens premier, c’est-à-dire être un partenaire, un consultant. En résumé être un conseillé de haut niveau, qui accepte le dialogue, donne les moyens à vos équipes de créer ce que vous avez imaginé. Ce qui implique de supprimer tous les obstacles se dressant devant eux, mettre à leur disposition les outils qui leur permettront d’avancer plus facilement mais surtout de les écouter : ils ont la connaissance ‘du terrain’ et vous feront remonter des faits, voire des solutions, souvent pleines de bon sens et en prise avec la réalité.
4) Avoir les yeux grand ouverts : les technologies sont en permanente ébullition, et nous nous devons d’être à l’écoute de ces changements, afin d’offrir à nos clients (et à nos équipes), le meilleur de la technologie. Cependant, attention au revers de la médaille : nos projets ne peuvent en aucun cas être des laboratoires permanents. Le rôle de l’architecte est donc d’être au fait des avancées technologiques, mais aussi de les filtrer, afin d’appliquer à son (ses) projet(s) les plus pertinentes
5) Faire des choix : il vaut mieux prendre des décisions et se préparer à changer de direction que de tergiverser indéfiniment. L’expérience montre que l’absence de décision est souvent plus préjudiciable que le mauvais choix. L’architecte doit se mouiller et mettre ‘sa tête sur le billot’, quitte à revenir sur sa décision.
6) Montrer la voie : attention, nous ne parlons pas ici d’un architecte muré dans ses certitudes (et dans sa tour d’ivoire). Mais plutôt d’un architecte qui est un membre de l’équipe, qui certes prend des décisions, donne les grandes orientions, mais qui les explique, les justifie, les nuance voire les remet en cause avec son équipe. Il doit se donner les moyens de mettre tout le monde dans le même sens.

A ces 6 commandements, nous aimerions en ajouter un septième, tiré de nos expériences :
7) Faire simple et stupide : la grande force d’un architecte, c’est de décomposer les problématiques complexes en problèmes élémentaires, et y apporter des solutions simples. Cette décomposition présente aussi l’avantage d’appliquer plus facilement les points énumérés ci dessus.

Réplication avec Subversion 1.5

John Ferguson Smart présente dans Replication in Subversion 1.5 la réplication de dépôt de source dans Subversion.
C’est une nouvelle fonctionnalité depuis Subversion 1.4.
Cette fonctionnalité peut être implémentée par l’outil de Subversion : svnsync
Voici les quelques commandes à lancer pour mettre en place un dépôt de source miroir qui contiendra un copie du dépôt de source existant :

$ svnadmin create /var/svn/repos-mirror
$ svnsync init svn://svnmirror svn://svnrepos

# Lancement manuel de la synchronisation
$ svnsync sync svn://svnmirror

En utilisant cette fonctionnalité et Apache, on peut aussi réaliser une distribution de dépôt de source afin de limiter le trafic réseau. Il est important de noter que les dépôts de source miroirs sont en lecture seule. Par exemple, cela reste utile pour un outil d’intégration continue. Ce dernier, au lieu d’utiliser le dépôt de source existant, utilisera le code source du dépôt du miroir, en s’assurant que le code source pris soit bien à jour.