Conception d'Applications Interactives :

Applications Web et JEESéance #5

J'ai besoin d'une appli we rapidement

On a un besoin !Maintenant on fait comment ?

Développement rapide d'applications web ?

Comment fait-on quand on a besoin de créer rapidement une petite application web d'entreprise ?

● La plupart des forges logicielles d'entreprise ne sont pas adaptées à ce besoin...

Développement rapide d'applications web ?

● Réponse du freelance hipster

Java est ringard, lourd et compliqué, utilise quelque chose de moderne comme Ruby on Rails !

Développement rapide d'applications web ?

● Réponse de la Production

Dans cette boîte on travaille sur la JVM, et on a des normes. Ton truc d'hippie ne

rentrera pas dans mes serveurs !

Développement rapide d'applications web ?

● Réponse du manager

Nos équipes ne connaissent pas la techno, les procédures ne sont pas là, le workflow n'est

pas prêt, et on ne sait pas chiffrer ça ! Et si on se trompe, à qui la faute ?

Développement rapide d'applications web ?

● Réponse du marketing

On a besoin de l'appli pour lundi !C'est toujours pareil, vous dites toujours non !

On va faire appel à une web agency et déployer sur le cloud, au moins ça sera fait...

Et moins cher !

Développement rapide d'applications web ?

● Et pourtant le besoin est là... Quoi faire ?

On est en 2013 ! Aujourd'hui on peut faire du développement

web rapide sur la JVM

Développement web rapide ?

C'est quoi ce beans ?

● Framework MVC de développement web rapide ○ Full stack Framework○ Générateurs de code : models, views, controllers

● Convention plutôt que configuration○ Élimination de la tuyauterie ○ Pas de soupe au XML○ Don’t Repeat Yourself (DRY)

● Orienté agilité, l'appli tourne dès le premier jour

Ruby a changé la façon de faire du développement web

Un peu d'histoire : Ruby on Rails

● Frameworks orientés applications d'entreprise○ Grosses applications○ Cycles de développement long○ Grosses équipes de développeurs ○ Coût de setup projet élevé

● Peu adaptés à petites applications ou cycles rapides

Un peu d'histoire : les outils JEE face à Rails

Concepts du développement web

rapide ?De quoi mon framework a besoin ?

Convention plutôt que configuration

● Le framework doit avoir des conventions qui définisent comment coder○ Si on suit les conventions, il n'y a pas de tuyauterie à faire

● Le framework doit permettre de coder autrement○ Pour des besoins pas adaptées à la convention○ Dans ce cas, on doit faire la tuyauterie

● Pour que ça marche, ces cas doivent rester à la marge○ Ratio 80% convention, 20% configuration maximum

Principe Don't Repeat Yourself (DRY)

Si on fait du web, suivons le webWhen a web framework starts an architecture fight

with the web, the framework loses.

● PHP et Ruby on Rails l'ont bien compris ○ Si on fait du web, on s'adapte au web !

● Un framework de développent web rapide doit être adapté au web

Modifiez, rechargez, c'est fait !

● Devoir redémarrer le serveur après une modif ?● Redéployer car on a changé un fichier ?

● A nouveau, regardons PHP ou Ruby on Rails○ Si on fait du web, on s'adapte au web !

● Avec un framework de développent web rapide il doit suffit de recharger la page pour qu la modif est prise en compte○ Ca, c'est de la productivité !

GrailsBridgekeeper: What... is your name?Sir Lancelot: My name is Sir Lancelot of Camelot.Bridgekeeper: What... is your quest?Sir Lancelot: To seek the Holy Grail.Bridgekeeper: What... is your favourite colour?Sir Lancelot: Blue.Bridgekeeper: Go on. Off you go.

Monty Python and the Holy Grail

Grails● Framework de développement web rapide

○ Sur la JVM○ Avec une intégration sans faille avec Java

● Inspiré par Ruby on Rails, Django et autres○ Convention plutôt que configuration○ Don’t Repeat Yourself (DRY)

