Archives du blog

Play tips – Test with an embedded mongodb

Si il y a deux outils que j’affectionne en ce moment, c’est bien Play! (v1.2.5, la v2 ne m’a pas encore convaincu) et MongoDB. Pour ceux qui ne connaissent pas Mongo, c’est une base de données NoSQL orientée document qui écrase un peu la concurrence actuellement. Pour synthétiser les points forts de celle-ci en quelques lignes (car ce n’est pas le sujet de ce billet), on vous dira que :

– MongoDb n’a pas de schéma, vous n’avez qu’à envoyer un objet en JSON, et il stocké, point barre.
– MongoDB va stocker votre objet comme un document en BSON (un encodage binaire du JSON)
– MongoDB vous donne une API javascript pour faire des requêtes, mais des drivers sont existants dans la plupart des languages.
– MongoDB est très performant. Et qu’en plus si une instance ne suffit pas en prod, vous pouvez en mettre plusieurs, et le sharding (la répartition de vos données entre les différentes instances) se fait tout seul.
– Mongo gère la réplication entre instances, mais également la consistence de votre base (ce qui n’est pas le cas de toutes les bases NoSQL) à travers un fichier de log des opérations entre autres.
Et globalement tout ceci est assez vrai. Mongo n’est surement pas la base de données ultime mais elle rend de très bons services si l’on a des choses un peu volumineuses à stocker.

Si vous avez testé Play!, vous avez surement déjà remarqué le système de persistence assez bien foutu. On annote une entité, on lui fait étendre une classe Model et ça roule. Et bien, pour MongoDB c’est à peu près la même chose.

Vous devez commencer par ajouter Morphia dans les dépendances du projet. Morphia (hébergé sous google code, si je vous jure, ça existe encore) est un petit ORM Java/MongoDB qui marche pas mal, et justement un module Play existe. on édite donc le fichier dependencies.yml pour ajouter Morphia.

 - play -> morphia 1.2.9

Un petit coup de “play deps” en ligne de commande pour récupérer le module et nous sommes prêts. Dans votre projet, prenez (ou créez) une entité, par exemple App

Si on ajoute un simple test unitaire

et qu’on le lance, le test échoue lamentablement à se connecter à votre MongoDB. Normal! Et le but de ce billet et de vous montrer comment lancer ces tests d’intégration sans installer MongoDB sur une machine. Pour cela une petite lib très pratique existe : embedmongo. Vous pouvez l’ajouter dans votre fichier de dépendances :

- de.flapdoodle.embedmongo -> de.flapdoodle.embedmongo 1.16

Nous devons compléter notre test unitaire pour démarrer une instance Mongo avant le test. La plupart des articles illustrant l’utilisation de cette librairie montre des exemples de tests unitaires où l’instance est démarrée dans une méthode annotée @BeforeClass (qui, comme vous le savez sans doute, sera executée avant les tests). Mais Play! fonctionne un peu différement puisqu’un test unitaire Play! (qui étend la classe UnitTest) démarre en fait l’application avant de lancer la classe de tests et notamment les plugins utilisés comme Morphia. Si nous utilisons une méthode annotée @BeforeClass , le test va échouer car Morphia ne parviendra pas à se connecter à l’instance embarquée qui ne sera pas encore démarrée. Un moyen simple de contournement est de créer notre propre classe de base pour les tests unitaires qui utilisera notre Test Runner plutôt que celui par défaut de Play! En fait, notre Runner va tout simplement étendre le Runner de base mais démarrera l’instance Mongo avant de démarrer Play! Get it ?

Voila donc notre classe de base de test (qui remplace UnitTest et utilise donc notre propre runner de tests)

et notre Runner, qui démarre l’instance avant d’appeler le runner de Play!

Notre test devient

Tadam! Cette fois le test fonctionne!

Enjoy!

Publicités

Un an de hype!

Après plus d’un an de blog, et 18 articles, voici le moment idéal de faire un petit résumé des thèmes abordés en 12 mois de hype!

Node
Pas mal de Node.js, peut être le sujet le plus hype de l’année, avec une série d’articles d’introduction :
Getting started with Node.js (part 1)
Getting started with Node.js (part 2)
Un complément à cette série avec la présentation du framework web Express (et mise en oeuvre avec un exemple dispo sur github) : Node, Express et Jade.
Si vous voulez coder, il faut également un IDE pratique : Cloud9 propose un outil en ligne, prévu pour faire du node.js.
Enfin deux billets autour de l’actualité de Node et de son écosystème :
Trello qui utilise Node (de façon assez étrange l’article le plus lu de l’année avec plusieurs milliers de lecture)
– La sortie d’un framework full stack : Meteor.js, assez intéressant pour son côté temps réél intégré.

