Depuis le milieu des années 2000, l’augmentation de la puissance de calcul de nos ordinateurs ne passe plus par l’élévation de la fréquence des processeurs mais par la multiplication des cœurs de processeur au sein de nos machines.

Pour tirer parti de cette multiplication, un algorithme doit être parallèlisé, c’est à dire qu’il doit pouvoir diviser ses instructions et les répartir sur différents cœurs pour une exécution simultanée.
De nombreux outils permettent d’implémenter un algorithme parallèle sur une machine, par exemple la librairie Task Parallelism Library (TPL) en .Net, abordé par Olivier Roux et Alexis Flaurimont ou encore le fork/join en Java étudié par Marc Bojoly et David Rousselie.

D’autres outils, implémentant par exemple le pattern Map/Reduce, permettent de distribuer le calcul vers des cœurs situés sur différentes machines.

Cet article présentera une introduction à la programmation orientée acteurs et les réponses qu’elle apporte à ces différents problèmes.

Cette programmation est issue d’un article paru en 1973, A Universal Modular Actor Formalism for Artificial Intelligence Carl Hewitt; Peter Bishop and Richard Steiger. Ericson, au milieu des années 80, implémente ce modèle en utilisant le langage Erlang pour la conception de systèmes téléphoniques robustes et distribués. Ce modèle est à présent repris, par Akka notamment, dont on utilisera la librairie version 1.2 en Java.

Cette implémentation donne à un acteur trois caractéristiques principales :

• Il possède un état interne.
• Il traite séquentiellement des messages stockés dans une queue.
• Il peut émettre des messages asynchrones à d’autres entités.

Dans cet article, l’implémentation d’un exemple simple permettra de mettre en avant certaines possibilités de cette solution.

Dans une première partie, on présentera le problème à traiter, puis on le modélisera selon la programmation orientée acteurs. Dans une deuxième partie, nous réaliserons une implémentation parallèle sur une unique machine puis, dans une troisième partie, nous distribuerons les calculs sur plusieurs nœuds.

1. Modélisation du problème

Exemple à implémenter

Réalisons un programme qui renvoie des images selon des dimensions demandées. Il reçoit la demande d’une image selon certaines dimensions (hauteur, largeur), charge l’image originale depuis le disque, réalise son redimensionnement et la transmet.

public byte[] Process(int imageNumber, int width, int height) {
  byte[] imageBytes = loadImage(imageNumber) ;
  byte[] resizedImage = createResizedImage(imageBytes, width, height);
  return resizedImage ;
}

Le processus est déclenché de manière évènementielle, i.e. les demandes sont traitées au fur et à mesure et non accumulées pour être traitées par lot.

Cette contrainte rend difficile l’utilisation d’outils de parallélisation de boucle de type paralleleFor de la librairie TPL car on ne connaît pas initialement le nombre d’itérations à effectuer. Une implémentation du pattern Master/Worker ou le master empile des tâches dans une file d’attente consommée par les workers serait plus adaptée. C’est sur la base de ce pattern que nous allons modéliser ce problème en acteurs.

Modélisation du problème

Une modélisation possible en acteurs de notre exemple comporte quatre types d’acteurs : un « Producer » émettant les demandes, un « Reader » récupérant l’image depuis le disque dur, un « Resizer » redimensionnant l’image, et un acteur « Exit » réceptionnant l’image redimensionnée.

Le message partagé entre les acteurs contient ici le numéro de l’image à charger, les dimensions voulues, et l’image.
On a volontairement pris soin de séparer les accès IO et les calculs de redimensionnement afin de bénéficier d’une plus grande souplesse lorsque l’on parallélisera l’implémentation.
Pour reprendre l’analogie avec le pattern Master/Worker, on peut ici considérer que chaque acteur est le master de l’acteur qu’il précède.

2. Implémentation parallèle sur une machine

Implémentation naïve

Le message échangé est implémenté par une simple classe immuable sérialisable appelée ImageMessage.

Les différentes classes acteurs étendent l’interface UntypedActor et implémentent la méthode onReceive qui permet de traiter le message.
Commençons avec le « Producer » qui recevra un startMessage pour démarrer l’envoi de dix demandes d’image.

public class Producer extends UntypedActor {

public void onReceive(Object message) throws Exception {
  if (message instanceof StartMessage) {
    //obtient une référence vers un acteur de type Reader.
    ActorRef reader = registry().actorsFor(Reader.class)[0];

    for (int i = 0; i < 10; i++) {
      ImageMessage imageMessage = buildImageMessage();
      //transmet le message
      reader.tell(imageMessage);
    }
  }
}

La méthode registry().actorFor permet d’obtenir tous les acteurs démarrés d’un certain type sur cette JVM. L’envoi asynchrone d’un message s’effectue par la méthode actorRef.tell(Object message). Notons qu’une méthode d’envoi synchrone existe.

Selon le même principe, la logique du « Reader » est la suivante :

byte[] imageBytes = loadImage(imageMessage.getImageNumber());
registry().actorsFor(Resizer.class)[0].tell(new ImageMessage(imageBytes, imageMessage));

Celle du « Resizer » :

byte[] resizedImage = createResizedImage(imageMessage);
registry().actorsFor(Exit.class)[0].tell(new ImageMessage(resizedImage,imageMessage));

L’ « Exit » reçoit simplement les images traitées.

Il ne reste plus qu’à instancier tous ces acteurs par la méthode Actors.actorOf, à les démarrer grâce à la méthode start(), et à envoyer un startMessage au « producer ».

public static void main(String[] args) {
  init();
  registry().actorsFor(Producer.class)[0].tell(new StartMessage());
}

private static void init() {
  Actors.actorOf(Producer.class).start();
  Actors.actorOf(Reader.class).start();
  Actors.actorOf(Resizer.class).start();
  Actors.actorOf(Exit.class).start();
}

Premier constat : une implémentation asynchrone est plus complexe qu’une implémentation synchrone classique. En effet, en programmation synchrone, le résultat d’une méthode appelée est systématiquement renvoyé à la méthode appelante. Ici, il appartient  au développeur de préciser à qui sera transmis le résultat de la méthode asynchrone.

On voit également que cette implémentation est relativement lourde à mettre en place par rapport à un paralleleFor, ou l’utilisation de Task de TPL.

Deuxième implémentation : multi-cœurs

Revenons à notre problème initial qui consiste à répartir les traitements sur les différents cœurs disponibles.

L’augmentation du nombre de « Reader » ne sert ici à rien car le goulet d’étranglement se situe au niveau du débit du disque dur.

L’opération de réduction du « Resizer » prend quatre fois plus de temps que la lecture du fichier faite par le « Reader ». Pour augmenter la performance, on va travailler sur deux dimensions : le nombre de « Resizer » et le nombre de cœurs utilisés.
Augmentons le nombre de « Resizers » et utilisons un acteur de type « LoadBalancer » pour repartir les messages selon le schéma suivant :

Voici le code du « Balancer » qui étend UntypedLoadBalancer et implémente seq(), méthode qui précise comment doivent être répartis les messages.

public class Balancer extends UntypedLoadBalancer {

  private InfiniteIterator<ActorRef> infiniteIterator;

  public InfiniteIterator<ActorRef> seq() {
    if (infiniteIterator == null) {
      //CyclicIterator permet au Balancer d'envoyer des messages
      //équitablement répartis entre les resizers.
      infiniteIterator = new CyclicIterator<ActorRef>(Arrays.asList(registry().actorsFor(Resizer.class)));
    }
    return infiniteIterator;
  }
}

La multiplication des « Resizers » n’a pas d’intérêt s’ils se partagent le même cœur.
Le paramétrage des cœurs, des threads et la liaison de ceux-ci aux acteurs s’effectue à l’aide des objets dispatcher fournit par Akka.

Ils se séparent en deux catégories principales:

• L’EventBasedDispatcher qui est basé sur un ThreadPoolExecutor . Il répartit les acteurs sur un pool de threads qui est construit automatiquement à partir du nombre de cœurs disponibles, du nombre maximal de threads autorisés, et de la configuration de la queue utilisée pour stocker les acteurs en attente.
  Ce dispatcher est plus adapté lorsque les acteurs ont des traitements courts à réaliser. En effet, un traitement long, ou un blocage IO, peut accaparer un thread et bloquer l’activation d’autres acteurs en attente.
• Le ThreadBasedDispatcher qui octroie un thread système par acteur. Le blocage d’un acteur ne retarde donc pas l’activation des autres acteurs.

Allouons un ThreadBasedDispatcher pour le Reader, afin que ses interruptions IO n’affectent pas les autres acteurs.

ActorRef reader = Actors.actorOf(Reader.class);
Dispatchers.newThreadBasedDispatcher(reader);
reader.start();

On notera ici que l’encapsulation de la lecture synchrone du « reader » par un objet acteur disposant de son propre thread, au sens où il n’est pas partagé avec d’autres acteurs et donc ne les bloque pas directement, la rend asynchrone pour les autres acteurs.

Finalement, allouons un EventBasedDispatcher pour les autres acteurs de la manière suivante :

MessageDispatcher messageDispatcher = configureDispatcher();
actorRef.setDispatcher(messageDispatcher);
actorRef.start();

La configuration de ce dernier permettra d’utiliser les quatre cœurs de la machine et de limiter le nombre maximum de threads à quatre. La taille de la file d’attente est choisie arbitrairement longue pour éviter les cas aux limites.

private static MessageDispatcher configureDispatcher() {
  return Dispatchers.newExecutorBasedEventDrivenDispatcher("the_dispatcher")
    .withNewThreadPoolWithLinkedBlockingQueueWithCapacity(1000)
    .setCorePoolSize(4)
    .setMaxPoolSize(4)
    .build();
}

On voit ici que l’API propose un réglage fin permettant d’adapter la configuration au matériel et au problème posé. Notons également que la configuration par défaut place tous les acteurs sur un EventBasedDispatcher configuré pour utiliser tous les cœurs de la machine. Notre première implémentation était donc déjà multi-cœurs.

On comprend alors que les acteurs fournissent un cadre qui simplifie les problèmes de concurrence à traiter par le développeur. Ces problèmes qui deviennent rapidement complexes, voir l’article de Sofian Djamaa, sont ici en parti contournés par l’utilisation de messages immuables et par le non partage d’état entre les acteurs (les états des acteurs seront présentés ultérieurement).

« Let It Crash »

Un des points importants de la programmation orientée acteurs introduit par Ericson est sa tolérance à l’erreur. Cette faculté est assurée par un acteur particulier de type Superviseur. Celui-ci surveille le bon fonctionnement d’autres acteurs. En Java, il attrape les exceptions levées par les acteurs surveillés et peut les redémarrer suivant une des stratégies suivantes :

one for one : seul l’acteur levant une exception est redémarré.
one for all : tous les acteurs supervisés sont redémarrés, cette stratégie est utilisée dans le cas de dépendance entre acteurs.

Par exemple, redémarrons notre  « reader » lorsque celui-ci lève une exception IO :

public static Supervisor buildSupervisor() {
  OneForOneStrategy oneForOneStrategy = new OneForOneStrategy(
    //type d'exception prises en charge
    new Class[]{IOException.class},
    //nombre maximum de d'essai de redemarrage
    100,
    // temps maximum pour le redemarrage
    5000
  );

  //creation de la strategie de supervision,
  //aucun acteur à superviser initialement
  SupervisorConfig supervisorConfig = new SupervisorConfig(oneForOneStrategy, new Supervise[0]);
  Supervisor supervisor = Supervisor.apply(supervisorConfig);
  return supervisor;
}
…

