Build your own service bus – par ou commencer ?

Julien on nov 29th 2010

Quelle meilleure façon de réveiller ce blog que de parler de la dernière soirée Alt.net ? Soirée sur le thème de « Build your own service bus » et co-présentée par Romain Verdier et moi-même.

Comme faut pas pousser mémé, je me contenterai d’inclure les slides et je me concentrerai sur un point précis. D’autres personnes plus littéraires que moi auront probablement l'occasion de vous résumer la soirée ! :-)

 

Hey Julien, c’est marrant ton histoire, mais il est ou l’arrêt le plus proche pour monter dans ton bus?

Tout d’abord, il faut bien comprendre qu’un service bus n’est qu’un framework pour simplifier la communication dans un système distribué. Voici donc quelques idées à creuser pour assimiler les concepts…

 

1. Acquérir des notions de messaging

Je vous suggère notamment de regarder MSMQ (ou son pendant portable et open source : ActiveMQ) et RabbitMQ. Ce dernier à la particularité d’utiliser un broker (les queues sont donc distantes) tandis que MSMQ permet la communication point à point mais rend l’écriture de scénarios publish-subscribe plus complexe. Pourquoi ne pas développer un petit chat pour se faire la main ? Cet exercice vous forcera a explorer les différents modèles sur le PubSub ou encore à étudier un minimum la serialization (astuce : n’essayez pas de recoder un protocole de communication a base de commandes en texte comme le FTP, on peut faire plus sympa ! :-)) .

En bonus, je vous conseille vivement d’acheter ce livre pour noel :


Enterprise Integration Patterns
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

This book provides a consistent vocabulary and visual notation framework to describe large-scale integration solutions across many technologies. It also explores in detail the advantages and limitations of asynchronous messaging architectures. The authors present practical advice on designing code that connects an application to a messaging system, and provide extensive information to help you determine when to send a message, how to route it to the proper destination, and how to monitor the health of a messaging system. If you want to know how to manage, monitor, and maintain a messaging system once it is in use, get this book

 

2. Acquérir des notions d’architecture sur les systèmes distribués et la SOA

Comme expliqué plus haut, un service bus n’est qu’un framework. Avant de se lancer tête baissée, il faut comprendre les principes sous-jacents. Mon auteur préféré sur la question est Udi Dahan, l'homme derrière NServiceBus...
Udi étant un conférencier assez actif, il est facile de trouver nombre de ses présentations sur le net. En voici quelques une :

Et pour les plus curieux d'entre vous (disclaimer : on sort du cadre des service bus !) :

Enfin, si vous avez beaucoup de transport en commun, vous pouvez également trouver un paquet de podcasts :

 

3. Explorer les framework open sources

Et notamment leurs samples !

 

4. La méthode du Sioux !

Si vous ne connaissez rien a tout ça mais que vous déchirez quand même en développement, jetez un œil à notre dernière offre d'emploi et contactez-mois si ça vous intéresse ! On se fera un plaisir de partager avec vous tout ce qu'on sait ! :-)

Bon courage !

Filed in .NET,Alt.net,Command Query Responsibility Segregation,Rencontres Alt.net | Un commentaire

« Bounded contexts » et persistance

Julien on jan 18th 2010

Dans mon billet précédant, je faisais remarquer que la persistance pouvait être implémentée de différente façon au sein d'un même système dans le cadre d'une approche SOA/CQRS. Laissez moi clarifier ce que j'entends par cela (ou plutôt ce que j'ai appris du maitre, Udi Dahan !).

Il est possible de faire varier la persistance selon (au moins) 2 axes.

