Stumpy

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 .

Dans l’article précèdent, nous avons mis en place un WebService offrant un accès sur une base de donnée par le biais du protocole OData.
Nous avons vu qu’il était possible de lire le flux par le biais du logiciel LinqPad mais également un simple navigateur.
Il serait intéressant maintenant de lire cela dans une application directement, non?

Je vous invite donc à reprendre votre solution de test fait dans l’article précèdent et y ajouter un projet de type WPF application.

Nous allons ensuite faire une petite interface qui va juste nous permettre d’avoir un rendu visuel, pour le cote sexy de l’application on repassera plus tard .

Pour vous faire gagner un peu de temps, voici le code xaml de la fenêtre :

<Grid>
    <Button Content="Refresh" Click="Button_refresh" Margin="214,0,213,258" />
    <ListBox x:Name="myList" Margin="0,0,295,0" />
</Grid>

Nous avons donc une ListBox et un Button, il reste maintenant à offrir une source de donnée à notre superbe application.

Pour cela, on ajoute une référence vers notre WebService comme d’habitude :
Clic droit sur References dans le projet puis ajouter un « service reference »
Notre service étant dans notre solution, il vous suffit de faire « Discover » puis de lui donner un petit nom, par exemple « MyService »

Rien de bien nouveau en soit, voyons maintenant comment remplir notre listbox.

Notre bouton de refresh étant brancher sur un évènement clic, il nous suffit de rajouter la méthode suivante en code-behind de notre fenêtre :

private void Button_refresh(object sender, RoutedEventArgs e)
{
    this.db = new MyService.NORTHWNDEntities(new Uri("http://localhost:26162/WcfDataService1.svc"));
    var query = from c in db.Contacts select c;
    this.Contact = new DataServiceCollection<MyService.Contacts>(query);
    this.myList.ItemsSource = Contact;
}

Pensez à ajouter les propriétés de classe :

MyService.NORTHWNDEntities db = null;
DataServiceCollection<MyService.Contacts> Contact = null;

Mais aussi à remplacer le port par celui sur lequel tourne votre service !

La première ligne est là pour nous permettre de récupérer un context sur notre webService et nous allons ensuite nous en servir pour l’interroger.
Dans mon cas, je souhaite récupérer l’ensemble des contacts donc ma requête reste assez simple et je la passe ensuite dans le constructeur de ma DataServiceCollection.
Il me reste plus qu’à donner comme source à ma liste la collection en question .
Je vous laisse essayer et constater que « normalement » tout marche comme prévu, quoique l’affichage de notre listbox n’est pas très agréable à voir.

Un petit ajout dans le xaml semble utile, remplacer votre listbox par celui-là puis relancer

<ListBox x:Name="myList" Margin="0,0,295,0">
    <ListBox.ItemTemplate>
        <DataTemplate>
             <TextBlock Text="{Binding ContactName}" />
        </DataTemplate>
   </ListBox.ItemTemplate>
</ListBox>

Déjà un bon résultat pour si peu de travail.
Une problématique qui peut se poser est la pagination des données, oui dans notre cas la liste des contacts n’est pas énorme mais dans le cas où elle contiendrait des milliers de données ?
Hmm…Un peu lourd de tout récupérer d’un coup peut-être ?

Retournons dans notre webservice et essayons de faire un système permettant de n’envoyer seulement que N éléments à la fois et s’arranger pour envoyer N de plus sur demande.
On se souvient avoir mis la ligne

config.SetEntitySetAccessRule("Contacts", EntitySetRights.All);

Ajoutons cette petite ligne à la suite :

config.SetEntitySetPageSize("Contacts", 42);

Et…voilà, notre système de pagination est fini, mon café n’a même pas eu le temps de refroidir…
Je vous laisse relancer votre client et constater que maintenant on ne récupère plus que les 42 premiers éléments de notre table, ajoutons donc un système pour récupérer la suite !

Retour dans le xaml pour y ajouter un petit bouton dont voici le xaml a glissé dans votre fenêtre :

<Button Content="Next" Click="Button_Next" Margin="314,0,112,258" />

Allons maintenant remplir le code de l’event sur lequel pointe ce bouton:

private void Button_Next(object sender, RoutedEventArgs e)
{
    if (this.Contact == null || this.Contact.Continuation == null)
        return;
    this.Contact.Load(this.db.Execute<MyService.Contacts>(this.Contact.Continuation.NextLinkUri));
}

Donc un petit check pour eviter de planter dans le cas ou notre liste n’aurait pas été chargées au préalable
Et ensuite, on charge la suite de notre collection, pour cela un petit appel à notre context en lui indiquant que l’on veut récupérer « la suite ».

Si vous regardez la valeur de NextLinkUri vous y verrez une simple uri avec un argument indiquant « quoi renvoyer »
Encore une fois, rien de bien sorcier, l’ensemble du process est géré pour nous.

Je vous laisse vous amuser avec votre nouveau bouton pour voir ce remplir votre liste de contact et de mon cote je garde encore mon café chaud pour le moment !

Jusqu’à la, nous avons fait de la lecture de base, on se souvient d’avoir laissé le service ouvert en écriture pour la table Contacts donc essayons d’y ajouter un élément .
Encore une fois, voici un petit morceau de xaml à ajouter dans votre fenêtre :

<Button Content="Add" Click="Button_Add" Margin="419,0,12,258" />

Et voici le code allant avec notre event d’ajout:

private void Button_Add(object sender, RoutedEventArgs e)
{
    if (this.Contact == null)
        return;
    this.Contact.Add(new MyService.Contacts()
    {
        CompanyName = "42",
        ContactName = "Marvin"
    });
    db.SaveChanges();
}

Un petit check pour la forme puis on ajoute un contact dans notre collection.
Et puis on demande au context de nous sauvegarder les changements.

Voilà, notre mini gestionnaire de contact est terminé, je vous laisse le décorer pendant que je déguste mon café.

La version en Silverlight reposerait sur le même code, juste noter que l’ensemble des appels au webservice seraient asynchrones comme toujours en Silverlight

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:

View Full Album

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

Week-end fatiguant mais très sympathique!

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.

Je me permet de relayer l’annonce d’une journée conférence à Epitech autour des technologies WPF et Silverlight ou plusieurs grands speakers de la communauté prendront parole.

Dans la ligné des mercredi du développement, le premier événement prendra place dans les locaux d’Epitech Paris le 1er Octobre (et oui un jeudi…besoin logistique) en ayant pour thème le développement avec WPF et Silverlight.

Voici l’url pour vous inscrire, la journée est plutôt pour un public professionnel mais les étudiants du campus seront les bienvenus également (sur inscription).

Programme de la journée :

9h30-12h30

Repas (non pris en charge)

14h-17h

Intervenant :

Mitsuru FURUTA, David Rousset – Microsoft France

Nicolas Clerc – Tekigo

Simon Ferquel

Je tiens a remercier Mitsuru Furuta et Fabienne Haas(communication Epitech) d’avoir si rapidement mis en place cet événement.

Le premier en date « soutenu » par le laboratoire Microsoft d’Epitech (MsLab).

Par ici l’annonce « officielle »

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.