Le Touilleur Express » Web 2.0

Play 2.0 announced at Devoxx 2011

Nicolas Martignole — Sat, 26 Nov 2011 13:29:07 +0000

Guillaume Bort and Sadek Drobi made two big announcements last Wednesday, 16th November at the Devoxx 2011 conference. First off, Play! 2.0 is available in beta form for download on the Play! Framework web site. Within hours, there were over 4,000 downloads (see Twitter here).
Secondly is that Play Framework is now the official web stack of the Typesafe products, Typesafe being the company created by Martin Odersky, creator of Scala. And last but not least, Guillaume Bort is joining the company’s Advisory Board, alongside James Gosling and Doug Lea.

Nice, hey?

But let’s back to the Devoxx presentation and what I thought of it. I’ll try to not be too enthusiastic, but this will be hard (as I am a Play Framework evangelist as part of my daily work).

Sadek Drobi is Zenexity’s CTO. Guillaume Bort is the co-founder of the company, and the original author of Play! Framework. As Sadek explained, Play! was born because of internals needs for their company, as a secret weapon to rapidly develop Java applications. The framework has been open-source as of the end of 2008. But right from the beginning, it’s was a framework designed for « real-life projects » for « real-life customers ». Not as a project you use to solve non-existant problems.

(Sadek with its hat and Guillaume)

I remember when Play! Framework was presented at a BOF at Devoxx 2009. 2 years later, there’s 3 conferences at Devoxx and one BOF. I’m looking at Devoxx 2011′s schedule, I don’t see any other web framework that had such exposure this week. This makes some of my friends cringe, but it definitely shows the interest the community has for this framework.

Why Play 2.0 ?

Since the beginning, Zenexity worked closely with the community. Play 1.x is now a very popular web framework, being simple and productive. However, adding functionalities is like creating a mega sandwich (or burger… or whatever) : that is, it becomes less maintainable and harder to patch. Plus, there’s a lot of “magic” going on in the core of Play 1.x (Maybe a little too much).

Second point is that meanwhile, the Web is evolving. People, especially in the Java community, are discovering a new world where a stateful approach might not be the only way to build web applications. Sadek and Guillaume say that we can really feel that architectures are changing, and this will have an impact on web frameworks. The very first Web frameworks were based on a static page approach. A single page generated by Perl, PHP or simple Java techniques. And this is still OK… if your content is static.

Web architectures on the server side needed to adapt to be able to work asynchronously with web clients. For instance, Ajax and related techniques like partial page refreshes gave birth to great web applications such as GMail. From a static page view, we moved to a dynamic approach on the server. Web frameworks were proud of this… especially JSF folks. One needs to understand that when usages changes, all web frameworks are impacted. Some are good for AJAX, some suck… I won’t give any names, but you see what I mean.

Today in 2011, the new challenge is easy web service integration and asynchronous processing. On a lot of web applications, you have to be able to link and reuse APIs such as Facebook API, Twitter OAuth, Google OpenID, or maybe your company SSO system that cost a tank… We know that to build a modern web application, the web framework has to be able to glue all these services together. And it has to be able to handle huge amounts of data, and the huge amount of things that can go wrong. Maybe tomorrow, a really good Web Developer will be the person that has a strong knowledge on Web APIs (OAuth, Github API, OpenID), and that is able to create value-added services from these external APIs.

From a technical point of view, Sadek explains that the Java Servlet API is very limited. We hope that Java EE 7 will propose a more modern approach. Java Servlet is just too… low-level. One important issue is that it’s impossible to split a task and configure threads, memory and CPU in a Web application. If you visit a page, you go through a Servlet. If you upload a file, another Servlet. Wouldn’t it be interesting to route the content in your application (and not in a crappy “web.xml”) and really focus on the business part ? It’s not normal that your application’s home page can blow up if someone else starts uploading a large file in another part of your application.

Web frameworks have been created to be the central point of the architecture, whereas Sadek and Guillaume think that being Client-focused (as in, clients of your application) and having an adaptive server are more important.

Basically, “server” should be written with a lower-case “s” and “Client” with an upper-case “C”.

What is also important to keep in mind is that the amount of data and the flow of data between Clients (browsers, other web apps, your iPhone…) and the server are evolving at a very fast pace. It’s not at all easy to write concurrent code, and this was something that Play 1.x was not designed for. Play 2.0 is not here as an evolution or replacement of Play 1.x. It’s here because we’re moving forward, baby. We have to adapt and be ready for these new kinds of applications we haven’t thought of before. You see what I mean ?

Sadek Drobi goes on to say that when a Java developer creates an application for the Web, he tends to have a sort of “automatic behaviours”. The first one, regarding the datastore, is to pick an ORM. And this is stupid. What for ? Because you can forget SQL ? ORM are a perfect tool… when you need it. And no, you don’t need an ORM every time, every where.

Take a look at your application. First, do you use honestly use advanced relational mapping in the database ? Yes ? And is it really useful ? How much time did you lose on Play 1.x with @OneToMany, @ManyToOne, @MaybeOneOrTwoToTooMany annotations ?

On the client side, especially in the browser, we have also new web technologies that ease the web app development. Personally (and I usually blog about this in French), I think that if you (yes, you there in the back) don’t want to learn HTML/CSS/HTTP, then you are in serious trouble. OK, let me be honest : you suck. Either learn basic web stuff or go back to your Cobol stuff.

Now, back to the presentation. So we have these new tools such as Sass, CoffeeScript, Less or jQuery. Guillaume explains that it would be also interesting to integrate these tools in Play 2.0 so that you get compilation and validation for CoffeeScript or Sass, for instance.

In a sense, Play 2.0 was born because they (Sadek and Guillaume) wanted to create not a v2 of Play, but a v2011 version of it. Something that is more mature, less magic, more type-safe, more solid. Something that is able to handle all the new use cases they talked about.

This is important point : Play 2.0 is more of a whole new framework that just an evolution of Play 1.x.

When we explain what is Play! Framework to someone for the very first time, especially to Java developers, we present it as a full-stack framework. You write java code in your editor, you switch to your web browser, hit refresh, and it works.

Java developer : No more console and maven hell. Play 1.x relies on Eclipse’s IDT compiler, the one we’ve been using for years : it just works.

Java developer : No more crappy logs in a console Play 1.x reports errors in the web browser. If there’s a compilation error, well, you see it in the browser. Forget about looking at logs files like a teenager with an adult magazine : no more logs.

What is also important is that Play 1.x is not a stateless web framework, but a « framework sans état conversationnel du côté serveur » wich translate into English as « a framework that respects web standard, has no conversation, thus no state on the server, as HTTP is from the beginning… »

The code editor and a web browser. That is all you need to work. Even better, you can use VI/Emacs/TextMate or any basic text editor, since all the work is done by Play! Framework. However I recommend IntelliJ for its good web support (JS/HTML/CSS/Java/bla bla bla).

Guillaume worked really hard to keep exactly the same spirit in Play 2.0 : productive, simple, no logs for dummies, no maven/gradle stuff, no xml… just being productive (and having fun, but that is another story).

Play 2.0 is a web framework that is able to compile, deploy, download dependencies, launch asynchronous jobs, runs tests, send emails and even (but we’re not 100% sure about this feature) prepare a good coffee if you need it.

Démonstration

Guillaume did a good demonstration of Play 2.0. Firstly : no more Python for the tooling and no more Groovy for the templating (compared to Play 1.x). Play 2.0’s engine is Scala. But hold on… don’t run away… no, you won’t have to learn Scala. You can write your code in Java or Scala, Play doesn’t care. The template language is Scala. But it’s very simple and there’s only a few tags to learn. It took me 1 day to understand how it works. And I’m happy to be able to do advanced stuff with Scala, when needed, in the view.

For Java, Guillaume removed Hibernate and took Avajé EBean. It’s a lightweight stateless ORM, that is less powerful than Hibernate. But it’s perfect for Play, it’s JPA compatible if I’m remember correctly. For the Scala part, Sadek implemented a simple SQL engine called Anorm. I started to use Anorm in May, spent some time with Sadek in August to fix some bugs, and I like it. Simple, easy to learn, not too much « scaletist » and just fine for a Scala beginner like me. You can also use some other Scala/SQL libraries such as ScalaQuery : it’s very easy to flip from one lib to another.

The very first characteristic of Play 2.0 is that it’s based on SBT, Simple Build Tool. As you can imagine, SBT is now the one in charge of dependencies, incremental compilation, tests, packaging, documentation and maybe (but not sure about this one) preparing a good coffee. It’s even easy to launch SBT and import Play commands into SBT. You also get tooling support for Eclipse and IntelliJ with SBT.

The template engine is new in Play 2.0. This is maybe the biggest difference between the 2 versions of the framework. I know that one of the Play core developer is working on porting the Groovy engine to Play 2.0. It will work, but does it makes sense ? Not sure about that.

Templates are HTML files with very little Scala code in them. Everything is strongly typed. Less errors, more validation at compile time, and maybe fewer tests since there’s less dynamic in the code. Each page declares the list of parameters, everything is transformed to Scala then compiled to byte-code. In terms of performance, the new template engine is 15 times faster than the previous one.

One important point : in order to write a view page with Play 2.0’s new template language, you don’t have to be a Scala Jedi Master. The syntax is easy to learn, and you have access to the power of Scala when needed. I also think that this is a good way to discover and learn Scala, if you only use Java for the controller side.

I had a really nice use-case recently, where Scala was really powerful. I wrote a Contact application. There’s a web page with a list of people ordered by last name. Here is an extract of one of my templates for Play 2.0 :

Play 2.0 in details

Sadek and Guillaume then go on and explain what is really new in Play 2.0. First, existing solutions in the Java world suffers from a very low-level approach. Let’s say you want to implement a file upload functionality. With the traditional approach, based on java.io.InputStream, it’s very complex to correctly write an application that does not block on I/O. The read() method in InputStream reads one byte after another. This is OK if the server is able to handle the reception of the byte stream. However, it tends to create resource deadlocks, where the server hangs and does not respond to incoming requests anymore. Sadek, who is also a very good Haskell developer, explains that they decided to adapt the Enumerator and Iteratee pattern in Play 2.0

Play 2.0 has a completely new approach, it applies inversion of control on the way the controller and the client exchange information. What is really awesome is the way it handles an incoming request. First, in the connection layer, Play 2.0 is like Play 1.x : a single thread listens for and dispatches any incoming requests (just like Node.JS, for instance). The request is then dispatched to either a limited pool of workers. If you annotate a part of your code in the controller with the @Asynchronous annotation, Play is then able to suspend your request, thus freeing one thread, while an asynchronous activity does something. Enumerator and Iteratee is a nice pattern where the asynchronous task tells the Enumerator when it completes its work, and that it can resume. It is much more efficient than the classical Future + Pooling approach we had in Play 1.x. And this is also why you now understand that Play 2.0 doesn’t care about the Servlet API, it just wouldn’t be able to work like this.

An Enumerator sends data to an Iteratee. The Iteratee executes a function, does something, and sends a signal back to the Enumerator with a status. See also the Continuation passing style » that is explained in Haskell documentation.

Well, you may say : why is this interesting ? Why should I care ? Well my friend, now you can start to write asynchronous web servers « à la Node.JS » (this is French) but with Scala or Java. Play 2.0 is much more functional. The code is easier to read, it’s also easy to split up long processing operations to speed-up your server.

To orchestrate everything, Guillaume and Sadek decided to use Akka. It’s a very powerful and simple Actor-based framework. I wrote an application for a startup, where we had to post-process uploaded images and generate PDFs : Akka is great. The code is easy to test, there’s no middleware stuff, ant it’s simple and very easy to develop in.

Akka is a powerful tool that lets you write asynchronous code very easily in your application. What I particularly like about it is that the thread pool and all the general fine-tuning is managed outside of your code. If there’s a new framework you need to look at, definitely check out Akka. Great tool.

Here is a sample from Play 2.0 that Guillaume showed at Devoxx. The search function receive a keyword. The AsyncResult is interesting because it tells Play to handle the code as an asynchronous function. While the search operation is done, the server frees up the resource and let the system handles another request. The Iteratee pattern is then used : when the search result is available, the html.results template is executed to generate the HTML response. The double-bang (!!) means : send the « keywords » to the searchInternet’s Actor. As you can see, the searchInternet could be anything, there’s no functional code here.

def search(keywords: String) = Action {
	 AsyncResult {
		(searchInternet !! keywords).map{
			found => Ok(html.results(found))
		}
	}
}

Sadek talked also a little about the data layer in Play 2.0 : either a relational database or NoSQL databases like MongoDB, etc. Play 2.0 does not try to hide the fact that there’s a data layer in your application. If you want to use Neo4J or PostgresSQL, well you can.

In Play 2.0, Guillaume decided to drop Hibernate 3 in favour of EBean. Why ? Well, Hibernate is a great tool and all, but it’s just too powerful for what we usually need for Play. It was really hard to set up the asynchronous part with Hibernate sessions. On the other hand, the java community really wants an ORM in Play for the Java part. EBean is simple to use, and offers good compatibility. There’s also some Spring 3 in Play 2.0 for the Bean binding and JSR-303. So EBean is simpler and better-adapted to Play 2.0.

For Scala, Sadek wrote Anorm (An Not ORM). Based on Scala’s complex parser, it’s a very simple parser technology that removes the JDBC boilerplate and offers a nice match/case engine. But if you don’t like Anorm, you can use ScalaQuery or whatever your favorite Scala technology is.

Guillaume also demonstrated that Play 2.0 is bundled with support for client-side tools such as CoffeeScript, Less or SASS. Play is a full stack framework. So it will compiles your CoffeeScript to Javascript. And last but not least, it is also capable of reporting errors in a CoffeeScript page for instance. This is just great.

With regards to “Cloud computing” support, Play 2.0 works on Heroku and soon, will also work on CloudBees.

Thanks to Akka, it will also be easy to distribute a work on multiple Play Servers. For instance, it will be possible to have a Play server as some sort of Front controller, that dispatches to another Play Server the « Image resize » operation (for example), and to another server the « Generate a PDF »… I don’t know if you realize how powerful this is. It will be easy to split up and create a flexible architecture. Something Java J2EE tried to sell 8 years ago.

The actual Play 2.0 core is not very complex. I spent a day with Guillaume and was able to understand how it works. In fact, there’s x4 less code. It’s thus easier to find your way around in your code.

On the performance side, Play 2.0 is 2 to 3 times faster than Play 1.x. On a MacBook Pro with an i7 processor with 8 cores, a simple Apache bench command shows that Play 2.0 manages just fine 40 000 requests per seconds. The network stack is JBoss Netty, one of the most powerful stacks for Asynchronous NIO in Java.

On the memory footprint side, their tests show that after a full GC, the heap is back to 2 MB…

Personally, if I have a negative feedback to give, it’s that the compilation is much slower with Scala. You lose the very quick turn-around/compilation experience we had with Play 1.x. Yes, it’s slower. Scala being more complex, it takes more time to generate the code and compile it.

