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

Réussir sa présentation à Devoxx France par Nicolas Martignole sur Vimeo.

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.

3 jours, avec donc un format 1+2. Le mercredi sera consacré à la formation, avec des sessions de 3 heures en matinée (University) et des sessions de 30mn à 1h l’après-midi. Si vous voulez +20 en Level « Développeur » en quelques heures, cette journée est importante. Jeudi et vendredi : le matin nous aurons des plénières, par des conférenciers prestigieux. L’après-midi : des conférences d’une heure. Le soir : tu seras sur une table avec des multi-prises. Peut-être que tu iras faire une « BOF »(Bird of a Feather) afin de croiser les gars du NoSQL User Group, la communauté des développeurs Android ou encore les gars du ParisJS… Bref tu auras une vie sociale de développeur. Et ne fais pas l’erreur de rentrer chez toi à 18h, tu louperas le meilleur.

Le prix mon ami : 350 EUR HT pour les 2 jours. C’est un prix que votre entreprise doit investir. Notez que je dis « investir« . Si vous pensez « payer, dépenser » vous n’avez pas compris en quoi consiste une conférence. C’est tout à fait normal : à Paris nous n’avons pas encore révolutionné le monde et le regard du développeur. Si vous pensez « c’est cher » c’est que vous auriez préféré que la conférence soit gratuite. Je vais vous dire un secret : c’est peut-être faisable. Par contre, nous serons obligé de vous imposer des présentations effectuées par des sociétés, que nous n’aurons pas sélectionné. Comprenez quelque chose : le prix d’entrée que votre entreprise paye est la garantie de l’indépendance. Grâce à votre ticket d’entrée, nous pouvons dire oui ou non aux sponsors. Au final c’est bon pour vous, c’est bon pour le contenu et c’est comme cela que Devoxx fonctionne.

Comment venir gratuitement ? Devenez speaker. Si votre présentation est retenue comme Conférence, University ou Tools in Action, vous recevez un badge speaker valable 3 jours d’une valeur de 450 EUR HT. Pour cela, réfléchissez à un sujet qui vous intéresse, commencez à travailler votre présentation, et dépechez-vous de soumettre un sujet sur le site cfp.devoxx.com en Français. Un comité de sélection de 12 indépendants est chargé du programme de Devoxx France. Vous saurez fin février si votre présentation est retenue ou non. Soyez imaginatif, allez sur le site www.parleys.com pour voir des présentations de Devoxx 2011. Il est important de comprendre comment et quoi présenter à Devoxx. Si vous pensez débarquer avec vos slides et nous faire de l’enfumage, prenez votre deuxième doigt, posez le sur la paupière, et poussez très fort jusqu’au coude : vous vous mettez le doigt dans l’oeil. Devoxx c’est juste la crème du top de la chantilly des speakers. Il y aura 50 présentations en Français et une vingtaine en Anglais. Pour la version Anglaise, nous allons avoir d’excellents speakers qui viennent des USA et d’Angleterre, qui travaillent chez Google, LinkedIn ou JBoss RedHat par exemple.

Si vous voulez être speaker, il y a aussi l’opportunité de faire un Quickie (15mn). Voyez où j’en suis, pour moi Devoxx en 2008 c’était le petit Nicolas dans une salle de 600 personnes, avec le trouillomètre à 100%. Mais quel pied, quel plaisir de se jeter dans le grand bain et de se dire : « ouais, j’ai fait une présentation à Devoxx ». Et du coup, dans 3 ans vous serez à l’aise pour faire des présentations. Un gars de Salesforce ou de Google viendra vous voir et vous dira « We want you ! ». Vous vous ferez graver « Devoxx France 2012″ sur le bras en souvenir de ce passage… Bref tentez le Quickie, il est plus facile d’être retenu et c’est très fun.

