C’est parti pour cette deuxième journée. Cette fois-ci, tout le monde est là, environ 1250 geeks pour assister à 2 jours de conférences.

Une petite visite chez le médecin en cette matinée m’a fait raté les keynotes. Je les regarderais sur Parleys lorsqu’elles seront disponibles.
Mais en gros, on salue le succès de cette première édition, et l’année 2013 verra elle aussi son édition parisienne du Devoxx ! J’ai déjà hâte d’y être !


Spring est mort, longue vie à Spring, par Gildas Cuisinier

Lorsque JavaEE 6 est sorti, on annonçait une guerre sans pitié avec Spring, et la fin proche de ce dernier.
Cela fait déjà 2 ans que JavaEE est sorti, mais qu’en est-il aujourd’hui ?

A l’époque, avant sa version 6, JavaEE avait « menti », en partiulier sur la soit disant simplicité du framework JavaEE, ainsi que sur la testabilité des applications l’utilisant…
C’est alors que Spring est arrivé pour résoudre pas mal de problèmes.
Initialement, toute la configuration se faisant avec des fichiers XML. Il faut dire que c’était à la mode, le XML !
Puis, la complexité de cette configuration augmentant, les namespaces sont arrivés, pour mieux catégoriser sa configuration Spring. On y voyait déjà plus clair !

Un jour, Java 5 est arrivé, en introduisant les annotations dans le code Java. Ceci va impliquer une nouvelle évolution de Spring : la configuration via les annotations.
En voici un exemple :

@Component
public class Jedi {
    private Arme arme;
    @Autowired
    public void setArme(Arme arme) {
        this.arme = arme;
    }
}

Seul ombre au tableau : pour se passer d’écrire de la configuration en XML, il faut écrire… du XML. En effet, il faut indiquer à Spring quel(s) package(s) doivent être scannés pour y lire les annotations :

    <context:component-scan base-package="xxx"/>

Entre temps, JavaEE est arrivé, et devient « sexy » : simplicité, testabilité, légèreté. Toutefois, cela demande une migration, non seulement du code, mais aussi des serveurs d’applications, car tous ne sont pas compatibles JavaEE 6.

De son côté, Spring sort en version 3.0 (décembre 2009), disposant de sa configuration par annotations.