Type safe

Play 2.0 also brings strong typing to the HTML template part. The first reflex is : damn, I prefer the groovy way. But bit by bit, I moved to Scala and started to really appreciate the type safe template engine.

The « routes » file is also compiled. Everything is compiled in Play 2.0. This is less error-prone. If you update a function in your controller and you forget to rename it in the “routes” file, Play will properly report the error. No more « 404 What the hell » exception.

To wrap things up, Guillaume did a nice presentation of the 3 applications they wrote in September. You have a complete CRUD application, an advanced HelloWorld and a complete application with authentication. I was happy to see that Guillaume took into consideration a suggestion I had back in September : don’t bother to give a stupid helloworld example. Give me a real application so that I can start to learn the framework, see how to set-up authentication, start to read some nice code… And please : no pet-store and no stupid hotel booking application.

By the way, dear reader, did you know that the Pet-store was actually a joke ? The idea to create a Petstore was suggested by a guy at 4:00 am after too many beers at SUN. Stop and think about this for a minute : would you really buy a bird on the Internet and have it shipped in a little box ? Come on… You can’t be serious… But apparently nobody was really surprised and we still believe that we can buy birds with a J2EE application… Ah ah ah.

What you won’t like in Play 2.0

Now my friends, let’s me be honest : Play 2.0 is not for dummies. A lot of people want to port their code and every day, they post a bunch of questions about migration patches and yada yada yada on the mailing-list. The question is : do you really need to migrate ? Do you really need to use Play 2.0 ? Maybe ya do, maybe ya don’t.

The templates are different, but it’s not too hard to port your code. The controller side is completely new. You can write it in Java or Scala. So don’t be scared : you don’t have to be a Scala developer (yet).

Play 2.0 was created to solve new issues and new architecture patterns. It’s more like a cousin than the little brother of Play 1.x.

However, and please read this carefully : Play 1.x is a community project and will be maintained by its core contributors (Guillaume Bort, Nicolas Leroux from Lunatech, Peter Hausel, Morten Kjetland, Erwan Loisant, Peter Hilton…). Zenexity has a lot of customers with live apps in production using Play 1.x. So Play 1.x is here to stay and is still a very interesting solution to look at.

If you want to learn Scala, Play 2.0 is really a great tool. I started to learn Scala in May with Play 1.x and play-scala, and it took me one month to start, maybe 2 months to really understand Scala and appreciate the language. As a Java developer with no functional background, I really like this language. Less verbose and not that hard to learn. Don’t be afraid of the fact that there’s are some hippie-guru-functional-heretics that talk about Scala like it’s their girlfriend. If you’re just a java developer, trust me : it’s easy to learn and to work with. Don’t give a shit about people that try to look smart with « Monad or higher-order function ». Soon you will be writing more Scala code than those pseudo-evangelists ever have…

One important point is that Play 2.0 is more like a new framework. If you want to write rock-solid applications and you need asynchronous/flexibility, then Play 2.0 is your guy.

I talked with Guillaume and at one point, I suggested that they change its name of the Framework to Play² ([plèy square]).

But we will keep Play 2.0, that’s already a big evolution.

Other interesting and great resources:
- Play 2.0 official web site
- Another great article by Matt Raible. I hope to see him in Paris for Devoxx France 2012
- James Ward also wrote great articles about Scala, Play and Heroku
- Play! Framework also has a Twitter account : @PlayFramework

This article was reviewed by Roland MALAPRADE (@rmalaprade).

Nicolas Martignole is a freelance developer. He lives in France, in Paris. He is a Play evangelist. He created the eXpress-Board, a job board for enthusiastic developers, with Play 1.2. He is also a member of the Paris JUG team and he’s one of the 4 crazy geeks that decided to organize Devoxx France, a conference for developers created by freelance developers, from the 18th to the 20th of April 2012. You can follow him on Twitter @nmartignole.

Original article in French here.

Comment tester son site sur les différentes versions d’Internet Explorer

Nicolas Martignole — Thu, 03 Nov 2011 08:06:08 +0000

Je ne sais pas pour vous, mais moi Windows j’ai dit bye-bye en 2008 pour prendre un Mac. Alors on peut dire ce que l’on veut d’Apple, râler très fort en disant que c’est cher, mais il y a un truc qui échappe encore au monde de Windows : ça marche.

En même temps on a un vrai métier « dans la vraie vie » comme disent les gens. Or dans ma vraie vie de développeur indépendant, je code des sites Internet avec Play! Framework pour des clients. Et les sites de mes clients doivent fonctionner sur le navigateur de Microsoft, à savoir Microsoft Internet Explorer. La question aujourd’hui, cher public, c’est comment tester facilement que le fruit de votre travail fonctionne sur IE7, IE8 et IE9 ? Et bien voici la réponse : Virtual Box et des VMs, un script intelligent et quelques heures de patience.

Je commence par la fin, pour montrer à la salle qu’il n’y a aucuns trucages :

Le site Artstechnica montre dans cet article que pour la première fois, Internet Explorer est passé sous la barre des 50% des navigateurs utilisés dans le monde, en octobre 2011. Bref si IE6 est presque mort, il faut bien voir qu’IE8 est actuellement le navigateur le plus utilisé dans le monde.

Alors voyons comment configurer des machines virtuelles rapidement avec IE7, IE8 et IE9. Pour IE7 nous allons utiliser Windows Vista. Et pour IE8/IE9 nous prendrons Windows 7 Ultimate Edition. Ce qui suit fonctionne pour Mac OS X et pour Linux.

Virtual Box
Commencez par installer Virtualbox, une machine virtuelle gratuite et géniale, développée par SUN Microsystems et qui appartient maintenant à Oracle. Sur Mac OS X avec un processeur Intel, ceci vous permet d’avoir un Windows fonctionnel et qui tourne parfaitement.

Les machines virtuelles Microsoft
Microsoft propose des machines virtuelles pour les développeurs Webs, afin de tester leurs sites webs facilement sur les différents navigateurs depuis août dernier. Ces images sont même patchées avec les dernières corrections de sécurité. Cependant vous ne pourrez pas activer l’image virtuelle. Ce ne sera donc pas une installation de Windows sur laquelle vous pourrez installer d’autres logiciels. Tous les 30 jours il faudra revenir à l’image de départ, mais je vais vous expliquer cela plus loin.

In order to help web designers and web developers test their websites in older versions of Internet Explorer, we’ve provided the following VHD with Windows set up with the specified version of Internet Explorer. The images are patched with the latest security updates and are otherwise clean installs of the operating system with very few modifications.

This download page contains different VPC images, depending on what you want to test. These images are specifically designed to run on Microsoft Virtual PC, and may or may not work in other hosting environments.

Due to the size of the Windows 7 and Windows Vista VHDs, it is split across several files, you’ll need to download all files for that version of the Internet Explorer and uncompress them to the same directory to unpack the VHD file.

The password to login to all of these images is Password1 and the username will be present when you first login.

*Note: You may be required to activate the OS as the product key has been deactivated. This is the expected behavior. The VHDs will not pass genuine validation. Immediately after you start the Windows 7 or Windows Vista images they will request to be activated. You can cancel the request and it will login to the desktop. You can activate up to two “rearms” (type slmgr –rearm at the command prompt) which will extend the trial for another 30 days each time OR simply shutdown the VPC image and discard the changes you’ve made from undo disks to reset the image back to its initial state. By doing either of these methods, you can technically have a base image which never expires although you will never be able to permanently save any changes on these images for longer than 90 days.

Le nom d’utilisateur sera Admin et le mot de passe par défaut est Password1.

Je veux un script
Je ne sais pas pour vous, mais moi je ne me vois pas télécharger chacune des VMs et ensuite configurer pas à pas les installations. En cherchant un peu sur Github, j’ai trouvé un script développé par Greg Thornton qui marche super bien sur Mac OS X Lion. Allez voir https://github.com/xdissent/ievms.

Pour lancer le téléchargement et l’installation des VMs, pour peu que Virtual Box soit déjà installé, comptez 3 à 4 heures avec la commande suivante :

curl -s https://raw.github.com/xdissent/ievms/master/ievms.sh | bash

Voilà, vous aurez ensuite 3 VMs sur VirtualBox configurées avec IE7, IE8 et IE9.

Oui mais le numéro de série ?
Pas besoin de numéro de série. Il suffit de ne pas activer la version de Windows, et de reprendre à chaque fois l’image de base sans sauvegarder sur VirtualBox. Une autre possibilité plus compliquée est expliquée sur le site de Microsoft.

Au final, cela vous donne un moyen simple et rapide de tester avec IE7, IE8 et IE9 votre site Internet.

D’autres manières de tester

Via Twitter (@nmartignole) j’ai eu d’autres suggestions d’outils et de liens intéressants. Voici ce que j’ai reçu :

- http://www.browserstack.com est une solution dans le cloud qui permet aussi de tester un site en local sur votre machine, via une Applet Java. Vous pouvez tester le service gratuitement 60mn, sinon c’est payant. Outil proposé par @alanzirek.

- SauceOnDemand permet de tester un site via des VMs hostées dans le Cloud. Intéressant, il est possible de faire tourner des tests Selenium afin de vous notifier lorsqu’une des versions pour un navigateur donné est cassée. Merci @fcamblor du BordeauxJUG pour l’info.

[Update]
Après plusieurs essais, la solution la plus pratique est Browserstack. Cet outil vous permet de tester via votre navigateur puis des machines virtuelles, l’ensemble des navigateurs du marché. A découvrir d’urgence.

Scala et Play! Framework

Nicolas Martignole — Mon, 06 Jun 2011 08:48:41 +0000

La conférence ScalaDays 2011 s’est déroulée la semaine dernière à Stanford, au sud de San Francisco. Guillaume Bort et Sadek Grobi étaient là-bas pour présenter la dernière version de l’approche Scala proposée par Play! Framework. Play! Scala permet d’utiliser Scala tout en conservant l’approche simple et puissante de Play! Framework. Je ne présente plus Play! Framework, car avec 260 000 téléchargements à ce jour on ne parle plus d’un épiphénomène, mais bien d’un outil de plus en plus populaire.

Après avoir installé Play! Framework v1.2.2RC1, l’installation du module s’effectue en quelques instants avec la commande « play install », qui permet de télécharger et de configurer les modules complémentaires de Play!

$ play install scala-0.9.1
$ play new myScalaWebApp --with scala
$ play run myScalaWebApp

Un moteur de template plus simple

Première différence avec la version Java, le moteur de template. Tout en conservant le nom des tags de la version actuelle, la nouvelle version Scala propose un moteur de template ultra-simple. L’idée est empruntée à Razor, le nouveau système de templating que l’on retrouve dans la toute dernière version du framework web de Microsoft. L’idée ? Au lieu d’encadrer avec le principe d’une balise ouvrante/fermante le code dynamique, il suffit de placer directement les tags, un peu finalement comme des Macros :

La version avec le moteur Groovy :


#{list products, as:'p'}
 ${p.name} (${p.price})
#{/list}

La nouvelle version avec le nouveau moteur Scala :


@for(p <- products) {
    @p.name ($@p.price)
}

Ce nouveau moteur de template permet d’écrire le code de la partie vue, de manière plus fluide et plus simple, comme une suite de macro appliquée dans un template.

Chaque template dans cette nouvelle version est une fonction. Il devient donc nécessaire de préciser les paramètres en entrée de chaque template, ce qui diffère de l’approche actuelle Java+Groovy. En quelques sortes, vos templates de page dans cette version deviennent des templates typés fortement, les paramètres attendus doivent être explicitement déclarés.

Il devient aussi facile de faire du pattern matching. Remarquez aussi le mélange des balises HTML, traitées comme du XML par Scala, et la partie purement dynamique :

@connected match {

    case Admin(name) => {
        Connected as admin (@name)
    }

    case User(name) => {
        Connected as @name
    }

}

Les Tags dans la version Groovy/Java sont des macros qui permettent de réutiliser à différents endroits, des bouts de code. Dans la version Scala, une nouveauté apparait implicitement : il devient possible de passer des paramètres à un Tag, mais il devient aussi possible de construire ce type d’appel :

Définissons d’abord un tag notice « views/tags/notice.scala.html »
Ce template prend 2 paramètres : un paramètre level de type String, dont la valeur par défaut sera error, ainsi qu’un bloc html :

@(level:String = "error")(body: (String) => Html)

@level match {

    case "success" => {
        
            @body("green")
        
    }

    case "warning" => {
        
            @body("orange")
        
    }

    case "error" => {
        
            @body("red")
        
    }

}

Si level vaut « error », nous affichons un bloc span avec pour style css « error », puis nous rappelons le template body en passant en paramètre la valeur « red ».
Voici comment l’utiliser dans une page :

@import views.tags.html._

@notice("error") { color =>
    Oops, something is wrong
}

Dans notre page principale, @notice est notre template définit comme un tag. Nous passons « error ». Cette fonction s’exécute et appelle ensuite body, en passant un paramètre de type String. Dans la page principale, je déclare une fonction qui prend un paramètre color, et qui retourne alors notre message d’erreur, avec la couleur red…

Cet exemple illustre simplement un nouveau principe disponible uniquement grâce à cette approche, où comme dirait quelqu’un l’an dernier, « tout est objet et fonction en même temps« .

Cette approche a aussi une conséquence sur la façon d’écrire et d’architecturer son application. Je pense qu’elle demandera vraiment une remise en question de notre habitude très « MVC », sagement appliquée ces 10 dernières années. Ne partez pas, on en reparle à la fin.

Anorm, un « Another NOT ORM » framework

Parlons un petit peu de JPA et de son utiliastion avec Scala auparavant. Techniquement, en utilisant l’implémentation JPA d’Hibernate, cela fonctionne. Je crois que Scala 2.8 ne supporte pas les annotations imbriquées comme @JoinTable. Il serait par exemple impossible d’écrire ce code en Scala :

// note : c'est du Java mon ami
 @JoinTable(
        name="CUST_PHONE",
        joinColumns=
            @JoinColumn(name="CUST_ID", referencedColumnName="ID"),
        inverseJoinColumns=
            @JoinColumn(name="PHONE_ID", referencedColumnName="ID")
    )

Deuxième question sur le concept de l’ORM et son utilisation avec Scala. Si je cherche à privilégier une approche immutable de mon domaine de données, est-ce que l’ORM reste intéressant ? Si je souhaite avoir un domaine objet pour travailler, et utiliser la base de données relationnelles comme mode de persistence, l’approche JPA+Java est parfaite. Si par contre je décide que mon domaine est avant tout en base, que le coeur de mon application travaille sur une base de données (relationnelle ou non) alors l’ORM perd de son intérêt.

Pour bien comprendre ce que j’essaye de dire, essayez d’imaginer où doit se situer la « golden source » de votre donnée. Est-ce que c’est en mémoire, dans votre serveur d’application ? Ou est-ce que votre donnée de référence doit être dans votre base de données ? Cela semble trivial, mais lorsque l’on prend l’approche sans état conversationnel, il devient plus simple de ne PAS utiliser d’ORM.