Pourquoi venir à Devoxx France 2012 ?
Tout d’abord, c’est l’occasion de rencontrer des personnes. Avant de s’assoir dans une salle et de baver devant Matt Raible ou Joshua Bloch, vous pourrez socialiser avec d’autres personnes. Vous verrez : vous n’êtes pas seul. En fait, nous sommes très nombreux. Et nous sommes de plus en plus important dans le monde de l’entreprise car nous avons une compétence sur le CV qui vaut de l’or : nous sommes passionnés.

Soit un numéro IBAN simple, présenté sous la forme d’une grosse chaîne de caractère :
FR7630057410821012122045021

Comment l’afficher à l’écran en le formatant de cette façon ?

FR76 3005 7410 8210 1212 2045 021

Voici un premier bout de code écrit en juillet dernier par votre serviteur :

val iban="FR7630057410821012122045021"

iban.zipWithIndex.map{p=>p match{case(t,idx) if (idx+1)%4==0=>{print(t+" ")} ; case(t,idx)=>{print(t)}}}

// si, si ça marche

Et voici le même code après avoir lu la doc et aussi après avoir vu un email sur la liste du Scala User Group :

for(p < - iban.sliding(4,4).toList){ print(p+" ")}

Conclusion : lisez la documentation avant de vous lancer dans des "expérimentations" pour dire ensuite "dans skala' c'est compliqué". ]]> http://www.touilleur-express.fr/2011/12/08/le-gars-qui-connait-scala-et-celui-qui-debute/feed/ 36 http://www.touilleur-express.fr/2011/12/03/le-nouveau-moteur-de-template-de-play-2-0/ http://www.touilleur-express.fr/2011/12/03/le-nouveau-moteur-de-template-de-play-2-0/#comments Sat, 03 Dec 2011 22:41:11 +0000 Nicolas Martignole http://www.touilleur-express.fr/?p=5989 Play 2.0 propose un nouveau moteur de template simple qui permet d’écrire des pages webs dynamiques. Directement inspiré de « Razor », l’un des moteurs de rendu d’ASP.MVC, il est à la fois simple et puissant. Venez avec moi, on va comparer Play 1.x et Play 2.0 

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

Sacha Labourey ouvre la soirée. Ancien CTO de JBoss, futur speaker à Devoxx France 2012 et accessoirement Suisse de son état, il est venu accompagné de François Déchery, VP of International Business Development. Ils sont co-fondateurs de la société Cloud Bees.

Le Cloud en ce moment, c’est tout d’abord beaucoup de commentaires et aussi beaucoup d’émotions dans le sujet. Les changements et la rupture d’architecture et organisationelle sont importants. Ce sont des changements fondamentaux. Ce soir, Sacha va simplement démontrer les changements qui nous attendent. Le futur est quelque chose que l’on ne voit pas, mais que l’on créé.

Sacha s’arrête sur quelques idées pour ancrer son discours. Par exemple, votre enfant ne vous a-t-il jamais demandé pourquoi les vieux téléphones ont des fils ? Ma fille de 4 ans par exemple a découvert la cassette VHS chez les grand-parents, mais elle appelle cela un « gros DVD ».

Imaginez dans quelques années une discussion avec un informaticien. Peut-être qu’il sera étonné d’apprendre que vous développiez en local sur votre poste de travail. En tous les cas, je suis sûr qu’il sera étonné d’apprendre que vous travaillez avec Eclipse (et toc, ça c’est fait…).

Cette évolution et cet impact est comparable dans une certaine mesure à l’arrivée de l’électricité. A la fin du XIXème siècle, le luxe est de générer de l’électricité et de le partager avec d’autres. Les premiers générateurs d’électricité permettent de mutualiser le coût de production d’une ressource. De nombreuses entreprises se créent et l’électricité connait un essor important.

En 1881 Edison présente une génératrice à l’exposition universelle de Paris.

L’électricité connait un essor rapide de 1870 à 1907 à Paris. Le choix entre le continu et l’alternatif et les différents standards rendent assez compliqué s la distribution de l’électricité. Mais à cette époque, peu de bâtiments et de sociétés utilisent l’électricité. Celle-ci n’est pas encore une commodité.

En 1902 on se retrouve par exemple avec un découpage de Paris, où chaque secteur a son standard.