Tout d'abord, nous pouvons utiliser un ORM (Nhibernate, Entity Framework, etc) ou avoir une approche plus directe de type ado.net ou procédure stockée. L'idée ici est d'adapter la solution au contexte spécifique du cas d'utilisation.  Voici 2 exemples :

  • On souhaite mettre à jour l'ensemble des commande en cours d'un client pour changer le mode de livraison. Ce processus doit inspecter les commandes non traitées pour vérifier si le poids des colis est compatible avec le nouveau mode de livraison.
    => Ici, le processus de selection ést plus ou moins complexe ET le nombre de commandes en cours est probablement réduit. Un modèle objet est probablement adapté au traitement.
  • Notre système stocke des cours de bourse. Une société annonce un "split" (chaque action sera "coupée" en X de sorte que 1 action avant le split = X actions après le split. => Une société peut être amené à faire ce genre de choses quand elle estime qu'une action est devenue trop onéreuse). On souhaite appliquer le coefficient sur l'ensemble des cours stockés en base pour faciliter certains calculs. On a donc potentiellement des centaines ou des milliers de cours à mettre à jour.
    => Ici, utiliser un modèle objet n'a aucun sens. Une simple requête SQL du type "UPDATE quotes SET price = (price / X) WHERE ..." est clairement plus simple à mettre en œuvre et sera surtout beaucoup plus optimisée !

Peut importe la solution retenue, le plus important est d'assigner la responsabilité du schéma et la lecture/écriture à un seul et unique bounded context. Ce point est capital : il nous garantit de ne pas intégrer différents systèmes par l'intermédiaire d'un point central (la base de données relationnelles) qui sera :

  • difficile à faire évoluer, car couplé à l'ensemble du système
  • un point de défaillance unique
  • un goulot d'étranglement en terme de performances/montée en charge

Par conséquent, chaque bounded doit pouvoir faire évoluer sa persistance de façon transparente pour le reste du système, ce qui implique également que le support retenu peut être différent pour chaque cas (SQL, base objet, base de documents, fichier texte, etc).
Cependant, ce type de décisions sera fortement influencé par l'organisation interne du projet et la taille des équipes. Après tout, si chaque développeur choisit sa propre technologie, il sera difficile de coordoner le transfert de connaissance ou encore les backups. Il est donc tout à fait possible dans un premier temps de se limiter à un même support (ex : SQL Serveur) mais de séparer logiquement les bounded contexts en créeant des bases de données distinctes. Il faudra ensuite veiller à ce que les différents logins utilisé ait un accès limité à une seule et unique base.

Filed in Command Query Responsibility Segregation,Domain Driven Design | Un commentaire

« Command Query Responsibility Segregation » et « bounded contexts ».

Julien on jan 17th 2010

Je sors de mon sommeil pour aborder une question posée sur la mailing list française d'Alt.net qui me tient à coeur. Pour paraphraser, nous avons le cas d'un client qui devient privilégié sur un site de e-commerce, ce qui lui donne droit à une livraison expresse pour toutes ses commandes en cours. L'auteur de la question souhaite comprendre comment est réparti la logique (mise à jour du client / passage des commandes en cours à une livraison expresse) et pourquoi Udi Dahan considère que l'utilisation d'un modèle objet pour représenter le domaine est un détail d'implémentation dans le cadre d'une approche CQRS.

Voici mon interprétation après avoir assisté à la formation d'Udi sur le SOA :

Commençons par la répartition de la logique :

Dans cet exemple, notre commande "MakeCustomerPreferred" sera exécuté dans un bounded context (entendez "service") différent de celui qui gère les ventes en cours. "MakeCustomerPreferred" semble par exemple rattaché à un service de CRM ou de marketing. En conséquence, cette commande ne peut pas mettre à jour directement une entité du bounded context "ventes". Ce n'est pas sa responsabilité (pensez "loose coupling" !) et ce ne serait pas scalable. Une fois que "MakeCustomerPreferred" aura été exécuté, le message handler (l'unité qui va traiter une commande ou un évènement donné) pourra lever un évènement du type "CustomerBecamePreferred". Ce dernier pourra lui même être écouté par un autre bounded context, comme celui des ventes, qui pourra à son tours décider de mettre à jour son sous système en conséquence.

En ce qui concerne l'utilisation d'un modèle objet du domaine :

Quand on applique cette approche architecturale de façon globale, le choix d'utiliser un modèle objet ou une approche "transaction script" devient du cas par cas. Chaque message handler  étant indépendant, on est libre de choisir le meilleur outil pour chaque cas d'utilisation. Par exemple, si on ne fait que mettre à jour un champ d'une table : pas besoin d'ORM ! On pourrait tout à fait imaginer n'exécuter qu'une simple requête SQL de type UPDATE. Au contraire, si l'exécution d'une logique complexe fait parti du processus de mise à jour, alors il se peut qu'un modèle objet soit plus adéquat. (Et d'ailleurs, qui à dit que SQL était le système de persistance le plus adapté à notre cas d'utilisation? Tout dépend !)

