En cette veille de long week-end, vous cherchez sûrement des idées pour combler tout ce temps libre…

Je souhaite signaler à la Terrre entière (enfin disons plus modestement aux visiteurs du blog technologique Novedia) quelques informations intéressantes en écho à mon article d’octobre 2011, où je vous conseillais plus qu’ardemment le livre de Jean Philippe GOUIGOUX à propos du profilage d’applications .NET.

Echo, dis-je, car ce livre vient d’être sélectionné par Red Gate Software (célèbre éditeur de produits de qualité) pour être offert en téléchargement gratuit dans sa version anglaise. Pour la version française, c’est toujours dispo chez Amazon ou directement aux éditions ENI.

Cerise sur le gâteau, l’auteur du livre a animé un WebCast librement accessible sur le sujet (toujours dans la langue de la perfide Albion).

Si avec tout cela vous vous ennuyez ce week-end…

Ce billet traitera moins de prospective ou de réactions à l’actualité pour rejoindre les soucis du quotidien de développeur…

Et quel pire souci peut il y avoir qu’un client qui vous appelle en vous disant « le logiciel que vous m’avez livré plante régulièrement, mais de manière complètement silencieuse »…

Vous voilà donc dans de beaux draps. Qu’un logiciel plante, d’accord, mais si je n’ai pas d’informations complémentaires, la situation est fort délicate.

Là, votre meilleur ami s’appelle … ProcDump. Le papa de votre meilleur ami n’est autre que Marc Russinovich, le pape des outils systèmes pour Windows (ex Sysinternals).
ProcDump est un outil en ligne de commande qui va se « brancher » sur un processus qui s’exécute et dumper le contenu de la mémoire et de la pile d’appel selon une ou plusieurs conditions :

• arrêt du programme, que ce soit proprement ou pour cause d’exception non gérée
• dépassement d’un seuil de consommation de ressources(CPU, mémoire) pendant plus que n secondes
• le programme ne répond plus à l’OS

Bref, les conditions annonciatrices d’un problème dans l’exécution d’un code déployé.

A partir de là, on se retrouve fièrement en possession d’un fichier .DMP qui contient donc le contenu de la mémoire, l’état des threads et de la pile d’appels. Et que fait on me direz vous ?

Et bien on appelle notre autre meilleur ami, j’ai nommé Visual Studio 2010.
En effet, VS 2010 est l’outil d’analyse des fichiers DMP (minidumps).

A partir d’un fichier DMP et des fichiers PDB de l’application, il est alors possible de restaurer le processus au moment du dysfonctionnement, et de voir la source du problème (boucle infinie, détail de la pile et de l’exception non gérée).

Petit truc : si vous analysez un fichier de dump produit par une autre machine que la votre, il vous faut suivre le mode opératoire décrit dans cet article, et notamment bien valider l’option qui dit à Visual Studio d’aller chercher ses fichiers de symboles (les fameux PDB) sur un serveur de fichiers (mis à disposition par Microsoft sur un site web).

Plus d’excuses pour des plantages inexpliqués !

Novedia était présent lors du DevCamp Microsoft Windows 8 le 29 Mars dernier.

Ce DevCamp marque le lancement d’une longue série d’événements orchestrés par Microsoft autour de Windows 8, dont aucune date de sortie n’est encore officielle, mais dont on voit bien arriver une beta sous peu et une RTM à l’automne. Il ne faudrait pas que le Père Noël soit privé de Windows 8 et de l’avalanche de produits associés (soyons sûr que les constructeurs de PC & tablettes attendent cela avec impatience pour secouer leurs ventes) !

Ce DevCamp s’est déroulé en 4 temps : une keynote, suivi d’un atelier de développement, de sessions focalisées sur certains aspects de la plateforme, puis un final sous forme de retours d’expérience (l’occasion de revoir Mitsu).

Windows 8 ?

