Cette 1ère partie nous est présentée par Christian Blavier de chez Octo.
Java, c'est plein de belles promesses. C'est comme un hamburger plein de beaux ingrédients mais tellement que ça peut en devenir écoeurant : trop de couches, trop d'abstraction, on s'éloigne trop du html, ...
Ruby On Rails quant à lui est optimisé pour le plaisir des développeurs, c'est plein de bonnes idées.
On y retrouve une architecture MVC.
Etant basé sur Ruby, on y retrouve certaines facilités comme la manipulation de dates, les closures, ...
C'est aussi un framework fait pour le web :
- Quelques lignes suffisent pour y déclarer notre contrôleur. Si on souhaite du JSon, il suffit de l'indiquer, pas besoin de framework.
- Templating web : des gems comme ham et sass donne des facilités respectives en html et css
- Routage : Pour avoir des urls type REST, 1 seule ligne suffira dans le fichier de configuration de routage
- Active Record : Gère la persistance directement dans le modèle.
C'est aussi un framework fait par des agilistes pour les agilistes. Le test est au coeur du développement et il existe un outillage important pour aider dans la testabilité. Parmis eux : Mocha, Girl Factory, Time Cop, Cucumber, ...
Pour le déploiement, Heroku offre une plateforme qui permet de déployer gratuitement son application; et ça en une ligne de commande.
HTML5
Pour la deuxième partie, c'est Alain Duval et Cédric Beurtheret de Objectif Informatique.
La présentation démarre avec un rappel de la Genèse de Html5 puis un rappel de ses principales fonctionnalités.
Ils nous livrent aussi un retour d’expérience projet.
Au début, ils avaient utilisé Gears puis sont passé à html5 quand ce fut possible. Leur application est destinée à gérer la relation clientèle pour des commerciaux équipés de tablet pc possédant une connectivité 3g. Un zoom est fait sur 3 fonctionnalités :
- Web worker : C'est une API pour lancer une tâche de fond sans bloquer le navigateur.
- Cross window messaging : permet à deux fenêtres de communiquer entre elles, même si elles ne sont pas sur le même domaine.
- Web storage : du stockage de données locales dans le navigateur. Il est possible de travailler en mode synchrone ou asynchrone, mais la 2ème option est recommandée car plus performante. Par contre attention à la sécurité de vos données, la base locale ne permet pas l'utilisation d'identifiants.
Et pour finir, nous avons le droit à une belle démo dédiée au JUG montrant ces 3 fonctionnalités : une page qui affiche des message twitter. Les messages sont récupérés par une web worker et stockés en base locale le tout avec une fenetre de log gérée par le cross window messaging. Pour montrer le bon fonctionnement, quelques personnes envoient des tweets qui apparaissent sans avoir à rafraîchir la page.
Play!
Et pour la dernière partie, c'est au tour de Nicolas Martignole et de Guillaume Bort.
Play est un framework qui fait de plus en plus parler de lui que ce soit sur les blog mais aussi dans des conférences comme Jazoon et même JavaOne.
Tout d'abord, il faut savoir que Play! n'est pas basé sur l'API Servlet qui est comme une muti-prise sur laquelle on a branché un tas d'appareils successivement.
L'analogie du McDo est prise comme exemple : là bas, vous faites la queue jusqu'à ce qu'une équipière prenne votre commande puis court dans tous les sens pour vous la préparer et vous l'apporter. Pendant ce temps là, elle ne peut pas prendre d'autre commande
Par contre, Play! c'est comme Starbuck. Les commandes ne sont pas prises par ceux qui préparent ce qui permet de répondre rapidement à une demande client.
La philosophie de Play! est assez proche de celle de Grails avec quelques fonctionnalités en moins comme les finders dynamiques.
On va avoir une url propre (ex : http://www.express-board.fr/user/sfeir/27) fini tout ces paramètres uniquement techniques. Une url se doit d'être lisible, bookmarkable et partageable.
Si on veut pouvoir monter en charge sans devoir mettre en place de réplication de session, le serveur doit être stateless. C'est à sens que les informations de session sont stockées dans le navigateur dans un cookie crypté de seulement 3Ko.
Play! n'est pas client side, c'est pourquoi son ihm se sert des langages du web : html/css/js
C'est comme un couteau suisse, c'est fullstack.
Là où en java, on a l'habitude d'une certaine complexité liée à l'intégration de différents frameworks entre eux, Play! propose de prendre le problème différemment. Un problème compliqué a t il besoin d'une solution compliquée ?
Play aide à la productivité en ayant un serveur sans état : pas besoin de le redémarrer pour ajouter/retirer des fonctionnalités, lorsqu'une erreur se produit en mode dev, elle s'affiche lisiblement dans le navigateur, ...
Et cela s'illustre dans la démo, en quelques minutes et très peu de code Guillaume contruit un formulaire pour ajouter des éléments à une liste de todos, et ce juste avec un éditeur de texte et aucun redémarrage. Tout cela est possible parce que Play ne se base pas les fichiers .class mais sur les fichiers .java.
Articles
