In Fine, en tant que partenaire de l’évènement majeur qu’est Devoxx France, a le plaisir de mettre à disposition une application pour Devoxx France sur Android. Cette première version permet :

• De mettre en favoris vos sessions préférées
• De consulter le planning des sessions, et le détail des speakers
• De voir ce qui se passe sur Twitter avec le tag devoxxfr
• D’avoir accès au plan des 2 étages de l’hôtel où se déroulera la conférence
• Et d’autres fonctionnalités…

Cette application fonctionne parfaitement sur téléphone , mais n’est pas encore totalement adaptée pour les tablettes. Dans les semaines qui viennent, nous allons continuer à mettre à jour l’application pour qu’elle soit la plus simple à utiliser possible. Voici une prévision des futures évolutions :

• Complète adaptation de l’ergonomie de l’application aux tablettes
• Ajout de la recherche sur les speakers. Actuellement elle ne fonctionne que sur les sessions
• Quand on clique sur une salle, afficher la carte de l’étage correspondant
• Pouvoir mettre en favori des speakers
• Et bien d’autres choses qui dépendront des retours que nous aurons

Nous sommes très fiers de mettre à disposition cette application. Elle sera mise en open source au moment de la conférence Devoxx France, certainement en licence Apache 2.
Si vous rencontrez des problèmes ou avez des suggestions, écrivez un commentaire ici, ou envoyer un mail au compte indiqué sur la fiche du Google Play Store.

Dans la suite de l’article, nous allons approfondir l’aspect technique de l’application. Si au contraire vous souhaitez directement aller télécharger l’application, alors il faut aller ici : Play Store

Architecture technique

Comme le montre le schéma ci-dessus, nous n’avons pas directement connecté l’application Android avec les API RESTful fournies par le site Devoxx. En effet les temps de réponse sont très variables, certains service ont déjà mis plus de 5 minutes à répondre. D’autre part, certains service renvoient des données en double ou incomplètes.
Le serveur intérmédiaire permet donc de mieux maîtriser les données. Grâce à Play et à Mongo DB, les temps de réponse sont excellents et la charge que peut encaisser le serveur est bien au dessus de ce que nous atteindrons. Un test JMeter a mesuré que le serveur pouvait encaisser 300 requêtes par secondes. La plupart des requêtes répondent en moins de 0.1 seconde. Nous estimons que le serveur aurait à supporter, au maximum de son activité, 25 requêtes par minute

The post L’application Devoxx France d’In Fine est disponible sur le Google Play Store first appeared on In Fine - Le Blog.

Cette première grosse journée pour Devoxx a été l’occasion de faire différentes annonces. La première concerne le framework Play et la deuxième concerne le monde Java français.

Play

La version 2.0 de Play a déjà été annoncée il y a plusieurs semaines. Une pré-version de test avait été mise à disposition. Aujourd’hui la sortie de la beta a été annoncée.

Lors de la présentation faite par Sadek Drobi (@Sadache) et Guillaume Bort, les nouveautés ont été détaillées :

• Intégration de Scala directement dans Play : les templates ne se feront plus en Groovy mais en Scala. Les classes pourront être faites en Java ou en Scala. Cela a pour conséquence la mise à disposition de la console Scala qui permettra, par exemple, d’appeler directement du code applicatif à parti de la ligne de commande.
• Un système de build est désormais intégré, il s’agit de SBT (Simple Build Tool). Ce choix est certainement la conséquence de l’intégration de Scala. Cela remplacera l’ancien système basé sur Ivy.
• Intégration d’Akka
• Les scripts javascript et les feuilles de styles sont compilés

Plus d’infos disponibles sur le site officiel : http://scala.playframework.org/2.0

L’autre annonce est que Play intègre désormais la stack Typesafe. Cela signifie que Typesafe fournira du support sur Play. De plus Guillaume Bort va désormais siégé au board of advisor de Typesafe (Je ne sais pas comment le traduire, conseil d’administration ?) en tant que conseiller sur les choix techniques web d’après ce que Guillaume a dit durant sa présentation.

