L’abruti de base qui raille Microsoft, alors qu’il a un iphone (propriétaire) et que son boulot consiste à pisser du Java pour Weblogic (propriétaire) est bien mort. La communauté Java est parfois mal perçue, assez centrée sur son nombril, mais c’est de moins en moins vrai. Nous avons changé en 5 ans. Le rachat de SUN Microsystems par Oracle nous force à regarder vers l’extérieur, et à arrêter de penser que « l’autre, c’est le méchant« .

Le plus important finalement, c’est le métier de développeur. Que tu fasses du C# ou du Java, tu fais ce beau métier de développeur. Et pour cela, je te respecte.

Sur scène, mardi matin j’ai noté que les présentateurs portaient un teeshirt sympa, sur lequel on pouvait voir « Fier d’être développeur ». Intéressé par le sujet, j’ai découvert le site Fier d’être développeur.

Ce mouvement, matérialisé par une association et un site web, avec logo et slogan, aura pour objectif de
- Promouvoir le métier de développeur de logiciels,
- Expliquer la valeur de ce métier alliant rigueur scientifique et force de créativité,
- Communiquer la noblesse du choix de faire carrière en tant que développeur,
- Valoriser l’impact de l’expérience sur l’équation économique des développements logiciels,
- Encourager le respect mutuel entre les développeurs indépendamment des plates-formes et technologies utilisées.

Cette initiative a été lancée par Daniel Cohen-Zardi, PDG de SoftFluent en association avec Eric Vernie et Eric Mittelette de Microsoft France. Je ne connais pas la société ni les auteurs, mais je trouve l’idée sympa.

Je m’engage aussi dans cette volonté de défendre le métier de développeur et la place du développeur en France. C’est un combat que je défends depuis de nombreuses années sur le blog, à travers des articles comme « Développeur après 31 ans ? Ridé et chauve tu seras« .

Aujourd’hui j’ai 36 ans. J’ai été chef de projet, mais j’aime coder. J’aime développer des applications. Je gagne très bien ma vie, car je bosse en permanence pour ma passion. Si je m’étais orienté vers la direction « Chef de Projet », je pense que je me serai rapidement ennuyé.

J’encourage par contre chacun à prendre des responsabilités de manager. Gérer un projet c’est gérer des personnes. Or lorsqu’à 23 ans, en 5ème année d’école d’informatique, on souhaite vous fait croire que vous serez « Chef de projet » en sortant, je crois que l’on vous ment. Cela rassure votre maman et permet de prélever des frais de scolarité plus intéressant.

Si vous devenez chef de projet pour gérer un projet informatique, vous allez vous rendre compte que c’est assez compliqué. L’expérience dit que, pour gérer des informaticiens, il est plus facile d’avoir été développeur, ou d’être encore développeur. Je m’excuse auprès des bons managers qui lisent et qui n’ont jamais tapé une ligne de code. Cela existe. Mais c’est exceptionnel.

Gérer un projet, c’est en fait gérer l’équipe qui réalise ce projet. Cela demande de l’expérience pour comprendre et sentir les forces en présence entre le client et l’équipe. Il faut de l’empathie pour comprendre pourquoi parfois, il est possible de coder en 15 minutes quelque chose d’exceptionnel.

Gérer un projet, c’est gérer un budget et du temps. Or le développeur en informatique n’a rien à voir avec l’ouvrier sur une chaine de montage. A quoi bon lui mettre sous le nez un plan en « jour/homme » calculé au doigt mouillé ? Nous devons donner des estimations de temps pour des choses que nous n’avons jamais fait, alors même que le client n’est pas certain de ce qu’il veut, et qu’en plus il n’arrive pas à se décider… Ajoutez à cela que nous utilisons des technologies jeunes, car ce qui est vieux n’est pas forcément moins cher ou plus utile. Oui, il faut prendre des risques dans ce métier. Il faut surtout apprendre à s’adapter.

Bref vous l’aurez compris, moi j’ai la vision d’un métier où certains développeurs (pas tous) peuvent continuer à coder. Ils seront capable de gérer d’autres développeurs, et seront payés à leur juste valeur. Pourquoi un informaticien compétent ne pourrait-il pas gagner 100 000 EUR par an ? Je rêve du jour où un patron du CAC40 comprendra que 3 développeurs peuvent lui construire un super logiciel, qui lui permettra de garder son poste de PDG, en gagnant des millions d’euros (et donc en créant des emplois).

Les derniers milliardaires aux USA comme le créateur de Facebook sont des informaticiens. Prend ça dans les dents : Steve Jobs était milliardaire avant 30 ans. Bill Gates aussi. Mark Zuckerberg aussi. Les 2 derniers sont des développeurs. Lorsque l’on parle d’eux, on n’ajoute pas « Nicolas, X-Mines » ou « Jacques, HEC-ESCP, Allemand première langue, a fait son CP à l’école des petits Chardons »

En informatique ce n’est pas le diplôme qui compte. C’est ce que tu fais, ce que tu créés. Et si tu n’es pas fier d’être développeur, alors passe la main. Car il y a des gens qui aiment ce métier.

Moi j’en fais partie, et je suis fier d’être développeur.

Fotopedia en quelques mots
Pierre Baillet (@octplane sur Twitter) est DevOps chez Fotopedia. Dev ET Ops. Un gars qui code ET qui pilote une plateforme qui fait plusieurs milliers de visites par jour.

Fotopedia est un site créé par Jean-Marie Hullot, un ancien d’Apple. Et pas n’importe lequel ancien employé d’Apple. Passé par NeXSTEP, vous avez peut-être lu le nom de Jean-Marie Hullot dans la bio de Steve Jobs. Avec une équipe, il a travaillé sur le projet de l’iPhone en secret à Paris.

Fotopedia est un site et un service qui permet de créer une encyclopédie de photos en haute qualité, sur le modèle de Wikipedia. Vous allez à un endroit, vous prenez des photos. Les photos sont sur Fotopedia. C’est simple et c’est génial. Le service est proposé sur iPad, sur les tablettes Androids, sous la forme d’un client lourd et enfin d’un site Internet.

Pierre explique que le site tourne 24h/24, sans aucun temps d’arrêt. MongoDB est une solution qui remplace petit à petit MySQL, car c’est tous simplement un système génial. Il permet de ne travailler que sur de petits exports de données, de faire des réplications, de travailler de manière asynchrone… Bref il a aussi révolutionné les méthodes de développements.

Deuxième contrainte : la scalabilité. Comment s’assurer que la solution pourra continuer à grandir ? Comment gérer le volume de données dans les mois, ou les années qui viennent ? Autant de challenges techniques à relever.

Fotopedia a été créé en 2006, avec aujourd’hui un bureau dans la Valley et un centre de R&D à Paris. Il y a 20 personnes, quelques anciens d’Apple, mais surtout des développeurs passionnés.
Fotopedia c’est un mélange de FlickR et de Wikipedia. C’est aussi une volonté humaniste, en créant des catalogues de photos libre de droits, pour l’humanité. L’Unesco et les équipes de Fotopedia ont développé « Fotopedia Heritage« , une application avec 25 000 photos et 4 000 POI, téléchargeable gratuitement. En 2011, l’équipe a remporté aussi un Crunchies Award pour la meilleur application sur Tablet.

Fotopedia c’est 150 millions de photos vues par mois sur le site et via les différentes applications. Il y a une base MySQL, qui est voie de disparition, mais surtout 4 serveurs indépendants avec à chaque fois 4 bases MongoDB. Tout est hébergé chez Amazon Web Service. Cela représente environ 500 Gb de données structurées, pour ce qui est de la partie MongoDB uniquement.

Un site qui ne peut pas s’arrêter
Le site tourne en permanence, avec donc une particularité intéressante : on ne peut pas l’arrêter. La nuit ne peut qu’empirer mille fois les choses comme dit Roméo à Juliette. Et c’est donc souvent la nuit, que les équipes en France doivent gérer les quelques rares petits soucis. A chaque seconde, il y a entre 400 et 1000 connexions, selon les heures de la journée. Il y a eu par exemple plus de 100 000 téléchargements par jour des applications fotopedia les jours de pointes, autant dire que cela tourne plutôt bien.

Pierre explique qu’il y a d’une part le site web, qui peut avoir quelques instants d’indisponibilités, mais surtout 7 applications différentes sur iOS. Et les gens payent pour ces applications. Autant dire qu’elles doivent marcher, qu’il n’est pas possible qu’elles ne fonctionnent pas car un abruti d’admin système a confondu une prise électrique dans un data-center à Evry.

Lorsqu’il y a cependant des problèmes techniques, toute l’architecture du site est pensée pour que le service se dégrade progressivement. Un paquet de Varnish en frontal permettent de donner quelques dizaines de minutes avant que le site soit vraiment down. Le simple fait d’arrêter le système une dizaine de secondes génère une centaine d’erreurs. Bref, pas un truc de mickey.

Une mise en production chaque semaine, plusieurs fixes par jour
La mise en production est intéressante. Un DSI de base ne pourrait pas comprendre. Englué dans sa méthode à Gilles(!!) de mise en production, il lui faut souvent 2 semaines pour mettre en production sa bouse. Alors qu’ici, des mises en production, il y en a toutes les semaines.

Les équipes utilisent Git, avec plusieurs branches. Chaque mercredi, la branche de dev est poussée en production. Il y a ensuite 3 hotfixes par jour. Parfois 0, parfois 10 hotfixes. Tout le monde a le droit de pousser en production. Si tu casses quelque chose, tu répares. Si tu ne sais pas réparer, tu te casses. Logique.

Les migrations de données doivent donc être transparents. Pierre reviendra plus tard sur l’utilisation et les avantages de MongoDB, qui me fait de plus en plus penser à la différence d’approche entre SVN et Git. Une fois que tu as compris que Git te permet de travailler de manière asynchrone à ton rythme, tu as compris Git. Et bien MongoDB permet aussi de ne travailler que sur des petits subsets de ses données, de faire des dumps sur S3 et de remonter en local les données. More on this later, stay tuned.

