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

• Avoid a Failed SOA: Business & Autonomous Components to the Rescue
• Udi Dahan on SOA @ E-VAN 01 June 2009
• Udi Dahan presents on Reliability, Availability, and Scalability

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

• Command Query Responsibility Segregation

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

• Hanselminutes Podcast 176 - NServiceBus with Udi Dahan
• Herding Code 67: Udi Dahan on Scalability
• Deepfried Bytes : Getting the Right Message about NServiceBus with Udi Dahan

3. Explorer les framework open sources

Et notamment leurs samples !

• NServiceBus
• MassTransit
• Rhino Service Bus (GL HF comme on je disais dans le temps, parce que niveau documentation, Rhino Service Bus est limité !)

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 !

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.

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

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?

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.

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 !

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.

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 !

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 :

• Les démos officielles, notamment celle ci ou celle la
• Une démo faite par Los Techies. Tellement impressionnante que je l'inclue directement dans le billet :

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 :

• Avec le mapping Resharper (celui que j'utilise personnellement)
• Avec le mapping Visual Studio

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