Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.

Conditions du test

Afin d’évaluer diverses structures de messages, le prototype utilise une structure arborescente. Traditionnellement, ce type de structure est récursif. Cependant, il n’est pas compatible avec la limitation de Thrift sur la déclaration avancée abordée dans le précédent article.
La profondeur a donc été arbitrairement limitée au niveau 6, soit 127 nœuds au maximum pour un arbre binaire complet. Il y a un type différent par profondeur, de Node0 pour la racine à Node6 pour les feuilles les plus basses. Les arbres générés le sont selon trois paramètres :

• le nombre total de nœuds, qui permet de faire varier le nombre d’objets du message,
• la cardinalité des fratries , qui joue sur la complexité : plus cette cardinalité est faible pour un nombre de nœuds donné, plus les fratries sont petites et nombreuses, donc plus le message est complexe,
• et la taille des nœuds, qui est fonction du champ « description ». Son contenu est une chaîne de caractères différente pour chacun d’eux et générée par décalage des valeurs Unicode des caractères.

La construction des arbres se fait récursivement et équitablement entre les fils d’un nœud. Ci-dessous trois exemples d’arbre à 5 nœuds avec, de gauche à droite, des tailles de fratries de 1, 2 et 3. Les numéros sont présents à titre indicatif et indiquent l’ordre de création des nœuds par l’algorithme de construction.

Les déclarations dans les IDLs Thrift IDL et Protocol Buffers language sont disponibles en fin d’article. Les versions utilisées sont 0.8.0 pour Thrift, 2.4.1 pour Protocol Buffers et HotSpot 1.6.0_29 pour la JVM.

Impact du nombre d’objets du message

Dans un premier temps, la complexité est fixée au minimum :

• La longueur des descriptions de chaque nœud est constante (32 caractères),
• le nombre de nœuds est variable,
• la structure choisie est le 1024-tree qui équivaut à un arbre à deux niveaux dans cette étude.

En effet, si la cardinalité des fratries est supérieure au nombre de nœuds n, on obtient un arbre à deux niveaux, une racine Node0 et n-1 enfants Node1. Les 1024-trees de cet article ont tous cette structure car n est toujours inférieur à 1024.

Tracer la taille du message sérialisé en fonction du nombre de nœuds donne le graphe suivant :

Aussi bien sur cet histogramme que sur les suivants, une barre plus basse correspond systématiquement à un meilleur résultat et l’ordre des barres (de gauche à droite) correspond à celui de la légende (de haut en bas).
Sur ce premier graphique, on retrouve un constat du benchmark Java Serializers, mais dans un contexte de message plus complexe : Thrift et protobuf ont des performances très proches.

Le graphique ci-dessous rapporte leurs résultats à ceux de la sérialisation Java. On constate que leur avantage en termes de taille de message s’amenuise à mesure que l’arbre grossit.

Sur le graphique suivant, on observe que la taille moyenne d’un nœud décroît rapidement pour la sérialisation Java. En effet, le protocole de sérialisation Java ajoute aux informations du message lui-même la description des classes sérialisées. Ce surcoût, important pour un petit message, devient négligeable pour des messages constitués de nombreux objets du même type.

Les protocoles de protobuf et Thrift, quant à eux, contiennent très peu d’information de structure : uniquement un identifiant de champ et un type. Ainsi ils voient la taille moyenne d’un nœud croître légèrement, car les listes d’enfants augmentent en nombre et taille quand l’arbre grossit.

Impact de la taille des objets

Pour ce second test, on fige la structure du message pour mesurer l’influence de la quantité d’information contenue dans chaque nœud :

• Un 1024-tree est considéré comme dans le test précédent,
• sa taille est fixée à 31 nœuds,
• la taille du champ « description » est utilisé comme variable.

Les résultats concernant la taille du message sont similaires au test précédent, Thrift et protobuf sont très proches et font mieux que la sérialisation Java surtout pour de petits objets.

Figer la structure du message montre que la différence de taille par rapport au protocole de sérialisation Java est quasi-constante. Ceci est dû au fait que protobuf et Thrift n’apportent aucun gain notable lorsqu’on fait varier la taille de la chaîne de caractères.
En effet, les trois protocoles en jeu la sérialisent sous forme de chaîne en UTF8 précédée de sa longueur. La différence est que le protocole Java utilise 2 octets pour la longueur des chaînes de moins de 2^16 caractères, tandis que les deux frameworks ont recours à un varint. Le saut entre 64 et 128 caractères est dû au fait que le format varint n’utilise qu’un octet pour coder les entiers entre 0 et 127, puis deux de 128 à 2^14.

Impact de la structure du message

Pour évaluer l’influence de la structure du message :

• la description de chaque nœud est fixée à 32 caractères,
• le nombre de nœuds est variable,
• la cardinalité des fratries prend trois valeurs : 2, 4 et 1024.

Par exemple, voici les trois variations considérées de l’arbre à 7 nœuds :

Le graphique qui suit recense les tailles des messages sérialisés.

Pour tous les protocoles de sérialisation, le comportement est similaire : plus de complexité conduit à un message sérialisé moins compact.
Cela est dû au fait que plus de complexité se traduit par un plus grand nombre de listes de noeuds-enfants. Cependant, la variation reste négligeable (environ 1%) pour Thrift et protobuf.

Le protocole de sérialisation Java est lui plus fortement influencé (jusqu’à 13%). En effet la quantité d’information utilisée par les descripteurs de classes est liée au nombre de types de classes mises en jeu. Plus les fratries sont grandes, moins on utilise de classes différentes. Par exemple, pour 63 nœuds, le 2-tree utilise toutes les classes de Node0 à Node5, le 4-tree s’arrête à Node3, et le 1024-tree à Node1.
Le résultat particulièrement bon du 2-tree de taille 127 est lié au fait que Node6 n’a pas de liste d’enfants et est donc plus compact que les autres types de Nodes. Dans cet arbre, la majorité des nœuds (64) est de type Node6.

Les tailles moyennes par nœud sont représentées dans l’histogramme ci-dessous :

L’évolution est conforme aux observations du premier test : l’écart entre Java et les deux frameworks s’amenuise lorsqu’on augmente la taille du graphe sans pour autant être négligeable.

En traçant le gain apporté par les deux frameworks par rapport à la sérialisation Java on obtient :

Par exemple, en considérant le message du 4-tree à 63 nœuds et un système devant soutenir une charge de 10000 requêtes/s, le remplacement de la sérialisation Java par Thrift permet de diminuer le besoin de bande passante de 75.45 Mo/s à 40.68Mo/s, soit un gain de 46%.

Conclusion

Cet article a présenté une comparaison portant sur la taille de sérialisation avec des messages complexes. Par rapport au benchmark JVM-serializers, l’avantage de Thrift et protobuf sur la sérialisation native Java est moins décisif en termes de compacité, même s’il reste intéressant.

La taille du message sérialisé par Thrift ou Protocol Buffers n’est pas influencée par la structure même du message. C’est surtout son volume qui a un impact : les deux frameworks offrent une sérialisation bien plus compacte que celle de Java surtout sur de petits messages. Cette observation rejoint le fait que Protocol Buffers n’est pas particulièrement adapté aux volumes de données importants.

Il faut rappeler qu’employer la sérialisation native Java comme référence n’est légitime que parce que cet article se limite aux protocoles de sérialisation. Thrift et Protocol Buffers offrent d’autres avantages tels l’interopérabilité avec plusieurs langages et la compatibilité ascendante et descendante des messages. Ils sont abordés dans l’article précédent.

Pour aller plus loin, on pourrait analyser les temps de sérialisation, l’empreinte mémoire, l’intégration aux processus de build…

Annexes

Voici la déclaration des objets en Thrift IDL : tree.thrift

namespace java com.octo.example.serialization.model.thrift

enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}
struct Node6 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
}
struct Node5 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
    6: list children,
}
[...]

et ainsi de suite jusqu’au Node0, qui correspond la racine de l’arbre. L’ordre employé évite le recours à la déclaration avancée.

Ci-dessous, l’équivalent en Protocol Buffers language : tree.proto

package serialization;

option java_package = "com.octo.example.serialization.model";
option java_outer_classname = "LimitedTreeProto";

enum RoomType {
    SINGLE =0;
    DOUBLE =1;
    SUITE =2;
}
message Node0 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
    repeated Node1 children = 6;
}
[...]
message Node6 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
}

L’ordre des nœuds plus naturel est supporté par le compilateur Protobuf.

Suggestion d'articles :

1. Sérialisation : Thrift et Protocol Buffers, principes et aperçu
2. Socle technique des applications Java EE : dans le WAR ou dans le serveur ?
3. Les nouveautés du langage dans Java 7

La sérialisation est une des bases de la transmission de données entre systèmes. Certains langages proposent d’ailleurs une méthode de sérialisation en standard, qui leur est souvent propre.

L’interopérabilité entre systèmes hétérogènes nécessite que le format de sérialisation soit compréhensible par différents langages et plates-formes. De nombreux standards utilisent le mécanisme d’IDL (Interface Description Language) pour répondre à ce besoin : ASN.1, CORBA ou encore SOAP.

Depuis quelques années, de nouveaux frameworks basés sur un IDL ont vu le jour pour l’interopérabilité de technologies hétérogènes dans une optique d’économie de bande passante. Parmi eux, on trouve Thrift et Protocol Buffers. Ce premier article présente les deux frameworks sous l’angle de la sérialisation des messages et détaille leur utilisation en Java.

Historique et objectifs

Thrift et Protocol Buffers (abrégé en protobuf) ont en commun d’avoir été développés par des acteurs majeurs du Web. Thrift a été initialement développé par Facebook, et est désormais en incubation chez Apache suite à son passage en open source. Protocol Buffers a commencé comme framework interne chez Google, où son utilisation est majoritaire. L’ouverture de son code source s’est faite après une remise à plat nommée Proto2.