Hadoop
La deuxième série d’article a été écrite pour le magazine Programmez et publiée en Septembre dernier. Hadoop est un incroyable outil, si vous voulez le découvrir :
Getting started with Hadoop (part 1)
Getting started with Hadoop (part 2)

Le site Mix-it
Une partie du succés de Mix-it de cette année est dû au site communautaire mis en place, que nous avons développé avec amour :
Le pourquoi
Le comment (avec plein d’outils sympas dedans).

Less
Ou comment le combo Less et Twitter Bootstrap va changer votre vie de développeur web : CSS sucks, do Less!

Play!
Sans avoir d’article vraiment consacré, Play! se retrouve un peu partout avec notamment un article assez lu sur l’annonce de la 2.0 beta à Devoxx :
Back from Devoxx : Play! 2, hopes and fears
Vous trouverez aussi des traces de Play! dans l’article consacré à Typesafe

Des retours de conf
De la What’s next de l’année dernière à fOSSa en passant par Mix-it (vu du côté orga, comment choisit-on les sessions)

Cast-it
Le podcast qui parle Java, mais pas que, continue! Si vous n’avez pas écouté depuis l’annonce, jetez-y une oreille, l’année fut bien remplie avec des invités locaux et internationaux (Romain Guy, Pamela Fox, Guillaume Laforge…)!

Thanks all for reading!


CSS sucks, do Less!

L’écriture d’une feuille de style est l’un des moments les plus douloureux pour tout développeur Web : la science occulte des CSS et sa verbosité en font une soupe rarement agréable à avaler. Mais un outil peut changer tout ça : Less!

Less est un preprocesseur CSS et n’est pas magique : vous devrez tout de même travailler pour avoir un style graphique convenable. Mais la où il innove, c’est par l’ajout de quelques fonctionnalités bien pratiques, et on se demande comment nous avons pu nous en passer jusque la.

Do Less

Pour démarrer, un fichier css peut être un fichier less : vous le renommez en .less et le tour est joué. Ensuite, pour utiliser ce fichier, plusieurs choix s’offrent à vous. Vous pouvez inclure less.js dans votre page web et le laisser transformer vos fichiers less en css.

<script src="less.js" type="text/javascript"></script>
<link rel="stylesheet/less" type="text/css" href="styles.less">

Ou vous pouvez compiler directement vos fichiers less en css, selon le type de votre application :
– Avec des compilateurs existants comme less.app
– Avec le module less de nodejs
– Si vous faites du Play!, vous pouvez utiliser le module prévu. A noter qu’en Play!2, le support de less est natif, la compilation se fait de façon transparente pour vous. Bref, Less commence à être connu et intégré un peu partout. Le magnifique Twitter Bootstrap par exemple, un super bootstrap css qui vous permet de faire un style sympa même sans rien comprendre à l’art obscur des css, est fait avec Less. Mais bon, Less, ça fait quoi ?

Variables

Que tout ceux qui n’ont jamais pesté pour changer la couleur d’un thème lève la main! Bon, je ne peux pas voir, mais je suis sûr que vous n’êtes pas nombreux. Tout ça à cause de l’absence de variable en CSS. Voyons un peux comment Less remédie à ce problème, et à bien d’autres… Les variables sont nos amies : c’est la première chose que l’on apprend en programmation. On se retrouve un peu démuni en CSS, avec l’obligation de copier/coller n fois la même couleur ou la taille de police, et la galère qui suit pour un changement. Avec Less, c’est fini!Si vous voulez créer un thème, après avoir repéré le code couleur qui vous faisait rêver sur ColourLovers, vous pouvez définir vos premières variables :

@body_color: #262626;
@font_color: #EAF2D9;

On peut également définir d’autres variables, telles que la taille de la police :

@font_size: 20px;

Là où ça devient intéressant, c’est que l’on peut également faire des opérations (pas n’importe quoi hein, juste des opérations mathématiques de base) :

@big_font_size: font_size + 2px;

Fonctions

Si l’on a des variables et des opérations, vous vous doutez que l’on a aussi … des fonctions ! Baptisées “mixins” elles permettent de créer des styles avec des paramètres. Exemple :  les petits bords arrondis sympas que l’on veut mettre sur tous les boutons mais qui sont définis avec des styles spécifiques à chaque navigateur, et que l’on doit répéter à chaque taille d’arrondis que l’on veut.
Less nous permet de créer une fonction border-radius avec un seul paramètre nommé radius

