Le blog de L'ami S'ami

Note : mon blog est désormais hébergé sur http://www.dng-consulting.com/blogs

--------------
L'initiative OLPC est fantastique. Lionel Laské, auteur DNG et président de cette association m'a demandé de transmettre ce message. Si vous êtes développeur et que l'expérience vous tente, n'hésitez pas à prendre contact avec l'association.

Pour préparer l'arrivée en Europe de l'ordinateur XO, OLPC France lance le concours d'idée: "Un XO pour un projet".


Vous êtes développeur, enseignant, chercheur, professionnel, étudiant ou simplement passionné ?
Vous souhaitez participer au développement Francophone du projet OLPC (One Laptop Per Child) ?
Vous avez une idée pour développer du contenu sur le XO ?

Proposez nous un sujet et vous aurez peut-être la chance unique de recevoir un ordinateur portable XO pour mener à bien et expérimenter votre projet.

Quelques liens pour en savoir plus:

· Le site d’OLPC France : http://olpc-france.org

· Le règlement du concours : http://olpc-france.org/reglement.html

· Le formulaire d’inscription : http://webapps.olpc-france.org/fr/register

· Comment développer pour le XO : http://wiki.laptop.org/go/Developers

· La mailing list OLPC France : olpc-france@lists.laptop.org

Selon cet article, de nombreux changements interviendront dans Firefox 3 concernant la mémoire. De l'avis général, il n'existe aujourd'hui aucun navigateur sans fuite mémoire, notamment lorsqu'il s'agit de manipuler le DOM et les closures (la gestion évènementielle) JavaScript.
GWT a pris ce phénomène à bras le corps en réinventant une sorte de modèle évènementiel au dessus des listeners JavaScript pour garantir l'absence de fuite. Je ne rentrerai pas dans les détails couverts dans cet article mais ce procédé fait encore pencher la balance lorsqu'il s'agit de choisir entre un Framework conçu avec GWT et un Framework UI encapsulant du JavaScript.

A l'avenir, je publierai des billets ici sur blogs@dng mais aussi sur ce nouveau blog hébergé sur dng-consulting.com et s'appuyant sur la toute nouvelle version du moteur de blog b2evolution (exceptionnel). Ce dernier couvrira un spectre de sujets beaucoup plus large que le seul cadre .NET. J'y publierai aussi sûrement plus souvent sans le risque de monopoliser la frontpage à mes camarades.
Voici le billet inaugural -> Repas avec Eric Meijer. Bonne lecture.

Les retours et réactions suite au dernier Symposium ont été nombreux. Certains m’ont également fait part de leurs impressions par mail. J’avais promis de donner quelques explications sur l’aspect logistique et les quelques difficultés de la matinée. Je répondrais ensuite au duo Fabien/BodySplash sur ma session DDD.

Logistique générale et cas particulier de la session DDD

La session DDD est décidément celle qui fait le plus couler de pixels. Pour rappel, cette session que j’animais avait lieu à 11h juste après la session plénière. Très vite en arrivant sur les lieues le matin, nous nous sommes rendus compte avec François Merand côté MS que l’organisation des TechDays avait buggué en attribuant une salle de 120 places. Pour rappel, les 3 derniers Symposium ont eu une affluence variant de 300 à 700 personnes. Il était difficile d’imaginer qu’autant de fidèles aient rendu les armes sous les assauts marketing de la machine TechDays. Lorsque la salle s'est remplit en 3mn après la session plénière nous avons compris qu’une partie importante du public allait devoir être refoulée par l’hôtesse d’accueil. A cet instant, plus d’une trentaine de personnes se tenaient debout ou assis à même le sol pendant que quelques VIP trustaient les premiers rangs.

Bien entendu on pourra toujours arguer qu’il est préférable d’avoir une salle pleine à craquer et refuser du monde plutôt qu’une salle à moitié vide. Pour le pédagogue que je suis, refouler ne serait-ce qu’une personne est quelque chose de difficilement concevable, vous l’entendrez sûrement au ton un peu irrité lors de la publication des webcasts. Après coup, la session DDD a dû refuser entre 60 et 100 personnes. Croyez-moi, j’en suis sincèrement désolé.

Il y aussi ceux qui m’ont fait le reproche d’avoir noyé la marque du Symposium dans celle des TechDays. Il est vrai que la session DDD n’apparaissait pas en tant que session étiquetée Symposium et qu’il a fallu constamment changer de salle tout au long de la journée. On ne peut que le regretter mais s’associer à la logistique des TechDays était aussi l’opportunité de toucher un public plus large que les habituels fidèles. A noter que Microsoft m’a gentiment proposé de rejouer la DDD plus tard dans la semaine. Une proposition que j’ai du décliner faute de vol, en période de grève.

Sur le reste de la journée, l’ensemble des sessions étaient pleines sans avoir jamais eu (à ma connaissance) à fermer de portes.

Concernant enfin les sujets traités lors de la journée, vos retours me confortent dans l’idée qu’ils étaient pertinents. C’est finalement là le plus important. Ce Symposium a aussi permit de faire découvrir de nouvelles têtes, comme celle d’Aurelien avec la session ROA.

Session DDD et billets de Fabien/BodySplash

Pour revenir maintenant à des considérations plus techniques et sûrement moins sensibles que l’organisation du Symposium, j’ai promis de répondre aux critiques constructives formulées par le duo Fabien/BodySplash sur le contenu de la session DDD. C’est un peu long mais le sujet vaut la peine d’être débattu.

Pour avoir lu les billets en question et les avoir publié sur DNG, si j’y réponds c’est que je trouve les remarques argumentées même si le terme « flop » me semble disons, un peu inadapté (pour rester courtois :-)).

La discussion qui suit préfigure d’une certaine manière de l’ambiance générale qui règne autour du sujet DDD et des problématiques (techniques) que cette approche aura à gérer dans les semaines à venir.

