Fabien Bézagu

L'histoire retient des couples légendaires : Roméo et Juliette, Bonnie and Clyde, le pâté et le saucisson... Je suis aujourd'hui convaincu que ROA et DDD ont leur place parmi ces couples légendaires.

Parmi les livres que j'ai lus cette année, c'est indiscutablement RESTful Web Services qui m'a le plus apporté. En deux mots, puisque ce n'est pas le sujet de ce billet, ce livre prône la simplicité en montrant que HTTP est suffisant pour créer des services web puissants sans ajouter de complexité inutile. Il introduit également Resource Oriented Architecture (ROA) qui est une approche pour créer des services web RESTful en mettant les ressources au coeur de l'architecture.

Plus je m'imprègne de ROA, plus je suis frappé par les parallèles qu'il est possible de faire avec DDD.

Des objets, encore des objets

Avec une conception orientée par le domaine (DDD), le paradigme objet est totalement utilisé. On pousse au maximum l'imbrication des données et des méthodes qui travaillent sur ces données. On cherche à modéliser le métier au travers de design patterns adaptés (stratégie, spécification, composite...). A contrario, les services (un objet qui fait plutôt qu'un objet qui est) doivent être utilisés avec parcimonie.

Il en est de même avec ROA. Cette approche s'oppose en effet à un style Remote Procedure Call (RPC) à la façon de SOAP, Corba et les autres. La procédure fait quelque chose et je me permet de citer le livre :

A resource is something, so I take an object-oriented approach to designing resouces. In fact, the resource-oriented design strategy could be called "extreme object-oriented."

Ah ! Qu'ils sonnent bien à mes oreilles ces deux termes mariés ensemble (je vous avais dit que je parlerai de couples légendaires).

