Ping-Conf : retour sur la deuxième journée

Après une première journée à Ping-Conf, la première conférence sur Play! Framework, voici mes notes de cette deuxième journée.

Avant de commencer, quelques mots sur Budapest, capitale de la Hongrie. C’est une très belle ville. Plus d’1.7 millions, les bâtiments sont magnifiques, surtout de nuit. En arrivant le matin, nous sommes passés par le marché couvert. Beaucoup de charcuterie, du paprika, et surtout une langue difficile à comprendre. Le Hongrois est une langue dérivée de la branche finno-ougrienne, comme le finnois ou l’estonien. Rien à voir avec l’anglais, une langue latine ou germaine. En tant que Français, nous sommes confondus avec les Roumains dans la rue, et cela, plusieurs fois. Le Français et le Roumain sont 2 langues latines, et la Roumanie est frontalière avec la Hongrie. Bref, je vous conseille Budapest pour un weekend sympa.

Keynote de LinkedIn

La journée commence par une keynote de LinkedIn, par Yevgeniy Brikman (@brikis98), mais que tout le monde appelle ‘Jim’. Plutôt qu’une keynote, c’était en fait une présentation très technique avec du live-coding. LinkedIn utilise Play2 depuis avril 2012. En fait, alors que nous étions à Devoxx France 2012 première édition, je me souviens avoir vu les équipes de Zenexity faire des Skypes avec les équipes de LinkedIn. Il y a plus de 60 applications aujourd’hui chez LinkedIn, avec Play2, en production. LinkedIn a dès le départ fait le choix d’utiliser Java. En février 2003, lorsque j’étais à Palo-Alto, j’ai eu la chance de travailler quelques semaines avec Yan Pujante, avant que celui-ci ne parte pour rejoindre LinkedIn.

Jim présente un sujet intéressant, la composition de contenu, autrement appelé portail. Comment gérer et charger efficacement différents contenus, provenant de différents services ? Play est un framework web particulièrement puissant pour faire de la composition de services. Sa présentation porte donc sur la capacité à composer différents contenus dans une action d’un contrôleur. Après avoir présenté les Enumerators/Iteratee/Enumeratee, il explique les différents moyens de streaming existant. Cela va de la solution côté serveur, à la solution Javascript, capable de charger des parties de votre page. Tout ceci s’inspire de Facebook BigPipe. L’idée étant de générer différentes morceaux de votre contenu, de les assembler et de les streamer vers le client. J’ai vraiment beaucoup aimé cette présentation. Sur un site où le contenu est constitué de différentes widgets, c’est une solution simple et ultra-puissante. Par rapport à un portail classique, la souplesse de Play2 est supérieure. Voir sur Github son projet complet.

Talk 1, Play is for Performance, James Roper

James Roper est le responsable du projet Play chez Typesafe. Guillaume et Sadek ont passé la main, et c’est maintenant les équipes de Typesafe qui se chargent de Play2. James est le chef de projet de Play2. Sa présentation est très originale car il n’a pas fait de slides. Enfin si… mais en écrivant une application play2. Au lieu de faire du Powerpoint ou un fichier Keynote, il a simplement écrit une application Play2 (voir le code ici). Cette application est constituée de pages webs, qui défilent comme des slides.

Pourquoi ? Et bien car il va faire tourner des benchmarks directement dans ses slides. J’ai bien aimé l’idée, et c’est assez simple à mettre en oeuvre. Le talk porte sur la performance et les connaissances à avoir pour bien comprendre Play2. Je conseille tout d’abord à tout développeur Play2 de lire la documentation sur les ThreadPools. C’est un sujet assez difficile à comprendre, surtout lorsque l’on vient de Play1. Tout d’abord, tout dans Play 2, est asynchrone. L’instruction Async (ou Action.async dans play2) ne sert qu’à indiquer que l’exécution d’un code peut s’effectuer dans un autre ExecutionContext. Malheureusement, nous mélangeons souvent le vocabulaire, ce que Sadek Drobi résume parfaitement dans un article. ExecutionContext est plus important que tout le reste dans play2. Et c’est vraiment dommage de regarder Enumeratee/Iterator/Enumerator, sans déjà avoir compris le fonctionnement interne de Play2. Je trouve qu’il y a encore des améliorations à faire sur ce point. Guillaume Bort parlait de revoir l’execution context dans le coeur de play2 en novembre dernier. Je ne sais pas s’il a avancé sur ce point.

Bref excusez-moi pour la digression, revenons à notre conférence. James rappelle d’abord un poncif : asynchrone ne veut pas dire plus rapide. Du code synchrone est plus rapide à l’exécution. La différence survient lorsque votre code effectue des appels bloquants. Par exemple une requête à une base de données. Les drivers classiques JDBC ne sont pas réactifs, et vont donc bloquer votre Thread, le temps de recevoir une réponse de la base. C’est là que Play fait la différence, en ayant en interne une architecture qui vous permet de séparer les traitements, et ainsi de ne pas bloquer une Thread principale. Par défaut, Play2 tourne avec une Thread par coeur, avec 24 Threads maximum (doc de référence). De même, mettre du code dans un bloc Future{ } ne le rend pas asynchrone. S’il y a du code bloquant, alors la Thread est bloquée, si vous conservez le même ExecutionContext. Il démontre à chaque fois cela avec des exemples de code simple et donc, des benchmarks. La solution (qui manque un peu de documentation je trouve) est d’utiliser différents ExecutionContext. En fait, Sadek présente même l’idée d’avoir des Actions spécifiques pour effectuer par exemple des requêtes JDBC…