Cela fait environ 4 ans que je suis de près l’approche DDD, depuis la sortie du Evans finalement. Je dois dire que la première fois que j’ai lu ce livre, j’ai sursauté au plafond en me disant « jamais je ne conseillerais à quiconque de mettre en œuvre ce genre de choses ». Et de fil en aiguille, quelques années plus tard j’avoue avoir un peu changé d’avis en m’apercevant qu’Evans avait vu juste sur un certain nombre de points. Le domaine deviendrait un élément central d’une application fortement couplée (je ne parle pas de SOA ou d’urbanisation qui se situe à un niveau plus haut) et l’ubiquitous langage, un allié de poids pour la formalisation du besoin MOE/MOA.

Lorsque les temples communautaires (que ce soit Java ou .NET) ont commencé à inviter en 2007 les adeptes du DDD pour parler du sujet, j’ai compris qu’une nouvelle tendance s’amorçait. Il se trouvait que cette communauté partageait aussi un certain nombre de valeurs avec les communautés dites « agiles », le refactoring, le TDD mais aussi le mapping O/R.

Parler DDD au Symposium me paraissait du coup inéluctable tant la communauté Francophone dans ce domaine était inexistante.
De l’avis de tous, les deux seuls ouvrages sur DDD publiés à ce jour en 5 ans sont d’une complexité effroyable même pour un expert du domaine. J’avoue avoir relu 3 fois l’Evans et quasiment autant de fois le Nilsson en .NET. Je n’ai jamais entendu deux personnes évoquer le sujet de la même manière. Et pour cause, le DDD laisse trop de place à la subjectivité. Et je ne parle pas des multiples néologismes créés parfois de toute pièce par Evans pour introduire des termes tels que les agrégats, les repositories, les value object ou les factories. Des notions qui ont bien entendu un sens très précis dans la philosophie DDD mais autant de sens technique utilisé à tord et à travers.

Du coup, soit je traitais le sujet DDD à la mode pure Evans, soit je donnais ma vision du DDD (celle qui me semble la plus pragmatique) pour tenter de convaincre le maximum de personnes qu’il y avait tout de même des choses pertinentes dans le DDD. Charge ensuite à chacun d’y aller en fonction de sa sensibilité ou de s’arrêter en posant ses limites. J’ai préféré la seconde option car elle correspondait mieux à ma vision du DDD.

J’ai passé des années à lutter contre le syndrome du DTO et de ce que j’appelle la mode des entités de services. Cette approche, que je considère aujourd’hui comme « vieille école » consiste à créer des objets métier type Facture, Commandes, Client et à y insérer le maximum de code technique. Lorsque 80% de ce code est de type infrastructure, pour être précis, des accès en base, les problèmes techniques surviennent très vite. Par définition mais aussi il est vrai par conviction, je considère qu’une entité ne doit pas être associée à une quelconque API Technique, ce fût le sujet de ma dernière session Symposium en 2005 et je n’en démordrais pas. Lorsqu'une entité de service ne peut être véhiculée sur la couche de présentation, le développeur la copie généralement dans un ValueObject.

Par ailleurs, nous sommes nombreux dans la communauté à penser que le DDD se trompe en voulant à tout prix s’appuyer sur des Repositories. Le premier à avoir traité ce problème est Christian Bauer, co-créateur d’Hibernate avec son fameux billet : « Repository Pattern vs. Transparent Persistence ». Il explique très concrètement, exemple à l’appui que le domaine doit rester « clean ». I think this pattern is a step backwards and should not be recommended. Keep the domain model implementation clean, testable, and reusable: no security checks, transaction demarcation, or explicit data store access in any of these classes. C’est aussi mon avis. Gavin King son collistier, enfonce le clou dans ce billet (Still Confused about Repositories) : Do we /really/ need another stupid layer in our already horribly over-engineered Java applications?. La réponse donnée par Fabio Kung montre à quel point subsiste cette forme d'hypocrisie dans le DDD qui consiste à ne pas appeler un chat un chat. Il illustre une DAO d’un côté et un Repository de l’autre. Jugez-en par vous-même, seul le nom de la classe change et conclut par « But err… what’s the difference? Just the name? YES! But the names are important, right?”. Les noms sont peut-être importants, mais pas au point de créer une nouvelle couche. Cet exemple montre à lui seul le paradoxe de cette couche du domaine qui s’appuie sur des DAO, pardon des repositories pour récupérer des données mais refuse l'appellation DAO.

Je ne parle même pas des problèmes d’Eager ou Lazy Fetching qu’engendre cette démarche qui se résume souvent par « qui peut le plus peut le moins ». Cette proximité Domaine/DAO empêche de véhiculer une entité de manière sérialisée sur le poste client et ouvre la porte au syndrome du DTO Evil. Les Repository renvoient des collections d’entités ou des agrégats et la combinaison des stratégies de fetching (je récupère un client et ses lignes, un client sans ses lignes, un client et ses factures, etc...) aboutissent inéluctablement à du N+1 Select puisqu'aucun service ne précharge au préalable les données. J'ai cherché très longtemps une sorte de "sample" ou de "PetShop" DDD, la seule application disponible sur domaindrivendesign.org est un convertisseur de monnaie. Pas très "business case".

Le contexte de ma présentation et mes griefs à l’encontre du DDD étant posées, je peux quoter les critiques formulées par Fabien et Body Splash.

Commençons par BodySplash :
« Critiquer une conférence de Sami Jaber est un exercice périlleux ». Quelle idée ! La critique constructive est souvent rare, il ne faut pas s'en priver.

« Du coup, à se concentrer sur la technique, l'ami Sami passe à côté de l'intérêt de DDD, et en plus se mélange les pinceaux dans les concepts. »

Après le contexte que je viens de poser, on comprendra aisément que laisser de côté la technique dans toute architecture ne peut-être que voué à l’échec.

