ALT.NET Paris – Compte rendu Sonar

Posted by radwane.hassen under Comptes Rendus Paris, Paris

Le 19 octobre dernier dans les locaux  de Valtech a eu lieu une présentation Alt.net autour de Sonar par Alexandre Victoor et Mathias Kluba, tous deux contributeurs du portage de sonar dans le monde .NET.
Ils ont tenté, au cours de la soirée, de répondre à une problématique récurrente dans les projets d’entreprises : comment mesurer et suivre la qualité du code produit ?

Sonar constitue une réponse à cette problématique en permettant de mesurer de nombreux paramètres, de les prendre facilement en main en permettant une approche top/down et en produisant des synthèses adaptables suivant les différents profils des intervenants.
L’équipe doit d’abord définir ses propres mesures (en faisant si besoin appel à des outils externes) selon plusieurs critères qu’offrent Sonar :

• identification des duplications de code ;
• mesure du niveau de documentation ;
• respect des règles de programmation ;
• détection des bugs potentiels ;
• évaluation de la couverture de code par les tests unitaires ;
• analyse de la répartition de la complexité ;
• analyse du Design et de l’Architecture d’une application et en faire ressortir des métriques orientées objet.

Il est alors possible de rendre accessible un dashboard personnalisé permettant à tous les acteurs du projet de suivre la qualimétrie. Voici un example de dashboard :

La présentation a été enrichi par de nombreuses démos qui ont suscitées des débats intéressants, l’intégration future de nouveaux plugins (NDepend…), son utilisation avec une usine logicielle existante (TFS, Jenkins…).

Tous les participants ont pu constater l’efficacité d’un tel outils ainsi que la plus value potentielle, permettant, comme le soutien les méthodes agiles :

• d’avoir une idée de la qualité avant de livrer un Sprint en production ;
• d’accentuer le management visuel, en donnant des indicateurs matérialisable aux projets ;

Les cas d’utilisations peuvent être également variés ; audit, code review, suivi de projet (management par la qualité)… Mais le plus important d’entre tous est de mettre en place un suivi et un esprit d’amélioration continue.

Petit résumé de la rencontre Alt.net Paris « Build your own service bus »

Posted by Mathias Kluba under Comptes Rendus Paris

Pour ceux qui n’ont pas pu assister à la présentation « Build your own service bus », vous pouvez consulter la présentation en ligne ici:

Le format de présentation « Prezi » a vraiment eu le « Wow effect ». Je pense même que le fait d’imbriquer et regrouper les termes en fonction de leur catégorie et leur niveau de détail, rend cette présentation très compréhensible, même si elle est dépourvue de phrases ou de la piste son.

Mais pour vous aider à mieux la comprendre, voici un petit résumé de ce que j’en ai compris.

Act I.

Je ne sais pas si le « messaging » est quelque chose à la mode en ce moment, mais il est nécessaire pour une architecture asynchrone et distribuée.
C’est aussi peut-être pour cela qu’on en parle beaucoup en ce moment, puisque la « mode » du cloud nous pousse à réaliser une architecture distribuée, mettant en œuvre de nombreux services différents, et offrant de la « scalabilité » à la demande.

Chez ABC Arbitrage, le besoin est avant tout de découpler les systèmes, mais aussi de traiter un gros volume de données avec la possibilité de « scaler » au besoin.

Romain et Julien ont commencé à expliquer que le but de cette présentation n’est pas de vous convaincre d’utiliser le messaging, ni de vous vendre une solution en particulier, ni même de vous convaincre de re-inventer un ServiceBus comme ils l’ont fait.

Mais cette présentation est une bonne base sur la théorie des ServiceBus afin de vous permettre de mieux comprendre ceux existants, ou de connaitre les fondamentaux afin de réaliser le votre.

Au départ, ils nous ont expliqué brièvement ce qu’est le Messaging, ce qu’est un ServiceBus, et la différence qu’il y a avec les technologies de Messaging (bas niveau), les ESB et les EAI (très haut niveau).

Si vous cherchez « service bus » sur codeplex, vous en trouverez plein. Peut-être qu’il s’y cache une petite merveille, mais elle n’a pas percé pour le moment.
Parmi les plus « matures » et les plus connues, il y a:

• NServiceBus
• Masstransit
• Rhino ESB

S’ils sont venus à la conclusion d’inventer leur propre ServiceBus, c’est que ceux existants ne répondaient pas à leurs contraintes.

Le besoin de nos 2 acolytes était d’avoir quelque chose de simple, et qui ne dépendait pas d’une technologie de messaging en particulier (NServiceBus et Rhino ESB sont seulement compatible MSMQ « out of the box »).
D’ailleurs, aillant besoin de traiter des données en C++ sur des machines Linux, ils ont choisi la technologie Apache Qpid.
Ils ont alors développé un ServiceBus avec leur strict nécessaire en terme de fonctionnalité, avec une API nécessitant le moins de configuration possible (convention over configuration), avec une implémentation C# et une autre C++.

Act II.

C’est alors qu’on est entré dans le vif du sujet, et qu’ils ont commencé à nous expliquer plus en détails ce qui compose un ServiceBus, et comment est-ce qu’ils l’ont implémenté.

Les messages

Tout d’abord nous avons vu ce qu’est un Message, quels sont les types de messages possibles, de quoi est-ce qu’il est composé, etc.
Ils distinguent 2 catégories de messages:

• Les Commandes: Elles expriment une intention adressée à un destinataire unique qui se chargera de confirmer l’exécution, ce qui permet de simuler un appel « synchrone » comme en RPC
• Les Evénements: Ils informent 0 à n systèmes que quelque chose s’est passé (ou non !), sans attendre une quelconque confirmation de lecture.

Puis nous avons vu ce qui compose le message:

• un contrat
• une enveloppe
• une donnée sérialisée

Il existe de très nombreuses façons de sérialiser vos données, mais pour des raisons d’interopérabilité avec le C++, et de performances, le format « Protocol Buffers » a été choisi.

L’enveloppe quant à elle va contenir toute les méta-données spécifiques au Messaging, à savoir des adresses de destination, des informations de routing, etc.

Ceux qui les consomment: les MessageHandlers

Le chapitre suivant traite des « Handlers », c’est à dire, les composants du systèmes qui traitent les messages.
On voit donc ici rapidement comment déclencher un traitement à la réception d’un type de message donné.
Tout ceci avec une grande simplicité à l’aide des conventions.

Mais avant que le message soit envoyé/reçu, il peut être traité et enrichi dans la « Pipeline ».
C’est un peu comme de l’AOP, ou on va pouvoir traiter les aspects techniques transverses, spécifiques au Messaging, et donc enrichir l’entête du message ou d’effectuer un traitement particulier en fonction de celui-ci.
C’est alors qu’on peut choisir de chronométrer le temps de traitement d’un message, de le filtrer, ou de le router vers la bonne destination.

Les traitements long avec état: les Sagas