Avec une architecture orientée services (SOA), ce sont les procédures qui sont mises en avant et il est alors légitime de vouloir y associer une approche RPC comme les WS-* (manière de désigner les gros services web à base de WSDL et de SOAP, qui n'a de simple que le nom).

ROA et DDD se marient parfaitement pour mettre en avant les entités et les objets du domaine.

URI et identité

En DDD, on reconnaît une entité car elle est identifiable. Deux entités différentes auront des identités différentes. HTTP s'appuie sur le même type de concept : l'identifiant uniforme de ressource (URI). Chaque ressource est ainsi identifiée de manière unique.

Il est également très important de ne pas confondre la ressource et son identifiant, pratique malheureusement largement répandu qui consiste par exemple à mélanger joyeusement la référence d'un client et le client lui-même. L'URI découle de la modélisation d'une ressource, pas l'inverse.

Associations et connectivité

Pour naviguer dans un graphe d'objets complexe, DDD incite à modéliser les relations qui existent entre les entités via des associations. Les entités sont connectées comme dans un grand réseau, oserai-je dire toile ? Ça y est j'ai osé ! La connectivité est ce qui a permis au Web de devenir aussi riche et populaire. Sans lien, chaque ressource serait condamné à vivre sa vie isolée des ressources qui lui sont voisines. Là encore DDD et ROA sont vraiment similaires.

Conclusion

Je n'ai fait qu'effleurer le sujet et je suis sûr qu'on peut trouver beaucoup d'autres similitudes entre ROA et DDD. Ces deux approches sont, à mon avis, très similaires et complémentaires. Elles sont basées sur la modélisation de la complexité tout en restant très simple. En parlant de simplicité, je ne résiste pas à l'envie de recopier la citation en préface du livre sus-cité :

A complex system that works is invariably found to have evolved from a simple system that worked.
John Gall, Systematics

Sous ce titre douteux, j'aimerais faire un petit rappel des règles et usage concernant la dénomination des personnes.

Régulièrement, je me retrouve dans des situations où je constate que les règles typographiques, de bienséance et légales ne sont pas respectées. Régulièrement, il m'arrive de faire aimablement (ou pas) remarquer ces erreurs, voire de me battre pour les faire corriger. Malheureusement, quasi systématiquement, on me répond la phrase que vous avez tous entendu : « Ahhh...C'est l'informatique !!! »... Y en a marre !

Comme je suis vaguement bien placé pour le savoir, derrière l'informatique, il y a des...informaticiens. Et pas n'importe lesquels : des développeurs. Donc, chers camarades développeurs, c'est à vous que j'adresse cette supplique : arrêtez de vous assoir sur les règles du français !

Nom d'usage et nom de famille

Je vais d'emblée tordre le cou à une croyance tenace : sauf cas exceptionnel, une personne ne change jamais de nom.

Il existe des usages qui permettent de porter un autre nom que celui qui nous a été transmis à la naissance :

• une femme mariée a le droit d'utiliser le nom de son mari ou l'accoler au sien,
• une célébrité peut prendre un pseudonyme qu'elle utilisera au quotidien,
• dans d'autres cas plus marginaux ou que je ne connais pas.

Cependant, et malgré l'utilisation d'un nom d'usage, le nom de famille ne change jamais. Il existe deux types de nom :

• le nom de famille, celui qu'on a tous à la naissance,
• le nom d'usage.

Toute autre type de nom n'existe pas sur un plan juridique. Par exemple :

• nom de jeune fille
• nom patronymique

Le nom d'usage est un choix personnel et ne doit ni être imposé, ni être empêché. Pour l'anecdote, ma femme ne porte pas mon nom et je ne peux pas m'empêcher de vous relater cet échange surnaturel entre ma femme et une personne digne de François Pignon :

« - Vous êtes mariée ?
- Oui.
- Quel est le nom de votre mari ?
- Bézagu.
- Votre nom c'est donc Bézagu, c'est ça ?
- Non, c'est Grimaud.
- Ah, vous n'êtes pas mariée alors !
- ... »

Dans le bon ordre SVP

Lorsqu'il est utilisé, le prénom doit être placé avant le nom de famille ou d'usage.

Comme le terme l'indique le prénom vient avant le nom. Si des listes doivent être affichées dans l'ordre alphabétique des noms, cela ne pose pas de problème tant que cela n'a pas de répercussion sur des courriers qui pourraient par exemple être automatiquement générés.

Ne m'appelez plus Mister

Cette partie est la plus controversée et concerne l'usage de l'abréviation pour « Monsieur » « Mr » au lieu de « M. ». Comme le souligne l'article Wikipédia, la recommandation actuelle est bien d'utiliser uniquement « M. ».

Il convient donc d'écrire : « M. Jean Dupont ».

Majuscules et accents

Seules les premières lettres du prénom et du nom doivent être en lettres capitales (j'ai d'ailleurs appris cela en écrivant ce billet donc ne me hurlez pas dessus si j'ai fait la faute par le passé, je ne la ferai plus).

Si une ou plusieurs de ces lettres prend un accent en minuscule, celui-ci ne doit pas être perdu avec le passage en majuscule.

Exemple : Éric Épée

Cela vaut également pour le « C cédille » : ç donne Ç.

Conclusion

Comme le dit un collègue, je suis un peu le Jean-Pierre Coffe de l'informatique. Tant pis. Mais si nous tous, développeur, pouvions faire un effort pour respecter ces quelques règles, on verrait peut-être moins souvent des âneries devant nos écrans et dans nos boîtes aux lettres.

Voici une façon ludique de s'entraîner à TDD, technique pas forcément évidente au premier abord.

• Joueurs : 2
• Âge : 7 à 77 ans
• Genre : Collaboratif
• Matériel : un ordinateur, xUnit et un langage au choix

Dans les règles qui suivent le joueur le moins expérimenté sera appelé Kevin et le joueur ayant un peu plus d'expérience, Yoda.

Déroulement de la partie :

1. Kevin se fixe un objectif secret qu'il ne dévoile pas à Yoda,
2. Kevin écrit un test trés simple,
3. Yoda fait passer le test de la maniére la plus bête possible,
4. Kevin a alors le choix :
   • Il considère que son objectif est atteint et la partie est terminée,
   • Il complète son test avec une nouvelle assertion,
   • Il écrit un nouveau test.
5. Si la partie n'est pas terminée, on revient à l'étape 3.

Ce type de partie est très enrichissante et il n'y a ni vainqueur ni vaincu. Yoda veillera juste à calmer le jeu lorsqu'il sentira que Kevin commence à sérieusement s'énerver (ce qui ne manquera pas d'arriver) en lui rappelant que ce n'est qu'un jeu.

J'aime pô les "if"s !

L'Agile Tour 2009 passera par Bordeaux !

Je fais partie du comité d'organisation et j'essaierai de relayer les informations donc restez à l'écoute. Si vous avez des questions, des suggestions ou envie de mettre la main à la pâte, n'hésitez pas à me contacter.

J'adore Matrix - le premier particulièrement - et il m'arrive souvent de lâcher une réplique de ce film culte lorsque je travaille. En ce moment, je prépare une présentation sur XP et il y a tellement de répliques utilisables qu'il faut que je me retienne (je me contenterai d'un Je ne peux que vous montrer la porte. C'est à vous qu'il appartient de la franchir.:-D). Mon ami Michael semble être lui aussi friand de ce genre de référence.