Côté infrastructure et surtout framework Web, c’est du Ruby On Rails. Mais bon, de la bouche de Pierre, ça rame. Alors pour que le truc tienne la charge, il faut lui coller un certain nombre de machins comme HAProxy, NGinx, Unicorn Rack HTTP, mongo-resque et d’autres noms de médicaments non remboursés par la Sécurité Sociale…

Côté langages, il y a du Java, du Scala, mais surtout du Ruby. L’équipe travaille sur d’autres solutions, pour avoir de meilleurs performances. Scala est à l’étude en ce moment, mais pour la partie backend. Ruby on Rails reste et restera le framework Web pour l’instant, car il est bien maîtrisé par les équipes. Les premières versions du site utilisaient MySQL, avant que MongoDB ne soit ajouté. Il reste encore aujourd’hui 13 tables. L’objectif est de virer MySQL et de ne garder que MongoDB.

2 ans d’expérience opérationnelles sur MongoDB
L’équipe est plutôt rodée à MongoDB, puisqu’elle l’utilise depuis septembre 2009 en production. Plus de 70% des données de Fotopedia sont stockées sur MongoDB.
Pour le monitoring en production, Pierre cite Munin et surtout Nagios. MongoDB est utilisé aussi pour collecter les logs de l’application. En frontal, ils utilisent Scribe, une solution de Facebook, qui permet de recevoir en temps réel les logs applicatifs, et de les stocker. Scribe est codé en C++ avec des I/O non-bloquantes.
MongoDB est aussi utilisé pour stocker toutes les erreurs, les transactions lentes, bref tout ce qui va mal. Le log d’erreur est limité en taille. 1Go de messages d’erreur, c’est une heure sur le site… Il n’est pas possible de tout loguer.

L’hébergement est à 100% sur AWS. Pierre explique que les machines ne sont pas très fiables. De temps en temps, il faut déplacer rapidement une partie de l’application car Amazon signale un risque d’incident. Il faut alors utiliser des scripts pour recréer une instance en quelques minutes, avant le crash. Grâce à des systèmes de surveillance et de redondances, ce type d’opération arrive cependant rarement.

Côté espace disque, ils sont abondants. Les disques montés sur Amazon sont assez lents. Pour certains traitements non critiques, où vous pouvez accepter de perdre des données de travail, les disques locaux sont plus performants. Les disques locaux sont plus pratique que les EBS (Elastic Bloc Storage).
Pour la base MySQL, ils utilisent AWS RDS. Pas cher et facile à configurer.

Comme le business n’est pas critique (vous n’essayez pas de faire un achat), il est possible de perdre un client en cas de plantage. Vous allez vous retrouvez avec une page d’erreur, vous rechargerez votre page, et vous pourrez continuer votre navigation. Tout le site est pensé en asynchrone, sans session.

Utilisation quotidienne de MongoDB
Tout d’abord c’est un excellent outil pour les développeurs. Vous pouvez configurer un serveur MongoDB en local avec une partie des données, commencer à travailler, tout est simple à configurer. En tant que développeur, Pierre explique que lorsque vous passez à MongoDB, votre modèle change beaucoup. Il observe que souvent, on remplace 2 ou 3 tables de base de données relationnelles, par un seul catalogue MongoDB. Tout est vraiment orienté développeur. Le code est plus facile à lire, et finalement, l’application devient plus robuste. En effet, comme il n’y a pas la notion de relation ou de jointure, finalement votre application est codée/pensée pour gérer des objets détachés, sans relation. Tout le code devient défensif.
Vous avez une entité Client avec la notion de Pays… disons que vous n’exportez qu’une partie de la base Client… et bien imaginez que votre code va traiter le fait que le Pays n’est pas présent. Peut-être qu’un simple champ blanc sera affiché sur la page web… ou que votre application plantera…

Ecrire et travailler avec mongoDB c’est donc moins de tables, et moins de requêtes. Le développeur remonte en une seule fois ce dont il a besoin. Pas de problèmes de jointures ou de requêtes en cascade.

Un autre point intéressant, c’est l’évolution du schéma. Si vous avez une base MySQL et que vous devez passer un script ALTER, croyez Pierre sur parole : vous allez boire des cafés. De leur expérience, cela ne marche pas correctement avec MySQL. Il faut arrêter le service, croiser les doigts et attendre que le script passe… ou pas. Parfois même, cela donne des trucs assez moches, surtout si vous utilisez un ORM. Qui n’a jamais réutilisé un champ de la base car il ne pouvait pas toucher au schéma ?

Avec MongoDB, vous avez la liberté de changer le schéma. Après vous avez un cerveau, et vous n’allez pas faire n’importe quoi toutes les 5 minutes. Sinon vous avez un autre problème. Vous êtes intelligent, vous allez ajouter ou changer quelques champs sur votre document. Pas plus. Il faut donc être organisé et réfléchir à son domaine. Mais comme vous êtes un dieu de l’approche Domain Driven Design, pas de soucis pour vous.

Pour que cela fonctionne correctement, vous comprenez bien qu’il faut avoir une architecture particulièrement bien pensée. La couche de présentation est programmée pour dégrader et gérer l’absence de valeurs pour un champ. Ceci permet de continuer un service dégradé pour des parties non-critiques de l’application. Cela facilite aussi les tests et le développement en local. Et bien oui : votre application n’a pas besoin d’un état et d’un modèle complet pour fonctionner.

Lorsque les données doivent être migrées, comme lorsque vous décidez de réorganiser vos champs, il est assez facile de faire des batchs en Ruby sur MongoDB. Cela ne pénalise pas trop les performances. Vous laissez bien entendu le serveur tourner. Un concept simple qui rend inutile les stratégies de migration de cow-boy d’un DBA classique.

Il faut que le code soit prévu pour que la gestion des clés étrangères soit correctement pensé. Typiquement tout le code est défensif. Un développeur peut alors travailler sur un petit subset des données. De toutes les façons il est impossible de monter toutes les données sur le poste de travail d’un développeur. Lorsqu’il faut passer sur les données pour travailler, il faut que cela soit efficace et rapide.

Sur MySQL lorsque tu créés un index cela bloque la table. Sur MongoDB, cela ralentit mais on peut continuer à l’interroger en tâche de fond.

Faites-vous des sauvegardes sur disquettes ?
Du côté sauvegarde et restauration : MongoDB est livré avec des outils pour backuper facilement à la collection prês, plutôt que de travailler sur toute la base, qui n’est pas intéressant. Stockage sur S3, on peut ensuite remonter localement une partie des collections. MySQL avec ses FK c’est quasi impossible. Avec MongoDB on peut remonter une partie de la base, ce qui est très pratique et très simple.

Cela permet au développeur de travailler facilement sur des copies de la production.

Du code, du code et du code
MongoDB a un noyau assez petit. Peut-être 150 000 lignes de C++. Il se compile sans soucis sur des distributions modernes de Linux. 10gen fait des packages par distribution. Il existe des drivers pour la plupart des langages. Les drivers sont maintenus par 10gen.

Du côté Java, le driver n’est pas trop mal codé. Mais ses réglages par défaut ne sont pas optimum pour de la production. Cependant il est facile de trouver des ressources sur Internet, ce n’est pas du tout compliqué.

Du côté de Ruby, le driver de base avait un énorme trou de sécurité. Lorsqu’un client envoyait une requête à un serveur MongoDB, le driver ne vérifiait pas dans les premières versions le corelationID, le numéro de séquence. Et cela donnait des bugs en production assez difficile à identifier. Le souci a vite été réglé, et vu le nombre de projets qui utilisent MongoDB, tout ce qui est sécurité est plutôt bien géré.

Quelques mots sur la configuration en Cluster
L’infrastructure de fotopedia est intéressante. 4 Machines avec à chaque fois, 4 serveurs MongoDB sur chaque machine. Si j’ai bien compris, une machine est primaire, les 3 autres sont secondaires. Pour que MongoDB puisse fonctionner, il faut au moins 3 serveurs (pas forcément 3 machines). Chaque machine a 15 Go de mémoire, bref de quoi tenir la charge quotidienne. Si un serveur secondaire est trop en retard par rapport au serveur primaire, il s’arrête, se vide, et se resynchronise ensuite avec le primaire. Tout est automatique, c’est le principe même de MongoDB.

La configuration d’un cluster est vraiment facile avec MongoDB. Vous pouvez ajouter/retirer à la volée des serveurs, vous pouvez donner des poids, bref faire un vrai travail d’architecte. Si vous voulez avoir un backup, vous pouvez avoir un serveur qui reste tout le temps secondaire. Par exemple une machine avec des disques en Raid10, qui devient, de fait, un serveur de secours.

Côté client, le driver est conscient de la topologie du réseau, ce qui permet de donner de bonnes performances. En terme de haute-dispo, un primaire peut laisser la main à un autre serveur primaire. Il est important de comprendre que MongoDB est défensif. Si un noeud a 50%-50% (2 serveurs) il n’y a pas d’élections, les 2 machines passent en secondaire. Lorsqu’un serveur est en secondaire, il continue à servir les données. Mais il n’accepte pas les écritures. Cela pour éviter d’avoir 2 Masters, et donc 2 écritures de l’application sur 2 machines. C’est pensé si 2 sites perdent la connexion, et ne peuvent plus se voir. Il faut alors une troisième machine pour pouvoir effectuer une élection. Probleme du Split-brain.

Les compromis
Il faut entre 20 et 25 secondes pour ré-élire un master. Pendant ce temps-là, oui il y a un risque de plantage, mais finalement uniquement pour les clients Webs qui inter-agissent avec le site. Pour relativier, on parle d’un site d’images comme dit Pierre. Pas d’un site qui doit sauver le monde ou gérer des essais nucléaires en Iran.