Cette dernière partie de la présentation traite du sujet sans doute le plus complexe, mais surtout le plus intéressant.
C’est en effet ici qu’on nous a expliqué comment effectuer des traitements avec état, de dérouler un Workflow en orchestrant l’envoi et la réception de certains messages.
La Saga est donc un Handler particulier qui effectue cela, et elle doit donc être créée suite à un message de début de traitement, et persisté afin de reprendre son traitement là ou elle en était suite à la réception d’autres messages.
Cela veut dire aussi que les messages sont alors identifiés à l’aide d’un « Correlation ID », afin de savoir quelle instance du Workflow faut-il reprendre.

Cela pose aussi d’autres problèmes, puisqu’il se peut que la Saga envoie une « Commande » pour effectuer un traitement, mais ce dernier pouvant échouer, la Saga ne recevra jamais de message de retour.
Il faut alors gérer les « Timeouts », pour passer le Workflow état « terminé ».

Cela est très bien expliqué dans la présentation, avec de magnifiques diagrammes de séquences.

Démo

Pour terminer, nous avions eu droit à une superbe démo d’une application de trading (WPF?) avec une courbe de prix d’une action (fictive) en temps réel.
Dans la démonstration, nous pouvions effectuer un achat d’un certain nombre d’actions à un prix désiré, l’application publie alors l’ordre dans le système, qui va effectuer l’achat si l’offre correspondante est trouvée.
On peut alors y voir une Saga qui s’occupe d’effectuer les achats par « paquet » afin de ne pas faire trop grimper le cour de l’action. Si le prix désiré n’est pas trouvé au bout d’un certain temps, et qu’il n’a pas été possible d’acheter le nombre d’actions voulu, nous avons alors la un bel exemple de gestion du Timeout.

Conclusion

Ma conclusion personnelle est que le Messaging est vraiment nécessaire aujourd’hui, car nous sommes de plus en plus dans des contextes distribués.
Réaliser un ServiceBus n’est pas si simple: il y a beaucoup de concepts, et même ABC Arbitrage a fait le choix de ne pas tous les implémenter.
Mais la complexité des certaines solutions existantes, et l’immaturité des autres, nous poussent souvent à la même conclusion: « Build your own Service Bus ».

Sans forcement vouloir inventer la solution parfaite, c’est en tout cas un très bon exercice, cela nous permet d’en apprendre plus sur le sujet, et nous préparer ainsi à des solutions plus complexes.

J’espère que cette petite présentation vous a plu, et que ça vous a encourager à assister à nos futures sessions d’ALT.Net !

Pour terminer, voici quelques liens utiles (en plus de ceux déjà présent dans l’article):

• http://blog.phatboyg.com/ le blog du créateur de Masstransit, aussi membre d’ALT.Net
• http://www.udidahan.com/ bien évidement le blog d’Udi Dahan, créateur de NServiceBus
• http://ayende.com/Blog/category/554.aspx le Blog d’Ayende autour de Rhino ESB. Très intéressant puisqu’il décortique NServiceBus et MassTransit afin de réaliser le sien
• http://distributedpodcast.com/ Si vous avez besoin de comprendre le Messaging et le ServiceBus, je vous conseil absolument d’écouter ces podcasts

ALT.NET #16 : WindDBG, compte rendu par Romain Verdier

Posted by romain under Comptes Rendus Paris

La dernière rencontre ALT.NET avait lieu chez Winwise. Yann Schwartz nous présentait une session (pleine de joie, rappelons-le) au sujet d’un outil méconnu et surpuissant : Windbg. En fait, il s’agissait surtout de voir comment tirer partie de Windbg pour débugger des applications managées ; après tout, c’est ALT.NET. Il y avait une bonne dizaine de personnes (ndYann : c’est faux, on était au moins une bonne douzaine) — les meilleurs d’entre tous –, et ce fut diablement intéressant : instructif, utile, pointu et digeste.

Par contre, Yann ne sait pas coder :

for(int i=0; i< 100000000; i++)
{
   if(!list.Contains(Guid.NewGuid().ToString()))
      list.Add(Guid.NewGuid().ToString());
}

Il faut probablement avoir une maladie mentale pour écrire ça ! C’est en tout cas ce que j’ai pensé sur le coup, en pouffant sur ma chaise (j’étais au fond de la salle). Ensuite, je ne sais plus si je l’ai compris de moi même ou si Yann a dû le préciser d’un air atterré, mais il avait fait exprès d’écrire ça. Parce que d’autres ne font pas exprès, et que ça pose des problèmes.

Windbg est un outil permettant de débugger des applications Windows, ou carrément Windows. Et ouais ! On l’utilise généralement en s’attachant à un processus, ou en analysant un dump existant. Il devient alors possible d’obtenir tout un tas d’informations utiles (sans jeu de mot) : on peut se balader dans la pile d’exécution, inspecter les threads, la mémoire, etc. tout en restant très peu intrusif ; windbg est en effet un outil léger de très bas niveau. C’est particulièrement utile lorsqu’on cherche à savoir d’où provient un problème sur une application qui tourne dans un environnement où il est impossible d’utiliser de profilers, d’outils de développement, et autres moyens de petits joueurs. Si vous voulez débugger une application ASP.NET déployée sur IIS en production, par exemple, quelques droits, une clé usb et windbg suffisent. Amenez quand même votre cerveau, on ne sait jamais.

On peut donc voir ce qui se passe au coeur d’une application native, mais il existe une extension à Windbg, sos, qui offre nombre de fonctionnalités propres à l’inspection et au debug des programmes .NET. Cette extension est elle-même étendue par un autre outil non-officiel, sosex, toujours spécifique à .NET, qui fait gagner +2 en force, +3 en magie et rend accessibles de nouvelles commandes intéressantes.

On a bien senti que Yann voulait rester pratique pour cette présentation, et on l’en remercie. Il s’agissait d’une démo continue et argumentée, en quelque sorte, qui avait pour but de montrer comment trouver et résoudre certains types de bugs à l’aide des outils appropriés. Il ne s’agissait pas d’une présentation qui avait pour but de montrer comment utiliser certains outils à l’aide de bugs appropriés. En fait, il est apparu assez clairement que dans 90% des cas, quelques commandes de sos et/ou de sosex pouvaient suffire à sécher les larmes des sales programmeurs que nous sommes.

Exemples :

• !DumpHeap -stat : Liste toutes les instances du tas, regroupées par type et triées par taille totale.
• !Threads : Liste les threads de l’application.
• !SyncBlk : Liste les blocs de synchronisation, pris ou attendus par les threads de l’application.
• !GCRoot addr : Affiche qui référence l’instance spécifiée et empêche donc sa collecte par le GC.
• !dlk : (commande Sosex) : Trouve automatiquement les deadlocks.
• !refs addr : (commande Sosex) : Affiche le graphe des références d’une instance, i.e. qui la référence, et qui elle référence.
• Etc.

Pour peu que l’on ait une petite idée de ce qu’on recherche, il devient généralement possible de remonter jusqu’à la source des problèmes en enchainant ces commandes. Les problèmes les plus classiques ainsi que les traitements préconisés ont été classés dans 12 catégories par le Dr Schwartz.

Le docteur Schwartz attend que son assistant l’aide à enfiler ses gants.

Les fuites mémoires