« Il existe en fait 3 types de service définit par Evans: les services d'application (interface, export excel), les services d'infrastructure (envoi de mail) et les services du domaine qui répondent à un métier bien précis (transfert d'argent entre deux comptes par exemple) ».

Cet exemple a été donné par les deux blogs. Effectivement, c’est ce que Evans dit et c’est aussi ce que je regrette. Lorsqu’on souhaite envoyer un mail, il faut être dans la couche d’infrastructure. En revanche, pour faire un export Excel, il faut être dans la couche services d’application. Très honnêtement, comment peut-on imaginer une seconde définir des couches d’architecture avec des exemples aussi légers (le Nilsson reprend d'ailleurs exactement les mêmes exemples). Comment fait-on lorsqu’on souhaite envoyer un mail contenant un export Excel ?

Une couche ne se définit par seulement par des cas fonctionnels, mais aussi par des dépendances binaires, une architecture physique et logique, un couplage par interface. L’export Excel est-il côté client ou côté domaine ? Est-il transactionnel ? Il existe des dizaines de cas où cette approche atteint ces limites. Je revendique donc l’explication donnée pour la couche de service vu sa totale subjectivité.

« Si on en croit Sami Jaber, tout ce qui est sous une racine d'agrégat est une value object. Faux. »
Les webcast seront publiées en Mars de mémoire, il m’est difficile de répondre à des choses que je n’ai pas dites. Le slide 15 montre les objets Customer et Order comme des entités avec une identité (la composition, donc les VO concernent les objets de l’agrégat)

« Une autre confusion est de comparer les repositories aux DAL ». Je pense avoir suffisamment démontré qu’à part le nom de la classe, on peut qualifier le Repository d’entrepôt, ça n’en fait pas autre chose qu’une DAO.

« Dans une deuxième moitié de session, Sami Jaber a présenté une manière intéressante de tenter d'automatiser le binding entre les objets du modèle et la couche présentation. L'idée est de placer des attributs par exemple sur nos setter des objets du modèle, et on peut imaginer un framework de présentation capable de lire par réflexion ces attributs pour automatiquement générer les validateurs qui vont bien ».
Pourquoi systématiquement recopier côté IHM ce qui existe déjà côté Entité. Bindons nos entités, c’est peut-être anti-DDD Evans like, mais largement plus pragmatique que faire de la réflection et du DTO à tout va.

« il n'existe pas de simple application CRUD ».
Peut-être pas « simples », mais pas si complexes, sûrement. Une application peut avoir du métier sans que cela justifie d’empiler des couches à tord et à travers. On en a assez souffert ces cinq dernières années.

Pour finir et faire écho à Fabien :
« Au delà de ce que Sami a dit, c'est surtout ce qu'il n'a pas dit qui me gêne. Je sens bien qu'il n'adhère pas du tout à DDD ».
Fabien, j’adhère sincèrement au fondements pragmatiques du DDD et la place centrale que le domaine doit jouer dans les applications de demain. Mais je rejette les délires d’architectes en mal de couches qui ont plombé tant de projets ces dernières années. Dans la même lignée que Gavin King et Christian Bauer qui l’expliquent d’ailleurs très bien.

« Ce langage n'est pas, comme il le dit, un jargon spécifique du projet ».
Même remarque que précédemment cf Page 11 de mon slideshare, il est bien précisé que c'est un langage technique entre MOA/MOE.

« Les entités du modèle ne sont pas forcément exposées aussi brutalement à une couche de présentation; la mise en place d'un couche applicative est parfois indispensable, ce qui, dans une approche du "tout bindé" est infaisable ».
Lorsqu’une entité répond à un besoin de présentation, on l’utilise. Lorsqu’une entité ne répond pas au visuel d’une IHM, on utilise un Value Object contrairement à une démarche systématique qui consiste à cloner à tout va des grappes d’objets. Sur une application de gestion « traditionnelle », plus de 80% des écrans peuvent bindés sur des entités. Sans sacrifier le Design, le gain en termes de productivité est énorme. Lorsqu'on essaie de forcer le DDD dans sa forme la plus extrème contre les réalités projets, on arrive aux échecs que tu cites toi même dans ce billet.

Pour finir le débat, Fabien et BodySplash, je comprends votre déception par rapport au fait que je n’ai pas soutenu DDD sans réserve dans cette session. Mais "ne pas soutenir" ne signifie pas "ne pas comprendre" ou "sortir des énormités". Avec cette réponse, j’imagine que le contexte est plus clair. Si ce n’est pas le cas, je vous invite tous les deux, à rédiger un article que je publierais avec grand plaisir sur DNG pour continuer le débat. Steve Degosserie, qui a assisté à la session m’a proposé de traiter le sujet de manière plus poussée dans un futur article. N’hésitez pas à en faire de même.

Sami

Bonjour à tous et bonne année 2008 avec beaucoup de retard. J'en profite aussi pour remercier ceux qui m'ont gentiment envoyé un mail ou passé un coup de fil.

L'année 2008 s'annonce très riche, pour DNG.org mais aussi pour DNG-Consulting, lequel a tendance à prendre en ce moment beaucoup de place sur les quelques slots réservés à mon activité de webmaster DNG.

Mais promis, parmi mes nouvelles résolutions, celle de blogguer plus, continuer à publier sur DNG ou ailleurs (j'en profite pour vous informer qu'un article sur le DDD sortira dans un prochain hors série du magazine Programmez), celle ne de pas vous faire regretter le prochain Symposium DNG (très prenant). Et celle enfin d'organiser un séminaire technique très particulier qui me tient à coeur et dont je livrerai quelques détails courant Février.

2008 sera une année très spéciale pour moi car c'est d'une certaine manière un retour aux sources. Contrairement aux années précédentes (très "évangélisantes"), mon activité sera focalisée à 80% sur du développement et la mise en pratique des nombreuses idées/bonnes pratiques formalisées plus ou moins dans ma tête depuis des années. Que ce soit sur la partie serveur (EJB3, SOA, WCF) ou cliente (GWT, Volta, Swing, etc..), je ferais partager tout au long de l'année ces bonnes pratiques, à commencer par le Symposium DNG qui sera un avant-goût de la conférence suivante.

Sinon, pour ne pas donner à ce billet un parfum d'auto-actualité pseudo nombriliste, je voulais rebondir sur la dernière annonce de Microsoft (relayée par Scott Guthrie) dévoilant très officiellement les manipulations à suivre pour profiter du code source du Framework .NET.

Ces manipulations marchent parfaitement sur mon poste, j'ai enfin pu lire le code source de la classe Control.cs du namespace System.Windows.Forms sans avoir l'impression de violer une quelconque licence (cf Reflector). En revanche, je trouve que cette ouverture n'est pas encore suffisante ou plutôt trop contraignante. Pour bénéficier de cet accès, le poste de développement doit :
- Posséder une connexion Internet ouverte en permanence
- être en session de Debug avec la pile d'exécution affichée dans une console sur la classe du Framework qu'on souhaite visualiser
- Télécharger un "patch" particulier pour VS.NET

Il faut avouer que pour quelqu'un qui cherche à comprendre du code source en passant d'une classe à l'autre, on fait plus simple. D'autant plus que la même opération sous Eclipse se résume à un "Attach Source Code" sur une archive (l'équivalent d'une DLL .NET) suivi d'un simple control+click ouvrant automatiquement le code source sur la méthode ou classe en question.

Du coup, j'ai essayé d'analyser la manière dont Visual Studio s'y prenait pour récupérer ce code source. Le tout en plaçant un proxy entre VS.NET 2008 et le "Web" dans une session Fiddler.

Les résultats de l'analyse Fiddler sont plutôt étonnants, ils nous indiquent que le serveur de source est ReferenceSource.microsoft.com et que les sources sont placés hiérarchiquement suivant une convention de nommage plutôt complexe. Autant dire qu'on est loin d'un serveur SVN, CVS ou TFS (Team Foundation Server). Autre aspect plutôt déroutant, lorsqu'on accède via un navigateur à ce repository, toute requête se solde par un status code 400, une page blanche en quelque sorte.

Microsoft a donc protégé ces sources pour que seul Visual Studio puisse y accéder avec une clé privée particulière (placée dans le cookie RSCCAuth). Lorsqu'on essaye la première fois de télécharger un fichier, une page dédiée à la licence s'affiche. Après acceptation, un cookie est généré et servira de clé d'accès.
Autant dire que pour une ouverture annoncée en fanfare, on aurait pu s'attendre à quelque chose de plus "Ouvert" justement ;-).

Bref, tout cela m'a donné une idée (et oui encore!). Reflector s'est fait une réputation mondiale sur la décompilation de code source. On pourrait imaginer un plugin VS.NET qui, sur l'appui de la touche F3 (Go To Definition) irait récupérer la clé Visual Studio générée par défaut pour ensuite enclencher un GET HTTP sur le serveur ReferenceSource. Ce plugin (pas très complexe à développer) serait une aubaine absolue pour nombre de développeurs et s'appuierait surtout sur la base d'origine de Microsoft.

D'ailleurs, peut-être que Microsoft lui même pourrait nous le fournir ?

A bon entendeur...

Mise à jour: bon j'avoue ne pas avoir pu résister à l'envie de proof of concepter l'AddIn en question. Ca marche plutôt bien et à priori sans exécuter les opérations listées sur le site de ScottGu.
Lancez le setupNetExplorer.msi, une entrée de menu apparaît dans Tools, une fois activé l'Add-In télécharge la classe Control.cs sur le site de Microsoft avec un cookie d'authentification qui semble fonctionner dans tous les cas. Voici le code source pour ceux qui souhaiteraient industrialiser le prototype, il n'y a plus qu'à enrichir la base de données des codes sources téléchargeables et cabler l'appui sur la touche F3. Avec le disclaimer d'usage sur les responsabilités de l'auteur hein ;-)

Je quote une question que m'a posé Lionel et à laquelle j'ai répondu en privé mais vu qu'on me la reposé plusieurs fois je me suis dis qu'elle avait peut-être mieux sa place sur ce blog.

(...)
Salut Sami,

Info ou Intox : tout ça me parait assez obscur : http://www.ddj.com/blog/javablog/archives/2007/11/google_android.html

ça te parlera surement plus à toi ?
(...)

L'annonce d'Android est effectivement "obscure" pour bons nombres d'entre nous. En dévoilant ce SDK destiné au développement d'applications Java sur le terminal mobile de Google, l'éditeur a brouillé pas mal de cartes. Android SDK est plus qu'un ensemble d'API. C'est un environnement de développement et d'exécution.
Un environnement de développement constitué d'un sous ensemble de J2SE et d'API natives liées à la plateforme d'exécution de l'Android, un Linux 2.6 intégrant un scheduler, un gestionnaire de mémoire, un gestionnaire réseau (3G/Wifi/Bluetooth...), etc. Ce Framework applicatif a été conçu de telle sorte que le hardware n'est jamais directement couplé aux API d'Android et du SDK Java.

Si la nouvelle plateforme mobile de Google s'arrêtait là, tout cela serait somme toute banale. La particularité d'Android SDK tient en effet dans l'environnement d'exécution, plus communément appelé Dalvik. Contrairement à ce que j'ai pu lire ici ou là, Dalvik n'est pas une JVM dans le vrai sens du terme. En effet, Google réalise du post-processing du Byte-code Java "standard" pour le transformer dans un byte-code optimisé (le .dex) qui sera ensuite interprété par une JVM spécialisée sans phase de JIT. L'optimisation est liée au fait que le byte-code en question s'appuie sur les registres là ou la JVM ou la CLR de Microsoft s'appuient sur la pile (et les variables locales). Les registres sont bien plus rapides que la pile mais moins souples. Google a aussi optimisé les appels natifs et au vu de l'hétérogénéité de la plateforme, ce gain sera plus qu'apréciable au moment d'interroger les drivers bluetooth ou Wifi.

Bref, Dalvik est un vrai pied de nez à J2ME (qui n'a jamais réellement percé chez les puristes du mobile) et prouve qu'on peut enrichir Java tout en y ajoutant des extensions propriétaires.
Il y a quelques années, je me rappelle qu'un certain Microsoft avait tenté le même genre de holdup en générant du byte-code MSIL (compatible avec la CLR de Microsoft). Ce langage s'appelait J++ ou J# et reprenait la syntaxe du J2SE avec quelques API propriétaires (notamment les MFC). Quand on connait la suite des évènements et les lourdes amendes que Microsoft a dû payer, on comprendra très mal que Google s'en sorte sans une égratignure. Le marché du Mobile est un marché hautement stratégique, un accord commercial n'est pas exclu entre les deux firmes même si j'ai du mal à cerner là où Sun pourrait trouver son bénéfice ...

Une affaire à suivre donc.

PS : A lire. Timepedia prouve avec ce prototype que GWT sait aussi générer du Java compatible Android.

Je viens de publier quelques pointeurs sur des articles d'une valeur inestimable pour tout développeur .NET. Le sujet de la sérialisation et du transfert de contrats de données avec WCF lorsqu'on utilise des Entités sera au coeur des problématiques WCF dans les années à venir. Je voulais couvrir ce sujet plus en profondeur sur DNG mais OakLeaf m'a devancé (et je les remercie d'une certaine manière car ils viennent de me faire gagner un heure ou deux de rédaction ;-)).

Ce qu'il faut retenir, ce sont les différents modes de DCS proposés par WCF. Pour simuler un couplage fort entre un client/serveur .NET (mode shared type), le NDCS est un passage obligé. Pour le reste, il vaut mieux éviter de transférer des entités et préférer des messages de type DTO.

Entre .NET Remoting et WCF, je trouve que MS est passé d'un extrême à l'autre...

Quand je pense aux heures passées parfois à deviner quand et comment un composant Swing est dessiné ou redessiné à l'écran (évènement paint() ou paintComponent()). Voici un petit deboggueur visuel qui devrait être remboursé par la sécurité sociale. Même à titre d'information, c'est toujours rigolo de savoir quel partie d'un écran est redessiné lorsqu'on évolue dans une application. A quand la même chose en WinForms ?
-> Debug Swing repainting

De retour de Barcelone et d'une semaine bien chargée j'en profite pour faire un retour synthétique de TechEd 2007 et les projets se qui se trament à l’horizon.

Autant le dire tout de suite, TechEd 2007 ne restera pas dans les annales. Il suffisait de jeter un œil sur le casting de l’évènement pour s’apercevoir qu’aucun des grands noms (sans faire offenses aux remplaçants) n’avaient fait le déplacement. Ajouter à cela une actualité plutôt creuse et un contenu parfois réchauffé et on comprend pourquoi les quelques journalistes présents à l’évènement affichaient une mine pâlotte au moment de rédiger. Est-ce à dire qu’il n’y a vraiment rien eu à se mettre sous la dent durant toute la semaine ? Bien entendu que Non. TechEd 2007 a tout de même recélé quelques pépites, j’entends par « pépite » une technologie qui a le vent en poupe et dont les sessions étaient pleines à craquer.

La première fût incontestablement « Entity Framework » ou le mapping objet/relationnel à la sauce Microsoft. Pour avoir suivi la plupart des sessions sur écran assis par terre dans le couloir au milieu d’une cinquantaine de « refoulés », le sujet était au cœur de toutes les discussions. Avec des speakers de la dimension de Luca Bolognese (ancien d’ObjectSpaces), Pablo Castro, Carl Perry ou Mike Taulty, la maison restait bien gardée. Sur le fond, j’avoue ne pas être un fan de cette API depuis ces débuts. EF s’appuie sur la notion de classes partielles pour gérer toute la tuyauterie de persistance là où Hibernate génère des proxies dynamiques à la volée (JDO a disparu pour cette raison). Une classe du domaine EF ressemble à tout sauf à une classe du domaine. On hérite d’une classe sorti tout droit d’un film de science fiction : System.Data.Objects.DataClasses.Entity (mais qui a bien pu trouver des noms de namespaces aussi pourris ?). On y référence allègrement des EntityRef (évidemment, lorsqu’on n’a pas de proxy dynamique, on expose forcément à l’utilisateur la complexité du Framework interne) et différentes relations techniques. Autant dire que pour l’instant EF ressemble plus à la petite sœur ratée de JDO qu’à un outil de mapping o/r de la dimension de Toplink ou Hibernate. A suivre cependant, tout cela n’est qu’en béta.

Côté stars, Linq a encore cette année tenu le haut du pavé. On ne le répètera jamais assez. Microsoft possède en Linq une avancée technologique considérable par rapport à la concurrence. Les concepts qui sous-tendent Linq sont puissants, élégants et pratiques.
Et pourtant, il y a comme un malaise à l’heure actuelle autour de Linq. Un malaise lié au positionnement marketing de Linq, qui, sans implémentation n’est finalement qu’une sorte de coquille vide. Or, des implémentations, il y en existe une bonne dizaine. A tel point qu’une session entière intitulée « Linq to X, what to choose ? » fût dédiée au sujet. Pour y avoir assisté, le moins qu’on puisse dire c’est que Microsoft ne sait justement pas où il nous emmène (petit clin d’oeil à « where do you whant to go today ? »). Linq sera utilisé dans 90% des cas dans sa version mapping o/r. Que choisir entre Linq to SQL (incomplet), Linq to DataSet (anti n-tiers) ou Linq to EntityFramework (en béta) ? Les réponses sont restées vagues et je prends le pari que dans un an, toutes ces API auront disparu au profit du seul et de l’unique Entity Framework, aujourd’hui encore dans les cartons. Et dire que Linq est censé sortir en release à la fin du mois. Allez comprendre Charles.

Autre star, Astoria. Les sessions étaient garnies, les speakers excellents et nul doute que ce sera un des sujets chauds en 2008. J’aimerai y consacrer une session au Symposium DNG (message subliminal, le contenu des sessions est arrêté, je vais bientôt lancer les appels à candidature sur DNG).

Pour le reste, excepté Silverlight qui est la grande tendance du moment, on aurait quasiment pu faire un copier/coller des sessions WPF et WCF de l’année dernière.

Pourtant, dans cette actualité qui semble plutôt calme, une technologie va petit à petit commencer à faire parler d’elle. J’avoue qu’Olivier m’a un peu coupé l’herbe sous le pied en blogguant sur le sujet cette semaine ;-).

