Guillaume Saint Etienne 's Blog

enfin, on sort des ténèbres... après presque 10 ans de règne sans partager sur l'accès aux données depuis la création du Framework .Net, les DataSets rendent les armes.

C'est une vision personnelle, mais je ne peux me rappeler que mes soirées de debuggage intenses avec les DataSet... absence de typage, requêtes SQL construites sur des concaténations de chaînes de caractère... en tout cas au début, on était obligé de commencer comme ca.

Même s'ils ont mûri, les DataSets sont synonymes de lignes et lignes de codes de plomberie techniques, lourdes, fastidieuses, inutiles... et à mon sens une vision tordue de l'accès aux données.
Tout cela m'avait vite poussé à regarder NHibernate et ses confrères. Vive le Mapping Objet Relationnel!

Pour moi Linq et surtout Ado.Net Entity Framework allait enterrer définitivement les odieux DataSets... il n'en a rien été.

Et cette nouvelle m'apparaît comme une sortie du tunnel: "here are no plans to add DataSet into future releases of Silverlight"
Un signe? Un espoir?
Une promesse d'une aube nouvelle????

Si une technologie qui a le vent en poupe ne soutient plus cet ancêtre, peut être est-ce l'annonce du début de la fin?
Allez, il faut croire au progrès.

http://blogs.msdn.com/adonet/archive/2009/05/26/dataset-and-silverlight.aspx
http://www.sheysrebellion.net/blog/2008/07/31/datasets-are-evil/
http://jelle.druyts.net/PermaLink.aspx?guid=61676665-06a7-443a-9462-71dae713539e (DataSets Are Not Evil)

http://www.slideshare.net/mcottmeyer/adopting-agile-1521562

exactement le genre de présentation que je fais
rapide, concis, une idée par slide, des idées claires & simples
des diapositives compréhensibles par tous et d'elles-même!

a MUST HAVE and a MUST FOLLOW

Pour changer de .Net, un petit billet d'humeur sur... le travail.

Voila donc cette grande journée de grève avec une paralysie quasi-totale annoncée.
Et qu'est ce que je remarque ce matin au boulot: 2 fois moins de mes collègues sont venus travailler, les autres sont restés travailler chez eux.
C'est un des avantages à bosser dans les domaines de l'IT ou du service. Nous n'avons pas *vraiment* besoin de nous déplacer sur notre lieux de travail tous les jours, dans l'absolu.

Résultat de cette journée: l'ambiance était particulièrement décontractée voire joviale. Travaillant dans un OpenSpace, voila que -tout d'un coup- une quiétude et un calme nécessaire à la concentration régnaient autour de nous. Le travail allait en être plus efficace.