• Symptôme : Votre application se comporte correctement, mais consomme (sans raison valable) de plus en plus de mémoire, sans faire mine de vouloir en rendre, ne serait-ce qu’un peu de temps en temps.
• Cause courante du mal : Ressources non-managées que l’on oublie de disposer, références oubliées qui empêchent la collecte de certaines instances, etc.
• Localiser la tumeur : (pseudo-méthode) On lance la commande !DumpHeap -stat pour trouver (en regardant la taille totale occupée par les instances d’un type) quels sont les celles qui sont susceptibles de consommer abusivement la mémoire : il s’agit souvent de tableaux de bytes (buffers, images) ou de strings. On exécute ensuite la commande !DumpHeap avec le paramètre -mt pour afficher la liste détaillée des adresses d’instances d’un type donné. A partir de là, il est souvent possible de retrouver quel(s) objet(s) les maintiennent en vie et qui est responsable des instanciations à l’aide de la commande !GCRoot [adresse].

Les deadlocks

• Symptômes : L’application se bloque, ne répond plus, mais ne consomme pas de CPU.
• Cause courante du mal : Plusieurs threads s’interbloquent, en s’attendant mutuellement. C’est pas bien. Il parait que ça s’appelle aussi une étreinte fatale. (?)
• Localiser la tumeur : On utilise la commande !dlk de sosex ! Il est également possible de s’en sortir en utilisant !SyncBlk, !DumpObj [adresse] et !DumpStackObjects.

Les freezes gourmands

• Symptômes : Là encore, il se peut que l’application continue à fonctionner, mais en se bloquant anormalement longtemps à certains moments, monopolisant complètement les ressources CPU à la disposition du processus.
• Cause courante du mal : Boucles infinies, ou presque, recherches linéaires dans des boucles, sérialisation stakhanoviste, etc.
• Localiser la tumeur : !runaway pour trouver le thread le plus gourmand, ~[nb]s pour passer au thread impétrant numéro [nb], puis !ClrStack pour avoir la pile d’appels pour ce thread.

Ah oui, au fait, il y avait un plan, dans cette présentation. Je viens de parler de la première partie, mais il en avait une seconde.

Avec Windbg & Co. On se rend bien compte qu’il faut souvent commencer comme si on voulait pécher la baleine, pour reserrer petit à petit les mailles du filet et trouver finalement la source du/des problème(s). Cette analyse suit certains patterns assez simples à identifier ; on aimerait donc pouvoir automatiser un peu cette inspection, notamment lorsqu’on travaille sur des dumps énormes ou que l’on cherche à identifier de façon systématique les risques potentiels d’un système, par exemple.

C’est donc sur cette problématique que s’est penché Yann pour la seconde partie de la présentation. La transition n’a pas été oubliée et nous avons eu droit en guise d’interlude à un petit worst-of des langages de programmation qui font saigner les yeux : APL, J, Brainfuck, et, évidemment, le langage de script de windbg. Car s’il existe effectivement quelques moyens d’utiliser windbg programmatiquement, c’est la misère. La première solution consiste à utiliser le langage de script de windbg (ORLY?). La seconde, à passer par Powerdbg, une extension de PowerShell qui communique avec Windbg via TCP (ce dernier peut en effet passer en mode « server »). C’est mieux, mais toujours pas très sexy. Et on aime ce qui est sexy, nous, pas vrai ?

Justement ! Le dernière solution, celle de Yann, est sexy. Ca s’appelle Linqdbg, et c’est comme son nom l’indique du Linq-to-Windbg. Utilisé dans une REPL — Yann utilisait LinqPad pour sa démo — ça permet enfin de chasser le deadlock sans se tordre de douleur. C’est un projet sympa, qui pourrait rapidement séduire ceux qui n’ont pas le courage de windébéger classiquement, ou qui veulent scripter leurs analyses sans apprendre la syntaxe du 3ème langage le plus compliqué du monde (le ROI n’est pas forcément évident). Au niveau technique, Yann vous en parlera probablement mieux que moi sur son blog, mais en deux mots, il s’agit d’un provider Linq qui interagit avec Windbg via TCP, à l’instar de Powerdbg, et qui encapsule les commandes les plus courantes.

Exemple de requêtes :


var instances = from i in Linqdbg.HeapStats()
                where i.Type.IsAssignableFrom(typeof(Toto))
                orderby i.TotalSize desc
                select i;


var leaked = from i in instances
             select i.GCRoot();

C’est malin, et c’est open source : bravo Yann. Si vous parlez C#, c’est un moyen élégant d’analyser finement un programme : on bénéficie de la puissance divine du framework .NET.

En conclusion, la session était vraiment plus intéressante que ce compte-rendu. Je dirais même plus : les pauvres blagues de ce compte rendu sont là pour vous faire oublier qu’il ne sert à rien. Je vous invite donc à jeter un coup d’oeil aux slides de la présentation et à cliquer sur ces quelques liens si vous avez envie d’en apprendre plus au sujet de ce sombre outil :

• Debugging tools for windows
• Sos
• Sosex
• CommandTree pour Windbg
• Article de Yann Schwartz sur Linqdbg : (très bientôt sur I am a vocoder )
• Powerdbg, ou windbg via PowerShell
• Blog de Tess Fernandez, alpiniste microsoft.
• Blog de John Robbins, débogueur émérite
• Article de Sami Jaber sur les fuites et windbg

Merci à Yann pour sa relecture attentive, et son remplissage de trous.

Alt.net paris #14: compte rendu AOP

Posted by jb under Comptes Rendus Paris

La dernière présentation du groupe s’est déroulée mercredi dernier, dans une salle mise à disposition par FastConnect, et c’était Romain qui officiait.

L’AOP étant un sujet qui me tient à cœur, et ayant traversé la France (presque) pour l’occasion, autant dire que j’avais quelques attentes quant à cette session.

Résumons pour les pressés : c’était bien, il va falloir revenir. Pour les moins pressés, détaillons le déroulement de cette dernière soirée alt.net à Paris.

Romain étant un des membres originels d’alt.net à Paris, il était temps qu’il monte sur scène pour nous parler d’un sujet qui visiblement lui tient à cœur, la programmation orientée aspect. Les intéressés peuvent consulter son blog, qui contient quelques articles dédiés à cette pratique.

Un rapide sondage nous a montré que si beaucoup de personnes avaient déjà entendu parler d’AOP, peu savaient vraiment de quoi il en retournait, et encore moins utilisaient de l’AOP pour des applications en production.

La présentation s’est déroulée autour de quatre points, ainsi que des démonstrations.

Le problème que tente de résoudre l’AOP.

Si l’OOP nous permet de résoudre élégamment une multitude de problèmes, force est de constater que dans certains cas, les moyens mis à disposition dans les langages OOP mainstream ne permettent pas de complètement isoler certaines responsabilités. Et même en refactorant au plus fin le code, on retrouve quand même des méthodes qui vont mélanger certaines responsabilités.

Romain donne l’exemple typique est celui du logging. On est intéressé par logger le comportement d’une couche applicative, mais avec les moyens standards de l’OOP, on finit par mélanger à un moment ou à un autre le code applicatif, et le code du logging.

C’est une problématique que l’on retrouve dans plusieurs cas. On pourrait citer la persistance des données, la sécurité, les transactions, l’internationalisation par exemple. Ce sont souvent des contraintes techniques. Le terme de fonctionnalité transverse est évoqué pour désigner ces cas.

