Archives mensuelles : mars 2011

image

L’impact psychologique du nommage

Ceux qui me suivent sur Twitter le savent, je suis en train de mettre en place TFS 2010 au sein de ma nouvelle société et à cet effet nous avons mis en place une toute nouvelle infrastructure matérielle afin d’utiliser un ensemble de machines virtuelles.

Lors de la création de la machine virtuelle destinée à l’installation de TFS 2010, un de mes collègues m’a demandé le nom de machine que je souhaitais pour cette machine virtuelle en me demandant si le nom “VM-TFS” me convenait.

image Je me suis alors empressé de lui dire que je ne souhaitais pas que VM apparaisse dans le nom de la machine afin que les utilisateurs ne puissent pas râler sur l’installation à cause du fait que cela soit une VM. Mon collègue l’a pris sur le ton de l’humour mais j’étais en réalité très sérieux.

Une VM doit réagir comme une machine physique et je ne souhaite pas que les utilisateurs puissent avoir une image négative de TFS à cause du fait qu’il soit installé dans une machine virtuelle. La société n’a pas l’habitude d’utiliser les technologies de virtualisation, il est donc plus simple de ne pas leur mettre sous les yeux un panneau “Attention c’est une VM” à chaque fois qu’ils vont y accéder. L’idée n’est pas de masquer les choses (la nouvelle infrastructure a été présentée après que la migration de TFS 2005 vers TFS 2010 ait été effectué) mais de faciliter l’adoption d’une nouvelle technologie en supprimant des freins liés à des idées préconçues.

Dans le domaine du développement, j’ai également conseillé à plusieurs clients de nommer “intelligemment” certaines classes afin d’inciter une réelle maintenance/refactorisation de celles-ci. Durant des revues de code, ou tests de migration, ou autre type d’intervention, j’ai régulièrement trouvé des classes helpers destinées à faciliter l’utilisation d’une fonctionnalité. Ces classes utilisent souvent un nommage du genre “EasyQqueChose” (EasyDB pour l’accès aux bases de données, EasyXml pour la manipulation XML, etc.) pour bien signifier aux développeurs qu’avec cette classe il sera très simple d’effectuer la tâche qu’ils doivent accomplir.

Seulement avec le temps, la classe destinée à faciliter les choses est devenue un vrai capharnaüm, et est devenue complexe à utiliser. Bien évidemment cette classe doit être refactorée depuis 97879 siècles mais au final elle ne l’est jamais.

Quand je rencontrais ce genre de cas, je proposais souvent la même idée : prendre quelques minutes pour renommer la classe “EasyQqueChose” en “FuckingComplexAndUnusableQqueChose”. Je ne suis parvenu à faire appliquer cette idée qu’une seule fois  (et oui il y a encore beaucoup de développeurs qui ont peur de renommer une classe…) et étrangement quand je suis revenu quelques semaines plus tard chez ce client la classe avait été refactorée (et donc de nouveau renommée).

image

Ce qu’il ne faut pas faire pour vendre un produit…

C’est le week-end je vous propose donc une petite note légère afin de vous relater une expérience récente.

Nous sommes en train d’étudier une nouvelle solution afin de réaliser le programme d’installation de notre solution et après discussion avec des collègues, je me mets donc à télécharger la version d’essai d’u très célèbre InstallShield bien que je ne l’avais même pas évoqué dans l’étude que j’avais réalisé et dans le rapport que j’avais rédigé à cet effet.

Pourquoi ne pas avoir abordé InstallShield ? La raison est très simple, je considère qu’InstallShield fait parti des produits que beaucoup de personnes achètent mais qui au final restent dans la boite. Je l’ai constaté chez mes précédents employeurs mais également chez mes anciens clients, InstallShield parait très bien au début, mais dès qu’on souhaite qu’il réponde à des besoins précis, c’est le début de la fin, c’est le début des galères.