En conclusion
MongoDB est un outil bien adapté aux équipes DevOPS. C’est un outil pour les développeurs qui permet de faire des choix plus tard, bien plus tard qu’avec une base relationnelle. Comprenez bien une chose : l’outil permet de ne pas décider au jour 1 de l’ensemble de votre modèle, et a été pensé pour s’adapter. Forcément, vous n’avez pas de modèles relationnels contraints par la base. L’application se charge de la cohérence et des relations entre les entités. Pierre rappelle que le code est plus simple, et que souvent vous retirez des tables de bases de données lorsque vous passez vers MongoDB.

Pour ma part, j’espère que vous pourrez voir cette présentation à Devoxx France en avril prochain. Les équipes de MongoDB vont aussi soumettre des sujets pour Devoxx France, en Anglais.

Enfin pour terminer, un grand merci à Xebia France pour cette superbe journée !

Quelques contre-arguments
Pour contre-balancer peut-être la présentation, nous pouvons relativiser en disant que Facebook tourne plutôt bien en production avec MySQL[1]. FourSquare a eu un souci avec MongoDB en 2010, comme aussi sans doute d’autres entreprises en ont eu avec MySQL, avec Oracle, avec une multi-prise dans un data-center à Evry…
On trouvera facilement un article d’un gars déçu par MongoDB ou surtout le fameux post sur Pastebin.com dont la véracité a été mise en doute. Vous trouverez d’ailleurs plus d’informations et les réponses de 10gen sur le poste original sur HackerNews.
Bref ne faites pas comme moi, ne soyez pas trop enthousiaste, testez, testez et re-testez. Mais ce retour d’expérience était vraiment riche et intéressant.

[1] http://www.datacenterknowledge.com/archives/2008/04/23/facebook-now-running-10000-web-servers/

Les slides de la présentation :

Dwight explique qu’un des principes de base qu’il a appris au fil des années, c’est l’importance de répliquer les données. Pour réussir, il faut être capable de construire un site web capable de ne pas rendre captif toutes les données qu’il va générer. J’aime beaucoup cette idée. Voyez votre projet comme une source de données. Essayez de ne pas prendre une solution trop captive et trop contraignante, car la clé de votre succès sera les services que vous pourrez construire sur vos données.

Pour s’assurer que les données sont bien sauvegardéss, vous pouvez les répliquer sur différents serveurs. Vous pouvez mettre en place une solution curative avec des backups de votre base. Ou sinon, vous pouvez aussi prévoir une solution préventive au niveau de votre architecture.

MongoDB c’est cela : une base de données type No-SQL orientée document, sans schéma, capable de fonctionner sur un énorme volume de donnée. C’est un serveur qui se configure en cluster en quelques minutes. Bref c’est un système qui coûte moins cher qu’une solution Oracle, et qui permet de répondre à pas mal de besoins. Mais pas à tous.

Aujourd’hui le premier souci est la capacité à monter en charge et à faire tourner sur un même CPU, sur un même espace mémoire, une quantité d’informations plus importante. Traiter en parallèle les données. Sur les bases de données relationnelles, il est acquis aujourd’hui que certaines opérations ne sont pas possibles lorsque le volume et le nombre de transaction à traiter sont importants. Les jointures, la consolidation des données, il s’avère que le prix de tout cela explose au fur et à mesure. Dwight dit que plutôt de parler de « noSQL » il préfère dire « noRelationnal ».

MongoDB est dans la famille des bases de données NoSQL. Jean-Laurent de Morlhon demande pourquoi, alors que l’approche non-relationnelle existe depuis les années 80, pourquoi cette approche est populaire aujourd’hui ? Tout d’abord Dwight explique qu’aujourd’hui, les volumes sont bien plus importants qu’il y a quelques années. L’approche non-relationnel est une solution logicielle, alors qu’il y a 10 ans nous étions dans la solution matérielle. Il y a 10 ans on achetait une machine plus grande. Aujourd’hui on travaille sur le logiciel et on arrête d’empiler la puissance mémoire/CPU.

Dwight explique aussi qu’il y a quelques années, on créait son modèle relationnel pour le minimum de système, en ne pensant qu’à l’application que l’on réalisait à ce moment là. Le souci de cette approche c’est lorsque le métier évolue. Comment garder à peu de frais un schéma ? Comment éviter des développements longs et couteux ? Aujourd’hui, une application et son modèle de donnée doit être pensé pour plusieurs années. Or le stockage devient un problème. Comment stocker et retrouver rapidement ces énormes volumes ?

Je trouve cette idée intéressante. Imaginez vos données comme un immeuble, qui aura besoin d’un ravalement de facade. Plus sérieusement, imaginez l’état de vos données dans 5 ans… Imaginez la quantité et le coût d’exploitation…

Les concurrents de MongoDB ne bénéficient pas de la même couverture médiatique. Apache Cassandra est un excellent produit, arrivé finaliste lors du concours de l’USI 2011. Il existe d’autres solutions comme Redis ou CouchDB, des solutions dites « No-SQL ». Si vous voulez briller en ville : parlez d’Agilité, de Scrum et terminez par une petite saucée de CloudComputing, le tout avec du NoSQL. Les hommes vous trouveront intelligents et les femmes se jetteront sur vous. Ou inversement. Bref.

Dwight parle ensuite d’Oracle, qui se positionne aussi sur ce secteur. Oracle a lancé un système clé/valeur, construit sur le moteur open-source de Berkley. IBM aussi s’intéresse forcément à ce type de solution. Pourquoi ? Car ce sera le nouvel eldorado.

Dans une entreprise traditionnelle, on a souvent une base relationnelle (SGBDR) et une base décisionnelle (data warehouse). Chaque système a ses avantages et ses inconvénients. Une base relationnelle permet de garantir l’intégrité, de gérer les transactions, et de représenter les relations entre les entités du Domaine. Un système de Datawarehouse est pensé pour l’analyse et le reporting sur les données. Enfin Dwight expose que MongoDB se place comme étant un troisième type de base de données. MongoDB offre de l’agilité, une installation et une capacité à s’installer en cluster bien plus simple (et surtout vraiment moins cher) que les solutions classiques des éditeurs comme Oracle ou IBM. Donc on voit ici qu’une entreprise pourra avoir ces 3 logiciels, avec un usage différent à chaque fois.

Si par contre vous regardez le monde des Startups en ce moment, là c’est une toute autre histoire. Traditionnellement, le couple PHP+MySQL+Apache était utilisé pour construire un site Internet. Ruby on Rails est largement utilisé par les startups. Mais comme l’expliquerons les équipes de Fotopedia quelques heures plus tard : Rails n’est pas aussi performant en production que Java/Scala/.NET. Bref, peu importe, si on parlait plutôt de bases de données ?
Et bien MongoDB est une compétence très demandée sur le marché, information que j’ai vérifié :

Source : http://data.story.lu/2011/09/29/facts-and-stats-mongodb-trend

Quelques questions de la salle ensuite parlent des relations entre les développeurs et les DBA. Quelqu’un demande à Dwight son opinion sur le métier de DBA par rapport à MongoDB. Il explique en forçant un peu le trait que tout d’abord, une base de donnée classique, c’est le royaume du DBA. Une base MongoDB, c’est plutôt le royaume des développeurs. En quelques sortes, le développeur prend le pouvoir sur le modèle. Dwight explique qu’il y a des DBAs pour les bases NoSQL, des personnes qui sont souvent aussi des développeurs. L’absence de schéma, sa flexibilité, le fait que ce modèle mappe directement le code, fait que forcément le développeur est le premier évangéliste de MongoDB.

Une autre question porte sur le nombre de clients qui utilisent MongoDB aujourd’hui en production. Personnellement lorsque j’entends ce type de question… ça me fatigue. Il n’y a que les Français pour se dire :
- »Ah moi je prends une techno QUE si c’est utilisé sur de VRAIS SITES ou sur des VRAIS PROJETS.

Pour la société 10gen, aujourd’hui Dwight explique qu’ils ont 400 clients. Il y a bien entendu bien plus de sociétés qui utilisent MongoDB. Dans le monde des startups, 90% des projets qu’il a vu font le choix de l’approche NoSQL, donc souvent MongoDB. Pourquoi ? Car il existe de nombreux drivers pour tous les langages.

Il résume cela avec une phrase en souriant :

It’s happening.

Une question ensuite porte sur Oracle, afin de connaître son opinion. Il voit des entreprises qui ajoutent MongoDB, tout en gardant leur base Oracle. Par ailleurs, Oracle travaille sur des solutions de type MySQL. Et ce sera un compétiteur pour 10gen très important. Il pense que si Oracle venait à ignorer l’approche NoSQL, alors ils perdront des parts de marché.

Pour terminer, nous avons eu aussi une présentation très détaillé de l’importance du schéma sur les performances. Le CEO de MongoDB passe 10 bonnes minutes à nous expliquer le problème de chargement de blocs non-contigus, spécialement lorsque les données recherchées ne sont pas dans un index. C’est impossible pour moi à retranscrire ici.

Mais au final, retenez que le CEO de MongoDB est un Geek, un gars qui assure, et qui peut vous parler de swap et de disques SSD dans une présentation.

Et moi, ça m’a donné envie d’essayer MongoDB.

Les organisateurs ouvrent la soirée par un petit mot, sur les sélections, et sur l’objectif de la soirée.

Chacun s’est préparé avec son binôme. Clavier externe, 2eme souris, un ou deux ordinateurs, tout est très sérieux. Des équipes venues de l’est de la France, du Luxembourg et de Suisse, il y avait du monde.

Remrquez les teeshirts personnalisés des équipes du GenevaJUG et d’inTech :

Quelques chiffres : il y avait 2 femmes et 26 hommes. Sur les 14 binômes, 12 utilisent Eclipse, 2 IDEA IntelliJ. Côté OS, 8 Mac, 6 Windows et 2 Linux. Le binôme des frères Le Merdy est original puisque ce sont de vrais jumeaux. Un autre binôme original : Jean-François et Henri, originaires du Québec, anciens binômes lorsqu’ils étaient étudiants. J’ai appris que le Québec avait un clavier QWERTY spécial. Pas mal de personnes de Vidal Software, Valtech et 4 personnes de la société InTech, avec entre autre Fabrice Croiseaux, directeur associé chez InTech S.A dans l’équipe bleue.