Windows 8 représente LE pari de Microsoft pour l’unification des OS dédiés aux postes clients, qu’ils soient « traditionnels » (les bon vieux desktop et laptop), dans l’air du temps (les tablettes) ou plus novateurs (laptops combinant interface clavier et écran tactile, comme l’a déjà essayé HP avec certaines modèles sous Windows 7). A terme, il est fort probable que les téléphones mobiles verront leur OS socle migrer vers un OS dérivé lui aussi de Windows 8 (Windows Phone 8 ?).

Prenons le Metro

La principale caractéristique de Windows 8 est d’avoir 2 shells : un classic shell (une sorte de Windows 7 raffiné), et un modern shell appelé plus communément Metro.

Le développement d’applications pour Windows 8 prend particulièrement sens pour son interface Metro.

Cette interface change radicalement l’expérience utilisateur pour les OS Microsoft. Elle est pensée pour le tactile, pour la fluidité et la rapidité. Elle offre une cohérence d’utilisation entre PC/tablette tactile, téléphone mobile et console de jeux (les sempiternels 3 écrans cités lors des TechDays des 3 dernières années).

Metro, oui, mais pas sans son Store

Windows 8 sera doté un Windows Store pour les applications Metro.
Ces applications natives permettront de tirer partie des riches fonctionnalités offertes par l’OS.

Il est à noter que Microsoft vise à ne pas reproduire les points négatifs des stores concurrents : le modèle économique sera flexible, les revenus des développeurs sera maximisé, et le processus de validation de l’application le plus transparent possible.

Ce Windows Store sera d’ailleurs à terme la market place avec le plus de potentiel de diffusion : à titre d’exemple, il y a actuellement 500 millions de PC sous la seule version 7 de Windows. Avec le renouvellement naturel du parc, on peut espérer le même nombre de clients potentiels pour ce store ! A titre de comparaison, les AndroPhones représentent de l’ordre de 250 millions d’unités.

Et le dév ?

Et quid du développement d’applications me direz vous ?

Vous décrire en détail comment développer une application Windows 8 n’est pas l’objectif de ce billet.
Retenez simplement que toute application Windows 8 repose sur le socle commun WinRT, et qu’on peut développer des applications faisant appel à WinRT dans énormément de langages : en C#/VB.NET + XAML, en HTML5 + JS, voire même en C++ (faut de tout pour faire un monde).

Les applications présentes actuellement sur la Consumer Preview utilisent XAML/C# ou HTML5/JS.
Le développement Windows 8 offre donc une grande liberté de choix, et devrait amener de nouveaux publics vers l’écosystème Microsoft.

Alors trop facile les applications Windows 8 ?

Sous des apparences de simplicité (l’interface utilisateur étant volontairement dans le style le plus dépouillé possible), le développement d’applications Windows 8 cache un bon nombre de subtilités techniques qu’il faut maîtriser :

• asynchronisme à tous les étages (ce qui donne le ressenti globale d’extrême fluidité)
• permissions limitées (exécution dans une sandbox),
• gestion du cycle de vie des applications qui sont mises en hibernation (familier pour les développeurs Windows Phone 7.5, mais pas forcément pour les autres),
• utilisation intelligente des fonctionnalités de l’OS (contrats, tuiles live),
• recours au cloud Azure pour le stockage persistent

Au delà de ces aspects strictement techniques, Metro est un nouveau paradigme d’interface qu’il faut appréhender avec soin pour le comprendre et en tirer sa substantifique moelle.

C’est donc plus que jamais le temps de faire travailler main dans la main développeurs et designers !

Des opportunités en veux tu en voilà …

Avec le lancement de Windows 8, le moment est adéquat pour les marques souhaitant profiter d’un buzz marketing pour apparaitre sur le Store et mettre en évidence des cas d’usages novateurs. En tant qu’acteur spécialisés sur les canaux digitaux, Novedia est là pour vous aider à imaginer, formaliser et mettre en place ces projets…

