fév
14

Prise en main de Couchbase

Cette semaine je me suis déplacé à la Cantine Numérique de Nantes pour assister à la soirée nosql du JUG. Thématiques abordées : Couchbase et MongoDB. Maintenant que je commence à avoir une bonne prise en main de Mongo, la présentation de Tugdual Grall aidant (comment ne pas être convaincu par un triathlète !), je me suis décidé a tester Couchbase. Pour moi ce n’est pas une inconnue non plus car j’ai beaucoup utilisé Memcached jusqu’à présent. De plus, avant de passer sur Mongo, j’utilisait CouchDB lorsque j’ai pris mes distances avec SQL. Je vais vous parler de mon cas : développeur sous MacOS ayant une expérience de MongoDB. C’est parti pour la prise en main de Couchbase !

Installation

Tout d’abord, au niveau du téléchargement MongoDB et CouchBase sont similaires : tout deux proposent des téléchargements pour Windows, Mac et Linux. Le code source est également disponible. Concernant MacOS, le fichier à télécharger fait la même taille : 50Mo grosso modo. L’avantage de Couchbase est qu’il fournit un wizard pour l’installation ainsi qu’une icône pour la barre du haut. Celle ci permet notamment d’effectuer des mises à jour, de gérer le serveur et d’accéder à l’interface d’administration graphique. MongoDB lui se contente de fournir une archive à placer typiquement dans /opt par exemple. Il n’y a pas d’interface graphique ni de système de mise à jour. Pour la configuration de base, on suit les étapes qui aboutiront à la configuration d’un bucket.

Interface d’administration

Le gros point fort de Couchbase : avec l’interface d’administration on peut tout faire ! C’est à la fois un outil qui peut être mis à disposition des administrateurs systèmes mais qui est également très pratique pour les développeurs. Toutes les opérations possibles sont disponibles dans cette interface. Bien sûr ces opérations sont également accessibles via une API REST et un outil en ligne de commande.

L’écran d’accueil est un dashboard qui nous montre l’état du cluster : serveurs up/down, mémoire utilisée, espace disque utilisé, opérations par secondes… Bref une belle interface de monitoring. On peut également avoir le détail sur l’ensemble des serveurs. Lorsque vous installer CouchDB sur une autre machine, vous aurez la possibilité de rejoindre le cluster existant uniquement en connaissant l’adresse IP et le mot de passe administrateur. Il n’y a pas d’opérations supplémentaires. L’inverse est également possible : depuis l’interface vous pouvez faire rejoindre un serveur existant à votre cluster (mais les données seront supprimées sur ce dernier ! un message vous avertira). C’est beaucoup plus simple qu’avec MongoDB ! Le failover se configure simplement également.

On a également accès aux logs et aux paramètres : notamment des alertes par email ou la compaction des bases.

Tester Couchbase avec l’interface graphique

Comme je le disais, le développeur peut utiliser cette interface d’administration. Il peut notamment créer directement des documents et les éditer en JSON dans le navigateur. Il peut également les supprimer.

On a également la possibilité de créer des vues. Finalement ce sont des opérations de type Map / Reduce que le développeur va créer en développement par exemple. Il va pouvoir tester son fonctionnement sur un sous ensemble de données puis passer sa vue en production avec cette fois-ci l’utilisation de toutes les données. C’est CouchDB qui gère en tâche de fond l’exécution du calcul, soit sur une base d’intervalles de temps soit sur un certain nombre de requêtes. L’affichage du résultat n’est donc pas forcément en temps réel. La syntaxe semble similaire à MongoDB :

Ecrire du code

Bien sûr une fois pris en main à ce niveau-là on veut tout de suite voir ce que ça donne au niveau du code. Tout comme pour MongoDB, il existe de nombreux drivers. En ce qui concerne Java, il y en a quatre : Ektorp, JRelax, jcouchdb et CouchDB4J. Je n’en ai testé aucun. CouchDB4J me paraît intéressant : il propose une API simple. En général, je ne suis pas pour le mapping lorsque l’on travaille en nosql, c’est une perte de temps et cela rigidifie l’application. Je vous mets un bout de code pour la forme :

