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

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

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

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.

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