Les gens étant restés, pour bon nombre, chez eux, la circulation fut plus fluide que d'habitude (source Europe 1) et la qualité de l'air était bonne ( http://www.airparif.asso.fr ).
L'analyse de la courbe de cumul de bouchon en IdF fait ressortir une étrangeté ( http://www.sytadin.fr/ ): l'intensité des bouchons était exactement égale à la courbe des moyennes (donc aucun effet de sur-bouchon) mais elle était décalée dans le temps; c'est à dire que les bouchons se sont produits beaucoup plus tôt dans la matinée puis résorbés, pour avoir retrouvé à 9h30 une valeur quasi nulle... du jamais vu pour Paris et sa banlieue!

75% des métros ont fonctionné mais comme il y avait beaucoup moins de monde, les voyageurs étaient détendus.

Et de réfléchir, en ces temps de crise, à la nécessité de repenser nos modes de travail. Avons nous besoin de dépenser autant de CO2 pour transporter autant de monde à des distances parfois incroyables (plus de 3h de transport par journée pour certains). Et tous en même temps (ne pouvons nous pas imaginer des horaires mieux adaptés?).

Selon le WWF, 50% des émissions de CO2 des entreprises sont liées aux déplacements professionnels : voyages d’affaires, trajets domicile-bureau, etc. L’ONG vient donc de lancer le challenge One in five pour pousser les entreprises à réduire leurs déplacements professionnels de 20% d’ici 5 ans. (source: http://www.greenit.fr/article/acteurs/50-des-emissions-de-co2-liees-aux-voyages-daffaires )

En bon provincial (et Occitan de surcroît) je suis convaincu qu'il y a trop de monde en Ile de France, et que concentrer 1/5eme de la population sur 1,7% de la surface du territoire est une aberration environnementale (et idéologique).

Les instances territoriales font toutes les études qui démontrent que les trajets domicile-travail coûtent trop cher en CO2 ( http://www.hauts-de-seine.equipement.gouv.fr/IMG/pdf/p6_pda_covoiturage_vf_cle636a11.pdf ).
Le gouvernement et la CEE s'y mettent aussi ( http://www.bougezautrement.gouv.fr/ ).

Je saluerai donc toutes les initiatives qui vont dans le sens du télétravail et de la dématérialisation, tel que http://www.cyberworkers.com/
et de suivre les actualités de sites "IT durable" tels que http://www.greenit.fr/

Il est temps de vivre au 21e siècle et de laisser loin derrière nous la révolution industrielle. L'ère a changé!

http://docs.google.com/Doc?id=dhp3ggmx_115g524prcq

je vais lever une veille taupe, peut être un débat sans fin, mais il me parait important d'essayer de remettre les cartes sur table.

Plus les années avancent, et plus je me questionne sur où vont les technologies et les éditeurs ou les projets Open Source?

Et je me demande si on ne frôle parfois pas la schizophrénie...
Par exemple chez Microsoft, on nous dit : "CRUD, Only When You Can Afford It" ( http://msdn.microsoft.com/en-us/library/ms978509.aspx )
et après on met en avant ASP.NET Dynamic Data, qui permet de faire des applications 100% orientées CRUD.

Au début était l'informatique, les carte perforées, puis les disques durs. Et tout cela stockait des données, des données, des données.
Puis vint Merise en grand éclaireur de la pensée informatique industrielle (pendant que les scientifiques n'en avaient cure, et persistait dans une voie fonctionnelle).

Ce que faisaient alors les logiciels se résumait en 4 verbes: Créer, Lire, Modifier, Effacer des données (Create Read Update Delete, CRUD en anglais).

Et après de nombreux logiciels produits sur ce modèle, on s'est rendu compte que:
1) cela ne faisait que produire des logiciels d'informaticiens, c'est à dire pas du tout "User Friendly";
2) la complexité de la réalité dépasse le stade de ces 4 opérations basiques.

On a commencé à réfléchir du point de vue de l'utilisateur. On s'est aperçu qu'il avait un besoin de logiciel dans le but de l'assister dans l'exécution de son métier (et accessoirement que l'utilisateur était livré avec des yeux).

On a donc sorti une artillerie lourde pour décrire - MODELISER - les processus métier, issus du besoin réel de l'utilisateur, représentés bien souvent par des Scénarios Utilisateurs (merci UML).

Des paradigmes tels que le "Model Driven Design" ou le "Domain Driven Design" sont venus consolider cette nouvelle façon de faire du logiciel.

Pourtant le CRUD n'avait pas pour autant disparu...

On a l'habitude de dire qu'il ne faut pas exposer les données directement au dessus d'une couche métier, tels que ce que l'on peut trouver exposé par un Web Service, et pourtant nombre d'applications le font.
et Microsoft qui va droit dedans avec SdS et ASP.NET Dynamic Data.

"Data-driven application" redevient un mot que l'on peut prononcer sans honte.

Microsoft n'est pas le seul, avec la lame de fond qu'est REST, tout est orienté ressource, donc données, et les opérations permises sont encore au nombre de... 4!
Question légitime: comment exprimer du métier avec ce genre d'outils?

Comment faire dans cet incessant aller-retour entre une paroisse et une autre? Est-ce un éternel recommencement? (et piétinement?)

la suite sur http://docs.google.com/Doc?id=dhp3ggmx_115g524prcq

article intégral sur http://docs.google.com/Doc?id=dhp3ggmx_113fv4x6tr7

the Microsoft's Application Architecture Guide 2.0
ou la Recette du Gâteau Logiciel selon Microsoft
commentée par votre serviteur

l'équipe P&P (Practices & Patterns) de Microsoft vient de sortir un bouquin en ligne (donc gratuit) à l'usage des architectes logiciels que je vous recommande chaudement: http://www.codeplex.com/AppArchGuide

Même si de larges pans de ce livre sont exclusivement tournés vers les technologies développées par MS, il y a de très bons passage très généralistes et utile au travail de n'importe quel architecte.
Je me propose de vous livrer et condenser ici 380 pages de précieux conseils.

A la lecture de cet ouvrage, il m'a semblé toujours judicieux de rappeler ce qui sont pour moi les fondements de l'art et la technique du développement logiciel en 2009:

Principes Clefs
(ou Grands Principes Métaphysiques, Tablettes de la Loi, Trucs de Grand Chef... comme vous voudrez)

on pourrait les voir comme une espèce de 6 commandements bibliques, quelque chose à inscrire dans les gènes de toute personne qui veut se lancer dans le développement d'un programme, qu'il s'agisse d'une application industrielle destinée à des milliers de personnes ou d'un programme pour machine à calculer, en passant par une RIA Web2.0 très à la mode.

• Divisez en plus petites unités fonctionnelles (Separate the areas of concern / SOC).
Diviser votre application en "features" ou "lots fonctionnels" de telle sorte que les fonctionnalités se recouvrent le moins possible (voire pas du tout).
Chaque "feature" (fonction) sera ainsi optimisée de manière indépendante des autres.
De même si une fonction ne rempli par complètement son rôle, ou bien si sa livraison est en echec, les autres fonctions en seront moins impactées.

Cette approche vous garanti que votre projet logiciel est facile à COMPRENDRE, puis à modéliser et à gérer durant tout son cycle de vie (et surtout sur les phases de maintenance et évolution)

Pour résumer: diviser, simplifier, découper. Discrétiser comme dirait mon prof de maths.
Prendre un problème complexe et le sub-diviser jusqu'à obtenir une somme de petits problèmes, chacun séparément étant évidement plus simples à résoudre que l'ensemble.

• Un composant/objet = Une responsabilité (et vice-versa).

Sachant qu'une responsabilité est soit technique, soit liée à une fonctionnalité (feature) décrite dans une spec (dans un monde idéal).
Les composants deviennent alors plus clair.
Bien sûr la notion même de ré-utilisabilité vient parfois rendre opaque une telle lecture. Car dès lors qu'un composant devient générique, son rôle peut s'opacifier. Il convient alors de bien prendre garde justement à ne pas aller vers une modélisation trop abstraite au risque de perdre ses collègues (et soi même) dans des méandres de réflexion trop personnelle. Toujours garder en tête l'utilisateur (ou l'utilisation) de la chose programmée.

"Un grand pouvoir implique de grandes responsabilités" lisait-on dans le comics Spider Man. C'est aussi vrai dans la fabrication d'un logiciel qui n'est pas une affaire à prendre à la légère.
Toute ligne de code à des effets. Et surtout l'effet de produire potentiellement un bug.
En limitant la responsabilité d'un module logiciel (j'appelle ici "module": une unité, une partie identifiable, interprétable, compilable ou encore une ressource) vous limiterez les sources d'erreurs.
Mais plus encore, il vous sera aisé de maintenir une "cartographie" de votre construction logicielle, c'est à dire savoir qu'est ce qui est responsable de quoi.

• Principe des boites noires (ou de moindre connaissance)
connu en Anglais sous les termes de: Principle of least knowledge. A component or an object should not know about internal
details of other components or objects. Also known as the Law of Demeter (LoD).

Chaque objet/composant/service est comme une boite noire (ou blanche). Il ne doit rien laisser transparaître de son fonctionnement interne.

Cette position est intéressante du point de vue extérieur à l'objet (ou au composant): un minimum de connaissance (voir aucune dans l'idéal) devrait être requis pour faire fonctionner un objet (ou le ré-utiliser).
En clair: celui-ci doit être tellement simple (et pas simpliste) à utiliser, tellement ER-GO-NO-MI-QUE, que il n'y a (presque) pas besoin de mode d'emploi.
Son usage doit tomber sous le sens.
Il doit être programmé en pensant à ceux qui vont s'en servir pour que toute manipulation en soit dramatiquement aisée.
S'il ne répond pas à ce critère, vous pouvez alors purement supprimer le composant en question.

* Ne ré-inventez pas la roue (ou tout autre chose) et ne vous répétez pas

en Anglais ça donne:
Don’t Repeat Yourself (DRY). Do not duplicate functionality within an application.

