MongoDB Aggregation Framework

Vous avez probablement entendu parlé de MongoDb, une solution NoSQL orientée document développée par 10Gen. Les documents sont stockés en JSON, et bien que vous ayez un driver disponible pour chaque language, on se retrouve souvent à coder les requêtes en javascript dans le shell mongo fourni. Je vais vous parler de la version 2.2 qui est la dernière version stable et contient le framework d’aggregation, grande nouveauté attendue par les développeurs. Pour votre information, les numéros de version de Mongo suivent le vieux modèle du kernel Linux : les numéros pairs sont stables (2.2) alors que les versions de développement sont instables (2.1). Node.js suit le même modèle par exemple.

L’aggrégation donc, qu’est ce que c’est? Pour vous faire comprendre l’intérêt nous allons prendre un petit exemple (version simplifée d’un vrai projet). Admettons que vous stockiez les connexions à votre application toute les minutes, par exemple avec un document qui ressemblerait à

{"timestamp": 1358608980 , "connections": 150}

C’est à dire un timestamp qui correspond à la minute concernée et un nombre de connexions total.

Disons que vous vouliez récupérer les statistiques sur une plage de temps, par exemple sur une heure : il faudrait alors aggréger ces données pour obtenir le nombre total de connexion et le nombre moyen par minute. Seulement voilà, MongoDb ne propose pas de “group by”, de “sum” ou de “avg” comme l’on pourrait avoir en SQL. Ce genre d’opération est même déconseillé, car fait en javascript cela prend un plus de temps que dans une base classique. C’est en tout cas à éviter pour répondre à des requêtes en temps réel. Mais bon des fois, on est obligé…

 The old way : Map/Reduce
Jusqu’à la version 2.2 donc, on utilisait un algo map/reduce pour arriver à nos fins. Si vous ne connaissez pas, je vous invite à lire cet article de votre serviteur expliquant le fonctionnement. Dans un algo map/reduce, Il faut écrire une fonction map et une fonction reduce, qui vont s’appliquer sur les données selectionnées par une requête (un sous ensemble de votre collection MongoDb).

La requête qui permet de selectionner ce sous ensemble serait par exemple :

// stats comprises entre 15:00 et 16:00

var query = { timestamp : { $gte: 1358607600, $lte: 1358611200 }}

La fonction map va renvoyer les informations qui vous intéressent pour une clé. Ici nous voulons les connexions pour l’heure qui nous intéresse, donc nous aurons une fonction comme suit :

// on renvoie les infos pour la clé 15:00

var map = function(){ emit(1358607600, { connections : this.connections}) }

La fonction reduce va ensuite aggréger les informations, en ajoutant les connexions totales pour la clé 15:00 et calculer la moyenne associée.

// calculer la somme de toutes les connexions et la moyenne

var reduce = function(key, values){
 var connections = Array.sum(values.connections);
 var avg = connections/values.length;
 return { connections: connections, avg: avg}
 }

Maintenant que nous avons nos fonctions map et reduce, ainsi que la requête pour remonter les données qui nous intéressent, on peut lancer le map reduce.

// dans le shell mongo

db.statistics.mapReduce(map, reduce, { query: query, out: { inline: 1 }})

Le out inline permet d’écrire la réponse dans le shell directement (sinon il faut préciser une collection qui acceuillera le résultat). On obtient une réponse du style :

{connections: 180000, avg: 3000}

en 4,5 secondes environ sur ma collection de plusieurs millions de document légèrement plus complexes que l’exemple.

The new way : Aggregation Framework
Maintenant voyons la nouvelle façon de faire avec le framework d’aggrégation. Une nouvelle opération apparaît : aggregate. Celle-ci remplace mapReduce et fonctionne comme le pipe sous Linux : de nouveaux opérateurs sont disponibles et on peut les enchaîner. Par exemple, le “group by” est simplifié avec un nouvel attribut $group. La requête qui permet de filtrer un sous ensemble de la collection est écrite avec un opérateur $match. Enfin de nouveaux opérateurs viennent nous simplifier la vie : $sum, $avg, $min, $max… J’imagine que vous avez saisi l’idée.

Ici on veut un élément match qui limite l’opération aux données de l’heure concernée, on peut réutiliser la même query que tout à l’heure. On groupe ensuite les documents avec une seule clé : celle de l’heure qui nous intéresse, puis l’on demande le calcul de deux valeurs, le nombre total de connexions (une somme) et la moyenne des connections (une moyenne donc).

db.statistics.aggregate(
 { $match: query},
 { $group: { _id: 1358607600, totalCompleted: {$sum: "$connections"}, totalAvg: {$avg: "$connections"}
 }})

Le résultat est le suivant (en 4,2 secondes, soit un temps légérement inférieur au précédent) :

{ result: [{
 "_id": 1358607600,
 "totalCompleted": 180000,
 "totalAvg": 3000
 }], ok: 1}

L’avantage principal du framework d’aggrégation réside dans sa plus grande simplicité d’écriture et de lecture : plus besoin d’écrire des fonctions js soi-même pour des opérations somme toute assez courantes. Spring Data Mongo par exemple, le très bon projet de SpringSource pour vous simplifier la vie, demande d’écrire des fonctions en js pour faire du map/reduce. Vous avez donc un projet Java, qui contient quand même quelques fichiers js au milieu pour faire certaines opérations. Beaucoup attendent donc avec impatience l’arrivée du support du framework d’aggrégation dans Spring Data. Espérons qu’il ne tarde pas trop! En attendant d’autres frameworks comme Jongo l’ont déjà intégré. Il y a toutefois quelques limites comme le résultat de l’aggregate qui doit faire moins de 16Mo. Bref tout n’est pas idéal, mais ce très bon produit s’améliore à chaque version!

Getting Real : a book review

Cette semaine j’ai lu un livre que j’ai adoré : ‘Getting Real‘. Sorti en 2005, il est probable que vous en ayez entendu parler. Il est écrit par la société ‘37 Signals‘, startup américaine dont le produit phare est Basecamp, l’appli web de gestion de projet. Vous ne les connaissez peut être pas, mais ils sont également à l’origine du projet Ruby on Rails, rien que ça. Leur philosophie est de réaliser des applications web et de les sortir le plus rapidement possible pour obtenir le feedback utilisateur, d’où le titre. Et les 170 pages valent vraiment la lecture!