Je ne résiste donc pas au plaisir de partager avec mes gentils lecteurs ces merveilleuses répliques qui peuvent - plus ou moins, parfois moins que plus je l'admet - être transposées à l'agilité.

• I know why you're here. I know what you've been doing. I know why you hardly sleep, why you live alone, and why night after night, you sit at your computer. You're looking for him. I know, because I was once looking for the same thing. And when he found me, he told me I wasn't really looking for him. I was looking for an answer. It's the question that drives us. It's the question that brought you here. You know the question, just as I did.

• You know that road. You know exactly where it ends. And I know that's not where you want to be.

• Unfortunately, no one can be told what The Matrix is. You have to see it for yourself.

• You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.

• You have to let it all go. Fear, doubt, and disbelief. Free your mind.

• I'm trying to free your mind. But I can only show you the door. You're the one that has to walk through it.

• Everybody falls the first time, right ?

• There is a difference between knowing the path and walking the path.

• You have to understand that most of these people are not ready to be unplugged. And many of them are so inert, so hopelessly dependent on the system that they will fight to protect it.

• Pay no attention to these hypocrites- to deny our own impulses is to deny the very thing that makes us human.

• Do not try to bend the spoon; that's impossible. Instead only try to realize the truth: There is no spoon.
  (s'applique plutôt à DDD, d'ailleurs je ne suis pas le seul à le penser : DDD: There Is No Database

• After nine years, you know what I realize? Ignorance is bliss.

• I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin.

Je suis en train d'apprendre à taper en dvorak. Késako ? Pour faire court, il s'agit d'une disposition de clavier plus adaptée que l'azerty. Une petite bande-dessinée explique tout ça très bien : DVzine.

Un wiki en français très complet m'a permis de réellement me lancer et j'ai choisi mon prochain clavier.

Quel rapport avec l'agilité ? Tout ! Et en particulier :

• Amélioration continue,
• Acceptation du changement,
• Qualité de vie.

PS : j'ai tapé ce billet en dvorak alors ne m'en voulez pas de ne pas être entré dans les détails :-D

Je me suis livré à une expérience naïve (ou pas) avec un projet sur lequel je travaille actuellement.

Et si j'essayais de supprimer tout ce que je peux sans faire passer un test au rouge ?

L'expérience interdite

J'ai donc fait une copie de mon projet et j'ai commencé mon labeur destructif. Je ne me suis donné qu'une limite : ne pas supprimer les pom.xml des projets. Hormis cela, j'avais quartier libre : le code Java, les annotations Spring MVC, les fichiers de configuration Hibernate, les pages JSP, les pages HTML, les images (très peu), le web.xml...

Environ deux heures plus tard, les tests claironnaient toujours que tout allait bien... Mais j'avais tout de même supprimé 248 fichiers (environ la moitié), 56% de la totalité du projet (en octets) étaient repartis dans le chaos électronique de mon PC et le projet dans son ensemble était aussi utile qu'un anorak dans le Sahara.

Motivations

Avant de tirer des conclusions sur ces résultats, je suppose qu'il faut que je revienne un peu sur les raisons qui m'ont poussé à faire cette expérience.

Tout d'abord, ce projet est né d'une volonté de montrer les bienfaits des pratiques d'Extreme Programming dans un contexte idéal et sans compromis. TDD est une des pierres angulaires de ces pratiques. Ecrire chaque test avant de coder permet d'éviter une dérive classique que tout développeur a déjà rencontré : le bazar ! Parce que les tests donnent le courage de changer la structure du code sans crainte d'introduire des régressions. Pour en revenir à mon projet, nous avons récemment souffert d'un bazar croissant dans la partie Web engendrant des bugs que les tests n'ont pas vu.

La deuxième raison, c'est que vendredi dernier, j'ai regardé cette vidéo de Bob Martin (dit Uncle Bob). Une claque. Une bonne claque qui remet sur le droit chemin en rappelant les règles de bases. Dont celle-ci : tout code écrit doit être justifié par un test rouge.

Digression sur les outils de couverture

A ce stade de mon billet, j'ai droit à ma sempiternelle digression. Que le lecteur qui souhaite passer son chemin ne s'en prive pas ;-)

Sur ce projet j'ai fait apparaître la couverture des tests grâce à un outil de mesure de couverture, en l'occurence Emma. La couverture mesurée par Emma sur chaque module du projet est affichée clairement dans Hudson : selon le module, la couverture du projet oscille entre 90 et 99% ! Etonnant, non ?

