Java EE 7, c’est parti !

La semaine dernière Oracle a annoncé la sortie de Java EE 7, en nous promettant (je cite) “le support de HTML5, plus de productivité pour les développeurs et la réponse aux besoins les plus exigeants des entreprises”.

Qu’en est-il vraiment ?

Etat des lieux de Java EE

Si Java est aujourd’hui le principal language utilisé en entreprise, Java EE n’a pas eu le même succès, la plupart des gens n’en utilisant qu’un sous-ensemble (JSP, Servlet, JPA, etc.) et non pas l’ensemble des APIs (EJBs, JMS…).

Les premières versions de la plateforme, mal conçues, ont été rapidement concurrencées par des frameworks tels que Spring : au bout de quelques années de concurrence, J2EE est devenu Java EE et a repris les principes majeurs de Spring tels que l’injection de dépendance par annotation ou les intercepteurs (encore qu’on pourrait argumenter que les intercepteurs Java EE sont nettement moins puissants que l’AOP fourni par Spring).

Cependant, entre-temps, notre monde a bougé : la productivité ou la satisfaction des développeurs n’est plus simplement limité à avoir un framework d’injection de dépendance ! Nous voulons pouvoir développer des applications REST, HTML5, dans le cloud, avec la stack ayant le plus de buzzwords possibles. Et j’oubliais la mobilité et le Big Data, sur des architectures distribuées

Que ce soit sur Google Trends (tendances des recherches Google) ou Indeed (tendances des offres d’emploi aux US), on retrouve les mêmes courbes :

• Google Trends : “Java EE” vs Node.js vs MongoDB vs Hadoop
• Indeed : “Java EE” vs Node.js vs MongoDB vs Hadoop

On voit bien ici que l’intérêt des développeurs pour Java EE n’a pas décollé, par rapport à des frameworks concurrents (node.js) ou des technologies NoSQL/Big Data.

C’est donc sur ces thèmes que Java EE doit se battre, en particulier contre Spring ou Node.js, qui sont des stacks ayant pris depuis longtemps le chemin des applications HTML5, REST, NoSQL, mobiles, dans le cloud, etc. Et c’est ce que nous allons donc étudier tout au long de cet article.

Le support de HTML5, 1ère partie : les Websockets

Le support de HTML5 m’a personnellement plutôt fait sourire : quel rapport entre Java EE et le HTML5 ? Pour Oracle, dans sa “press release”, cela signifie supporter les Websockets !

Quiconque ayant déjà fait des Websockets se méfie en voyant ce type d’annonce :

• Utiliser des Websockets est une problématique bien plus compliquée que d’avoir simplement une implémentation sur son serveur d’application. Il est clair que la solution proposée par Java EE va poser des problèmes de portabilité et de gestion des erreurs (que faites-vous si un serveur proxy ou un navigateur client ne supporte pas Websocket ?).
• Les Websockets changent radicalement la manière dont on conçoit une application, car l’idée est de pouvoir faire du “push” depuis le serveur, ce qui est très différent d’une architecture classique où l’on répond à des requêtes envoyées par un client HTTP. La seule solution en Java EE consiste à utiliser JMS 2.0 pour faire ces envois (mécanisme détaillé dans ce blog), ce que je trouve plutôt lourd. Sortir un serveur JMS pour faire des Websockets, c’est quand même bien compliqué !

Pour utiliser Atmosphere depuis pas mal de temps, un excellent framework qui résout tous ces problèmes de manière performante et élégante, je vois mal quiconque utiliser Java EE 7 directement.

La press release d’Oracle met donc en avant une avancée technique nécessaire et intéressante, mais dont l’implémentation reste simpliste.

Le support de HTML5, 2ème partie : JAX-RS 2 et JSON

Faire une application HTML5 avec un framework MVC JavaScript moderne, de type backbone.js ou angular.js, c’est surtout consommer des services REST, et s’échanger des données au format JSON.

La mise à jour de l’API JAX RS est donc particulièrement bienvenue, et permet :

• D’avoir des intercepteurs sur ses services REST
• De pouvoir avoir des services asynchrones
• D’avoir une API cliente (il était en effet assez incroyable de constater qu’il y avait une API serveur mais pas d’API cliente !)

De même nous disposons maintenant d’une API JSON standardisée, avec JSON-P (plus de détails sur cet article). Une nouveauté intéressante est l’ajout d’une API fluente permettant de créer du JSON (personnellement je n’ai encore jamais eu ce besoin, mais cela peut toujours être utile).

Toutes ces fonctionnalités étant présentes dans les stacks concurrente (par exemple Spring MVC REST + Jackson 2), il s’agit donc là d’une mise à jour nécessaire.

Un regret cependant : cette stack ne propose pas de support pour réaliser des tests unitaires avec des mocks, comme nous en disposons dans Spring. C’est une fonctionnalité que j’apprécie particulièrement, par exemple dans Tatami (voici en exemple), et qui devrait bientôt faire l’objet d’un nouvel article sur ce blog.

Le support de HTML5, 3ème partie : JSF 2.2

De manière plus discrète, Java EE 7 amène également les “passthrough attributes” dans JSF 2.2, ce qui permet enfin d’utiliser HTML5 avec JSF 2.2.

Jusqu’à présent, on ne pouvait utiliser que les tags reconnus par sa librairie de composants : or, en HTML5, vous pouvez ajouter et définir vos propres attributs, que vous utilisez ensuite en JavaScript.

Les “passthrough attributes” sont en fait assez basiques : la librairie de composant va simplement rendre ces attributs côté client. Elle fait alors juste “passe plat” entre le code JSF et le HTML généré. Mais cela change tout, car nous pouvons maintenant avoir nos propres attributs côté client !

Pas de cloud dans Java EE 7

L’objectif de Java EE 7 était le cloud : comme présenté l’année dernière par Oracle (les slides sont encore ici), nous devions pouvoir développer “dans le cloud” avec Java EE 7, et plus précisément :