Devoxx France

Une version française de Devoxx se tiendra du 18 au 20 avril 2012 à Paris ! Elle est inspirée du modèle belge et elle durera 3 jours et sera à 75% en français et 25% en anglais. Elle est organisée par les membres du Paris Jug (Antonio Goncalves, Zouheir Cadi, José Paumard et Nicolas Martignolle). Ce sera la plus grosse conférence Java francophone, venez nombreux !
In Fine sera bien entendu partenaire de cet évènement.
Plus de détails sur le blog de Nicolas Martignolle.

The post Devoxx 2011 – annonces first appeared on In Fine - Le Blog.

Je suis devenu un adepte du framework Play!. Je ne le pratique pas depuis longtemps, seulement depuis 10 mois environ. Mais la courbe d’apprentissage est vraiment rapide. Une semaine est suffisante pour être à l’aise et être autonome. J’ai la modeste prétention, dans cet article, de montrer 2 ou 3 trucs qui font de ce framework une nouvelle manière de voir le web en Java.

Pour commencer, Play! est très simple à installer. Il suffit de décompresser le zip dans un répertoire, et de créer une variable PLAY_HOME qui pointe sur ce répertoire. Play! a uniquement besoin de Java comme pré-requis pour fonctionner. Et c’est tout ! Pour rappel, la plupart des autres frameworks web Java ont au moins besoin d’un serveur d’application…

Comme Play! embarque un serveur web, il se suffit à lui-même. Cette notion est appelée “full-stack”. Elle signifie que Play! est autonome à la fois dans son mode de développement en proposant tout ce qu’il faut pour faire une application web, de la couche présentation à l’accès aux données, et également lors de l’exécution des applications Play! qui tournent grâce au serveur web intégré.

Play! propose de nombreuses fonctionnalités peu répandues dans le monde du web en java. Par exemple, le code modifié est pris à chaud par le serveur web, il suffit de rafraîchir le navigateur pour voir sa modification ! La gestion d’erreur est également poussée. Lorsqu’une exception se produit, l’erreur s’affiche très clairement dans le navigateur. Comme le montre l’image suivante :

Le développement rapide est une des caractéristiques de Play! On passe beaucoup plus de temps à coder qu’à faire de la configuration ou de l’installation. Et ce n’est pas tout, Play! propose beaucoup de moyens d’accélérer le développement. Je vais donc vous en montrer quelques uns. Je ne compte pas énumérer tout ce qui fait que Play! permet de développer rapidement, mais seulement donner un aperçu.
Play! propose sur son site, une documentation très complète, ainsi qu’un tutoriel bien fait qui permet de se familiariser avec les notions principales du framework. Si on peut paraître sceptique devant tant de d’enthousiasme, faire le tutoriel permettra à quiconque de se rendre compte de la rapidité avec laquelle le développement se fait avec Play!.

Arborescence

Ceux qui connaissent Ruby on Rails et Grails ont déjà les bases pour Play!. Par exemple, l’arborescence des répertoires est très similaire :

Les répertoires ont des noms explicites, par exemple le répertoire public permet au serveur web de renvoyer des ressources directement, telles que des images ou des scripts.
Le répertoire conf contient les fichiers de configuration comme son nom l’indique. Par défaut, Play! en crée trois :

• Un pour l’application de l’application et du serveur web
• Un pour définir les URL de l’application
• Un dernier contenant les messages de l’application

D’autres fichiers de configuration peuvent être créer dans ce répertoire, notamment pour chaque langue gérée par votre application.

La puissance dans le fichier de configuration

Application.conf est un fichier similaire à un fichier properties. Il est créé par Play! lors de la création d’une application. Il contient plein de valeurs essentielles pour configurer le serveur web, telles que le port à utiliser, le nom du cookie. Il contient également des propriétés permettant de configurer l’application comme la base de données, la configuration JPA, du cache…

