Un bon Karma au Devoxx Paris 2013

Retour sur les 2 jours que j’ai passé au Devoxx Paris 2013.

Pour cette édition j’avais décidé de me borner à quatre thèmes qui me tiennent à coeur : le développement d’applications web modernes, le NoSQL, l’intégration continue et les outils de tests.

À partir du large programme qui se présentait devant moi, j’ai donc procédé à la sélection de deux University, deux tools in action et quatre conférences dont voici la liste en vrac.

AngularJS, ou le futur du développement Web – Thierry Chatel

Angular est un framework JavaScript, plutôt léger (plus petit à charger que JQuery) et sans dépendances.
Il a été créé pour résoudre un des principaux problèmes du développement web, ie, HTML n’est pas fait pour faire de l’applicatif. Il n’est pas possible de faire le lien entre les tags et les données (One Way Data-Binding).

Les concepts à retenir, qui font la force d’Angular :

  1. MVC
  2. Two Way Data-Binding : un changement sur la vue, met à jour le modèle et inversement, un changement sur le modèle met à jour la vue. La majorité du code d’une application javaScript sert à traverser, manipuler ou écouter le modèle DOM. Le Data-Binding d’Angular permet d’élaguer ce code et de concentrer son énergie sur le fonctionnel de l’application.

    Exemple.
  3. Templates : un template Angular consiste en du bon vieux code HTML. Le vocabulaire HTML est simplement étendu pour contenir les instructions permettant de projeter le modèle sur la vue.

    Exemple.
  4. L’injection de dépendances
  5. Directives : les directives permettent de créer des tags HTML personnalisés qui peuvent être utilisés comme de nouveaux widgets.

Arquillian pour des tests Web simples et efficaces – Alexis Hassler

Arquillian est un outil de test pour JavaEE.

La logique habituelle, lorsque l’on teste du code destiné à être déployé au sein d’un conteneur, est de gérer un conteneur embarqué au sein d’un test. Arquillian autorise à faire l’inverse, c’est-à-dire d’amener le test au sein d’un conteneur JavaEE.

En somme, Arquillian est le chaînon manquant pour tester ces composants simplement depuis JUnit. Et ce, tout en bénéficiant des services fournis par un conteneur (transactions, base de données, etc).

Live coding avec Yeoman & AngularJS – Matthieu Lux

Yeoman regroupe un ensemble d’outils et de bibliothèques sélectionnés dans le but d’aider le développeur à créer des applications webs JavaScript de qualité.
Yeoman gère aussi un workflow qui est là pour aider le développeur à initialiser ses applications, les tester, les packager.

La démo consistait à créer une application web Angular, avec les tests et un design facilité grâce à Twitter Bootstrap.
Une commande résume la simplicité du process : yo angular.

Elastifiez votre application : du SQL au NoSQL en moins d’une heure – David Pilato et Tugdual Grall

La solution NoSQL choisie pour cette migration est couplée à .

D’entrée de jeu, la question est posée, « Pourquoi migrer ? ».
Et la réponse est simple et tient en 3 points :

  1. Scalabilité verticale,
  2. Scalabilité horizontale,
  3. Recherche full text.

L’application de départ est une application web java « old school » :
– Appli CRUD Angular d’édition de contacts ,
– Services Java HTTP/REST,
– DAO (jdbc),
– Base SQL (HSQL),
– Recherche du type select bidule where truc like '%machin%';.

L’application d’arrivée est une application web java « moderne » :
– Appli CRUD Angular d’édition de contacts ,
– Services Java HTTP/REST,
– Couchbase Client (dispo sous maven),
– Base NoSQL (CouchBase).
– Recherche full text (Elasticsearch)
NB : CouchBase est une base orientée document où les données sont stockées au format json.

Jusque là rien de très impressionnant. C’est alors qu’un script d’insertion d’1 million d’enregistrements est déclenché. CouchBase ingurgite tout cela sans broncher, l’application continue de fonctionner correctement.