S'il planait comme un air de Volta pendant ces quelques jours autour du TechEd, il n'y a eu aucune session, pas un mot, aucun whitepaper. Et pourtant, Volta est la révolution silencieuse qui se trame dans les coulisses de Microsoft et qui préfigure du Web de demain. Imaginez développer vos applications en .NET (C#, VB, etc…) et générer du Silverlight, du WPF ou du HML/JavaScript lors du déploiement. Le concept de client Web universel (« write once, run every where ») avec comme environnement d’exécution, la machine virtuelle JavaScript du navigateur. Google l’a inventé avec GWT, Microsoft y croit tout autant, sinon plus. La bataille ne fait que commencer. Si Volta est effectivement aujourd’hui un projet de recherche, le produit existe. Est-il plus performant que GWT, s’appuie t-il sur Script#, comme on peut le présupposer ? Dispose t-il des mêmes optimisations compilateur ? Autant de questions auxquelles il m’est aujourd’hui difficile de répondre. Et on comprendra aisément que Microsoft souhaite garder l’implémentation de référence confidentielle tant le sujet est sensible et stratégique (moi, des infos ? mais non ;-)).

Si vous hésitez encore à vous inscrire au Symposium DNG 2008, sachez que nous mettons tout en œuvre avec François Merand pour inviter le papa de Volta, Eric Meijer (co-inventeur de Linq, rien que ça) au Symposium. D’ici là, tout le secret qui entoure ce projet se sera surement estompé et nous aurons droit à une démo très officielle de Volta.

Pour finir, et je ne le répèterai jamais assez : si vous êtes développeur .NET ou Java, n’hésitez pas allez voir ce qui se fait de l’autre côté. Cassez les barrières, on ne peut que s’enrichir de la multiculture technologique. La mise en perspective des deux environnements est une occasion fantastique de pointer du doigt les failles de telle ou telle API. En travaillant GWT il y a plus d’un an, j’étais convaincu par le concept. Avec la sortie de Volta, il ne me restera finalement plus qu’à combler les 10% de différences qui feront l'originalité ou la banalité du produit …

Il y a des fois, on se demande ce qui passe par la tête de certains chez Microsoft Corp. L'éditeur vient de se rendre compte que la mondialement distribuée béta 2 d'Orcas (sous sa forme VPC) expire le 1er Novembre prochain, soit dans 4 jours. Pour rappel, cette VPC implique un téléchargement de presque 10 Go de données. J'imagine ceux (comme Roy) qui ont mis des heures (comme moi) voire des jours à récupérer Orcas et qui s'apprêtent le 5 Novembre prochain à faire une démo à TechEd Barcelone avec une TFS ou des samples déjà configurés. Le pire dans cette histoire, c'est qu'ils devront une seconde fois télécharger 10Go pour simplement modifier une date de 8 Octets. On marche sur la tête, je vous le dis :-)