Talk 2 : Play2, ScalaZ and Sci-Fi

Pascal Voitot (@mandubian) et Julien Tournay  (@skaalf) sont développeurs chez Zengularity. Le talk qui va suivre, est vraiment poussé, et très intéressant. Pascal explique qu’il faut rester calme, bien respirer, on va faire un peu de Science Fiction… Au programme : Scalaz Streams.

Nos 2 experts sont tout d’abord de très bons développeurs, avec une bonne connaissance du coeur de Play!, puisqu’ils sont tous les deux contributeurs. Pascal a travaillé sur la lib JSON et Julien a présenté la librairie JSON de validation prévue pour Play 2.3 la veille.

Tout débute par la présentation de Process, la classe principale qui nous intéresse aujourd’hui. Un Process[F,O] représente un stream de valeur de O, capable d’entrelacer des requêtes externes afin d’évaluer des expressions de la forme F[A]. Pour cela, un Process est en fait une machine à état avec 3 états différents :

1. Emit qui indique que quelque chose doit être envoyé
2. Halt pour indiquer que le Process a terminé d’effectuer ses requêtes et d’émettre des valeurs sur sa sortie. Cet état permet aussi d’indiquer les cas d’erreur.
3. Await pour demander au driver d’évaluer une fonction de type F[A] avant de reprendre le traitement, dès que le résultat sera disponible

Ce que je comprends, c’est qu’un Process est à la fois source et consommateur. Pascal explique que Process est implémenté comme une Free Monad. Sans bagage dans votre formation sur la Théorie des Catégories, ça va piquer un peu. Promis, je vous expliquerai ce qu’est une free monad (lorsque j’aurai moi aussi compris)

La présentation pousse assez loin et nous montre ce que pourrait être le code du coeur de Play avec Process. C’est un pur exercice, mais qui reste facile à comprendre. J’ai trouvé personnellement l’approche plus intuitive, et j’ai appris pleins de choses sur le coeur de Play2.

Talk 3 : BBC for Children, Making the case for Play

Après Scalaz, le talk suivant était… étonnant. Adam Evans (@ajevans85) et Asher Glynn (@asherglynn) sont 2 développeurs de la BBC. Ils nous ont donné un retour d’expérience rafraîchissant sur Play. La BBC a un portail de jeux pour les enfants, CBeebies. Ici, ma fille est fan du site Hugo l’Escargot. Bref la BBC est passé du monde PHP au monde Play2+Scala, avec succès. La présentation raconte cette aventure. Le portail CBeebies est très populaire. Plus de 2 millions de client. Le souci sur l’ancienne version, c’est que lorsque le site ne marchait pas… le client se mettait à pleurer. Ce client (entre 6 et 12 ans) est ultra exigeant. Rien à faire de votre framework Java, sauf s’il fait pouet-pouet. Il y a des contraintes étonnantes de montées en charge. Par exemple le matin : les gamins jouent avec l’iPad pendant que les parents dorment…

Le passage des équipes de développeurs de la BBC d’un monde PHP vers le monde Scala s’est effectué rapidement. L’apprentissage de Scala s’est fait sans trop de soucis. Les équipes ont débuté avec les templates et du code Java, mais progressivement, en moins de 2 mois, tout le monde est monté sur Scala sans difficultés. Le typage fort et la composition sont 2 choses qui permettent au développeur comme à l’architecte d’être productif.

Il est vrai que Play2 a l’avantage de ne pas vous demander de connaître tous les outils et toutes les librairies du monde Java. L’intégration et le retour d’erreur dans le navigateur sont des outils de productivité.

Talk 4 : Play at the Guardian

Grant Klopper travaille pour un journal anglais, The Guardian. Le projet complet du site web a été open-sourcé sur Github, ce qui vous permettra de voir comment fonctionne le site mobile, et une partie du site grand public. Ce qu’il faut retenir, c’est les chiffres. Le site reçoit presque 6 millions de visites par jour, dont presque 2 millions de visiteurs via les applications mobiles. De façon étonnante, l’infrastructure est assez légère, avec peu de machines. Malheureusement la présentation n’était pas assez technique, et nous n’avons pas eu assez de réponses sur l’architecture. Quant au code, idem, c’était trop léger. Dommage, car il doit y avoir beaucoup d’histoires à raconter

Conclusion

Il reste encore 2 présentations, mais l’avion pour Paris nous attend. Il est temps de rentrer, après ces 2 jours très enrichissants. Côté organisation, c’était parfait. Pour un budget avion+hôtel raisonnable, cette conférence était l’une des plus intéressantes de ces derniers mois. J’espère y retourner l’an prochain.

Articles similaires:

Retour sur Ping-conf Devoxx 2013, la deuxième journée USI 2011 : ma deuxième journée USI 2011 : retour sur la première journée