• Avoir des APIs pour gérer le provisionning, l’élasticité, la qualité de service, etc.
• Avoir des applications modulaires, avec Jigsaw
• Avoir du “vrai” multi-tenancy sur les serveurs d’app
• Enfin, JCache allait renaître de ses cendres et nous aurions une API de cache digne de ce nom

Au final, tout cela a été abandonné.

Pour avoir participé à la spécification JMS 2, je peux vous confirmer que cet abandon a été volontaire : aucun vendeur de serveur d’application ne souhaite voir ces fonctionnalités être intégrées dans Java EE. Cela fait plus de 10 ans que l’ajout de ces fonctionnalités “avancées” dans Java EE sont sabordées par une grande partie des acteurs du JCP, car ce sont grâce à elles que les entreprises clientes achètent des serveurs en “version entreprise” au lieu de se contenter d’un simple Tomcat.

C’est donc un grand gâchi, mais ce n’est que partie remise. Comme en son temps l’arrivée de Spring a fait bouger le JCP, l’arrivée du cloud va nécessairement faire bouger les lignes. A titre d’exemple, les ventes de serveurs d’Oracle (les anciens serveurs Sun, que Oracle a racheté) ont chuté de 27,2% ce trimestre ! Il est donc probable que le JCP, à nouveau, soit forcé de s’adapter.

Focus sur JMS 2

L’un des succès de Java EE 7 est l’arrivée de JMS 2. Plus de 10 ans après la norme précédente, et toujours sans support du clustering (cf. le point précédent), JMS 2 propose une API modernisée, qui vous permettra de vous passer de la fameuse JmsTemplate de Spring.

JMS 2, heureusement, garde quand même l’un des grands bénéfices de JMS 1, qui était de pouvoir être utilisé en dehors d’un serveur d’application : en effet, les vendeurs de serveurs d’applications voulaient lier JMS 2 à CDI, de manière à obliger les utilisateurs à avoir un serveur d’application pour envoyer un message. Au final, nous restons donc sur une API proche de l’originale, mais modernisée et simplifiée.

Cette nouvelle API a été très bien décrite dans ce blog, nous en retiendrons principalement :

• La suppression de beaucoup de code inutile
• La fin de l’API connection.createSession(true,Session.SESSION_TRANSACTED), dont les deux paramètres étaient une curiosité étonnante
• L’ajout d’une API “fluente”, de type context.createProducer().setPriority(1).setProperty(“foo”, “bar”).send(demoQueue, textMessage);

La bonne surprise de Java EE 7 : l’intégration de Spring Batch

Lancé par IBM, l’intégration des batchs dans Java EE est enfin une réalité ! Dans la pratique, il s’agit d’une intégration du code Spring Batch dans Java EE :

• L’API est la même
• Les fichiers de configuration sont les mêmes
• Même dans les slides d’Oracle, on retrouve des schémas copiés/collés du site de Spring Batch

D’autre part, SpringSource a fait le maximum pour que Spring Batch puisse être utilisé dans Java EE (avec CDI), mais sans que l’on soit obligé de dépendre de ses APIs.

Depuis le nombre d’années que l’on attendait une solution pour faire des batchs en Java EE, c’est donc une excellente nouvelle, d’autant plus que Spring Batch est une solution très largement reconnue.

Reste à voir quelles implémentations seront disponibles dans les différents serveurs d’applications :

• Est-ce que les vendeurs de serveurs d’applications se contenteront tous de copier/coller le code de Spring Batch, ou certains feront-ils des implémentations spécifiques ?
• Est-ce que nous aurons enfin des stratégies performantes de partitionning des batchs ? Les versions disponibles sur Spring Batch sont en effet en cours de développement depuis longtemps, sans grande avancée.

Cette nouvelle devrait également permettre de faire revivre Spring Batch, qui est un projet qui ne progressait plus beaucoup ces dernières années, en particulier depuis que Accenture en avait abandonné le co-développement avec SpringSource.

En conclusion

Cette montée de version de Java EE, tant attendue, n’a pas tenue ses promesses. L’objectif “cloud” a été totalement raté, de même qu’un certain nombre d’API qui devaient être mises à jour (JCache en particulier).

Heureusement, un travail minimal a été réalisé sur les HTML5 et sur JMS 2, et nous avons eu la bonne surprise de voir l’intégration de Spring Batch dans la spécification. En 2013, nous n’en attendions pas moins !

Plus d’une heure et demi de vidéo sur ElasticSearch, encore un IppEvent d’une grande qualité technique avec David Pilato, qui nous présente le moteur de recherche Open Source le plus avancé du moment.

Je profite de ce billet pour vous annoncer deux nouvelles en relation avec l’évènement :

• Tatami, notre réseau social d’entreprise Open Source, utilise maintenant exclusivement Elastic Search pour ses recherches. Vous pouvez retrouver le code sur https://github.com/ippontech/tatami
• Notre prochain IppEvent aura lieu Jeudi 20 Juin et traitera de Cassandra : http://ippevent-cassandra.eventbrite.fr/?ref=etckt

Elasticsearch – Le moteur de recherche élastique pour tous, pour David Pilato from Ippon Technologies on Vimeo.

Au début du web nous n’avions que des pages statiques, nous entrions une adresse et le serveur nous retournait une page HTML. Puis nous avons voulu dynamiser un peu nos sites avec du Javascript et de l’AJAX, jusqu’à avoir des applications complètes dans nos navigateurs. Ce que nous appelons maintenant des “Single-Page-Application”.

Une des problématiques lors du développement d’application de type “single-page” est que nous chargeons une page, puis nous modifions le contenu de celle-ci au gré des clicks de l’utilisateur sans modifier visiblement l’URL de la page. Ceci est logique, car nous restons toujours sur la même page, mais ne suit pas la philosophie de Web où un contenu est identifié de manière unique.