Le voilà enfin,  le nouveau langage web  révolutionnaire, la fin des problèmes de compatibilité entre les navigateurs, la solution à tous nos soucis de développeur web. Bon, ce que je viens d’écrire est peut-être un peu trop optimiste… Certes, HTML 5 a pour objectif de standardiser les technologies du web mais il ne faut pas rêver,  ce ne sera pas, ou plutôt,  cela ne semble pas être la solution miracle.

<Intro>

Si vous ne le savez pas encore, HTML 5, comme le présuppose son nom, est la nouvelle version de HTML après HTML 4.1. Cette évolution de l’HyperText Markup Language se veut être à la fois un regroupement de bonnes pratiques observées depuis plusieurs années sur la toile et dans les entreprises mais aussi un regroupement de nouvelles fonctionnalités qui faisaient défaut. Initiées au départ, par les trois géants du web que sont Apple, Google et Mozilla au sein du Web Hypertext Application Technology Working Group (WHATWG), ces spécifications ont été ensuite reprises par le W3C pour être normalisées.

HTML 5 a aussi pour ambition de simplifier son utilisation qui s’est complexifiée avec le temps. Prenons pour exemple, la déclaration de certaines balises qui a été réduite au strict minimum. La déclaration du doctype devient très simple. La déclaration des scripts JS inline devient implicite.

L’implémentation de nombreux types de validations client comme la validation d’une chaine de caractères (email, code postal, numéro de téléphone…) est facilitée par l’utilisation d’attributs natifs.

La réalisation d’effets graphiques simples tels que, les coins arrondis, les ombres (de texte ou de boite) ou les dégradés de couleur deviennent natifs en CSS 3 (avec malheureusement encore quelques variations entre les différents navigateurs…).

<ASP.NET MVC>

The right way for HTML 5 !

HTML 5 arrive avec son lot de bonnes nouvelles et nous devons, en tant que modestes développeurs ASP.NET, être prêts à l’accueillir. Pour celles et ceux qui n’auraient pas encore mis leur nez dans l’implémentation du pattern MVC en ASP.NET, c’est le moment.

A mon sens, pour faire du HTML 5, il faut oublier les contrôles ASP.NET standards, produisant du code HTML plus que perfectible. Il faut désormais se tourner vers ASP.NET MVC qui permet d’avoir la maitrise totale du code HTML final. Fini les gros Datagrid très pratiques générant un code HTML lourd. Le développeur revient aux fondamentaux du développement web et doit recoder son beau tableau à la main mais avec beaucoup plus d’API qu’avant, simplifiant ainsi son implémentation. Le résultat est un code HTML plus propre, plus léger pour transiter sur les réseaux et facilement maintenable pour les éventuels intégrateurs. Le passage à HTML 5 se fait alors naturellement.

Des frameworks déjà disponibles, fournissent des méthodes évitant aux développeurs de réinventer la roue. Ils permettent notamment de simplifier l’accès aux éléments des pages, la gestion des évènements, la communication avec le serveur…

<Limitations>

HTML 5 en ASP.NET est donc bien possible mais jusqu’où ? Il est aisé de dire « Mon application est en HTML 5 » en ajoutant simplement le doctype qui correspond, mais l’est-elle vraiment ?

Les principaux acteurs du web se sont incontestablement associés pour définir les standards de cette nouvelle mouture mais, malheureusement, ils ne s’accordent toujours pas sur l’ensemble des aspects de la spécification. L’exemple frappant reste celui de la prise en compte des formats vidéo. Chacun voudrait que son standard vidéo soit celui retenu dans la spécification et cela donne un grand n’importe quoi. Pour le moment, pas de réel changement par rapport à la version précédente d’HTML, le format vidéo supporté dépend du navigateur. Pour être cross navigateur, il faudra prévoir une version de la vidéo pour chaque format existant. Quel dommage pour une spécification qui se veut être une standardisation ?!