Le script continue de tourner et c’est au tour d’Elasticsearch d’entrer en jeu. Via quelques clics, un cluster de 5 noeuds sera dédié à l’indexation des données de l’application. Via quelques clics supplémentaires, CouchBase est configurée pour déverser l’ensemble de ses données dans le cluster d’Elasticsearch.

Les insertions continuent en arrière plan…

La recherche full text est implémentée le plus simplement du monde en pointant directement sur Elasticsearch et non plus sur le service java.

Vient le moment où ils s’aperçoivent qu’il manque un champ dans leur saisie des contacts.
La réaction classique aurait été de couper le script d’insertion, de faire un alter table pour ajouter le champ manquant, de modifier la requête SQL, le DAO puis le code JavaScript.
Or, seul le code JavaScript est modifié. Le json produit par l’ajout d’un nouveau contact prend en compte le nouveau champ. Le nouveau contact est sauvegardé dans CouchBase et la recherche full text fonctionne sur le nouveau champ.

Pendant ce temps-là, le script d’insertion tourne toujours…

Petite cerise sur le gâteau, Kibana, une interface pour Elasticsearch offre la possibilité de créer des tableaux de bord personnalisés sur les données indexées.
Encore quelques clics, un nouveau tableau de bord nouvellement apparaît et on peut voir différents graphes, camemberts et autres histogrammes afficher des stats en temps réel sur les données insérées.

Bref, le NoSQL a de l’avenir.

BigData@DevoxxFr, Saison 2 – Pablo Lopez et Hugo Geissmann

Il s’agissait ici d’un retour d’expérience sur la tentative de création d’une solution BigData clé en main.
Face à des concurrents comme Cloudera, l’aventure s’est révélée plus difficile que prévue.

Architecting for Continuous Delivery – Axel Fontaine

Tout le monde connaît l’intégration continue et c’est rentré dans les pratiques courantes.
L’étape d’après est de passer au déploiement continu. Facebook ou Stackoverflow s’y sont mis, pourquoi pas nous ?
Dans cette présentation, l’intervenant nous a expliqué dans les grandes lignes, les bonnes pratiques à mettre en place pour franchir le pas, tant au niveau développement qu’au niveau configuration des environnements.
Très instructif, mais en résumé il faut avoir un sacré talent de négociateur pour réussir à convaincre que l’on peut se passer d’une équipe de recette.

De compiletout.bat à l’Usine Logicielle pour Java – Guillaume Rams

Salle comble pour Guillaume, consultant/formateur pour Oxiane.

Fort de son expertise dans la filière usine logicielle (intégration continue, qualimétrie), Guillaume a fait le tour des outils disponibles dans l’univers java pour « automatiser et outiller au maximum l’activité de développement », depuis le poste du développeur jusqu’aux environnements de recette.
Le but recherché étant d’augmenter la productivité ainsi que la qualité dans les différentes phases du cycle de vie d’un logiciel.

La question de la responsabilité de l’usine logicielle a aussi été abordée. On est à cheval entre de l’assistance au développement et de l’administration système. Le DevOps a donc été introduit pour expliquer comment répondre à ce nouveau besoin. Il y avait beaucoup de choses à dire à ce sujet et le temps a manqué sur la fin.

Encore bravo pour le travail réalisé en amont et le talk, qui s’est bien déroulé.

Les slides sont disponibles sur Speaker Deck.

Le fantome, le zombie et testacular, panorama des outils de tests pour application web moderne – Jean-laurent De morlhon et Pierre Gayvallet

De toutes les conférences auxquelles j’ai pu assister, c’est celle-ci qui m’aura le plus marqué.

Côté technique, le contenu était très intéressant puisqu’il s’agissait d’un retour d’expérience de sept projets d’application web sur lesquels les outils de tests présentés ont pu être éprouvés comme il se doit.

D’un point de vue personnel, j’ai beaucoup appris sur « comment » tester de bout en bout une application web y compris le frontend.
Avec ma vision de développeur orienté backend Java/Smalltalk, j’ai toujours eu l’impression que les développeurs frontend JavaScript réalisaient peu de tests unitaires par manque d’outillage adapté.
Or, tout un panel d’outils de tests existent et, utilisé à bon escient s’avère redoutablement efficace.

