Stumpy

 

Faire une application Silverlight c’est bien.

L’exposer sur le web, c’est mieux.

Avoir des utilisateurs c’est top.

…Mais combien d’utilisateur j’ai ? Et que font-ils sur mon application ?

Genre la feature de la mort qui tue que j’ai mis 2 semaines à dev est-elle utilisée ?

Appart aller faire du porte à porte auprès de vos utilisateurs, ce genre d’informations n’est pas facile à obtenir (quoique le porte à porte ne l’est pas non plus)

Bien sûr il est possible d’envisager de se recoder une petite librairie qui va loguer l’ensemble des actions de vos visiteurs et ensuite passer encore des jours entiers à vous faire un panel pour voir l’ensemble de ces informations de façon pratique.

Ou bien…il vous suffit d’utiliser Silverlight Analytics Framework qui fait le café pour vous.

Ce Framework est juste bien fait .

Son nom devrait je trouve évoluer car même si au départ penser pour du Silverlight, il est maintenant compatible avec l’ensemble des technologies WP/E (WPF, Silverlight, WP7).

Son but est d’offrir de manière très simple une manière de logguer les actions des utilisateurs sur nos applications et au lieu de refaire le monde, utilisez les panels qui existent déjà pour nous afficher l’ensemble des informations collectées.

Prenons un exemple concret :

Vous avez une page de votre application qui porte le doux nom de MyKillerFeature qui contient un truc qui déchire tout sur le plan technique, il serait bon de savoir si vos utilisateurs s’en servent.

Le Framework va vous permettre de savoir d’un part si vos utilisateurs cliquent sur le lien de votre page mais également le temps qu’ils passent dedans et/ou les actions qu’ils font dedans.

Et c’est là que vous allez vous rendre compte que même pas 10% vont voir et qu’en moyenne ils y restent moins de 5 secondes tellement la KillerFeature est sans intérêt pour eux, simple et pauvre user  lambda:).

Mais comment cela marche me direz-vous ?

Simplement je répondrais !

Tout ce fait dans Blend (rien ne vous empêche de loguer des choses dans le code-behind !) d’une façon vraiment simple et a la porté du premier designer venu !

Comme nous l’avons vue, la force du Framework est de se reposer sur l’existant en termes d’outil d’analyse, donc avec un peu de chance, votre favori est déjà géré par le Framework.

Une fois le Framework installé, ouvrez votre page xaml puis glisser le behavior d’analyse qui vous convient sur le layout principal, pour ma part je vais prendre googleAnalytics et le configurer avec le code UA obtenu sur mon compte Google.com/analytics.

La marche à suivre étant la même avec les autres outils d’analyse, il vous suffit de rentrer votre code de tracking(ou identifiants divers).

Voilà, nous avons maintenant fait le plus dur, oui oui !

Lors de l’ouverture du menu behavior vous avez pu voir qu’il en existe beaucoup :

· Plusieurs du type *Analytics, comme nous l’avons vu ce sont nos outils d’analyse et rien ne vous empêche d’en mettre plusieurs à la fois.

· Des Track*, ce sont ces behaviors qui vous permettent…et bien de tracker les actions utilisateurs.

Prenez un exemple simple, glissez un TrackAction vers vos boutons de menu, vérifiez que leur events sont bien réglés sur « Click » et…et bien c’est tout.

Au runtime, les behaviors vont « communiquer » ensemble pour transmettre les informations vers votre interface d’analyse, dans mon cas Google analytics.

A noter que lors de la collection des events, chaque Track* remonte le nom du contrôle auquel le behavior est attaché, il est donc judicieux de donner des noms « propres » a ses contrôles .

Je ne vais pas répéter longuement la doc en vous listant l’ensemble des behaviors disponible mais en bref :

-actions de type event classique

-action de navigation

-action de formulaire (quelles sont le top5 des recherches faites ?)