Session s = new Session(« localhost »,5984);
Database db = s.getDatabase(« foodb »);

Document doc = db.getDocument(« documentid1234″);
doc.put(« foo », »bar »);
db.saveDocument(doc);

Document newdoc = new Document();
newdoc.put(« foo », »baz »);
db.saveDocument(newdoc);

ViewResult result = db.getAllDocuments();
for (Document d: result.getResults()) {
System.out.println(d.getId());
Document full = db.getDocument(d.getId());
}

Il n’y a que très peu de différences avec le driver officiel Java pour MongoDB. Les drivers Java fournis en exemple par Couchbase sont des projets communautaires.

Concernant Node.js, il existe le paquet Cradle. Il n’est également pas officiel mais semble très actif. On peut l’installer directement avec npm. La syntaxe est bien dans l’esprit de node.js avec la notion de callback nécessairement utilisée. Cradle supporte également les vues.

Il y a pas mal de pull requests et des tâches en cours. C’est plutôt bon signe.

Bien sûr vous pouvez aussi vous contentez d’utiliser uniquement l’API HTTP. C’est un choix à faire.

Architecture

Pour une fois, je n’en parle pas trop. L’objectif de l’article était de prendre en main Couchbase et de voir rapidement ce qu’on pouvait en faire. Celà dit c’est toujours intéressant de savoir ce qu’il y a sous le capot. Typiquement, il s’agit d’un serveur HTTP qui expose une API pour effectuer toutes les opérations sur les bases en appliquant le principe  du Fire and forget (port 8092). Il est également possible de s’y connecter avec le protocole memcached (port 11211/11210). Toute la gestion du cluster (dont notamment le fail over) est développé en Erlang. Le reste est écrit en C.

Conclusion

L’interface graphique m’a convaincu, l’entreprise qui supporte le projet aussi et l’architecture de la solution semble véritablement bien huilée. Memcached est une solution connue et utilisée depuis longtemps : Couchbase contribue au projet pour son « Object-Managed Cache ». La gestion de cluster par Erlang est également un gage de crédibilité. Maintenant la prochaine étape pour moi : c’est de faire un PoC et d’écrire du code. Je crois que je vais ressusciter mon URL Shortener et enfin le mettre en ligne : https://github.com/loicguillois/lgu.me

 

oct
04

JugSummerCamp 2012

Première approche

Vendredi 14 septembre, j’ai pu me rendre à une journée de conférences Java et de technologies gravitant autour à La Rochelle. Comme l’année dernière, l’événement a eu lieu près du port à l’espace ENCAN. Cette année la thématique s’est tourné vers le cloud et le développement dans un cadre plus large.

Pour commencer nous avons été accueillis autours d’un café c’était très sympa. J’ai reconnu quelques speakers et personnes déjà présentes l’année dernière mais surtout toujours autant de passionnés près à passer un vendredi éducatif. Dans le même temps Karl retrouve une de ses connaissances, un ancien collègue avec qui on va également passer la journée.

Les hostilités démarre par le speak d’ouverture de Nicolas De Loof. Très axé sur l’humour autour de notre métier de développeur, il a mis en scène ses compères les castcodeurs avec des marionnettes. On applaudit tous en coeur, voilà la journée est lancée.

GoogleTV : point de vue d’un développeur Android

Pour commencer la journée j’ai naturellement voulu assister à la conférence sur la GoogleTV présenté par Olivier Gonthier de chez Zenika. Zenika a d’ailleurs eu la gentillesse d’offrir une Logitech Revue à l’un des participants.

GoogleTV à l’origine, c’est un fork de la version d’Android 3.1 adapté TV avec notamment l’absence de gestion d’écran tactile et avec les applications qui s’affichent uniquement en paysage (écran large et pas de flip. Scroll vertical proscris et navigation horizontale préconisée). L’intégration de Google Play et d’un vrai navigateur (Chrome) en font une plateforme plus que jamais connectée. Elle a été présenté au GoogleIO en 2010 (à l’origine Logitech et Sony, soit sous forme de box soit sous forme intégré dans une TV). GoogleTV est restée non disponible en France jusqu’à il y a quelques jours. Aujourd’hui il y a de nouveaux constructeurs dont Vizio, HiSense.

