Retours du Talend Partner Summit, 15 avril 2010

En 2008, Valtech Technology signait un partenariat avec Talend, jeune éditeur de solutions d’intégration de données Open Source et challenger d’un marché de l’ETL dominé par les solutions propriétaires coûteuses et ciblant avant tout les projets de Business Intelligence.

De ce fait, le positionnement initial de Talend visait l’intégration opérationnelle, c’est-à-dire la synchronisation de données entre applications. Un domaine où les développements spécifiques étaient légions (les fameux « batchs » de données) et sur lequel l’ETL Talend Open Studio était particulièrement compétitif : outil intuitif et facile d’utilisation, connectable à de multiples sources de données grâce à la richesse de ses connecteurs, proposant une large palette de composants prêts à l’emploi pour traiter les données et un design graphique des flux de données au sein d’une interface familière au commun des développeurs Java, le tout sans coût initial d’achat de licences !

Nombre de DSI ont tenté l’aventure et les gains de productivité, d’évolutivité et de maintenabilité des développements middleware ont rapidement convaincu. J’aurai même tendance à dire que le succès de l’ETL Talend, et plus généralement de l’ETL Open Source, a fait de l’ombre à d’autres stratégies d’intégration middleware (notamment l’ESB) car ces outils ont aussi la capacité à gérer des flux en quasi-temps réel ! (Grâce à la technologie de Change Data Capture, ou encore l’exposition possible d’un flux en tant que WebService.)

Depuis, Talend a convaincu certains clients d’utiliser l’ETL sur des problématiques d’alimentation d’entrepôt de données décisionnel (là où la concurrence est plus rude avec des solutions très performantes comme la solution Informatica Powercenter…) et a aussi enrichi son offre : une ligne de produits dédiée à la qualité de la donnée (Talend Data Quality, proposant des fonctions de Data Profiling, Data Cleansing, de portail Web de reporting sur la qualité des données), et surtout, depuis le début de l’année 2010, une offre de Master Data Management : Talend MDM.

Alors, que dire sur le MDM ? Certes, je ne vais surprendre personne en disant que les problématiques de Data Management sont revenues ces dernières années sur le devant de la scène. La faute à des référentiels de données de piètre qualité : donnée incomplète, incohérente, non valide, doublonnée, associée à des valorisations multiples… Le constat d’une mauvaise qualité des données, pourtant vitales et stratégiques aux activités de l’entreprise (le « patrimoine informationnel » de l’entreprise), remonte à tous les niveaux de décisions. Car la donnée de référence est par définition diffusée à l’échelle du SI : applications de CRM, de finance, de RH, de logistique, etc…

Quelles sont les raisons de ce constat ? Citons entre autre : un manque de maîtrise dans la modélisation des données, le manque de contrôles appliqués sur la saisie, des responsabilités mal définies sur la gouvernance des données, des IHMs de saisie souvent obsolètes (technologies 90s’), difficilement maintenables par manque de compétences ou d’intérêt, utilisateurs métier réfractaires à leur utilisation, process d’acquisition et de diffusion des données non rationalisés et mal maîtrisés…

Alors le Master Data Management, qui est à la fois une démarche et un outillage, vise à résoudre ces problèmes soulevés sur la mauvaise qualité du patrimoine informationnel de l’entreprise. Les aspects démarches et outillage se complètent. En effet, aucun outil ne pourra par exemple assurer la pertinence d’une modélisation adaptée à l’ensemble des besoins de l’entreprise, ni encore la cohérence d’une architecture centrée autour d’un Hub de données (le « point de vérité ») et alimenté par de multiples points d’acquisition. Le projet de Data Management est ainsi avant tout une démarche d’urbanisation du SI.

En terme d’outillage, Talend rentre donc sur le marché du MDM avec une solution proposée en 2 versions : la Community Edition (gratuite) et l’Entreprise Edition (version à souscription). Le principe est le même que sur les deux lignes de produits précédentes. La version gratuite permet d’utiliser l’outil sans restriction (licence GPL) et la version payante apporte des briques qui facilitent le travail en équipe et l’exploitation de la plateforme de production.

Talend MDM est un outil complet. Il centralise en une seule plateforme les fonctions de gestion, de gouvernance et d’intégration des données. Citons notamment les fonctionnalités suivantes :

• un éditeur XML pour modéliser (ou consulter) la structure des entités de référence (vue uniquement hiérarchique) ;
• le Studio talend pour définir les jobs d’intégration (connecteurs spécifiques fournies pour les entités du MDM) ;
• un gestionnaire d’évènements pour déclencher les contrôles nécessaires à la validation des données et les jobs assurant leur diffusion ;
• un module de BPM (basé sur la solution de BPM Open Source BonitaSoft) pour assurer les workflows collaboratifs de contrôle et de validation des données ;
• une appli web pour la saisie et le stewardship des données (supervision de la qualité des données).

La solution de Talend vise à outiller les référentiels « génériques ». Elle ne fournit pas de modèle de données pré-défini orienté Produit ou Client et se distingue ainsi de bons nombres de solutions de MDM PIM ou CDM. La concurrence est donc plutôt à chercher actuellement du côté de la solution EBX Platform (Orchestra Networks).

Mais attention, le marché du MDM « générique », boosté par l’offre de Talend, risque de voir arriver sous peu de nouveaux entrants. L’américain Informatica n’a t-il pas annoncé le rachat de l’éditeur de solutions MDM (multi-domaines) Siperian, quasiment le même jour que la sortie de Talend MDM ?!

En tout cas, nul ne se plaindra d’une offre de solutions MDM élargie car la cause est noble : assurer la qualité des référentiels de données afin de fiabiliser les entrants des processus opérationnels et décisionnels à l’échelle de l’ensemble des activités de l’entreprise.

