Microsoft Techdays 2010 (3/3)

Les Techdays sont l’occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d’outils sous forme de présentations, d’ateliers ou de retour d’expérience. Difficile de couvrir complètement cet événement tant l’offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts (voir le premier ou le second), sur les sessions que nous avions choisi et de partager avec vous notre ressenti.

Fin de la série avec des sessions plus orientés geek.

Coding4Fun

Une belle démonstration de ce que les dernières API du framework proposent.

• Simulation du multitouch avec plusieurs souris : idéal pour tester une application multitouch sur un écran traditionnel, même si l'usabilité paraît chaotique et le framework requérant à l'application d'être lancée en plein écran.
• Utilisation de silverlight out of browser (pour accéder au filesystem de manière limitée, aux contrôleurs type webcam) et WCF pour piloter un robot à distance !

Pas vraiment de valeur à tous ces développements mais des idées et surtout la démonstration que le framework est complet et facile d'utilisation (comment ca c'est orienté?)

Session : C# et Linq avancé

Une session qui repose sur des manipulation de lamba Expression et la génération dynamique de code. Séduisant pour l'esprit (encore faut-il rester concentré) mais on ne fait pas un compilateur tous les matins. C'est surtout l'occasion de réfléchir à nos petites habitudes de développements et d'y repenser sous un nouvel angle après avoir encore une fois constaté la flexibilité que linq permet.

J’aurais bien aimé voir d’avantage d’astuces liés aux nouveautés de C#4.

Session : AOP et .net

Dommage à mon goût que l’on ait passé un peu trop de temps sur l’explication de l’AOP plutôt que d’entrer directement dans le vif du sujet  - reste qu'ils ont présenté PostSharp (en autres mais je ne vais pas m'attarder sur spring.net). Si vous ne le connaissez pas, il s’agit d’un outil permettant d’injecter du code lors de la compilation.

Imaginons que je veuille être sur que toutes les propriétés de mes POCO commencent par vérifier que l'objet est à jour avant de retourner leur valeur mais je veuille garder la description la plus simple possible de mes objets. Alors il me suffit d’écrire le script PostSharp qui déclare le code à ajouter sur la propriété. A la compilation, l'IL normalement produite est modifiée et le code supplémentaire injecté.

Gain de temps considérable pour le développeur et surtout garantie qu'aucun n'oubliera de le faire. Le debugger reste utilisable sur le code ajouté.

Bémol : le binaire produit peut être beaucoup plus volumineux, code moins factorisé.

Session : détecter et éviter les fuites mémoire en .Net

Session technique encore, qui explique comment et pourquoi il est possible d'avoir des fuites mémoires en .Net. Trois outils sont présentés pour les détecter (dotTrate, .Net Memory Profiler et WinDbg), le tout illustré sur une application faite sur mesure (comprendre : qui fuit plus que les baignoires utilisés à l'école primaire en cours de mathématiques).

Une session qui, pour moi, a trouvé une application immédiate, puisque mise en œuvre dès la fin des techdays sur une mission. Bien qu'utilisant trois outils spécifiques, les principes présentés restent génériques et peuvent être appliqués avec d'autres outils (Ants, par exemple).

Session : Développement parallèle avancé

Animé par Bruno Boucard qui a co-animé une session USI l'année dernière avec Arnaud Mazin. Une session orientée "Pattern de modélisation" pour le développement parallèle. Très Intéressant sur le principe mais elle s'est arrêtée au moment ou cela commençait à être intéressant. C'est à dire au moment de faire le lien entre le choix de la démarche (orienté données vs orienté tâche) et de l'algo avec l'implémentation : les API du marché.

Session : Le langage Axum

Une autre session sur le parallélisme (co-animé également par Boucard). Cette fois-ci s'est beaucoup plus intéressant (pour moi) car beaucoup plus concret. Axum est une sorte de DSL de la plateforme .net - paradigme de programmation orienté Agent et message.

La grosse difficulté des algorithmes parallèle repose sur la complexité à estimer les effets de bords et de concurrence d'accès à certaines données. L'idée est donc de proposer la notion d'agent dont le contenu de l'implémentation est invisible et immuable depuis l'extérieur. Il répond à des messages reçus via un channel sur l'un des ports qu'il expose. La notion de message facilite le découpage de l'algorithme et celle d'agent limite les risques d'effets de bords.

On retrouve certains principes des langages fonctionnelles (immuable) mais on reste proche d'une syntaxe objet. Ce langage n'a clairement pas la prétention de réaliser à lui seul le développement de l'application mais plutôt de simplifier le développement de tâches critiques.

On retrouve les promesses de la plateforme .net : choisis le langage qui t'arrange, le compilateur produira in fine de l'IL.

Bémol : il s'agit d'un projet de recherche qui est (très) loin d'être utilisable en production.

Session : Pex et Moles appliqués pour tester Sharepoint

Il s'agit à nouveau d'outils fournis par le labo de Research de MS mais à un stade beaucoup plus abouti (ils font partie de la release de VS 2010).

Moles permet de remplacer n'importe quelle méthode du framework de base par un délégué et donc de coder la fonction de votre choix (le remplacement est fait à la compilation en modifiant l'IL générée). Pex permet de générer intelligement des tests unitaires par introspection des branchements de votre code.

A quoi ca sert tout ça ?

Imaginez que vous vouliez tester un code du genre : Si la date du jour est supérieure à 01/01/2011 alors Exception 'offre terminée' . Et bien avec Mole, vous remplacez le DateTime.Now par une fonction qui prend en paramètre la date de votre choix. Puis Pex, vous génère les tests unitaires correspondants aux cas aux limites : ici 01/01/2011.

Attention, cela ne vous dispense pas d'écrire des TU puisque sans TU, PEX ne saura pas ce qui doit être testé. Il vous évite juste décrire tous les cas aux limites et vous garantit surtout que vous n'avez rien oublié.

Imaginons maintenant un cas plus complexe, vous voulez tester un système mastodonte qui plus est distant - au hasard Sharepoint.  L'équipe Moles a fourni une sorte de mock qui récrit simplement tous les points d'accroches de l'API Sharepoint. Vous pouvez ainsi tester facilement et de manière indépendante sans même l'avoir sur votre poste, votre développement. Ils sont engagés à fournir la même chose pour tout leur genre d'outils ex : ActiveDirectory.

Je trouve que cela offre des possibilités intéressantes pour tester des systèmes critiques qui nécessitent une couverture très fine du code, ou des legacy non designés pour les tests.

Mick Philippon, Nicolas Raynaud, Olivier Roux