Afin de s’affranchir des barrières de langages, ces deux frameworks reposent sur des mécanismes classiques :

• un IDL pour décrire les structures de données,
• une génération statique du code de sérialisation dans divers langages de programmation,
• un protocole de sérialisation, c’est-à-dire une méthode de représentation des messages.

On peut par exemple générer du code permettant l’échange de messages entre Java et C++ :

Cet article se focalise en priorité sur le protocole de sérialisation, qu’il convient de distinguer du protocole de transport. Ce dernier correspond au support véhiculant le message sérialisé suivant le protocole de sérialisation.

Pourquoi de nouveaux protocoles de sérialisation ?

Protobuf se limite au protocole de sérialisation, et est donc similaire à la CDR de CORBA ou à ASN.1 associé à un encodeur : il s’agit uniquement de représenter un message sous forme sérialisée.
Thrift y ajoute des implémentations de RPC en mode client/serveur sur plusieurs protocoles de transport (HTTP, Socket, File…). Leurs fonctionnalités sont limitées par rapport à ce que propose CORBA par exemple : Thrift ne propose pas de gestion des transactions, de reprise sur erreur ou de fonctionnalités d’annuaire.

Les principes de Thrift et Protocol Buffers ne sont donc pas nouveaux. Ces deux frameworks ont néanmoins deux avantages majeurs pour les contextes de haute disponibilité et forte scalabilité, tels ceux de Google ou Facebook :

• Compatibilité ascendante/descendante : permet de faire évoluer l’interface sans nécessiter de redéploiement immédiat de toutes les applications concernées
• Taille de message et temps de sérialisation/désérialisation optimisés : permettent de minimiser les besoins de bande passante et de temps de traitement. Le champ d’utilisation peut de plus être étendu à la persistance de données.

L’argument de compacité du message est uniquement valable si on emploie le protocole de sérialisation binaire de Protobuf et le protocole compact de Thrift, car ils permettent une optimisation de la taille du message à l’octet près.
Par exemple, les deux sérialisent une chaîne de caractères en la faisant précéder par sa longueur, à l’instar de CDR. Mais ils codent cette longueur avec un varint, qui est plus compact que l’entier sur 32 bits employé par CDR.

IDL et interfaces

Thrift et Protobuf se ressemblent énormément en pratique. L’IDL du premier s’appelle Thrift IDL, celui du second se nomme simplement protocol buffer language. Les deux frameworks supportent la plupart des types de données courants, le détail est disponible ici pour Thrift et là pour Protobuf.

L’exemple considéré est l’objet Node dont une version en Java est la suivante :

package com.octo.example.serialization.model;

public class Node implements Serializable {
    private Integer mNumber;
    private boolean mEven;
    private Double mRate;
    private RoomType mType;
    private String mDescription;
[...]
}

Il contient quelques membres de types différents, dont une énumération ; les accesseurs ont été omis par concision.

Voici le descripteur équivalent en Thrift IDL : tree.thrift

namespace java com.octo.example.serialization.model.thrift
enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}
struct Node {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type = RoomType.SINGLE,
    5: optional string description
}

La première ligne permet de spécifier le package Java auquel appartiendra le code généré par le compilateur Thrift. L’énumération RoomType associe une constante numérique à chaque valeur possible. Puis notre objet Node lui-même est défini.
En Thrift IDL, chaque champ est défini par

• un identifiant unique
• suivi de l’indication s’il est optionnel ou non (optional/mandatory),
• puis son type,
• son nom
• et une valeur par défaut précédée du signe = si nécessaire.

Le message est donc sérialisé sous forme clef-valeur, avec l’identifiant unique comme clef. La valeur contient le type puis la valeur elle-même. Voici à fins d’illustration ce que donne la struct Node sérialisée avec le protocole de sérialisation TJSONProtocol de Thrift :

{
  "1":{
    "i32":0
  },
  "2":{
    "tf":1
  },
  "3":{
    "dbl":0.0
  },
  "4":{
    "i32":0
  },
  "5":{
    "str":"Lorem ipsum dolor sit amet, cons"
  }
}

Voici le pendant en Protocol Buffers language : tree.proto

package serialization;
option java_package = "com.octo.example.serialization.model";
option java_outer_classname = "TreeProto";
enum RoomType {
    SINGLE =0;
    DOUBLE =1;
    SUITE =2;
}
message Node {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4 [default = SINGLE];
    optional string description = 5;
}

La première ligne correspond au package protobuf, ce qui permet d’éviter les conflits lors d’imports de fichiers .proto externes par exemple. Les deux lignes suivantes sont des options propres à la génération de code Java ; il s’agit du nom de package et du nom de la classe générée par protoc.
La déclaration d’un champ se fait de manière similaire à celle de Thrift :

• l’indication si le champs est optionnel (optional) ou non (required),
• puis son type,
• son nom,
• son identifiant unique précédé du signe =
• suivi d’une valeur par défaut si nécessaire.

La sérialisation suit le même principe que celle de Thrift : le message est sérialisé en clef-valeur avec l’identifiant unique comme clef. Le détail de l’encodage binaire est fourni ici.

Versioning et évolution de l’interface

La compatibilité ascendante/descendante des messages nécessite de respecter certaines règles afin d’être garantie. Ces dernières sont similaires pour les deux frameworks.
La pierre angulaire de la compatibilité est l’identifiant unique associé aux champs. La principale règle de désérialisation est que tout champ d’identifiant inconnu est ignoré. Il reste néanmoins conservé dans le message car il peut être utile à d’autres versions de l’interface.

Les règles à respecter lors de l’évolution des interface sont les suivantes

• les identifiants de champs doivent être invariants
• tout champ ajouté dans une nouvelle version doit être optionnel, sous peine de ne plus pouvoir lire les messages issus d’anciennes versions
• les valeurs par défaut ne doivent en général pas être modifiées. En effet, elles ne sont pas transmises dans le message sérialisé, mais assignées par le code de désérialisation
• tout champ obligatoire doit être présent dans toutes les versions de l’interface, passées ou futures.

A ces règles protobuf ajoute

• des compatiblités entre types, par exemple entre uint32 et bool,
• un mécanisme d’extension afin de réserver des plages d’identifiants pour une utilisation future, pour de l’héritage par exemple.

Génération du code

L’étape suivante consiste à générer le code correspondant aux objets et interfaces définies ci-dessus. Le compilateur Thrift est utilisé de la manière suivante :

thrift -v --gen java -o . tree.thrift

Le code généré est placé dans un sous-répertoire gen-java, avec autant de fichiers-classes que de structs et énumérations :

gen-java
└── com
    └── octo
        └── example
            └── serialization
                └── model
                    └── thrift
                        ├── Node.java
                        └── RoomType.java

Pour Protobuf, le principe reste le même, même si la ligne de commande change un peu :

protoc -I=project/root/ --java-out=. tree.proto

Dans ce cas un unique fichier est généré, contenant l’ensemble des messages sous forme de classes internes

java
└── com
    └── octo
        └── example
            └── serialization
                └── model
                    └── TreeProto.java

Cas particulier : déclaration avancée et récursion

Le but initial de l’exemple était de sérialiser un arbre constitué de nœuds. Or Thrift ne supporte pas la déclaration avancée, donc les structures récursives. Cette limitation est explicite dans le white paper de Thrift :

Due to inherent complexities and potential for circular dependencies, we explicitly disallow forward declaration. Two Thrift structs cannot each contain an instance of the other.

Par exemple, le compilateur Thrift bloque sur deux erreurs lors du parsing de la struct suivante :

namespace java com.octo.example.serialization.model.thrift
struct InvalidNode {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type = RoomType.SINGLE,
    5: optional string description,
    6: list<InvalidNode> children
}
enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}

La première est à la ligne 6 : Type « RoomType » has not been defined, et la seconde à la ligne 8 : Type « Node » has not been defined.

Protobuf n’a pas cette limitation et compile donc sans erreur un .proto équivalent. La classe chargée de la sérialisation, CodedInputStream propose une sécurité sur le niveau de récursion. La limite par défaut est de 64, et peut être modifiée via la méthode setRecursionLimit.

Conversion modèle applicatif – objets sérialisables

Si l’applicatif utilise déjà un modèle d’objets existants, des méthodes de conversion entre ce modèle et les objets sérialisables doivent être développées. Ni Thrift ni protobuf ne proposent de moyen d’automatiser ou de générer ce code de conversion. Afin d’éviter ce surcoût, il est préférable de manipuler directement les objets sérialisables générés à l’étape précédente quand cela est possible.

Dans l’exemple, l’objet de départ Node est un simple POJO, la conversion a donc été codée manuellement dans des classes dédiées à la sérialisation. Les objets générés par Thrift exposent des accesseurs pour chacun des champs :

package com.octo.example.serialization.serializers.tree;

public class ThriftTreeSerializer {
[...]
    public com.octo.example.serialization.model.thrift.Node convertToSerializable(Node pNode) {
        com.octo.example.serialization.model.thrift.Node vNode = new com.octo.example.serialization.model.thrift.Node();
        vNode.setNumber(pNode.getNumber());
        vNode.setRate(pNode.getRate());
        vNode.setType(RoomType.valueOf(pNode.getType().toString()));
        vNode.setDescription(pNode.getDescription());
        vNode.setEven(pNode.isEven());
        for (Node vChild : pNode.getChildren()) {
            vNode.addToChildren(convertToNode1(vChild));
        }
        return vNode;
    }
}

Protobuf utilise des messages immuables et le pattern builder :

package com.octo.example.serialization.serializers.tree;