Pour départager les concurrents, David et Jean-Laurent ont préparé un Kata, exercice de programmation. L’objectif de l’exercice est d’ajouter une nouvelle fonctionnalité et de développer une application Web. Premier point : certains binômes n’ont pas réussi à développer l’application Web en 2 heures.

L’exercice est sympa, vous pouvez le faire en lisant les instructions sur la page Github de David Gageot.

Pendant les 2 heures, nous avons vu des idées originales, ou plus farfelues. Clairement, la maîtrise des outils fait la différence. Bien connaître easyMock (dont Henri Tremblay, l’un des concurrents ce soir là est l’un des développeurs), JUnit, moreUnit, FestAssert… Mais attention à ne pas tomber dans le piège des tests, et de passer 2 heures à écrire des tests. Il était important de rajouter la nouvelle fonctionnalité et de construire l’application Web.

Le code du projet est volontairement mal écrit, afin d’évaluer la capacité du binôme à refactorer celui-ci. Cependant, il était interdit de toucher à la classe Item. Vous pouviez la sous-classer, mais sans y toucher. On a vu du Decorator Pattern, du Value Object, des choses avec des Listeners… L’imagination des concurrents a été fertile.

Au bout de 20mn, certains ont fait le choix d’écrire toute une batterie de tests pour reprendre les règles de gestion, et pour pouvoir ré-écrire la classe Inn. D’autres se sont dit que le code marchait (même s’il était bien moche) et ont attaqué par la WebApp. Ici nous avons vu quand même qu’un développeur Java n’est pas un gars qui fait du Web. Il y a ceux qui écrivent à la main un serveur Web (qui marchait très bien), ceux qui ont cloné SimpleHttp à partir du projet de David Gageot. J’ai vu un projet avec Play2 et Java, avec au final une belle application basée sur Twitter Bootstrap.

Twitter Bootstrap est un projet simple, un ensemble de feuilles de style, que vous pouvez ajouter en quelques instants à votre web-app. Le bootstrap donne les bases d’une application Web correcte, comme on en fait en 2012. Le système de grille ou les styles des tableaux permettent de construire une application Web qui ressemble à quelque chose. Niveau HTML, j’ai vu des trucs pas très beaux. On a vraiment l’impression que les développeurs Javas ne connaissent pas HTML. Je referme la parenthèse.

Plus la soirée avance, plus la tension est palpable. Des binômes discutent ardemment sur des points précis du cahier des charges… D’autres se plaignent de la lenteur de leur IDE… David et Jean-Laurent passent voir chacun des groupes, de table en table.

Vers 22h00, le concours est terminé. Chacun des binômes raconte son expérience, ce qu’il a fait et ce qu’il n’a pas fait. Le code de chaque équipe est relevé, et le lendemain, ce sera finalement 5 équipes sur les 14, qui seront retenues. Voir la liste des finalistes sur le site de Code-Story.

Rendez-vous le mardi 14 février pour connaître enfin le nom du binôme qui accompagnera David et Jean-Laurent à la conférence « Devoxx France » fin avril…

Interview de Jean-Laurent de Morlhon et de David Gageot

Cette semaine, rendez-vous avec Jean-Laurent et David, qui organisent le concours « Code Story » pour Devoxx France. Voyons un peu ce qui vous attend, et quelques informations sur le déroulement des sélections.

Nicolas : Bonjour à tous les deux, merci d’avoir accepté de prendre un peu de temps pour répondre à nos questions. Jean-Laurent, David, pour vous présenter aux quelques rares Geeks qui ne vous connaissent pas, je vais vous demander un petit exercice. Présentez l’autre en 140 caractères… et pas le droit d’utiliser d’URL Shortener

Jean-Laurent : David est indépendant. Il aime le code simple qui fonctionne et cherche toujours le petit truc en plus pour être encore plus direct et efficace.

DavidL : J-L est CTO de Xebia. Il aime le code simple qui fonctionne. Il sait monter des super équipes de dév. et les aider à monter en puissance.

Première question : comment tout a commencé et d’où vient l’idée de Code-Story ?

L’idée de base est de trouver un binome pour nous aider à faire 2 jours de live coding pour Devoxx France. Car à deux on doutait de notre capacité à transmettre quelque chose d’enrichissant pour le public tout en développant sans concession. On aurait pu chercher des amis dans la communauté, on a tenté le petit concours histoire de faire un peu de buzz et aussi un peu juste pour voir si ca marche.

Au premier tour, il y a eu plus de 60 soumissions de code par plus de 60 personnes. On peut dire que c’est un succès, dont on ne soupçonnais pas l’ampleur. Certaines personnes ont aussi juste balancé par twitter ou sur github des solutions, sans même chercher à nous contacter ou à pariticiper. L’ampleur de l’engouement nous a clairement dépassé.

Pour le deuxième tour, on a sélectionné 39 de ces personnes. Quelque unes ont du abandonner à cause de la distance géographique. On aura donc 14 binômes chez Xebia le 1 février, on va binomer avec eux, histoire de voir en situation reelle avec qui on “fit” le mieux.

Combien de binôme iront en finale ?

Du deuxième tour ne « survivront » que trois ou quatre binômes. La crême de la crême…

Est-ce qu’il y a des binômes seul et des binômes à trois ? Comme dans la Vérité si je mens : on partage en trois : moitié, moitié et moitié…

Que des vrais binômes. Au premier tour, il y avait une 6-team mais 12 mains sur un clavier, on pense que c’est un peu compliqué.

Donc c’est un combat à la mort pour la finale ?

A mort en effet. Il ne doit rester que deux personnes pour nous accompagner à Devoxx France. C’est avec ce binôme que nous allons nous préparer. L’idée est de trouver deux développeurs avec lesquels nous aurons un bon feeling. A Devoxx, nous mélangerons les deux binômes en permanence.

Serons-nous autorisé à être déguisé le soir de la finale ?

Nous ne voyons pas de quel droit on pourrait t’interdire de te déguiser Nicolas. Tu as l’air de bien aimer ça. Mais souviens toi que l’on recrute des super développeurs pas des clowns ventriloques !

Quelle proposition de code vous a fait le plus sourire/marrer/hurler de rire ?

Il y a le code d’Olivier Croisier qui en bon psychopathe a patché le JDK. Faut pas jouer avec ce bonhomme là ! Il a eu aussi les petits concours de code en 140 caractères sur Twitter. Que du beau code, promis. Un des codes les plus terrifiant implémentait un pattern Visitor avec un Builder afin de résoudre le FooBarQix grâce à un Fork/Join. No comment.

Du côté des langages, est-ce que les candidat se sont lachés ?

Beaucoup de Java et de Scala. Mais aussi du Groovy, du Ruby, du Javascript, du Closure, Fantom, du Yeti, du Erlang, de l’Assembleur (si si), du C, du Ioke et du Gosu. Tout ça sur une même JVM (enfin, on a fermé les yeux et fait comme si). N’oublions pas une implémentation en Play!, un plugin maven et même des scripts bash. Je crois qu’on peut dire que les candidats se sont lâchés. Cela n’a pas été de tout repos de lire autant de code d’autant de langages différents. On aime ça, et pour certains langages on avait des points de comparaisons interessant.

Lorsque ma femme regardait « La nouvelle Star » (car moi je ne regardais pas, hem…) il y avait toujours un moment où un gars arrivait aux sélections plié en deux, l’air tout misérable, et en fait chantait comme un Dieu. Par exemple, Christophe Willem.

Donc est-ce que vous avez vu des personnes vraiment surprenantes ou pas encore ?

Pas encore, le premier tour se faisant pas mail, on a pas rencontrer directement les gens. Le deuxième tour va être plus surprenant. On cherche un binôme qui sait coder, qui sait aussi raconter ce qu’il code et que ca soit enrichissant, le tout devant 40 personnes, donc pas un steak de grosse SSII. On espère avoir l’embarras du choix.

Comment va se dérouler la soirée du 14 février au Paris JUG ?

On part du principe du Randori, c’est à dire un seul sujet et des binômes qui alternent toutes les 5 minutes sur le même clavier.
On le rend plus fun en modifiant les règles au fur et à mesure et un ajoutant un jury qui buzze les binômes. Chaque binôme qui est buzzé après la pause du buffet est éliminé. Il ne doit en rester qu’un !
On va impliquer le public aussi pour ajouter de la pression aux candidats !

Si je veux gagner, quels sont les 3 super pouvoirs qu’il me faut ? Est-ce qu’il faut être roux par exemple ?

Si tu es roux, barbu et que tu aimes les chatons, tu es déjà sélectionné. On a aussi sélectionné tous les directeurs techniques de Xebia de plus d’1m85. Pour les autres, il faut un niveau « Grand maître » en Java, s’entraîner aux raccourcis de son IDE même sous la douche, ne pas se pose de question métaphysique sur “est ce que faire des tests unitaires ça sert en vrai ?”, avoir la tendance maladive à faire maigrir les poms plutôt que grossir et aimer le travail en binôme.

Est-ce que vous avez déjà commencé à préparer Devoxx France ?

Pour l’instant nous ne sommes que deux mais nous avons pas mal d’idées. Notamment l’organisation de la salle et le sujet du jour J. Mais cela va demander de la préparation et du matériel. Vivement deux personnes de plus pour nous donner des idées pour enrichir tout cela.

D’autres points que vous souhaiteriez évoquer ?

On fait ce concours pour rigoler mais clairement notre but est de préparer une super session pour Devoxx France. Pendant deux jours nous allons développer une application devant un public. Le tout en essayant de montrer des techniques, des outils, des méthodes que tout le monde ne connait pas forcément. Notre objectif c’est que chaque participant de Devoxx vienne nous voir pour une itération d’une heure.

