1. Conception d'Applications
Interactives :
Applications Web et JEE
Séance #3
J'ai besoin d'une appli web rapidement

2. On a un besoin !
Maintenant on fait comment ?

3. 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...

4. 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 !

5. 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 !

6. 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 ?

7. 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 !

8. 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

9. Développement web
rapide ?
C'est quoi ce beans ?

10. Un peu d'histoire : Ruby on Rails
● 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

11. Un peu d'histoire :
les outils JEE face à 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

12. Concepts du
développement web
rapide ?
De quoi mon framework a besoin ?

13. 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)

14. Si on fait du web, suivons le web
When 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

15. 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 !
● Il doit suffire de recharger la page pour que la modif soit
prise en compte
○ Ca, c'est de la productivité !

16. Grails
Bridgekeeper: 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

17. Grails
à la rescousse
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)

18. Il y a quoi dans
?

19. Il y a quoi d'autre 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
?

20. 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/

21. Mais il y a quoi sous le capot ?
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

22. Et quel IDE j'utilise ?
● 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 !

23. Mais si je veux être encore plus hype ?
● Les développeurs cools jouent avec Play Framework

24. Play! Framework
Je veux jouer !

25. 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

26. - 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

27. 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

28. 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

29. 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

30. 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

31. Et quel IDE j'utilise ?
● 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

32. Le mot de la fin
Un principe à ne pas oublier

33. 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

34. Show us something, dude !
Voici une petite démo