Durant mon étude j’avais quand même bien évidemment fait quelques recherches sur internet afin d’avoir un ressenti global des dernières versions du produit et ce ressenti était négatif. On trouve en effet assez facilement des retours d’expériences très négatifs de personnes qui déconseille fortement d’utiliser ce produit.

Un petit tour sur Twitter confirme d’ailleurs cette impression :

image
(cliquer pour agrandir)

Après discussion avec des collègues ayant lu mon rapport, je décide donc quand même de télécharger une version d’essai de cet outil sur le site officiel. Et en garçon bien élevé je remplis donc le formulaire de téléchargement avec mes coordonnées.

Quelle ne fut pas ma surprise de voir le chef de produit de Flexera Software m’appeler au téléphone alors que je venais à peine de finir de télécharger l’outil (oui nous avons une connexion internet qui aime bien faire le tour du monde avant de nous renvoyer les paquets direction Pau…).

Suite à ce (court, je vous l’avoue) échange téléphonique, je vous propose donc une petite liste d’éléments à éviter de faire si vous souhaitez me vendre un produit :

  • Règle n°1 : Ne pas me téléphoner alors que je viens à peine de finir de télécharger une version d’essai ! Cela laisse un sentiment d’agression très désagréable. Si je viens de télécharger une version d’essai c’est que… euh… je veux juste essayer le produit. Pour une enquête de satisfaction, un mail ou un appel à la fin de la période d’évaluation est plus pertinent qu’un appel alors que l’on a rien essayé du tout.
  • Règle n°2 : Se présenter correctement afin d’être facilement indentifiable. Hint : La marque InstallShield est immensément plus forte que Flexera Software. Se présenter avec le nom de cette société, c’est être certain de ne pas être identifié par l’aimable personne qui répond au téléphone.
  • Règle n°3 : Si l’on tombe sur quelqu’un de patient qui se dit prêt à prendre 5min pour répondre à des questions, poser des questions PERTINENTES ou à QCM. Le QCM est une excellente forme de questionnaire pour donner l’illusion au sondé de ne pas avoir à réfléchir et de rester passif. Plus le sondé aura l’impression d’avoir à faire avec des questions stupides où les réponses sont évidentes et/ou à des questions qui demandent de réfléchir, plus il y a de chances qu’il se dise “rah il me fait c**** avec ces questions à la ***”. Le QCM permet d’avoir des réponses simplement et rapidement, pas besoin de réfléchir à la formulation de la réponse = peu de rejet.

Sur ce, vous l’aurez deviné, attendez-vous à avoir un feedback sur InstallShield dans les prochains jours sur ce blog…

unsecure

Le bug de conception de la PasswordBox

C’est en utilisant la PasswordBox récemment (et en réfléchissant un peu plus que d’habitude) que j’ai réalisé ce que contrôle avait un bug de conception lié à la sécurité.

En WPF, le contrôle expose deux propriétés liées à la gestion du mot de passe.

La propriété SecurePassword est une propriété en readonly qui renvoie le mot de passe stocké par la PasswordBox sous la forme d’une SecureString.

Le type SecureString est un type intéressant qui permet de stocker en mémoire une string de manière sécurisée. Cette chaine de caractères est en effet cryptée en mémoire via DPAPI et ne peut donc être lue en clair malgré le fait qu’elle réside en mémoire.

Pour définir la valeur d’une SecureString il est nécessaire de le remplir caractère par caractère grâce à la méthode AppendChar, et pour lire en clair la valeur stockée par une SecureString on doit allouer de la mémoire et y stocker la valeur en clair de la SecureString via un Marshal.SecureStringToBSTR (qui au passage ne respecte pas les conventions de nommage .net). Une fois lue, on peut ensuite faire un reset la zone mémoire qui contient la valeur en clair via la méthode ZeroFreeBSTR (qui ne respecte toujours pas les conventions de nommage .net).

On réduit ainsi fortement l’intervalle de temps où la chaine de caractères, dans notre cas le mot de passe, est en clair en mémoire.