Dès le début le ton est donné : ce livre représente leurs idées sur la façon de construire des applications web le plus rapidement et le mieux possible. C’est surtout une façon de refuser de faire l’inutile, très proche de la philosophie Lean dont on entend de plus en plus parler. Cela ne représente que leur vision, mais avec plusieurs centaines de milliers de clients et Jeff Bezos (fondateur d’Amazon) comme investisseur principal depuis (10 millions de dollars), on peut considérer qu’il s’y connaissent un peu. Il n’ont rien inventé et le disent, mais chaque page du livre amène son idée (oui, une par page, « smaller » on vous dit) et éventuellement un petit témoignage d’une personnalité du Web.

Bien des choses énoncées sont des mantras de l’agilité : ne bougez pas la deadline, bougez le périmètre. Les specs entières en amont ne servent à rien. Ecrivez de petites histoires. Résolution de problème just-in-time. Pour ce point là, ils donnent leur propre exemple, lors du lancement de Basecamp : il n’y avait pas de système de paiement. Pourquoi? Parce que l’abonnement étant mensuel, ils avaient donc 30 jours devant eux pour l’implémenter, avant qu’un client en ait besoin! Ca c’est just-in-time!

Il y aussi plein de bon sens :
Se concentrer sur une seule idée, mais la faire bien.
La scalabilité c’est pour plus tard.
Faire le code le plus simple possible.
Ne faites pas de réunions.
Vous ne plairez pas à tout le monde.
Dire toujours non aux propositions de fonctionnalité et attendre d’être harcelé pour considérer son développement.
Les mockups d’écran sont le meilleur moyen de commencer une discussion.

Je ne veux pas vous spoiler plus le contenu mais j’ai été frappé par la similarité de leurs idées avec celles que nous avions en fondant NinjaSquad. Construire d’abord des applis pour nous, pour des choses qui nous manquent. Le financement externe est le plan B. Il faut être passionné par le sujet pour faire quelque chose de bon. Une équipe de trois est la taille idéale pour démarrer un projet. Les bons écrivains sont de bons développeurs. Choisissez les outils qui vous passionnent.

Tout ça me parle beaucoup, et la lecture de ce livre a été très motivante pour continuer les petits (et grands) projets que nous avons en cours.

Vous n’avez pas d’excuse pour ne pas le lire, il est gratuit sur leur site. Moi, après m’être flagellé pour avoir attendu aussi longtemps de le lire, je vais m’attaquer à Rework, leur deuxième best seller!

Scala on Coursera

La semaine dernière s’achevait le cours Functional Programming Principle in Scala de Coursera, animé par Martin Odersky en personne. Si vous ne connaissez pas Coursera, sachez que c’est l’une des startups californiennes qui se lance dans le domaine de l’éducation en ligne (l’une de leur dernière recrue est Pamela Fox, speakeuse à Mix-it 2012, et qui, alors qu’elle n’était pas encore employée, avait fait une keynote sur l’éducation). Sur le site, vous suivez des cours en vidéo, vous avez des exercices à faire et à rendre, vous recevez des notes et à la fin un diplome si vous avez été sages. Avec pas loin de 2 000 000 d’inscrits, le site a pris son envol, à juste titre il faut dire car la plateforme est très bien conçue. Martin Odersky, et sa société TypeSafe, frappe donc encore un grand coup marketing en lançant ce cours en ligne sur Coursera. Si ce nom vous est également inconnu, Martin est le créateur de Scala avec une équipe de l’EPFL (Ecole Polytechnique Fédérale de Lausanne) où il est chercheur. Il a également bossé sur le compilateur Java et notamment contribué aux génériques de Java5. On peut donc dire sans trop se tromper qu’il en connaît un rayon en matière de JVM et de langage.

 

Je ne l’avais jamais vu en revanche donner un cours, mais les videos sur Coursera qu’il a réalisé sont claires et compréhensibles à condition d’avoir un minimum d’anglais (et également de faire abstraction de l’accent allemand, qui est quand même plus compréhensible que l’accent français probablement). Le volume de cours n’est pas négligeable : s’étalant sur 7 semaines, il fallait quand même prévoir une à deux heures pour les vidéos et de quelques minutes à plusieurs heures pour les exercices. Mais cela n’a pas décourager les foules : le cours a compté 50000 participants (ou plutot inscrits, je ne sais pas si tous en sont venus à bout). Ce que j’en retiendrais :

 

Les plus :

– la plateforme Coursera : rien à dire, je trouve ça bien très bien fait. Les vidéos sont téléchargeables ou visionnables en ligne, avec une possibilité d’accélérer la lecture qui est très appréciable tout en restant compréhensible. Les exercices sont très clairs, vous téléchargez un projet tout prêt dans le cas de ce cours, une fois terminé, vous pouvez le soumettre en ligne de commande avec ‘submit monmail monpassword’. Des tests unitaires vont alors se lancer sur votre projet directement sur la plateforme et vous pouvez voir votre résultat sur la page de feedback. Il faut patienter quelques minutes mais rien de dramatique. Le système de note est intéressant, avec un petit côté gamification : on cherche à avoir le 10/10 même si une note inférieure permet de valider le cours. Seul point négatif à ce propos : l’absence de trace vraiment explicite pour comprendre quel test et quand votre programme a échoué : on se retrouve à mettre de vieux println dans le code pour essayer de cerner le problème.

– les leçons étaient très souvent intéressantes, mettant bien en avant la programmation fonctionnelle, avec des exemples bien choisis et des solutions élégantes. J’avais lu le livre d’Odersky “Programming in Scala” lors de sa sortie, et j’ai retrouvé des exemples du livre, mais je m’y suis bien moins ennuyé. Les exercices étaient loin d’être triviaux pour certains : celui sur les anagrammes que je pensais faire en quelques minutes m’a finalement pris les 2h de ma pause déjeuner… La progression était correcte, et j’ai eu l’impression d’apprendre des choses tout au long du cours : je pouvais difficilement en demander plus.