Pour tirer des informations valides d'un tel outil, un minimum de compréhension et de recul est requis. Pour mesurer la couverture, Emma "instrumente" le code en insérant des drapeaux qui sont levés lorsqu'un test passe par le code. Comment pourrait-il faire plus ? Un code peut donc avoir une excellente couverture sans qu'aucune assertion ne soit faite en sortie. Il est très facile de tricher avec ce genre d'outil.

Dernier point : Emma est bien sûr incapable de vérifier autre chose que du code Java et c'est en partie le drame.

La seule information valable à retirer d'une telle mesure est la suivante : les zones non couvertes ne le sont vraiment pas et les zones couvertes le sont peut-être.

Et maintenant ?

Soyons clair : la plus grosse partie de l'application que j'ai pu supprimer, c'est l'application Web. Sans le fichier web.xml déjà, un serveur d'application comme Tomcat ne peut plus rien faire. Ensuite, il y a le cas des pages JSP qui sont difficilement testables.

Mes question actuelles sont les suivantes :

• Peut-on avoir une démarche TDD pour vérifier la sortie correcte du HTML par le serveur d'application ?
• Tomcat, qui prend plusieurs secondes à démarrer, est-il adapté pour faire du TDD où les tests sont exécutés tout le temps ?
• Est-ce qu'en testant les sorties des pages Web et en simulant des envois de formulaire, on fait encore des tests unitaires et pas des tests d'intégration ?
• Est-ce que c'est important de distinguer test unitaire et test d'intégration ?

Je n'ai pas de réponse définitive à toutes ces questions et je serais très curieux d'avoir des retours d'expérience sur ces points.

Allez, pour finir, je ne résiste pas à l'envie de recopier un petit dicton glâné ici :

Si ça vaut la peine d'être construit, ça vaut la peine d'être testé.

Si ça ne vaut pas la peine d'être testé, alors pourquoi tu perds ton temps dessus ?

Alimenter mon blog avec des trucs de geek, vraiment, c'est n'importe quoi.

Mon jeu du moment ? Ecrire des expressions régulières pour refactorer mon code :-D Les possibilités de recherche/remplacement fournies avec Eclipse sont très puissantes. Pour preuve, voici mon dernier refactoring (quoique là franchement, je sais pas si on peut encore appeler ça un refactoring) :

Rechercher :

^.*new ([a-zA-Z]*Stat)((.*)\);$\n^.*setDate((.*)\).*$\n
^.*Repositories.stats\(\).add.*$\n

Remplacer par

\tRepositories.stats().add(new $1($2).withDate($3));\n

Le premier qui me donne un exemple avant/après gagne...pas grand chose parce que bon 1) j'ai rien à offrir et 2) faut vraiment se vanter de savoir lire ça ???

Tout d'abord, je souhaite ajouter un petit préambule à ce billet. Je travaille désormais dans une équipe agile et je peux désormais ouvertement afficher mon enthousiasme pour ces méthodes. Diable que c'est agréable !! Je sais également que certains de mes collègues lisent ou liront ce blog et je tiens tout de suite à les prévenir que toute ressemblance avec des personnes ou des situations existantes ne saurait être que fortuite. Bon peut-être pas tant que ça mais au moins, je tairai leurs noms ;-)

Bon, revenons à nos moutons. Ou plutôt venons-y. En ce moment c'est la simplicité qui m'inspire et comme j'aime bien ça, je trouve des analogies un peu partout.

Quand je regarde un joueur de tennis de très haut niveau, une danseuse étoile, un bon comédien, je ne vois absolument pas la difficulté de ce qu'ils font jusqu'à me dire parfois : "Mais c'est super simple, je peux le faire moi aussi". Pas vous ? Bien sûr, je sais que c'est totalement faux (il suffit de me voir sur un terrain de tennis par exemple) et que ce n'est pas parce que la difficulté ne se voit pas qu'elle n'existe pas.

Le seul but de cette simplicité apparente n'est pas de rendre les choses plus agréables à l'oeil du spectateur : elle sert l'efficacité. L'exemple le plus flagrant qui me vient à l'esprit est l'Aikido. Cette vidéo d'O'Sensei Morihei Ueshiba, que je me suis fait un plaisir de revoir en écrivant ce billet, est fabuleuse. On y voit un "vieillard" faire des gestes d'une simplicité extrême et envoyer ses partenaires à terre avec une facilité déconcertante. Ceux qui ont, comme moi, un peu pratiqué cet art martial le savent : cette simplicité n'est pas facile à atteindre et l'efficacité n'est pas "jouée" par les partenaires, elle est réelle.