La PasswordBox utilisant une SecureString en interne on pourrait donc se dire que ce contrôle est parfaitement sécurisé… si l’on évoquait pas la seconde propriété dédiée à la gestion du mot de passe : la propriété Password.

Cette propriété de type String permet de définir et récupérer le mot de passe stocké par la PasswordBox. Et qui dit type String dit, lisible comme de l’eau de roche via n’importe quel outil de type Snoop et consors :

Donc en résumé, la propriété Password devrait en réalité se nommer “UnSecurePassword” et la propriété SecurePassword est inutile. Pourquoi en effet stocker le mot de passe de manière sécurisé si on l’expose en même temps en clair ?

Vous allez me répondre que c’est simple, il faut bien que l’on soit capable de définir la valeur de la PasswordBox via une propriété qui ne soit pas en Readonly. Certes, mais en a-t-on vraiment besoin ?

Le contrôle n’a pour objectif que d’afficher des ●●●●●● et on se moque donc de savoir si les ●●●●●● représente le vrai mot de passe ou en réalité de simples espaces. La classe SecureString exposant une propriété Length on pourrait facilement avoir une représentation visuelle du mot de passe sans avoir à le stocker en clair en mémoire.

On disposerait ainsi d’un contrôle PasswordBox vraiment sécurisé et non pas d’une sécurité en carton.

Quand à l’implémentation d’un tel SecurePasswordBox, il pourrait bien faire l’objet d’un prochain article…

image

On peut se dire que l’équipe d’Internet Explorer 9 a gagné…

On peut se dire que l’équipe d’Internet Explorer 9 a gagné en constatant qu’aujourd’hui un bloggeur peut se permettre d’écrire un post intitulé “Why Internet Explorer will survive and Firefox won’t” sans être trop ridicule.

imageIl s’agit certes d’un point de vue subjectif, et d’un avis tranché, mais qui est défendu avec des arguments intéressants et valables.  Le post est très largement discutable (je ne suis d’ailleurs pas d’accord avec ce billet) mais il reste crédible.

Et cela n’aurait pas du tout été le cas encore hier… Le même auteur aurait eu la même crédibilité en écrivant l’exact contraire. Et je trouve que ce changement de situation est remarquable.

J’avais déjà bloggé à différentes reprises (Compte Rendu PDC 2010 et Les nouveautés d’IE 9) sur le fait que j’étais impressionné par le travail d’engineering réalisé par l’équipe d’Internet Explorer et même s’il reste des défauts non négligeables (j’y reviendrais ultérieurement via un autre post) , force est de constater que le résultat est de l’avis de toutes les personnes censées à la hauteur (voire au-dessus en ce qui concerne les performances) des autres principaux navigateurs du marché.

Il y a très clairement une part de stratégie dans tout cela, mais la concurrence y est également pour beaucoup. Tous les navigateurs ont exactement les mêmes objectifs : une performance maximale en utilisant si possible le GPU pour y arriver, le respect de standards n’existant pas encore (HTML 5, CSS 3), une ergonomie réétudiée d’un point de vue de la gestion des onglets et de la barre d’adresse (entre autres), et une simili intégration des applications web en applications “natives”. Au point que l’on peut ne plus trop voir la différence entre ceux-ci :

Loin de moi l’idée de dire qu’IE 9 est le meilleur des navigateurs, ce qui est sûr ce qu’avec la sortie d’IE 9, la disponibilité de Chrome 10, et la publication de 4 (!) versions majeures de Firefox,  c’est durant cette année 2011 que l’on devrait probablement voir se décider quels seront les leaders de ce marché !

image_312

Et oh il y a quelqu’un ?

C’est un peu le sens de la question que l’on m’a posé il y a quelques instants jours où mon interlocuteur me demandait si je connaissais des flux RSS à propos de .net intéressants et en français.

imageJ’ai en effet un “catalogue” de flux assez important que je m’efforce de maintenir régulièrement (autant en ajoutant des abonnements qu’en en supprimant) et il s’agit d’une des rares choses que j’ai toujours refusé de partager intégralement.