Filed in Command Query Responsibility Segregation,Domain Driven Design | 5 commentaires

XP Day France, Jour 1

Julien on mai 25th 2009

Me voila de retour à la maison après une 1ère journée au XP Day (une conférence sur les méthodes agiles organisée par l'association eXtremme programming France) ; et autant dire que je suis ravi d'avoir fait le déplacement. D'autant que je ne savais pas trop à quoi m'attendre dans la mesure ou c'était la première fois que je venais.

J'ai donc assisté à 5 sessions aujourd'hui :

  • Introduction à Scrum
  • Retrospectives, la clef de l'amélioration continue
  • XP 2.0 : améliorer l'amélioration continue avec Lean
  • Product Owner, qui es-tu, que fais-tu?
  • Acquérir de l'expertise Lean

Soit 2 grands thèmes : Scrum (que l'on ne présente plus) et Lean qui est très "branché" ces temps-ci.

Globalement c'était très intéressant avec cependant quelques bas sur les sessions retrospectives (un peu trop récité) et Product Owner. J'ai malheureusement retrouvé sur cette derniètre un anti-pattern classique pour les présentations dont l'audience n'est pas débutante : on se perd dans les questions pointues, les speakers n'avancent pas au rythme prévu et du coup une bonne partie du message passe à la trappe !

Les sessions sur Lean étaient pour moi une vraie découverte. J'avais entendu parlé du terme plusieurs fois mais je n'appréhendais toujours pas les grands principes. Cette 1ère journée m'a permise d'en savoir un peu plus. Il est un peu tôt pour moi pour en parler en profondeur, mais j'ai eu l'impression que Lean et Agile agissent sur des axes différents ce qui est une sorte de mini-révélation à mon niveau :-).

Quelques mots également sur l'organisation : elle était tout bonnement parfaite vu le tarif de l'inscription. Le cadre etait très agréable (ok, il faisait un peu chaud mais ce n'est certainement pas la faute des organisateurs :-)), le timing était globalement respecté, on a eu le droit a de petits goodies sympas (planning cards, mug, chronomètre, ...) et le repas du midi était très bon (je ne savais même pas que c'était inclus!). Pour 230€, je dis chapeau bas messieurs !

A quand un évènement équivalent pour Alt.net?

Filed in Agilité | Un commentaire

Revue rapide du livre « Implementation Patterns »

Julien on mar 1st 2009

J'ai fini il y a quelques jours le dernier livre de Kent Beck : "Implementation patterns" publié à la fin de l'année 2007. Pour rappel, Kent Beck c'est l'homme derrière l'eXtreme Programming ou encore JUnit. Autant dire un gourou de l'industrie, duquel on attends énormément de ses livres et diverses publications.

Ce livre, c'est avant tout l'explication d'un terme qui ne m'était pas familier : "Implementation patterns". Concrètement, si les design pattern se focalisent sur l'interaction que plusieurs classent peuvent avoir pour fournir une fonctionnalité, les "patterns d'implémentation" agissent à un niveau plus bas : ce sont des recettes qui s'appliquent à chaque ligne de code et donc plusieurs dizaines de fois par jour. Par exemple, on parle de nomage, de décomposition en fonctions, de getters/setters, de choix de collections (Java...) et évidemment de pleins d'autres choses.

Le fait est que je suis vraiment resté sur ma faim avec ce livre... Certes il parle de plein de choses intéressantes, mais on éfleure à peine le sujet sans jamais avoir les tenants ou les aboutissants de tel ou tel conseil. Ce n'est d'ailleurs pas très surprenant quand on voit la taille du bouquin : 150 pages. J'ai l'impression que ce livre n'a pas trouvé son audience : trop abstrait pour un public de débutants, trop léger pour des développeurs plus expérimentés. Dommage Mr Beck !

"Implementation patterns" me rappelle d'ailleurs l'excellent livre de Steve McConnell : Code Complete. Si vous ne l'avez pas lu, n'hésitez plus ! Vous en retirerez bien plus.

Filed in Livres | Aucun commentaire

Alt.net : nouveau site !

Julien on mar 1st 2009

Alt.net FR possède désormais un nouveau site, mettez à jour vos favoris : www.altnetfr.org !

Filed in Alt.net | 4 commentaires

Rapidité VS Qualité

Julien on fév 8th 2009

On a trop souvent tendance à opposer rapidité de développement et qualité. Ces 2 caractéristiques ne sont en fait pas situées sur le même axe : faire diminuer la qualité n'implique pas une accélération du temps de développement. Bien au contraire.

Le raisonnement est généralement le suivant : il faut implémenter le plus rapidement une solution qui "fonctionne", pas besoin de faire quelque chose de spécialement brillant ou "beau techniquement". Malheureusement, c'est oublier une vérité fondamentale du développement logiciel :

Le coût total d'un projet est égal à la somme du coût de développement et du coût de maintenance.

Il se trouve que dans notre industrie, le coût de maintenance représente généralement plusieurs fois le coût de développement d'une solution. Chaque ligne de code sera lue plusieurs dizaines de fois après son écriture, chaque classe sera modifiée par plusieurs développeurs, des fonctionnalités devront être ajoutées dans chaque couche, sur chaque écran... La nature changeante des besoins des utilisateurs d'un produit font que ce dernier est systématiquement amené à évoluer.

Il est alors intéressant de pousser l'analyse un cran plus bas... En effet, un projet est lui même une suite de mini-projets qui, bout-à-bout, forment un tout cohérent et utilisable. Par exemple, pour implémenter une fonctionnalité on aura besoin d'aller préciser le besoin auprès du business, de réfléchir à l'implémentation, de réaliser l'implémentation, de tester la solution développée, ou de la documenter. Il faudra la débugger plusieurs fois et de la modifier pour faire face à de nouveaux besoins... Ces différentes étapes s'étalent dans le temps et peuvent impliquer une ou plusieurs personnes. Un projet peut donc être découpé en plusieurs dizaines ou centaines de mini-projets.

Or la définition du coût total d'un projet est aussi applicable pour l'ensemble de ces mini-projets. Autrement dit, chaque fois que la qualité est mise de coté dans un mini-projet, on augmente de façon significative le coût de maintenance pour ce dernier. Par conséquent, on augmente également la durée et le coût de développement pour le projet parent de manière générale (la maintenance d'un mini-projet faisant parti du coût de développement du projet parent). La vision court-termiste consistant à sacrifier la qualité sur l'hôtel de la rapidité de développement revient à se tirer une balle dans le pied.

Pour s'en convaincre, il suffit de prendre un exemple très simple :

Considérons un projet X constitué de 10 mini-projets. Dans un scénario idéal ou la qualité interne de mon projet reste élevée, chaque mini-projet nécessite un temps de développement de 3 (jours, mois, points, patates, peut importe :-)) et un temps de maintenance de 7. La durée totale du projet X est donc de 100.

Admettons maintenant qu'en sautant les étapes permettant de garder une qualité élevée, j'arrive à faire baisser le temps de développement initial de chaque mini-projet à 2. "Hourra ! Je viens de gagner 10 sur la durée totale, mon patron va me féliciter ! Mais? Mais? pourquoi mes développeurs ont de plus en plus de mal à modifier et debugger l'application? Damn it !" Mon coût de maintenance vient en fait de passer à 10 pour chaque mini-projet, soit un coût total de 120. On commence à comprendre pourquoi la plupart des projets informatiques sont en retard voir annulés...

Une fois que l'on est convaincu par cette analyse, il devient très simple de comprendre une autre vérité fondamentale du développement logiciel :

L'augmentation de la qualité interne d'une solution provoque une augmentation de la rapidité de développement.

Et non pas l'inverse !

Par conséquent, il est important de prendre le temps nécessaire pour refactoriser sa solution logicielle, sous peine de voir la dette technique exploser. Cet investissement est systématiquement bénéfique !

Edit : Scott bellware nous présente une excellente métaphore sur la qualité logicielle et pourquoi elle est primordiale. Je garde son exemple basé sur la colonne vertébrale en tête !

Filed in Gestion de projet | 3 commentaires

Comment détecter les copier-coller dans un projet?

Julien on jan 31st 2009

Parceque rare sont les équipes ou l'ensemble des développeurs applique le principe de ne jamais répéter du code (DRY!), il peut être utile d'avoir un petit outil sous la main pour détecter les éventuelles duplications au sein d'une solution.
En effet, tout code dupliqué pose des problèmes de maintenabilité accrus. Dans la majorité des cas on modifiera le code en question à un endroit, mais on oubliera systématiquement la copie qui se trouve ici ou là...

Simian
est un outil qui permet d'avoir rapidement un apperçu de l'étendu des dégats en un temps record (20 secondes pour 200 000 lignes de code). Il s'intégre directement dans visual studio en tant qu'"Outil externe" et sa configuration se fait en à peine 2 minutes.

Autrement dit, il suffit de suivre les instructions suivantes :

  1. Télécharger et installer Simian
  2. Dans Visual Studio, aller dans "Outils" => "Outils externe..."
  3. Cliquer sur "Ajouter"
  4. Utiliser les paramètres suivants (sans les guillemets) :Titre : "Simian - Solution" (modifier par ce que vous arrange)
    Commande : Chemin ou vous Simian est installé
    Arguments : "-formatter=vs -excludes=**/*.Designer.cs **/*.cs"
    Répertoire initial : "$(SolutionDir)"
  5. Répéter la même opération 2 fois avec les paramètres suivants :Titre : "Simian - Projet courant"
    Arguments : "-formatter=vs -includes=**/*.cs -excludes=**/*.Designer.cs $(ProjectDir)"
    Répertoire initial : "$(ProjectDir)"

    Titre : "Simian - Fichier courant"
    Arguments : "-formatter=vs $(ItemFileName) $(ItemExt)"
    Répertoire initial : "$(ItemDir)"

  6. Il n'y a plus qu'a aller dans le menu "Outils" pour lancer l'analyse!

A noter que vous pouvez double cliquer sur les lignes du résultat de l'analyse pour naviguer directement vers le code en question.

Filed in outils | Un commentaire

Sortie de la Release Candidate d’Asp.net MVC

Julien on jan 27th 2009

Je ne commente que très rarement les annonces faites ici et la sur Net... Pourtant, j'ai envie de faire une exception avec celle qui vient d'être publiée un peu plus tôt aujourd'hui par Scott Guthrie et Phil Haack : l'annonce de la RC d'Asp.net MVC.

Asp.net MVC est un produit à part chez Microsoft, c'est une ALTernative à une technologie bien connue sous la plateforme .Net : les Webforms. C'est surtout l'un des tout premiers efforts de Microsoft pour adhérer à une certaine façon de développer des logiciels. Entendez par là agilité, tests, DRY ou encore SOLID.

C'est aussi un autre regard sur la communauté : jamais auparavant un framework n'aura tant bénéficier des retours des utilisateurs. Pour s'en convaincre il suffit de voir les points d'extensions qui ont été ajoutés, les signatures qui ont été refactorisées pour éliminer les dépendances vers les briques non testables, ou encore les nouveaux helpers dans MVC Futures qui sont dérivés de projets open source comme MVC Contrib.

Mais enfin de compte, cette release candidate est avant toute chose une victoire. Une victoire pour tout ceux qui militent pour développer des logiciels autrement. Aujourd'hui tout ces gens ne sont plus marginaux sur la plateforme .Net, ils ont désormais le soutient de Microsoft!

Alors ce framework n'est pas parfait. Des ALTernatives très puissantes existent d'ailleurs sous d'autres plateformes (Ruby On Rails pour n'en citer qu'une). Sous .Net, nous avons depuis longtemps Monorail, qui est peut être d'ailleurs plus mature ou plus puissant, je n'ai pas d'avis sur la question. Le fait est que c'est un tel changement de paradigme au sein de cette communauté que l'on ne peut que se réjouir de cette annonce!

Longue vie à Asp.net MVC !

Filed in Asp.net MVC | Aucun commentaire

Découvrez Resharper!

Julien on déc 18th 2008

Resharper est pour moi l'outil le plus important en dehors de Visual Studio pour développer en .Net. C'est simple, je suis incapable de travailler sans, et la plupart des personnes que je connais qui l'utilisent sont dans le même cas. Je vous parle d'une productivité augmenté de plusieurs dizaines de pour cent pour les taches de développements! Et d'une qualité accrue pour la simple raison que l'on se permets de refactoriser le code en permanence comme l'opération devient indolore et peu couteuse. Pourtant, pour avoir rencontré un certain nombre d'éditeurs de logiciels récemment, je peux vous assurer que le taux de pénétration de cet add-in magique reste faible, trop faible.

Certes, parler de resharper ici revient à précher aux convaincus. Si vous lisez ce blog, il y a de fortes chances pour que vous soyez déjà utilisateur... Si ce n'est pas le cas, je vous invite non seulement à lire la suite mais surtout à essayer et faire essayer cet outil !

Resharper, ça sert à quoi ?

Resharper est un outil qui permet d'améliorer significativement la productivité des développeurs. Ses fonctionnalités couvrent les points suivants :

  • Refactoring
  • Analyse de code
  • Génération de code
  • Formatage de code
  • Navigation
  • Exécution des tests unitaires

Concrètement, Resharper vous permet de passer moins de temps sur l'accessoire et plus sur l'essentiel. Vous ne me croyez pas? voici quelques exemples de fonctionnalités (non exhaustif !):

Refactoring :

  • Créer une interface à partir d'une classe
  • Créer une méthode à partir du code sélectionné
  • Introduire un membre, une variable ou un paramètre à partir d'une expression
  • Changer la signature d'une méthode (par exemple, modifier l'ordre des paramètres)
  • Réécrire des expressions pour utiliser l'opérateur ??

