DotNet

WSCF 0.5 : schema-based contract-first modelling

Mathieu Szablowski — Sun, 10 Jul 2005 00:03:00 GMT

WSCF est un outil de ThinkTecture permettant une autre approche de la conception de services.

Si Visual Studio se base sur le code que vous avez écrit pour concevoir un contrat, l'approche de WSCF est inverse et permet de génrérer le contrat à partir d'un modèle (basé sur un fichier XSD).

Il suffit donc de décrire son domaine à l'aide du designer de Visual Studio. WSCF se charge de la création d'un WSDL.
Un petit exemple:

On passe un petit coup d'assistant pour obtenir le WSDL:

Et on obtient un joli WiiiiizDeul:

Mais ce n'est pas tout car maintenant, il nous faut demander à générer le squelette du code :

Le code est ensuite généré, à la fois les contrôleurs et les types du domaine. Vous pouvez en trouver deux exemples, ici et ici.

Un outil bien sympa en somme, totalement intégré à Visual Studio et qui devrait permettre à nos services d'être plus accessible à d'autres plate-formes grâce à une approche orientée contrat.

Ingo Rammer : Optimization for Dummies

Mathieu Szablowski — Thu, 07 Jul 2005 22:52:00 GMT

Session Optimizing Scalability, Performance and Availability With Systems Built on the .NET Framework

Avec un titre aussi long, on était en droit de s'attendre à un exhaustif contenu. L'architecte de ThinkTecture a tenu ses promesses et nous a développé une présentation orientée vers la pratique. En trois points, basés sur des cas concrets, Ingo nous a apporté un peu de son expérience en matière d'analyse, de correction ou d'optimisation.

Premier point Analyse Réseau

Dans cette première partie, il fût question d'analyse de réseau, de sniffing à l'aide d'EtheReal nous permettant de cibler une erreur d'implémentation dans un BackService.

Deuxieme point SQL

Après avoir clairement annoncé que l'ensemble de cette démonstration ne pourrait qu'irriter certains développeurs de la partie Accès aux données du Framework .net, Ingo a clairement mit en évidence les faiblesses du DataSet tel qu'il est présenté dans de nombreux supports et l'importance d'un outil comme le SQL Profiler de SQL Server 2000.

Troisième point Mémoire

S'en est suivit une présentation de CLR Profiler 2.0 permettant de mettre en évidence les mêmes faiblesses du DataSet (décidement...) par rapport à une implémentation personnelle de certaines fonctionnalités d'accès aux données.

NB: Ingo a d'ailleurs rappellé que le Dataset était une excellente fonctionnalité du Framework, dans le cadre d'une application nécessitant un accès en mode déconnecté aux données.

En conclusion, en 1h15, la facilité dont Ingo a analysé et optimisé son application donne envie de revoir, comparé, testé différentes implémentations. Surtout au vue des résultats obtenus ;)

La mauvaise réputation

Mathieu Szablowski — Mon, 09 May 2005 22:38:00 GMT

En pleine lecture de ce merveilleux ouvrage qu'est UML 2 et les Designs Patterns de Craig Larman, j'ai eu le souffle coupé.

En effet, en pleine présentation du Pattern GRASP contrôleur, celui-ci prend à parti, vous, moi et tout développeur asp.net digne de ce nom :

"Il est également possible d'appliquer une méthode de délégation similaire avec .NET et WebForms : le fichier de code behind qui contient le gestionnaire d'évènements pour les clics sur les boutons du navigatuer Web obtiendra une référence à un objet contrôleur du domaine, puis lui déléguera la requête. Cette technique contraste avec le style fragile habituel de la programmation ASP.NET dans lequel les développeurs insèrent la logique applicative dans le fichier de code-behind, mélangeant ainsi la logique applicative et la couche présentation."

Mais bien sûr, on code aussi les requêtes dans les évènements, on n'a qu'une seule classe et la chaîne de connexion de notre base de données est dans un string. Et la marmotte...

Exceptions...

Mathieu Szablowski — Wed, 16 Mar 2005 12:04:00 GMT

Lors d’une conversation, nous sommes rentrés en conflit mon interlocuteur et moi au sujet du traitement des exceptions.

Celui-ci recourait systématiquement à un MessageBox.Show() afin d’informer l’utilisateur que son action avait échouée et de la raison de cet échec. Me demandant, pourquoi il ne fallait pas recourir à ce genre de reflexe, je lui ai cité un premier exemple.

Durant le développement d’un intranet de gestion de production, l’ensemble de l’équipe de développement avait jugé bon d’informer l’utilisateur des erreurs qui surgissaient lors des différents accès aux données.
15 jours de mise en pré-production plus tard, l’étude des logs de l’application présenta une situation pour le moins surprenante : "Une seule personne s’était connectée à l’application, mais celle-ci s’était connectée une quarantaine de fois".