Mettre en place une veille technologie via RSS demande du temps, et de l’expérience pour arriver à ce qu’une veille journalière soit simple et rapide à faire, bref, pour qu’elle soit efficace. Je ne souhaite donc pas partager l’intégralité de ce travail de fourmi mais j’en partage à l’occasion un extrait par thème pour indiquer par exemple, quels sont les meilleurs flux sur WPF, sur TFS, etc. Je partage néanmoins certains résultats de ma veille via les News de la semaine.

Revenons donc à nos flux français, et sans avoir besoin de trop réfléchir, je sais déjà que la majorité des flux FR auxquels je suis abonné ne sont pas des flux RSS techniques (alors que la très grande majorité de l’ensemble des flux auxquels je suis abonné l’est…)

Afin d’avoir une idée plus précise je me suis donc lancé dans un parcours manuel, et je vais partager cette liste avec vous :

Lionel Limozin http://www.paslatek.net/ [14/03/11]
Romain Verdier http://codingly.com/ [18/04/10]
Mitsu Furuta http://mitsufu.wordpress.com/ [21/12/10]
Guillaume Belmas http://blogs.codes-sources.com/kangoo/default.aspx [28/10/10]
Michel Perfetti http://blogs.codes-sources.com/miiitch/default.aspx [14/03/11]
Guillaume Andre http://www.guillaumeandre.com/ [07/11/10]
David Catuhe http://www.catuhe.com/ [14/03/11]
Benoit Laut http://benoitlaut.net/ [11/03/11]
Simon Ferquel http://www.simonferquel.net//blog/Default.aspx [14/06/10]
Sebastien Pertus http://www.dotmim.com/ [02/03/11]
Guillaume Lacasa http://blog.adhess.net/ [01/03/11]
Etienne Margraff http://blogs.codes-sources.com/etienne/ [08/03/11]

Quelques remarques à propos de cette liste :

  • Je connais personnellement toutes ces personnes. Je pourrais m’auto congratuler en me disant que c’est le résultat d’un excellent networking mais je pencherais plutôt vers une interrogation plus primaire “Euh… Mais ils sont les où les autres, on est les seuls à faire du .net ?”
  • L’exacte moitié d’entre eux sont des anciens collègues
  • Et une moitié seulement ont blogué quelque chose… depuis le  début de l’année
  • En plus de ces flux, je consulte assez régulièrement les blogs de CodeS-SourceS, je m’abonnerais volontiers à certains d’entre eux mais je DETESTE m’abonner à des flux qui n’exposent pas leur contenu en entier. Je considère que l’objectif du RSS est de syndiquer du contenu et non des résumés, il faut donc que je considère que la valeur ajoutée du blog soit assez importante pour que je transige à cette prise de position.
  • En volume, cette liste représente … moins de 5% de mes flux.

Bloguer (et qui plus est régulièrement) est compliqué et nécessite d’y investir BEAUCOUP de temps. Même si l’on trouve au tout début la motivation pour arriver à consacrer le temps nécessaire à cette activité, il n’en reste pas moins que faire vivre un blog tout au long de l’année est une tâche hardue. Il n’est donc pas très étonnant de voir ce faible nombre de flux et de constater que l’activité de ces flux est en moyenne assez faible.

De plus, une bonne partie de ces blogs fournissent un contenu qui (et ce n’est que mon avis personnel) ne devrait pas être dans un blog. Le contenu est souvent assez structuré pour ne pas être présenté sous la forme d’un post qui sera lu uniquement par les lecteurs du blog mais devrait faire l’objet d’un article posté sur un des sites communautaires disponibles en France. (ASP-PHP.net, TechHeadBrothers, pour ne citer qu’eux)