Le gros avantage de ce fichier, est qu’il peut être l’unique fichier de configuration de l’application, et ce quel que soit l’environnement sur lequel est déployé la web app ! En effet Play! intègre un système qui permet de surcharger des valeurs dans le fichier de configuration. Lors du lancement de l’application, il suffit de préciser un paramètre supplémentaire sur la ligne de commande pour choisir les propriétés à appliquer. Comme ce n’est sûrement pas clair, voici un exemple :

%integration.application.mode=dev
%production.application.mode=prod
application.mode=dev

Le fichier ci-dessus est un extrait d’un fichier de configuration application.conf. Il contient 3 fois la même propriété nommée application.mode. Certaines sont suffixées ce qui permet de donner une valeur précise selon si l’application est lancée en intégration ou en production. Par défaut, la valeur sera celle de ligne 3 si le paramètre n’est pas indiqué. C’est super pratique et très bien pensé !

Le rechargement à chaud du code et de la conf

La propriété que j’ai montré dans l’extrait du fichier application.conf dans le paragraphe précédent, est une clé très spéciale, qui permet encore à Play! de se distinguer. Elle permet d’indiquer au framework que l’application est en mode développement ou production. La distinction est très importante pour le développeur, et pour la sécurité de l’application.

Le mode dev permet au développeur un gain de temps maximum. Lors du développement, un changement sur un fichier de code ou de configuration sera pris à chaud par le framework. Un rafraîchissement de la page du navigateur, et c’est pris en compte ! C’est tout simplement du bonheur de développer dans ces conditions.
Le mode production interdit, bien entendu, le rechargement du code à chaud, mais il permet également de précompiler les fichiers java et les fichiers de templates (qui sont les fichiers permettant l’affichage des pages web). Les performances sont donc meilleures en mode production qu’en mode développement.

Sans état !

Play! est un framework sans état. Cela signifie qu’aucune session n’est conservée du côté du serveur. Cette philosophie est à l’opposée de la plupart des frameworks java bâtis sur la norme servlet. Cela permet à Play! de se rapprocher de la philosophie initiale du protocole HTTP où chaque requête est indépendante de la précédente, donc sans état. Le framework sait qui effectue la requête grâce au cookie.
Du côté serveur, il faut donc repenser sa manière de gérer les requêtes sans état. Par exemple, si des objets doivent être stockés pour être utilisés lors des requêtes suivantes, il faudra utiliser un cache ou la base de donnée directement. D’ailleurs à propos du cache, Play! intègre un cache directement basé sur EhCache.
Le fait que Play! soit sans état permet d’avoir une architecture scalable. Cela permet aussi au framework de gérer très facilement les requêtes de type REST qui sont également des requêtes sans état.
Encore une bonne raison d’essayer Play!.

Exemple d’URL de type REST

Allez, je vous donne un exemple de REST implémenté dans Play!. L’exemple suivant permet d’effacer une personne de l’application.
L’unique page de l’application affiche une liste de personnes. La seule action possible est d’en effacer une :

Le fait de cliquer sur le lien delete appelera une URL définie dans le fichier de configuration routes dont voici l’extrait concerné :

DELETE        /person/{id}         Application.deletePerson

Ce fichier définie une URL de type REST. Elle signifie qu’une URL de type /person/348 avec la méthode HTTP DELETE appelera la méthode Application.deletePerson avec le paramètre 348.
Lorsqu’on affiche la page d’accueil, la log indique :

21:00:57,315 INFO  ~ URL called : GET localhost/

Ensuite, une fois que nous cliquons sur le lien delete :

21:06:24,937 INFO  ~ URL called : DELETE localhost/person/2

Evidemment, l’affichage des personnes fonctionne tel qu’attendu :

Le code java est extrêmement simple. Voici la méthode affichant l’URL et la méthode HTTP pour chaque requête HTTP :

@Before
static void printHttpInfos() {
	Logger.info("URL called : %s %s", request.method, request.domain + request.path);
}

Et voici le code java permettant la suppression d’une personne :