Ce sont ces problèmes que tentent de résoudre l’AOP, en fournissant au développeur des moyens d’isoler ces différentes fonctionnalités.

Les concepts de l’AOP.

Tout comme l’OOP, l’AOP à son propre jargon. Romain a ainsi décrit les termes spécifiques suivants:

• Aspect: Fonctionnalité transverse.
• Advice: Le code de l’aspect.
• Joinpoint: Point de jonction d’un aspect, c’est l’endroit logique où va venir se greffer l’aspect. Des exemples de joinpoint : entrée ou sortie de méthode, lecture ou écriture d’un champ, levée d’une exception, instantiation d’un object.
• Pointcut: Ensemble de joinpoint appliqués à un programme. Par exemple, l’ensemble des méthodes de la classe Foo.
• Weaver (tisseur): En l’absence de support de l’AOP au niveau du langage, c’est l’outil qui va tisser les advices aux pointcuts (et ouais).

Les techniques mises en oeuvre dans l’AOP.

Romain s’est ensuite attaché à expliquer les différents moyens de décrire les joinpoints et les pointcuts, en utilisant par exemple :

• Un langage particulier, à la AspectJ.
• Des méta-données, ou des annotations, quand la plateforme le permet.
• Des fichiers de configuration, que ce soit du XML, des DSL, ou autre fichier plat.
• Le code lui même, au travers d’une API spécifique au tisseur.

Puis il a décrit les différentes techniques de tissage:

• Statique, ou le tissage est réalisé avant l’exécution. Le tisseur peut opérer au niveau du code, ou au niveau du bytecode dans le cas de .net. On peut même imaginer interagir directement avec le compilateur, c’est possible dans le cas de boo par exemple.
• Dynamique, ou le tissage des aspects est réalisé pendant l’exécution. En .net on utilisera l’infrastructure de remoting, des dynamic proxies, ou encore des techniques plus évoluées comme l’API de profiling de la CLR.
• Hybride, qui utilise une combinaison des deux. Typiquement, l’infrastructure est tissée aux pointcuts, et les aspects y sont injectés à l’exécution.

Les outils .NET.

Malgré le fait qu’il existe des dizaines d’outils disponibles, Romain souligne le fait que très peu sont réellement utilisés dans des applications en production.

Pour ce qui est du tissage dynamique, outre la couche de remoting intégrée nativement au framework .net, il cite en particulier la fameuse librairie Castle.DynamicProxy pour faire de l’AOP dynamique, mais aussi LinFu.DynamicProxy, qui fait ici office d’outsider.

Détail intéressant, Romain a ensuite montré une relation entre les conteneurs IOC et l’AOP. Comme Spring.NET par exemple. En effet, les conteneurs IOC font souvent appel à des frameworks d’AOP pour résoudre leurs problématiques d’injection et d’interception. On évitera juste d’assimiler l’IOC à l’AOP, ce dernier couvrant potentiellement bien plus de besoins que les conteneurs IOC ne peuvent couvrir.

Du côté de l’AOP statique, il cite LinFu.Aop, encore assez jeune, mais surtout PostSharp, qui est à ce jour le framework (commercial cependant) le plus complet et le plus riche en terme de tissage statique.

Il nous a ensuite fait des démos de ces différents outils et techniques.

Conclusion

Une grosse session donc, avec une des plus fortes participations du groupe. La présentation haute en couleur du pince sans rire Romain a permis de lancer un débat qui s’est continué autour du buffet fourni par FastConnect. Et c’est ce qui continue de faire l’intérêt de ces sessions.

Les slides de cette session:

Alt.net Paris #13 : compte-rendu de l’Open Space

Posted by Julien under Comptes Rendus Paris

Le compte rendu de la dernière session d’Alt.net Paris ne serait complet sans dire quelques mots sur la 2ème partie de soirée. En effet, la session de Sebastien étant terminée (Vincent nous détaille les principaux enseignements dans le billet précédent), nous avons décidé de faire un mini Open Space…

Open Space? Vous avez dit Open Space?

L’Open Space est une réunion auto-organisée ou les participants définissent et prioritisent eux même les ordres du jour. Le site Open Space World en fait la définition suivante :

Au Forum Ouvert, les participants créent et gèrent eux-mêmes un ordre du jour (agenda) comprenant divers groupes de travail, en séances simultanées, ayant un thème commun, d’importance stratégique, comme par exemple: «quelle doit-être la stratégie pour le groupe, organisation ou communauté que toutes les parties puissent supporter et développer en travaillant ensemble.»

Et concrètement?

Après une brève explication du concept aux présents, nous avons donné à chacun la possibilité de proposer un ou plusieurs sujets à discuter. Chaque participant à ensuite eu l’opportunité de voter pour ses 2 sujets préférés, en déposant une pastille sur le tableau. Les votes ont fait ressortir les 4 sujets suivants :

• Comment introduire Nhibernate dans un projet
• IoC et applications legacy
• TDD
• Développement asynchrone et messaging

Nous nous sommes alors réparti en 2 groupes pour aborder les 2 premiers sujets pendant environ 45 minutes, puis nous avons répété le processus pour les 2 suivants.

En conclusion

Ce format de discussion nous aura permis d’explorer des sujets passionnants, de faire participer aux débats tous les présents et de s’axer sur des retours d’expériences concrets, tout en fournissant un cadre totalement informel et détendu (Merci à Octo pour la salle, les boissons et les petits-fours !). Seul regret : il y avait tellement de sujets que nous souhaitions aborder et si peu de temps Vivement les prochaines réunions pour vider le backlog !

Alt.net Paris #13 : Adaptive Object Modeling, compte-rendu par Vincent B.

Posted by vincent under Comptes Rendus Paris

Contexte

Malgré un changement d’horaire tardif, la communauté à une fois de plus répondu
présent à l’appel avec environ 15 à 20 personnes présentes. La présentation était
animé par Sébastien Ros de la société Evaluant.

Systèmes Adaptables

Tout le monde en fait mais personne ne le sait

Un système adaptable permet de répondre à différentes problématiques :

• Les règles métiers peuvent changer fréquemment
• Cycles de développement, test, déploiement couteux
• Réutiliser la même application mais adapter le domaine à chaque utilisation

Pour cela le système doit s’adapter au domaine manipulé et non l’inverse. Le domaine devient alors une variable de configuration de l’application, il est décrit. On ne va plus directement décrire chaque entités du domaine dans une classe, mais créer un modèle objet qui va permettre de décrire ce domaine, on parle alors de meta modèle. Le domaine peut alors être « instancié » via une description fournie par l’utilisateur ou l’expert métier et pour chaque nouvelle application, on fournit une nouvelle configuration (le modèle métier). Le système pourra interpréter cette nouvelle configuration directement pendant l’exécution (modification en temps réel)

Techniques d’implémentation

L’implémentation de cette architecture adaptable est souvent composée de petit design pattern comme le pattern TypeObject ou encore le pattern Strategy.

TypeObject

