Hier soir la soirée était placée sous le thème « Java et le Web ». Malgré les grèves, il y avait les 210 passionnés et une belle ambiance. Le buffet était offert par Zenexity. En quelques mots, Zenexity, c’est une équipe dynamique de passionnés du Web rassemblée, autour d’Habib Guergachi et de Guillaume Bort, responsable du projet « Play! Framework » .
Ruby on Rails
En première partie, Christian Blavier d’Octo nous a présenté le framework Ruby on Rails. Il a publié un billet sur le blog d’Octo intéressant : « Confession d’un Javaiste repenti« . Il commence très fort avec l’image d’un hamburger, où chaque tranche du hamburger est estampillée du nom d’une technologie Java. Spring, JSF, Richfaces, HTML, et souvent, un petit pattern maison, pour justifier notre boulot d’architecte. Un ange passe dans la salle, mais personne ne se lève et ne crie au scandale. Le slide suivant représente le même hamburger passablement moisi, avec la réalité de certains projets, qui pour faire du Web, n’arrivent pas à mettre en oeuvre ce socle correctement.
Lors d’une mission, il découvre Ruby On Rails. Ce framework Web qui fête ses 6 ans est basé sur le langage Ruby. Dans le statut même de RoR (Ruby on Rails) les fondateurs mettent en avant la joie de programmer comme l’un des facteurs clés du framework. La productivité et le support du Web aussi. Personnellement je retrouve les mêmes valeurs dans Play!
Christian présente l’architecture du framework, purement MVC. Du côté du modèle relationnel, le moteur ActiveRecord (j’aurai plutôt pensé au pattern de M.Fowler Active Record) offre à RoR un socle à la fois simple mais suffisamment puissant pour réaliser des sites Webs et des applications d’entreprise. N’en déplaise à certain.
Concernant Ruby, Christian nous montre quelques exemples qui me font penser à Groovy. Langage dynamique et faiblement typé, Ruby offre par exemple ce type de syntaxe pour la manipulation des dates :
now = DateTime.now tomorrow = now + 1.day one_week_ago = 7.days.ago
Le support des closures fait bien entendu partie de Ruby :
Closure, ["one","two"].map{ |word| word.upcase }
RoR est un framework fait pour le Web. Votre classe de base étend une classe ApplicationController. Pour ceux qui ont suivi ensuite la présentation de Play! nous retrouvons la même approche. C’est l’approche « Skinny controller / fat model » ou l’approche Domain Driven Design.
Dans cet exemple, la méthode index charge l’ensemble des Books puis la place dans une variable @books, qui est retournée à la vue.
class BooksController < ApplicationController def index @books = Book.all end
Pour exemple, l'approche Play! Framework donnerait quelque chose comme cela:
public class Application extends Controller { public static void index() { Listbooks=Book.findAll(); render(books); } }
Ruby on Rails utilise un moteur de templating pour ce qui est de la partie vue. Il dispose de plusieurs moteurs, comme par exemple Haml
#profile .left.column #date= print_date #address= current_user.address .right.column #email= current_user.email #bio= current_user.bio
Le moteur Haml vient en remplacement je crois du moteur de base de Rails, appelé ERB:
<div id="profile"> <div class="left column"> <div id="date"><%= print_date %></div> <div id="address"><%= current_user.address %></div> </div> <div class="right column"> <div id="email"><%= current_user.email %></div> <div id="bio"><%= current_user.bio %></div> </div> </div>>
haml utilise l’indentation comme Python pour séparer les blocs. Christian cite aussi le projet SASS qui a été porté sous la forme d’un module pour Play! Framework aussi. Si vos CSS sont un vrai millefeuille, regardez SASS. Ce moteur permet de définir des variables que vous utilisez souvent dans vos feuilles CSS.
Concernant l’architecture, RoR est au plus proche de l’architecture REST, avec des URLs signifiantes. Un fichier de route permet enfin de construire des URLs bookmarkables et propres… comme un autre framework dont on parlera plus tard 😉
Concernant la partie ActiveRecord, rails comme grails dispose d’un ensemble de scripts très puissants pour générer rapidement des entités. Par exemple pour construire une entité Book avec quelques attributs :
rails generate model book title:string description:string
Pour terminer, il est important de noter que Rails est l’un des frameworks Webs les plus utilisés sur les projets Webs et les projets de startups. Avec des livres de références et les années d’expériences sur ce framework, c’est un moteur qui est souvent le point de départ de nombreuses aventures Webs. Lors du dernier Startup Weekend à Paris, les 3 premiers projets étaient basés sur Ruby on Rails. L’un des projets a utilisé Play! Framework, et il me semble que cela sera amené à se développer dans les mois qui viennent.
Bon, sinon le jour où vous passez au Paris JUG : ne faîtes pas de slides avec un fond noir, prenez le template du Paris JUG.
HTML 5
Alain Duval, directeur technique d’Objectif Informatique et Cédric Beurtheret, expert Java EE, présentent HTML 5. J’ai bien aimé cette présentation car elle nous fait prendre conscience des changements à venir dans la façon d’appréhender la réalisation d’une application Web. J’ai vraiment l’impression que le métier d’architecte web est une nouvelle compétence qui va exploser dans les années qui viennent.
HTML4 c’est 1998. Jusqu’en 2004 il ne se passait pas grand chose. HTML 5 est un effort tourné vers les nouvelles architectures avec un gros effort de standardisation. A priori la version finale est prévue pour dans 2 ans. Les problèmes de rétro-comptabilité et de support entre les navigateurs sont derrières nous. Les acteurs du marché travaillent ensemble pour proposer des standards. Cela dit, concernant par exemple l’initiative d’Apple sur le codec vidéo… je ne suis pas certain que cette belle lune de miel ne dure longtemps.
Des balises HTML seront progressivement retirées comme applet, frame ou font par exemple. J’ai retrouvé le lien cité par Alain pendant la présentation : HTML5_Visual-cheet-sheet.pdf. Le Doctype d’une page HTML 5 est ultra simple :
<!DOCTYPE html>
A titre d’exemple, le site de Zengularity est écrit en HTML 5 si vous voulez tester. C’est une plateforme de vidéos courtes sur le Web, le HTML 5, le framework Play!, réalisée par les équipes de Zenexity.
HTML 5 apporte des balises pour structurer la page. Il sera facile de définir par exemple une section header ou footer, sans devoir appliquer systématiquement un habillage avec des DIV comme aujourd’hui.
Concernant les Formulaires, nous notons l’apparition de nouveaux tags :
<search> <tel> <url> <email>
Sur le site du W3C, vous pouvez trouver des articles complets et intéressants si vous souhaitez découvrir comment nous ferons des formulaires webs demain.
Prenez par exemple ce code source :
<form method="post" enctype="application/x-www-form-urlencoded" action="https://pizza.example.com/order.cgi"> <p><label>Customer name: <input name="custname" required></label></p> <p><label>Telephone: <input type=tel name="custtel"></label></p> <p><label>E-mail address: <input type=email name="custemail"></label></p> <fieldset> <legend> Pizza Size </legend> <p><label> <input type=radio name=size value="small"> Small </label></p> <p><label> <input type=radio name=size value="medium"> Medium </label></p> <p><label> <input type=radio name=size value="large"> Large </label></p> </fieldset> <fieldset> <legend> Pizza Toppings </legend> <p><label> <input type=checkbox name="topping" value="bacon"> Bacon </label></p> <p><label> <input type=checkbox name="topping" value="cheese"> Extra Cheese </label></p> <p><label> <input type=checkbox name="topping" value="onion"> Onion </label></p> <p><label> <input type=checkbox name="topping" value="mushroom"> Mushroom </label></p> </fieldset> <p><label>Preferred delivery time: <input type=time min="11:00" max="21:00" step="900" name="delivery" required></label></p> <p><label>Delivery instructions: <textarea name="comments"></textarea></label></p> <p><button>Submit order</button><p> </form>
Si vous avez un navigateur assez récent, voici ce que cela donne :
De nouveaux attributs comme PlaceHolder, AutoComplete ou Autofocus font aussi partie des balises HTML 5. Nous aurons donc de moins en moins besoin de javascript. Le support natif sera la garantie que le poids des pages va fortement baisser je pense.
Alain pense que la validation des formulaires sera effectuée plus facilement du côté du navigateur.
Le côté multimedia et les différentes démonstrations sur la balise Canvas sont très prometteurs. Le support du multimédia, de la vidéo, de la 2D et de la 3D, le support natif de SVG, tout ceci devrait remplacer le player Flash dans les années qui viennent. Encore faut-il que les industriels s’accordent sur les Codecs. Et là, c’est le foutoir. Donc Flash a encore de longues années devant lui je pense.
Pour terminer, Cédric nous montre une application HTML 5 avec géolocalisation, drag and drop, support du mode offline. HTML 5 introduit la notion de Web workers. Cette application de gestion de la relation client à usage des commerciaux tourne sur TabletPC. Lorsque le commercial n’est pas connecté à Internet, une partie de sa base client est téléchargée sur le navigateur afin qu’il puisse travailler en mode déconnecté. La synchronisation a été implémentée avec un Web Worker. C’est une APi qui permet de lancer des scripts Javscripts en tache de fond. Cédrid explique qu’il était parti sur Google Gears, mais que Google arrête le support de cette technologie pour plutôt privilégier le socle HTML 5.
Concernant la possibilité de stocker des données sur le poste client, HTML 5 propose 3 niveaux différents selon vos besoins :
-> SessionStorage volatile, durée de la session
-> LocalStorage persistant mais limité en taille
-> WebDatabase basé sur SQLLite ou IndexB
Cédric attire notre attention quant à la sécurité des données sur le navigateur client. A priori la base n’est pas sécurisée, il faut donc prévoir une solution de cryptage.
En conclusion, en 30 minutes ce fut une belle présentation sur HTML 5, avec des pointeurs sur ce qui sera forcément notre futur demain. En tant que développeur, je le dis et je le répète, il n’est plus possible de ne pas connaître le HTML, CSS et Javascript en 2010. La récréation est terminée, la vision du « web-designer » qui fait ma page est très franco-française. Nos amis américains se marrent bien lorsque je raconte cette histoire.
Bref si tu n’as pas codé une page HTML à 30 ans, tu as raté ta vie de développeur.
Zenexity et le projet Zengularity
Le buffet était offert par Zenexity. J’aimerai parler un peu du projet Zengularity. Allez voir sur le site les différentes vidéos. Le concept ? Vous présenter en quelques minutes un sujet technique. Les premières vidéos parlent de Scala, de Web Workers, d’architecture, de programmation fonctionnelle. Sympa comme initiative. A tester.
Présentation Play! Framework avec Guillaume Bort
La deuxième partie de la soirée était consacrée à une présentation de Play! Framework puis à une démonstration par Guillaume. Je mettrai les slides en ligne la semaine prochaine, je vais faire cette même présentation lundi 18 octobre à la conférence Soft-Shake à Genève. Si vous voulez voir ce qu’il est possible de faire en une heure, rendez-vous lundi matin à 11h30.
Les retours sur Twitter ce matin étaient positifs, j’espère qu’avec Guillaume nous vous avons passé notre passion pour ce framework. Je le dis et j’insiste : si vous voulez vous faire plaisir avec du Java, que vos problèmes soient pour du Web ou une application lourde, testez Play! Framework.
0 no like
Mon avis : la présentation sur le Play! framework était vraiment excellente, sexy à souhait. Bravo !
J’ai quelques interrogations sur Play!… Mes affirmations seront peut-être erronées, merci de me corriger le cas échéant 😉 .
Je me permet de revenir sur la question que j’ai posé, qui a pu paraître agressive : « mais pourquoi c’est static ? »
En effet, je m’interrogeai sur la nécessité d’utiliser des méthodes statiques dans les contrôleurs. Si je ne m’abuse, Play! est le seul framework web (tous langages confondus) à avoir choisi cette voie.
Si j’ai bien compris, Guillaume considère que les méthodes d’un contrôleur sont les points d’entrée d’une application, et sont static au même titre qu’une méthode « main ».
Du coup, on peut s’interroger sur la nécessité pour un contrôleur d’hériter de la classe « Controller », s’il n’est jamais instancié…
En fait, c’est une astuce technique qui permet de réaliser deux choses :
1) Marquer le contrôleur en temps que contrôleur, au même titre que l’annotation @Controller dans Spring
2) Fournir un accès direct aux méthodes statiques de la classe Controller, sans nécessiter pour cela d’utiliser un import statique.
Et il en est à priori de même pour les classes du modèle.
Avec ces méthodes statiques, Play! se démarque fortement des autres Frameworks RAD récents : Grails, symfony, Jax-RS, RoR (et d’autres ?) créent tous une nouvelle instance du contrôleur à chaque requête.
Cela permet notamment d’utiliser des attributs d’instance du contrôleur pour se faire injecter des informations de contexte sur la requête, ainsi que transmettre des données à la vue.
Par ailleurs, il semble qu’avec Play! il ne soit pas nécessaire d’annoter les entités JPA avec @Entity, ni de fournir de constructeur par défaut. J’ai oui dire que pour y parvenir, Play! utiliserait le compilateur Eclipse pour compiler et enrichir le code…
Quelqu’un a t’il des pistes à ce sujet ? Est-ce que cela ne signifie pas qu’il est impossible de compiler et packager une application Play! sans utiliser les commandes Play! ? Play! tournerait donc sur une JVM, mais ne serait pas du Java au sens stricte du terme (au même titre qu’Android) ?
N’hésitez pas à me pourfendre si je débite des imbécilités 😉 . Sous mes airs de râleur, j’apprécie la bouffée d’air frais qu’apporte ce framework. Je pense que Play! peut apporter au monde Java la même révolution que symfony au monde PHP.
Cette soirée a du être intéressante !
Quel était le ressenti général après avoir vu Rails et Play! ? Est ce que ça a redonné envie à Christian Blavier de retoucher au java ?
« si vous voulez vous faire plaisir avec du Java, que vos problèmes soient pour du Web ou une application lourde, testez Play! Framework. »
Comment tu fais un client lourd avec play?
Loïc
Hello Loic,
Non ca ne me donne pas spécialement envie de me remettre au Java (pour le web tout du moins) ni à Play (je ne m’y suis jamais mis).
Je suis loin de cracher sur Play, que je trouve excellent et même meilleur que Grails car plus léger et plus en rupture (ca ne tire pas spring, hibernate …). Mais je dois avouer que je trouve que Play est un « me too » de Rails avec quelques années de retard et du coup forcément une communauté moindre.
Du coup je cherche les raisons pour lesquelles on ferait du Play plutôt que du Rails … peut être pour ne pas changer de langage ? m’est avis qu’un geek motivé apprend un nouveau langage en 2 soirées. Peut être la compatibilité avec des serveurs d’app, mais bon les serveurs nginx et unicorn en rails boostent qd même pas mal.
En tout cas Play va surement apporter des killer features qui n’existent pas dans Rails (et c’est peut etre déjà le cas aujourd’hui), et dans ce cas là les 2 communautés auront le bénéfice d’une « émulation postive ». Mais pour l’instant je trouve que c’est encore Rails qui tire Play …
J’espère t’avoir répondu 😉
(et j’en profite pour remercier Nicolas de m’avoir offert une tribune au JUG !)
@Christian Je viens personnellement du monde java, et autant je m’intéresse à Groovy, à Grails et à Play!, voire à Scala, autant je sais que je n’irai pas voir Rails. Pour une raison simple: je reste dans le monde java, avec la possibilité d’appliquer ces technos à mes projets java. Dans le monde Rails, il faudrait que je reparte de zéro. Cela dit, bravo au créateur de ROR, qui est un précurseur, et à ceux qui s’en sont inspiré (sans copier bêtement) dans le monde java.
Le premier lien pour Zengularity est http://www.zengularity.fr/ et il semble être incorrect. La version en .com fonctionne correctement par contre.
@Bertrand : corrigé, merci
@Piwai Il est nécessaire d’annoter tes entités avec @Entity car Play! s’appuie sur JPA. La possibilité d’étendre JPASupport ou Model lorsque tu définis ton modèle permet de suivre le pattern ActiveRecord. Cela te donne les méthodes de finder comme findAll() qui sont en fait enrichies à la compilation par Play!. Il est vrai que tu dois utiliser son enrichisseur de code, car certains mécanismes font appels (comme pour Spring ou Hibernate) soit à des Proxies, soit à des classes instrumentées. Principe de l’AOP tout simplement. Le tout reste très souple, et par expérience n’est pas plus compliqué ou différent qu’un cglib.jar dans le path d’Hibernate.
@Christian merci pour ton retour!
@Piwaï
Bon y’a pas mal de chose dans ce que tu dis, je vais tenter de répondre point par point.
– « En effet, je m’interrogeai sur la nécessité d’utiliser des méthodes statiques dans les contrôleurs. Si je ne m’abuse, Play! est le seul framework web (tous langages confondus) à avoir choisi cette voie. »
>> Oui, la plupart des frameworks n’utilisent pas de méthodes statiques, car elle sont considéré comme « bad practise » par la plupart des dev Java. LE problème des méthode statiques, c’est l’impossibilité d’overider une méthode dans une classe fille. Si tu trouve une bonne raison d’utiliser de l’héritage dans les controllers (A part l’héritage de la classe Controller de play), fais moi signe, j’ai pas mal cherché, jamais trouvé ^^
– « Si j’ai bien compris, Guillaume considère que les méthodes d’un contrôleur sont les points d’entrée d’une application, et sont static au même titre qu’une méthode « main ».
>> Tu as bien compris 🙂
– « En fait, c’est une astuce technique qui permet de réaliser deux choses :
1) Marquer le contrôleur en temps que contrôleur, au même titre que l’annotation @Controller dans Spring »
>> C’est un peu plus qu’une astuce. Comme tu le sais, l’héritage marque une relation de type « est un » (cette formulation est une simplification du principe de Liskov). Puisque toutes les classes qui héritent de « Controller » sont des controller, l’utilisation de l’héritage est tout à fait correcte. Je trouve même ça plus élégant que des annotations qui sont « seulement » des métadonnées rattachées à ta classe. C’est pour cela que Play! te fournit une annotation « @WIth », qui permet de mutualiser du code entre des Controllers (utiliser l’héritage pour cela serait un défaut de conception).
– « 2) Fournir un accès direct aux méthodes statiques de la classe Controller, sans nécessiter pour cela d’utiliser un import statique. »
>> Effectivement, mais ce n’est qu’un effet de bord pratique.
– « Cela permet notamment d’utiliser des attributs d’instance du contrôleur pour se faire injecter des informations de contexte sur la requête, ainsi que transmettre des données à la vue. »
>> Oui, mais il n’y a pas d’injection de dépendances dans Play! (du moins par défaut. Il y’a un modules Spring, personnellement je ne vois pas l’intérêt dans ce contexte).
Les plupart des framework « web » en Java sont statefull, donc évidement, il est capital pour eux de pouvoir injecter des instances (les états entre autre) dans les controlleurs.
– « Par ailleurs, il semble qu’avec Play! il ne soit pas nécessaire d’annoter les entités JPA avec @Entity, ni de fournir de constructeur par défaut. J’ai oui dire que pour y parvenir, Play! utiliserait le compilateur Eclipse pour compiler et enrichir le code… »
>> Play! manipule le bytecode pour générer du « boilerplate code », comme les getters / setters, à diverses endroits. Ca te permet essentiellement d’alléger ton code, mais si tu veux ecrire les getters / setter toi même, ou réutiliser des Entités JPA existantes, tu peux 🙂
Le code compilé par Play! est du code Java « normal », qui tourne sur une JVM « normale » (pas comme Android donc), tu peux le décompiler pour voir le résultat final.
Voila, c’était un peu long, j’espere que ça répond à tes questions.
jto.
@Nicolas
Lors du JUG, tu as dit que tu utilisais le framework Play! pour faire du prototypage parce qu’il permettait des cycles de développement rapide. (Corriges moi si ma reformulation est inexacte.)
Par contre, j’ai cru comprendre que s’il fallait faire plus qu’un prototype alors ta préférence se porter sur une autre stack. Pourrais tu donner plus de details sur ton point de vue? Quel est le ‘sweet spot’ pour Play!? Dans quel cas, ta préférence porte sur une autre stack? Pourquoi?
@Bertrand oui en effet, pour monter des écrans sur un modèle JPA, en effet c’est ce que j’ai fais, surtout en l’absence de spécifications GUI cet été.
Par contre je n’ai pas dit que je changerai de stack. Play! est adapté pour réaliser des applications riches. J’ai expliqué que dans le cas où tes besoins sont de faire une application type client lourd et que tes équipes n’ont pas de compétences HTML/CSS/jQuery alors une solution basée sur JSF avec une librairie comme IceFaces ou RichFaces me semble plus adaptée pour répondre à ce besoin.
Mais clairement, je préfère une approche Web où l’interface client n’est pas un client lourd mais du Web. Après, et c’est la réalité du terrain, il n’est pas toujours possible de faire ce que l’on veut.
La vidéo à la fin de la présentation a montré un certain nombre de réalisations qui tournent avec Play! Framework. Cela allait de l’application de gestion client riche au site web, en passant par un portail. Comme vous l’avez vu, de belles références utilisent Play! aujourd’hui
Tu m’as convaincu mardi d’aller essayer Play!
Argh! Ruby n’est pas faiblement typé. Confondre dynamique et faible, ca me désole.
PHP est Javascript sont dynamiques et faiblement typés
Python et Ruby sont dynamiques et fortement typés.