En sortant de la salle, il doit hésiter « Bon maintenant je vais voir Romain Guy ou Matt Raible ou je reste pour une deuxième itération de CodeStory ? »

Merci et à bientôt !

Merci et rendez-vous le mardi 14 février au Paris JUG pour la finale des sélections et à Devoxx France, pour voir Code-Story en direct !

Gatling is a web performance testing tool written in Scala, that relies on Akka, Jboss Netty and Async Http Client to litteraly explode your web application and ensure that it works under heavy stress-load. The project is hosted on Github : https://github.com/excilys/gatling

Gatling en quelques mots
Gatling est un outil opens-source lancé en décembre 2011. C’est un outil de stress qui permet de tester la montée en charge d’un site Internet. Il simule un grand nombre de connexion sur le serveur, en jouant des scénarii pré-enregistrés. Les résultats sont ensuite analysés à posteriori, pour fournir différentes courbes et indicateurs.

Gatling est donc une alternative à JMeter, en exploitant un moteur en Scala à base d’Actors, et en utilisant le principe des entrées/sorties non bloquantes. Il s’appuie sur Akka, sur Async Http Client de JF.Arcand et enfin sur JBoss Netty.

Pourquoi les tests de charge sont importants ?
Pourquoi le test en charge est-il important ? Réaliser des tests de charge est important. Cela devrait faire partie du cycle de développement. Stéphane explique qu’il a enchainé différentes missions, et qu’il a testé les outils du marché : Apache JMeter, Grinder, OpenSTA ou encore HP LoadRunner… difficile de trouver la solution qui l’intéressait. Surtout, particulièrement pour JMeter, son expérience montre que l’outil n’est pas adapté à de très gros tests de charge. Romain explique que JMeter ne dépasse pas les 1514 injecteurs sur une seule machine.
Par ailleurs, Stéphane voyant ce que Scala propose, trouve qu’il y a un sujet intéressant à lancer, et le projet démarre donc en juin dernier avec Romain.

Principes importants
Gatling est une solution asynchrone. En général, les solutions classiques utilisent l’approche « 1 virtualUser=1 thread ». Cette approche est limitée dès lors qu’il s’agit de vraiment « taper » dans le serveur. Cela fonctionne, mais l’injecteur est pénalisé par de nombreux context-switching.

Ensuite, l’asynchrone coule de source si l’on réfléchit quelques instants à ce que font vraiment les visiteurs d’un site Internet. Vous par exemple, vous êtes entrain de lire cet article, un café à la main, l’oeil encore un peu fatigué de votre week-end. Et pendant ce temps-là, le serveur ne fait rien. C’est ce que l’on appelle le « Think-Time ». L’idée de Gatling est d’utiliser ce temps de pause dans votre scénario pour faire exécuter une tâche à un autre virtual-user. Simple non ?
Au lieu de mettre une thread en sleep, ce qui coûte des ressources, Gatling a une Thread d’exécution qui enchaine les traitements. Au final, Stéphane explique que le moteur tourne avec de 30 à 40 threads grand maximum pour environ 12500 Virtual User sur une machine classique, type Intel 4-Core i7. Je testerai cela et je vous donnerai mes résultats.

Les scénarii sont du code
Gatling c’est une arme pour les développeurs. Plutôt des personnes capables de coder. La puissance de Scala et la facilité pour écrire une belle API, permettent à Gatling d’avoir un moteur de scénario très puissant et très simple. Vous pouvez soit écrire un scénario directement sous la forme de code Scala, soit importer un scénario écrit avec du Scala, mais en utilisant l’API.

J’ai travaillé avec de vrais ingénieurs QA, qui savent coder, et je pense qu’il n’y aurait pas de difficultés à leur faire utiliser l’outil. C’est même moins verbeux qu’un scénario OpenSTA.

Ensuite, une idée intéressante, c’est le typage fort et la vérification du scénario à la compilation. Oui, votre scénario est compilé, et donc il est validé avant de l’envoyer sur vos injecteurs. Pas d’interprétation à la volée, qui d’après Stéphane, est trop gourmand en ressources. Avoir un scénario « type-safe » en quelques sortes.

Des rapports sympas
Gatling ne fait pas de reporting en temps réel pour l’instant. L’outil effectue son tir, peut s’appuyer sur une base JDBC en entrée pour charger des données, mais les rapports sont générés à posteriori. L’ensemble est sympa, avec des librairies de Chart en Javascript.
A titre personnel, pour le projet CMesDonnées.com, j’ai utilisé HighCharts. Simple et facile à mettre en place, il fait de très belles courbes à votre projet. Pardon, il donne de belles courbes à vos données.

Les différents composants de l’outil
Gatling est hébergé sur GitHub. Vous pouvez télécharger une version stable dans la section Downloads. Après avoir installé l’outil, vous avez :
- un Recorder, client Swing qui démarre un proxy http pour enregistrer les requêtes.
- un outil de reporting pour analyser les résultats et générer des pages webs de rapport
- le moteur d’injection, qui prend un scénario et qui l’exécute

Il y a aussi déjà un artefact Maven pour faciliter la création d’un projet Gatling.

Techniquement, Stéphane entre ensuite dans les détails de l’outil. J’ai retenu que pour le parsing XML, le plus efficace est VTD-XML. La documentation complète de Gatling est en ligne sur le Wiki.

Pourquoi Scala ?
La motivation au départ était d’utiliser Akka. Ce moteur d’Actor très puissant et très simple à utiliser, permet de découper l’exécution des étapes d’un scénario. Il y a aussi pas mal de stratégie pour gérer les itérations et le branchement conditionnel, d’un Actor à l’autre. La présentation est allée assez loin dans les détails, on retiendra que le principe d’Actor est un outil excellent pour développer une application avec des éléments asynchrones.

Nous avons eu ensuite plusieurs démonstrations de l’outil, pas mal de discussions intéressantes sur l’implémentation et les choix techniques. L’outil est encore jeune mais il fonctionne bien. Vous pouvez le tester et donner votre avis à Stéphane et à Romain.

Pour terminer :
- télécharger Gatling
- le wiki

Chaque rencontre est unique. Ce type de personnage est souvent charismatique, intelligent et fascinant. Enfin moi je le constate depuis que je traine mes jeans dans les conférences. Forcément si tu n’es jamais sorti de chez toi, que tu es encore « vierge de conférence » ce qui va suivre ne va pas t’intéresser, voire te faire sourire gentiment. Encore une fois : j’assume.

Vous utilisez Maven ? Ant ? Junit ? Mais qui se cache derrière ces librairies ? J’ai donc sélectionné 10 personnalités du monde anglophone, qui m’ont marqué et qui sont sur la liste des gens « à rencontrer une fois dans votre vie ».

Joshua J.Bloch

Crédit photo : R.Maton, Web-tambouille.fr

Joshua Bloch est développeur et auteur de livres sur Java, employé par Google depuis 2004. Il a développé une partie de l’API Collections de Java, dirigé la conception de la partie java.math et du principe d’assert. En 2001 il a publié un livre indispensable à tout développeur Java : « Effective Java« . C’est aussi le co-auteur de « Java Puzzlers » qu’il a écrit avec Neal Gafter, employé aujourd’hui par Microsoft. C’est aussi l’auteur de « Java Concurreny in Practice » co-écrit avec Brian Goetz et Doug Lea entre autre. Ces livres doivent faire partie de votre bibliothèque de développeur. Excellent speaker habitué de Devoxx, il est responsable depuis fin 2011 du développement du langage Dart, une alternative à JavaScript, pour les navigateurs internets. Son compte Twitter : @joshbloch

A Devoxx 2010 et Devoxx 2011, ses présentations étaient passionnantes, avec une approche sur des sujets autour de Java qui vous ouvre les yeux. A voir au moins une fois dans sa vie de « Java-iste ».

Jason van Zyl

Crédit photo : M.Figuière Xebia France

Jason van Zyl est le créateur du projet Apache Maven et d’autres projets comme Apache Velocity[1] et du projet Plexus. Fondateur et directeur technique de la société Sonatype, il est aussi membre de l’Apache Software Foundation. Il est aussi connu pour ses prises de décisions parfois tranchées et son caractère bien trempé. Il aura eu au moins le mérite de créer Maven, outil devenu quasi indispensable dans le monde Java.

Pour l’avoir vu en 2009 j’avoue que je n’ai pas aimé son arrogance et sa manière de présenter. Mais ce gars là a pondu Maven, vous ne pouvez pas ignorer son existence. Aujourd’hui la communauté Maven est bien plus large, de nombreux Français sont contributeurs ou ont travaillé sur le projet (A.Héritier, N.de Loof, Emmanuel Venisse, Olivier Lamy, Vincent Massol, Fabrice Bellingard pour ceux que je connais…)

James Gosling
Créateur du langage Java en 1994, ancien ingénieur chez SUN Microsystems. James vient du monde Smalltalk. Après plusieurs années chez SUN, de 1984 à 2010, il quitte SUN pour Google. Depuis 2011, il s’est engagé dans une aventure de startup avec des robots sous-marins. Speaker assez discret et peut-être pas le plus charismatique, c’est en tout cas une personne simple, facile d’accès et passionnante.

Avec Java en 1995, il a révolutionné au bon moment le développement informatique. Java a retiré la gestion de la mémoire au développeur, et a proposé dès le départ le principe du « Write once, run everywhere ». A l’époque le développement devait s’effectuer sur la plateforme cible. En 15 ans l’industrie s’est tournée vers Internet, et Java a permis d’avancer rapidement. A ce jour, il reste toujours premier dans le classement TIOBE 2011 et 2012  des langages de programmation qui mesure la popularité d’un langage, mais pas le nombre de projets effectivement écrits avec Java.

Doug Lea