Le principe de GoogleTV est d’incruster un overlay vidéo et sonore directement au niveau du flux HDMI.  Un clavier est disponible ainsi qu’une télécommande avec Touchpad pour Sony (clavier complet au dos). Le mode d’affichage picture in picture (live intégré, notamment pour les pubs, les jeux) est accessible depuis un bouton de la télécommande.

A noter que le gros point faible sont ses limitations du SDK pour le développeur :

  • impossible récupérer le flux vidéo/audio
  • pas de «Picture in Picture»
  • pas de localisation précise (les GoogleTV sont dépourvues de GPS)
  • impossible de connaître la chaîne courante (car flux HDMI)

Et évidemment, les fonctionnalités liées au téléphone, les capteurs (accéléromètres…), micro, caméra etc. ne sont pas disponibles.

En revanche, il est possible de réaliser quelques choses sympas :

Un émulateur est disponible uniquement sur Linux malheureusement il n’est pas possible d’utiliser une machine virtuelle car celui-ci fait appel à des fonctionnalités natives. La meilleure solution consiste à disposer d’une clef USB bootable si comme moi vous travailler sous MacOS ou avec Windows. Google serait en train de travailler sur une alternative actuellement en cours de développement. Il est également possible de faire du remote debugging via le réseau local.

Le market Google Play permet de réaliser des packages pour TV, téléphone, tablettes ou un mix. Le fonctionnement reste identique en comparaison du déploiement d’applications tablettes ou smartphone.

Un dernier point technique sur le développement concernant les applications HTML5. Il faut savoir que cette partie est mieux documentée que Java (SDK). La navigation se fait par événement clavier Javascript (tout comme sur les TV connectées). L’autozoom est activé par défaut et il est possible de le désactiver pour mieux contrôler le rendu final en utilisant les feuilles de styles de la bonne manière (respect des standards). Google propose également des templates complet (HTML/CSS/Javascript). Il ne reste plus qu’à injecter le contenu. Ce système peut être pratique pour du prototypage notamment. Contrairement au SDK, Google fourni une checklist pour valider l’application point par point. La majorité des points évoqués sont applicables à toute application Web.

Enfin un dernier détail, pour les webmasters il est possible de mettre en valeur le contenu des vidéos d’un siteweb en réalisant l’équivalent du sitemap mais cette fois ci pour les vidéos. Le moteur de recherche de Google indexera ainsi le contenu et ira même jusqu’à mettre en avant les flux live en cours de diffusion.

Node.js : Un riche retour d’expérience

De loin la présentation que j’attendais le plus ! Je voulais comparer mon expérience avec celle d’un autre développeur. Finalement, la majorité des concepts mis en avant, je les avais compris et les choix techniques sont similaires. J’ai pu voir que Romain Maton avait un bagage plus important sur node.js ce qui me permet d’aller encore plus loin sur certains aspects.

Tout d’abord il a évoqué les différents modules «tout en un» qui permettent de rapidement prendre en main node.js sans avoir à chercher quel module utiliser pour telle ou telle chose. Ici les choix sont faits et un peu de documentation pour accompagner. Il a notamment conseillé l’utilisation de node-express-boilerplate. Personnellement je préfère prendre le temps de comprendre ce qui est utilisé quitte à me tromper et à perdre du temps mais au moins la compréhension n’en est que plus grande. Cela dit pour un futur projet pourquoi pas. Le risque avec ce type de module c’est de faire des amalgames entre ce que fait node.js de base et ce qui vient d’un module tierce.

Sans hésiter il a évoqué Express.js (qu’on utilise à Gamific), celui ci est le plus répandu et le mieux documenté. Aujourd’hui la communauté autour de ce module est conséquente. Un point que je n’avais pas remarqué, c’est la possibilité d’utiliser app.param avec expression régulière pour filtrer les URI. A mettre en oeuvre !