La Soirée Scala au Paris JUG a été riche en découvertes. Les langages fonctionnels et Scala sont encore peu répandus et tout le monde était curieux de découvrir ces nouveaux concepts.

Mais avant de commencer il a fallu patienter un peu :

• une annonce de l’Agile France par Sébastien Douche. Cette conférence aura lieu du 31 Mai au 1 Juin 2010.
• la présentation des sponsors 2010 dont Valtech fait partie
• la présentation d’un nouveau membre de l’équipage du Paris JUG, moi, terminée par quelques mots sur Duchess France et le blog en ligne depuis quelques semaines

Les concepts des langages fonctionnels

Pour commencer, la présentation de Sadek Drobi de Valtech Technology Consulting sur  les concepts de base de la programmation fonctionnelle.

D’abord les types et l’inférence de type. Puis la fonction qui est un concept très simple : une fonction prend des choses en paramètre et renvoie quelque chose.  Dans les langages fonctionnels, c’est un type comme un autre qui peut être utilisé de bien des manières. Sa simplicité permet de la définir au fil de l’eau, de la réutiliser, de la combiner, de la transformer.

La présentation très pédagogique pour les débutants a été ponctuée d’exemples en Scala codés en live.

Faute de temps, les aspects plus spécifiquement OOP  et les traits ont été balayés très rapidement.

Scala par la pratique

La seconde présentation a été assurée par Romain Maton et Nicolas Jozwiak de la société Xebia. Cette présentation a été plus concrète et plus spécifiquement Scala.

Les présentateurs ont tout d’abord présenté les origines de Scala et mis en évidence sa croissance récente dans l’ensemble des langages de la JVM.

Viennent ensuite quelques exemples concrets d’utilisation et une présentation des capacités du pattern matching, de l’API Actor qui permet une meilleure gestion de la concurrence via des échanges asynchrones de messages non mutables,  et des traits, un moyen d’étendre les fonctionnalités d’un objet dynamiquement par une technique de mixin.

Scala a déjà quelques frameworks réputés : Akka, un framework qui étend l’API Actor, ainsi que Lift, un framework de développement Web.  Quelques outils de développement (pluging Eclipse ou IntelliJ, ScalaTest) et nous voilà prêts à développer en Scala.

La dernière partie à été consacrée au futur de Scala, le potentiel et les évolutions prévues pour ce nouveau langage mais aussi le challenge qui résulte du changement de paradigme des langages fonctionnels.

Et ça n’est pas fini

Comme d’habitude, la soirée s’est terminée dans un café proche pour diner ensemble, débattre de tout ce que l’on a découvert et discuter avec les speakers.

La prochaine rencontre du Paris JUG est prévue le 11 mai sur le thème “Share, Build and Deploy” avec un focus sur l’outil de gestion de configuration Git, Maven 3 et l’outil de déploiement Deployit.

Ce billet souhaite inaugurer le début d’une série de billets pour mettre en lumière l’ensemble des technologies gravitant autour de la plateforme .Net de Microsoft, l’intérêt que porte Valtech à cette plateforme ainsi que le savoir faire de la communauté .Net au sein de Valtech.

Pour ce premier billet, nous allons nous attarder sur un projet lancé par Microsoft et voué à rejoindre la version 4 du Framework .Net. Cet outil est actuellement déjà disponible, téléchargeable et utilisable pour peu que l’on dispose de la version 2008 de Visual Studio. Ce projet nommé « Code Contracts » consiste, comme son nom l’indique plutôt bien, à la mise en œuvre pour la plateforme .net (et donc pour l’ensemble des langages de la plateforme) du concept de programmation par contrat.

Le concept est relativement simple et « Code Contract » permet de définir au niveau d’une méthode des pré-conditions (instruction Contract.Requires), des post-conditions (instruction Contract.Ensures) et des objets invariants (instruction Contract.Invariant) c’est-à-dire qu’un objet doit remplir une condition pendant tout le temps d’un traitement (de façon à ce que des variables ne prennent pas des valeurs inattendues). Lorsqu’un des contrats n’est pas respecté, une exception est levée du type ContractException indiquant la condition non respectée.

Une telle approche doit permettre d’établir un contrat fort avec une méthode. Il n’est alors possible de l’appeler qu’avec des données valides c’est-à-dire vérifiant les pré-conditions sous peine de lever une exception. Les erreurs de traitements ou les bugs sont plus rapidement détectés grâce aux différents types de contrat disponibles.

Un autre avantage de ce framework est de pouvoir vérifier certains contrats de façon statique à la compilation et de pouvoir ainsi signaler très tôt des conditions non vérifiées au développeur et ceci à travers des warnings.

Parmi les autres objectifs fixés du projet, on notera également la possibilité d’utiliser ces contrats pour générer automatiquement des tests unitaires plus pertinents en évitant les valeurs ne vérifiant pas les pré-conditions ou en utilisant les pré-conditions pour générer des tests avec des valeurs limites.

On peut noter également que cette démarche simplifie l’écriture de tests unitaires car certains contrôles sont maintenant faits par contrat à l’intérieur de la méthode. Les tests unitaires se bornant alors à appeler la méthode avec plusieurs jeux de données et à vérifier que la méthode ne lève pas d’exception de type ContractException. La programmation par contrat n’ôte pas l’absolue nécessité d’écrire des tests unitaires mais permet d’exprimer dans le code des conditions qui auparavant ne pouvaient être que « vérifiées » par l’utilisation de tests unitaires.

« Code Contracts » devrait également pouvoir à terme servir à générer de la documentation plus pertinente en affichant les pré-conditions et les post-conditions dans la documentation des méthodes.

Quelques informations sur l’installation et la configuration.

L’installation du package téléchargé (cf en bas de cet article) intègre directement les fonctionnalités dans Visual Studio.

L’activation des fonctionnalités se fait dans les propriétés du projet, où un onglet a été ajouté (cf image ci-dessous). On peut alors activer les contrôles à la compilation et/ou ceux à l’exécution.

