Un outil pour l’amélioration continue du standard

Désolé pour les gamers, mais non je ne vais pas vous parler du dernier Day of Defeat. Par DoD comprenez plutôt « Definition of Done », c’est à dire l’ensemble des critères à respecter pour considérer une tâche terminée. Par exemple, avant de soumettre son code, un développeur doit s’assurer de respecter le critère: « tests unitaires OK ».

En quoi un outil aussi « low-tech » et aussi simpliste qu’une check-list peut nous aider à l’ère de Google et de l’iPhone ? À une révolution dans le niveau de qualité fournie. Pour preuve emblématique, les initiatives récentes dans le milieu hospitalier. Cet extrait parle de la pose d’un cathéter (voie veineuse centrale).

« In 2001, though, a critical care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give a doctor checklist a try. [...] Doctor are supposed to (1) wash their hands with soap, (2) clean the patient’s skin with chlorhexidine antiseptic, (3) put sterile drap over the entire patient, (4) wear a mask, hat, steril gown, and gloves, and (5) put a steril dressing over the insertion site once the line is in. [...]

In the Keystone initiative’s first eighteen months, the hospitals saved an estimated $175 million in costs and more than fifteen hundred lives.« 

Et ce seulement dans le Michigan !

Avant même de parler des DoD, je rappelle que ceux-ci sont au service de l’amélioration continue du standard.

Qu’est ce qu’un ( bon ) standard ?

Je vous propose cette définition :
« Un standard est la meilleure pratique constatée à ce jour, énoncé explicitement, avec une finalité affichée, et dont on sait mesurer les écarts. »

Celui-ci au sens Lean se doit de respecter certaines grandes caractéristiques, il doit être :

• issu du terrain
• évolué sur la base de l’amélioration continue et de la résolution de problème
• simple
• supporté au maximum par du management visuel
• remis en cause sur la forme et sur le fond lorsqu’il n’est pas appliqué

Les DoD sont des éléments de ce standard, ils se doivent donc eux aussi de respecter ces caractéristiques. Appliquons donc celles-ci à nos DoD :

Issu du terrain

C’est sur le terrain que devra être appliqué le standard et c’est bien là que les problèmes sont rencontrés et encore là que le standard sera remis en cause et amélioré.

Voici un autre extrait tiré du même livre qui relate l’échec de la première version de cette check-list. Cette première version ayant été rédigée par des chirurgiens, non pas au bloc, mais lors de réunions en omettant la plupart des acteurs, infirmières, anesthésistes, …

« I gave the checklist to Dee, the circulating nurse, and asked her to run through the first section with us at the right time. Fifteen minutes later, we were about to put the patient under general anesthesia, and I had to say, Wait, what about the checklist?
« I already did it, » Dee said. She showed me the sheet. All the boxes were checked off.
No, no, no, I said. It’s supposed to be a verbal checklist, a team checklist.
« Where does it say that? » she asked. I looked again. She was right. It didn’t say that anywhere.
Just try it verbally anyway, I said.
Dee shrugged and started going through the list. But some of the checks were ambiguous. [...]. And after a few minutes of puzzling our way through the list, everyone was becoming exasperated. Even the patient started shifting around the table.
« Is everything okay? » she asked.
Oh yes, I told her. We ‘re only going through our checklist. Don’t worry.
But I was getting impatient, too.  The checklist was too long. It was unclear. And past a certain point, it was starting to feel like a distraction from person we had on the table.
By the end of the day, we had stopped using the checklist. Forget making this work around the table. It wasn’t even working in one operating room. »

Dans cet extrait il est clair que l’infirmière Dee aurait dû être consultée pour l’élaboration de la check-list. Les propositions d’améliorations doivent être émises par ceux qui rencontrent le problème et qui ont la meilleure vision de toutes les contraintes. Mais c’est loin d’être suffisant.

Un exemple issu de nos métiers : Jean développeur décide qu’à partir de maintenant le passage dans un formateur de code est obligatoire avant tout commit. C’est donc un nouveau DoD pour terminer une tâche de développement.

C’est sans doute une bonne initiative, mais elle est vouée à l’échec. Pourquoi ?

Évoluant sur la base de l’amélioration continue et de la résolution de problème

Le standard ne pourra être respecté que si il est partagé par toute l’équipe. Pour y arriver, le Lean nous met à disposition l’amélioration continue et la résolution de problème via, dans le cas des méthodes agiles, les rétrospectives.

Revenons au formateur de code de Jean. C’est une nouvelle contrainte pour les développeurs qui ne la comprennent pas forcément ( « c’est pour faire joli ? », « moi j’aime pas les accolades à droite ! « , etc…).

En effet, les autres membres n’éprouveront pas le besoin puisqu’ils n’y voient pas de solution à un problème donné.

Pourquoi ne pas se servir de la rétrospective ?

Si des actions d’amélioration ont été trouvées lors d’une rétrospective, il est très probable que des DoD puissent s’en déduire. De plus, c’est un moment privilégié où toute l’équipe est concentrée à l’amélioration du process.

Comment ce cas aurait pu être traité en rétro ?

Jean : « Je n’ai pas pu finir ma user story pour la recette, le merge était trop difficile avec la US de René. »

René : « Mais on ne travaillait pas sur les mêmes méthodes ? »

Jean : « J’ai eu pleins de conflits parce que tu mets toutes tes accolades à la ligne… »

René : « Mais c’est beaucoup plus lisible au niveau de l’indentation, non ? »

Jean : « C’est pas le standard le plus répandu ! »

René : « C’est toi le stand… »

La vache Octo : « Meuuuuuuuuuuuuuuuuuuuuuuh »

Le coach Octo : « Ca vous dit de traiter le point au calme et en rétrospective technique ? »

Dans cette retro spécifique aux développeurs le coach (ou team leader) va aider l’équipe à clore ce débat « passionnant » de l’indentation et convenir d’un formateur unique ainsi que de l’ajout au standard d’un DoD « FORMATEUR DE CODE APPLIQUÉ ».

On a maintenant deux fervents défenseurs de cette partie du standard, Jean qui appréhende un nouveau merge difficile et René qui aime ses accolades !

C’est donc bien le processus d’amélioration continue qui nourrit et fait évoluer le standard.

Simple

Le but final est de construire le meilleur standard applicable. Qui dit applicable dit simple. Cela implique que les DoD qui le composent soient le plus simples possibles.

Ainsi, la formalisation d’un DoD doit respecter quelques règles :

• univoque pour toute l’équipe :
  • « BUILD OK » peut ne pas être suffisant, c’est en local ? en environnement sandbox ?
  • « BUILD OK SUR MACHINE TOTO » lève le doute.
• en nombre limité :
  • Cette liste de DoD devra être appliquée et contrôlée pour chaque tâche Il faut donc limiter leur nombre (entre 1 et 10 critères pour passer une tâche d’un état à un autre)
• concis :
  • Le nombre de DoD pour l’ensemble du process peut devenir conséquent, il ne faut pas noyer l’information. À « Vérifier que le build d’intégration continue sur la machine TOTO n’a pas été mis en échec par notre commit », on préférera « BUILD OK SUR MACHINE LP32″ qui reste malgré tout parlant pour l’équipe.

Management visuel

Toujours dans le but de rendre notre standard applicable le plus simplement possible, nous allons cette fois ci nous appuyer sur le management visuel.

Rendre les DoD visuels les rendra plus accessibles et donc plus facilement utilisables.

Comme ils ne seront qu’une source d’informations parmi d’autres, il convient de les rendre clairs et normés. Par exemple Post-It vert clair /  marqueur noir / en majuscule.

Je vous laisse apprécier la différence :

En agile, les étapes du processus sont reflétées par les colonnes du scrumboard / kanban board. Les DoD doivent être contrôlés au changement d’état. Celui-ci se matérialise par le déplacement du Post-It de la colonne A vers la colonne B. Le meilleur endroit pour afficher les DoD est donc, à mon sens, au dessus (ou en dessous) de celles-ci.

Remis en cause sur la forme et sur le fond lorsqu’il est non appliqué

L’un des grands principes d’un standard, tel que le Lean le définit, est qu’il est vivant. La définition d’un standard donnée en début d’article parlait bien d’un instant T. Si à T+1 on observe que le standard n’a pas été appliqué, il faut le remettre en cause.

Si un critère du DoD n’est pas appliqué il est nécessaire de se poser les questions suivantes :

• le critère n’a pas été vérifié car il n’est plus pertinent ?
• le critère n’a pas été vérifié car il n’est pas assez « ergonomique » et clair dans le DoD ?
• le critère n’a pas été vérifié car la personne n’a pas regardé le DoD ?
• le développeur en charge de vérifier le critère a pensé à tort/à raison qu’il s’agissait d’un cas particulier non encore explicité dans le standard de l’équipe ?

Dans le cas où le critère a été mal compris il convient de le modifier. Par exemple si le critère « TEST FONCTIONNEL OK » ne suffit pas car le test peut passer en local mais échouer en environnement sandbox, le reformuler en « TEST FONCTIONNEL OK EN SANDBOX ».

Mais que faire quand on découvre que le DoD a été contourné à tort ?

Déboires

Dans la pratique il s’avère que, même avec des développeurs pleins de bonne volonté, l’application des DoD n’est pas toujours réalisée.

Et pourtant… C’est très frustrant de voir à une rétrospective une US KO, la vélocité chuter, alors que le remède était là, en majuscules et visible partout dans l’openspace :

Jean, en charge de la US à KO : « Ca marchait en local. »

L’équipe : …

Comment garantir le respect des DoD

Quelque chose de simple mais qui fonctionne : le binômage dans le déplacement des Post-It. Un développeur souhaitant faire avancer sa tâche doit avertir un autre développeur. Le but étant de responsabiliser deux personnes sur le respect du DoD mis en place pour ce changement d’état.

De manière générale, il faut à tout prix responsabiliser l’équipe au respect des DoD : « c’est votre standard, c’est-à-dire la meilleure façon que vous avez trouvé jusqu’ici pour réaliser l’objectif. Soit vous l’appliquez à la lettre si il est pertinent soit vous le remettez en cause en équipe».

Un autre outil qui peut déranger mais qui peut fonctionner dans certaines équipes, le « wall of shame ». Très simple… un Post-It géant avec le nom de chaque développeur. Le non respect d’un DoD entrainant un bâton à coté du nom du développeur concerné.

Il suffit d’en faire un jeu plus qu’un outil de « flicage » et c’est à mon avis le meilleur moyen de garantir le respect des DoD. L’équipe est responsable des DoD donc à l’équipe elle-même de fixer, dans un cadre pro, la conséquence du non respect du standard. Le but n’étant pas de sanctionner mais de faire prendre conscience des DoD.

Comment en faire un jeu ?

• 5 bâtons = un fond d’écran « Dora l’exploratrice » pendant 2 jours
• 10 bâtons = des croissants pour l’équipe
• …

Enfin, quelque chose que je n’ai pas encore pu essayer mais qui me semble prometteur, les cases à cocher. De la même manière que pour une check-list classique, il faudrait posséder sur les Post-It matérialisant les User-Stories une case à cocher par DoD. Ainsi un oubli de DoD est clairement visible de tous. Et tout le monde peut participer au respect du standard. Si vous avez des retours d’expériences la dessus, je suis preneur !

Conclusion

On peut maintenant définir un DoD :
« Elément visible de tous, concis et univoque définissant les conditions permettant de passer une tâche d’un état à un autre. Leur ensemble définissant le standard d’un processus ».

Avec l’utilisation des DoD, il devient possible de partager tous les standards d’une équipe sur l’outil que tout le monde utilise et voit en permanence, le scrumboard / kanban board.

Autrement dit, la meilleure façon d’apporter de la valeur au projet connue à ce jour est visible par tous et à tout instant.

L’un des facteurs clé pour la réussite de la mise en place d’une architecture orientée services, c’est de parvenir à identifier et mettre en œuvre des services à forte valeur ajoutée. Cet article synthétise, sous forme de questions pratiques, les principaux éléments et concepts à considérer pour réussir cette transformation du SI.

Cet article sera publié en 3 parties :
Partie 1 – Questions 1 et 2
Partie 2 – Questions 3 à 6
Partie 3 – Questions 6 à 10

1) Qu’est-ce qu’un service ?
Dans le domaine informatique, un service est tout programme exposant une ou plusieurs fonctionnalités à des tierces applications en environnement distribué

2) Comment émergent les services ?
Pour qu’on puisse parler de service, il faut un client et un fournisseur de service.

Dans un processus « Bottom up », un service émerge d’une démarche « Push » initiée par un fournisseur ou « Pull » initiée par un consommateur.

Dans un processus « Top-down », il est la résultante d’une étude plus globale et systémique du SI ou d’un bloc du SI.

Processus Bottom-Up

- Processus « push» – par le fournisseur (Le fournisseur fournit un service le plus « générique » possible)

C’est une démarche initiée par un fournisseur qui expose un service et le propose à ses partenaires. Le fournisseur essaie de proposer un service le plus générique possible qui répond au besoin de tous ses partenaires (exemple : les services exposés par ViaMichelin, Amazon, Google, etc.)

- Processus « Pull» – par le client (Le client demande un service)

Cette démarche est initiée par un consommateur qui exprime le besoin pour un ou plusieurs service(s) lui permettant d’échanger avec des tierces applications. Dans ce cas, le fournisseur essaie de répondre au besoin du consommateur sans forcément prendre en compte des perspectives de réutilisation du service. Cela s’explique par le fait que ce genre de demande se conjugue généralement avec des impératifs « Time To market » imposés par le client du service.

Processus Top-Down (Le service est identifé)

Certains services de ce processus émergent d’une démarche d’urbanisation ou de refonte du SI. Le besoin d’échanges est préalablement étudié et une définition des services est proposée.

Il est vrai que cette démarche garantit une cohérence globale de l’ensemble des services, néanmoins, sa mise en place s’avère un challenge inintelligible dont les bénéfices sont loin d’être acquis.

