• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Play Framework 2.x lightening talk @ LyonJUG 18 Mars 2014
 

Play Framework 2.x lightening talk @ LyonJUG 18 Mars 2014

on

  • 548 views

Téléchargez le PDF avec le bouton au-dessus du slideshow. ...

Téléchargez le PDF avec le bouton au-dessus du slideshow.

J'ai utilisé Play 2.x pour déployer un service en Saas et j'ai bien aimé plusieurs nouveaux concepts, plus simples que les autres frameworks Java, car ne reposant pas sur la Servlet API.

J'ai voulu le partager avec le Java User Group de Lyon. Durée 15 minutes.

C'est tombé juste avant une présentation de Java EE 7 par David Delabassee, une belle occasion d'introduire le débat.

Statistics

Views

Total Views
548
Views on SlideShare
546
Embed Views
2

Actions

Likes
0
Downloads
1
Comments
0

2 Embeds 2

https://twitter.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - J’ai déployé une appli en SAAS pour Atlassian Confluence - Voir https://marketplace.atlassian.com/vendors/1210634 <br /> - Play remet en cause nos hypothèses et ça rafraîchit <br /> - Donc j’ai voulu partager ça avec la communauté JUG <br />
  • Les auteurs valent le détour <br /> Conférences de Habib Guergachi a Devoxx, je recommande <br /> Habib aime bien jeter un paver dans la mare, moquer les habitudes des devs Java. Il nous incite à nous rebeller contre le modèle Entreprise. <br />
  • - Problème = Modèle Entreprise = J2EE est une spec lourde, demande beaucoup de compétences, on n’est senior qu’après 7 ans. Cool, ça nous fait des hauts salaires. <br /> - Ruby On Rails: A côté on a des jeunes qui font des services web utilisés par des milliers d&apos;utilisateurs et qui ont 20 ans. Quel est le problème de productivité avec Java? Où est-ce qu&apos;on s&apos;est enlisés?- Une partie de la réponse c&apos;est la critique de la Servlet API <br /> - Une autre, la remise en cause de nos modes de gestion de projet. <br />
  • BDUF: Spécifier un projet sur 1 an, cahier des charges de 1000 pages = Approche “brute force” et plutôt naive. <br /> Le BDUF, et le modèle de la DSI centralisée, c’est notre mort en tant qu’ingénieurs. <br /> Habib promeut: <br /> - Décentralisé, <br /> - Petites équipes <br /> - Typiquement, Agile,- Web-Oriented Architecture =&gt; Applications REST, indépendantes, centrées sur leur métier (Stockage de fichiers, recherche plein texte), mash-ups- Play est l&apos;aboutissement de cette philosophie. <br />
  • BDUF: Spécifier un projet sur 1 an, cahier des charges de 1000 pages = Approche “brute force” et plutôt naive. <br /> Le BDUF, et le modèle de la DSI centralisée, c’est notre mort en tant qu’ingénieurs. <br /> Habib promeut: <br /> - Décentralisé, <br /> - Petites équipes <br /> - Typiquement, Agile,- Web-Oriented Architecture =&gt; Applications REST, indépendantes, centrées sur leur métier (Stockage de fichiers, recherche plein texte), mash-ups- Play est l&apos;aboutissement de cette philosophie. <br />
  • Principes- Priorité à la productivité. Hypothèse qu’on va faire du web =&gt; on peut fournir un fw intégré. But: Livrer une app en quelques jours.- Prêt pour le cloud. En phase avec la philosophie Décentralisé: Si l&apos;appli a du succès, si arrive au coeur des services métiers, on peut la scaler. Sinon on peut lui donner 1/2 CPU. Comme vu a JUG de Janvier sur Logback, ça a un impact sur le code: En Cloud, un serveur n’a pas d’importance, il peut être éteint et remplacé en quelques secondes, donc on doit faire plus de “stateless”. On va voir comment toute cette philosophie est implémentée dans Play.- Asynchrone. Principe que le framework doit être en avance sur les usages. Les usages évoluent: Long polling, chat, streaming, et surtout quand les back-ends ont beaucoup de latence (ex: dans le cas de stocker dans Amazon S3, et dans le cas des DSI orientées WOA), on ne peut pas bloquer un thread en attendant une réponse. Car cela supposerait 1 thread par client, donc 10 000 clients, 10000 threads, pas scalable.Donc le NIO, et sortir de la Servlet API, c&apos;est à la fois une question de scalabilité, une question de nouveaux usages, et une question d’architecture du web décentralisé puisqu’on repose sur des back-ends à forte latence. cf JUG suivant par David Delabassee: Il va nous présenter les WebSockets et le NIO dans Java 7. <br />
  • Prenons un exemple de choses fondamentales que Play remet en cause.- Le sessions en Servlet API = envoie un cookie JSESSIONID pour identifier l&apos;utilisateur, et les variables de session sont stockées en RAM.- Du coup, toute une classe de pb.- En cluster, le second noeud ne connaîtra pas la session. Seul le premier. =&gt; LB à affinité de session: Un client est toujours renvoyé au même noeud.- Redémarrage =&gt; Sessions perdue =&gt; Utilisatuer déloggué =&gt; Inventer “Persistence des sessions” sur un disque.- Après 6 mois et 1m visites, problématique de la purge de sesisons.- Toute une classe de problèmes, parce que hypothèse de base incorrecte. On ne peut pas scaler quand le server stocke 1 session par client.- Dans Play: Si vous avez une variable utilisateur à stocker =&gt; Cookie =&gt; Signé par clé privée. Pas d&apos;info du côté du serveur. <br /> STATELESS. Pas d&apos;état côté server. Soit dans le cookie, soit dans la DB soit chez le client. Donc vous pouvez multiplier les serveurs web: vos 15 autres serveurs ont les mêmes infos pour traiter vos requêtes. <br /> - Ensuite, pour optimisation: Cache API. Pb de cache, pas de session.- Je recommande la lecture des critiques de la Servlet API, pour remettre en perspective nos connaissances. <br />
  • Passons au code. <br /> Rassurant: HTML- Injection de variable au milieu: @context.- En réalité, c’est un template Scala =&gt; Compilé en .class =&gt; Appelé directement depuis Java. Le plus efficace! <br /> =&gt; Play = culture Scala, jouer avec le bytecode. <br />
  • - Liste des URLs -&gt; Méthodes associées. <br /> - Technique à la mode: “Design d’API” <br /> - Par oppositions aux urls *.do, *.action de Struts. Tous les fw Java redéfinissent le routing d’URL, c’est la preuve que l’expression des urls dans la Servlet API est trop limitée. Impact: Le developpeur doit apprendre 2, 3, 4 fw pour router ses urls: Servlet API + Struts + Spring + ... <br /> - Design d’urls = important quand on expose son API et qu’on veut faire du RESTful. <br /> - Donc important dans un SI de type “WOA”, où beaucoup d’autres équipes consomment vos services, <br /> - Et des urls expressives évitent d’avoir à documenter =&gt; Principe Agile: La meilleure doc est celle qu’on n’a pas besoin d’écrire. <br />
  • - Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel au template vu précédemment, voyez comme le type-checking est pratique. <br /> - Oh! La méthode est statique! Tout est statique!- Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout débutant, de stocker des variables d&apos;état ou de cache. <br /> =&gt; On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails. <br />
  • Démarrer- Play =&gt; Lance la SBT- L&apos;outil de build est scala. Pas Maven.- Inconvénient: Gérer les dépendances en sbt, il faut réapprendre- Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21)- Commande run =&gt; Lance Netty =&gt; Server d&apos;appli qui supporte les websockets.- Depuis 2-3 slides je présente des choix d&apos;architectures qu&apos;ils ont faits: Ils ont choisi qu&apos;on fait du web, JPA - Hibernate, Netty, tempaltes HTML.- Choix réversibles: Templates Soy ou Velocity.- Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l&apos;appli rapidement. Une application de qualité, qui soit scalable. <br />
  • Revenons sur les principes:- Productif: Play propose des choix par défaut qui sont “suitable” pour de la prod. But: Livrer une app en quelques jours au lieu de se quereller sur les fws. <br /> - Prêt pour le cloud: On a vu comment le stateless étati exprimé, on a vu l’usage des sessions, et au JUG de Janvier on a vu Logback. <br /> - Asynchrone: On n’a pas vu mais Play intègre par défaut des WebSockets + Comet <br /> Choix sérieux. LinkedIn utilise Play sur plusieurs sous-parties du site. <br />
  • Un mot sur les critiques- L&apos;usage des statics controversé - rend le code peu testable. Il y a plusieurs workarounds: PowerMock et l&apos;usage de Guice ou Spring, mais globalement ça veut dire qu&apos;on n&apos;est pas assez poussé à faire du test unitaire. <br /> - Les libraries utilisées doivent être NIO <br /> - Le support JUnit est désagréable: Il faut exécuter les tests dans le browser- L&apos;usage de la SBT: Un outil difficile à apprendre, j&apos;espère que vous n&apos;en aurez pas trop besoin.- La perte de compatibilité entre la version 1 et 2. Beaucoup de plugins n&apos;existent que pour la version 1. Mais LinkedIn utilise la version 2. <br />
  • Enfin, pourquoi? Dans SSII, sur votre projet...- D&apos;abord vous allez former vos recrues rapidement. Elles seront plus vite capables de mettre une appli en prod. Ça, c&apos;est bon pour vous.- Ce qui est aussi bon pour vous, c&apos;est que vous allez apprendre ou entendre parler de plein de technos modernes. Même si vous ne les utilisez pas pour Play, ça va vous remettre à l&apos;heure et vous rafraîchir.- Et si vos membres apprennent des choses sur le projet, les jeunes vont vouloir venir travailler pour vous. Donc vous pourrez vous entourer de gens talentueux et motivés, et ça, ça vous permettra de maintenir votre actualisation.Donc au total, vous apprenez, vous êtes productifs, et vous attirez des gens motivés qui vont vous apprendre et qui vont maintenir votre actualisation. <br />
  • HTTP Denial: Comme si on allait remplacer HTTP par un nouveau protocole l’an prochain <br /> URL Routing: Pour preuve, la majorité des frameworks réimplémentent leur propre routing. Ex: Struts & urls en *.do <br /> La Servlet API n’étant pas suffisante, on a besoin de frameworks, donc d’apprendre autant de frameworks. On éparpille nos compétences entre Struts, Spring Servlet, JSP, JSF, JBoss Seam etc. <br /> JSF: Mais pourquoi??? http://global3.memecdn.com/why-meme_o_293612.jpg <br /> Servlet API 3.1 arrive après que les usages soient devenus fréquents. <br />
  • =&gt; Technos de 2014. Plutôt que de passer des heures à apprendre Spring et à m’ennuyer avec des specs J2EE dont la mailing liste est décédée, j’ai pu me concentrer sur des technos qui ont de la vraie valeur ajoutée, j’ai retrouvé de la productivitié, de l’agilité, le plaisir de coder en java. J’ai rajeuni. Et ça reste prêt pour la scalabilité, et ça s’inscrit dans une vision plus moderne d’architecture du SI. cf Habib Guergachi à Devoxx en 2012 et 2013. <br />
  • - play.db.jpa.JPA =&gt; Pas le vrai javax.persistence.Persistence <br /> - L’EntityManager (=en gros, la transaction) est dans le thread <br /> - Notez que c’est un bean, mappé par JPA à une table de db. <br /> - Notez les membres public: Après compilation ils sont privés avec des getters/setters, ce qui vous permet d’overrider les getters/setters. Encore un exemple de culture Scala. <br /> - Remarquez le “DAO” directement sur le Bean. <br /> =&gt; Principe du modèle non-anémique. Les getters valident leurs données, les DAO sont sous forme de méthodes statiques, le bean est riche. Voir http://www.playframework.com/documentation/1.0/model <br /> - Play! intègre des scripts d’évolution. On y pense rarement jusqu’au second déploiement en prod... <br />
  • - Chaque rafraîchissement, recompilation si nécessaire (et classloader de Play) <br /> - Principe: Accélérer le dev <br /> - Bientôt on pourra corriger l’erreur directement depuis le web? bientôt un IDE web ;) ? <br />