Ce pattern permet de définir dynamiquement de nouvelles entité pour le système. TypeObject est utilisée pour séparer une Entité de son Type (Entity et EntityType). Les entités ont des attributs, qui sont mise en œuvre avec le pattern Property. TypeObject est réutilisé dans un deuxième temps en vue de définir les types d’attributs, appelés AttributeTypes. Dans les langages orientés objet la structure d’un programme est créé via un ensemble de classes. Une classe définit généralement la structure et le comportement de l’objet. Et donc généralement nous avons une par entité à représenter. Pour introduire une nouvelle entité il faut alors créer une nouvelle classe, c’est-à-dire programmer.

Property

Une propriété est généralement définie par une variable dans une classe. Puisque nous n’avons pas de classe spécifique à un type ici, on va utiliser une liste qui contiendra tous les propriétés du type.

Dans cet exemple, on utilise une classe property qui définit trois attributs : name, type et value. Pour que le modèle soit encore plus adaptable, il suffit de ré-appliquer le pattern TypeObject pour les propriétés. On va alors obtenir un nouveau pattern connu sous le nom de TypeSquare

Relation

Il ne reste plus qu’à rajouter une relation supplémentaire entre EntityType et Entity pour obtenir le modèle ERA : Entités, Relations, Attributs

Comportements

Les comportements c’est un peu plus compliquer à généraliser autant que des entités, je ne vais donc pas développer autant, cependant deux solutions existent :

Pattern Strategy

On va ce pattern strategy avec un peu d’IOC pour faire un système de plugin. Malheureusement, il va bien falloir mettre les mains dans le code.

Pattern RuleObject

Ce pattern répond à la problématique précédente, on va ici pouvoir « composer » les règles avec divers opérateurs et faire des tests sur des valeurs de propriétés. Plutôt qu’un long discourt voici le diagramme final :

Interpréteur

L’interpréteur est le cœur du système , c’est lui qui va charger toutes les métadonnées et si possible de façon dynamique, c’est-à-dire qu’une modification soit appliquée en direct.

What’s next ?

Microsoft Oslo, avec la création de DSL graphiques et textuels.

On peut aussi ce demander si ce type de modèle sera toujours d’actualité avec le retour en force des langages dynamiques et la fameuse DLR

Conclusion

Pour moi la meilleur représentation de ce type de système, c’est Sharepoint avec ses Content type, ses types de listes. Mais attention à vouloir faire du tout générique on arrive rapidement dans des usines à gaz, le plus dur c’est de bien placer le curseur entre le trop Spécifique et le tout générique. Finalement c’est à vous de créer votre modèle adaptable en fonction de vos besoins.

Ressources et liens

• http://adaptiveobjectmodel.com/ (diagrammes)
• http://grozeille.com/2009/05/24/alt-net-adaptive-object-modeling/ Compte rendu par Mathias Kluba

ALT.NET Paris #12 : Entity Framework, compte-rendu par Farid LAOUFI

Posted by farid under Comptes Rendus Paris

Première bougie d’ALT.NET Paris

Tout d’abord, avant de parler du contenu de cette session ALT.NET, je me dois de signaler que notre groupe vient de fêter sa première année, comme l’a indiqué Julien. Donc merci à lui, ainsi qu’à Robert !

Contexte

Entre vingt-cinq et trente personnes étaient présentes à cette rencontre, animée par Mathieu MEZIL. Il a parlé de son sujet de prédilection : Entity Framework. Ce n’est pas pour rien qu’il est MVP sur cette technologie Si vous souhaitez en savoir plus sur Entity Framework, je vous conseille vivement la lecture de son blog, qui est une vraie mine d’or sur le sujet. En voici l’adresse : http://blogs.developpeur.org/matthieu/default.aspx.

Avant que commence la présentation, chaque participant s’est brièvement présenté et a indiqué les raisons de sa venue. Beaucoup avaient pour objectif de se faire une idée de la technologie; de plus, à peu près tout le monde a déjà utilisé un outil de mapping objet/relationnel « maison » ou un produit tel que NHibernate.

Fondamentaux d’Entity Framework

Après une petite introduction sur ce qu’est Entity Framework, Mathieu nous a montré un schéma de Julia LERMAN résumant assez bien les possibilités de l’outil, puis nous a dit qu’il aimait beaucoup ce dernier… Au cas où quelqu’un n’aurait pas compris le message, il a enlevé son pull pour que tout le monde puisse admirer son beau tee-shirt « I love EDM ». Très émouvant

Plus sérieusement, Mathieu nous a indiqué que des providers Entity Framework pour les principales bases de données devraient être actuellement disponibles, il n’a pu le confirmer avec certitude que pour SQL Server (le contraire eut été surprenant ), Oracle et MySQL. Il nous a également précisé que Microsoft est vraiment en train d’investir à fond sur Entity Framework (environ 150 personnes affectées à ce projet chez Redmond !), et ce dans l’optique de proposer une solution unifiée concernant les problématiques d’accès aux données et de mapping objet/relationnel. Quid de LINQ To SQL ? Eh bien c’est très simple : d’après Mathieu les quelques personnes encore affectées à ce projet ne font qu’écrire des assistants permettant de porter un existant LINQ To SQL vers Entity Framework. Je vous laisse tirer les conclusions qui s’imposent…

Scénarios de mappings

L’un des points forts d’Entity Framework est de permettre une très grande souplesse dans le mapping entre les données présentes en base et les entités définies dans du code .NET. Voici quelques-uns de ces scénarios.

Simple

Similaire à ce qui est propose dans LINQ To SQL : une table est mappée à une entité.

Vertical splitting

Scénario dans lequel une relation 1-1 existe entre deux tables, Entity Framework autorise un mapping de ces deux tables sur une unique entité.

Inheritance

Application des principes de la programmation orientée objet au mapping objet/relationnel (par exemple l’héritage).

Entity Framework, concrètement

Tout d’abord, il faut partir du principe qu’il est possible avec Entity Framework de donner différentes perspectives d’une même donnée présente en base : il est donc envisageable (et recommandé) de créer plusieurs modèles Entity Framework qui sauront mieux s’adapter à certains besoins.

Un modèle Entity Framework est constitué de trois briques distinctes :

• Le SSDL, décrivant tout ou partie de la base de données
• Le CSDL, décrivant les entités
• Le MSL, décrivant le mapping entre les objets de la base de données et les entités

Sans rentrer dans les détails, ces trois parties se modélisent dans un fichier au format XML, ce qui rappelle ce qui se fait pour NHibernate, à une exception près : pour un modèle Entity Framework donné, toutes les informations le décrivant doivent être contenues dans un même fichier XML, ce qui peut s’avérer gênant si deux développeurs ont à le modifier simultanément… Ce point sera corrigé dans la version 2 d’Entity Framework. Ceci étant dit, il y a quand même quelques points positifs à souligner Les voici :

• L’intégration dans Visual Studio, avec la présence d’un designer, même s’il n’intègre pas certaines fonctionnalités « avancées » d’Entity Framework.
• Encore l’intégration dans Visual Studio, permettant la génération automatique du code C# correspondant
• Dans le code C# généré, les classes représentant les entités sont prêtes pour être utilisées dans des scénarii WCF
• Toujours dans le code C# généré, les classes sont partielles, ce qui permet de les étendre sans risque de perdre ses modifications.