Pour les templates, sans surprise, c’est jade qui est également évoqué. J’ai longtemps hésité à l’utiliser ou pas, notamment par le fait que la syntaxe XML de l’HTML est perdue, mais il faut reconnaître qu’à l’usage le code Jade est davantage lisible car bien indenté et moins verbeux.

Pour la communication avec le client, socket.io est cité. Je connaissais et j’avais utilisé mais là il a parler en particulier des rooms et c’est vrai que c’est extrêmement pratique. Cela permet de bien compartimenter les communications et avec peu de lignes de codes. J’ai notamment pu l’expérimenter sur des navigateurs supportant Websocket et d’autres non (donc XHR-Polling). La négociation sur le protocole à utiliser est automatique et transparente.

Node.js est particulier dans le sens où tout est synchrone et fonctionne par callback. aync.js permet la gestion des stacks de callback .

D’autres modules ont été cités et c’est vrai qu’il me manquait tout ça pour aller en production :

  • winston (logging)
  • nodemon / supervisor (rechargement à chaud)
  • forever (relancement de node.js en cas de crash)
  • zombie / vows (tests)

Il a présenté comment créer des modules au sein de son application. De toute façon, en développant on se rend compte rapidement du besoin de séparer son code. On peut comparer ce mécanisme à celui des controlleurs dans Play! Un module s’occupe du traitement de certaines URL (module User, module API etc.)

Le module asset est très utile il permet de gérer les ressources javascript et CSS par exemples et de les concaténer/compresser.

Il existe un site Web https://npmjs.org qui référence l’ensemble des paquets en fournissant quelques statistiques d’usage afin de faire son choix sereinement. Dans le même état d’esprit, sur la documentation officiel, on trouvera un indice de ‘stability’ pour l’API qu’il faudra prendre en compte.

On a fait le tour des solutions d’hébergement dans le cloud, j’avais déjà utiliser Heroku, les autres ont l’air tout aussi intéressant car spécialiser sur node:

HTML5, Spring, NoSQL et mobilité

Beaucoup de buzz words dans le titre de cette présentation. Celle ci s’est tournée en une présentation de l’architecture et des technologies utilisées par l’application Tatami. Bien que certains thèmes soit abordés avec une certaine rigidité et conception simplifié de la réalité, cette présentation était parfaite pour le développeur J2EE qui veut découvrir comment faire du Java différemment, du Java tourné vers le Web et les applications modernes. Cette présentation est signée Julien Dubois, un expert reconnu de Spring.

Alors on commence par la présentation rapide des nouveautés concernant les formulaires HTML (et oui, dans les applications de gestion c’est la majorité du contenu des écrans). En vrac :

  • Champs texte (input) de type=»email»
  • Attribut required
  • Attributs min, max

Vous l’aurez compris ces nouveautés permettent aux derniers navigateurs de faire eux même la validation des formulaires sans écrire une seule ligne de JavaScript. Le gros inconvénient ici, c’est que le développeur n’a pas la main sur le comportement/rendu graphique. Mais comme dit plus haut, en entreprise ça suffira peut être (au moins dans un premier temps).

La bibliothèque atmosphere est évoquée. Puis quelques généralités sont présentées sur HTML5, CSS3 et websocket. Ensuite on arrive sur une partie un peu plus technique avec un roundup des solutions de stockage de données au niveau du navigateur :

  • web storage
  • indexed database
  • web sql database : pas supporté par IE et Firefox, en pause au W3C (il manque plusieurs implémentations pour en faire un standard)

Les technologies permettant le développement de jeux (entre autre) sont survolées en un slide : canvas, 3D avec WebGL, audio et video. On aura rien appris sur ce coup là. Surtout que Julien enchaîne en nous expliquant que coder le html/css/javascript à la main est de plus en plus compliqué et qu’il faut encore attendre 2 à 3 ans que HTML5 mûrisse. Sa conclusion : des outils sont nécessaires pour réussir une appli web : jQuery, Twitter Bootstrap, Mustache, Underscore, Backbone. On sent le fan de Spring ! C’est d’ailleurs dommage que la partie développement mobile se limite à un «il n’y a rien à faire, Twitter Bootstrap fait tout tout seul».

