1. Conception d'Applications
Interactives :
Applications Web et JEE
Séance #5
J'ai besoin d'une appli we 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. ● 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

11. ● 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

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 !
● 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é !

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
● 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

18. Il y a quoi dans ?

19. ● 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 ?

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

22. ● 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 ?

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

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

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