L’écosystème Hadoop

En 2004, Google a publié un article présentant son algorithme de calcul à grande échelle, MapReduce, ainsi que son système de fichier en cluster, GoogleFS. Rapidement (2005) une version open source voyait le jour sous l’impulsion de Yahoo.

Aujourd’hui il est difficile de se retrouver dans la jungle d’Hadoop pour les raisons suivantes :

1. Ce sont des technologies jeunes.

2. Beaucoup de buzz et de communication de sociétés qui veulent prendre le train Big Data en marche.

3. Des raccourcis sont souvent employés (non MapReduce ou un équivalent n’est pas suffisant pour parler d’Hadoop).

4. Beaucoup d’acteurs différents (des mastodontes, des spécialistes du web, des start-up, …).

Dans une distribution Hadoop on va retrouver les éléments suivants (ou leur équivalence) HDFS, MapReduce, ZooKeeper, HBase, Hive, HCatalog, Oozie, Pig,  Sqoop, …

Ces solutions sont des projets Apache et donc disponibles mais l’intérêt d’un package complet est évident : compatibilité entre les composants, simplicité d’installation, support, …

Dans cet article on évoquera les trois distributions majeures que sont Cloudera, HortonWorks et MapR, toutes les trois se basant sur Apache Hadoop.

On peut toutefois les distinguer en fonction de la distance qu’elles prennent avec cette base :

• MapR : noyau Hadoop mais repackagé et enrichi de solutions propriétaires.

• Cloudera : fidèle en grande partie sauf pour les outils d’administration.

• HortonWorks : fidèle à la distribution Apache et donc 100% open source.

Il existe d’autres distributions, voire des offres cloud, mais qui n’offrent pas l’ensemble des fonctionnalités d’une plate forme Hadoop ou ne sont pas open source (ou a minima gratuites) comme Intel Distribution for Hadoop ou bien Greenplum (Pivotal HD).

Le cœur : Hadoop kernel

Hadoop est le framework le plus utilisé actuellement pour manipuler et faire du Big Data.

Apache Hadoop est un framework qui va permettre le traitement de données massives sur un cluster allant de une à plusieurs centaines de machines, c’est un projet open source (Apache v2 licence).

Hadoop est écrit en Java et a été créé par Doug Cutting et Michael Cafarella en 2005 (Doug, travaillait alors pour Yahoo sur son projet de crawler web Nutch).

C’est lui qui va gérer la distribution des données au cœur des machines du cluster, leurs éventuelles défaillances mais aussi l’agrégation du traitement final.

L’architecture est de type « Share nothing » : aucune donnée n’est traitée par deux noeuds différents même si les données sont réparties sur plusieurs noeuds (principe d’un noeud primaire et de noeuds secondaires). 

HDFS (Hadoop Distributed File System)

HDFS est un système de fichiers Java utilisé pour stocker des données structurées ou non sur un ensemble de serveurs distribués.

HDFS s’appuie sur le système de fichier natif de l’OS pour présenter un système de stockage unifié reposant sur un ensemble de disques et de systèmes de fichiers hétérogènes.

La consistance des données est basée sur la redondance. Une donnée est stockée sur au moins n volumes différents.

Éléments importants :

Node (Master/slave) : Dans une architecture Hadoop chaque membre pouvant traiter des données est appelé node (Noeud). Un seul d’entre eux peut être master même s’il peut changer au cours de la vie du cluster.

Il est responsable de la localisation des données dans le cluster (il est appelé Name Node). Les autres sont des slaves appelés Data Nodes.

Bien qu’il puisse y avoir plusieurs Name Nodes, la “promotion” doit se faire manuellement (Hadoop 2.0, actuellement en version alpha, introduit un failover automatisé).

Le Name Node est donc un Single Point Of Failure (SPOF) dans un cluster Hadoop.

Au sein du cluster, les données sont découpées et distribuées en blocks selon les deux paramètres suivants :

• Blocksize : Taille unitaire de stockage (généralement 64 Mo ou 128 Mo). C’est à dire qu’un fichier de 1 Go (et une taille de block de 128 Mo) sera divisé en 8 blocks.

• Replication factor : C’est le nombre de copies d’une données devant être réparties sur les différents noeuds du cluster (souvent 3, c’est à dire une primaire et deux secondaires).

Enfin, un principe important d’HDFS est que les fichiers sont de type “write-once” car dans des opérations analytiques on lit la donnée beaucoup plus qu’on l’écrit. C’est donc sur la lecture que les efforts ont été portés.
Ce qui signifie que l’on ne modifie pas les données déjà présentes.

Un principe lié est qu’à partir du moment ou un fichier HDFS est ouvert en écriture, il est verrouillé pendant toute la durée du traitement.
Il est donc impossible d’accéder à des données ou à un résultat tant que le job n’est pas terminé et n’a pas fermé le fichier (et un fichier peut être très volumineux avec Hadoop).

Alternatives

MapR

En mai 2011, MapR a annoncé une alternative au système HDFS. Ce système permet d’éviter le SPOF qu’est le Name Node. Ce système n’est pas inconnu car il s’agit de HBase, dont elle propose une version propriétaire.

HBase (Apache)

HBase est un sous-projet d’Hadoop, c’est un système de gestion de base de données non relationnelles distribué, écrit en Java, disposant d’un stockage structuré pour les grandes tables.

HBase est inspirée des publications de Google sur BigTable. Comme BigTable, c’est une base de données orientée colonnes.

HBase est souvent utilisé conjointement au système de fichiers HDFS, ce dernier facilitant la distribution des données de HBase sur plusieurs noeuds.

Contrairement à HDFS, HBase permet de gérer les accès aléatoires read/write pour des applications de type temps réel.

Cassandra (Facebook)

Cassandra est une base de données orientée colonnes développée sous l’impulsion de Facebook.

Cassandra supporte l’exécution de jobs MapReduce qui peuvent y puiser les données en entrée et y stocker les résultats en retour (ou bien dans un système de fichiers).

Cassandra comparativement à HBase est meilleur pour les écritures alors que ce dernier est plus performant pour les lectures.

Offre Cloud

Le cloud est un complément idéal au monde Hadoop, en offrant des possibilités de stockage et de traitement extensibles.

Il est donc possible d’utiliser un système de fichiers situé dans le cloud pour le stockage des données et l’exécution des traitements.

Solutions supportées :

• Amazon S3.

• Kosmix’s CloudStore.

• IBM GPFS (General Parallel File System).

MapReduce

A l’origine crée par Google pour son outil de recherche web.

C’est un framework qui permet le décomposition d’une requête importante en un ensemble de requêtes plus petites qui vont produire chacune un sous ensemble du résultat final : c’est la fonction Map.

L’ensemble des résultats est traité (agrégation, filtre) : c’est la fonction Reduce.

Alternatives

YARN (HortonWorks)

YARN (Yet-Another-Resource-Negotiator) est aussi appelé  MapReduce 2.0, ce n’est pas une refonte mais une évolution du framework MapReduce.

YARN apporte une séparation claire entre les problématiques suivantes :

• Gestion de l’état du cluster et des ressources.
• Gestion de l’exécution des jobs.

YARN est compatible avec les anciennes versions de MapReduce (il faut simplement recompiler le code).

Les extensions

Requêtage des données : Hive (Facebook)

Hive est à l’origine un projet Facebook qui permet de faire le lien entre le monde SQL et Hadoop.

Il permet l’exécution de requêtes SQL sur un cluster Hadoop en vue d’analyser et d’agréger les données.

Le langage SQL est nommé HiveQL. C’est un langage de visualisation uniquement, c’est pourquoi seules les instructions de type “Select” sont supportées pour la manipulation des données.

Dans certains cas, les développeurs doivent faire le mapping entre les structures de données et Hive.

Hive utilise un connecteur jdbc/odbc.

Scripting sur les données : Pig (Yahoo)

Pig est à l’origine un projet Yahoo qui permet le requêtage des données Hadoop à partir d’un langage de script.

Contrairement à Hive, Pig est basé sur un langage de haut niveau PigLatin qui permet de créer des programmes de type MapReduce.

Contrairement à Hive, Pig ne dispose pas d’interface web.

Intégration SGBD-R : Sqoop (Cloudera)

Sqoop permet le transfert des données entre un cluster Hadoop et des bases de données relationnelles.

C’est un produit développé par Cloudera.

Il permet d’importer/exporter des données depuis/vers Hadoop et Hive.

Pour la manipulation des données Sqoop utilise MapReduce et des drivers JDBC.

Ordonnanceur : Apache Oozie (Yahoo)

Oozie est une solution de workflow (au sens scheduler d’exploitation) utilisée pour gérer et coordonner les tâches de traitement de données à destination de Hadoop.

Oozie s’intègre parfaitement avec l’écosystème Hadoop puisqu’il supporte les types de jobs suivant :

• MapReduce (Java et Streaming).

• Pig.

• Hive.

• Sqoop.

• Autres tels que programmes Java ou scripts de type Shell.

Gestion des clusters Hadoop

Clustering

Apache ZooKeeper

ZooKeeper est un service de coordination des services d’un cluster Hadoop.

En particulier, le rôle de ZooKeeper est de fournir aux composants Hadoop les fonctionnalités de distribution.

Pour cela il centralise les éléments de configuration du cluster Hadoop, propose des services de clusterisation et gère la synchronisation des différents éléments (événements).

ZooKeeper est un élément indispensable au bon fonctionnement de HBase. 

Supervision

Apache Ambari (HortonWorks)

Ambari est un projet d’incubation Apache initié par HortonWorks et destiné à la supervision et à l’administration de clusters Hadoop.

C’est un outil web qui propose un tableau de bord. Cela permet de visualiser rapidement l’état d’un cluster.

Ambari dispose d’un tableau de bord dont le rôle est de fournir une représentation :

• De l’état des services.

• De la configuration du cluster et des services.

• Des informations issues de Ganglia et de Nagios.

• De l’exécution des jobs.

• Des métriques de chaque machine et du cluster.

De plus Ambari inclue un système de gestion de configuration permettant de déployer des services d’Hadoop ou de son écosystème sur des clusters de machines.

Ambari se positionne en alternative à Chef, Puppet pour les solutions génériques ou encore à Cloudera Manager pour le monde Hadoop.

Ambari ne se limite pas à Hadoop mais permet de gérer également tous les outils de l’écosystème.

Les outils annoncés sont :

• Hadoop

• HDFS

• MapReduce

• Hive, HCatalog

• Oozie

• HBase

• Ganglia, Nagios

Autres

Apache Flume (Cloudera)

Flume est une solution de collecte et d’agrégation de fichiers logs, destinés à être stockés et traités par Hadoop.

Il a été conçu pour s’interfacer directement avec HDFS au travers d’une API native.

Flume est à l’origine un projet Cloudera, reversé depuis à la fondation Apache.

Alternatives : Apache Chukwa.

Apache Mahout

Apache Mahout est un projet de la fondation Apache visant à créer des implémentations d’algorithmes d’apprentissage automatique et de datamining.

Même si les principaux algorithmes d’apprentissage se basent sur MapReduce, il n’y a pas d’obligation à utiliser Hadoop. Apache Mahout ayant été conçu pour pouvoir fonctionner sans cette dépendance. 

Apache Drill (MapR)

Initié par MapR, Drill est un système distribué permettant d’effectuer des requêtes sur de larges données. Il implémente les concepts exposés par le projet Google Dremel.

Drill permet d’adresser le besoin temps réel d’un projet Hadoop. MapReduce étant plutôt conçu pour traiter de larges volumes de données en batch sans objectif de rapidité et sans possibilité de redéfinir la requête à la volée.

Drill est donc un système distribué qui permet l’analyse interactive des données, ce n’est pas un remplacement de MapReduce mais un complément qui est plus adapté pour certains besoins.

Apache HCatalog (HortonWorks)

HCatalog permet l’interopérabilité d’un cluster de données Hadoop avec des systèmes externes.

HCatalog est un service de management de tables et de schéma des données Hadoop :

• Permet d’attaquer les données HDFS via des schémas de type tables de données en lecture/écriture.
• Permet d’opérer sur des données issues de MapReduce, Pig ou Hive.

Apache Tez (HortonWorks)

Tez est un nouveau framework en incubation chez Apache.

Utilisant YARN il remplace MapReduce afin de fournir des requêtes dites “temps réel”. La faible latence est en effet un pré requis à l’exploration interactive des données stockées sur un cluster Hadoop.

C’est un concurrent d’Apache Drill (MapR) ou de Cloudera Impala.

Vue d’ensemble de la plate forme Hadoop

Les distributions

HortonWorks

Présentation

HortonWorks a été formé en juin 2011 par des membres de l’équipe Yahoo en charge du projet Hadoop.

Leur but est de faciliter l’adoption de la plate forme Hadoop d’Apache, c’est pourquoi tous les composants sont open source et sous licence Apache.

Le modèle économique d’HortonWorks est de ne pas vendre de licence mais uniquement du support et des formations.

Cette distribution est la plus conforme à la plate forme Hadoop d’Apache et HortonWorks est un gros contributeur Hadoop.

Parmi les projets reversés il y a :

• YARN,

• HCatalog,

• Ambari,

• …

Composants de la plate forme HDP

Les éléments suivants composent la plate forme HortonWorks :

1. Cœur Hadoop (HDFS/MapReduce).

2. NoSQL (Apache HBase).

3. Méta-données (Apache HCatalog).

4. Plate forme de script (Apache Pig).

5. Requêtage (Apache Hive).

6. Planification(Apache Oozie).

7. Coordination (Apache Zookeeper).

8. Gestion et supervision (Apache Ambari).

9. Services d’intégration (HCatalog APIs, WebHDFS, Talend Open Studio for Big Data, Apache Sqoop).

10. Gestion distribuée des logs (Apache Flume).

11. Apprentissage (Apache Mahout).