En fait, lors d’un dépannage, nous avions demandé à l’utilisatrice de se connecter à l’aide d’un autre compte. Le problème en question était une erreur dans la gestion des droits et le problème fut rapidement résolu. Cependant, face aux erreurs semblables (même message d’erreur) que rencontraient certaines de ses collègues, cette personne leur a recommandé de se connecter avec un couple login/mot de passe qui fonctionnait beaucoup mieux :D .

En cas d’exceptions donc, il ne faut pas prévenir l’utilisateur de la cause de l’exception, juste des conséquences que cela entraîne.

Cette anecdote n’a vraiment suffit à convaincre mon interlocuteur et celui-ci me posa implicitement des questions essentielles auxquelles, il est vrai, j’ai eu du mal à répondre de façon claire et concise.

Profitant du week-end, je me suis plongé dans mes bouquins et notamment "Conception et Programmation Orientées Objet" de Bertrand Meyer. Ce dernier présente tout un chapitre à la définition et au traitement des exceptions.

Voici donc les questions et ce que je peux en retenir :

Qu’est-ce qu’une exception ?

Il faut d’abord définir ce qu’est un échec. Il s’agît tout simplement du cas où une partie de l’application ne sait pas ou ne peut pas remplir son rôle. Cette échec intervient à l’exécution et est causé par une exception. Une exception est donc un évènement provoquant l’échec de la méthode due à un état anormal du système.

Que signifie traiter l’exception ?

Traiter l’exception consiste dans un premier temps à identifier l’exception, sa nature, en soit, ce qui a changé dans le système pour provoquer un échec.
Dans un second temps, il faut adapter la méthode (B Meyer parle de routine) afin que celle-ci tente de remplir son rôle.

Alors mon interlocuteur a-t-il réellement traité l’exception en informant l’utilisateur qu’une exception a eu lieu et que l’action a échoué ?

Oui, en partie, il a identifié l’exception et assure ainsi la survie de l’application (pas de crash) et l’intégrité des résultats (aucun résultat renvoyé donc pas de résultat inattendu).
Cependant, le simple fait de renvoyer un message d’erreur à l’utilisateur revient à baisser les bras face au problème "tenter de modifier la méthode pour qu’elle tente de remplir son rôle".
Cette mauvaise habitude l’incite à ne jamais tenter de résoudre le problème. Nous sommes d’accord qu’il sera toujours délicat de modifier une méthode pour que celle-ci accède à un fichier qui n’existe pas ou bien qu’elle tente une division par zéro. Cependant, un certain nombre d’exception est gérable et le fait de se poser la question incitera à créer des fichiers secondaires ou à s’assurer que la variable ne contienne jamais 0.

En conclusion, on peut dire qu’une exception n’est pas une erreur et encore moins un simple évènement dont il faut avertir l’utilisateur. Il faut aussi tenter de gérer cette situation afin que l’application puisse remplir son rôle dans un maximum de circonstaces.

DevDay's et nouveautés

Mathieu Szablowski — Fri, 11 Mar 2005 14:06:00 GMT

VS 2005, SQL Server 2005 et autres Software Factory…

Après deux sessions de DevDay’s à Strasbourg et à Lille, je me penche désormais sur un rapide tour d’horizon de ce qui nous a été présenté et des réactions que j’ai pu observer.

VS 2005 : "70% de code en moins"

De part le nombre d’assistants, de raccourcis, de fonctionnalités présentés, on est en droit de s’attendre réellement à une chute vertigineuse de la quantité de code à écrire. A cela, on peut réagir de deux façons différentes.

- "houla, c’est quoi ce truc qui fait tout tout seul, je vais servir à rien, je vais perdre ma place, il n’y a plus rien à faire."

- "Waou, c’est génial, j’ai plus rien à faire, je vais enfin avoir le temps de m’entraîner à Rally Sport Challenge (clin d’œil aux devday’s 2003)"

Pour ma part, d’un naturel optimiste, je tends plutôt vers la deuxième réaction, à la différence que je trouve que ce genre d’assistanat va nous permettre de nous concentrer sur le nœud du problème plutôt que de tourner autour avec de sempiternel question de format, présentation et autres tâches "Chronophage" ( Merci JB).

Les sceptiques diront que Microsoft est allé trop loin en privant le développeur de toute liberté.

Cette réaction est la répétition de ce qui arriva lors de la présentation de ASP.NET v1. Je me souviens des Devday’s 2002, de la présentation du ViewState et de la réaction des participants. A l’heure d’aujourd’hui, on se rend compte que cette fonctionnalité nous simplifie la vie et qu’elle n’entrave en rien la construction.

SQL Server 2005

De nouvelles fonctionnalités, plus alléchantes les une que les autres. Les réactions sont enthousiastes et tout le monde réfléchit déjà à la façon dont ils vont corriger leurs bases. Pour ma part, je suis heureux de ces arrivées bien qu’aucune ne soit réellement essentielle, je pense. Ces apports permettront de répondre aux problèmes autrefois insolvables ou presque mais devront se contenter de cela. Hors de question pour moi, d’ajouter des champs XML un peu partout, de coder toutes mes procédures en C# ou d’utiliser du Pivot à tout bout de champ.

