Et c’est parti pour la seconde journée de Devoxx France 2013. Le jeudi est la première journée des conférences et quickies. Moins de code, mais toujours autant de fun.
Pour cause de timing, j’ai hélas raté les keynotes du matin. La première, présentée par une partie de l’équipe organisatrice de l’événement, était essentiellement destinée à accueillir les personnes et donner un certain nombre de chiffres. Une annonce toutefois : la nouvelle version du site Parleys, refait complètement en HTML 5. Exit le Flash, et c’est tant mieux !
La seconde, L’Histoire des Ecritures, présentée par Clarisse Herrenschmidt retraçait l’histoire de l’écriture, au terme de nombreux siècles d’évolution. Une keynote visiblement passionnante, qui change un peu des thèmes très informatiques dont on a l’habitude. Certains l’ont comparée à la keynote de Michel Serres à l’USI, donc forcément un compliment ! L’ayant ratée, je pense qu’il s’agira de la première que je regarderais sur le site de Parleys.
Dernière keynote fut celle de Martin Odersky, le créateur de Scala. Il semble que les retours indiquent que la keynote n’a pas été dans la direction d’un apaisement entre les Javaïstes et les Scalafistes. Dommage.
Elastifiez votre application : du SQL au NoSQL en moins d’une heure
David Pilato et Tugdual Grall nous propose un guide pour migrer une application utilisant une base de données relationnelle vers une base de données NoSQL.
Tout d’abord, une question : pourquoi migrer ?
- Il est aisé de faire de la scalabilité verticale : augmentation des serveurs, de la mémoire, etc. Mais cela ne suffit plus, on voudrait de la scalabilité horizontale.
- La recherche doit être structurée. On souhaiterait de la recherche full-text.
Ils vont nous montrer le développement d’une application basée sur CouchBase pour la base de données NoSQL et ElasticSearch pour la partie recherche.
On commence par une visite de l’application telle qu’elle est, dans sa version relationelle. Il s’agit d’une base assez simple, avec des fonctionnalités de CRUD, et une recherche assez limitée (la recherche n’est pas multi-champs, très stricte, etc.).
Première étape du refactoring de l’application : mettre en place une API REST dans le serveur (utilisation de Spring MVC + Jackson). Par exemple, on propose une méthode de récupération d’une personne par son ID (ou éventuellement par son nom).
Deuxième étape, mise en place de CouchBase. Côté code, on ajoute la dépendance vers le client CouchBase dans le pom.xml. L’API utilisée ici est très claire et concise. Pour montrer que ça fonctionne, Tugdual montre des appels REST via la commande curl. Ce n’est pas sexy, mais ça marche effectivement.
L’interface graphique de l’application se fait en Angular, mais ça n’a guère d’importance ici.
Tout fonctionne bien, mais ce n’est pas encore ça. Par exemple, si on cherche Joe Smith, on trouvera des résultats, mais pas si l’on cherche Smith Joe. C’est là qu’intervient ElasticSearch. Une fois l’index dans ElasticSearch créé, on duplique les données de CouchBase vers ElasticSearch, tout ceci se faisant très simplement via l’interface web de CouchBase (la base de données est prévue pour fonctionner avec ElasticSearch).
Maintenant, on modifie la partie de recherche - gérée par AngularJS - afin de taper directement sur ElasticSearch, sans passer par le serveur. Avec pratiquement aucune modification, la recherche bénéficie désormais de la puissance d’ElasticSearch : recherche multi-champs, recherche plus générique (désormais la recherche Smith Joe trouve effectivement Joe Smith), etc.
Passons maintenant à l’analyse de données. David présente Kibana, un plugin d’Elastic Search qui permet de créer des dashboards dynamiques. En quelques clics, David arrive à créer un histogramme montrant la distribution des dates de naissance parmi la base de données contenant déjà plus d’un million d’entrées. Même chose pour créer un camembert pour la répartition par pays. Ce dashboard est dynamique. On peut ainsi naviguer dans nos données.
Un autre point positif des bases NoSQL : les données sont sans schéma (schema less), c’est-à-dire qu’il est possible d’ajouter, modifier ou supprimer des champs sans aucun problème. Aucun ALTER TABLE à faire, pas de freeze de la base de données, pas d’update des données existantes.
En moins d’une heure, David et Tug ont réussi leur pari de faire migrer leur application pour la rendre plus scalable, plus élastique. En prime, et ce n’est pas négligeable, ils ont ajouté de vraies fonctionnalités de recherche et de création de dashboards dynamiques, à moindre frais. Une telle migration n’est toutefois pas si aisée dans le monde réél, et se passer d’une base relationnelle n’est pas toujours simple, en particulier car il faut changer aussi sa façon de penser son modèle de données.
Les bronzés font du dév
Ellène Siber Dijoux (@ElleneSiber), durant un Quickie humoristique, nous montre la vie professionnelle de Martin Dutruc, jeune développeur fraichement débarqué de son école. La déconvenue va être totale, et nous voyons à travers cette petite histoire pas mal de travers de notre métier (quand il n’est pas exécuté par les bonnes personnes) ainsi qu’un certain nombre de clichés dans notre environnement :
- La société à “taille humaine” de 1200 personnes ;
- Le commercial qui était un ancien développeur et qui connait bien le monde du ”Java - J deux ZE” ;
- Pas de machine lors de l’arrivée d’un nouveau dans l’équipe. Du coup on lui donne 1000 pages de documentation, fonctionnelle ou technique ;
- Le problème du build qui ne passe pas, alors il faut ignorer les tests ;
- La mauvaise gestion du temps, de la pseudo-agilité (vive les itérations de 2 mois !).
Ellène s’en est bien sortie, le format de sa présentation n’était pas forcément facile. Hélas, ces travers sentaient beaucoup le vécu, y compris pour moi. En tout cas, bien vu Ellène :)
Comparing JVM Web Frameworks
Matt Raible (@mraible) nous propose une comparaison de différents frameworks Web tournant sur la JVM. Tout d’abord une petite histoire sur le web et les frameworks web pour la JVM.
Image de Matt Raible (Copyright Raible Designs)
Y a t’il trop de frameworks web pour la JVM ? La salle pense en majorité que oui. L’arrivée des frameworks JavaScript ne change pas la donne, et posent d’autres problèmes : peu de scalabilité, problème de sécurité, code potentiellement critique côté client, etc.
Passons au comparatif des frameworks. Tout d’abord, quels critères pour choisir les candidats ?
- Communauté / Support
- HTML 5
- REST
- Mobile
- Performances
- Rapidité des pages
Matt décide de se “borner” à la plateforme JVM pour restreindre son choix. Cela laisse tout de même un large choix de langage : Java, Scala, Groovy, etc.
Faire des comparatifs n’est pas simple. Il faut affronter communautés passionnées (surtout celles ayant une mauvaise note), critiques sur la façon de noter ou sur les notes. Il y aussi la possibilité de “tricher” avec les résultats.
Pour Matt, l’une des très bonne comparaison de frameworks était la présentation World Wide Wait lors du Devoxx 2011. Autre comparatif intéressant est le site devrates.com qui permet avant tout de connaitre la popularité d’un framework.
S’il s’agit d’un framework full stack, Matt recommande avant tout de choisir en fonction du langage que l’on souhaite utiliser : JRuby, Groovy, Scala ou Java.
Cette présentation n’était pas une comparaison en soi, mais plutôt les bonnes méthodes à suivre quand on veut faire soi même une comparaison de frameworks, afin de choisir ce qui permettra de mieux répondre à nos besoins. Une présentation intéressante, mais peut-être un peu en deça de ce que nous avait habitué Matt Raible par le passé.
Structures de données exotiques, au delà de ArrayList, HashMap et autres HashSet
On a tendance à toujours sortir l’artillerie lourde, et pas de considérer vraiment le problème que l’on a. Comme il le dit, quand on a un marteau, tout ressemble à un clou ! Durant cette présentation, Sam nous présente 4 structures de données, un poil exotique.
Skiplist
- Stockage de données ordonnées
- Insertion / suppression en
O(log N) - Recherche en
O(log N)
Plutôt que de parcourir toute la liste pour chercher un élément, on prend des “voies express”, c’est-à-dire qu’on va sauter des éléments. Pour vulgariser un peu, Sam compare ça aux Métro 1 et au RER A. Par exemple, si l’on veut se rendre de La Défense à Châtelet, on peut prendre l’une ou l’autre des lignes. Le Métro 1 va mettre plus de temps, car il s’arrête à chaque station, alors que le RER prend une voie “express” (du moins en temps normal, quand il n’y a pas d’incident :) ). On arrive ainsi plus vite à destination. C’est le même principe pour les SkipList lorsqu’on la parcourt à la recherche d’un élément : on ne va pas aller d’élément en élément, mais on va plutôt prendre des “raccourcis”.
Depuis le JDK 1.6, il existe des implémentations de ce type de structure :
Tries
Cette structure est une sorte d’arbre ternaire. Pour une recherche de texte, la complexité va dépendre non de la taille de l’arbre, mais de la longueur de la chaine de recherche.
Toutefois, cette structure reste assez gourmande en mémoire. Sam fait un focus sur la structure Hash Array Mapped Trie (HAMT). Dans ce type de structure, on code les clés sur 32 bits, du coup la profondeur de l’arbre ne dépassera jamais 7 niveaux.
Pour la complexité nous avons d’excellents résultats :
- ajouter, premier, dernier, n-ième élément, mise à jour ->
O(1). - concat, insert, preprend ->
O(N)(N étant au maximum 7).
A noter qu’il existe une Concurrent Trie (CTrie) qui n’est pas bloquante.
Sketches
Prendre un ensemble de données, en extraire des informations, puis travailler sur ces informations et non sur les données elles-mêmes.
Bloom Filters
Structure de données probabiliste. Par exemple, est-ce qu’un élément appartient à un ensemble de données ? On ne pas être sûr à 100% que la donnée soit présente, mais on est absolument certain qu’elle n’y ait pas. Il ne peut donc pas y avoir de faux-négatif.
Attention toutefois, si un Bloom Filter accepte les insertions, il ne peut pas y ajouter de suppression de données. Afin de supporter la suppression, il faudra utiliser un Counting Bloom Filter.
On peut trouver une implémentation dans Guava, BloomFilter
Count Min Sketches
Le Count Min Sketch est une évolution du Bloom Filter. Cette structure garde l’information du nombre d’occurences de chaque élément. Une utilisation de ce genre de structure est de détecter quelle source change le plus souvent ses données, les IP qui consomment le plus de bande passante, etc.
A voir sur GitHub, une librairie de structure de données par flux.
Une seconde journée moins chargée en terme de conférence en ce qui me concerne, car il me fallait encore préparer mon passage du lendemain avec Julien Jakubowski. J’ai également beaucoup discuté avec d’autres personnes, visiter un peu les stands, etc.