Pour pouvoir utiliser l’API fournie, il convient d’ajouter une référence dans le projet à l’assembly « Microsoft.Contract ».

Voici donc des exemples concrets de code source.

Toutes les méthodes pour définir des contrats sont des méthodes statiques définies dans la classe Contract présente dans le namespace System.Diagnostics .Contracts.

• Définition de pré-conditions :

Contract.Requires( x ! = null );
 
Contract.Requires( x > y );

• Définition de post-conditions :

normale :

Contract.Ensures( this .F > 0 );

sur une levée d’exception (avec T le type de l’exception) :

Contract.EnsuresOnThrow<T>( this.F > 0 );

sur la valeur de retour (avec T qui est le type de retour de la fonction) :

Contract.Ensures(0 < Contract.Result<T>());

• Définition d’un objet invariant (contrat vérifié tout au long du traitement) :

Contract. Invariant ( this .y >= 0 );
Contract. Invariant ( this .x > this.y );

• Définition d’une assertion (le contrat doit être vérifié à un endroit précis du traitement) :

Contract.Assert( this .x == 3, "la valeur devrait être 3" );

Voici donc un exemple un peu plus complet :

public class CodeContract
{
  public static void Main(string[] arg)
  {
    CodeContract cc = new CodeContract();
    cc.Test1();
    cc.Test2();
  }
  public void Test1()
  {
    DivideUnderZero(5, 3);
  }
  public void Test2()
  {
    DivideUnderZero(5, 0);
    //Warning à la compilation (problème détecté de façon statique)
    //contracts: requires is false: denominateur doit être different de 0
  }
  public float DivideUnderZero(int num, int den)
  {
    Contract.Requires(den != 0, "denominateur doit être different de 0");
    Contract.Requires(num > den);
    Contract.Ensures(0 < Contract.Result<System.Single>());
 
    //Warning à la compilation (problème potentiel détecté mais résolu lors de l'execution)
    //contracts: ensures unproven
    return num / den;
  }
}

Pour conclure, je pense que l’introduction de la programmation par contrat introduit dans le framework .Net par une approche très facile à mettre en œuvre aide le développeur à détecter rapidement ces erreurs lors de l’écriture du « bon code ». Ceci convient tout à fait à l’écriture de code métier dans lequel les erreurs peuvent coûter cher et être difficilement détectables. La programmation par contrat est donc un nouvel outil dans l’escarcelle du développeur.

D’aucun pourrait reprocher à cette approche le fait d’avoir un code moins ouvert à l’évolution. Auquel cas je répondrais que toute évolution du code nécessite de toute façon la modification des tests unitaires et donc que la modification des contrats fait aussi dans cette logique d’évolution de façon à écrire et garantir le bon fonctionnement du code écrit.

Sources :
Manuel Utilisateur
Site Web
Téléchargement de Code Contract:

Suite à beaucoup de mystère, Didier Girard nous à présenté hier les évolutions réalisé par Google de l’App Engine Java hier chez Google France.

Ayant eu la chance d’être parmi les développeurs sélectionnés, voici les points présentés :

• Chiffres : 150k développeurs travaillent avec App Engine, 50k app sont déployés : Ebay, BuddyPoke …

• Présentation des évolutions de la console d’administration :

1. différentes métriques de consommation,
2. la possibilité de gérer sa consommation et de payer du dépassement à la demande
3. présentation du système de Cloud computing pour la gestion de la performance et de la consommation
4. l’accès à la base de données,
5. import export des données
6. La gestion du Cache pour faire des économies
7. La gestion de CRON : interrogation d’URL (avec un petit + la définition de la Time Zone)
8. le SDC, Secure Data Connector : pour créer une connexion ssl à votre SI …

• Présentation du plugin Google pour eclipse

1. Création de projet simple et prêt à être déployé via App Engine (Sur les bases de GWT)
2. choix des sdk gwt et App Engine à utiliser dans votre application
3. seul obligation pour votre application : définir le nom de l’application ( à voir + tard la définition des noms de domaines)
4. présentation de la gestion de persistance en JDO (ou JPA) via la base Google de type BigTable.

Google nous propose donc un moyen simple de créer des application web en java simple à déployer, dans le cadre d’application Open-Social.

Pour le moment cela semble très prometteur. A vous de faire une demande de compte chez google pour commencer à réaliser vos applications.

A voir les applications de Didier :

Wolfengine et ergosum

Annonces :

• Guillaume Laforge a réalisé la portabilité de Groove sur App Eng.
• Un plugin Maven devrait être mis à disposition cette semaine sur google code.

Voila pour les infos glanés lors de la présentation chez Google France.

Valtech Lunch, une rencontre conviviale autour d’un déjeuner !
Avec le témoignage du Club Méditerranée
Le 7 Avril 2009 à Paris la Défense

Votre emploi du temps ne vous permet pas toujours d’accorder suffisamment de temps à la veille technologique ;
c’est pourquoi Valtech vous propose une rencontre de 12h15 à 13h45.

Ainsi, sans surcharger votre agenda, vous aurez l’occasion de faire le point sur ce qu’il est envisageable de faire en termes de migration progressive de systèmes d’information de type Mainframe vers des technologies moins onéreuses et plus flexibles.

Cette présentation durera 1h30 et sera accompagnée d’un déjeuner léger (type plateau repas).

Pour chaque inscription (60 € par personne), nous vous proposons d’inviter gratuitement une personne de votre choix.

Inscrivez-vous à la session Valtech Lunch du 7 Avril 2009

Les erreurs passent, il n’y a que le vrai qui reste.

Discutons les préjugés qui éclosent autour de REST (REpresentational State Transfer).
REST est un style d’architecture fondé sur ce qui définit le WEB.