Ces sites permettent d’avoir une visibilité bien supérieure que sur les blogs et permettent de syndiquer du contenu de bonne qualité puisque relu et validé par ses administrateurs / modérateurs. Je pense que le premier réflexe des auteurs est de se dire que le temps investi dans la rédaction d’un article doit leur revenir directement et intégralement. Ce sentiment est légitime mais je reste convaincu qu’il s’agit d’une démarche contre productive pour les raisons évoquées ci-dessus.

Bon maintenant que je me suis permis d’indiquer que je pensais qu’il y avait moyen de bien mieux faire pour animer et faire vivre la « communauté », je me dois de partager quelques idées/pistes :

  • Mettre en place des blogs multi-auteurs. Parvenir à publier des posts (intéressants et intelligents qui plus est) tous les jours de l’année à 07:00 du matin, et avoir plus d’une année de posts d’avance est réservée à une élite unique, il est inutile de songer à atteindre un tel niveau. La solution si l’on souhaite publier régulièrement des posts de qualité autant sur le fond que la forme (pour le fond et la forme  Codingly est une bonne référence) est de s’y mettre à plusieurs. Si Jean Marc Morandini l’a compris depuis des années, je suis persuadé que des développeurs peuvent faire de même !
  • « Laisser tomber les blogs » et écrire des articles !

Pour conclure, je tiens à préciser que l’intégralité de ce post ne reflète que mon avis personnel (même si je sais que les idées décrites sont partagées par les quelques personnes qui l’ont lu avant publication) et c’est d’ailleurs bien pour cette raison que cela fut l’objet d’un post de blog et non d’un article 😉

Et vous qu’en pensez-vous ?

image

Session Ergonomie aux TechDays 2011

Je viens de regarder la session “Changer la vie de vos utilisateurs en intégrant design et ergonomie” (étrange d’avoir un nom aussi long pour une session sur l’ergonomie…) d’un de mes ex-collègues Olivier Courtois de la société Bewise.

Cette session est très réussie tant au niveau de la forme (je n’en attendais pas moins de la part d’Olivier) que du fond.

Je vous invite donc à la visionner si vous vous intéressez de près ou de loin à ce sujet.

image

Suite à cette présentation, je me suis décidé à tester cette “conception centrée utilisateur” présentée dans cette session, sur le développement de ma prochaine fonctionnalité.

Je ne suis pas designer ni ergonome, je vais donc uniquement donner mon point de vue de développeur sur cette méthode de travail et pourquoi je me suis décidé à l’expérimenter.

L’objectif de débuter par la conception et la réalisation de l’interface utilisateur au lieu de débuter par la conception et l’écriture de code pour les couches sous-jacente est tout à fait pertinente puisqu’elle permet de se concentrer sur le principal acteur de votre application : l’utilisateur.

Celui-ci se moque éperdument de savoir si vous écrit du code ADO.net à la mano ou si vous avez utiliser le dernier ORM à la mode.

Les seuls interlocuteurs qui peuvent vous reprocher du code écrit avec les pieds et/ou non maintenable sont :

  • les développeurs de votre équipe qui vont potentiellement vous écharper d’avoir écrit du code en carton
  • vos responsables (chef de projet, n+1, etc.) qui verront d’un mauvais œil le fait qu’il soit nécessaire de passer 3 siècles à maintenir et faire évoluer une fonctionnalité qui certes est très bien d’un point de vue UI mais coute au final très cher en développement

Le fait de débuter par la création de l’UI présente les avantages suivants :

  • permet de faire des itérations de validation de la fonctionnalité d’un point de vue de son utilisation avant même de penser à l’implémentation technique sous-jacente.
  • Permet de ne pas bâcler l’UI et l’ergonomie. Si je dois mettre 5 jours à implémenter une fonctionnalité, et que je commence par la partie la plus technique, il y a des chances que le temps consacré à l’UI soit réduit, et que les solutions adoptées soient les solutions “au plus vite”
  • Permet d’éviter l’over-engineering. Si le développeur attaque débute par le développement de l’UI il y a de fortes chances qu’il n’est ensuite plus le temps de réfléchir à implémenter une solution technique inutilement complexe.

