Technologies

Tutoriel : Play/Scala/Java/Heroku !

Publié le : Auteur: vhanniet Laisser un commentaire
technologies

Voilà un tutoriel très impressionnant. Découvrir en même temps Play, Scala et Heroku !
Je n’ai pas écrit ce tutoriel moi même, je me contente de commenter et de fournir quelques infos complémentaires. Par ailleurs, bien entendu, je n’ai pas lu de littérature sur ces technos avant de me lancer dans le tutoriel. C’est bien le principe d’un tutoriel de nos jour, non ? : se lancer les mains dans les poches et réussir !!!

Le tutoriel Play que je vais commenter, très bien fait, est à ouvrir et démarrer ici : http://www.playframework.com/documentation/2.1.1/JavaTodoList.

Une première chose à remarquer : son petit frère « pur Scala » est presque à la même adresse. Il suffit de remplacer JavaTodoList par ScalaTodoList dans l’adresse ci-dessus. Une deuxième chose à noter est le « 2.1.1 » dans l’adresse qui indique la version de Play utilisée dans ce tutoriel. Sur la page web du tutoriel, on peut cliquer en haut à droite dans une listbox qui se déroule à hauteur de « Browse versions » et ainsi accéder à différentes versions du tutoriel (elles sont réellement différentes).

Scala ou Java ?

En fait j’ai joué plusieurs fois les deux tutoriels. Scala est le langage « natif » avec Play et on en trouve un petit peu dans le tutoriel Java. Le tutoriel Scala est cependant un petit peu plus simple : c’est certainement lié à la plus grande concision de Scala par rapport à Java.
Ce qui est amusant, et notable, c’est qu’on aboutit exactement au même résultat utilisateur pour les deux tutoriels. Rien de surprenant puisqu’on a la même IHM en HTML.

Prerequisites

Tiens, ça commence bizarrement : on n’a pas besoin d’Eclipse ? C’est même déconseillé ? D’un autre côté, c’est vrai que c’est plus rapide et plus simple de tout faire en ligne de commande et avec un petit éditeur performant… En tout cas tant qu’on reste au niveau tutoriel c’est sûr !
Comme éditeur de texte j’ai découvert et choisi Sublime Text 2. Franchement, c’est top.  Si je devais développer j’utiliserais surement  ça… En gros : on ne se pose pas de question, tout est naturel et rapide.
Après, effectivement, le framework Scala contient tout ce qui permet de gérer le cycle de vie « unitaire » : compilation, déploiement, debugging. En ajoutant Heroku qui embarque Github : tout est là au niveau technique, y compris sur la voie DevOps côté Heroku (voir à la fin).

Projet creation

Bon, créons notre première appli Play. On va faire mieux que « Hello World » : on se lance carrément dans une appli de gestion de tâches !
Un simple

$ play new todolist

sert de wizard et on obtient une appli vide… mais qu’on peut déjà lancer. Au passage notons qu’une fois qu’on l’a lancée (c’est en fait l’étape suivante) on se retrouve avec un répertoire contenant 162 fichiers répartis dans 117 dossiers et occupant environ 6 Mo. C’est pas que ça fasse beaucoup en tant que tel (ça contient notamment un serveur web) mais y retrouver ses petits en cas de plantage et tout en ligne de commande… ça promet de nombreuses heures de jeu si le projet est un peu conséquent !

Using the Play console

Allez, on lance la bête :

cd todolist
$ play
[todolist] $ run

suivis d’un petit http://localhost:9000/ dans un web browser quelconque, et ça y est on a un magnifique écran HTML5 digne d’un message d’accueil Apache ou Tomcat ! On ne peut pas dire que cette première appli (vide) Play soit spectaculaire : honnêtement je m’attendais à un peu plus de fun.

Overview

Et là, tout de suite, on rentre dans le coeur de l’approche WOA(*) : on apprend que le fichier « routes » contient directement le mapping entre les adresses web de l’appli et les méthodes à invoquer (ici Java). C’est certain, c’est super simple et efficace ! …enfin, jusqu’à ce qu’on ait des dizaines de pages dans l’appli. Dans le même esprit ces méthodes retournent… un code HTML !
C’est étonnamment simple sur les principes, et plutôt séduisant.
(*) Web Oriented Architecture

Development work-flow

Allez, on se fait quand même un petit « Hello World » au passage. Et on en profite pour voire le debugging, vachement bien fait. Et c’est là où c’est fun : pas besoin de relancer le serveur pour prendre en compte des modifs dans le code Java, et en cas d’erreur de compilation on voit directement l’endroit où ça coince dans la page de rendu dans le browser. Là pour le coup on doit gagner pas mal de temps…

Preparing the application