1. REST n’a rien inventé, le premier des serveurs WEB faisait déjà du REST…

C’est vrai et REST propose une vision d’un WEB étendu aux échanges de machine à machine (M2M) là où le WEB est aujourd’hui un système dont les consommateurs sont des humains.

2. J’ai implémenté un programme sur mon serveur WEB qui renvoie des Représentations différentes en fonction de l’attribut Accept de l’entête HTTP et de la méthode (GET, PUT, DELETE) envoyée par le client, je fais donc du REST.

Partiellement vrai. On ne peut pas vraiment décréter que l’on fait du REST sans savoir à quelles contraintes on doit se plier. Au départ, on trouve la thèse de Roy Fiedling. Il a analysé les caractéristiques du système WEB en interaction avec les utilisateurs humains. Par extension, il a construit le style REST pour le dialogue de machine à machine, dont chacune des propriétés suivantes offrent des qualités au système:

1. Données structurées au dessus d’HTTP: accessibilité
2. Universal Ressource Identifier (URI): adressabilité, diffusabilité de l’information
3. Sans état: montée en charge (scalability)
4. Contrat uniforme (verbes HTTP): inter-médiation (cache, sécurité, etc.), contrôle
5. Sûreté (répétabilité du GET) & idem potence (une modification produit toujours le même résultat, par exemple, la fonction incrément n’est pas idempotente): robustesse à la perte de communication serveur
6. Hyperliens (les liens inclus dans la représentation de la ressource permettent de naviger vers ses services associés – pensons aux pages WEB des humains !) : couplage lâche (pas besoin d’extraire l’identification de la ressource pour la passer aux autres services)
7. HATEOAS (Hypermedia As The Engine Of Application State): montée en charge
8. Ressource auto-porteuse de l’information (pas besoin de notice pour consommer la ressource: utiliser le type de la ressource – est-il connu ?, lire son contenu pour trouver comment s’en servir – contient-il des hyperliens ?): couplage lâche

La vision puriste de REST, celle de son créateur, détermine que toutes ces contraintes doivent être respectées pour arriver à un système REST. Dans les faits, seules les premières étapes son outillées. Soyez indulgent avec le prochain puriste qui vous dira que votre système n’est pas REST et demandez lui s’il a bientôt terminé son implémentation pour le support des deux derniers niveaux…
Notons qu’aujourd’hui, le WEB “humain” (celui qui nous fait surfer d’une page à l’autre) satisfait ces contraintes, même la dernière: les liens et formulaires des pages sont interprétables par nos cerveaux évolués.

3. Si je dois assurer l’idem potence, je ne peux pas implémenter la fonction incrément, par exemple ?

Il faut préciser en disant qu’on ne peut pas la réaliser côté serveur. D’ume manière générale, il y a un surcoût lorsque l’on architecture un système sur REST. Nous sommes peut-être trop habitués à penser RPC et pas assez Ressource. Dès que l’on est bloqué en REST, il faut inventer une nouvelle ressource qui réalisera la fonction souhaitée.
Par exemple, pour la gestion des transactions, on peut créer une ressource transaction qui possède un état et dont la représentation permettrait de confirmer la transaction ou l’annuler annuler. Vous pouvez lire le thread suivant : [xml-dev] A question about REST and transaction isolation (en anglais) qui date de février 2004, et oui, il y a cinq ans !
A la différence des services web RPC classiques, REST ne propose donc pas de solution native pour répondre à la problématique des transactions applicatives. Si on en a besoin, il faut analyser son besoin transactionnel et l’implémenter grâce à une ressource.

4. Je dois donc juste faire un choix de framework pour commencer à développer avec REST.

Oui, c’est un bon point d’entrée. Et il ne faut pas non plus négliger le choix du framework de marshalling qui a un impact direct sur la quantité de code applicatif à développer. Un client disait qu’il était tenté de se passer de framework puisqu’on était sur les bases du web, et c’est vrai, on pourrait se contenter de l’API Servlet dans le monde java par exemple. Cependant, dès que l’on va commencer à écrire ses servlet REST, il va y avoir du code en commun: la gestion des header, la représentation des ressources en flux Json ou XML par exemple. Il y a donc bel et bien la place pour un framework REST ici. Nous avons déjà des expériences sur le choix à faire et nous pouvons vous aider.

5. Avec REST, on doit exposer ses objets métiers de trop de formats différent: XML ad-hoc, XML générique RSS ou Atom, Json…

La multi-représentabilité est aussi une force. Si vous choississez Atom par exemple, vous bénéficiez de tous les clients Atom déjà développés : clients lourds, intégration dans les portails, etc. Vos données disposent alors d’une diffusabilité maximale.
De même, si vos utilisateurs sont déjà des consommateurs de pages WEB, de flux RSS, ils retrouveront des applications familières. Si on va jusqu’au bout, les outils de Mashups qui cherchent a laisser l’utilisateur libre de construire lui-même les services dont il a besoin, seront friands des ressources REST à consommer.

6. REST est l’architecture utilisée par le WEB actuel. Mais dans mon S.I., je n’ai pas besoin que ma donnée fasse trois fois le tour de la Terre avant d’être consommé par un employé…

Le fait que le WEB soit un réseau mondial n’est pas ce qui nous intéresse pour les application métier. Le vrai critère ici, c’est plutôt la propriété de montée en charge qui a son importance pour les S.I. A l’heure du Cloud Computing (que les vendeurs de solutions hébergées ont bien du mal à évangéliser), un S.I. bâtit sur REST à l’opportunité de bénéficier de la robustesse de tous les équipements et stratégies qui rendent le WEB performant:

• proxy
• cache (Cache-Control, ETag)
• compression des requêtes (Accept-Encoding / Content-Encoding)