public class ProtoBufTreeSerializer {
[...]
    public com.octo.example.serialization.model.LimitedTreeProto.Node convertToSerializable(Node pNode) {
        com.octo.example.serialization.model.LimitedTreeProto.Node.Builder vBuilder = com.octo.example.serialization.model.LimitedTreeProto.Node.newBuilder()
        .setNumber(pNode.getNumber())
        .setRate(pNode.getRate())
        .setType(LimitedTreeProto.RoomType.valueOf(pNode.getType().toString()))
        .setDescription(pNode.getDescription())
        .setEven(pNode.isEven());
        for (Node vNode : pNode.getChildren()) {
            vBuilder.addChildren(convertToNode1(vNode));
        }
        return vBuilder.build();
    }
}

Une autre méthode consiste à faire implémenter l’interface Externalizable aux objets du modèle applicatif. Cela permet d’utiliser l’un des deux frameworks tout en maintenant la compatibilité avec les API de sérialisation Java standards. Cependant, l’utilisation du protocole de sérialisation de Java augmente la taille du message, notamment à cause la présence des noms de classes complets.
Sur un court message, le surcoût est rédhibitoire. À titre d’exemple, le même Node pèse 49 octets s’il est sérialisé par protobuf directement, et 118 octets si on utilise protobuf via Externalizable.writeExternal.

Sérialisation en pratique

Thrift propose plusieurs protocoles de sérialisation à choisir parmi les implémentations de TProtocol fournies, dont deux binaires :

• TBinaryProtocol : code chaque champ est sous la forme longeur puis valeur binaire,
• TCompactProtocol : produit un message plus compact grâce à des optimisations, dont l’utilisation systématique de varints.

Ce dernier est préférable et globalement équivalent à celui de protobuf. Voici un exemple de classe de sérialisation avec Thrift

package com.octo.example.serialization.serializers.tree;
import com.octo.example.serialization.model.thrift.Node;
[...]
public class ThriftTreeSerializer {
    public byte[] serialize(Node Object) throws Exception {
        TSerializer serializer = new TSerializer(new TCompactProtocol.Factory());
        return serializer.serialize(Object);
    }
    public Node deserialize(byte[] pMessage) throws Exception {
        TDeserializer deserializer = new TDeserializer(new TCompactProtocol.Factory());
        Node vRoot = new Node();
        deserializer.deserialize(vRoot, pMessage);
        return vRoot;
    }
[...]
}

Protobuf lui ne propose nativement qu’un protocole binaire. Des extensions permettent le support d’autres protocoles de sérialisation, par exemple protobuf-java-format qui sérialise en JSON, XML ou HTML.
La classe de sérialisation équivalente en protobuf :

package com.octo.example.serialization.serializers.tree;
import com.octo.example.serialization.model.LimitedTreeProto.Node;
[...]
public class ProtoBufTreeSerializer {
    public byte[] serialize(Node object) throws Exception {
        return object.toByteArray();
    }
    public Node deserialize(byte[] message) throws Exception {
        CodedInputStream vStream = CodedInputStream.newInstance(message);
        return Node.parseFrom(vStream);
    }
[...]
}

Conclusion

Thrift et Protocol Buffers sont deux frameworks qui n’innovent pas sur le principe. Les deux frameworks sont relativement similaires et répondent surtout aux besoins des sociétés qui les ont créées, Facebook et Google. Elles ont revisité les mécanismes classiques d’interopérabilité via un IDL, en mettant l’accent sur les performances et la compatibilité ascendante et descendante, deux caractéristiques cruciales dans leur contexte. Ces frameworks proposent principalement de la sérialisation, avec en sus une implémentation RPC simple pour Thrift.

Du fait de la génération statique de code et de la nécessité potentielle de développer des méthodes de conversion, leur utilisation peut s’avérer coûteuse à mettre en œuvre. Comme beaucoup d’outils spécialisés, il vaut donc mieux avoir un besoin avéré de leurs avantages et bien évaluer leurs limitations avant d’envisager leur utilisation.

D’autres frameworks de sérialisation utilisent des principes différents de ceux de Thrift et Protocol Buffers. Apache Avro notamment, qui repose sur la présence systématique de l’interface dans le format sérialisé. Cela lui permet de rendre la génération de code optionnelle et de se passer d’identifiants uniques de champs.

Thrift et Protocol Buffers obtiennent des performances équivalentes dans un benchmark regroupant plusieurs sérialiseurs Java. Ce benchmark se limite toutefois à l’utilisation d’un unique message. Dans un prochain article, les deux frameworks seront comparés en termes de compacité de la sérialisation avec une structure de message variable.

Références

Les versions utilisées pour cet article sont la 0.8.0 pour Thrift et la 2.4.1 pour Protocol Buffers. Les liens suivants sont en anglais.

• Documentation officielle de Protocol Buffers : complète et didactique.
• Thrift : the missing guide, plus clair et détaillé que le très léger Wiki officiel de Thrift.
• Thrift white paper
• Java serializers benchmark : comparaison souvent remise à jour des performances d’un grand nombre de couples sérialiseurs/protocoles.
• Thrift vs Protocol Buffers : comparaison des deux projets d’un point de vue global (documentation, qualité de code, fonctionnalités, performances…)

Suggestion d'articles :

1. Thrift et Protocol Buffers : compacité du message sérialisé dans le monde Java
2. Des principes (ou quelques idées…) REST et du Mashup

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

« La complexité, c’est comme le cholestérol. Il faut surtout se débarasser du mauvais. » (Proverbe gascon-malgache)

DDD est l’acronyme de Domain Driven Design. Ce n’est ni un framework, ni une méthodologie, mais plutôt une approche décrite dans l’ouvrage du même nom d’Eric Evans. Un de ses objectifs est de définir une vision et un langage partagés par toutes les personnes impliquées dans la construction d’une application, afin de mieux en appréhender la complexité. Nous ne souhaitons pas faire ici une présentation de DDD (voir plutôt ici pour une introduction). Nous voulons montrer comment DDD peut adresser certaines problématiques évoquées dans l’article “J’ai mal à mon application ! Ca se soigne ?” au travers d’un exemple d’application (“je veux vendre et acheter des légumes sur internet”), tout en s’inscrivant dans une démarche de développement Agile.

User Stories et Ubiquitous Language

Dans notre exemple, on veut créer un site web qui permet aux agriculteurs de mettre en vente leur production, et aux consommateurs d’acheter ces produits. Il s’agit là de notre Bounded Context, c’est-à-dire les bornes de notre domaine. Imaginons une équipe projet Agile typique pour assurer le build et le run de cette application : Product Owner, experts métier, développeurs…

L’équipe doit produire des Users Stories qui représentent les besoins utilisateur à implémenter. C’est également l’occasion de définir le langage partagé (Ubiquitous Language) :

• En tant qu’agriculteur , je veux m’inscrire afin de pouvoir mettre en vente des légumes
• En tant qu’agriculteur, je veux mettre en vente une quantité de légumes à un certain prix
• En tant qu’agriculteur, je veux pouvoir changer le prix d’un légume mis en vente
  
• En tant qu’agriculteur, je veux voir un message d’erreur si ma mise en vente ne respecte pas la spécification d’une mise en vente autorisée 
• En tant que consommateur, je veux consulter la liste des agriculteurs de ma région
• En tant que consommateur, je veux m’abonner afin d’être notifié lors de la baisse du prix d’un légume

Ici, les termes et expressions “consommateur”, “agriculteur”, “spécification d’une mise en vente autorisée”… font partie du langage partagé de notre contexte. Ils pourront être utilisés indifféremment par l’ensemble des acteurs projets et désigneront toujours les mêmes concepts : ils constituent le “langage pivot” des échanges entre ces différents acteurs. C’est une des raisons pour lesquelles tous les acteurs impliqués dans la construction du produit doivent être présents lors des ateliers de cadrage des User Stories, chaque intervenant pouvant contribuer et s’imprégner du langage commun. Une piste pour partager ce dernier peut être de définir un lexique dans une page wiki.

Voyons maintenant comment implémenter ces User Stories…

Langage objet et programmation procédurale

Dans la plupart des applications, nous observons très souvent la même architecture : IHM + services procéduraux + objets du domaine anémiques + accès aux données (typiquement via un ORM). On retrouve alors souvent des services dont le code ressemble à ce qui suit :

1
2
3
4
5
6
7
8
9
10
11
12

public void acheterDesLegumesAUnAgriculteur(Integer consomateurId, Integer agriculteurId, Integer legumeId, Integer quantite){
   Consommateur consommateur = consomateurWsClient.getConsommateur(consomateurId);
   Agriculteur agriculteur = agriculteurDAO.getById(agriculteurId);
   consommateur.getPanier().put(legumeId,quantite);
   verifierAgriculteurALeLegume(agriculteur,legumeId,quantite);
   BigDecimal prix = recupererPrix(agriculteur,legumeId,quantite);
   bankService.transfererArgent(consommateur.getRib(),agriculteur.getRib(),prix);
   agriculteur.putLegume(legumeId,agriculteur.getLegume(legumeId)-quantite);
   agriculteurDAO.save(agriculteur);
   String message = creerMessageAchat(agriculteur,legumeId,quantite);
   mailService.sendMail(consommateur.getMail(),message);
}

On constate que le code de cette méthode s’apparente à un script, qui manipule des structures de données et invoque des “fonctions” exposées par des composants plus ou moins techniques.

Finalement, nous utilisons ici très peu les concepts inhérents au paradigme du langage, dont la notion même d’objet comme structure de données capable de répondre à des messages, d’interagir. C’est là tout le paradoxe du langage objet utilisé pour faire de la programmation procédurale ! En fait, la plupart des systèmes sont modélisés par leurs données, et non par leurs interactions.