Lorsqu’un modèle Entity Framework a été défini, il est possible de l’utiliser via un objet ObjectContext. Un tel objet a généralement une portée définie via un bloc using dans lequel plusieurs opérations pourront être effectuées sur le modèle, puis finalement sur la base de données, le tout de manière transactionnelle. Un objet ObjectContext gère également un cache qui peut être paramétré finement, assimilable au cache de premier niveau de NHibernate. Un cache de second niveau (utile pour certaines données tels que des listes de pays, … qui n’évoluent quasiment jamais) sera disponible dans la prochaine version d’Entity Framework.

Dans la portée d’un objet ObjectContext, il est bien entendu possible d’effectuer des requêtes. Le plus simple consiste à utiliser LINQ : chaque type d’entité est exposé comme une collection, avec du coup des possibilités de jointures, de filtrages, de tris, … En complément de LINQ, Entity Framework met à disposition une syntaxe pseudo SQL nommée ESQL, permettant de requêter non pas la base de données (tout du moins pas directement), mais plutôt le modèle Entity Framework. A noter qu’il est tout à fait possible de combiner, au sein d’une même requête, les capacités de LINQ et d’ESQL, ce qui laisse envisager des perspectives intéressantes pour traiter nos données.

Mathieu nous a également montré une méthode permettant de combiner Entity Framework avec ADO.NET Data Services.

Un dernier point avant de conclure : les entités peuvent être des POCO avec la version 1 d’Entity Framework, pour cela il faut mettre en œuvre un projet disponible sur MSDN Gallery. L’aspect POCO sera nativement en charge à partir de la prochaine version d’Entity Framework.

Conclusion

Cette présentation fut très intéressante, d’un très bon niveau (maintenant je sais vraiment ce qu’est Entity Framework), et le présentateur maîtrisait parfaitement son sujet (même si on a dû se relayer pour lui apporter des verres d’eau ). Comme d’habitude (c’était ma troisième participation à une rencontre ALT.NET), les questions, remarques et polémiques ont fusé…

Alt.Net Paris #11 : TDD, compte rendu par Clément Bouillier

Posted by clement under Comptes Rendus Paris

Cette session Alt.Net regroupait de nouveau une trentaine de participants autour de Djamel et Frédéric qui nous présentaient le développement piloté par les tests (TDD, Test Driven Development). Les participants avaient majoritairement une coloration TDD, mais nous avions nos « avocats du diable » forts utiles pour alimenter la discussion comme d’habitude (Alt.NET serait bien triste sans cela).

La discussion a commencé par une question classique mais logique : pourquoi des tests ou pourquoi pas ? Au premier abord, la réponse amène beaucoup de « stéréotypes » (cher, long, utilité…), des points qui peuvent au demeurant être légitimes dans certains cas particuliers (ce sujet n’a pas été traité plus avant). Mais la réponse apporte surtout une bonne introduction à la pratique.

La suite consista à faire les premiers pas en répondant aux questions : quand tester et comment s’y prendre ? Pour aboutir à des points fondamentaux pas forcément évidents au premier abord : le TDD ce n’est pas qu’écrire des tests unitaires, mais c’est une pratique par laquelle, pour bien faire, il sera nécessaire de faire usage d’un ensemble de bonnes pratiques.

Pourquoi ne pas faire des tests ?

En faisant un rapide sondage de l’audience, nous avons mis en évidence que de nombreuses objections sont couramment mises en avant : « c’est trop cher », « ça prend trop de temps », « je les ferais plus tard » (= jamais comme souligné dans la presentation), « comment m’assurer que mes tests vérifient ce qui est spécifié et pas une fausse interprétation » (intention du développeur VS besoin du client), « ce n’est pas faisable dans mon cas », « qu’est-ce que je teste », « mon code va changer, je le testerai quand il sera stable »…

L’idée de la session était de contredire certains de ces points, de démontrer les forces de la pratique, mais pas forcément de batailler contre des avis tranchés sur la question. Pour cela, un exemple simple a été utilisé : implémenter un MasterMind.

Quand tester ?

Comme cela a été dit plusieurs fois, l’objectif des tests n’est pas d’avoir des indicateurs de couverture maximaux mais d’avoir un code correspondant le plus à ce que le développeur s’attend à avoir, i.e. son intention donc et non malheureusement le besoin client, l’interprétation de celui-ci ne pouvant être cadré par le TDD…il n’y a pas de magie.

La question qui en découle est : qu’est-ce qui doit être testé ? Il n’est pas nécessaire de tester du code sans intérêt particulier du point de vue de sa complexité (il sera toujours temps d’ajouter des tests s’il se complexifie). De même qu’elle est granularité des tests, est-ce que je parle de tests unitaires, de tests d’intégration, de tests fonctionnels…mais ce point est un sujet un peu plus avancé qui fut traité rapidement.

Les tests se révèlent également un outil puissant dans le cas des changements inéluctables d’une application (liés au changement du besoin ou à des remaniements du code), en fournissant une « base de connaissance » pour la non-régression.

La question du temps passé aujourd’hui en debugging répétitif et autres applications consoles satellites peu réutilisables a aussi été soulevée. Pourquoi ne pas considérer que ce temps est un temps qu’il vaut mieux consacrer à des tests réutilisables i.e. automatisables et rapides. Cela n’exclue pas le debugging mais en réduit notablement les excès et même apporte une base permettant un debugging plus aisé (en debuggant les tests).
Ce sujet a été un point de controverse assez discuté pendant la session : est-ce que je sais ce que je veux a priori (ce qui me permet de démarrer mes premiers tests) ou est-ce le fait de coder qui révèle l’intention ? Je dirais après réflexion que la réponse est les deux. Mais le point soulevé est que la seconde sans la première revient à tomber dans le travers de s’attaquer au cas le plus complexe, à « se perdre » dans la conception du design miracle et des algorithmes traitant tous les cas, et cela rejoins un second point : lorsqu’on agit ainsi, on risque inévitablement d’introduire des bugs au fur et à mesure de la complexification du code née de notre cerveau de codeur/concepteur tout puissant (un peu mégalo… ). Tant qu’on n’en a pas tout va bien, le jour où cela arrive c’est la chute libre : aucun filet pour se rattraper…

Comment s’y prendre ?

L’approche TDD demande donc un peu d’humilité en commençant par des tests simples (au développeur de bien évaluer la simplicité minimale, dans l’exemple donné, on était forcément un peu caricatural, mais l’idée était là). On part donc d’une intention simple a priori fondée. Par la suite, on complexifie de manière incrémentale en écrivant le test qui révèle l’intention à chaque étape (analogie avec l’alpiniste qui à pose un mousqueton régulièrement, nécessite également de réaliser un check in à chaque état stable de nos développement). On développe donc l’intention en développant, mais en développant les tests d’abord.
L’avantage est également de mettre à jour l’approche utilisée et de documenter le code produit explicitement (notion de spécifications exécutables).
Ceci a été démontré par Frédéric via leur exemple relativement simple, et c’est un point assez crucial du TDD à mon sens.

Un autre point a été soulevé : il n’est pas contradictoire d’esquisser quelques diagrammes UML afin de cadrer notre intention globale, mais il serait contradictoire d’être dans une démarche « pure MDA », structurant et contraignant le design en premier lieu sans passer par les tests.