La question devient alors : quel est le meilleur DSL pour accéder à une base de données ? Les développeurs de Play! Framework se sont creusés la tête, et Sadek Grobi a proposé une approche très simple et très puissante basée sur SQL.

Anorm (Anorm is Not a Object Relational Mapper) est un nouveau moteur très puissant qui tire partie de la richesse de Scala. Je retrouve un des points forts de Play! Framework, que l’on pourrait résumer par l’approche « tu es un p$$tain de développeur oui ou merde ? » . Or comme chaque développeur, tu as fais du SQL. Cela tombe bien, Anorm ne propose pas un nouveau DSL, il se base sur SQL. Oui tu m’as bien entendu, tu vas faire du bon vieux SQL qui marche depuis la nuit des temps. Et c’est pareil pour la couche web : tu ne vas pas décrire ta page web en Java, tu vas la coder en HTML. Tu sais ce que c’est le HTML non ?
Bref le retour à la source.

Cela s’accorde bien lorsqu’en face vous cherchez (et vous trouvez) des problèmes inhérents au mélange du monde relationnel et du monde objet. Prenez par exemple une relation de type @OneToMany de type lazy. Disons une liste de Pays et de Villes, un Pays pouvant contenir plusieurs Villes. Avec une relation de type @OneToMany, si vous souhaitez construire votre ensemble Pays/Villes, vous vous retrouvez par défaut avec le problème du N+1 SELECT. Il faut alors passer par un left join dans vos @NamedQuery. Vas-y que je te rappelle que tu travailles sur un modèle relationnel, dans ton beau modèle tout objet… (voir aussi Hibernate Performance Fetching).

Ici il n’est plus question d’abstraction, puisque vous travaillez directement sur votre base de données. Un point faible de cette approche semble être la dépendance du code par rapport au schéma. Si je décide que ma base de données est la source de référence, il faudra donc que je corrige mes requêtes si le schéma change. Mais dans l’approche JPA, lorsque mon domaine change, je dois aussi reprendre le code de mon service. Bref il y a toujours quelque chose à reprendre si votre Domaine (avec un grand D) évolue. Que ce soit dans le monde objet, ou dans le monde relationnel. Comprenez une chose : soit vous ignorez la base de données, soit vous en faite une amie.

Voici un exemple tiré de la documentation de l’API, qui montre comment récupérer une liste de pays, puis ensuite construire une nouvelle collection pour la vue :

// Create an SQL query
val selectCountries = SQL("Select * from Country")

// Transform the resulting Stream[Row] as a List[(String,String)]
val countries = selectCountries().map(row =>
    row[String]("code") -> row[String]("name")
).toList

Un autre exemple tiré de l’exemple Yabe :

val postsWithAuthor:List[(Post~User)] =
    SQL(
        """
            select * from Post p join User u on
            p.author_id = u.id order by p.postedAt desc
        """
    ).as( Post ~< User * )

Vous pouvez aussi l'écrire de cette façon dans la class Post :

def allWithAuthor:List[(Post,User)] =
    SQL(
        """
            select * from Post p join User u on p.author_id = u.id
            order by p.postedAt desc
        """
    ).as( Post ~< User ^^ flatten * )

Puis vous pourrez vous en servir dans une action dans votre controller de cette façon :

import models._

object Application extends Controller {

def index = {
    val allPosts = Post.allWithAuthor
    html.index(
        front = allPosts.headOption,
        older = allPosts.drop(1)
    )
}

}

headOption récupère le post le plus récent pour l’afficher complètement, older est l’ensemble des Posts moins le post le plus récent que nous venons d’afficher. Pratique non ?

Nul doute qu’il sera nécessaire de bien comprendre et de challenger cette approche. Mais elle vient remettre en question le mouvement « tout-orm » du monde Java, avec une petite brise fraiche qui plaît bien.

Du code plus lisible et bien typé

L’approche Scala pour Play! est intéressante car elle rend le code plus simple et plus facile à lire. Finalement, dans l’esprit nous pouvons voir une requête Web comme l’enchainement de différentes fonctions de transformation. Soit un état de départ donné n, si j’applique ma fonction f(n) sur mon ensemble, je dois retrouver toujours le même résultat. C’est exactement la définition même d’une URI : pour un espace d’adressage donné, je retourne un ensemble de méta-données. Scala avec son approche fonctionnelle est particulièrement intéressant pour construire une application web.

C’est vraiment un pas en avant vers une architecture où le client tient les informations d’état (appelez cela la session si vous voulez) et où le serveur est complètement sans état conversationnel. Il peut cependant très bien avoir un cache de données, mais il n’y a plus la notion de session utilisateur du côté serveur. Il y a la notion de session serveur du côté client. Que ce soit dès aujourd’hui avec un Cookie, ou demain avec HTML5, c’est une approche assez différente. Je n’ai pas dit mieux ou moins bien, j’ai bien dit : une approche différente.

Prévu dans la version 1.0

La version 0.9.1 est sortie juste à temps pour Scala Days. La version 1.0 apportera d’autres concepts dans la roadmap :

Before completing the 1.0 version of Play Scala we need to work on the following aspects:

- Rework the MVC layer to make it easier to compose Actions.
- Add proper JSON support — Probably using Lift JSON
- Provide an API to work with the Play async features.
- Integrate Akka actors
- Provide a type safe way to express routes directly in Scala
So probably move to Scala 2.9.

Conclusion

Intéressant et très poussé, Play! Scala offre un moteur Web plus simple à utiliser que Lift pour la plateforme Scala. A titre personnel, je vais travailler dessus pendant 2 mois. Je vous ferai part de ce qui m’a plu et ce que j’ai trouvé délicat. Allez y jeter un oeil par curiosité, c’est facile à tester, le tutorial Yabe permet de se lancer rapidement, cela ne vous demandera que quelques heures.

A suivre donc.

Références :
Le site de Play! Framework : http://scala.playframework.org/
Le souci des requêtes N+1 sur StackOverflow
Guide des stratégies de chargement d’Hibernate

Envoi de courrier électronique en masse

Nicolas Martignole — Wed, 01 Jun 2011 15:49:17 +0000

Une goutte de sueur froide dans le café

Petite sueur froide ce matin. Notre but est de calculer au plus juste les différents prix pour les annonceurs pour l’eXpress-Board. Pour cela, nous avons besoin de quelques statistiques. Il est 08h32, je commence à coder quelques lignes. Quelques minutes plus tard, j’ai une belle page, avec de beaux chiffres… et de nouveaux soucis que je viens de m’ajouter.

Il y a eu 456 « UserRequest » depuis que j’ai lancé ce système en septembre 2010. Il s’agit des demandes de mise en relation de la part des recruteurs, à l’intention des candidats. Sur ce nombre, il y a eu 164 demandes acceptées (35.3%), 113 demandes refusées (24.72%) et surtout… petite sueur froide… 180 demandes en attente (39.8%). Comment se fait-il que les candidats ne donnent pas suite ? Ok dans le lot, il y a ceux qui ne répondent pas tout de suite. Mais c’est un chiffre un peu trop important.

Le souci n’est pas lié uniquement aux candidats qui ne répondent pas. Il est aussi lié à l’infrastructure technique que j’utilise. Les emails aujourd’hui sont envoyés via la passerelle SMTP de Gandi, qui est aussi le hosteur du domaine express-board.fr. Or cette passerelle limite l’envoi par heure, afin d’éviter de se retrouver marqué comme « spammeur ». Bref il est possible qu’un certain nombre de mes emails… ne soient pas envoyés correctement.

La goutte est tombée dans le café lorsque j’ai retrouvé un gros paquet d’erreurs sur PlayApps, lors de l’envoi d’emails à toi, cher Candidat. Gandi et sa passerelle SMTP me tappe, pour surcharger l’utilisation du serveur SMTP… Allez, on va faire un peu de DNS et de configuration ce matin…

La configuration des serveurs SMTP pour les nuls

Il est facile de configurer un serveur SMTP, mais bien plus compliqué de le rendre « présentable » pour les passerelles de filtrage. En fait, sans expérience en marketing web, sans connaisance des termes white-list, DKIM ou SPF, et bien tu ne vas pas très loin. Allez, je suis presque sûr que tu ne connais pas DKIM… fait pas ton timide.

SMTP

Petit rappel : SMTP (Simple Mail Transfer Protocol) est un protocole vieux comme le monde, qui permet de transférer des messages électroniques vers un serveur. Il ne permet pas de récupérer du courrier électronique. Pour cela vous utiliserez POP ou IMAP. On pourrait penser que le protocole a été inventé en même temps que les pigeons voyageurs, mais non. C’est plus récent.

DKIM

DKIM (DomainKeys Identified Mail) est une norme d’identification fiable des noms de domaine, qui date de 2004. Expliqué dans la RFC 4871, ce système permet en fait à l’aide d’un système de clé publique/clé privée, de garantir l’authenticité du domaine expéditeur. Elle permet aussi à des intermédiaires techniques de prendre la responsabilité de l’envoi. C’est exactement ce que je cherche : déléguer cette certification à un tiers, qui lui, est connu de vos fournisseurs d’accès.

Le système est assez simple. Les messages sont signés avec une clé RSA, une signature est ensuite communiquée à votre message de cette manière :
- tout d’abord le corps du message est signé, afin bien entendu d’éviter qu’un email modifié passe à travers la grille.
- il est possible ensuite d’ajouter d’autres headers SMTP dans la signature
- un nouveau champ SMTP appelé DKIM-Signature est ajouté, avec la liste des headers signés, différentes informations pour valider le domaine, le nom de l’algo utilisé, le hash du corps du message, le tout est empaqueté.
- les champs de l’entête ainsi que le champ DKIM-Signature sont ensuite normalisés (canonicalized en Anglais) et hashés.
- une signature RSA est calculé sur ce hash, et cette signature est ajoutée dans le champ DKIM-Signature

L’ensemble est donc un espèce de timbre poste méga-sécurisé, qui valide bien l’expéditeur, et/ou la plateforme technique ayant fait passer le message. Par contre, pour mettre cela en place, il faut avoir soit son propre serveur SMTP, soit croiser les doigts pour que votre solution actuelle l’utilise. Je crois (sans avoir vérifié) que Gandi propose ce système lorsque vous utilisez leurs relais SMTP… Donc à priori j’ai déjà. Cool.

SPF

SPF (Sender Policy Framework) est plutôt un moyen de limiter le spam en déclarant dans votre DNS quelles sont les sources valides dans votre domaine, qui ont le droit d’envoyer des emails. Par exemple, si un email arrive chez vous en provenance de 217.10.11.12 , alors que je n’ai dit que seul telle autre IP a le droit d’envoyer un email, il sera marqué comme spam. Ce n’est pas LA solution, mais un moyen simple d’améliorer aussi la réputation de son domaine.

Sinon il y a d’autres solutions

Si vous souhaitez envoyer une newsletter (une lettre de publi-information) il est peut-être plus intéressant de passer par des solutions comme MailChimp par exemple. Une API type JSON/REST permet d’intégrer dans son application tout ce qu’il faut pour créer votre newsletter, mettre à jour la liste des personnes intéressées et gérer aussi les désinscriptions. Par ailleurs la plateforme propose des outils marketing (taux d’ouverture, fréquence de lecture par jour, etc). Bref cela pourra être intéressant plus tard si je souhaite mettre en place une liste de diffusion sur l’eXpress-Board.

SendGrid est une autre solution, plus orientée du côté de l’envoi massif d’emails. Premier service intéressant : c’est votre postier. Il agit comme un tiers de confiance vis-à-vis des destinataires des emails. Techniquement, vous avez plus de chances que votre email atteigne sans soucis son destinataire, qu’en se reposant sur votre propre configuration SMTP par défaut. Ensuite, et cela peut devenir intéressant, c’est un système capable de diffuser rapidement un volume important. Ils envoient plus de 45 millions d’emails par jour pour le compte de 23 000 entreprises… La solution de base à 0.10 USD pour 1000 est ultra-compétitif. Mais pour ce prix, votre email ne sera pas reçu immédiatement par le destinataire. C’est un peu ennuyant lorsqu’il s’agit d’envoyer un rappel de mot de passe. Votre client risque de ne pas revenir sur votre site, s’il reçoit 3 heures plus tard son mot de passe. Il faut alors prendre une solution un peu plus chère, mais le tout reste raisonnable. Comptez 79 USD par mois, pour débuter.

CritSend est un poil plus technique. Le système gère aussi l’envoi, il offre un système de désabonnement automatiquement. Par ailleurs, il stocke les emails incorrects. Cela me permettrait de nettoyer par exemple chaque nuit les comptes invalides sur l’eXpress-Board. Le prix est compétitif : 20 000 emails pour 10$, bref de quoi travailler tranquillement sans soucis.

Conclusion

Je pense que je vais tester MailChimp. Le service est gratuit jusqu’à 2000 emails par moi. Il va me servir d’abord de relai SMTP. Je verrai plus tard pour ce qui est de l’envoi des newsletters.
Sinon à plus court terme, j’ai nettoyé mes enregistrements DNS, mais je crois que je vais basculer vers une solution plus pro.

Merci à @framiere, @Baztoune, @jsevellec, @cestpasdur, @ProjectBleuet, @ThibaudVibes, @fabriceclaeys et @evenisse pour vos informations cet après-midi sur Twitter.

Ressources

Voici d’autres solutions proposées.

Si votre besoin est plutôt de l’envoi d’emails transactionnels (mot de passe oublié, création de compte, facture)
- MailJet propose une offre gratuite jusqu’à 6000 emails par mois (merci Bruno S.)
- Postmark propose une offre à 1.5 $ pour 1000 emails envoyés

Si votre besoin est plutôt du type lettre d’information
- MailChimp
- Campaign Monitor est plus marketing/suivi des emails lus

Pour tester la configuration SPF d’un domaine : MyIPTest.

CSS3 : découvrez les ombres et la lumière

Nicolas Martignole — Sat, 12 Feb 2011 23:16:12 +0000

HTML5 et CSS3 arrivent à grand pas, il est temps de s’y mettre sérieusement. En fait si vous avez un téléphone Android ou un iPhone dans la poche, vous avez déjà un appareil tout à fait capable d’utiliser ces nouvelles spécifications. Mais concernant les navigateurs un peu plus ancien, où en sommes-nous vraiment ?

Internet Explorer 6 est mort depuis des années

Si votre DSI vous impose encore l’usage de cette bouse de pseudo-navigateur, envoyez-lui un faire-part lui annonçant que son précieux est mort depuis 10 ans. IE6 est sorti en août 2001. IE8 date de mars 2009 et c’est le premier navigateur utilisé. IE9 est disponible en Release Candidate au moment où j’écris ces lignes.