Quelle démarche favoriser?
Dans l’absolu, il n’y a pas de démarche à favoriser en particulier. Les 3 peuvent co-exister selon le contexte et l’offre de services existante. Néanmoins, en phase de conception et de mise en œuvre du service, il est primordial de prendre en considération les points suivants:
1) Favoriser une démarche itérative et collaborative entre clients(s) et fournisseurs de services.

Pourquoi? Parce qu’un service est un processus dont le résultat ne préexiste pas à la demande du client, cela signifie que le client va devoir s’engager vis-à-vis d’un fournisseur avant que la service ne soit réalisée, c’est-à-dire avant qu’il puisse évaluer la qualité de ce résultat, puisque celle-ci ne pourra être évaluée qu’une fois le service réalisé. Ce décalage temporel entre l’engagement de la transaction client/fournisseur et la réalisation du service crée une situation d’incertitude. D’où l’importance des méthodologies de mise en œuvre projet concernant ce type de besoin.
2) Penser un service donné en tant qu’offre de services, plutôt qu’un mono-service qui essaie de répondre à tous les besoins
3) Ne pas considérer l’étude d’urbanisation, s’il y en avait une, comme une cible en elle même, mais plutôt comme un fil conducteur pour la cible.

Suggestion d'articles :

1. Le tour des ESB en 10 questions
2. SOA par la pratique

Suite à un certain nombre de demandes de la part de nos clients, nous avons décidé d’ouvrir, à titre expérimental, nos parcours de formation OCTO à des participants extérieurs. C’est ainsi qu’OCTO Academy est né ! Concrètement, il s’agit d’ouvrir la cinquantaine de jours de formation que nous animons tout au long de l’année dans nos locaux.

Ces formations destinées à nos architectes sont la meilleure illustration de notre devise « Apprendre à jouer l’excellence ».

Elles sont animées par :

• les référents OCTO sur un domaine (architectes, experts, agilistes)
• des intervenants prestigieux comme David Anderson sur Kanban, ou Greg Young sur l’Applied DDD.

Elles couvrent 4 thématiques :

• Management de SI
• Architecture et technologies
• Méthodologies et conduite du changement
• Accompagnement de projets

Le site OCTO Academy (en béta) présente un petit catalogue formation avec un formulaire d’inscription.
Le catalogue va s’étoffer progressivement dans les mois à venir…

Suggestion d'articles :

1. Session ALT.NET avec Greg Young ce mercredi à OCTO
2. 4 Formations OCTO Technology – 2 et 3 juillet 2008
3. OCTO propose une formation ScrumMaster le 7 et 8 février 2008

A l’époque de la bulle Internet, les « brick-and-mortar » étaient destinés tout simplement à disparaître face à l’émergence des « pure-players » internet. Il était alors vital pour toute société « classique » souhaitant survivre de disposer d’un site web, si possible marchand. Un crack et 10 ans plus tard, nombre de pure players ont disparu, certains sont maintenant des géants, et les « brick-and-mortars » sont bien présents sur le marché.

Une nouvelle révolution est entamée avec la mobilité et l’ubiquité d’internet, portées en particulier par l’avènement de l’iPhone et autres smartphones. Internet s’est démocratisé et l’homme de la rue a appris à se servir des outils que ce medium met à portée de sa main. La possibilité de consulter le web à tout moment et en toute occasion vient modifier l’importance accordée à ce medium. Au delà d’offrir un simple site marchand, il s’agit maintenant de tirer partie des synergies possibles entre ces différents canaux et des utilisations faites d’Internet. Le ROPO (Research Online, Purchase Offline) devient par exemple un service nécessaire pour toutes les enseignes pour attirer les clients qui souhaitent s’assurer de la disponibilité de l’article avant de se déplacer ou qui ne veulent pas payer de frais de livraison.

Or du côté des anciens « brick-and-mortar », la mise en ligne d’un site marchand s’est rarement accompagnée d’une réflexion sur les relations entre le canal web et les magasins physiques. Des silos opérationnels et SI séparent souvent la gestion du site web et celle des magasins physiques. Pourtant, c’est le tissage de liens étroits entre le web et le monde physique qui doit permettre non seulement d’accompagner un client sur l’ensemble de son parcours, qu’il soit sur internet ou dans la rue (et donc à le suivre sur différents canaux), ou de lui offrir de nouveaux services tels que le ROPO, mais aussi de dégager de nouvelles synergies dans les organisations. Ainsi, pour commander en magasin un article en rupture de stock et le faire livrer, l’utilisation d’une plate-forme logistique spécialisée dans l’expédition, par exemple la plate-forme adossée au site marchand, se révèle plus efficace qu’une gestion des livraisons par chaque magasin.

Cette capacité à tirer des synergies entre les différents canaux de vente est un facteur de développement majeur. En effet, un distributeur US, Nordstrom, a fait le calcul qu’un client « multi-canal » dépense quatre fois plus qu’un client « mono-canal » et que le recours au stock magasin pour répondre aux ruptures de stock sur le site marchand a permis de doubler le taux de conversion des recherches en ventes (Source : article du International Herald Tribune).

Du point de vue du SI, cette capacité demande en général une révolution copernicienne pour passer d’une orientation purement « produits » historique à une orientation « clients » et mettre en place une gestion des données en temps réel dans un système centralisé. Elle implique donc, non seulement des projets d’organisation, mais également des refontes majeures dans la répartition des systèmes d’information et dans leur mise en oeuvre, avec une gestion délicate du déploiement de ces nouveaux outils. Elle exige également une attention particulière à l’arrivée de nouveaux canaux ou à de nouvelles utilisations des canaux existants. Pour ce faire, le système d’information doit bien sûr rester maîtrisé mais aussi ouvert et évolutif. Plus qu’adapté, on lui demande surtout d’être adaptable. Et sur ce dernier point, les « pure players » ont pris une longueur d’avance sur les « brick-and-mortar » aussi bien dans leurs méthodes de développement que dans la gestion de leur SI…

J’ai constaté à de nombreuses reprises que des problèmes de montée en charge revenaient souvent dès lors qu’on utilisait WCF. WCF, pour Windows Communication Foundation, est le protocole lié au framework .Net qui permet la communication distante. Cela est, la plupart du temps, du à une vision « magique » de WCF, qui est censé fonctionner tout seul, sans configuration. Sauf qu’en réalité, cela ne marche pas. Voici donc quelques clefs pour comprendre comment configurer et utiliser WCF.

Configuration

WCF possède plusieurs paramètres de configuration qui déterminent sa manière de gérer les requêtes. Une analogie qui permet de bien comprendre leur rôle est celle de Theme Hospital, un jeu datant d’un certain nombre d’années.

Parcours d’un malade

Dans cette métaphore, un appel WCF est comparé à un malade qui va se faire soigner. Tout d’abord il détermine comment se rendre à l’hôpital, s’il y a plusieurs moyens, puis se présente à l’accueil pour créer un dossier, va ensuite en salle d’attente en attendant que soient libre à la fois une salle de consultation et un médecin pour le recevoir. Il va alors à cette consultation, qui représente le traitement effectif de la demande. Les différents éléments de ce parcours sont guidés par des paramètres de configuration, que nous allons détailler.

MaxConcurrentInstance

Ce paramètre représente le nombre de moyens d’accès à votre hôpital (routes, hélicoptère, ambulance, téléportation,…). Selon la manière dont est configuré un autre paramètre, InstanceContextMode, la stratégie des patients sera différente.

• InstanceContextMode=Single : Tout le monde emprunte la même voie d’accès. Le paramètre MaxConcurrentInstance ne sert donc à rien
• InstanceContextMode=PerSession : Tous les patients venant du même endroit (i.e. toutes les requêtes venant du même client) empruntent la même voie d’accès. Il y a donc besoin d’autant de voie d’accès que de clients différents
• InstanceContextMode=PerCall : Chaque patient emprunte sa voie propre. Il faut donc prévoir un nombre important de voies d’accès, et donc une valeur élevée pour le paramètre MaxConcurrentInstance

MaxConcurrentSessions

Ce paramètre représente le nombre de salles de consultation, et donc le nombre de requêtes qu’il est possible de traiter en parallèle. Attention cependant, une salle de consultation sans médecin est inutile. Ce paramètre doit donc avoir une valeur proche de MaxConcurrentCalls, bien que légèrement inférieure, afin de ne pas avoir de salle vide. Il faut également noter que, les malades étant quelque peu élitistes, ils souhaitent une salle de consultation dédiée à eux et aux malades provenant du même endroit. Une session est donc créée par client se connectant.

MaxConcurrentCalls

Ce paramètre représente le nombre de médecins. Il y en faut un peu plus que de salles de consultation, parce qu’il arrive qu’un médecin fasse une pause. Techniquement, cela signifie qu’une fois la session créée, il faut libérer du temps processeur pour traiter l’appel, et que cela se base sur le nombre de threads allouées par le ThreadPool (sur lequel nous allons revenir). Il faut donc prévoir les temps de switch et de concurrence entre threads qui peuvent conduire à la « pause » prise par les médecins.

MaxConnections

Ce paramètre représente la taille de la salle d’attente. Cela est quelque peu biaisé dans la mesure où sont comptabilisés aussi bien les malades en attente que ceux en consultation. Ainsi, l’augmentation de ce paramètre fournira une plus grande possibilité de mise en tampon des requêtes.

ListenBacklog

Ce paramètre représente le nombre de sièges devant l’accueil. Les patients ne sont pas encore enregistrés auprès de l’hôpital et attendent qu’une charmante secrétaire veuille bien s’occuper d’eux. De la même manière que dans le monde réel, ce paramètre doit être maintenu assez bas. Le patient n’est en effet pas encore dans le système et perdra vite patience. Cela correspond à une connexion TCP en état Half-open et se traduit par un timeout assez court au niveau du système. Augmenter ce paramètre conduit donc simplement à délayer la remontée d’erreur au client, et à changer la nature de l’erreur qui passe de « il n’y a plus de place » à « j’ai attendu trop longtemps », ce qui complique le débogage.

Préconisations

Bien qu’il soit impossible de donner des valeurs idéales pour ces paramètres, puisqu’elles dépendent bien évidemment du contexte applicatif, il est possible de donner des relations entre ces paramètres :

• MaxConcurrentInstance doit être dimensionné en fonction de la stratégie définie par le paramètre InstanceContextMode et du nombre de clients.
• MaxConcurrentSessions doit être dimensionné en fonction du nombre de clients.
• MaxConcurrentCalls doit être légèrement supérieur à MaxConcurrentSessions.
• MaxConnections doit être supérieur aux deux précédents et dimensionné en fonction des timeout positionnés. Il faut en effet éviter que les malades en salle d’attente perdent patience, là encore dans l’optique de remonter au plus vite les erreurs.
• ListenBacklog doit être bas.

À part pour ce dernier, il est à noter que sur dimensionner les paramètres n’a que très peu d’influence sur les  performances. En effet, il s’agit de maximums, le système ne créant les ressources qu’à la demande. Il faut cependant tenir compte des pics de communication, afin d’éviter que la création et le maintien des ressources liées à WCF ne prenne tout le temps de processeur disponible.

Autres éléments ThreadPool

Tout est configuré, les paramètres sont bons, et pourtant, cela ne fonctionne toujours pas ? Normal, vous n’avez pas assez de threads dans votre ThreadPool. Avec là encore, l’effet baguette magique, qui pousse à croire que le ThreadPool va fonctionner pour vous dans sa configuration par défaut. Pour comprendre l’influence du ThreadPool, il faut savoir que d’une part, chaque appel WCF est traité dans un thread d’I/O asynchrone, gérée par le ThreadPool, et d’autre part, que le ThreadPool à un fonctionnement particulier.

En effet, l’objectif ultime du ThreadPool, sa raison d’être, est d’amener ou de ramener le nombre de worker threads et de thread d’I/O asynchrones à son idéal, qui est par défaut égal au nombre de cœurs logiques de la machine. Par ailleurs, il est cadencé à 500ms, et obéit à l’algorithme suivant :

Sur un appel :

Si nombre_de_threads < idéal
Alors créer un thread
Sinon mettre en attente

Sur déclenchement du timer interne (500ms)

Si il y a au moins un demande en attente
Alors créer un thread
Sinon supprimer un thread

Pour illustrer son fonctionnement, prenons un cas d’école. Imaginons que chacune de vos threads peut traiter 10 appels par 500 ms, que vous recevez 50 appels par 500 ms et que vous avez 2 cœurs. On obtient le graphe suivant :

Figure 1 Évolution des traitements WCF dans le temps

On s’aperçoit que le fonctionnement du ThreadPool le fait osciller autour de l’idéal. Dans la pratique, le ThreadPool étant optimisé, on finit par arriver à l’idéal de traitement (dans notre cas, 5 threads), mais on s’aperçoit que cela peut prendre du temps et que, pendant cette période de ‘calibration’, les requêtes entrantes peuvent patienter un temps très long, au point même parfois de déclencher des timeouts.

La solution consiste à régler manuellement l’idéal du ThreadPool. Cela se fait par l’appel à la méthode System.Threading.ThreadPool.SetMinThreads, en dimensionnant les paramètres de l’appel en fonction de la capacité de traitement de vos services WCF. Attention cependant à ne pas trop relever ce paramètre, puisque cela conduit à la création de nombreux threads, ce qui peut être dommageable (temps de switch + taille mémoire de chaque thread)

Dans la pratique, ce nombre est largement supérieur au nombre de cœurs logiques de la machine. Il ne faut donc pas hésiter à monter jusqu’à une cinquantaine de threads par cœurs, sans que cela n’impacte réellement les performances, tout en gardant en tête que le dimensionnement idéal est « au plus juste » et se découvre par essais successifs.

Conclusion

Il n’y a pas de baguette magique ! Même si WCF est plus simple à utiliser que ses ainés, il demeure cependant qu’il faut savoir le configurer correctement afin d’en tirer le plein potentiel.

Dans les projets agile, on utilise souvent des dashboards ou des tableaux Kanban. On les retrouve, soit sous forme de Post-its au murs :

soit sous forme électronique :

image de kanban electronique est une image de greenhopper prise sur http://www.atlassian.com/software/greenhopper/

La forme électronique présente plusieurs avantages :
- pas de post-its qui se décollent
- possibilité d’interagir entre équipes distantes
- possibilité de suivre automatiquement le temps de réalisation d’une tache
- etc.