J'anime une formation sur .NET la semaine prochaine et sans cette annonce sur le blog de Jeff Beehler, ma VPC Orcas aurait peut-être flanché en plein milieu. Prenez vos précautions...

Contrairement à Miguel, j'avoue être un peu plus sceptique sur le futur de Mono dans un contexte où Microsoft ouvre ses sources. Ce qu'un développeur recherche en s'associant à un projet de ce type c'est l'excitation intellectuelle que procure la concurrence avec une société comme Microsoft. Refaire .NET en mieux et un peu en "aveugle" est un forcément un challenge.

Désormais, tout le monde aura accès aux sources (même si je ne doute pas que c'était déjà le cas avec Reflector) et les développeurs de Mono pourront à loisirs se pencher sur le code des prochaines API avant même d'y avoir réfléchit. Et cette première lecture va indéniablement influencer la manière dont ils coderont Linq ou WCF (le couple WPF/Silverlight est un peu particulier, car c'est une technologie desktop avec des spécificités plateformes).

Quoi qu'il en soit, tant que .NET n'adopte pas une licence GPL ou équivalente, la légitimité de Mono reste intacte. Mais pour combien de temps ...

C'est le feuilleton de la semaine. Toute la place Californienne en parlait depuis plus d'un an, BEA était à vendre et force est de constater que les repreneurs ne se pressaient pas au portillon.

En proposant 6,7 Milliard de $, Oracle lance les hostilités et se paye ainsi la disparition funèbre d'un de ses concurrents les plus sérieux.

Je me souviens avoir fait mes premières armes sur WebLogic Server, à l'époque (en 2000), BEA fournissant un des serveurs d'application les plus robustes du marché. WLS séduisait par la qualité de ses consoles graphiques et la richesse de son noyau. C'était l'époque Cédric Beust, WebGain, Visual Café, BEA Workshop ou Weblogic Integration.

Depuis, BEA n'a jamais réellement réussit à diversifier son business model. Resté un pure player du monde des serveurs d'application, la firme a toujours couru après cette crédibilité BPM qui lui faisait tant défaut. En basant son modèle économique sur le seul revenu de ses licences WLS ou Aqualogic, BEA s'est isolé un peu plus. Dans un marché où le serveur d'application devient une "commodity" et les Open Source de vrais concurrents, l'avenir tendait inexorablement à s'assombrir.

Malgré tout, BEA a toujours cherché à rester en pointe, WLS 10 fût par exemple de mémoire le premier serveur d'application certifié J2EE 1.5 (on attend toujours JBoss au passage) et son implémentation a encore gagné en qualité ces derniers mois. Signe que la société possède des développeurs de talents.

Dans ce contexte, si ce rachat se confirme (et on en est loin vu les derniers développements) cela signerait la fin de BEA. Un serveur d'application de moins n'est jamais une bonne nouvelle même si l'offre SOA est pléthore sur le marché.
Oracle possède à tous les niveaux l'équivalent (souvent en moins bien d'ailleurs) et on voit mal l'éditeur fusionner ex-Collaxa et Aqualogic. Une restructuration technique de son offre serait encore plus couteuse qu'un coulage en bonne et due forme.

Souhaitons qu'il n'en soit rien...

J'essaierai régulièrement de publier quelques articles (travaillés) dans la rubrique technologies de DNG Consulting. Voici le premier, qui traite (un peu) de DDD et (beaucoup) d'atelier Clean RAD en Java.
C'est ici -> http://www.dng-consulting.com/technologies.html

Plus d'un mois après mon dernier billet, je reprends la plume électronique pour vous donner quelques nouvelles sur la communauté DNG et les projets qui s'annoncent à l'horizon pour le site.

Mais avant, un petit détour sur un changement de situation personnelle. Après de très belles années en tant que Directeur technique, je ne suis très officiellement plus en poste chez Valtech. Mon adresse mail sami.jaber@valtech.fr répondra désormais aux abonnés absents.
Rassurez-vous, je n'arrête pas l'informatique, il me reste encore quelques neurones récalcitrants ici ou là. La suite s'inscrira toujours en lettres électroniques avec la même envie de vous faire partager cet univers fabuleux des nouvelles technos sous l'angle de l'architecture logicielle.

C'est dans cet esprit que j'ai donc créé la société DNG Consulting. L'idée est de me concentrer un peu plus sur des activités et des projets qui me tiennent à coeur tout en assurant (surement mieux) mon rôle au sein de la communauté DNG. Si vous souhaitez en savoir plus, n'hésitez pas à parcourir le site http://www.dng-consulting.com.

DNGC (décidément, encore un nouvel acronyme ;-)) apportera un support logistique et une meilleure exploitation de l'image DNG mais aussi du côté "multi-technologies" qui manque aujourd'hui à l'image DNG. J'ouvrirai bientôt un espace techno dédié aux plateformes .NET mais aussi Java (au passage, cela explique pourquoi DNGC signifie plutôt "Design New Guides" que DotNetGuru) en traitant de sujets multi-culturels (et qui n'ont pas attrait forcément qu'au développement). DNGC distribuera les quelques formations sur lesquelles je planche et qui manque cruellement au catalogue de bon nombre d'entreprises du marché (GWT, DDD, Struts 2, ...).