Grails à la rescousse

Il y a quoi dans ?

● Développement en Groovy ● Très expressive● Sans tuyauterie

○ Rapidité et simplicité : change le code et recharge la page !

● Syntaxe familière pour développeurs Java● Intégration sans faille avec Java

Il y a quoi d'autre dans ?

Groovy, baby !

Langage de POO destiné à la plate-forme Java● Inspiré de Python, Ruby et Smalltalk● Syntaxe très proche de Java● Compilé

○ soit à la volée dynamiquement○ soit classiquement vers bytecode

● Typages statique et dynamique● Support natif pour listes, maps et regex ● Fermetures ou clôtures (closures)● Surcharge des opérateurs

http://groovy.codehaus.org/

Grails n'est pas un jouet

● Si vous faites les choses à la façon Grails○ Tout est simple, aucun boilerplate

● Pour les besoins exotiques○ Vous pouvez mettre les mains dans Spring○ Tout reste propre pour le reste de l'application

Mais il y a quoi sous le capot ?

● Spring Tool Suite (STS)○ IDE basé sur Eclipse○ Support pour toute la suite Spring○ Support complet Grails (et Groovy, of course)

● IntelliJ Ultimate Edition○ Support complet Grails (et Groovy, of course) via plugin○ Payant

● NetBeans○ Support complet Grails (et Groovy, of course via plugin

● Gedit, TextMate, Notepad++, même Emacs !

Et quel IDE j'utilise ?

● Les développeurs cools jouent avec Play Framework

Mais si je veux être encore plus hype ?

Play! FrameworkJe veux jouer !

Le projet

Play! est un framework pour ● faire du développement web● avec une haute productivité● avec l'état de l'art des technologies web● sur la JVM● double modèle de développement

○ Java ou Scala

- productivité et plaisir

● Conçu par des développeurs web pour des développeurs web

● Gestion simple, flexible et puissante du protocole HTTP○ Framework web -> HTTP au centre○ Stateless, request-response

● Facilité de démarrage○ Courbe d'apprentissage douce

● Rapidité et simplicité : change le code et recharge la page !

● Framework complet, full-stack

non plus n'est pas un jouet

● Modèle de programmation HTTP asynchrone● Architecture scalable de haute performance● Modèle reactive, non bloquant● Typage fort

● Architecture stateless basé sur HTTP● Modifiez, rechargez, c'est fait !● HTTP utilisé comme protocole, avec sa semantique

Le web a évolué

● On est au bord d'une nouvelle évolution :○ Les requêtes asynchrones en temps réel○ Des énormes flux de données○ Les BDD non relationnelles

● Les frameworks classiques ont du mal à s'adapter

Les limites des frameworks classiques

● Chaque utilisateur connecté consomme des ressources○ Mémoire, threads...

● Modèles basés sur l'attente active○ Synchronisme entre requête et réponse○ On bloque un thread côté serveur

● Les I/O sont bloquantes

Play! utilise un modèle réactif

● Inversion de contrôle○ On agit que lorsqu'on a quelque chose à faire

● Sans perte de contrôle○ Mais on est capable de garder le contrôle

● Iteratee/Enumerator IO

● Eclipse○ Avec ScalaIDE plugin○ Support complet Play! (et Scala, of course)

● IntelliJ Ultimate Edition○ Support complet Play! (et Scala, of course) via plugin○ Payant

● NetBeans○ Support complet Grails (et Groovy, of course via plugin

Et quel IDE j'utilise ?

Le mot de la finUn principe à ne pas oublier

Loi de l'outil

Si le seul outil que tu as est un marteau, tu vas t'attaquer à tous les problèmes comme si ils étaient des clous

● Grails, Play et autres sont adaptés à un type de besoin● GWT, Spring, JSF et autres sont adaptés à un autre

Il faut utiliser chaque techno pour l'utilisation pour laquelle il est pertinent

Show us something, dude !

Voici une petite démo