Mais on leur reproche de perdre au moins deux gros intérêts :
1) Être visible à tout moment par l’équipe
2) Pouvoir interagir directement avec les Post-Its

Un simple vidéo-projecteur peut suffire a résoudre le premier point.

Le deuxième semble plus compliqué, la vidéo suivante vous montre le contraire.

Suggestion d'articles :

1. Comment concevoir vos applications iPhone ? Avec le post-it OCTO !

Aujourd’hui les grands groupes industriels font face à une multiplication des solutions de gestion dans leurs filiales avec un constat, plus on s’éloigne du centre et plus les solutions se font hétérogènes et exotiques. Ces différentes solutions vont de SAP, leader du marché pour lequel les processus sont presque gravés dans le code jusqu’à un simple ensemble d’outils de bureautique : un tableur pour suivre les commandes et un éditeur de texte pour émettre des factures. Entre ces deux extrêmes il existe quelques acteurs majeurs : Oracle EBS, SAGE, NAVISION… et de nombreux éditeurs locaux.

Comment rationaliser un écosystème aussi diversifié ?

Au niveau du groupe les gains d’une solution uniforme sur l’ensemble des entités sont évidents :

• reporting simplifié
• économies réalisée sur la formation aux outils
• capitalisation des équipes IT
• rationalisation du SI

D’un autre coté, les filiales en devenir veulent être capables d’évoluer rapidement sans être contraintes par un outil mais en ayant la possibilité d’informatiser un processus qui émerge de leur organisation. Et cela passe donc par des choix différents de ce qui est proposé par la maison mère. Il sera souvent préféré une solution ERP intermédiaire au core model pour de nombreuses raisons dont :

• des coûts moindres
• une maîtrise du périmètre des processus implémentés
• la rapidité de mise en œuvre

Ces points se résument à un choix entre simplicité et complexité qui est proposé par le centre. Or le coeur est complexe parce qu’il est riche et cette richesse est intrinsèquement lourde, ce qui est un atout au centre mais deviendra un frein dans les jeunes filiales.

Certains éditeurs essaient de pallier à cette problématique en proposant des solutions distinctes pour des BU de tailles différentes, c’est le cas par exemple avec SAP Business One, mais ce modèle ne fonctionne pas. Les synergies entre les solutions sont détruites au fur et à mesure que l’on essaie d’adresser les besoins de l’une ou l’autre des cibles.

Alors comment faire ? Et surtout, comment bien faire ?

A l’approche top-down qui définit une cible au centre, nous allons préférer l’approche bottom-up. Construire une application qui réponde aux besoins des petites entités, puis augmenter le périmètre avec des entités plus importantes jusqu’à rejoindre le core model… peut-être.
Nous allons donc nous inspirer de la méthodologie agile, itérative, pour construire le coeur de cet ERP de façon incrémentale.

La base doit être acceptable par de toutes petites structures et solide afin de pouvoir grandir. Pour cela les critères de choix vont être les suivants :

• des coûts réduits
• une technologie éprouvée
• un périmètre fonctionnel qui couvre 80% des besoins

C’est donc naturellement que nous allons chercher des candidats du coté des projets open source matures : OpenERP, Compiere, Neogia, ERP5…. Souples et robustes, ils sont modulaires ce qui est l’empreinte d’un développement communautaire au niveau de l’architecture logicielle. Cette modularité est la garantie d’une évolutivité future. De plus, les projets open source nous apportent des technologies ouvertes et standardisées facilitant l’intégration avec d’autres systèmes.

Et c’est un point important, l’approche d’OCTO n’est pas de créer un second core model décorélé du centre, en concurrence avec le centre. Il s’agit de réaliser un système qui soit potentiellement une marche vers le système central, une marche qui rapproche du centre. Ainsi cette solution apporte de la valeur à la filiale ET au centre.

Le choix d’une approche incrémentale pour la rationalisation du SI est différenciante dans le sens où il s’agit d’accompagner la création de valeur depuis le début d’une activité. Le système qui va être implémenté doit aider l’organisation cible sur un cycle court en terme de réalisation de « business » et sur un cycle long en l’aidant à s’intégrer dans le core model du centre. Et ceci de façon progressive. La méthode agile va nous permettre de faire évoluer en douceur l’ERP retenu vers les limites fixées : couvrir X% des processus, supporter une charge maximum de X utilisateurs…

Bien que les notions d’ERP et d’agilité puissent paraître antinomiques, il s’avère possible de profiter du meilleur des deux mondes dans ces projets souvent réputés pour être très lourds à cadrer, à réaliser et à mettre en oeuvre.

Dans un prochain article, nous verrons comment aborder ce type de projet d’un point de vue organisationnel et fonctionnel. Les projets ERP forment intrinsèquement un ensemble de fonctionnalités fortement imbriquées et nous verrons comment, avec une approche agile / incrémentale, nous allons pouvoir segmenter ces projets dans des livraisons fréquentes et fonctionnelles apportant de la valeur aux métiers régulièrement.

Suggestion d'articles :

1. Agilité et SOA ?

La communauté « DevOps » nous invite à repenser la frontière classique de nos organisation, séparant d’un côté les études, i.e. ceux qui écrivent le code (le “Build”) et de l’autre côté la production, i.e. ceux qui déploient et exploitent ces applications (le “Run”).

2 groupes se retrouvent dans le mouvement DevOps et apportent un peu de fraicheur dans ces réflexions aussi anciennes que les DSIs :

les agilistes qui ont levé la « contrainte » côté développement, et sont maintenant capable de « livrer » beaucoup plus souvent du logiciel valorisé par le client…mais regrettent que « la prod ne suive pas »

des experts ou des managers de la « prod » des grands du web (Amazon, Facebook, LinkedIn…) partageant leurs retours d’expérience sur leur façon d’envisager cette frontière

Au delà des fractures organisationnelles, les préoccupations des études et de la production sont bien distinctes et respectivement louables.
Les études recherchent plus de réactivité (sous la pression du métier et du marché notamment) : il faut aller vite, ajouter de nouvelles fonctionnalités, réadapter les directions, refactorer, upgrader les frameworks, déployer rapidement pour tester…La nature même du code (“Soft”) est celle ci : maléable, adaptable.
A l’inverse, la production a besoin de stabilité et de standardisation. Stabilité car il est souvent difficile d’anticiper quels impacts auront telles modifications de l’infrastructure : un disque local qui devient un disque réseau mais impacte les temps de réponses, ou bien un changement de code qui impacte fortement la consommation CPU et par la même le “capacity planning”. Standardisation enfin car la production veut s’assurer que certaines règles (sécurité réseaux, configuration des fichiers de logs…) sont uniformément respectées.

Très souvent, la frontière entre ces deux populations se concrétise par la phase de déploiement où les études “livrent” ou parfois se « débarrassent » de leur code et où ce dernier va suivre un long chemin au travers des couloirs de Mise En Production. Et ce point précis cristallise la divergence d’objectifs. Les études voudraient la main sur une partie de l’infrastructure, pouvoir déployer rapidement, à demande et simplement sur les environnements (a minima ceux de “tests” au sens large). A l’inverse, la production a le souci des environnements, de l’utilisation des ressources, de la consommation de bande passante et de la fiabilité en général. Ce que veut la production : des fichiers de log standards, une configuration du serveur HTTP identique…

Sauf que ces deux groupes ont un objectif commun : faire fonctionner le système…et finalement le déploiement n’est pas le plus important dans cette problématique même si c’est certainement une des activités les plus consommatrices en ressource : la moitié du temps de la production est ainsi consommée par le déploiement ou des problèmes liés au déploiement.

C’est donc certainement le premier levier d’amélioration mais non l’unique. Damon Edwards et John Allspaw nous rappellent :

• qu’il s’agit de partager des métriques et d’être capable de transformer des variables techniques (augmentation des temps de réponse…) en variables business (baisse du CA généré…). Et qu’une des clés du succès d’interprétation de ces métriques est la collaboration entre les études (la compréhension du code) et la production (la compréhension des serveurs, du réseau…)
• “qu’agilifier” le processus de développement c’est bien mais que le véritable enjeu c’est l’agilité « business » qui passe par la réduction du délai global “from concept to cash”, de l’idée à la mise au production. Cela passera entre autres par des déploiements plus “agiles”, sur l’exemple de Flickr, qui réalise 10 déploiements quotidiens

Atteindre cet objectif ne se fera pas sans douleur et trouve des leviers d’amélioration dans 4 axes :

• de l’outillage qui permettra d’industrialiser l’infrastructure et de rassurer la production sur la façon dont cette infrastructure est utilisée par les études. C’est un des gènes du cloud : le self service. Les offres de cloud public sont matures sur le sujet mais certaines offres (VMWare par exemple) visent à reproduire ces modes de fonctionnement en interne. Mais sans forcément aller à ces niveaux de maturité, on peut imaginer l’utilisation d’outils type Puppet, Chef ou CFEngine…
• de l’architecture qui peut permettre de décorréler les cycles de déploiements, de déployer du code sans pour autant déployer la fonctionnalité…
• de l’organisationnel qui vous amènera peut-être à vous aussi implémenter les patterns d’Amazon “two pizzas team” et “you build it, you run it”
• du processus qui permettra de fluidifier tous ces échanges. Comment déployer plus souvent ? Comment limiter ses risques en déployant progressivement ? Comment appliquer les leçons de « flux » tirées de Kanban à la production ? Comment repenser les mécanismes de communication et de coordination à l’oeuvre sur la frontière études/production ?

En définitive ces 4 axes nous permettront d’atteindre les objectifs supérieurs de DevOps : améliorer la collaboration, la confiance et l’alignement d’objectifs entre les études et la production.

Développer en Groovy et Grails simplifie grandement le développement d’une application Web. Passée l’étape du prototype, les simplifications apportées par Grails ne vous épargneront pas de devoir vous plonger dans les frameworks sous-jacents afin de résoudre des problématiques plus complexes.

Qu’en est-il des transactions en Grails ? Sur un sujet aussi sensible, il est important de comprendre quel est ce comportement par défaut choisi par Grails.

La documentation de Grails est un peu sommaire, ne traitant vraiment que de où et comment les déclarer mais pas vraiment de comment les utiliser. Les premiers points ne seront pas ré-expliqués ici, vous pouvez vous référer à la documentation.

L’article complet, en anglais uniquement, aborde les points suivants :

• le modèle transactionnel de Grails, par défaut dans la couche de Services
• les risques et pièges de ce modèle, à savoir un traitement métier en dehors d’une transaction ou réparti sur plusieurs transactions
• les bonnes pratiques pour gérer et déclarer les transactions en Grails
• les interactions parfois étranges entre les transactions et la session Hibernate
• une alternative au modèle transactionnel de Grails pour simplifier la gestion des transactions et supprimer les risques identifiés auparavant. L’article inclus le code nécessaire à cette modification et explique les impacts d’une telle modification.

Vous pouvez retrouver le code et les tests mentionnés dans cet article dans notre repo SVN .

Suggestion d'articles :

1. GRAILS et FitNesse : au service de l’innovation métier
2. Grails Maven Plugin 0.3
3. Architecture Dynamique basée sur la solution Grails

Dernier article de la série consacrée aux services web AMAZON, celui-ci se veut avant tout un retour d’expérience.

Alors AWS ?

Pour rappel dans l’étude menée, nous devions étudier l’offre d’AMAZON sur trois axes : facilité de mise en œuvre, coûts et montée en charge.

Facilité de mise en œuvre

L’application que nous avons déployée repose sur un certain nombre de services AWS. Sans rentrer dans les détails, l’application de test assurait les fonctions suivantes :

• Stockage : Transfert de fichiers médias depuis le poste client
• Serveur Web : Navigation au sein d’une bibliothèque de fichiers médias
• Conversion : Conversion de fichiers médias dans différents bitrates
• Streaming : Lecture de fichiers médias

Pour répondre à ces besoins, nous avons utilisé les services AMAZON suivants :

• Elastic Compute Cloud (EC2) pour la conversion et la logique de navigation.
  • CloudWatch qui permet de monitorer une application
  • Auto Scaling pour permettre l’allocation dynamique de nouvelles machines virtuelles
  • Simple Queue Service (SQS) : le service de messagerie middleware de type MOM pour la communication entre machines virtuelles
  • Simple Storage service (S3) : stockage de type clé/valeur pour l’accès en streaming aux fichiers média
  • Relational Database Service (RDS) : stockage de type SGBDR basé sur MySQL pour la gestion des utilisateurs et des arborescences de fichiers

De nombreux services AWS (CloudFront, SimpleDB, VirtualPrivateCloud …) n’ont pas été mis en oeuvre. Néanmoins, nous pouvons tirer les conclusions suivantes pour ceux utilisés :

• La compréhension des différents concepts et possibilités des AWS nécessitent un ticket d’entrée non négligeable. Maitriser la terminologie, les cas d’utilisations, les possibilités de chaque service … demande du temps. Ce point est à moduler en fonction du background technique plus ou moins important de l’architecte. Les néophytes en infrastructure y seront d’autant plus sensibles.
• Les ressources liées aux AWS sont nombreuses, qu’il s’agisse de la documentation officielle, claire et complète, des différents projets open source ou encore de la communauté d’utilisateurs. Vous n’êtes pas seul et las AWS ne sont pas des boites noires.
• Enfin, cela peut paraitre évident mais ce ne l’est pas toujours : les services AWS fonctionnent tels qu’annoncés. Nous n’avons pas eu de surprise, que ce soit des bugs ou des comportements étranges.

Coûts

Le calcul des coûts par anticipation est quelque chose d’assez complexe, c’est sans doute pourquoi AMAZON propose d’utiliser un outil pour vous aider. La tarification se fait par service mais pour la plupart des services, la bande passante utilisée intervient dans le calcul du prix. Qui plus est, ces données qui traversent les firewalls des data centers d’AMAZON ont des tarifs dégressifs en fonction de leur volumes !

Attardons nous sur cette notion de données entrantes et sortantes des data centers.