Ce dernier point démontre l’intérêt de commencer par les tests, ils doivent nous forcer à ne pas aller trop vite et à découper notre travail. Je pense sincèrement que c’est également un argument par rapport au temps et au coût lié au TDD, nous perdons régulièrement du temps à vouloir concevoir/développer trop compliqué.

Dans l’exemple du MasterMind, plusieurs points essentiels liés à l’application du TDD sont ressortis de la discussion (formulation assez proche de la présentation) :

• La démarche est un cercle vertueux : intention > code du test (ne compile pas) > code qui ne fonctionne pas (test rouge) > code qui fonctionne (test vert) > remaniement (refactoring) pour répondre à une intention plus complexe
• En découle qu’il faut commencer par des cas simples Vs penser aux cas les plus complexes, le cercle vertueux nous amenant aux plus complexes
• Un test doit être bien écrit = AAA : Acteur + Action + Assertions (attention aux tests sans assertions !!)
• Ne pas faire un modèle trop complexe, laisser l’évolution des intentions guider le remaniement du code pour aboutir au modèle le plus juste (et pas forcément le plus générique, le plus beau…ce qui rappelle le principe YAGNI).
• Le remaniement à une étape donnée doit se faire soit sur les tests, soit sur le code de production, l’un servant de filet de sécurité à l’autre.
• Un bug doit systématiquement amener à écrire un test vérifiant la correction (approche la mieux adaptée au legacy code).
• Jouer l’ensemble des tests (automatiques et rapides afin de ne pas perdre de temps)

Quelques remarques connexes ont vu le jour également. Notamment est-ce que TDD est contradictoire avec la programmation par contrats? Ou plutôt complémentaire? C’est plutôt la seconde proposition qui retenait l’attention.

TDD est une pratique englobant beaucoup de pratiques

Le principal point est que le TDD nécessite rapidement de s’intéresser à des pratiques de design courantes et considérées comme bonnes qu’il n’est pas toujours facile de mettre en place sans cette approche.
Le débat fut animé sur la question pendant la session. Mon avis étant qu’il y a beaucoup de développeurs expérimentés, « experts » et autres personnes aux titres élogieux – surtout dans la communauté .NET – et qui n’ont pas la moindre idée de toutes ces bonnes pratiques. Elles les balayent systématiquement et orgueilleusement en les sacrifiant sur l’autel de la performance ou de la productivité (NDJ : enfin… c’est ce qu’elles pensent!), et ce évidemment au détriment de la maintenabilité…

Ainsi, Frédéric et Djamel nous ont parlé de couplage faible à l’aide d’injection de dépendance (voir Fowler) permettant de faciliter les tests unitaires, de différents patterns notamment pour WPF : M-V-VM et les Converter, ou encore des plus classiques (GoF) comme l’Abstract Factory (fabrique abstraite en français/québécois)… Tout cela permet de faciliter grandement l’approche des tests et devrait être utilisé afin de bénéficier pleinement des bénéfices de la pratique.

Via les exemples WPF, on a pu voir un peu les limites du TDD au niveau du test de l’interface, bien que l’intérêt du pattern M-V-VM permette de s’en accommoder tout en structurant avantageusement son code. Des solutions existent tout de même, j’ai rapidement vu White…à creuser.

On peut parler du bouchonnage ou Mock/Stub (voir Fowler pour la différence Mocks/Stubs). L’idée étant d’utiliser de faux objets dans les graphes de dépendances de l’objet testé afin de limiter les effets de bord liés à ces dépendances par rapport à l’intention testée.

Enfin, deux sujets dont on aurait pu parler plus profondément (mais le sujet était déjà assez touffu) : l’intégration continue qui pouvait être entraperçu dans les mots souvent répétés comme « outillage » ou « automatisation », et la couverture de code qui a été abordée rapidement. Je rajouterais sur ce dernier sujet qu’il est très important de garder en tête que ces métriques (comme toutes les autres) sont à prendre avec des pincettes, ne surtout pas croire que 100% de couverture = code parfait. Il est important de toujours garder en tête les problématiques liées à la combinatoire des données d’entrée à nos tests qui restreint ce point de vue.

Conclusion

Pour résumer, je reprendrais celle de la présentation de Djamel et Frédéric (que l’audience a remerciée sincèrement de cette présentation de qualité et du dialogue établi).

Le TDD est :

• pas forcément plus cher ou plus long à mettre en oeuvre,
• applicable (presque) dans tous les cas

Le TDD apporte :

• Un code mieux documenté
• La possibilité de modifier sans risque (non-régression)
• Un code au design le plus juste et flexible (dans un contexte de changement permanent inhérent aux sujets traités dans les projets informatiques)

A noter que TDD est une pratique qui se marie très bien au DDD présenté à Alt.NET France en décembre (cf. Eric Evans et/ou Jimmy Nilson, je n’ai lu que le 2nd).

Références

Un document de 70 pages fort intéressant reprenant beaucoup d’éléments discutés lors de la rencontre : Foundation of programming

Greg Young sur Design by Contracts et TDD à l’USI2009 (à voir pour les chanceux )

Livres sur DDD intégrant l’approche TDD : Domain-Driven Design, Eric Evans et Applying Domain Driven Design and Patterns, Jimmy Nilson

Enfin un grand merci à Octo pour nous avoir accueilli et pour cette présentation…tout le monde trouvera le site d’Octo, faisons un peu de pub pour l’USI2009 où on pourra retrouver Greg et Frédéric notamment.

Rq : Frédéric, pourrais-tu nous donner le lien vers la présentation de Greg Young sur TDD que tu as vivement recommandée…(recherche rapide sans succès…), ainsi qu’un lien vers les slides éventuellement ?

ALT.Net FR #10′ : Débat MVC, compte rendu par Vincent B.

Posted by vincent under Comptes Rendus Paris

Préparations

C’est hier jeudi que notre petit débat sur MVC avait lieu. Nous nous sommes donc retrouvé à environ une bonne vingtaine de personnes dans le 8ème arrondissement, avec pas mal de nouvelles têtes.
Pour un sujet qui n’occupait que 4, 5 personnes au début sur les discussions google, il a finalement fait déplacer des foules (plus grosse réunion depuis les débuts de Alt.net France). Il nous à fallut revoir la disposition de la salle, avec plus de chaises pour ainsi former un grand cercle. La séance c’est déroulée sans projecteur et n’a malheureusement pas pu être enregistrée.

Le débat :

Introduction au MVC ?

Après une rapide présentation de chacun des participants, et un rappel par Julien, de l’esprit Alt.net, j’ai commencé en posant quelques questions d’ordre général pour permettre de mieux cibler les différents niveaux avec Asp.net MVC :

• A peine une dizaine de personnes ont déjà utilisé MVC, et la majorité d’entre eux ont commencé le développement web il y a assez longtemps (au moins avec du php/asp). La grande partie des personnes restantes était venues pour découvrir ou chercher un peu plus que la brève introduction des Techdays.
• Justement combien ont assisté à la séance des TechDays ? 5 à 6 personnes donc pas énormément de monde. Apparemment cette présentation aux TechDays n’a convaincue personne et les retours ne sont pas glorieux.
• Combien on déjà fait du WebForm ? Une bonne majorité environ 15 personnes (ouf ! )

