CoffeeBean

Calcul distribué avec Spark

2013-05-14T13:42:00.002+02:00

Spark est un outil de calcul distribué, permettant de lancer de gros calcul sur un cluster.

D'après ses développeurs, Spark est jusqu'à 100 fois plus rapide qu'Hadoop pour effectuer le même genre de taches.
Spark repose sur HDFS (Hadoop Distributed File System) mais les calculs se font en mémoire pour accélérer les traitements. Le but de cette accélération est de pouvoir effectuer des requêtes en temps réel sur de très gros volumes de données, par exemple sur les logs d'accès d'un site Internet. L'analyse des données en temps réel, le rêve quand on fait de la BI!

D'autres applications sont possibles comme le machine learning ou le data mining. Mais commençons par mettre les mains dans le cambouis!
Le coeur de Spark est écrit en Scala mais des API Java et Python sont également proposées pour interagir avec le framework. Un shell est fourni par défaut, il permet de manipuler facilement l'API Scala de Spark. Très pratique pour faire des tests!

Pour découvrir Spark, commençons par lire un fichier en local :

val textFile = sc.textFile("README.md")

Note : sc est un objet disponible par défaut dans le shell, il correspond au contexte Spark courant.

On veut maintenant compter les occurences de chaque mot dans ce fichier :

val wordCounts = textFile.flatMap(line => line.split(" ")) //on crée un tableau de mots
.map(word => (word, 1)) // on crée un tuple par mot pour compter les occurrences
.reduceByKey((a, b) => a + b) // on additionne les nombres d’occurrences en groupant par clé (par mot)

Un aspect vraiment sympa et puissant avec Spark, il est possible de manipuler les fichiers locaux ou les fichiers distribués sur HDFS exactement de la même manière. L'API masque complètement cet aspect.
On peut donc refaire la même chose mais en lisant le fichier sur HDFS comme ceci :

val textFile = sc.textFile("hdfs://masterHost:9000/data/README.md")

