Le JUG Geneva… Play!

L'URL courte de cet article est : http://inagua.ch/jGnuU


logoGenevaJug-small

RDV est pris pour 18h à et à priori c’est complet…

J’arrive à l’heure sur le site… Première constatation : ils ne payent pas les flèches au JUG ;) La salle était bien indiquée, impossible de se perdre dans cet énorme batiment… Xavier a balancé Maxime : je pense que ce sera lui de corvée de fléchage à l’Agile Tour 2010 ;)

Une fois sur place Xavier me vante PREZI.com, un outil pour créer des supports de présentation permettant de zoomer des concepts les plus généraux aux plus particuliers tout en suivant un fil conducteur ; outil qu’il a utilisé pour  pour faire son introduction… Effet vraiment efficace… A creuser !

La salle se remplit… 54 inscrits aux dires de Xavier.

18h18 : ça commence !…


play-logo

Xavier se présente ” furtivement ” puis présente le JUG devant un auditoire studieux :

Promouvoir Java et capitaliser les diverses expériences.

Une cinquantaine de participants attentifs

Une cinquantaine de participants attentifs

Après avoir énoncé les sponsors, il annonce l’agenda pour le premier semestre :

  • Sonar,
  • Maven,
  • Java EE 6 et
  • GlassFish 3

Et la présentation commence…

Play!

La société

Le fondateur présente sa société : ” Zenexity ne fait pas de régie, 60% de R&D, et est indépendante dans le sens où elle n’a pas de partenariat“.

  • Habib Guergachi, CEO, rejette avec insistance les technologies Java JEE et insiste sur ses grandes missions. Il est ” le meilleur de France accompagné du meilleur de France “.
  • Guillaume Bort, CTO, fondateur de playframework.org
Guillaume à gauche et Habib à droite

Guillaume à gauche et Habib à droite

Au cours de leur présentation ils expriment clairement leur rejet du monde Java EE / EJB : une complexité qui s’auto-alimente, des développeurs en arrêt maladie, des clients qui dépensent des budgets colossaux… J’avais l’impression d’une de nos discussions avec Stéphane ;)

Un slogan qui forcément ne laisse pas insensible : ” Zenexity aide ses clients à construire son SI avec les technologies du futur alors que la majorité des SSII utilisent les technologies du passé “.

Après avoir été heurté par ce que j’ai tout d’abord considéré comme de l’arrogance, le discours commence à me séduire : ” Le Java Enterprise c’est des développeurs en arrêt maladie ! “. Je me dis finalement qu’il faut bien une bonne dose de “convictions” pour s’attaquer au dogme JEE. A se demander si Habib ne le ferait pas exprès pour se démarquer ?! Et puis il n’y a que la vérité qui blesse ;)

Le framework

En regard de ce positionnement sur JEE, ils présentent Play! comme une rupture dans la façon de penser et de travailler dans ce monde de complexité.

Play! 1.0 : 140.000 visites et 20.000 downloads

Play! 1.0 : 140.000 visites et 20.000 downloads

Puis Guillaume prend la parole pour retracer l’historique de Play! :

  • Créé en 2007, en interne, par Guillaume Bort avec des idées différenciatrices
  • Open source en 2008 pour fiabiliser le produit
  • 2009 : la 1.0 sort après 2 ans de dev
  • janvier 2010 : la 1.0.1
  • Parti d’abord en France, en  Chine et Amérique du nord
  • Quelques stats : downloads, messages sur le google group, followers twitters

L’Observatoire de l’Excellence Logisitique : forfait réalisé par Zenexity (Sematic = CMS open source) avec Play!

Au passage Habib confronte le mode de fonctionnement des JSR Java où l’on réfléchit à 30 dans une salle avant de réaliser à ces réussites que sont Hibernate, Spring (… Play! ;) : on part d’une implémentation réussie pour créer un standard.

Guillaume justifie ensuite pourquoi un nouveau framework Java ?

  • les frameworks sont développés par des développeurs Java et non pas par des développeurs web
  • des interfaces à outrance avec des implémentations : ” une interface Request avec l’implémentation HttpRequest pour le cas où un jour le web change de protocole ” ;)
  • les développeurs Java attachent par exemple plus d’importance à l’utilisation ou pas d’un singleton avant le nombre de requêtes GET
  • 1 million de Java développeurs mais 1,8 milliards d’humains ont accès au web (http + html : hypertextuel)
  • Comparaison avec Django (Python) et Rails (Ruby) orienté Request et Response, réalisés par des développeurs web