Vision d’ensemble de la distribution

Déploiement de la plate forme

Machine Virtuelle prête à l’emploi

HortonWorks met à disposition une machine virtuelle ou sont pré installés les composants de la plate forme Hadoop.

C’est l’idéal pour l’apprentissage de la plate forme mais incompatible avec les exigences de production ou même celles d’un POC.

Installation automatique avec Ambari

En plus de la gestion du cluster, Ambari permet le déploiement de l’ensemble des composants Hadoop de manière centralisée.

Installation manuelle avec Linux RPM

HortonWorks met à disposition des packages RPM.

En utilisant le principe des RPM Linux il est possible d’installer les composants HDP manuellement.

Cloudera

Présentation

Cloudera se veut comme la compagnie commerciale Hadoop.

Fondée par des experts Hadoop en provenance de Facebook, Google, Oracle et Yahoo.

Si leur plate forme est en grande partie basée sur Hadoop d’Apache, elle est complétée avec des composants maison essentiellement pour la gestion du cluster.

A noter aussi que la version d’Apache Hadoop distribuée est la dernière version stable complétée de patchs critiques ainsi que de quelques fonctionnalités de la version de développement.

Le modèle économique de Cloudera est la vente de licences mais aussi du support et des formations. 

Cloudera propose une version entièrement open source de leur plate forme (Licence Apache 2.0).

Composants de la plate forme CDH (Cloudera’s Distribution including Apache Hadoop)

Composants Apache :

• HDFS : File System distribué.

• MapReduce : Framework de traitement parallélisé.

• HBase : Base de données NoSQL (accès read/write aléatoires).

• Hive : Requêtage de type SQL.

• Pig : Scripting et requêtage Hadoop.

• Oozie : Workflow et planification de jobs Hadoop.

• Sqoop : Intégration de bases SQL.

• Flume : Exploitation de fichiers (log) dans Hadoop.

• ZooKeeper : Service de coordination pour les applications distribuées.

• Mahout : Framework d’apprentissage et de datamining pour Hadoop.

Composants d’origine Cloudera :

• Hadoop Common: Un ensemble d’utilitaires.

• Hue : SDK permettant de développer des interfaces utilisateur pour les applications Hadoop.

• Whirr : Librairies et scripts pour l’exécution d’Hadoop et de services liés dans le cloud.

Composants non Apache Hadoop :

• Cloudera Impala : Moteur temps réel de requêtage SQL parallélisé de données stockées dans HDFS ou HBase. Contrairement à Hive de Hadoop, Impala n’utilise pas le framework MapReduce qui exige que les résultats de recherche soient écrits sur le disque, ce qui lui permet d’exécuter les requêtes plus rapidement. La consultation des données peut être interactive. Licence : ASLv2.

• Cloudera Manager : Déploiement et gestion des composants Hadoop.

A noter que Cloudera Manager n’est pas entièrement Open Source mais dispose d’une version gratuite avec quelques restrictions :

• La version gratuite est limitée à 50 noeuds.

• Certaines fonctionnalités sont uniquement disponibles sur la version commerciale (comme le monitoring, les sauvegardes et les mises à jour automatiques).

• Support uniquement pour la version payante.

Vision d’ensemble de la distribution

Déploiement de la plate forme

Automatique avec Cloudera Manager

Cloudera Manager permet l’installation des composants de la plate forme sur une machine (y compris distante).

Cloudera Manager permet la configuration centralisée des composants du cluster.

Enfin Cloudera Manager permet de finaliser l’installation en vérifiant le bon fonctionnement de chacun des composants.

Manuel avec les packages

Récupération des archives tarball (tgz) contenant la distribution.

Configuration et installation à l’aide des scripts fournis.

MapR

Présentation

MapR a été fondée en 2009 par d’anciens membres de Google.

Bien que son approche soit commerciale, MapR contribue à des projets Apache Hadoop comme HBase, Pig, Hive, ZooKeeper et surtout Drill. 

MapR se distingue surtout de la version d’Apache Hadoop par sa prise de distance avec le cœur de la plate-forme. Ils proposent ainsi leur propre système de fichier distribué ainsi que leur propre version de MapReduce : MapR FS et MapR MR.

Trois versions de leur solution sont disponibles :

• M3 : version open source.

• M5 : Ajoute des fonctions de haute disponibilité et du support.

• M7 : Environnement HBase optimisé.

MapR a remporté de beaux succès commerciaux depuis sa création.

• Un partenariat avec EMC pour une la création et le support d’une version spécifique à la plate forme Hadoop d’EMC.

• MapR est à l’origine de la version cloud de MapReduce d’Amazon : Elastic Map Reduce (EMR).

• Enfin ils ont été retenu par Google pour l’offre Big Data de Google Compute Engine (GCE).

Contenu de la distribution MapR M3

Composants Apache :

• HBase,

• Pig,

• Hive,

• Mahout,

• Cascading,

• Sqoop,

• Flume

MapR propose son propre système en remplacement de HDFS :

• Une version maison de HBase (performance et fiabilité améliorées).

Avantages :

• Système plus adapté au mode read/write que HDFS.

• MapR intègre un serveur NFS (Network File System) pour l’intégration au SI de l’entreprise.

• Simplification de mise en oeuvre (surcouche du File System de l’OS et non remplacement comme HDFS).

• Plus de Single Point Of Failure.

MapR FS reste compatible avec les API MapReduce/HDFS et HBase.

MapR propose son propre système en remplacement de MapReduce d’Apache.

Avantages :

• MapR annonce de meilleures performances.

• Entièrement optimisé pour HBase.

MapR Control System (MCS)

MCS permet la gestion et la supervision du cluster Hadoop. C’est un outil web permettant à la fois les ressources du cluster (CPU, Ram, Disque) que les services et les jobs.

MCS permet de définir des alarmes sur des seuils ou des quotas …

La visualisation des informations est assurée par le composant HeatMap.

Autres spécificités :

Apache Cascading

Cascading est un framework Java dédié à Hadoop. Il permet à un développeur Java de retrouver ses marques (JUnit, Spring, etc…) et de manipuler les concepts d’Hadoop avec un langage de haut niveau sans en  connaître les API.

Apache Vaidya

Hadoop Vaidya est un outil d’analyse des performances des jobs MapReduce.

Son principe de fonctionnement est basé sur des règles qu’il confronte aux statistiques d’exécution des jobs et aux fichiers de configuration.

Le rapport est produit au format XML.

Apache Drill

MapReduce a la réputation d’être puissant mais complexe à manipuler (il faut en maîtriser l’API).

De plus, il est impossible de redéfinir les requêtes à la volée.

Drill vient compléter MapReduce et se présente sous la forme d’une API permettant de créer plus rapidement des requêtes en se basant sur le modèle SQL.

SQL plutôt qu’une nouvelle API, c’est donc le choix de la capitalisation fait par Drill.

Vision d’ensemble de la distribution

Déploiement de la plate forme

Machine virtuelle

MapR fourni une machine virtuelle avec un seul noeud et l’ensemble des composants installés.

C’est l’idéal pour une prise en main de la plate-forme mais incompatible avec les exigences de production.

Manuelle avec les packages

MapR ne fournit pas de système de déploiement Hadoop.

L’installation est donc essentiellement manuelle avec des automatisations possibles.

Tout d’abord il faut récupérer les composants à installer :

• Depuis le repository internet

• Depuis un repository local

• Avec des packages Debian/Linux

Après édition de la configuration il faut ensuite exécuter les scripts fourni pour installer les composants MapR sur chaque machine.

A noter que la distribution ne contient pas les composants Apache et qu’il faut les installer manuellement.

Conclusion

Les trois distributions ont une approche et un positionnement différent en ce qui concerne la vision d’une plate forme Hadoop (open source, modèle économique…).

Le choix se portera sur l’une ou l’autre solution en fonction des exigences :

• Solution open source.

• Maturité de la solution.

• Partenariats et compatibilité avec les produits satellites. 

Le choix d’une distribution est d’autant plus difficile que l’avenir d’Hadoop est loin d’être tout tracé.

En effet des virages technologiques importants sont d’ores et déjà annoncés :

1. Hadoop est né afin de répondre à la problématique suivante : comment traiter des téra-octets de données simplement ?

La réponse proposée alors, un système de fichier distribué, est arrivée à un moment où il était impossible de traiter de tels volumes de données en mémoire. Maintenant le coût de la RAM a fortement baissé et avec la généralisation des architecture 64 bits ce n’est plus tout à fait exact.

2. La sécurité : elle est encore balbutiante malgré quelques initiatives comme Apache Knox.

3. L’intégration avec le SI, une plate forme Hadoop isolée et non intégrée au système d’information ne sera plus possible dans le futur (en tout cas certains besoins exigeront une interaction plus grande).

4. Un support direct des transactions ce qui a toujours été un challenge très important dans le monde des données distribuées.

Cloudera

Le vétéran ce qu’il lui donne une légitimité et un nombre de clients supérieur à ces concurrents.

Un autre avantage est de disposer dans ses rangs de Doug Cutting le créateur d’Hadoop.

Cloudera est très prompt à sortir les dernières versions d’Hadoop (les premiers à sortir une distribution compatible Hadoop 2.0).

Les principaux partenaires sont IBM, HP, Oracle.

MapR

La plus éloignée d’Apache Hadoop car elle intègre leur propre vision de MapReduce et HDFS. Après Cloudera c’est la solution la plus mature.

C’est aussi la solution la plus simple à  installer grâce à leur utilisation du file system natif.

Beaucoup de partenariats de haut niveau et très stratégiques sur le cloud (Amazon Elastic MapReduce et Google Compute Engine).

HortonWorks

C’est la seule plate forme 100 % Apache Hadoop.

La stratégie assumée d’HortonWorks est de se baser sur les versions stables et testées d’Apache Hadoop plutôt que sur les dernières versions.

Leur solution de gestion du cluster, Ambari, n’est pas aussi mature que la concurrence : Cloudera Manager et HeatMap.

Malgré sa relative jeunesse, HortonWorks a signé des partenariats importants avec IBM, Microsoft, Teradata et Talend. Ils ont notamment signé avec Microsoft un accord pour le déploiement de leur plate forme sur Azure.

Il y a une poignée d’années, prononcer le mot Javascript face à un développeur JavaEE, c’était comme parler de la valeur du ticket restaurant lors d’un premier entretien d’embauche… Juste un truc pas complètement à côté de la plaque, mais plutôt à éviter, un aspect de la réalisation qu’il fallait mieux cacher comme la poussière qu’on pousse sous le tapis…

Et puis, progressivement, une révolution a eu lieu : le HTML5 s’est précisé, l’outillage s’est raffiné (merci Firebug et Chrome !) et surtout des frameworks de plus en plus puissants et faciles à utiliser ont fleuri (en commençant par JQuery), permettant d’exploiter à fond les capacités impressionnantes de ce langage. Et petit à petit, les technologies Front ont retrouvé grâce auprès des développeurs JavaEE.

Dernier acte à ce jour, la parution de plusieurs solutions dites de MVC javascript, telles que BackBone.js (qui fait déjà figure d’ancêtre !), Angular.js et Ember.js (pour ne citer que les plus populaires).

Ember.js : mon petit préféré…

Dans ce post, nous nous intéresserons uniquement à Ember.js, qui est à mon goût, la solution la plus complète et la plus “élégante” (en tout cas de celles que j’ai pu aborder…)

Ember est un framework Javascript issu du projet SproutCore, grandement utilisé par Apple notamment pour ses applications Web. Contrairement à Backbone.js, Ember est directement conçu pour être couplé à Handlebars pour les aspects templating, et offre immédiatement des possibilités de binding bi-directionnelles. Il est dépendant de JQuery.