Nous proposons donc à Gauthier, qui a le plus d’expérience avec ce Design (compte tenu de l’absence de Symon), de refaire un récapitulatif du fonctionnement :

- M : Model => entités métier, couche de service (WCF, etc.)
- V : View => l’interface utilisateur
- C : Controller => le point d’entrée unique qui décide quel modèle utiliser et dans quel vue.

Julien complète ces explications par un schéma d’interaction entre ces différents tiers :
CMV serait donc le nom le plus approprié en fait. Une Action du Controller est appelée grâce au nouveau module de Routing d’asp.net (une Action est par défaut une méthode public du controller). Cette méthode va récuperer les données de façon classique via vos services d’acces aux données puis les passer à la vue. Pour finir la méthode demande le rendu de la vue désirée.

Pourquoi MVC ?

Alors que notre introduction aura pris un quart d’heure. La question de « pourquoi MVC ?» est rapidement venue sur le tapis. Un petit groupe (les dev Web) essayait de justifier l’utilisation de ce Design face au design WebForm d’asp.net. Je ne vais pas refaire le débat ici mais un avantage vu par quelqu’un pouvait être considéré comme un inconvénient pour un autre. Voici une petite liste des points évoqués (à vous de vous faire votre opinion)

• Gestion de l’état (viewstate)
• Postback
• Le cycle de vie
• Le debug
• Les tests
• Le html et js
• Les contrôles

Conclusion :

Je vais reprendre le compte rendu de Robert pour conclure :

J’ai trouvez que le débat hier jeudi était très passionnant, mais un peu trop focalisé sûr l’aspect WebForms contre MVC (un débat un peu « troll » selon quelqu’un dont je ne dit pas le nom). Pour ma part, comme quelqu’un qui a jamais fait du ASP.NET MVC (ou autre MVC), mais qui a fait du ASP classique et WebForms, j’ai trouvé les arguments du côté MVC bon, mais je ne suis pas complètement convaincu. J’étais absolument d’accord avec la déclaration « on peut faire un logiciel merdique avec des WebForms et l’MVC », en revanche je pense qu’on peut faire un bon logiciel en utilisant MVC ou WebForms (je trouve que Subtext est un très bon « codebase », même si c’est en WebForms).
J’étais un peu déçu que l’on n’ai pas parlé des view engines. Je cois que je arriverais à facilement comprendre les couches en C# sur le serveur, mais que les rendu du HTML risque de rapidement devenir bordelique. Même si l’HTML n’est pas un sujet très dure à comprendre je cois que ce n’est pas facile d’avoir une bonne organisation du code pour générer du HTML.

J’étais étonné de voir au tant de monde, comme on a tout organisé à la dernière minute. J’étais un peu déçu qu’on n’ait pas vu Yann qui a animé notre forum.

Il serait peut être bon de refaire une vraie réunion, avec présentation, pour rentrer dans la technique avec de bonnes démos, à vous de nous dire !

ALT.Net FR #10 : Aspectize, compte rendu par Gauthier

Posted by gauthier under Comptes Rendus Paris

Je me livre ici à l’exercice d’un compte rendu sur le site alt.net fr (merci Julien!), ici le compte rendu de la présentation du produit innovant par certains aspects (hum): Aspectize

le produit en deux mots

• un outil visant à apporter certains des atouts d’une bonne architecture au projets rad, du moins de le rendre d’avantage possible
• vendu comme un outil permettant « de montrer un résultat dès le premier jour sans compromettre l’architecture »
• le but est de fixer des invariants dans la manière d’implémenter les applications (binding, tiering, validation, exceptions), de réduire le code au code métier

la mise en oeuvre générale

• définition du modèle relationel et de ses attributs (emplacement de stockage, validation) à l’aide d’un outil visuel intégré à visual studio (à la DSL tools)
• durant l’écriture des services métiers l’accès aux données de ce modèle est réalisé à l’aide d’un datamapper (ou manager je ne sais plus) chargeant les entités et relations dans un objet opaque (un dataset pour la controverse)
• création de l’ui avec les outils RAD, l’ui n’aura cependant aucun code de gestion des evenements
• utilisation du binding studio (application standalone) pour effectuer le wiring entre le modèle, les services et l’ui, nous n’avons vu que windowsform le concept étant d’introspecter les composants graphiques et de lier les attributs de ceux-ci avec le modèle relationnel précédement défini, ce wiring est donc effectué au runtime en suivant ces méta données, il a été discuté de quelques possibilités avancées en terme de stubs, de proxying
• profit!

trade-offs

l’outil peut avoir une empreinte importante sur certains aspects, quelques points me venant à l’esprit sont:

• usage de types intégraux seulement (ou dataset non typé) pour les binding ui – service
• cette limitation peut rendre nécéssaire le wrapping sous forme de facades plus procédurales qu’idéalement
• nécéssité de se fondre au moule / à la triade ‘donnée-traitement-affichage’ intégré au framework
• débats sur la « versionabilité » des modifications effectuées dans le modèle / binding studio
• débats sur la nécéssité d’exécuter pour vérifier qu’il n’y à pas d’erreur de (selon moi, les mêmes erreurs se retrouvent dans le code, en inversant deux paramètres, mauvaise méthode ou je ne sais quoi, souvent à cause de l’autocompletion!!!)
• les mêmes trade-off de n’importe quel outil RAD orienté GUI
• beaucoup de clics, de popups
• beaucoup trop de clics, de popups
• le produit devra trouver une audience favorable auprès de plusieurs acteurs pour que son potentiel puisse croître

trade-ins?

sans vouloir confirmer leur existance sans mise en oeuvre, les arguments qui pourraient attirer l’attention des managers/commerciaux, (ces points sont à peu de choses près cités)

• travailler des le premier jour et montrer un résultat sans compromettre des décision technique de déploiement ni réécrire « la démo » pour en faire quelquechose de « production » / « maintenable »
• le paradigme « donnée-traitement-affichage » est compréhensible par tous (contrairement à « l’objet » décrié par les concepteurs du produit) donc plus simple a développer/maintenir
• ce middleware ne dépend « que » du framework .net / visual studio et offre un moyen/modèle de conception intégré

un mot sur la réunion dans l’ensemble

• sans dire qu’il s’agissait d’une « non-présentation » étant donné l’ardeur du public, au final, nous n’avons pas pus voir la présentation du produit entière car chaque particularité à été vivement discutée il reste encore beaucoup a découvrir pour se faire une idée plus fine du produit…
• le produit est issue du travail de deux concepteurs passionés (et concernés), ils ont « bootstrapé » leur propre outil, ont chacuns un track record imposant sur les technologies microsoft…

au final, la réunion était comme à l’habitude trop courte pour avoir le temps d’en finir avec les(ses) questions, de rencontrer tout le monde.

Avec l’affluence croissante les sujets pour les prochaines réunions ont également fusés, c’est en cours de discussion.

N’hésitez pas à laisser vos commentaires / trackbacks concernant la présentation et à en discuter sur le groupe, à exercer un droit de réponse envers mes propos déformés, invalides, injustes envers le produit.