• Il n’y a pas de surcoût lors de l’interaction de services AWS au sein d’une même région. Par exemple, l’accès à un bucket S3 situé en Irlande depuis une instance EC2 exécutant elle aussi en Irlande, ne génèrera pas de frais liés au transfert de données.
• Entre des instances EC2 situées dans différentes zones de disponibilités mais dans la même région, le transfert de données sera facturé à un prix dit Regional Data Transfer.
• Le transfert de données entre des services AWS basés dans différentes régions est facturé au prix dit Internet Data Transfer pour chaque coté du transfert (entrée et sortie).

Eléments ayant un impact sur le prix

Sans rentrer dans la tarification détaillée des AWS, voici quelques indications

• La région d’utilisation a un impact sur la plupart des coûts des services.
• Pour les services associées à des instances (EC2, RDS), chaque heure débutée est intégralement facturée, que l’instance soit sollicitée ou non.
• Pour les prix des instances EC2, il est important de signaler qu’une distinction est faîte entre les OS Linux et Windows. La différence de prix peut selon la configuration s’élever jusqu’à 40 % de plus pour une instance Windows. Ensuite, comme indiqué lors du premier article, le  configuration matérielle bas de gamme est 25 fois moins chère que la plus chère (de 0.10$/heure contre 2.88$/heure). Enfin, AMAZON propose diverses offres pour réduire le coût horaire :
  • Reserved Instances – l’utilisateur réserve une instance pour une ou trois années (230$ pour un an ou 350$ pour trois ans dans le cas d’une instance d’entrée de gamme), et bénéficie ainsi de prix horaires réduits (environ 50% de moins).
  • Spot instances – en fonction de la charge du data center, AMAZON établit toutes les 30 minutes un Spot price. Dans ce système d’enchères, l’utilisateur définit un prix maximum, une région, une configuration matérielle et un nombre d’instances. Si le Spot price correspond à l’offre faite par l’utilisateur, celui-ci se voit attribuer les instances demandées.

• CloudWatch ajoute environ 0.015$/heure/instance
• Le coût d’une instance RDS va de 0.12$/heure à 3.10$/heure en fonction de la configuration matérielle. L’espace de stockage est facturé 0.10 $/Go/mois et l’espace supplémentaire pour les backups vaut 0.15 $/Go/mois. 0.10$ donne droit à 1 million de requête SQL. L’activation de la réplication entre zones de disponibilités double les prix précédents sauf pour le stokcage des backups et la facturation par requêtes
• S3 de 0.15$ à 0.055$/Go/mois en fonction du volume de stockage. La facturation par requête est découpée en deux catégories : les requêtes PUT, COPY, LIST facturées 0.01$ pour 1000  et les autres requêtes dont GET facturées 0.01$ pour 10 000
• Les coûts de transfert des données sont communs aux différents AWS :
  • Regional Data Transfer : 0.01$/Go/mois pour le trafic entrant et sortant
  • Internet Data Transfer gratuit jusqu’au 1 novembre 2010, les données entrantes seront facturées 0.10$ /Go/mois. Pour les données sortantes, le premier Go par mois est gratuit, ensuite il vous en coutera 0.15$/Go/mois pour les 10 premiers To où un tarif dégressif s’applique jusqu’à atteindre 0.08$/Go/mois si vous utilisez plus de 150 To/mois

Cette complexité tarifaire impose d’avoir une grande connaissance de l’application qui va être déployée. Cela peut ne pas poser de trop gros problèmes dans le cas d’une application existante, déjà en exécution au sein d’un SI interne puisque l’obtention de métrique pourra se faire par une instrumentation sommaire si elle n’est pas déjà faite. En revanche, dans le cas d’une conception « from scratch » cela peut être moins aisé. En outre, on notera que la tarification peut impacter les choix d’architecture : comment grouper les services au sein d’une même région pour les limiter les coûts tout en ayant un déploiement sur plusieurs sites ? Quelle granularité pour les messages SQS sachant que la facturation est faite par requête ? …

Pour conclure cette partie, comme souligné dans l’article suivant, il est clair que comparée à une solution d’hébergement classique, une offre d’IaaS comme celle d’AMAZON n’est pas avantageuse si l’on souhaite exécuter des instances en permanence. La vraie force de l’IaaS, c’est l’élasticité, le dimensionnement automatique pour suivre la montée en charge.

Montée en charge

Ce point était l’un des plus important pour notre étude. Le service AutoScaling fourni par AMAZON fonctionne correctement : lorsque les critères sont atteints la taille d’un groupe de machines.

Néanmoins, il est important de souligner que la période selon laquelle un groupe d’instances EC2 est dimensionné, doit être déterminée avec attention, au risque de lancer de multiples instances et donc de voir les coûts s’envoler. Supposons qu’un site web ait une courbe d’utilisation qui associée à certains paramètres d’AutoScaling (typiquement la période de dimensionnement d’une heure) produise le diagramme de vie des instances EC2 suivant :

Diagramme de vie des instances

Ainsi, nous aurons consommé : 12 heures pour l’instance 1, 6 heures pour l’instance 2, 4 heures pour l’instance 3 et 2 heures pour les instances 4, 5 et 6. Soit un total de 28 heures machines.

Supposons maintenant que l’échelle de temps du graphique précédent ne soit pas l’heure, mais la minute. Nous avons alors 6 heures machines à payer – car chaque heure consommée est pleinement facturée – pour seulement 12 minutes de fonctionnement. Notons au passage que 4 instances auraient suffi. Cet exemple s’applique sur quelques minutes et quelques machines, imaginons maintenant que cela concerne des dizaines de machines pendant une année…

Dans une première approche, on souhaite disposer d’un système très réactif et donc d’une période de dimensionnement très courte -  de l’ordre de quelques minutes. Or ce choix peut s’avérer ruineux.

Donc

Tout d’abord, et c’est positif, AMAZON WS existe depuis un certain temps et fonctionne bien : aucun plantage ou message d’erreur, une documentation claire et une communauté importante font qu’il est assez agréable de travailler sur l’infrastructure AMAZON. Par ailleurs la portabilité est là : envie de rapatrier l ‘application chez vous ? C’est faisable.

Par ailleurs, le coté ‘infra’ plus que ‘appli’ peut avoir son importance dans le choix du fournisseur car contrairement à GOOGLE qui annonce : « ne vous inquiétez pas, nous gérons votre appli », AMAZON donne les outils pour gérer et maitriser son soft : nous savons où sont les machines, les données, nous avons la possibilité de rester maître de notre soft. Le revers de la médaille est la quantité de facteurs à gérer.

Le premier de ces facteurs est la réactivité de l’élasticité. Cette élasticité est la raison d’être du cloud computing IaaS, sinon autant aller chez un hébergeur. Voulez-vous dimensionner votre infrastructure toutes les 10 minutes, toutes les heures ou bien tous les jours ? La réponse à cette question passe par une maîtrise avancée de l’application à déployer.

Par ailleurs, et c’est aussi vrai pour Microsoft et GOOGLE, les différents éléments à prendre en compte pour une estimation budgétaire et plus spécifiquement les volumes de données entrants et sortants des data centers AMAZON, nécessitent une maitrise de la volumétrie de  son application. L’idéal étant une application existante qu’il ne reste plus qu’à outiller. En outre, l’aspect financier (volumétrie, nombre de requêtes …) peut impacter l’architecture de l’application.

AMAZON est la solution si il s’agit de faire une externalisation d’infra privée vers le Cloud – normal puisqu’il n’y a presque rien à faire ! Pour du développement from scratch, AMAZON se prête mieux à du web-service, du batch ou du site web statique là ou on peut supposer que GOOGLE et MICROSOFT sont meilleurs pour des applis web, mais attention dans ce cas aux problèmes de portabilité. Rien ne vous empêche de déployer une archive WAR sur un TOMCAT au sein d’une instance EC2 mais le niveau d’abstraction offert par les solutions GOOGLE et MICROSOFT permet de faciliter grandement le déploiement, vous avez beaucoup moins de questions à vous poser. Par ailleurs, il est tout à fait possible d’intégrer AMAZON avec une autre solution.

Pour terminer, il faut garder à l’esprit que les choses évoluent très vite dans le monde du Cloud Computing. Ainsi, GOOGLE supporte maintenant le SQL pour les App Engine Business alors que le principal point négatif de GAE était son système de Base de Données non SQL.

De même l’offre AMAZON a encore évolué entre la fin du projet présenté ici (mars 2010) et la rédaction du présent document (Juin 2010) : le service de load balancing gère les sessions http (sticky-sessions) tandis que cloud front supporte le protocole HTTPS

Suggestion d'articles :

1. Déploiement d’une application sur l’infrastructure AMAZON (2/3)
2. Déploiement d’une application sur l’infrastructure AMAZON (1/3)
3. Panorama des différentes offres de cloud computing : Amazon Web Services

Le Green Challenge était un concours, ouvert lancé dans le cadre de l’Université du SI 2010.
Il avait pour objectif de faire émerger des patterns de développement permettant d’améliorer la sobriété des logiciels, ou “Green Patterns”. Il a mobilisé 15 équipes, soit une cinquantaine de développeurs, pendant 2 mois. Les gagnants

Le concours s’est terminé début juillet et les gagnants ont été désignés lors d’une session USI 2010 dédiée au challenge (voir vidéo).

Le jury du Green Challenge était composé de :

• Frédéric Bordage, expert du Green IT ( animateur de greenit.fr)
• Lionel Laské, directeur de l’innovation chez C2S (Groupe Bouygues)
• Guillaume Plouin, en charge du projet chez OCTO Technology

Il a désigné 3 équipes lauréates :

• Julien  LAMANDE / Paul ELISE
• Gabriel LANDAIS / Julien ADAM
• Mickael Robert / Maxime RAMEAU / Florent DAVID

Ces équipes ont réussi à faire baisser la consommation en Watts de l’application de 20% côté serveur (Google App Engine), et de 80% côté navigateur (mesure par l’AddOn GreenFox).

Les graphiques suivants présentent les économies en Watts qu’ils ont réussi faire au travers de leur application. Leurs résultats sont comparés à ceux de l’application de référence livrée au début du challenge. Il y a un facteur 100 entre les unités de mesures de GreenFox et celle d’AppEngine. Le gain maximum était donc obtenu en travaillant sur la partie client de l’application.

Les Green Patterns

Les Green Patterns issues du Challenge sont présentées en détail dans cette page. Voici une synthèse rapide :

• Réaliser le maximum de traitements côté serveur quitte à réduire l’ergonomie à l’essentiel
• Profiler l’application pour identifier les traitements fortement consommateur de CPU
• Optimiser ces traitements pour limiter le nombre d’opérations réalisées ou remplacer ces traitements par des librairies plus efficaces
• Pré-générer les affichages sur le serveur et éviter le code interprété (JavaScript ou JSP)

What’s next ?

Nous allons publier GreenFox, l’AddOn Firefox développé pour mesurer les consommations CPU, dans l’écosystème Mozilla.

Nous aimerions diffuser les Green Patterns.
Votre aide est la bienvenue pour relayer l’information et pointer vers cette page.
Et si vous connaissez un site communautaire pertinent pour les publier, nous sommes preneurs…

Suggestion d'articles :

1. Participez au Green Challenge !
2. Retour sur le BarCamp Java du Mardi 30 Septembre
3. Retour d’expérience BPMN

L’édition USI Paris 2010, qui a eu lieu au Pavillon d’Armenonville les 1er et 2 juillet derniers, est certes terminée….

Mais les premiers Webcasts sont enfin disponibles !

Participants USI et lecteurs du blog OCTO vous pouvez maintenant revivre les sessions et les keynotes USI en allant sur le site de l’événement : www.universite-du-si.com

Suggestion d'articles :

1. Revivez la keynote de Michel Serres à USI 2008
2. Découvrez l’Agenda des conférences USI Paris 2010
3. USI 2009 : toutes les sessions disponibles dans le coffret DVD

Afin de tester nos développements iPhone nous utilisons largement les frameworks Google-Toolbox-for-Mac et OCMock (cf Tests unitaires et tests d’interface sur iPhone : État des lieux)
Après la mise à jour du SDK4 et le passage à Xcode 3.2.3 nous avons eu une désagréable surprise : nos frameworks de tests ne compilaient plus et jusqu’à aujourd’hui on trouve très peu d’information sur la façon de régler ce problème.
Voici comment nous nous y sommes pris :

L’erreur de build rencontrée est la suivante :

Undefined symbols:
"_OBJC_CLASS_$_OCMockObject", referenced from:
objc-class-ref-to-OCMockObject in WebServiceTest.o
ld: symbol(s) not found

Jusqu’à maintenant nous ajoutions la bibliothèque OCMock.framework à la phase de build « Link Binary With Libraries ». Il semble que l’on ne peut plus utiliser la version précompilée du Framework disponible dans la section téléchargement du site d’OCMock.

Pour faire fonctionner OCMock avec Xcode 3.2.3 vous devez :

• Effacer ocmock.framework, ainsi que la phase « copy files » du build et toutes les références aux header de OCMock dans les « search path » de votre target.
• Faire un check out de la dernière version sur le repository svn de OCMock : http://svn.mulle-kybernetik.com/OCMock/trunk
• Faire un build de la target OCMockPhoneSim
• Copier le fichier libOCMock.a et le répertoire Headers dans votre projet
• Ajouter libOCMock.a aux framework de votre projet et ajouter un lien vers le répertoire Headers dans les « search path » de votre target de test

Vous buildez à nouveau et… rien ne se passe.

Apres OCMock c’est maintenant le script de Google-Toolbox-for-Mac qui reste bloqué indéfiniment sur cette erreur :

SBSetAccelerometerClientEventsEnabled failed: (ipc/
send) invalid destination port

Là encore la solution est de récupérer les sources de GTM sur le trunk du repository, puis de remplacer tous les fichiers nécessaires aux tests iPhone comme indiqué dans le guide d’installation :

http://code.google.com/p/google-toolbox-for-mac/wiki/iPhoneUnitTesting

Maintenant vous pouvez enfin relancer vos tests !

Suggestion d'articles :

1. Tests unitaires et tests d’interface sur iPhone : État des lieux