– au delà de Scala, difficile de ne pas aimer la programmation fonctionnelle. Et la pratiquer en Java est un vrai plaisir. Les collections scala sont géniales, vraiment. Dans la vie de tous les jours, je pallie comme beaucoup le manque grâce à l’excellente librairie Guava par exemple, et ce n’est pas sans déplaisir que je vois l’arrivée de Java8 (dont de nombreux concepts sont déjà dans Scala).

 

Le moins :

– Certains exercices étaient plus “mathématiques” que “programmatique”, j’avais l’impression de retourner en prépa plus que d’apprendre un langage. On sent ici le côté académique de Odersky et je me demande si cela n’a pas rebuté un certain nombre de participants. Cela se sent aussi sur le langage en lui même, avec son système de type. Ce n’est pas le genre de chose qui m’intéresse outre mesure (que le système de type soit complet ou pas…), et certaines vidéos à ce sujet étaient moins intéressantes à regarder.

– Je me suis limité à utiliser l’IDE conseillé, un Eclipse packagé pour Scala. Et j’ai trouvé l’expérience horrible (je travaille pourtant très souvent sous Eclipse), l’IDE plantait régulièrement, la complétion était longue, les erreurs souvent obscures et lancer les tests était lent. Autrement dit je ne sais pas comment les équipes qui travaillent sur des projets conséquents se débrouillent pour être productives. Il est fort possible qu’il y ait eu un problème avec ma machine, mais j’ai un macbook avec jdk7 assez standard : j’imagine donc que d’autres peuvent avoir ce problème. J’ai vu que beaucoup utilisait TextMate, et IntelliJ pour certains, ce qui est certainement mieux mais pas toujours possible dans une entreprise. Et globalement tout est lent, la compilation, les tests, l’execution… TypeSafe fournit un gros travail à ce sujet mais il y encore du chemin à parcourir.

– J’ai souvent cherché des solutions alternatives une fois mes exercices rendus et je me suis rendu compte que même en connaissant très bien le problème, j’avais parfois du mal à comprendre celles-ci, tant les possibilités et styles peuvent varier. Je trouve ça assez inquiétant pour la maintenabilité d’une application, en tout cas si personne ne prend le temps de bien fixer certaines règles. La liberté amenée par Scala vient avec un prix de rigueur, Odersky le dit lui même dans ses vidéos, n’hésitez pas à nommer les résultats intermédiaires de vos programmes. Et c’est vrai que l’API donne parfois envie de chaîner les appels sur une ligne, il faut donc résister et accepter de perdre en “oneliner” pour gagner en lisibilté.

– Les boucles “for comprehension” sont un concept puissant mais on se retrouve vite perdu entre les types disponibles, les itérateurs déclarés et les filtres. Alors que le code executé est souvent simple, toute la logique se trouve dans la déclaration du for. C’est souvent compliqué à débugger, parfois correct mais incroyablement lent si vous avez fait un mauvais choix (dont on ne se rend pas toujours compte immédiatement). Pour les anagrammes j’avais par exemple une solution qui fonctionnait correctement mais qui mettait 30 secondes de plus pour un itérateur mal déclaré. Il doit y avoir des carnages dans certaines applications… Il est parfois plus simple de faire le code avec des “map” et des “filter” puis de convertir en “for comprehension” par la suite.

 

Si le sujet vous intéresse un autre article bien plus complet sur Scala et Coursera se trouve ici. Je ne peux qu’admirer l’excellence marketing de TypeSafe qui réussit encore une fois un très beau coup (après l’annonce récente de l’entrée de Rod Johnson au board par exemple). Et à titre personnel, je suis content d’avoir participer : j’ai appris de nouvelles choses et voir d’autres langages est toujours un excellent moyen de progresser. Je ne suis par contre toujours pas convaincu pour faire un vrai gros projet de la vraie vie avec. Ou alors avec un mec de chez Twitter ou Foursquare qui vient m’aider à démarrer et à prendre les bonnes options et les bonnes pratiques. Mais on en a rarement sous la main. Je surveille quand même du coin de l’oeil, on ne sait jamais…

Meetup W3C de Lyon

Lundi 28 Octobre avait lieu à Lyon le W3C meetup. Le principe est simple, le w3c prend l’avion avec quelques uns de ses développeurs et speakers et débarque pour faire une série de mini talks sur le web. Organisé en partenariat avec le Grand Lyon, des startups du coin étaient aussi conviées à présenter leurs produits en essayant de les lier, au moins vaguement au web.

Premier bon point pour les locaux, dans l’hôtel de ville, ce qui a quand même autrement plus la classe que le bar ou l’école du coin! Par contre, pas de chaises prévues, tout le monde s’assoit par terre, pendant que les speakers se préparent pour leurs 5 à 10 minutes de talk.

On commence avec ohmytoast, une startup lyonnaise, qui propose une solution pour enrichir vos photos avec des métadonnées, du web semantique, pour créer des albums avec un sens. Le concept a l’air sympa, niveau techno, l’équipe se repose sur html5, css3 et Apache Camel pour la partie serveur.

Le deuxième talk, extrêmement court, était pour moi le plus intéressant de la soirée. En 3 minutes, Rudy Rigot nous montre l’histoire du webdesign et l’intérêt du responsive design. Prenez deux minutes pour voir ses slides, et jouer avec le resize, ca vaut le détour.

Vient ensuite, Eric Daspet qui présente Tea, une solution de lecture d’ebook dans le navigateur, qui repose donc uniquement sur des technos web. Le choix full web du reader n’a pas été simple, mais Eric voit de nombreux avantages (navigateurs présents sur tous les devices, pas de frais liés à Apple ou Google) malgré quelques inconvénients (moins de performances, pas de présence sur les marketplaces). Tea est encore en phase de développement, à revoir dans quelques mois donc.

Viennent ensuite des speakers W3C qui présentent les nouveautés HTML5. Mais bon, ça commence à sentir le réchauffé avec les différentes balises video, audio… Rien d’exceptionnel. Deux développeurs de Mozilla font une démo d’un jeu 3D qui tourne dans Firefox 16 : ils ont développé le jeu en interne (un quake-like) en C++ et un compilateur transpile le code en JS. Ils prédisent donc que de vrais jeux vont voir le jour dans le navigateur dans les prochaines années. Ils montrent également une fonction de login dans le navigateur qui permet de partager facilement des pages avec ses amis par tchat.