public static void deletePerson(long id) {
	Person.<Person> findById(id).delete();
	index();
}

Je ne vais pas vous décrire ce que fait chaque ligne de code. Je voulais simplement montrer à quel point il est facile de faire des choses qui sont plus compliquées sans Play!. Encore une fois, n’hésitez pas à aller faire le tutoriel sur le site de Play!, on y apprend toutes les bases et notamment ce que je viens de vous montrer.

Les tests

Dans un framework moderne, la prise en charge des tests est indispensable, et Play! n’y échappe pas. Les tests Play! sont basés sur deux librairies très connues : JUnit et Selenium.
En lançant le serveur en mode test, les tests peuvent être lancés via une page dédiée sur l’application web. C’est très pratique pour lancer manuellement des tests via le browser.
D’autre part les données de tests peuvent être initialisées grâce à un fichier YAML. Voici le fichier utilisé pour initialiser les données du paragraphe précédent (dans mon cas je l’ai utilisé pour initialiser la base de données de mon application) :

Person(test1):
    firstName: Florian
    lastName: Boulay

Person(test2):
    firstName: Antonio
    lastName: Goncalves

Person(test3):
    firstName: Antoine
    lastName: Ramponi

Play! permet de créer 3 types de tests :

• Les tests unitaires : les classes doivent hériter de la classe UnitTest. C’est l’équivalent d’un test JUnit classique.
• Les tests fonctionnels : les classes doivent hériter de la classe FunctionnalTest. Ce sont des tests d’intégration avec l’application web.
• Les tests de validation : ce sont des tests Selenium.

Les tests fonctionnels

Je vais faire un petit zoom sur les tests dits fonctionnels.

Pour cela j’ai un peu modifié l’exemple utilisé précédemment afin d’avoir plus de cas de tests possibles. La mini application web ne comporte toujours qu’une seule page, mais elle est désormais composée de 2 listes : une liste d’employés disponibles, et une des employés d’astreinte. L’interface ressemble à ceci :

Le fait de cliquer sur on call permet de faire passer la personne d’astreinte en la mettant dans la seconde liste. Le fait de cliquer sur free permet de faire l’inverse.

Comme dit précédemment les classes de test doivent hériter de la classe FunctionnalTest. De plus, le serveur doit être lancé en mode test. Voici un exemple de test fonctionnel permettant de tester l’unique page de cette application. La première méthode teste l’état initial, c’est-à-dire les 3 personnes qui sont présentes dans la liste des employés disponibles. La seconde méthode teste le passage d’une personne de la première liste à la seconde en cliquant sur le lien on call :

public class EmployeesTest extends FunctionalTest {

	@Before
	public void setUp() {
		Logger.debug("Reloading all data");
		Fixtures.deleteAll();
		Fixtures.load("data.yml");
	}

	@Test
	public void testStartState() throws Exception {
		Response response = GET("/");
		// test the 200 status
		assertIsOk(response);
		String httpBody = getContent(response);
		assertTrue(httpBody.length() > 0);
		// test that 3 <li> are returned
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Florian Boulay.*" +
							"<li>Antonio Goncalves.*" +
							"<li>Antoine Ramponi.*" +
							"</ul>", response);
	}

	@Test
	public void testOnCallPeople() throws Exception {
		// make Antonio Goncalves on call
		Person antonio = Person.find("byFirstName", "Antonio").<Person> first();
		Response response = PUT("/person/onCall/" + antonio.id, "text/html", "");
		// test the 302 response
		assertStatus(302, response);
		String httpBody = getContent(response);
		assertTrue(httpBody.length() == 0);
		java.net.URL locationHeader = new java.net.URL(response.getHeader("location"));
		response = GET(locationHeader.getPath());
		// test the 200 response
		httpBody = getContent(response);
		assertTrue(httpBody.length() > 0);
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Florian Boulay.*" +
							"<li>Antoine Ramponi.*" +
							"</ul>", response);
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Antonio Goncalves.*" +
							"</ul>", response);
	}

}