Concernant les parts de marché des navigateurs webs, le leader en cette début d’année 2011 est Internet Explorer 8 avec 34.17%, puis Firefox 3.6 avec 18.55% et en 3ème position notre bon vieux Internet Explorer 6 avec seulement 11.43% de part de marché. Vous trouverez d’autres chiffres sur le site de Net MarketShare.

Regardons plutôt vers l’avenir et vers ce qu’il est possible d’utiliser dès maintenant sur beaucoup de navigateurs. Croyez-moi, il est temps de se mettre à niveau si vous n’avez jamais touché une balise HTML de votre vie.

Le mythe du Web Designer

Dans la communauté Java, les développeurs imaginent parfois qu’ils vont travailler avec des « Web Designers« . Un jour, quelqu’un leur a expliqué qu’il fallait qu’ils fassent la partie « serveur » et qu’un gars allait faire la partie Web.

Hé les gars… on s’est moqué de vous… c’était une blague… comme le papa Noël, il faut arrêter d’y croire.

C’est culturel et je vais expliquer pourquoi. Il y a quelques années, les développeurs d’application de gestion utilisaient des clients lourds. Or lorsque vous développez en C/C++ avec Qt ou en Java avec Swing, vous êtes habitué à utiliser des composants. La création d’une interface utilisateur n’est pas un souci. Cela fait 20 ans que nous sommes capables de construire des applications de gestion sans soucis.
Le problème s’est posé lorsque nous avons dû commencer à faire du Web. Plus exactement, du client riche (RIA si vous voulez vous la raconter). Or le Web est un milieu bien plus jeune et en constante évolution, là où du côté du client lourd nous étions dans un environnement stable.
Pour bien maîtriser le développement Web, il faut d’abord comprendre son architecture. Puis ensuite de nouveaux concepts comme les états sans session transactionnelle du côté serveur.
Au lieu de chercher à comprendre, nous avons voulu calquer ce que nous savions faire dans la bonne grosse application type client lourd.

Grave erreur.

Cela donne des applications qui ne sont pas des applications webs. A la limite, rendez-vous service : ne faîtes pas de Web. Vous étiez meilleurs avant.

J’appelle donc les développeurs Java qui pensent que l’on peut faire du Web avec un W majuscule : le web designer n’existe pas. C’est toi mon ami qui doit apprendre à construire l’interface en comprenant ce que fait un navigateur. Et ne pense pas te cacher derrière un framework (GWT/JSF/Flex) au lieu de prendre quelques heures pour découvrir ce que le navigateur peut faire.

Je te le promets, c’est fun et c’est simple. Plus que Scala, plus que Clojure et plus qu’Haskell. Et cela te sera certainement plus utile à mon avis.

On appelle cela HTML5 et CSS3…

Dessinons un cadre

Prenez un simple DIV pour commencer, avec un fond orange et une taille fixée. Une page en HTML5 se déclare aussi simplement que cela :




  
  My first HTML5 page

Ce qui donne :

Ajoutons de l’ombre avec la propriété box-shadow

Pour ajouter une ombre sur votre objet, CSS3 introduit la propriété box-shadow. Voyons comment ajouter une ombre simple sur notre boîte. Tout d’abord le résultat :

Le code est assez simple :

Notez que si votre navigateur ne reconnait pas cette propriété, il se contentera d’afficher un cadre orange. Nous appelons cette notion le dégradage progressif. Cela ne fait pas planter le navigateur, il est toujours en mesure d’afficher la sémantique de la page. La mise en forme sera simplement moins riche.

Pour aller plus loin avec les ombres : http://www.css3.info/preview/box-shadow/

Arrondir les bords

La propriété border-radius permet d’arrondir simplement les bords de votre cadre. Opera 10.5+, Safari 5+, IE9 et Chrome 5+ reconnaissent cette propriété nativement. Firefox 3.6+ doit par contre utiliser la propriété -moz-border-radius, jusqu’à ce qu’une version plus récente de Firefox reconnaisse cette propriété nativement. Ce sera le cas de Firefox 4.

Le code source complet:

Il est bien entendu possible de définir pour chaque coin des paramètres différents.

Plus de détails : http://www.css3.info/preview/rounded-border/

Dégradé de couleur

CSS3 permet aussi de créer des dégradés. Webkit, le moteur de Safari, Chrome ou Konqueror, est présent sur Android et sur IPhone. Par ailleurs si vous surfez avec Safari sur Mac ou Chrome sur PC, vous utilisez Webkit sans le savoir. Autant dire que ce que vous allez voir est déjà utilisable sur un bon nombre de plateforme.

Pour construire une barre de navigation dans un menu ou pour ajouter un dégradé à votre tableau, la propriété gradient est parfaite. Elle est arrivée fin 2008 sur Webkit. Le moteur Mozilla a ensuite ajouté sa version, plus proche de la spécification CSS3. C’est un sujet encore très récent car le dernier draft sur le site du W3C date du 12 février 2011…

Du côté Microsoft, IE7 et IE8 permettent de faire des gradients en utilisant des propriétés propriétaires. Je ne vous en parlerai donc même pas. Ce que vous allez voir ne marche que sur Mozilla et WebKit.

Voyons d’abord un simple petit dégradé sur notre cadre :

Si vous voyez un cadre rouge, votre navigateur ne reconnait pas la propriété CSS -webkit-gradient ou -moz-linear-gradient.

Pour afficher ce dégradé linéaire, j’ai simplement définit plusieurs fois la propriété background de mon div :

- Le site CSS3 Gradient Generator permet de générer de beaux dégradés.
- Ultimate CSS Gradient Generator est très pratique car il donne des gradients préconfigurés pour débuter rapidement.

Transition

Jusqu’ici, nous avons simplement ajouté des styles sur notre élément. Il est maintenant temps de vous montrer une version animée de notre cadre. Il serait sympa d’animer la couleur de fond lorsque l’utilisateur survole un cadre par exemple.

Solution 1
Je vais d’abord faire en sorte que le dégradé de fond soit différent lorsque l’utilisateur passe la souris au dessus du DIV. Pour détecter ceci, j’utilise :hover sur le DIV :

Survolez-moi 1

Survolez-moi

Le code source :



Survolez-moi 1


Survolez-moi

Solution 2
La solution 1 n’est pas optimale. Il faut calculer les dégradés à la main, clairement ce n’est pas très pratique. Et si nous pouvions jouer sur certaines propriétés comme l’opacité ? Le tout avec une belle transition ?

CSS3 permet d’ajouter des transitions très facilement. Sur l’eXpress-Board par exemple, si vous survolez le menu de navigation en haut, vous verrez qu’un petit effet de transition est ajouté lorsque vous passez la souris sur les options. Une transition est une opération qui s’applique sur une ou plusieurs propriétés CSS. Par exemple vous pouvez appliquer une transition sur la propriété background-color ou sur la propriété opacity. C’est exactement ce que nous allons faire ici.

Tout d’abord le résultat final, observez ce que fait le navigateur lorsque vous survolez le cadre :

Survolez-moi 8

Survolez-moi 9

Concernant Mozilla, les transitions ne sont supportées qu’à partir de la version 3.6.4 ou dans la bêta de Firefox 4. Par contre, du côté de Chrome ou de Safari, webkit supporte très bien celles-ci depuis bientôt 2 ans.

Voyez le code source nécessaire pour animer simplement la propriété opacity :



Survolez-moi 8


Survolez-moi 9

Pour aller plus loin et découvrir d’autres effets très puissants avec les transitions, voici quelques sites :

- la norme W3C explique la syntaxe
- Using CSS3 Transitions, Transforms and Animation : ce site vous montre toutes les transitions possibles
- Gaetan Renaudeau explique les transitions CSS3 sur Zengularity. Je l’ai mis en oeuvre sur la page d’accueil de l’eXpress-Board.
- Un effet LightBox en CSS3

Conclusion

Vous avez découvert les propriétés CSS3 suivants :
– box-shadow pour dessiner une ombre portée
– border-radius pour arrondir les angles
– gradient pour faire un dégradé
– transition pour passer d’une valeur à une autre pour une propriété CSS.

Ce n’est que 2% de ce qu’il est possible de faire simplement de nos jours. Souvenez-vous de cet article lorsqu’il s’agira de rendre agréable l’interface de votre logiciel… Sortons un peu de la culture « ingénieur » du côté serveur et n’oublions pas que nous codons des logiciels qui doivent être agréable à utiliser. C’est bien de faire 3 séparations en couche. C’est mieux de penser qu’il y a un utilisateur qui va cliquer dans votre interface. C’est bien de rêver la nuit de Lombok. C’est encore mieux de penser que trouver 3 belles couleurs ne demande que 5 minutes d’efforts…

Rêvons un peu, sortons de l’ombre et allons vers la lumière.

Ressources
- Initializr.com : pour construire en 2mn un projet HTML5 propre, qui fonctionne aussi avec les navigateurs anciens.
- Ultimate CSS Gradient Editor : trouver des gradients propres
- Modernizr : librairie JS pour simplifier la gestion des tags HTML5
- HTML5shim permet d’ajouter des fonctions HTML5 à des versions antérieurs à IE9 si vous devez coder pour les navigateurs Microsoft.
- Liste de librairies JS et CSS pour ajouter tout un ensemble de fonctionnalités comme les formulaires, les styles ou le local-storage.
- WebForms2 est une implémentation cross-browser qui descend jusqu’à IE6 de la spécification WHATWG Web Forms 2.0. Cette spécification donne une vision de ce qui sera disponible au delà d’HTML5.
- Vendor prefixed CSS properties liste à jour de l’ensemble des propriétés CSS3 implémentés par moteur de rendu. Gecko pour Firefox, Webkit pour Chrome/Safari, Presto pour Opera et Trident pour Microsoft.

Devops expliqué simplement

Nicolas Martignole — Sat, 04 Dec 2010 14:30:13 +0000

Une histoire fictive de la réalité

Credit photo Steve Chilton http://www.flickr.com/photos/steve_chilton/2322020454/sizes/z/in/photostream/

J’imagine votre joie en ce beau vendredi. Il est 17h50 et vous venez juste de réussir à construire votre projet avec Maven. Après 3 jours d’efforts surhumains, vous avez enfin terminé le packaging de votre logiciel/projet/truc-du-moment. Comme le projet était à mettre en prod il y a 2 jours, vous êtes largement dans les temps avec seulement 48 heures de retard. Donc tout va bien, vous êtes prêt à passer en prod.

Et il est maintenant temps d’appeler le gars de l’exploite.

Pour ceux qui ne connaissent pas le gars de l’exploite, c’est ce bonhomme qui ne vit que la nuit, qui passe son temps à installer, configurer, patcher, arrêter, relancer et surtout installer les logiciels que vous développpez.

En règle générale vous n’avez que de brefs échanges au téléphone. Souvent des Onomatopées pour sa part comme « Mouais, mmmfff, grrr, cool ». Alors que de votre côté vous avez vos phrases toutes faites auxquelles il ne réagit plus comme ma favorite « Mais sur mon poste ça marchaaaiiit » ou « Ben l’intégration continue elle est verte, alors ça doit marchéeeee » et encore une autre : « Je comprends, chez moi ça marche avec H2 in-memory et Tomcat. Pourquoi cela ne marcherait-il pas avec Websfear et Ourahcleu ? »

Nous avons donc à notre gauche un expert système aussi sexy que Sébastien Chabal et à notre droite un développeur protégé par son bouclier « Maven+ ». Et vous, chef de projet/architecte/femme au foyer devez faire cohabiter ces 2 espèces…

Le développeur a une fâcheuse tendance à ne pas penser qu’un jour, peut-être, son logiciel sera mis en production. L’exploitant système d’autre part a une tendance ennuyante à demander des conditions de prods, quant bien même l’installation n’est prévue que pour 2 testeurs.

Bref cela donne beaucoup d’échanges intéressants.

Heureusement que l’on fait pas ça hein…

Il y a heureusement un mouvement intéressant qui prend de l’ampleur, et dont nous aurons l’occasion de parler dans les mois qui viennent : DevOps

J’ai entendu parler de DevOps à Devoxx 2010 pour la première fois. Il s’agit d’un ensemble de techniques collaboratives pour que les développeurs, les personnes de l’exploitation système et les équipes de tests travaillent plus efficacement ensembles. C’est aussi un mot pour regrouper plusieurs idées brillantes dont la première serait « et si on arretait de travailler comme des bourrins« .

Il y a le commerce équitable où tu respectes le gars qui fait du café en Colombie.

Il y a Devops pour envisager de manière différente la relation développeur-testeur-gars de l’exploitation.

Basé sur des valeurs Agiles, DevOps propose de livrer souvent, simplement et par petits incréments votre logiciel. Cela semble logique dans la suite du mouvement amorcé dans le développement, avec l’essor des méthodes Agiles comme Scrum par exemple.

Le petit plus du mouvement DevOps : il est initié par les experts systèmes des grands du Web. Il est plus centré sur la mise en production et l’assurance qualité. Ne cherchez pas de certification DevOps, nous parlons bien d’une manière de travailler différemment.

De la même manière que vous avez de l’intégration continue, vous pourriez avoir aussi une mise en production continue. L’essor du Cloud et des systèmes de virtualisation expliquent aussi l’apparition de ce mouvement. Il est désormais possible non pas de mettre en production un logiciel, mais carrément une image virtuelle complète et validée. Le temps de l’installation d’une application sur un serveur d’app est peut-être même terminé. Il sera demain plus simple d’installer et de démarrer une machine virtuelle, plutôt que de perdre du temps avec un serveur d’application Java.

So-li-da-ri-té

DevOps c’est aussi un ensemble de pratiques afin de favoriser le travail entre les développeurs, les testeurs et les équipes systèmes. Cela va à l’encontre des silos érigés dans les DSI ces dernières années. Il est plus efficace de co-localiser un développeur, une personne de la production et un ingénieur qualité, que de les disperser dans 3 sites différentes. Retirez aussi les micro-managers qui ne servent à rien et laissez-les travailler. Bon, du coup la DSI ne sert plus à grand chose, mais qui en doute encore hein ?

Automatisation

Pour être efficace, une démarche « DevOps » doit aussi viser l’hyper industrialisation des processus. Oh que j’aime cette phrase de consultant…. Attendez j’en essaye une autre… l’automatisation des tâches répétitives permet de réduire les facteurs de coûts et d’améliorer la livraison des incréments de manière itérative…. ça se voit que j’ai vendu du SOA.

Blague à part, vous l’aurez compris, pour être efficace il faut travailler avec les exploitants systèmes et les équipes qualités. En France les équipes qualités ne sont pas valorisées. Elles sont même absentes de certains projets. Lorsque j’étais chez Reuters, c’était le chef QA qui décidait ou non de la sortie de notre logiciel. Imaginez un instant que ce ne soit pas le chef de projet… Respirez… pensez-y encore…. voilà… vous pensez DevOps.

Développer c’est aussi mettre en production

Etre développeur dans une approche DevOps, c’est aller voir les personnes de l’exploitation. C’est passer une journée avec eux afin de comprendre les problèmes rencontrés. Ce sera très enrichissant et cela vous permettra de voir ce que font réellement les clients.