Doug Lea est connu des développeurs Javas pour son travail sur l’API Concurrent, sur les Threads et pour avoir apporté à Java une librairie puissante dans la gestion de la concurrence. Il est aujourd’hui professeur à la State University of New-York à Oswego. Doug Lea est l’auteur du livre « Concurrent Programming in Java(tm) : Design Principles and Pattern » et co-auteur du livre « Java Concurrency in Practice« . Doug Lea était l’un des rares indépendants faisant partie du Java Community Process. Il a décidé de quitter le JCP fin 2010, suite aux changements politiques provoqués par le rachat de SUN Microsystems par Oracle.

Gavin King

Si vous utilisez Hibernate, et je me doute que vous en avez au moins entendu parler, Gavin King est l’auteur original du framework Hibernate. Salarié chez JBoss RedHat, il est aujourd’hui le développeur principal du nouveau langage Ceylon avec Stéphane Epardaud et Emmanuel Bernard, 2 Français salariés de JBoss RedHat, que vous connaissez sans doute.

Gavin King est aussi l’auteur du framework Seam, qui a proposé une approche orientée conversation, destinée à faciliter l’écriture d’applications webs complexes. Il a été contributeur sur Java EE 6 autour de JPA, JSF et EJB3. C’est le Spec Lead de la spécification JSR-299 Contexts and Dependency Injection for the Java(tm) EE Edition, plus souvent appelé « CDI ».

A titre personnel je ne l’ai jamais rencontré. Basé au Mexique, il serait question qu’il vienne vivre en Europe en 2012. Vous voyez, j’assume mon côté People aussi.

Rod Johnson

Rod Johnson est le fondateur du framework Spring. C’est aujourd’hui le responsable de la société SpringSource, rachetée par VM Ware en 2009. Rod a révolutionné l’approche J2EE fin 2002 avec un livre qui reste encore à ce jour très intéressant à lire : Expert one-on-one J2EE Development. A l’époque où ce livre est sorti, je me souviens que nous étions tous convaincus que J2EE est les EJB 2.1 allaient révolutionner le monde. Ce fut le cas, en donnant à l’industrie une raison pour arrêter de suivre aveuglément SUN Microsystems. Spring a renversé l’oligarchie dans les années 2000 et a donné un coup d’arrêt aux architectures J2EE.

Aujourd’hui en 2012 je pense que Spring est devenu un framework qui se court après lui-même. Bien qu’excellent techniquement, il y a une recherche systématique à vouloir « abstraire » et « simplifier » les frameworks des copains. Prenez le projet « Spring Data » : belle brique technique, on peut s’interroger sur l’utilité de certains projets…

Spring 3.1 est sorti fin décembre 2011, et la société s’oriente rapidement vers le Cloud pour proposer toujours plus d’outils libres et open-source, avec du support professionnel. SpringSource a aussi racheté la société G2One, fondée par Guillaume Laforge (chef de projet du langage Groovy), Graeme Rocher et Alex Tkachman en 2007.

Je pense que Jürgen Höller, le développeur principal de Spring, aurait mérité d’être dans cette page. D’une grande gentillesse, c’est un peu le Wozniak de Rod Johnson. Discret, avec un esprit brillant, c’est le développeur qui a écrit et qui continue à écrire une bonne partie de Spring.

Kent Beck

Kent Beck est le créateur de la méthode de développement « Extreme Programming » dites aussi « méthode XP ». L’eXtreme Programming consiste à pousser à fond toutes les techniques de développement et d’organisation, afin de développer un logiciel d’excellente qualité. C’est aussi l’auteur du principe de programmation visant à écrire les tests avant le code, la fameuse méthode TDD pour Tests Driven Development. C’est enfin le co-auteur du framework JUnit avec Erich Gamma, utilisé pour écrire des tests unitaires dans notre industrie (car nous, on écrit des tests).

Kent Beck est l’un des 17 développeurs ayant signé le « Manifeste Agile« . En 2011 il travaillait chez Facebook. Il a écrit une dizaine de livres autour de SmallTalk, de Java et des pratiques Agiles. Vous pourrez lire régulièrement ses articles sur son blog.

Erich Gamma

Erich Gamma est l’un  des 4 auteurs du fameux livre « Design Patterns: Elements of Reusable Object-oriented Software« . C’est l’un des 4 membres du GoF, dit « Gang of Four » qui comprend Richard Helm, Ralph Johnson et John Vlissides.  Erich a co-écrit JUnit, il a travaillé beaucoup sur l’IDE Java Eclipse, c’était le leader du développement de la partie JDT sur Eclipse. Il travaille d’ailleurs depuis 2011 chez Microsoft dans l’équipe Visual Studio. Il a écrit avec Kent Beck le livre « Eclipse : principes, patterns et plugins« . Bref, Eclipse c’est quelque part un peu Erich.

Martin Fowler

Martin Fowler est un auteur, un conférencier et le responsable technique de la société ThoughtWorks. Il a révolutionné l’approche orientée objet, il est considéré comme l’un des meilleurs spécialistes de la conception objet. Ses nombreux articles et publications influencent l’industrie. Le principe d’inversion de contrôle, rendu populaire par Spring, ainsi que le principe d’injection de dépendances : c’est lui. Son blog est une vraie mine d’informations. C’est aussi l’un des 17 auteurs du Manifeste Agile, il est passionné par toutes les techniques de développements dites « Agile ».

J’ai assisté à une de ses présentations lors de la conférence de l’USI 2010. Impressionnant et passionnant. A faire une fois dans sa vie. Vous pouvez lire mon compte rendu écrit en 2010.

Robert C.Martin dit « Uncle Bob »

Bob Martin a popularisé le principe de « je me prends une petite claque pendant une conférence » en étant un speaker hors-pair, un évangéliste du métier de développeur, et surtout un gars passionnant à écouter. Si vous vous inquietez de votre avenir professionnel, si vous vous demandez si c’est bien « d’être chef de projet à 31 ans » vous pouvez lire « Développeur après 31 ans : ridé et chauve tu seras« , mais surtout vous devez prendre le temps d’écouter « Uncle Bob »

Bob est aussi l’un des 17 créateurs du Manifeste Agile. Passionné par le développement et l’Agilité, il est l’auteur du livre « Object Oriented Analysis and Design » mais surtout du livre « Clean Code: A Handbook of Software Craftsmanship« . Enfin c’est le fondateur du mouvement du « Craftsmanship« , qui donne un nom à une approche où le développeur n’est pas pris comme un pisseur de code décérébré.

Conclusion

Cette liste n’engage que moi, blablabla. Mais ne pas connaître Martin Fowler ou Gavin King lorsque l’on se dit « développeur Java » c’est inquiétant. Imaginons que vous êtes cuisinier. Si vous ne citez pas de tête le nom de prestigieux chefs de cuisine comme Alain Ducasse, Joël Robuchon, Anne-Sophie Pic ou Paul Bocuse, j’imagine que vous travaillez dans une cantine scolaire. Votre boulot c’est de décongeler des plats, de les servir à la bonne température, je comprends. Mais ne dîtes pas que vous « êtes développeur Java » dans ce cas.

Et les femmes alors ?

Cette liste ne contient pas de noms de femmes. J’aurai pu citer quelques femmes célèbres[1] comme Barbara Jane Liskov ou Marissa Mayer, mais je pense aussi aux épouses de ces messieurs. Faire des conférences à travers le monde ou coder toute la nuit, gérer une vie de famille, tout ceci c’est souvent un travail d’équipe.

Pour terminer, j’ai une bonne nouvelle : 2 des personnes que vous voyez ci-dessus seront présentes à la conférence Devoxx France 2012 que je co-organise avec 3 autres fous du Paris JUG.

Rendez-vous lundi 15 janvier pour vous inscrire sur reg.devoxx.com, et rendez-vous du 18 au 20 avril pour prendre une petite claque et découvrir Dart…

Je vous souhaite en 2012 de découvrir un groupe d’utilisateur. S’il y a un moyen de changer de métier, c’est bien de rencontrer d’autres personnes qui font le même métier que vous. Découvrir un groupe qui tourne autour de vos centres d’intérêts, particulièrement pour les Parisiens, est assez facile. A Paris nous avons par exemple le Paris JUG (Paris Java User Group) qui ce mardi propose une soirée DevOps. Petit clin d’oeil amical à ceux qui pensent que l’on ne parle que de Java : vous voyez on ne parle justement pas QUE de Java. Notez-le pour plus tard. Il y a aussi le Alt.NET, groupe des utilisateurs de la plateforme .NET. J’ai déjeuné avec Rui Carvalho, qui s’occupe du groupe de Paris, rencontre très sympa, où l’on voit que la même passion anime cette communauté. En décembre dernier vous auriez pu avoir une soirée Git par Sébastien Douche. Il y a le PAUG pour Paris Android User Group, le Paris Google Technology User Group pour rencontrer des développeurs autour des technologies Google. Si vous êtes une femme, il y a les JDuchess, qui permet aux femmes dans notre métier de se réunir. Ce soir par exemple il y a une soirée sur « Comprendre les langages dynamiques » animé par S.Douche à l’ISEP. Il y a aussi le Paris MongoDB User Group, le ParisJS pour tout ce qui tourne autour du Web et de Javascript, le Scala User Group, le Groovy User Group, le Scrum User Group, le SoftwareCraftmanship User Group ou encore le NoSQL User Group…

Bref tu l’auras compris : si tu es Parisien et que tu ne fais pas au moins une sortie en 2012 : c’est dommage.

Lorsque je dis « chérie, je sors » ma chère et tendre épouse sait que ce n’est pas (que) pour aller boire une bière avec des potes. Bon ok, c’est surtout ça. Mais c’est aussi et avant tout pour rencontrer d’autres personnes qui font le même métier que moi. Et qui, accessoirement, arrivent à voir leur métier avec un oeil passionné. Je vous encourage à prendre le temps de trouver un sujet qui vous intéresse et à vous bouger, ne serait-ce qu’un soir. Pour les Parisiens, il est assez facile de trouver une soirée par semaine, et de tenter l’aventure.

Allez-y, testez, et on en reparle à la fin de cette année.

Les différents formats de présentation