Son apprentissage est relativement rapide, grâce à un site Web plutôt didactique et à une bonne documentation de l’API (en tout cas, tant qu’on ne touche pas à Ember-data qui fera sûrement l’objet d’un autre post…). Je recommande cependant l’excellent article d’Andy Matthews (http://www.adobe.com/devnet/html5/articles/flame-on-a-beginners-guide-to-emberjs.html) pour une première plongée. C’est clairement cet article qui m’a permis d’écrire le mien ! Il y a également un très bon tutoriel vidéo directement disponible sur le site.

Étant un amateur de portail (j’ai prononcé un gros mot ?), je me suis dit qu’il serait intéressant de voir dans quelle mesure il pourrait être possible d’utiliser Ember dans le cadre particulier d’une portlet. Il n’y a rien d’évident à cela, sachant que ce type de framework est généralement conçu pour manipuler une page Web, alors même qu’une portlet ne produira qu’un fragment de la page… La cible retenue est l’inusable Liferay.

Maven et Liferay : c’est possible !

Depuis la version 6.1 du portail Liferay, il est possible d’abandonner le plugin sdk de l’éditeur pour une structure plus classique de projet Maven. Liferay publie en effet à la fois les artefacts du portail et les plugins de construction ou de déploiement sur des repositories publics.

Pour aller plus loin, vous aurez donc besoin :

• De télécharger et de dézipper un bundle Liferay/tomcat (disponible à l’URL http://www.liferay.com/downloads/liferay-portal/available-releases),
• D’avoir une installation Maven opérationnelle sur votre station.

Pour plus de simplicité, il est préférable de définir au préalable un profile spécifique à l’installation locale de son portail Liferay dans le fichier settings.xml du répertoire .m2. Ce profile est du type :

  <profile>
    <id>emberlf</id>
    <properties>
       <liferay.version>6.1.1</liferay.version>
       <liferay.auto.deploy.dir>%path to liferay bundle%/Liferay6.1/liferay-portal-6.1.1-ce-ga2/deploy</liferay.auto.deploy.dir>
    </properties>
  </profile>

Démarrer votre portail et lancer la création du squelette de projet de portlet par la commande suivante :

  mvn archetype:generate -DarchetypeArtifactId=liferay-portlet-archetype -DarchetypeGroupId=com.liferay.maven.archetypes -DarchetypeVersion=6.1.0 -DgroupId=fr.ippon.liferay.ember -DartifactId=ember-portlet -Dversion=1.0-SNAPSHOT -DinteractiveMode=false

Charger le projet dans votre éditeur, et vous avez alors une magnifique portlet qui ne fait rien… On peut même la déployer sur le portail à l’aide d’une commande :

  mvn -Pemberlf package liferay:deploy

Ah si, elle affiche “This is the ember-portlet.”.

Le reste de cet article va vous montrer comment faire rapidement bien mieux !

Intégration d’Ember à la portlet

Avant toute chose, il faut bien entendu récupérer la distribution d’Ember.js et les frameworks associés. Cet article se base sur la version 1.0.0-rc3.

La première chose à faire est de recopier les ressources ember dans le projet

•  ember-1.0.0-rc.3.js, handlebars-1.0.0-rc3.js et jquery-1.9.1.min.js dans le répertoire ember-portlet/src/main/webapp/js

Une fois ces ressources copiées, il convient de les déclarer à la portlet. Cette déclaration s’effectue au travers du fichier liferay-portlet.xml en y ajoutant les lignes :

        <footer-portlet-javascript>/js/jquery-1.9.1.min.js</footer-portlet-javascript>
        <footer-portlet-javascript>/js/handlebars.js</footer-portlet-javascript>
        <footer-portlet-javascript>/js/ember-1.0.0-rc.1.js</footer-portlet-javascript>

On va également ajouter dans le fichier main.js déjà présent (créé par défaut par Liferay), la déclaration de l’application Ember.js, plus quelques petites subtilités permettant de valider le fonctionnement d’Ember.js :

  App = Ember.Application.create({
    rootElement: $('section#portlet_emberportlet_WAR_emberportlet')
  });

  App.ApplicationView = Ember.View.extend({
    click: function(evt) {
      alert("Well done ! En plein sur la View Ember de la portlet !");
    }
  });

  App.ApplicationController = Ember.Controller.extend({
    templateName: 'Ember portlet',
    people: [
      {firstName: "Kitien", lastName: "Laroutte"},
      {firstName: "Sophie", lastName: "Fonsec"},
      {firstName: "Igor", lastName: "Saherseize"}
    ]
  });

Le point le plus important (et peu documenté…) est que l’on initialise l’application en lui passant un ‘rootElement’ correspondant au contenu de la portlet. Cela permet de limiter et de positionner les actions sur le DOM effectuées par le framework, qui est ainsi restreint au fragment de page servi par la portlet.

Le reste est assez standard :

• On crée une vue, dans laquelle on définit un événement sur le clic,
• On crée un contrôleur qui se contente pour le moment de définir des données pour affichage dans la JSP…

Rien de très dynamique pour le moment.

vous pouvez alors modifier votre fichier view.jsp de la façon suivante :

<%@ taglib uri="http://java.sun.com/portlet_2_0" prefix="portlet" %>

<portlet:defineObjects />

<script type="text/x-handlebars">

    <h3>{{templateName}} </h3>
    <ul>
        {{#each people}}
            <li>Hello {{firstName}}</li>
        {{/each}}
    </ul>
</script>

Après déploiement de la portlet par un mvn -Pember-liferay clean package liferay:deploy et placement dans une page du portail, on obtient la vue de la liste des personnes déclarées précédemment.

Et un clic sur le fragment de page affichant la portlet produit l’affichage d’une boîte d’alerte.

Il est maintenant temps d’aller un cran plus loin !

Service Liferay et JSON

Liferay est un portail offrant une architecture de services particulièrement ouverte. On bénéficie ainsi de nombreux services SOAP ou REST/JSon permettant de manipuler les principaux objets créés au travers du “service builder”.

Pour consulter (et tester !) ces services JSON, il suffit de se rendre sur la page suivante de son portail local :

http://localhost:8080/api/jsonws

L’appel suivant, une fois les valeurs de repositoryId et de token d’authentification fixés permet par exemple de récupérer les fichiers stockés dans le répertoire de la bibliothèque :

http://localhost:8080/api/secure/jsonws/dlapp/get-file-entries?repositoryId=<repoId>&folderId=0&p_auth=<token secu>

On va donc mettre à profit cette capacité pour construire une petite interface permettant de lister les répertoires de la bibliothèque Liferay et les fichiers qu’ils contiennent.

C’est beau la mécanique Ember !

Dans toute application Ember.js, l’essentiel de l’interface et de la cinématique applicative est réparti entre les fichiers HTML et Javascript. Les deux sont intimement liés et doivent normalement s’aborder simultanément, ce qui est assez difficile dans le cas d’un post de Blog, vous en conviendrez… On va donc commencer par s’intéresser à la partir JSP de notre portlet. Pour cela, il convient de remplacer le contenu de view.jsp par le code suivant :

<%@ page import="com.liferay.portlet.documentlibrary.model.DLFolderConstants" %>
<%@ page import="com.liferay.portal.kernel.util.WebKeys" %>
<%@ page import="com.liferay.portal.theme.ThemeDisplay" %>
<%@ page import="com.liferay.portal.security.auth.AuthTokenUtil" %>

<%@ taglib uri="http://java.sun.com/portlet_2_0" prefix="portlet" %>
<%@ taglib prefix="liferay-portlet" uri="http://liferay.com/tld/portlet" %>

<portlet:defineObjects />
<%
    String auth= AuthTokenUtil.getToken(request);
    ThemeDisplay themeDisplay = (ThemeDisplay) request.getAttribute(WebKeys.THEME_DISPLAY);
    long defaultRepoId = DLFolderConstants.getDataRepositoryId(themeDisplay.getScopeGroupId(), DLFolderConstants.DEFAULT_PARENT_FOLDER_ID);
%>

<script language="javascript">
     var repoId = <%=defaultRepoId%>;
</script>

<script type="text/x-handlebars">
    <div id="selector">
        <div id="file-entries-frm">
            <b>Select File Directory: </b>
            {{view Ember.Select
            contentBinding="App.fileDirectoriesSelector.content"
            optionLabelPath="content.folderName"
            optionValuePath="content.id"
            valueBinding="App.fileDirectoriesSelector.selectedFolderId"
            prompt="Select a folder :"
            }}
        </div>
    </div>
    <hr/>
    <div id="filelist">
        {{view App.FileListView}}
    </div>
</script>

<script type="text/x-handlebars" data-template-name="filelist">

    <div id="file-entries-content">
        <div id="file-entries">
            <ul>
                {{#each App.fileEntriesController}}
                <li>
                    <span>{{size}} octets</span>
                    <h3>{{name}}-{{title}}</h3>
                    <p>{{description}}</p>
                </li>
                {{/each}}
            </ul>
        </div>
    </div>

</script>

Évidemment, ce code, même assez concis mérite quelques explications. Explorons le ligne par ligne :

• Lignes 11 à 19 : Un premier point à résoudre, purement Liferay, consiste à récupérer l’identifiant du repository par défaut du portail.On doit pouvoir faire mieux, mais cette partie de la JSP n’existe que pour cela…
• Lignes 21 : On pose le template d’affichage de la vue Ember. Ce template ne dispose pas d’attribut data_template_name (on peut aussi fixer cette attribut à “application”).
• Ligne 25 : Introduction d’un sélecteur Ember avec toute la magie de ce framework ! Ainsi on binde non seulement les valeurs affichées sur une variable Javascript (contentBinding), mais également le résultat d’une action de sélection (valueBinding). Tout cela sera plus clair en analysant le fichier Javascript
• Ligne 35 : On intègre la vue définie par App.FileListView. On verra que cette vue s’appuie sur le template défini en ligne 40
• Ligne 45 : On utilise les capacités de boucle du framework pour afficher autant de blocs HTML qu’il y a de fichiers présents dans le répertoire sélectionné. Libre à vous d’afficher d’autres informations, liées à l’objet App.FileEntry

Comme déjà précisé plus haut, le seul fichier JSP est largement insuffisant pour comprendre la mécanique Ember, l’essentiel de l’application étant dans le fichier javascript. Pour cela, on va modifier le fichier main.js pour qu’il contienne le code suivant :

/**************************
* Application
**************************/
var App;

App = Ember.Application.create({
  rootElement: $('section#portlet_emberportlet_WAR_emberportlet'),
  LOG_TRANSITIONS: true
});

/**************************
* Models
**************************/
App.FileEntry = Em.Object.extend({
  companyId: null,
  createDate: null,
  custom1ImageId: null,
  custom2ImageId: null,
  description: null,
  extension: null,
  extraSettings: null,
  fileEntryId: null,
  fileEntryTypeId: null,
  folderId: null,
  groupId: null,
  largeImageId: null,
  mimeType: null,
  modifiedDate: null,
  name: null,
  readCount: null,
  repositoryId: null,
  size: null,
  smallImageId: null,
  title: null,
  userId: null,
  userName: null,
  uuid: null,
  version: null,
  versionUserId: null,
  versionUserName: null
});

/**************************
* Views
**************************/
App.FileListView = Ember.View.extend({
  templateName: 'filelist',
  classNames: ['filelist']
});

App.FileDirectoriesSelector = Ember.Object.extend({
  selectedFolderName: "",
  selectedFolderId: -1,
  selectedFolderIdChanged: function(){
  App.fileEntriesController.loadFileEntriesBySelect();}.observes('selectedFolderId')
});

App.fileDirectoriesSelector = App.FileDirectoriesSelector.create({
  content: getFolders()
});

function getFolders() {
  var url = 'http://localhost:8080/api/secure/jsonws/dlapp/get-folders/repository-id/%@/parent-folder-id/0?p_auth=%@'.fmt(repoId,Liferay.authToken);
  // Push Default folder by default
  folders = Ember.ArrayProxy.create({content:[Ember.Object.create({folderName: "Root Folder", id: 0})]});
  $.getJSON(url,function(data){
    $(data).each(function(index,value){
      folders.addObject(Ember.Object.create({folderName: value.name, id: value.folderId}));
    })
  });
  return folders;
  }

/**************************
* Controllers
**************************/
App.fileEntriesController = Em.ArrayController.create({
  content: [],
  loadFileEntriesBySelect: function() {
    var me = this;
    if (App.fileDirectoriesSelector.selectedFolderId != null) {
      var url = 'http://localhost:8080/api/secure/jsonws/dlapp/get-file-entries?repositoryId=%@'.fmt(repoId);
      url += '&folderId=%@&p_auth=%@'.fmt(App.fileDirectoriesSelector.selectedFolderId, Liferay.authToken);
      $.getJSON(url,function(data){
        me.set('content', []);
        $(data).each(function(index,value){
          var t = App.FileEntry.create({
            description: value.description,
            extension: value.extension,
            largeImageId: value.largeImageId,
            mimeType: value.mimeType,
            modifiedDate: value.modifiedDate,
            name: value.name,
            readCount: value.readCount,
            size: value.size,
            smallImageId: value.smallImageId,
            title: value.title,
            userId: value.userId,
            userName: value.userName
          });
          me.pushObject(t);
        })
      });
    }
  }
});

Voici quelques explications concernant le contenu du fichier javascript :

• Lignes 6 : On déclare l’application Ember. Le premier paramètre permet de restreindre la portée du framework à la section définissant la portlet, le second est optionnel et permet de logguer les transitions dans la console Javascript (peu utile dans notre cas où l’unique transition amène sur la page par défaut).
• Ligne 14 : On définit un objet Ember.js qui est le symétrique de l’objet manipulé par Liferay pour décrire les FileEntry. J’y ai mis tous les attributs, même si la plupart d’entre eux ne sont pas utilisés ici.
• Ligne 46 : La vue intégrée dans le template par défaut est définie et pointe vers le template du même nom. Ember permet de faire plus court en utilisant des conventions de nommage. Mais pour être plus clair, j’ai préféré faire de la sorte.
• Ligne 51 à 58 : On déclare ici un objet qui va jouer un rôle prépondérant dans le fonctionnement de l’application. Il s’agit en effet de la vue javascript du sélecteur de répertoire affiché dans le template. Cette déclaration se fait en deux temps : par extend() puis par create, car on utilise un ‘observateur’ sur la variable selectedFolderId qui ne peut porter que sur un objet étendu (Attention, cette information est très mal documentée et n’est valable que sur les distributions récentes d’Ember.js). A noter également que la variable content s’appuie sur le retour d’une fonction
• Ligne 62 : Cette fonction s’appuie sur les services REST de Liferay et sur JQuery pour construire la liste des répertoires présents dans la bibliothèque Liferay de premier niveau.
• Ligne 71 : On crée un contrôleur Ember.js qui va contenir le résultat de l’appel aux services REST Liferay listant les fichiers présents dans le répertoire passé en argument. Ce contrôleur pourra ensuite être exploité dans le template d’affichage filelist

En synthèse, selectedFolderId est directement lié à la valeur du sélecteur HTML et toute modification de sa valeur provoquera un appel à la fonction liée à la propriété selecteFolderIdChanged. Elégant, non ?

Pour teminer et uniquement pour des aspects purement esthétiques, on va utiliser le fichier main.css suivant, qui va décorer les boites correspondant à chacun des fichiers trouvés :

  #p_p_id_emberportlet_WAR_emberportlet_ {
    font-family: 'tahoma', sans-serif;
    background: #eeeeee;
  }

  #file-entries-frm {
    margin: 0 auto 15px auto;
    text-align: center;
  }

  #file-entries-content {
    border: 1px solid blue;
    margin: 0 auto;
  }

  #file-entries ul {
    padding: 0;
    border: 1px solid #999999;
  }

  #file-entries ul li {
    text-align: left;
    margin: 0;
    padding: 10px;
    list-style: none;
    border-bottom: 1px solid #999999;
    min-height: 50px;
    background: #eeeeee; /* Old browsers */
    background: -moz-linear-gradient(top, #eeeeee 0%, #dddddd 100%); /* FF3.6+ */
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#eeeeee), color-stop(100%,#dddddd)); /* Chrome,Safari4+ */
    background: -webkit-linear-gradient(top, #eeeeee 0%,#dddddd 100%); /* Chrome10+,Safari5.1+ */
    background: -o-linear-gradient(top, #eeeeee 0%,#dddddd 100%); /* Opera 11.10+ */
    background: -ms-linear-gradient(top, #eeeeee 0%,#dddddd 100%); /* IE10+ */
    background: linear-gradient(top, #eeeeee 0%,#dddddd 100%); /* W3C */
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#eeeeee', endColorstr='#dddddd',GradientType=0 ); /* IE6-9 */
  }

  #file-entries ul li:hover {
    background: #cfe7fa; /* Old browsers */
    background: -moz-linear-gradient(top, #cfe7fa 0%, #6393c1 100%); /* FF3.6+ */
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#cfe7fa), color-stop(100%,#6393c1)); /* Chrome,Safari4+ */
    background: -webkit-linear-gradient(top, #cfe7fa 0%,#6393c1 100%); /* Chrome10+,Safari5.1+ */
    background: -o-linear-gradient(top, #cfe7fa 0%,#6393c1 100%); /* Opera 11.10+ */
    background: -ms-linear-gradient(top, #cfe7fa 0%,#6393c1 100%); /* IE10+ */
    background: linear-gradient(top, #cfe7fa 0%,#6393c1 100%); /* W3C */
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#cfe7fa', endColorstr='#6393c1',GradientType=0 ); /* IE6-9 */
  }

  #file-entries ul li span {
    float: right;
    font-size: 8pt;
    color: #888888;
  }

  #file-entries ul li img {
    float: left;
    margin: 0 10px 0 0;
    width: 48px;
    height: 48px;
  }

  #file-entries ul li h3 {
    font-size: 11pt;
    margin: 0;
  }

  #file-entries ul li p {
    margin: 0;
    font-size: 10pt;
  }

Lancement de la compilation et du déploiement

Reste maintenant à compiler et déployer le tout, par une commande du type :

  mvn -Pemberlf package liferay:deploy

ATTENTION, la portlet est relativement simpliste et ne fonctionne que pour un utilisateur loggué. Donc, placez la sur une page secondaire et identifiez-vous avant d’y accéder.
Pour que la démonstration soit pertinente, il faut également que la bibliothèque contiennent des répertoires et des documents, histoire d’avoir des choses à afficher !

Vous devez dorénavant obtenir une portlet du type :

Pour information, voici la vue Back-office standard de Liferay sur ma bibliothèque de document, pour le même répertoire :

En moins de 200 lignes de code et avec une lisibilité très correct, on arrive donc à mettre en place un fonctionnement AJAX évolué sans gros effort. C’est beau le Javascript, non ?

Lors de cet Ippevent, nous n’aurons pas 1 mais 3 speakers :

• Sébastien Letélié (dévelopeur Web depuis 15 ans et CTO chez Intuitive) nous fera fera une démo de live coding sur AngularJS
• Thierry Lau (Développeur front end chez Sfeir) fera une présentation sur les modules $http et $resource du Framework.
• Et enfin Patrick Aljord (indépendant et ancien d’IsoHunt) fera une intervention sur AngularJS et Firebase

Quarante cinq mois intenses

Je suis arrivé chez Ippon en Septembre 2009 avec le rôle de “Manager Technique en charge de la capitalisation des savoirs faire”. En plus d’un poste de consultant classique je disposais d’un mi-temps pour recenser l’expertise au sein de la société et communiquer sur cette expertise pour la faire connaître à l’extérieur et contribuer au rayonnement de l’entreprise. Deux rôles pour le même poste, en somme.
Dans mon premier rôle de consultant au sein du pôle conseil, j’ai été servi : près de 20 missions en 3 ans et demi comportant des prestations critiques (audit technique ou d’architecture) ou décisives (conseil au choix d’outils ou de frameworks). Il s’est donc agit en majorité de conseil à haute valeur ajoutée des missions courtes aux enjeux importants : ouverture de compte, décisions engageantes.
Dans mon deuxième rôle, Ippon m’a laissé carte blanche, me permettant d’expérimenter un certain nombre de choses. Pour mener à bien cette tâche de capitalisation j’ai repris en main le blog (en incitant et aidant mes collègues à contribuer), créé et animé les comptes Twitter et Facebook de la société et testé des approches différentes pour le recrutement des nouveaux collaborateurs.
L’année 2011 a été celle de la création des Ippevents qui rencontrent toujours un beau succès (et qui permettent à des consultants Ippon de faire leur premières armes de conférencier) et en 2012 mes premier pas de speaker dans les Jugs puis à Devoxx.

Les projets Open Source et le JCP

C’est grâce à Ippon, que je me suis rendu à Devoxx en novembre 2010 et que j’ai rencontré mes premiers contacts chez Red Hat. Soucieux de rester crédible dans mes missions de conseil, je cherchais un moyen de garder le contact avec le développement (tâche difficile quand on effectue des missions courtes sur des aspects conseils) et la contribution open source m’est apparue comme la meilleure solution pour ne pas me rouiller sur le développement. C’est ainsi qu’avec le soutien d’Ippon je commençais à travailler sur le projet Seam Social devenu Agorava depuis, et participer au JCP sur CDI 1.1 et une tentative de JSR avortée avec Java Social (JSR 357)

Alors pourquoi partir ?

Tout cela aurait pu durer encore longtemps si je n’avais pas eu cette opportunité qui fait partie des quelques rares susceptibles de me faire quitter Ippon. En fait, c’est plus le monde du service (dans lequel j’évolue depuis 17 ans) que je quitte, qu’Ippon Technologies pour aller donner dans le développement open source professionnel.
Et une chose est sûre, sans Ippon je n’aurai certainement pas pu accéder à cette nouvelle carrière. Les nombreuses missions internes et externes m’ont permis d’apprendre plein de choses et de nouer les contacts qui me permettent aujourd’hui de tourner cette page. J’ai clairement bénéficié de l’excellence d’Ippon pour décrocher ce job.

Place à prendre

Je m’en vais donc vers de nouvelles aventures en laissant un poste vacant au sein d’Ippon Technologies. Ce poste de manager en charge de la capitalisation des savoir faire possède suffisamment de facettes pour que chacun s’y retrouve. Il comporte quelques figures imposées pas forcément désagréables (blog, organisation des Ippevents) et pas mal de figures libres (contribution à des projets Open Sources, relation avec la communauté, organisation d’ateliers internes, etc…) et un mi-temps pour le faire. Si tout ça vous tente (et j’espère vous avoir donné envie) contactez Julien Dubois (jdubois {at} ippon.fr) notre directeur du pôle conseil.
Pour ma part, je dis “au revoir Ippon et merci !”

Cette nouvelle édition a les mêmes buts que les précédentes :

• Nous permettre de recruter des gens qui savent réfléchir et qui savent coder
• Tout en ayant un support amusant, aussi bien pour les gens qui postulent que pour nous-mêmes (oui, faire passer des entretiens c’est dur pour nous aussi…)

L’esprit reste donc le même, avec quelques nouveautés, par exemple le premier challenge est cette fois-ci en JavaScript !

Rappelons tout de même quelques règles pour les participants :

• Notre but est de recruter des personnes de tout niveau : le challenge n’est pas fait pour être impossible, et n’est pas réservé à des “experts” particuliers
• Vous pouvez être “malins”, comme sur le challenge précédent, et donc contourner les obstacles : en fait, nous sommes intéressés par vos solutions (et nous avons déjà eu des solutions surprenantes lorsque nous avons fait les tests en interne…)
• N’oubliez pas, en postulant, de décrire vos solutions ou d’envoyer votre code source !
• Enfin, une règle de bonne conduite : laissez les autres jouer… Si vous avez trouvé la solution, ne la publiez pas sur Twitter ou sur votre blog dans les 5 minutes, même si vous êtes très contents de vous… Ce n’est pas un concours de vitesse, ni un concours où il faut être le premier (d’ailleurs nous avons plus d’un poste à pourvoir !)

Sur ce :

• Le code sera disponible sur ce repository Github https://github.com/ippontech/IpponRecrute3 aujourd’hui (Jeudi 18 Avril 2013) à 14h00. Bon jeu !

Pour moi, il s’agissait d’une API de client lourd destinée à faire évoluer l’antédiluvienne techno Swing, pour contrer celle développée par Eclipse (RCP) SWT (c’est moi qui suppute). Or, renseignement pris, il s’avère que JavaFX se positionne dans le secteur RIA et les plateformes mobiles par l’intégration à Java ME. Donc, il faut bien admettre que cela ressemble à un projet de bon aloi, ambitieux et suivi. Quel est le problème, alors ? Je me suis mis à creuser dans les possibilités de la bête.

Comme pas mal de technos Java (souvenez-vous des EJB 2…), JavaFX a connu une première mouture partiellement avortée. A l’époque, elle nécessitait une étape de précompilation qui est aujourd’hui abandonnée pour une solution “tout Java”. JavaFX 1 disposait également d’un langage propre, JavaFX Script, abandonné également. Pendant un moment, le projet Visage a prétendu prendre la relève ; il existe également GroovyFX et ScalaFX, pour les amateurs. Actuellement, la version officielle est JavaFX 2, et une version 3 est annoncée pour cette année 2013.
Enfin, NetBeans intègre les outils nécessaires à son exploitation, et un Scene Builder est disponible pour les autres. Il y aura aussi un plugin IntelliJ IDEA, incessamment (il est encore immature, d’après ce que l’on m’a dit).

OK, voilà pour la partie historique. Alors, qu’avons-nous là ? Entre nos mains, une solution IHM événementielle multiplateforme (desktop, web) intégrant le skinning CSS pour la personnalisation du rendu et supportant HTML pour le formatage des textes. Il y a aussi des effets en veux-tu en voilà (animations, transformations, transitions animées).
Pas de dépendances volumineuses en exécution, donc, sur Java SE 7 qui devrait (n’est-ce pas) être votre JVM par défaut maintenant. Du côté des composants (UI Controls), on peut leur appliquer des layouts et tous les effets précités.
On dispose en outre d’une extensibilité poussée. D’ailleurs, JFXtras (très inspiré mais relativement étroit d’esprit) et DataFX (qui fournit un effort d’abstraction des sources de données) ne sont qu’un exemple parmi les nombreux projets avancés sur le sujet – Nan, j’déconne, en fait je n’en ai pas trouvé tant que ça

Voici un tour des composants de base de JavaFX :

Label, Button, Radio Button, Toggle Button, Checkbox, Choice Box, Text Field, Password Field, Scroll Bar, Scroll Pane, List View, Table View, Tree View, Combo Box, Separator, Slider, Progress Bar and Progress Indicator, Hyperlink, Tooltip, HTML Editor, Titled Pane and Accordion, Menu, Color Picker, Pagination Control…

De plus, JavaFX propose aussi une API de graphiques (Charts) complète, fondée sur du SVG, de quoi rendre Birt jaloux (ou pas).

Tout cela, mesdames et messieurs, pouvant coexister dans des applications Swing (par le biais d’une Scene)… Et, j’ai envie de dire : c’est bien la moindre des choses ! Parce que finalement, à mon avis, c’est ici que se trouve le “noeud d’adoption” de la technologie. Franchement, qui a envie de faire du Web avec JavaFX alors qu’il existe des frameworks web ultra poussés avec des composants surpuissants (PrimeFaces, si tu me regardes…) ?? Il n’importe donc que de savoir si JavaFX a une valeur ajoutée en terme de productivité par rapport à Swing, en se limitant aux clients lourds, donc. Sans cela, qui en voudrait ?

J’ai relevé en gras, dans l’encadré ci-dessus, tous les éléments qui me semblent nouveaux, hormis l’utilisation optionnelle du FXML (avec binding tout de même, et l’utilisation des annotations Java). Honnêtement ? C’est pas vraiment la révolution… Je ne sais pas vous, mais moi j’attends BEAUCOUP plus d’une librairie de composants ; il faut dire que j’ai fait du Flex, aussi… Pour moi, si l’API GUI de Java doit évoluer, c’est en fournissant AU MINIMUM des composants de la trempe de ce que l’on trouve sur le web. Ce n’est pas comme si les clients lourds avaient le vent en poupe, n’est-ce pas ?.. Il faudrait donc qu’ils fassent montre de capacités inédites pour percer, CQFD.

Si vous voulez ajouter facilement (et rapidement) des éléments de data visualisation à vos applications existantes, vous serez heureux d’adopter JavaFX. Je ne sais même pas si les graphiques peuvent être rendus suffisamment interactifs, d’ailleurs.  Mais sinon ? Je ne vois pas comment justifier la courbe d’apprentissage d’une nouvelle technologie (in cauda venenum, il y aura forcément de la charge de débugage), simplement pour dire qu’on a arrêté de faire du Swing (de l’AWT, d’accord ; on doit poser des limites à la résistance au changement).

Ce qu’il manque à Swing “out of the box” (SwingX est mort, mais il reste JGoodies ou ASC Suite – c’est payant), ce sont des composants avancés (un pauvre composant de saisie de dates/calendrier ; des champs auto-complétés, auto-validés ; des tables auto-paginés, auto-filtrés, auto-triés ; l’intégration de cartes géographiques ; des listes de sélection liées ; des graphes, des mindmaps ; ou que sais-je encore, clef en main). C’est quand même un comble que les interfaces utilisateur distantes soient aujourd’hui plus riches que les interfaces locales… Or, l’offre de JavaFX me semble encore inférieure à ce qui peut être fait avec HTML5. C’est la fin de la discussion, je pense… JavaFX est à la traîne, et je n’ai rien trouvé d’annoncé pour la version 3 qui remédierait à cela (Ah, il y a l’intégration de la 3D au menu – pourquoi pas ?).
[mode_perfide]A ce compte-là, on pouvait très bien se contenter des bibliothèques de composants Swing externes développées depuis de longues années. Mais c’est peut-être bêtement un problème de copyright…[/mode_perfide]

Conclusion : oui, JavaFX est décevant, non content d’avoir eu du mal à décoller. Et compte tenu des besoins en termes d’applications client lourd ces dernières années, il est tout à fait normal que son adoption soit médiocre. La tentative de vente forcée avec le JDK 7 n’y fera rien, à mon avis.
JavaFX n’a pas un problème de visibilité (des livres existent, notamment chez Apress, entre autres) mais un problème de productivité, comme on l’a vu. La pénurie de profils expérimentés risque de faire encore longtemps défaut.
C’est moche, je sais.

PS : Y aurait-t-il des volontaires pour démarrer un projet “PrimeFX” ? Levez le doigt ; personne ?..

Le changement est toujours  compliqué, surtout après des années de modèle prédictif, et ces 6 mois ont été riches en enseignement. Je pense refaire un billet pour faire le point sur le passage à l’agilité pour toute la DSI et analyser si l’objectif affiché est atteint (et à quel prix). Pour le moment,  je me contenterai de réaliser un billet sur la vision d’un membre d’une team scrum, des quelques pièges que j’ai pu rencontrer et dans lesquels j’espère ne plus tomber.

• Le Product owner tu écouteras et tu motiveras

On ne le répétera jamais assez mais scrum ne rime pas avec : “aucune spécification”. C’est même une composante importante. Tout ce que scrum dit c’est qu’il n’existe aucun format imposé et qu’elles ne doivent pas impérativement être complètes ni définitives avant le lancement du développement.

Notre projet couvre un besoin nouveau pour le client et nécessite un travail important de conception.  Le product owner (PO) n’a ni le recul ni le temps nécessaires pour nous donner des spécifications claires et complètes pour démarrer.  Après coup, cette situation n’est pas insurmontable et l’important est de rendre au PO ce qui appartient au PO. Il ne faut pas que l’équipe prenne la responsabilité des spécifications d’une fonctionnalité,  ce n’est pas notre application et nos décisions seront forcément incomprises voire critiquées. Et sans l’appui du PO, les dérives peuvent être nombreuses.

Il est important de remettre le PO au centre des décisions, cela lui redonne de la confiance et ressoude l’équipe, augmentant ainsi les chances de réussite du projet.

• Avec le Scrum master, la communication tu développeras

Scrum met l’accent sur la communication au sein de l’équipe et la définit comme composante principale de réussite du projet. Le daily scrum meeting est là pour rendre compte des tâches en cours, réalisées ou restantes à faire et participe à cette communication.

Dans notre cas, le scrum master (SCM) n’est pas staffé à 100% sur le projet et gère plusieurs autres projets en même temps. Dans cette configuration, il est important que l’équipe remonte au SCM les alertes potentielles du sprint et en particulier les tâches incertaines pouvant dériver. Ce sont par exemple des tâches nouvelles pour l’équipe, jamais réalisées par celle-ci. Ou encore une tâche d’une durée importante, supérieure à une journée. Ces tâches peuvent être sous-estimées et l’augmentation peut entraîner la dérive du Sprint. On peut l’observer facilement sur un Sprint Burndown Chart, avec une courbe qui stagne et ne décroit plus.

Pour les repérer facilement, nous les affichons sur le whiteboard avec des post-it de taille plus importante permettant au SCM de les suivre facilement. Augmenter la communication avec le SCM lui permet de suivre sereinement le projet et de pouvoir réaliser correctement son rôle de protection de l’équipe.

• Les incertitudes, tu élimineras

On l’a vu, les incertitudes sont une composante importante dans la probabilité de dérive d’un sprint. Il faut pouvoir les estimer et pour cela, il faut définir ce qui est une tâche incertaine et ce qui ne l’est pas.

Tout d’abord, Il est important de faire évoluer l’évaluation de ses tâches pendant le déroulement des sprints. Une tâche réalisée en 2h la première fois prendra nettement moins de temps la seconde fois. Tenir ainsi ses tâches à jour permet de garder une évaluation la plus juste possible et une estimation de sprint cohérente.

Les tâches incertaines ne peuvent être évaluées aisément. Elles peuvent être reconnaissables quand une évaluation ne fait pas le consensus de l’équipe ou quand une tâche ne peut tout simplement pas être évaluée. Ce sont souvent des tâches jamais réalisées par l’équipe ou mal spécifiées. Dans le deuxième cas, je déconseille fortement de les prendre dans le sprint. Engager son équipe sur quelque chose qu’elle ne maîtrise pas est le meilleur moyen de rater le sprint et de perdre en confiance dans le PO.

Dans le cas des tâches inconnues,  elles doivent être évaluées au possible, prises en compte dans le sprint et suivies de près par l’équipe. Une fois réalisées, elles sortiront de leur statut incertain, pourront être évaluées,  réévaluées et traitées plus sereinement.

Une fois estimées, vient le moment de les réaliser. On peut suivre deux méthodes pour éffectuer ces tâches.  Les résoudre en fin de sprint, après avoir fini l’ensemble des tâches simples ou en tout début de sprint.

Je conseille fortement de les éliminer le plus tôt possible, ne pas remettre au lendemain ce que l’on peut réaliser tout de suite ! Une tâche incertaine peut fortement dériver et mettre en péril le sprint. Les réaliser tôt permet de conserver du temps dans le cas où elle échappe à l’équipe et ainsi permet de garder la possibilité de prendre les décisions nécessaires pour boucler le sprint (retirer une user story, modifier la priorité …). Un deuxième point à ne pas négliger est le stress généré par une tâche qui dérive. Il est beaucoup plus simple de gérer ce genre de tâche en début de sprint que deux jours avant la démo,  quand rien ne fonctionne.

Plus tôt elles sont résolues et plus sereine est l’équipe.

• En continu, tu t’amélioreras et pour cela à 100% tu ne te chargeras pas

La gestion des incertitudes demande une certaine souplesse dans le sprint et une partie de celui-ci peut être conservée pour encaisser une dérive éventuelle. Mais conserver du temps pour les tâches incertaines ne doit pas être la principale priorité.

Scrum prône une constante remise en cause de l’équipe, notamment grâce au sprint review. Une bonne pratique d’amélioration continue consiste à conserver pour chaque sprint une partie du temps alloué à des tâches non dépendantes d’une user story. Ce temps peut être utilisé pour du refactoring, pour améliorer la couverture de test d’une fonctionnalité ou un process de travail. Nous, nous conservons 10% de notre temps (par développeur) à améliorer constamment notre environnement de travail. Dernièrement,  nous avons dépensé ce temps à passer de feuilles Excel partagées à Jira pour la gestion du projet. Excel nous convenait pour la gestion d’un sprint mais le passage à Jira nous a permis d’améliorer le travail collaboratif et le bug tracking.

Nous dépensons aussi ce temps pour améliorer nos build maven, notre couverture de tests, nos montées de versions …

Le chemin vers Scrum est semé d’embûches surtout dans un environnement non préparé pour cette méthode. Le PO est une pièce clef du processus et doit rester maître de l’application. Ne pas prendre de décision à sa place et ne pas hésiter à lui renvoyer tous vos questionnements est une bonne démarche pour conserver le PO dans son rôle.

La communication au sein de l’équipe est importante et le SCM doit être tenu au fait des avancées de l’équipe. On pourra ainsi utiliser tout ce qui est à notre disposition pour qu’il puisse suivre très facilement le bon déroulé du sprint.

L’incertitude au sein du sprint doit être maîtrisée pour plus de sérénité au sein de l’équipe. Conserver une estimation cohérente de ses tâches permet de cibler rapidement ce qui pourrait poser problème. Les résoudre en début de sprint permet d’éviter beaucoup de stress inutile.

Et ne jamais perdre de vue que scrum prône une perpétuelle amélioration de ses processus de travail et qu’il est important de conserver du temps pour les réaliser. Garder 10 % de son temps à réaliser des tâches annexes permet d’augmenter la qualité du projet.

Scrum propose une méthodologie de travail pragmatique qui apporte plus de sérénité au sein de l’équipe. L’équipe ne porte plus seule la responsabilité de l’ensemble des tâches de réalisation d‘un projet et l’environnement de travail est beaucoup plus serein. On peut enfin se recentrer sur ce qu’on fait le mieux, développer, et trouver les meilleures solutions techniques pour que le projet réussisse.

• N’hésitez pas à passer sur notre stand (Stand n°3) pour discuter avec nos experts ou vous renseigner sur nos formations
• Rendez-vous à 14h00 dans la salle Concorde pour participer à la conférence  ’L'Agilité dans la mobilité’ par Alvin Berthelot, Chef de Projet chez Ippon Technologies
• Une dizaine de consultants Ippon seront également présents sur place, dans le cadre de notre participation active aux grands évènements (comme Devoxx ou le futur Devops Day)

En gros, il s’agit d’un framework qui va à la fois gérer la construction et le paramétrage de vos projets, tout en prenant en charge un ensemble de tâches fastidieuses de vos développements Java (comme l’implémentation des accesseurs et des fonctions #toString, #hashCode, etc). En fait, Spring Roo fait plus que de générer du code ; à chaque étape du projet, il propose une aide en ligne contextuelle qui va vous suggérer les actions à réaliser pour avancer. Et là, moi je dis youpi ! Vous pourrez donc, en ligne de commande (intégrée à STS pour ceux qui le veulent), indiquer quelles sont vos entités et leurs données, ainsi que leurs relations. Pour cela, Vous demanderez à Spring Roo d’incorporer les dépendances vers vos couches techniques. Ensuite, vous préciserez quels services vous souhaitez fournir, et leur protocole.

En fin de compte, Spring Roo pourra également générer pour vous, par exemple, les contrôleurs et les vues Spring MVC pour obtenir une interface CRUD prête à l’emploi. En plus elle sera belle, ce qui ne gâche rien ! Comment ? vous vouliez ajouter Spring Web Flow ? Qu’à cela ne tienne, il suffit de demander. Sans oublier de prendre en charge la sécurité, bien entendu Spring Security est supporté… Que demande le peuple ? Pardon ? Vous êtes “tatillon” ? Pas de problème, Spring Roo sait détecter vos modifications et il ne repassera pas derrière vous. On dit même qu’il est intelligent… Brrrrrrr !

Seulement voilà, il y a de grandes chances pour que vous ne connaissiez pas Spring Roo. Et c’est vraiment dommage, je trouve. Moi-même, avant, je ne connaissais pas Spring Roo. Et je ne connaissais pas SpringFuse non plus, d’ailleurs. Je savais, à la rigueur, me servir des archétypes Maven. C’était toujours ça, certes. Ça me permettait de sauver la face, disons.

Alors je codais tout à la main, et je perdais du temps à faire des choses pas drôles, ou à me creuser les méninges pour trouver comment intégrer les différentes briques de mes applications dans des environnements toujours différents. Je ne me concentrais pas sur le modèle et le code métier. Je n’étais pas non plus capable de sortir de mon chapeau une application exécutable en quelques jours, dont je pouvais ensuite me servir tout naturellement comme base de développement. Mes clients et utilisateurs étaient tristes aussi, du coup, parce qu’ils devaient attendre pour avoir une idée de ce que je faisais dans mon coin. Mais ça, c’était avant.

Faites moi(vous) plaisir, essayez Spring Roo…

Pour aller plus loin (et comprendre mieux) :
http://blog.axones.com/index.php/2012/02/14/spring-roo-developpez-en-roue-libre/
http://blog.valtech.fr/2010/09/23/tutoriel-spring-roo/
http://www.touilleur-express.fr/2010/09/09/spring-roo/
http://today.java.net/article/2012/06/19/spring-roo-and-webflow-ken-rimple-co-author-spring-roo-action

Si l’une de ses formations vous intéresse, vous n’avez qu’à écrire à formation@ippon.fr pour vous inscrire ou simplement demander plus d’informations.

• JSF2/Primefaces
• Date : du 16 au 18 Avril 2013
• Prix : 1650€ HT
• Descriptif : Cette formation est la formation officielle PrimeFaces proposée par Prime Teknoloji. Elle est conçue par Çağatay Çivici, le fondateur et développeur principal de PrimeFaces, les supports de cours (powerpoint) seront donc en anglais.

• Spring
• Date : du 24 au 26 Avril 2013
• Prix :  1490€ HT
• Descriptif : Si une configuration Spring simple est à la portée de tous, avoir une architecture Spring correcte, en comprendre le fonctionnement interne et connaître les fonctionnalités avancées du framework sont des tâches nettement plus ardues.
  L’objectif de cette formation est de donner les bonnes bases pour comprendre les principaux aspects de Spring, de manière à ce que les participants soient capables de :
  • développer une application Spring complète (persistance, métier, validation, transactions, sécurité, Web, Ajax…)
  • comprendre le fonctionnement interne de Spring et donc être autonomes lorsqu’un bug ou une situation anormale se produit
  • avoir intégré la philosophie de développement Spring, afin de pouvoir facilement prendre en main un sous-projet ou une fonctionnalité Spring qu’ils ne connaissent pas encore

• MuleESB
• Date : du 15 au 17 Mai 2013
• Prix : 1490€ HT
• Descriptif : Mise en oeuvre d’un ESB avec Mule: Structurez, partagez vos services et vos flux d’informations à l’aide un Bus Open Source accessible
  

• Etat de l’art mobile
• Date : 23 Mai 2013
• Prix : 550€ HT
• Descriptif : Solutions natives, web ou hybrides, architectures, ergonomies, marketplaces, tout savoir pour plonger dans l’univers de la mobilité

• JS Expert
• Date : du 29 au 31 Mai 2013
• Prix : 1490€ HT
• Descriptif : Javascript, uniquement pour experts ! Venez (re)découvrir le coeur du langage, ses APIs et les frameworks incontournables. Une vraie réflexion sur les applications de demain.

“Les API JS avec HTML5, JS avancé, Architectures associées”

• Etat de l’art du Web
• Date : 6 Juin 2013
• Prix : 550€ HT
• Descriptif :  Standards, frameworks, CMS, portails et architectures mis à nu pour alimenter votre veille technologique

• Liferay 
• Date : du 12 au 14 Juin 2013
• Prix : 1490€ HT
• Descriptif : Liferay: administration et développement. Liferay est une référence dans les solutions de portail. Maîtrisez-en les subtilités de développement et d’administration

Ippon est bien évidemment présent sur Devoxx sur le stand M6  – Ippon Technologies / Atomes .

Venez poser directement vos questions aux responsables de l’offre Formation.

Ne cherchez plus ! Cet Ippevent est fait pour vous. Présenté par David Pilato Technical advocate chez ElasticSearch,  celui-ci vous présentera au cours de la soirée pourquoi et comment il est passé de la recherche SQL à Elasticsearch en détaillant les apports de ce moteur par rapport à une solution pure Lucene :

• Pourquoi Elasticsearch ?
• L’indexation
• La recherche
• La collecte de données (rivers)
• Les facettes et le principe de navigation par facettes
• La scalabilité horizontale
• L’analyse et le mapping
• La percolation
• La communauté

Pour vous inscrire, rien de plus simple, il vous suffit d’utiliser le bandeau ci-dessous

Bio du speaker

David Pilato est “technical advocate” chez Elasticsearch.com, après avoir passé les deux dernières années à promouvoir le projet open-source Elasticsearch, dont il anime la communauté française. Fidèle des JUG, il a donné une conférence sur le sujet lors de la première édition de Devoxx France en avril 2012 et sillonne désormais les routes de France pour partager sa passion.

Il a implémenté un certain nombre de plugins pour l’écosystème Elasticsearch (Rivers RSS, FileSystem et DropBox, Factories Spring).

Il a également implémenté Elasticsearch pour plusieurs projets, dont une importante administration française. Il est le co-auteur du projet open-source Scrutmydocs.org basé sur Elasticsearch qui permet de disposer d’un moteur de recherche “à la google” des documents de vos disques durs.

@dadoonet et @ElasticsearchFR sur Twitter

dadoonet sur GitHub

Adding more cache

To increase application performance, one of the classic solutions is to add more cache. We already have a cache configured in the application, it is on the JpaVetRepositoryImpl.

We are going to generalize this cache on 2 different parts of the application:

• Using the Spring Cache abstraction, like on the JpaVetRepositoryImpl, to cache frequently used business methods. The JpaOwnerRepositoryImpl.findByLastName() method is a perfect candidate for this: doing a “like” clause is very slow on a database, and people’s last names do not change frequently. So we decided to cache this result for 60 seconds.
• Using the Hibernate second level cache: we have cached most entities and collections of the application, and re-coded parts of the application to use this cache. As a result, using Hibernate’s “showSql=true” parameter, we can see that the application does not execute any unnecessary SQL request (as long as there is no write, requests are only executed once).

You can see those changes in the following commit:

[Source code]

Our final result goes up to 1225 req/sec. That’s only a 15% performance boost, but please note that we have a very small database, and that it is running locally. On a real-world system, the improvement should be better, especially for the JpaOwnerRepositoryImpl.findByLastName() method.

Extreme testing

We decided to do an extreme testing session, in order to see if we really stabilized the application (using Tomcat’s NIO connector and going stateless, specifically).

So we ran our test again on the Macbook, still with 500 threads, but this time we let it run until we had 100 000 user sessions.

Our results are extremely good:

• No HTTP error at all
• Memory stays at the same level, no matter how many users are using it
• The application runs smoothly, and stabilizes at 1565 req/sec !!

This is, of course, an excellent result.

Conclusion and final thoughts

During those five days, we have gone through the classical steps we use at Ippon Technologies when auditing a project:

• Creating a “real” test case
• Removing data in the HTTP Sessions
• Removing the JVM locks
• Tuning the persistence layer
• Adding a cache

For each of these steps, JMeter and YourKit were our best tools to stress test the application and monitor how it responded to the test.

Of course, more work could have been done on JVM tuning, and on database tuning (but changing the database schema is outside the scope of this article).

At the beginning of the tests, we had to increase our heap memory size to 1 Gb, and could only serve 548 req/sec, with some HTTP errors. After completing our audit, we are now back to 128 M, and can serve 1225 req/sec with no error at all. We expect those results to be even better on a real server, with many cores and threads, and where removing JVM locks will have a more significant impact.

We also had a great improvement in the application stability, having 0 errors and 1565 req/sec with 100 000 users on our “extreme tests”. The application is now ready to handle a lot of users without any trouble.

Last but not least, we have switched the persistence layer from JDBC to JPA: a quick look at the code shows how much clearer and smaller the JPA code is. And the Spring Data JPA code is even clearer and smaller. It’s great to see that quality code can also be more performant than low-level, hard-to-code classes.

[edit]

You can find the other episodes of this series here : part 1, part 2, part 3 and part 4.

Vous avez raison. Dans cet Ippevent présenté par Michael Zam(fondateur et CTO de Karmicsoft), venez rencontrer les cloudjects, une nouvelle espèce d’objets vivant dans le cloud, investie pour matérialiser vos rêves en sprints de 2 minutes, capable de simuler le fonctionnement des modèles métier objet, domptable par clic, scriptable à la volée et testable unitairement, habillée avec une GUI à la mode façon RIA, tout justement taillée pour la gestion des données complexes.

À bord du vaisseau MyDraft, vous ferez un voyage spatio-temporel, dégusterez les délices des spécifications vivantes animées par des modèles exécutables, sous la coupe protectrice de la traçabilité agile, socialiserez avec des cloudjects à karma ouvert, pour découvrir ensemble comment réconcilier réactivité, économies, sécurisation du périmètre fonctionnel et pur plaisir.

Cet Ippevent aura lieu le jeudi 21 mars à 19h dans nos locaux de Levallois Perret (90 rue Baudin). Pour vous inscrire il suffit de cliquer sur le bandeau ci-dessous.

We are going to do a step-by-step audit of the application, and show:

• Tools & techniques we usually work with when doing a performance audit
• Common pitfalls and how to avoid them

For doing this audit, we will use our own fork of the project, which is located at: https://github.com/jdubois/spring-petclinic

As this tuning is a bit long, we have split it into 5 parts, which we will post every day this week:

• Monday: setting up the tests
• Tuesday: going stateless and Tomcat tuning
• Wednesday: removing the JVM locks
• Thursday: should we stay on JDBC, or is JPA better?
• Friday: adding a cache, and final words

Many thanks to:

• Pierre Templier and Christophe Parageaud, from Ippon Technologies, for proof-reading this analysis.
• Michaël Isvy from SpringSource/VMWare, who is the main developer of the Spring-petclinic application, for helping me and allowing me to torture his application.
• Thibault Duchateau and Romain Lespinasse from the Dandelion Project, for correcting their library at an unbelievable speed.
• James Ward, the author of WebJars, for best practices in using his library.

Creating a JMeter test

First of all, we have configured the application to be in “production” mode:

• We defined the logging level to error [Source code]
• We have configured the application to use MySQL (as in this project HSQLDB runs in the same JVM as the application, and thus will distort profiling) [Source code]

We’ve created a JMeter test, which is available here.

We have run this test a first time, with the “POST new visit” step activated, in order to create 10 visits per pet. This means running this test with 10 threads, doing 13 loops each (as there are 13 pets). The “POST new visit” step was then disabled: the application does not paginate visits, so doing inserts will just break it down really quickly.

As visits are the main objects that are being created in the application, they should have been paginated, or there should be at least a limit on the dataset that is returned. On the other hand, it would be really strange that a user has a pet that goes 1000 times to the vet, so this would not be a realistic test case.

That’s why we have decided to limit this test to 10 visits per pet: this is important, as this will have an impact in the future tests.

We have have then run the test normally (using “mvn clean tomcat7:run“), with a 2011 Macbook Pro, with 500 concurrent users each doing the test 10 times.

It is also important to mention that:

• Everything is on the same computer: Tomcat, MySQL, JMeter… This is not a “production” architecture but it’s easier to diagnose/debug it that way
• We use Tomcat 7, with Java 1.6 and 128M of RAM
• We have been careful in doing a “mvn clean” in the process, in order to remove older HTTP session states
• We do a “warm up” of the application before launching the tests, so the JIT compiler has the time to optimize the application

We have also run those tests on several other computers, with the same results (proportionally, some having more CPU power than the others).

The first results are as follow: the application quickly goes up to 285 requests per second (req/sec), then slows down and throws “java.lang.OutOfMemoryError: Java heap space” errors after nearly 700 users. We then have lots of HTTP errors, and the application gets so slow it is not usable anymore.

Of course, we can give more memory to the application, so that it can handle our 5000 users. With 1 Gigabytes of heap, the application can handle the load, with a result of 548 req/sec and 0,2% of HTTP errors.

Conclusion of part 1

The application cannot handle a lot of load: with 128 MB of RAM, the application starts to fail after 600 simultaneous users, which is a rather small number. Of course, we can give it more RAM to push that limit: we will be able to have more users, but as the GC will have more work, it is likely that the application does not perform very well.

We will see tomorrow, in the next episode of this series, how we started to solve that problem.

[edit]

You can find the other episodes of this series here : part 2, part 3, part 4 and part 5.

Au programme :

• 14h00 – 14h15 : Introduction par Bertrand Pinel, Directeur Technique d’Ippon Technologies
• 14h15 – 14h45 : Présentation de Liferay et des dernières innovations de la version 6.1. Marc Brassier mettra l’accent sur les avantages techniques et commerciaux du portail Liferay.

• 14h45 – 15h15 : Retour d’expérience d’Amaguiz – Amaline Assurances – Un site Internet avec Liferay

• 15h15 – 15h30 : Pause
• 15h30 – 16h00 : Présentation de l’offre Liferay Cloud par Yann Vigara, Responsable de l’Offre hébergement/Cloud d’Ippon Technologies.
• 16h00-16h30 : Echanges avec nos experts

Les équipes d’Ippon Technologies et de Liferay animeront le séminaire et se tiendront à votre disposition pour répondre à vos questions.

Lors de cet évènement vous pourrez :

• Découvrir et apprécier les avantages de Liferay, le portail J2EE prêt à l’emploi

• Profiter de l’expérience de clients qui utilisent déjà Liferay
• Découvrir l’offre d’hébergement Liferay développé par Ippon Technologies
• Echanger avec nos experts sur des problématiques que vous rencontrez et profiter de leurs retours d’expérience.

Cet évènement s’adresse en particulier à des responsables informatiques et métiers impliqués dans des projets Portails, CMS, eCommerce, Collaboration et réseaux sociaux.

Cet évènement gratuit, aura lieu à Paris (lieu à venir) , le jeudi 4 avril, de 14h à 16h30 .

• Tatami est l’un des très rares RSE Open Source, et le seul à notre connaissance sous license Apache 2.0 (et donc “business friendly”)
• Tatami utilise exclusivement Apache Cassandra pour stocker ses données, ce qui lui donne une performance et une montée en charge nettement supérieures
• Tatami possède une interface entièrement HTML5, en responsive design, ce qui lui permet de fonctionner de manière fluide et intuitive sur tout type de support

Nous sommes donc heureux de pouvoir annoncer la disponibilité de Tatami 2.0, après plusieurs mois de travail, sur le compte Github du projet: https://github.com/ippontech/tatami/tree/2.0.0

Un grand merci à Orange Labs

Tout d’abord, nous voulons dire un grand merci à Orange Labs, qui utilise Tatami en interne, et qui a très largement contribué aux nouvelles fonctionnalités de Tatami v2, en particulier :

• La gestion des flux RSS
• La personnalisation de l’interface graphique
• La gestion des emails donnant un résumé de l’activité hebdomadaire ou journalière

Le HTML5 et le NoSQL vous intéressent? Vous souhaitez de nouvelles fonctionnalités sur Tatami? Faites comme Orange Labs, et venez participer au développement de l’application sur https://github.com/ippontech/tatami

Un très grand nombre de nouvelles fonctionnalités

Cette version a été largement inspirée et voulue par nos utilisateurs, elle propose donc de très nombreuses nouvelles fonctionnalités :

• La gestion des fichiers attachés (avec gestion d’un quota)
• Un nouveau moteur de recherche, plus simple à utiliser (à la Google)
• Une toute nouvelle interface graphique pour les pages d’administration, utilisant Backbone.js
• De nouveaux algorithmes proposant des personnes, des groupes ou des tags à suivre
• Un nouvel écran facilitant la mise en place de son compte Tatami

Utilisez Tatami grâce à Ippon Technologies

Comme toujours depuis un an, vous pouvez utiliser Tatami gratuitement sur l’instance fournie par Ippon Technologies : https://tatami.ippon.fr

Cette instance a quelques limitations, en particulier sur la taille des fichiers attachés (pour des raisons évidentes…), mais vous pouvez nous contacter pour avoir une version “privée” que nous vous hébergerons chez Atomes, notre filiale spécialisée dans l’hébergement d’applications Java.

• L’impératif : basé sur une notion d’états modifiés par des instructions (le modèle de Turing), il s’agit de l’approche la plus répandue. Plus immédiate et intuitive, la plupart des langages informatiques utilisés (notamment les langages objet) sont basés sur ce paradigme.
• Le déclaratif : le programme est décrit sous forme d’une description de la solution par rapport à un état initial. La programmation fonctionnelle en fait partie.

Facilement vue comme un joujou pour matheux aimant manier des concepts compliqués, la programmation fonctionnelle n’est pourtant pas incompatible avec les concepts de la programmation orienté objet. De plus, l’impératif n’a pas répondu à toutes les attentes : la concurrence, la parallélisation…
Scala, Haskell, Erlang ou Groovy sont des langages fonctionnels que vous avez pu rencontrer, mais il est possible également de coder différemment en java en utilisant quelques principes (et librairies) fonctionnels. Java 8 et la JSR 355 introduiront les bases du fonctionnel dans Java.
Voici les quatre concepts de la programmation fonctionnelle.

La pureté de la fonction

Une fonction pure, au sens mathématique, est une fonction qui ne change pas l’état du monde. Sa seule fonction est de prendre une ou des données en entrée et retourner un résultat en sortie. Quelle que soit le moment où la fonction est jouée, avec des données identiques en entrée, la sortie reste la même.
Il existe plusieurs intérêts à utiliser au maximum des fonctions pures :

• Il n’y a aucun risque d’effet de bord à utiliser des fonctions, aucune variable cachée qui sera modifiée involontairement par cette fonction
• Tester une fonction pure est très simple
• La fonction peut être rejouée à l’infini : tant qu’elle recevra en paramètre la même donnée, elle retournera le même résultat, sans modifier quoi que ce soit
• Il est également possible de ne pas jouer cette fonction, et gagner du temps si son résultat n’est pas utilisé

Nous prendrons comme exemple, afin d’illustrer chacun de ces principes, un programme permettant de calculer les occurrences suivantes de suites. Examinons la fonction ci-dessous.

On constate que cette fonction n’est pas pure. Un indice très clair est le fait qu’elle retourne “void”. Si cette fonction ne modifiait pas l’état du monde, elle ne servirait à rien. La modification se situe au niveau de la ligne : majFichier(suites);
Celle-ci met à jour les fichiers correspondant aux suites que l’on manipule. Nous voulons modifier ce fichier, il n’est donc pas question de rendre cette fonction pure. Cependant, pour tester bien plus facilement ce que nous faisons, il est possible d’extraire de cette fonction, un code qui peut être, lui intégré en fonction pure. C’est ce que nous faisons ci-dessous.

La fonction calculeProchaineLigne est pure : tant que nous entrons la même chaîne de chiffres en paramètres, le retour sera identique. Elle peut donc être jouée à l’infini et être testée sans modifier l’état du monde.

L’immutabilité (ou immuabilité)

Il s’agit d’un concept allant de pair avec la pureté. Nous ne voulons pas changer l’état du monde, et ainsi nous ne changerons pas non plus l’état des paramètres passés à une fonction.
En java, nous utiliserons le mot-clef final.

Reprenons notre fonction précédente :

La ligne : suite.setLigneCalculee(newLine); viole le principe d’immuabilité. D’une manière générale, l’utilisation de getter dans les classes est incompatible avec le principe d’immuabilité. Nous pouvons avoir à la place, dans notre classe Suite :

De la même manière, notre liste passée en paramètre est actuellement modifiée en même temps qu’elle est parcourue. Nous allons donc créer une nouvelle liste dans laquelle nous insèrerons les nouvelles données, sans modifier la liste existante :

Ainsi, si la suite passée en paramètre est utilisée à un autre endroit du programme, aucun effet de bord n’est risqué. On gagne en simplicité de programmation.

L’expressivité

Cela correspond à l’utilisation de fonctions d’ordre supérieur, c’est-à-dire des fonctions qui prendront d’autres fonctions en paramètre.
Pour illustrer l’expressivité, nous utiliserons la bibliothèque Google Guava. Nous utiliserons l’interface Function pour définir comment obtenir un objet de la classe Suite avec la nouvelle ligne calculée à partir d’un objet de la classe Suite.

Nous pouvons l’utiliser grâce à la fonction transform de Google Guava qui applique une Function sur chaque élément de la liste passée en paramètre et retourne une nouvelle liste. Notre boucle est donc résumée en une seule ligne :

Composabilité

Il s’agit de la capacité de composer des fonctions ensemble pour obtenir une fonction.
Ainsi, si on modifie la suite de telle manière que la ligne suivante corresponde au calcul de la prochaine ligne sur laquelle on réapplique le même calcul, on aura tout simplement dans notre fonction :

La pureté et l’immutabilité nous permettent de faire cela sans prendre de risque.

Loin d’être un outil exotique, la programmation fonctionnelle peut nous permettre, en utilisant ses principes, de rendre nos codes plus lisibles et plus maintenables et ce, même dans des langages orientés objet.

Lire la suite

Sécuriser la communication entre vos apps Android et vos serveurs par Nicolas Guillot : Google vient de publier un article très intéressant sur son blog développeur Android. Il détaille la possibilité d’authentifier la communication entre les apps Android et les services web via un token OAuth fourni par Google. En d’autres termes, l’application Android utilise les services de Google Play pour permettre aux serveurs fournissant les services web utilisés de vérifier la validité de l’appel (vient-il bien de l’application ou a-t-il été corrompu ?) et de reconnaître l’utilisateur de l’application. Les bénéfices sont multiples.

Lire la suite

Worklight Studio – La stratégie mobile d’IBM pour les entreprises par Lorys Pognon : Nous disposons de plusieurs outils pour faire du développement mobile. Worklight studio est l’un de ces outils. Développé par une société israélienne rachetée par IBM, il met à disposition des entreprises un environnement intégré de développement mobile multiplateforme couplé avec un MDM (Mobile Device Management) et d’un module IBM WebSphere Cast Iron qui permet aux entreprises de connecter rapidement leurs applications mobiles à d’autres applications de l’entreprise.

Lire la suite

BlackBerry 10… est-ce la dernière chance ? par Lorys Pognon : BlackBerry a été l’un des acteurs incontournables de la téléphonie. Je dirai que c’est le premier téléphone portable à avoir été adopté en entreprise pour tout ce qui est du push mail et de la messagerie instantanée. Il demeure pour certains, l’un des téléphones les plus sécurisés. En plus de la cible professionnelle, les différents modèles de BlackBerry ont toujours été appréciés par les jeunes. Mais voilà, avec les smartphones Android, iOS, RIM a quelques difficultés à séduire.

Lire la suite

Dans une première partie, j’évoquais l’informatique en tant que produit d’une culture du développement. On ne rappelle jamais assez (à mon goût) que le développement logiciel est avant tout une production humaine. A ce titre, elle est une œuvre de création intellectuelle, à laquelle s’appliquent d’ailleurs les règles du copyright. Pourtant l’informatique, par sa nature dématérialisée, est  depuis longtemps l’objet et le moyen d’un pillage en règles. L’échange de disquettes s’est tout naturellement développé (si j’ose dire), car cette pratique fut perçue comme aussi normale que la copie privée des disques en vinyle sur cassettes audio.

C’est la numérisation, la dématérialisation, qui a ouvert grand les vannes de ces pratiques qui jusqu’alors n’étaient pas exagérément considérées comme illégitimes. Devant l’ampleur du phénomène actuel, on est en droit de se demander s’il est encore rentable de vendre du logiciel.

À qui vendre ?

Après tout, on connaît des structures économiques qui parviennent à prospérer en proposant des prestations concernant le logiciel libre. Ce ne sont pas les acteurs principaux du marché… à moins que… mais c’est vrai : Google et Facebook et même Yahoo! mon Dieu, gagnent des sous sans forcément vendre leur logiciel ! Force est de constater qu’il est au moins possible de proposer certains services informatiques gratuitement au grand public.

Bon, nous avons donc la preuve qu’il est en tout cas possible de produire un logiciel tout en gagnant de l’argent (et même d’entrer en bourse, argh).

Mais qu’en est-il de la distribution ? Peut-on aussi encore espérer rentabiliser un programme informatique sur la base des licences vendues ? A vrai dire, cela dépend avant tout du client. Trois secteurs sont particulièrement rentables pour un éditeur de logiciels, par rapport aux autres : l’immobilier, la banque et les télécoms. A la traîne, on trouve le secteur de l’informatique lui-même et celui des jeux vidéos ; mais aussi les grands secteurs publics (santé, éducation, administration) qui ont nécessairement des budgets plus frileux par les temps qui courent.

Dans un second temps, on peut imaginer que la monétisation d’un logiciel dépende également de son architecture et/ou de sa(ses) plate-forme(s) de déploiement. En effet, cette industrie s’appuie sur différents modèles en la matière (backoffice, desktop app, mobile app, console app, web app, cloud app, etc.), et la façon de commercialiser les logiciels, d’un environnement à l’autre, peut varier du tout au tout. En fait, on peut espérer que plus le médium de diffusion sera fermé et protégé, plus il sera difficile aux utilisateurs de s’affranchir de l’obligation de régler une licence pour l’utilisation du logiciel. Cependant, on s’est aperçu en pratique que la difficulté de piratage des logiciels n’est pas liée au support mais qu’elle est inversement proportionnelle à l’attractivité du produit. Les jeux sur console, fortement liés au matériel et parfois distribués sur des cartouches électroniques sont, on l’a vu, parmi les moins rentables. Dans ce graphique, on constate que les secteurs de grande consommation sont mal rémunérés ; sauf en ce qui concerne les réseaux sociaux qui, eux, tirent leurs revenus du trafic généré par le biais de leurs services (publicités ajoutées aux écrans).

Moralité, si vous voulez vivre de votre programmation, je vous conseillerais de miser sur des clients qui constituent une niche fonctionnelle et qui ne soient pas avares de leurs sous !.. Qui a dit “nouvelle économie” ? Il n’y a rien de nouveau là-dedans, si ?

Encore un élément à considérer : la durée du développement semblerait constituer un levier important de profit. Travaillez fort et ne lésinez pas sur les fonctionnalités, vos clients vous en saurons gré ! C’est quand même bon de voir reconnaître ses efforts, in fine. Le corollaire, c’est qu’il vous faudra d’abord investir avant de pouvoir vendre. On n’a rien sans rien, même dans les TIC, apparemment. Par ailleurs, bien que le taux de piratage des logiciels en France ait diminué en 2011 pour s’établir à 37% (merci de me passer les pincettes), il demeure nettement supérieur à celui de pas mal d’autres pays européens. Peut-être devriez-vous vous expatrier ?

Pour pouvoir vendre, doit-on se protéger ?

On estimerait (avec des pincettes, donc) le manque à gagner mondial dû au piratage des logiciels à 63,4 milliards de dollars (1,98 milliard d’euros en France). Des sommes qu’il convient de rapporter aux 11,3 milliards d’euros de chiffre d’affaires du secteur français, soit 2% de la production mondiale. Pour comparaison (même si ce n’est pas raison), on estime le coût de l’évasion fiscale française entre 30 et 50 milliards d’Euros par an.

Le CA du secteur mondial des logiciels est estimé à 132 milliards de dollars (2009). Ce n’est pas rien, certes, et la demande de logiciels reste très forte. Cependant, il faut également considérer que les produits disponibles sont de moins en moins novateurs, dans le sens où l’essentiel des travaux aujourd’hui concerne des ravalements d’IHM ou des portages technologiques (desktop to web, web to mobile, par exemple) ; vous avez regardé Microsoft Office 2010 ?

Aurait-on atteint un seuil fonctionnel ? On s’aperçoit que certains acteurs de l’édition logicielle ont (volontairement ?) adopté une stratégie “de la tortue” ; certaines fonctionnalités évidentes ne vous semblent-elles pas cruellement manquer à votre OS ou à votre iBidule favoris ? Vivement la prochaine version, hein ? Tous les jours, il y en a un plus geek que vous qui vient vous faire baver devant son nouveau processeur et ses fonds d’écrans 3D animés, avouez ! Même si on ne vous fait pas forcément payer pour les mises à jour, vous remarquerez tout de même que ces nouvelles fonctions réclament toujours plus de puissance… incitation détournée à la vente, je vous dis : le revenu vient des machines dont le besoin est provoqué par le logiciel système ou ceux que vous y ajoutez (des jeux surtout, gourmands en ressources par définition). Futé, non ? C’est encore une piste marketing à creuser si vous voulez vous y mettre, ça porte même un nom : l’obsolescence programmée.

Malgré de nouvelles formes de commercialisation, avec des app stores et des cartouches (ma fille de 9 ans sait ce qu’est une R4, voyez-vous), rien n’arrête l’utilisation frauduleuse de logiciels. On peut même prendre le pari que rien ne l’arrêtera, tant les numéros de licence et cracks divers fourmillent littéralement sur la toile. C’est un problème culturel aussi bien que technologique. Même sans support physique et avec l’apparition de nouvelles formes de licence (on peut acheter des logiciels par tronçons, voire en bénéficier par abonnement), rien n’y fait vraiment. Pourtant, l’internet comme média de distribution se prête parfaitement à la fourniture d’un service logiciel dont l’accès est restreint (en couverture fonctionnelle ou en durée, donc) sans qu’il soit possible de les héberger soi-même – autrement dit, de les copier.

“Le cloud ! Le cloud ! Le cloud !” scanderont certains ; mouais… bof ! L’avantage compétitif, je pense, ne vient pas de la répartition de charge (traitement et stockage) mais bien du déploiement distant. Impossible d’installer chez soi, en toute discrétion, quelque chose qui nécessite une infrastructure externe (toutes fonctionnalités de partage ou centralisées en général). Eurêka, CQFD !

Alors, que vendre ?

Un éditeur de logiciels est confronté à deux défis : premièrement cibler et faire connaître son produit pour trouver ses utilisateurs dans le monde entier. Deuxièmement opter pour un mode de collecte des revenus qui lui permette de vivre. Au vu des indices récoltés ci-dessus, un profil rémunérateur émerge. En arrière seulement, malheureusement, émerge la question de la productivité et de la qualité du développement. En effet, l’obsolescence programmée dont nous avons parlé n’oblige absolument pas cet éditeur à miser sur une fiabilité à toute épreuve. On fera bien une mise à jour en cas de problème… Le seul point critique est constitué par la sécurité. Et il arrive bien souvent qu’untel ou tel autre aient chauds aux fesses quand une faille est découverte ! Cela nous apprend à nouveau deux choses : on n’est jamais à la merci d’une mauvaise publicité ET certains produits très répandus ne sont pas à la hauteur. En fait, ils ne le seront jamais. Mais ils rapportent de l’argent.

En gros, les développeurs (jeunes et fougueux) d’aujourd’hui, veulent développer des “applications mobiles”. C’est facile, souple, et le circuit de vente incontournable a largement pignon sur rue. Pour celui dont le souci est avant tout de mettre sa solution à disposition largement, au sein d’un circuit fiable de collecte des revenus, l’apparition des app stores est une bénédiction. La plupart du temps, ce n’est pas donné (certes : Apple par exemple prend 30% sur les ventes), mais il faut reconnaître que cela répond à un vrai besoin, en centralisant des catalogues de l’offre disponible. Est-ce-à-dire que le meilleur moyen de gagner de l’argent dans le logiciel serait de vendre ceux des autres ? Sûrement ; et, encore une fois, ceci n’est pas une règle propre aux TIC. De plus, sachez que l’essentiel du volume d’affaires sur ces circuits est accaparé par un nombre très restreint de produits stars ; il est dès lors difficile de percer même avec un bon logiciel. Aujourd’hui, il semblerait que la meilleure niche commerciale pour les logiciels réside dans l’intermédiation. Celui qui dégage les prébendes les plus importantes est celui qui a la capacité de s’imposer comme intermédiaire, celui qui sait se placer au cœur des flux les plus importants (voir encore Google et Facebook). Revenus de la publicité ou rentes d’hébergement étant les filières les plus lucratives, dans un contexte de diffusion publique.

On constate donc que l’argent ne semble pas aller vers les algorithmes mais vers l’accès aux services. C’est moche, je sais.

TO READ:

La Nouvelle Économie – Wikipedia (qui a lancé une campagne d’appel aux dons)

En livre, L’économie du logiciel (François Horn) – 2004

Livre blanc sur les modèles économiques du logiciel libre – April

How Free Apps Can Make More Money Than Paid Apps – TechCrunch
When Freemium Fails – WSJ.com

Avec le HTML5 et son élément <video> le multimédia est censé avoir enfin trouvé sa place. Alors pourquoi ne pas en profiter pour ajouter quelques animations bien sympathiques dans les pages Web en se passant de Flash. Voyez par exemple cette page du site d’Apple : animation du « Unlock » de l’iPhone 5, animation des écouteurs en mode Quicktime VR (manipulables à la souris), HTML5 fait la preuve de sa dimension multimédia tant attendue.

Sauf que les choses ne sont ni aussi triviales, ni aussi évidentes : un click droit sur la zone des écouteurs ou sur la zone de l’iPhone à « unlocker » fait apparaître que l’élément est en fait une simple image. Étonnant. Un coup d’œil sur le code source HTML et le DOM en mémoire ne montre aucune balise vidéo, ni flux vidéo chargé. Mais un élément <canvas> existe. Pourquoi Apple, créateur du H.264, ne l’utilise pas et ne met pas de vidéo sur cette page de son site ? Comment ont-ils pu contourner cette contrainte ?

Codecs… Ho… Nan !

Entrons dans les histoires de codecs vidéo. Il existe 3 grands codecs vidéos qui concernent les navigateurs ; deux sont «gratuits», Ogg Theora et WebM, et un est soumis à de multiples brevets de la part de Apple et Microsoft: le H.264/MPEG-4. Résultat, à ce jour il n’existe pas un codec qui soit pris en charge par les principaux navigateurs (lire ici sur wikipedia). Par exemple Opera ne supporte pas H.264 quand Safari ne supporte que H.264 (sauf si utilisation de plugins) ou quand Firefox supporte H.264, mais pas sous MacOS, pendant que IE ne supporte que H.264… un vrai sac de nœud.

Dans ces conditions, difficile d’utiliser l’élément HTML5 <video> quand on s’adresse au public le plus large. Une fois constatée cette impasse, la solution naturelle qui s’imposerait serait d’utiliser Flash. Mais on se souvient tous de la lettre de Steve Jobs  dans laquelle il livre ses réflexions sur Flash, et on imagine aisément que personne d’intellectuellement sain chez Apple n’a du se risquer à cette proposition peu corporate…

Reste donc un rare dénominateur commun pour effectuer des animations et des sorties graphiques maîtrisées: l’élément <canvas> associé à des images. Une vidéo n’est-elle pas une succession d’images ? En téléchargeant N images puis en effectuant une copie de ces images sur le canvas à intervalle régulier, on arrive au résultat escompté. Oui mais… Oui mais rapidement le téléchargement peut devenir conséquent, à raison de 25 images/sec… Solution viable, donc, mais coûteuse en terme de bande passante. Reste finalement une seule solution cohérente dans l’esprit d’Apple: écrire son « codec » vidéo en Javascript. Un codec qui doit être simple à manipuler, qui ne doit pas dégrader l’image (à la différence de ce que fait le DivX par exemple) et qui doit rester efficace quel que soit le navigateur, depuis IE7 (il existe de quoi émuler le <canvas>) jusqu’à iOS, Chrome ou Opera. Pour un puriste le terme « codec » n’est peut-être pas exact mais il reste conforme dans le contexte, on s’en contentera.

Sans rentrer dans les détails, examinons de plus près comment Apple s’y est pris pour faire en javascript une animation optimisée à partir d’images JPG.

Codec, la ration en Javascript et JSON

Nous pendrons comme exemple le « Unlock » animé vu précédemment sur le site d’Apple. L’idée de base du codec est très simple : on part d’une image initiale clé I1 (une « keyframe » en matière de vidéo), à laquelle on applique ensuite la différence nécessaire pour atteindre l’image suivante I2. On procède ainsi par récurrence jusqu’à atteindre l’image finale de l’animation qui est aussi implémentée comme une keyframe. En observant les images chargées par le navigateur on découvre ainsi:

• unlock_keyframe.jpg
• unlock_001.jpg,
• unlock_002.jpg ,
• unlock_endframe.jpg.

Techniquement les images unlock_001.jpg et unlock_002.jpg forment un flux continu de données pour les images intermédiaires. (je n’ai mis qu’une copie d’écran partielle, j’expliquerai plus loin pourquoi il y a deux images et pas une seule, ainsi que leurs formes carrées…).

Il nous faut maintenant savoir quelle partie du flux unlock_001 et unlock_002 il faut copier pour passer de l’image In à l’image In+1. En observant les ressources chargées par le navigateur on découvre un fichier manifest unlock_manifest.json chargé via AJAX.

Ce manifest décrit parfaitement notre animation : elle nécessite 2 images de données (imagesRequired:2, nos deux jpg unlock_NN.jpg) pour réaliser les mises à jour entre les images (frames)  et elle sera composée de 91 images (frames) intermédiaires. Quant au blockSize (blockSize:8), on verra plus tard sa signification, mais partons du principe que l’unité de mise à jour d’une image est un bloc de 8×8 pixels. Nous allons maintenant examiner les données du tableau des frames. Pour cela observons comment le codec fonctionne, bref soulevons le capot du code Javascript mis en place par Apple.

Apple fournit divers fichiers de script nommés ac_XXXX.js (pourquoi AC ? A pour Apple, C pour quoi? Codec ? Suis pas sûr) qui prennent en charge la problématique habituelle des différents navigateurs (pas de jQuery dans cette page) en mettant en œuvre un namespace AC. On trouve donc des objets AC.Element, AC.Function, AC.Object, AC.RegExp etc…

A noter que les fichiers JS sont optimisés et minimisés, donc le code vu dans le navigateur est souvent peu lisible : je recréerai quelques noms de variables pour la bonne compréhension.

Intéressons nous au fichier ac_flow.js qui est celui qui implémente le codec et sa manipulation. Il définit notamment les classes suivantes qui concernent notre exemple:

• AC.Flow: la classe principale chargée de jouer l’animation
• AC.Flow.Manifest: la classe qui gère le manifeste associé à l’animation
• AC.Flow.Manifest.Keys: les infos issues du manifeste pour construire chaque image intermédiaire
• AC.Flow.SharedMethods: les fonctions diverses

Une fois chargé via AJAX, le fichier manifest est parsé ainsi:

Une frame du fichier JSON (exemple de la frame 1) : “AAxACABhABAFgABAKAABA1yACA11ABA2jADA2vABA3SADA3dACA4BAD“) est donc décomposée par bloc de 5 caractères codés en base64 : les 3 premiers caractères indiquent la position où doit avoir lieu la modification sur le canvas cible (location), les 2 suivants le nombre de blocs à lire pour la mise à jour (length). “AAxAC” s’interprète donc ainsi : lire 2 blocs (AC) à la position actuelle dans le flux (unlock_NN.jpg) et effectuer la mise à jour sur le canvas en position 49 (AAx). Simple et efficace. On pourra juste noter que Apple a adapté le décodage Base64, qui normalement est toujours constitué de blocs de 4 caractères pour coder 3 octets, (soit 6 bits par caractère – ce point précis est d’ailleurs respecté ici).

On anime le canvas…

Maintenant que le manifest est décodé et les blocs identifiés il reste à jouer l’animation en copiant les blocs concernés à partir du flux. Ainsi, on trouve des méthodes habituelles play, pause, showFrame etc… Elles effectuent leurs sorties sur le canvas cible. Mais la méthode la plus intéressante est __applyDiffRange chargée d’appliquer les modifications entre deux images (note : j’ai injecté quelques commentaires et noms de variables pour clarifier le code):

On retrouve les notions vues plus hauts, à savoir la lecture de n blocs à partir de l’image de diff en cours (unlock_xx) qui sont ensuite copiés vers le canvas à la position décodée à partir du manifest. Ces traitements sont visibles dans la console du navigateur:

De même, les structures Base64 des 91 frames qui renseignent sur le nombre de blocs à mettre à jour sont celles-ci, une fois réduites en taille:

Les 60 premières mises à jour sont limitées, elle concernent l’animation de la zone du “unlock”. Puis ensuite les choses s’accélèrent avec les 30 dernières mises à jour conséquentes en nombre, correspondant à l’apparition des icônes de l’iPhone et à leurs déplacements  jusqu’à ce qu’elles trouvent leur place sur l’écran et se superposent à la keyframe finale.

Si on continue à lire ce fichier JS, on note encore l’existence d’une classe AC.Flow.VR qui émule Quicktime VR (oui oui, vous lisez bien), utilisée d’ailleurs dans le cas de la rotation des écouteurs. De même on découvre que Apple a dû fournir précédemment une version de l’animation composée basiquement d’un ensemble de n images brutes enchainées à partir d’un élément <img> ! Peut-être la première version.

Enfin on découvre que la description de l’animation actuellement dans le fichier manifest JSON est prévue aussi pour être intégrée dans un fichier image PNG, ce qui améliorerait certainement les performances pour coder/décoder les informations (plus besoin de passer par du Base64, lecture en masse).

Avant de refermer cet article, revenons sur la notion de blockSize vue dans le fichier manifest. Les images de données ont ces dimensions: unlock_01.jpg, w=1624 , h=1624 et unlock_02.jpg, w= 160 , h=160. Le format des images est du JPG. La norme JPG nous renseigne qu’un JPG est décomposé en blocs de 8×8 pixels ou 16×16 pixels. Or dans notre cas le blockSize inscrit dans le manifest est de 8 pixels : Apple a donc créé des JPG en veillant à respecter cette caractéristique de compression, sans perte de qualité, ce qui permet une relecture parfaite des pixels du block. On constate bien d’ailleurs que les images unlock_NN.jpg sont constituées de bandes de 8 pixels de haut et de largeur un multiple de 8 (1624=8x 203, 160=8×20). Astucieux.  Pour être complet, le fait que les images soient carrées simplifie les calculs (mais sans plus), et impose donc de fabriquer deux images pour optimiser la taille globale en Ko qui devra être téléchargée .

En conclusion, alors que le HTML5 semble devenir pour beaucoup un standard enfin respecté par les navigateurs, qu’il dispose des moyens modernes pour jouer des animations et gérer l’interactivité souhaitée, Apple nous prend à contre-pied et nous montre si besoin était, que le chemin sera encore long avant de pouvoir fédérer définitivement les acteurs.

En attendant, les animations sont faites à partir d’images JPG !

Pour nos clients, nous nous sommes employés à utiliser les méthodes les plus adaptées à leurs besoins et à leurs attentes que se soit dans le suivi des projets, comme nous le faisons chez Darty, Suez ou encore EDF ou dans une réflexion plus globale sur la mise en place d’une démarche Agile, comme nous le faisons chez Thalès.

Notre défi pour l’avenir est de continuer à démontrer l’efficacité des méthodes Agiles sur un marché concurrentiel ayant besoin d’une grande réactivité. Montrer que ces méthodes ne sont pas que des discussions de principes mais avant tout des atouts pour la réussite de nos projets.

Plus que jamais l’Agilité fait partie intégrante de l’activité d’Ippon. Sur les projets classiques bien entendu, mais aussi de plus en plus sur les projets mobiles encore plus exigeants en termes de changement et d’adaptation. La nouvelle offre complète de Cloud Ippon, suite à l’acquisition d’Atomes, va fournir le cadre idéal pour mettre en pratique notre expertise Agile jusqu’en production, avec les pratiques DevOps, et confirmer la réussite et la création de valeur jusqu’au bout du projet.

Notre reporter a été demander aux participants ce qu’évoque pour eux ‘l’Agilité’… Des réponses aussi riches et personnelles que surprenantes!