Certaines implémentations de HTML 5 ne sont pas encore disponibles pour toutes les plateformes. En effet, parmi les évolutions apportées par cette nouvelle version du langage, l’implémentation des flux duplex via les web sockets n’est pas entièrement prise en charge par la plateforme .NET. Si la partie cliente dépend uniquement du navigateur, la partie serveur a aussi un rôle à jouer.  Or, le serveur IIS ne supporte pas encore le protocole web sockets. Pour le moment, seuls quelques serveurs d’application les supportent, tels que Jetty et Node JS (le serveur en Javascript). Il n’est donc pas possible d’utiliser cette évolution avec une plateforme full .NET. Il faudra attendre la plateforme Windows 8 avec IIS 8 et ASP.NET 4.5.

<Applications>

Pour résumer, HTML 5 est déjà là. Plus ou moins terminé, plus ou moins standard entre les navigateurs et les plateformes. Mais attention, si certaines fonctionnalités sont déjà présentes, la spécification n’étant pas finalisée, celles-ci peuvent être modifiées !

Donc, pour savoir dans quels cas il faut se lancer dans l’aventure HTML 5 et dans quels cas il vaut mieux l’éviter, il faut se poser les bonnes questions. Il faut commencer par identifier le type de l’application concernée et les utilisateurs finaux de cette application.

Si l’application est un site grand public, on veillera à bien étudier les nouvelles fonctionnalités que l’on souhaite utiliser sur le site. Cette fonction est-elle implémentée sur tous les navigateurs ? Y a-t-il un risque que l’implémentation change avant la fin de l’élaboration des spécifications ? (Et bien sûr, cette fonctionnalité est-elle bien adaptée à tous les visiteurs ?)

Si l’application est une application intranet, le scope des utilisateurs finaux est plus réduit et le nombre de navigateurs utilisés est souvent limité. On peut donc choisir d’utiliser telles ou telles nouvelles fonctionnalités du langage en ciblant les navigateurs. En entreprise, il est aussi possible de les imposer ce qui réduit encore l’éventail des navigateurs clients.

<Conclusion>

Au final, HTML 5 apporte un réel plus dans l’implémentation des applications web mais il faut prendre garde car les spécifications ne sont pas encore terminées. La version finale est prévue pour cette année mais rien ne dit que cette version sera conforme à ce qui est déjà écrit.  En attendant, tous les grands acteurs du web s’y préparent et Microsoft sera évidemment au rendez-vous.

ASP.NET MVC est la mise en œuvre apportée par Microsoft du design pattern MVC. Un projet Web MVC est caractérisé par le faible couplage entre les pages de rendu HTML, les données et les différentes interactions entre ces deux couches qui va se faire dans le contrôleur.

Cette année une session au Techdays 2012 a été consacrée sur les bonnes pratiques à utiliser dans un projet ASP.NET MVC et sur les pièges à éviter. Cette session a été  animée par Rui Carvalho architecte senior.net Net, Asp.Net, MVC, Sql Server et Julien Corioland formateur et consultant .net qui travaille principalement sur les technologies Silverlight et Silverlight pour Windows Phone mais également sur ASP.NET MVC / Windows Azure.

Durant la sessions, les animateurs ont abordé les points suivants:

• Rappel sur le design pattern MVC
• Bonnes pratiques
• Exemple de structuration/architecture d’un projet MVC

Rappel sur le design pattern MVC

Le modèle MVC est constitué des éléments suivants :

Modèle : représente la couche métier d’une application.

Vue : constitue les éléments d’interface utilisateurs : pages web, contrôles Web…

Contrôleur : permet de piloter l’application, il interprète les actions à réaliser et ordonne leur exécution (lecture, traitement de données et mises à jour).

Ci-dessous un schéma détaillant la relation entre les différentes couches :

Bonnes pratiques

Pourquoi choisir ASP.NET MVC?