Les mêmes développeurs enchaînent ensuite sur une démo de Firefox OS, un OS full html, qui vise les plateformes mobiles. C’est en version très très alpha, avec peu de téléphones qui fonctionnent. Un market sera disponible, les applications étant des pur webapps, avec un packaging léger (un peu comme les webapps Chrome, un fichier json servant à la description de l’application). Des apis supplémentaires ont bien sûr été développées pour accéder à l’appareil photo, passer des appels, etc… Ces apis ont été soumises au W3C pour devenir un jour des standards accessibles dans le navigateur.

Un speaker vient ensuite parler des hyperdevices, autrement dit connecter plusieurs devices avec plusieurs technologies (websockets, réalité augmentée, web sémantique…) et propose quelques démos sympathiques mais souvent déjà vues (dessiner sur un téléphone et afficher le résultat en temps réel sur son écran de laptop…).

Dernière partie, sur les nouveautés du W3C. La seule notable est présentée par Lea Verrou, nouvelle arrivée au W3C, qui nous parle du sitee WebPlatform.org sorti ce mois-ci. L’ambition du site est de devenir la référence en matière de documentation sur les technologies web. Il devrait notamment être enrichi et traduit dans les prochaines semaines et, à terme, une API sera disponible pour permettre aux outils comme les IDEs de récupérer cette documentation.

La soirée se termine avec un buffet excellent qui permet de discuter avec les nombreux participants et quelques speakers. Pour un développeur web qui se tient un peu au courant de l’actualité, ce n’était pas une soirée extrêmement palpitante, mais elle a le mérite d’exister et d’amener quelques noms connus du W3C en France. Et puis le buffet était vraiment bien!

JUGSummerCamp 2012

Premier voyage de l’équipe NinjaSquad, direction La Rochelle pour le JUG Summer Camp. Du Java, du Web, l’océan, une conf gratuite d’une journée avec une organisation irréprochable, il faudrait être difficile pour ne pas aimer!

Keynote : Nicolas de Loof – @ndeloof

Nicolas nous a fait un numéro de stand up très drôle en parodiant le podcast bien connu dans le monde Java : les Castcodeurs. Comme aucun d’entre eux n’étaient présents, Nicolas a eu l’idée de faire un puppet show en reprenant les traits caractéristiques de chacun d’entre eux, pour faire une keynote originale sur notre métier. Franc succès dans la salle (évidemment seulement drôle si on écoute ce podcast).

La journée se déroule ensuite sur deux tracks de confèrence, il faut donc faire des choix.

Google TV : Olivier Gonthier – @rolios

Première présentation sur la Google TV, petit boîtier qui permet de faire tourner des applis Android sur votre télé, mais pas encore disponible en France (on ne connait même pas les partenariats avec les opérateurs). Le principe est simple : une prise HDMI en entrée reçoit le flux vidéo et une prise HDMI de sortie le renvoie vers la TV. A noter que le code de Google TV n’est pas open source. Sinon techniquement c’est le même market que les applis Android traditionnelles.

Commençons par le point qui fâche et qui, à mon sens, fait perdre tout l’intérêt de la chose : il n’est pas possible de récupérer le flux video, ni la chaine visionnée par l’utilisateur, donc vous pouvez oublier toutes les idées d’applications contextuelles: IMDB sur le film en cours ou les stats du match que vous êtes en train de regarder, c’est foutu!

Mais il y a deux ou trois trucs intéressants quand même : par exemple, le « second screen app« , qui permet aux devices Android de s’interfacer avec la GoogleTV et de vous servir de télécommande ou mieux, d’écran annexe pour certaines applications. L’exemple que je trouve assez cool : un jeu de poker Hold’em où la TV affiche la table de jeu (avec les cartes communes et les mises) et chaque joueur voit ses cartes sur son téléphone. Ce genre d’application peut avoir un grand potentiel, je suis sûr que l’on va voir apparaître des applications géniales!

Le développement est de la programmation Android traditionnelle, le SDK étant complété avec des fonctions pures TV (touches telecommande par ex). Si vous souhaitez développer une application Android utilisant le « second screen », vous pouvez utiliser Anymote library (voir dans les exemples de code fournis par Google, dans l’application Blackjack TV).

Il est également possible de développer des applications en html5, la GoogleTV ayant un très bon navigateur Chrome intégré (très bien documenté d’après le speaker). Il est aussi possible de packager votre application avec Phonegap pour la distribuer directement sur le Market.

En plus j’ai gagné la GoogleTV du concours, yay!

Node.js : Romain Maton – @rmat0n

Romain faisait une présentation générale de Node.js (voir articles précédents et les excellents articles de Romain) avec quelques rappels sur les principes de base. C’était une présentation très orientée web-app avec le framework web Express et son moteur de template par défaut Jade (cf article précédent également).

Puis les modules importants :

– l’incontournable Socket.io pour faire des websockets

– logging avec Winston

– nodemon, redémarrage automatique dès que vous modifiez un fichier.

– forever pour relancer l’application en cas d’erreur qui coupe l’appli

– jasmine, qunit pour les tests

Et pour terminer une petite démo sympa avec la librairie speak qui fait parler le navigateur pour annoncer le prochain bus qui passe.

Start me up : Nicolas de Loof – @ndeloof

Après le buffet repas le plus incroyable pour une conf que j’aie vu (les membres de l’orga Mix-it présents étaient impressionnés), on reprend avec ‘Start me up’ ou comment passer rapidement de l’idée à la réalisation (en utilisant Cloudbees, dont Nicolas est employé). L’idée est ici de faire un mini moteur de recherche sur les talks de la conf. Nicolas utilise au passage un autre service dans le cloud que je ne connaissais pas : WebSolr, un Solr as a Service. Cloudbees on aime bien, Mix-it est hébergé gracieusement dessus et ça marche très bien (le support a toujours été très réactif en cas de problème).

La présentation est intéressante, Nicolas étant un bon speaker, mais si vous avez déjà vu une présentation de Cloudbees le contenu ne vous surprendra pas (comment déployer, comment gérer ses instances, comment déclarer des propriétés pour le déploiement etc.). La nouveauté la plus notable est sans doute le Click Start, qui permet en un clic de créer tout ce qui va bien pour un type d’application (squelette du projet, repository de code, instance jenkins, base de données et instance de run). Pour l’instant, quatre types de Click Start sont disponibles (JavaEE6, Hibernate/Tomcat, Rest/Backbone, Scala/Lift).

