1. J’ai besoin d’une appli
web rapidement !
Développement rapide d'applications web
sur la JVM ?

2. T'es qui, toi ?
Horacio Gonzalez
Spaniard lost in Brittany, Java developer,
dreamer and all-around geek
● Architecte technique au Crédit Mutuel Arkea
○ Direction Technique Informatique
● JUG Leader du FinistJUG
http://lostinbrittany.org/
+Horacio.Gonzalez
@LostInBrittany

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19. Il y a quoi dans ?

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

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

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

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

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

25. Play! Framework
Je veux jouer !

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

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

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

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

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

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

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

33. Twitter Bootstrap
Car nous ne sommes pas
tous des graphistes

34. C'est très beau ça... mais le
HTML5/CSS3/JS me fait peur !
● Si on fait du web en 2013 on ne peut pas
se passer du HTML5/CSS3/JS
○ Mais la plupart des développeurs Java n'aiment pas HTML5/CSS3/JS
○ On n'est pas des graphistes !
● Quoi faire ?
● Solution 1: Venir à la séssion FinistJUG d'avril
○ JavaScript pour des développeurs Java
● Solution 2 : Utiliser Twitter Bootstrap

35. C'est quoi Twitter Bootstrap
● Constats chez Twitter en 2009 :
○ Les développeurs d'applications web n'aiment pas
faire de l'IHM web
○ A chaque nouvelle application, on refaisait une IHM
○ Soucis d'ergonomie, d'uniformité, d'esthétisme
● Solution : faire un boîte à utils HTML5/CSS3/JS
○ Pour IHMs performantes, egonomiques et jolies
○ Simple à utiliser
■ Permettant à un développeur de faire des IHMs
belles et efficaces
○ Lingua franca entre graphistes et développeurs

36. La panoplie Twitter Bootstrap
● Des éléments de base, des composants, des
widgets complèxes...
● Modulable
● Responsive

37. Facile à intégrer,
facile à personnaliser
● Il suffit d'embarquer les JS et CSS Bootstrap
● Les composants sont des classes CSS
● Pas besoin de prise de tête avec la présentation
● Responsive, adaptable à tout terminal
Mais je veux ma présentation à moi
● Des thèmes
○ Permettant de garder la puissance Bootstrap
○ Adaptant le look à ce que je veux
○ Toujours sans prise de tête développeur

38. Lingua franca ?
● Les graphistes web aiment Bootstrap
○ Ergonomie soignée
○ CSS claires et structurées
○ Simplicité d'adaptation et personnalisation des thèmes
● Les développeurs aiment Bootstrap
● Les graphistes et développeurs comprennent Bootstrap
Langage commun entre
développeurs et graphistes
● Le graphiste fournit des maquettes en Bootstrap
● Le développeur adapte sa logique IHM à Bootstrap

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

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

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