Ce que Sacha explique, c’est que l’informatique aujourd’hui est un peu prêt dans le même état que le réseau électrique en 1900 à Paris. Il existe différents producteurs, il n’y a pas de standards, le consommateur est encore un conso-acteur qui doit s’inquiéter du format, de l’ampérage et du type de courant…

Alors qu’en 2011, une prise standard vous donne de l’électricité. Aujourd’hui, nous avons de la résilience, et il est même possible de changer de fournisseur. Chaque mois, votre entreprise paye une facture d’électricité, comme une simple commodité. Pourquoi ne pas voir dans quelques années la même approche pour l’informatique d’entreprises ?

Sacha Labourey passe ensuite sur les centres de données. Quoique l’on en dise, les data-centers ne sont pas aussi beaux que sur les publicités IBM. Dans les faits, ils coutent chers, ils dégagent de la chaleur et ils demandent de l’électricité. Dans le futur, les lois et la protection des données seront peut-être plus stricte, à un tel point que les entreprises ne seront plus en mesure d’avoir un data-center rentable.

Aujourd’hui, l’informatique c’est de la haute couture : peu de réutilisabilité, peu de services, une intégration assez compliquée, un sentiment de parfois être un Artiste Héroïque plutôt qu’un vague Ingénieur…

Le Cloud c’est avant tout de l’infrastructure, avec au départ non pas des hébergeurs, mais des utilisateurs. Quelle est la société qui gagne le plus d’argent avec le Cloud ? Ce n’est pas un hébergeur, c’est Amazon. Un site qui vend des livres… Et qui aujourd’hui a créé un nouveau business model.

Sacha fait ensuite le parrallèle entre le coût d’un centre de données pour une entreprise, et l’intérêt à moyen-long termes pour une grande entreprise. Cette immobilisation financière n’est pas forcément stratégique pour des entreprises de taille moyenne. Par contre, il l’est pour un Google et un Amazon. La question du Cloud se pose donc avant tout pour les utilisateurs finaux et les entreprises classiques.

Sacha espère que le Cloud Computing sera une commodité, comme l’électricité aujourd’hui. Vouloir faire de la haute-couture pour tout, ce n’est pas rentable. La crise financière actuelle aura même peut-être un effet sur les DSI. Nous pouvons même supposer que les équipes du métier, qui continuent à avoir besoin de l’informatique, n’attendrons pas que la DSI s’en remettent.

Je rêve aussi personnellement que certaines DSI qui ne vivent que grâce à deux ou trois grosses SSII iront se planter rapidement, histoire de laisser la place à une nouvelle relation entre le client, et les gens qui codent, nous.

Sacha termine par une citation à méditer :

If you don’t like change, you’re going to like irrelevance even less.
General. Erik Shineski

J’en ajoute une aussi pour la route et qui colle bien à CloudBees :

“Never doubt that a small group of committed people can change the world. Indeed it is the only thing that ever has.”
Citation de Margaret Mead

Définition du cloud

Sacha Labourey présente ensuite les différents types d’architectures dans le Cloud. SaaS, PaaS ou IaaS, tout ceci c’est pas mal de jargon. Mais il est important de comprendre qu’il y a différentes architectures, pour différents usages.

• SaaS (SalesForce, NetSuite, ZenDesk,HubSpot)
• Paas( CloudBees, heroku, app engine vmForce database.com)
• Iaas (Amazon Web Services, RackspaceCloud, terremark, Eucalyptus System)
• Cloud computing->informatique à la demande, accès à des ressources virtualisées.

Le SaaS : solution assez rigide, c’est l’utilisation du service qui prime sur les principes d’architecture. Le SaaS est particulièrement adapté à l’approche orientée solutions comme SalesForce. Quelque part, votre GMail c’est du SaaS si vous voulez.

PaaS : le Platform as a Service est l’étage où vous pouvez placer CloudBees. Cette couche intermédiaire redonne l’environnement de développement et surtout de production habituel. Les serveurs, les logiciels, la montée en charge sont cependant gérées par la plate-forme. Il y a différentes philosophies selon les vendeurs sur PaaS. Personnellement j’aime beaucoup Heroku pour l’approche orientée production.