Le but de mon propos devient finalement lui aussi simple à exprimer : il faut apprendre à désapprendre les gestes compliqués et inutiles qui nous embarrassent et qui nuisent à notre efficacité. Dans le monde de l'entreprise, je sais cependant que c'est difficile et que ceux qui brassent de l'air inutilement sont souvent récompensés à tort. Les gestes inutiles deviennent même parfois la "norme" à suivre sans qu'on sache pourquoi on les reproduit !

Après chaque séance de code avec mon binôme, je me pose souvent cette question de bilan dans le but de m'améliorer : "Est-ce que j'aurais pu faire plus simple, et donc plus efficace ?". Et je crois que je progresse, tout doucement.

Ma brute recrute des élèves !

Magnifique ! C'est le premier mot qui me vient à l'esprit lorsque je vois cette nouvelle API.

Cette bibliothèque permet de remplacer les fichiers XML de mapping NHibernate par du bon vieux code .NET. Les avantages sont clairs :

• Compilation du mapping, puisque c'est du code,
• Meilleure testabilité, puisque c'est du code,
• Refactoring assisté, puisque c'est du code.

Pour en savoir plus et voir quelques exemples de mapping :

• L'article sur InfoQ que j'ai découvert ce matin dans mon Google Reader,
• Le site du projet,
• Skinning the Cat with Fluent NHibernate, un exemple de mapping.

Un petit portage en Java serait parfait pour montrer à de nombreux développeurs qu'il n'y a pas que XML dans la vie ;-)

J'aime partager mes petits plaisirs. Le dernier en date est un tableau qui nous permet d'afficher les histoires utilisateurs (le nous en question n'est pas très important mais pour la petite histoire, il s'agit des personnes impliquées dans LE projet). Voici la bête :

Pour refaire la même chose à la maison, il vous faut :

• un tableau en tissu (une trentaine d'euros); les dimensions de celui-ci sont de 120 par 90.
• des fiches bristols 75x125 (un euro environ les 100)
• de l'auto-agrippant adhésif (plus connu sous le nom de Velcrow). J'insiste sur le côté adhésif sauf si vous êtes suffisamment joueur pour coudre du carton !

Il suffit ensuite de coller un petit morceau d'auto-agrippant au dos de chaque histoire :

(désolé pour la qualité de la photo mais je n'ai pas réussi à faire mieux)

En conclusion, pour une somme raisonnable, nous avons un système d'affichage des histoires super pratique car les histoires s'enlèvent et se remettent au tableau très facilement.

Le titre de ce billet est le titre de mon nouveau livre. Je viens de le recevoir ce soir et je ne résiste pas à faire partager à mes nombreux lecteurs (je m'emballe un peu là non ?!) mon plaisir de feuilleter un livre neuf, la douceur du papier, la qualité de l'impression.

A première vue, celui- est de bonne facture, les dessins agrémentant les chapitres très jolis (j'ai cru reconnaître ce cher Martin Fowler au coin du feu en train de raconter une histoire).

J'essaierai de faire un compte-rendu de ma lecture dans quelques temps.

Ne cherchez pas la faute dans le titre, il n'y en a pas. Il s'agit simplement de la définition étymologique du mot "forfait". Je l'ai découverte grâce à une interview donnée par Guillaume Bodet à la Web TV TV4IT.

Replaçons dans le contexte. Ma question existentielle du moment est la suivante : dans quel cadre contractuel peut-on réaliser un projet agile ? Et plus précisément : forfait et agilité sont-ils compatibles ? J'ai donc fait ma petite recherche google et, sans pousser très loin, je suis tombé sur cette interview très intéressante que je ne résiste pas à résumer ici.

Après avoir présenté les deux modes de réalisations que sont la régie et le forfait, Guillaume Bodet affirme qu'un projet agile ne peut en aucun cas être mené au forfait. Le forfait repose en effet sur un engagement de la part du fournisseur en terme de délai et de périmètre. Si le projet ne correspond pas ou déborde, des avenants sont signés pour gérer cet échec. Échec qui, au passage, est très prévisible dans ces conditions. Il y a donc une réticence au changement contraire aux principes de l'agilité.

En mode régie, au contraire, le fournisseur met en place une équipe facturée au jour le jour pour livrer, régulièrement et de manière itérative, un logiciel fonctionnel. L'une et l'autre des deux parties peuvent librement mettre fin au contrat.

Guillaume Bodet conclut par cette remarque qui m'a servit d'introduction : forfait vient du latin forsfaire qui signifie "faire du mal" ! Étonnant non ?

Pour ma part, j'avoue être séduit par cet argumentaire et je vais encore réfléchir et faire quelques recherches et lectures sur le sujet.