Mathieu Szablowski

Lors du TechEd, Jb Evain et moi même sommes restés ébahis de la manière dont Ingo Rammer  pose sur la photo de son blog. Ni une ni deux, nous avions décidé de l’imiter dès notre retour (y’a pas de mal à imiter ce genre de personnage ;) ).

 

 

 Jb ayant été plus rapide que moi et d’après les commentaires que son billet a récoltés, il semblerait même que ce soit devenu une mode, qu'Ingo ne semble pas décider à couper court. Allez tous ensemble, faisons preuve de patriotisme esthétique et démontrons que les développeurs français savent aussi le faire.

 

J'en profite également pour saluer Jb qui nous quitte pour de nouvelles aventures. Lors de ce même TechEd, un séminaire a été consacré aux étudiants. A la fin de celui-ci, un tee shirt nous a été offert avec un slogan plutôt accrocheur :

 

 

Tout cela pour en arriver à dire que cette année passée à travailler avec Jean-Baptiste (qui ne m'en voudra pas d'utiliser son prénom ;) ) fût un réel plaisir et une nouvelle inspiration pour moi. Ses talents et ses grandes connaissances nous ont, à tous, beaucoup apporté et j'aimerais lui souhaiter bonne chance pour la suite d'une manière un peu particulière.

 

Allez Jb, juste pour toi ;) :

 

if code is poetry then JbEvain is my muse 

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.

 

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

Je suis depuis dimanche à Amsterdam pour le TechEd 2005.

J'ai pu assisté hier à trois conférences concernant les architectures orientées services. La programmation de ce TechEd et la fréquentation des sessions sur le sujet ne peuvent que confirmer le fait que l'on ne pourra bientôt plus passer à coté de ce type de conception.

8h30 Dealing with Data in Service Oriented Architecture

Dès 8h30, Ron Jacobs qui fait partie de l'équipe Patterns&pratices de Microsoft a abordé la gestion des données dans les systèmes connectés.

Ron a démontré que la mise en place d'un système interconnecté mettait en branle tous les reflexes que nous pouvons avoir concernant l'accès, le stockage ou la transmission des données.

Cela passe par la définition des différents types de données (internes au service ou intégrés au message), du ciblage de données immuables, de la necessité de mettre en place une solution de versionning et enfin et pas des moindres de l'obligation de définir clairement le propriétaires des données ainsi que ses responsabilités (notification et transmission des données actualisées).

14h45 The gray area of implementing Services using Object Oriented Technologies

Un peu plus ciblé implémentation, cette session de l'étonnant Beat Schwegler (qui vous illustre ses propos en vous racontant ses vacances) fût l'occasion de bien prendre conscience en quoi la programmation orientée services se distingue d'une approche POO classique (la "Grey Area" présente entre le modèle SOA et son implémentation).

Dans un premier temps, Beat nous a présenté la distinction entre un appel de méthode où l'on utilise un objet, d'un certain type connu (dans ce qui nous est accessible) et la consommation d'une WebMethod dont on ne connait que la description qui nous en est faite dans le WSDL.

La suite concernait l'encodage des messages SOAP. Beat en arrive à la conclusion que RPC ne doit être utilisé qu'en dernier ressors et a mis l'accent sur l'importance de WSA (Web Services Addressing) à court et moyen terme.

Cette session s'est conclue sur l'importance de respecter les contrats ou de la mise en place d'un système adaptable afin de garantir le service aux applications clientes.
  

17h45 Patterns for Service - Oriented Architecture

j'ai retrouvé Ron Jacobs dans une salle comble pour une conférence beaucoup plus généraliste sur SOA. Je dois dire que j'ai été un peu déçu du contenu de la session même si les compétences techniques et la qualité de présentation étaient au rendez-vous.
Il faut dire que sur 1h15 de session, une bonne heure a été consacrée à la présentation de différents anti-patterns. Si l'objectif est bien entendu le même (évitez des erreurs de conceptions dans les services connectés), j'aurais pour ma part préféré d'avantages de présentation de Best Pratices.

Les cas présentés ont tout de même permis de conclure qu'il ne faut pas faire confiance au client pour quoi que ce soit ou de l'importance de restreindre la généricité de ces services afin de mieux répondre aux attentes des clients. La spécialisation des services ou des interfaces facilite également la compréhension du service par un contrat beaucoup plus explicite.

La démonstration du Global Account Integration sur le site de l'équipe Patterns&Pratices a achevé cette session afin de permettre de rencontrer d'avantages de ces Best Pratices.  

 

 

 

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

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.

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.

 

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.

Si l'installation du SP2 s'est très bien passée sur mon portable, j'ai eu énormément de mal à l'installer sur mon poste à domicile.

En effet, lors de la première tentative, l'installation m'a signalé que je n'avais pas assez de place sur la disque. On me demande donc de rectifier cela et de réessayer. Je fais de la place sur mon disque et je retente : l'installation reste bloquée à l'initialisation. Je retente plusieurs fois sans succès.  Il m'aura fallu recourir à la restauration système pour pouvoir reexécuter la mise à jour.

Affaire à suivre également, depuis l'installation du SP sur mon portable, celui ci refuse de se connecter au WLAN de mon domicile si le WEP est activé. Génant mais peut être une simple coincidence.

 

 

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#.