En introduction, les deux intervenants ont fait un petit rappel sur la taxonomie des tests : acceptances, intégrations, unitaires.
Ils ont dès lors insisté sur l’importance des test d’acceptances lorsque l’on développe un frontend mais qu’il ne faut pas en faire trop.
À partir de ce constat, ils nous ont expliqué la technique “outside-in” (cf. GOOS), à savoir, du TDD pragmatique basé sur les tests d’acceptances.
Pour mettre en place cette technique “outside-in”, ils ont donc utilisé un ensemble de browsers, librairies, frameworks et runners bien spécifiques dont ils nous ont détaillés les fonctionnalités.

Browsers headless

Leur intérêt ne sautent pas immédiatement aux yeux. Cependant, de par leurs caractéristiques intrinsèques (rapides et automatisables), ils deviennent vite indispensables si l’on souhaite jouer des tests frontend JavaScript au sein d’une chaîne d’intégration continue.
Trois d’entre eux sortent du lot :

  1. CasperJS(basé sur PhantomJS)
  2. Zombie.js

CasperJS et PhantomJS font du vrai rendering alors que Zombie.js fait de l’émulation.
Les différences se jouent ensuite sur les limitations au niveau du rendu, les API proposées (fluent ou raw) et la lisibilité des codes de tests qui en découlent.

Le petit plus en faveur de CasperJS et PhantomJS est la possibilité de réaliser une capture d’écran. En cas d’erreur, le débuggage est plus facilie.

Librairies

Parmi l’offre que l’on peut trouver sur internet, 2 librairies ont été sélectionnées pour faciliter la rédaction de tests :

  1. Chai.js

Chai.js est une librairie d’assertion pour faire du BDD/TDD.
Les assertions sont regroupées en 3 « styles » : Should, Expect, Assert.
Should et Expect permettent d’améliorer la lisibilité des assertions via l’utilisation de getters chaînés :
...
foo.should.be.a('string');
expect(foo).to.not.equal('bar');
...

Sinon.js est une librairie regroupant un ensemble de fonctionnalités permettant de mettre en place des Spies, Stubs et Mocks ainsi que d’émuler des timers et des appels Ajax. Elle ne possède aucune dépendance et fonctionne sous tous les environnements.

Frameworks

Au cours des intermèdes de live coding rythmant la présentation, j’ai pu voir en action deux frameworks de test particulièrement intéressants :







Qunit est un framework de tests unitaires développé par les membres de l’équipe de JQuery pour tester JQuery. Il n’est toutefois pas spécifique aux tests JQuery et peut-être utilisé pour tester tout code JavaScript. Qunit s’avère pratique, car, en association avec JSTestDriver, il est possible d’exécuter ses tests unitaires javaScript directement depuis eclipse.

Mocha tourne sur node.js ou dans un navigateur, s’intègre bien dans une chaîne d’intégration continue et surtout, permet de rédiger des tests synchrones sur des appels ajax.

Runner

Le sujet principal de la présentation restera tout de même Karma, un lanceur de test multi-navigateur, développé par l’équipe d’AngularJS et fonctionnant sous node.js.
Il permet de faire du test unitaire comme du test d’acceptance, et peut facilement se brancher dans une chaîne d’intégration continue.
Le but de Karma est de faciliter au maximum la vie du développeur en lui apportant un environnement de test complet et productif.

Son principal intérêt vient du fait que le choix du framework de test est configurable. Plusieurs adapters existent dont Qunit et Mocha.
Autre aspect très attrayant, Karma détecte les changements sur les fichiers à exécuter et relance automatiquement les tests le cas échéant.

Bilan

AngularJS, Karma et Yeoman sont en train de donner un gros coup de boost dans l’industrialisation des développements frontend et le NoSQL prend de plus en plus d’importance dans les nouveaux projets.
Passé à côté de toute cette effervescence serait bien dommage.
Et surtout, le développeur JavaScript a désormais tout l’outillage disponible pour réaliser des applications web modernes de qualité. No excuse!!