Pour résoudre ce problème et avoir un identifiant unique pour chaque ressource, il existait jusqu’à maintenant une solution : Ajouter des hash pour avoir des adresses comme ceci http://monsite/#article/0/spring_c_est_bien

Le hash apporte une solution partielle, car si cette technique permet d’avoir un identifiant unique pour une ressource, celle-ci est connue uniquement du navigateur, mais pas du serveur. Alors oui, nous pouvons mettre l’adresse en favori et lorsque l’utilisateur rechargera cette page, il l’aura bien la page dans le bon état, mais il reste des problèmes.

Tout d’abord,  l’affichage de la page n’est pas optimale, car la remise dans le bonne état de la page se fait forcément côté sur le client via Javacript, car le serveur n’ayant pas l’intégralité du nom de la ressource, il ne peut pas générer la page dans son état final. Pour l’utilisateur ça veut dire attendre que tous les scripts soient chargés, puis que le javascript s’exécute. Sur une machine peut puissante ou si vous utilisez 90 % votre CPU pour lire une vidéo avec flash, un temps plus ou moins long est nécessaire pour que la page s’affiche et donc l’expérience utilisateur est dégradée.

L’autre problème d’avoir le nom de la ressource uniquement sur le client est que si le serveur doit faire une redirection, il la fera uniquement vers le début de l’adresse. Par exemple si vous devez vous authentifier, vous serez rediriger vers la page d’accueil et non vers la page que vous avez appelez initialement.

Mais ça c’était avant, maintenant avec HTML5, il est possible d’avoir des vrais adresses comme ceci http://monsite/article/0/spring_c_est_bien tout en continuant à utiliser de l’Ajax. Pour réaliser ce miracle, nous utilisons la nouvelle fonction pushstate de l’objet History. Alors quand je dis nous utilisons, c’est vrai, le pushstate a été mis en place sur la prochaine version de Tatami. Nous ne sommes pas les seuls Twitter utilise cette technique pour accélérer son affichage, comme indiqué ici.

Compatibilité

Avec HTML5, nous ne savons jamais quel navigateur supporte quelle fonctionnalité, voici un tableau des navigateurs supportant le pushstate

IE

Firefox

Safari

Chrome

Opéra

iPhone

Android

-

4.0+

5.0+

8.0+

11.50+

4.2.1+

Navigation via du hash

Nous allons créer les liens de la manières suivantes :

Lorsqu’un utilisateur clique sur un lien, le serveur n’est pas appelé puisque nous restons sur la même page. Pour modifier le contenu de la page, il ne reste plus qu’à ajouter un événement sur le changement du hash.

Attention, l’événement n’est pas lancé au chargement de la page, il faut appeler la fonction de modification du contenu au chargement de la page.

Navigation via pushstate

Pour ce type de navigation, nous utilisons les liens suivants avec des vrais URLs :

Lorsque l’utilisateur clique sur un lien, il est nécessaire de supprimer le comportement par défaut du navigateur, sinon le serveur sera appelé. Nous allons ensuite changer l’url et appeler la fonction modifiant le contenu de la page

Il est nécessaire d’ajouter l’événement suivant pour que le contenu de la page soit modifié lors de la navigation via les boutons “précédent” et “suivant”

Attention le comportement par défaut de cet événement est différent entre les navigateurs Webkit et Firefox. Sous Webkit l’événement est appelé lors du chargement de la page, alors qu’il ne l’est pas sous Firefox

Pushstate dans les frameworks MVC

Il est possible dès maintenant d’avoir le support du pushstate dans certains frameworks MVC. L’utilisation des ces frameworks permet de détecter le support de la fonctionnalité par le navigateur et d’utiliser la méthode du hash pour les vieux navigateurs.

Backbone

Pour l’utiliser, il suffit de l’activer au moment du lancement de la gestion des routes

Il est également possible de passer en paramètre de start, la propriété  silent: true, qui permet de ne pas déclencher la route lors du chargement initial de la page.

AngularJS

Il suffit de le déclarer dans la configuration de l’application

Il n’y a pas d’équivalent au silent: true de backbone.js, pour ne pas avoir de déclenchement d’une route lors du premier chargement, ce qui peut s’avérer gênant dans certains cas.

GWT

Gwt ne supporte pas cette fonctionnalité pour le moment, mais il existe l’extension https://github.com/jbarop/gwt-pushstate/

Pourquoi le pushstate c’est génial ?

L’intérêt t’utiliser Ajax sur un site Web ou une application n’est plus à démontrer. Consommation de bande passante réduite, fluidité, possibilités ergonomiques étendues. Néanmoins, ils posent certaines problématiques qu’il est possible de résoudre avec cette nouvelle possibilité

Site Web

Sur un site Web la principale problématique est la complexité d’indexation des contenus affichés en Ajax. Pour l’indexation par Google, la méthode est la suivante :

• Ajouter avant le hash un ! pour avoir une url de ce type http://monsite/#!article/0/spring_c_est_bien. Google comprend alors qu’il s’agit d’un contenu Ajax et pas d’une navigation d’ancre
• Sur ce type de contenu Google va appeler l’url suivante http://monsite/?_escaped_fragment_=article/0/spring_c_est_bien qui devra retourner le contenu html complet

Avec pushstate, il n’est plus nécessaire de faire ce type de configuration, mais il est nécessaire qu’un appel direct aux adresses générées via pushstate retourne le code HTML complet.

Dans ce cas le mode silent de backbone est intéressant, le contenu de la page étant généré complètement par le serveur lors d’un appel direct, il n’a pas à être généré par le client. Ce procédé est utilisé par Twitter.

Si nous accédons à un “Trending-topic” directement depuis la barre d’adresse via cette url https://twitter.com/search?q=%23RolandGarros&src=tren, nous obtenons la page HTML complète :

Mais si nous accédons à la page en cliquant depuis le bloc “tendance”. L’url est la même, mais il entraîne un appel AJAX avec une réponse en JSON :