Les grands acteurs de l’Internet font souvent le “pari de la confiance” en proposant des API ouvertes, accessibles depuis le Web. Ces APIs permettent à d’autres acteurs, entreprises ou développeurs indépendants, d’innover en les exploitant, et d’inventer de nouveaux modèles économiques.

On peut citer en exemple les plateformes suivantes : Google Maps API, Facebook Graph API, SalesForce AppExchange, Twitter API, etc. Et plus près de nous, il existe des écosystèmes issus d’acteurs français : Mappy API, Netvibes UWA, Nabaztag API, etc.

Cette démarche permet la constitution d’un écosystème fécond, tant pour l’entreprise qui met à disposition les APIs, que pour celles qui les exploitent. Cette mise à disposition permet en particulier de :

• Créer des revenus directs, en les facturant. Exemple : Google Maps devient payant pour plus de 1M de transactions /an.
• Étendre une communauté, et donc recruter des utilisateurs. Exemple : grâce aux applications dérivées de sa plateforme, Twitter a atteint 200M d’utilisateurs et fait figure de grand du Web.
• Faire émerger de nouveaux usages pour sa plateforme et donc faire évoluer son modèle de revenu. Exemple : En 2009, Apple a constaté que les développeurs d’applications souhaitaient vendre non seulement des applications, mais aussi des contenus pour leurs applications. Le modèle de l’AppStore a donc évolué pour intégrer cette possibilité.

Les 3 modèles d’écosystème

Marc Andreessen (ancien fondateur de Netscape) distingue 3 types de plateformes ouvertes (voir ce billet) :

• Niveau 1   »Access API » : ces plateformes permettent l’appel à un traitement métier sans fourniture d’interface homme/machine. Exemples : recherche de livres chez Amazon, geocoding chez Mappy.

• Niveau  2   »Plug-In API » : Ces plateformes permettent d’intégrer une application à l’interface du fournisseur. Exemple : les applications Facebook, les Widgets Netvibes.
• Niveau  3   »Runtime Environment » : Ces plateformes fournissent non seulement une API, une interface, mais aussi un environnement d’exécution. Exemple : les applications AppExchange ou l’iPhone.

Il est clair que l’investissement du fournisseur de l’API va croissant du niveau 1 au 3. Il est donc fréquent de commencer au niveau 1, avant d’envisager les niveaux supérieurs.

L’outillage destiné aux développeurs

Le succès d’un écosystème ouvert est fortement dépendant de l’enthousiasme des développeurs. Pour les conquérir, il est crucial de leur fournir un langage facile à prendre en main et, si possible, des outils de productivité.
Côté langage, il existe un large consensus autour des APIs REST/JavaScript, simples à prendre en main, et adaptées à des développeurs connaissant mal les langages objets. Exemples : API Google, Yahoo, Mappy, etc. Proposer un langage simple est particulièrement recommandé aux nouveaux entrants qui n’ont pas le pouvoir de persuasion d’Apple (qui a réussi à convaincre des milliers de développeurs de se former à ObjectiveC…).

Pour ce qui concerne l’outillage, on peut distinguer 3 niveaux d’offres :

• Niveau 1 “zéro outillage” : les développeurs écrivent leur code dans l’environnement  de leur choix, puis font appel à la plateforme pour le tester. Exemple : Google Maps API.
• Niveau 2 “IDE” : on fournit un environnement de développement, souvent sous la forme de PlugIn Eclipse, pour donner un peu de productivité aux développeurs : coloration syntaxique, autocomplétion, bouton de publication, etc. Exemple : Flash Builder.
• Niveau 3 “Emulateur” : en plus de l’environnement de développement, on fournit un émulateur aux développeurs. Exemples : Google App Engine, iPhone.

Là encore, le niveau 3 représente un investissement beaucoup plus conséquent que le 1 ou le 2.

Le lancement de la communauté

La publication d’une documentation claire, simple à prendre en main, et d’exemples de code réutilisables est incontournable pour satisfaire les développeurs. L’animation de la communauté passe aussi par la mise en oeuvre de forums de discussions et autres outils participatifs (par exemple, ZenDesk).
Il peut être intéressant de se raccrocher à une communauté existante plutôt que d’en créer une à partir de rien. Par exemple, Android a recruté dans les communautés Java.
Enfin, il est classique d’organiser un concours avec des prix à la clef, pour initier le mouvement communautaire. Voir par exemple, l’Android Developer Challenge.

Un dernier point est essentiel : le modèle d’accès aux APIs. Certaines plateformes nécessitent une inscription préalable à leur usage (c’était le cas pour Google Maps jusqu’à mai 2010). D’autres plateformes vont même jusqu’à valider les applications développées (c’est le cas de la très polémique validation par Apple des applications iPhone).

Je pense qu’imposer le minimum de contraintes aux développeurs est un signe très positif, à même de créer un climat de confiance, et d’élargir la communauté. La modération à postériori me parait être la meilleure pratique.

Comment démarrer ?

Il est relativement simple de démarrer avec une plateforme / un outillage de niveau 1. Par exemple, la Ville de Rennes a récemment lancé une expérimentation en ouvrant des API sur les données de ses transports publics.
On pourra ensuite monter en puissance de manière itérative vers une plateforme de niveau 2/3 et un outillage plus avancé.

Je vous propose quelques pistes par secteurs d’activité. Ces pistes sont largement issues de mes envies en tant qu’utilisateur :

• Banque : ouvrir la liste des opérations de chaque client en les sécurisant via le protocole OAuth
• Opérateurs télécoms et fournisseurs d’énergie : ouvrir les encours de consommation de chaque client en les sécurisant via OAuth
• Médias & culture : ouvrir les programmes de télévision/radio/musées/salles de cinéma
• Industriels : ouvrir les catalogues produits
• Administration : ouvrir les données publiques à la manière de data.gov

Alors, quand pensez-vous lancer votre écosystème ouvert ?

Depuis les 5 dernières années, on assiste à une intensification de l’usage des Nouvelles Technologies de l’Information et de la Communication (NTIC) dans le monde professionnel : téléphonie mobile, courrier électronique, plateformes collaboratives, partage documentaire en ligne, solutions de messageries instantanées, Accès internet mobile, voix sur IP, etc. Tout cela a été possible grâce à la généralisation et la banalisation de la connexion internet et à la standardisation et la modernisation des réseaux filaires et sans fil (wifi, Bluetooth, connexion internet 3G, etc.).

Conscientes de l’importance de ces technologies et outils, la plupart des entreprises se sont pressées à les adopter, chacune à son rythme, et ses besoins, offrant aux collaborateurs de nouveaux canaux de communication et d’échanges. L’arrivée de solutions mobiles et de systèmes d’exploitation à interfaces ergonomiques (iPhone, Ipad, Android, Windows Mobile, etc.) dote les technologies de l’information et de la communication d’un bel avenir.

Par ailleurs, les NTIC constituent un facteur d’évolution des rapports sociaux, des emplois et des métiers. Elles accompagnent une série de transformations concernant la stratégie de l’entreprise, l’organisation du travail, les formes de management, la concertation et la négociation.

Cet article porte sur le positionnement des NTIC, ses apports et ses impacts sur l’entreprise et sur la vie quotidienne des collaborateurs et l’environnement de travail. Il donne à nos décideurs (DSI, R&D, stratégie, marketing, etc) une première grille de lecture leur permettant de viser la bonne politique NTIC à adopter en adéquation avec l’histoire et la culture de l’entreprise et un aperçu des challenges à relever aujourd’hui et demain.

NTIC et l’ « Entreprise » Opportunités 1) Augmenter la réactivité de l’entreprise

Les outils de communication permettent l’accès à l’information à tout moment, à tout endroit. La multiplication des canaux de communication (téléphone, connexion internet mobile, messagerie) à la portée des différents collaborateurs, dote l’entreprise d’une capacité de réactivité non négligeable face aux besoins de plus en plus oppressants du marché et des clients. Cela permet à l’entreprise de répondre à des opportunités et des demandes, de conclure des contrats en un temps optimal grâce à l’accessibilité des collaborateurs à l’information et aux données d’aide à la décision (disponibilité des ressources, niveaux stocks, seuils de rentabilité, etc.) leur permettant de prendre les bonnes orientations.

2) Communication peu onéreuse mais porteuse

Plusieurs solutions ont vu le jour permettant à n’importe qui de communiquer et échanger plus facilement ses idées. En plus du site internet institutionnel, de plus en plus d’entreprises proposent des outils communautaires rapprochant collaborateurs et internautes.

Les objectifs sont multiples :

• Apporter une attention particulière aux clients en leur permettant d’échanger sur leur projets et problèmes tout en partageant leurs expériences.
• Communiquer sur les nouveaux produits, offres, événements, etc.
• Guider, renseigner le client/consommateur pour faire son choix
• Partager la connaissance avec les internautes tout en recueillant leurs retours, commentaires, critiques.
• Afficher la maîtrise d’un tel ou tel sujet ou domaine permettant à l’entreprise de gagner plus facilement des parts de marché.

Cela dit, ce canal de communication permet aussi de tester des concepts, comme le Customer Driven Design ou le Crowd Sourcing privilégiant l’ouverture de l’entreprise vers l’extérieur via des pratiques bottom-up qu’internet va continuer à favoriser. Dans ce registre, vous pouvez apprécier par exemple l’initiative innovante d’Asus concernant ses produits du futur wepc, qui a mis à disposition des utilisateurs un site internet très novateur leurs permettant d’exprimer leurs imaginations et leurs besoins pour les futurs produits.

3) Formalisation du savoir faire

Les outils collaboratifs et de gestion des connaissances (wiki, blog, etc.) permettent de formaliser le savoir-faire, son partage et sa transmission. Un énorme de gain de temps et d’efficacité permettant d’augmenter la réactivité et la rentabilité de l’entreprise.

Risques

Mais ces opportunités définies précédemment, comme les usages évoqués en première partie, font ressortir des inquiétudes et des risques variés.

1) Changements incessants et évolutifs du cœur de métier de l’entreprise

Il y a quelques années, l’information au sens large était moins présente sur internet. En même temps l’accès à cette information était moins généralisé. Aujourd’hui, avec la généralisation de la connexion internet et la multiplication des sites d’échange d’expérience, d’idée, de solutions techniques, on assiste à l’explosion des sources d’information et la facilité à y accéder. Énormément d’entreprises voient leurs métiers changer ou se transformer au fil du temps se sentant de plus en plus oppressées à s’adapter pour survivre. Quelques exemples de domaines les plus marquants : L’édition papier, la distribution, le conseil au sens large, etc.

La R&D, l’innovation, l’expérience, la veille concurrentielle deviennent les maîtres mots pour survivre

2) Exposition à la concurrence

Avec l’explosion des blogs et le partage du contenu avec les internautes, la veille concurrentielle n’a jamais été aussi facile. Toute différentiation sur un domaine donné peut être facilement copiée, ce qui nécessite de l’entreprise des efforts financiers lourds et une différentiation de l’offre produits/services plus marquée afin de garder une longueur d’avance sur les concurrents.

3) Exposition au pillage

Un risque qui peut nous paraître improbable mais reste tout de même important à mentionner concerne la confidentialité et la sécurité des données de l’entreprise. Les différents canaux (web, terminaux mobiles dont on dispose) multiplient les risques de pillage et le piratage des données. Il serait important par exemple de définir différentes politiques de sécurité selon la criticité de la donnée pour l’entreprise.

4) Risque de baisse de la productivité

Même si ses outils augmentent la réactivité de l’entreprise, leur multiplication excessive risque d’engendrer à l’échelle de l’entreprise une baisse de son rendement : rédaction excessive de courriers et de messages électroniques, alimentation de divers outils de l’entreprise (blog, wiki, outils de reporting, etc.), navigation prolongée sur internet, etc. Des campagnes de sensibilisation et de communication ne pourraient-elles pas être suffisantes pour limiter ce risque sans franchir la frontière de la répression et la restriction à l’usage?

5) Risque de bouleversement des relations hiérarchiques

La génération d’indicateurs de performance et de rentabilité en temps réel, accessibles peu importe le lieu et l’heure risque de rythmer la relation entre managers et collaborateurs vers le meilleur comme vers le pire.

NTIC et l’ « Individu » Opportunités 1) Acquisition facile du savoir et de l’information

D’un point de vue individuel, tous ces outils permettent aux collaborateurs d’avoir plus d’autonomie dans la réalisation de leur travail au quotidien et un accès facilité à l’information. On assiste vraiment à la démocratisation du savoir, quelque soit la formation de l’individu et ses diplômes. Seul le manque d’initiative personnelle peut être un frein.

2) Liberté du collaborateur

Plus besoin d’être présent sur le de travail pour bien accomplir les tâches au quotidien. Du moment où chaque collaborateur soit joignable à tout moment de la journée et qu’il ait accès aux outils et à l’information, le télétravail devient une option qui prend pleinement son sens. Une flexibilité et une liberté non négligeable pourraient être offertes aux collaborateurs pour conjuguer contraintes de la vie privée et exigences professionnelles sans impacts sur les délais et la qualité du travail fourni. Bien évidemment, cet impact n’est valable que pour les domaines et les tâches qui se prêtent au télétravail.

Risques 1) Bouleversement de l’espace/temps de travail

Avec les moyens NTIC dont on dispose aujourd’hui, il est de plus en plus difficile de faire le distinguo entre temps de travail et temps personnel et de tracer une frontière entre la sphère professionnelle et la sphère privée. Même si pas mal d’entreprises se sont pressées à déployer des politiques d’accès aux ressources internet très restrictives et sélectives, la prolifération des solutions mobiles personnelles à interfaces ergonomiques et la banalisation de la connexion internet mobile rendent ce genre de politique obsolète.

2) Réduction de la sphère privée

Au-delà de l’environnement professionnel, l’omniprésence des NTIC entraine une réduction de la sphère privée des individus tout en accélérant leur popularisation. L’accès et l’alimentation des réseaux sociaux professionnels ou personnels sort les individus de l’anonymat et trace leur histoire. Quand un collaborateur intervient sur un blog, peu importe lequel, commente un post, forcément, n’importe qui peut en porter un jugement, positif soit-il ou négatif.

3) Impact sur la culture

