Archives de catégorie : Clients riches

image

Ressources supplémentaires sur le développement d’applications métier (LOB) pour Windows 8 et WP8

Comme indiqué précedemment, j’ai eu l’opportunité de présenter une session sur le développement d’applications métier pour Windows 8 et Windows Phone 8 avec la précieuse aide d’Audrey Petit.

image

Nous avons évoqué une grande variété de sujets (Opportunités, Déploiement (via le Store ou déploiement privé), Ergonomie Modern UI, Stratégies, Transition vers ModernUI, etc.) et n’avons donc pas pu approfondir tous ces sujets en 1h.

En fonction des Q&A de fin de session, je vous propose donc une liste de ressources complémentaires qui vous permettra d’aller plus loin sur certains points.

Pour débuter cette liste de ressources, je vous propose en plus des différentes démonstrations que nous vous avons montré, un case study sur le développement d’applications métier pour Win8.

Du côté utilisateur, voici un post de blog indiquant comment Utiliser des applications d’entreprise avec Windows 8 [US]. La fonctionnalité est présentée dans le contexte “Bring your own device” mais correspond tout à fait à celle indiquée durant la session.

Du côté IT, pour le déploiement des applications via Intune et l’app portail d’entreprise vous pouvez consulter cette présentation très complète sur le déploiement d’applications d’entreprise pour Windows Phone [FR]

Si vous souhaitez une synthèse du processus de déploiement que nous avons décrit vous pouvez également consulter ce post ainsi que ce post rentrant plus dans le détail de Windows Intune.

Toujours sur Windows Intune, Channel9 propose une démo en vidéo du process de déploiement.

Nous avons également parlé des possibilités de déploiement via scripts, vous trouverez sur cette page la documentation sur ceux-ci mais également sur la suppression des applications comme demandé durant la session de Q&A.

A propos de la question sur la possibilité de créer des applications ASP.net avec le look ModernUI, vous trouverez ici un ensemble de ressources permettant d’y arriver avec présence des plugin jQuery que j’avais évoqué.

Et enfin pour confirmer ce que j’indiquais à propos de l’addin de storyboarding pour Powerpoint il vous faudra disposer de Visual Studio 2012 Test Professional, Premium ou encore Ultimate pour être capable d’en profiter :

image

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

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 !

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 !

image

TextChanged… ou pas (encore)…

C’est dès la première semaine où je suis arrivé chez mon nouvel employeur que j’ai
pu m’exclamer en indiquant que “Rah purée, c’est pas vrai, c’est un bug de WPF…”

Je n’ai pas vu de sourire moqueur de mes collègues mais je suis à peu près sûr que
certains d’entre eux ont dû se dire qu’il était osé de rejeter la faute du bug que
j’avais introduit sur la technologie elle-même et non pas sur une erreur d’inattention.
Et quelques recherches plus tard, je me suis rendu compte… que j’avais bien raison
!

Le scénario est pourtant très simple, il s’agit tout simplement de modifier le texte
d’une TextBox. La particularité de cette modification est que je l’ai réalisé dans
l’évènement TextChanged comme ceci :

image

Je m’attendais à voir le message “Je suis vide” après un click sur mon bouton et bien…
non, ma textbox auparavant remplie devient vide. Et pourtant je rentre bien dans ma
condition et si je mets un espion sur la valeur de la propriété Text elle est bien
définie avec ma chaine. Seul l’affichage n’est pas impacté. Bizarre non ?

Et bien je me suis conforté dans l’idée qu’il s’agissait d’un bug, lorsque je n’ai
pas réussi à reproduire le soucis dans une application .net 4.0. En effet si l’on
fait le test dans VS 2010 et que l’on change de version de framework on se retrouve
avec l’effet désiré ou non !

[Update] Je vous propose ci-dessous le projet de test afin que vous puissiez changer
la version du framework et voir le changement de comportement :

<br />

image

Silverlight bientôt sur la XBOX

J’indiquais il y a quelques semaines qu’il était possible que Silverlight arrive prochainement
sur la télévision, et bien nous avons présent la confirmation qu’il y a de fortes
chances que cela soit le cas.

image

Confirmant la stratégie “3 screens and a cloud”, Silverlight sera la couche UI vous
permettant de cibler les trois types d’écrans ciblés par Microsoft à savoir : le PC
(en in et out of browser), le téléphone avec Windows Phone 7, et enfin la XBOX puisque
l’éditeur a posté une offre d’emploi plus qu’explicite (avant de la corriger) :

image

Même si cela
avait déjà été évoqué l’année dernière, à propos de streaming vidéo et de création
de bannières publicitaires cross platform
, cela pourrait être une excellente nouvelle
si Microsoft cible un des scénarios suivants :

  • Permettre aux développeurs de créer des applications tierces pour XBOX en étandant
    l’AppHub pour le moment destiné aux jeux XNA pour XBOX
  • Permettre aux développeurs d’accès au Smooth Streaming (déjà utilisé au sein de la
    XBOX) afin de pouvoir accéder directement sur sa TV à des applications ou sites orientés
    vidéos (comme Channel9 par exemple)

Facebook, Twitter (des vrais applications pas celles avec les avatars XBOX ;)), Skype,
Live Messenger tout cela sur votre TV, c’est peut-être pour demain !

Source : http://www.mobiletechworld.com/2010/11/23/silverlight-headed-to-the-xbox-but-microsoft-doesnt-want-you-to-know-about-it-yet/

image

L’avenir de Silverlight

Il y a beaucoup de spéculations sur l’avenir de Silverlight depuis quelques jours,
beaucoup de personnes annonçant la mort de cette technologie : https://twitter.com/#!/search/silverlight%20dead

