Ippon Technologies a lancé il y a 3 semaines un grand concours de code, portant sur l’application Tatami.

Ce concours consistait à finaliser et à débugger une application complète, basée sur HTML5+Spring+Cassandra. Du vrai code, disponible sur GitHub, pour une vraie application !

Cette application a été spécialement développée par votre humble serviteur, ainsi que par mon collègue Thomas Escolan, que je tiens à vivement remercier pour son travail sur la partie HTML5.

Le jeu s’est terminé ce matin, il est donc temps de faire un bilan et d’annoncer les vainqueurs !

Bilan du jeu

Sur Github, nous avons eu 60 “watchers”, 46 “forks” et 18 “pull requests” : il est évident que ce jeu a été pour nous un grand succès.

Au final, nous avons eu une dizaine de participations intéressantes (que nous allons détailler ci-après), dont certaines étaient particulièrement avancées et créatives.

L’application a évolué de manière très notable, même s’il est parfois compliqué de pouvoir fusionner des modifications provenant de tous ces forks différentes.

L’un de nos objectifs futurs est de pouvoir terminer l’application, afin qu’elle soit rééllement utilisable, sachant qu’il n’existe pas de solution Open Source équivalente (à notre connaissance, le système qui s’en approche le plus est Yammer, qui bien entendu est un logiciel commercial).

Participations marquantes

Un fork “full Java EE”

Romain Manni-Bucau, commiter TomEE et OpenEJB, a fait un fork supprimant totalement Spring de l’application :

https://github.com/rmannibucau/tatami

Le code final fonctionne donc correctement sur TomEE, à quelques nuances près (en particulier la sécurité, qui en Java EE doit être configurée dans le serveur d’applications et non dans l’application, ainsi que le cache, qui a dû être codé spécifiquement), et cela nous a permis de faire des tests de performance très intéressants, entre deux stacks concurrentes :

• Jetty + Spring + Spring MVC REST
• Tomcat + OpenEJB + CXF

Le résultat initial étant très lié au serveur d’applications (Jetty faisant du NIO par défaut, il tenait nettement mieux la charge), après un peu de tuning Romain est arrivé aux statistiques suivantes, avec pour 1000 utilisateurs concurrents, sur une petite machine de bureau :

• Spring : 196.6 requêtes par seconde
• TomEE : 182.3 requêtes par seconde

Sachant que les serveurs et JMeter étaient tous sur la même machine, ces résultats sont bien entendu à prendre avec une pincée de sel…

Mais quoiqu’il en soit, nous pouvons en tirer les conclusions suivantes :

• Spring et TomEE tiennent la chargent de manière équivalente
• L’application tient facilement 3000 utilisateurs concurrents, avant que JMeter ne crashe : nous tenons donc extrêmement bien la charge, essentiellement grâce à Cassandra et au système de cache
• L’ajout d’un cache nous fait gagner environ 20% de requêtes/seconde, car on n’a plus à faire un accès réseau (local) vers Cassandra, et à sérialiser/déserialiser les données : Cassandra seul peut donc largement suffire en tant que cache distribué

Si vous voulez faire ces tests vous-mêmes, le jeu de test est disponible sur GitHub. Attention cependant, la version Spring a depuis pas mal évolué, l’ajout de nouvelles fonctionnalités devraient logiquement la faire ralentir un peu.

Enfin, pour ce qui est de la productivité et de la qualité des développements Spring vs Java EE, je vous laisse juges en lisant le code source :

• Le code Spring est nécessairement plus concis, car Spring propose plus de fonctionnalités en standard (c’est normal d’ailleurs, Spring s’appuyant sur Java EE pour l’améliorer)
• Le code “full Java EE” est plus standard (pas d’annotations Spring), en particulier sur la partie REST (pour l’injection de dépendances les deux codes utilisent le standard @Inject, les différences restent donc minimes)

Ajout de tests unitaires avec cassandra-unit

Jérémy Sevellec, l’auteur de cassandra-unit, a ajouté une suite complète de tests d’intégration utilisant (évidemment) cassandra-unit. C’est sans doute la contribution qui a le plus aidé à la qualité du code.

Jérémy a également fait preuve d’un excellent esprit de participation (ce qui compte au Judo !), vous pouvez donc voir ce travail dans cette pull request qui a été ajoutée au code du projet :