Un projet  Web développé avec ASP.NET  MVC  a pour avantage d’être bien structuré en  proposant une architecture qui fait une séparation nette entre la couche du rendu  HTML et celle des données. Une telle architecture permet une meilleure testabilité de l’application et la rend extensible plus facilement. En effet, lors de la création d’une application ASP.NET MVC  un projet de test est généré automatiquement.

ASP.NET MVC met l’accent sur le référencement naturel,  une problématique non négligeable dans le monde du Web. Un site bien référencé par les moteurs de recherche améliore sa visibilité sur la toile et réduit ses coûts publicitaires. ASP.NET MVC, offre par son système de routage un mécanisme pour la génération d’url  décorées.

De plus, Microsoft met  à notre disposition un ensemble d’outils et moyens  pour améliorer la productivité d’un projet MVC notamment avec NuGet ,le scaffolding / Template T4 pour la génération de code et Razor le nouveau moteur de vue.

Bonnes pratiques

Démarrer un projet web ASP.NET MVC est une tâche assez simple néanmoins le démarrer correctement en est une autre.  Durant la session, une liste de recommandation a été fournie lors de la mise en place et développement d’une application web MVC :

• Eviter de laisser la route par défaut au niveau du fichier global.asax et ajouter des contraintes au niveau des routes en utilisant les expressions régulières, des valeurs spécifiques afin de maîtriser les points d’accès  au site web.
• Respecter le design pattern MVC en gardant une séparation nette entre le modèle de données et la vue. Une solution proposée serait de créer un projet à part pour la couche Business et accès aux données.
• Favoriser l’utilisation des vues typées
• Favoriser l’utilisation des « Data Annotation » qui permettront  de gérer d’une façon déclarative un ensemble d’action comme la validation de données, …
• Utiliser la validation des données et créer aussi ses propres validateurs
• Favoriser l’utilisation des filtres qui va permettre le rajout d’une façon déclarative d’une fonctionnalité transverse à l’application comme par exemple l’authentification. Il existe 3 types de filtres : Autorisation Filter, Exception Filter,   Action et Result Filter. A noter qu’il est possible de définir ses propres filtres.
• Créer ses propres « HTML Helpers » pour factoriser le code.

Exemple de structuration/architecture d’un projet MVC

La deuxième partie de la session était consacrée à la présentation d’un exemple sur une architecture  « type » dans un projet. Bien sûr, il ne faut pas appliquer à la lettre ce qui est proposé sachant que la définition de l’architecture d’un projet dépend de plusieurs facteurs lié au projet lui-même. Je citerai ci-dessous les quelques points que j’ai pu noter :

• Privilégier le design pattern SOLID
• Utilisation d’un projet  Bootstrapper pour la gestion de la partie configuration d’une application
• Séparation complète entre le code de l’interface utilisateur  (Vue) et le code fonctionnel en créant deux projets distincts
• Découplage fonctionnel en favorisant l’utilisation des areas

Conclusion

J’ai trouvé cette session intéressante même si la deuxième partie de la session consacrée à l’architecture était relativement courte et pas assez détaillée. Néanmoins, cette session m’a donné une idée globale sur les points à retenir lors du développement d’une application MVC notamment comment profiter des data Annotation pour gérer tous les contrôles transverses sur une fonctionnalité(validation des données , autorisations, authentification…) sans pour autant polluer le code métier.

Avec ASP.NET MVC  nous retrouvons les fondamentaux du développements web. Nos vues sont plus simples et libérées des contrôles serveurs où la logique métier et l’affichage peuvent se mêler. Nous avons ainsi une séparation nette entre la vue, chargée uniquement de l’affichage, le modèle, responsable de la manipulation et traitement de données et le contrôleur, qui gère les interactions entre la vue et le modèle. La question qui reste c’est quand privilégier l’utilisation d’une application ASP.NET MVC à une application .NET WebForm ?

Liens Utiles:

• Exemple structuration/architecture projet à télécharger: SampArch
• NuGet: http://nuget.codeplex.com/