La partie nosql nous présentera la base de donnée Cassandra dont les avantages dans les grandes lignes sont:

  • montée en charge «élastique», sans effort
  • complexe à héberger
  • non consistance des données
  • pas de transaction
  • retour de la couche DAO
  • pas de recherche full texte

Bonne présentation malgré tout pour le débutant qui ne sait pas par où commencer et qui veut se lancer dans du développement d’applications innovantes.

Dart : apologie de l’échec

Je vais passer rapidement cette conférence, l’article étant déjà assez long et cette présentation n’en vaut pas la peine. En bref, il s’agit d’un langage de script côté client et serveur présenté comme une alternative de JavaScript et conçu spécifiquement pour le Web. Il existe déjà un certain nombre de chose pour développer : un IDE (Dart Editor), une VM (Dart VM), un navigateur (Dartium) et également un outil de compilation (Dart2js).

Au delà du fait que Dart ne soit pas du tout prêt pour la production (ils sont en alpha et le support par les navigateurs Web du marché est inexistant), l’ensemble de la présentation était tourné comme un troll envers JavaScript agrémenté de jeux de mots lourdingues et de photos décalées dans la présentation (en vrac : les Spice Girls, Johnny Halliday, un détournement de notre Président). Bref.

J’ai trouvé cette présentation ridicule, le sujet n’étant pas maitrisé (je pense à JavaScript) et la démonstration n’a même pas marché. Maintenant j’ai la conviction que Dart n’a que peu d’avenir (sauf si quelqu’un de sérieux vient m’en parler et réussit à me convaincre).

Beaglebone : l’esprit hacker

Une présentation comme je les aime : du technique et du geek. Un retour aux sources d’une belle manière sur le matériel avec la présentation du Beaglebone et plus généralement de cette génération de cartes mères low cost dont on peut faire à peu près tout avec un peu d’imagination.

Tout d’abord le Beaglebone dans les grandes lignes : processeur ARM v7 Cortex A8 et processeur 3D. De quoi avoir une puissance de calcul non négligeable ! Les 256Mo de mémoire vive et le lecteur de carte microSD permettent de faire tourner un Linux et tout ce qui compile sur cible ARM. Tout cela dans la taille d’une carte de crédit et ne consommant que 2Watts. On en trouve à 80 $ environ.

Dans ce milieu on entend souvent parler d’Arduino, mais ça n’a rien à voir. Il s’agit d’un micro-contrôleur et à ce titre il ne dispose pas d’OS (que l’on peut choisir) mais d’un firmware qui ne vous permettra de faire tourner uniquement des programmes écrit en langage C (sic!). A ces conditions de développement spartiates s’ajoute un matériel vraiment limité : processeur à 16MHz et la mémoire programme de 4Ko à 128Ko selon le modèle. L’avantage ici reste le coût dérisoire et une consommation électrique encore revue à la baisse.

Un concurrent sérieux : Raspberry Pi. Depuis quelques semaines on voit fleurir sur Twitter le nombre de possesseurs de cette fameuse carte en France. L’architecture est similaire au BeagleBone avec un processeur ARM 700Mhz. L’inconvénient principal de celui ci reste qu’il est livré «nu», la carte seule et que la documentation reste légère comparé au BeagleBone.

Concernant BeagleBone, on a évoqué tout ce qui était possible : station météo, domotique, robotique, openCV et openNI (reconnaissance faciale, mouvement comme sur la kinect…). On peut ajouter à un BeagleBone tout un tas de cartes-filles qui communiqueront avec les ports de notre carte (analogique ou numérique) : GPS, accéléromètre, écran LCD, capteurs divers… en fait tout ce que l’on peut trouver dans un smartphone actuel et bien plus encore.