REST est une approche rafraichissante dans le monde très server-side de Java aujourd’hui. Ce style architectural résonne d’une tonalité très actuelle en 2009 sur les architectures où la performance, la montée en charge et la robustesse à la perte de connexion en situation de mobilité sont des critères de plus en plus porteurs de valeur pour les applications que nous concevons. Les RIAs seront tout particulièrement intéressées par la consommation des services possédants de telles qualités.

Pour en savoir plus, vous pouvez venir au prochain Valtech AfterWork qui abordera le sujet SOA (précisions sur ce précédent billet).

Mercredi 25 mars 2009 – 18h30 Paris la Défense

Après l’Afterwork GWT…

Après l’Afterwork Agilité…

Encore un évènement inédit proposé par Valtech avec une toute nouvelle session dédiée à l’Architecture et SOA! Cet évènement gratuit se déroule dans les locaux de Valtech Training, au rez de chaussée du bâtiment “Coeur Défense”. Cette session est ouverte à toutes et tous. C’est un moyen privilégié de découvrir l’Architecture, mais aussi le groupe Valtech dans une ambiance très conviviale et propice aux échanges.

A travers cette présentation, nous vous présenterons la vision de Valtech pour les architectures de services et comment concrètement les aborder tout en s’inscrivant dans un legacy fort. Nous parlerons notamment des ESB, présentés comme la pierre angulaire de SOA et de l’alternative technologique REST.

Au programme:

• SOA, la vision de Valtech,
• Panorama des ESB open-sources,
• L’alternative REST,
• Et bien sûr, une pause pour se restaurer et échanger sur les sujets qui vous intéressent.

Ne manquez surtout pas cette soirée ! Les places sont limitées, pour vous inscrire, cliquez ici :

Détails et inscription pour l’AfterWork « Architecture et SOA »

Ce Samedi 31 Janvier a eu lieu un JavaCamp à Paris, le JavaCampParis 3.

A partir de 9h30 – 10h, les premiers participants sont arrivés; et après un détour par la machine à café, le JavaCamp a démarré.

Les personnes présentes ont alors proposé des sujets qui les intéressaient (et se sont aussi présentées); ensuite, une “refactorisation” des sujets proposés a mis en évidence 7 thèmes :

• TDD (Test Driven Development)
• langages de scripting autour de la JVM (Scala, Groovy, Ruby)
• DDD (Domain Driven Design)
• les langages RIA et les frameworks Web: GWT, Flex, Wicket
• Scrum
• JEE 6 et Spring
• SOA
• Les Mocks

Ces thèmes ont pu être débattus/présentés par les participants dans 2 salles et sur 4 créneaux horaires : 10h15 -11h30, 10h45-13h00, 13h30-14h30, 14h45-16h.

Pendant la séance “les langages RIA et les frameworks Web: GWT, Flex, Wicket”, Tarik, et Eric, nous ont présenté Wicket (en avant premiere de ParisJug) et leur framework au dessus Wicket (pour faciliter et mettre à jour dynamiquement les formulaires dans Wicket); et avant de plus partir sur Flex, j’ai pu présenter la mise en oeuvre de GWT.

En abordant les “langages de scripting autour de la JVM (Scala, Groovy, Ruby)”, on a pu parler de la facilité d’intégration, de la mise en oeuvre, de l’intéret et de la pertinence des iDE dans le cadre des développements Scala (qui est compilé), Ruby, Groovy et Java Fx.

En parallèle, dans la salle “Solaris”, les débats ont porté sur la testabilité des programmes java. Nous avons eu un bon aperçu des différentes pratiques et technologies associées aux tests logiciels. En vrac: les x-Unit, Selenium, GreenPepper, FitNesse, Concordion, Bumblebee, SWTBot. Le débat suivant fut une présentation de DDD (Domain Driven Design) par Sébastien Letélié et le principal framework : Qi4j. Une approche intéressante qui est une “sur-couche” à la programmation orientée objet. Cette vision incite les objets java à se décomposer par comportement. On obtient donc un composite formé de plusieurs associations.

Dans l’autre salle, durant la séance “Scrum”, après de brefs retour d’expérience, Eric (pas le même que celui de Wicket, mais le co-organisateur) a pris la parole, et après avoir défini Scrum, nous a fait part de son avis sur combien Scrum peut être mal appliqué, et, ainsi souffrir d’une image négative; d’ailleurs le sujet a ensuite débordé sur le cycle de vie des méthodologies projets (la courbe des experts, early adopters, main stream users, …), et un comparatif entre ces dernières.

Un grand merci aux sponsors de la journée, Sun (pour les locaux) et Valtech (pour le petit déjeuner et les pizzas à midi), ainsi qu’à Jean Yves Pronier (côté Sun pour les locaux), Eric Lefevre-Ardant (co-organisateur avec moi-même), Eric Le Merdy, Claude Falguière (soutiens) et Alexis Moussine-Pouchkine (qui nous a mis en contact avec Jean-Yves), ainsi qu’aux participants pour le bon déroulement de la journée.

D’autres retours:

• I.T. Aware (Sébastien Letélié): http://www.itaware.eu/2009/01/31/javacamp-iii-tdd-et-ddd/
• Tom’s Quest: http://www.tomsquest.com/blog/javacamp-3-compte-rendu/
• The Coder’s Breakfast: http://thecodersbreakfast.net/index.php?post/2009/02/01/Java-Barcamp-3-%3A-compte-rendu
• Photos d’Eric Lefevre: http://flickr.com/photos/elefevre/sets/72157613231545482/

Cet article fait suite à la présentation de Rational Quality Manager reçue à l’IBM Innovation Center (Noisy le Grand), et mes expérimentations avec la trial de cet outil.