Nous avons pourtant l’impression que la programmation orientée objet pourrait nous aider à traiter plus efficacement des problèmes complexes, en s’appuyant sur des patterns et principes tels que l’encapsulation ou la séparation de responsabilités. Ça tombe bien, car la POO est au coeur de DDD ! Et notamment au coeur du modèle du domaine.

Modélisation du domaine

Cette activité doit nous permettre de nous attaquer à la complexité essentielle, c’est-à-dire celle qui est consubstancielle du problème à résoudre. Quelle est notre problématique métier ? Quels sont les « objets » mis en jeu ? Quels sont les comportements, les règles qui régissent les interactions ? Le modèle du domaine doit être “ubiquitous”, c’est-à-dire partagé par l’ensemble des acteurs contribuant à la construction du produit. Les noms et les verbes utilisés font partie de l’ubiquitous language. L’architecture logicielle qui va porter notre application devra être au service de notre domaine.

Qui modélise ? Quand ?

En début d’itération, l’équipe définit et échange sur les User Stories à traiter et s’accorde un temps de réflexion pour partager sa vision du modèle du domaine. Utilisateurs et experts métiers apportent leur connaissance du problème à résoudre ; développeurs et architectes fournissent leur point de vue d’experts techniques. L’équipe doit garder en tête que le modèle retenu a une limite de validité (modèle valide sous contraintes), puisqu’il est conçu pour :

• Modéliser une problématique bien précise et uniquement celle-ci : celle du Bounded Context en question
• Répondre au problème qui se pose aujourd’hui : demain, nous pourrons raffiner le modèle
• Être implémentable techniquement : si les composants et mécanismes purement techniques (relatifs à l’implémentation logicielle) ne font pas partie du domaine et ne doivent pas le polluer, la modélisation ne doit pas non plus ignorer ce qui effectivement réalisable et ce qui ne l’est pas !

Avec quels outils ?

On peut utiliser un tableau blanc et dessiner une représentation du modèle. Pour faire cela, UML peut aider, mais un AGL n’est pas nécessaire.  Il n’est pas non plus nécessaire d’avoir une représentation exhaustive du modèle. La représentation que l’on donne n’est qu’un moyen d’échange, de partage de la compréhension par l’ensemble des acteurs. Puisque le modèle est ubiquitous, si l’on souhaite conserver une représentation particulière, il faut se poser la question : quelle représentation de notre modèle ne pourra-t-on pas retrouver dans le code ?

Que mettre dans un modèle ?

La littérature abonde sur les éléments qui peuvent constituer un modèle du domaine à la sauce DDD. On peut notamment citer :

• Les Aggregate Roots : des objets ayant une identité et représentant chacun une unité de cohérence (ex: un agriculteur, une commande)
• Les services du domaine, représentant des opérations agissant sur plusieurs objets (ex: une opération bancaire)
• Les repositories, abstraction du moyen de stockage des Aggregate Roots
• Les specifications, qui représentent des ensembles de critères et permettent d’exprimer des règles métier
• Les évènements du domaine, qui matérialisent des évènements importants survenus dans le domaine

Ces patterns peuvent aider à mieux structurer le code, à séparer les responsabilités et expliciter les concepts. Idéalement, ils sont connus par l’ensemble de l’équipe, y compris les profils non techniques : les échanges seront d’autant plus facilités que les concepts seront partagés.

Un exemple de modèle

Le schéma ci-après illustre notre vision du coeur du modèle du domaine de l’application de vente de légumes. On ne s’intéresse ici qu’aux éléments saillants du modèle. Pour une meilleur lisibilité, nous avons formalisé notre modèle en UML. On retrouve ainsi les Aggregate Roots Agriculteur, Consommateur et Legume.

Un bon test de recette du modèle produit est : quelqu’un qui n’est pas impliqué dans la construction du produit arrive-t-il a comprendre ce que fait l’application ?

Il faut également faire attention à ne pas « surdesigner ». Les principes KISS et YAGNI restent valables pour la modélisation du domaine. Il faut assumer que le modèle n’est qu’une représentation incomplète de la réalité. Il n’est pas nécessaire non plus de mettre dans son application tous les designs patterns du GoF .

Il faut également surveiller l’évolution dans le temps du modèle du domaine, et le refactorer lorsque c’est nécessaire.
En effet, on peut arriver progressivement à un effet plat de spaghettis, c’est-à-dire que les dépendances entre objets du modèle sont très nombreuses. Dans ce cas, il faut peut-être définir de nouveaux agrégats, afin de gagner en cohésion et de masquer les entités aggrégées au reste du modèle.
Si le modèle contient trop de classes pour que l’on puisse se représenter son fonctionnement, c’est qu’il adresse certainement trop de problématiques. Il faudra alors définir autant de Bounded Contexts qu’il y a de problématiques. C’est également un axe qui permet de scaler une équipe, en créant des sous-équipes dédies à chacun de ces nouveaux contextes.

Architecture et implémentation

L’architecture logicielle qui portera le domaine est celle proposé par Eric Evans:

Interface Utilisateur

Cette couche a pour responsabilité de :

• Présenter les informations observables du système à l’utilisateur
• Interpréter les actions de l’utilisateur pour interagir avec le système

Services applicatifs

Cette couche a pour responsabilité de coordonner les activités de l’application. Elle ne contient pas de logique métier et ne maintient aucun état des objets du domaine. Elle peut cependant maintenir un état de la session applicative. Elle porte la gestion des transactions et la sécurité. Sa responsabilité est également de récupérer les objets du domaine via le repository pour “injecter” la dynamique dans le domaine. Enfin, elle est également en charge de l’ajout ou la suppression d’objets dans le repository.

Pour illustrer un exemple de service applicatif de notre application, on a choisi le service d’achat de légumes :

1
2
3
4
5
6

public void acheterDesLegumesAUnAgriculteur(Integer consommateurId, Integer agriculteurId, Integer legumeId, Integer quantite){
   Consommateur consommateur = consommateurRepository.getById(consommateurId);
   Agriculteur agriculteur = agriculteurRepository.getById(agriculteurId);
   Legume legume = legumeRepository.getById(legumeId);
   consommateur.achete(quantite,legume,agriculteur);
}

Domaine

Cette couche comporte toutes les classes correspondant aux éléments du modèle du domaine.

Pour illustrer le code d’un Aggregate Root, on a choisi la méthode de mise en vente d’un légume :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Agriculteur {
   Integer id;
   Map  legumesALaVente ;
 
   public void metEnVente(Legume legume, Prix prix){
        if(!MiseEnVenteAutoriseeSpecification.isSatisfiedBy(this,legume,prix)){
		this.legumesALaVente.put(legume, prix);
		DomainEvents.notify(new AgriculteurAMisEnVenteLegumeEvenement(this.id,this.legume,this.prix));
	}else{
		throw new MiseEnVenteNonAutoriseeException(agriculteur,legume);
        }
  }
...
}

Infrastructure

Cette couche sert les autres couches, notamment pour :

L’anti-corruption consiste à éviter la pollution du domaine par un modèle externe, tel que celui d’une autre application du SI. Cette notion correspond à ce que nous nommons, chez OCTO, le pattern « Royaume-Emissaire ». Prenons l’exemple de l’Aggregate Root « Consommateur ». Je peux récupérer un consommateur particulier en interrogeant le ConsommateurRepository. Mais pour répondre à ma demande, le repository aura peut-être besoin de récupérer un objet externe (en provenance d’une autre application) via un appel Web Service. Pour cela, il s’appuiera sur un composant dédié de la couche d’infrastructure. Ensemble, le repository et la couche d’infrastructure fournissent un mécanisme d’anticorruption vis-à-vis de notre modèle : l’objectif est de ne pas introduire de dépendance forte de notre modèle vers un modèle externe, dont nous ne maîtrisons pas les évolutions et qui n’est probablement pas adapté à nos besoins…

Bref, l’important à retenir, c’est que tout élément introduisant une complexité non essentielle (non liée à notre problématique métier) doit être « emprisonné » dans une couche d’infrastructure / anti-corruption.

Finalement, cette architecture en couches n’est pas si éloignée de ce que l’on rencontre dans bon nombre d’applications. La différence fondamentale est que le domaine est un ensemble d’objets “intelligents” et que le code du domaine est suffisamment expressif pour que l’on comprenne ce que fait l’application.

DDD aide-t-il à faire de meilleures applications ?

DDD n’est pas le silver bullet qui garantit l’application parfaite. Si la démarche apporte des réponses pragmatiques sur le partage et la compréhension du produit construit, certaines limites subsistent.

On retiendra les points suivants :

Points positifs de l’architecture

• La modélisation du domaine est au plus proche de la problématique des utilisateurs, et on a réussi à construire un code très expressif dans lequel il est aisé d’identifier une règle, un comportement. La plasticité du système facilite les changements fréquents dont ont besoin les utilisateurs.
• Puisque la modélisation du domaine met l’accent sur l’identification des interactions dans le système, il devient plus naturel de mettre en oeuvre une interface utilisateur orientée tâches/activités
  
• Les échanges sont facilités entre profils fonctionnels et techniques sur les fonctionnalités offertes par l’application, et les règles (les comportements) qu’elle implémente
• Les développeurs bénéficient d’une meilleure compréhension du métier à la lecture du code du domaine : un nouveau développeur peut plus facilement appréhender le code et le fonctionnel de l’application
• La testabilité fonctionnelle est facilitée : les règles métier sont explicitées, concentrées dans une couche bien définie de l’application, et donc plus facilement testables par un outil de tests fonctionnels automatisés
• La robustesse vis-à-vis des changements dans le SI et de l’architecture technique est améliorée, grâce à la couche d’infrastructure / anti-corruption

Points négatifs de l’architecture