Du legacy au cloud : David Gageot – @dgageot

David est un excellent speaker que je vous recommande de voir si il est dans une conférence à laquelle vous assistez. Son talk est du pur live coding, sans aucun slide, et reprenait le kata de Gilded Rose où une application existante doit être refactorée.  Une spécification est disponible, mais David ne recommande pas particulièrement de la lire pour commencer mais plutôt de créer des tests sur le code existant que l’on doit retravailler. La logique étant que si l’application convient aux utilisateurs actuellement, le plus important est de préserver son fonctionnement. Les tests sont assez simples à écrire, on appelle chaque méthode et on colle dans le assert le résultat renvoyé : on obtient ainsi une série de tests au vert qui seront notre sécurité.

David utilise le plugin infinitest qui relance les tests dès que le code est modifié : si vos tests sont très courts, le feed-back est immédiat.

La marche à suivre pour refactorer le code est la suivante :

– augmenter la symétrie (mettre les if/else et les equals de la même façon, en enlevant les conditions inversées par exemple).

– puis faire apparaître les duplications de code afin d’extraire de nouvelles méthodes

David finit par introduire de la délégation (un objet était passé dans toutes les méthodes de la classe), en utilisant une annotation de Lombok.

Une fois le code propre, David écrit un petit serveur http qui expose les données en JSON, déploie l’application sur heroku, puis déploie un front statique sur Github Pages (comme le blog de NinjaSquad) qui consomme les données.

Le tout en 45 minutes, en expliquant très bien ses choix et en utilisant IntelliJ avec maestria. C’est la présentation que j’ai préféré de la journée, même si parfois le refactoring était un peu magique, David connaissant bien le code et étant pressé par le temps. Si vous voulez tester le dojo par vous même, les projets sont disponibles sur le compte Github de David.

Beaglebone = Arduino^10 : Laurent Huet – @lhuet35

Laurent nous faisait descendre de quelques niveaux d’abstraction avec un talk sur Beaglebone, une carte plus puissante qu’un Arduino, un peu du même type que le Raspberry Pi. La présentation était intéressante, avec une explication générale des principes, une démo, et les technos que l’on peut faire tourner sur ce type de cartes (C/C++, Java, Python, Node.js …). Manque de chance pour Laurent, sa carte de démo avait grillé la veille (les risques du métiers), mais son talk n’en a pas été trop perturbé, bravo à lui!

Programatoo pour les grands : Audrey Neveu – @audrey_neveu et Ludovic Borie – @ludovicborie

Vous avez peut être entendu parler de Programatoo, un atelier de programmation pour initier les enfants dès l’age de 6 ans aux joies du code. Audrey et Ludovic nous ont montré les différents outils que l’on peut utiliser pour  éveiller la curiosité des plus petits (je ne sais pas si cela peut fonctionner avec vos collègues également) : Scratch, KidsRuby ou encore TortueScript. Très sympa, si vous avez des enfants, ce genre d’outils devraient vous intéresser!

La journée de conf se termine déjà, l’assemblée se dirige vers le port pour un repas tous ensemble. Le JUGSummerCamp aura été une très belle journée, superbement organisée par Jerôme Petit, Orianne Tisseuil et leur équipe. L’équipe Mix-it en partie présente compte bien leur emprunter quelques bonnes idées! Si vous avez l’occasion de vous rendre à la prochaine édition, n’hésitez pas, la conférence, gratuite, est l’une des toutes meilleures en France et la Rochelle et ses alentours ne manquent pas de charme pour rester quelques jours supplémentaires!

Je deviens un ninja!

Et oui, avec quelques amis, nous avons fondé la société Ninja Squad, et je serais donc officiellement un ninja dans quelques jours. Je suis très heureux de me lancer dans cette aventure et c’est avec impatience que se sont écoulés les derniers mois. Nous y voilà enfin et vous pouvez lire plus de détails sur notre blog avec l’annonce officielle.

Notre ambition est de réaliser des projets qui nous tiennent à coeur, open sourcer des outils et nous allons également faire profiter la région de nos services, aussi bien en prestation de développement (ce que nous adorons faire), qu’en conseil ou expertise plus ponctuelle et formations.

Si vous suivez ce blog ou que vous connaissez Mix-IT, vous savez que cette société sera Agile avec du Java, du Web et du Mobile!

Mes compagnons sont :

– Agnès Crépet, JDuchess active sur tous les fronts, du LyonJUG, à Mix-IT en passant par Cast-IT

– Cyril Lacôte, ex-Googler (auteur en grande partie du site de Mix-IT)

– Jean-Baptiste Nizet, top 0.01% de Stack Overflow

Alors si vous cherchez une petite équipe de dév qui va bien, vous savez à qui penser!

Getting started with Apache Camel : Part 1

Je voulais écrire un court billet sur les tests dans Camel. Puis je me suis rendu compte que je n’avais jamais évoqué Camel sur ce blog. Ce qui est un peu étrange vu que c’est le framework que j’utilise tous les jours, sur plusieurs projets, depuis plus d’un an. Et que c’est l’un des outils les plus cools et les plus indispensables pour garder votre intégrité mentale dès qu’il s’agit de router des messages entre différentes machines/protocoles/wtf has imagined the architect guy before you.

Donc je vais vous raconter comment on peut faire des trucs géniaux dans Camel. D’abord le nom complet est Apache Camel, un projet qui fête ses 5 ans, avec pas mal de contributeurs, dont une grande partie vient de la société FuseSource (récemment acquise par RedHat). Pas vraiment de soucis à se faire sur la maturité du projet donc. Mais à quoi ça sert ? Il faut voir Camel comme un routeur de messages entre vos différents applicatifs, certains appelleront ça un ESB léger. D’ailleurs Apache Service Mix, qui est l’artellerie lourde en matière d’ESB Apache se base sur Camel pour sa gestion des routes. D’autres appelleront ça un framework d’intégration, à la Spring Integration mais en plus complet et plus agréable à utiliser. D’ailleurs si vous êtes un fan de Spring, aucun problème l’interopérabilité est vraiment excellente.