Les frameworks Java actuels cherchent à dissimuler la complexité existante

Puis, partant du constat qu’actuellement on passe plus de temps à préparer le retour arrière d’une mise en production que la livraison elle même (c’est dire si on a confiance ;), Guillaume précise les motivations à développer Play! :

  • Je peux livrer quand je veux.
  • On ne se cache pas derrière n couches d’abstraction
  • Pas d’injection de dépendance : l’IOC n’est pas une fin en soi !

Il précise leur positionnement face à Java :

  • La complexité de Java est culturelle, imposée et non pas intrinsèque au langage
  • Pourquoi en Java : car c’est un écosystème génial
  • ON EST POUR JAVA, c’est un très bon langage…
  • Même si il va rapidement avoir des remplaçants (SCALA notamment)

Il rappelle avec ironie qu’une solution existe et fonctionne depuis longtemps : le web !… Or, le web repose sur REST :

  • « Le web est TROP simple, il ne sert qu’à échanger des photos » ironise Habib des clients
  • REST est l’architecture du web
  • Quelque soit le langage, il existe une librairie d’accès HTTP

Pour développer Play! ils ont appris de l’existant :

  • se concentre sur la productivité du développeur
  • un style d’architecture : RESTful architecture (web, stateless)
  • une requete avec une réponse, rejouable

La démo

Puis arrive enfin la démo… Attendue avec impatience comme le prouve les houra de la foule ;)

” Play! est un outil ” lance Guillaume en tapant “play” dans son terminal afin de nous montrer le résultat dans la console… Je me sens entre Rails et Maven !… Il complète en disant : ” Pas de war ! Pas de servlet container ! Pas de sessions java, on est restful, stateless ! ”

Play! est un outil... Play! console ;)

Play! est un outil... Play! console ;)

A mesure qu’il déroule sa démo, je retrouve petit à petit les caractéristiques qui font la force de Rails :

  • la commande initiale pour générer le squelette du projet (l’arborescence)
  • l’arborescence elle même très proche de celle d’un projet Rails
  • des vues en html, des controllers en java, des modeles
  • des environnements DEV et PROD
  • convention over configuration
  • le fichier « routes »
  • comme on a le source à l’exécution, quand on a une erreur on peut pointer la ligne en erreur :
    • dans la requête / page html
    • dans la console serveur
  • le nom de la variable dans le contrôleur suffit : name au lieu put(«name», name)
    • DRY : Don’t Repeat Yourself
  • les helpers pour générer les URLs
  • La notion d’ActiveRecord : Contact.findAll(), les attributs “property”

Par contre Play! vient avec un runner de test accessible à l’URL <host>/@tests , runner qui joue l’intégralité des tests : unitaires, fonctionnels, selenium… Là, mon coeur chavire. Cette fonctionnalité manquante en l’état dans Rails est “juste géniale”.

