Ping-Conf est une conférence organisée à Budapest, qui a eu lieu du 15 au 17 janvier. Petite particularité, c’est la première conférence uniquement sur Play! Framework, sur 2 jours. Impossible pour moi de ne pas y aller. J’ai présenté un sujet sur mon retour d’expérience avec Zaptravel, Play2 et Redis.
Organisé dans un endroit tout neuf, le BMC, nous étions environ 200 personnes. Au programme, 6 conférences par jour. Côté organisation, c’était vraiment parfait pour une première édition. Badge avec le programme, très belle salle, excellent buffet, Wifi, streaming des sessions en direct sur Internet, repas des speakers, bref que du bon. Et mon avis est partagé avec les autres speakers qui étaient présents.
La première journée débute par une keynote d’ouverture, par Sadek Drobi, CTO de Zengularity et développeur principal sur Prismic.io. On retrouve un peu de sa présentation de Scala.IO, avec cependant quelques informations sur le développement de Play! Framework. La communauté est de plus en plus importante. Comme nous le verrons pendant ces 2 jours, il y a en fait beaucoup de projets qui utilisent Play! Framework. 90 projets par exemple chez LinkedIn. On est très loin de l’épiphénomène.
La première conférence de Matt Hamer fait un retour d’expérience sur une architecture 2-tiers avec Play! Matt présente un projet qui a plusieurs millions d’utilisateurs, dans le monde de la publicité sur Internet. L’architecture est composée de 2 domaines différents. D’une part, une couche de présentation, et d’autre part, un backend avec un ensemble de services. Les 2 couches utilisent Play2/Java, avec cependant 2 cas d’usages différents. La première implémentation utilise HTTP pour faire communiquer les 2 couches. Cependant, pour des raisons historiques, le projet rencontre un problème de performance avec la sérialisation Java. Classique, c’est exactement le même souci (je me dis : la même merde) que ce que nous avions avec du vieux J2EE, des EJBs remotes, et donc, cette sérialisation qui tue les performances. Son équipe remplace alors cela par Protocol Buffer. Ce système d’encodage de données structurés donne de meilleurs résultats, et surtout, est plus lâche que le contrat de la sérialisation Java. Bon, soit. Mais mes vieux réflexes de Java-istes me disent à ce moment là : toi tu es entrain de te refaire ce que nous avons déjà vu dans le monde Java/Entreprise.
Une architecture avec 2 tiers permet cependant de distinguer la mise à jour de la partie service, de ce qui est du tiers de présentation. On peut argumenter que les fréquences de mise à jour de l’interface utilisateur sont plus fréquentes, que celles du backend. D’où une architecture en mille-feuille. Encore faut-il ne pas tomber dans le dogmatisme, et c’est ce qui moi, m’a un peu ennuyé dans cette présentation. Si HTTP et donc Protocol Buffer donnent satisfaction, l’équipe d’architecture se dit que ce serait bien d’utiliser plutôt Akka, et le système de Remote-Agent. Il se trouve d’ailleurs qu’Akka utilise Protocol Buffer pour sérialiser et échanger les données… Grâce à la simplicité d’Akka, en effet nous avons vu qu’il était facile de mettre en place ce type d’architecture. Pour ma part, je préfère utiliser HTTP, et faire des services Webs. J’échangerai des données avec un format comme JSON. Si j’ai un souci de performances, un varnish permettra de GZiper le flux HTTP. Si je dois déployer cela dans un réseau d’entreprise, je sais que ce système sera plus simple à configurer, qu’un cluster avec Akka. Enfin je me dis que c’est ce que fait LinkedIn, et que donc, ça ne doit pas être une trop mauvaise idée…
La deuxième conférence est proposée par Christopher Hunt (@huntchr). Ancien de SpringSource/vmWare, il est basé en Australie. Sa présentation porte essentiellement sur sbt-web, sur web-jars et sur Javascript. Il montre les nouveaux outils et librairies que nous pourrons utiliser dans Play 2.3. D’un point de vue technique, c’est convaincant et bien ficelé. Si vous codez une application Web sur la JVM (même JSF est supporté) allez faire un tour sur http://www.webjars.org/. Quant à sbt-web, c’est un plugin pour SBT. Je n’ai pas très bien compris cette partie. Plus intéressant, sbt-jshint-plugin permet d’intégrer JSHint dans une application Play. Le tout fonctionne durant la phase « test », en utilisant Rhino, le moteur JS intégré dans les dernières versions de Java. Commencez par regarder JSHint. Cet outil permet d’introspecter votre code JS et de vous montrer en temps réel les erreurs ou les problèmes potentiels. Cette conférence était donc très orientée JS, avec pas mal de présentations sur ce que le framework peut vous proposer.
La troisième conférence porte sur le Cake Patterns. Yann Simon (@simon_yann) est Français, il vit depuis 7 ans à Berlin. Sa présentation est construite autour de plusieurs projets Play2/Scala, qu’il va nous détailler étape par étape. Si l’injection de dépendance est une drogue dure dans le monde Java, voyons comment le monde Scala se penche et adresse ce problème. Tout d’abord, un peu d’informations pour commencer. On s’en doute, mais l’injection de dépendance dans le monde Java peut avoir aussi un coût en terme de performances. Yann cite l’article « The Hidden Class Loading Performance Impact of the Spring Framework« . Lié à un bug dans les versions 3.0.7 et 3.1 de Spring framework, celui-ci a cependant été corrigé depuis. Mais bon, allez voir le bug SPR-9014 pour mieux dormir ce soir…
La présentation permettait à chacun de comprendre comment, dans le monde Scala, nous pouvons aussi avoir de l’injection de dépendances pour les compsants, et donc, la possibilité de réutiliser des composants. Il faudrait consacrer un article complet pour vous expliquer le principe de ce pattern.
La pause déjeuner mérite quelques lignes, car c’était très bon. Buffet chaud, avec des mets typiquement hongrois. Très sympa, et cela nous a aidé à tenir jusqu’au soir, pour le dîner des présentateurs. A noter que la veille, nous avions déjà goûté le très bon vin hongrois (cabernet, syrah, merlot et d’autres cépages locaux) ainsi que la nourriture (viandes en sauce, grillade, patate, crème, paprika, ragoût…). Bref tout cela pour dire que nous avons bien déjeuné 🙂
Au passage mon Macbook Pro décide de rendre définitivement l’âme. En fait la carte graphique montre des signes de faiblesse depuis 10 jours. J’avais prévu un backup avec une clé USB pour pouvoir faire ma présentation en fin de journée : heureusement 🙂
L’après-midi reprend avec la 4ème conférence, la présentation de Julien Tournay (@skaalf) et Pascal Voitot (@mandubian) de Zengularity. Très bonne présentation sur leurs travaux actuels, l’API de validation de Play 2.3. Celle-ci n’est pas encore intégrée dans le coeur de Play, mais devrait nous permettre de simplifier notre code. Qu’est-ce que cela va changer ? Vous pourrez définir les contraintes de validation de vos formulaires avec la même API que celle qui permet déjà de valider le chargement d’une donnée JSON par exemple. Ainsi, nous pourrons exprimer avec le même format nos différentes contraintes de validation. Les exemples de codes montrent que le passage de l’api de validation actuelle vers la nouvelle ne demandera pas trop d’efforts. A suivre donc.
Après une heure assez poussée, et une heure avant que je passe à mon tour, la 5ème présentation est animée par Matthias Nehlsen (@matthiasnehlsen). Freelance, il est aussi l’auteur d’un blog, avec des articles détaillés sur Play. Sa présentation porte sur l’écriture d’une application de Chat, avec Server-sent event, et typage fort… jusque dans le navigateur.
Avez-vous entendu parler de scala.js ? Il s’agit d’un transpileur qui permet d’écrire du Scala… qui sera compilé en code Javascript du côté client. Bien entendu, cela reste limité à ce qu’il est possible de faire en JS. L’intérêt et la motivation est d’utiliser Scala pour apporter le typage fort et de générer du code JS. Tout ceci bien entendu est encore expérimental. J’ai pas trop accroché.
Par contre j’ai trouvé intéressant la présentation de React.js durant sa démonstration. Alternative intéressante à Angular.JS, ce projet est poussé par Facebook. N’étant pas un expert Javascript, je ne vais pas me lancer dans une comparaison des 2 frameworks. Ce que j’ai compris cependant : React.JS utilise un DOM virtuel, et effectue des mises à jour par comparaison. Il effectue des copies virtuelles lorsque quelque chose doit s’afficher, et que donc, le dom doit être mis à jour. Contrairement à Angular.JS, il n’y a pas d’invalidations. A priori, React.js est plus proche de l’approche où les données sont immuables, et chaque nouvelle version du DOM est donc une copie « virtuelle ». Matthias a montré une application avec une puissante fonction d’Undo, où chaque étape de la modification du DOM (en recevant un message par exemple) peut être annulé. Bref je me dis que j’irai bien voir React.js, pour compléter ce que j’ai déjà appris avec Angular.js
Enfin la dernière présentation de la journée était la mienne, sur Play2 et Redis. Elle est disponible en vidéo sur le site UStream, et vous pourrez donc la regarder si cela vous intéresse.
Rendez-vous dans un autre article pour la 2ème journée.
Je vous laisse avec quelques photos de Budapest, by night, et le marché que nous avons traversé le matin en allant à la conférence. C’est une très belle ville.
0 no like
Hello,
Pour le Cake Pattern j’avais fait un article assez complet sur InfoQ qui explique comment ca marche aux développeurs habitués à Spring:
http://www.infoq.com/fr/articles/cake-pattern-scala-explique-developpeurs-spring
————
Pour React, j’ai l’occasion de l’utiliser en ce moment après avoir fait un peu d’Angular. C’est un framework très simple, beaucoup plus simple qu’Angular et beaucoup plus facile de raisonner avec. La prise en main est rapide, la doc est claire et on a fait le tour de toutes les fonctionnalités en quelques heures: ça vaut le coup de s’y mettre vu l’investissement. Contrairement à Angular qui n’est pas vraiment fieldtesté sur un projet majeur chez Google, React est utilisé intensivement sur Facebook et Instagram.
En revanche la documentation actuelle manque d’explications sur comment structurer son application. React pilote et optimise les modifications sur le DOM, mais il ne fait que ça, contrairement à Angular qui fourni en plus de l’injection de dépendances, des services comme $http…
Par exemple, il faut lire un peu entre les lignes de la doc pour comprendre que sur Instagram par exemple ils utilisent React avec le routeur de Backbone (qui sera remplacé par le routeur Flatiron Director bientot). Ils sont en train de combler ces vides dans la doc en ce moment. Ce qui est bien c’est que les mecs de Facebook et Instagram sont très actifs et répondent à toutes les questions sur leur channel IRC.
Pour ceux qui utilisent Angular et veulent se mettre à React la prise en main est très simple. Dans Angular on utilise souvent des directives custom avec un isolate scope. Les variables du isolate scope utilisées avec = permettent de faire du 2-way binding. Perso je trouve cette approche plutôt « sale » et son parent et si je dois modifier une variable d’un scope parent, je préfère passer des fonctions dans le isolate scope.
En fait un composant React c’est un peu comme une directive avec un isolate scope sur lequel vous ne pouvez utiliser que des @ et &, donc pas de 2-way binding avec =. Ce scope en one-way binding est appelé « props » en React.
React ne le permet pas car il ne fait pas de dirty checking et n’a aucun moyen alors de detecter qu’il faut refaire un rendu du DOM, contrairement à Angular.
Dans React quand il faut refaire un rendu du DOM, il faut l’appeler explicitement sur le composant avec « setState » donc la fonction du parent qu’on passe dans les props/scope de l’enfant donc appeler setState sur le parent pour déclencher le rendu alors qu’avec Angular il suffit de modifier le scope parent (via la fonction ou le 2-way binding) et le rendu sera déclenché par dirty checking.
J’avais posé une question à ce sujet sur StackOverflow qui explique quelques trucs sur le sujet:
http://stackoverflow.com/questions/21111217/react-compared-to-angular-directive-with-isolate-scope
A noter qu’il n’y a pas encore de support JSX sur Intellij, mais ça va l’IDE s’en sort pas trop mal quand même et ne met pas du rouge partout.
Merci pour ce retour intéressant.
Une question cependant, dans la mesure où il s’agit d’une conférence dédiée à Play!. Y a-t-il eu des présentations ou des discussions en lien avec Play! v1 ?
Beaucoup de développeurs (dont moi), gardent une préférence sur la version 1, plus adaptée à Java, et plus accessible que la version 2. La question d’une « résurrection » de cette v1 fait toujours débat, mais hélas toujours pas de bonne nouvelle à l’horizon.
Rien de nouveau donc ?
@Romain Honnêtement, pas de conférences ou de retours sur Play! Framework v1. Je sais que les contributeurs travaillent pour sortir une nouvelle version dans quelques semaines, avec des bugs fixes et quelques nouveautés. Mais rien de nouveau à attendre.
Cela dit, la v1 tourne très bien et reste intéressante, surtout pour démarrer un projet web classique.
Je conseille la v2 pour les projets devant effectuer de l’intégration de services Webs, pour faire des architectures orientées Webs, ou pour profiter du typage fort, apporté par Scala. A titre personnel, je ne pense pas que Play2 + Java soit un choix intéressant, mais c’est très subjectif.
A voir et revoir selon ses besoins et son projet.