Les introductions à Camel me laissent toujours un peu sur ma faim, sans doute parce que ce n’est pas au premier coup d’oeil que l’on comprend sa puissance. Mais au fil des projets, on tombe sur souvent sur des use cases qui correspondent exactement à ce que propose Camel dans un de ses nombreux modules ou patterns, et c’est la que la magie opère. Ce n’est pas rare que l’on me demande d’ajouter une fonctionnalité et que Camel permette de répondre : ‘Pas de problème, il y a un pattern qui fait exactement ça’.

Il faut un peu de temps pour se faire au fonctionnement et appréhender les différents patterns. Car, au début, Apache Camel à été créé comme une implémentation Open Source des EIPs (Enterprise Integration Patterns), qui sont à peu près aussi chiants à lire que les Design Pattern : tant que l’on n’en a pas eu besoin ça n’a pas vraiment de sens.

Organisation
Quand vous démarrez un projet, vous n’avez besoin que d’une seule dépendance : camel-core (actuellement en version 2.10.x). Elle contient les fameux EIPs de base ainsi que la gestion des protocoles les plus courants (fichier par exemple). Ensuite si vous voulez faire quelque chose d’autre comme des appels ftp, il faut ajouter le module correspondant, camel-ftp, dans vos dépendances. La liste des modules disponibles est impressionante : vous pouvez interagir avec tout ce dont vous pouvez avoir besoin : de MongoDb à un AS400 en passant par un LDAP, Nagios, JDBC, des flux RSS… Il y a également des modules qui ne sont pas dans le repo officiel (c’était le cas des Websockets jusqu’à peu encore) car ils sont en cours de stabilisation, ou d’autres pour des problèmes de licence (module SAP par exemple). Tous les protocoles réseaux sont également gérés. Bref il faut faire quelque chose de très très exotique pour ne pas trouver son bonheur.

Pour avoir modestement contribué à quelques bugfixes et features, le code du core est très bien pensé, écrit et testé. Les modules sont eux de qualité un peu plus variable, mais tous ceux couramment utilisés sont très bien faits et production-ready.

A quoi ca ressemble une route ?
Ces routes peuvent être écrites en XML, mais comme 95% des développeurs je trouve ça pas terriblement fun, j’utilise l’autre alternative, la DSL fournie par Camel, qui permet d’écrire les routes directement en Java (qui a en plus l’immense avantage de vous donner l’autocomplétion dans votre IDE). C’est un peu perturbant au début, parce que l’on écrit pas des méthodes comme dans un projet classique, on écrit la déclaration des routes que les messages vont suivre dans l’application.

Par exemple :

from("file://inbox?delete=true").to("bean:handleOrder").to("file:outbox");

Voilà, ça c’est une route. Basique certes, mais qui permet de récupérer un fichier dans un répertoire inbox, d’envoyer son contenu (que l’on imagine être une liste de commande) à un bean Java qui s’occupera de les traiter, avant de placer le fichier de commandes traitées dans un répertoire outbox.

Même si on a jamais fait de Camel de sa vie, la DSL se lit assez bien, une déclaration de route se fait de la façon suivante :
– un point d’entrée (identifié par le ‘from’) qui s’appelle un Endpoint en langage Camel. Le triplet de déclaration d’un endpoint est souvent le même à savoir un protocole (ici ‘file’), un nom (ici ‘inbox’ qui correspond au répertoire) puis des options après le ? (ici pour indiquer que les fichiers sont supprimés après lecture)
– un ensemble d’étape (identifiés par ‘to’), la dernière étant le point de sortie, sur le même modèle.

Dans cette route il n’y a pas de pattern particulier, c’est une route basique du type ‘mon message va de là à là’. Camel va se charger pour vous de faire les conversions de type nécessaire. Si les commandes sont en xml dans le fichier, il va convertir le xml en objets Java pour pouvoir appeler le bean de traitement de commande, puis reconvertir en xml pour les placer dans le fichier de sortie.

Admettons que maintenant votre système de commande expose également un webservice REST qui doit appeler le même bean et également pousser le fichier de commandes traitées dans le répertoire outbox. Easy! D’abord on découpe la route précédente en 2, grâce au mot clé ‘direct’ qui est en fait un moyen de créer des sous routes.

from("file://inbox?delete=true").to("direct:orders");
 from("direct:orders").to("bean:handleOrder").to("file:outbox");

Maintenant ajouter le webservice se résume à créer une route qui écoute les requêtes entrantes grâce au module cxfrs pour du REST et qui appelle la route direct:orders

from("cxfrs:bean:orderRest").to("direct:orders");

Il y a bien sûr un peu de code pour indiquer à cxfrs que l’on attend les requêtes sur tel port avec tels paramètres, mais la route en elle-même se réduit à ça.

Pattern
Avant de voir un premier pattern, il faut comprendre comment sont organisés les messages dans Camel. Nous avons vu que la déclaration de route est une suite d’étapes. Entre chacune de ces étapes, l’objet qui va transiter est un Exchange, qui contient un message In et un message Out. A chaque étape l’exchange entre avec le message In rempli et le message Out vide, puis la partie Out va être remplie avec le résultat de l’étape. Lors de l’étape suivante, ce message Out va devenir le message In et ainsi de suite. Une fois que l’on a compris ce principe de chaine (un out devient le in de l’étape suivante, qui remplit le out, qui devient à son tour le message in de l’étape suivante etc…), tout devient très simple. Un message en lui même est composé d’un ensemble de header et d’un body.

Donc si vous voulez utiliser un pattern Camel comme par exemple filtrer les messages, vous utilisez la fonction filter dans la DSL

from("direct:orders").filter(header("filiale").isEqualTo("Europe")).to("direct:europe");

Si vos commandes de la filiale Europe doivent subir un traitement spécial, vous pouvez filtrer les messages sur ce header. Camel fournit pas mal de méthode pour établir ces filtres de façon simple (ici sur un header), mais vous pouvez également appeler une méthode de votre métier pour filtrer.

Allez, un dernier exemple de pattern moins connu que filter et qui sert beaucoup : ‘recipientList’. Il permet de router dynamiquement un message.
Par exemple :

from("direct:orders").recipientList(header("filiale").prepend("direct:"));
 from("direct:europe").to(...);
 from("direct:asie").to(...);

