Bonjour,

C’est parti, le SUG French is launched !

Lors de la Soirée inaugurale French SUG du jeudi 19 mars 2009, nous avons eu le plaisir d’accueillir  M. Jeff Sutherland avec un World Wide Tour sur Scrum, vous vous dites “des chiffres, des chiffres” voici directement les slides de la présentation : FrenchUserGroupMar2009.

Ce qui me semble quand même beaucoup plus important est l’annonce faite par Luc Legardeur : “Jeff nous propose d’organiser les prochains “Scrum Gathering” à Paris !!!”.

Autre invité de marque : Claude Aubry qui nous a présenté l’état de Scrum en France en comparaison avec XP et le cycle en V, résultat des courses, le cycle en V se meurt, XP pur s’épuise tandis que Scrum ne cesse de progresser depuis 2005 (de 12 certifiés à 550 à ce jour).

Il ressort de ces présentations le constat du manque de retour sur l’application de Scrum en France. C’est pour cela que le French SUG se propose de lancer un audit auprès des 550 Scrum Master certifiés ainsi qu’aux entreprises Agiles.

En bref, un lancement réussi (+100 personnes), sponsorisé par Borland.

Les membres du bureau ont été rapidement présentés en début de soirée mais pour le moment le site n’est pas encore à jour. Dans tous les cas, les membres de ce bureau sont bien représentatifs de l’écosystème Agile en 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

Jean-Baptiste Cazaux nous a donné un cours du soir la semaine dernière sur la technologie Flex d’Adobe.

Cela a pu donner l’occasion aux consultants présents de confirmer une récente étude du cabinet Gartner sur le marché des technologies RIA. A la lumière des démonstrations du présentateur, nous avons effectivement constaté la maturité de la plate-forme.

Le programme fut riche:

• Démos d’applications Flex et AIR
• Présentation du langage et des outils
• Debug d’une application
• Extensions de composants graphiques
• La gestion des évènements
• Les layouts
• Le Framework MVC Cairngorm

Le moins que l’on puisse dire, c’est que Jean-Baptiste a su nous donner envie d’aller plus loin dans la découverte de la plate-forme applicative. Nous nous revoyons d’ailleurs cette semaine pour la suite de la présentation.

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).

Merci à Éric Le Merdy de nous avoir présenté le cours du soir sur le graphisme mercredi dernier.
La présentation qui est elle-même un bel exemple de design est disponible sur slideshare :
http://www.slideshare.net/eric.lemerdy/le-graphisme

Éric nous a présenté quelques principes de design, des sources d’inspiration et des ressources sur internet (voir la présentation) puis nous a montré concrètement comment utiliser Inkscape pour produire facilement des images sympas.

Éric nous a montré très modestement comment il produit ses créations et nous a tous donné envie d’en faire autant.

Il y a demain mercredi 4 mars à 18h30, un cours sur le graphisme, animé par Eric Le Merdy. Eric a déjà réalisé plusieurs dessins pour illustrer son blog (voir par exemple ici) mais aussi des documents de certains de nos clients. Sans être graphiste, ses capacités à réaliser des illustrations est utile à Eric dans son travail de consultant.

Eric réalise la majorité de ses dessins à l’aide de l’outil Inkscape. Le cours sera donc principalement basé dessus.

Au programme:

• Inkscape: Vectors, vectors, vectors  !
• Inkscape: Vectorisation de Bitmap
• Inkscape: Dessin (formes, coloriage (!) )
• Inkscape: Réutilisation d’internet (Open Clip Art, dafont, etc.)
• Gimp: Snapshots
• Gimp: Layers, layers, layers !

Notre fil rouge sera de travailler sur l’amélioration du badge de CITCON.

Il y aura des démos d’Inkscape (téléchargez-le pour tester en séance).

Vous n’ètes pas employé de Valtech?

Cette soirée est donnée par un Valtechien pour les Valtechiens. Néanmoins, si le sujet vous intéresse, il est possible de nous rejoindre. Pour cela, contactez-nous à l’adresse eric POINT lefevre AT valtech POINT fr.

La présentation

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 »