Application Web

Dans une application Web, la problématique lorsque l’on utilise la méthode des hash est que tout ce qui se trouve après le hash n’est pas envoyé au serveur, donc lors d’une redirection cette information n’étant pas présente, celle-ci est faite sur l’adresse jusqu’au hash, donc la page d’accueil de l’application.

Le cas fonctionnel où ce comportement est gênant est lorsque nous mettons l’adresse en favori où lorsque nous l’envoyons par e-mail. Si pour accéder à la page, ne devons passer par processus d’authentification, nous serons dirigé vers la page d’accueil de l’application plutôt que vers le contenu intéressant.

Pour une application Web, qui n’a pas vocation à être indexée par les moteurs de recherche,  il n’est pas nécessaire que le serveur retourne le HTML complet de la page. Il suffit qu’il réponde à toutes les ressources, le client se chargeant de mettre à jour le contenu en AJAX.

Nous avons fait ceci sur Tatami, lorsque nous accédions à “Trending topic” sans être authentifié :

Avant , nous étions redirigé vers l’accueil lorsque nous saisissions l’url https://tatami.ippon.fr/tatami/#/tags/TatamiV3

Maintenant, nous sommes bien redirigé vers le “Trending topic” lorsque nous saisissons  l’url https://tatami.ippon.fr/tatami/new/tags/TatamiV3

Vous êtes intéressé par AngularJS mais vous n’avez pas pu venir à notre dernier IppEvent consacré au sujet ? Heureusement, Ippon Technologies a filmé l’événement et vous propose les vidéos gratuitement en ligne !

Nous vous proposons donc 3 vidéos :

Sébastien Letélié nous montre le fonctionnement d’AngularJS via une session de “live coding”

ANGULARJS & le futur du développement web from Ippon Technologies on Vimeo.

Thierry Lau et les filtres sur AngularJS

Focus sur les filtres ANGULARJS from Ippon Technologies on Vimeo.

Patrick Aljord sur AngularJS et Firebase

ANGULARJS & le futur du développement web from Ippon Technologies on Vimeo.

L’Ippevent sur les APIs Cassandra change de date en raison d’un appel à la grève lancé par plusieurs syndicats de la SNCF

RDV LE JEUDI 20 JUIN à Partir de 19h00

MERCI POUR VOTRE COMPRÉHENSION

Chez Ippon Technologies, nous utilisons Hector depuis plusieurs années, que ce soit chez nos clients ou pour nos applications Open Source, comme par exemple Tatami.

Hector est un driver très fiable, assez performant, mais qui possède une API complexe, et qui est sans doute trop “bas niveau”. Résultat : le code d’accès à Cassandra est verbeux, ce qui ne facilite pas les développements.

Cette soirée va être l’occasion d’assister à deux retours d’expérience sur les nouvelles APIs Cassandra : sont-elles vraiment simples d’utilisation ? Sont-elles mures ? Que peut-on faire avec ?

1ère partie de soirée : “Cassandra-Java-Driver : vers cassandra 1.2 et au-dela” - Par Vincent BERETTI, manager technique chez Ippon Technologies

Les équipes de DataStax ont releasé récemment un tout nouveau driver pour exploiter pleinement CQL3 et le “Binary Protocol” introduit dans Cassandra 1.2. Pendant cette session, nous présenterons rapidement les concepts et fonctionnalités de ce nouveau driver qui pose les bases de l’avenir de Cassandra.

2ème partie de soirée : “JPA avec Cassandra ? Mission pas impossible!” - Par Duy Hai DOAN, développeur indépendant

Vous avez toujours voulu vous mettre à Cassandra mais vous n’avez pas encore l’occasion de sauter le pas ? Vous le connaissez déjà, mais le code bas niveau vous rebute ? Venez découvrir Achilles, un Entity Manager pour Cassandra qui est là pour vous faciliter la vie.
Durant cette présentation, nous allons créer un clone de Twitter pas à pas avec Achilles en toute simplicité.

Inscrivez-vous à cet IppEvent, qui est comme d’habitude gratuit, sur http://ippevent-cassandra.eventbrite.fr/?ref=etckt

Ou par mail, en demandant une invitation à marketing@ippon.fr

Le French Scrum User Group organise le 26 Juin prochain une “croisière Agile” sur la Seine.
Retrouvez d’autres agilistes sur une péniche amarrée en face de la Tour Eiffel à Paris, à l’occasion d’une rencontre organisée dans la droite ligne des désormais fameuses “Scrum Nights” !

Au programme de la soirée :

• point rapide sur l’actualité du French Scrum User Group
• présentation du nouveau sponsor annuel de l’association : France Télévisions expliquera leur dynamique interne de transition vers l’agilité et les raisons de leur implication dans la communauté agile par le biais du soutien au French Scrum User Group.
• 4 ateliers, sélectionnés par la communauté parmi les propositions émises sur Ideascale. N’hésitez pas à voter pour les sessions auxquelles vous souhaiteriez assister à cette occasion !

La soirée se terminera par un cocktail doublé d’une croisière sur la Seine qui nous permettra de profiter d’une vue pittoresque sur “Paris by night”.

Vous trouverez toutes les informations concernant la soirée ici.

Ippon Technologies est très impliqué dans la communauté agile, notamment par le biais de son soutien au French Scrum User Group en tant que sponsor annuel et sponsor régulier d’événements tels que le Scrum Day. A ce titre nous serons bien évidement présents lors de cette soirée. N’hésitez pas à venir nous  rencontrer pour de discuter de Scrum, de l’Agilité en général, voire même de bien d’autres sujets !

Péniche L’Événement

Ippon sera partenaire Platinum de la 3ème édition du Symposium Liferay France, organisé à Paris.

Rendez-vous le 6 juin pour tout savoir sur les nouvelles fonctionnalités de la première plateforme pour le développement d’applications web innovantes.