Play Framework 2.x lightening talk @ LyonJUG 18 Mars 2014 Play Framework 2.x lightening talk @ LyonJUG 18 Mars 2014 Presentation Transcript

  • PLAY FRAMEWORK 2 JAVA @aragot mercredi 19 mars 14 - J’ai déployé une appli en SAAS pour Atlassian Confluence - Voir https://marketplace.atlassian.com/vendors/1210634 - Play remet en cause nos hypothèses et ça rafraîchit - Donc j’ai voulu partager ça avec la communauté JUG
  • GUILLAUME BORT & HABIB GUERGACHI CTO & CEO chez Zengularity http://soat.developpez.com/articles/weborientedarchitecture/ http://www.parleys.com/play/5148922a0364bc17fc56c738 http://www.parleys.com/play/517ae9a4e4b0736a5fa66a1f mercredi 19 mars 14 Les auteurs valent le détour Conférences de Habib Guergachi a Devoxx, je recommande Habib aime bien jeter un paver dans la mare, moquer les habitudes des devs Java. Il nous incite à nous rebeller contre le modèle Entreprise.
  • GUILLAUME BORT & HABIB GUERGACHI Devoxx 2012 Devoxx 2013 CTO & CEO chez Zengularity http://soat.developpez.com/articles/weborientedarchitecture/ http://www.parleys.com/play/5148922a0364bc17fc56c738 http://www.parleys.com/play/517ae9a4e4b0736a5fa66a1f mercredi 19 mars 14 Les auteurs valent le détour Conférences de Habib Guergachi a Devoxx, je recommande Habib aime bien jeter un paver dans la mare, moquer les habitudes des devs Java. Il nous incite à nous rebeller contre le modèle Entreprise.
  • GUILLAUME BORT & HABIB GUERGACHI CTO & CEO chez Zengularity JEE mercredi 19 mars 14 - Problème = Modèle Entreprise = J2EE est une spec lourde, demande beaucoup de compétences, on n’est senior qu’après 7 ans. Cool, ça nous fait des hauts salaires. - Ruby On Rails: A côté on a des jeunes qui font des services web utilisés par des milliers d'utilisateurs et qui ont 20 ans. Quel est le problème de productivité avec Java? Où est-ce qu'on s'est enlisés? - Une partie de la réponse c'est la critique de la Servlet API - Une autre, la remise en cause de nos modes de gestion de projet.
  • GUILLAUME BORT & HABIB GUERGACHI CTO & CEO chez Zengularity “Mort du modèle Entreprise” mercredi 19 mars 14 BDUF: Spécifier un projet sur 1 an, cahier des charges de 1000 pages = Approche “brute force” et plutôt naive. Le BDUF, et le modèle de la DSI centralisée, c’est notre mort en tant qu’ingénieurs. Habib promeut: - Décentralisé, - Petites équipes - Typiquement, Agile, - Web-Oriented Architecture => Applications REST, indépendantes, centrées sur leur métier (Stockage de fichiers, recherche plein texte), mash-ups - Play est l'aboutissement de cette philosophie.
  • GUILLAUME BORT & HABIB GUERGACHI CTO & CEO chez Zengularity “Web-Oriented Architecture” mercredi 19 mars 14 BDUF: Spécifier un projet sur 1 an, cahier des charges de 1000 pages = Approche “brute force” et plutôt naive. Le BDUF, et le modèle de la DSI centralisée, c’est notre mort en tant qu’ingénieurs. Habib promeut: - Décentralisé, - Petites équipes - Typiquement, Agile, - Web-Oriented Architecture => Applications REST, indépendantes, centrées sur leur métier (Stockage de fichiers, recherche plein texte), mash-ups - Play est l'aboutissement de cette philosophie.
  • PRINCIPES • Productivité du développeur • Prêt pour le Cloud[1] • Asynchrone [1] https://news.ycombinator.com/item?id=7172060 mercredi 19 mars 14 Principes - Priorité à la productivité. Hypothèse qu’on va faire du web => on peut fournir un fw intégré. But: Livrer une app en quelques jours. - Prêt pour le cloud. En phase avec la philosophie Décentralisé: Si l'appli a du succès, si arrive au coeur des services métiers, on peut la scaler. Sinon on peut lui donner 1/2 CPU. Comme vu a JUG de Janvier sur Logback, ça a un impact sur le code: En Cloud, un serveur n’a pas d’importance, il peut être éteint et remplacé en quelques secondes, donc on doit faire plus de “stateless”. On va voir comment toute cette philosophie est implémentée dans Play. - Asynchrone. Principe que le framework doit être en avance sur les usages. Les usages évoluent: Long polling, chat, streaming, et surtout quand les back-ends ont beaucoup de latence (ex: dans le cas de stocker dans Amazon S3, et dans le cas des DSI orientées WOA), on ne peut pas bloquer un thread en attendant une réponse. Car cela supposerait 1 thread par client, donc 10 000 clients, 10000 threads, pas scalable. Donc le NIO, et sortir de la Servlet API, c'est à la fois une question de scalabilité, une question de nouveaux usages, et une question d’architecture du web décentralisé puisqu’on repose sur des back-ends à forte latence. cf JUG suivant par David Delabassee: Il va nous présenter les WebSockets et le NIO dans Java 7.
  • SESSIONS Sessions façon J2EE: • Cookie: JSessionID • Sessions façon Play: • Cookie (signé) mercredi 19 mars 14 Prenons un exemple de choses fondamentales que Play remet en cause. - Le sessions en Servlet API = envoie un cookie JSESSIONID pour identifier l'utilisateur, et les variables de session sont stockées en RAM. - Du coup, toute une classe de pb. - En cluster, le second noeud ne connaîtra pas la session. Seul le premier. => LB à affinité de session: Un client est toujours renvoyé au même noeud. - Redémarrage => Sessions perdue => Utilisatuer déloggué => Inventer “Persistence des sessions” sur un disque. - Après 6 mois et 1m visites, problématique de la purge de sesisons. - Toute une classe de problèmes, parce que hypothèse de base incorrecte. On ne peut pas scaler quand le server stocke 1 session par client. - Dans Play: Si vous avez une variable utilisateur à stocker => Cookie => Signé par clé privée. Pas d'info du côté du serveur. STATELESS. Pas d'état côté server. Soit dans le cookie, soit dans la DB soit chez le client. Donc vous pouvez multiplier les serveurs web: vos 15 autres serveurs ont les mêmes infos pour traiter vos requêtes. - Ensuite, pour optimisation: Cache API. Pb de cache, pas de session. - Je recommande la lecture des critiques de la Servlet API, pour remettre en perspective nos connaissances.
  • TEMPLATES mercredi 19 mars 14 Passons au code. Rassurant: HTML - Injection de variable au milieu: @context. - En réalité, c’est un template Scala => Compilé en .class => Appelé directement depuis Java. Le plus efficace! => Play = culture Scala, jouer avec le bytecode.
  • ROUTES mercredi 19 mars 14 - Liste des URLs -> Méthodes associées. - Technique à la mode: “Design d’API” - Par oppositions aux urls *.do, *.action de Struts. Tous les fw Java redéfinissent le routing d’URL, c’est la preuve que l’expression des urls dans la Servlet API est trop limitée. Impact: Le developpeur doit apprendre 2, 3, 4 fw pour router ses urls: Servlet API + Struts + Spring + ... - Design d’urls = important quand on expose son API et qu’on veut faire du RESTful. - Donc important dans un SI de type “WOA”, où beaucoup d’autres équipes consomment vos services, - Et des urls expressives évitent d’avoir à documenter => Principe Agile: La meilleure doc est celle qu’on n’a pas besoin d’écrire.
  • CONTRÔLEURS mercredi 19 mars 14 - Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel au template vu précédemment, voyez comme le type-checking est pratique. - Oh! La méthode est statique! Tout est statique! - Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout débutant, de stocker des variables d'état ou de cache. => On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.
  • CONTRÔLEURS mercredi 19 mars 14 - Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel au template vu précédemment, voyez comme le type-checking est pratique. - Oh! La méthode est statique! Tout est statique! - Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout débutant, de stocker des variables d'état ou de cache. => On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.
  • CONTRÔLEURS mercredi 19 mars 14 - Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel au template vu précédemment, voyez comme le type-checking est pratique. - Oh! La méthode est statique! Tout est statique! - Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout débutant, de stocker des variables d'état ou de cache. => On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.
  • CONTRÔLEURS mercredi 19 mars 14 - Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel au template vu précédemment, voyez comme le type-checking est pratique. - Oh! La méthode est statique! Tout est statique! - Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout débutant, de stocker des variables d'état ou de cache. => On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.
  • CONTRÔLEURS mercredi 19 mars 14 - Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel au template vu précédemment, voyez comme le type-checking est pratique. - Oh! La méthode est statique! Tout est statique! - Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout débutant, de stocker des variables d'état ou de cache. => On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.
  • LANCEMENT mercredi 19 mars 14 Démarrer - Play => Lance la SBT - L'outil de build est scala. Pas Maven. - Inconvénient: Gérer les dépendances en sbt, il faut réapprendre - Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21) - Commande run => Lance Netty => Server d'appli qui supporte les websockets. - Depuis 2-3 slides je présente des choix d'architectures qu'ils ont faits: Ils ont choisi qu'on fait du web, JPA - Hibernate, Netty, tempaltes HTML. - Choix réversibles: Templates Soy ou Velocity. - Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l'appli rapidement. Une application de qualité, qui soit scalable.
  • LANCEMENT mercredi 19 mars 14 Démarrer - Play => Lance la SBT - L'outil de build est scala. Pas Maven. - Inconvénient: Gérer les dépendances en sbt, il faut réapprendre - Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21) - Commande run => Lance Netty => Server d'appli qui supporte les websockets. - Depuis 2-3 slides je présente des choix d'architectures qu'ils ont faits: Ils ont choisi qu'on fait du web, JPA - Hibernate, Netty, tempaltes HTML. - Choix réversibles: Templates Soy ou Velocity. - Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l'appli rapidement. Une application de qualité, qui soit scalable.
  • LANCEMENT mercredi 19 mars 14 Démarrer - Play => Lance la SBT - L'outil de build est scala. Pas Maven. - Inconvénient: Gérer les dépendances en sbt, il faut réapprendre - Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21) - Commande run => Lance Netty => Server d'appli qui supporte les websockets. - Depuis 2-3 slides je présente des choix d'architectures qu'ils ont faits: Ils ont choisi qu'on fait du web, JPA - Hibernate, Netty, tempaltes HTML. - Choix réversibles: Templates Soy ou Velocity. - Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l'appli rapidement. Une application de qualité, qui soit scalable.
  • PRINCIPES • Productivité • Cloud • Asynchrone mercredi 19 mars 14 Revenons sur les principes: - Productif: Play propose des choix par défaut qui sont “suitable” pour de la prod. But: Livrer une app en quelques jours au lieu de se quereller sur les fws. - Prêt pour le cloud: On a vu comment le stateless étati exprimé, on a vu l’usage des sessions, et au JUG de Janvier on a vu Logback. - Asynchrone: On n’a pas vu mais Play intègre par défaut des WebSockets + Comet Choix sérieux. LinkedIn utilise Play sur plusieurs sous-parties du site.
  • PRINCIPES • Productivité • Cloud • Asynchrone • Choix d’architecture • Stateless, Sessions • WebSockets, Comet, Netty IMPLEMENTATION mercredi 19 mars 14 Revenons sur les principes: - Productif: Play propose des choix par défaut qui sont “suitable” pour de la prod. But: Livrer une app en quelques jours au lieu de se quereller sur les fws. - Prêt pour le cloud: On a vu comment le stateless étati exprimé, on a vu l’usage des sessions, et au JUG de Janvier on a vu Logback. - Asynchrone: On n’a pas vu mais Play intègre par défaut des WebSockets + Comet Choix sérieux. LinkedIn utilise Play sur plusieurs sous-parties du site.
  • CRITIQUES • #1: Statics • Librairies: /! NIO • Support JUnit [1] • SBT • Compatibilité 1.x - 2.x [1] http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/ mercredi 19 mars 14 Un mot sur les critiques - L'usage des statics controversé - rend le code peu testable. Il y a plusieurs workarounds: PowerMock et l'usage de Guice ou Spring, mais globalement ça veut dire qu'on n'est pas assez poussé à faire du test unitaire. - Les libraries utilisées doivent être NIO - Le support JUnit est désagréable: Il faut exécuter les tests dans le browser - L'usage de la SBT: Un outil difficile à apprendre, j'espère que vous n'en aurez pas trop besoin. - La perte de compatibilité entre la version 1 et 2. Beaucoup de plugins n'existent que pour la version 1. Mais LinkedIn utilise la version 2.
  • POURQUOI? • Quick learning curve • Technos incontournables en 2014 • Attirer des talents mercredi 19 mars 14 Enfin, pourquoi? Dans SSII, sur votre projet... - D'abord vous allez former vos recrues rapidement. Elles seront plus vite capables de mettre une appli en prod. Ça, c'est bon pour vous. - Ce qui est aussi bon pour vous, c'est que vous allez apprendre ou entendre parler de plein de technos modernes. Même si vous ne les utilisez pas pour Play, ça va vous remettre à l'heure et vous rafraîchir. - Et si vos membres apprennent des choses sur le projet, les jeunes vont vouloir venir travailler pour vous. Donc vous pourrez vous entourer de gens talentueux et motivés, et ça, ça vous permettra de maintenir votre actualisation. Donc au total, vous apprenez, vous êtes productifs, et vous attirez des gens motivés qui vont vous apprendre et qui vont maintenir votre actualisation.
  • Adrien Ragot - adrien@play-sql.com @aragot mercredi 19 mars 14
  • RESERVE mercredi 19 mars 14
  • PLAY 2.X [1] • Asynchronous programming • Controllers return Promise<Result> • Comet,WebSockets • Event model,Akka • Native support for Java and Scala • Type Safety • Compiled HTML templates (Scala) • Compiled routes (Scala) • SBT build file [1] http://www.playframework.com/documentation/2.0/Philosophy mercredi 19 mars 14
  • LA SERVLET API • HTTP Denial • Limited syntax for url routing • Requires frameworks = 2x more config files • Struts, Spring, JSP, JSF, JBoss Seam... • NIO since Servlet API 3.1 (Java 7, May 2013) [1] http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api mercredi 19 mars 14 HTTP Denial: Comme si on allait remplacer HTTP par un nouveau protocole l’an prochain URL Routing: Pour preuve, la majorité des frameworks réimplémentent leur propre routing. Ex: Struts & urls en *.do La Servlet API n’étant pas suffisante, on a besoin de frameworks, donc d’apprendre autant de frameworks. On éparpille nos compétences entre Struts, Spring Servlet, JSP, JSF, JBoss Seam etc. JSF: Mais pourquoi??? http://global3.memecdn.com/why-meme_o_293612.jpg Servlet API 3.1 arrive après que les usages soient devenus fréquents.
  • VOUS ENTENDREZ PARLER DE... • Backbone.js, Require.js, CoffeeScript • FluentLenium / WebDriver / Page Objects • Logback • Heroku • ... mercredi 19 mars 14 => Technos de 2014. Plutôt que de passer des heures à apprendre Spring et à m’ennuyer avec des specs J2EE dont la mailing liste est décédée, j’ai pu me concentrer sur des technos qui ont de la vraie valeur ajoutée, j’ai retrouvé de la productivitié, de l’agilité, le plaisir de coder en java. J’ai rajeuni. Et ça reste prêt pour la scalabilité, et ça s’inscrit dans une vision plus moderne d’architecture du SI. cf Habib Guergachi à Devoxx en 2012 et 2013.
  • JPA (PERSISTENCE) Non anaemic domain model: http://www.playframework.com/documentation/1.0/model mercredi 19 mars 14 - play.db.jpa.JPA => Pas le vrai javax.persistence.Persistence - L’EntityManager (=en gros, la transaction) est dans le thread - Notez que c’est un bean, mappé par JPA à une table de db. - Notez les membres public: Après compilation ils sont privés avec des getters/setters, ce qui vous permet d’overrider les getters/setters. Encore un exemple de culture Scala. - Remarquez le “DAO” directement sur le Bean. => Principe du modèle non-anémique. Les getters valident leurs données, les DAO sont sous forme de méthodes statiques, le bean est riche. Voir http://www.playframework.com/documentation/1.0/model - Play! intègre des scripts d’évolution. On y pense rarement jusqu’au second déploiement en prod...
  • GESTION DES ERREURS mercredi 19 mars 14 - Chaque rafraîchissement, recompilation si nécessaire (et classloader de Play) - Principe: Accélérer le dev - Bientôt on pourra corriger l’erreur directement depuis le web? bientôt un IDE web ;) ?
  • ACTIVITÉ Play 1.0 October 2008 Oct2008 Nov2010 Apr2011 Fev2013 Play 1.1 JBoss Netty Play 1.2 Apache Ivy WebSockets Play 2.1 JSON API Filters RequireJS Play 2.2 Buffering gzip Hibernate or Ebean Sep2013 Play 2.0 Async Scala Type Safety Sbt Mars2012 mercredi 19 mars 14