Malgré l’arrivée de JavaEE 6, les équipes ne souhaitent pas abandonner Spring. Gildas nous le montre avec un certain nombre de statistiques tirées de son questionnaire Spring (entre 100 et 130 personnes y ont répondu).
Aujourd’hui, Spring est toujours très présent, en particulier les version 3.x :

  • 50% des sondés utilisent Spring 3.0 ;
  • 23% sont déjà passés à Spring 3.1 ;
  • 19% n’utilisent pas Spring ;
  • 8% sont restés sur des versions 2.0 ou 2.5 de Spring.
  • D’ailleurs, dans l’audience, seules 3 personnes utilisent JavaEE 6 en production, alors que la quasi totalité utilise Spring 2.5 / 3.0 en production. Très peu (pour l’heure), utilisent Spring 3.1 en production.

    Les principaux reproches faits à Spring :

    • Trop compliqué à mettre en place. Généralement, on travaille sur une application où Spring est déjà en place, on ne regarde pas comment cela fonctionne concrètement.
    • Invasif.
    • Trop de XML. Maintenant, on s’oriente beaucoup plus vers les annotations, comme pour JavaEE. Cependant, cela pose un autre souci : la configuration par annotations étant dispersée dans le code, il devient plus fastidieux d’avoir une vision globale de celle-ci…
    • L’aspect propriétaire. Toutefois, si SpringSource gère seul le code, mais reste ouvert aux propositions.
    • Gildas parle ensuite de Spring 3.1. Qu’apporte-t-il ?
      Spring 3.1 finit ce que Spring 3.0 avait introduit : tout est désormais annotable, on peut faire du « NoXML » !
      L’exemple cité plus haut s’écrira désormais ainsi :

      @Configuration
      @ComponentScan("xxx")
      public class Configuration {
          ...
      }
      

      De nouvelles annotations arrivent, pour gérer le scheduling (@EnableScheduling) ou encore pour configurer Spring MVC (@EnableWebMvc).
      Les annotations ne permettent pas tout, et il est parfois nécessaire, en plus d’annoter sa classe, d’étendre une classe de Spring (exemple : les Interceptors MVC).

      D’autres points intéressants sur Spring 3.1 :

      • Support d’Hibernate 4 ;
      • Namespace c: (pour simplifier les constructeurs) ;
      • JPA sans le persistence.xml ;
      • Amélioration du support REST dans Spring MVC ;
      • FlashMap dans Spring MVC.

      En conclusion, Spring est loin d’être mort, car l’adoption de JavaEE est encore loin d’être une réalité, et de plus, Spring dispose de tout un écosystème autour de lui : SpringData, SpringMobile, SpringSocial, SpringBatch, etc.


      Après la pause déjeuner, je vais zapper les conférences, et aller voir un peu ce qui se fait du côté de Code Story

      Code Story

      Le principe : 4 développeurs (David Gageot, Jean-Laurent de Morlhon, Sébastien et Eric le Merdy) se chargent du développement d’une application se connectant à Github pour créer un historique de projet.
      Ensuite, cette application va s’interfacer avec Jenkins, Sonar, Trello, etc. pour pouvoir ajouter des événements dans la vie du projet (build cassé, règle de qualité non respectée, etc.).
      Au final, l’application devrait pouvoir attribuer des badges aux développeurs du projet surveillé : le meilleur casseur de build, le commiteur le plus prolifique, etc.
      Tout se fait bien entendu en live, en partant de zéro.

      Chaque itération dure environ 1 heure, avec 2 sessions de 25 minutes de développement.
      Au début, un petit stand-up meeting pour expliquer ce qui va être fait dans l’itération, et à la fin, une rétrospective pour expliquer les accomplissements, ainsi que les difficultés rencontrées.
      Concrètement, l’équipe se divise en 2 binômes :

      • Le premier binôme est au front : il code face à l’audience, et explique à voix haute ce qu’il fait.
      • Le second binôme travaille plus en retrait, et on ne voit pas concrètement ce sur quoi il travaille (mais on finit par le savoir lors de la rétrospective de fin d’itération).

      Deux vidéo-projecteurs nous permettent de suivre leur travail en direct. Le premier diffuse l’écran du premier binôme (en général pour montrer soit IntelliJ, soit une console shell, soit le navigateur web), le second montre le « serveur », avec Jenkins ou Sonar qui analysent en permanence le travail commité sur GitHub.

      Lorsque j’y suis allé, le projet n’en était encore qu’à ses débuts, et l’équipe mettait en place le déploiement automatisé, et commençait à écrire ses premières pages web.
      Mais il était intéressant de voir 4 développeurs plutôt talentueux (dont 3 ex-collègues à moi :) ) travailler en direct live, dans des conditions proches de la réalité (avec des dead-lines très courtes).
      D’ailleurs, à en voir les retours, ce Code Story a été très apprécié. Plusieurs fois j’ai voulu y retourner, mais à chaque fois, j’ai été obligé de rester en dehors de la salle, tant elle était perpétuellement remplie !

      A noter que lorsque j’y suis passé, l’équipe avait déjà eu recours à pas mal d’outils ou de librairies :

      • Github (version entreprise) pour stocker le code ;
      • Infinitest pour laisser l’IDE exécuter en permance les tests unitaires ;
      • Zombie.js un framework JavaScript pour tester l’interface web ;
      • Mocha un autre framework de tests JavaScript ;
      • Jersey, une librairie Java pour faire du REST ;
      • Fest-assert, une extension à JUnit (ou TestNG) pour écrire des assertions de manière plus fluide (fluent) ;
      • Guava l’incontournable librairie de Google pour ajouter tant de choses manquantes à Java !
      • Growl un outil de notification pour Mac, affichant une notification à chaque fois que l’application vient à builder ;
      • Jenkins pour l’intégration continue ;
      • Sonar pour l’analyse qualité ;
      • IntelliJ, l’IDE Java de référence ;
      • Trello comme mur à post-its virtuel, permettant de planifier les tâches des itérations ;
      • Mustache.js un framework JavaScript de templating.

      L’équipe a mis en place le build incassable : on ne committe que si ça compile bien chez soi. Du coup, Jenkins devient moins utile. D’ailleurs, à ce propos, il faut noter que David Gageot est partisan de l’intégration continue sans serveur !
      Grawl est également mis en place pour offrir un maximum de réactivité : dès qu’un commit est réalisé sur le repository Git, Grawl nous indique qu’un build Jenkins démarre… puis quelques secondes plus tard il nous indique que le build est terminé, avec succès bien sûr !

      Une librairie qui a atiré mon attention, c’est Mustache.js, qui permet de faire du templating en JavaScript.
      Voici un exemple tout simple :

      <script type="x-template" id="commit-template">
          {{#commit}}
              <div class="commit">{{author}}</div>
          {{/commit}}
      </script>
      
      Mustache.to_html($("commit-template").html, json);
      

      Bref, une très jolie expérience que ce Code Story ! Dommage que je n’ai pu assister à des sessions vers la fin, pour voir le projet presque abouti.
      Toujours est il que le code est à retrouver sur GitHub.


      BigData et Hadoop par Pablio Lopez

      Pablo Lopez nous parle d’une expérience vraiment très intéressante. Il travaille pour une grande société de vente de produits en ligne (il ne le citera pas, mais il s’agit d’une société à l’image ferroviaire vendant différentes prestations de voyages).
      Celle-ci gère environ 1,000,000 de visiteurs uniques par jour, et environ 1/5 de ces visiteurs réalisent une commande.
      Ce sont ainsi au total environ 65,000,000 commandes par an, avec un pic, autour de mi-octobre, de 350,000 ventes pour une seule journée !
      L’ambition : être le leader mondial dans son activité dans les 3 ans. Rien que ça, pour, ce qui était il y a encore 10 ans à peine, une startup…

      Côté technique, nous avons 500 serveurs de production, gérant environ 80 applications, chaque serveur disposant de 5 JVM. L’utilisateur navigue sur 13 niveaux de load balancing. Joli !
      Au final, chaque serveur va générer 7 Go de logs quotidiennement ! Il est donc difficile de gérer un tel volume !
      Ce qu’il faut, c’est :

      • Centraliser les logs ;
      • Sécuriser les fichiers de logs, les sauvegarder ;
      • Analyser : pouvoir récupérer les informations selon des catégories (paiement, recherche, etc.) ;
      • Informer les bonnes personnes avec les bonnes informations ;
      • Archiver, pouvoir comparer les logs d’une journée sur l’autre, d’une semaine sur l’autre, d’un mois sur l’autre, etc.
      • Et tout cela en temps réel s’il vous plait !
      • Etant un site de e-commerce, on doit avoir une disponibilité de 99,995%, ainsi qu’un temps de réponse sous la seconde (voire même sous les 200 ms). Et là dessus, il n’y a pas de négociation possible !
        La base de données étant le « Single point of failure » (goulot d’étranglement), il ne faut surtout pas la surcharger !

        Quelles solutions ?

        Pour arriver à leurs fins, l’équipe de Pablo va avoir recours à :

        Les outils doivent tenir la charge, être scalables, avoir une excellente tolérance à la panne.

        Première chose : centraliser les logs, et le plus vite possible. Pour cela, ils font appel à SyslogAppender, un appender de log4j, qui peut transmettre les logs via UDP. De l’autre côté, syslog-ng est utilisé pour écouter ces packets UDP.

        Flume est utilisé pour pouvoir copier les logs sur des systèmes de fichiers distribués (hdfs).

        Second point : sécuriser les fichiers.
        HDFS (Hadoop Distributed File System) est utilisé ici. Chaque log est copié 3 fois, sur des disques « classiques ». Cette duplication rend ainsi obsolète des système de type RAID.
        hdfs travaille mal avec des « petits » fichiers (moins de 64Mo). Pour résoudre ce problème on regroupe plusieurs « petits » fichiers un seul (fichier de type .har).

        Il faut maintenant analyser les logs, par « tranche » de 64M (sur le principe du principe map / reduce).

        Les rapports d’analyse sont stockés sur du MongoDB :

        • Elasticité du modèle, pour le faire évoluer facilement ;
        • Facilement interrogeable, avec du JSON ;
        • Maturité de l’API de requêtage ;
        • Scalabilité.

        Play! est utilisé pour représenter les rapports d’analyse. Play! est choisi pour sa facilité de mise en oeuvre, son intégration de JSON et MongoDB, etc.

        Dernière problématique : le temps réel !

        Premier souci : Hadoop ne sait pas faire de map / reduce sur des fichiers non fermés (or ici, tout est en streaming). Flume va résoudre ce problème en fermant les fichiers à chaque minute.
        Hélas, le temps de traitement du map / reduce est alors d’environ 45 minutes ! Beaucoup trop long !
        La première correction sera de modifier le cluster. Ensuite, les JVM gérées par Hadoop sont tunées, en particulier pour la gestion mémoire.
        L’interaction avec Flume est également améliorée. On arrive maintenant à 6 minutes. C’est déjà mieux, mais le temps doit encore être réduit !
        On optimise l’utilisation de Java : suppression de librairies tierces, optimisation de la sérialisation des objets, etc.
        Au final, on arrive à 45 secondes pour traiter 1 minute de logs.

        Quelle est l’utilisation quotidienne de ce système ?

        • Analyse quotidienne des logs, pour le SLA (« Service Level Agreement« , autrement dit un document définissant le niveau de qualité attendu) ;
        • Corrélation des logs. Si un utilisateur a eu un problème, il faut savoir identifier les serveurs par lesquels il est passé (on rappelle qu’un utilisateur peut passer par 13 niveaux de load-balancing !) ;
        • Comparer différentes versions du site, voir si la nouvelle version ne contient pas des liens cassés par exemple.

        Concernant l’avenir :

        • L’équipe soit avoir de nouveaux uses cases : par ex. savoir où passe le robot Google, détecter les utilisations frauduleuses de CB, faire des ratio recherches / achats ;
        • Agrandir encore la plateforme, remettre à jour les machines ;
        • Avoir de l’analyse de logs à la demande, sans avoir à développer et déployer de nouveaux map / reduce. Utiliser Hive ? Cascading ?
        • Quel avenir pour les produits utilisés ? L’équipe souhaite contribuer à Flume. Quelques craintes également sur la versatilité d’Hadoop.

        Dernier détail : l’investissement s’est fait essentiellement au niveau des machines (~ 70K€).
        Le projet, quant à lui, est passé des premières discussions à la machine à café à la production en l’espace d’environ 7 à 8 mois.

        Voilà un joli projet, qui montre une utilisation concrète d’Hadoop, MongoDB, Flume et Play! pour un traitement massif des logs.

        Start Slide Show with PicLens Lite PicLens