Rational est assurément abonné à la newsletter Valtech. Dans un premier article sur Rational TestManager, je reprochais à ce dernier ses capacités de personnalisation pour ainsi dire inexistantes. Rational sortait alors en remplacement de RTM : CQTM, basé sur Clearquest. On était alors à la limite de l’outil de développement au niveau des possibilités de personnalisation. Dans un second article, c’est l’intégration insuffisante de CQTM à ses outils d’exécution de test (RFT, RMT, RPT, …) qui était montrée du doigt. Aujourd’hui, IBM Rational sort Rational Quality Manager (RQM), basé sur Jazz dont le maitre mot est : intégration.
A la fin de cet article, vous saurez que le principal reproche que l’on peut faire à RQM est qu’il est payant. Le prochain outil d’IBM sera donc entièrement gratuit et totalement open source.

Ou pas.

RQM fait donc suite à CQTM, faisant lui-même suite à RTM, souhaitons-lui tout d’abord une vie plus longue que ses prédécesseurs…
Sorti fin Octobre 2008, RQM est basé sur la nouvelle plateforme Jazz, dont l’objectif avoué est de réussir coté serveur ce que Eclipse a réussi du coté du poste de travail : proposer un socle ouvert, extensible (interfaces REST) et collaboratif et devenir de facto un « standard » d’intégration (d’autres éditeurs commencent déjà à proposer leurs solutions sur Jazz).
En plus de permettre une intégration entre outils et une meilleure communication des différents utilisateurs, Jazz répond également aux problèmes de couplage entre outils et de dépendance de versions. Problématique dont IBM est bien au fait avec sa large gamme d’outils incompatible entre versions différentes. Jazz, en récupérant le mécanisme de mise à jour d’Eclipse simplifie donc cette partie, pour le bonheur de l’utilisateur, et d’IBM.

Le projet Jazz, initié il y a 2 ans par IBM est ouvert mais pas open source, ce qui concrètement signifie que les partenaires du projet peuvent y participer et y apporter leurs orientations et contributions, mais le code source n’est pas public.
Jazz et RTC sont utilisés pour leur propre développement, et leur avancement visibles de tous en direct sur jazz.net.

RQM est donc l’un des premiers « plug-in » Jazz, au coté de Rational Team Concert (RTC) qui lui adresse la partie développement (oui, le test et le développement sont encore séparés, même si désormais Jazz est là pour les unir dans la joie et l’agilité), et Rational Requirement Composer (RRC), dédié à l’activité de mise au point des exigences fonctionnelles d’un projet, RequisitePro s’occupant de leur gestion (cycle de vie, matrice de dépendances, etc.).

RQM s’interface également avec les différents outils de test suivants :
• Rational Functional Tester : outil d’automatisation des tests d’IHM
• Rational Performance Tester : outil de tests de charge et de performance
• Rational Service Tester : outil de test de web services
• AppScan : outil de sécurité serveur et respect des standards

A noter la disparition de Rational Manual Tester, puisque les tests manuels sont maintenant directement gérés par RQM.
Il est également possible de se connecter à des bases Clearquest et les synchroniser avec RQM, par l’intermédiaire du connecteur Jazz.

A la différence de CQTM où le client le plus complet était le client Eclipse, RQM ne propose dans l’état actuel qu’un client web mais celui-ci supporte l’ensemble des fonctionnalités de RQM (y compris l’exécution des tests de tout type). Un client RQM Eclipse est attendu courant 2009, afin notamment d’éviter aux développeurs d’avoir à quitter Eclipse pour bénéficier de l’intégration RTC-RQM.
Cependant, ce client web s’avère très agréable à l’utilisation, son ergonomie a été largement améliorée depuis CQTM, et il bénéficie maintenant d’une navigation par onglets, d’une barre de navigation générale, et utilise les technos du web dynamique (menus déroulants, panels qui scrollent avec la fenêtre, drag and drop, popup en surimpression, …). La durée nécessaire pour ouvrir une session est par ailleurs assez élevée (environ 20 secondes en localhost server).

Au sujet de l’intégration entre RQM et RTC, il s’avère que les versions actuelles ne sont pas compatibles entre elles. Il n’est pas possible d’installer RTC et RQM dans la même instance Jazz, les processus permettant une collaboration entre le développement et le test sont donc inactifs et les bases de données des 2 outils séparées. Une des conséquences est que les anomalies doivent être dupliquées entre RQM et RTC.
RQM et RTC devraient être rendus compatibles dans le courant de Q1’09.

RQM s’articule autour des grandes parties classiques suivantes :
• Déclaration des exigences
• Conception et gestion des plans de test et des cas de test
• Construction des scripts de tests (manuels ou automatisés)
• Création des suites de test
• Exécution des tests
• Analyse des résultats
• Création et gestion des anomalies
• Reporting

RQM permet la création de work items Jazz de type exigence. Ce work item est assez simple, on y retrouve les informations classiques (description, commentaires, pièces jointes, lien avec cas de test, …) mais il n’est pas hiérarchisé (pas d’arborescence). Il faudra passer par une requête pour les visualiser (de la même manière que dans le client web CQTM).
Si il est possible d’importer la plupart des types de fiches depuis des fichiers XML, il également possible pour les exigences de les importer depuis RequisitePro.
Chaque action effectuée dans RQM est consignée dans un journal d’évènements, et il est possible de s’inscrire à certains types d’évènements afin d’en recevoir des notifications (mail ou flux RSS).

Le « Test Plan », objet central dans RQM, possède de nombreuses sections : résumé/description, objectifs de test, objectifs qualité, objectifs business, exigences, planification, estimation de charges, environnements de test, équipe en charge, critères d’entrée et de sortie, cas de test, pièces-jointes, et emplacements de ressources partagées. En gros, les différents éléments que l’on peut retrouver dans une stratégie de test.