Voici les quelques logs générées :

00:39:21,725 DEBUG ~ Reloading all data
00:39:21,777 INFO  ~ URL called : GET localhost/
00:39:22,469 DEBUG ~ Reloading all data
00:39:22,505 INFO  ~ URL called : PUT localhost/person/onCall/8
00:39:22,525 INFO  ~ URL called : GET localhost/

L’API simple

Ce qui est très agréable au quotidien avec Play! est la facilité d’utilisation des API disponibles. Je n’ai pas montré beaucoup de code dans cet article, mais vous pouvez constater la simplicité de lecture du code fait avec Play!. Cela permet comme presque tout le reste, d’avoir une marge de progression rapide, d’être opérationnel bien plus vite qu’avec d’autres framework web… Mais tout ça, je l’ai déjà dit. Je vais plutôt vous montrer quelques lignes utilisant l’API de Play!, vous pourrez vous faire une idée bien plus facilement qu’avec un long discours.

// récupérer la requête HTTP courante
Request request = Http.Request.current();

// récupérer l'EntityManager 
EntityManager em = JPA.em();

// faire un appel rapide à un web service
HttpResponse response = WS.url("http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius").get();

// récupérer toutes les entités Person (entité au sens objet du modèle de donnée)
List<Person> findAll = Person.findAll()
// compter le nombre d'entités Person
long count = Person.count();
// faire des requêtes simple sur l'entité Person
List<Person> allAntos = Person.find("byFirstNameLike", "anto%").fetch();
// etc......

Petit mot de la fin

Cet article touche à sa fin. J’aurais tellement voulu vous en montrer plus comme la validation super simple, les templates HTML, comment répondre au client en fonction du format qu’il demande (XML, JSON….), mais c’est déjà assez long. Je profiterai d’un prochain article pour me concentrer sur un aspect plus précis du framework.
J’espère avoir convaincu les quelques sceptiques à propos du framework Play!

Ressources

Site officiel du framework Play! : http://www.playframework.org/
Le google group très actif : http://groups.google.com/group/play-framework
Le repository git du code source de Play! : https://github.com/playframework/play
Le premier livre sur Play! : http://www.the-play-book.co.uk/

The post Ce que j’aime dans Play! first appeared on In Fine - Le Blog.

Mise à jour du 6 décembre 2010 :CloudBees a levé 4 millions de dollars. Plus de détails sur le blog de CloudBees.

Devoxx 2010 s’est tenue toute cette semaine à Anvers. Entre 2 présentations de Brian Goetz, Joshua Bloch ou Mark Reinhold, je suis allé voir quelques personnalités du monde java afin d’en savoir plus sur leur actualité et leurs impressions.

Stephan Janssen

Créateur du BeJUG et de Devoxx. Je suis allé le voir pour avoir quelques détails sur l’organisation d’un tel évènement.

Bonjour Stephan, peux-tu présenter Devoxx à ceux qui ne connaissent pas ?
Devoxx est une conférence annuelle qui est organisée par le Java User Group belge. C’est déjà la neuvième édition. Quelques statistiques : 3000 personnes qui viennent de 40 pays, et cela dure 5 jours à Anvers dans le deuxième plus grand complexe de cinéma d’Europe.

Comment expliques-tu le succès de Devoxx ?
D’abord le prix qui est vraiment pas cher, moins de 500€ pour 5 jours. On a aussi des rock stars qui viennent ! On a des personnes comme Joshua Bloch, Romain Guy etc. Le lieu aussi avec des écrans géants est vraiment chouette.

Penses-tu que Devoxx se déroulera ailleurs dans un futur proche ?
L’autre endroit possible est le Heysel à Bruxelles, mais le problème est que nous devons créer des salles nous-mêmes, ce qui aurait pour conséquence que le prix de l’entrée doublerait. Je préfère “less is more”.

As-tu eu le temps d’assister à quelques sessions ?
Oui, j’en ai vu quelques sessions. Ca roule bien, mais heureusement on également parleys où toutes les sessions seront diffusées.