https://github.com/ippontech/tatami/pull/32

Utilisation d’un configuration Spring avec 0 ligne de XML

Gildas Cuisinier, bien connu des amateurs de Spring, nous a proposé une configuration Spring “0 XML”. La mode actuelle est de faire le moins de XML possible, mais d’un point de vue purement personnel je vous avoue trouver cette configuration moins lisible que son homologue XML.

Vous pouvez étudier son travail via cette pull request, elle aussi acceptée dans le projet :

https://github.com/ippontech/tatami/pull/36

Cependant, ce code s’est révélé relativement lent au démarrage, car il forçait l’application à scanner tout son classpath. Fabien Arrault (Ippon Technologies) nous a donc proposé cette pull request, qui réintroduit quelques lignes de XML et nous redonne les performances d’origine :

https://github.com/ippontech/tatami/pull/38

Utilisation de Spring Mobile et JQuery Mobile

L’une des amélioration à réaliser était de réaliser une interface “mobile” de l’application. Plusieurs personnes ont démarré cette fonctionnalité, en utilisant toutes :

• Spring Mobile pour savoir si l’utilisateur utilisait (ou non) un téléphone ou une tablette
• Les fonctionnalités de Spring MVC pour rediriger ensuite l’utilisateur vers une vue “standard” ou une vue “mobile”

Gildas Cuisinier en a proposé une première version qui a été intégrée dans le projet principal :

https://github.com/ippontech/tatami/pull/46

Utilisation de Spring Social

Spring Social est un sous-projet Spring permettant d’utiliser simplement les APIs des différents réseaus sociaux tels que Twitter, Facebook, etc…

L’un des objectifs du jeu était de connecter l’application à ces réseaux, à priori en utilisant Spring Social : malheureusement, c’est l’un des seuls objectifs qui n’a pas été entièrement finalisé.

Sam Bessalah en a certainement fait la version la plus aboutie, mais il ne l’a pas livrée à temps pour la date finale du jeu :

https://github.com/samklr/tatami

Gagnants

2ème place : François Descamps

François Descamps a contribué un nombre de pull requests impressionnant. Il gagne donc haut la main le trophée du fair play, car il a très régulièrement soumis son code pour qu’il soit intégré dans l’application d’origine.

En particulier (et de manière non exhaustive), il a :

• Refactoré le code JavaScript (mais précisons que ce refactoring ne fait pas l’unanimité du jury)
• Mis en place Elastic Search avec l’aide de David Martin (Ippon Technologies), pour pouvoir rechercher des utilisateurs et des tweets
• Ajouté une protection contre les attaques XSS avec JSoup et Bean Validation
• Et proposé de nombreux commits pour améliorer l’interface graphique et l’utilisabilité…

François gagne donc une place de 2 jours à Devoxx France !

1ère place : DuyHai Doan

DuyHai Doan a fait un fork particulièrement impressionnant. Le seul défaut de sa contribution étant qu’elle soit dans un fork tellement éloigné du master qu’il nous sera difficile de réintégrer ses modifications dans le code principal.

Mais à part cela, il a développé un très grand nombre de fonctionnalités, ce qui fait de son fork une version de l’application plus avancée que l’originale, malgré les commits de nombreux concurrents différents.

En particulier, il a :

• utilisé Hector Object Mapper pour améliorer la qualité de la couche repository (en utilisant au maximum JPA)
• utilisé Cassandra de manière intelligente pour proposer une recherche des utilisateurs sans utiliser Elastic Search (ou Lucene). Cependant, il n’a pas implémenté la recherche des Tweets (impossible à faire avec Cassandra), il a donc une solution plus simple que celle utilisant Elastic Search, mais moins complète
• mis en place ESAPI et Bean Validation pour protéger l’application des attaques XSS
• ajouté la librairie Thymeleaf comme moteur de templates HTML5
• codé une interface graphique riche en utilisant LESS CSS, en ajoutant de nombreuses nouvelles fonctionnalités (les profils utilisateurs), ainsi qu’en améliorant le design général de l’application
• réalisé une excellente couverture de tests en utilisant TestNG
• développé une version mobile très complète de l’application, avec Spring Mobile, LESS CSS, Jackson, HTML5. C’est le point principal qui a fait gagner DuyHai

DuyHai gagne donc une place de 2 jours à Devoxx France, ainsi qu’un Galaxy Tab !