De plus en plus de contenu est produit sur internet, indexé par des moteurs de recherche occupant une place prépondérante dans notre quotidien. Ce constat nous mène à se poser les questions suivantes : aujourd’hui, vaut-il la peine de tout apprendre par cœur? Cela risque t-il d’appauvrir la culture individuelle à terme, ou au contraire de l’enrichir? Un premier élément de réponse nous a été donné par le philosophe Michel Serres dans ce podcast qui nous éclaire sur le fait qu’il faut se libérer l’esprit, en s’appuyant sur internet et l’informatique d’une façon générale, pour se focaliser sur l’innovation…

Les challenges d’aujourd’hui et de demain…

Les NTIC sont en train de transformer profondément le monde du travail, d’abord en interne des entreprises avec l’émergence d’équipes complètement transversales, elles, basées sur la facilité de l’échange et la collaboration au regard des organisations hiérarchiques traditionnelles, qui elles, étaient cantonnées et cloisonnées. Cependant la révolution réside plus dans la mise à disposition et le partage d’une information riche renforçant le sentiment d’autonomie et permettant à chacun de rester en contact permanent avec l’entreprise.

Quelques soient les risques et les opportunités pour les entreprises, leur adoption deviennent inéluctables et tout le challenge aujourd’hui est : comment conjuguer risques et opportunités pour bénéficier de l’apport des NTIC dans la rentabilité et le développement de l’entreprise.

Malgré tout, plusieurs challenges restent à relever par les NTIC. D’abord, la multiplication des outils et la prolifération d’internet a conduit à l’utilisation de plus en plus de serveur de stockage, à la construction d’ordinateurs de plus en plus puissants. C’est le développement durable et la green IT qui seront à terme au cœur du provisionnement des NTIC dans l’entreprise.

Un autre challenge à relever aussi concerne la sécurité des systèmes d’information et la protection de la vie privée.

Pour finir, à force de voir la frontière disparaître entre temps de travail et temps personnel, l’organisation de travail actuelle aura-t-elle un sens à terme? Ou bien, tendons nous vers le travail à la demande, peu importe le jour de la semaine, l’heure de la journée.

Suggestion d'articles :

1. Alfresco est il une solution pour votre entreprise ?
2. Article : Parallélisation, distribution : de nouveaux enjeux pour les applications d’entreprise?
3. Nantes JUG – Apache Maven, mise en œuvre en entreprise

Récemment, j’ai été amené à participer à plusieurs études d’évolution de SI. Ce qui m’a personnellement frappé dans ces différentes missions c’est l’image commune qu’utilisaient nos interlocuteurs pour décrire leur SI idéal. Cette image est celle de la boîte de « LEGO » ! En effet, pour rationaliser les coûts et diminuer les délais des projets, ils souhaitaient avoir des briques applicatives génériques qu’ils pourraient combiner à souhait comme les briques de « LEGO ». Je me suis alors interrogé sur les raisons qui font que ces personnes, d’horizons différents, partagent cet idéal commun.

L’excellente présentation de Luc De Brabandere à l’USI 2009 intitulé « Les dix paradoxes de la créativité »  m’a éclairé sur le sujet. En effet, Luc De Brabandere explique que la créativité des individus est conditionnée par la perception qu’ils ont de leur environnement. Dans notre cas, la vision répandue des SI est héritée du monde des BTP. Pour s’en rendre compte, il suffit de regarder les termes que nous utilisons : maîtrise d’ouvrage, maîtrise d’œuvre, briques, architectes… En conséquence, il est totalement naturel que le SI idéal soit une boîte de « LEGO » géante !

Changer de vision pour changer le SI

A OCTO nous constatons que cette vision boîte de « LEGO » n’est pas efficace. D’une part, le 100% réutilisable est un mythe qu’aucune entreprise n’a réussi à atteindre (nous sommes plutôt dans une fourchette de 5-10%). D’autre part, les composants réutilisables coûtent très cher et, lorsqu’un projet veut en bénéficier, des adaptations s’avèrent souvent nécessaires.

Alors comment faire pour atteindre les objectifs initiaux qui sont la rationalisation des coûts et la diminution des délais des projets ?

La première étape consiste à nous ouvrir de nouvelles perspectives en dépassant le cadre mental que nous nous sommes imposés en regardant le SI comme

Un système évolutif et non comme un système figé comme le sous-entend la vision BTP

Une fois ce nouveau cadre établi, il faut commencer à repenser notre approche des projets informatiques. Pour étayer cette idée, je vais prendre l’exemple des briques réutilisables.

Des briques réutilisables évolutives

L’approche classique des projets informatiques consiste à vouloir définir en totalité et dans le détail une application tout en amont du projet (projet en cascade). Pour les briques réutilisables cette approche nous conduit à vouloir définir, en amont, une brique qui répond à tous les besoins actuels et futurs.

A contrario, en partant du principe que le SI est en évolution constante, il devient naturel d’opter pour une approche incrémentale. En effet, au lieu de vouloir répondre à tous les besoins en même temps, nous allons répondre aux besoins avérés des projets un par un en enrichissant continuellement les fonctionnalités du composant. Et pour rendre possible une évolution continue dans le temps, il faut préserver un temps de traitement des demandes stable, malgré l’inexorable montée en complexité. Dans ce but, deux éléments peuvent être mis en place :

• Un harnais de tests automatisé afin de garantir la non-régression fonctionnelle durant la phase de croissance
• Une équipe pluridisciplinaire dédiée pour garder un niveau élevé d’expertise sur le sujet et faciliter le traitement des demandes

Cette approche présente plusieurs avantages. D’abord, le composant développé est adapté aux besoins des projets et il est directement utilisable. Ensuite, la complexité du composant est réduite considérablement puisqu’il n’embarque que les fonctionnalités nécessaires aux projets (évite le sur-design qui a pour but d’embarquer des besoins futurs non avérés). De plus, le harnais de tests permet d’accélérer la détection les problèmes (tests qui ne passent plus). Enfin, la flexibilité offerte par le modèle incrémental permet de tenir compte des nouveaux besoins qui n’ont pas été prévu au début du projet.

Conclusion

Changer notre vision du SI n’est pas chose facile. En effet, ce changement implique le changement de nos méthodes et notre organisation du travail. Cependant, il faut prendre conscience que pour dépasser les limites actuelles auxquelles nous sommes confrontés, ce changement est nécessaire.