Pour commencer, je vais vous expliquer les différents formats possibles. Ce qui suit est vrai pour Devoxx France comme pour Devoxx « tout court » (la version en Belgique est 100% en anglais). Le premier format pour le mercredi matin sera « University ». Il s’agit de présentations de 3 heures. Plutôt deux fois 1h30, avec une pause café. Dans une salle de 250 places environ, le format « University » est idéal pour découvrir une technologie ou un outil. Exemple de session « University » : Java EE 6 par la pratique, Scala pour les débutants, Kanban in Action… Il devrait y avoir entre 4 et 8 sessions University à Devoxx France.

Deuxième format, intéressant pour présenter un outil ou des librairies : Tools In Action. Ce format est adapté pour présenter des logiciels commerciaux, des plateformes techniques ou des librairies populaires. D’une durée de 30mn ou 1h, ce format est agréable à regarder en fin de journée après avoir fait 2 sessions de 3H sur des sujets pointus. Il devrait y avoir entre 8 et 10 slots « Tools in Action ».

Le jeudi et le vendredi, il y aura 3 ou 4 plénières le matin, puis ensuite un cycle de 6 conférences d’une heure sur 4 salles à 6 salles, soit entre 24 conférences et 36 conférences. La durée est exactement de 50mn, car il faut compter 10mn pour passer d’une salle à l’autre. C’est le format standard, comptez 45mn de présentation et un peu de temps pour les questions de la salle à la fin.

Pendant le break du déjeuner, il y aura enfin 8 à 10 « Quickie ». Il s’agit de présentation flash de 12 à 15mn maximum. Elles ne sont pas enregistrées alors que les autres formats dont je vous ai parlé sont filmés, afin de pouvoir ensuite mettre les vidéos sur le site Parleys.com.
Un Quickie c’est un exercice sympa et pas forcément facile. Mon premier conseil : cela demande de la répétition et du travail. Mais c’est fun et sympa. C’est aussi le format le plus ouvert, où vous pouvez venir nous parler de votre projet open-source perso, de votre amour pour les Nabaztag ou des ESB dans la Finance comme votre serviteur en 2008…

Pour terminer, le soir à partir de 19H00 et jusqu’à 22h il y aura les « Birt of a Feather » ou BOF. Il s’agit de réunion d’une heure, par groupe de 40 personnes, plutôt centré sur les communautés. C’est une espèce de réunion d’anciens combattants. Il y aura le BOF des Java User Groups, le BOF des JDuchess, le BOF du ParisJS, le BOF du NoSQL User Group, le BOF des fans de Spring, le BOF PlayFramework… Bref de quoi surtout discuter et s’amuser. Il n’y a pas forcément de slides, c’est plus décontracté et rencontre.

Qui sélectionne les sujets ?

Nous avons créé un comité de sélection composé de 12 personnes. Nous avons demandé essentiellement aux Zindeps, le groupe de Freelance auquel Antonio, José et moi-même appartenons. Ils connaissent Devoxx, ils sont indépendants, motivés et passionnés. Pour compléter nous avons demandé à des personnes de la communauté Agile, Langages Alternatifs et Web, afin d’avoir un panel aussi large et indépendant que possible. Avec les 4 personnes de l’organisation, c’est donc 16 personnes qui se chargent du contenu.

Quels sont les sujets que l’on peut présenter ?

Il suffit de coller à l’un des 4 thèmes de Devoxx France 2012 :
- Web, Cloud et NoSQL
- Langages alternatifs pour la JVM
- Java, Java SE et Java EE
- Entreprises et Pratiques

Ce qui est intéressant en général : présentation par les auteurs d’un framework ou d’un langage, retour sur expérience, démonstration et live-coding, présentation sur des outils largement utilisés par les développeurs comme Spring, présentation sur les communautés, sur les concepts et les pratiques de développement. Des présentations sur l’infrastructure, la sécurité ou la production sont aussi intéressantes, et fonctionnent bien en général.

Ce qui est moins demandé : des sujets sur la modélisation ou la génération de code, des présentations sur des produits privés et commerciaux, sur des langages trop exotiques, sur des librairies utilisées par 2 personnes dans le monde… Pour comprendre ce qui intéresse l’audience, regardez sur Parleys.com quelles sont les 10 présentations les plus populaires et les 10 présentations les moins bien notées. Et voyez si votre sujet est assez intéressant ou pas.