• La démarche encourage a faire de la programmation orienté objet, mais pour des contraintes techniques, limite l’encapsulation. Par exemple, pour la restitution des informations à l’utilisateur, il est nécessaire d’accéder aux données internes des objets. Dans le code, nous sommes donc contraints de rajouter des getters qui vont polluer l’objet et le modèle
• Le modèle du domaine est très adaptée pour interagir avec le système. En revanche, il l’est beaucoup moins pour la recherche ou la collecte de données agrégées. En effet, le modèle contient beaucoup de relations entre entités, ce qui peut nous obliger à effectuer un grand nombre de jointures en base pour remonter l’information qui nous intéresse. On risque alors de faire face à des problèmes de performances du système en lecture.

Take away !

Certains éléments de DDD aident sur des problématiques fondamentales de l’industrie logicielle :

• la cohérence dans la vision du domaine, et la levée d’ambiguïtés entre les acteurs de la construction de l’application.
• La réalisation d’application représentant un système complexe

Nous pensons que les pratiques suivantes peuvent réellement aider dans l’atteinte de ces objectifs :

• Isoler les problématiques adressées par l’application (ou les applications) en définissant des Bounded Contexts
• Pour chaque Bounded Context, se poser les questions : Quels objectifs ? Quelles contraintes ? Quelle architecture ? Quelle technologie ? (ex: peut-être certains contextes gagneront-ils à être modélisés et implémentés sous la forme d’objets « intelligents » ; pour d’autres, l’utilisation du pattern Transaction Script sera plus adapté, etc….)
  
• Partager les nouveaux termes de l’Ubiquitious Language en début d’itération, lors de la définition des nouvelles fonctionnalités
• Remettre en cause le modèle régulièrement, le faire évoluer au fil des itérations, en faisant collaborer développeurs et experts métier
• Faire apparaître l’Ubiquitious Language dans le modèle du domaine, dans le code
• Faire des ateliers en début d’itération pour faire émerger le meilleur design
• Faire apparaître l’intention dans le code : les noms de méthodes ne doivent pas mentir (pas de getAndSaveOrDeleteContextInDB !)
• Mettre en place une couche d’anti-corruption lorsqu’il est nécessaire d’interagir avec des systèmes externes
• Utiliser les notions d’Aggregate Roots, Repository, Specification… lorsqu’elles permettent d’expliciter des concepts

Le modèle du domaine permet d’exprimer clairement les règles de gestion et le comportement de nos applications. Néanmoins, la limite du modèle du domaine, tel qu’il a été présenté dans cet article, est atteinte. Celui-ci convient parfaitement pour le traitement et la persistence de l’information, ainsi que le contrôle de sa cohérence. En revanche, il ne semble pas adapté à la lecture d’informations à partir du système, pour laquelle la flexibilité et la performance de l’accès aux données peuvent être cruciales.

Dans un article à suivre, nous vous proposons de découvrir le pattern CQRS, et d’en extraire quelques bonnes idées afin d’améliorer notre architecture.

Suggestion d'articles :

1. 5 minutes pour : Monter en complexité, Approche TDD / Tests en PHP, PHP & Ajax
2. Un peu de design de code avec le framework GWT – Part I
3. Le Test Driven Development au secours de Javascript !

Récemment un papier d’étude de Google UK a été publié sur la performance des langages de programmation JAVA, Scala, C++ et Go (Loop Recognition in C++/Java/Go/Scala). Dans ce papier, les performances des langages sont comparées sur la base d’un algorithme de recherche de boucles dans un graphe (Algorithme de Tarjan).

Principalement basé sur la performance d’exécution d’instructions séquentielles (boucles), la gestion de la mémoire, le temps de compilation et le nombre de lignes de code écrites cette étude montre que pour arriver à des hautes performances en C++ les optimisations techniques (au niveau du langage) deviennent trop compliquées pour le résultat produit. Comme le dit Robert Hundt :

We find that in regards to performance, C++ wins out by
a large margin. However, it also required the most extensive
tuning efforts, many of which were done at a level of sophistication
that would not be available to the average programmer.

Cependant, cet article a été critiqué sur son use-case peu pertinent et sur la validité des résultats. Quand même, C++ est le ++ fort ! Bien qu’il ait été maladroit, ce cher Robert a soulevé un point très intéressant : la programmation haute performance n’est-elle réservée qu’à une élite de développeur C++ ? Le développeur moyen peut-il espérer développer des applications haute performance ?

Plusieurs critiques de cette étude sont apparues sur Internet. Les arguments contre ont été :

• L’exemple en JAVA pourrait être plus optimisé au niveau des collections : http://jeremymanson.blogspot.com/2011/06/scala-java-shootout.html
• C’est ridicule de comparer JAVA et C++ sur une application mono-threadée : (même site)
• L’exemple implémenté en Go n’est pas représentatif et aurait pu être optimisé pour être plus rapide (mailing-list Go)

Ces arguments sont valables mais le message que voulait faire passer Robert Hundt semble malgré tout cohérent. Explorons en détail ce sujet.

De quelle performance parle-t-on ?

Tout d’abord la performance d’un langage (au sens de l’étude Google) n’est pas une affaire si subjective. Il y a deux aspects principaux de performance : le CPU et la mémoire.

Essoufler son CPU

Pour le CPU, un langage performant est un langage qui permet d’exécuter des instructions en un nombre de cycles CPU faible. Ensuite il y a la possibilité de répartir son code sur les différents cœurs du CPU (parallélisme).

En ce qui concerne l’exécution d’instructions, les compilateurs JIT (Just In Time, compilation à la volée) de JAVA et .NET sont assez performants pour générer du byte-code optimisé. En C/C++ cela dépend énormément du compilateur et de son utilisation (flags de compilation). Il faut connaître son hardware pour compiler de manière optimale.

Le monde managé et les différents compilateurs C++ sont dans le même ordre de grandeur d’exécution d’instruction. Match nul ici entre JAVA/Scala (les langages managés de manière générale) et C/C++.

Le parallélisme via les threads POSIX semble idéal dans la théorie grâce à une meilleure gestion de la synchronisation (pthreads et semaphores). Donc C et C++ remportent la palme. En théorie seulement…

Là entre en jeu la complexité du design des applications multithreadées : il faut découper son code pour le rendre parallélisable sur la base d’un langage qui n’est pas fait pour (tous les langages objets/impératifs). Il faut également gérer la concurrence à la main (locks). De plus, la parallélisation peut drastiquement dégrader les performances d’une application : I/O en goulot d’étranglement, deadlocks, synchronisation des threads. Ceci est valable pour C/C++ mais également pour JAVA, C#… bref pour tous les langages objets supportant le multithreading.

Notre fameux développeur moyen se casse les dents ! Il peut être un très bon développeur, très intelligent mais il n’a pas les outils (langage) pour développer une application performante quand le multithreading entre en jeu. On peut même enlever le mot « moyen » !

Les langages managés et C++ se valent pour une application massivement séquentielle. Pour du multithreading, les problèmes sont similaires entre les langages managés objet et C++. L’écriture de traitement parallèle est simplifiée dans les langages fonctionnels par la nature du paradigme fonctionnel : closures, currying, lambda expressions.

Optimiser l’utilisation de la mémoire

Ensuite vient la gestion de la mémoire. Un langage performant est un langage permettant d’optimiser l’utilisation de celle-ci notamment éviter de saturer la mémoire, accéder rapidement à la donnée..

L’accès à la mémoire pourrait être plus rapide en C++ via l’utilisation directe des pointeurs mais je pense que c’est anecdotique. D’autant plus qu’en JAVA l’accès au tas (heap) est plus rapide qu’en C++. Enfin, l’overhead de défragmentation côté JAVA est significatif grâce à la défragmentation en continu par le garbage collector.

Le point différenciant est l’optimisation de l’espace mémoire : à la main en C/C++, via garbage collector en JAVA.
Le problème principal du GC (Garbage Collector) est l’étape de full-collect qui stoppe une application et la rend donc non-déterministe : j’ai multithréadé partout mais ce n’est pas plus rapide… Pire, ça freeze !
Ce point est très souvent reproché à JAVA (aux langages managés d’une manière générale) même si les évolutions des différents GC ont permis de rendre ce temps de full-collect plus court. On peut estimer que les full-collect (pauses) sont d’un ordre de grandeur inférieur à la seconde sur une JVM Sun classique (en tunant les paramètres de la « young generation » de la JVM).

Les JVM embarquées (appliances) ou optimisées (type Azul )  réduisent (ou même suppriment) le full-collect. On arrive à des ordres de grandeurs bien inférieurs à 100ms (on approche plutôt des 10ms).

En C/C++ la gestion de la mémoire se fait à la main. Malheureusement cela signifie également plus de chance d’introduire des fuites mémoires (l’erreur est humaine). Les smart pointers (auto_ptr ou bibliothèque Boost par exemple) permettent d’éviter ces fuites via les compteurs de référence mais leur utilisation peut être lourde : utilisation hasardeuse avec les conteneurs de la STL, conversion vers pointeurs classiques pour utiliser des frameworks tiers ne manipulant pas les smart pointers…

Les inconvénients de l’utilisation des pointeurs en C++ et les avancées en matière de gestion de la mémoire dans les langages managés (objet et fonctionnel) équilibrent le rapport de force.

La performance est-elle uniquement réservée aux applications C/C++ ?

De mon point de vue, je sursaute quand j’entends qu’on ne peut faire de la haute performance uniquement en C++. Premièrement, la complexité du C++ équilibre le rapport de performance avec les langages managés objets et fonctionnels comme nous avons pu le voir jusqu’à présent.

Les avancées dans les langages managés permettent de développer des applications performantes. Prenons tout simplement l’exemple de Twitter qui utilise un front-end JAVA : Netty (en remplacement d’une architecture basée sur RoR).