L’accent a été mis sur la distribution ångström qui permet d’installer Linux avec une excellente prise en charge du matériel de la carte. C’est d’ailleurs la distribution qui est fournie avec le BeagleBone sur une MicroSD. Le noyau est à jour et l’environnement logiciel est préconfiguré avec notamment node.js et Cloud9, de quoi se lancer sereinement dans l’aventure matérielle en tant que «simple» développeur.

Intégrez du BPM dans vos applications métier avec Bonita Open Studio

Cette présentation était dynamique, l’objectif était de montrer comment mettre en place une application de «call for paper» de la création jusqu’au vote en passant par l’approbation. Bonita est très graphique et permet à des profils non techniques de dessiner véritablement le processus qu’ils souhaitent voir implémenté dans l’application. Les formulaires peuvent être générés et des actions du type «envoi de mail» peuvent être créées et un backoffice est disponible ce qui revient à créer l’application sans écrire une seule ligne de code et ainsi créer une application process centric deux fois plus rapidement (c’est le discours marketing mais je le pense aussi). Une autre approche est possible en intégrant Bonita au niveau du code (bibliothèque Java et API). A tester à l’occasion, c’est dans le même esprit que Talend (un ETL) et d’ailleurs les deux fonctionnent ensemble.

Conclusion

L’organisation était un peu différente de l’année dernière, il n’y a pas eu de talk de clôture, ça manquait un peu je trouve mais sinon le contenu des présentations était sympa et dans une bonne ambiance. Le midi l’idée des Quickie était une très bonne idée, mais du coup pour ma part je suis parti manger à l’extérieur. J’ai loupé ça. J’espère pouvoir récupérer les vidéos ou les slides de quelques uns, notamment la présentation de Cassandra. Pour conclure merci aux speakers, aux sponsors et surtout aux organisateurs !

août
02

Développement de l’application HbbTV Roland Garros

Cela fait quelques temps que je devait écrire un billet sur le sujet du développement d’applications Web pour les TV. Je vais donc vous raconter l’aventure de ce mois de mai 2011 durant lequel avec quelques collègues et en collaboration avec IBM nous avont réussi à développer une application en 1 mois pour le compte de France Télévision.

Le développement Web sur TV

Chez Wiztivi, nous sommes des pionniers de la télé connectée et forcément ça aide. Nous sommes en contact permanent avec les constructeurs et les différents acteurs de l’IPTV, y compris (bien sûr) notre principal actionnaire : SFR. L’environnement de développement classique d’un développeur d’applications TV, c’est un PC et pleins de TV : différentes marques, différents modèles, différents firmwares mais aussi quelques box ADSL et consoles de jeux :-)

Du point de vue des technologies, ça reste du standard : HTML, CSS, Javascript. La plupart des TV intègre aujourd’hui WebKit ce qui nous facilite le travaille mais il reste malgré tout de nombreuses différences entre TV ce qui nécessite un effort particulier d’intégration et de tests. Il y a aussi les spécificités de chaque marque : API propriétaire et lecteurs vidéo différents. Finalement, l’environnement n’est pas plus contraignant que de réaliser une application Web classique qui soit fonctionnelle sur la majorité des navigateurs du marché (Firefox, Chrome/Safari, Internet Explorer, Opera).

En terme d’usage des applications, tout se pilote depuis la télécommande ce qui a notamment des impacts sur la gestion de la navigation et du focus. Il nous arrive également de devoir gérer des widgets spécifiques à la TV comme un clavier virtuel ou des players video.

La technologie HbbTV

Jusqu’à présent la solution la plus utilisée pour déployer des applications Web sur TV et box étaient d’héberger celles ci sur un serveur. Le constructeur intégrait le lien vers l’applications via son firmware. De ce fait, les communications passent par la prise ethernet de la TV/Box. HbbTV est une nouvelle approche qui permet au contraire de diffuser l’application dans le flux TV. L’idée est d’ajouter des informations au niveau de la TNT. Ainsi ce sont les chaînes qui peuvent désormais diffuser des applications.