Chaque développeur devrait être capable de construire l’ensemble du projet puis de l’installer. Il n’est pas normal qu’une seule personne soit en charge de packager et livrer l’application. Nous devons être tous responsable du logiciel.

Les développeurs sont en général assez mauvais sous Unix. Allez je vais essayer de voir si tu sais répondre à cette série de questions simples :

- Que se passe-t-il si je fais un kill -3 sur le pid d’un process Java sous Unix ?
- A quoi sert la commande jps livrée dans le JDK 6 ?
- Comment remplacer le caractère ^M avec vi ?

Si tu réponds à ces 3 questions, tu es un maître. Si tu connais au moins l’une des réponses, c’est pas mal. Sinon… et bien sinon c’est pas grave, tu es comme la majorité des personnes.

L’effet silo

Soyons réaliste : beaucoup de projets informatiques actuels ne sont pas adaptés aux idées du mouvement DevOps. Nous avons mis en place des départements isolés. L’équipe métier, l’équipe technique, l’assurance qualité et l’équipe d’exploitation. Chaque silo est bien séparé. La communication s’effectue par l’intermédiaire de « réunions » avec des « phones-calls », alors que parfois les équipes sont dans le même bâtiment… Très rapidement cela conduit à une polarisation des relations entre les équipes. C’est « eux » contre « nous »…
Alors qu’un chef courageux prenne ces équipes et les mettent dans un même espace. Du métier à l’exploitation. Voyons ce que cela donne, ayons le courage d’aller à l’envers de ce qui coûte de plus en plus cher au fil du temps… C’est ça DevOps.

Je pense aussi qu’il y a un effet génération. Les 40 ans et plus ont une vision des années 90, sans Twitter et sans Facebook. Alors que la tranche 25-40 ans ne comprend pas pourquoi la mise en production d’un projet doit rester héroïque. Si les choses changent, c’est aussi parce que nous en avons marre de devoir envoyer 3 emails pour relancer « dans l’urgence » un serveur…

Conclusion

DevOps est un nouveau buzz word appuyé cependant par des acteurs du Webs. Une fois encore, ils viennent bousculer le monde de l’entreprise avec une approche Agile des relations développeurs/assurance qualité/production. C’est aussi une nouvelle fracture entre l’approche classique, majoritaire dans les DSI aujourd’hui, et l’approche Web mise en oeuvre par les petites structures.

C’est un mouvement lancé par des personnes qui pensent qu’il faut construire des logiciels avec de bonnes équipes, de bonnes relations inter-équipes et de bonnes technologies. Le plus important c’est le dernier mètre, les derniers instants avant que votre plateforme soit lancé. C’est aussi une vision où par exemple la mise en production n’a pas lieu dans 20 mois mais dès le premier mois. C’est une vision où le développeur prend conscience des problèmes d’exploitations. Plutôt que de s’auto-congratuler sur une approche DAO/Service, il pensera à faire une couche de logging efficace et pratique à utiliser.

Je pense que nous aurons l’occasion d’en parler dans les mois qui viennent. Surveillez les blogs des voisins comme Xebia, Octo ou Ippon Technologies, je pense que le sujet est intéressant à débattre.

Ressources

Blog de Patrick Debois (cité par Sébastien ci-dessous dans les commentaires)
Très bonne présentation sur DevOps sur son son blog. Le slide sur Kanban avec l’abattage à la chaîne est énorme… Et la métaphore du barbecue, j’ai adoré. A invité d’urgence à Agile France. Vous trouverez pleins d’astuces, comme l’appel de l’API Rest de Nexus via des scripts. Cela vous permet de récupérer la dernière SNAPSHOT de votre projet pour l’installer (dédicace à Emmanuel Servent de Xebia, il comprendra).

Blog de Stephen Nelson-Smith, Agile Sysadmin. Beaucoup d’articles intéressants comme la notion de golden image

Continuous Delivery, le blog de Jez Humble et Dave Farley est intéressant. Jez est product Manager de Go, un logiciel de ThoughtWorks Studios. Go permet de gérer la compilation, l’installation et le lancement de campagne de tests pour différents environnements (UAT, Prod, Dev) très simplement. C’est un outil d’industrialisation intéressant avec une édition community.

Il y a un même un DEVOPS_Borat sur Twitter qui balance pas mal de trucs marrants.

Réponses aux questions

1) Sous Unix pour générer une Stack Trace d’un processus Java vous pouvez envoyer le signal QUIT à un processus Java. Par exemple kill -3 .
Sous Windows il suffit de sélectionner la fenêtre où tourne votre application et de faire Ctrl-Break.
2) La commande jps que peu de monde connaît, alors qu’elle fait partie de Java 6, permet de lister les processus Javas qui tournent sur votre machine.
3) Pour remplacer le terminateur de fin de ligne Windows lorsque vous êtes sous Unix, avec vi voici la suite de touche à jouer : [Esc] : % s / [Ctrl-V] [Ctrl-M] / / g . Il y a aussi sinon la commande dos2unix et des milliers d’autres façons de faire

L'eXpress-Board bascule sur la plateforme PlayApps.net

Nicolas Martignole — Thu, 24 Jun 2010 07:38:41 +0000

Play! Framework est un framework Java dont je vous parle depuis quelques temps. Comme vous le savez, j’ai lancé un site d’offres d’emplois pour passionnés, l’eXpress-Board.fr, réalisé justement avec ce framework Web il y a 2 mois. Le site marche bien. J’ai reçu hier soir le témoignage de Fabrice, qui a signé grâce à l’eXpress-Board.fr

Zenexity est une société Française dont le directeur technique, Guillaume Bort, est aussi le fondateur du framework Play! Zenexity a lancé un nouveau service en bêta il y a quelques jours : PlayApps.net. Il s’agit d’une solution PaaS (Platform as a service) construite en partenariat avec la société Gandi.

Ce service permet :
- d’installer une application Play! Framework en quelques minutes
- de configurer la quantité de CPU et de mémoire selon l’usage de son application
- de gérer les sauvegardes de la base comme de l’application facilement
- d’effectuer l’installation d’une nouvelle version en sauvegardant l’ancienne
- d’afficher des statistiques sur l’application (trafic, mémoire, réseau)
- de suivre les performances dans le temps
- de gérer les bases de données simplement
- de ne pas perdre de temps avec la configuration système
- de se connecter via SSH si nécessaire pour pouvoir travailler avec l’application directement

L’installation est relativement simple. Pour tout vous dire, j’ai migré en 30 minutes mon application existante ainsi que la base de données vers le nouveau serveur, sachant que le plus long a été de me souvenir des commandes MySQL pour exporter/importer la base . Je ne m’attendais pas à ce que cela soit aussi simple et rapide.

Playapps.net est en bêta, mais il y a déjà 71 applications installées sur la plate-forme. Son accès se fait sur invitation seulement pour l’instant. Si ce projet vous intéresse, vous pouvez demander un accès sur le site PlayApps.net.

A terme, je gagne un système qui me fait gagner du temps, offre un service de qualité à mes clients, et me permet de me concentrer sur le coeur de ma solution, sans devoir bidouiller des serveurs. Par rapport à Google App Engine, sur lequel il est possible de faire tourner Play!, je préfère finalement payer quelques euros par mois pour avoir une vraie plateforme, sur laquelle je peux travailler.
La liste de diffusion de Play! Framework montre que beaucoup de personnes rencontrent des difficultés liées aux limitations de la JVM sur la plateforme Google.

Côté performance, des tests conduits par Guillaume sur l’express-board avec Apache Bench montre que l’application tourne sans soucis à 80 visiteurs par seconde, et que la page d’accueil a une latence moyenne de 57ms avec 20 threads seulement. Le tout avec une JVM qui n’utilise que 64Mo. Oui je sais, ça fait bizarre lorsque l’on pense qu’une application Java peut fonctionner avec si peu de mémoire… C’est 4 fois moins de mémoire que mon iPhone. Quand on utilise pas 10 000 frameworks, croyez-moi ça tourne.

Ce nouveau service ouvre la voie au développement Web léger en Java, ainsi qu’à l’hébergement. Il sera intéressant de revenir sur les différentes architectures Webs et de montrer à quoi peut répondre Play! Framework. Après les plateformes L.A.M.P (Linux Apache MySql Php) nous allons passer aux plateformes LiPlayFraMy (Linux/Play! Framework/MySql) pour un prix similaire, mais sur une JVM.

Moi je dis, ce que font ces gars là est à suivre.

Spring Faces+WebFlow+Java classique comparé à Play! Framework

Nicolas Martignole — Thu, 13 May 2010 13:23:31 +0000

Dans cet article, je vous propose de regarder 2 approches différentes pour résoudre un même problème : construire une application web sécurisée, moderne et Ajaxisé. Je vais vous présenter les différences de conceptions sur la partie Java essentiellement. Cet article ne sera pas une introduction à l’une ou l’autre des technologies. Je souhaite vous éclairer sur quelques concepts différents dans Play! par rapport à l’approche classique.

Pour comparer 2 choses, il faut un référentiel comparable. JBoss Seam propose sur cette page plusieurs versions d’une application de réservation de chambres d’hôtels. La version originale basée sur JSF 1.2 n’est plus toute jeune mais fonctionne très bien. J’en avais parlé sur le Touilleur Express il y a 3 ans et demie… Quand je me dis que cela fait plus de 3 ans que j’ai vu cela, et qu’à l’époque je vous avais convaincu de regarder JSF par rapport à Struts, je me dis qu’il faut que je réussisse dans cet article à vous montrer la nouvelle approche, celle de 2010.

Nous allons prendre Spring Faces et Spring Webflow, une approche que je trouve très intéressante et qui permet de réaliser des applications Webs avec les technologies de Spring.

I. Le match : télécharger, installer et lancer la démo

Voyons tout d’abord comment télécharger, compiler et lancer la démonstration avec chacun des environnements. Je souhaite évaluer la rapidité de prise en main. Je souhaite que le projet soit configuré dans IDEA IntelliJ ou Eclipse pour travailler, et je vais évaluer la facilité à monter chacun des environnements. Je regarderai aussi le temps de démarrage des serveurs Webs testés.

I.1) Préparation de l’espace de démo pour Spring

SpringSource propose « Spring Travel« , une version basée sur Spring Faces, Spring WebFlow 2.0.9 et une librairie JSF avancée pour le rendu. J’ai regardé précisément le code « booking-faces » dans le répertoire projects/spring-webflow-samples pour écrire cet article. Si vous souhaitez tester par vous même :
- téléchargez la version Spring WebFlow 2.0.9 sur le site de SpringSource
- décompressez l’archive
- ouvrez le répertoire projects/spring-webflow-samples/booking-faces
- tapez mvn eclipse:eclipse pour créer un nouveau projet
- ou sinon tapez mvn idea:idea pour créer un projet IDEA IntelliJ
- ou enfin, si vous avez IDEA IntelliJ, celui-ci importe sans problème le pom.xml et vous prépare un projet configuré… Pas besoins de plugins.

Faire tourner la démo en local
Pour faire fonctionner la version Spring en local, éditez le pom.xml et ajoutez Jetty dans la balise build/plugins comme ici:

   ...
   
        swf-booking-faces
        
        	...

            
                org.mortbay.jetty
                maven-jetty-plugin
            

        
    
    
        2.5.6.SEC01
        1.2.0.09

Vous pourrez alors lancer la démo avec mvn jetty:run dans le répertoire de la démo de Spring.

I.2) Configuration de la version Play! Framework

Play! Framework se télécharge sur le site de Play!. Voici comment suivre mes explications pour la deuxième partie :
- décompressez le zip dans un répertoire C:\Soft\play par exemple
- ajoutez C:\Soft\play à votre PATH

Pour lancer l’application :
- allez dans le répertoire C:\Soft\play\samples-and-tests\booking
- tapez « play run » et connectez-vous sur http://localhost:9000/

Pour travailler avec Eclipse ou IDEA IntelliJ
- allez dans le répertoire C:\Soft\play\samples-and-tests\booking
- tapez play eclipsify pour créer un projet Eclipse
- OU tapez play idealize pour créer un module IDEA IntelliJ
c’est tout !

I.3) Résultat du match :

Facilité d’installation : match nul
Qualité de la doc sur le site : match nul
Création du projet dans IDEA IntelliJ : match nul
Serveur : la démo Spring n’embarque pas de serveur, il a fallut ajouter Jetty pour tester alors que Play! Framework dispose de son propre serveur
Temps de démarrage : avantage Play! qui démarre très rapidement en 2 secondes.

Vainqueur : Play! Framework d’une courte longueur

II. Le modèle

II.1) Spécification fonctionnelle

L’objectif de l’application est de réaliser un site de réservation d’hôtel. Pour cela, l’utilisateur peut chercher un hôtel, puis ensuite créer une réservation (Booking en Anglais).

L’utilisateur doit s’authentifier avant de pouvoir terminer sa réservation. Une entité User permet donc de gérer la sécurité facilement avec un moteur de persistence.

Nous utiliserons JPA et une base en mémoire pour les 2 versions. L’essentiel est que Play! Framework comme la version Spring, utilisent JPA. Donc les entités sont presque identiques.

II.2) Une entité simple : l’Hotel

Prenons tout d’abord l’entité Hotel qui représente un hôtel. Voici la version de la démo Spring Webflow/JSF :

package org.springframework.webflow.samples.booking;

import java.io.Serializable;
import java.math.BigDecimal;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

/**
 * Version Spring Web Flow. La sérialisation est nécessaire pour JSF.
 */
@Entity
public class Hotel implements Serializable {
    private static final long serialVersionUID = 4011346719502656269L;
    private Long id;
    private String name;
    private String address;
    private String city;
    private String state;
    private String zip;
    private String country;
    private BigDecimal price;

    @Id
    @GeneratedValue
    public Long getId() {
	return id;
    }

    public void setId(Long id) {
	this.id = id;
    }

    public String getName() {
	return name;
    }

    public void setName(String name) {
	this.name = name;
    }

    public String getAddress() {
	return address;
    }

    public void setAddress(String address) {
	this.address = address;
    }

    public String getCity() {
	return city;
    }

    public void setCity(String city) {
	this.city = city;
    }

    public String getZip() {
	return zip;
    }

    public void setZip(String zip) {
	this.zip = zip;
    }

    public String getState() {
	return state;
    }

    public void setState(String state) {
	this.state = state;
    }

    public String getCountry() {
	return country;
    }

    public void setCountry(String country) {
	this.country = country;
    }

    @Column(precision = 6, scale = 2)
    public BigDecimal getPrice() {
	return price;
    }

    public void setPrice(BigDecimal price) {
	this.price = price;
    }

    public Booking createBooking(User user) {
	return new Booking(this, user);
    }

    @Override
    public String toString() {
	return "Hotel(" + name + "," + address + "," + city + "," + zip + ")";
    }
}

Voici la version Play! Framework :

package models;

import play.db.jpa.*;
import play.data.validation.*;
import javax.persistence.*;
import java.math.*;