Software Factory

Sujet sensible dont l’echo renvoit aux projets off-shore, Software Factory est le sujet à la mode. Si on peut penser que Microsoft suit cette mode comme tout le monde, on peut difficilement nier que l’ensemble des outils de l’éditeur devrait permettre rapidement et simplement la mise en place d’usine à logiciels.

Enfin, nous pourrons industrialiser les développements (certains n’ont pas attendu), informer, rassurer, convaincre les clients potentiels et ainsi relancer le secteur du développement.

Que ce sujet ou cette transition soit un risque pour le marché national, possible, mais ce genre d’outils et de méthode, réclament de nouvelles compétences et de nouveaux profils qu’il conviendra d’acquérir ou de proposer.

Soirée MSDN ASP.NET v2.0

Mathieu Szablowski — Wed, 09 Feb 2005 22:34:00 GMT

Aujourd’hui, nous avons eu la chance, Vincent Bourdon, François Michaël Dain et moi-même, d’assister à la soirée des abonnés MSDN. Cette soirée était animée par Scott Guthrie membre de la Web Platform and Tools Team, à l’origine d’ASP.NET v2.0.

En un peu moins de 4 heures, Scott s’est attaché à nous présenter les nouvelles fonctionnalités d’ASP.NET, un aperçu du développement sous Visual Studio 2005 et pour finir, les effets de la migration de vos applications ASP.NET v1.X vers des applications v2.0. Détaillons rapidement (encore plus rapidement que le conférencier?, si si c’est possible) ces différentes chapitres.

Les nouvelles fonctionnalités d’ASP.NET 2 ont ici été regroupées à l’aide des ASP.NET 2.0 Application Services API’s.
Ont été présentés, les services Membership et Role manager qui vous permettront de rapidement (presque sans code) implémenter un système d’authentification ainsi qu’une gestion des droits d’utilisateurs sur votre site ou encore le service site navigation vous permettant de définir rapidement une carte de votre site, carte qui permettra la génération automatique des menus par exemple.
Si on ajoute, le service personalization qui offre à l’utilisateur la possibilité de modifier la présentation du site ou les services Database Caching et Management, on se dit que la session était bien remplie.
Et on n’a pas tort.

Pourtant, ce planning chargé n’a pas empêché notre présentateur d’ajouter une description des fonctionnalités de Visual Studio 2005 propre à ASP.NET 2, à savoir et en vrac :

les outils d’aide à la modélisation de la couche d’accès aux données.
le respect de votre norme et de votre présentation dans le code HTML.
la complétion présente dans tous les types de fichiers et paramétrable suivant le type de validation ou navigateur ciblé.
L’absence de fichier de projet ou de solution.
La facilité de mise en production son projet.

Et bien d’autres choses…

Après une courte pause (plus courte pour le présentateur que pour les participants ;) ), Visual Studio 2005 nous a été présenté et plus particulièrement les fonctions d’architectes avec les diagrammes de classes et les fonctions de testeurs avec les tests unitaires et les tests de montée en charge des applications ASP.NET 2.

Si après ce programme et déjà 3 heures de conférences, on est en droit de s’attendre à un répit, Scott Guthrie n’était pas de cet avis et a aussitôt enchaîné sur les aspects de la migration.

Si on peut être sceptique voire effrayé par le travail à fournir, que l’on semble justifié lorsque l’on liste l’ensemble des nouvelles fonctionnalités, nous avons été rapidement été rassurés. Certes, le premier exemple de migration ne concernait que la version du Framework utilisé par l’application déjà compilée, l’Issue Tracker Starter Kit. Cependant, les exemples suivants traitant de la mise à niveau du code et des fonctionnalités de vos applications ASP.NET v2.0 ont permis de se rendre compte du travail effectué par les équipes de Microsoft. Sans vouloir m’avancer, cette migration ne devrait être une barrière infranchissable.

Cette soirée abonnés MSDN a donc permis d’avoir un avant-goût des DevDay’s qui auront lieur dans un peu plus d’un mois (sans remettre en cause la qualité de la présentation d’aujourd’hui) et de lancer la campagne pour la version 2.0 du Framework de Microsoft en France.

C# un langage en carton???

Mathieu Szablowski — Thu, 02 Sep 2004 15:11:00 GMT

A la recherche de l'ensemble des standardisations qu'avai subit C#, je me suis retrouvé à rechercher le sens de l'acronyme ECMA.

ECMA signifie donc, pour ceux qui ne le saurait pas, European Carton Makers Association.

Voila qui plaira aux détracteurs du C#, et qui prouve par a + b + Google, que celui ci est un langage en carton.

Je finirais par rappeler à Madame Linda de Souza que nous attendons toujours impatiemment son article sur la portabilité des applications C#.