IaaS : c’est de l’Infrastructure as a Service. A cette étage de la fusée, vous avez plus ou moins un méga réseau élastique, mais il faut travailler pas mal pour réellement tirer partie de l’IaaS. Amazon Web Services est la solution la plus populaire mais il en existe d’autres.

CloudBees

Alors que fait CloudBees ?

Solution de PaaS, CloudBees gère le cycle complet du logiciel. De la compilation à la mise en production, puis à l’exploitation. Cloud Bees veut devenir le leader de la solution Java pour Cloud. Fort de l’expérience de JBoss, Sacha vise rapidement une place sur le podium, afin d’apporter tout le savoir faire du monde Java Enterprise vers le Cloud.

Cloud Bees c’est aussi déjà un bon nombre d’outils et de services d’entreprises, prêt à l’emploi. Côté développement, vous pouvez démarrer un projet avec une forge logiciel, avec JFrog, Sonar ou XWiki. Côté production, on retrouve des outils populaires comme New Relic ou Mongo HQ. Il y a encore un peu de travail avant de rattraper la liste des AddOns d’Heroku, mais franchement c’est bien.

CloudBees c’est donc 2 ruches distinctes : Dev@Cloud et Run@Cloud. J’en ai déjà parlé sur le Touilleur Express à l’occasion de la présentation de N.De Loof au RivieraDev.

DEV@Cloud est un environnement de développement avec intégration continue basée sur Jenkins, repository Maven privé, et j’imagine rapidement des outils comme bug tracking ou autre.

RUN@Cloud est l’environnement d’exécution de votre application. C’est donc avant tout le moyen le plus simple de déployer une application Java dans le Cloud.

Conclusion

Sacha Labourey a quelque chose d’indispensable : une vision. Loin de la soupe technique, il sait ce que CloudBees doit faire pour réussir. Alors que pas mal de monde s’intéresse aux caractéristiques du Cloud, lui s’intéresse à la finalité et aux futurs services. Cette approche est importante, car certains éditeurs de logiciels empilent les version de leurs logiciels les unes après les autres, mais n’ont pas de mission. Ils ne savent pas expliquer « POURQUOI » leur solution est intéressante. Ils empilent les présentations sur ce que FONT TECHNIQUEMENT leurs solutions, alors que le plus important est de savoir pourquoi elles existent.

Ensuite, CloudBees si j’ai correctement compris, fait le choix de ne travailler qu’avec Java pour l’instant. Pas de Groovy ou de Scala. A voir à moyen-long terme si cela ne change pas.

CloudBees est clairement une solution pour les développeurs Java modernes. Si vous êtes habitué à utiliser Maven, à faire de l’intégration continue avec Jenkins, à faire de la mise en production vers un Apache Tomcat, c’est une solution qui vous fera gagner du temps. Un autre intérêt, c’est que finalement CloudBees abstrait l’IaaS et offre de la fléxibilité sans vous locker sur une infrastructure.

Les concurrents de CloudBees ? Le premier qui me vient en tête c’est Heroku. J’aime beaucoup l’approche différente d’Heroku. Les Add-Ons sont plus nombreux que ceux de CloudBees pour l’instant. Vous pouvez faire du Ruby, du Scala, du Java, du PHP ou du Python… et avec 510 000 applications en production, Heroku n’est pas un petit joueur.

CloudFoundry est assez similaire, et permet déjà de faire tourner autre chose que du Java. C’est surtout une solution open-source. N’ayant pas testé CloudFoundry, je n’ai pas d’avis sur la plateforme.

Il existe beaucoup de PaaS, mais je retiendrai que CloudBees est avant tout pensé et adapté aux développeurs Java.

Et mine de rien, on est 10 millions de développeurs dans le monde.

A suivre donc…

Ressources
Vous pouvez tester et découvrir les solutions CloudBees en version d’évaluation sur leu