Modifions maintenant notre calcul, pour ne compter que les 9èmes mots de chaque ligne. Si la ligne contient moins de 9 mots, on veut afficher "smaller than 9". Pour ça on peut appeler la fonction lift sur notre tableau de mot (fonction standard dans l'API Scala), qui nous renverra une Option[String].
Le code devient alors :

val wordNineCOunts = textFile.map(line => line.split(" ")
.lift(9).getOrElse("smaller than 9")) // si la valeur n'est pas présente dans l'option, on écrit "smaller than 9"
.map(word => (word, 1))
.reduceByKey((a, b) => a + b)

Pour afficher le résultat, on procède comme ceci :

wordNineCOunts.collect

On obtient alors :

Array((different,1), (to,2), (other,1), (no,1), (params`.,1), (its,2), (spark:/,1), (open,1), (`/usr/local/lib/libmesos.so`,1), (of,1), (programming,1), (CPUs.,1), (HDFS,1), (smaller than 9,40), (want,1), (with,1), (so.,1), (the,1), (that,2), (minimum,,1), (Simple,1), (documentation,1), (bin,1), (their,1), (this,1), (variable,1))...

Note : 'collect' permet de passer d'un objet Spark de type RDD (resilient distributed dataset) à un simple tableau de valeurs

On peut aussi trier les résultats sur le deuxième membre de chaque tuple, c'est à dire trier les mots par nombre d’occurrence :

wordNineCounts
.collect
.sortWith((a, b) => a._2 > b._2)

Array((smaller than 9,40), (to,2), (its,2), (that,2), (different,1), (other,1), (no,1), (params`.,1), (spark:/,1), (`/usr/local/lib/libmesos.so`,1), (of,1), (open,1), (programming,1), (CPUs.,1), (HDFS,1), (want,1), (with,1), (so.,1), (the,1), (minimum,,1), (Simple,1), (documentation,1), (bin,1), (their,1), (this,1), (variable,1))...

En conculsion, Spark est un très bon cas d'utilisation de Scala, peu verbeux pour manipuler les données et bien adapté pour les traitements en parallèle, notamment grâce à l'immutabilité poussée par le langage.
Juste pour vous faire une idée, regardez ce que donnerait la même chose en Java.

Pour aller plus loin, vous pouvez aussi regarder Shark, qui repose sur Spark et apporte la possibilité de faire des requêtes avec un langage "SQL like" sur vos données distribuées. Shark est compatible avec Apache Hive tout en permettant de profiter de la vitesse d’exécution de Spark.

Comparaison d'Anorm et Slick pour l'accès aux bases de données relationnelles en Scala

2013-03-18T22:34:00.000+01:00

Anorm et Slick sont 2 librairies Scala qui permettent d'intéragir avec des bases de données relationnelles.
La première fait partie du framework Play (mais peut être utilisée séparément et propose d'écrire les requêtes en utilisant directement le langage SQL, la deuxième est l'outil officiel de la stack TypeSafe (la société derrière le langage Scala) et propose un DSL (Domain Specific Langage) plus fortement typé, pour générer du SQL.

Nous allons comparer ces 2 outils et voir comment implémenter les cas d'utilisation classiques à travers l' exemple de l'application Computer Database.

Remarque : Slick propose plusieurs modes de fonctionnement dont le mode plain sql qui permet à l'instar d'Anorm d'écrire du "vrai SQL". Ce mode est préconisé lorsque l'on a besoin d'écrire une requête très spécifique difficilement exprimable avec le DSL. Dans cet article nous étudierons uniquement le mode "lifted embedding" qui est plus fréquemment utilisé.

Définition des structures de données

Avec Anorm, on définit 'case class' pour définir notre modèle, ainsi que des fonctions de mapping pour faire correspondre les resultats de requêtes avec des objets Scala :

case class Company(id: Pk[Long] = NotAssigned, name: String)
case class Computer(id: Pk[Long] = NotAssigned, name: String, introduced: Option[Date], discontinued: Option[Date], companyId: Option[Long])


object Company {
    
  /**
   * Parse a Company from a ResultSet
   */
  val simple = {
    get[Pk[Long]]("company.id") ≈
    get[String]("company.name") map {
      case id~name => Company(id, name)
    }
  }
 //méthodes de lecture, insertion, mise à jour dans la base
}


object Computer {
  
  // -- Parsers
  
  /**
   * Parse a Computer from a ResultSet
   */
  val simple = {
    get[Pk[Long]]("computer.id") ~
    get[String]("computer.name") ~
    get[Option[Date]]("computer.introduced") ~
    get[Option[Date]]("computer.discontinued") ~
    get[Option[Long]]("computer.company_id") map {
      case id~name~introduced~discontinued~companyId => Computer(id, name, introduced, discontinued, companyId)
    }
  }

  //méthodes de lecture, insertion, mise à jour dans la base
}

Le symbole '~' permet de représenter la composition des result sets en provenance de la base de données, puis de définir des tuples Scala à partir de ces données.

Avec Slick, en plus des case class, on décrit la structure des tables de la base de données, afin de pouvoir les manipuler à travers le DSL :

case class Company(id: Option[Long], name: String)
case class Computer(id: Option[Long] = None, name: String, introduced: Option[Date]= None, discontinued: Option[Date]= None, companyId: Option[Long]=None)

object Companies extends Table[Company]("COMPANY") {

  def id = column[Long]("id", O.PrimaryKey, O.AutoInc)
  def name = column[String]("name", O.NotNull)
  def * = id.? ~ name <>(Company.apply _, Company.unapply _)
  def autoInc = * returning id
  
  //méthodes de lecture, insertion, mise à jour dans la base
}

object Computers extends Table[Computer]("COMPUTER") {

  def id = column[Long]("id", O.PrimaryKey, O.AutoInc)
  def name = column[String]("name", O.NotNull)
  def introduced = column[Date]("introduced", O.Nullable)
  def discontinued = column[Date]("discontinued", O.Nullable)
  def companyId = column[Long]("companyId", O.Nullable)

  def * = id.? ~ name ~ introduced.? ~ discontinued.? ~ companyId.? <>(Computer.apply _, Computer.unapply _)

  def autoInc = * returning id

//...
}

Récupération d'une liste d'entrées

On va commencer par lister les marques d'ordinateurs (companies). On veut récupérer des tuples (id, name) sous forme de String (cette info sera uniquement utilisée pour l'affichage sur la page web).

Avec Anorm, on écrit notre requête SQL puis on explicite la correspondance avec le modèle en utilisant la fonction map :

def options: Seq[(String,String)] = DB.withConnection { implicit connection =>
    SQL("select * from company order by name").as(Company.simple *).map(c => c.id.toString -> c.name)
  }

Avec Slick on utilise les API de collections et les structures pour itérer sur les résultats de la requête générée :

def options: Seq[(String, String)] = DB.withSession { implicit session =>
      val query = (for {
        company <- Companies
      } yield (company.id, company.name)
        ).sortBy(_._2)
      query.list.map(row => (row._1.toString, row._2))
  }

Récupération d'une liste d'entrées paginées à partir d'un filtre

On complique un peu les choses, en introduisant la pagination, le tri et la recherche par filtres.
Anorm :

def list(page: Int = 0, pageSize: Int = 10, orderBy: Int = 1, filter: String = "%"): Page[(Computer, Option[Company])] = {
    
    val offest = pageSize * page
    
    DB.withConnection { implicit connection =>
      
      val computers = SQL(
        """
          select * from computer 
          left join company on computer.company_id = company.id
          where computer.name like {filter}
          order by {orderBy} nulls last
          limit {pageSize} offset {offset}
        """
      ).on(
        'pageSize -> pageSize, 
        'offset -> offest,
        'filter -> filter,
        'orderBy -> orderBy
      ).as(Computer.withCompany *)

      val totalRows = count(filter)

      //count sera décrit plus bas

      Page(computers, page, offest, totalRows)
      
    }
    
  }

Les paramètres entre accolades sont substitués à l'aide de la fonction 'on'.

Ce code nécessite l'introduction d'une fonction 'Computer.withCompany' pour transformer les résultats du left join en une collection de type Seq[(Computer, Option[Company])] :

val withCompany = Computer.simple ~ (Company.simple ?) map {
  case computer~company => (computer,company)
}

Le caractère '?' permet de spécifier que la compagnie est optionnelle.

Slick :

 def list(page: Int = 0, pageSize: Int = 10, orderBy: Int = 1, filter: String = "%"): Page[(Computer, Option[Company])] = {

    val offset = pageSize * page

    DB.withSession { implicit session =>
        val query =
          (for {
            (computer, company) <- Computers leftJoin Companies on (_.companyId === _.id)
            if computer.name.toLowerCase like filter.toLowerCase()
          }
          yield (computer, company.id.?, company.name.?))
            .drop(offset)
            .take(pageSize)

        val totalRows = count(filter)
        val result = query.list.map(row => (row._1, row._2.map(value => Company(Option(value), row._3.get))))

        Page(result, page, offset, totalRows)
    }
  }

Ici on trouve une autre difficulté. On ne peut pas déclarer directement la jointure avec la compagnie comme optionnelle. On doit ruser en disant qu'on peut avoir un id et un nom, puis en utilisant la fonction map sur l'option d'id, on peut recréer notre type Option[Company] et renvoyer le bon résultat.

Note : dans les 2 cas on utilise un type Page créé par nos soins pour gérer la pagination des données :

case class Page[A](items: Seq[A], page: Int, offset: Long, total: Long) {
  lazy val prev = Option(page - 1).filter(_ >= 0)
  lazy val next = Option(page + 1).filter(_ => (offset + items.size) < total)
}

Insertion d'une entrée dans la base de données

Anorm :

def insert(computer: Computer) = {
    DB.withConnection { implicit connection =>
      SQL(
        """
          insert into computer values (
            (select next value for computer_seq), 
            {name}, {introduced}, {discontinued}, {company_id}
          )
        """
      ).on(
        'name -> computer.name,
        'introduced -> computer.introduced,
        'discontinued -> computer.discontinued,
        'company_id -> computer.companyId
      ).executeUpdate()
    }
  }

Slick :

  def insert(computer: Computer) {
   DB.withSession { implicit session =>
      Computers.autoInc.insert(computer)
    }
  }

Note : pour effectuer les opérations au sein d'une transaction, il faut remplacer "DB.withConnection" (Anorm) ou "DB.withSession" (Slick) par "DB.withTransaction". Le bloc sera ensuite transactionnel. Si besoin les paramètres implicites "connection" et "session" proposent une méthode "rollback()".

Calcul du nombre d'éléments

Anorm :

def count(filter: String) : Int = {
    DB.withConnection { implicit connection =>
     SQL(
        """
          select count(*) from computer 
          left join company on computer.company_id = company.id
          where computer.name like {filter}
        """
      ).on(
        'filter -> filter
      ).as(scalar[Long].single)
  }

Slick :

def count(filter: String) : Int = DB.withSession { implicit session =>
      Query(Computers.where(_.name.toLowerCase like filter.toLowerCase).length).first
  }

Mise à jour d'une entrée

Anorm :

def update(id: Long, computer: Computer) = {
    DB.withConnection { implicit connection =>
      SQL(
        """
          update computer
          set name = {name}, introduced = {introduced}, discontinued = {discontinued}, company_id = {company_id}
          where id = {id}
        """
      ).on(
        'id -> id,
        'name -> computer.name,
        'introduced -> computer.introduced,
        'discontinued -> computer.discontinued,
        'company_id -> computer.companyId
      ).executeUpdate()
    }
  }

Slick :

def update(id: Long, computer: Computer) {
    DB.withSession { implicit session =>
        val computerToUpdate: Computer = computer.copy(Some(id))
        Query(Computers).where(_.id === id).update(computerToUpdate)
    }
  }

Suppression d'une entrée

Anorm :

def delete(id: Long) = {
    DB.withConnection { implicit connection =>
      SQL("delete from computer where id = {id}").on('id -> id).executeUpdate()
    }
  }

Slick :

def delete(id: Long) {
    DB.withSession { implicit session =>
        Computers.where(_.id === id).mutate(_.delete)
    }
  }

Conclusion

Slick et Anorm ont chacun leurs avantages et inconvénients.
Voici mon avis sur leurs points positifs et négatifs respectifs ;

Anorm

Les + :

Pas besoin d'apprendre un nouveau DSL
Possibilité de tester directement ses requêtes SQL dans la base de données avant de les coller dans le code

Les - :

Code SQL, donc potentiellement spécifique à une base de données en particulier
Plus verbeux que Slick
Requêtes non "type safe"

Slick

Les + :

DSL typé
Plus concis qu'Anorm. Ceci est particulièrement visible sur les opérations d'insertion/mise à jour de données

Les -

Plus opaque, il est parfois difficile d'imaginer le code SQL qui se cache derrière le DSL. En cas d'erreur ça complique un peu les choses...
La structure du framework incite à utiliser directement un driver spécifique à une base de données (par exemple la classe scala.slick.driver.MySQLDriver) mais le plugin Play-Slick aide à rendre le code plus générique

Pour moi il n'y a pas vraiment de vainqueur, je pense que le choix dépendra surtout du fait que vous vous sentiez plus à l'aise avec SQL ou avec les collections Scala pour parcourir vos données.

Bonus : Ce n'est qu'un pour le moment "proof of concept" mais il existe une version "type safe" d'Anorm, qui utilise les macros Scala lors de la phase de compilation pour renvoyer des résultats typés en fonction de la définition du schéma de la base de données. En plus de proposer un code plus concis, cette version d'Anorm apporterait aussi plus de sécurité au développeur : https://github.com/guillaumebort/anormtyped-demo
Personnellement je suis hyper-séduit par cette solution!

Et vous, laquelle de ces deux librairies préférez vous?

Un plugin Slick pour Play 2.1

2013-02-06T12:05:00.000+01:00

Un plugin Slick pour Play 2.1 a été initié par Typesafe, il permet d'utiliser Slick (un librairie d'accès aux bases de données relationnelles en Scala) facilement au sein de Play, avec en prime la génération automatique du schéma (évolutions). Le but ultime est que son code soit intégré à Play 2.2 pour que Slick soit utilisable par défaut. C'est encore au stade Beta mais vous pouvez déjà jouer avec en le récupérant ici : https://github.com/freekh/play-slick.

Si ça vous intéresse n'hésitez pas à contribuer, l'auteur Fredrik Ekholdt est très abordable, il vient d'ailleurs d'intégrer au plugin ma modeste contribution permettant d'abstraire le driver jdbc utilisé (et donc de switcher facilement d'une base à une autre), donc merci Fredrik :)