Ensuite, les goulots d’étranglement sont souvent ailleurs :

• Accès I/O : le goulot d’étranglement classique par la dépendance à l’unité de stockage physique (disque dur) ou même distant (web-services, appels RPC)  - 4 ms de latence uniquement pour trouver la donnée sur un HDD 7200 trs/min à ajouter au taux de transfert de données (environ 1000 Mbits/sec sur un HDD 7200 trs/min).
  
• Réseau (transport/déserialisation/queuing) : même avec une bonne connexion réseau, la sérialisation/désérialisation des paquets arrivant/sortant au niveau du switch engendre un overhead, tout comme le queuing des messages au niveau du switch – 11µs de sérialisation pour un paquet de 1500 bytes sur une connexion 1Gb (en UDP), 2,7ms de latence pour une queue de 1024 pkts 
  
• Architecture logicielle : l’empilement de stacks applicatives réduisent les performances – Latence très variable
• Système d’exploitation : l’ordonnancement des processus du noyau et la gestion des signaux d’interruption matériel peut nuire à la priorité d’exécution des threads d’une application (le noyau choisit ce qu’il exécute en priorité) – Latence très variable, dépend de la sollicitation du matériel pouvant aller de 10µs à plus de 10ms dans des cas de livelock (trafic réseau important sur un serveur par exemple)

Nous voyons que les ordres de grandeurs ci-dessus ne sont pas extrêmement éloignés du full-collect sur des runtimes optimisés (dans les 10ms).

Le CPU peut même être un goulot d’étranglement si le besoin de latence sur des traitements est inférieur à la milliseconde (cache miss/taille des caches, memory barrier, latence du bus interne, nombre limité de cores; les cartes FPGA (Field-Programmable Gate Array) ou ASIC (Application-Specific Integrated Circuit) et les GPU (Graphics Processing Unit) sont utilisés pour cela). Pour ces besoins de latence extrêmement faibles (ex : en arbitrage haute fréquence), quelque soit le langage les algorithmes ne peuvent tout simplement pas être exécutés sur un CPU compte tenu de toutes ces contraintes à gérer.

Certains langages fonctionnels permettent d’ailleurs de répartir des threads sur plusieurs cœurs (Haskell et Erlang notamment). De plus, le modèle de programmation par « acteurs » utilisé par ces deux langages fonctionnels assurent un traitement simplifié de la concurrence : immuabilité, mémoire non partagée. En effet, en Erlang et Haskell un acteur est exécuté dans un processus light (à ne pas confondre avec un processus OS; un processus Erlang , par exemple, est un thread du processus de l’application ayant un heap protégé) et non un thread applicatif; il a donc son propre espace mémoire; pas de risque qu’un autre thread de l’application écrive dans cet espace (c’est tout de même possible en Scala).

Alors, moi, développeur moyen, puis-je espérer développer du code performant ?

Au fond je suis d’accord avec ce brave Robert : l’effort d’optimisation est un paramètre essentiel pour définir la performance d’une application. La recherche d’optimisation peut être très compliquée pour gagner peu voire même dégrader les performances d’une application.

Ainsi sur des applications où la notion d’algorithme existe, quand bien même les threads POSIX sont maîtrisés il y a toujours la barrière de l’interprétation humaine. C’est au développeur de concevoir l’algorithme, de le rendre parallélisable et d’éviter tout problème de conception. Notre développeur moyen défini par Robert Hundt est en réalité un développeur commun, c’est-à-dire une personne ayant tout simplement sa propre interprétation d’une solution à un problème donné

La complexité de la parallélisation et de la gestion de la mémoire me font dire qu’il est peut être plus judicieux d’utiliser les bons outils : simples et productifs. En utilisant les bons outils il est donc possible de développer des applications performantes sans avoir besoin d’un niveau stratosphérique.

Finalement, que choisir : C++/JAVA/Scala ?

L’un des seuls cas où il est incontestable que C++ est le langage qu’il faut pour de la performance est pour tout ce qui est driver/middleware/OS; l’accès direct au matériel en quelque sorte. En effet, les applications s’appuient sur un OS qui utilise des drivers pour accéder au matériel. Pour éviter un overhead supplémentaire (matériel (code machine) > OS (C++) > application) et abstraire la complexité au niveau des applications, les drivers et fonctions systèmes d’un OS se doivent d’être au plus proche du matériel (i.e. sans l’overhead du runtime).

Au niveau applicatif, la tendance est différente. Un algorithme ne prend pas directement en compte l’accès au matériel. De ce fait la performance n’est pas directement fonction de l’accès au matériel.

Pour une application low-latency -exécution de traitements inférieurs à 10ms comprenant réseau, exécution d’instruction, récupération de données…- C/C++ est une solution pertinente. Délocaliser des traitements CPU sur des GPU et autres cartes FPGA/ASIC tant que possible est même nécessaire.