Dans le cadre de la séparation des responsabilité, il ne doit pas y avoir 2 objets/composants/services qui aient la même responsabilité.
En clair, veillez à ce que jamais une fonctionnalité ne soit dupliquée quelque part dans votre édifice final (ou solution ou même votre ensemble urbanisé d'informatique d'entreprise).

Ceci est un exercice délicat. Sans parler des problèmes complexes qui se posent dès que l'on veut partager des fonctionnalités avec d'autres équipes ou d'autres systèmes (problème de représentation, de vision, d'échange et de politiques - et ces politiques ne s'arrêtent pas à des histoires de sécurité mais revêtent bien des fois des apparences de politique civile - voir guerrière dans certaines organisation ... bref!).

Un exercice délicat, disais-je, ne serait-ce que tenter de l'appliquer à soi-même.

Il est difficile de donner un recette pour être sûr que ce précepte soit constamment appliqué.
Mais j'ai appris récemment une bonne approche: supprimer du code.
Oui, oui, vous avez bien lu. L'idée est de considérer que toute ligne de code écrite est mauvaise.
Elle l'est par définition, car derrière une ligne se cache un bug.
Ensuite, relisez (ou faites relire) votre code en vous disant "est-ce que cette fonction (ou feature) n'existe pas déjà ailleurs"?

Pour arriver à faire une telle lecture de votre solution logicielle (code ou intégration de composants/service), il est indispensable d'en posseder une cartographie particulièrement claire et bien documentée.

Dans les effets positifs, on sait bien qu'une telle mesure rend les changements plus simples à gérer ainsi que la maintenance corrective de l'application ou la solution.

* Ne passez pas votre vie à faire du Design / Modélisation

"Avoid doing all your design upfront (BDUF). "

Modéliser c'est bien. Agir c'est mieux. Mais difficile de trouver le juste équilibre. On ne va pas non plus revenir au RAD des années 80.
Combinez les approches. MDA ? le Modèle avant tout? TDD? les tests et rien que les tests?
Peut être un peu de tout ça.
En tout cas, ne vous laissez pas bloquer.
Un Design genre "Draft" (brouillon) ou "squetch" (exquisse) peut parfois être suffisant dans nombre de projets.
Si les spécifications sont peu claires ou très glissantes, alors partez sur du code dirigé par les tests.
Mais n'oubliez pas de tenir un modèle à jour pour avoir une bonne cartographie du projet.

Les modèles évoluent, et parfois aussi vite que le code. L'art est de garder le tout synchronisé!

(Re)Mettez-en des couches!

Différence entre un Tiers et une Couche (Tiers/Layer)
Une couche est un regroupement logique de "composants" logiciels.
Une bonne analogie est le modèle en couche OSI que j'ai déjà mentionné dans les colonnes.
La séparation de communication entre N et N+1 est complètement vérifiée (ou doit l'être).

La suite de l'article intégral sur http://docs.google.com/Doc?id=dhp3ggmx_113fv4x6tr7

j'ai vu ce jour arriver, grâce à cette vidéo:
http://wm.microsoft.com/ms/msdn/oslo/mwindowexample.wmv

Bien sur, ce que vous voyez n'est qu'une petite démo ultra-triviale et mon titre est un petit effet de manche.

Le génération de code à partir de spécifications ce n'est pas nouveau. CAML fait cela depuis longtemps.
Mais ça se rapproche. Ça se démocratise.

On est bien loin des langages B ou Z (cauchemar de mes dernières années de fac). Avec 'M' (justement appelé ainsi en références aux "vieux" langages formels) on arrive à un niveau de manipulation bien plus sympathique pour créer son propre générateur de langage.

Ecrire sa propre grammaire devient plus abordable. Cette video le démontre.
Nous voyons un "ex-développeur" écrire un programme juste en déclarant les spécifications du résultat attendu.

Il dicte en anglais la description du résultat qui est attendu. En français on pourrait faire la même chose avec une grammaire du style: "Donne moi une fenêtre qui soit avec un fond rouge, qui contienne un bloc de texte appelé BT. BT contient le texte 'salut les gars!' avec une couleur verte." (bon, d'accord, le français est une sale langue pour nous informaticiens, avec toutes ses règles d'accords, de conjugaison et surtout l'ambiguïté introduite par les relatives)

Voila qui stigmatise bien le futur du processus de développement de logiciels.
A mon humble avis, dans 5 à 10 ans, nous n'aurons plus à écrire une ligne de code.

Cela tiendra à plusieurs facteurs:

1) l'enrichissement des Framework de développement:
quelque soit la plateforme choisie (.Net ou J2EE), ce n'est que lorsque les API seront suffisament riche, que le niveau d'abstraction présenté sera suffisant pour brancher un outil de génération de code.
On a presque atteint ce stade. La video montre que WPF par exemple est assez haut niveau pour pouvoir être ciblé directement par un modèle qui peut sembler assez naturel. Il faudrait tout de même critiquer le fait que cette syntaxe reste assez lourde et figée et donc qui s'éloigne d'une grammaire context-sensitive (donc moins "permissive" que le langage naturel mais du coup qui élimine tout risque d'ambiguïté)

2) le Framework "programmatoriel" (+) ne pourra pas tout faire, car il est par nature orienté sur du non-fonctionnel, et sur des opérations somme-toute "techniques". Aidé par des annexes qui règlent des problématiques particulières telles que l'accès aux données, le monitoring, la gestion des défauts, la programmation concurrente, et tout autre sujet à la mode, ces Frameworks font beaucoup , vraiment beaucoup mais ne savent pas traiter les cas métiers.

3) A ce moment là, il faudra établir des frameworks métiers très bien pensés pour être à leur tour la cible de spécifications fonctionnelles écrite en M (ou en Z pour les récalcitrants). La stabilisation de ces frameworks sera longue et douloureuse.
D'abord parce que chaque métier à sa façon de faire, d'écrire des procédures (si tant est il a pu arriver à un niveau de maturité qui permet de les coucher sur papier sans ambiguïté, ce qui n'est pas gagné);
Ensuite parce que chaque entreprise est tentée d'écrire le sien (selon sa propre vision de son métier) et que pour un même métier on aura des centaines ou des milliers de frameworks différents. Problèmes de normalisation (on a l'habitude) en vue!