Push database -> browser avec Mongo et Play

2012-11-20T08:22:00.000+01:00

Aujourd'hui je vous propose une expérience amusante à réaliser avec Play Framework 2.1 et la base de données NoSQL MongoDB.
Vous avez peut être entendu parler de ReactiveMongo, un driver Scala "asynchrone et réactif" pour Mongo. Il existe un plugin Play pour utiliser ce driver plus facilement au sein d'une webapp. Nous allons voir comment utiliser ces technologies pour récupérer un ensemble de messages de manière asynchrone et pour les pousser vers le navigateur en temps réel, dans une application de type "Twitter lite". Le but de notre prototype : en laissant une page de recherche ouverte, on veut voir les nouveaux messages correspondant à cette recherche s'afficher dès leur enregistrement en base de données, sans effectuer de "pull" vers le serveur.

Côté browser nous allons utiliser la technologie SSE (Server-Sent Events).
Si on reprend la définition du W3C, SSE est le fait "qu'une page reçoive automatiquement les mises à jour d'un serveur". C'est donc une technique de push qui permet de s'abonner à des mises à jour et à afficher les nouvelles données sans effectuer de requête de rechargement.

Note : certains auront remarqué que le principe de SSE est proche de celui des WebSockets. Si ces 2 techniques font partie d' HTML5, SSE est plus simple car il ne gère que la transmission de données que dans le sens serveur -> client, alors que WebSocket est bidirectionnel.

Assez parlé, un peu de code (Scala) :

 def search(filter: String) = Action { 
    val query = QueryBuilder().query(
                    BSONDocument("message" -> BSONRegex(filter, "")))

    //query results asynchronous cursor
    val cursor = 
        collection.find[JsValue](query, QueryOpts().tailable.awaitData)

    //create the enumerator
    val dataProducer = cursor.enumerate

    //stream the results
    Ok.stream(dataProducer through EventSource())
        .as("text/event-stream")
}

L'objet "collection" est notre lien avec la base de données. Dans notre contrôleur Play, on crée un curseur qui renverra les nouveaux messages contenant notre filtre de recherche, au fur et à mesure de leur arrivée dans la base grâce à l'option "tailable.awaitData".
On utilise ensuite la méthode "Ok.stream" qui permet d'envoyer des résultats partiels au client dès leur disponibilité. L'objet "EventSource" fait partie de l'API Iteratee de Play (voir cette page pour en savoir plus) et fournit un pont vers la fonction SSE définie côté client :