.border-radius(@radius){
 border-radius: @radius;
 -webkit-border-radius: @radius;
 -moz-border-radius: @radius;
}

Cette fonction peut ensuite être appelée dans votre style :

.border-radius(10px);

Et ca devient franchement cool, quand on voit que d’autres ont pris le temps de faire des fonctions à notre place, et que l’on peut utiliser ces fichiers dans nos styles, lesselements ou encore dans le Bootstrap Twitter (oui, je suis fan).

Vous n’aurez plus jamais besoin d’écrire un préfixe navigateur (voir l’excellent screencast de nettuts), et ça, ça n’a pas de prix!

Less inclue lui aussi nativement un certain nombre de fonctions portant sur le traitement des couleurs (saturate, lighten, etc http://lesscss.org/#-color-functions). Par exemple :

fade(@color, 50%);

renvoie une couleur 50% plus transparente. Cool, huh ?

Nesting

Maintenant que nous avons vu les briques de base, on peut se pencher un peu plus sur l’apparence d’un fichier .less. On a l’habitude en css de répéter pour chaque régle toute les classes concernées, ce qui devient vite très verbeux :

.share {
 ...
}
.share .name {
 ...
}
.share .tag {
 ...
}
.share .tag .price {
 ...
}

En less, on peut faire quelque chose de plus simple et plus logique :

.share {
  ...
  .name {
    ...
  }
  .tag {
    ...
    .price {
      ...
    }
  }
}

Ce nesting peut s’appliquer aussi bien aux classes, aux ids et aux éléments.
Le nesting a de plus l’avantage d’inciter a regrouper les règles, ce qui peut vite tourner à l’anarchie dans un fichier css classique (qui n’a jamais ajouté sa règle tout en bas du fichier pour aller vite …).

Import

Toujours dans l’idée d’avoir un style plus clair, il est possible de découper ses fichiers less en fichier plus petits et de faire des inclusions là où ils sont nécessaires. Ainsi, vous pouvez avoir un fichier de variables, avec les propriétés générales de l’application, couleurs, font etc… et un fichier de fonctions utilitaires que vous incluez ensuite dans vos fichiers de style.

@import "variables.less";
@import "utils.less";

Magique non ? Moi je ne peux plus m’en passer !

Il existe bien sûr des alternatives à Less telles que Sass issu du monde Ruby (excellent screencast pour le découvrir) ou Stylus, Cet article met d’ailleurs en avant les différences entre Sass et Less.

Le prochain article reprendra la mini appli nodejs des articles précédents et ajoutera un peu de style en less ! Stay tuned !

Back from Devoxx : Play! 2, hopes and fears

Le mois de Novembre est de loin le préféré des Javaistes et tous ceux qui le peuvent se rendent à Devoxx, la plus grande conférence européenne sur Java. Plutôt que de commenter chaque session vue, je vais essayer de synthétiser mes impressions sur ces 3 jours de conférences.

Devoxx c’est 5 jours, 2 d’universités et 3 de conférences, à Anvers avec 3300 développeurs. C’est beaucoup de rencontres, des gens que l’on apprécie mais que l’on ne croise qu’aux conférences, et d’autres que l’on voit pour la première fois (et que l’on tente de reconnaître des avatars twitter, avec plus ou moins de succès!). L’organisation est extrêmement bien rodée (10 ème édition) et l’équipe de Stephan fait un travail incroyable (vous imaginez servir 3300 geeks affamés pendant une semaine dans un cinéma où se déroulent 6 tracks en parallèle?).

Il y avait de nombreux sujets traités mais je vais me concentrer sur les sujets qui n’étaient pas ou peu présents l’année précédente, en commençant par Play! dans ce premier article.

Avec aucun talk l’année dernière et 3 cette année, on peut dire que Play! a fait du bruit! Nous avons notamment eu l’annonce de la beta release de la version 2.0 et du rapprochement avec la société Typesafe. Une version qui comme le laisse supposer l’intégration dans la stack de Typesafe s’oriente vers Scala, même si Java sera toujours supporté (l’animation en haut à droite de ce site vous donne une bonne idée de l’évolution).

Fears

Cette décision me gêne un peu personnellement et d’après les échos que j’en ai eu, n’est pas forcément très populaire. Vous pouvez installer cette bêta et vous faire une idée par vous même avec la documentation disponible, mais la simplicité que l’on aimait dans la version 1 disparaît un peu. J’ai attendu quelques jours avant de faire ce billet, car je voulais tester un peu par moi même et prendre la température autour de moi et sur le web. Que nous amène donc cette v2 ?

Même si il est possible de rester sur une version Java pour la partie serveur, le moteur de template est pour l’instant en Scala uniquement, alors que Groovy jusqu’à présent faisait un très bon travail en se faisant oublier. Scala amène un typage plus fort donc une détection plus en amont des erreurs éventuelles, ce qui est louable. Trois exemples d’application sont disponibles avec la bêta, et pour avoir joué un peu avec, ce changement ralentit pas mal la compilation des templates : là où on passait son temps à rafraîchir le navigateur pour avoir instantanément le résultat, on attend maintenant un peu que la compilation se fasse, malgré le fait que mon laptop (MacBook Pro) soit relativement puissant. Le système de template Groovy sera peut être sauvé par la communauté  et réintroduit.

Et Scala est certainement un très bon outil lorsqu’on le maîtrise mais il demande globalement plus d’investissement, et là ou la v1 permettait de se plonger rapidement dans le code, cette v2 inquiète un peu par sa complexification inutile. La documentation est encore un peu légère (normal pour une bêta) donc ces craintes sont peut être inutiles mais j’en doute…

La compatibilité est de plus brisée, vous ne pourrez pas upgrader votre application sans un peu de travail. Le système de build est maintenant confié à SBT, le maven-like de Scala : plus de fichier dependencies.yml donc, et l’ensemble de commande est devenu un wrapper de SBT. A voir à l’utilisation, un peu de lecture si vous voulez approfondir.

Hopes

Tout n’est heureusement pas à jeter dans cette nouvelle version! On peut noter l’utilisation d’IO non bloquant (à la nodejs entre autre), et le traitement asynchrone plus développé (concept Iteratee/Numerator issu de Haskell). L’introduction d’Akka permet de supporter une lourde charge tranquillement et le framework Play! a lui même été en partie réécrit pour en utilisant ces concepts. La démo montre que 10000 requêtes ne posent pas de problème au serveur qui monte au maximum à 15Mo de RAM, et redescend à 2Mo une fois la vague passée : impressionnant, même si les requêtes ne faisaient aucun traitement métier. Play! pourrait devenir un outil de choix pour les applications à très fortes volumétries.

L’abstraction de l’accès aux données est réduite au maximum pour laisser aux développeurs le choix du datastore approprié. On retrouve tout de même les entités avec annotations JPA, et Ebean a remplacé Hibernate et amène un finder pratique pour requêter la base, et plus stateless que son prédécesseur. Dans mes rapides tests, on n’est pas vraiment dérangé par cette nouveauté, à creuser plus en détails.

Côté client, l’objectif est de permettre d’intégrer les excellentes technologies que l’on voit apparaître comme Jade, Less (c’est mon prochain billet de la série Nodejs), Backbone.js, Coffeescript. Un répertoire ‘assets’ a été ajouté à la structure du projet et les fichiers contenus sont automatiquement compilés et disponibles comme si ils étaient des ressources (par exemple les .coffee sont compilés en js et disponibles comme si le js était dans le répertoire public).

Les routes sont également compilées et ça c’est très pratique ! Si le controller ou la méthode indiqué dans le fichier route est inexistant, vous le savez immédiatement.

Dans les petits bonus plaisants, on peut maintenant écrire (en Scala) « def index = TODO » qui permet de continuer à écrire son code sans se préoccuper de l’implémentation du controller. Si on appelle cette méthode, elle affiche dans votre navigateur une belle page avec TODO. Le genre de détail ‘nice to have’.

Si vous voulez approfondir et vous faire votre avis, voici quelques liens qui peuvent vous intéresser :  la page officiellele blog Ipponle blog du Touilleur.

So what ?

Play est définitivement devenu populaire, et apprécié par beaucoup. Je fais partie de ceux qui apprécient son côté simple, productif, efficace et fun et qui l’ont utilisé pour faire des sites actuellement en ligne. Cette v2 me laisse un peu sceptique, n’étant pas spécialement un fanatique de Scala. C’est un excellent langage et très puissant, mais aussi très exigeant à produire et maintenir (des personnes autrement plus qualifiées que moi se sont déchainées sur le sujet ces derniers temps). Là où Play! faisait merveille pour commencer une application en 10 minutes après la lecture de 3 pages de tutorial, la v2 s’oriente vers une stack haute performance plus élitiste. Peut être que dans un an Scala/Play nous aura conquis. Dans tous les cas la hype est toujours là, il va falloir tester ça!