Il est possible de créer des templates afin de limiter l’affichage qu’à certaines sections, ainsi que créer un « snapshot » afin de prendre une photo du plan de test à un instant donné. Il est également possible pour l’utilisateur de déléguer l’approbation d’un plan de test (ou d’un cas de test) à d’autres utilisateurs n’ayant pas ce droit à la base. A noter qu’il existe des raccourcis dans les différentes fiches pour créer rapidement des tâches (work items) afin de tracer ou déléguer ce qu’il reste à faire.
Comme pour les exigences, le plan de test n’est pas hiérarchisé.

Les cas de test, rassemblés dans les plans de test, possèdent eux les sections suivantes : résumé/description, coût (sera utilisé comme critère de pondération pour estimer l’avancement des campagnes de test), couvertures d’exigences, pré et post conditions (description textuelle), résultats attendus, et pièces jointes.
Comme pour les plans de test, la plupart de ces sections sont textuelles, elles ne servent donc qu’à séparer les différents types d’informations, qui auraient pu se retrouver rassemblées dans le champ description. La présence de ces différents champs/sections n’apporte pas d’information supplémentaire ni ne rend la conception des tests plus rapide.
L’avant-dernière section des cas de test est celle des scripts de test. Oui, scripts de test au pluriel car c’est bien plusieurs scripts que l’on peut associer à un même cas de test, le choix du script à exécuter se faisant au moment de l’exécution.
La dernière section des cas de test est celle des « test execution record » (TER).

Ces TER remplacent les « configured test cases » de CQTM, qui associent à un cas de test un environnement de test (par exemple, Windows XP SP2, IE7 et WAS6) – la configuration anciennement dans CQTM.
RQM permet de générer automatiquement des TER à partir des différentes combinaisons possibles parmi les environnements d’exécution. Il est possible de choisir le niveau de couverture souhaité, ce qui va influer sur le nombre de TER générés. Le réglage dit optimal utilise la technique « pairwise » (combinatoire par paire)

A la différence de CQTM, les scripts sont des fiches sous RQM. Pour être tout à fait précis, c’était aussi des fiches sous CQTM mais elles étaient masquées à l’utilisateur (TMExternalFile). La fiche test script est donc visible, et en plus du script à proprement parler, elle possède également un titre, une description, et un type. En fonction du type choisi, une série de paramètres vont devoir être renseignés. Pour la majorité des types, il suffira d’indiquer le nom et l’emplacement du fichier de script du type choisi à exécuter. En sus des outils précédemment cités (RFT, RPT, …), un script dans RQM peut être de type ligne de commande (on indique alors la commande système à exécuter, par exemple appel d’un batch, ainsi que les arguments à utiliser) ou manuel.
C’est pour le type manuel que RQM offre le plus de possibilités (ce qui est un peu normal puisque c’est le seul type de script pour lequel la conception a lieu dans RQM). Globalement, on retrouve le même fonctionnement que celui de Rational Manual Tester, on crée une succession d’étapes en indiquant si c’est une étape de type action ou de type vérification. L’interface est similaire également, l’éditeur d’étape est de type rich text, en plus de possibilités de formatage du texte assez complètes (taille, couleur, alignement, puces, tableau, …), on retrouve les assistants d’insertion et de comparaison de données de RMT. RQM intègre donc un RMT version web (Eclipse précédemment).

Il est également possible de créer des « test data » (les datapools de CQTM) à partir de fichier CSV, afin d’externaliser dans des tableaux les jeux de données à utiliser dans les scripts. On peut ainsi variabiliser un script en l’associant à un datapool à plusieurs lignes, ou en créant une autre fiche script avec le même fichier de script et un autre datapool si l’on veut individualiser leurs résultats d’exécution.

Un nouvel objet qui apparait dans RQM est le « keyword ». Un keyword possède un nom, un type (manuel, RFT, …) et un script associé. Les keywords, à l’image de feu les actions réutilisables de RMT, servent à définir un ensemble d’actions/vérifications (celles consignées dans le script associé) réutilisables dans différents autres scripts. Ils permettent ainsi la factorisation des étapes de script, avec tous les avantages que cela comporte : création plus rapide des scripts, il suffit de piocher parmi ses keywords, maintenance facilitée, puisque il suffit de modifier le script d’un keyword pour modifier l’ensemble des scripts utilisant ce keyword, etc.

Autre changement par rapport à CQTM, l’exécution des tests est maintenant possible depuis le client web. Le serveur web contacte la machine de test sur laquelle doit être exécuté le test, à l’aide d’un agent tournant dessus en tâche de fond (nommé « adapter »).
Voici un exemple avec RFT :

Le client web se cantonne donc à un rôle de superviseur d’exécution, il n’a pas de rôle actif dans l’exécution des tests, à l’exception des scripts manuels, et sauf bien sur si un outil d’exécution de test est installé sur la même machine.
RQM étant de fait orienté test distribué, il permet de gérer un parc de machine de test. On déclare une machine avec sa configuration physique, puis ses différents OS / VM, et par OS, ses différentes applications. RQM est ensuite capable de récupérer la liste des adapters présents sur ce système afin de savoir quels types de scripts pourront être exécutés dessus. Il est également possible de créer des groupes de machines.
Fonctionnalité qui pourra être intéressante pour les équipes de test importante et/ou reparties géographiquement, ou les machines de test particulières (pré-prod, plateforme de test de charge, etc.) : il est possible de faire des demandes de réservation de machines de test, pour une plage de temps donnée, et de gérer le calendrier des réservations.

Les différents cas de test sont assemblés dans des suites de test, qui seront ensuite exécutées. A noter la présence d’une option dans la suite de test qui permet d’exécuter en parallèle ses différents cas de test, ce qui pourra être intéressant dans le cadre de tests distribués sur plusieurs machines. Ce n’est pas encore l’ « execution flow » de Mercury, mais c’est toujours ça en plus par rapport à CQTM.
L’exécution d’une campagne, en plus d’être déclenchée manuellement, peut également avoir lieu suite à un évènement donné dans la plateforme Jazz, typiquement la création d’un nouveau build dans RTC.
La console d’exécution permet de suivre l’avancement des suites de test en cours d’exécution.
Les « execution results » sont sauvegardés au terme de chaque exécution, pour les cas de test et les suites de test.