<script type="text/javascript" charset="utf-8">
    var feed = new EventSource("/news/search?filter=@filter");
    feed.addEventListener('message', function(e) {
    var result  = jQuery.parseJSON(event.data);
    //[...]
</script>

On récupère enfin chaque nouveau message dans un objet javascript "result" afin de l'afficher dynamiquement.

Note : lors de la commande "collection.find[JsValue](...)" les objets obtenus via la requête Mongo ont été automatiquement convertis au format JSON (ou JsValue) avant de les pousser sur la socket SSE.
Cela fonctionne grâce à un paramètre implicite (les fameux "implicits" de Scala) définissant une méthode de transformation. Pour profiter de ces implicits il suffit d'ajouter la ligne "import play.modules.reactivemongo.PlayBsonImplicits._".

Note 2 : "dataProducer through EventSource()" peut aussi s'écrire "dataProducer &> EventSource()", selon les goûts...

Vous pouvez récupérer le code complet de l'application ici.

Play.Rules!►Return : un nouveau chapitre d'introduction à Scala

2012-10-11T21:45:00.002+02:00

Dans ce chapitre nous allons voir l’intérêt d'utiliser Scala à travers quelques exemples, les différences avec la version Java et surtout "pourquoi Scala colle à l'esprit de Play".
Ceci peut donc être vu comme un chapitre bonus, sans lien avec le tuto "Bookmarks", pour vous donner envie de découvrir Scala.

Lire le chapitre : https://github.com/3monkeys/play.rules/blob/master/livre.play.deux/12-scala.md

Play2 : Les Iteratees expliqués aux humains... francophones!

2012-09-15T15:38:00.000+02:00

Dans le post précédent nous avons vu comment envoyer des données de manière asynchrone vers le browser avec Play 2. Pour cela nous avons utilisé quelques fonctionnalités de l'API Iteratee offerte par Play Framework.

Afin de pouvoir expliquer plus en profondeur les concepts derrière cette API, je viens de faire la traduction en français d'un très bon article en anglais écrit par un développeur travaillant chez Zenexity, la société éditrice de Play.

Pour lire cet article intitulé "Play2 : Les Iteratees expliqués aux humains... francophones!", ça se passe ici : http://gist.github.com/3727850#file_iteratees_humains.md

L'article original se trouve ici : http://mandubian.com/2012/08/27/understanding-play2-iteratees-for-normal-humans

Experiment : Play2 + Scala + Iteratee + Comet = Realtime Web

2012-08-05T20:07:00.002+02:00

Just a little experiment I've done with Play2, Scala and Iteratee to mixup some Twitter searches : see the POC and the explanations on Github here!

Akka : à la découverte des acteurs

2012-06-01T08:47:00.000+02:00

Akka est un framework permettant de gérer des problématiques de parallélisation et d'asynchronisme, basé sur un système d'acteurs. Les acteurs sont des objets capables de communiquer entre eux par messages pour échanger des ordres d’exécution et des informations sur leur état.

Dans cet article nous allons étudier un cas assez simple : comment appliquer une transformation (une multiplication par deux) sur une liste d'entiers en parallélisant les calculs.

Pour ceci nous allons créer un système avec plusieurs acteurs :

Un master qui va dispatcher le travail puis récupérer les résultats
Des workers qui vont traiter individuellement les transformations d'entiers

Cette première portion de code va initialiser le système et créer les acteurs. On démarre le master en lui envoyant un message de type Start.

    
final int nbWorkers = 6;
List<Integer> numbers = Arrays.asList(1, 5, 15, 22, 66, 55);
ActorSystem system = ActorSystem.create("mySystem");
ActorRef master = system.actorOf(new Props(new UntypedActorFactory() {
  public UntypedActor create() {
    return new Master(nbWorkers, numbers);
  }
}), "master");
Start startMessage = new Start();
master.tell(startMessage);

Au moment de sa création, le master va déclarer un routeur capable de répartir les traitements demandés sur un nombre de nœuds définis par nos soins (ici on en a 6) .

public class Master extends UntypedActor {
  private List<Integer> numbers;
  private final ActorRef workerRouter;
  long start = System.currentTimeMillis();

  public Master(int nbWorkers, List<Integer> numbers) {
    transformedNumbers = new ArrayList<Integer>();
    this.numbers = numbers;
    //create the worker dispatcher
    workerRouter = this.getContext().actorOf(new Props(Worker.class).withRouter(new RoundRobinRouter(nbWorkers)), "workerRouter");
    System.out.println("master and router created");
  }

Voyons maintenant comment le master répond aux messages. Cet acteur reconnaît deux types de messages : Start et Response. Leur code est assez sommaire :

public class Start{}

public class Result{
    public Result(int value) {
      this.value = value;
    }
    public int value;
  }

Le premier est vide, il permet simplement de démarrer le master pour lui demander de dispatcher le travail de calcul envoyant chaque entier à un worker (comme nous l'avons vu plus haut). L'autre est un simple conteneur qui permet aux workers de renvoyer les résultats partiels du calcul.

Lé méthode "onReceive" que l'on définit dans le master reçoit les messages qui sont adressés à celui ci :

@Override
  public void onReceive(Object message) {
    if(message instanceof Start){
      System.out.println("master received a start event");
      //dispatch
      for (Integer number : numbers){
        // send to a worker
        workerRouter.tell(number, getSelf());
      }
    }
    else if(message instanceof Result){
      System.out.println("master received result event");
      Result result = (Result) message;
      //join
      transformedNumbers.add(result.value);
      if(transformedNumbers.size() == numbers.size()){
        Duration duration = Duration.create(System.currentTimeMillis() - start, TimeUnit.MILLISECONDS);
        System.out.println(transformedNumbers.size() + " numbers computed in " + duration);
        //stop master and its workers
        getContext().stop(getSelf());
        getContext().system().shutdown();
      }
    }
  }

Une fois que le master a récupéré le nombre de réponses attendues, le travail est terminé et on peut afficher le résultat.
L'instruction "tell" permet de travailler de manière asynchrone : lorsque l'on demande à un worker de traiter un entier, on continue à exécuter le code pour traiter les éléments suivants sans attendre le résultat, qui sera communiqué au master à l'aide d'une notification.

Enfin, voici le code de la classe Worker :

public class Worker extends UntypedActor {

  @Override
  public void onReceive(Object message) {
    System.out.println("worker received an event");
    if(message instanceof  Integer){
      int number = (Integer) message;
      int transformedNumber = tranform(number);
      //send result to master
      getSender().tell(new Result(transformedNumber), self());
    }
  }

  private int tranform(int number){
    try {
      Thread.sleep(4000);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
    return number *2;
  }
}

La méthode transform contient le code de la transformation. On introduit volontairement un "sleep" de 4 secondes pour allonger le traitement et mesurer plus facilement le gain de la parallélisation.

Premières observations

Définir plusieurs workers permet de répartir le traitement sur plusieurs threads en faisant abstraction de la programmation parallèle :

Avec un seul worker, transformer les 6 entiers demandés prend environ 24 secondes
Avec 4 workers : environ 8 secondes
Avec 6 workers : environ 4 secondes

Pour un nombre de workers supérieur ou égal au nombre d'éléments, le temps de calcul revient à peu près à passer une seule fois dans le sleep de 4 secondes : on n'attend pas la fin d'un calcul et du sleep associé pour passer aux itérations suivantes.

Dans notre cas comme il y a des phases d'attente on peut même aller à un nombre de workers supérieurs au nombre de coeurs de la machine (j'ai lancé ce code sur un dual-core). Ceci peut également être pertinent lorsqu'on attend la réponse d'un webservice par exemple ou pour tout autre type d'entrées/sorties.

Quelques modifications

On aimerait pouvoir récupérer le résultat du traitement depuis une méthode appelante.
Cependant si celle ci n'est pas gérée par un acteur, on ne peut pas répondre directement depuis notre master à l'aide d'un "tell". On passe alors par l'API Future d'Akka.
Un future permet de lancer un traitement en parallèle (dans un thread séparé) puis de récupérer le résultat.
Par exemple :

public static void main(String[]args) throws Exception{
    ActorSystem system = ActorSystem.create("mySystem");

    Future<String> f1 = future(new Callable<String>() {
      public String call() throws Exception {
        Thread.sleep(4000);
        return "You String is ready !!";
      }
    }, system.dispatcher());
    Timeout timeout = new Timeout(Duration.parse("30 seconds"));
    String result = Await.result(f1, timeout.duration());
    System.out.println(result);
  }

Note : On utilise ici la classe Future d'Akka et non celle du JDK. Un des avantages de cette version est de permettre la récupération de la valeur dès qu'elle est disponible sans avoir à vérifier périodiquement que le traitement est terminé.

On peut utiliser le même mécanisme pour obtenir la réponse d'un acteur une fois ses taches terminées.
La méthode Patterns.ask permet de définir un acteur implicite auquel notre master pourra répondre à travers un objet de type Future :

Future future = Patterns.ask(master, startMessage, timeout);
List<Integer> result = (List<Integer>) Await.result(future, timeout.duration());

On peut ainsi imaginer une méthode qui appelle notre système d'acteurs et qui retourne le résultat :

public List<Integer> transform(List<Integer> numbers){
 ActorSystem system = ActorSystem.create("mySystem");
    ActorRef master = system.actorOf(new Props(new UntypedActorFactory() {
      public UntypedActor create() {
        System.out.println("create master");
        return new Master(nbWorkers, numbers);
      }
    }), "master");
    Start startMessage =  new Start();
    Timeout timeout = new Timeout(Duration.parse("30 seconds"));
    Future future = Patterns.ask(master, startMessage, timeout);
    List<Integer> result = (List<Integer>) Await.result(future, timeout.duration());
    system.shutdown();
 return result;
  }

Pour renvoyer le message depuis le master, on garde une référence de l'expéditeur initial (déclaré implicitement lors de l'appel de 'ask') pour pouvoir lui répondre plus tard.
Attention, appeler la méthode 'getSender' en fin de traitement renverrait le message au dernier expéditeur, dans ce cas ce serait un worker.
On sauvegarde donc cette référence dans le bloc "Start" du worker :

public class Master extends UntypedActor {
  
  private ActorRef initialSender;
 ...

if(message instanceof Start){
  this.initialSender = getSender();
 ... 
}

if(message instanceof Response){
if(transformedNumbers.size() == numbers.size()){
    reply();
  }
...
}

public void reply(){
    initialSender.tell(transformedNumbers);
    //stop master and its workers
    getContext().stop(getSelf());
  }
}

Note : Attention à l'utilisation de la classe Await.result qui est bloquante (d'où l'obligation d'utiliser un timeout). Ici cela ne pose pas de problème car elle intervient après avoir lancé tous les calculs en parallèle mais l'utiliser à un mauvais endroit aurait un impact sur les performances.

Pour terminer ce long article, Akka est un framework écrit avec le langage Scala, il propose donc naturellement une API Scala pour manipuler les acteurs. Scala permet d'écrire un code un peu plus élégant que Java pour ce genre de choses (par exemple en évitant les "cast"). Voici à quoi pourrait ressembler un worker en Scala :

class Worker extends Actor { 
    def receive = {
 case Int(number) => 
  sender ! number * 2
    }

Vous pouvez télécharger le code source des exemples ici.

HTML5 input tags module for Play 2.0

2012-04-06T17:48:00.003+02:00

First try on Play2 module writing!
You can learn more and checkout the project here : https://github.com/loicdescotte/Play2-HTML5Tags
Any suggest or idea is welcome!

Un article sur Play Framework dans le magazine Programmez

2012-02-29T12:10:00.001+01:00

J'ai eu l'honneur il y a quelques mois d'écrire quelques pages pour présenter Play Framework dans le magazine Programmez.
Cet article vient de paraître, vous pouvez le découvrir dans le dernier numéro.

N.B : Malheureusement l'article ne couvre pas la prochaine version du framework annoncée pour Avril (il a en fait été rédigé au mois d'Octobre dernier...)

Kotlin : premiers essais avec IntelliJ IDEA

2012-02-17T15:31:00.002+01:00

Cette semaine, Jetbrains a mis disposition le code source de Kotlin sur Github.
On peut y télécharger le runtime, le compilateur et un plugin pour IntelliJ IDEA (attention, il faut la dernière version 'EAP' de l'IDE pour que cela fonctionne).
Voyons ensemble comment essayer ce nouveau langage en quelques lignes de code.

Une fois le plugin IDEA installé, on peut créer un nouveau fichier Kotlin en utilisant menu "New" --> "Kotlin file" L'IDE demandera alors le chemin vers le runtime Kotlin. Après avoir renseigné ce chemin, on peut commencer à coder!

Pour commencer, on crée une méthode main :

fun main(args : Array<String>) {
}

Testons maintenant quelques fonctionnalités. La fonction 'filter' disponible sur les collections prend en paramètre une autre fonction :

    val list1 = arrayList(1, 2, 3, 4, 5)
    println(list1.filter{it -> it>2})

Cette fonction est disponible même sur les collections Java (ici on manipule une ArrayList) grâce au mécanisme d'extension de Kotlin (voir doc).
Dans notre exemple, la fonction passée en paramètre demande de ne retourner que les nombres superieurs à 2. La sortie sera donc : 3,4,5

Comme cette fonction ne prend qu'un paramètre, on peut simplifier son écriture comme ceci :

 println(list1.filter{it>2})

La fonction 'map' transforme une collection en une autre collection en appliquant une fonction à chaque élément :

    val list2 = arrayList("bob", "joe", "john")
    println(list2.map{
        "Hello " + it.toUpperCase()
    })

On peut noter que l'inférence de type fonctionne bien dans l'IDE. En effet, après le mot 'it' IDEA nous propose toutes les fonctions relatives au type String, qu'il a pu déterminer en analysant la construction de la list 'list2'.
Note : on aurait pu écrire explicitement le type de cette liste de cette manière : val list2: Array<String> = arrayList("bob", "joe", "john")

Dans un style plus "framework Web", définission maintenant une fonction 'get' qui prend en paramètre une route (une URL) et une fonction à exécuter lors de l'appel de cette URL :

fun get(route: String, process : () -> String) {
    val response = process()
    println("added route $route : " + response)
}

Note : on observe au passage la syntaxe '$route' qui permet d'insérer une expression dans un string.

Kotlin permet de passer le corps d'une fonction à l'exterieur des parenthèses si cette fonction est le dernier paramètre de la fonction englobante.

Derrière cette phrase compliquée, on peut voir que l'on peut appeler notre fonction comme ceci :

    get("/hello") {
        val name = "bob"
        "<h1>hello $name</h1>"
    }

On a donc une fonction 'get' qui peut être appelée en utilisant la même structure que 'map', 'filter' ou même qu'une simple boucle 'while'. En exécutant le code ci-dessus, on a bien "<h1>hello bob </h1>" dans la console.

En conclusion, ce premier aperçu est plutôt positif, l'IDE répond bien et semble tout à fait fonctionnel pour une preview. En plus, l'équipe de Kotlin a annoncé vouloir faire fonctionner Play Framework avec Kotlin!

Pour en savoir plus sur ce langage, vous pouvez visiter cette page et découvrir d'autres fonctionnalités comme le pattern matching, les properties, les generics (bien plus puissants qu'en Java)... Et si vous avez la flemme de configurer IntelliJ IDEA, vous pouvez toujours jouer avec la Web Demo!

Présentation Play au Togo JUG : les slides

2012-01-28T15:42:00.001+01:00

Philippe et moi avons eu le plaisir de faire une présentation sur Play Framework (en versions 1.x et 2.0) pour le Togo JUG ce matin.

Les slides (présentation du framework, tutoriels...) sont disponibles ici : http://3monkeys.github.com/prez.play/

Note : pour les visionner il vaut mieux utiliser un navigateur sous WebKit, par exemple Chrome ou Safari.

Premiers pas avec Scalatra

2011-12-25T11:50:00.001+01:00

Scalatra est un framework Web ultra léger pour le langage Scala inspiré par Sinatra, un framework très populaire dans le monde Ruby.

Scalatra privilégie une approche très simple basée sur les principes REST. Pour effectuer une action, on part d'une méthode HTTP et d'une route (URL d'accès à la fonction), auxquelles on ajoute le traitement désiré :

get("/hello") {
    "hello!"
}

Avec cette approche et la manipulation XML proposée en Scala, on peut déclarer et renvoyer du contenu comme ceci :

get("/hello") {
  <html>
      <body>
        <h1>Hello!</h1>
     </body>
   </html>
}

On peut facilement ajouter des paramètres dans l'URL :

get("/hello/:name") { 
    <html>
      <body>
        <h1>Hello {params("name")} !</h1>
      </body>
    </html>
  }

Renvoyer du contenu XML (ou JSON ou ce qu'on veut) pour exposer un service REST :

get("/persons"){
 contentType="application/xml"
 <xml>
     <persons>{
         Database.entries.map { 
                    entry =>  <person>{entry}</person> 
                }
     }</persons>
 </xml> 
 }

Faire un POST pour enregistrer de nouvelles données :

post("/person"){
 val name = params("name")
 Database.addEntry(name)
 redirect("/persons")
  }

Remarque : Pour tester la méthode ci-dessus, on peut par exemple utiliser curl en ligne de commande :

curl for test: curl --data "name=jim" http://localhost:8080/person

On peut aussi rediriger l'action vers un template :

 get("/hello2/:name") {
      templateEngine.layout("hello-scalate.scaml", Map("name" -> params("name")))
  }

Scalatra est livré par défaut avec le moteur de template Scalate, qui est compatible avec plusieurs formats de templates. Voici un exemple avec le format scaml :

//redefinition du titre dans le layout par défaut
- attributes("title") 
//paramètre de requête
-@ val name: String

%h1 Welcome!
%p Hello, how are you #{name} ?

Enfin, on peut définir les actions à effecter en cas d'erreur :

notFound { 
<h1>Nothing found here</h1>
<img src="/images/404.jpg" />        
}

Le framework fonctionne avec l'outil de build SBT. Un support des WebSockets est proposé à travers la librairie Socket.IO. En utilisant Jetty, le conteneur par défaut de Scalatra, on peut recharger le code à chaud (plus ou moins rapidement). Pour cela on le démarre avec la commande suivante :

 sbt
 > container:start
   > ~ aux-compile

Dans cet exemple, j'ai simulé à la base de données avec un "object" Scala. Un object est l'équivalent d'un singleton : c'est une classe qui possède une instance unique.

object Database{
 //shared entries (simulate database)
 var entries = List("bob", "joe", "john") 
 def addEntry(name: String){
     entries = entries:+name
 }
}

On pourra facilement remplacer cette implémentation par une vraie base de données. Si vous n'avez pas besoin d'une base SQL (ce qui est en fait souvent le cas), vous pouvez regarder des choses plus simples comme la base de données objet NeoDatis qui supporte officiellement Scala. Pour des besoins de scalabilité plus importants, vous pouvez aussi jeter un oeil du côté de MongoDB et de Casbah (son toolkit Scala). Avec ce genre d'outils vous conserverez une architecture simple, pas besoin de s'embêter avec des frameworks à la Spring, le langage apporte tout ce qu'il faut pour gérer l'injection de dépendance nativement. Pour conclure, Scalatra nous prouve que contrairement aux idées reçues, on peut faire des choses extrêmement simples et efficaces en Scala avec des API bien pensées. Si vous cherchez quelque chose s'en rapprochant et utilisant le langage Java, vous pouvez regarder du côté de Spark.
Et puis j'allais oublier, joyeux Noël à tous!

Site officiel de Scalatra

Stateful VS Stateless : une mise en bouche du débat

2011-11-16T11:04:00.001+01:00

Philippe Charrière, Antoine Sabot-Durant et moi avons eu l’honneur d'être interviewés par les JDuchess pour présenter le sujet de la prochaine conférence du Lyon JUG : Architecture stateful vs stateless (que nous animerons mardi prochain)

Cette première partie du débat est à lire ici

Présentation Stateful VS Stateless au Lyon JUG le 22 Novembre

2011-11-12T19:03:00.001+01:00

Le mardi 22 Novembre j'aurai l'honneur d'animer une session sur le thème des architectures stateless avec Philippe Charrière. Nous présenterons ce concept à travers une démo basée sur Play Framework.

Nous confronterons notre vision à celle d'Antoine Sabot-Durant qui présentera l'alternative stateful avec Java EE (CDI, EJB 3...).

Pour vous inscrire à cette présentation, c'est ici : http://www.lyonjug.org/evenements/architecture-stateful-vs-stateless

Un nouveau site pour Play.Rules!

2011-10-06T12:00:00.001+02:00

Mon coéquipier Philippe (aussi connu sous le pseudo @k33g_org) vient de mettre en ligne un superbe site Web pour notre ebook Play.Rules!

Ce site permet de consulter en ligne les différents chapitres.
Il nous servira aussi à publier les news concernant le livre et son avancement.

Voici donc une URL à bookmarker ;) http://3monkeys.github.com/play.rules/

Pour ce qui est des nouveaux chapitres, on est pas mal occupés en ce moment mais du contenu supplémentaire ne devrait pas tarder à se montrer!

Play Framework Cookbook

2011-09-25T18:33:00.000+02:00

J'ai eu la chance de recevoir un exemplaire gratuit du livre Play Framework Cookbook de la part de Packt en échange d'une critique sur ce blog. Je vais donc essayer de vous donner mon avis tout en restant le plus objectif possible.

Après un premier chapitre qui présente toutes les opérations courantes d’un projet Play (création de vues, modèles, routes, gestion de la session utilisateur...), le livre se focalise sur un ensemble d’astuces répondant à des cas concrets. On trouve par exemple des chapitres traitant de (au hasard et dans le désordre) :

la configuration des routes par annotations
le caching
la génération de fichiers PDF ou de graphiques avec Google Chart API
l’injection de beans Spring ou Guice

Le livre explique en détail les principes de la création de modules Play et donne des exemples d’utilisation de modules existants, comme la connexion à une base NoSQL à l’aide du module MongoDB.
Si on devait résumer le style d’écriture, ce serait “beaucoup de code et peu de blala”.
Pour chaque partie on retrouve les mêmes sections : getting ready, how to do it, how it works, there is more.
Cette structure permet de comprendre en détail le fonctionnement des différentes briques du framework. La dernière de ces 3 parties a un rôle d’ouverture, on y trouve des conseils pour améliorer notre code ou pour booster les perfs ainsi que des solutions alternatives en s’appuyant par exemple sur des librairies externes.

Le livre ne s’arrête pas au développement d’une application Play. Il présente un certain nombre d’astuces pour la mise en production (comme la mise en place d’un load balancer), l’intégration continue (avec jenkins), la gestion des logs ou encore le paramétrage d’un repository de modules privé.
Vous l'aurez compris, il couvre donc un scope d’astuces assez large. Ce livre ne demande pas forcément une lecture linéaire : on peut facilement sauter des chapitres pour aller directement chercher l’exemple qui répondra à notre problème du moment.

Si on devait trouver quelques petits manques ou défauts, aucune plateforme de cloud n’est présentée. Le livre a été écrit trop tôt pour parler du PaaS Heroku, cependant les modules CloudBees et Google APP Engine existent depuis un certain temps et auraient pu être abordés. Pas de Scala non plus, mais il est vrai cela demanderait presque un deuxième livre, l’API Play Scala étant vraiment différente de la version Java (ceci devrait changer avec Play 2.0).
Enfin, le livre s'adresse plutôt aux personnes qui connaissent les bases de Play et qui veulent des recettes pour répondre a des problèmes précis. Cette démarche va assez loin puisque le livre comprend même une partie dédiée à l’optimisation de byte code. En ce sens, le tutoriel YABE de la documentation officielle ou le livre Play.Rules (pub perso ;) seront sûrement des pistes à privilégier pour les novices.
Cet ouvrage sera par contre une mine d’or pour les développeurs qui se lancent dans un projet “real life” et qui cherchent un vrai cookbook avec des techniques applicables au quotidien. Et comme je suis sympa je vous offre un chapitre gratuit!

Heroku offre un PaaS pour Play Framework

2011-08-29T19:06:00.000+02:00

Bonne nouvelle les amis, la plateforme de Cloud Heroku, particulièrement célèbre dans le monde Ruby, vient d'annoncer un support natif des application Play Framework!

Nous avons donc à notre disposition un PaaS pour notre (ou du moins mon) framework préféré, permettant de déployer une application en production en une ligne commande (via Git).
De plus, en dessous d'un certaine nombre d'un certain nombre de connexions le service est gratuit.
Et si votre application rencontre le succès que vous espériez, vous pourrez alors passer sur du payant avec une configuration un peu plus costaud et bénéficier de toute la scalabilité offerte par la plateforme.

Tout ça pour vous dire que je pensais justement faire un chapitre dans l'eBook play!rules sur le déploiement d'une application dans le Cloud... Heroku étant la première plateforme à supporter Play nativement, je vais naturellement m'orienter vers cette solution. So stay tuned, le chapitre devrait arriver très rapidement.

Ps : merci à Nicolas du Touilleur Express qui a tweeté cette information hyper vite comme toujours!

MAJ : Le (très court) chapitre sur Heroku est maintenant disponible ici.

Kotlin: un nouveau langage pour la JVM

2011-07-20T12:12:00.009+02:00

JetBrains (l'éditeur de l'excellent IDE IntelliJ IDEA) vient d'annoncer qu'ils lançaient leur propre langage pour la JVM : Kotlin.
Cette annonce arrive quelques mois après celle de Red Hat qui a presénté le langage Ceylon au mois d'Avril.

Alors à quoi ressemble ce nouveau langage? Pour faire court, prenez Scala, rendez le un peu plus abordable et facile d'accès, ajoutez y un peu de Groovy et quelques nouvelles features.

Vous comprendrez mieux avec quelques exemples de code .

On peut facilement écrire ce genre de code grâce aux expressions lambda :

names filter {it.startsWith("A")} map {it.toUpperCase()} foreach {print(it)}

Ce code écrit en majuscule dans la console tous les nom commençant par A.
C'est le genre de choses toutes simples qui peuvent être vraiment lourdes à écrire en Java...

On peut également faire du pattern matching à la Scala :

fun cases(obj : Any) {
  when(obj) {
    1          => print("One")
    "Hello"    => print("Greeting")
    is Long    => print("Long")
    !is String => print("Not a string")
    else       => print("Unknown") 
  }
}

Kotlin est un langage à typage statique. Mais il propose un mécanisme d'inférence de type pour alléger la syntaxe :

var a : Int = 1
var b = 1 // Type inféré

On peut même automatiser les cast dans certains cas :

if (obj is String) 
    return obj.length // pas de cast explicite

Le langage fournit un système de properties très bien pensé (pour éviter d'écrire les getters et setters à la main), qui rappelle un peu celui de C#.

La gestion des null est aussi très efficace et devrait résoudre pas mal de problèmes liés au null pointers. Un champ ne peut être null que si on l'autorise :

var a : String = "abc"
a = null // erreur de compilation

var b : String? = "abc"
b = null // ok

Pour y accéder, on fait comme en Groovy :

b?.length()

Ceci renverra length() si b est non null, rien sinon. On pourra donc éviter quelques fastidieux if(b!=null) dans notre code.

Pour réduire le risque d'erreurs, l'utilisation du "?" est obligatoire pour accéder aux objets "nullables" :

b.length() //erreur de compilation

Enfin, le langage offre la même sécurité que Scala au niveau de l'immutabilité, avec l'usage du mot clé "val" (au lieu de "var") pour déclarer une propriété immuable. Ceci aura aussi une incidence sur la génération automatique des accesseurs : seul un getter est généré pour une propriété de type val.

Si cette mise en bouche vous a ouvert l'appétit, je vous conseille de regarder ces exemples plus détaillés sur le site du langage.

En tout cas personnellement je trouve ça très prometteur. Le support natif dans IntelliJ IDEA sera un gros plus des son lancement. J'espère sincèrement que ce langage aura sa chance dans la jungle des langages pour la JVM!

MAJ : Vous pouvez dès à présent jouer avec la Web demo de Kotlin

Play!Rules: un chapitre sur Play et Scala

2011-06-24T22:34:00.000+02:00

Un nouveau chapitre est disponible dans l'ebook gratuit (et open source) Play!Rules, il explique comment développer avec Play Framework et le langage Scala .

Pour en savoir plus, ça se passe ici.

Spring Data JPA et Querydsl

2011-05-28T10:50:00.021+02:00

SpringSource a récemment lancé le projet Spring-Data, un ensemble de sous projets ayant pour but de nous aider à manipuler plus facilement nos données.

Nous allons nous attarder sur Spring-Data-JPA, qui fournit un ensemble d'automatisations pour JPA.

Repositories

Les repositories sont des interfaces pour lesquelles nous n'avons pas à fournir d'implémentation. Ces interfaces seront implémentées par le framework lui même au démarrage du contexte Spring.

On considère la classe Person :

@Entity
public class Person {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String firstName;
    private String lastName;
    private Integer age;
    private String city;
 //getters & setters 
}

Si on écrit par exemple :

public interface PersonRepository extends JpaRepository<Person, Long> {
    List<Person> findByCity(String city);    
}

Spring implémentera une requête en se basant sur le nom de la méthode, pour rechercher des personnes par la ville où elles habitent.

Pour utiliser plusieurs paramètres on utilise le mot clé "And" :

List<Person> findByFirstNameAndLastName(String firstName, String lastName);

On peut utiliser tout un tas d'autres mots clés dans le nom des méthodes pour construire nos requêtes :

And
Or
GreaterThan
LessThan
Like
IsNull
OrderBy
...

Par exemple :

List<Person> findByAgeOrderByLastnameDesc(Integer age);

Les repositories permettent aussi de persister les entités dans la base :

personRepository.save(person);

Ces fonctionnalités sont directement reprises depuis Hades, les 2 frameworks partageant le même spec leader.

Si on veut écrire directement une requête JPQL, on peut utiliser l'annotation @Query :

@Query("ma super requête ici")
List<Person> findWithMyCustomQuery(Customer customer);

La requête sera exécutée lorsque qu'on appellera la méthode findWithMyCustomQuery.

Named queries

Pour utiliser une NamedQuery, il suffit que le nom de la méthode du repository suive le même nom que la NamedQuery. Dans ce cas de figure, le framework n'essaiera pas de générer une requête en suivant le nom de la méthode.
Par exemple la méthode findByNameWithMyFilters sera mappée sur la requête nommée "Person.findByNameWithMyFilters".

Entité :

@Entity
@NamedQuery(name = "Person.findByNameWithMyFilters", 
  query = "select p from Person p where filter1 = ? and filter2 = ?")
public class Person {...}

Repository :

Person findByNameWithMyFilters(String filter1, String filter2);

Ces repositories nous facilitent bien la vie en générant pour nous les requêtes pour un grand nombre de cas courants. Un détail qui a son importance : toutes les méthodes des repositories sont transactionnelles par défaut.

Querydsl

Querydsl est une librairie qui apporte des API pour requêter des entités de manière "typesafe" et avec une syntaxe épurée. Spring-Data supporte cette librairie pour simplifier l'écriture de prédicats en Java.

Voici quelques exemples de requêtes, avec l'utilisation des mots clés eq (equals), like et gt (greater than) :

private static QPerson person = QPerson.person;

public static BooleanExpression fromCity(String city) {
 return person.city.like(city);
}

public static BooleanExpression byName(String firstName, String lastName) {
 return person.firstName.eq(firstName).and(person.lastName.eq(lastName));
}

public static BooleanExpression adults() {
 return person.age.gt(18);
}

J'aime beaucoup cette syntaxe, elle est vraiment fluide, facile à écrire et lisible. Il est bien sur possible de gérer des cas plus complexes, je vous laisse consulter la doc de Querydsl pour en savoir plus.

Pour exécuter une requête utilisant un de ces prédicats, il suffit d'écrire :

personRepository.findAll(Person.fromCity("maVille"))

personRepository.findAll(Person.adults())

Pour que tout cela fonctionne, notre repository doit implémenter QuerydslPredicateExecutor. On doit également définir ce plugin dans le build maven, qui se chargera des générer les classes Q* pour chacune des entités du projet :

<plugin>
        <groupId>com.mysema.maven</groupId>
      <artifactId>maven-apt-plugin</artifactId>
      <version>1.0</version>
      <executions>
          <execution>
              <phase>generate-sources</phase>
              <goals>
                  <goal>process</goal>
              </goals>
              <configuration>
                  <outputDirectory>target/generated-sources</outputDirectory>
                  <processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
              </configuration>
          </execution>
      </executions>
  </plugin>

N.B : Il est possible d'écrire nos prédicats avec l'api criteria de JPA 2 au lieu de Querydsl si on le souhaite, en utilisant la classe org.springframework.data.jpa.domain.Specification à la place de nos BooleanExpression.

Voyons comment utiliser nos repositories et nos prédicats :

@Test
  public void testPersistence() {

      Person p = new Person();
      p.setFirstName("loic");
      p.setLastName("descotte");
      p.setCity("Grenoble");
      p.setAge(29);

      Person p2 = new Person();
      p2.setFirstName("john");
      p2.setLastName("doe");
      p2.setAge(17);
      p2.setCity("NYC");

      //save
      personRepository.save(p);
      personRepository.save(p2);

      persons = personRepository.findAll();
      assertEquals(persons.size(),2);

      persons = (List) personRepository.findAll(Person.fromCity("%Gre%"));
      assertEquals(persons.size(),1);
      assertEquals(persons.get(0).getFirstName(),"loic");

      persons = (List) personRepository.findByFirstNameAndLastName("loic", "descotte");
      assertEquals(persons.size(),1);
      assertEquals(persons.get(0).getCity(),"Grenoble");

      persons = (List) personRepository.findAll(Person.adults());
      assertEquals(persons.size(),1);
      assertEquals(persons.get(0).getFirstName(),"loic");
  }

Dans cet exemple le code client est une classe de test, mais on peut très bien appeler notre repository depuis un service REST, depuis la couche graphique, etc. (voir le code source de l'exemple en téléchargement à la fin de cet article).

On voit dans ces exemples qu'on a complètement modifié notre façon d'architecturer notre application Spring: on peut si on le souhaite se passer des couche "services" ou "business" qui contiennent habituellement la logique de notre application.
En effet Spring-Data et ses repositories ont un bon gout de DDD (Domain Driven Design). Ceux qui ont essayé Play connaissent déjà cette approche.
Le code métier de notre application peut être recentré sur le modèle (objets du domaine métier). A nous la vrai conception objet, fini les modèles anémiques sans intelligence dont les seules méthodes sont des getters et des setters.
Comme vous le voyez dans cet exemple, on a même la possibilité de placer nos prédicats d'accès à la base de données dans la classe Personne.

Pour conclure ce nouveau framework est vraiment prometteur et apporte pas mal de nouveautés et de facilités aux applications codées en environnement Spring.
Le seul bémol que j'ai vu étant (comme souvent avec Spring et Maven) le temps nécessaire pour mettre au point la configuration XML et trouver les bonnes dépendances (sans compter les conflits avec Jersey, etc.)
Mais comme je suis sympa vous pouvez tout recopier dans le code source des exemples de l'article : code source de l'exemple.

Je vous conseille de jeter également un oeil aux autres projets de Spring-Data, tout aussi intéressants et qui adressent le monde NoSQL (bases orientées graphes, documents, clé/valeur...).

WebSocket et Play Framework

2011-05-22T16:33:00.002+02:00

Vous avez surement entendu parler de WebSocket, un (futur) standard HTML 5 qui permet de faire du push de données du serveur vers le navigateur.
L'utilisation des WebSockets est très simple avec Play et très utile dans le cas de traitements asynchrones.

Vous pouvez lire ce nouveau chapitre dédié à WebSocket sur l'ebook play.rules : https://github.com/3monkeys/play.rules/blob/master/livre.play.un/part01-ch05-jobs-et-traitements-asynchrones.md (deuxième partie du fichier).

Comme d'habitude n'hésitez pas à envoyer vos remarques si des éléments ne sont pas clairs ou si vous trouvez des fautes :)

Du Play et du Scala!

2011-04-12T19:25:00.001+02:00

Je suis entrain de réécrire entièrement en Scala mon application de démo pour Play framework!
Le code de l'application est disponible ici : https://github.com/loicdescotte/vote4music-scala
Une occasion de comparer les langages, puisque la version Java est disponible là : https://github.com/loicdescotte/vote4music

Personnellement je trouve l'API Scala de Play plutôt bien pensée, elle colle même peut être encore plus à l'esprit Play que la version Java. On gagne en concision et surtout en expressivité du code grâce à l'approche fonctionnelle.

Le code de l'application n'est pas encore parfait, il reste quelques bugs et quelques TODO (les API Json et XML ne sont par exemple pas encore fonctionnelles). Mais la plupart des fonctionnalités sont là.

Cette version Scala fera d'ailleurs l'objet d'un chapitre dans le livre Play.rules dont je vous ai parlé dans le post précédent.

Pourquoi Play + Ebook gratuit et open source!

2011-04-10T12:48:00.003+02:00

Sur ce blog il m'est souvent arrivé de vous parler de Play Framework.
Aujourd'hui revenons un peu au début de l'histoire, je vais vous présenter les raisons pour lesquelles j'aime autant Play.

J'ai décris toutes ces raisons ici (suivez le lien)

En fait ceci n'est que le premier chapitre d'un Ebook gratuit, open source et collaboratif sur lequel je travaille avec mes 2 amis @k33g_org et @mklabs! Notre but est de fournir un livre convivial, facile à lire et avec un ton un peu différent de ce qu'on trouve dans la littérature habituelle. L'aspect open source donnera, je l'espère, l'envie à des personnes de nous aider pour les relectures ou de contribuer à des chapitres!

On en est qu'a tout début, il reste encore beaucoup à écrire. Mais on avance à bon rythme et petit à petit le livre devrait se remplir! Vous pouvez déjà le consulter librement sur GitHub : https://github.com/3monkeys/play.rules

Présentation du langage Scala par Aleksandar Prokopec de l'EPFL

2011-03-25T14:21:00.000+01:00

Lundi dernier nous avons eu le plaisir d'accueillir à l'Alpes JUG Aleksandar Prokopec, un des contributeurs de Scala, le langage orienté objet et fonctionnel pour la JVM dont tout le monde parle en ce moment.

Les slides et le compte rendu de la présentation sont disponible ici.