Venez rencontrer les experts Liferay d’Ippon et de l’hébergeur Atomes Hosting, les dirigeants de Liferay, les utilisateurs et les membres de la communauté !

Au programme : retours d’expérience clients, présentations techniques sur les meilleurs usages de la solution de portail et zoom sur les nouveautés Liferay.

Yann Vigara, Responsable de l’Offre Cloud Liferay Ippon animera une conférence “Liferay en production”  :

“Petit kit de survie pour la mise en production de votre portail Liferay. Vous découvrirez les bonnes pratiques qui ont fait leurs preuves dans les environnements de production que nous gérons. Vous apprendrez comment sécuriser et optimiser votre Liferay. Nous explorerons les enjeux et les solutions liés au déploiement d’un portail dans le Cloud.”

Horaires et lieu :  de 14h00 à 14h35 dans le Salon Bonaparte.

Vous pourrez aussi rencontrer les équipes Ippon et Atomes Hosting sur le Stand dans l’espace Partenaires.

Pour tout savoir sur l’événement et vous inscrire, cliquez ici

Durant une de mes récentes missions j’ai eu la chance de développer une application HTML5 en mode offline. Cette application a pour coeur de métier le calcul de structures dans le bâtiment. En gros, l’ingénieur bâtiment va sur un chantier avec son laptop ou sa tablette, ouvre l’application et rentre des données de mesures physiques pour voir si à tout hasard le bâtiment ne risque pas de s’écrouler ^^. Toute la logique métier est donc côté client et une connexion au serveur web permet juste de télécharger l’application une première fois, puis de faire des mises à jour.

La grande question est pourquoi avoir choisi des technos Web pour faire une application “desktop” offline ? Tout d’abord c’était un pari sur l’avenir et ensuite plusieurs devices clients étaient ciblés, notamment des laptops et des tablettes, et ça HTML5 sait bien faire. L’argument récurrent contre HTML5 est la compatibilité navigateur. Pour une application interne à l’entreprise, on aurait pu cibler un seul navigateur mais ça n’a pas été notre cas. Le client voulait de la compatibilité Firefox, Chrome et même IE8 ! Heureusement ils ont bien voulu de Google Chrome Frame.

Dans cet article, je vous présenterai donc les différentes technos, APIs que j’ai utilisé pour développer cette application mais surtout je vous dévoilerai les 20% d’écueils qui ont pris 80% de mon temps !

Mode Offline

Mon ingénieur en bâtiment, il n’aura pas forcément de connexion internet sur les chantiers. Il lui faut donc une application capable de fonctionner en mode offline. HTML5 a introduit l’interface ApplicationCache qui va permettre de mettre en cache l’application web et ainsi de se passer d’une connexion internet les fois suivantes.

Le fichier cache manifest

Le fichier cache manifest est un simple fichier texte qui va référencer tous les fichiers de votre application qui doivent (ou ne doivent pas) être mis en cache. Voici un exemple de fichier manifest qui demande à mettre en cache les fichiers index.html et css/style.css :

CACHE MANIFEST
index.html
css/style.css

Ce fichier (“manifest.appcache” par exemple mais vous pouvez lui donner n’importe quel nom ou extension) doit être référencé par votre page dans la balise <html> :

<html manifest="manifest.appcache">
...
</html>

Voilà rien de plus simple. Mais on peut faire un peu plus compliqué. Le fichier cache manifest peut se décomposer en 3 sections :

• La section CACHE : c’est la section par défaut, celle qui va référencer les fichiers à mettre en cache
• La section NETWORK : c’est l’opposé de la section CACHE, ici on va référencer les fichiers qui nécessiteront toujours un accès réseau
• La section FALLBACK : dans cette section on peut proposer des pages de “secours” si des ressources ne sont pas accessibles.

En exemple :

CACHE MANIFEST
# on peut omettre cette ligne car CACHE: est la section par défaut
CACHE:
index.html
css/style.css
# Ressources qui nécessitent que l'utilisateur soit online
NETWORK:
img/logo.png
# offline.html sera utilisé si online.html n'est pas accessible
# offline.html sera utilisé à la place des autres fichiers html si ils ne sont pas accessibles
FALLBACK:
online.html offline.html
*.html offline.html

Ecueils Pas de Wildcards dans la section CACHE

On peut utiliser des wildcards dans les sections NETWORK et FALLBACK mais pas dans la section CACHE ! Si vous avez beaucoup de fichiers dans votre application ça peut être ennuyeux. Je vous conseille d’utiliser un petit script pour générer une première fois votre fichier, sous Unix par exemple :

echo "CACHE MANIFEST" > manifest.appcache; find . -type f | sed "s#^\./##" >> manifest.appcache

Type MIME du fichier cache manifest

Une erreur fréquente est d’oublier de vérifier que votre serveur web sert le fichier cache manifest avec le bon type MIME. Un fichier cache manifest doit avoir le type MIME “text/cache-manifest”. Par exemple dans Apache, vous pouvez rajouter cette ligne dans le fichier de configuration :

AddType text/cache-manifest .appcache

Mise à jour du cache

Tiens bizarre, vous avez modifié votre fichier index.html mais lorsque vous rechargez la page, vous ne voyez pas vos modifications !? C’est normal si vous avez mis en cache votre fichier index.html ! C’est bien là le principe du cache Du coup si vous voulez que votre navigateur mette à jour son cache avec votre nouveau fichier, vous devez modifier le fichier cache manifest.
Je vous conseille d’utiliser une ligne de commentaire avec un numéro de version que vous incrémenterez lorsque vous déploierez une nouvelle version de votre application.

CACHE MANIFEST
# Version 2
index.html
...

(note: le cache peut également être mis à jour programmatiquement via l’api ou lorsque vous effacez le cache du navigateur)

C’est trop bien le cache HTML5 mais en mode développement c’est pas pratique

Effectivement, c’est pas pratique car pour voir vos modifications vous devez en permanence modifier votre fichier cache manifest ! Là plusieurs solutions s’offrent à vous :