4) et dernier obstacle: le langage "sur-fonctionnel" lui-même (c'est à dire le langage source computé par M)
il faudra plus que des grammaires formelles pour arriver à exprimer librement le comportement d'un logiciel et pondre en quelques ordres vocaux une suite logicielle complète.

Pourtant le travail du développeur ne cesse d'évoluer. Moins technique, plus formel.

M va nous faire progresser dans ce sens, car il rend juste ce vieux rêve (celui de Turing) plus "proche".

Des blocs entier de lignes de code pourront être générées par simple description, mais pas l'intégralité du logiciel.
Mais la notion de ré-utilisabilité et de frameworks métiers va devenir toujours plus pressante.

La qualité du design sera fondamentale puisque les logiciels seront fabriqués réellement à partir du modèle. Mais l'on ne peut se soustraire aux obligations de qualité et de fiabilité.
L'on doit donc se poser la question de la testabilité des modèles.
Et de s'assurer que les briques sous-jacentes et invoquées par nos générateurs de code depuis le modèle sont également exemptes de tout défauts... faute de quoi, on aura fait que déplacer les problèmes.

(+) ne me demandez pas d'où je le sors celui là, c'est venu comme ca.

Introduction

Pour une solution logicielle basée sur une interface Web, les Défis technologiques à venir sont majeurs.

Le modèle économique naturel d’une telle solution est l’application louée.

C’est aujourd’hui sur le marché une grande tendance, affublée de différents acronymes ;

SaaS (Software As A Service), Application OnDemand, S+S (Software Plus Services), etc…

Les applications louées sont un excellent modèle financier mais requiert de grandes capacités techniques :

disponibilité, monté en charge, configurabilité, résilience, surveillabilité …

L’idée est de penser comment relever ces défis en intégrant ces problématiques au cœur du logiciel, c'est-à-dire dans le code.

Cas fréquemment rencontrés

Beaucoup s’imaginent que faire du SaaS c’est mettre un serveur Web à disposition de chaque locataire de l’application, ou plutôt une instance de Serveur Web . Dans IIS la chose est simple à réaliser. Créer un site virtuel pour chaque applicatif et faites pointer sur un répertoire différent (ou mutualisez la partie BIN pour avoir le même code exécuté partout).

Changez la ConnectionString et voila une nouvelle application prête à accueillir un locataire de plus.

Ce genre d’architecture physique (de déploiement) n’est pas sans poser de problèmes. Regardons comment ca marche dans IIS :

image sur le document: http://docs.google.com/Doc?id=dhp3ggmx_98f642cnvj

Chaque site Web de client à son processus dédié et donc un espace mémoire isolé ( x Mo de footprint par site Web).

Viennent ensuite les serveurs Back qui font tourner SQL Server.

Problèmes posés

Cette architecture présente l’inconvénient d’un certain monolithisme. Certes la base de données est dé-corrélée des autres traitements. Mais justement tous les traitements autres que Base de Données sont massivement imposés au serveur IIS qui doit tout faire dans un espace mémoire qui devient vite saturé.

Pour augmenter la capacité d’accueil de l’application, il n’y a guère d’autres moyens que d’ajouter des serveurs Web avec IIS et/ou de la RAM pour monter en capacité charge (interventions physiques ou sur machines virtuelles).

Il est impossible d’effectuer de la répartition de charge logique entre les différents briques applicatives inter-clients. On ne peut répartir la charge que par client (locataire) de la plateforme.

C’est sans parler des problèmes de mise à jour de la partie applicative (code) sur chaque serveur applicatif. On peut aussi avoir besoin de centraliser certaines parties.

Pourquoi y répondre ?

* Pour offrir plus de souplesse

* Pour simplifier l’exploitation

* Pour augmenter la capacité d’accueil

* Pour encaisser les pics de charge

* Pour s’aligner sur un modèle de programmation issu des meilleurs pratiques

* Pour exploiter enfin les capacités du framework .Net et de IIS

Pistes de réflexion

L’idée directrice est de tirer parti de la puissance que le Framework .Net peut apporter.

Avec ses évolutions, et notamment la version 3.5, .Net s’est doté de WCF, l’implémentation concrète d’un nouveau paradigme de programmation orienté services (SOA).

Avec WCF, on programme des services encore plus simplement qu’on programmait des composants avant (je pense à COM/COM+/DCOM).

Ce qui est important de garder en mémoire ici, c’est qu’ à partir du moment où on a des composants qui s’exposent en services WCF, toute la partie déploiement est complètement découplée et donc re-paramétrable à souhait.

On peut choisir librement les scénarios de transport, protocole, sécurité, fiabilité que l’on souhaite sans redévelopper une seule ligne de code.

Les applicatifs Web programmés en .Net fonctionnent avec ce que Microsoft appelle maintenant son « serveur applicatif », c'est-à-dire IIS.

S’il est présenté comme un vrai serveur applicatif, pourquoi n’en offre-t-il pas toutes les fonctionnalités ? Car si on s’en tient à la console de gestion IIS on peut rester sur sa faim…

La réponse à cette question est : Utilisez WAS !

la suite est ici: http://docs.google.com/Doc?id=dhp3ggmx_98f642cnvj

Dans le cadre du projet OpenNetCRM http://www.codeplex.com/OpenNetCRM, je vous propose un tour d'horizon de l'architecture de codage technique (organisation des assemblies) de base que nous avons mis en place.

Microsoft nous présente depuis déjà les années 2002-2003 un modèle d'architecture de construction du logiciel N-tiers, qui est aujourd'hui accepté à peu près (avec toutes les variantes nécessaires) par l'ensemble de la communauté .Net

Je vous propose de revenir sur ce modèle et de le décrypter avec les technologies d'aujourd'hui :

La couche UIC est implémentée par les éléments de type VIEW du projet MVC ASP.Net « Views ».

La couche UIP est implémentée par les éléments de type CONTROLER du projet MVC ASP.Net « Controllers ». que nous pourrions compléter par une librairie de type WF (Human Workflow).

La couche Service Interface (SI) est implémentée par l’assembly X.Common.Services.AccessSurface et les sous-assemblies.

La couche BW n’est pas implémentée dans cette version. La couche BC est dans X.Common.Business

La couche BE est dans X.Common.Business.Entities

La couche DAC/DAL est dans X.Common.DataAccess.Entities et Common.DataAccess.Manipulations.

La couche SG est dans X.Common.Services.ExternalGateways

Les couches Verticales sont les couches techniques. Elles sont à 90% prises en charge par le Framework .Net 3.5 et des librairies externes comme Microsoft.Practices.EnterpriseLibrary ou autres. Mais nous avons souvent besoin de les compléter ou les rendre plus accessibles.

En pratique, que mettre dans le projet logiciel?

ici, je vous livre une suggestion de construction de la solution logicielle telle qu'on peut la compiler dans Visual Studio, basé sur le projet CodePlex que nous avons monté avec Rui ( http://www.rui.fr/2008/09/16/LancementDunProjetDeCRMOuvert.aspx ) et Zied ( www.zied.fr )

Le reste étant visuel, je vous propose de lire l'intégralité de ce billet sur
http://docs.google.com/Doc?id=dhp3ggmx_79fd5v7xcf

tout ces/mes billets sont bien gentils mais que valent-ils s'ils ne sont pas soutenus par une expérience de terrain complète?

Travaillant depuis des années sur des projets divers et surtout avec une réalité d'entreprise excessivement variante d'un projet à l'autre (ambitions, moyens, vision), il m'a semblé judicieux de rallier l'idée de Rui Carvalho http://www.rui.fr/ :
monter un projet Open Source global autour d'une application universelle de CRM (Customer Relationship Management), afin d'assurer une continuité dans l'œuvre architecturale logicielle que l'on peut être amenée à réaliser aux cours de nos vies d'informaticiens.

La gestion de la relation client me semble être partout.
Et surtout présente à toutes les échelles et sous différentes formes.
Du petit artisan à la multi-nationale, toute personne qui a une activité professionnelle, quel qu'en soit le domaine, se doit de "chouchouter" ses clients.

Si de très grands éditeurs se sont depuis longtemps emparés du marché logiciel de gestion de la relation client, personne n'a pensé à fournir une solution qui soit à la fois pour Monsieur Tout-le-Monde et en même temps un socle applicatif unique qui définisse les fondamentaux de ce grand domaine informatique.

Ce projet s'appelle Open .Net CRM et est visible sur cette page http://www.opennetcrm.org/
Le code est ouvert bien sur, et une démo sera en ligne. Pour l'instant nous invitons les curieux à regarder comment cela se construit, car c'est en même temps le labo technologique de l'état de l'art de la programmation .Net

Nous avons en effet mis au menu, les plats suivants:
IHM Web avec ASP.Net 3.5 MVC preview 5
mapping O/R avec EF
WorkFlow .Net 3.0
Managed Extensibility Framework
WCF / REST

(tout est standad VS 2008 SP1 sauf http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=16775 )

Bien sur, toute bonne volonté pour nous aider dans l'effort de codage sera grandement appréciée

Notre ambition est aussi de mettre sur pied un "Generic Application Blocks (GA for CRM projects".
C'est à dire de faire en sorte que le code de ce projet puisse alimenter des projets plus importants par des briques de base qui codent déjà le fonctionnement standard de toute application CRM qui se respecte.

Nous vous tiendrons informé de l'avancement de ce projet régulièrement, et il sera pour moi le moyen de vous fournir des exemples concrets à mes billets (en particulier sur tout ce qui est SOA/ SaaS / Cloud Programming) tout en permettant de rester dans l'axe d'un projet d'entreprise complet et solide.

consultez l'intégralité de cet article ici:
http://docs.google.com/Doc?id=dhp3ggmx_92hf99pvc3

ou Comment utiliser WCF pour imiter le comportement REST de ADO.Net Data Services?

L'idée est de programmer simplement un service en mode REST qui puisse consommer des données d'un Service SaaS.

Comme je l'ai expliqué dans mon billet précédent, il n'est pas bon d'utiliser directement ADO.Net Data Services car vos données sont exposées sans la moindre pudeur.

C'est pour cela que j'ai détaillé comment on pouvait utiliser la puissance de Entity Framework, tout en étant excessivement rigoureux au niveau sécurité et respect des contraintes "métier" en développant soit même la technique qui nous permettait de filtrer, verifier, limiter l'information retournée. Et en toute simplicité grace à LINQ.

Il ne reste plus qu'à peaufiner l'exposition de ce que cet objet Metier sait faire.

Ado.Net Data Services (anciennement Astoria) et l'initiative Live Mesh nous ramène dans le droit chemin des standards Internet.
Microsoft embrasse soudainement la philosophie REST, se conforme aux formats Atom ou RSS. Bref, le développeur est roi, vive le développeur !

Chacun son choix, chacun sa paroisse. WCF est suffisament puissant pour se conformer à une option de déploiement plutot qu'un autre.

REST peut s'averer le bon choix de l'ouverture et de la simplicité. Son modèle va influencer notre façon d'exposer du Service.

Il faut déjà bien assimiler ce qu'est REST. Je vois renvoie pour cela à la lecture de cet article que j'aime bien car tr_s clair et à la fois qui explique bien les fondamentaux:
[http://www.biologeek.com/rest,traduction,web-semantique/pour-ne-plus-etre-en-rest-comprendre-cette-architecture/]
(copiez coller le lien entre crochets)

Representational State Transfer

REST est l'acronyme de Representational State Transfer. Son principe est de tirer parti du fameux protocole HTTP.

Appliqué au monde des Services Logociels, le concept clé est de manipuler des ressources ,et des actions que l'on peut appliquer aux ressources exposées.

Ces Ressources sont identifiées (de manière unique, c'est le but) par des Uniform Resource Identifiers (URIs).

Les web services basés sur SOAP font usage d'une URI pour désigner le "endpoint " du service augmenté d'une opération.

Un web service à la sauce REST (dit "RESTful") utilise une URI unique pour referencer chaque ressource, et utilise les verbes déjà définis par le protocole HTTP comme GET (prendre, lire) ou PUT (poster, modifier) pour definir les actions sur ces resources.

L'URI permet très simplement d'identifier le "endpoint" du service et l'opération à invoquer, mais finalement de manière assez figée et sans toute les possibilités d'extension de SOAP (et sans même parler de WS-*).

L'URI se doit donc d'être réellement et universellement unique.

Chaque ressource à son URI propre.

Si tous les blogs de DNG sont sur l'uri http://www.dotnetguru2.org/blogs, alors un de mes articles (le n°4655 par example) devra être servi par l'URI: http://www.dotnetguru2.org/blogs/4655

par défaut le verbe HTTP sera GET qui sera donc interprété en action "prendre" ou "lire". C'est l'usage dans REST.

Cette unicité est la plus importante. Chaque ressource doit avoir sa propre et unique URI.

Les codes de retour HTTP doivent être utilisés de la bonne manière, afin d'informer l'appelant (client) de ce qui s'est passé coté serveur lors de la tentative de réponse à une URI demandée (erreurs ou pas, nous verrons en détail plus loin dans cet article).

Vient ensuite le concept de "pureté" de l'URI

"URI purity", est une bonne pratique qui impose que la valeur de l'URI ne doit pas masquer sa signification et ne doit pas contenir de "bruit" d'implémentation.
Idéalement, l'URI doit exprimer purement le chemin à une ressource, et ne doit pas laisser transparaitre quelles sont les technologies sous-jacentes (IIS, Apache, .Net ou J2EE) utilisées.
Par exemple, si mon URI est "http://www.dotnetguru2.org/blogs/posts.svc?id=4655", tout le monde comprend que j'utilise IIS et .Net pour implémenter mon service. Cela ajoute une information à mon URI qui n'a rien avoir avec la ressource que je veux exposer.
Il faut donc faire disparaitre cette information inutile de l'URI (grâce à du URL rewriting ou l'attribut WebGet(UriTemplate=XXX) de WCF)
Si je change de techno d'implémentation, mes URI doivent rester immuables dans le temps (afin de ne pas avoir à faire changer le code d'appel de tous mes clients).

Comment de notre coté exposer notre objet Métier "fiabilisé" via REST?

Voici une petite fiche de recette:

Ayant adopté la "philosophie" REST, nous devons donc repenser l'exposition dans nos services comme une exposition de Ressources.

Les Ressources sont nommées de manière unique on l'a dit. Dans notre exemple OpenCRM nous avons des Clients. Il faudra donc une méthode pour lister les Clients, obtenir le détail d'un client, créer un nouveau client, modifier un client existant, et supprimer un client.

Tout cela est horriblement CRUD, mais c'est bien la philosophie de REST. Il faudra rester prudent quant à la surface d'exposition de telles méthodes, aux pré-requis. Et à ce titre ne pas hésiter à faire évoluer cette modélisation vers quelque chose de moins basique, et qui se teinte plus du métier pour lequel nous oeuvrons.

Travaillons d'abord les méthode de "lecture" des données. WCF sait gérer ces cas grâce à l'attribut [WebGet]
L'idée avec REST est que c'est l'URI qui dicte le comportement du service invoké, de telle sorte que l'appel d'un REST service est très simple à écrire et décrypter par un humain (comparé à SOAP).

La méthode (verbe) Http sera dont GET, et l'URI nous dira quelle "ressource" on veut obtenir.

...........

consultez l'intégralité de cet article ici:
http://docs.google.com/Doc?id=dhp3ggmx_92hf99pvc3

Bien Exposer des Données à travers un Service Partagé (SaaS) en toute Sécurité ... et sans peine!

http://docs.google.com/Doc?id=dhp3ggmx_88d4ddv7dm (copiez coller cette URL pour voir l'article avec les illustrations, on n'a pas le droit de faire des liens vers google ici )

Devant la prolifération des outils qui facilitent tellement l'exposition de modèle de données, on ne peut que s'inquiéter des dérives que de telles facilités peuvent engendrées.

Avec le mouvement du "Programming the Cloud", et toute la tendance massive du SaaS (qui devient chez Microsoft l'émergence des futures solutions louées en ligne pour les data et les services) l'accès aux données à travers un Service devient un enjeu majeur.

Notez qu'on ne parlera bientôt plus de "programme" ou de "logiciel" mais de Service, tout simplement.

En bon développeurs de "Services" que nous sommes, et vu la demande croissante de production, nous souhaitons tous des moyens pour construire plus vite.

Microsoft nous gate avec le SP1 de son Framework .Net 3.5, en particulier avec le Entity Framework (EF ou Ado.Net EF).

ADO.NET Data Services fini de nous séduire en proposant d'exposer le plus simplement du monde, 2 clics, 1 ligne de code, les données directement puisées d'une base de données relationnelle ( (voir http://msdn.microsoft.com/en-us/data/cc300162.aspx ) ou d'une source de données autre (voir http://msdn.microsoft.com/en-us/data/cc745968.aspx

Pourtant que d'erreurs allons nous commettre, si comme par le passé, nous utilisons ces automatismes, sans un minimum de prudence et de raison.

C'est sans parler des problèmes évidents de sécurité, mais les démonstrations faites par les évangélistes me font toujours un peu peur... Combien de développeurs s'inspirent de ces exemples, et oublient au moment de mettre en production de re-vérifier toutes les failles de sécurités laissées béantes en phase de développement.

Au delà de la sécurité, je veux mettre l'accent spécifiquement sur la nature des données exposées.

Cet aspect parait souvent désué à nombre de concepteurs qui balaient le problème d'un " de toutes façons, mon modèle de données est irréprochable".

Mettons nous dans un cas pratique intéressant, celui d'une application en mode SaaS justement.

Nos données sont isolées pour les différents utilisateurs du Service. Mais le schéma et le modèle de données est unique dans notre partie physique.

Notre modèle physique pourrait ressembler à ceci dans une application dont le but serait de gérer des clients (cClients) possédés par un utilisateur (gTennant) de l'application (et celle-ci serait multi-utilisateurs).

Grâce à Entity Framework, il est aisé d'en tirer un modèle logique, comme celui-ci (voir les tutoriels sur EF qui ne manquent pas sur le Web et sur http://www.zied.fr/ )

Il est évident pour des raisons de sécurité et de bon sens, que toutes les données présentes ici dans le modèle logique ne doivent pas apparaitre aux yeux du monde extérieur.

Sinon, tout le monde pourrait connaitre quels sont les utilisateurs ("Tennant" en anglais) de mon application louée, savoir s'ils ont un abonnement valide, connaitre leurs clients, etc. Ce serait une catastrophe!

Le principe de mapping que nous offre le modèle logique de EF nous permet de supprimer des objets entités du modèle ou bien de "dégraisser" des propriétés d'une entité (c'est à dire ne plus les mapper entre le modèle physique et le modèle logique).
Si nous faisions cela, nous ne pourrions plus requêter avec Linq sur les entités ou les propriétés que nous ferions disparaitre; ce n'est donc pas la bonne solution.

De plus, nous voulons créer un service qui justement soit consommé par un utilisateur (Tennant) et celui ne peut voir que ses propres clients.
Il faut donc passer par un objet Service qui fasse la requête appropriée et qui filtre les résultats.

L'idée est donc de NE PAS utiliser Ado.Net Data Services directement mais reproduire la même chose en passant par un objet métier dont nous avons le contrôle absolu et qui endossera une véritable fonction métier, dans notre cas, filtrer la liste des utilisateurs selon l'ID du Tennant.

Pour cela, il est bon de créer une librairie de classe supplémentaire, dédiée au classes de type "Métier" ou "Domaine" selon votre design.
Imaginons que nous y ajoutions une classe "SimplesServices" qui contiendra les méthodes
public string Authenticate(string Login, string Password)
et
public List [ Client ] GetClientsList(string SecurityToken)

La 2eme sera chargée de nous retourner la liste des objets qui représentent les client du Tennant qui s'est préalablement Authentifié.
La méthode Authenticate retournant justement un SecurityToken. Ce n'est qu'une façon d'établir une sécurité dans un service.
Pour quelque chose de plus robuste encore, je vous conseille d'utiliser les options de sécurité programmables (WS-Security) avec WCF et/ou CardSpace.

Notamment, on peut récupérer le UserName en utilisant les Security Token.
WCF permet de le faire assez facilement, je vous recommande de lire cet article qui permet une mise en oeuvre rapide
comme ceci
http://msdn.microsoft.com/en-us/library/ms751480.aspx

l'idée est de récupérer les identifiants de l'appelant du service à l'aide d'un certificat, et d'en extraire le UserName

[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class EchoService : IEchoService
{
public string Echo()
{
string userName;
string certificateSubjectName;
GetCallerIdentities(
OperationContext.Current.ServiceSecurityContext,
out userName,
out certificateSubjectName);
return String.Format("Hello {0}, {1}",
userName, certificateSubjectName);
}
}

Dans notre code, nous exploiterons le UserName.

Le tout est maintenant de faire une requête Linq qui renvoie les Clients de l'utilisateur dont le UserName est celui récupéré par le Security Token

public List<Client> GetClientsList(string SecurityToken)
{
string userName;
string certificateSubjectName;

GetCallerIdentities(
OperationContext.Current.ServiceSecurityContext,
out userName,
out certificateSubjectName);

SimpleModelDataContext contxt = new SimpleModelDataContext();

var requete = from clients in contxt.cClients
where (clients.gTennant.Name == userName)
select clients;

}

Tout semble bien au niveau de la requête Linq. Nous avons fait notre job, c'est à dire filtrer les données par rapport au Nom du Tennant (Utilisateur)

Le petit hic c'est qu'on ne peut pas retourner l'objet Entité "cClients" tel quel car il contient des informations que nous ne voulons pas divulguer.

Il faut donc exposer un autre objet Entité Client, mais qui n'a du sens qu'au niveau Métier, c'est à dire à ce niveau ci de notre code.

Il n'y a pour l'instant pas le choix (en l'absence d'un outil qui reste à créer) que de déclarer une classe faite par nos soins (mais on peut aller vite en utilisant le visualiseur de diagramme de classes intégré à Visual Studio); ce qui donne:

Voila pourquoi notre méthode retourne une List<Client> (et non pas de "cClient").

Avidement, le type de classe "Client" ne correspond par à la classe d'entité "cCclient" défini au niveau Entity Framework (dans le code behind du fichier .edmx)

Il nous manque un outil de mapping "entité données /entité métier". Il n'existe pas (à ma connaissance) d'outil graphique aujourd'hui, quoique le concept de EF pourrait être justement transposable.

Mais il y a Linq to Objects ! Et une seule ligne peut nous permettre d'écrire une transposition de propriétés d'objets. Et c'est rudement efficace!

Pour preuve:

var resultatRequete = requete.AsQueryable();

var mappingEFversEM = from t in resultatRequete
select new Client { Nom = t.LastName, Prenom = t.FirstName } ;

return mappingEFversEM.ToList<Client>();

On part de la 1ere requête, et on en constitue une autre qui va utiliser les résultats que la 1ere produit (donc une liste de "cClient"), et en extraire (par select) de nouveaux (new) objets de type Client (et non plus cClient) qui sont instanciés à la volée (avec la nouvelle syntaxe des initialiseurs), ce qui nous permet de choisir les propriétés (ici seulement le Nom et le Prenom) à peupler.

Voila réglé la grosse problématique de la sécurité et de la représentation des données que nous exposons au monde extérieur.

Par contre nous avons perdu l'avantage qui était que le protocole REST était complètement pris en charge par ADO.Net Data Services. Il sera facile de remédier à cela, ce que je montrerai dans la suite de ce billet.

Bonne rentrée.

PS: le "truc" de la transformation de représentation d'objet en une autre m'a été soufflé par Mohamed Zied NEMILI, développeur émérite, dont je ne peux que vous conseiller la lecture de son blog http://www.zied.fr/ .

Afin d'éviter de faire trop d'appel à la BD , on a souvent eu besoin d'avoir une petite couche de persistance, mais en mémoire
et pouvant stocker beaucoup d'objets
... une sorte de CACHE en quelque sorte!
avec EDM, c'est encore plus vrai

et pour un SaaS c'est encore plus vrai, car c'est de l'application web (Asp.Net) et une telle couche permettrait d'arrêter les bidouilles avec la Session
sachant que la Session N'est PAS faite pour y stocker des objets de données, et ne doit pas être utilisé comme un cache.

ca tombe bien, Microsoft, nous prépare Velocity

c'est livré comme un SessionStoreProvider pour ASP.Net, donc l'intégration dans IIS est automatique, rien à bricoler au niveau déploiement.

ca se télécharge ici:
http://www.microsoft.com/downloads/details.aspx?FamilyId=B24C3708-EEFF-4055-A867-19B5851E7CD2&displaylang=en

"Velocity" is a distributed in-memory application cache platform for developing scalable, available, and high-performance applications. Using "Velocity," applications can store any serializable CLR object without concern for where the object gets stored because data is cached across multiple computers. "Velocity" allows copies of data to be stored across the cache cluster, protecting data against failures. It can be configured to run as a service accessed over the network or can be run embedded with the distributed application. "Velocity" includes an ASP.NET session provider object enabling storage of ASP.NET session objects in the distributed cache without having to write to databases, which increases the performance and scalability of ASP.NET applications.

http://msdn.microsoft.com/en-us/library/cc645013.aspx

http://msdn.microsoft.com/en-us/data/cc655792.aspx

pour ceux (comme moi) qui adorent essuyer les plâtres ou qui sont tellement avides de faire tenir ses promesses à Ado.Net Entities, un petit avertissement s'impose avant de se jeter dans l'adoption du SP1 beta de VS2008 (et ce sera surement valable pour sa version définitive):

si vous avez déjà développé des classes avec les Modele d'Entités de données EDMX, vous rencontrerez quelques problème en passant de la version ADO.NET Entity Framework Beta 3 que l'on peut télécharger sur downloads.microsoft.com depuis plusieurs mois déjà, au SERVICE PACK1 BETA de VS2008 fraichement sorti.

Comme il fallait s'y attendre, d'une version Beta à une autre, le schéma XSD des fichiers EDMX a changé, et une fois passé le service pack 1 de VS2008, vos projets avec des classes Ado.Net entities ne vont plus compiler (error de validation XML sur les fichiers EDMX)

Rassurez vous, la partie n'est pas perdue pour autant.

A l'aide d'un clic droit sur le fichier EDMX dans l'explorateur de solution, vous pouvez éditer l'original XML de ce fichier. Et modifier le tout à la main:

d'abord, un élément XML a été enlevé, il se trouve dans <edmx : Designer >
et se nomme <edmx:ReverseEngineer />
il suffit tout simplement de le supprimer

ensuite, les blocs XML ont été un peu ré-ordonner et il vous faudra réordonner les 3 blocs principaux présents dans <edmx:Runtime>

1)<!-- SSDL content -->

2)<!-- CSDL content -->

3)<!-- C-S mapping content -->

(ca n'est pas la partie la plus importante mais le "Custom Tool" qui parse les fichiers EDMX peut raler de ne pas trouver certaines références mapées)

enfin, c'est dans la partie <!-- SSDL content --> <edmx:StorageModels>
que ca coince.
Un nouvel attribut nommé Provider est apparu dans la balise <Schema>. Mais ce n'est pas tout , le ProviderManifestToken a changé et un nouveau sous schema est entré en scène.
Bref, il vous faudra changer tout le contenu interne de la balise
<Schema Namespace="MonModelAMoi.Store" .............>
par ceci
<Schema Namespace="MonModelAMoi.Store"
Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2005" xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" xmlns="http://schemas.microsoft.com/ado/2006/04/edm/ssdl">

Sauvez, et déjà vous pourrez constater agréablement que votre EDMX peut de nouveau etre édité en mode WYSIWYG

Je me suis lancé dans une étude exhaustive de la qualité des services au sens SOA.

Si nous sommes tous convaincus (j'espère) du bien fondé de ces architectures, encore faut-il bien les approcher.

C'est sous un nouveau regard, celui de l'Ergonomie (Usability en Anglais) que je vous livre ma reflexion sur l'approche orienté service dans l'industrie du logiciel en 2008.

Dans cet article, je fais le tour de toutes les bonnes recettes concrètes applicables simplement en phase de design sur vos services. Si vous êtes également en panne d'inspiration, cette approche est une bonne méthodologie pour écrire des Web Services quand on ne sait pas par quel bout les prendre. Bonne lecture.

Avez vous le sens du service?

Cette phrase, certains développeurs auraient pu l'entendre au cours de leur carrière.
Qu'ils se rassurent, il ne s'agit pas d'une remontrance à leur encontre pour ceux qui travaillent dans une société de "services".
Oui, le service est sacré surtout lorsque le service demandé est celui que l'on attache à un système d'informations.

Aujourd'hui, des termes comme SaaS commencent à prendre du poids et si le logiciel peut être (doit être, même!) vu comme un service ou augmenté de services, cela ne se fait ni automatiquement (et sûrement pas en un CleanRAD aveugle), ni sans réfléchir aux acteurs impliqués dans la construction et dans l'utilisation d'un logiciel ou un SI.

Un logiciel est un système dynamique, il y a des entrées, des sorties, des changements et même des bouleversements.
C'est une entité, complexe. Une machine, une usine et même un écosystème à lui tout seul.
Il doit respecter non seulement des contraintes externes mais aussi ses propres contraintes, intrinsèques, posées par le framework qui a servi à le développer.

Avoir le sens du service logiciel, c'est penser à tout cela.
C'est avoir toujours en tête que l'on est pas seul à programmer et poursuivre nos efforts pour que, bientôt, le développement durable ait également du sens dans l'industrie du logiciel.

Qu'est qu'un bon service?

c'est la question qu'il faut se poser. Et derrière cette question s'en cache une flopée d'autres... "qu'est ce qui me rend productif si j'utilise un service ? quel surcharge de travail vais-je assumer lorsque je vais le consommer ?" pourrait-on se demander...

Il y a une dimension humaine -psychologique même- à un service puisqu'il aborde un métier. Et qui dit métier dit "savoir faire". Expression dans lequel le mot savoir est peut être plus important que le mot faire. Il y a de la cognition et de la sémantique derrière tout cela.

Il faut penser, comme les ergonomes, en terme de scénarios d'utilisation.

Tout cela peut se reprendre en une formule: est que mon service est utilisable?

La capacité à être utilisable c'est la "usablity"; le mot a plus de sens dans sa traduction depuis l'anglais: ER-GO-NO-MI-QUE.

Voila, le loup est enfin lâché: l'ergonomie doit rentrer en ligne de compte dans le design des Services et d'une Architecture Orientée Service (SOA).

Mais prenons garde, l'ergonomie est une science humaine.
C'est là que l'approche peut dérouter plus d'une personne: faire rentrer l'aspect humain dans la programmabilité des services.

La suite ici: http://docs.google.com/Doc?id=dhp3ggmx_38f58b3d

je n'ai absolument aucun culte de la personnalité pour qui que ce soit, et surtout pour Bill Gates. Force est de reconnaitre que c'est quelqu'un qui a compté pour l'histoire de l'informatique et on lui doit de grandes avancées technologiques fondamentales (COM et .Net).

Il s'habille vraiment mal (le pantalon qui remonte au dessus de l'estomac sur une chemise blanche bouffante, c'est vraiment attroce) mais il a le sens de l'humour.

L'auto dérision pratiquée par l'ex homme le plus riche du monde, cela donne ca:
http://www.youtube.com/watch?v=v5uw07iEkjU&eurl

genre: "vous avez vu qui sont mes amis, hein?"
allez, c'est drole quand meme, surtout la scéance de méditation Zen sur une boule géante