S’en est suivi un grand nombre d’articles, de tweets, de posts de blogs affirmant
que Silverlight est mort, ou au contraire que la technologie est bel est bien toujours
d’actualité et continuera d’évoluer.

imageProcédons
à un rappel des faits pour comprendre l’agitation actuelle autour de Silverlight.

L’évènement de l’année destiné aux développeurs Microsoft a eu lieu en fin de semaine
dernière à Seattle. La PDC est traditionnellement l’évènement où ont lieu les annonces
concernant les technologies qui seront proposées par l’éditeur dans 1, 2 ou 3 ans.
Lors du keynote de l’édition de cette année, le géant de Redmond n’a quasiment pas
parlé de Silverlight si ce n’est de son utilisation pour le développement d’applications
Windows Phone 7. A contrario, l’éditeur a mis l’accent sur Internet Explorer 9 et
les standards liés au web tels qu’HTML 5. La même mise en avant a été faite dans le
contenu de la conférence en elle-même. IE 9 et HTML5 et Windows Phone 7 ont été privilégié
et Silverlight a été étrangement absent (ou tout du moins peu présent) durant la conférence.

Surprise par cette faible présence Mary Foley -célèbre journaliste spécialisée sur
l’actualité de Microsoft depuis de nombreuses années – a
donc interrogé Bob Muglia
Président de la division Serveurs et Outils à ce sujet. Et
la réponse de celui-ci a été surprenante puisqu’il a indiqué à Mary Jo Foley que “Silverlight
est la plate-forme de développement pour Windows Phone” et que la stratégie visant
à faire de Silverlight une plate-forme de développement multi-plateforme “avait changé”.

Et ce discours a provoqué d’importantes réactions sur Twitter mais également sur différents
sites technologiques tels que Mashable “Microsoft
Shifts From Silverlight to HTML
” ou TechCrunch “Microsoft
Has Seen The Light. And It’s Not Silverlight.
” pour ne citer qu’eux. S’en suivirent
une trainée de RTs et de messages indiquant que Silverlight était une technologie
morte et que Microsoft ne voyait l’avenir qu’au travers d’HTML 5.

Qu’en est-t-il réellement ?

Bien que rien n’ait été présenté à la PDC10 à ce sujet, Silverlight 5 est bel et bien
en route comme a pu le présenter l’équipe durant le mois de Septembre : http://team.silverlight.net/announcement/the-future-of-silverlight/ Silverlight
est donc bel et bien vivant, il reste à comprendre son positionnement par rapport
à HTML 5 afin de clore ce débat.

Et ce positionnement a été très clairement évoqué par Steve
Ballmer il y a un mois lors du Gartner Symposium
. A la question “Quel est la principale
stratégie de Microsoft concernant le développement d’applications RIA ? Silverlight
ou HTML 5 ?”, Ballmer répondit très clairement que pour “le développement d’applications
“universelles” c’est à dire réellement multiplateforme, il n’y aucune question à se
poser la direction à prendre est HTML 5”. “L’industrie pousse fortement HTML 5 pour
répondre à ce genre de problématique, Microsoft compris.”

Quand à Silverlight, il s’agit certes d’un runtime multi plate-forme et multi-browser,
mais Microsoft a surtout développé une plate-forme de développement d’applications
clientes pour PC, Windows Phone, etc. Il confirme au passage ce que Bob Muglia a indiqué
à Mary Jo Foley à savoir que Silverlight prenait donc cette direction qui n’était
pas celle prévue à la naissance de la technologie (lorsqu’elle était encore nommée
WPF/E pour WPF Everywhere).

Donc non, Silverlight n’est pas mort ! Cette technologie est destinée
à compléter HTML 5 là où le standard ne répond pas aux besoins du marché (au niveau
de la gestion des médias par exemple) et au développement d’applications clientes
sur différents types de devices : le PC, le Windows Phone, et pourquoi pas dans le
futur la télévision.

Update
: Bob Muglia a posté sur le blog de l’équipe Silverlight afin de donner la position
officielle de Microsoft.
<br />

image

WPF et Option Strict

Débutant une formation WPF la semaine dernière chez un client, je me suis retrouvé
sur un problème intéressant : lors de la création de projets WPF, le code généré par
Visual Studio ne compilait pas. Inutile de vous dire qu’il s’agit du genre d’incidents
qui jette un rapide discrédit sur la technologie ce qui n’est évident à gérer en début
de formation…

Le problème est lié à l’utilisation du langage VB et de la directive Option Strict.
Si vous êtes un développeur VB sérieux et rigoureux vous avez très probablement activé
l’option strict afin d’éviter d’autoriser le compilateur à ne pas signaler les opérations
de cast plutôt hazardeuses. Seul problème, le code généré par les templates de projet
de WPF n’est pas compatible avec cette vérification du compilateur si vous utilisez
Visual Studio 2008 RTM :

image 

En effet si vous éditez le fichier MyWpfExtensions.vb présent au sein de votre projet
vous trouverez la ligne de code fautive :

Friend ReadOnly Property Application() As Application
    Get
        Return Global.System.Windows.Application.Current
    End Get
End Property

Il est nécessaire de modifier le code du getter afin d’ajouter un cast explicite afin
que le code compile correctement :

Friend ReadOnly Property Application() As Application
      Get
          Return CType(Global.System.Windows.Application.Current, Application)
      End Get
End Property

La solution pour résoudre ce problème est simple : il vous faut installer
le Service Pack 1 de Visual Studio 2008
.

Autre solution si avez un besoin très urgent du correctif, vous pouvez directement télécharger
les templates mis à jour sur cet article de la KB de Microsoft
.