• configurez votre serveur web pour que vos fichiers expirent tout de suite
• ne pas utiliser de cache en développement

Ne pas mettre en cache le fichier cache manifest lui-même

Car si vous le faites, votre fichier cache manifest sera en cache et votre navigateur ne verra pas les modifications apportées au fichier cache manifest et ne mettra donc pas à jour son cache ! Il faudra attendre le temps d’expiration du fichier.

Double Rechargement

Lors du téléchargement d’une nouvelle version de votre application, il faut reloader 2 fois la page : une fois pour mettre à jour son cache, une 2ème fois pour vraiment charger la nouvelle version en cache. Pour éviter ce double rechargement à votre utilisateur, vous pouvez utiliser un peu de code Javascript qui va faire ce boulot pour vous :

// On vérifie si un nouveau cache est disponible au chargement de la page
window.addEventListener('load', function(e) {

  window.applicationCache.addEventListener('updateready', function(e) {
    if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
      // Là le navigateur a téléchargé un nouveau cache
      // On change le cache et on recharge la page
      window.applicationCache.swapCache();
      window.location.reload();
    } else {
      // Le cache Manifest n'a pas changé, on ne fait rien
    }
  }, false);

}, false);

Api Localstorage

Robert, mon ingénieur en bâtiment, il avait l’habitude avec son logiciel desktop de sauvegarder son travail, de revenir sur son chantier le lendemain et de reprendre là où il s’était arrêté. Si on était sur une application Web classique, on sauvegarderait notre travail dans une base de données. Mais en offline, il faut composer avec ce que le navigateur nous propose. Il y a les cookies, mais bon la taille maximale d’un cookie est de 4ko, ça fait pas beaucoup. Ce qu’il nous faut c’est donc un espace de stockage :

• de grande capacité
• sur le client
• qui persiste au-delà d’un rechargement de page
• qui n’est pas transmis au serveur

Dans un premier temps on va utiliser le Web Storage et plus particulièrement le LocalStorage qui se comporte simplement comme une Map clé-valeur. Celui-ci répond à tous nos besoins. Par exemple, sa limite de stockage est de 5Mo par nom de domaine. Cette limite est évoquée dans la spécification mais ce nombre peut différer selon les implémentations.

Ecueils String-String

Le principal problème est que le LocalStorage ne propose qu’un mapping clé-valeur où clé et valeur ne peuvent être que des chaines de caractères ! Si vous sauvegardez un int ou un objet, celui-ci sera transformé en chaine de caractères. Lorsque vous voudrez le charger, il faudra coder une petite étape intermédiaire pour retrouver votre objet initial (parseInt() ou JSON.parse() par exemple). Mais si vous ne voulez pas vous embêter, vous pouvez utiliser le petit framework Locache qui possède une API simple de cache et qui permet notamment de sauvegarder vos objets dans le LocalStorage et de le récupérer en tant que tel.

Api File, Filesystem

Robert, qui dépose tous les matins ses enfants à l’école, il est content de pouvoir sauvegarder son travail dans son navigateur. Mais avant il le faisait dans des fichiers qu’il pouvait voir en vrai sur son disque dur. En plus, ça lui arrivait d’envoyer son fichier à son collègue Miguel pour qu’il y jette un oeil. Ok… pas de problème…
Dans une application web classique, c’est le serveur qui envoie un binaire à votre navigateur et ce dernier vous propose de le sauvegarder quelque part sur le filesystem. Mais là je vous rappelle, on travaille en mode offline.

HTML5 introduit plusieurs APIs permettant de gérer des fichiers :

• l’API File permet de lire des fichiers provenant de votre système de fichiers au niveau OS
• les APIs FileWriter et FileSystem permettent de gérer un système de fichier à l’intérieur de votre navigateur. Ce système de fichier est cantonné à un nom de domaine et évidemment vous ne pouvez pas y accéder en dehors de votre navigateur courant. Mais le W3C a tout prévu et l’interface FileWriter possède une méthode saveAs(data, filename) permettant de sauvegarder le fichier sur votre filesystem au niveau OS. Malheureusement cette méthode n’est supporté que dans Chrome. Heureusement, il existe un polyfill pour les autres browsers : FileSaver.js.

Ecueils Support des navigateurs

Ici le principal écueil est le support disparate des navigateurs des APIs de fichiers. D’une part, les APIs fichiers de HTML5 sont compliqués car scindés en différentes API et de l’autre côté, certains navigateurs supportent une Api mais pas l’autre. C’est facile de s’y perdre. Je vous conseille d’utiliser le site caniuse pour se tenir au courant des différentes compatibilités navigateurs.

Modélisation 2D

Autre truc sympa que l’application doit faire, c’est modéliser les différentes structures (poteaux, dalles, …) des bâtiments. Oui, Robert comprend mieux avec des schémas et des dessins. Pas vous ?

Bon ici on était confronté à deux choix : Canvas ou SVG. On a essayé les deux :

• Canvas avec Kinetic.js
• SVG avec Raphael.js

et à vrai dire on était plutôt satisfait des deux. En ce qui nous concerne, ce qui a fait la différence, c’est que SVG c’est du vectoriel. D’une, l’application précédente utilisait du vectoriel et de deux, ces modélisations devaient être imprimé pour être incorporé dans un rapport.

Framework Javascript, CSS

Bien sûr au-delà de HTML5, nous avons utilisé plénitude d’outils et framework Javascripts, CSS. Je ne vais pas les détailler ici, surtout que mes collègues s’y sont déjà attelés :

• Pour la partie MVC : Backbone.js, http://blog.ippon.fr/2012/09/04/presentation-de-backbone-js/
• Pour la gestion des ressources : Require.js, http://blog.ippon.fr/2012/06/07/amd-loader-pour-un-code-javascript-organise-et-performant/
• L’inévitable Twitter Bootstrap. Le thème classique était suffisant et le responsive CSS de Bootstrap était juste nécessaire.