/**
 * Version Play! Framework
 */
@Entity
public class Hotel extends play.db.jpa.Model {

    @Required
    @MaxSize(50)
    public String name;

    @MaxSize(100)
    public String address;

    @Required
    @MaxSize(40)
    public String city;

    @Required
    @MaxSize(6)
    @MinSize(2)
    public String state;

    @Required
    @MaxSize(6)
    @MinSize(5)
    public String zip;

    @Required
    @MaxSize(40)
    @MinSize(2)
    public String country;

    @Column(precision=6, scale=2)
    public BigDecimal price;

    public String toString() {
        return "Hotel(" + name + "," + address + "," + city + "," + zip + ")";
    }

}

Les différences entre les 2 versions :
- Play! Framework étend la classe « play.db.jpa.Model » qui fournit le support JPA.
- Les attributs sont publics dans la version Play!, ce qui logiquement évite des getters/setters comme dans la version Spring classique. Moi depuis que l’encapsulation n’est plus à la mode en soirée, j’ai arrêté.
- La syntaxe JPA est un peu plus poussée dans la version Play! Nous verrons si cela permet d’améliorer l’expérience utilisateur dans l’interface graphique ou non.

Le bean de Spring n’étend pas une classe de base contrairement à Play!, ce qui permet d’étendre éventuellement Hotel. Mais est-ce que c’est quelque chose que nous faisons pour des Entities ? Je me pose la question. Perso je décourage l’héritage avec JPA. FBI = Fausse bonne idée.

[Update] Avec Play! Framework vous pouvez étendre la classe Model afin de simplifier la gestion JPA de l’entité. Cela fait partie des bonnes pratiques comme expliqué par Nicolas Leroux dans les commentaires. Pour en savoir plus, regardez la doc de la partie JPA de Play!

Play! gère l’identité dans la class Model avec un attribut Id de type Long par défaut. Si vous souhaitez gérer votre propre id, vous ~~devez~~ pouvez par exemple étendre la class JPASupport de Play!, puis simplement définir un attribut @Id comme d’habitude avec JPA. C’est tout à fait possible.

On voit que dans la version Spring, il y a une méthode « createBooking » qui permet de créer au niveau de l’Hotel une réservation.

Il n’y a donc pas de vainqueur dans cette partie pour moi. Les 2 approches se valent je pense. Je préfère la simplicité de Play! Framework qui remet en question quelques habitudes du monde Java, comme l’encapsulation systématique.

Par contre je n’aime pas trop l’approche de placer les annotations JPA sur les getters/setters plutôt que sur les attributs de la classe dans la version Spring. On perd beaucoup en lisibilité.

II.3) Une entité plus compliquée : Booking

Une réservation est l’association d’un User, d’un Hotel, d’une date d’arrivée et de départ et de différents autres attributs. Je vais faire exprès de vous donner la version complète des 2 frameworks, afin de vous montrer les différences flagrantes entre les 2 approches.

La version de la démo Spring WebFlow telle qu’elle est livrée, sans trucages, sans effets spéciaux :

package org.springframework.webflow.samples.booking;

import java.io.Serializable;
import java.math.BigDecimal;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;

import javax.persistence.Basic;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
import javax.persistence.Transient;

import org.springframework.binding.message.MessageBuilder;
import org.springframework.binding.message.MessageContext;
import org.springframework.binding.validation.ValidationContext;

/**
 * A Hotel Booking made by a User.
 */
@Entity
public class Booking implements Serializable {

    private static final long serialVersionUID = 1171567558348174963L;

    private Long id;
    private User user;
    private Hotel hotel;
    private Date checkinDate;
    private Date checkoutDate;
    private String creditCard;
    private String creditCardName;
    private int creditCardExpiryMonth;
    private int creditCardExpiryYear;
    private boolean smoking;
    private int beds;
    private Amenity amenities;   // Absent de la version Play!

    public Booking() {
    }

    public Booking(Hotel hotel, User user) {
        this.hotel = hotel;
        this.user = user;
        Calendar calendar = Calendar.getInstance();
        setCheckinDate(calendar.getTime());
        calendar.add(Calendar.DAY_OF_MONTH, 1);
        setCheckoutDate(calendar.getTime());
    }

    @Transient
    public BigDecimal getTotal() {
        return hotel.getPrice().multiply(new BigDecimal(getNights()));
    }

    @Transient
    public int getNights() {
        if (checkinDate == null || checkoutDate == null) {
            return 0;
        } else {
            return (int) (checkoutDate.getTime() - checkinDate.getTime()) / 1000 / 60 / 60 / 24;
        }
    }

    @Id
    @GeneratedValue(strategy = GenerationType.TABLE)
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Basic
    @Temporal(TemporalType.DATE)
    public Date getCheckinDate() {
        return checkinDate;
    }

    public void setCheckinDate(Date datetime) {
        this.checkinDate = datetime;
    }

    @ManyToOne
    public Hotel getHotel() {
        return hotel;
    }

    public void setHotel(Hotel hotel) {
        this.hotel = hotel;
    }

    @ManyToOne
    public User getUser() {
        return user;
    }

    public void setUser(User user) {
        this.user = user;
    }

    @Basic
    @Temporal(TemporalType.DATE)
    public Date getCheckoutDate() {
        return checkoutDate;
    }

    public void setCheckoutDate(Date checkoutDate) {
        this.checkoutDate = checkoutDate;
    }

    public String getCreditCard() {
        return creditCard;
    }

    public void setCreditCard(String creditCard) {
        this.creditCard = creditCard;
    }

    @Transient
    public String getDescription() {
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM);
        return hotel == null ? null : hotel.getName() + ", " + df.format(getCheckinDate()) + " to "
                + df.format(getCheckoutDate());
    }

    public boolean isSmoking() {
        return smoking;
    }

    public void setSmoking(boolean smoking) {
        this.smoking = smoking;
    }

    public int getBeds() {
        return beds;
    }

    public void setBeds(int beds) {
        this.beds = beds;
    }

    public String getCreditCardName() {
        return creditCardName;
    }

    public void setCreditCardName(String creditCardName) {
        this.creditCardName = creditCardName;
    }

    public int getCreditCardExpiryMonth() {
        return creditCardExpiryMonth;
    }

    public void setCreditCardExpiryMonth(int creditCardExpiryMonth) {
        this.creditCardExpiryMonth = creditCardExpiryMonth;
    }

    public int getCreditCardExpiryYear() {
        return creditCardExpiryYear;
    }

    public void setCreditCardExpiryYear(int creditCardExpiryYear) {
        this.creditCardExpiryYear = creditCardExpiryYear;
    }

    @Transient
    public Amenity getAmenities() {
        return amenities;
    }

    public void setAmenities(Amenity amenities) {
        this.amenities = amenities;
    }

    public void validateEnterBookingDetails(ValidationContext context) {
        MessageContext messages = context.getMessageContext();
        if (checkinDate.before(today())) {
            messages.addMessage(new MessageBuilder().error().source("checkinDate").code(
                    "booking.checkinDate.beforeToday").build());
        } else if (checkoutDate.before(checkinDate)) {
            messages.addMessage(new MessageBuilder().error().source("checkoutDate").code(
                    "booking.checkoutDate.beforeCheckinDate").build());
        }
    }

    private Date today() {
        Calendar calendar = Calendar.getInstance();
        calendar.add(Calendar.DAY_OF_MONTH, -1);
        return calendar.getTime();
    }

    @Override
    public String toString() {
        return "Booking(" + user + "," + hotel + ")";
    }

}

Voyons la version Play! Framework de l’entité Booking maintenant :

package models;

import play.db.jpa.*;
import play.data.validation.*;
import javax.persistence.*;
import java.util.*;
import java.text.*;
import java.math.*;

@Entity
public class Booking extends Model {

    @Required
    @ManyToOne
    public User user;

    @Required
    @ManyToOne
    public Hotel hotel;

    @Required
    @Temporal(TemporalType.DATE)
    public Date checkinDate;

    @Required
    @Temporal(TemporalType.DATE)
    public Date checkoutDate;

    @Required(message="Credit card number is required")
    @Match(value="^\\d{16}$", message="Credit card number must be numeric and 16 digits long")
    public String creditCard;

    @Required(message="Credit card name is required")
    @MinSize(value=3, message="Credit card name is required")
    @MaxSize(value=70, message="Credit card name is required")
    public String creditCardName;
    public int creditCardExpiryMonth;
    public int creditCardExpiryYear;
    public boolean smoking;
    public int beds;

    public Booking(Hotel hotel, User user) {
        this.hotel = hotel;
        this.user = user;
    }

    public BigDecimal getTotal() {
        return hotel.price.multiply( new BigDecimal( getNights() ) );
    }

    public int getNights() {
        return (int) ( checkoutDate.getTime() - checkinDate.getTime() ) / 1000 / 60 / 60 / 24;
    }

    public String getDescription() {
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM);
        return hotel==null ? null : hotel.name +
            ", " + df.format( checkinDate ) +
            " to " + df.format( checkoutDate );
    }

    public String toString() {
        return "Booking(" + user + ","+ hotel + ")";
    }

}

Tout d’abord il manque des choses dans la version Play! Framework, et on ne compare donc plus exactement la même chose. Notez l’absence de l’entité Amenity. Ensuite, la version Spring utilise une approche différente pour l’attribut @Id et spécifie le générateur alors que la version Play! hérite de ce que la super-classe Model propose.

Ce qui me dérange dans la version Spring c’est la présence de la méthode validateEnterBookingDetails. Celle-ci est intéressante fonctionnellement, mais dépose une dépendance vers MessageContext un peu trop forte à mon goût.

Regardez aussi la différence sur la validation du numéro de carte de paiement. La version Play! utilise un moteur simple similaire à Hibernate Validation, mais propriétaire à Play! Au contraire la version Spring ne précise rien, et on imagine donc que la validation des 16 digits se fera dans la vue… et pas dans le modèle.

Conclusion : j’ai de plus en plus de mal avec la sauce des getters/setters, surtout lorsque les entités dépasse les « HelloWorld » et que l’on commence à sortir des cas d’usages compliqués. Souvenez-vous de ce que je vous disais : pour résoudre des problèmes compliqués il faut des solutions simples…

III. Le contrôleur

Après avoir regardé 2 entités différentes pour le modèle, voyons maintenant la différence d’approche entre Spring WebFlow et Play! Framework. Je vais étudier le cas de l’affichage de la liste des Hôtels, lorsque l’utilisateur clique sur le bouton Search par exemple.

III.1) Spring WebFlow

L’approche de Spring WebFlow est la suivante : afin d’éviter d’écrire un controller classique, Spring propose de définir les chemins logiques de navigation en XML, et d’associer directement des méthodes sur des services pour récupérer la partie Model. Cette approche a l’avantage de simplifier le développement de workflow webs complexes. Je vais vous présenter le concept.

Pour commencer, nous définissions un flow en XML pour l’action qui affiche la liste des Hotel correspondant à un critère de recherche. Je ne vous montre que la view-state « reviewHotels » afin de ne se concentrer que sur l’exemple :

« main-flow.xml »




	

	
		// Effacé pour simplifier l'exemple...

Le point fort de Spring WebFlow/JSF ici : il sera possible de ne redessiner qu’une partie de l’interface. En effet, vous avez noté le tag ? Grâce à ce système très pratique avec Spring WebFlow et JSF, si vous avez une partie cliente en Ajax il devient alors possible de ne redéfinir qu’une partie de l’interface.

Dans la démo Play! Booking, ce mécanisme est implémenté « à la main » dans la page index.html. Tout est fait avec du jQuery et le tag jsAction de Play!, qui appelle des actions du controller Play. Celui-ci retourne alors des fragments de HTML, ce qui fait que la version Play! est aussi ajaxisé. Je reconnais que c’est moins évident et facile, mais les 2 se discutent.

Il y a donc un BookingService avec une méthode findHotels pour rechercher la liste des hôtels, d’après le Flow XML. Il s’agit d’une interface, ce qui permet de changer l’implémentation. Dans notre cas nous n’aurons que la version JPA. Si vous avez une forte envie de faire une version PasJPA notez que c’est super utile…

public interface BookingService {
   // j'ai effacé les autres méthodes ici pour ne garder que l'essentiel

    public List findHotels(SearchCriteria criteria);

}

Le service implémente l’interface, j’ai supprimé une bonne partie du code afin de ne vous laissez que ce qui nous intéresse. Mais croyez-moi, la version complète est assez verbeuse. Ce qui nous intéresse ici c’est uniquement la méthode findHotels

@Service("bookingService")
@Repository
public class JpaBookingService implements BookingService {

    private EntityManager em;

    @PersistenceContext
    public void setEntityManager(EntityManager em) {
        this.em = em;
    }

   // Note : j'ai effacé du code ici pour ne garder que quelques méthodes

    @Transactional(readOnly = true)
    @SuppressWarnings("unchecked")
    public List findHotels(SearchCriteria criteria) {
        String pattern = getSearchPattern(criteria);
        return em.createQuery(
                "select h from Hotel h where lower(h.name) like " + pattern + " or lower(h.city) like " + pattern
                        + " or lower(h.zip) like " + pattern + " or lower(h.address) like " + pattern + " order by h."
                        + criteria.getSortBy()).setMaxResults(criteria.getPageSize()).setFirstResult(
                criteria.getPage() * criteria.getPageSize()).getResultList();
    }

   // Note 2 : j'ai effacé du code ici pour ne garder que quelques méthodes

   // helpers
   private String getSearchPattern(SearchCriteria criteria) {
        if (StringUtils.hasText(criteria.getSearchString())) {
            return "'%" + criteria.getSearchString().toLowerCase().replace('*', '%') + "%'";
        } else {
            return "'%'";
        }
    }

}

Le plus intéressant est donc la méthode findHotels. Elle permet d’effectuer la recherche, de retourner une List d’Hotel à la vue, que nous verrons tout à l’heure si vous êtes toujours motivé.

III.2) Le contrôleur version Play! Framework

L’approche de Play! est un peu plus simple mais demande un peu plus de code Java.
Je précise tout de suite : j’ai modifié l’exemple afin de retirer la partie Authentification et pour ne me concentrer que sur le Use-Case de récupérer la liste des Hotel correspondant à un critère entré dans l’interface utilisateur.

public class Hotels extends Controller {

    public static void list(String search, Integer size, Integer page) {
        List hotels = null;
        page = page != null ? page : 1;
        if(search.trim().length() == 0) {
            hotels = Hotel.all().fetch(page, size);
        } else {
            search = search.toLowerCase();
            hotels = Hotel.find("lower(name) like ? OR lower(city) like ?", "%"+search+"%", "%"+search+"%").fetch(page, size);
        }
        render(hotels, search, size, page);
    }
   ...
    // Note : code effacé pour ne conserver que la méthode list
   ...
}