Merci
Merci

Sacha Labourey

Après une carrière chez JBoss, Sacha a créé une société CloudBees.

Bonjour Sacha, quelle est la raison de ta venue à Devoxx cette année ?
Manger des sandwichs, et boire des coca zero principalement ! Mais surtout présenter CloudBees, ma société.

Présente nous CloudBees.
CloudBees est une société qui vit dans les nuages, et qui vise à rendre les développeurs à nouveau en contrôle de l’informatique, qui a été trop longtemps volé par ces messieurs de l’IT.
Le désir est de pouvoir faire totalement faire ses développements dans le cloud, ensuite les tests unitaires et le Q&A de manière générale, et ensuite la mise en production. Donc l’unité sur laquelle on se focalise en tant que développeur sera vraiment l’application, on ne se soucie plus du tout de l’IT, on ne soucie plus du tout de virtual machine, de java virutal machine, d’operation system, de storage, de backup, tout ça doit disparaître. On se focalise sur l’application, et nous on fera le reste.

CloudBees est uniquement destiné aux applications java ?
Aujourd’hui on est orienté sur la machine virtuelle java, ça peut être scala, jRuby ou autre chose. Aujourd’hui la majorité utilise java malgré sa mort annoncé jour après jour, c’est quand même un écosystème extrêmement saint et fort, mais rien dans l’infrastructure qu’on est en train de mettre en place en terme de process, en terme de provisionning et autre ne dépend réellement de java. C’est suffisamment générique, mais il faut choisir ses guerres, la notre c’est celle de java pour l’instant.

Pour terminer, quelles sont tes impressions sur Devoxx 2010 ?
J’ai pas encore eu le temps d’aller voir des sessions, mais je retrouve tout à fait l’esprit JavaPolis de l’époque, donc ça se passe très bien, et on est à peine mieux respecté qu’à JavaOne donc ça fait toujours plaisir.

Merci beaucoup Sacha.
Merci !

Nicolas Leroux

Nicolas est expatrié aux Pays-Bas où il travaille en tant que développeur pour la société Lunatech. Il est également un des contributeurs les plus actifs du framework Play!. C’est à ce titre que je suis allé le voir.

Bonjour Nicolas, quelle est la raison de ta venue à Devoxx cette année ?
Pour voir les conférences, faire du networking et aussi pour promouvoir Play! bien sûr.

Il n’y a pas de session sur Play! cette année, en avez-vous proposé une ?
Nous avions proposé une vraie session Play!, pas dans le BoF. Vue la concurrence acharnée qu’il y a à Devoxx, on a été refusé, c’est pas grave, l’année prochaine on réessaiera.

Play! 1.1 est sorti il y a un peu moins d’un mois, quelles sont les prochaines étapes ?
Il y en a beaucoup ! Il y a plusieurs axes de travail. Guillaume Bort est en train de travailler sur une partie qui s’appelle Evolution, qui permet de migrer ses bases de données très facilement.
Personnellement, quand j’ai cinq minutes, je travaille sur un meilleur binding entre JSON et java. Après il a plein d’autres choses à faire. Ce que j’aimerais faire, c’est un conteneur pour JBoss.
Comme c’est actuellement le cas pour Glassfish.
Erwan Loisant est train d’améliorer les librairies clientes pour faire des requêtes à des web services et Peter Hilton travaille sur la documentation

Y a-t-il une roadmap pour la version 1.2 ?
Elle est pas encore définitive, mais la roadmap peut être consultée sur le site playframework.org qui a un lien sur le bug tracker qui est Lighthouse, et là on peut voir la roadmap.

Merci Nicolas, à l’année prochaine pour une session officielle de Play!
Ou alors si vous avez l’occasion d’aller à Paris pour voir Zenexity, c’est des petits gars sympas et ils vous expliqueront tout !

The post Devoxx 2010, vu de l’intérieur first appeared on In Fine - Le Blog.