Camel va appeler la sous-route qui correspond à la bonne filiale. Si vous ajouter une nouvelle filiale dans votre SI, vous avez seulement à écrire la sous route qui correspond. C’est pas cool ça?

J’ai encore des dizaines de trucs géniaux sur Camel, mais on va s’arrêter là pour aujourd’hui et on reprendra la prochaine fois. Stay tuned!

Play tips – Test with an embedded mongodb

Si il y a deux outils que j’affectionne en ce moment, c’est bien Play! (v1.2.5, la v2 ne m’a pas encore convaincu) et MongoDB. Pour ceux qui ne connaissent pas Mongo, c’est une base de données NoSQL orientée document qui écrase un peu la concurrence actuellement. Pour synthétiser les points forts de celle-ci en quelques lignes (car ce n’est pas le sujet de ce billet), on vous dira que :

– MongoDb n’a pas de schéma, vous n’avez qu’à envoyer un objet en JSON, et il stocké, point barre.
– MongoDB va stocker votre objet comme un document en BSON (un encodage binaire du JSON)
– MongoDB vous donne une API javascript pour faire des requêtes, mais des drivers sont existants dans la plupart des languages.
– MongoDB est très performant. Et qu’en plus si une instance ne suffit pas en prod, vous pouvez en mettre plusieurs, et le sharding (la répartition de vos données entre les différentes instances) se fait tout seul.
– Mongo gère la réplication entre instances, mais également la consistence de votre base (ce qui n’est pas le cas de toutes les bases NoSQL) à travers un fichier de log des opérations entre autres.
Et globalement tout ceci est assez vrai. Mongo n’est surement pas la base de données ultime mais elle rend de très bons services si l’on a des choses un peu volumineuses à stocker.

Si vous avez testé Play!, vous avez surement déjà remarqué le système de persistence assez bien foutu. On annote une entité, on lui fait étendre une classe Model et ça roule. Et bien, pour MongoDB c’est à peu près la même chose.

Vous devez commencer par ajouter Morphia dans les dépendances du projet. Morphia (hébergé sous google code, si je vous jure, ça existe encore) est un petit ORM Java/MongoDB qui marche pas mal, et justement un module Play existe. on édite donc le fichier dependencies.yml pour ajouter Morphia.

 - play -> morphia 1.2.9

Un petit coup de “play deps” en ligne de commande pour récupérer le module et nous sommes prêts. Dans votre projet, prenez (ou créez) une entité, par exemple App

	@Entity
	public class App extends Model {
	public String name;
	}

view raw App.java hosted with ❤ by GitHub

Si on ajoute un simple test unitaire

	import models.App;
	import org.junit.Test;
	import play.test.UnitTest;
	import java.util.List;
	public class AppTest extends UnitTest {
	@Test
	public void saveNewApp() {
	App app = new App();
	app.name = "camel-ref";
	app.save();
	List<App> apps = App.findAll();
	assertEquals(1, apps.size());
	}
	}

view raw AppTest.java hosted with ❤ by GitHub

et qu’on le lance, le test échoue lamentablement à se connecter à votre MongoDB. Normal! Et le but de ce billet et de vous montrer comment lancer ces tests d’intégration sans installer MongoDB sur une machine. Pour cela une petite lib très pratique existe : embedmongo. Vous pouvez l’ajouter dans votre fichier de dépendances :

- de.flapdoodle.embedmongo -> de.flapdoodle.embedmongo 1.16

Nous devons compléter notre test unitaire pour démarrer une instance Mongo avant le test. La plupart des articles illustrant l’utilisation de cette librairie montre des exemples de tests unitaires où l’instance est démarrée dans une méthode annotée @BeforeClass (qui, comme vous le savez sans doute, sera executée avant les tests). Mais Play! fonctionne un peu différement puisqu’un test unitaire Play! (qui étend la classe UnitTest) démarre en fait l’application avant de lancer la classe de tests et notamment les plugins utilisés comme Morphia. Si nous utilisons une méthode annotée @BeforeClass , le test va échouer car Morphia ne parviendra pas à se connecter à l’instance embarquée qui ne sera pas encore démarrée. Un moyen simple de contournement est de créer notre propre classe de base pour les tests unitaires qui utilisera notre Test Runner plutôt que celui par défaut de Play! En fait, notre Runner va tout simplement étendre le Runner de base mais démarrera l’instance Mongo avant de démarrer Play! Get it ?

Voila donc notre classe de base de test (qui remplace UnitTest et utilise donc notre propre runner de tests)

	@RunWith(MongoPlayJUnitRunner.class)
	public class MongoTest extends org.junit.Assert {
	@Rule
	public PlayJUnitRunner.StartPlay startPlayBeforeTests = PlayJUnitRunner.StartPlay.rule();
	}

view raw MongoTest.java hosted with ❤ by GitHub

et notre Runner, qui démarre l’instance avant d’appeler le runner de Play!

	public class MongoPlayJUnitRunner extends PlayJUnitRunner {
	static int PORT = 27017;
	static {
	try {
	MongodConfig config = new MongodConfig(Version.V2_0, PORT, Network.localhostIsIPv6());
	MongodExecutable prepared = MongoDBRuntime.getDefaultInstance().prepare(config);
	prepared.start();
	new Mongo("localhost", PORT);
	PlayJUnitRunner.StartPlay.rule();
	} catch (IOException e) {
	Logger.error("Could not start embedmongo instance");
	}
	}
	public MongoPlayJUnitRunner(Class testClass) throws ClassNotFoundException, InitializationError, IOException {
	super(testClass);
	}
	}

view raw MongoPlayJUnitRunner.java hosted with ❤ by GitHub

Notre test devient

	import models.App;
	import org.junit.Test;
	import java.util.List;
	public class AppMongoTest extends MongoTest {
	@Test
	public void saveNewApp() {
	App app = new App();
	app.name = "camel-ref";
	app.save();
	List<App> apps = App.findAll();
	assertEquals(1, apps.size());
	}
	}

view raw AppMongoTest.java hosted with ❤ by GitHub

Tadam! Cette fois le test fonctionne!

Enjoy!

Un an de hype!

Après plus d’un an de blog, et 18 articles, voici le moment idéal de faire un petit résumé des thèmes abordés en 12 mois de hype!