Conclusion

J’ai oublié de préciser que ce développement n’était pas un développement de zéro mais une migration d’application desktop écrite en C++ vers une application web offline écrite en HTML Javascript ! On commence à voir des entreprises de moins en moins frileuses par rapport à ces nouvelles technologies Web et tant mieux ! Le Web existe maintenant depuis plus de 20 ans et est utilisé partout, par tout le monde et tout le temps.

Je pense que HTML5 a de beaux jours devant lui et notamment dans le développement d’applications d’entreprise dites desktop. Les APIs sont là, les implémentations ne suivent pas toujours mais la communauté HTML/Javascript/CSS est tellement bouillante que de nombreux frameworks émergent pour combler les trous. La convergence applications web, applications desktop et applications mobiles sera sans doute HTML5 (ou HTML6 ^^). Seul l’avenir nous le dira.

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.

Le revival du Javascript

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 ?

Le printemps des conférences informatiques parisiennes se poursuit, après Devoxx puis le Scrum Day place aux DevopsDays qui ont eu lieu le 18 et le 19 avril dernier.

Le format de ces journées est assez atypique car elles sont découpées en deux parties distinctes :

• Des conférences le matin concernant la culture devops

• Des “open spaces” l’après-midi afin de favoriser les échanges entre les participants.

Différents types de profils étaient présents : les 100% ops qui cherchent à en savoir plus sur le monde du dev, les devops (50% dev, 50% ops) qui viennent parfaire leurs connaissances et trouver de nouvelles idées, les 100% devs qui cherchent quant à eux, à en savoir plus sur le monde des ops (je me range dans cette catégorie). Vous verrez, en lisant la suite, que le contenu de ces deux jours comblera les attentes des différents profils.

 

Les conférences

 

1ère présentation : CustomerOps ou le devops appliqué au service client.

Cette première présentation nous explique comment la culture devops permet d’améliorer le service client et la qualité de support chez Datadog. Leur définition du devops tient en 4 éléments :

• Culture – Tous les développeurs se succèdent sur les tâches de support client afin de parfaire leur connaissance du produit.

• Automatisation – Automatiser un maximum de processus pour gagner et réactivité et même pouvoir être pro-actif. Automatiser également les sources de retour d’utilisation de l’application (email, réseaux sociaux etc …)

• Mesure – Utilisation de différentes métriques afin de mesurer tout ce qui se passe sur le produit.

• Partage – Exposer ces métriques

2ème présentation : Améliorer ses développements grâce aux devops

https://speakerdeck.com/skade/how-devops-improved-my-dev

Ici le speaker nous explique avec un cas concret comment la culture devops lui a permis d’améliorer la qualité et l’organisation de ses développements.

Grâce à la communication avec les ops il a pu rendre son application plus maintenable et plus facilement déployable en production.

Il a ensuite insisté sur le besoin d’avoir des métriques et du log dans chacune des applications que l’on développe afin d’avoir un maximum de retour sur son utilisation.

Le dernier point important à ses yeux est la polyvalence des développeurs; ils doivent pouvoir passer facilement d’un rôle de dev front à personne en charge du déploiement de l’application.

 

3ème présentation : Projet ou produit ?

https://speakerdeck.com/elpicador/how-products-can-improve-projects

Cette présentation nous montre tout d’abord les différences entre un produit (totalement orienté client) et un projet plus géré en fonction de son coût et des délais impartis.

Ensuite le speaker nous présente quels sont à ses yeux les clés du succès d’un produit :

• Construire rapidement un MVP : Minimum Viable Product

• Mesurer en ayant des feedbacks réguliers sur son produit

• Apprendre de ses erreurs afin de construire un produit meilleur

Ces éléments ne sont pas valables seulement pour un produit mais aussi pour un projet : “Think product, do project”

 

4ème présentation : Transformer des devs en devops

Fabrice Bernhard nous présente les éléments mis en place chez Theodo pour former ses développeurs junior à la culture devops.

La clé est d’intéresser ces nouveaux développeurs aux problématiques des ops en les confrontant à la production et en organisant du “pair devopsing” lors des phases de développement et de déploiement de l’application. Il faut ensuite les sensibiliser à l’utilisation des bons outils (mise en place de bacs à sable pour effectuer des tests) et aux problématiques de performances.

Cependant cela ne fait pas tout et un bon dev ne devient pas devops grâce à des outils. L’expérience et la responsabilité de la plateforme sont des bons leviers pour devenir devops.

 

5ème présentation : How we release software for gov.uk

Retour d’expérience sur  la “success story” anglaise du moment : la refonte du site du gouvernement.

Tout part d’un rapport intitulé “Revolution not evolution” qui préconise de créer un centre d’excellence pour rationaliser les services existants puis mettre en place les nouveaux services numériques du gouvernement. S’en suit une une accélération des cycles de livraison (4h pour envoyer un développement en production, 20 déploiements par jour),  une simplification des interfaces, une plus grande transparence (publication sur GitHub, ouverture des API), une refonte graphique (titre de “Design of the year 2013”). Leur mot d’ordre pour développer ce site est “digital services so good that people prefer to use them”.

Le site est effectivement, clair, pratique et utilisable depuis d’autres applications car toutes les données sont accessibles via une API ou en JSON. Exemple de question simple d’utilisation : Quand s’effectue le prochain changement d’heure ? https://www.gov.uk/when-do-the-clocks-change ou https://www.gov.uk/when-do-the-clocks-change.json

Toujours dans un esprit de transparence et de partage leur façon de travailler est expliquée sur ce même site : https://www.gov.uk/service-manual

 

6ème présentation : Map & Territory: A story of visibility

Cette présentation part du principe qu’une fois un produit ou projet en production on passe la majeure partie de son temps à effectuer des corrections. Si l’on veut réduire ces temps de corrections on a besoin d’extraire des informations qui ont un sens depuis des sources de données hétérogènes (logs, base de données, …). Ces informations nous permettront de mieux comprendre l’utilisation faite du produit.