Analyse de code :

  • Détecter toutes les erreurs de compilation dans la solution (sans compiler)
  • Détecter le code non utilisé dans la solution
  • Détecter les exceptions potentielles de type NullReferenceException
  • Suggestions sur les paramètres des fonctions. Par exemple utiliser un ICollection en paramètre plutôt qu'un IList si on n'utilise que des membres de ICollection dans le code de la fonction

Génération de code :

  • Générer les propriétés pour les membres sélectionnés (totalement configurable pour utiliser des propriétés automatiques ou non, des propriétés en lecture seule, etc.)
  • Générer un constructeur à partir des membres sélectionnés
  • Implémenter une interface en générant la structure des méthodes
  • Générer un membre (par exemple, après avoir tapé _foo = new Foo(); je peux générer _foo automatiquement avec un raccourci)
  • Générer une méthode (par exemple, après avoir tapé foo.Bar(); je peux générer la méthode Bar dans la classe Foo avec un raccourci)
  • Suggestion des using à ajouter au fur et à mesure que l'on écrit le code
  • Templates pour le code et les fichiers

Formatage de code :

  • Retirer les using inutile
  • Trier les membres d'une classe par visibilité (private, protected, internal, public)
  • Organiser la classe avec des régions de façon automatique

Navigation :

  • Trouver toutes les utilisations d'un symbole (Visual Studio le fait déjà mais très lentement par rapport à Resharper)
  • Surligner l'utilisation d'un symbole
  • Accès rapide aux fichiers, types et symboles en tapant leur nom ou initiales
  • Aller à la classe dont la classe courante hérite, à la classe fille.

Exécution des tests unitaires :

  • Exécuter le test spécifié
  • Exécuter tous les tests

Le plus simple pour se faire une idée concrète est encore de visionner les nombreux webcasts réalisés ici et la :

Vous pouvez également lire l'excellente série 31 days of Resharper.

Enfin, si vous téléchargez la démo, je vous conseille vivement de télécharger et d'imprimer la feuille résumant les raccourcis :

Toutes ces fonctionalités ont évidemment un prix, soit 315€ pour la version complète (c# + vb.net) ou 225€ pour la version C# seulement. Je peux vous assurer que c'est rentabilisé en 1 semaine !

P.S : Non, je n'ai pas d'actions chez Jetbrains, le créateur de Resharper :-)

Filed in outils | 12 commentaires