`

Comment structurer sa présentation ?

Premier point : ne commencez pas à réfléchir au titre. Vous allez tout d’abord réfléchir au contenu. Ne commencez pas par « ce que je vais présenter » mais plutôt « pourquoi je vais présenter ce sujet ». Quelles sont les 5 raisons qui font que vous avez envie de présenter ce sujet ? Pour Play Framework par exemple, je dirais :
- je veux présenter Play car il est simple à apprendre
- car il est différent des autres frameworks Web dans le monde Java
- car je pense qu’il peut réconcilier les développeurs Java avec le Web
- car il propose une approche complète sans serveur J2EE et sans API Servlet, et c’est étonnant
- car il répond à certains besoins mais pas non plus à tous

Ensuite vous pouvez penser à la façon de présenter. Après avoir travaillé le « Why » vous allez penser le « How ». Si vous prenez le format « Conference » de 50mn, vous pouvez présenter 4 ou 5 idées sans prendre de risque. Vous pouvez pour cela prendre le format classique et faire des slides pour vous aider et montrer des schémas ou des photos. Si vous voulez montrer que votre outil est génial, pourquoi ne pas vous en servir et nous montrer comment il marche en 30 mn ? Attention, faire une session de « live-coding » ou d’écriture d’applications demande beaucoup de répétitions ou de talents. Rien de plus catastrophique que « l’effet démo »… Certains speakers enregistrent sous forme vidéo leurs démonstrations, afin de pouvoir s’en sortir et montrer un résultat parfait. Je pense par exemple à la dernière session de Matt Raible à Devoxx qui a fait un tabac. D’autres se lancent dans l’écriture d’une application, mais ils sont très bons : je pense à James Ward qui a codé en direct.

Voilà, vous savez pourquoi vous voulez présenter votre sujet, vous savez comment vous allez faire. Et vous n’êtes pas tombé dans le piège de dire « ce que vous allez présenter » car cela coule de source.

Il ne reste plus qu’à trouver un titre court et percutant, qui permettra au conférencier de se décider au dernier moment et de venir vous voir. Evitez le titre bateau « Spring 4.2″ ou « Hibernate » qui ne sont pas informatifs. Essayez de commencer par « Pourquoi ou Comment » :
- « Pourquoi Play Framework est un jouet sérieux »,
- « Comment cohabiter avec une équipe de production ? »,
- « Découvrir HTML5 avec 5 exemples »
- « Scrum pour les nuls, surtout pour eux »,
- « Git : parce que Seb c’est bien »,
- « Scala ce qui en parlent et ce qui en font ne sont pas les mêmes »
- « Découvertes archéologique dans le code »
- « L’Art de la Rétrospective » (une vraie présentation par F.Beckmann et J.Couvreur)

Comment proposer son sujet sur le site cfp.devoxx.com ?

Tout d’abord inscrivez-vous et présentez-vous. Et prenez le temps de compléter votre bio. En effet, ce texte sera ensuite utilisé sur le site et dans le programme de la conférence. Si vous mettez « TODO » et bien on publiera « TODO ». Présentez-vous à la 3ème personne du singulier en 4 à 5 lignes. Ce que vous faîtes en ce moment, le nom de votre entreprise, votre expérience.

Pensez à présenter à deux, surtout si vous n’avez jamais fait de présentation à Devoxx. En général, j’ai remarqué que les présentations en binôme sont meilleures. Les meilleurs speakers comme Neal Ford font une cinquantaine de présentation par an. Juste pour expliquer qu’il est normal que ce gars soit très bon. Dans ce cas sur le site cfp.devoxx.com, ajoutez l’autre speaker.

Dans la partie référence, vous devez prendre soin de préciser si vous avez déjà fait des présentations à d’autres conférences, à des JUG ou à des User Groups. Mettez aussi des liens vers votre blog, vers vos présentations par exemple. Si vous n’avez jamais rien présenté, pas de soucis. Vous pouvez le préciser. Il y a toujours une première fois.

Dans le résumé de présentation de votre sujet, pensez « programme télévision ». En 8 lignes, vous devez être capable de résumer ce que le conférencier va voir. Concentrez-vous sur le « Why ». Pourquoi une personne doit vous choisir et doit venir vous voir ? Si vous manquez d’inspiration, regardez les anciens sites de Devoxx pour trouver une idée.

Enfin pour terminer, préparez une photo de vous qui ne soit PAS une photo d’identité. Ouvrez un magazine comme Capital ou Management, vous ne verrez pas de photos d’identité. Ensuite ne prenez PAS de photo de vous à un mariage ou en vacances. Prenez un appareil photo numérique, placez-vous devant votre bureau dans votre open-space, croisez les bras, pensez à prendre un air inspiré, clic-clac c’est dans la boîte. Devoxx c’est un concert de Rock. Dans quelques années vous serez une rock-star. Et vous serez encore fier de cette photo où vous avez l’air jeune et avec plus de cheveux que maintenant.
Bref, une photo quoi.

Et ensuite ?

Le comité se retrouve toutes les 3 semaines pour pouvoir s’assurer que l’ensemble des personnes est d’accord sur le contenu. La date butoir pour proposer un ou plusieurs sujets sera le 15 février 2012. Soit dans moins de 60 jours. Vous n’aurez pas un retour le 16 février au matin. Vous aurez cependant un retour dès que le comité aura assez de sujets pour construire un programme cohérent. Ensuite vous serez retenu et invité si vous faîtes une University, une Conférence ou un Tools in Action. Par contre pour les Quickies et les BOFs nous n’offriront pas de places cette année.

Si vous n’êtes pas retenu nous essayerons de vous donner plus de détails. Mais je ne vous garantie pas que vous aurez une explication détaillée de 25 lignes. S’il y a 150 propositions pour 50 places, vous comprenez qu’il est plus difficile d’être sélectionné. Cela arrive souvent, moi le premier je me fais bouler, surtout des conférences en Anglais. Voilà c’est la vie, au moins vous, vous essayez. Et ça, c’est important.

Conclusion

Devoxx France est une aventure à vivre. Si vous n’avez pas envie de présenter un sujet, pensez aux meilleurs speakers que vous avez vu lors d’une conférence ou d’une soirée de User-Groups. Et pensez à les contacter, à leur parler de Devoxx France et à les encourager à proposer un sujet.

Pour Play 2.0, lorsque Sadek Drobi et Guillaume Bort ont débuté leurs travaux avant l’été 2011, il y avait un challenge important : proposer un nouveau moteur de template.

Pour créer un moteur puissant :

- le langage doit être une composition de code HTML et de code dynamique compact et facile à lire dans la vue. Une page sans complexité accidentelle. Idéalement, le développeur ne doit pas être coupé lorsqu’il tape son code en étant obligé d’ouvrir et de fermer des marqueurs comme dans Play 1.x. Pour cela, il faut que le parser soit assez puissant pour distinguer les blocs de code et les blocs HTML.
- la syntaxe doit être facile et rapide à apprendre comme l’était Groovy dans Play 1.x. Contrairement à Grails, Play 1.x n’a pas beaucoup de possibilités du côté vue. Cette simplicité force à penser son code différemment du côté contrôleur/modèle. Il faut donc que les quelques tags soient faciles à comprendre pour un débutant.
- on ne doit pas inventer un n-ieme langage de template ou de markup, ne pas se lancer dans l’écriture d’un langage propriétaire. Idéalement, s’appuyer sur un langage puissant capable d’utiliser des closures et de manipuler les collections facilement comme Groovy ou Scala.
- le texte doit être éditable dans un éditeur de texte simple et fonctionner correctement dans un IDE
- la syntaxe doit être aussi pensé pour que les IDE puissent proposer des plugins puissants, chose difficile avec Groovy dans Play 1.x
- chaque page doit être testable de manière unitaire : la génération de la page HTML finale doit être quelque chose qui s’intègre dans le développement et que l’on peut appeler à partir d’un interpreteur SBT, sans devoir activer un controleur et mettre en marche le reste de Play 2.0.

Avec ceci en tête, Play 2.0 propose un moteur sympa. Le mieux pour t’en parler, c’est de te montrer du code.

Play 1.x et Play 2.0 sont sur un bateau

Imaginons que vous deviez coder une application pour vendre des Pizzas par Internet. Nous allons voir les différences entre l’ancien format de play et le nouveau. Je commence par une simple page avec un lien qui permet de charger une deuxième page.

Tout d’abord la version Play 1.x, on remarque que le texte du lien est encadré par une balise #{a} #{/a}. Cette balise n’est évidemment pas reconnue par votre éditeur HTML, sauf si vous utilisez le plugin Play pour IntelliJ.

#{extends 'main.html' /}
#{set title:'Pizza' /}

  <h1>Bienvenue chez Pizza Service 1</h1>

  #{a @Application.listPizzas()}Liste de nos produits#{/a}

La version Play 2.0 reprend la même sémantique, mais comme vous pouvez le constater, cette fois l’écriture est plus fluide. Vous écrivez du HTML et vous utilisez simplement un marquer @ pour signaler au parser qu’il doit interpréter ce qui suit comme du code. Comment le parser sait que « vous avez terminé ? » et qu’il repasse au HTML ? C’est tout le génie de Sadek, qui a utilisé les parser combinators de Scala pour écrire cette partie. J’ai commencé à utiliser ce moteur en juin 2011. Et vraiment, il est génial.

@main("Pizza") {

  <h1>Bienvenue chez Pizza Service 2</h1>

  <a href="@routes.Application.listPizzas">Liste de nos produits</a>

}

Liste des pizzas avec Play 1.x

Voyons maintenant comment itérer une liste de Pizza et afficher ligne par ligne le nom de chaque pizza. Côté serveur, nous imaginons que je retourne une List<Pizza> pizzas :

#{extends 'main.html' /}
#{set title:'Pizza' /}
<h1>Liste de nos pizzas</h1>

 #{list items:pizzas, as:'pizza'}
   ${pizza.name} <br/>
 #{/list}

Liste des pizzas avec Play 2.0

Pour la version Play 2.0, tout d’abord nous notons que le template est plus fortement typé. En effet, il déclare ligne 1 qu’il demande une liste de pizzas. Ceci permet à Play de vous notifier lorsque vous vous êtes trompé, et que votre template ne pourra pas fonctionner. Le typage fort est un principe qui permet de rendre votre code plus robuste.

L’itération de la collection ici, est présenté « à la Java ». Il y a d’autres moyens d’itérer, mais pour l’essentiel notez que c’est légèrement plus simple que l’ancienne version.

@(pizzas:List[Pizza])
@main("Pizza") {
<h1>Liste de nos pizzas</h1>

  @for(pizza <- pizzas) {
    @pizza.name <br/>
  }
}

Le Parser de template de Play 2.0 comprend la syntaxe de la boucle for, et sait aussi lorsque vous souhaitez simplement afficher du HTML, comme dans le cas de la balise <BR/> ci-dessus. Notez aussi le @pizza.name : pas de geName() qui viendrait perturber la lecture et qui rendrait le code plus lourd.

Gestion des blocs conditionnels

Voyons comment gérer maintenant le cas où la liste des Pizzas est vide. Il serait bien d’afficher un message d’information à l’utilisateur pour lui expliquer qu’il n’y a plus de Pizza non ?

Tout d’abord la version Play 1.x avec l’utilisation de la balise if et de la balise else :

#{extends 'main.html' /}
#{set title:'Pizza' /}
<h1>Liste des pizzas Play 1.0</h1>
#{if pizzas}
  #{list items:pizzas, as:'pizza'}
      ${pizza.name}<br/>
  #{/list}
#{/if}
#{else}
  <strong>Désolé, nous n'avons pas de Pizzas en stock</strong>
#{/else}

Ensuite la version Play 2.0, j’ai écrit du code « à la Java » pour vous montrer un exemple simple :

@(pizzas:List[Pizza])
@main("Pizza") {
<h1>Liste de nos pizzas</h1>
@if(pizzas.isEmpty){
  <p>Pas de pizzas en ce moment</p>
}else{
  @for(pizza <- pizzas) {
      @pizza.name<br/>
    }
  }
}

Un regret ici : si je veux utiliser la fonction map de Scala sur @pizzas à la place de la for-comprehension, je ne peux pas utiliser getOrElse car je me retrouve avec un scala.collection.mutable.Buffer. Je poserai la question à Sadek à l’occasion.

Page de modèle

Lorsque vous créez une application web, il est important de pouvoir déclarer des modèles de page. Ceci vous évite de répéter dans chaque page des informations de mise en page commune comme le menu de navigation, le pied de page, etc.

Play 1.x

Avec Play 1.x la création d’un template est simple : il suffit de déclarer une page html et d’indiquer avec le tag doLayout que Play! doit insérer le code de votre page

(fichier main.html)

<!DOCTYPE html>

<html>
    <head>
        <title>#{get 'title' /}</title>
    </head>
    <body>
        #{doLayout /}
    </body>
</html>

Pour indiquer que vous souhaitez utiliser le template « main.html », et que vous souhaitez passer « HELLO » pour le titre de la page,

#{extends 'main.html' /}
#{set title:'HELLO' /}

... reste de la page ...

Play 2.0

Le principe est aussi de déclarer un template. Ce template accepte un paramètre title de type String. Ici, si la page fille ne précise pas de titre, je mets une valeur par défaut (Pizza Play 2). Le tag @content se contente d’exécuter la fonction qui génère le contenu principal de la page. Chose intéressante : vous pouvez avoir plusieurs blocs différents, mettre de la logique dans le template, bref faire tout un tas de chose que Play 1.x ne sait pas faire.

@(title: String = "Pizza Play 2")(content: Html)

<!DOCTYPE html>

<html>
    <head>
        <title>@title</title>
    </head>
    <body>
        @content
    </body>
</html>

Conclusion

Plus concis et aussi puissant, Play 2.0 ouvre la porte du fonctionnel et du typage fort. Dans des templates Webs, cela permet de renforcer la qualité du code. Par ailleurs, chaque page est en fait compilé vers du Scala, puis du byte-code java. Ceci permet d’exécuter les pages comme de simples fonctions. Vous pouvez donc faire des tests unitaires sur une page en mockant la collection de Pizza afin de vérifier le comportement de la page. Oui tu as bien lu : tu peux faire un test sans avoir besoin de controleur et d’une base de données derrière.

Le bon père de famille devrait aussi être rassuré car le support de Servlet 3.0 est prévu dans Play 2.0. D’ici à ce que Play vienne aussi chatouiller le monde Java EE Web, on est plus très loin. Il y a tout un tas de trucs sympathiques comme le support de OAuth 1.0 et 2.0, la possibilité d’invoquer un deuxième serveur Play à partir du premier via Akka… bref pas mal de choses intéressantes.

Si vous vous posez la question d’utiliser Play 2.0 pour « un projet de la vraie vie » c’est encore un peu tôt. Personnellement j’ai travaillé du mois de mai à novembre sur Play 1.x avec Scala et le moteur que vous venez de voir : il est vraiment très simple et puissant. Vous avez sous le pied toute la puissance de Scala, surtout lorsqu’il s’agit de manipuler des collections, ou de faire des appels ré-entrant vers le controleur. Pour Play 2.0 il faudra attendre la sortie d’une version stable, prévue pour le printemps prochain. D’ici là on a déjà de quoi s’amuser cependant.

Je suis convaincu que quelques uns d’entre vous vont se mettre à faire du Scala grâce à Play 2.0. Souvenez-vous de ce petit article dans quelques mois… On en reparlera.

Référence :

Cette article est inspiré de l’article « Introducing Razor » écrit par Scott Guthrie

The Razor view engine