ENIB 2013-2014 - CAI Web #3: J’ai besoin d’une appli web rapidement
Upcoming SlideShare
Loading in...5
×
 

ENIB 2013-2014 - CAI Web #3: J’ai besoin d’une appli web rapidement

on

  • 276 views

 

Statistics

Views

Total Views
276
Views on SlideShare
276
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ENIB 2013-2014 - CAI Web #3: J’ai besoin d’une appli web rapidement ENIB 2013-2014 - CAI Web #3: J’ai besoin d’une appli web rapidement Presentation Transcript

  • Conception d'Applications Interactives : Applications Web et JEE Séance #3 J'ai besoin d'une appli web 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 ?
  • 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
  • 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
  • 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 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
  • 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é !
  • 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
  • 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)
  • Il y a quoi dans ?
  • 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 ?
  • 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/
  • 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
  • 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 !
  • Mais si je veux être encore plus hype ? ● Les développeurs cools jouent avec Play Framework
  • Play! Framework Je 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
  • 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
  • Le mot de la fin Un 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