On est toujours dans le fun avec la gestion des TODO. Mine de rien, ça doit être super efficace lorsqu’on est sur un développement nouveau.
Ça vaut le coup d’aller lire la page d’explication sur la gestion du routage embarquée dans Play. Là encore on est vraiment dans la WOA : au plus près du protocole HTTP.

Prepare the Task model

Là on entre dans le développement « métier » : les classes Java « métier » sont identifiées comme les éléments « models » du pattern MVC sous-tendu par Play. Effectivement, le répertoire « app » contient maintenant trois sous-répertoires : models, views, controllers.
Je note au passage que ce qu’on appelle « application » est le contrôleur. C’est un peu comme si on disait que ce qui est le plus important dans une application c’est d’avoir un utilisateur et de lui afficher des trucs. Et ensuite on fait en sorte que les trucs puissent se rattacher à un service métier qu’on rend à cet utilisateur. C’est une façon de voir la vie très… contemporaine. Tout dans la communication, à défaut d’avoir finalisé les idées sur le fond !

The application template

Bon, là on est dans le HTML. Même avec le helper et le caractère « @ » pour les annotations Play j’ai du mal à imaginer développer l’IHM d’un projet conséquent de cette façon. Mais je ne suis pas un spécialiste, et c’est peut-être tout aussi compliqué d’écrire les écrans HTML d’un projet Java classique ?

The task form

C’est l’étape du tutoriel qui m’a posé le plus de problème. Il faut ajouter la ligne

static Form<Task> taskForm = Form.form(Task.class);

dans Application.java, mais où pour ne pas avoir d’erreur de compilation ? En fait, le truc c’est de ne pas oublier les imports :

import play.data.*;
import models.*;

A ce stade on n’a toujours rien de plus sur la page d’accueil.

Rendering the first page

Ça sent bon : on va voir un vrai truc sur la page d’accueil de notre application Play !
Je peux préciser que la ligne de code est à ajouter dans le fichier Application.java dans le corps de la méthode tasks(). Ça paraît assez évident après coup mais quand on déroule le tutoriel sans se poser de question…
Bon c’est pas beau (faudrait peaufiner la présentation) mais ça y est : on peut créer une tâche. En fait la création est très fugitive puisque rien n’est encore prévu pour stocker et persister cette tâche !

Handling the form submission

Ça y est, on n’a plus de TODO quand on crée une tâche. Mais elle n’est toujours pas persistée, on a juste géré la notion de formulaire HTML. C’est fait de manière concise et efficace. Un effet Play ?

Persist the tasks in a database

C’est là qu’on découvre EBean, la solution Play par défaut pour le mapping objet relationnel (ORM) qui gère la persistance des objets créés par l’application. Là non plus je ne suis pas un spécialiste mais ça ressemble comme deux gouttes d’eau à Hibernate and co. Avec, donc, les mêmes problèmes latents en cas de complexité du modèle métier (et non, on ne peut pas toujours faire les choses simplement : des fois c’est réellement compliqué, comme la vie).

Deleting tasks

Il s’agit plutôt ici de brancher la méthode de suppression sur le bouton [delete]. On intervient donc dans le contrôleur Application.java. C’est simple et efficace.

Deploying to Heroku

Jusque là l’application Todolist fonctionne parfaitement sur mon poste. L’idée est maintenant d’utiliser une PAAS (Plate-forme As A Service) pour déployer dans le cloud. Concrètement ça n’a pas fonctionné sur mon poste pour des raisons de firewall au niveau du protocole Git. Il n’empêche qu’on peut voir facilement ce que ça peut donner dans une pure approche DevOps, et ça reste très simple.
Un petit coup de Git pour assurer la gestion des versions, et au passage garantir que ce qui tourne en prod est bien la dernière version qu’on veut déployer, et ça y est, c’est déployé. Et on peut facilement adapter les ressources matérielles depuis le Dashboard Heroku (c’est tout l’intérêt du cloud).

Bilan

Cette première prise en main de Play est séduisante. Ce que je retiens est que :

  • il s’agit d’un framework complet : c’est à la fois pas bien (encore un nouveau framework) et bien (on n’embarque pas de superflu : lean attitude)
  • c’est du développement lean : on code directement au plus prés du protocole HTTP et quand ça plante on debugge directement sur la page web !!
  • c’est du MVC bien rangé : un répertoire distinct pour le M, le V et le C

Reste à voir ce que ça donne avec une équipe moyennement performante. Ben oui, quand tout le monde est super compétent et super motivé ça marche toujours ! C’est systématiquement le cas pour les « nouveaux » frameworks. Et même le fait qu’il y ait de grands utilisateurs, et donc que la techno fonctionne (mais la techno ça fonctionne toujours), ne garantit pas que tout projet va marcher aussi bien sur un projet lambda.

A suivre…