HbbTV propose deux modes de fonctionnement : broadband et broadcast. La première approche est assez classique : on va définir une URL dans le flux. Lorsque l’utilisateur arrive sur une chaîne, l’application est chargée depuis cette URL. La communication passe donc par la prise ethernet et fonctionne (presque) comme une application standard : on peut notamment faire des requêtes XHR. La seconde approche est différente. Elle permet de diffuser l’application dans son intégralité dans le flux. Les performances sont donc tributaire du débit TNT et nous oblige à restreindre la taille des images et la quantité d’informations à envoyer à la TV. L’application peut malgré tout se mettre à jour par des informations qui sont mise à jour au niveau du flux (le carousel et les stream events). Développer une application broadcast est donc très contraignante pour le développeur et ça on s’en rend compte quand on développe, pas en lisant les spécifications du standards qui de toute façon ne sont pas respectées à la lettre.

Les TV qui supportent cette technologie ont commencé à apparaître sur le marché français en début d’année. Elles devraient se démocratiser en 2012. On peut dors et déjà acheter, par exemple, cet TV Toshiba de 42 pouces (800€).

France Télévision et HbbTV

France Télévision avait déjà effectué une démonstration à l’IFA. Cette application sera prochainement diffusée au niveau national mais pour la chaîne public le vrai grand test se déroulait en ce printemps 2011. L’idée du projet Roland Garros était de montrer que l’usage de l’HbbTV permet un usage enrichie de la TV. On parle d’ailleurs souvent de « télétexte HD ». France Télévision fait partie du consortium qui développe HbbTV et souhaite réellement devenir leader sur ce thème sur le plan national.


L’application Roland Garros

Les internationaux de Tennis intéressent énormément de monde et chaque jour France 2 et France 3 diffusaient de nombreux matchs. Le but de l’application est d’apportée le maximum d’information aux utilisateurs : résultats en direct (y compris pour les matchs qui ne sont pas en cours de diffusion), les fiches des joueurs et un album photo. Il y a différents modes d’affichages et on peut basculer à volonté entre le live et l’application grâce à la télécommande. L’application était disponible uniquement en broadband. Une popup « Veuillez connecter votre TV » apparaissait si nécessaire. Voici une vidéo de démonstration :

Architecture nosql

Les données nous ont été mise à disposition par IBM. De notre coté nous avons donc développé une application HTML/CSS full javascript. Pour les besoins de mise en forme des informations et de performances, nous avons mis en place un serveur d’application avec une application Spring connectée à la fois au backend IBM et à une instance MongoDB hébergée localement. Ainsi nous avons mis en place un batch qui régulièrement importait et mettait en forme les données (XML) dans notre base. Il faut savoir que nous recevions énormément d’information pour tout les matchs en cours. En fin de tournois, nous avions plusieurs giga de base de donnée. Mongo nous a permis de construire un modèle de donnée prêt à l’emploi notamment pour le résultat des matchs et la construction du tableau de classement. Nous avons utilisé Morphia afin de conserver une approche objet au niveau de notre code Java. Nous utilisions Spring ensuite pour sérialiser ces données en JSON au travers de webservices directement exploitable par les frontend par requêtes Ajax.

Nos outils

Personnellement, je travaille sous Ubuntu. Nous avons utiliser Eclipse et essentiellement Chrome couplé à ses outils de développement pour le développement des interfaces Web. J’ai apprécié l’iPad et l’application France Télévision qui permet d’avoir le live sur mon bureau. C’est appréciable de voir que l’interface de notre application se rafraîchis plus vite que la plupart des sites Web en ligne publiant les résultats de Roland Garros.


Conclusion

Au final, développer une application HbbTV demande surtout d’être en contact avec les constructeurs et d’être alaise techniquement en dehors des technologies Web. En interne, nous utilisions une carte de diffusion (Dektec) ainsi que la solution bien connu dans le milieu : OpenCaster. Heureusement que Karl s’y connait bien  ;-) Sans lui ça aurait été difficile !

A noté que Wiztivi a également développé l’application HbbTV pour NRJ12. De mon coté, le prochain article sur la thématique TV parlera de Google TV mais je suis de près aussi Apple TV.

Go back to top