Avant de les extraire il faut définir des métriques clés qui indiqueront quels sont les éléments à surveiller aussi bien techniques que métiers.

Le speaker explique ensuite l’approche “event stream” : “Plenty of small producers, few big consumers”. Tout ce qui bouge doit être loggé pour être ensuite agrégé puis corrélé avec les autres métriques. Suite à cela, une décision peut être prise sur le plan d’action à mener pour corriger ou enrichir une fonctionnalité.

L’ensemble de ces métriques forme donc une carte de l’application qui nous permet de surveiller le territoire (application).

 

7ème présentation : Les 10 pièges à éviter lors d’une transition devops

Dans cette présentation les speakers nous indiquent les pièges dans lesquels il ne faut pas tomber lors de la mise en place d’une approche devops dans un projet.

Ces quelques conseils résument bien l’ensemble de ces deux jours :

• Devops ce n’est pas que de l’outillage mais un ensemble outil + processus + culture

• Il ne faut pas penser qu’au déploiement de l’application mais plutôt à la vie de l’application dans son ensemble.

• Il ne suffit pas de désigner des équipes devops, la transition doit être faite par les équipes elles même. L’utilisation d’un coach Devops peut être nécessaire pour les aider.

• Les aspects culturels ne sont pas à négliger et certains éléments de la transition agile peuvent être utilisés :

• Amélioration continue

• Collaboration entre les équipes

• Transparence

• Il faut mesurer un maximum de choses afin d’évaluer les progrès effectués

• Ne pas oublier l’amélioration continue

Suite aux conférences quelques Ignite Talks (présentations de 5 min chronométrées) ont eu lieu. Dur de creuser un sujet en ce court laps de temps mais quelques slides sympas :

• Si Devops avait été inventé par Coca-Cola : http://www.slideshare.net/devopsdays/what-if-devops-was-invented-by-coca-cola

• Tests de performance en continue : http://devopsdays.org/events/2013-paris/proposals/PerformancesPerpetuellesIgnite/

Les openspaces

 

Les openspaces sont des espaces de discussion libres où les règles suivantes s’appliquent :

• Les personnes qui se présentent, sont les bonnes.

• Ce qui arrive, est la seule chose qui pouvait arriver.

• Ça commence quand ça commence.

• Quand c’est fini, c’est fini.

Les thèmes des différents openspaces sont proposés au préalable par les personnes présentes aux DevopsDays, puis chacun s’inscrit aux discussions de son choix. Les participants aux openspaces ne sont pas obligés de rester tout le long de la discussion et sont même invités à aller de salle en salle pour assister à différentes discussions.

Ce format est assez intéressant car il permet de recueillir et d’échanger rapidement et facilement des idées assez variées sur un même sujet. Cependant les discussions étaient parfois décousues ou s’éloignaient assez rapidement du sujet de base. Dur pour un pur dev de rentrer dans certaines discussions mais néanmoins quelques discussions intéressantes où l’on sentait que les ops veulent mieux comprendre le monde des devs afin d’améliorer la qualité de leur travail et inversement.

 

Conclusion

Ces deux jours ont été très intéressants et plutôt surprenants. Je m’étais préparé (man page sur les genoux) à assister à des conférences très techniques qui parleraient de virtualisation, de configuration réseaux, de scripts de déploiement, etc … Pas du tout, les conférences étaient parfaitement accessibles et très orientées cycle de vie du projet.

L’élément le plus souvent cité est le fait de mesurer un maximum de choses sur une application. De ces mesures découleront un meilleur retour sur l’utilisation et une meilleure réactivité des équipes en charge de la maintenance du produit.

D’autres éléments présentés rejoignent aussi des arguments déjà entendus dans des conférences agiles : améliorer la communication entre les équipes, réduire les silos, apprendre en continue de ses erreurs, chercher à s’améliorer, partager ses connaissances, …

Suite à ce printemps de l’informatique, on se rapproche donc tout doucement de la recette magique pour développer rapidement une application de qualité : des équipes impliquées, une grande dose de communication, une cuillère d’agilité le tout agrémenté de métriques permettant d’avoir un retour constant.

 

En bonus quelques bons mots des devopsdays :

“I don’t want to be woken up at night, so I call myself a developper”, Florian Gilcher

“Speed is important but momentum is everything”, Kushal Pisavadia

“It’s not the big that eat the small, it’s the fast that eat the slow”, Fabrice Bernhard

“Think product, do project”, Rémy-Christophe Schermesser

Au pays des frameworks JavaScript MVC, AngularJS est une valeur montante. En rutpture avec les autres frameworks MVC, Anugular est fondé sur une approche déclarative et la mise en oeuvre de composants pour concevoir les IHM web. Il adapte et étend le HTML traditionnel pour servir le contenu dynamique via un mécanisme de data-binding permettant la synchronisation automatique des modèles et des vues. Bref, AngularJS réduit considérablement le besoin de manipuler le DOM HTML et produit du code plus concis et facile à tester.

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

Une soirée chargée et riche en perspective. Pour vous inscrire comme à chaque fois, utilisez le bandeau ci-dessous.

Gestion d’un événement pour Ippevent AngularJS réalisé par Eventbrite

Une fois n’est pas coutume, il ne s’agit ni d’un post technique ni d’une annonce concernant les Ippevents, mais ayant publié une quarantaine d’articles sur ce blog depuis 2009 je me suis permis de l’utiliser pour vous dire au revoir.
Le 27 mai prochain je quitterai le monde de l’ESN (avant on disait SSII mais ça, c’était avant) pour commencer une nouvelle aventure en tant que “Senior Software Engineer” chez Red Hat. Conscient de ce que je dois à Ippon, je souhaitais revenir sur mon parcours et donner une idée de comment une carrière peut se dérouler au sein de la société.

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 !”