Pour la petite histoire, Guillaume déroule l’intégralité de sa démonstration sous Textmate… Il argumente en disant qu’il cherche à montrer que l’on peut développer avec un éditeur léger. De plus, étant donné que selon lui 30% de ses développements sont du Java, il préfère un bon éditeur web plutôt qu’un génial éditeur Java. Pour ma part, je trouve inconcevable que l’on puisse en 2010 utiliser un éditeur de code qui n’offre pas de refactoring ! Il y a encore des développeurs qui font du chercher/remplacer pour renommer une variable, une classe, un fichier… Ils font à la main l’extraction de méthode ?!… Plus généralement, j’ai peur qu’a sortir régulièrement de nouveaux langages / frameworks, nous soyons condamnés à utiliser des IDE constamment en retard et donc non adaptés à la technologie utilisée : nous sommes condamnés à développer en éditant des fichiers texte sous Notepad ;(

Pour revenir sur Play!, il y a actuellement deux branches : la 1.0, la version stable et la 1.0.1 qui vient d’être livrée il y a quelques jours. Guillaume annonce également qu’ils sont en train de revoir la notion de module : ils sont en train de créer un repository de ces modules, car il n’est plus possible de tout intégrer à la distribution Play! comme c’était le cas au départ lorsqu’il y avait 5 modules développés par Guillaume lui même. Cela me fait penser aux gem Ruby.

Sur la fin de la présentation, il nous lance quelques pistes :

  • Play! acccepte d’autres modules comme le compilateur SCALA, module sur lequel ils vont investir, persuadés des avantages que le langage SCALA apporte
  • Le module SASS aussi intéressant pour maitriser les CSS…
  • Habib nous alerte sur le fait que les “transactions relaxées” sont l’avenir !

Et Guillaume fini la présentation sur le module CRUD… Il permet de faciliter la génération des modèles et de leur vues (et une parenthèse sur les validateurs) : je retrouve exactement les scaffolds Rails (à la différence qu’ils sont partie intégrante de la distribution Rails)… Et qu’avec RSpec on peut même générer le squelette du test !

Et Habib de remettre une couche sur l’avenir sur le web : avec HTML 5, déjà pris en charge par Chrome et Safari :

  1. on retrouve une convergence et standardisation du HTML
  2. la sauvegarde de données sur le poste client, traduisant cette tendance à l’allégement des serveur et l’enrichissement des clients

La discussion

19h45 la discussion commence…

  • On en revient très rapidement à cette question sur la compatibilité du framework avec le système d’information et l’environnement de production des clients… Ca ne serait pas plutôt avec leur mentalité ;)
  • Oui mais avec BEA au moins y a le support ” lance un participant… ” Qui a déjà appelé le support BEA ? ” répond Habib… Merci Habib pour cet argument qui se suffit à lui même.
  • Et le tunning ? Sur Weblogic tu peux tunner le serveur d’application ! ” ajoute un autre participant. Guillaume répond ” Le même ! On Hibernate, http… Tu peux tuner ces composants.” Pour ma part j’ajouterais que le besoin de tunner des mastodontes est venu de l’ajout de couches de complexité : si tu simplifies ton serveur, tu amoindris, voire élimine, les besoins de tunning. Le tunning n’est pas une fin en soi !
  • Mais quel est votre serveur de transaction ? “… Les questions sont tellement formatées par des années de pratique JEE…
  • JEE 6 c’est mieux !… EN effet, mais par rapport à JEE 5 ! Cela reste compliqué dans l’absolu.
  • Les applications de demain seront distribuées sur le web : voir ce que fait Google avec Salesforce.com
  • en.dorse.me
  • Je demande à Guillaume quelles sont les motivations pour redévelopper Rails en Java… La réponse est claire : recycler des développeurs, des compétences, Java. Guillaume ajoutera après qu’en plus, Play!, avec ses mécanismes de pré-compilation et compilation optimisée par les dernières JVM, est plus performant que Rails.

Ce n’est pas sans mal que Xavier parvient à mettre un terme entre ces ” Grands Architectes JEE ” avec leurs questions formatées Enterprise et ces vaillants guerriers de Play!

C’est quand même impressionnant comment ces praticiens JEE sont formatés. On leur présente une petite Twingo RS qui leur permet d’arriver rapidement et avec fiabilité d’un point de départ à un point d’arrivée, et eux ne peuvent s’empécher de demander : mais comment fait-on pour transporter un tunnelier de plusieurs tonnes au travers des montagnes (faire des transactions, du tunning de performance…) ? Mais le client n’a jamais demandé cela ! Ils ont ajouté, créé, des contraintes techniques, et sont perdus quand on leur offre un outil qui élimine ces contraintes techniques.

Puis vient le tirage au sort pour les goodies avec un raté de ce site qui tire au sort parmi les participants… Comme quoi, on en revient toujours au même : papier et crayons, rendent bien des services, sans jamais bugger ;)

Le buffet est amené : quantité et qualité concluent cette première séance.

J’en profite pour aborder Habib et lui demander comment il fait pour vendre Play! à ses clients. Pour moi c’est exactement la même problématique de simplicité novatrice, voire inquiétante, que pour Rails… Là encore une réponse claire (où je retrouve encore le parallèle avec l’agilité) :

Donner aux développeurs ! Là, la simplicité séduit la base puis remonte.

Puis je me dirige vers Guillaume pour parler du module SASS qui permet de générer des sites orientés iPhone.

Conclusion

Tout d’abord, chapeau à l’équipe du JUG Geneva pour l’intérêt du sujet et la qualité de l’organisation : Xavier, Maxime et David pour ceux que je connais, Géraldine et Ludovic pour ceux qu’il me reste à découvrir. Je suis bien placé pour savoir que ce n’est pas évident de gérer une cinquantaine de participants. Continuez ainsi !