L’approche de Play! Framework est donc la suivante :
- écrire une classe dans le répertoire « controllers » qui étend la class Controller de Play!
- écrire une méthode public static avec en argument les paramètres de la vue. Play! se charge de vous récupérer ce que l’utilisateur a entré. Notez ensuite l’appel pour récupérer la liste des Hotels :

            search = search.toLowerCase();
            hotels = Hotel.find("lower(name) like ? OR lower(city) like ?", "%"+search+"%", "%"+search+"%").fetch(page, size);

La méthode find est une méthode statique définie dans la classe JPASupport. Elle permet d’exécuter des requêtes JPA. Vous pouvez aussi écrire une méthode dans l’entité Hotel pour éviter de placer ici du code technique par exemple. Les 2 approches se valent.

III.3) Différence d’approche

La version Spring WebFlow demande plus de XML, ce qui personnellement me dérange. Je trouve que la définition des flows n’est pas simple. C’est même une fausse bonne idée. Je préfère une approche fortement typée en Java, où par contre pour que la magie opère, je dois étendre des classes spécialisées de Play! Framework.

Côté test, il est assez simple de tester Spring WebFlow, mais je n’ai pas testé personnellement.

Je vais être méchant avec Spring WebFlow : je trouve cela bien compliqué pour résoudre un problème simple. Ici quel est l’apport du XML ? Des annotations ? Est-ce que notre vie est plus simple grâce à ce système ? Permettez-moi d’en douter.

C’est peut-être une révolution par rapport à l’approche Struts, mais tant qu’à faire la révolution, il ne faut pas s’arrêter à un concept basé sur un fichier XML pour définir la navigation d’une application Web.

III. 4) Synthèse

Avantages de Spring Web Flow

- possibilité de déclarer en quelques lignes un bout de code pour que la vue récupère le Model sans devoir définir un controller.
- gestion de la navigation de l’utilisateur fine dans le site
- se repose sur des Services facile à tester pour s’assurer que le Model est correct
- bien meilleur que l’approche classique où les DAO dans les Services ne servent à rien
- Spring MVC récupère les paramètres de la vue et les dénormalise, ce qui est très pratique.
- bonne intégration de la sécurité

Inconvénients de Spring Web Flow

- clairement plus compliqué que Play! sur ce point
- XML tu aimes ou tu n’aimes pas, mais c’est ton environnement de développement Web
- gestion pas facile pour les débutants entre les view-states, les action-states, les transitions etc.
- l’EntityManager à la main dans le service : pas top. Mais c’est quelque chose qui est souvent factorisé dans des classes de GenericService par exemple, avec un DAO… Bref encore 3 ou 4 classes Java en plus.

Avantages de Play! Framework :

- le controlleur déclare des méthodes static et public qui deviennent autant d’URL dans la vue
- le framework se charge de récupérer et dénormaliser les paramètres de la vue
- approche full java
- les entités ont un moteur comme GORM en Grails mais plus simple. Cela permet d’avoir des finders comme méthode statique sur l’entité Hotel. C’est cependant statique et plus limité que Grails/GORM.

Inconvénients de Play! Framework :

- le controller de base étend une class de Play! (si la spécialisation vous dérange plutôt que la composition)
- la gestion des workflows compliqué demande un effort de développement par rapport à Spring WebFlow, qui sera capable de retomber sur ses pieds.

IV. La Vue

Je vais maintenant évaluer plusieurs critères :
- la création d’une page pour chacune des technos
- la qualité de l’expérience utilisateur avec l’utilisation d’Ajax
- la taille des pages webs et les temps de chargement

IV.1) Créer une page avec Spring Faces

Basé sur JSF, cette partie sera donc essentiellement une discussion sur JSF plutôt que sur Spring. Je parlerai un peu de la taglibs de Spring pour la partie validation du côté client, que je trouve très bien fait. Mais l’essentiel du débat porte plus sur JSF ici.

Dans le projet Spring Webflow, les pages sont construites à partir d’un template, avec la technologie Facelets. Très pratique, cela vous permet de construire le canevas de votre site, puis de spécialiser vos vues en écrivant peu de code.

Le template standard.xhtml :





	
	Spring Faces: Hotel Booking Sample Application

	
	
		
		
		
		
		
	
	
	



	
		
			Spring Travel: A Spring Faces Reference Application
			
				
	            	Welcome, ${currentUser.name} | Logout
				
				
	            	Login

La page « reviewHotels.xhtml » avec 52 balises HTML+JSF permet d’afficher la liste des Hôtels :







	
		Hotel Results
		
			
		
		
			
				
				
					
						
							
								
							
						
						#{h.name}
					
					
						Address
						#{h.address}
					
					
						
							
								
							
						
						#{h.city}, #{h.state}, #{h.country}
					
					
						Zip
						#{h.zip}
					
					
						Action

Ce que j’apprécie à titre personnel avec JSF :
- possibilité d’écrire du code de mise en forme sans avoir besoin de faire trop de CSS
- moteur de construction de page assez proche d’une vue client lourd
- possibilité d’écrire avec la syntaxe JSF et d’avoir un rendu riche sans se prendre la tête avec du Javascript ou des feuilles de style.
De toutes les façons, je suis pas développeur Web. Donc mort aux CSS…

Ce qui me fait un peu tiquer, c’est que l’on dit au développeur Java : tu n’auras pas besoin d’apprendre à faire une mise en page compliquée en HTML et CSS…

Mais bon, vous vous foutez pas un peu de nous là ?

La page demande 52 balises. Et ce dataTable pourrait très bien être un simple TABLE en HTML avec une CSS non ? Ce qui d’ailleurs est le cas au final non ?

IV.2) Créer une page avec Play! Framework

Attention cela pique les yeux. Comme JSF ou Wicket, vous pouvez utiliser un éditeur HTML pour construire votre page. En effet, le format des pages de Play! Framework est très original puisque c’est du HTML ni plus, ni moins. Il y a cependant l’utilisation de Groovy qui risque de faire peur à quelques uns. Je note cela comme un inconvénient par rapport à JSF.

La version livrée avec Play! utilise jQuery et Ajax à fond. Il y a en fait une page principale, puis un ensemble de fonction Javascript pour ne charger rapidement que ce qui change dans un DIV au format HTML. C’est radicalement différent, et peut-être moins facile d’abord pour des gens n’ayant jamais fait de Web. Je vous montre donc plutôt ici ma version « gars qui a fait du Java et du Web et qui découvre Play »

Play! Framework dispose aussi d’un moteur de template. Je vais donc vous montrer 2 fichiers. Le fichier main.html est un template de base que j’utilise pour le site :




    
        #{get 'title' /}
        
        
        #{get 'moreStyles' /}
        
        
        
        #{get 'moreScripts' /}
    
    

        
            play framework booking demo
            #{if user?.id}
                
                    Connected as ${user.username}
                    |
                    Search
                    |
                    Settings
                    |
                    Logout
                
            #{/if}
        

        
            #{if flash.error}
                
                    ${flash.error}
                
            #{/if}
            #{if flash.success}
                
                    ${flash.success}
                
            #{/if}

            #{doLayout /}

        

        
            Created with play framework and really inspirated from the booking sample application provided by seam framework

Voici la page qui affiche la liste des Hotels. Le fichier s’appelle « list.html » comme le nom de la méthode list du Controller Hotels que nous avons vu plus haut. Il est bien entendu possible de déclarer un nom différent et de configurer une autre route avec Play! Framework.

Le fichier est assez simple : il reçoit un objet List, il itère en Groovy avec un tag spécifique à Play et il affiche le résultat dans un tableau HTML :

#{extends 'main.html' /}
#{set title:'Search result'/}

#{if hotels}

    #{list hotels, as:'hotel'}
    
    #{/list}
    
    
    
        Name
        Address
        City, State
        Zip
        Action
    
    
    
        ${hotel.name}
        ${hotel.address}
        ${hotel.city}, ${hotel.state}, ${hotel.country}
        ${hotel.zip}
        
            View Hotel
        
    


    More results

#{/if}

#{else}

    No more results

#{/else}

Name	Address	City, State	Zip	Action
${hotel.name}	${hotel.address}	${hotel.city}, ${hotel.state}, ${hotel.country}	${hotel.zip}	View Hotel

La version Play! est très dépouillée. L’inconvénient : il sera nécessaire dans les 2 cas (JSF comme Play!) d’apprendre la technologie de rendu et les tags pour travailler efficacement. Mais Play! n’est pas orienté composant comme JSF. Il n’y a pas d’utilisation de l’Expression Language, ici c’est Groovy. Ce moteur Groovy est un poil plus lent que Japid, un autre moteur Java qui est disponible pour Play!

Regardez aussi la liste des modules de Play! Framework. Il y a du lourd comme le support de Scala, le moteur NoSQL MongoDB, Guice, GWT ou le module Search avec Lucene (comme Hibernate Search en plus simple).

Un inconvénient de Play! pour les personnes qui n’ont jamais fait de Web : la mise en page et la partie CSS. Lorsque je monte un projet avec Play! Framework, j’utilise par exemple CSS 960 grid system. Je connais ces systèmes car j’ai un gros background Web. Pour le CSS, pour sélectionner des couleurs qui ne font pas vomir l’utilisateur, j’ai pleins d’outils comme Kuler d’Adobe pour préparer des styles… Donc pour moi qui suit très Web : je peux faire un truc joli avec Play! Framework. Je pourrai styliser mes tableaux sans soucis. Je pense que ce qui est bien avec JSF, c’est que cela vous aide à monter vos pages facilement, à construire vos formulaires ou vos tableaux sans devoir devenir une bête en HTML/CSS. Mais c’est un peu dommage, lorsque l’on voit le potentiel d’HTML 5 pour les années qui viennent.

IV.3) Expérience utilisateur

J’ai lancé les 2 applications et j’ai effectué une comparaison en tant qu’utilisateur. Je donne l’avantage à la version Spring Faces. Je trouve que la librairie de Spring de validation du côté client est très sympa.

En terme de rapidité, la version Play! Framework est vraiment plus réactive. Si je clique comme un dingue avec un script Selenium, la version Spring WebFlow est à la peine alors que la version Play! se tourne les pouces sans s’essoufler.

IV.5) Taille des pages Webs

La page d’affichage de la liste des Hôtels sur Spring WebFlow (cliquez sur l’image pour l’afficher en grand) :

La version Play! Framework :

Mes tests avec YSlow en effectuant 10 chargements de la page puis en prenant la moyenne :

Moyenne des temps de chargement de la page liste des Hotels pour 10 hotels:
- Play! Framework en mode Dev ou Prod : 0,234 secondes
- Spring WebFlow avec Jetty : 1.286 secondes
- Spring WebFlow avec Tomcat 6.0.20 : 1.092 secondes

Le mode Prod de Play! ne prend qu’un peu plus de temps à démarrer, mais je n’ai pas constaté de différence une fois le serveur lancé.

Volume de la partie HTML sans CSS/Images et temps de chargement :
Si je ne regarde que la partie HTML sans prendre en compte le temps de chargement des images, je teste réellement que la partie serveur.

Play! Framework : chargement de 3.1 kb en un temps moyen de 14ms
Tomcat+Spring : chargement de 14kb en un temps moyen de 52 ms

Donc pour un affichage similaire, vous voyez le souci ? la version Spring Faces de cette démonstration est 5 fois plus lourde et demande 4 à 5 fois plus de temps. Je ne dis pas qu’en général c’est le cas, mais pour notre exemple oui c’est le cas. Et nous sommes sur le même cahier des charges : afficher dans un tableau une liste d’Hôtel.

V. Conclusion

Si vous avez pris le temps de lire cet énorme article jusqu’au bout, merci. Revenez voir le code des deux version en détail. Téléchargez chacune des versions et donnez vos propres arguments techniques en faveur de l’un ou de l’autre.

J’ai envie de taper du poing sur la table : il est temps de revoir le développement Web en Java.
Le développement Web demande des compétences. Si vous ne les avez pas, ne prenez pas une techno pour couvrir vos lacunes. Apprenez à faire du Web. Désolé, le XML ne m’excite pas. Play! est plus facile à apprendre que toute la stack Spring que je vous ai présenté. Car elle est plus simple et tout aussi puissante.

Pour construire une application Web compliquée ou d’entreprise, est-ce que dans 5 ans nous ferrons toujours du JSF ? ou est-ce que nous ferrons du HTML+CSS+jQuery ? Je pose la question. Evidemment, Play! Framework doit encore faire ses preuves et on peut me retourner l’argument. Mais c’est plus simple, plus réaliste et plus facile à maintenir.

Le point faible de Play! par rapport à un framework comme Spring Faces+Spring WebFlow+JSF c’est qu’il faut plus d’efforts pour construire ses composants dans la partie vue. D’un autre côté, lorsque vous avez un framework aussi puissant que JSF, vous avez envie de prendre des tableaux avancés, des richTables, ou des composants plus puissants. Cela entraîne parfois le risque de prendre des composants qui font trop par rapport à un tableau simple. D’ailleurs, si vous ne preniez pas ces composants, quel intérêt à utiliser une librairie JSF ? Je pose la question.

Un risque est donc d’utiliser des composants riches trop facilement dans une application Web avec JSF. Vous vous retrouvez avec un tableau avec des colonnes triables, alors que vous n’en n’avez pas besoin. Et votre page pèse 15-20kb au lieu de peser 2-5kb, et demande de la mémoire et du CPU du côté serveur.

Le site « eXpress-Board » tourne sur la même machine que le blog « Le Touilleur Express » avec 3 parts chez Gandi, soit 768Mo. Le process Java tourne avec 128 Mo de mémoire, et prend entre 5 et 16% de l’utilisation de la machine, bien loin de MySQL qui est très sollicité par WordPress pour le Blog.

Je vais me faire taper par les maîtres Javas qui ne vont pas être d’accord. Mais c’est la première fois où j’en ai rien à faire, car je suis sûr de mes arguments.

Allez SuperTroll, sort du bois, je t’attends.

On va bien s’amuser…

Java et les frameworks Webs : une longue histoire compliquée

Nicolas Martignole — Sat, 01 May 2010 21:45:38 +0000

Crédit photo michael.heiss Licence Commons Creatives 2.0

Imaginons que vous êtes votre framework Web Java favori… Disons que vous habitez dans une maison, qui représente votre framework Web Java.

Fermez les yeux… visualisez une petite usine qui fume avec 345 tuyaux, plusieurs portes d’entrées, des grillages à certains endroits, une pelouse fatiguée, un panneau « Attention, Chien Dangereux (et Con)« , des panneaux solaires qui ne sont pas raccordés, un autocollant « Java 7 Rulez » et des empilements de briques… Il y a souvent des coupures, des problèmes d’allocations de ressources, des débordements de pile. Lorsque vous voulez fermer les volets, vous devez relancer le groupe électrogène. Pour ajouter une chambre supplémentaire, vous avez fait poser une extension sur le toit…