Pour une application massivement parallèle avec threads indépendants C++ est une bonne solution. Si les ressources sont difficiles à trouver, les langages managés objets (JAVA/C#) répondent également à ce besoin. Souvenons-nous de Twitter qui utilise un front-end JAVA !
Les compilateurs et runtimes actuels (notamment les optimisations de GC pour Java 7) permettent d’obtenir du code optimisé (au niveau du compilateur, sur les boucles par exemple) et de la gestion de la mémoire performante(défragmentation en continu). On gagne très peu en performance d’exécution d’instruction en C++ par rapport aux langages managés.

Pour une application nécessitant d’être massivement parallèle et de faire transiter des états, la performance devient affaire de design et les langages fonctionnels répondent à ce besoin. Rien que sur le développement de l’algorithme de Tarjan, voici la conclusion sur une version optimisée en Scala :

This version is only 270 lines of code, about 25% of the C++ version, and not only is it shorter, run-time also improved by about 3x.

Les langages fonctionnels permettent de surpasser les difficultés des langages objets. L’avancée de ces langages en termes de performance (et sa simplicité inhérente) en font des candidats plus que sérieux au développement haute performance. Un élément penche en cette faveur : l’arrivée prochaine de C++0x qui introduit des notions fonctionnelles au sein de C++ (inférence de type, lambda expression, et function objects -à savoir closures passées aux threads-). Même le C++ veut se simplifier !

Suggestion d'articles :

1. Introduction à la Programmation Orientée Acteurs
2. De retour du Adobe Développeurs Exchange RIA 2010
3. Vers une supervision IT de la performance métier du SI (2/2)

Users really respond to speed

La citation est de Marissa Meyer, VP expérience utilisateur à Google, en 2006.

Pas grand chose n’a changé depuis, si ce n’est qu’on a des chiffres plus précis, et un peu effrayants, sur l’importance de la performance dans les applications web : Quelques points de performance feront la différence entre une expérience réussie et une application perçue négativement par ses utilisateurs.

Ou plutôt si, ce qui a changé c’est que depuis 2006 on ne se contente plus de sites web, les applications web ont envahi les entreprises et leur SI. Il devient donc primordial de faire attention aux spécificités des applications web : On ne traite pas un navigateur comme un client lourd.

Les spécificités des clients légers

Sur un client lourd c’est essentiellement le code applicatif qui va être un problème et qu’on va se charger d’optimiser : pools d’accès à la base de données, les index, les caches applicatifs, optimisation du code, ou même configuration des différents services et des serveurs.

Sur une application web, plus de 90 % du temps est passé sur le réseau et dans le navigateur. Sur les 10 plus gros sites web français on tourne même plutôt autour de 95 %. Ce qui nous préoccupera c’est donc l’enchaînement des requêtes http et l’architecture de la page.

Agir sur l’applicatif sur le serveur c’est agir sur la petite barre verte de la première ligne de notre exemple, et uniquement celle-ci.

Cette première ligne représente une demie seconde sur les dix secondes et demie nécessaires à charger complètement notre écran web lors du premier accès.

Améliorer de juste 5 % le reste de notre écran sera plus efficace que de diviser par 4 ou 5 le temps de calcul sur le serveur.

Fort impact du JavaScript

Les applications web riches ont tendance à faire un usage excessif de JavaScript, et c’est encore plus vrai quand on tente de reproduire l’interface d’un client lourd habituel.

C’est souvent ce code JavaScript qui pose pourtant le problème de performance le plus visible. Dans notre exemple ce qui saute aux yeux c’est ce grand rectangle bleu en quatrième ligne. Cette quatrième ligne c’est le chargement de la bibliothèque jQuery, de ses modules, et des codes spécifiques à l’affichage de l’application.

Contrairement à ce qu’on pourrait penser, ce n’est pas l’exécution du code JavaScript qui est à optimiser, mais bien son téléchargement dans le navigateur. Tous les navigateurs parallélisent les téléchargements pour optimiser l’utilisation de la bande passante mais Microsoft Internet Explorer 6 et 7 ne savent pas le faire quand ils téléchargent du JavaScript.

Tout est alors mis en attente : non seulement les autres composants à télécharger mais aussi le rendu du reste de la page. C’est soit une page blanche soit la page précédente avec un sablier en guise de curseur que l’utilisateur aura comme seul retour. L’expérience est désastreuse en termes de ressenti utilisateur.

De la seconde 1,5 à la seconde 3,5, le navigateur ne fait rien d’autre que télécharger le code JavaScript. On voit pourtant que le navigateur ne fait pas grand chose : la courbe processeur (orange) et la courbe de bande passante (verte) sont loin d’être à leur maximum.

Si nous pouvions paralléliser le reste des activités du navigateur, nous pourrions gagner de une à deux secondes sur le chargement total de la page, soit 10 % à 20 % de performance.

Chargement asynchrone

Il existe plusieurs techniques pour faire sauter le comportement bloquant de JavaScript. Chacune a ses inconvénients et aucune ne couvre tous les cas d’utilisations.

Créer dynamiquement la balise <script src=’…’> avec le DOM

// à la place de <script src="/path/to/script.js"></script>

// on créé la balise <script> dynamiquement
// via le DOM et createElement
var s = document.createElement("script") ;
s.type = "text/JavaScript" ;
s.src = "/path/to/script.js" ;
s.async = false ;
// puis on l’insère dans la balise <head> en haut de document
var head = document.head || document.getElementsByTagName("head")[0] ;
head.appendChild(s) ;

Cette technique assure un chargement asynchrone sur tous les navigateurs mais les scripts s’exécuteront dans leur ordre d’arrivée et pas dans leur ordre d’appel sous Microsoft Internet Explorer, ce qui empêche de gérer des dépendances entre plusieurs scripts. Elle a toutefois le fort avantage de ne rien demander d’autre que ces quelques lignes.

C’est généralement cette technique qu’on utilise pour télécharger de manière asynchrone les scripts de publicité et les compteurs de visite.

Télécharger le script via une requête Ajax avant son insertion dans la page

// à la place de <script src="/path/to/script.js"></script>

// on initialise une requête Ajax
// pour télécharger le fichier javascript
var req ;
if (window.XMLHttpRequest) {
  req = new XMLHttpRequest();
} else if (window.ActiveXObject) {
  req = new ActiveXObject("Microsoft.XMLHTTP");
}
req.onreadystatechange = function() {
  if (req.readyState == 4 && req.status == 200) {
    // en cas de réussite on insère dynamiquement une balise <script>
    // avec le code javascript comme contenu
    var s = document.createElement("script") ;
    s.type = "text/JavaScript" ;
    s.appendChild(document.createTextNode(req.responseText) ;
    var head = document.head || document.getElementsByTagName("head")[0] ;
    head.appendChild(s) ;
  }
}
req.open("GET", "/path/to/script.js") ;
req.send(null) ;

Cette technique a l’avantage de vous dissocier l’exécution et le téléchargement, vous permettant de gérer vous-même les dépendances entre scripts, mais nécessite que la page HTML et le fichier JavaScript soient sur le même domaine. Le code de gestion des dépendances peut aussi être un peu long à concevoir.

Initialiser le cache navigateur avant insertion

// à la place de <script src="/path/to/script.js"></script>

// Une fois le fichier javascript téléchargé une fois (voir plus bas)
// il devrait se trouver dans le cache du navigateur
// et donc s’exécuter immédiatement quand on
// créé la balise <script> correspondante via DOM
var insertScript = function(url) {
  var s = document.createElement("script") ;
  s.type = "text/JavaScript" ;
  s.src = "/path/to/script.js" ;
  var head = document.head || document.getElementsByTagName("head")[0] ;
  head.appendChild(s) ;
}
// On fait télécharger le fichier en utilisant
// - soit un préchargement d’image (pour IE)
// - soit la balise <object> (pour les autres navigateurs)
// Le fichier sera donc téléchargé mais non exécuté
// La fonction insertScript est exécutée à la fin du téléchargement
var path = "/path/to/script.js" ;
if (navigator.appName.indexOf('Microsoft') === 0) {
  var o = new Image() ;
  o.onload = insertScript ;
  o.src = path ;
} else {
  var o = document.createElement("object") ;
  o.type = "text/cache" ;
  o.onload = insertScript ;
  o.data = "/path/to/script.js" ;
  o.width = 0 ;
  o.height = 0 ;
  document.body.appendChild(o) ;
}

Ici nous devons gérer différemment Opera et Microsoft Internet Explorer du reste des navigateurs. Si le navigateur ne met pas correctement en cache le fichier JavaScript, nous risquons aussi de générer deux requêtes HTTP, voire deux téléchargements, et dégrader très nettement les performances. En échange le téléchargement et l’exécution sont décorrélés et il n’y a pas de contrainte de domaine.

Plus complète mais plus complexe, c’est souvent cette technique qui est utilisée par les bibliothèques de code qui s’occupent de ces questions pour vous et vous mâchent le travail.

Tout ceci existe déjà

À nos exemples il faut ajouter la gestion des erreurs, des dépendances entre fichiers externes, ainsi les dépendances entre fichiers externes et scripts embarqués dans le HTML. Un tel code est complexe mais surtout il est fragile car il est facile de casser telle ou telle version d’un navigateur sans s’en rendre compte.

Heureusement d’autres l’ont fait pour nous. Il existe de nombreuses bibliothèques de code complètes qui proposent le chargement asynchrone des fichiers JavaScript. Les plus connues se nomment LABjs, Headjs, ControlJs et RequireJS.

Une fois payé le surcoût dû à la bibliothèque elle-même (1,5 à 2,2 Ko pour les trois premières), vous avez à votre disposition des méthodes pour charger des fichiers JavaScript de façon asynchrone sur l’ensemble des navigateurs en gérant les dépendances entre blocs de code et fichiers.

LABjs a un développement actif et son développeur principal met un point d’honneur à fouiller et vérifier tous les cas possible sur les différents navigateurs. C’est celle que nous vous recommandons si vous n’avez pas de besoin plus spécifiques.

Avec LABjs cela donne :

$LAB.script("jquery.js").wait()
  .script("jquery-moduleA.js")
  .script("jquery-moduleB.js").wait()
  .script("site.js")
  .wait( function() {
    doSomethingWithDocumentAndJquery() ;
  } ) ;

Les fichiers jquery.js, jquery-moduleA.js, jquery-moduleB.js et site.js seront tous les quatre téléchargés en parallèle. L’instruction wait() impose que tous les fichiers déjà en cours de chargement soient exécutés avant d’exécuter les fichiers suivants. Le fichier jquery.js sera donc toujours exécuté en premier et le fichier site.js sera toujours exécuté en dernier quand bien même le téléchargement serait fait dans un autre ordre (parce que jquery.js est plus volumineux donc plus long par exemple). La dernière instruction wait() permet d’introduire une dépendance pour un code directement embarqué dans la page HTML.

Quels résultats ?

Dans notre exemple, l’utilisation de LABjs impose des pages 2 Ko plus volumineuses mais permet d’exploiter deux files de téléchargement au lieu d’une seule pendant deux secondes.

Comme la bande passante est largement sous-utilisée lors d’une session de navigation, le surpoids de 2 Ko au total est quasiment invisible par rapport au gain d’une seconde sur le chargement de la page.

Le temps de travail est d’environ une journée pour bien faire les choses et convertir les fichiers externes et les quelques scripts directement embarqués dans la page à la syntaxe LAB.js. Pour diminuer le temps de chargement de la page d’une seconde, c’est un retour sur investissement quasiment imbattable.

Pour aller plus loin, il est aussi conseillé d’éviter de multiplier le nombre de fichiers JavaScript à télécharger. Au delà de deux, quatre au maximum, il est préférable de les regrouper entre eux. C’est d’autant plus vrai si votre application est accédée via des smartphones sur réseau 3G ou via des réseaux distants avec une forte latence.

Suggestion d'articles :

1. Le Test Driven Development au secours de Javascript !
2. Le futur de JavaScript encore incertain
3. La meilleure façon de rater son projet grâce à Maven2

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

• La personne propriétaire du portable l’éteint rapidement
• Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? J’en vois au moins trois :

• Qu’il existe un standard explicite ou implicite pour le groupe
• Que l’écart au standard soit détectable rapidement par tous les membres du groupe
• Qu’une prévention des futurs écarts soit possible sans confrontation supplémentaire

Y a t’il des activités de groupe — autres que les réunions — dans lesquelles un vaccin de ce type pourrait fonctionner ? Bien sûr ! Par exemple, certaines équipes de développement utilisent un lapin Nabaztag qui “écoute” en permanence les résultats du serveur de build continu. Ici le standard est que le code déposé par chacun sur le serveur doit passer tous les tests. Lorsque ce n’est pas le cas, le lapin remue les oreilles et dénonce immédiatement l’auteur de l’infraction. Cet évènement incite ledit auteur à réparer le build, et les autres développeurs à toujours mieux vérifier le passage des tests sur leur code avant de le déposer.

Il existe d’autres moyens que le test pour détecter les défauts d’un système en cours de développement. D’après Wikipedia, une analyse faite par Capers Jones sur 12000 projets de développement à montré que le taux de découverte des défauts latents par des inspections formelles se situe entre 60% et 65%. Pour les inspections informelles, le chiffre est inférieur à 50%. Pour les tests en général, le taux de découverte des défauts latents est d’à peu près 30%.

L’inspection formelle, également appelée “revue de code” constitue une mesure de prévention particulièrement puissante pour améliorer en continu la qualité de vos développements. C’est une amélioration générique, qui fonctionne donc également comme un “vaccin” :

• Il existe un standard (correction du code, règles de codage, de lisibilité, de modularité, d’architecture, de couverture par les tests etc).
• L’écart au standard (erreur de logique ou infraction au standard) est détecté rapidement par tous les membres de la revue (le code étant rétroprojeté).
• Après la revue les autres participants peuvent rechercher et corriger rapidement des écarts similaires sur leur code, sans confrontation supplémentaire.

A court terme, la revue permet aux participants — même les plus novices — d’apprendre de nouvelles choses (sans avoir à poser des questions embarrassantes). A moyen terme, son usage régulier réduit significativement le nombre de défauts du système. A long terme la revue de code contribue à créer une culture de la qualité logicielle dans votre entreprise.

Comme dans le cas des vrais vaccins, ce type d’amélioration générique ne va pas sans quelques inconvénients ni réticences. Lorsque vous mettrez en place une stratégie de revue de code, vous rencontrerez très certainement des objections:

- “Mobiliser chaque semaine tous les développeurs va coûter cher et mettre le projet très en retard !”
- “Ici, il n’y a pas de standard de qualité du code !”
- “Ici dès qu’on échange sur le code ou le design cela finit par des débats houleux !”
- “On a déjà essayé de faire des revues et c’était vécu comme du flicage !”

Ces obstacles peuvent être surmontés. Apprenez à mener des revues de code. Mesurez le coût de la non-qualité sur votre projet; essayez des revues de code régulières pour une période de trois mois, puis mesurez le à nouveau. Si votre équipe respecte déjà le standard “pas de sonnerie intempestive en réunion” qu’est-ce qui l’empêche de respecter des standards encore plus cruciaux pour votre entreprise ?

Suggestion d'articles :

1. USI 2011 est à la recherche de ses speakers !
2. OCTO recherche un(e) assistant(e) RH: activez vos réseaux!
3. Ma lecture de l’architecture de Percolator : un composant du moteur de recherche Google

Cela fait maintenant 3 mois que le projet Natal est devenu une réalité sous la forme d’un accessoire pour la console de jeu Xbox 360 : La Kinect.


Cette technologie de caméra 3D n’est pas nouvelle, mais elle était jusqu’ici réservée à un petit groupe de passionnés travaillant soit dans les laboratoires de recherche soit dans de rares entreprises innovant dans ce domaine. Depuis 3 mois tout ce petit monde est en effervescence et cette communauté d’utilisateurs a explosé ! En produisant sa caméra 3D en masse, et en l’équipant d’un port USB exploitable par le plus grand monde (Mac, Linux, Windows et même PS3), Microsoft a rendu accessible cette technologie jusqu’ici couteuse et confidentielle à tous. C’est ainsi qu’une équipe du MIT a remplacé un couteux matériel par un simple accessoire de 150$ disponible dans tous les magasins !

Voici les dernières nouvelles à propos de cette fameuse Kinect :

• Microsoft a passé la barre des 10 millions kinect vendues au début du mois (en 3 mois ½ donc). Pour rappel, la kinect est entrée dans le Guiness des records en janvier pour « l’appareil électronique de grande consommation qui s’est vendu le plus rapidement de l’histoire » (8 millions en 60 jours)
  Article sur guinnessworldrecords.com





• Pour suivre tous les hacks kinect : http://kinecthacks.net/
  Le dernier que j’ai testé : Un hack pour Minecraft codé en python : http://www.orderofevents.com/MineCraft/KinectInfo.htm
  




• Le SDK kinect ‘grand public’ de Microsoft devrait être disponible ce printemps. (gratuit, mais limité aux applications non commerciales). Pour le moment seuls les possesseurs du SDK Xbox 360 (>10.000€) peuvent développer 100% légalement des application Kinect.




• Le driver OpenKinect supporte maintenant le mode 1280×1024 des 2 caméras, mais la résolution 3D est toujours inchangée. La rumeur dit qu’une mise à jour du firmware de la Kinect va l’améliorer dans les semaines qui viennent, mais rien n’a été confirmé par Microsoft pour le moment.
  http://openkinect.org/wiki/Main_Page
  




• OpenNi (API Natural Interaction Open Source) dispose maintenant de wrapper C# qui fonctionnent très bien.
  http://www.openni.org
  

Il existe maintenant plusieurs frameworks Open Source très performants qui permettent en quelques jours de profiter de cette nouvelle forme d’interaction homme-machine. Plusieurs entreprises (dont Octo Technology) lancent actuellement des chantiers de R&D autour de la Kinect et des nouveaux usages qui en émergent.
Il faut donc s’attendre dand les mois qui viennent a voir fleurir un grand nombre de projets professionnels tirant partie de la Kinect (Assurance, Media, Retail…) avec probablement la même effervescence que les révolutions du tactile et du mobile de ces dernières années.

Suggestion d'articles :

1. Kinect, I mock you so much
2. RIA vs RDA en Java : quoi de neuf en 2008?
3. Kinect: un tour d’horizon tout naturellement

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 ?

Travaillant avec les technos Web, j’ai souvent été confronté à Javascript.
Java-iste dans l’âme, j’ai été un peu rebuté par ce langage interprété (non compilé), faiblement typé, basée sur la notion de prototype (donc sans classe !)… bref, trop souple pour être vraiment sérieux !

Si on ajoute à cela qu’il existe un moteur par version de navigateur (actuellement on a Chakra chez IE9, V8 pour Chrome, TraceMonkey chez Firefox3.5, SquirrelFish pour Safari ou encore Carakan pour Opera10…) ce sont les maux  de tête assurés !

La solution: le TDD !
Cette méthode de développement est une bonne façon d’avoir un retour rapide sur son code et ainsi, de compenser le côté « non-compilé » de Javascript.
De plus, les tests unitaires sont particulièrement importants lorsque le typage est dynamique (comme c’est le cas en Javascript, mais aussi en Ruby, Groovy, Python, etc.). Dans ces environnements, c’est le harnais de test produit par le TDD qui permettra au développeur d’avoir la confiance suffisante pour faire du refactoring.

Il existe de nombreux frameworks de tests unitaires Javascript. On retiendra en particulier QUnit (l’outil de tests officiel de JQuery), Jasmine (orienté BDD et successeur de JSunit, le pionnier, sorti en 2001) ou encore le YUI Test de Yahoo.
Dans cet article, je vous présenterai JsTestDriver.

J’ai choisi JsTestDriver pour plusieurs raisons:

• syntaxe xUnit.
• exécution des tests en parallèle sur plusieurs moteurs JS et agrégation des résultats.
• plugin Eclipse et IntelliJ (alors que la plupart des framework de test JS s’exécute sur le browser, ce qui, en mode TDD, oblige à switcher sans arrêt entre son IDE et son browser)
• côté industrialisation: il est possible de faire de l’intégration continue et d’obtenir des indicateurs de couverture de code.
• la communauté est active et la road-map intéressante.

Architecture

JsTestDriver s’exécute sous la forme d’un serveur (maître) auquel on attache des navigateurs (esclaves).

Le serveur reçoit les sources JS à tester et les déploie sur chacun des navigateurs (au passage, on évite les problèmes de cache associés aux ressources Javascript).

Les navigateurs exécutent les tests et renvoient le résultat au serveur JsTestDriver qui les compile.

Pratique: le plugin Eclipse intègre à la fois la partie serveur et la partie client.

Action !

Je vous propose un petit exemple en 5 étapes, sous Eclipse:

1. Configuration de l’environnement

Installer le plugin Eclipse JsTestDriver depuis http://js-test-driver.googlecode.com/svn/update/

Ce plugin rajoute une nouvelle vue à l’IDE. Pour l’afficher, il faut la sélectionner dans le menu Windows > Show View.

Dans Windows>Préférence>JsTestDriver, définir le port qui sera utilisé par le serveur ainsi que les différents browsers sur lesquels on souhaite tester.

2. Configuration du projet

Créer le fichier de config jsTestDriver.conf à la racine du projet:

	server: http://localhost:42442

	load:
	- src/main/js/*.js
	- src/test/js/*.js

Configurer le plugin pour le projet (dans le menu Run > Run configurations)

3. Ecriture d’un test unitaire

Dans src/test/js/cartTest.js.
Si vous êtes familiers avec JUnit, la syntaxe ne vous surprendra pas.

	CartTest = TestCase("CartTest");

	CartTest.prototype.testGetTotalWithOneBook = function() {
	    var cart = new katapotter.Cart();
	    var books = [{"title":"first book"}];
	    assertEquals(8, cart.getTotal(books));
	};

Evidemment, ce test ne passe pas !

4. Ecriture du code

Ecrire le code JS minimum permettant de faire passer le test au vert:
src/main/js/cart.js

	var katapotter = {};

	katapotter.Cart = function () {};
	katapotter.Cart.prototype.getTotal = function(books) {
	    return books.length * 8;
	};

5. Exécution du test

Démarrer le serveur (bouton accessible sur la vue JsTestDriver).

La barre passe au jaune, ce qui signifie « Serveur démarré, pas de browser associé ».
En cliquant sur les icônes des navigateurs à utiliser, un nouvel onglet est ouvert dans chacun d’eux (ils sont prêts à recevoir le code JS à tester) et la barre du plugin passe au vert.

un clic droit sur la classe de test permet de lancer le test.

La suite, ce sont les 5 étapes classiques du cycle TDD:

Côté industrialisation

Il existe un jstd-maven-plugin qui permet d’intégrer les tests JsTestDriver dans le processus de Build Maven.
Ce plugin peut

• lancer une instance de serveur au moment de l’exécution des tests, exécuter les tests dans un browser local puis arrêter le serveur
• ou utiliser un serveur JsTestDriver standalone

Le second cas est intéressant car il permet de tester sur de nombreux browsers (locaux ou remote).
Ainsi, pour attacher un browser à un serveur JsTestDriver standalone (en langage JsTestDriver, on parle de « capturer un browser esclave »), il suffit de faire pointer le browser vers l’URL du serveur JsTestDriver standalone.
Il devient donc possible de tester en parallèle sur IE6, IE7, IE8 sur Windows XP et Safari sur MacOS, par exemple !

Pour conclure

Le TDD permet d’obtenir un code robuste: il génère une importante suite composée de petits tests unitaires très centrés sur le code fonctionnel. Ce harnais de tests permet de contrebalancer la (trop) grande souplesse de Javascript et la diversité des moteurs JS.

JsTestDriver est une bonne option pour faire du TDD: il supporte bien le modèle de développement TDD,  sa syntaxe est simple, il est rapide et s’intègre agréablement à Eclipse.

Suggestion d'articles :

1. « Behavior Driven Development » grâce au pattern MVVM et GreenPepper
2. TDI ou Test Driven Infrastructure
3. La stratégie de test d’une architecture REST (2/3) – Test d’intégration