Il ne me reste plus qu’à expérimenter tout cela, que cela soit d’un point de vue du process (sketchs, itérations de validations, puis dév) que des outils (balsamiq, SketchFlow, etc.). Je ne manquerais pas de partager avec vous mes premiers retours à ce sujet !

Wordpress

A y est !

image

Afin de célébrer l’arrivée du printemps, et mon 2000ème tweet (oui je tweete plus que je ne bloggue…), j’ai enfin quitté la plate-forme désuète que j’utilisais depuis bien longtemps afin de me mettre sur la plate-forme avec l’ecosystème le plus riche : WordPress.

Les objectifs que je souhaitais atteindre en migrant étaient simples :

 

 

  • Ne plus devoir coder pour personnaliser mon blog, mais me reposer sur les différents plugin existants
  • Avoir la possibilité d’avoir assez simplement un blog un peu plus agréable graphiquement (oui, je sais ce n’était pas compliqué de faire mieux…)
  • et enfin avoir un meilleur référencement grâce aux capacités “naturelles” d’un moteur de blog robuste et optimisé.

Et comme la ‘”tradition” le veut, je vous propose donc un petit post mortem du déroulement de la migration.

Mais avant de commencer cette description, je tiens à remercier Guillaume André pour avoir réalisé l’image du bandeau du blog !

Il a en effet réussi à transformer mon magnifique dessin de développeur :

Sans titre

en un résultat bien plus agréable pour vos yeux (et pour les miens Sourire ) :

Sourire

L’installation de WordPress fut très simple grâce à l’utilisation de Web Platform Installer. Toutes les dépendances nécessaires s’installent toutes seules comme des grandes, et on se retrouve ainsi en 5min avec un WordPress fonctionnel.

Premier défi : l’import des posts existants. Je ne partais pas en effet de zero puisque je souhaitais récupérer un peu plus de 200 posts. La majorité des bloggeurs qui ont réalisé ce type de migration ont utilisé le langage BlogML. Après avoir fait quelques tests, j’ai constaté que je perdais pas mal de formatage et de mise en page en utilisant cette technique j’en ai donc utilisé une différente : le RSS !

J’ai donc configuré DasBlog pour exposer l’intégralité de mes posts dans mon flux RSS et importer ce flux dans WordPress qui propose un importer “in the box”.

Mission réussie, il a ensuite été nécessaire de recatégoriser l’ensemble de ces posts.

DasBlog ne supporte que les tags et ne supporte pas les catégories contrairement à WordPress. Après avoir utiliser le converter de Catégories/Tags, j’ai donc créé un ensemble de catégories et j’ai ensuite donc classés manuellement les posts selon ces catégories… Il s’agit de la première opération couteuse en temps. J’ai mis un peu moins d’1h30 pour effectuer le classement des 218 posts.

Comme de plus en plus de thèmes, celui que j’utilise à présent propose des miniatures d’images. Ces miniatures d’images sont à définir manuellement dans l’interface d’administration de wordpress lorsque l’on poste un nouveau contenu. N’allant pas faire manuellement chaque post afin de définir ces miniatures je me suis donc tourné vers le plugin nommé “Auto Post Thumbnail”.

Ce plugin permet d’automatiquement générer une miniature en fonction du contenu du post que l’on insère. Et il propose même de parcourir l’intégralité du contenu d’un blog afin de regénérer l’ensemble des miniatures. Et la bonne nouvelle est qu’il remplit parfaitement son job.

image

Et j’ai ensuite terminé cette migration par la tâche la plus complexe : la mise en place de redirections 301 afin d’éviter que cette migration ne génère beaucoup de liens mort.

Et cette opération a été bien plus douloureuse que ce que j’avais anticipé malgré les différentes recherches que j’avais effectué afin de préparer cette migration.

Premier constat, les redirections sont souvent négligées dans la plupart des articles décrivant la migration de DasBlog vers WordPress. Quand elles ne sont pas complètement oubliées, elles sont réalisées d’une manière assez approximative.