Récemment, j’ai été amené à participer à plusieurs études d’évolution de SI. Ce qui m’a personnellement frappé dans ces différentes missions c’est l’image commune qu’utilisaient nos interlocuteurs pour décrire leur SI idéal. Cette image est celle de la boîte de « LEGO » ! En effet, pour rationaliser les coûts et diminuer les délais des projets, ils souhaitaient avoir des briques applicatives génériques qu’ils pourraient combiner à souhait comme les briques de « LEGO ». Je me suis alors interrogé sur les raisons qui font que ces personnes, d’horizons différents, partagent cet idéal commun.
L’excellente présentation de Luc De Brabandere à l’USI 2009 intitulé « Les dix paradoxes de la créativité » (http://usi2009.universite-du-si.com/webcast-5-31-Luc.De.Brabandere.html) m’a éclairé sur le sujet. En effet, Luc De Brabandere explique que la créativité des individus est conditionnée par la perception qu’ils ont de leur environnement. Dans notre cas, la vision répandue des SI est héritée du monde des BTP. Pour s’en rendre compte, il suffit de regarder les termes que nous utilisons : maîtrise d’ouvrage, maîtrise d’œuvre, briques, architectes… En conséquence, il est totalement naturel que le SI idéal soit une boîte de « LEGO » géante !
Changer de vision pour changer le SI
A OCTO nous constatons que cette vision boîte de « LEGO » n’est pas efficace. D’une part, le 100% réutilisable est un mythe qu’aucune entreprise n’a réussi à atteindre (nous sommes plutôt dans une fourchette de 5-10%). D’autre part, les composants réutilisables coûtent très cher et, lorsqu’un projet veut en bénéficier, des adaptations s’avèrent souvent nécessaires.
Alors comment faire pour atteindre les objectifs initiaux qui sont la rationalisation des coûts et la diminution des délais des projets ?
La première étape consiste à nous ouvrir de nouvelles perspectives en dépassant le cadre mental que nous nous sommes imposés en regardant le SI comme
Un système évolutif et non comme un système figé comme le sous-entend la vision BTP
Une fois ce nouveau cadre établi, il faut commencer à repenser notre approche des projets informatiques. Pour étayer cette idée, je vais prendre l’exemple des briques réutilisables.
Des briques réutilisables évolutives
L’approche classique des projets informatiques consiste à vouloir définir en totalité et dans le détail une application tout en amont du projet (projet en cascade). Pour les briques réutilisables cette approche nous conduit à vouloir définir, en amont, une brique qui répond à tous les besoins actuels et futurs.
A contrario, en partant du principe que le SI est en évolution constante, il devient naturel d’opter pour une approche incrémentale. En effet, au lieu de vouloir répondre à tous les besoins en même temps, nous allons répondre aux besoins avérés des projets un par un en enrichissant continuellement les fonctionnalités du composant. Et pour rendre possible une évolution continue dans le temps, il faut préserver un temps de traitement des demandes stable, malgré l’inexorable montée en complexité. Dans ce but, deux éléments peuvent être mis en place :
-    Un harnais de tests automatisé afin de garantir la non-régression fonctionnelle durant la phase de croissance
-    Une équipe pluridisciplinaire dédiée pour garder un niveau élevé d’expertise sur le sujet et faciliter le traitement des demandes
Cette approche présente plusieurs avantages. D’abord, le composant développé est adapté aux besoins des projets et il est directement utilisable. Ensuite, la complexité du composant est réduite considérablement puisqu’il n’embarque que les fonctionnalités nécessaires aux projets (évite le sur-design qui a pour but d’embarquer des besoins futurs non avérés). De plus, le harnais de tests permet d’accélérer la détection les problèmes (tests qui ne passent plus). Enfin, la flexibilité offerte par le modèle incrémental permet de tenir compte des nouveaux besoins qui n’ont pas été prévu au début du projet.
Conclusion
Changer notre vision du SI n’est pas chose facile. En effet, ce changement implique le changement de nos méthodes et notre organisation du travail. Cependant, il faut prendre conscience que pour dépasser les limites actuelles auxquelles nous sommes confrontés, ce changement est nécessaire.

Nous avons déterminé dans la première partie que les nombres à virgule flottante sont à proscrire.

Nos armes seront donc le BigDecimal en Java, le type decimal en .Net. Malheureusement, d’autres pièges pavent notre chemin.

Notes:

• Sous Oracle, le type NUMBER(p,s) peut être soit décimal si p (et optionnellement s) est spécifié et sera à virgule flottante sinon. Conclusion, toujours spécifier p (et s pour avoir des décimales).
• Pour un Web Service, la valeur d’un type xs:decimal sera sous forme texte (ie. « 123.456″) et sera donc précis et mappé sans problème vers un BigDecimal (Java) ou decimal (.Net).

Utilisation des décimaux Littéraux

J’ai souvent le commentaire suivant: « J’aime pas les BigDecimal, on ne peut pas utiliser les opérateurs du langage avec ». C’est vrai, mais en attendant que Java supporte la surcharge d’opérateur (et c’est pas demain la veille), vous n’avez pas le choix, il faut utiliser les méthodes de la classe BigDecimal.

Le respect de la première règle ci-haut proscrit les choses suivantes:

BigDecimal d = new BigDecimal(1.0); // initialisation par un double
BigDecimal d = BigDecimal.valueOf(1.0); // aussi une initialisation par un double
boolean b = (d.doubleValue() == 0.0); // comparaison avec un double
BigDecimal d = BigDecimal.valueOf(d1.doubleValue() * d2.doubleValue()); // passage par un double pour calcul mathématique

remplacer tout cela par

BigDecimal d = new BigDecimal("1.0"); // crée très précisément un BigDecimal de mantisse 10 et d'échelle 1
BigDecimal d = BigDecimal.valueOf(10, 1); // Même résultat que la ligne précédente
boolean b = (d.signum() == 0); // signum compare avec zéro et retourne -1, 0 ou 1. Pour une valeur différente de zéro, faire un compareTo
BigDecimal d = d1.multiply(d2); // tout le calcul se fait en type décimal

Échelle

L’échelle (scale) indique le nombre de chiffres à droite de la virgule. Il faut bien comprendre que deux chiffres apparemment identiques peuvent être en fait différents de par leur échelle. C’est pour cette raison qu’en Java, dans l’exemple ci-dessous, b sera faux

BigDecimal d1 = new BigDecimal("1.0");
BigDecimal d2 = new BigDecimal("1.00");
boolean b = d1.equals(d2); // false

L’échelle a aussi un impact lors d’opérations mathématiques.

Note: L’affichage d’un BigDecimal (d.toString()) affichera toujours l’échelle en entier et non uniquement les zéros significatifs.

Additions et soustractions

L’échelle du résultat d’une addition ou soustraction sera la plus grosse échelle des deux opérandes.

BigDecimal d1 = new BigDecimal("1.0"); // échelle de 1
BigDecimal d2 = new BigDecimal("2.00"); // échelle de 2
BigDecimal r = d1.add(d2); // résultat d'échelle 2
System.out.println(r); // affiche 3.00

Multiplications

L’échelle du résultat d’une multiplication sera la somme des échelles des opérandes (car mathématiquement, le résultat ne sera jamais sur plus).

BigDecimal d1 = new BigDecimal("1.0"); // échelle de 1
BigDecimal d2 = new BigDecimal("2.00"); // échelle de 2
BigDecimal r = d1.multiply(d2); // résultat d'échelle 3
System.out.println(r); // affiche 2.000

Divisions

Tout se complique pour les divisions. En effet, l’échelle théorique du résultat d’une division est potentiellement infinie (si le résultat de la division est un nombre périodique par exemple). C’est très différent de l’arithmétique en virgules flottantes qui stockera, dans sa taille finie, la valeur la plus proche du résultat réel. Vous aurez donc les résultats suivants:

BigDecimal d1 = new BigDecimal("1.0");
BigDecimal d2 = new BigDecimal("3.0");
System.out.println(d1.divide(d2, RoundingMode.HALF_UP)); // affiche 0.3
System.out.println(d1.divide(d2, 4, RoundingMode.HALF_UP)); // affiche 0.3333
System.out.println(d1.divide(d2)); // ArithmeticException

Si la règle d’arrondi n’est pas spécifié, comme le BigDecimal ne peut décider comment arrondir par lui-même, il retourne une exception *et c’est une bonne chose*. En effet, il ne faut jamais arrondir au hasard. Si vous ne savez pas comment arrondir, demandez à votre MOA. L’arrondi est systématiquement lié à une règle métier (ex.: arrondir à la précision de la monnaie). Je vous recommande d’ailleurs de mettre dans vos tests unitaires des chiffres testant l’arrondi pour prévenir les problèmes.

Comparaison

C’est l’un des comportements laissant le plus perplexes les développeurs. Nous en avons parlé plus haut, le equals
du BigDecimal compare aussi l’échelle. Il ne faut donc jamais l’utiliser si l’on souhaite comparer la valeur du BigDecimal. C’est là où compareTo vient à notre secours. Il se comporte comme nous le voudrions intuitivement.

BigDecimal d1 = new BigDecimal("1.0");
BigDecimal d2 = new BigDecimal("1.00");
int i = d1.compareTo(d2); // 0, ce qui veut dire de même valeur selon le contrat de compareTo

À noter: Comparativement à la comparaison entre nombres à virgule flottante, il n’est pas nécessaire d’ajouter un delta lors des comparaisons. Le décimal étant toujours précis, la comparaison sans delta le sera donc aussi.

Conversion

Il faut prendre quelques précautions lors de la conversion d’une BigDecimal vers une valeur entière. En effet, celui-ci arrondira à l’unité. Il est souvent plus sécuritaire de vérifier s’il y a des décimales lors de la conversion. Les méthodes xxxValueExact() ont donc été mise à disposition pour faire très exactement ceci. Une ArithmeticException sera lancée si une conversion sans arrondi est impossible.

BigDecimal d1 = new BigDecimal("1.1");
System.out.println("i: " + d1.intValue()); // affiche 1
System.out.println(d1.intValueExact()); // lance une ArithmeticException

.NET

L’article s’est pour l’instant beaucoup penché sur Java. L’équivalent .Net du BigDecimal est le decimal. De même qu’en Java, il doit être utilisé en tout temps au lieu du float et double.

Littéraux

Le type decimal étant un type primitif de .Net, C# fournit une syntaxe littérale pour ce dernier (suffixe m). Les zéros non significatifs sont utiles pour déterminer l’échelle.

decimal d = 99.9m; // le m indiquant qu'il s'agit d'un décimal
decimal b = 9.00m; // decimal d'échelle 2

Il est d’ailleurs judicieusement nécessaire de convertir explicitement d’une virgule flottante à un décimal.

decimal a = (decimal) 9.0; // conversion explicite nécessaire et perte de précision potentielle. À ne pas faire!

Calculs mathématiques

Être un type primitif a d’autres avantages, les calculs mathématiques sont plus élégants qu’en Java.

decimal d = 1.0m * 2.0m; // +, -, /, * et % sont utilisables
decimal b = decimal.Multiply(1.0m, 2.0m); // l'équivalent en méthode statique est aussi disponible

La division n’a pas besoin et ne peut avoir de règle d’arrondi. Elle fera au mieux dans les 96 bits d’espace. Il ne faut toutefois pas oublier qu’un arrondi sera éventuellement nécessaire et sera comme toujours guidé par une règle métier.

Comparaison

Comparativement à Java, le compare et le equals donne le même résultat peut importe l’échelle. C’est beaucoup plus intuitif, mais implique qu’il est impossible de comparer en voulant considérer l’échelle.

Console.WriteLine(decimal.Compare(1.00m, 1.0m)); // affiche 0, donc égal
Console.WriteLine(1.0m.CompareTo(1.00m)); // autre façon de comparer, retourne aussi 0
Console.WriteLine(1.0m.Equals(1.00m)); // affiche true

Il est d’ailleurs impossible de connaître l’échelle d’un décimal facilement en .Net. Pour avoir l’échelle, il faut faire ceci:

int scale = (System.Decimal.GetBits(monDecimal)[3] >> 16) & 31; // oui oui, ça s'invente pas

ou passer par un ToString, trouver le séparateur décimal (en fonction de la culture) et compter le nombre de chiffres à sa droite.

Conversion

Au niveau conversion, il existe des méthodes ToXXX permettant la conversion vers un autre type. Le concept de ToXXXExact n’existe pas. Il faut donc s’assurer au préalable qu’il n’y aura pas de perte de précision. Une solution possible est ceci:

decimal toInt = 1.1m;
int i = decimal.ToInt32(toInt);
Console.WriteLine(toInt.Equals(new decimal(i))); // n'est pas égal, car nous avons perdu les décimales

Conclusion

Le but n’est pas de comparer, mais vous l’aurez compris

• La version Java demande de bien comprendre son implémentation, mais sévi en cas de mauvaise utilisation
• La version .Net se veut plus conviviale, mais est donc plus permissive et rend plus compliqués certaines opérations.

Mais peu importe le langage, les choses importantes à retenir se résument à

• Ne pas utiliser de types à virgule flottante pour représenter des décimaux
• Avoir en tête qu’en informatique de gestion tous les nombres ou presque sont des décimaux
• Penser aux arrondis et les faire suivant une règle métier
• Bien avoir en tête les spécificités du langage avant utilisation

Une seule nuance à ces règles. Il est possible que pour des raisons de performance vous deviez utiliser des nombres à virgule flottante. Par exemple, dans le cadre du simulation de Monte-Carlo. Je ne peux dans ce cas que vous recommander de bien vous documenter sur la manipulation des nombres à virgule flottante. Il existe de nombreuses méthodes pour minimiser les problèmes mais le tout reste relativement complexe et sors du cadre de cet article.  Ne les utilisez donc qu’en dernier recours.

En conclusion, appliquez ces règles religieusement et vous devriez être parés pour éviter les soucis de calcul de vos futures applications d’entreprise. Je vous souhaite de précis calculs et vous dis à la prochaine.

Suggestion d'articles :

1. Problèmes courants: Imprécision des calculs mathématiques (1ère partie)
2. Refactoring .NET avec UML, 1ère partie
3. Construire ses parsers ANTLR avec Maven – Partie 3/3 – Testez vos grammaires

Avec la croissance de la plateforme Android et l’annonce de Google sur le nombre de terminaux activés chaque jour, le nombre de projets Android a de bonnes chances de progresser également. Avec cette augmentation, la question de l’industrialisation des développements se pose donc. Pourquoi industrialiser ? Comment ? Des questions auxquelles nous allons répondre dans ce billet…

Pourquoi industrialiser ?

Autant sur une application de gestion, la question ne se pose quasiment pas, autant sur une application Android, on est en droit de se demander si cela vaut le coup.

Effectivement, alors que les projets java se déroulent généralement sur plusieurs mois avec des équipes un peu conséquentes, les projets d’applications mobiles sont généralement plus courtes, avec des équipes plus petites. Les applications doivent être innovantes et rapidement mises sur le Market pour arriver avant la concurrence. Cela vaut-il donc le coup d’investir dans tous les moyens habituels (build, intégration continue, …) qui peuvent paraître lourds et démesurés pour un tel projet ?

A fortiori, le versionning du code est indispensable, peu importe la nature et la taille du projet. Je ne vais pas m’étendre sur le sujet, cela fait des années que cette pratique s’est généralisée. Concernant le build et l’intégration continue, cela a un intérêt dès lors que l’équipe de développement est constituée de plus d’une personne. Cela facilitera le travail des développeurs et permettra d’avoir une version rapidement montrable au marketing ou la MOA, indispensable pour avoir du feedback rapide.

Malgré la taille réduite de ces projets, il ne faut donc pas hésiter à investir un minimum pour faciliter le travail des développeurs d’une part et dans une optique de maintenance d’autre part. L’application doit certes sortir rapidement, mais elle devra continuer de vivre et d’évoluer et donc la qualité incombe.

Maven, la bonne solution ?

Maven a ses détracteurs mais est globalement très répandu en entreprise pour construire les projets java. Concernant Android, je ne suis pas sûr qu’on puisse en dire autant pour le moment…

Après l’avoir utilisé sur l’application Sinistres de Generali, plusieurs constats :

• Les jar Android n’étaient disponibles dans aucun repo central. J’ai contacté Romain Guy pour avoir des infos sur le sujet mais aucune réponse. Ils sont disponibles depuis quelques jours sur le repo central. Enfin ! Par contre, il manque encore google maps.
• Le plugin mosabua, décrit dans le livre Maven Definitive Guide, censé remédier à cela en installant les jar dans le repo local, nécessitait il y a encore peu de temps de modifier les pom.xml pour concorder avec les versions du SDK Android (1.5 pour la 3, 1.6 pour la 4…). Cela semble aujourd’hui résolu mais nous a fait perdre pas mal de temps.
• Une fois installé, le plugin fonctionne plutôt bien et permet de compiler, tester, packager, déployer sur un émulateur… depuis sa ligne de commande mvn.
• Par contre, n’espérez pas trop utiliser le trio Eclipse – Maven – Android, y compris avec m2eclipse. Les trois s’entendent assez mal : les projets Android sous Eclipse ont un format un peu particulier (répertoire gen généré lors des modifications de ressources, référencement du sdk Android). Lorsque m2 est activé sur le projet ou simplement avec eclipse:eclipse, plus rien ne fonctionne : On perd le type Android du projet et il s’emmêle les pinceaux avec le répertoire gen donc impossible de travailler depuis Eclipse, fâcheux. Il existe un plugin eclipse supplémentaire pour tenter d’intégrer les trois mais ca n’a pas fonctionné pour moi…

Au final beaucoup de temps perdu pour avoir un environnement de développement un peu bancal et la question : est ce que Maven est vraiment utile dans notre cas ? On pense tout de suite à Maven lorsqu’il s’agit de builder notre application mais n’est-ce pas un peu too much ?

L’un des principaux bénéfices de Maven est la gestion des dépendances. Hors, dans une application Android, le nombre de dépendances est somme toute assez ridicule. Vous aurez généralement l’api google maps, éventuellement une librairie pour faire du soap, et en poussant le bouchon admob ou google analytics. Aucune dépendance transitive. Bref, pas de quoi sortir la grosse artillerie. D’autant plus qu’aucune de ces librairies n’est dispo dans un repo central et il vous faudra donc les installer manuellement dans un repo d’entreprise ou local.

Pour le reste, toutes les commandes disponibles grâce au plugin Maven le sont également avec ant, qui semble être l’outil préconisé par Google.

Ant, la solution fournie en standard

Lorsque vous créez un projet via la ligne de commande (android create project --target 8 --name AndroidAnt --path ./AndroidAntProject --activity AndroidAntActivity --package com.octo.android.androidant), un fichier build.xml est généré, contrairement aux projets créés dans Eclipse. Ce build.xml minimaliste (quasiment vide) fourni toutefois l’essentiel des tâches nécessaires :

• clean, pour nettoyer le projet
• compile, pour compiler le code et générer les classes
• debug, pour générer le package (apk) avec le keystore de debug (généralement dans $HOME/.android/debug.keystore)
• release, pour générer le package avec votre keystore (généralement celui que vous allez utiliser pour publier sur le market)
• install, pour installer l’application sur un émulateur (démarré) ou un device connecté.
• uninstall, pour désinstaller l’application précédemment installée.

C’est assez confortable car vous n’avez pas à écrire ces tâches, elles sont définies dans le fichier {SDK}/platforms/{platform}/templates/android_rules.xml. Comparé à toutes les tâches plus ou moins manuelles à effectuer avec Maven, on y gagne franchement au départ.

Par contre, la solution Ant souffre également de l’intégration avec Eclipse. En effet, les tâches étant définies dans un fichier externe, elles ne sont pas disponibles dans la vue Ant. La solution alternative consiste à utiliser les external tools avec une des commandes ci-dessus.

Intégration continue

Si les deux outils vu précédemment sont un peu en désaccord avec l’IDE, ils n’en restent pas moins tout à fait utilisable en dehors via la ligne de commande et donc également via un outil d’intégration continue comme Hudson.

Aussi simplement que sur un projet Java standard, vous pouvez configurer un build (maven ou ant) et la commande souhaitée. Mais Hudson va plus loin puisque via le plugin Android Emulator Plugin, vous pouvez démarrer l’émulateur au début du build et l’éteindre à la fin. Vous pouvez également installer l’application sur différentes configurations (version d’Android, résolution d’écran, densité d’écran, locale) afin de valider l’application sur les différentes plateformes cibles.
Si vous ne testez que sur une plateforme, mieux vaut laisser un émulateur fonctionner, ca évite de perdre plus de 5 minutes à chaque build.

Pour le reste, tout se passe comme pour un build standard, la seule particularité étant d’avoir le SDK installé sur le serveur d’intégration continue.

Conclusion

Maven Ant Simplicité / Prise en main 2/5
(plugins diverses pas encore opérationnels) 4/5
(par défaut avec Android) Gestion de dépendances 3.5/5
(les jars android sont enfin sur central, manque encore maps) 2/5
(pas besoin de préciser les jars android) Intégration IDE 2.5/5
(utiliser les external tools) 2.5/5
(utiliser les external tools) Intégration continue 4/5
(plugin hudson) 4/5
(plugin hudson) TOTAL 12 / 20 12.5 / 20

Alors, Ant ou Maven ? Après nos déboires avec Maven sur le projet Generali, j’aurai conseillé Ant sans hésiter. L’arrivée (très) récente des jars dans le repo central me laisse à penser qu’on pourra bientôt travailler avec Maven, Android (et Eclipse) plus sereinement.

Android a l’avantage d’être basé sur le langage Java. On bénéficie ainsi des outils existants pour construire nos applications. Si l’intégration n’est pas totale entre l’IDE, le SDK et ces outils de builds, ils sont indispensables sur un serveur d’intégration continue. C’est aujourd’hui leur principal intérêt, car Eclipse et le plugin Android (AJDT) restent à mon sens incontournable sur le poste du développeur pour être productif.

Dans un prochain article, nous aborderons les problématiques de qualité du code et des tests…

Suggestion d'articles :

1. 5 minutes pour : Quels sont les ateliers de développements, IDE disponibles en PHP ?
2. Développer une application parallèlement sur iPhone et Android
3. Intégrez vos développements d’applications grails avec maven

Après la démocratisation d’Ajax (ie. requêtes HTTP asynchrones en Javascript), plusieurs techniques ont été élaborées afin de permettre le push de données depuis le serveur toujours en utilisant HTTP. C’est grâce à ces techniques que l’on reçoit nos mails dans une application web sans avoir à cliquer sur le bouton « Refresh », que les applications de chat sont possibles sans plugin tierce (Flash, Java, …), etc. Le W3C et l’IETF ont spécifié une API Javascript et un protocole nommé Websocket. Ce protocole connecté est adapté à l’envoi de données dans les deux sens et évite de détourner HTTP de son usage initial (ie. un protocole déconnecté sans état).

Le protocole Websocket, HTTP et les proxys

Websocket n’est donc pas une spécification des techniques de push sur HTTP (long polling, HTTP Streaming, …), ni une surcouche à HTTP mais bien un protocole à part entière.
Il reste pourtant lié à HTTP en réutilisant l’architecture réseau de celui-ci. En effet, l’ouverture d’une connexion Websocket s’effectue avec une requête HTTP qui demande au serveur « de mettre à jour la connexion » en connexion Websocket.

GET /demo HTTP/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1  .P00
Sec-WebSocket-Protocol: sample
Upgrade: WebSocket
Sec-WebSocket-Key1: 4 @1  46546xW%0l 1 5
Origin: http://example.com

^n:ds[4U

Le serveur, s’il supporte le protocole Websocket, peut ainsi terminer l’ouverture de la connexion et la suite du dialogue entre le client et le serveur s’effectuera avec le protocole Websocket.

HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/demo
Sec-WebSocket-Protocol: sample

8jKS'y:G*Co,Wxa-

Ce type d’ouverture de connexion permet de réutiliser le port HTTP (ou HTTPS) classiquement utilisé et de passer les proxys comme une simple requête HTTP. Cependant, certains proxy n’autorisant pas les connexions longues risquent de poser problème en coupant les connexions Websocket.
Avec la démocratisation du protocole Websocket, on peut cependant espérer que ce type de proxy disparaîtra peu à peu.
L’utilisation de Websocket sécurisé (wss:// dans l’URL au lieu de ws://) permet d’augmenter les chances de passer à travers ces proxys peu coopératifs. En effet, si un proxy est explicitement configuré dans le navigateur, les implémentations actuelles de Websocket utilisent des tunnels via HTTP CONNECT de la même façon que HTTPS. La connexion n’est ainsi plus différentiable d’une connexion HTTPS du point de vue des proxys.

Le support des Websockets Le support par les navigateurs

Comme pour les autres fonctionnalités qui viennent avec HTML5, les Websockets ne sont pas supportées par tous les navigateurs :

• Chrome les supporte depuis sa version 4.0.429
• Safari depuis la version 5.0

Quant aux autres navigateurs, ils ne les supportent tout simplement pas encore.

Pour pallier à ce manque temporaire, deux approches ont été implémentées :

• un wrapper Javascript client qui bascule sur une implémentation Flash (qui est capable d’ouvrir des sockets TCP). Cette solution permet de garder tous les avantages des Websockets mais ajoute une dépendance vers le Player Flash,
• un wrapper Javascript client qui bascule sur du long polling ou HTTP Streaming. Cette fois-ci, plus de dépendance vers le Player Flash mais on revient vers une émulation du push avec HTTP.

Le support côté serveur

Côté serveur, il faut distinguer deux types de composants (dans le monde Java) :

• les implémentations du protocole Websocket comme Netty, Grizzly, Jetty 7 (l’article de Xavier montre comment utiliser les Websockets avec Jetty 7), JWebSocket (et son implémentation TCP), Kaazing, … Ces implémentations proposent une API plus (Jetty) ou moins (Kaazing) bas niveau pour exploiter les fonctionnalités du push serveur.
• les frameworks qui proposent une API de plus haut niveau et qui s’appuient sur les implémentations précédentes. On retrouve ainsi Atmoshpere, Cometd (en version 2) ou encore JWebSocket. Ces frameworks proposent donc une API indépendante de l’implémentation WebSocket sous-jacente (d’ailleurs, Atmosphere était avant tout une implémentation de Comet).

Cette distinction ne veut cependant pas dire que les frameworks implémentant le protocole Websocket sont forcément de plus bas niveau que Atmosphere ou JWebSocket. Par exemple, Kaazing propose des fonctionnalités et une API d’au moins aussi haut niveau que celle de JWebSocket.

Pourquoi (pas) les Websockets ?

Au-dela de pouvoir pousser des données du serveur vers le client, encore faut-il pouvoir l’exploiter sans passer son temps dans la plomberie. C’est bien de pouvoir réagir à une connexion, un message, une déconnexion, … mais il faut gérer les clients connectés, les timeouts des connexions (le client ne connait pas le timeout après lequel le serveur coupe la connexion), savoir quels messages renvoyer lorsqu’une coupure de connexion survient et autres limitations du fait de la jeunesse du protocole Websocket.

Là encore les frameworks comme Kaazing, JWebsocket ou Cometd sont bien utiles pour s’occuper de ces problématiques bas niveau mais aussi pour proposer des fonctionnalités utilisant tout le potentiel des Websockets.

Parmi celles-ci, on peut trouver :

• du publish subscribe
• du RPC (Remote Procedure Call) et RRPC (Reverse Remote Procedure Call) pour que le serveur puisse appeler des services du client
• des passerelles vers des protocoles connectés comme JMS, JDBC, Jabber, IMAP, …
• bus événementiel

Enfin, il est légitime de se dire que toutes ces fonctionnalités sont envisageables avec des techniques comme Comet sur HTTP. Alors pourquoi préférer les Websockets alors que leur support par les navigateurs est encore limité et que les proxys risquent de ne pas toujours jouer le jeu ?

Tout d’abord, lorsqu’on utilise du polling ou tout autre technique sur HTTP, on utilise forcément une connexion dédiée pour recevoir des données poussées du serveur vers le client et une autre connexion pour envoyer des données depuis le client (via une requête HTTP classique). Une connexion Websocket, quant à elle, est full duplex. C’est à dire que la même connexion est utilisée pour recevoir et envoyer des données. Le serveur gère donc moins de connexions ouvertes et moins d’ouvertures et fermetures de connexions ponctuelles. Il faut cependant souligner que les implémentations serveur doivent être adaptées à la gestion d’un grand nombre de connexions simultanées et continues (utilisation d’un pool de threads plutôt qu’un thread par socket ouverte, entrées-sorties non bloquantes, notifications par l’OS de l’activité des sockets, …), que ce soit en utilisant Comet ou les Websockets.

Ensuite, en terme de bande passante, la taille du message minimum du protocole WebSocket est de 2 octets (0×00 pour le début du message et 0xFF pour la fin). Avec HTTP, il faut compter au moins 200 octets pour un header. Quand il s’agit d’envoyer des messages de maintient de connexions (ou de réouverture de connexion avec Comet), avec un nombre important de clients connectés, l’occupation de la bande passante avec Comet devient non négligeable.

Conclusion

Le protocole Websocket est donc un moyen de répondre au besoin de push de données depuis le serveur qui était jusque-là implémenté en détournant HTTP de son usage prévu initialement. Il permet ainsi d’optimiser l’usage des resources côté serveur et de faire le pont entre une architecture web (ie. centrée autour de HTTP et des navigateurs Internet) et les autres protocoles connectés (JMS, IMAP, Jabber, …) ouvrant ainsi la porte au web « temp réel ».

Suggestion d'articles :

1. Jetty & HTML 5: les WebSockets sont là !
2. Des téléphones mobiles connectés à internet. Pourquoi faire ?

J’inaugure aujourd’hui une nouvelle chronique que j’ai appelée problèmes courants. J’y traiterai l’une après l’autre les erreurs classiques rencontrées à travers mes années d’informatique.

Ce premier article de la série visera à démystifier les calculs mathématiques et à établir de bonnes pratiques au sein d’une application d’entreprise. Par application d’entreprise, nous entendons une application gérant des montants d’argent, des prix, des quantités. Il a été coupé en deux, la première partie expliquant le problème, la deuxième montrant comment le gérer en Java et .Net.

Bill travaille sur un logiciel de paiement de commissions. Il doit ajouter une commission de 1,2$. Il se fait donc une petite méthode faisant cette opération et le petit test unitaire qui va avec.

 @Test
 public void testAddCommission() {
  double actual = addCommission(1000000.1);
  assertEquals(1000001.3, actual, 0);
 }

 public static double addCommission(double nominal) {
  return nominal + 1.2f;
 }

java.lang.AssertionError: expected:<1000001.3> but was:<1000001.3000000477>

« Ah ben zut alors! C’est pas le bon résultat ».

Qu’est-ce qui se passe?

Virgules flottantes vs décimaux

Les nombres à virgule flottante (floating point numbers) ont été introduits pour des raisons de performance (et uniquement pour ça) dans les ordinateurs. Ils sont devenus omniprésents depuis l’arrivée du Intel 80486 et son coprocesseur de virgules flottantes. Cela permet de faire une multiplication ou une division en 1 cycle de processeur. Il s’agit des types float, double et quad (leur précision respective dépend du langage mais chacun double la précision du précédent).

Avec des décimaux, c’est plus lent (en gros autant d’opérations que quand vous posiez une multiplication au primaire, sauf qu’heureusement un ordinateur va plus vite et fait moins de fautes…). Par décimaux nous entendons le type decimal (en .Net) et BigDecimal (en Java).

Pourquoi utilisez de décimaux dans ce cas me direz-vous? Car ils n’utilisent pas la même représentation.

Dans les deux cas, nous avons une mantisse et un exposant. Toutefois, la mantisse d’un décimal est un entier. Celle de la virgule flottante, un nombre entre 0 et 1 en base 2. Il faut bien comprendre que les chiffres à droite de la virgule sont donc puissance de fraction de 2, car nous sommes en base 2. Par exemple, 0,1 en base 2 vaut 0,5 en base 10.

Un autre exemple: 7.5, s’écrit 75E-1 en décimal, la mantisse est de 75 et l’exposant sera -1. Pour la virgule flottante, nous aurons 0.75E1 en base 10, ce qui donne 0.11 en base 2 ((1/2)^1 + (1/2)^2) pour la mantisse et 1 pour l’exposant. En gros, il s’agit d’une série de puissance d’1/2 au lieu d’un série de puissance de 1/10. C’est ce changement de représentation qui permet des calculs si rapide, car comme on le sait, les ordinateurs aiment bien le binaire.

C’est un problème de base

Les problèmes surviennent quand le nombre se représente parfaitement en base 10, mais ne peut l’être en base 2. L’exemple courant est 0.1. Sa valeur en base 2 est périodique (0.000110011001100…). Nous ne pouvons par le représenter précisément. La norme IEEE 754 régissant l’arithmétique des nombres à virgule flottante s’efforce donc de les exprimer au mieux et de gérer les arrondis, mais la perte de précision reste.

Il est très important de comprendre que les problèmes dont on parle sont des problèmes de représentation et non pas des problèmes de précision.
Les problèmes de précision, on sait les gérer. Il suffit d’augmenter la précision. La précision n’est pas suffisante dans un double et hop, on passe à un quad. Mais notre 0,1 ne pourra toujours pas être représenté précisément. À noter, ce n’est pas dépendant du langage. Tous les représentent de la même façon et utilisent le coprocesseur de virgules flottantes pour leurs calculs.

L’exemple de 0.1 en plus détaillé:

float f = 0.1f;
System.out.println(f); // affiche 0.1
BigDecimal d = new BigDecimal(f);
System.out.println(d); // affiche 0.100000001490116119384765625

On pourrait croire que le passage vers le BigDecimal détruit le chiffre. Et non. Pour compliquer l’histoire, c’est l’affichage du float qui est faux. La vraie valeur du float est celle affichée par le BigDecimal. Mais l’algorithme d’affichage des virgules flottantes est d’afficher autant de bits que nécessaire pour faire la différence entre deux valeurs adjacentes. Donc, en fait, l’affichage tronque la vraie valeur.

Conclusion

Comme nous avons brièvement vu plus haut, le type décimal est différent. Il est composé d’une mantisse et d’une échelle, mais la mantisse est sous forme d’entier. La valeur décrite est donc dans tous les cas parfaitement représentée et n’a pas besoin d’être arrondie. Cette précision est essentielle dans le cadre d’une application manipulant des montants d’argent par exemple.

D’ailleurs, nos ancêtres le savaient. Aucun programmeur Cobol de l’époque n’utiliserait une virgule flottante. Malheureusement, le savoir s’est perdu en chemin. Le plus cuisant exemple est Java qui n’avait même pas de type décimal (BigDecimal) lors de sa création.

Cette erreur a été réparé et en prime, le BigDecimal java n’a virtuellement pas de restriction de taille (et donc de problème de précision). Le decimal .Net est de son côté sur 128 bits. C’est largement suffisant pour prévenir les erreurs de précision étant donnée l’échelle des montants des applications d’entreprise.

Première règle: Ne jamais utiliser de nombres à virgule flottante dans vos applications de type entreprise. Dans aucun cas! Même pour vos littéraux. Mettez une règle Checkstyle s’assurant que personne ne les utilise.

Il y a bien sûr des exceptions à cette règle (performance), mais elles sont rarissimes.

La suite de cet article détaillera l’usage des types décimaux (BigDecimal et decimal) en Java et .Net. En effet, même s’ils préviennent les problèmes de représentation, d’autres erreurs vous attendent à l’orée du bois.

Suggestion d'articles :

1. Problèmes courants: Imprécision des calculs mathématiques (2e partie)
2. Sécurité des services web – 1ère partie
3. Refactoring .NET avec UML, 1ère partie