Merci, merci et merci, trois fois, pour cette soirée de fraicheur. Cela me rassure de constater que je ne suis pas le seul à souffrir de cette complexité de JEE. Cela fait du bien de rencontrer d’autres Don Quichote, des cavaliers qui luttent contre ces moulins : la quête de la simplicité. Il serait intéressant de mettre dans la même arène les gars de Play! et les présentateurs de GlassFish et Java EE 6 ;)

On arrête les plans sur la comète, on arrête les framework génériques qui font tout  : un air d’agilité soufflait. En écrivant ce post, je ne peux effectivement m’empêcher de faire le parallèle entre ce mouvement de frameworks structurellement épurés (Play!, Rails…) et l’agilité il y a quelques années : on se pose la question de la finalité, et pour y arriver on revient à la simplicité !

Merci à ces deux extrémistes de la simplicité.

Quant à cette fougue qui anime Habib, elle me rappelle mes première années de passion où je me battais pour évangéliser XP et l’Agilité contre la complexité non fonctionnelle (selon moi) des méthodes en place… A cette différence qu’il a mis en application ce conseil que j’avais retenu à la fin de mon premier XP Day Paris :

Il ne faut pas prêcher, ce qui conduit parfois à l’agressivité : il faut agir, prouver par l’action.

Et je ne peux m’empécher de clore ce post avec cette autre citation, d’Antoine de Saint Exupéry :

La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.

petit-prince

Liens

PS: Merci à Xavier et Maxime pour leur relecture.

L'URL courte de cet article est : http://inagua.ch/jGnuU

11 réflexions au sujet de « Le JUG Geneva… Play! »

  1. ça va devenir une concurrence déloyale aux présentations tellement ce résumé en 5 minutes est bien tourné. La prochaine présentation du JUG Genève commencera donc par faire référence à cette entrée de blog et plus précisément à la prise de position sur le fait que l’époque des vi, emacs et Textmate est révolue. Vive l’époque du refactoring et des tests unitaires dans un environnement intégré !

    Bravo Jacques !

  2. hoho Freddy, t’aurais du être là, guillaume a fait toutes ça démo sur textmate :)
    et Jacques, je pense que la plupart des questions sur les transactions, le tunning c’était plus pour creuser sur le comment s’en passer plutot que par quoi elles ont été remplacées, mais les présentateurs étaient un peu en mode combat et tourner toutes les réponses en croisade anti-JEE, dommage

    Tom

  3. Merci pour ce compte rendu et pour cette soirée.

    La présentation était vraiment intéressante. En plus, cela m’a permis de découvrir ce framework et de constater “enfin” un réelle innovation sur les frameworks web Java.

  4. Merci Jacques pour le compte rendu super clair!

    Néanmoins je suis pas trop d’accord sur la partie Twingo RS :) Si Java est autant utilisé et apprécié dans les applications entreprises c’est justement pour sa force dans les domaines comme la gestion transactionnelles ou gestion de la sécurité. Par contre effectivement plutôt très moyen sur l’efficacité pour développer la couche MVC d’une application web. Les questions plus orientés JEE étaient légitimes et toute façon Play n’empêche (a priori) pas l’utilisation de librairie comme JTA par exemple pour gérer les transactions métiers mais propose surtout une autre vision de la partie front et on en avait bien besoin! Je pense qu’on était tous assez alignés, prêt à ébranler notre formatage pour la partie web, mais pas prêts à lâcher ce qui fait la force du JEE: ses compétences back-end.

    En tout cas merci et on se revoit à la prochaine conférence!

  5. Bonjour,

    Merci Alexis pour cette intervention qui sort du choeur des louanges consensuelles. La présentation était orientée, voire provocatrice, le résumé le retranscrit bien.

    Quelques points qui n’ont pas été creusés me semblent intéressants :

    - Il s’agit moins d’un framework que d’un container où l’AGL et le runtime sont fortement couplés. Cela me semble fort éloigné des préoccupations agiles et de ce que la plate forme JEE tente d’obtenir (malgré tous les mécanismes propriétaires des éditeurs)
    - Si on veut faire vite, et que l’on se débarrasse de toute la stack JEE (qui je le reconnais est très lourde), pourquoi ne pas faire du PHP ?
    - La plupart des références sont plus des sites orientés Web 2.0 que des applications de gestion que l’on connait

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*


*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>