La technique la plus utilisée consiste à créer des regex pour transformer automatiquement d’anciennes url vers le nouveau modèle d’urls. Un système qui peut convenir pour une majorité de posts mais en aucun cas pour l’intégralité.

Je me suis donc tourné vers le plugin le plus utilisé dans ce cadre : “Redirection”.

Afin de créer l’intégralité des redirections, j’ai donc souhaité créer un fichier csv qui permettent d’effectuer le matching de toutes les urls.

Et pour cela j’ai utilisé une technique très simple bien qu’apparemment personne ne l’utilise, j’ai utilisé tout simplement les fichiers sitemaps de l’ancien blog et du nouveau ! Les fichiers sitemaps sont un catalogue de l’ensemble des contenus d’un blog, il s’agit donc de l’élément idéal pour effectuer le matching.

Ce matching a de plus été effectué très simplement puisque je n’ai appliqué qu’un simple tri alphabétique sur les urls regroupées pour avoir un matching exact à 100%.

image

Je me suis arracher les cheveux pour arriver à faire comprendre mon beau csv au plugin Redirection… Pour finalement laisser tomber en concluant que ce plugin ne fonctionne pas avec IIS…

Je me suis donc tourné vers une solution de plus bas niveau, le module d’url rewriting de IIS7 qui permet d’effectuer des redirections d’url.

Ce module stocke dans le web.config les urlmaps que l’on définit, j’ai donc écrit une moulinette afin de transformer mon csv en éléments xml que j’ai inséré dans le fichier de config pour parvenir à mes fins.

Et me voilà donc enfin sur wordpress, avec un blog fonctionnel et personnalisable que je vais pouvoir m’empresser de remplir de contenu !

Blog en Travaux

Ce blog est en travaux pendant (j’espère) quelques heures. Je quitte en effet la plate-forme DasBlog (qui ne vit plus) pour rejoindre la communautés des utilisateurs de la plate-forme la plus populaire au monde : WordPress !

Je vais donc m’attacher à migrer les anciens posts sur ce nouveau blog, bien évidemment l’adresse du blog de change pas, tout comme le feed RSS qui reste le même !

Oui, j’effectue cette migration en live (en ayant préparé un minimum quand même…), ce blog n’est pas une application en production mais un simple blog, cela n’est donc pas grave s’il est offline pendant quelques heures !

Log de migration :

[13:21] Installation WordPress OK

[13:27] Installation Rewriting OK

[13:40] Installation Thème OK

[13:50] Posts importés OK !

[14:35] Re-Catégorisation des 219 posts OK

[15:55] Victoire ! Problème des thumbnails résolu !

[18:40] Redirections 301 dans url dans anciens posts vers les nouvelles URL OK !

[18:45] Migration terminée !

news

News de la semaine #9

imageEric
Lippert nous rappelle les
best practices à appliquer concernant la méthode GetHashCode
.

L’équipe de la TPL nous montre un
exemple d’utilisation du Concurrency Visualizer fourni avec VS 2010.

Du côté de l’actualité produits, JetBrains propose des
previews de dotCover 1.1 et dotTrace 4.5
.

Microsoft annonce la
fin du projet Axum
.

MonoDevelop
2.6 est disponible en béta
.

Le Snippet
Designer est disponible en 1.3.1

Les
PowerTools de TFS 2010 sont disponibles dans leur nouvelle version de Mars.

Du côté de l’actualité française, Lionel Limozin présente comment
installer son environnement de développement pour développer pour Windows Embedded
avec “Silverlight”
.

Benoit Laut propose un
article sur Entity Framework et les requêtes générées par cet ORM
.

Faites vraiment attention avec les BitmapEffect

Lors d’une session de profiling CPU effectué durant une session de test de l’application
sous TSE, je me suis rendu compte que l’application sur certaines sessions utilisateurs
essayait de pomper 100% du CPU. Et avec grande surprise, quand j’ai demandé aux testeurs
s’ils effectuaient des traitements longs et couteux, certains m’ont indiqué que non
pas du tout, ils étaient juste devant une fenêtre qui affichait une petite grille
avec quelques lignes.