Le dernier type de fiche de RQM, qui vient logiquement après l’exécution des tests, est le « defect ».
Il est possible de créer durant les exécutions des defects afin de garder la traçabilité entre l’anomalie et le test qui l’a mis en évidence.

Les fiches defect sont assez semblables à ce que l’on pouvait trouver dans CQTM, je ne rentrerai donc pas dans leur détail. A noter que si il est possible de retrouver les defects saisis ou rattachés durant une exécution (de manière assez laborieuse), je n’ai pas trouvé le mécanisme inverse qui permettrait de connaitre à partir d’un defect, quels tests l’ont mis en évidence.

La dernière partie de RQM est la partie reporting. Elle utilise BIRT, mais il semblerait qu’elle ne soit pas totalement finalisée dans la version actuelle de RQM (pas trouvé comment créer de reports).
En dehors des reports, il est toujours possible de créer ses propres « viewlets » et sous-onglets dans son dashboard / page d’accueil, et de ce coté, les possibilités et l’ergonomie sont plutôt sympathiques.

A noter qu’un nouvel outil dédié au reporting fera son apparition avec Jazz : Rational Enterprise Reporting.

Autre limitation de la version actuelle : RQM ne supporte qu’une seule « project area », tous les utilisateurs et toutes les fiches sont donc partagés, et pour créer un cloisonnement entre projets distincts, il faudra installer plusieurs instances du serveur RQM/Jazz.

Et pour terminer : la customisation. Sur ce sujet, le nouveau challenger va devoir batailler ferme pour atteindre les possibilités de son aïeul CQTM.
La customisation se répartit entre client web et Eclipse de RQM, ou plutôt RTC pour la partie Eclipse puisque le client Eclipse de RQM n’existant pas encore et l’unification par Jazz aidant, c’est le client RTC qui récupère la partie customisation de RQM.
Le client web de RQM permet la création d’utilisateurs et d’équipes, la configuration des ressources partagées, de la base de données Jazz, la gestion des licences, etc.
Le client Eclipse/RTC gère donc le reste et le plus intéressant, à savoir la définition des rôles et des process / workflows, la personnalisation des projets, des fiches, etc.
N’ayant pas vu cette partie, je ne pourrais donc pas vous en parler dans l’immédiat.

Pour conclure, et ne pas déroger à la règle des précédents articles, voici à mon sens un petit récapitulatif des avantages et des inconvénients de RQM à ce jour :

Points forts :

- Client web réussi. Interface intuitive et efficace, et supportant l’ensemble des fonctionnalités utilisateur (ce qui n’était pas le cas de CQTM)
- Conception des tests manuels maintenant intégrée (comme pour Quality Center, tiens). On a maintenant avec RQM un RMT version web.
- Dashboard en page d’accueil. Nombreuses possibilités de personnalisation, interface ergonomique, résultats convaincants
- Solution de keywords efficace
- Jazz. Intégration et collaboration (partie non couverte par cet article. A creuser)

Points faibles :

- Recherche d’objet (cas de test, keyword, exécution, etc.) parfois laborieuse. Le requêtage est bien plus limité que ce que CQTM offrait avec ses recherches multi-critères et multi-opérateurs (equals, in, like, not, less, more, etc.)
- Absence de hiérarchie au sein d’un même type d’objet. Il existe des liens entre objets de type différent (par exemple, plan de test => cas de test), mais il pourrait être utile d’avoir une hiérarchie pour les plans de test, les exigences, les suites de test et les anomalies (mère-filles). Et pour rejoindre le 1er point faible, il serait bon de voir apparaitre une tree list, afin de faire du « drill down » dans les objets de RQM.
- Pas de client Eclipse (à venir ?)
- Possibilités de customisation moindres que celles de CQTM (partie à creuser également dans un prochain article)
- Licences. Les licences sont actuellement nominatives ! Pour 100 utilisateurs différents, il faudra 100 licences, même si seuls 10 se connectent simultanément. Espérons qu’un mode de licences flottantes est prévue pour bientôt… De plus, les fonctionnalités avancées de la partie exécution (réservation machines, etc.) nécessitent une licence supplémentaire. Pour finir, l’obligation de faire évoluer le type de licence serveur selon le nombre d’utilisateurs maximum (5, 250, …). Une facturation à la licence flottante ne serait-elle pas suffisante ?
- Version en cours non finalisée entièrement. La plateforme Jazz et ses greffons sont encore jeunes, et ça se voit parfois (bien que la stabilité de RQM soit irréprochable). Je ne sais pas si le tout est exploitable en production dans l’état, mais on pourra en reparler dans un prochain article dans 6 mois…

La semaine dernière, avec Pascal, nous présentions une seconde fois l’after work GWT (voir le post précédent pour le 1er afterwork).

Si vous n’êtes pas très saumon fumé ni champagne, mais plutôt Eclipse et Widget, je vous propose de réveillonner avec notre présentation mise à jour, ainsi que les workspaces d’execices et de correction !

Ces workspaces sont utilisables sous windows (avec un JDK 5 minimum).

Pour n’avoir aucun problème, vous devrez installer gwt et gwtext C:\dev, selon l’arborescence suivante (des chemins en dur sont présents dans les .launch entre autres) :

C:\dev\gwt\gwt-windows-1.5.3

C:\dev\gwt\gwtext-2.0.5

Pour Linux et MacOsX, le mieux est de récupérer les projets et de corriger les chemins de lancement (.launch).

Le succès était encore une fois au rendez vous, je remercie encore l’organisation côté Valtech Technology Consulting et côté Valtech Training !

Joyeux Noël à tous !

AfterWork GWT : présentations et TP