  Supervisor supervisor = buildSupervisor();
  //on applique le superviseur au reader
  supervisor.link(reader);

L’utilisation des superviseurs peut aller beaucoup plus loin. Ainsi les superviseurs peuvent surveiller d’autres superviseurs ou démarrer eux-mêmes les acteurs qu’ils supervisent. On peut alors aboutir à un arbre de supervision qui permet de gérer l’application selon différents blocs fonctionnels comme le montre le schéma suivant :

3. Implémentation multi-machines

Troisième implémentation : multi-noeuds.

Maintenant que le programme occupe tous les cœurs de la machine, distribuons le sur plusieurs machines. Le « producer » et « l’exit » seront placés sur une machine maitre, tandis que chaque machine esclave contiendra un « reader »  et des « resizers ».

Schématiquement :

Techniquement, la sérialisation des messages est réalisée par Google Protocol Buffer et la partie réseau est assurée par JBoss Netty.

Du point de vue du développeur, la différence entre adresser des messages sur une même machine, et adresser des messages sur une machine distante réside dans la façon d’obtenir la référence vers l’acteur auquel on souhaite envoyer le message (Akka version 1.2).

Celui-ci doit être déclaré accessible depuis l’extérieur :

remote().start("localhost", 2552).register("reader-service", reader);

La référence est ensuite disponible sur les autres machines par la méthode remote().actorFor :

remote().actorFor("reader-service", "192.168.1.5", 2552);

On voit dans le cadre de cet exemple qu’une fois la complexité absorbée pour une utilisation mono machine, la distribution des calculs sur différents nœuds est relativement simple.

Dernière implémentation : utilisation de l’état interne d’un acteur.

Finalement, utilisons l’état interne d’un acteur pour gérer l’absence de fichier dans un nœud. Si un « reader » ne trouve pas l’image i, il le signale au « balancer ». Le « balancer »  mémorise cette information et renvoie la demande de l’image i aux nœuds qui, a priori, ont l’image.

Ce cas d’utilisation met en avant le fait que la communication entre acteurs n’est pas unidirectionnelle. On voit également que l’utilisation d’états internes est utile pour changer dynamiquement le comportement de l’application. Attention néanmoins à l’augmentation de la complexité induite par ce changement.

Conclusion

La programmation orientée acteurs apporte des réponses aux problématiques de parallélisation et de distribution de calculs. Par le biais des superviseurs, elle propose un moyen de gérer les incidents. Les états internes permettent de « dynamiser » l’application au sens où le comportement peut changer au cours du temps (exemple de l’image absente d’un nœud). Et finalement, le système de dispatcher permet une gestion fine des ressources (cœur/ thread) utilisées.

Néanmoins le choix de ce paradigme s’avère plus lourd à mettre en place que la librairie TPL dans le cadre d’une implémentation mono-machine par exemple, et s’accompagne d’une augmentation de la complexité : coder en asynchrone n’est pas standard et l’utilisation d’états internes amène des difficultés supplémentaires.

Bruno Boucard au TechDays compare la programmation orientée acteurs avec d’autres solutions de parallélisation et de distribution en fonction du type d’algorithmes à implémenter. Il montre que les programmes composés de plusieurs étapes chainées et parallélisables (ici l’implémentation sans images manquantes), ou des programmes dont le traitement est irrégulié (ici l’exemple de l’image manquante) bénéficient le plus de ce type de programmation.

Suggestion d'articles :

1. La programmation haute performance n’est-elle réservée qu’à une élite de développeurs C++ ?
2. Introduction à la gestion de version distribuée
3. Datacenter as a Computer : une plongée dans les datacenters des acteurs du cloud

Introduction

Le développement d’applications pour terminaux mobiles (iPhone, iPad, Android, Blackberry, Windows Phone, Nokia Symbian, Samsung Bada…) se heurte à la fragmentation des technologies de développements: environnement iOS/Objective-C pour l’iPhone et l’iPad, SDK Java spécifique pour Android, J2ME pour Symbian, etc.

Deux approches possibles lorsque l’on débute un projet d’application ciblant plusieurs de ces plateformes sont de développer une application pour chacune d’elle, ou de développer un site Web compatible.

Dans le premier cas, l’inconvénient concerne bien évidemment le coût des développements. Dans le deuxième, on sera limité en richesse de l’application par les possibilités du Web.

Ce fut l’objet d’un précédent article sur notre blog: http://blog.octo.com/debat-web-apps-vs-natif/.

Entre ces deux approches se situe une offre assez fournie de solutions de développement multi-plateforme, proposées par des éditeurs proposant leurs propres plateformes d’exécution et leurs outils de développement.

Parmi celles-ci, nous nous sommes concentrés dans cet article sur PhoneGap et Titanium Mobile, qui sont aujourd’hui parmi les plus abouties et sont représentatives des deux principales approches de développement multi-plateforme: l’utilisation des moteurs de rendus Web pour PhoneGap, et la translation de code source vers la plateforme cible pour Titanium.

Présentation des solutions

PhoneGap

Nitobi, l’éditeur de PhoneGap, a annoncé son rachat par Adobe le 3 octobre 2011. Cela confirme l’intérêt que l’on peut avoir envers cette solution, même si ce rachat surprise apporte une certaine incertitude sur l’avenir de PhoneGap.
PhoneGap est un outil open-source, et devrait d’ailleurs rejoindre la fondation Apache.
Le principe de PhoneGap est de fournir des API JavaScript aux navigateurs Web standards, permettant d’appeler des fonctionnalités natives non disponibles autrement: accéder à l’appareil photo, à l’accéléromètre, au système de fichiers…
Cela nécessite d’embarquer le code source HTML/CSS/JS dans une application native, grâce au composant permettant d’inclure une vue Web dans une application, disponible dans chaque SDK.

Titanium

Développé par Appcelerator qui vend du support et des formations sur Titanium, c’est également une solution libre.

Le principe de Titanium est de fournir une machine virtuelle JavaScript permettant d’accéder au système natif, et ainsi de développer des applications natives mais en JavaScript. C’est la promesse d’applications plus réactives et à l’expérience utilisateur plus proche du natif que celles basées sur des pages Web, comme PhoneGap.

Points communs

L’intérêt principal de l’utilisation d’une plateforme de développement multi-plateforme comme PhoneGap et Titanium Mobile réside en 2 points:

• pouvoir déployer l’application sur les magasins (AppStore, Android Market…) afin de bénéficier de ce canal de distribution et de communication. Cela est réellement assuré par ces deux outils;
• réduire les coûts de développements en mutualisant du code. Cela est assuré par ces deux outils à condition de bien les utiliser et de limiter la part des développements spécifiques à chaque plateforme et donc de se limiter aux fonctionnalités supportées « out of the box ». On rogne donc sur l’expérience utilisateur et la richesse fonctionnelle.

Comparaison

Plateformes supportées

Notre avis:

En pratique, les développements PhoneGap nécessitent des adaptations pour chaque plateforme, dont les capacités et l’expérience utilisateurs diffèrent fortement. Etant donné l’état du marché (avec l’écrasante domination de l’iPhone, d’Android et de Blackberry), on ciblera généralement ces 3 plateformes uniquement. C’est ce que l’on a pu constater dans la plupart des cas où une entreprise ciblait initialement toutes les plateformes: l’augmentation du coût pour les supporter au fur et à mesure rendait cela impossible et finalement, au maximum, seules les 3 ou 4 principales étaient vraiment adressées.
Concernant Titanium, le support de Blackberry est encore récent et disponible uniquement sous Windows, alors que la plupart des développeurs mobiles sont sous Mac (pour l’iPhone). Cela est dommage mais on espère que ce sera bientôt résolu.
Pour cibler tous les terminaux mobiles à moindre coût, le meilleur moyen reste de réaliser un site Web simple, qui permet de diffuser de l’information mais ne permet ni de fournir des fonctionnalités avancées (appareil photo, etc.), ni de proposer une expérience utilisateur riche, ni d’être visible sur l’AppStore.

Richesse de la plateforme

Notre avis:

Titanium est indéniablement plus riche fonctionnellement et fournira une apparence plus proche du natif, ce qui est en général l’objectif des concepteurs d’applications.
PhoneGap est dans l’absolu plus limité en terme de fonctionnalités, et on doit concevoir les écrans comme des pages Web et non des écrans natifs. C’est d’ailleurs une erreur que l’on retrouve souvent sur les projets mobiles utilisant des technologies Web: il ne faut surtout pas tenter de reproduire des comportements natifs, mais plutôt viser des comportements Web performants.
Les deux plateformes sont extensibles, Titanium plus facilement que PhoneGap, mais nous déconseillons globalement d’aller dans cette direction car cela devient très coûteux à maintenir (on estime en général à 20% la part maximale de code spécifique tolérable), et nécessite en outre encore plus de compétences que de faire des applications natives spécifiques à chaque plateforme.

Plateforme de développement

Notre avis:

On remarque l’utilisation de plus en plus large de JavaScript, un langage décrié par ses côtés peu structuré et trop tolérant. Il est nécessaire, pour développer ce type d’applications, de se former profondément à JavaScript et de connaître les design patterns de structuration/modularisation du code dans ce langage, qui existent mais sont souvent mal connus des développeurs.
C’est d’ailleurs le principal objet de la formation à Titanium donnée par leur expert Kevin Whinnery, que nous avons eu la chance de suivre à l’UpdateConf 2011.
De manière globale, l’environnement de développement de Titanium est mieux intégré et plus documenté.

Productivité des développement

Notre avis:

Titanium fournit un environnement de développement « clé en main » et performant, là où PhoneGap nécessite d’installer et configurer soi-même plusieurs environnements.
La productivité est clairement côté Titanium aujourd’hui.

Gestion des déploiements

Notre avis:

L’automatisation du packaging et de la livraison des applications sur les différentes plateformes (magasins publics type AppStore ou comptes privés « in house ») est un véritable enjeu concernant la productivité des développements et le coût global d’un projet. C’est d’ailleurs pour cela qu’OCTO propose Appaloosa, qui facilite la distribution en entreprise d’applications mobiles dans des stores privés.
L’outil PhoneGap Build (compatible uniquement avec les applications PhoneGap), qui vient d’être ouvert en version finale, était une véritable nécessité.

Synthèse

Les points forts de PhoneGap sont donc aujourd’hui son support de plus de 6 plateformes, et le fait qu’il utilise au maximum les technologies standards du Web.
Ses points faibles concernent ses limitations fonctionnelles et sa moindre richesse d’IHM du fait qu’il n’utilise pas les composants natifs, ainsi que son manque d’outillage de développement.

Les points forts de Titanium sont sa richesse fonctionnelle et graphique, ainsi que la productivité de son environnement de développement.
Son point faible concerne le peu de plateformes supportées.

Conclusion

En conclusion, on a pu voir que Titanium est globalement plus productif et fournit plus de fonctionnalités que PhoneGap dans le but de développer des applications mobiles multi-plateformes. On le préfèrera en général, si l’on ne doit pas supporter plus que iOS + Android + BlackBerry.
Au-delà du choix de l’outil, notre conseil majeur restera d’utiliser les outils pour ce qu’ils savent faire, et éviter de « tordre » leur usage pour leur faire faire autre chose ou de manière différente. Cela s’approche des problématiques bien connues d’utilisation trop personnalisée de progiciels, qui rend rapidement très coûteuse la moindre évolution.

Et d’ors et déjà, le choix de la technologie de développement multi-plateformes doit aussi se faire par-rapport aux applications Web HTML5 qui apportent de plus en plus de fonctionnalités et viennent sérieusement concurrencer les approches natives et hybrides, et les solutions Web existantes comme les moteurs de rendus (BkRender, Wokup) et les nombreux frameworks Web pour mobiles (par exemple Sencha Touch.

La problématique du développement mobile multi-plateforme est loin d’être encore résolue, et nul doute que nous reviendrons encore dessus rapidement car c’est un enjeu fort pour les entreprises aujourd’hui.

Suggestion d'articles :

1. Applications natives ou web HTML5 pour mon mobile ?
2. Ce que jQuery Mobile nous apprend sur le Web Mobile
3. Le terminal mobile et usabilité ou comment réveiller le canal web et les applications desktop

Avec l’arrivée massive des processeurs multi-cœur, le parallélisme peut devenir une nécessité pour une application afin exploiter toute la puissance disponible d’une machine proposant ce type d’architecture. En effet, la loi de Moore, vérifiée depuis 1973, se heurte à une autre loi, celle des rendements décroissants.  Le nombre de transistors à ajouter pour obtenir un gain de performance donné devient de plus en plus important, empêchant les fondeurs de continuer à augmenter la fréquence d’horloge des processeurs. Pour contourner ce problème, ils favorisent les architectures multi-cœurs. Le parallélisme peut être très impactant dans le développement d’une application, celle-ci devant être écrite et adaptée pour tirer parti du hardware.

Qu’est-ce que le parallélisme sur une architecture multi-cœur? C’est l’emploi des capacités de calculs en simultané dans un cadre déterministe. Cela consiste à prendre une tâche, la diviser en un ensemble de sous-tâches indépendantes à exécuter simultanément, le travail étant réparti sur plusieurs cœurs (la notion de concurrence, quant à elle traite de l’allocation d’une même ressource CPU pour plusieurs processus, chacun disposant à son tour d’un quantum de temps de calcul).

Dans cet article, je vais examiner comment il peut être relativement facile d’implémenter la programmation parallèle dans une application, en utilisant le Framework  .NET 4.0 et sa librairie TPL (Task Programming Library).

Rappelons que l’idée principale est d’utiliser la puissance des machines multi-cœurs. Le challenge est donc de savoir comment diviser un fragment de programme en multiple unités et ce, de façon simultanée.

Je vous renvoie à un article rédigé par Olivier Roux en 2009, traitant du même sujet mais basé sur les Parallel Exentions. Le but de ce nouvel article est de faire un point sur le développement parallèle, deux ans après. Certains éléments sont rebalayés ici, d’autres clarifiés, de nouveaux sujets sont abordés ainsi que des tests de performance.

La solution existante depuis le Framework .NET 2.0 est l’utilisation d’un pool de threads. Il est composé d’un scheduler et d’une file d’attente de threads. Quand un thread a fini son travail, il est mis dans la file et est de nouveau disponible pour être capté par une opération à exécuter.

Quels sont les avantages et nouveautés de la programmation parallèle dans le Framework .NET 4.0 ? Comme premier élément de réponse, je poserai la question suivante :

• Combien de développeurs sont capables de développer une application multi-threads sans difficultés ?

Il est impossible de prédire le comportement d’un thread après sa création, d’où la complexité de ce type de développement, plutôt réservé aux développeurs chevronnés, spécialisés dans ce domaine. Les difficultés liées à la programmation parallèle sont évoquées dans un article de Sofian Djamaa.

Comment utiliser les tâches ?

Dans les version précédentes de .NET, il était complexe d’obtenir des informations sur ce qui se passait exactement après avoir mis un élément en attente dans le pool, c’était du « fire and forget ».

En .NET 4.0, la librairie TPL est un moyen « simplifié » d’utiliser le pool de threads. Une tâche (Task) représente une opération asynchrone, et à certains égards, ressemble à la création d’un nouveau thread ou à un élément de travail du pool de threads (work item), mais à un niveau supérieur d’abstraction. Les tâches ont deux avantages principaux:

• Une utilisation plus efficace des ressources système:
  Il n’y a pas de relation 1-1 entre une tâche et un thread. Les tâches sont mises en attente dans le thread pool. Celui-ci a été amélioré à l’aide d’algorithmes (comme Hill-climbing) pour déterminer et ajuster le nombre de threads afin de maximiser le trafic. De plus, des algorithmes de type Work-stealing sont utilisés pour répartir la charge en fonction du nombre de processeurs (ou cœurs) disponibles. Le CLR 4.0 s’occupe donc de gérer le niveau de concurrence entre les threads.
• Un meilleur contrôle programmatique qu’avec les threads ou work items:
  La librairie TPL fournit un ensemble de fonctions de contrôle : mise en attente, annulation, gestion des exceptions et plus encore.

Exemple 1 : Création de tâches

	static void Main(string[] args)
	        {
	            //Création et lancement de la première tâche
	            var t1=Task.Factory.StartNew(() => ProcessNumbers(10, 20));
	            //Création et lancement de la deuxième tâche
	            var t2=Task.Factory.StartNew(() => ProcessNumbers(20, 30));
	            //Création et lancement de la troisième tâche
	            var t3=Task.Factory.StartNew(() => ProcessNumbers(30, 40));
	            Console.ReadLine();
	        }  

	        static void ProcessNumbers(int start, int stop)
	        {
	            for (int i = start; i < stop; i++)
	                Console.Write(" " + i);
	        }

Ci-dessus, je créé 3 tâches, exécutées en parallèle. Remarquons que la tâche t3 commence avant que la tâche t2 soit terminée, car l’exécution des tâches est asynchrone.

Exemple 2 : Attendre l’exécution de tâches

	//Création et lancement de la première tâche
	 var t1=Task.Factory.StartNew(() => ProcessNumbers(10, 20));
	 //Création et lancement de la deuxième tâche
	 var t2=Task.Factory.StartNew(() => ProcessNumbers(20, 30));  

	 //Attendons que t1 et t2 soient finies pour commencer t3
	 t1.Wait();
	 t2.Wait();  

	 //Création et lancement de la troisième tâche
	 var t3=Task.Factory.StartNew(() => ProcessNumbers(30, 40));
	 Console.ReadLine(); 

	        }

Le code ci-dessus permet à la tâche t3 de commencer après que les tâches t1 et t2 soient finies. Ces deux tâches sont mises en attente dans le thread pool, l’appel à la fonction Wait() bloque les autres tâches jusqu’à ce que l’exécution de t1 et t2 soit terminée. J’aurais pu utiliser la méthode WaitAll() : Task.WaitAll(t1, t2), cela revient au même.

Exemple 3 : Tâche retournant un résultat

// La method MyMethod() retourne une chaîne de caractères
Task aTask = new Task(MyMethod);
aTask.Start();

Task.WaitAll();

string result = aTask.Result;

Pour que la tâche retourne une valeur, il faut utiliser la version générique Task<T>. Le paramètre T désigne le type de retour. Le type Task a une propriété « Result » qui bloque l’exécution en y accédant, je m’explique :

var task = Task.Factory.StartNew(() =>
{
    Thread.Sleep(3000);
    return "dummy value";
});
Console.WriteLine(task.Result);

La tâche s’exécute dans un thread séparé et prendra 3 secondes. Lorsque j’appelle « Console.WriteLine », une exception n’est pas levée même si le résultat n’est pas encore disponible. L’exécution est bloquée 3 secondes avant de continuer. Cela peut être nécessaire lorsqu’utilisé avec des tâches longues, sachant qu’elles utiliseront cette faculté de bloquer en attendant qu’elles soient terminées.

Remarque : la méthode WaitAny(t1, t2, t3…) permet d’attendre l’exécution de l’une des tâches sans se soucier laquelle.

Il est également possible d’utiliser la méthode ContinueWith(Action<Task>) pour réaliser la même chose, à savoir attendre la fin d’une tâche pour en débuter une autre. La méthode ContinueWhenAll(Task[], Action<Task[]>), quant à elle permet de spécifier quelle(s) tâche(s) attendre avant d’en commencer une autre.
Plus généralement, TaskFactory contient un nombre intéressant de méthodes qui pourront vous aider dans de nombreuses occasions.

Comment paralléliser les boucles ?

L’idée est de traiter chaque itération indépendante de la boucle simultanément.

Exemple 4 : Parallel.For

Considérons une boucle for basique :

for (int i = 0; i < 200; i++)
{
    if (i % 2 == 1)
        Console.WriteLine(i + " ");
}

Remarquons que pour paralléliser cette boucle, la syntaxe change peu:

Parallel.For(0, 200, (i) =>
{
    if (i % 2 == 1)
        Console.WriteLine(i + " ");
});

Exemple 5 : Parallel.ForEach

Voici un exemple plus concret, il provient du projet CreditReview que fournit Microsoft.  L’idée est d’identifier les comptes à risque s’ils ont excédé leur limite de crédit les mois précédents. Le statut de crédit de chaque client ne dépend pas du statut d’un autre.

Boucle séquentielle :

static void UpdatePredictionsSequential(AccountRepository accounts)
        {
            foreach (Account account in accounts.AllAccounts)
            {
                Trend trend = SampleUtilities.Fit(account.Balance);
                double prediction = trend.Predict(
                                 account.Balance.Length + NumberOfMonths);
                account.SeqPrediction = prediction;
                account.SeqWarning = prediction < account.Overdraft;
            }
        }

Boucle parallèle :

static void UpdatePredictionsParallel(AccountRepository accounts)
        {
            Parallel.ForEach(accounts.AllAccounts, account =>
            {
                Trend trend = SampleUtilities.Fit(account.Balance);
                double prediction = trend.Predict(
                                   account.Balance.Length + NumberOfMonths);
                account.ParPrediction = prediction;
                account.ParWarning = prediction < account.Overdraft;
            });
        }

Une telle construction gère de façon dynamique l’augmentation et la réduction du nombre de threads, suivant la charge disponible sur chaque cœur, impliqués dans les opérations de façon à déterminer le nombre de threads optimal pour une charge de travail donnée.

L’avantage par rapport à la gestion classique de threads pour le développeur est de lui épargner de coder des solutions de partitionnement des charges de travail, celui-ci pouvant se concentrer sur la logique métier.

Optimisation des boucles

Dans la pratique, quand plusieurs boucles sont imbriquées, il n’est pas nécessaire de paralléliser boucles externe et boucles internes, la boucle externe suffit. En effet, celle-ci offre de plus grandes unités de travail à paralléliser, diluant la surcharge due au mécanisme de synchronisation des threads.

Une autre optimisation est l’emploi d’une valeur locale. Le problème est le suivant : supposons que nous voulions additionner la racine carré d’un nombre dix millions de fois. Le calcul est parallélisable sans problème, mais additionner les valeurs devient gênant car nous devons verrouiller la mise à jour du total :

Exemple  6 : Lock, optimisation avec une valeur locale

object locker = new object();
double total = 0;
Parallel.For (1, 10000000,
              i => { lock (locker) total += Math.Sqrt (i); });

Dans le code ci-dessus, le gain du à la paralléisation est contrebalancé par le coût de 10 millions de locks, dont nous n’avons pas besoin.

object locker = new object();
double grandTotal = 0;

Parallel.For (1, 10000000,

  () => 0.0,                     // Initialisation de la valeur locale.

  (i, state, localTotal) =>      // Le délégué invoqué pour chaque itération
     localTotal + Math.Sqrt (i),    // Il retourne la nouvelle valeur locale.

  localTotal =>                                // Ajout de la variable locale
    { lock (locker) grandTotal += localTotal; }    // à la valeur globale.

Certes, il y a toujours des locks mais seulement pour la somme grandTotal += localTotal, ce qui est beaucoup plus efficace que la version précédente.

Exemple 7 : Degré de parallélisme

Il s’agit de limiter le nombre de cœurs à utiliser dans une exécution.

var options = new ParallelOptions();
options.MaxDegreeOfParallelism = Math.Max(Environment.ProcessorCount / 2, 1);

Parallel.For(0, pixelData.GetUpperBound(0), options, row =>
{
    for (int col=0; col < pixelData.GetUpperBound(1); ++col)
    {
        pixelData[row, col] = AdjustContrast(pixelData[row, col], minPixel, maxPixel);
    }
});

Bien souvent, la configuration par défaut convient, mais dans certains cas il peut être utile d’utiliser un sous-ensemble des cœurs disponibles. En pratique, cela limite le nombre d’opérations simultanées, qui peut être intéressant si nous exécutons un processus long, nous ne voulons pas multiplier les requêtes sur le serveur en même temps. Le serveur lui-même peut ne pas être en mesure de toutes les traiter et étonnamment se retrouver surchargé (le principe d’une attaque DOS).

PLINQ

L’une des autres avancées du Framework .NET 4.0 en matière de parallélisme est le Parallel LINQ (PLINQ). Son utilisation est identique à LINQ-to-Objects et LINQ-to-XML. Tous les opérateurs de requêtes du C# 3.5 sont disponibles. Les requêtes LINQ-to-SQL et LINQ-to-Entities sont toujours exécutées par les bases de données, donc non parallélisable par PLINQ.

PLINQ s’avère utile pour les requêtes nécessitant une grande quantité de calcul. Il est aussi possible d’interroger simultanément plusieurs sources de données (bases de données, fichier XML…) après avoir été chargées en mémoire.

Exemple 8 : de LINQ à PLINQ

Une requête simple LINQ

IEnumerable data = ...;
var q = data.Where(x => p(x)).Orderby(x => k(x)).Select(x => f(x));
foreach (var e in q) a(e);

En PLINQ

IEnumerable data = ...;
var q = data.AsParallel().Where(x => p(x)).Orderby(x => k(x)).Select(x => f(x));
foreach (var e in q) a(e);

PLINQ exécute les clauses Where, OrderBy et Select de manière transparente sur tous les coeurs disponibles. La technologie Parallel Linq, qui est un sujet à part entière, ne sera pas plus détaillée volontairement.

Comment débugger?

Pour parcourir unitairement en mode pas-à-pas chaque thread, Visual Studio 2010 possède une fenêtre dédiée : Debug -> Windows -> Parallel Tasks. Il est possible de freezer les tâches, de switcher entre-elles. Visual Studio identifiera les deadlocks et vous dira quelles sont les deux threads mis en cause et quel objet elles attendent.

Nous pouvons aussi afficher une représentation graphique des threads exécutés : Debug -> Windows -> Parallel Stacks.

Gestion des exceptions

Il est possible de gérer les exceptions, en effet, celles-ci sont stockées dans une tâche et sont levées lorsque toutes les tâches sont terminées. Les exceptions ne sont jamais perdues et correctement propagées. Pour les propager au thread appelant, elles sont encapsulées dans une instance AggregateException. Elle peut énumérer, examiner toutes les exceptions qui ont été levées individuellement.

Exemple 9 : AggreagateException

var task1 = Task.Factory.StartNew(() =>
            {
                throw new MyCustomException("mon exception");
            });

            try
            {
                task1.Wait();
            }
            catch (AggregateException ae)
            {
                foreach (var e in ae.InnerExceptions)
                {
                    if (e is MyCustomException)
                    {
                        Console.WriteLine(e.Message);
                    }
                    else
                    {
                        throw;
                    }
                }
            }

Et les performances ?

La première démo illustrant le gain de performances de la programmation multi-cœurs en .NET 4.0 est une multiplication de deux matrices de même dimension et le calcul du résultat dans une troisième. Cet exemple est un bon candidat pour le parallélisme car nécessitant beaucoup de calculs.

Je fais cette opération tout d’abord en mode séquentiel, puis en mode parallèle et je compare le temps d’exécution de chacun des deux modes.

Exemple 10 : multiplication de matrices

Ci-dessous le code d’initialisation des matrices :

static double[,] InitializeMatrix(int rows, int cols)
        {
            double[,] matrix = new double[rows, cols];

            Random r = new Random();
            for (int i = 0; i < rows; i++)
            {
                for (int j = 0; j < cols; j++)
                {
                    matrix[i, j] = r.Next(100);
                }
            }
            return matrix;
        }

La boucle séquentielle:

static void MultiplyMatricesSequential(double[,] matA, double[,] matB,
                                                double[,] result)
        {
            int matACols = matA.GetLength(0);
            int matBCols = matB.GetLength(0);
            int matARows = matA.GetLength(0);

            for (int i = 0; i < matARows; i++)
            {
                for (int j = 0; j < matBCols; j++)
                {
                    double temp = 0;
                    for (int k = 0; k < matACols; k++)
                    {
                        temp += matA[i, k] * matB[k, j];
                    }
                    result[i, j] = temp;
                }
            }
        }

Et la boucle parallélisée:

static void MultiplyMatricesParallel(double[,] matA, double[,] matB, double[,] result)
        {
            int matACols = matA.GetLength(1);
            int matBCols = matB.GetLength(1);
            int matARows = matA.GetLength(0);

            // Multiplication des matrices
            // Parallélisation de la boucle externe pour partitionner
            //la matrice source par ligne.
            Parallel.For(0, matARows, i =>
            {
                for (int j = 0; j < matBCols; j++)
                {
                    double temp = 0;
                    for (int k = 0; k < matACols; k++)
                    {
                        temp += matA[i, k] * matB[k, j];
                    }
                    result[i, j] = temp;
                }
            });
        }

La machine sur laquelle les tests sont effectués embarque un processeur Intel Core i7 Quad-Core HT.

Les résultats sont logiquement ceux espérés.

J’ai fait varier la taille des matrices [n,n], n prenant respectivement les valeurs 500, 1000, 1500, 2000, et 2500.

Dans les tests en mode parallèle, le pourcentage d’utilisation du CPU est toujours monté à 100% :

Il est resté bloqué à 12% en mode séquentiel. Cela s’explique par la nature du processeur, Quad-Core en effet, mais 8 threads (avec le support de l’HyperThreading).

En tirant parti de la librairie TPL du Framework .NET 4.0, le temps d’exécution peut même être divisé par un facteur supérieur à 4, en mode parallèle. Ce résultat peut sembler étonnant, nous devrions avoir un gain de performances théoriques inférieures à 4 (car quatre cœurs). En effet, dans l’OS, d’autres applications tournent en arrière-plan. Le mécanisme de synchronisation des threads doit aussi prendre un peu de puissance de calcul. Ceci reflète sans doute l’amélioration des performances due au mode HyperThreading du processeur.

Exemple 11 : BabyNames

La deuxième démo utilise PLINQ cette fois. C’est la démo BabyNames du training kit Visual Studio 2010. Les coordonnées d’individus d’une population sont chargées en mémoire (250 Mo), une requête LINQ ou PLINQ est exécutée suivant le mode désiré. Elle recense le nombre de naissances par année, pour un nom/prénom choisi.

J’obtiens les résultats suivants, en faisant varier le nombre de cœurs :

Les résultats sont à peu près du même ordre que dans l’exemple précédent. Il est intéressant de noter que notre processeur étant HT, le programme détecte 8 cœurs. Nous pouvons donc sélectionner très finement le degré de parallélisme voulu. Nous observons que la requête PLINQ exécuté sur un seul thread d’un unique cœur est presque aussi rapide que la même requête LINQ.

La programmation parallèle est longtemps restée le domaine de développeurs spécialisés. Il semblerait que cela soit en train de changer dans le monde .NET, et c’est plutôt une bonne nouvelle. En effet, le gain de performances que la librairie TPL peut apporter est à prendre en compte dans le développement d’une application ou d’un composant de celle-ci.

Le parallélisme à la sauce Microsoft inclus dans le Framework .NET 4éme mouture est certes une surcouche encapsulant elle-même les mécanismes plus bas niveau du parallélisme, j’entends déjà les puristes de la manipulation du thread crier au scandale. Néanmoins, le développement d’une application multi-threadée est grandement simplifié et peut demander peu d’efforts à condition que les algorithmes soient facilement parallélisable, y compris pour adapter un code déjà existant.

Notons que le C# 5 Async doit apporter un lot de nouveautés, qui, combinées avec la librairie TPL, devraient être intéressantes pour les opérations asynchrones.

Suggestion d'articles :

1. Parallélisation, distribution partie 3 : comment tirer parti des processeurs multi-coeurs à travers l’API de concurrence de Java 7 ?
2. Environnement de développement Maven/Eclipse pour GWT 1.7
3. Devons-nous changer de paradigme pour le développement d’applications informatiques?

Dans cet article, nous allons faire le point sur Node, une technologie serveur dont tout le monde parle et qui est devenue, en 2 ans seulement, le 3ème projet le plus suivi sur GitHub derrière Rails et jQuery.

Node en quelques mots

Node est une technologie créée en 2009 par Ryan Dahl et soutenue par Joyent qui permet de réaliser simplement des applications réseau asynchrones, performantes et scalables en JavaScript.

Pourquoi JavaScript ?
Aujourd’hui, pour traiter un grand nombre de requêtes, la stratégie des serveurs haute performance, comme nginx par exemple, est d’utiliser un thread et une approche événementielle.

Node reprend ce principe et va plus loin en utilisant JavaScript: un langage conçu pour tourner au sein du navigateur dans un thread et une boucle événementielle asynchrone.

C’est également un choix qui simplifie les développements web puisque le langage côté navigateur et serveur est le même. Par la même occasion, cela ouvre de nombreuses perspectives en terme de partage de code entre ces deux mondes.

Exemple de code asynchrone affichant « hello world » en JS:

setTimeout(function () { console.log('world') }, 2000);
console.log('hello');

Comment ?
Pour exécuter du code JS côté serveur, Node utilise le moteur V8 de Google.

C’est l’un des moteurs JS les plus performants grâce à de nombreuses optimisations (compilation du code JS en code machine, garbage collector, …) dont on trouvera le détail ici.

Pour les aspects non pris en charge par JS et V8, Node implémente ses propres librairies non bloquantes (HTTP, TCP, FileSystem, etc…).

Rapide et léger
Ces choix techniques font que les applications basées sur Node sont très performantes et capables de traiter efficacement un grand nombre de requêtes concurrentes tout en gardant une empreinte mémoire faible.

En pratique?
Voici un serveur développé en JS et utilisant le module HTTP de Node. Les requêtes sont traitées de façon asynchrone dans un callback.

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337');

Node et Rails une histoire comparable ?

Pour bien comprendre le phénomène Node, il est intéressant de le mettre en perspective avec Rails à ses débuts.

Une adoption d’abord chez les développeurs
A l’inverse de technologies poussées par des poids lourds, Rails est une technologie qui a d’abord été adoptée et popularisée par les développeurs.

De la même façon, Node est un projet open source qui a démarré sur la plateforme de social coding GitHub essentiellement fréquentée par des développeurs web.

Aujourd’hui, Node est le 3ème projet le plus suivi sur cette plateforme.

Les deux technologies répondent à une problématique de leurs temps
Rails permettait de faire, beaucoup plus simplement que les autres, des applications web CRUD avec base de données. Ce type d’application était la tendance il y a quelques années.

Aujourd’hui, la tendance est au web temps réel et Node permet de le faire de façon performante mais surtout plus simplement que les autres.

Exemple: avec Node et le module NowJS, il est possible de faire un chat web en 12 lignes.

Il y a un module pour ça
La force de Rails, hormis la qualité du framework, est l’éco-système de gems développées par la communauté. Sans celui-ci l’intérêt de Rails serait beaucoup plus limité.

On retrouve cela avec Node et de nombreux modules tiers sont disponibles. Il existe d’ailleurs un gestionnaire de paquet, Node Package Manager, similaire à RubyGems.

C’est cette capacité à être étendu et la communauté autour qui fait tout l’intérêt et le potentiel de Node.

Une précision toutefois, même si Node et Rails ont un début de parcours semblable, les deux technologies sont fondamentalement différentes techniquement et dans la réponse qu’elles apportent. Rails est un framework MVC, Node est une base sur laquelle d’autres modules sont développées, dont des frameworks web.

Où en est Node aujourd’hui ?

Node et son éco-système évoluent très rapidement, néanmoins voici plus ou moins l’état actuel.

Node
Node est activement développé. C’est une technologie “from scratch” qui change encore beaucoup mais qui est utilisable et performante.

Node tourne sous MacOS, Linux et depuis peu Windows.
Fait assez significatif, Microsoft a participé à ce portage.

Modules
Les modules disponibles évoluent eux aussi rapidement.

Il y a eu un gros effort de développement fait par la communauté et on trouve maintenant des modules pour la plupart des besoins habituels (web temps réel, frameworks, persistance, templates, tests, DSL, …).

A titre d’exemples, on pourra aller voir: Express, Socket.IO, CoffeeScript, Mongoose, Zombie.js, Vows,  …

Globalement, c’est un éco-système qui se cherche encore mais qui évolue vite.

Il y aura, comme ce fut le cas avec la vague Rails et ses plugins, une « sélection naturelle » des modules.

Les applications qui utilisent Node
Comme avec Rails au début, ce sont surtout des applications de développeurs ou des startups. On trouve également quelques sociétés comme Yammer, HP (webOS), 37signals (Pow).

Les cas d’utilisation sont assez variés: API, web temps réel, serveurs, etc…

Node est principalement utilisé sur les aspects nécessitant de traiter un grand nombre de requêtes avec des temps de réponse faible.

Aujourd’hui, ce qu’il manque surtout à Node pour passer sur le devant de la scène est une killer app grand public.

A retenir

Node est une nouvelle technologie qui suscite, à juste titre, beaucoup d’intérêt par ses performances et sa simplicité.

Mais Node s’inscrit aussi dans une tendance générale du web.

Depuis plusieurs années, on constate une montée en puissances de JS, notamment côté navigateur avec:

• des moteurs de plus en plus rapides
• des applications et des frameworks pour les développer de plus en plus évolués (BackBone, Sammy.js, …)

Node en permettant d’utiliser le même langage côté serveur ouvre de nombreuses possibilités. Il n’est pas rare de voir des modules pouvant être exécuté côté navigateur ou serveur avec la même base de code.

Aujourd’hui, tous les éléments sont réunis pour voir émerger de nouveaux frameworks web basés sur Node permettant de faire simplement du JS de bout en bout:

Technique
JS est présent à tous les niveaux, les briques de base côté Node sont développées (modules web temps réel, persistance, templates, …) et les performances sont suffisantes pour supporter les nouveaux usages web.

Communauté
Grâce au choix du langage et à son faible coût d’entrée, Node bénéficie d’une communauté active, très importante et fortement orientée web.

Voici plus d’un an maintenant que je réalise régulièrement des scripts PowerShell en tout genre.
Dernièrement j’ai pu remarquer que j’utilisais et améliorais continuellement certaines pratiques qui me facilitaient aussi bien le développement de scripts PowerShell que leur correction ou évolution.

Dans cet article (en anglais), je vous présente ainsi ces « bonnes pratiques » que j’ai pu identifier avec le temps.
La suite ici.

Suggestion d'articles :

1. OCTO partage ses bonnes pratiques dans le livre Partageons ce qui nous départage
2. PowerShell : le couteau suisse des administrateurs Windows ?
3. Beckett, la guitare de Jimi Hendrix et les pratiques agiles

L’Agile est aujourd’hui un outil puissant d’amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d’information.

Si la méthode commence à être connue, sa mise en œuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.

Ainsi, dans les organisations où les pratiques d’achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu’à l’aide d’avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les principes fondamentaux de l’Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l’avancement du projet pour répondre mieux aux besoins des utilisateurs.

Alors que faire ? Comment concilier des principes d’achats bien rodés mais a priori antagonistes avec les principes de projet Agile ? Peut-on faire évoluer ces principes ? Chez OCTO, nous avons la conviction qu’il existe des moyens d’y parvenir en respectant les contraintes et les enjeux de votre entreprise.

Nous vous proposons d’échanger avec vous sur ce thème et pourquoi pas vous accompagner dans un travail en profondeur sur vos pratiques d’achats et de contractualisation.

Pour commencer nos échanges, nous offrons 2 séances de travail de 2h gratuites au 3 premières entreprises qui nous contacteront.

Contactez-moi pour cela sur ymartel@octo.com et travaillons ensemble à améliorer un peu plus votre ingénierie informatique!

Suggestion d'articles :

1. Contractualisation Agile
2. Comment mieux prioriser en projet agile
3. Quels sont les types de tests que l’on utilise sur un projet agile ?

Un article récent publié sur InfoQ abordait la sécurité de HTML5 dans sa globalité, et notamment sur des attaques concernant les nouvelles fonctionnalités de navigation hors-ligne de HTML5.

Quelles sont donc ces fonctionnalités et qu’en est-il vraiment des risques associés?

Rappel historique

La seule possibilité pour une application web HTML/JavaScript de stocker des données dans un navigateur était jusqu’à récemment de les stocker dans un cookie. Limités en taille (la spécification exige seulement des navigateurs qu’ils puissent gérer 4096 octets par cookie!), parfois refusés par les navigateurs et nettoyés régulièrement, et assimilés à des logiciels espions par les antivirus, leur fiabilité restait très limitée.
D’autres technologies à base de plugins, comme Adobe Flash, utilisaient des procédés propriétaires ne répondant pas aux normes du W3C (les « super cookies« ) et très critiquées pour leur opacité (manque de contrôle pour l’utilisateur pour savoir quelles informations sont stockées ou les supprimer). En 2007, Google a sorti Google Gears qui a permis de stocker des données dans le navigateur sous la forme d’une base de  données relationnelle et de disposer en local d’un cache de ressources (cf. les articles publiés par Olivier Mallassi sur le blog OCTO).

Cette nouveauté a permis le développement de véritables applications web stockant un nombre conséquent de données en local, permettant un fonctionnement déconnecté de l’application et une meilleure réactivité en évitant d’inutiles aller-retours avec le serveur. L’exemple le plus marquant étant naturellement le client mail de Google, Gmail, qui innovait en plus avec le « flaky mode » où l’utilisateur naviguait en permance en local, utilisant les ressources stockées dans son navigateur, et où l’application mettait à jour ces données quand une connexion à Internet était disponible. Cependant, Google Gears restait un produit de Google, et son implémentation sur les navigateurs n’était pas garantie.

Le groupe de travail sur HTML5, auquel contribue fortement Google, a alors déclaré vouloir inclure dans la spécification HTML5 des normes de stockage local s’inspirant de Google Gears. En parallèle, début 2009, Google a d’ailleurs arrêté le développement de Google Gears, au profit de l’implémentation de la norme HTML5.

Cette normalisation contraint déjà les navigateurs web à implémenter ces mécanismes, entraînant à coup sûr une démocratisation de leur utilisation par les applications web.

Quels sont les risques liés au stockage local?

Parmi les sites précurseurs dans l’utilisation de stockage local se trouvent les webmails. Les données stockées dans  le navigateur sont donc les courriers électroniques de l’utilisateur, qui sont des données très critiques par-rapport au respect de la vie privée, sans parler des cas où certains mails contiendraient des données plus sensibles, comme un numéro de compte bancaire…
Il convient donc impérativement de s’assurer qu’aucun tiers ne puisse accéder à ces données.

Quels sont les mécanismes de stockage local?

HTML5 prévoit deux systèmes de stockage de données en local :

• le Web Storage, comprenant local storage, toujours accessible à l’application et permettant par exemple à des onglets différents de partager des données, et le session storage, accessible uniquement à une fenêtre donnée. Les données sont stockées sous la forme de clés/valeurs,
• la Web SQL Database fournissant cette fois une base de données relationnelle, implémentée par les navigateurs avec SQLite. Signalons au passage que le choix de SQLite a été fait par les éditeurs de navigateurs au détriment de la proposition initiale de « Indexed DB » proposée par le W3C.

Un autre système de stockage local est fourni sous la forme de caches permettant cette fois-ci de stocker des ressources (images, fichiers JavaScript, etc.) et non plus des données.

Dans leurs spécifications respectives, le W3C aborde la sécurité, et décrit les mêmes problématiques pour les deux.

Quels risques et quelles protections?

La seule protection spécifiée par le W3C concerne l’origine des sites : des données stockées par un site A ne doivent pas être visibles pour un site B, en se basant sur l’hôte du site et le port. Cela empêche par exemple une iframe inclus dans un site, typiquement un encart publicitaire, d’avoir accès aux données stockées localement par ce site.

Ce systèmes ne protège pas de certaines attaques, d’ailleurs décrites dans la spécification :

- les attaques par usurpation de DNS, qui consistent à usurper une adresse IP d’un serveur pour envoyer des paquets à sa place. Ce risque sera toutefois mitigé en utilisant SSL, et concerne le web dans sa globalité.

- le partage de nom d’hôte entre plusieurs sites : si le site d’adresse http://www.mon-site.com/site1 stocke des données, un autre site d’adresse http://www.mon-site.com/site2 y aura accès sans resctriction. Le risque étant faible de se faire attaquer par ce biais, car on a déjà fait confiance au premier site.

On remarquera que les attaques par XSS (cross site scripting) ne sont pas mentionnées et constituent pourtant un risque important, bien mis en valeur par l’OWASP. On pourra le mitiger avec notamment un contrôle du code côté serveur et une validation des données passées dans les formulaires.

La spécification ne prévoit pas d’autre mécanisme de sécurité.

Un point très important n’est pas abordé dans la spécification et pourrait pourtant s’avérer crucial : la spécification ne prévoit que les données stockées en base locale soient cryptées, elles sont toujours stockées en clair.
Ce point a été soulevé par Nicholas C. Zakas (un des référents mondiaux sur le langage JavaScript notamment, qui contribue à HTML5). Il a même proposé une proposition très détaillée d’évolution de la spécification vers un cryptage des données, décrite dans ce billet.
Dans ce système, un serveur d’application web aurait la responsabilité de chiffrer les données sur le client, avec une clé de cryptage gérée par l’application. Concrètement, une application web devrait exécuter la méthode Javascript suivante pour ouvrir la connexion en base de données :

window.openSecureStorage("mystorage", window.AES_128, key, function(storage){
//use storage object
});

L’application web choisirait donc l’algorithme de cryptage et la clef. Ainsi, même si un attaquant parvenait à récupérer des données, il ne pourrait les exploiter. On remarquera d’ailleurs que sans cryptage, toute personne ayant acccès physiquement au poste client pourra lire toutes ces données…

Bien que sa proposition soit assez complète et détaillée, il n’y a pas encore eu de suite à ma connaissance de la part d’autres acteurs du web.

On peut tout de même se rassurer concernant les postes publiques (cyber cafés, etc.). En effet, les données sont stockées dans le navigateur dans un profil créé pour l’utilisateur, qui est normalement effacé lorsqu’il quitte le poste et que le compte est ré-initialisé, ce qui doit être l’usage pour ce type de poste. L’utilisateur devant tout de même s’en assurer, ce qui est loin d’être évident pour un utilisateur non initié. Il est ici plus question d’éducation des utilisateurs que de technologie.

Enfin, les caches peuvent quant à eux être attaqués par « Cache poisoning ». L’objectif de l’attaquant est alors d’injecter dans le cache du navigateur un fichier JavaScript en remplacement d’un fichier fourni par le serveur « sain », et dont le script malicieux serait exécuté par le client. Ce risque est à prendre en compte particulièrement dans les réseaux wifi ouverts comme on en trouve par exemple dans des restaurants, mais si ces attaques sont difficiles à détecter et à contrer, le risque s’avère relativement faible d’après les conditions requises pour permettre l’attaque, citées par l’OWASP.

Conclusion

Malgré cette énumération de risques, qui plus est incomplète, il convient d’insister sur le fait qu’ils ne sont pas spécifiques à HTML5 mais au contraire inhérents au web depuis ses débuts.
La nouveauté avec HTML5 est qu’il offre la possibilité de faire des application plus riches, stockant plus de données localement.
Cela doit simplement inciter les concepteurs et développeurs d’applications web à une certaine vigilance concernant la sécurité des données locales, mais ne vous y méprenez pas, HTML5 constitue bien dès aujourd’hui une formidable opportunité pour vos applications web!

Suggestion d'articles :

1. HTML5 : la promesse d’un browser qui devient VM
2. Tous les navigateurs acceptent HTML5 et CSS3
3. Applications natives ou web HTML5 pour mon mobile ?

Les Techdays sont l’occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d’outils sous forme de présentations, d’ateliers ou de retour d’expérience. Difficile de couvrir complètement cet événement tant l’offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts (voir le premier ou le second), sur les sessions que nous avions choisi et de partager avec vous notre ressenti.

Fin de la série avec des sessions plus orientés geek.

Coding4Fun

Une belle démonstration de ce que les dernières API du framework proposent.

• Simulation du multitouch avec plusieurs souris : idéal pour tester une application multitouch sur un écran traditionnel, même si l’usabilité paraît chaotique et le framework requérant à l’application d’être lancée en plein écran.
• Utilisation de silverlight out of browser (pour accéder au filesystem de manière limitée, aux contrôleurs type webcam) et WCF pour piloter un robot à distance !

Pas vraiment de valeur à tous ces développements mais des idées et surtout la démonstration que le framework est complet et facile d’utilisation (comment ca c’est orienté?)

Session : C# et Linq avancé

Une session qui repose sur des manipulation de lamba Expression et la génération dynamique de code. Séduisant pour l’esprit (encore faut-il rester concentré) mais on ne fait pas un compilateur tous les matins. C’est surtout l’occasion de réfléchir à nos petites habitudes de développements et d’y repenser sous un nouvel angle après avoir encore une fois constaté la flexibilité que linq permet.

J’aurais bien aimé voir d’avantage d’astuces liés aux nouveautés de C#4.

Session : AOP et .net

Dommage à mon goût que l’on ait passé un peu trop de temps sur l’explication de l’AOP plutôt que d’entrer directement dans le vif du sujet  – reste qu’ils ont présenté PostSharp (en autres mais je ne vais pas m’attarder sur spring.net). Si vous ne le connaissez pas, il s’agit d’un outil permettant d’injecter du code lors de la compilation.

Imaginons que je veuille être sur que toutes les propriétés de mes POCO commencent par vérifier que l’objet est à jour avant de retourner leur valeur mais je veuille garder la description la plus simple possible de mes objets. Alors il me suffit d’écrire le script PostSharp qui déclare le code à ajouter sur la propriété. A la compilation, l’IL normalement produite est modifiée et le code supplémentaire injecté.

Gain de temps considérable pour le développeur et surtout garantie qu’aucun n’oubliera de le faire. Le debugger reste utilisable sur le code ajouté.

Bémol : le binaire produit peut être beaucoup plus volumineux, code moins factorisé.

Session : détecter et éviter les fuites mémoire en .Net

Session technique encore, qui explique comment et pourquoi il est possible d’avoir des fuites mémoires en .Net. Trois outils sont présentés pour les détecter (dotTrate, .Net Memory Profiler et WinDbg), le tout illustré sur une application faite sur mesure (comprendre : qui fuit plus que les baignoires utilisés à l’école primaire en cours de mathématiques).

Une session qui, pour moi, a trouvé une application immédiate, puisque mise en œuvre dès la fin des techdays sur une mission. Bien qu’utilisant trois outils spécifiques, les principes présentés restent génériques et peuvent être appliqués avec d’autres outils (Ants, par exemple).

Session : Développement parallèle avancé

Animé par Bruno Boucard qui a co-animé une session USI l’année dernière avec Arnaud Mazin. Une session orientée « Pattern de modélisation » pour le développement parallèle. Très Intéressant sur le principe mais elle s’est arrêtée au moment ou cela commençait à être intéressant. C’est à dire au moment de faire le lien entre le choix de la démarche (orienté données vs orienté tâche) et de l’algo avec l’implémentation : les API du marché.

Session : Le langage Axum

Une autre session sur le parallélisme (co-animé également par Boucard). Cette fois-ci s’est beaucoup plus intéressant (pour moi) car beaucoup plus concret. Axum est une sorte de DSL de la plateforme .net – paradigme de programmation orienté Agent et message.

La grosse difficulté des algorithmes parallèle repose sur la complexité à estimer les effets de bords et de concurrence d’accès à certaines données. L’idée est donc de proposer la notion d’agent dont le contenu de l’implémentation est invisible et immuable depuis l’extérieur. Il répond à des messages reçus via un channel sur l’un des ports qu’il expose. La notion de message facilite le découpage de l’algorithme et celle d’agent limite les risques d’effets de bords.

On retrouve certains principes des langages fonctionnelles (immuable) mais on reste proche d’une syntaxe objet. Ce langage n’a clairement pas la prétention de réaliser à lui seul le développement de l’application mais plutôt de simplifier le développement de tâches critiques.

On retrouve les promesses de la plateforme .net : choisis le langage qui t’arrange, le compilateur produira in fine de l’IL.

Bémol : il s’agit d’un projet de recherche qui est (très) loin d’être utilisable en production.

Session : Pex et Moles appliqués pour tester Sharepoint

Il s’agit à nouveau d’outils fournis par le labo de Research de MS mais à un stade beaucoup plus abouti (ils font partie de la release de VS 2010).

Moles permet de remplacer n’importe quelle méthode du framework de base par un délégué et donc de coder la fonction de votre choix (le remplacement est fait à la compilation en modifiant l’IL générée). Pex permet de générer intelligement des tests unitaires par introspection des branchements de votre code.

A quoi ca sert tout ça ?

Imaginez que vous vouliez tester un code du genre : Si la date du jour est supérieure à 01/01/2011 alors Exception ‘offre terminée’ . Et bien avec Mole, vous remplacez le DateTime.Now par une fonction qui prend en paramètre la date de votre choix. Puis Pex, vous génère les tests unitaires correspondants aux cas aux limites : ici 01/01/2011.

Attention, cela ne vous dispense pas d’écrire des TU puisque sans TU, PEX ne saura pas ce qui doit être testé. Il vous évite juste décrire tous les cas aux limites et vous garantit surtout que vous n’avez rien oublié.

Imaginons maintenant un cas plus complexe, vous voulez tester un système mastodonte qui plus est distant – au hasard Sharepoint.  L’équipe Moles a fourni une sorte de mock qui récrit simplement tous les points d’accroches de l’API Sharepoint. Vous pouvez ainsi tester facilement et de manière indépendante sans même l’avoir sur votre poste, votre développement. Ils sont engagés à fournir la même chose pour tout leur genre d’outils ex : ActiveDirectory.

Je trouve que cela offre des possibilités intéressantes pour tester des systèmes critiques qui nécessitent une couverture très fine du code, ou des legacy non designés pour les tests.

Mick Philippon, Nicolas Raynaud, Olivier Roux

Suggestion d'articles :

1. Microsoft Techdays 2010 (1/3)
2. Microsoft Techdays 2010 (2/3)
3. Le Cloud selon Microsoft, retour de TechEd 2010

Les Techdays sont l’occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d’outils sous forme de présentations, d’ateliers ou de retour d’expérience. Difficile de couvrir complètement cet événement tant l’offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts (voir le premier), sur les sessions que nous avions choisi et de partager avec vous notre ressenti.

Ce deuxième post est orienté nouveautés serveurs, cloud … et un petit bonus.

Session : SQL Server 2008 R2 pour les développeurs

Une session très technique qui présente les nouveautés du T-SQL dans 2008 R2 notamment les nouveaux types de données (Hierarchy, Date, Time, DateTime2) et leur utilisation. Une partie de la session servit à présenter l’utilisation de méthode .Net dans les procédures stockées. Il faut savoir que c’est possible, mais je ne vois pas grand intérêt à le faire. Des illustrations autours de ces points furent faites en T-SQL, mais également en .Net.

Sessions : Découvrir Windows Server 2008 R2 en 1h chrono et Les services de fichier et le stockage sous Windows Server 2008 R2

Première remarque : Windows Server 2008 R2, c’est long à dire. On ne se compare pas encore à du Capcom (Super Street Fighter 4 Alpha remix extra plus), mais on s’en rapproche. Vivement Windows Server 2008 R2 SP1 ! Bref, la R2 (pour faire court) reste une évolution mineure, mais qui apporte néanmoins son lot de nouveautés. Sans les citer toutes, voilà celles qui me semblent les plus intéressantes:

• Hyper-V permet maintenant de faire de la migration de VM à chaud, sans les arrêter. Les VHD (virtual hard drive) sont extensibles à chaud également. Un petit utilitaire, Wim2VHD permet de déployer un WIM sans avoir à démarrer la VM.
• L’apparition de BranchCache, qui automatise la stratégie de cache des fichiers entre sites distants.
• La gestion de 256 cœurs et jusqu’à 300 VM par serveur. Regrouper les machines, c’est bien, parce qu’on a le « core parking » qui permet d’affecter toute la charge sur une partie des cœurs, économisant ainsi l’énergie, et surtout chauffant moins.

Pour le reste, il s’agit plus d’évolutions de 2008 que de réelles nouveautés.

Session : Temps réel dur avec Windows CE

Windows CE n’est à priori pas un OS dédié au temps réel. La session présente les manières de créer des applications temps réel en utilisant Windows CE (6.5). Un regret : plus de la moitié de la session servit à expliquer ce qu’est le temps réel. Du coup, la partie réservée à la mise en œuvre fut tronquée pour cause de temps, me laissant ainsi sur ma faim. Bref, en conclusion : il est possible de faire du temps réel sous Windows CE, même si, honnêtement, un OS dédié reste plus facile à appréhender et à utiliser.

Windows Azure AppFabric

Présentation des fonctionnalités de la plateforme et de ses différentes briques:

• Windows Azure: l’environnement d’exécution d’applications web (Web Role) et services (Worker Role) sur le cloud, d’APIs de stockage de fichiers sous forme de blob, de donnée en tables dénormalisées ou queues (FIFO).
• SQL Azure : environnement de stockage relationnel des données. Certaines fonctionnalités de SQL server sont ici désactivées (plus de détails) et notamment tous les services de reporting et décisionnel que l’on peut brancher sur un SQL Server classique.
• Windows Azure Platform permet d’échanger à l’intérieur du cloud et vers l’extérieur via
  • ServiceBus
    • Relaie les appels de service vers les providers du service (s’étant initialement enregistrés auprès du ServiceBus). Gestion du Multicast
    • Négocie les connexions à travers firewall, NAT, DMZ puisque le provider du service n’effectue que des connexions sortantes vers le ServiceBus qui le redirige vers un client lors d’un appel. Permet même de négocier des connexions directes entre client et provider de service lorsque la sécurité le permet.
    • Est multi plateforme, peut exposer les services en SOAP ou en REST
• AccessControl :
  • Sécurise les services, scénarios simple de user/password ou intégration avec ADFS v2
  • Fédération d’authentification entre plusieurs fournisseurs d’identité,
  • Support de Web Resource Authorization Protocol (WRAP) et Simple Web Token (SWT)

Une plateforme qui parait complète et qui privilégie la cohabitation avec des systèmes existants. La volonté apparait de ne pas se couper des standards et de s’intégrer dans des architectures hybrides.

Workshop: Développer pour Windows Azure (PaaS)

Le but de ce workshop était de montrer les différentes étapes pour créer une application hébergée sur le Cloud de Microsoft. Le cas d’étude portait sur une application ASP.NET classique. Le résultat est sans appel, rendre « Azure compliant » un site web est on ne peut plus facile :

• Déploiement, le simple ajout d’un projet dans votre solution VS2010 et il suffit alors d’un click droit pour packager l’application sous la forme d’un zip et d’un fichier de conf pour ensuite le déployer sur votre environnement Azure (AppFabric).
• Développement,  les services azures sont accessibles sous forme de surcouche de WCF, rien de nouveau à maîtriser.
• Stockage (non relationnel),lLa encore c’est simple, il suffit de connaitre la connection string donnée par AppFabric et d’utiliser une API fournie par le framework pour être capable en quelques lignes de gérer ses fichiers sur le cloud.
• Testabilité, le framework de développement met à disposition un outil « Development Fabric » permettant de reproduire en local le comportement du serveur AppFabric pour la gestion des applications, du load balancing, et du stockage. On peut donc debugger tranquillement son application en local avant de déployer.

Architectures hybrides Azure/Entreprise

Cette session dessinait brièvement différentes topologies de systèmes et de besoins et listait pour chacune d’elles les avantages et inconvénients à migrer sur le cloud Saas, PaaS ou IaaS (volontairement bref) :

• Sites web marketing: demande sporadique, pics d’affluence, besoin de sécurité réduite

=> migration du site sur le cloud, meilleure gestion des pics d’affluence, économies en maintenance et gain en disponibilité.

• Logiciel de CRM, utilisateurs nomades, besoin de disponibilité

=> passage à une offre de CRM SaaS (l’exemple classique de Salesforce), gain en maintenance, disponibilité, accessibilité depuis différents endroits et terminaux.

• Référentiel métier legacy, besoin d’accessibilité depuis l’extérieur: restrictions juridiques (zone de stockage), accès depuis multiples plateformes, besoin de sécurit

=> on garde son référentiel localement et on expose des services un outil de Bridge dialoguant avec Azure ServiceBus et permettant d’exposer son service au public contrôlé par AccessControl.

Session intéressante car elle adresse des problématiques plus réelles et ne présente pas le cloud comme la solution idéale, mais plutot comme un moyen d’amélioration, d’optimisation et d’économie.

Session : objets vivants, objets intelligents

Une session sur le design, qui partait à priori d’une très bonne initiative : explorer les comportement émergents et les interactions entre objets dès lors qu’ils sont rendus ‘intelligents’ par la technologie. Malheureusement, les projets présentés ne sont que des illustrations de concepts qui existent dans la littérature SF depuis un demi-siècle (utérus artificiel, table-écran,…). Il manquait vraiment un coté concret, sur les possibilités offertes par la technologie d’aujourd’hui (par opposition à celle du futur à base de nanomachines et autres) dans la création d’objets ‘awares’.

A suivre …

Mick Philippon, Nicolas Raynaud, Olivier Roux

Suggestion d'articles :

1. Microsoft Techdays 2010 (1/3)
2. Microsoft Techdays 2010 (3/3)
3. Le Cloud selon Microsoft, retour de TechEd 2010

Les Techdays sont l’occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d’outils sous forme de présentations, d’ateliers ou de retour d’expérience. Difficile de couvrir complètement cet événement tant l’offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts, sur les sessions que nous avions choisi et de partager avec vous notre ressenti.

Ce premier post revient plus particulièrement sur le lancement des nouveaux frameworks.

Les plénières

Avec la sortie de Windows 7 en fin d’année dernière et de celles d’Office, Visual Studio, du CLR 4, EntityFramework 4, d’ASP.net 4 et de Silverlight 4 en 2010, le programme des plénières se devait d’être copieux – sans parler la partie administration et déploiement de l’OS, les serveurs (SQLServer 2008 R2 …), Sharepoint et Azure. Le moins que l’on puisse dire, c’est que cela a surtout été brouillon notamment pour la première : une course effrénée pour en montrer le plus possible. Si je dois résumer en deux faits marquants, ce sera surtout sur … Office :)

Outlook conforte son rôle d’outil central dans la sphère Office.

Après les mails, les calendriers, les contacts, les aperçus des docs Office, il intègre dorénavant le « chat » + la présence de l’utilisateur et un micro-twitter (équivalent statut dans gtalk). Exchange dématérialise les messages vocaux pour les faire apparaître comme un mail dans la messagerie – idéal quand le collaborateur se déplace souvent car il a un seul point d’entrée pour gérer ses communications.  Et surtout Outlook implémente la notion de conversation … c’est vrai qu’il fallait l’inventer. Finalement, au collaboratif près, il ressemble un peu aux ambitions de Wave sauf qu’au moins je sais à quoi il sert.

Des outils plus collaboratifs

Puisqu’on parle de collaboratif, j’arrive au seul truc qui m’a donné envie d’acheter (tout de suite) Office, c’est la possibilité de travailler simultanément sur le même document !! Fini les merges de présentation. L’ensemble des produits Office sont disponible en version WebAccess (contre seulement Outlook aujourd’hui).

L’objectif est clair : concurrencer google apps pour les pro.

Session : Entity Framework 4

Si on regarde la session naïvement, on a l’impression de voir un outil formidable et innovant avec un grand nombre d’améliorations (lazy loading, approche code-first en plus de base first …). Sauf que NHibernate fait déjà tout ça. Cela laisse une impression plus que mitigée ; on va dire que le produit commence à être compétitif. Le designer saura peut-être s’attacher les faveurs des décideurs.

Sinon, on a abordé au cours de la session T4 qui est un outil présent depuis un moment dans VisualStudio mais qui en 2010 à l’avantage d’être plus facile d’accès. Il s’agit d’un outil permettant de créer des templates et donc de générer du code facilement (idéal pour certaines portions fastidieuses et sans valeur ajoutée). Reste à ne pas tomber dans l’excès du tout généré ; d’autant que comme il a été sorti des couches de présentation, il peut être appelé de manière totalement indépendante.

Session : ASP.net 4

Bon, au temps le dire tout de suite, ASP.net 4, seul, n’est pas une révolution.

Il n’en reste pas moins qu’il apporte un certains nombre d’améliorations sur la gestion des identifiants et du viewstate, les url friendly ou encore l’embarquement natif de bibliothèques de graphes assez sexy et paramétrables (génération dynamique d’images donc compatible tout navigateur).

Un effort fourni pour développer des applications aux standards du Web

Le développeur peut également choisir à partir de cette version le mode de rendu de son composant graphique. C’est à dire les balises HTML réellement générées ce qui simplifie la gestion des styles.

Il est à noter que, comme pour de nombreuses autres séances, les démos ont été faites sur Firefox, histoire de montrer la compatibilité des développements MS aux standards du web (et autres produits que IE).

ASP.net 4 couplé par exemple ASP.net MVC 2 (ou spring.net par exemple) fournit une solution assez élégante et rapide pour développer des applications Web.

Session : Nouveautés de WPF 4

La session a débuté très doucement en présentant des nouveautés qui relèvent plus de la correction de bug (i.e. Lisibilité des petites polices) et de la mise à niveau de WPF par rapport à Silverlight plus abouti dans certains domaines. En vrac, possibilité de Bitmap caching d’animations pour améliorer les performances d’un écran chargé, animations facilitées avec le EasingAnimations (les rendant plus « naturelles ») ou encore l’arrivée du VisualStateManager présent depuis longtemps dans SilverLight.

Les vraies nouveautés viennent en deuxième partie !

WPF4 s’intègre à Windows 7: des contrôles et fonctionalités font leur apparition pour améliorer l’usabilité en tirant partie des possibilités de l’OS (personnalisation des menus contextuels de la taskbar), support du multitouch (évènements et processors du framework Surface). Amélioration du binding qui supporte maintenant les DynamicObjects, et l’intellisense fait enfin son apparition dans le xaml pour les propriétés de binding !

Session : Sur le futur de XAML

XAML est le XML décrivant les composants graphiques de Silverlight et WPF. Dorénavant toute la mécanique a été extraite de ces deux produits pour en faire une DLL à part : objectif convergence. Objectif particulièrement important car elle est aussi utilisée avec Workflow Foundation (support pour l’instant des anciens workflow) et avec le XPS – le PDF like de Microsoft.

XAML, représentation XML unique d’un arbre d’objets

En fait, il faut voir XAML comme une représentation XML de n’importe quel arbre d’objets. On peut de manière extrêmement simple sérialisé/désérialisé des objets en XAML et bénéficier de tous les optimisations faites sur la composition des balises. Enfin, l’apparition intéressante de XAMLDom, parser interrogeable via du Linq, permet de faire du code concis et lisible et pour du XML c’est pas négligeable !

Session : Ergonomie des applications multi-touch

Avec la sortie de Windows 7 et de ses API multi-touch, cette session qui revient sur l’histoire du multi-touch (avec des réalisations datant des année 80), sur les possibilités offertes par cette forme d’interaction et surtout sur ses limites. La session allait au delà du multi-touch, avec l’évocation du projet Natal et des contrôles cérébraux. Très critique sur ces nouvelles formes d’interaction, qui sont, contrairement à ce qu’on pourrait penser en voyant l’engouement qu’elles suscitent, limitées, la session s’est attardée sur les limites de chacune.

Quelques illustrations, sur, par exemple, la précision impossible en multi-touch (essayez de faire du photoshop précis au pixel près avec vos gros doigts, pour voir), la fatigue inhérente à l’utilisation du projet natal (Minority report c’est bien, mais après huit heures, tu as des bras d’haltérophile), etc. ont permis de carder les limites de ces nouvelles formes d’interactions et, finalement, de se demander si le vieux couple clavier souris n’a pas encore de beaux jours devant lui.

Session : Sharepoint 2010 et Visual Studio 2010

Enfin ! C’est le sentiment principal. Avec les versions 2010, le développement Sharepoint est enfin intégré nativement à Visual Studio. Plus besoin de télécharger des add-ins et autres SDK dédiés, tout est dans la boite.

On trouve donc des modèles de projets dédiés Sharepoint dans Visual Studio 2010, des assistants pour faciliter les tâches courantes …

Session : Développement, suivi et tableaux de bord

Cette session présente EPM (Entreprise Project Manager), qui regroupe Microsoft Projet et le serveur associé. Conclusion principale : Project, c’est très bien pour faire du financier et des rapports pour les chefs, mais pour le développeur au quotidien, ça ne sert à rien.

L’intérêt principal de la session était dans l’exposé des passerelles possibles entre Team Fondation Server (et son utilisation dans le cadre d’une méthodologie Agile) et EPM. Une telle passerelle permettrait au développeur de travailler avec TFS et aux chefs d’avoir les données financières associées.

L’interopérabilité entre EPM et Excel 2010 a également été mise en avant, partant du constat qu’Excel est aujourd’hui l’outil majoritaire pour la gestion de projet.

A suivre …

Mick Philippon, Nicolas Raynaud, Olivier Roux.

Suggestion d'articles :

1. Microsoft Techdays 2010 (3/3)
2. Microsoft Techdays 2010 (2/3)
3. Le Cloud selon Microsoft, retour de TechEd 2010