Ma nouvelle adresse professionnelle est donc sami.jaber@dng-consulting.com et de manière plus informelle : sami.jaber@gmail.com. Notez que pour éviter d'être juge et parti, il n'y aura aucune publicité, prosélytisme ou marketing que ce soit au profit de DNGC sur DotNetGuru.org. Restriction qui ne concerne bien évidemment pas les autres annonceurs, qui font d'une certaine manière vivre le site.

Pour revenir à DNG, je souhaitais répondre aux nombreuses questions concernant le Symposium, l'avenir du site et les blogs.

Symposium DNG
Le Symposium DNG se déroulera du 11 au 13 Février 2008 et sera hébergé par l'enseigne des TechDays 2008. Nous bénéficierons d'une grande salle permettant d'accueillir un nombre important de participants et Microsoft, plus que jamais, assurera le sponsoring de l'évènement par l'intermédiaire de François Merand (que je remercie au passage). Après la venue de Bill Gates lors de la dernière édition, il n'est pas impossible que nous sollicitions un invité de marque cette année encore. Peu après les TechEd à Barcelone en Novembre (DNG couvrira l'évènement sur place), je lancerai les appels à candidature pour tracer une ligne éditoriale, définir le contenu et les speakers du Symposium DNG 2008. Vous êtes nombreux à m'avoir déjà sollicité, il n'y aura évidemment pas de place pour tout le monde mais je suis sûr que vous comprendrez la difficulté de l'arbitrage.

Les Blogs
Le site actuel des blogs DNG reçoit de plus en plus de visites, l'infrastructure actuelle a besoin d'être améliorée d'un point de vue ergonomique mais aussi pour lutter contre les SPAM, qui empoisonnent la vie de tout webmaster. Nous évaluons donc avec Sébastien une migration vers la toute dernière version de b2 avec en prime un relooking complet. Un nouveau domaine a donc vu le jour, plus explicite que dotnetguru2.org, hébergé à l'adresse http://www.dngblogs.org. Le nouveau et l'ancien site pointeront vers le même à une date qui sera déterminée par le résultats des tests que nous menons actuellement. N'hésitez pas à nous faire part de votre feedback en sachant que le serveur dngblogs est une machine de test, forcément moins robuste que le site de production.

SPAM et inscriptions des membres
Régulièrement, certains utilisateurs s'enregistrent en tant que membre DNG pour pouvoir participer aux forums et poster des commentaires. Sachez que j'ai dû mettre en place une protection manuelle car certains Robots (parfois je me dis qu'il y forcément des humains derrière toute cette intelligence) arrivaient à déchiffrer le CAPTCHA mis en place pour créer des utilisateurs fictifs propriétaires de comptes mails réels empruntés à des PC zombies. Du coup, toute inscription passe aujourd'hui par une étape de vérification manuelle (pouvant prendre 48h selon la disponibilité du modérateur) avec pendant ce temps, aucun droit de consultation/modification sur le profil en question. J'avoue que je me serais bien passé de ces minutes perdues, mais c'est le prix à payer pour disposer d'un site "safe" de SPAM et d'une base de membres propre.

Rentrée technologique
Cette rentrée, comme les rentrées précédentes sera palpitante d'un point de vue techno. Côté .NET, l'ère SOA avec les couples WCF+WPF/Silverlight+EntityFramework/Linq s'annonce passionnante. De nombreux patterns devront apparaitre pour faire discuter tout ce petit monde. Quid du modeling, de la distribution de services web et du passage d'entités entre couches. Quid du couple RAD+SOA (la clé du succès), etc..
Côté Java, nous sommes aussi dans une phase de transition. Excepté l'ovni GWT/AJAX que personne n'avait réellement prévu, EJB 3 commence à percer avec un mapping O/R définitivement installé, jusque dans les specs du JCP aidé par la percée des communautés Open Source. En revanche, la partie desktop reste en pleine mutation avec Sun qui cherche à améliorer le côté RAD de Swing (SwingLabs, Swing Framework, JSR 295) tout en proposant un concurrent de WPF en la personne de JavaFX.

Bref, le nombre de technologies côté .NET et J2EE ne cessent de progresser avec des éditeurs qui se crêpent le chignon à coup d'API et de nouveaux Framework. Et tout cela sans que n'apparaissent réellement les bonnes pratiques d'architecture et de conception qui feront les bons projets de demain. Du coup, il y a encore un peu de quoi continuer sur DNG. J'espère vous faire partager ces prochains grands moments technologiques sur les plateformes DNG, DNGBlogs.org et DNGC.

Merci de votre fidélité...

Update 10/03 : Merci encore à tous, qui par mail ou via les commentaires m'ont apporté leurs encouragements. Et promis, je n'adhèrerai pas au médef pour ceux qui s'en sont inquiété :-D

Lors des rencontres GWT, j’ai montré un exemple d’intégration EJB 3 GWT basé sur le nouveau design RPC de la version 1.4. Dans les jours qui ont suivi, j’ai reçu énormément de mails me demandant le code source de cette démo.

Il y a très peu, voire quasiment pas (à ma connaissance) d’information publiée sur le Web à ce sujet. Alors que Spring est présenté comme modèle d’intégration RPC, il faut avouer que EJB 3 souffre d’un manque de reconnaissance du Framework GWT. Et pour cause, EJB 3 ce sont les annotations, les génériques, le JDK 5 et toutes les fonctionnalités non (encore) supportées par le compilateur GWT.

Du coup, j’ai essayé de prendre le meilleur des deux mondes en proposant un mariage qui soit le plus doux possible et surtout le plus pérenne en attendant les prochaines évolutions du Framework.

Dans son nouveau mode d’extensibilité, RPC propose de tirer partie de la reflection et de l’invocation dynamique de méthode. GWT passe en paramètre la méthode et les paramètres invoqués par le client à une servlet chargée de déléguer l’appel à un conteneur EJB. Seule contrainte, la cible de l’invocation doit être un objet dérivant de l’interface cliente (de type RemoteService). J’ai donc dû adapter un peu le principe, lorsque la servlet reçoit l’invocation cliente elle extrait la signature de la méthode et la compare de manière symétrique aux méthodes contenues dans un proxy EJB récupéré préalablement via un lookup JNDI. Je me sers du nom logique paramétré dans le fichier de module comme binding JNDI (ce nom doit correspondre au nom de l’EJB ). Voici le code, je laisse les puristes comprendre précisément pourquoi il m’a fallu écrire la méthode methodEquals() plutôt qu’effectuer l’invocation directement grâce à rpcRequest.getMethod().

package com.myapplication.server;

import java.lang.reflect.Method;
import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.servlet.http.HttpServletRequest;

import com.google.gwt.user.client.rpc.InvocationException;
import com.google.gwt.user.client.rpc.SerializationException;
import com.google.gwt.user.server.rpc.RPC;
import com.google.gwt.user.server.rpc.RPCRequest;
import com.google.gwt.user.server.rpc.RemoteServiceServlet;

public class EJB3ProxyServlet extends RemoteServiceServlet {

public boolean equalsMethod(Method m1, Method m2) {
        // test the method name
        if (!m1.getName().equals(m2.getName())) {
                            return false;
        }

	if (!m1.getReturnType().equals(m2.getReturnType()))
		return false;

	Class[] params1 = m1.getParameterTypes();
	Class[] params2 = m2.getParameterTypes();
	if (params1.length == params2.length) {
		for (int i = 0; i < params1.length; i++) {
			if (params1[i] != params2[i])
				return false;
		}
		return true;
	}
	return false;
}

public String processCall(String payload) throws SerializationException {
	try {
	Object obj = null;
	InitialContext ctx;
	RPCRequest rpcRequest = null;
	try {

	 Hashtable env = new Hashtable();
	 env.put(Context.INITIAL_CONTEXT_FACTORY,
	      "org.jnp.interfaces.NamingContextFactory");
	 env.put(Context.PROVIDER_URL, "localhost");
	 env.put(Context.URL_PKG_PREFIXES,
		"org.jboss.naming:org.jnp.interfaces");
 	 ctx = new InitialContext(env);
	 // Récupère le nom de l'EJB à partir de l'URL du service RPC
	 String[] path = 
                        getThreadLocalRequest().getServletPath() 
				.split("/");
        // Il préférable de faire des appels locaux EJB en mode GWT RPC
	obj = ctx.lookup("EAR Name" + path[path.length - 1]
				+ "/local");
	HttpServletRequest mod = this.getThreadLocalRequest();
	rpcRequest = RPC.decodeRequest(payload, obj.getClass());
		
        // Cherche la méthode en question dans le proxy EJB  
	for (Method m : obj.getClass().getMethods()) {
		  if (equalsMethod(rpcRequest.getMethod(), m)) {
		    // > GWT 1.4
                    return RPC.invokeAndEncodeResponse(obj, m, rpcRequest
					.getParameters(), rpcRequest.getSerializationPolicy());
                    // < GWT 1.4
                    return RPC.invokeAndEncodeResponse(obj, m, rpcRequest
					.getParameters());
	   	  }
	}
   } catch (NamingException e) {
		// Gestion d'erreur minimaliste				
   }

   throw new InvocationException("Method not found");

} catch (InvocationException ex) {
	return RPC.encodeResponseForFailure(null, ex);
}

}

Ce proxy permettra de ne plus avoir à coder systématiquement les délégations et vous fera économiser parfois plusieurs milliers de lignes. Il suffit de spécifier dans le fichier module.xml la servlet EJB3ProxyServlet de la manière suivante :

<servlet path="/MySessionBean" 
      class="com.myapplication.server.EJB3ProxyServlet"/>

Le code client lui, ne bouge pas, par rapport à un service RPC classique.

Vous n’avez plus aucune raison de ne pas utiliser les EJB 3 avec GWT…

MAJ : le code à été modifié pour prendre en compte les remarques de Joan.