-action de type Media (combien de temps l’user moyen regarde ma vidéo avant de la stopper ?, est-il passé en fullscreen ?)

-bien d’autre (et rien ne vous empêche bien sûr d’ajouter les vôtres au besoin.

Voilà un Framework qu’il est bon et pratique .

Qui plus est, bien fait, on y retrouve des fonctionnalités agréable telles que :

· Gestion des applications Out of Browser

· Gestion du mode offline (envois des stats une fois online)

· Gestion totalement par behavior, ne réclame aucune ligne de code

· Gestion du A/B Testing (offrir une interface particulière (VisualState powered) à 10% de ses users et voir leurs réactions)

Et une liste d’outils d’analyse qui s’agrandit encore régulièrement :

La liste ne vous convient pas ? Votre outil n’est pas dessus ?

Un behavior vous permet d’indiquer un endpoint « home-made » pour les datas donc ajouter votre panel d’analyse perso ne devrait pas être bien long.

Et ensuite rien ne vous empêche de faire un behavior spécial pour votre panel et l’offrir (ou non) a d’autre utilisateur.

Le résultat ? Dans le cas de Google analytics, les statistiques sont disponible chaque nuit sur les coups de minuit, voici celle que j’ai récupéré pour mon petit sample :

On retrouve les catégories que j’ai indiquées dans mes behavior et la répartition du type d’action qui ont été logués.

Si on explore un peu les sous menu, on peut avoir de nombreux détails.

A vous d’avoir une nomination correcte pour vous y retrouver.

Voilà, je pense que nous avons fait un tour rapide de qu’est-ce que Silverlight Analytics Framework et comment l’utiliser pour obtenir un maximum d’information sur ses utilisateurs.

Mettre en place une solution de surveillance sur ses sites est devenu une habitude/obligation depuis quelques années maintenant mais ce n’est pas encore un réflexe au niveau applicatif.

Pourtant nous avons beaucoup à apprendre des habitudes de nos utilisateurs .

Je vous invite tout de même a prévenir sur vos applications que des informations quand a son utilisation sont envoyées , offrir un moyen d’activer ou non cette option est également des plus conseillé pour éviter tout ennuis.

L’activation ou non peut ce faire simplement avec quelques lignes de code.

Le problème de mélanger ces deux technologies que sont WPF et XNA existe depuis leurs débuts, chacune étant fort performante dans son domaines mais dans certains cas, nous aimerions bien pouvoir mixer les deux.
Au hasard, un éditeur d’environnement pour jeux vidéo .

Il existe plusieurs solution plus ou moins viables, on peut citer par exemple le classique WindowsFormHost qui marche mais implique certaines limitations comme l’impossibilité de poser des contrôles WPF par-dessus le rendu XNA.
Valentin Billotte propose quant à lui une méthode différente et qui pour l’avoir vu tournée marche plutôt bien mais certains ont quelques réticences pour l’utiliser en raison de son principe de superposition des rendu

Par le biais de mon travail de recherche sur le produit Artlantis.com, une idée a germée dans mon esprit mais est restée bien longtemps tranquille par manque de temps.
Il y a peu, je suis tombé sur un forum ou quelqu’un évoquait cette même idée mais n’avait pas vraiment fait de proof-of-concept donc je me suis dis que c’était le bon moment !

Une fois expliqué en détail le process, un de mes collègues sur le projet de fin d’étude que je lead (PrismEngine), Alexandre Bossard nous a mis rapidement en place ce proto pour démontrer que oui cette solution est viable !
La solution a été un peu retouché car est maintenant notre méthode de rendu au sein de notre éditeur mais voici la marche à suivre si vous souhaitez essayer cette méthode qui pour le moment ne nous a pas déçu.

A noter que cette solution est viable pour un éditeur mais je ne promets rien pour un jeu , d’une part utilisation de WPF donc aucune porta sur Xbox360/Zune/WP7 mais surtout malgré un FPS tout à fait correct, la transformation reste couteuse.

Son avantage est de garder toute la puissance de WPF, avec une modification minimum de votre class Game coté XNA.
La seule chose « contraignante » est la partie input qu’il faut légèrement surcouché car on ne travail plus directement sur le rendu XNA mais une simple Image WPF.
Oui, oui, une simple Image WPF donc aucuns soucis pour y ajouter divers contrôle, effet graphique et autre choses marrantes .

Voici la marche à suivre pour faire le premier proto, une bonne réorganisation est utiles pour rendre les choses plus élégantes mais allons au plus simple pour comprendre l’idée!
Dans l’ordre nous aurons besoin de :
1. Un projet XNA pour PC que l’on compilera sous forme de library et non exécutable (pour pouvoir l’embarquer au sein de l’appli WPF
2. Une appli WPF dans laquelle on ajoute une référence vers Microsoft.Xna.Framework.Game

Préparons notre class Game maintenant :
On y ajoute quelques « helpers » qui vont nous servir a faire le gros du travail

RenderTarget2D target; // Nous allons dessiner notre scene dedans
public WriteableBitmap bitmap = new WriteableBitmap(800, 460, 96, 96, System.Windows.Media.PixelFormats.Bgra32, null); // l'image que nous donnerons a WPF pour l'éditeur
Color[] colors = new Color[800 * 460]; // le tableau pour remplir notre image
private System.Windows.Threading.DispatcherTimer timer; // un timer, nous allons nous passer du cycle XNA classique donc il faut simuler nos ticks

Au sein de votre Constructor, nous allons ajouter 3 choses:

// on fix une hauteur et largeur en rapport avec notre image, bien sur ensuite ce morceau se devra de gérer les changements de résolution au runtime
this.graphics.PreferredBackBufferHeight = 460;
this.graphics.PreferredBackBufferWidth = 800;
this.graphics.ApplyChanges();
//on appel différentes méthodes de la classe Game manuellement, nous ne passerons pas par le cycle XNA donc c'est a nous de le faire
this.Initialize();
this.LoadContent();
//on lance le timer qui va nous permettre de gérer nos Ticks
this.timer = new System.Windows.Threading.DispatcherTimer();
this.timer.Interval = new System.TimeSpan(5000);
this.timer.Tick += new EventHandler(this.EngineTick);
this.timer.Start();

dans le LoadContent, nous allons initialiser notre RenderTarget:

this.target = new RenderTarget2D(graphics.GraphicsDevice, 800, 460, false, SurfaceFormat.Bgra4444, DepthFormat.Depth24, 0, RenderTargetUsage.DiscardContents);

Et viens la seule partie qui implique vraiment quelques changements dans votre code, la méthode Draw.
Au lieu de le faire de manière classique, nous allons rendre l’image dans notre texture puis ensuite copier son contenu au sein de notre WriteableBitmap qui sera l’image que nous donnerons a l’interface WPF.

protected override void Draw(GameTime gameTime)
{
    graphics.GraphicsDevice.SetRenderTarget(target); // on indique que l'on veut rendre dans notre RenderTarget
    GraphicsDevice.Clear(Color.CornflowerBlue);

    // TODO: Add your drawing code here

    base.Draw(gameTime); // on rend notre scene
    graphics.GraphicsDevice.SetRenderTarget(null);
    target.GetData<Microsoft.Xna.Framework.Color>(colors) // on recupere les pixels de notre scene
    // Bridge wpf/xna
    // Nous allons ecrire dans notre WriteableBitmap et lui assigner les pixels de notre scene
    bitmap.Lock();
    unsafe
    {
        int bb = (int)bitmap.BackBuffer;
        foreach (Microsoft.Xna.Framework.Color color in colors)
        {
            *((int*)bb) = color.B | (color.G <<  8 ) | (color.R << 16) | (color.A << 24);
            bb += sizeof(IntPtr);
        }
    }
    bitmap.AddDirtyRect(new System.Windows.Int32Rect(0, 0, 800, 460));
    bitmap.Unlock();
}

On remarque que l’utilisation d’un peu de code unsafe est obligatoire, la doc msdn est d’accord avec nous sur ce point, pensez donc bien a activé le code unsafe dans les propriétés de votre projet.

Dans notre Windows WPF, il nous suffit maintenant d’instancier notre classe Game mais au lieu de faire appel à la méthode Run qui va d’elle-même créer une fenêtre de rendu et faire appel aux méthodes Init, load,…, chose que nous ne voulons pas, nous allons laisser faire notre Constructor légèrement modifié.

Voici le code-behind de ma fenetre de test :

public partial class MainWindow : Window
{
    XNAPart.Game1 game;

     public MainWindow()
    {
        InitializeComponent();
        this.Init();
    }

     private void Init()
    {
        this.game = new XNAPart.Game1();
        // le fichier XAML de notre Windows comporte un controle de type Image qui porte le nom "Preview", on lui assign l'image de notre jeu
        this.Preview.Source = this.game.bitmap;
    }
}

Pas trop compliqué pour un résultat vraiment sympa et agréable à utiliser .
Petite preview avec le rendu XNA dans l’image du haut, un petit bouton par-dessus et un coup de visualBrush à partir de notre Image, chose impossible par exemple avec la méthode du WindowFormHost.

La politique de Microsoft avec sa nouvelle gamme de techno est d’offrir un ensemble d’outil permettant une création rapide de logiciel mais également avec une forte personnalisation.

WPF et Silverlight reposent tous deux sur .Net et ce qui nous concerne dans cet article et qui fait leurs forces sur le langage XAML (eXtensible Application Markup Language).

Langage permettant une vrai interaction avec le code métier tout en restant bien séparé (oui oui, c’est possible).

Nous n’en somme plus aux outils qui génèrent des lignes de code (quoi que si on s’enfonce dans le processus d’exécution, on en revient forcement a cela) comme nous avons pu connaitre avec l’ère des WinForms par exemple.

Cette façon de faire, Apple la compris avec Cocoa qui stock ses interfaces dans du xml, Microsoft quand a lui a opté pour enrichir quelque peu tout cela pour en faire du xaml.
J’évoque ce point car au sein de mon travail je côtoie de très proche Cocoa et j’aime les comparer et voir les forces et faiblesses de chacun (De bons points partout !).

Nous le voyons de plus en plus sur l’ensemble des plateformes, ce qui intéresse l’utilisateur n’est plus vraiment la fonctionnalité, entendre par là que cela doit marcher mais que de nos jours c’est une chose implicite (et heureusement nous aurions tendance à dire) et donc que le point central est maintenant la forme du produit.

Son style, son look, son design !

Savoir mettre en avant une fonctionnalité ne passe plus seulement par la mettre dans le manuel de l’application mais justement que ce dernier soit sans intérêt car l’ensemble des interactions homme machine soient les plus logiques et donc naturelles possible.

Un logiciel n’est donc plus créé par une équipe de développeurs mais de designers qui vont la réfléchir et prototyper en mettant en avant l’utilisation, non plus seulement le fonctionnel du produit.

Ensuite seulement, les développeurs vont sortir leurs outils bien à eux et donner à vie à l’application.

Ce processus en deux temps existe depuis toujours mais les choses étant ce qu’elle était, nous nous retrouvions soit avec une application qui fait le café mais ignoble, soit avec un œuvre d’art mais sans aucun intérêt.

Cette époque est révolue et les outils émergent pour que nos métiers deviennent de plus en plus complémentaires.

Ceux qui me connaissent savent que je suis un piètre graphiste, que le design et moi cela fait 3 mais je tente de me soigner depuis quelques temps maintenant, j’aurais même tendance à dire que malgré mon absence de talent artistique, je « pense » design avant de me jeter sur un morceau de code et c’est déjà un bien grand pas pour nous pauvres développeurs !

Bon ce discours, on le connait tous maintenant mais dans la réalité ?

Et bien les designers et autres « artistes » on les cherche encore à nos côtés en entreprise !

Alors il faut également apprendre à se servir de quelques outils nous permettant de devenir plus polyvalent sur nos créations et d’apporter cette petite touche créative sortant tout droit de nos esprits tordu et agencé a coup de if else.

Lancé il y a maintenant quelques mois, le site .Toolbox réclame d’être mieux connu de par les utilisateurs de Blend pour qui c’est leur outil de travail mais également de ceux qui lance Visual Studio donc nous les esprits tordu.

Oui il faut le reconnaitre, Visual Studio gère le fameux xaml et c’est même pratique pour faire une application minimaliste mais si on veut rentrer dans cette nouvelle ère il faut un outil adapté, le fameux Blend.

.Toolbox est organisé comme un site de gamers mais dispense de nombreux cours sur un panel assez large de possibilités, on y gagne des médailles et autres achievements a chaque fois que l’on passe un niveau donc si vous aviez besoin de motivation pour vous lancer dans le design, dur de faire mieux (si si, en le répétant souvent on finit par y croire)

Vous pourrez constater qu’avec bien peu de code, on peut arriver à de fort jolie ET fonctionnel résultat donc maintenant, une fois votre expertise sur Blend dans la poche je vous laisse imaginer la puissance de vos applications .

http://www.microsoft.com/design/toolbox/

La problématique est toute simple, au sein d’un logiciel, j’ai plusieurs “toolsbox” me servant à modifier mes paramètres, chaque box peut apparaitre X fois sur Y inspecteurs différents mais au final tous sont reliées au même modèles.

Face au fait que beaucoup de données sont traitées, même si toutes viennent du même modèle et donc “n’existe” qu’une fois, il n’en reste pas moins que chaque instanciation de mes ViewModel implique de jouer son rôle de proxy pour ces données, mais pas une fois, plusieurs fois pour offrir les mêmes données?!

Donc oui le pattern MVVM indique que comme on tape sur le même model, chaque viewModel offre ce qu’il faut à sa vue et puis basta, et bien dans mon cas cela ne me suffit pas.

Deux solutions sont dont offertes:

• Instancier mon unique DataContext en codebehind lors de la création de mes vues
• Trouver un moyen pour que la view s’occupe elle-même de récupérer une instance unique de son ModelView

Ayant pris l’habitude d’utiliser blend, car blend c’est vraiment la vie (une petite pensée pour Dick Lantim qui aura essayé pendant deux mois de me convertir sans réussir…je regrette de ne pas avoir été un bon élève!), j’ai donc opté pour la seconde solution.

L’idée est de remplacer le code suivant qui permet l’instanciation du DataContext par un autre permettant de juste récupérer une instance unique du DataContext.

<UserControl.DataContext>
        <ModelView:BoxCamera/>
</UserControl.DataContext>

L’idée va être de passer par un ObjectDataProvider que nous allons déclarer une fois pour toute dans le App.xaml:

<Application.Resources>
    <ObjectDataProvider MethodName="GetInstance" ObjectType="{x:Type ModelView:BoxCamera}" x:Key="BoxCamera"/>
</Application.Resources>

Et notre ModelView va maintenant passer en mode Singleton pour renvoyer une unique instance qui va donc nous permettre de soulager un peu l’application en évitant de créer plusieurs ModelView quand un seul est nécessaire.

private static BoxCamera _instance;
        public static BoxCamera GetInstance()
        {
            if (_instance != null) return _instance;
            else
            {
                _instance = new BoxCamera();
                return _instance;
            }
        }
private BoxCamera() {}

Il nous reste plus qu’à faire notre binding de DataContext dans notre View et ensuite son utilisation est totalement transparente:

DataContext="{DynamicResource BoxCamera}"

Et voilà, plusieurs vue, un seul DataContext instancié donc dans certains cas le gain est vraiment appréciable .

Ce cas est assez particulier car repose sur un besoin que je viens d’avoir mais il faut noter que l’ObjectDataProvider  est vraiment pratique pour gérer un peu plus finement les créations de DataContext au sein de nos vues.

Par exemple, nous pouvons instancié un ModelView précis:

<ObjectDataProvider  ObjectType="{x:Type ModelView:BoxCamera}" x:Key="BoxCamera"/>

Mais dans le cas où nous aimerions passer des paramètres a notre constructor?

<ObjectDataProvider MethodName="GetInstance" ObjectType="{x:Type ModelView:BoxCamera}" x:Key="BoxCamera">
    <ObjectDataProvider.ConstructorParameters>
        <system:String>Stumpy</sys:system>
    </ObjectDataProvider.ConstructorParameters>
</ObjectDataProvider>

Vous avez besoin d’une donnée précise dans un morceau de votre application mais bon, pour X raison le ViewModel de cette vue ne contient pas la donnée et son ajout est peu pratique/élégant?
Aucun soucis car il vous suffit de récupérer notre ressource déclarée plus haut comme source et vous binder dessus:

<TextBlock Text="{Binding Path=FocaleValue, Source={StaticResource BoxCamera}}"/>

Bon il faut avouer, ce n’est pas super propre comme façon de faire mais disons que cela peut dépanner dans certains cas.

Un ViewModel un peu long à charger?
Aucun soucis, en settant IsAsynchronous a true, notre ViewModel est chargé en async donc on soulage encore un peu nos vues lors des phases de lancement.

Et nous pouvons sans doute lui trouver encore d’autres utilités .

Avec un peu de retard, voici un debrief du TGS 2009 qui c’est tenu le 28 et 29 Novembre.

J’étais sur place en qualité d’exposant pour Epitech, plus particulièrement pour le GameDevLab (laboratoire de jeux vidéo de l’école) et pour le MsLab (laboratoire Microsoft de l’école).

Autant le dire tout de suite, je ne suis pas un fan inconditionnel de manga…On peut le dire je n’aime pas cela dans l’ensemble mais l’ambiance qui se dégage de ce genre de salon est toujours sympa et il y a toujours moyen de se trouver quelques coins “oldies” pour amateur de jeux vidéo.

Les deux jours ont été assez crevant, les 8h de trajet en voiture avec tout le matériel, les courtes nuits et cette fameuse ambiance de salon ne laissant que peu de temps pour se reposer .

Je retiendrais surtout le fameux concert de Bernard Minet du samedi soir qui fut un grand moment, plein de souvenirs.

Le stand Epitech était sous le thème des interfaces tactiles que ce soit par la présence de mur tactile, d’écran tactile et de Surface, table basse tactile qu’on commence à bien connaitre sur ce blog .

Lors de la première soirée, moi et Mickael Thumerel avons eu l’envie de rush une petite application permettant de dessiner sur la Surface mais a l’inverse de l’application fournis en présentation, permettre un peu plus de chose telle que:

• édition poussée
• sauvegarde
• envois par mail
• ajout dans l’application image automatique
• et deux trois autres petites choses qui nous ont été réclamées par “nos artistes”

Pour une application codée en une petite heure après 8h de voyage et une installation de stand, le résultat a été des plus convainquant car la table n’a quasiment presque que tournée sur notre application et nous avons eu le plaisir de voir qu’une si petite “chose” pouvait rencontrer un franc succès.

Voici quelques créations faite sur notre application:

Ah…il n’en faut pas beaucoup pour amuser les foules .

Week-end fatiguant mais très sympathique!

Un petit post rapide pour faire tourner une vidéo de démonstration de Dungeon&Dragon sur Surface.

C’est encore du Work in Progress mais on retrouve déjà les principaux éléments.

La mise en application de ce type de jeu est toujours difficile et bien sur on perd l’esprit d’une bonne table de jeu mais je suis certain qu’il y a moyen de faire des trucs sympa malgré tout.

 

http://blogs.msdn.com/surface/archive/2009/10/19/dungeons-dragons-done-right-on-microsoft-surface.aspx

Pour finir mes études à Epitech j’étais à la recherche d’un emploi intéressant et si possible me permettant de subvenir à mes besoins que ce soit pour payer mes études mais également tout simplement vivre.

Je pense pouvoir dire que c’est mission accomplie! La signature sera faite la semaine prochaine mais j’ai déjà été présenté à l’équipe et mon pc est commandé donc je pense pouvoir affirmer que c’est partie!

Me voici donc responsable de l’interface Windows du logiciel Artlantis, un renderer dynamique pour le monde de l’architecture. L’idée est de permettre des rendus de qualité photographique en prenant comme base des modèles d’architecture.

Donner vie a des scènes animées par l’ajout d’atmosphère, de modèles, d’herbe, enfin tout ce qui pourrait permettre de montrer une vision « virtuelle » d’un projet d’architecture.

Je mélange donc ma passion pour l’univers du jeu vidéo, oui ce n’est pas un moteur de jeu mais un moteur de rendu très complet donc on retrouve de nombreux points communs mais surtout, l’interface que je vais devoir créer sera en WPF, technologies que j’apprécie énormément depuis mon passage a Microsoft France.

Début du contrat le 2 novembre, en espérant que l’ensemble tienne bien ses promesses .

Petit débrief rapidement de la conférence faite aujourd’hui dans les locaux d’Epitech ayant pour sujet:

« Industrialisation des développements N-tiers avec WPF et Silverlight »

Salle très bien remplie, speakers intéressants et surtout sujets très sympathique .

Matinée permettant un survol rapide de WPF puis d’une démonstration de comment proprement découper ses applications, pensez en MVVM et utilisation de framework tel que Composite Application Guidance pour arriver à un résultat permettant une totale absence d’interdépendance entre les différents modules/morceaux d’application.

Une après-midi tournée surtout vers les RIA Services au sein de SilverLight 3, démonstration classique d’un serveur offrant une base de donnée et utilisation de celle-ci dans un client.

Classique mais on constate vite la force de la technologie mais surtout la facilitée d’utilisation qui motive vraiment à regarder tout cela de plus près et suivre son avancement.

Le webcast sera dispo dans les jours qui viennent, une petite mise a jour sera faite a ce moment la J.

Encore merci a l’ensemble des intervenants pour leurs boulots et présentations.

La petite vidéo de fin de la Surface Academy 2009 a été publiée donc pour ceux qui veulent voir le résultat de ce stage :

Pas si mauvais que cela, surtout si on prend en compte le temps d’adaptation à la plateforme et technique que chacun a du faire.

Bonne chose à la « promo 2010 » si Microsoft décide de relancer le projet dans 1 an.

En pleine lecture du livre de Thomas Lebrun ayant pour sujet WPF et je ne peux que vous le conseiller !

Il reprend l’essentiel de WPF, on peut y trouver son compte en qualité de parfait débutant ou initié comme je pense pouvoir me caractériser.

Comme Thomas l’évoque dans son introduction, obtenir des informations sur cette technologie n’est pas en soit bien compliqué mais il n’existait pas vraiment de publication « papier » dans la langue de Molière. C’est malgré tout agréable de temps en temps de lire un bon livre technique dans sa langue maternelle.

Au fil de la lecture, on comprend les mécanismes de WPF et on ne peut admettre que oui cette technologie bouleverse les habitudes, elle permet de faire facilement ce que nous espérions tous . Bien sur cela reste récent et réclame sans doute encore quelques améliorations mais l’évolution est rapide et je n’ai aucune inquiétude pour cela.