Node
Pas mal de Node.js, peut être le sujet le plus hype de l’année, avec une série d’articles d’introduction :
– Getting started with Node.js (part 1)
– Getting started with Node.js (part 2)
Un complément à cette série avec la présentation du framework web Express (et mise en oeuvre avec un exemple dispo sur github) : Node, Express et Jade.
Si vous voulez coder, il faut également un IDE pratique : Cloud9 propose un outil en ligne, prévu pour faire du node.js.
Enfin deux billets autour de l’actualité de Node et de son écosystème :
– Trello qui utilise Node (de façon assez étrange l’article le plus lu de l’année avec plusieurs milliers de lecture)
– La sortie d’un framework full stack : Meteor.js, assez intéressant pour son côté temps réél intégré.

Hadoop
La deuxième série d’article a été écrite pour le magazine Programmez et publiée en Septembre dernier. Hadoop est un incroyable outil, si vous voulez le découvrir :
– Getting started with Hadoop (part 1)
– Getting started with Hadoop (part 2)

Le site Mix-it
Une partie du succés de Mix-it de cette année est dû au site communautaire mis en place, que nous avons développé avec amour :
– Le pourquoi
– Le comment (avec plein d’outils sympas dedans).

Less
Ou comment le combo Less et Twitter Bootstrap va changer votre vie de développeur web : CSS sucks, do Less!

Play!
Sans avoir d’article vraiment consacré, Play! se retrouve un peu partout avec notamment un article assez lu sur l’annonce de la 2.0 beta à Devoxx :
– Back from Devoxx : Play! 2, hopes and fears
Vous trouverez aussi des traces de Play! dans l’article consacré à Typesafe

Des retours de conf
De la What’s next de l’année dernière à fOSSa en passant par Mix-it (vu du côté orga, comment choisit-on les sessions)

Cast-it
Le podcast qui parle Java, mais pas que, continue! Si vous n’avez pas écouté depuis l’annonce, jetez-y une oreille, l’année fut bien remplie avec des invités locaux et internationaux (Romain Guy, Pamela Fox, Guillaume Laforge…)!

Thanks all for reading!

Le site Mix-it : making-of

Mix-IT est terminé et beaucoup de participants ont apprécié le nouveau site avec ses facettes communautaires et social gaming. En tout cas, nous avons pris beaucoup de plaisir à le faire. Car oui, ce site a été entièrement développé par les soins de notre équipe, particulièrement par Cyril Lacote (qui, il faut le dire doit avoir 60% du code à lui seul), Agnès Crépet et moi même, aidé par le reste de la team, avec leurs propositions, tests et feedback.

Voici donc une liste non exhaustive des outils et technos utilisés :

Trello : nous sommes des fans de la première heure de cet outil, qui nous a beaucoup servi pour échanger (mes camarades globe trotteur étant toujours décalés de plusieurs heures). Trello permet de faire un scrumboard interactif (on est notifié des échanges sur une tache), temps reel, avec un système de vote, label et filtre. Ça n’est pas JIRA mais pour un outil gratuit, c’est un outil génial.

Github : les sources du projet sont gérées sous Git. Aucun d’entre nous n’est un expert mais nous n’avons pas rencontré de problème majeur passés les premiers réglages. Nous avons utilisé le modèle décrit par Github (voir le talk de Zach Holman, et les articles GitHub), a savoir des pull requests, revues par un autre développeur avant d’être acceptées dans le master. C’est une bonne façon de garder une ‘collective ownership’ du code, même sans commiter.

Cloudbees : l’application est hébergée gracieusement par Cloudbees, qui a de plus acceptée généreusement de nous offrir les services additionnels qui nous était nécessaires (SendGrid, base de données en mode étendu, application en mode On Demand). La plateforme est très bien réalisée, le déploiement prend quelques minutes et est très simple à configurer. Ajoutez à ça un support ultra réactif et le fait qu’un déploiement est invisible pour les utilisateurs et vous avez une plateforme de choix pour vos développements.

Techniquement, l’application est codée avec le framework Play! (1.2.4 à l’heure actuelle) : rien à dire là dessus, Cyril et Agnès ne connaissaient pas et étaient productifs en quelques heures, peu de problèmes rencontrés, et avec tout un tas de modules à disposition (recherche full text Lucene, export PDF, parser Markdown). Bref, un outil génial! Un peu de Guava en plus et nous avions nos briques côté serveur. La base de données est un MySQL (hébergement cloudbees oblige).

Côté client, rien de très original, du bon vieux jQuery pour la manipulation de DOM. Et pour faire la même chose côté serveur (en Java donc), nous avons utilisé Jerry, qui nous permet de manipuler le contenu HTML des posts Google+ pour transformer les mentions d’utilisateurs. Nous avons également utilisé un plugin jQuery bien pratique pour gérer la dirtiness des formulaires et empêcher la sortie des pages en cours d’édition : dirtyforms.

Twitter Bootstrap : probablement notre coup de coeur, car même si nous faisons tous du développement, aucun d’entre nous n’est très doué en CSS. Et là, Twitter Bootstrap peut vous sauver : c’est un bootstrap CSS qui vous donne juste ce qu’il faut de cadre pour faire une application web présentable. Inconvénient : beaucoup de sites utilisent la même chose, il faut donc faire un peu de customisation pour différencier votre site. Tous les icones utilisés proviennent de fontawesome. Nous utilisons la version Less de Bootstrap plutôt que la version CSS : pour plus d’infos voir article précédent.

Ce qui n’a jamais atteint la mise en ligne

Nous avions envie de mettre un peu de communication temps réel sur le site avec un système de notifications lorsqu’un participant auquel vous étiez relié effectuait une action sur le site. Pour ça, un projet annexe (disponible sur github également) utilisant nodejs était utilisé. Dès qu’une action était effectuée sur le site, une requête était envoyée à un serveur nodejs, qui notifiait les utilisateurs intéressés connectés (par websocket en utilisant socket.io). La notification se fait sous forme d’une notification HTML5 si disponible dans le navigateur, ou en utilisant le plugin noty. Malheureusement nous n’avons pas eu le temps de terminer cette fonctionnalité.

Maybe next year… D’ici là, vous pouvez trouver les sources sur Github et vous amusez avec!