Un jour, un gars vient sonner chez vous. Vous ouvrez la porte et il vous dit : « Bonjour, moi je m’appelle PHP, j’ai l’air moins sérieux que toi, mais je fais tourner de gros sites Webs« . Et toi, tu le regardes comme un hippie Baba-Cool bien gentil, mais au final tu lui lances un « t’es incapable de monter en charge« .
Vlam, tu refermes la porte.

Le lendemain, un autre gars vient te voir et te tape sur l’épaule : « Bonjour, moi c’est Ruby on Rails. Je t’éclate en productivité et en plus mes développeurs s’amusent« . Là tu lui ris très fort au nez et tu lui dis : « Ouais mais Ruby c’est pas comme le Latin ? Une langue morte ?« . Vlam, et tu lâches le chien pour voir s’il a vraiment des soucis de montée en charge.

Le surlendemain, un mec qui semble avoir fumé un arbre sonne à ta porte. Il porte un teeshirt « NE TIREZ PAS : JE TOURNE SUR LA JVM ».
C’est Mr Grails.
Fier comme un pape : « Salut, moi c’est Grails. Je suis enfin là pour t’apporter de la productivité, je suis en Groovy et je tourne sur la JVM… Gentil… pas tirer…« . Et toi de répondre : « Grails c’est pas si performant en production, il faut apprendre Groovy, et en plus tu portes un teeshirt moche« . Le gars a juste le temps de reculer lorsque tu refermes la porte.

Quelques jours plus tard, un gars en costard-cravate, look banal, sonne à ta porte… « Salut, moi c’est JSF2. Je suis un standard, j’ai plusieurs implémentations possibles, je suis là pour tuer Struts2. Comme je suis un standard, je suis bon pour toi et pour ton CV. Par contre pour avoir des composants intéressants il faudra que tu prennes RichFaces/IceFaces ou autre. Et pour ce qui est du REST, on prendra mon pote JAX-RS… et pour la mise en prod on prendra le serveur Trucmuche de 80mo… et blablablabla…« .
Bon là c’est facile, le bonhomme se taille en 4 tout seul. Refermons la porte poliment et retournons à TéléFoot.

Licence Commons Creatives, crédit photo Kenichi Nobusue

Quelques idées sérieuses
Le développement Web fait-il partie du génome des développeurs Java ?
Autant PHP me semble fortement lié à une culture Web, autant Java n’est pas forcément associé au Web. Lors des présentations de Play! Framework, Nicolas Leroux et Guillaume Bort demandaient à la salle du Paris JUG :
Qui est développeur Web ?
Quelques mains timides se lèvent sur les quelques 450 personnes présentes. Guillaume demande ensuite qui a déjà fait des JSPs ou des Servlets. Et là, presque tout le monde lève sa main… Donc si nous comprenons bien ce qui se passe, vous n’êtes pas développeur Web, mais pourtant vous faîtes des JSPs, des Servlets et du Struts…
Ce qui est dommage si nous continuons sur cette idée, c’est que du coup, vous n’avez pas forcément de connaissances en HTML, en CSS, en JavaScript. Si je vous dis que le protocole HTTP est sans état, cela vous semble-t-il alors normal de voir des frameworks massivement avec état, comme le principe même de JSF par exemple ?

Le Web est un vaste espace documentaire. Chaque ressource doit disposer d’une adresse unique, d’une URI. Les répertoires virtuels d’un site doivent être autant de conteneur, pour classer et ranger vos objets, par catégorie. Le protocole Web dispose depuis 15 ans des verbes d’action pour manipuler les documents : GET,POST,DELETE et PUT essentiellement. Saviez-vous que JSF 1.x ne faisait que des POSTs pour échanger des données avec le serveur ? Qui imagine avoir des URLs bookmarkable avec ce type de framework ?

Chaque URL affichée par votre navigateur représente finalement une vue. Les premiers frameworks du monde Java, Struts 1.x pour n’en citer qu’un, ont été construit par dessus l’API des Servlets. Intéressant, lorsque l’on pense qu’une Servlet ajoute la notion de session du côté du serveur, concept qui va rendre la vie des développeurs Javas un peu plus compliqué que prévu. Tout d’un coup, un navigateur qui n’est pas connecté au serveur Web en permanence, demande au serveur de maintenir une session. Le concept magique de session, qui permet d’acheter des oiseaux dans un magasin, devient la référence pour les développeurs Webs. Cette démonstration a eu l’effet d’un lampadaire sur les moustiques : tout le monde a plongé dans le monde formidable de la session. J’y reviens plus loin dans quelques lignes.

Le jour où Gavin King a annoncé Seam, il explique entre autre avec fierté que son framework gère le bouton « Back » du navigateur… Chose qui me semble normal, et que nous savions gérer en 1997 avec du Perl, et un peu d’huile de coude.

La session dans les frameworks Webs Java est un objet assez mal compris. L’implémentation de certains frameworks Webs, que j’appelle « avec session » comme Tapestry, Struts ou Wicket, utilisent un Cookie pour identifier la session du navigateur avec une session en mémoire sur le serveur. Ce ticket permet de stocker sur le serveur des objets volumineux. Je vois alors le framework Web comme une sorte de Mont de Piété. Vous déposez vos valeurs, on vous donne un ticket. Lorsque vous revenez, vous récupérez alors vos valeurs, votre session contre ce ticket. Ce mécanisme est nécessaire car il n’est pas souhaitable de sérialiser vos données et de les passer au client. Le souci : cela entraîne une consommation de mémoire du côté serveur car le développeur Java aura tendance à mettre en session tout et n’importe quoi.

Il y a eu une tentative de faire travailler le navigateur Web, et de lui donner alors toutes les données de session. L’avantage ? Les Serveurs sans état peuvent alors être monté en cluster, et le navigateur passe les données de session de page en page. Cela fonctionne avec de la réécriture d’URL lorsque vous faîtes des GET ou en postant les données dans des champs cachés si vous faîtes du POST. Cela marche très bien, c’est le principe d’eBay. Il y a cependant quelques limitations, comme la taille des URIs par exemple. Vous ne vous êtes pas demandé quel serait la taille maximale d’une URI ?
Avant tout, la RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) précise dans la section 3.2.1 qu’il n’y a pas de limite sur la taille d’une URI. En théorie, il serait donc possible de passer des données de session énorme. Dans les faits, c’est faux. Internet Explorer ne dépasse pas 2083 caractères, Firefox pousse jusqu’à 65565 caractères. Mais les serveurs Webs comme Apache limitent à 4000 caractères par défaut, comme parfois les proxy qui se chargent de faire de la redirection ou du load-balancing.

En général, les frameworks Webs évitent d’avoir une notion de session qui coûte de la mémoire côté serveur lorsque celle-ci n’est pas indispensable. Les frameworks Javas ont proposé très tôt ce concept de Session. Pour monter plus de Sessions, il faudra souvent avoir plus de mémoire. Personne n’aura expliqué au développeur Web Java comment calculer la taille de sa session.

Il y eu ensuite le souci de la durée de vie des Sessions. Soit aucune session, proche des EJB stateless, soit avec une session, on pense aux EJBs statefull. Mais ce concept métier ne fonctionnait pas bien avec le Web. Lorsque les premières architectures Webs pour la partie vue ont commencé à discuter avec des architectures métiers écrites sur la base des EJB 2.x, ce fut assez amusant. Pour que le monde du Web puisse afficher des données sur plusieurs écrans successifs, il fallait les stocker dans le « Web Tiers ». Nous avons utilisé des DTO, représentant des données venues de la partie métier. Puis quelqu’un a dit un jour que la séparation entre le Web tiers et l’EJB Tiers était une grosse bêtise inventée par des vendeurs de machines. Et nous avons tué cette idée aussi rapidement qu’elle s’était diffusée. Je rigole pas trop fort car je connais encore beaucoup de systèmes en production avec un tiers Web, et un tiers EJB. Il y a un firewall entre le monde extérieur et le Web tiers. Puis un deuxième firewall entre le web tiers et l’ejb tiers. Bien entendu, 4 machines pour le tout, afin de faire du load-balancing… J’imagine le sourire du commercial qui a vendu les machines à l’époque.

Seam a introduit le concept de conversation. En décembre 2006 j’en parlais avec passion. Cela a été repris dans CDI, dans JEE6. Et le concept de conversation Flash est aussi maintenant partie intégrante de Grails ou de Play! Framework par exemple. Preuve qu’il est possible de gérer de manière fine la durée des sessions.

Tout ceci pour dire que je crois que les frameworks Javas et le monde Web ne se sont pas vraiment compris. Nous avons souvent une complexité culturelle avec Java, qui n’est pas nécessaire lorsque l’on fait du Web (idée de Guillaume Bort, auteur de Play! Framework). Les développeurs Javas que je connais, même les meilleurs, n’ont pas nécessairement la culture Web. Avoir une culture Web pour moi, c’est connaître le protocole HTTP, HTML, CSS, REST et les possibilités des architectures sans états. Ce n’est pas imposer une vision middleware, qui ne fonctionne pas avec le Web. C’est certainement une chose sur laquelle nous devons encore travailler, nous qui sommes développeur Java. Le jour où SUN Microsystems, IBM et HP ont décidé que pour vendre de la machine, il fallait de la complexité, nous aurions dû faire attention. Pourquoi les autres langages comme PHP, Python, Perl ou C# ont-ils des frameworks Webs digne de ce nom ? Parce qu’ils n’ont pas cherché à en faire une longue histoire compliquée. Parce qu’ils ont respecté HTTP pour ce qu’il était, sans essayer une danse du ventre pour séduire les développeurs, pour finalement les planter quelques mois plus tard. Que celui qui n’a jamais entendu un AdminSys râler à propos de Tomcat et des serveurs d’applications lève la main…

J’écris cela car je pense que le Web et Java ont encore des efforts pour se comprendre. Je ne suis pas extasié devant GWT, inventé pour masquer la complexité de JavaScript. Je ne suis pas impressionné par Apache Wicket qui permet de coder « à la Swing » dans un monde massivement orienté objet une application Web, qui n’a que faire de l’orienté objet. Je ne suis pas impressionné par JSF 2 qui a rattrapé le retard, mais qui dispose de plusieurs implémentations, qui demande le support d’une librairie externe pour faire de l’AJAX, et qui demande des librairies pour faire de l’orienté composant…

Je suis impressionné par contre par la créativité des développeurs Javas, qui cherchent parfois à faire du client lourd dans un navigateur, en appelant cela « un client léger ». Bon sang, une application Web n’a rien à voir avec la vision à papa, avec des fenêtres et des boutons qui font pouet-pouet… Prenez dans ce cas une techno comme Flex par exemple, pour faire un client déporté

Je pense qu’il est temps de faire simple. Les vraies architectures Webs c’est pour maintenant. Allez lire sur le blog de Guillaume Bort pourquoi Play! Framework n’est pas basé sur l’API Servlet. C’est très intéressant.

Merci de penser que Java et les frameworks Webs c’est simple.

L'utilité de Twitter pour les Geeks

Nicolas Martignole — Sun, 18 Apr 2010 16:00:37 +0000

Tout le monde se demande bien ce que l’on peut trouver à Twitter. Je ne sais pas si j’ai compris, mais en tous les cas, je peux au moins partager mon expérience. J’ai installé Twitter il y a 18 mois, sans franchement avoir une idée de son utilité. Le concept est simple : c’est un mégaphone placé dans les oreilles des gens qui souhaitent vous écouter. Pour peu que votre vie soit un peu intéressante, Twitter peut rendre de grands services, et surtout vous distraire.

Premier principe : les « followers » sont des personnes qui s’abonnent à votre canal de diffusion Twitter. Plus vous avez de followers, plus vous êtes populaire. Cela me rappelle une phrase d’Audiard : Lorsque les gens d’1m80 parlent, ceux d’1m60 écoutent…« . Là c’est un peu la même chose : lorsque les gens avec 1000 followers parlent, ceux avec 30 followers écoutent….

Twitter n’est pas un logiciel. C’est un service sur Internet. La société Twitter a ouvert l’API, ce qui a permis à beaucoup de développeurs d’implémenter différents logiciels. Sur Mac j’utilise Tweetie comme sur iPhone. Il a l’énorme avantage d’avoir un affichage par conversation, très pratique pour suivre le message d’origine lorsque quelqu’un vous répond. J’ai laissé tomber Nambu, mais c’est un bon client Mac. Sur Windows, TweetDecks est pas utilisé par les personnes que je followe. Il permet par exemple d’ajuster son rate d’updates Twitter par canal de diffusion : Mentions, DM, New Followers, Lists.
La liste des applications est longue (Tweetr, Twibble, Seesmic). Je vous conseille de tester plusieurs clients.

J’utilise essentiellement Twitter sur mon iPhone. C’est un moyen de se tenir informé de ce que font vos amis, vos connaissances, et les bonhommes de la communauté Java pour moi. Ce matin je lisais les soucis du pauvre Sacha Labourey (@slabourey) qui tente de rejoindre Philadelphie en partant de Suisse. Il a conduit de nuit jusqu’à Barcelone, avant de prendre un avion de Barcelone à Madrid, puis les USA. On peut suivre aussi les conférences et se faire indiquer les sujets intéressants, tout comme les casseroles à éviter.
Lorsque James Gosling a quitté SUN, nous l’avons su quelques heures plus tard, via Twitter. Je cherchais ce matin le nom de la voiture électrique très sportive, je pose la question sur Twitter, 12 personnes répondent. C’est la Tesla Roadster, une voiture qui passe de 0 à 100 en 3.9 secondes, fabriquée par Lotus en Angleterre puis équipée d’un moteur électrique par Tesla aux USA. Cette petite vidéo vous montrera les capacités de la bête.

Twitter et d’autres services
Un grand nombre de services s’est lancé, afin de proposer des concepts au dessus de Twitter. Le site Twitgraph.com par exemple vous permet de regarder quelques statistiques sur votre activité sur Twitter. Le site Foamee vous rappelle lorsque vous devez une bière à quelqu’un. Tweeple Twak permet de suivre le nombre de gens qui arrêtent de vous suivre. Pratique pour les comptes Twitter « pro ».
Le site Twitterank est un peu le Top 50 de Twitter, avec des indications sur la popularité de votre compte.

Les sites de statistiques permettent de visualiser quelques statistiques comme la fréquence à laquelle vous Twittez sur Twitter Analyzer. Mon préféré est le site TweetStats. Il donne des indicateurs précis sur la fréquence d’utilisation de Twitter, qui vous retweeter le plus, les mots clés que vous utilisez le plus.
Voici par exemple mon hashtag cloud :

Enfin si vous souhaitez voir quels sont les personnes que vous suivez, qui ne vous suivent pas en retour, un petit clic sur FriendOrFollow et vous aurez la réponse à votre question.

Références :
Une longue liste de services Twitter pour aller plus loin
69 Twitter Web Services you should know la liste complète et à jour des services pour Twitter.
Twitter le site officiel.
19 Twitter Desktop Apps Compared pour trouver une application pour votre PC ou votre Mac.

Crédit photo : CarrotCreative sur FlickR. Photo en licence Commons Creative.