Après vérification, la fenêtre était très simple, et lorsque l’on ouvre ou ferme la
fenêtre le CPU passe d’aux alentours de 0% à 100% alors qu’aucun traitement n’est
censé se dérouler. Bien évidemment le problème n’a pas été détecté jusqu’à présent
puisqu’utilisé ailleurs que dans une session TSE, ce comportement n’est pas reproductible.

On passe donc doucement aux choses sérieuses, et ne connaissant pas encore correctement
l’application sur laquelle je travaille, je lance Snoop afin de trouver le nom de
la fenêtre incriminée et je commence mes premiers tests afin d’affiner ma réflexion
et mieux cibler les potentielles sources de problèmes.

Snoop est un utilitaire gratuit disponible
sur CodePlex
qui permet de parcourir agréablement l’arbre de contrôle de n’importe
quelle application WPF. Il permet, de plus, de modifier les propriétés de ces contrôles
afin de voir l’impact que cela peut avoir sur l’interface… et/ou le comportement de
l’application. Il s’agit d’un de mes outils préférés de debug d’applications WPF.

Et première piste, je me rends compte que si je collapse un des usercontrol présent
dans la fenêtre, le CPU continue d’être à un haut niveau mais baisse de manière assez
notable.

Rendez-vous donc dans le code de ce usercontrol, je me rends compte qu’il y a un backgroundworker
qui est utilisé, que beaucoup d’évènements sont déclenchés, mais pas de trace flagrante
d’un traitement bloquant.

Afin d’analyser plus finement le comportement de ce background worker, et de ces évènements
qui me semblent à première vue potentiellement louches, je me lance donc dans une
session de profiling CPU afin de pouvoir rapidement détecter le point qui pose problème.
J’utilise pour cela le profiler de Visual Studio 2008 Team Suite, et je compare les
résultats avec les résultats proposés par dotTrace.

Après avoir “nettoyé” plusieurs points ennuyeux qui parasitaient ma lecture du rapport
du profiler (essentiellement des appels de ressources I/O, réseau, etc. effectués
en synchrone), je commence à faire une grosse grimace en me rendant compte que le
CPU passe beaucoup de temps non pas à exécuter du code managé (ce qui m’aurait permis
de comprendre simplement où était l’erreur de développement) mais le passe à exécuter
du natif. Bref, ça sent vraiment pas bon, et d’un potentiel problème de développement
je me retrouve sur un problème qui risque d’être beaucoup plus compliqué à résoudre.

Etant dans une application WPF, il y a de bonnes chances que ce temps passé à exécuter
du natif soit du temps passé à exécuter du code lié à l’affichage. Je retourne donc
au sein de Visual Studio afin d’analyser le XAML du usercontrol que j’avais “spotté”
via Snoop et rien ne me choque, je remonte donc l’arbre de contrôle pour essayer de
trouver une piste, et je me rends compte que la fenêtre qui contient le usercontrol
n’a pas de bordure et à l’AllowTransparency d’activé. Ce sont des éléments potentiellement
couteux mais même désactivés le CPU ne souhaite toujours pas prendre de repos.

EasyDropShadowExamplesAlors
qu’une simple suppression du DropShadowEffect qui a été placé à l’intérieur de cette
fenêtre permet de passer d’une consommation de 100% à quelques % ! Et je dois bien
avouer que ce fut pour moi une vraie surprise, tout le monde sait que les
BitmapEffect sont lents et couteux comme je vous l’indiquais il y a presque 3 ans
,
mais de là à prendre 100% du CPU il y a quand même un pas… que WPF a franchi dans
certaines conditions sous TSE !

Conclusion de ce post mortem de séance de tests : Faites donc particulièrement attention
à l’utilisation des BitmapEffects si votre application doit être utilisé via TSE !