La prochaine session du Paris Scala User Group aura lieu jeudi 26 Janvier à 19h30 dans les locaux de Xebia.

À cette occasion, Stéphane Landelle nous présentera Gatling qui est un outil de stress test écrit en Scala et reposant sur les frameworks akka et Netty. En seconde partie, il nous donnera un retour d’expérience sur l’utilisation de Scala pour développer l’outil.

Il reste encore des places. Si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Actualité éditeurs / SSII

• Spring Integration 2.1 (Par Bertrand Dechoux)
• Spring Data Redis 1.0.0 (Par Bertrand Dechoux & Mathieu Bigorne)
• « Big Data » par Nathan Marz et Sam Ritchie est disponible en MEAP (Par Bertrand Dechoux)
• Scalding, une API Scala pour Cascading par Twitter (Par Bertrand Dechoux)
• Firefox 10 sortira en version ESR (Par Benoit Lemoine)
• Firebug 1.9.0 (Par Bertrand Dechoux)

Le coin de la technique

• Seren : Serialization Enhancer (Par Jean Helou)
• Apologie des lambdas de blocks pour javascript (Par Jean Helou)
• Verbosité des langages de programmation (Par Olivier Michallat)

Evénements de notre communauté en France et à l’étranger

• L’artisanat, un métier d’avenir (Par Xavier Bucchiotty)
• Une semaine riche pour les User Groups

Actualité éditeurs / SSII

Spring Integration 2.1

Un an après la sortie en 2.0, Spring Integration est désormais disponible en version 2.1. On notera un meilleur support des scripts (Groovy, Ruby/JRuby, Python/Jython, et JavaScript) grâce à la JSR-223. Il est ainsi possible de définir des ‘filters, splitters, routers, transformers’ directement dans vos fichiers de configuration ou par l’intermédiaire de ressources, permettant de cette manière de recharger vos scripts à chaud. On notera également une meilleure intégration avec RabbitMQ/AMQP, GemFire, Redis et MongoDB.

Spring Data Redis 1.0.0

Spring Data Redis est sortie le mois dernier dans sa première version stable. Redis est une base de données clé-valeur avec d’excellentes performances qui peut stocker les types de données classiques (chaîne de caractères, liste, map …). Spring Data Redis fournit un niveau d’abstraction supplémentaire qui facilite l’interaction avec Redis. Cette version permet également d’utiliser Redis comme implémentation d’un cache via l’abstraction de Spring. Il s’agit de la première solution NoSql KeyValue supportée par Spring Data mais Riak ne devrait pas se faire attendre longtemps.

« Big Data » par Nathan Marz et Sam Ritchie est disponible en MEAP

Big Data est un univers à part entière et rend non triviale la conception d’une architecture à la fois rapide (« temps réel ») et supportant de grandes volumétries. Deux ingénieurs de Twitter, Nathan Marz -créateur de Storm- et Sam Ritchie en dévoilent les principes dans « Big Data, Principles and best practices of scalable realtime data systems ». Le livre n’est pour l’instant pas finalisé mais est disponible en MEAP (Manning Early Access Program). Le code bd50 vous permet de disposer d’une réduction de 50%.

Scalding, une API Scala pour Cascading par Twitter

Hadoop est un acteur incontournable du BigData. Pour autant, peu vous vanteront la concision des traitements de données implémentés en se basant uniquement sur son API Java. De nombreuses solutions apparaissent pour combler ce manque. Certaines introduisent un nouveau langage comme Pig et Hive. D’autres proposent une API plus succincte, mais en gardant un langage complet, comme c’est le cas de Cascading. Mecredi 11 Janvier, Twitter a rendu open source Scalding, son API Scala pour Cascading, simplifiant encore plus l’usage de MapReduce dans un environnement Scala. Pour les fans de Clojure, Cascalog est une solution similaire mais encore plus succincte. La version 1.8.5 est sortie le 4 Janvier.

Firefox 10 sortira en version ESR

La fondation Mozilla a finalement décidé de maintenir 2 versions de Firefox en parallèle : la première suivra le cycle de livraison actuel (toutes les 6 semaines); alors que la seconde, plutôt à destination des entreprises, aura un cycle de livraison d’un an. Cette version ESR (Extended Support Release), dont Firefox 10 sera le premier représentant, sera maintenue avec les mises à jour de sécurité uniquement, le moteur de rendu et la gestion de plugin n’évoluant pas.

Firebug 1.9.0

Pour les inconditionnels de Firefox, la version 1.9.0 de Firebug vient de sortir. On notera entre autres la possibilité de renvoyer les requêtes HTTP ou encore de visualiser les headers des réponses contenues dans le cache.

Le coin de la technique

Seren : Serialization Enhancer

Olivier Croisier a annoncé cette semaine SEREN, une bibliothèque destinée à accélérer la sérialisation des objets en améliorant le traitement des wrappers numériques et des chaînes de caractères.
Prenant la forme d’un agent pour la JVM, SEREN peut s’utiliser sans modifier le code existant et peut être ajouté ou supprimé simplement en redémarrant la JVM.

Comme toute amélioration de performance, il s’agit d’un compromis: SEREN propose d’augmenter un peu la taille du flux binaire sérialisé en échange d’un gain de vitesse, un compromis que l’auteur recommande pour la sérialisation mémoire en citant EHCache. Il est possible de configurer les classes « améliorées » par SEREN au travers des fichiers de configuration et d’un mécanisme de filtre qui peut être étendu au besoin.

Retrouvez l’introduction de SEREN sur son blog et le code sur github.

Apologie des lambdas de blocks pour javascript

Le working group ECMA, responsable de la définition du standard ECMAScript implémenté par javascript envisage l’ajout de lambdas de blocks à javascript, un ajout que Yehuda Katz défend dans un article de blog parfaitement illustré comparant ruby et javascript sur le terrain du principe de correspondance de Tennent, des lambdas de fonctions et des lambdas de blocks.
Les exemples utilisés présentent des refactorings d’une forme canonique vers des formes idiomatiques dans les deux langages pour illustrer les principes mis en œuvre, une excellente introduction au sujet.

Verbosité des langages de programmation

À l’heure où les comparaisons entre langages tournent souvent en guerres de clochers, Dhanji R. Prasanna (ancien employé de Google et membre du projet Guice) se livre à une analyse plus posée et réfléchie sur l’équilibre entre expressivité et lisibilité. Cet article se démarque par son pragmatisme, la pertinence des exemples choisis, et le recul évident de l’auteur sur un grand nombre de langages.

Lire Languages, Verbosity, and Java.

Evénements de notre communauté en France et à l’étranger

L’artisanat, un métier d’avenir

Plusieurs réflexions ont lieu en ce moment au sein de la communauté pour définir ce qu’est le métier de développeur. On en a parlé lors du Paris JUG d’Octobre 2011. Le mouvement de fond associé est bien sûr celui du Software Craftsmanship. Nous mettons cette semaine en avant deux entrées de blog pour nous aider à avancer sur le sujet.
Le premier article postule que le développement informatique ne peut-être vu ni comme un art ni une science. Pour l’auteur de ce blog, au titre provocateur, notre métier n’est pas purement un art car le produit fini fait quelque chose ni totalement une science car il n’y a pas de loi universelle sur le développement, il peut y avoir autant de réponse qu’il y a de développeurs. On peut accepter ces arguments ou pas. Mais au delà du pur débat d’idées on se rend compte qu’il est difficile d’expliquer un métier si complexe à une personne extérieure.

L’auteur revient aussi sur le caractère unique des réalisations informatiques, et unique dans sa réalisation comme ses défauts. Il porte l’empreinte des personnes qui l’ont réalisé. Nous avons tous notre propre expérience sur des outils, des méthodes, des technologies, et nous expérimentons quelques fois de nouvelles façons de faire. Cela rend la manière de réaliser le travail éphémère et inscrite dans un contexte.
C’est peut-être cela la différence entre produire et écrire du code. Une vision « industrialiste » de la production du code induit une idée de volume, de quantitatif. La production serait le résultat d’un processus établi au résultat attendu, le développeur n’étant que l’élément interchangeable de transformation de la spécification à la réalisation.
L’autre vision s’attache plus à l’aspect qualitatif et humain. Le travail est confié à une personne et est un élément prépondérant dans la rédaction d’une solution au problème donné. L’auteur d’un travail d’écriture de code se voit assigné une ligne directrice, à lui ensuite de tracer le meilleur chemin.

Le second billet revient sur l’importance de s’appuyer sur des personnes qui savent faire les choses. Créer une table de toutes pièces pour le commun des mortels ne semble pas compliqué. Un menuisier professionnel aura lui une toute autre vision de la réalisation. Il pensera à adapter au mieux son savoir-faire au besoin précis du client, anticipera bien plus de problèmes, choisira avec soin les outils et matériaux employés.
Nous sommes dans un contexte qui nous oblige à réduire le temps nécessaire pour mettre à disposition de nouvelles fonctionnalités. Comment alors expliquer à un utilisateur que le changement de formule de calcul d’un champ dans un rapport peut prendre plusieurs heures? Échangeons alors sur nos visions des choses. Si le client ne veut pas d’une table qui dure un siècle, il n’y a pas de raison de la fabriquer. Si par contre, il n’en a pas conscience, discutons ensemble pour trouver la meilleure façon de la réaliser. C’est en travaillant ensemble que le résultat sera celui attendu.

Une semaine riche pour les User Groups

Cette semaine est riche en événements proposés par les UG. Il y en aura pour tous les goûts.

Ce soir, mardi 17 :

• Le Lyon JUG propose une soirée Performance des serveurs en Java animée par Ludovic Poitou.
• Le Normandie JUG propose une soirée Annotation animée par Olivier Croisier.

Le mercredi 18, l’Alpes JUG propose une soirée Objectif Cloud avec Paul Sandoz et Nicolas De Loof.

Le jeudi 19 :

• Le Paris Groovy and Grails User Group accueilleCédric Champeau sur le thème Groovy 2.0 : un pas vers le typage statique.
• Le Toulouse JUG organise une soirée Grails animée par Vincent Barrier et Franck Silvestre.
• Le Paris Android User Group propose une conférence sur Ice Cream Sandwich animée par Léo Cacheux et Daniel Fages.
• Le Bordeaux JUG accueilleura Romain Maton pour une soirée Optimisez votre site web sur mobile.
• Le Mars JUG propose une soirée EclipseLink animée par Shaun Smith.

Pour vous tenir à jour, suivez le calendrier de conférences maintenu par Duchess France.

Si le switch-case acceptant des chaînes de caractères est pour vous une chouette invention, le pattern matching de Scala nous indique que ce n’est pas suffisant ! En effet, il y a d’autres cas où une série de if-else_if-else_if… serait sympathiquement transformée en une sorte de structure plus ou moins équivalente au switch-case. Par exemple, ce serait bien de pouvoir simplifier une série de compositions entre des instanceof et des class cast enfermés dans cette série de if-else_if-… en vue de réaliser des traitements spécifiques selon le type d’un paramètre (en attendant le multi-méthode).

Dans cet article, nous allons voir ce que peut apporter le pattern matching de Scala dans différents cas.

Note : le pattern matching tel qu’il apparaît dans le langage Scala n’est pas nouveau. Cette caractéristique existe déjà dans des langages comme OCaml et Haskell. On le retrouve aussi dans des dialectes de Lisp. Prolog propose aussi une sorte de pattern matching, mais celui-ci utilise en fait un mécanisme assez différent (on parle d’unification dans ce cas).

Approche classique

Le pattern matching de Scala possède un cas d’utilisation qui est similaire aux switch-case de Java et de C : chaque entrée se base sur un entier ou tout autre scalaire. Voici un exemple :

def toYesOrNo(choice: Int): String = choice match {
  case 1 => "yes"
  case 0 => "no"
  case _ => "error"
}

Si vous appelez toYesOrNo(1), Scala répond "yes". Et si vous entrez toYesOrNo(2), Scala répond "error". Ici, le symbole _ est utilisé pour indiquer le cas par défaut. On peut remarquer que nous n’utilisons pas l’instruction break. Cette instruction est d’une certaine manière implicite.

Maintenant, si vous souhaitez que la fonction réponde "yes" non seulement pour la valeur 1, mais aussi pour les valeurs 2 et 3, on écrira :

def toYesOrNo(choice: Int): String = choice match {
  case 1 | 2 | 3 => "yes"
  case 0 => "no"
  case _ => "error"
}

Jusque là, rien de vraiment nouveau.

Utilisons des chaînes de caractères en entrée, comme le permet Java 7. Utiliser des chaînes est intéressant par exemple lorsque vous devez analyser les arguments passés à votre programme :

def parseArgument(arg: String) = arg match {
  case "-h" | "--help"    => displayHelp
  case "-v" | "--version" => displayVerion
  case whatever => unknownArgument(whatever)
}

Si vous entrez parseArgument("-h") ou parseArgument("--help"), Scala appellera la fonction displayHelp. Et si vous entrez parseArgument("hein?"), Scala appellera la fonction unknownArgument("hein?"). Dans la fonction parseArgument, nous n’avons pas utilisé ‘_’ pour le cas par défaut. En fait, lorsque le cas par défaut est utilisé, contrairement aux fonctions précédentes, on a la possibilité de lui donner un nom.

Pattern typé

Parfois en Java, vous devez faire face à une variable déclarée en tant que Object ou toute autre interface ou classe de haut niveau. Malheureusement, après avoir vérifié que la variable n’est pas nulle, vous devez en plus utiliser une série de if-else incluant des tests avec instanceof et cast. Tout ça dans le but de vérifier la classe ou l’interface d’une instance, avant de l’utiliser et de la traiter comme il se doit. C’est le cas, par exemple, lorsque vous devez redéfinir la méthode equals() en Java.

Voici comment Scala voit la chose :

def f(x: Any): String = x match {
  case i:Int => "integer: " + i
  case _:Double => "a double"
  case s:String => "I want to say " + s
}

On obtient alors les résultats suivants :

f(1) → "integer: 1"
f(1.0) → "a double"
f("hello") → "I want to say hello"

N’est-ce pas mieux qu’une succession de if+instanceof+cast ?

Ce type de pattern matching est utile pour traverser une structure utilisant le design pattern composite. Par exemple, vous pouvez l’utiliser pour explorer plus aisément le DOM d’un document XML ou le modèle objet d’un message JSON.

Approche fonctionnelle du pattern matching

Une particularité d’une telle structure, c’est qu’elle offre une approche alternative pour écrire des fonctions. Par exemple, considérons la fonction factorielle. Si nous choisissons la version récursive, habituellement nous la définirions ainsi :

def fact(n: Int): Int =
  if (n == 0) 1
  else n * fact(n - 1)

Mais, on peut aussi utiliser le pattern matching de Scala dans ce cas :

def fact(n: Int): Int = n match {
  case 0 => 1
  case n => n * fact(n - 1)
}

Notez l’utilisation de la variable n ci-dessus. Elle est mise en correspondance avec toutes les valeurs qui n’apparaissent pas dans les cas précédents. Il faut comprendre que le n du dernier cas n’est pas le même que celui utilisé dans la signature de la fonction. Si vous voulez utiliser directement le paramètre n et non pas une autre variable du même nom, vous devez délimiter le nom de la variable par des guillemets inversés dans la déclaration du case, comme ceci : `n`

Sinon, voici un moyen simple de définir la fonction factorielle en Scala :

def fact(n) = (1 to n).foldLeft(1) { _ * _ }

Où foldLeft est une opération visant à « réduire » une collection par rapport à une fonction et { _ * _ } est une fonction anonyme qui équivaut à { case (x: Int, y: Int) => x * y }, autrement dit une fonction qui prend deux entiers et effectue la multiplication de ces deux entiers.

Pattern matching et collection : l’approche par « similarité »

Le pattern matching peut être appliqué aux collections. Ci-dessous, vous avez une fonction qui calcule la longueur d’une liste sans pattern matching :

def length[A](list: List[A]): Int = {
  if (list.isEmpty) 0
  else 1 + length(list.tail)
}

Maintenant, voici la même fonction avec le pattern matching :

def length[A](list: List[A]): Int = list match {
  case Nil => 0
  case _ :: tail => 1 + length(tail)
}

Dans cette fonction, il y a deux cas (ou plutôt deux case). Le premier vérifie si la liste est vide grâce à la valeur Nil. Le second vérifie si il y a au moins un élément dans la liste. La notation _::tail doit être interprétée comme « une liste ayant au moins un élément, sachant qu’on ne s’intéresse qu’au reste de la liste qui est représenté par la variable tail ». Ici, le reste peut être Nil (ie. la liste vide) ou n’importe quelle liste non vide.

On peut utiliser cette approche par similarité avec des tuples afin d’améliorer la méthode parserArgument vue auparavant :

def parseArgument(arg : String, value: Any) = (arg, value) match {
  case ("-l", lang) => setLanguageTo(lang)
  case ("-o" | "--optim", n : Int) if ((0 < n) && (n <= 5))
    => setOptimizationLevelTo(n)
  case ("-o" | "--optim", badLevel) => badOptimizationLevel(badLevel)
  case ("-h" | "--help", _) => displayHelp()
  case bad => badArgument(bad)
}

Notez en premier lieu l’utilisation de l’opérateur | qui permet de mettre en correspondance des formes alternatives de arg au sein d’un tuple. Notez aussi l’utilisation de deux patterns pour les options -o et --optim. Ces patterns se distinguent par l’utilisation d’un prédicat qu’on appelle une garde. Une garde vous permet d’affiner vos case lorsque le pattern ne suffit pas.

Pattern Matching avancé : case class

Les case classes sont des classes dont une partie du comportement est prédéfinie afin de faciliter leur construction et leur utilisation dans des patterns. Les cases classes vous permettent de manipuler des symboles paramétrés, provenant par exemple de l’analyse d’un compilateur ou de votre DSL interne.

L’exemple ci-dessous montre comment utiliser les case classes et le pattern matching afin de représenter simplement des expressions mathématiques, de les évaluer et d’en calculer la dérivée. Commençons par définir les symboles que nous utiliserons : la variable X, la constante, l’addition, la multiplication et la négation (pour le fun !). Ici, sealed signifie qu’aucune classe fille de Expression n’apparaîtra en dehors de l’espace de nom courant.

sealed abstract class Expression
case object X extends Expression
case class Const(value: Int) extends Expression
case class Add(left: Expression, right: Expression) extends Expression
case class Mult(left: Expression, right: Expression) extends Expression
case class Neg(expr: Expression) extends Expression

Maintenant, définissons une fonction qui évalue une expression avec une valeur donnée pour la variable X, en utilisant le pattern matching.

def eval(expression: Expression, xValue: Int): Int = expression match {
  case X => xValue
  case Const(cst) => cst
  case Add(left, right) => eval(left, xValue) + eval(right, xValue)
  case Mult(left, right) => eval(left, xValue) * eval(right, xValue)
  case Neg(expr) => - eval(expr, xValue)
}

Essayons la fonction eval :

// 1 + 2 * X*X
val expr = Add(Const(1), Mult(Const(2), Mult(X, X)))
assert(eval(expr, 3) == 19)

Maintenant, définissons une fonction qui calcule la dérivée (non réduite) par rapport à X d’une expression :

def deriv(expression: Expression): Expression = expression match {
  case X => Const(1)
  case Const(_) => Const(0)
  case Add(left, right) => Add(deriv(left), deriv(right))
  case Mult(left, right) => Add(Mult(deriv(left), right), Mult(left, deriv(right)))
  case Neg(expr) => Neg(deriv(expr))
}

Essayons notre fonction deriv :

val df = deriv(expr)

Voici à quoi ressemble df :

Add(Const(0),
  Add(Mult(Const(0),Mult(X,X)),
    Mult(Const(2),
      Add(Mult(Const(1),X),
        Mult(X,Const(1))))))
// = 0 + (0 * X*X + 2 * (1*X + X*1)) = 4 * X

Et en utilisant les deux fonctions conjointement :

assert(eval(df, 3), 12)

Autres utilisations avancées du pattern matching

Il y a d’autres notations particulières utilisables dans le pattern matching de Scala. Scala permet ainsi de déclarer des alias sur tout ou partie d’un pattern qui pourront être exploités par la suite. L’alias doit apparaître avant le pattern séparé d’un @. Par exemple, dans l’expression address @ Address(_, _, "Paris", "France"), nous acceptons dans address toutes les adresses en France à Paris, mais peu importe la rue et le numéro.

Il y a une notation spécifique pour faire correspondre des séquences avec _*. Cette notation prend en compte zéro élément, un élément ou plus dans une séquence.

En Scala, le pattern matching n’apparaît pas seulement après la fonction match. Vous pouvez utiliser le pattern matching pour les paramètres de closures et dans les blocs catch.

Il est possible aussi de personnaliser le comportement du pattern matching au moyen des extractor. Pour cela, vous devez définir la méthode unapply (et/ou unapplySeq pour une séquence) au niveau des objets que vous utiliserez dans les pattern matching.

Conclusion

Dans cet article, nous avons vu différentes manières d’utiliser le pattern matching de Scala. Le principal avantage de cet outil est de fournir une manière simple de construire des structures alternatives basées sur la mise en correspondance de valeurs scalaires, de chaînes de caractères, de collections, mais aussi de symboles paramétrés et de types. Pour moi, le pattern matching est l’une des alternatives les plus sexy à la structure if ! Une bonne utilisation du pattern matching peut rendre votre programme plus lisible et vous aider à mettre en oeuvre un DSL interne.

Cet article est une traduction libre, faite avec l’autorisation de l’auteur, de « Playing with Scala’s pattern matching » publié par François Sarradin le 14/02/2011 sur http://kerflyn.wordpress.com/.

Le coin de la technique

• Infinitest supporte scala
• CouchBase et CouchDB (par Xavier Bucchiotty)
• Alerte de sécurité sur la quasi totalité des serveurs web (par Pierre Laporte)

Evénements de notre communauté en France et à l’étranger

• Lancement de la communauté Software Craftsmanship de Toulouse
• Ce soir, 10 janvier, Paris JUG DevOps et Avant JUG des Duchess
• Introduction aux DSL en Groovy au Nantes JUG le jeudi 12 janvier

Le coin de la technique

Infinitest supporte scala

Les dernières versions d’infinitest apportent des corrections pour intellij IDEA 11 et le support des projets Scala. Infinitest est disponible sur github.

CouchBase et CouchDB

Damien Katz est un des fondateurs du projet Apache CouchDB. CouchDB fait partie de l’univers NoSQL, écrit en Erlang, orienté ‘document’ avec des API basées sur Javascript et JSON. Dans son blog, il indique qu’une grande partie de l’équipe ainsi que lui-même quittent le projet pour fonder Couchbase Server, le successeur.
Ce changement signifie aussi que les produits Couchbase ne seront plus sous licence Apache. Damien Katz ne dénigre pas cette fondation, à qui le succès de CouchDB est intimement lié. Les produits CouchBase sont payants, et selon Damien Katz, l’approche par consensus des développeurs, si chère à Apache, est un frein à la compétitivité du produit.
Cette approche permet donc à l’équipe de servir au mieux ses clients avec une plus grande réactivité. Il assure cependant que l’équipe continue de contribuer à CouchDB qui se porte plutôt bien. Son but actuel est de porter la version 2.0 de CouchBase avec un portage d’une partie du code d’Erlang vers C/C++.
Affaire à suivre.

Alerte de sécurité sur la quasi totalité des serveurs web

Deux chercheurs en sécurité, Alexander Klink et Julian Wälde, ont relevé une faille de sécurité algorithmique dans la plupart des serveurs web du marché. Sont concernées, les plateformes Java, Python, Ruby, PHP, Node.JS et ASP.NET.

La vulnérabilité détectée est de type attaque par complexité algorithmique. Elle consiste à rechercher le pire scénario possible dans l’implémentation d’une fonctionnalité. Ici, les hash tables sont la cible de l’attaque.

Le principe est le suivant : lorsqu’un serveur reçoit une requête http qui contient n paramètres, il crée un tableau associatif avec pour clé, le nom du paramètre, et pour valeur, l’ensemble des valeurs reçues. La hash table résultante utilise le hachage du nom du paramètre pour déterminer son emplacement.

Dans le meilleur des cas, c’est-à-dire lorsqu’il n’existe pas deux paramètres ayant le même hachage, l’insertion d’un élément se fait en temps constant (en O( 1 )). Dans le pire des cas, elle se fait en temps linéaire (en O( n )).

Mais revenons à notre attaque. Il suffit de construire une requête HTTP avec un grand nombre de paramètres ayant tous le même hachage. Le serveur sera contraint de passer systématiquement par le pire des cas possibles pour l’insertion dans sa hash table. En prenant n paramètres, on arrive à une complexité de n(O( n )), c’est-à-dire O( n² ), la complexité quadratique. Il est donc possible de bloquer le CPU d’un serveur à 100% d’utilisation pendant plusieurs minutes.

A l’heure actuelle, certains serveurs ont été mis à jour pour limiter le nombre de paramètres HTTP pouvant être reçus par un serveur (1’000 pour ASP.NET, 10’000 pour Tomcat, valeur non connue pour PHP). La vulnérabilité n’est donc pas totalement corrigée mais ses effets sont considérablement réduits. La correction complète impliquerait de rendre aléatoire le hachage des chaînes de caractères selon les plateformes par l’inclusion d’un seed. De ce fait, il ne serait plus possible de construire de telles collisions.

Notons qu’une correction est également en cours pour Glassfish et sera mise à disposition avec le prochain patch de sécurité.

Evénements de notre communauté en France et à l’étranger

Lancement de la communauté Software Craftsmanship de Toulouse

La semaine dernière, Antoine Vernois et Thierry Cros ont organisé à Toulouse une réunion autour du Software Craftsmanship qui a réuni 15 personnes. Cette réunion marque le lancement de la communauté Software Craftsmanship de Toulouse et de ses environs.
Un premier événement est en cours de planification : Un coding dojo au format randori.
Vous trouverez plus de détails sur le blog d’Antoine : La communauté Software Craftsmanship à Toulouse.

Ce soir, 10 janvier, Paris JUG DevOps et Avant JUG des Duchess

Ce soir, le premier Paris JUG de l’année sera consacré à DevOps avec une session Packaging natif par Henri Gomez et une session Puppet par Carlos Sanchez.
Les Duchess reprennent également les bonnes habitudes avec le premier Avant JUG de l’année.

Introduction aux DSL en Groovy au Nantes JUG le jeudi 12 janvier

Le Nantes JUG commence l’année 2012 ce jeudi 12 avec une soirée Introduction aux DSL (Domain Specific Languages) en Groovy présentée par Cédric Champeau, senior software developer chez SpringSource.
Les inscriptions sont ouvertes sur JUG Events.

Xebia a le plaisir d’organiser un Paris Mongo Day avec Dwight Merriman et 10gen le 2 Février !

09h30 – 11h30 : Rencontrez Dwight Merriman, CEO de 10Gen

Venez rencontrer le CEO d’une des startups les plus en vue du monde NoSQL.

• 09h30 – 11h00 : présentation de l’univers NoSQL par Dwight Merriman, suivie d’une session de questions/réponses avec l’auditoire préparée et modérée par Jean-Laurent de Morlhon.
• 11h00 – 11h30 : petit déjeuner pour faire connaissance avec l’équipe 10gen.

Inscriptions pour la rencontre avec Dwight Merriman de 9h30 à 11h30 ici.

11h30 – 18h00 : Mongo DB du dév à la prod

De 11h30 à 18h30, 2 tracks MongoDB en parallèle autour du développement, de l’exploitation et des retours d’expérience ().

• MONGO (track commune)
  • La roadmap de MongoDB par Dwight Merriman, CEO de 10gen.
  • Les internes de MongoDB par 10gen.

• DEV
  • MongoDB en Java par Katia Aresti (90 mins).
  • MongoDB avec Play! Framework par Guillaume Bort (60 mins).
  • MongoDB en Scala par Olivier Michallat (60 mins).
  • MongoDB avec Grails par Aurélien Maury (60 mins).
  • MongoDB en PHP par Fabrice Bernhard (60 mins).

• OPS
  • Partir en production avec MongoDB par Alvin Richard (10Gen) : mise en place, monitoring, backups, haute disponibilité, support, …
  • MongoDB vs. MySQL vu par des DevOps par Pierre Baillet et Mathieu Poumeyrol (fotopedia).

Un buffet déjeuner sera offert à 12h30.

Inscriptions pour le Mongo Day 11h30-18h30 ici.

19h00 – 22h00 : Meetup avec le Paris MongoDB User Group

De 19h00 à 22h00 Meetup avec le Paris MongoDB User Group, Dwight Merriman et toutes les équipes de 10gen.

Un buffet dinatoire sera offert durant le meetup.

Inscriptions pour le Meetup de 19h00 à 22h00 ici.

À cette occasion, Jean-Luc Canela nous proposera une présentation sur specs2. specs2 est un framework de tests écrit en scala permettant d’écrire vos tests unitaires ainsi que vos tests d’acceptance (en mode BDD) avec une approche fonctionnelle.

Il reste encore des places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Actualité éditeurs / SSII

• Scala : la saga continue
• VMWare, Cisco et Google jouent aux marionnettes

Le coin de la technique

• Hibernate et ses performances anti-patterns
• Gitblit : le nouveau gestionnaire de repositories Git

Evénements de notre communauté en France et à l’étranger

• L’Apache Software Foundation et Subversion
• En vrac

Actualité éditeurs / SSII

Scala : la saga continue

Lors de notre précédente revue de presse nous vous avions parlé de l’article publié par Stephen Colbourne qui expliquait pourquoi il compare Scala aux EJB2. En réponse aux critiques qui l’accusaient de n’avoir pas assez utilisé Scala dans la vie réelle, il a publié un mail envoyé par Coda Hale (ingénieur infrastructure chez Yammer) à Donald Fischer (CEO de Typesafe) et Martin Odersky (créateur de Scala). Ce mail contient une série de critiques précises contre le langage (complexe, courbe d’apprentissage importante, forme idiomatique, outils de build immatures, incompatibilité des binaires entre versions majeures et des problèmes de performances de certaines formes fonctionnelles) qui ont amené Yammer à reconsidérer son utilisation.
Il s’avère ensuite que le mail est un échange privé dans lequel Coda Hale répondait à une demande de Typesafe sur les points d’amélioration possibles du langage, il avait été placé dans un gist de github pour relecture et s’est retrouvé partagé et repris par mégarde. Son contenu finit par être repris de façon générale.
Finalement, Yammer publie sa position officielle toujours par la plume de Coda Hale. Dans ce communiqué, il indique

• qu’ils suivent une philosophie très pragmatique, et qu’ils essayent de nombreux outils pour résoudre leurs problèmes.
• que tous les langages ont des défauts face aux types de problématiques rencontrées chez Yammer
• qu’ils ont construit plusieurs systèmes impressionnants avec Scala (gestion de centaines de milliers d’utilisateurs, de millions de recherches, etc avec des performance très élevées).
• que Scala est un langage encore jeune (il le compare à java 1.3) et qu’il est normal qu’il ait encore quelques bords à arrondir, que c’était justement le sens de la démarche de Typesafe.

En retrait de l’agitation, Martin Odersky adresse indirectement une partie des problèmes remontés lors de cette controverse dans un article publié sur le blog de Typesafe. Quelques points intéressants

• Support au développement avec l’annonce de la sortie en release candidate de scala IDE
• Courbe d’apprentissage réduite d’une part par l’IDE, par des sources gratuites dont un site de documentation collaboratif et pour le reste par des formations.
• Accélération du compilateur et soutient au travail accompli dans le compilateur incrémental de SBT.
• Community avec surtout le passage de Scala sous github

Il évoque également la performance, les frameworks (avec akka, et play2), les plans pour répondre aux problèmes de compatibilité binaire.

La bataille fait rage pour décider du langage qui remplacera Java sur la JVM, bataille qui ne manquera pas de s’amplifier avec les fonctionnalités annoncées pour Java 8 (Jigsaw, Lambda expressions, le reste du projet Coin, …) et l’arrivée de nouveaux challengers annoncés ces derniers temps (Kotlin et Ceylon)

VMWare, Cisco et Google jouent aux marionnettes

PuppetLabs, l’entreprise commerciale derrière l’outil Open source Puppet vient d’annoncer sur son blog que VMWare, Cisco et Google venaient de prendre des parts lors du dernier tour de table effectué par la société. En dehors du blabla marketing d’une telle annonce, il faut bien reconnaître que, comme elle le dit, ces partenaires utilisent déjà Puppet « en production et à grande échelle ». Et il est certain que cette association en jette !
En tout cas, il est certain que cette annonce se présente dans une dynamique très porteuse pour les outils de management de configuration. Avec le Cloud, la tendance à prendre en compte le Devops se confirme et c’est toute l’industrie qui va en bénéficier.
Rappelons que PuppetLabs édite aussi la solution commerciale Puppet Enterprise sortie il y a peu en version 2.0. Et pour ceux que ça intéresse, notons que ce récent article donne des pistes pour optimiser ses éditeurs texte et parle même de Geppetto, un IDE basé sur Eclipse pour Puppet.

Le coin de la technique

Hibernate et ses performances anti-patterns

Pour ceux qui n’ont pas encore vu cette présentation de Patrycja Wegrzynowic à Devoxx, Mathilde Lemée en reparle ici. Cet article détaillé revient avec des exemples précis sur des cas d’utilisation réel de l’outil. On y retrouve les exemples de N+1 SELECT, de problème de synchronisation en écriture et bien d’autres.
L’accroche de la présentation à Devoxx est simple « I do think Hibernate is a great tool ». De plus en plus de débats se lèvent sur l’utilisation de ce framework. Il est évertué par les uns pour son gain de productivité et son utilisation simple mais décrié par les autres pour les contraintes de modélisation qu’il entraîne et son côté opaque.
Lors de notre dernier XKE (Xebia Knowledge Exchange), nous avons eu la chance d’assister à une présentation de David Gageot sur la notion d’outil et de framework. Lors de cette session, il a codé sous nos yeux une application Web simple, sans utiliser de grand framework. L’idée était de nous amener à nous poser les bonnes questions face aux outils que nous utilisons tous les jours:

• En ai-je vraiment besoin ?
• A quoi sert-il vraiment ?
• Son utilisation m’amène-t-elle plus de valeurs ajoutées que de contraintes ?

L’idée directrice de David était de nous montrer que nous ne sommes pas obligés d’utiliser des outils très imposants pour des tâches très simples.
Un outil, à la différence d’un framework, n’imposera que peu de contraintes à son utilisateur. Il restreint son périmètre d’utilisation pour être « expert » dans une tâche bien précise. L’avantage cependant d’un framework est d’offrir des guides d’utilisation, afin d’assurer une homogénéité au sein de plusieurs projets.
Il faut savoir adapter l’outil à la tâche qui lui correspond. Mieux vaut utiliser des outils simples, non intrusifs pour faire correctement ce qui est demandé en se laissant la possibilité de changer plus tard.
De la même manière, Hibernate est un outil puissant, encore faut-il savoir l’utiliser correctement. Tous les cas d’utilisation n’en on pas l’utilité. Mais rappelons nous que si nous voulons l’introduire dans notre projet, apprenons d’abord à bien l’utiliser.Tout est une question d’adaptation. C’est le coeur de notre métier, comprendre le contexte pour lui apporter la meilleure réponse possible. La réponse universelle n’existe pas et c’est cela qui rend notre profession intéressante.

Gitblit : le nouveau gestionnaire de repositories Git

GitBlit est une application Web Open-Source (licence Apache Software Foundation version 2.0), reposant sur une stack pure Java, et qui a pour objectif de gérer, consulter et héberger des repositories Git. Il utilise pour cela JGit, une implémentation Java du gestionnaire de sources distribué.

L’application se présente sous deux modes :

1. Gitblit GO : une solution clé en main basée sur Jetty. Il n’est pas nécessaire d’installer un quelconque serveur Web ou même Git lui-même, c’est l’option à privilégier si l’on veut démarrer le plus simplement et rapidement possible. L’objectif de ce mode est d’obtenir un serveur fonctionnel avec un minimum de configuration. En effet, un unique fichier texte permet de configurer le serveur et Gitblit. Aussi, un certificat pour communiquer via HTTPS est automatiquement généré pour localhost et un script permet d’en générer un pour n’importe quel hostname.
2. Gitblit WAR : si vous utilisez déjà un conteneur de servlets où vous déployer vos différents outils, le mode WAR est à privilégier. Les versions 6, 7 et 8 de Jetty ainsi que les versions 6 et 7 de Tomcat sont supportées. De manière générale, n’importe quelle implémentation de Servlet 2.5 ou 3.0 devrait fonctionner.

Gitblit peut être utiliser de différentes manières :

• Comme une simple IHM Web (inspirée de Gitweb) pour consulter les repositories Git sans accès administrateur ou ou gestion de comptes utilisateurs.
• Comme une stack Git complète pour cloner, « pusher » et contrôler l’accès aux repositories.
• Gitblit peut être utiliser sans aucun outil relatif à Git (dont Git lui-même) ou il peut collaborer avec vos outils existants.

Les administrateurs peuvent gérer les repos et comptes utilisateurs soit via l’IHM Web, soit via une interface JSON RPC accessible depuis le Gitblit Manager (une IHM Swing pour gérer les repos Git et administrer un serveur Gitblit de manière distante) ou depuis un outil custom.

L’application requière au minimum un JRE/JDK 6.

Evénements de notre communauté en France et à l’étranger

L’Apache Software Foundation et Subversion

Ben Collins-Sussman, fondateur du projet Subversion et membre actuelle de l’Apache Software Foundation, vient donner son point de vue sur un débat qui fait rage : Pourquoi l’ASF choisit encore Subversion comme gestionnaire de source ?
La première réponse apportée par Jim Jagielski, un des leaders de l’ASF, est de garantir l’intégrité des projets sur le long terme et ne pas céder aux dernières modes. Ben Collins-Sussman pense lui que l’ASF est aussi présente pour fournir des protections légales face à l’utilisation des outils et d’assurer une cohérence aux long-termes et non seulement sur le software mais aussi sur les membres de la communauté.
Pour lui ce dernier point est assuré au sein de la fondation avec ces quelques mots « community over code ». Les réponses apportées aux différents problèmes des projets se font par consensus et système de vote au sein des projets.
Cet esprit de communauté et de protection légale est la raison pour laquelle Ben Collins-Sussman défend l’idée que les projets Apache doivent joindre le Grand Repository Subersion d’Apache. Mais l’utilisation de ce dépôt de source ne doit en aucun cas être unique. Certains projets pourraient selon lui utiliser Git et déposer de façon automatisée les sources au sein du Subversion d’Apache une fois par jour.
Pour reprendre le titre de son article, entrer dans une communauté, ce n’est pas être forcé d’utiliser tous ses outils.

En vrac

Sortie de Lucene 3.5.0 réduisant entre autre de façon significative la consommation mémoire lors de l’ouverture d’un IndexReader.

Sortie de ElasticSearch 0.18.5 comprenant des corrections de bugs mais surtout reprenant Lucene 3.5.0.

Sortie de Solr 3.5.0 reprenant également Lucene 3.5.0.

Sortie de SpringSource Tool Suite 2.8.1 dont le but principal est de réduire les couts de migrations de m2eclipse à m2e. Il y a d’ailleurs une FAQ intéressante sur m2e fournie par SpringSource (elle est bien sûr applicable aux utilisateurs d’Eclipse version « normale »).

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• Sortie de la première version stable de Restfuse 1.0

Le coin de la technique

• Humour de développeur

Evénements de notre communauté en France et à l’étranger

• Scala et les EJB2
• Retour sur l’atelier Apache Mahout des Duchess France

Actualité éditeurs / SSII

Sortie de la première version stable de Restfuse 1.0

Restfuse 1.0.0 est la première version stable de cette API créée par EclipseSource. Il s’agit d’une extension open source de JUnit qui permet de tester des implémentations différentes REST (Jersey, RESTLET, RESTeasy…). Ses créateurs s’appuient sur le besoin d’avoir des tests d’intégration sur les services REST au-delà des tests unitaires, et des mocks des services afin de vérifier que le système entier fonctionne correctement.

Les objectifs de ce framework sont :

• Trouver une solution propre pour tester les services REST asynchrones. Pour tester les services asynchrones, les deux solutions les plus communes sont : callbacks ou polling. Les annotations @Callback et @Poll sont fournies afin d’éviter de boucler sur la requête ou de démarrer le serveur avant ou dans le test.

• Faciliter la configuration des requêtes avec des annotations. L’annotation @HttpTest permet de configurer la requête HTTP et de l’envoyer avant que le test ne soit exécuté. Cette méthode essaie d’améliorer d’autres APIs de tests, comme rest-assured où la requête doit être configurée en code Java dans la méthode de test.

Vous pouvez trouver des exemples d’utilisation sur la page de Restfuse et aussi dans cet article InfoQ qui contient plusieurs exemples assez pratiques.

Le projet est hébergé sur Github. La version 1.0 est disponible sur le dépôt central de Maven et aussi sur p2 pour le systèmes OSGi.

Le coin de la technique

Humour de développeur

Nous vous avertissons tout de suite, si vous êtes allergiques à l’humour geek ou aux anglicismes, vous pouvez zapper ce passage qui risque de vous faire bondir. Toujours là ? Allons-y alors !
Depuis peu tournent sur la toile des liens vers cet article. Celui-ci est en fait un « best-of » d’une vieille page de StackOverflow ayant généré des commentaires sur 12 (!) pages. Nous vous laissons la lire, en plusieurs fois tout de même pour éviter l’overdose, mais voici une petite sélection:

• les Yoda conditions: elles consistent à inverser la variable avec la valeur testée dans une condition. Ainsi on écrira if (CONST_VALUE == variable) au lieu de if (variable == CONST_VALUE). Ceci car Yoda lui-même parle en inversant les mots: « si grande est la variable, Jedi tu deviendra ».
• Pokémon Exception Handling: consiste à faire un catch (Throwable t) histoire de catcher toutes exceptions. Provient du slogan des Pokemons « catch’em all« .
• Les accolades égyptiennes: elles représentent le formatage par défaut en Java (voir les préconisations de Sun), c’est-à-dire que la position des accolades fait penser à un Égyptien. Le mieux est de voir cela en image.
• Refuctoring: décrit l’action prenant un beau morceau de code bien pensé pour le transformer, à travers une série d’étapes (ir-)réversibles, en un immonde plat de spaghettis non maintenable.
• Stringly Typed: par opposition à « Strongly typed », indique l’absence de typage et l’utilisation à outrance des chaînes de caractères, entraînant des problèmes visibles seulement au runtime. Se rencontre souvent dans les fichiers XML ou chez les novices en Javascript.
• Le Baklava code: désigne du code où trop de couches s’empilent. On fera l’analogie avec la « Théorie des pâtes » qui assimile des problèmes d’architecture du code à des plats de pâtes. On y retrouve le code spaghetti, le code ravioli, le code lasagne et… le code Spaghetti avec boulettes. Délectez-vous avec les recettes !
• Hydra Code: désigne du code impossible à corriger, où une correction entraîne inévitablement de nouveaux bugs.
• Protoduction code: lorsque du code non prévu qui n’était pas destiné à se retrouver en production finit par y atterrir. Le « Protoduction Driven Development » se rapproche ainsi souvent du « Marketing Feature Driven Devlopment ».
• Megamoth: la MEGA MOnolitique méTHode se retrouve souvent dans les projets où des codeurs bien intentionnés ont regroupé en une seule méthode différents traitements et logiques compliqués histoire de garder le reste du code simple et clair. Généralement, cette méthode fait plusieurs écrans de haut, quelques centaines de lignes et les commentaires sont bien sûr sans rapport avec le traitement effectif.

C’étaient quelques-unes des perles de la première page du thread sur Stackoverflow. La lecture du reste des 12 page est bien sûr fortement conseillée pour se détendre les zygomatiques.

Evénements de notre communauté en France et à l’étranger

Scala et les EJB2

Stephen Colebourne, le bouillant project lead de Joda Time présentait à Devoxx le 17 novembre dernier une conférence sur le langage Fantom. De cette présentation on n’en a malheureusement retenu qu’une petite phrase sibylline lourde de sous-entendus: « Scala ressemble aux EJB2″.

La pique n’a pas manqué de créer le buzz, à tel point que Colebourne s’est senti obligé d’y apporter une explication, puis une autre.

Colebourne voit du mérite dans bien des langages: Groovy, Kotlin, Ceylon, Gosu, Xtend, Clojure et bien entendu, Fantom. Mais sur Scala il reste plutôt sévère: selon lui il y aurait « beaucoup à dire sur Scala, mais peu de bien », car ce langage « prend une direction totalement erronée pour l’avenir ».

Mais que reproche-t-il au juste à ce langage?

• Modularité. Scala n’a pas de système de modules et reprend ainsi une erreur fondamentale du langage Java, difficile à corriger (cf. le projet Jigsaw). Colebourne est d’avis qu’un outil externe tel que Maven, Ivy ou OSGi n’est pas une solution durable à un problème qui doit être résolu au coeur même du langage.

• Concurrence: pourtant si vantée, la programmation concurrente sous Scala ne serait pour Colebourne qu’un « écran de fumée ». Scala s’appuie davantage sur le design de ses librairies et sur une certaine discipline de codage que sur une contrainte forte et inhérente au langage, et permet en effet qu’un objet mutable soit partagé — contrairement à Fantom, qui lui traque ces objets et les signale par des erreurs de compilation.

• Communauté: la communauté Scala serait certes large et active, mais faite de sophistes davantage mus par la beauté du langage et l’émulation intellectuelle que par l’efficacité pragmatique des algorithmes. Colebourne la considère comme un cercle élitiste tendant à prendre de haut le Javaïste « de base ».

• Système de typage: pour Colebourne, ils serait tout simplement trop complexe, « au-delà du raisonnable ». Cette complexité serait un faux atout: « si j’ajoute un String à une liste d’entiers, je devrais obtenir une erreur de compilation, non une liste de Any« .

• Syntaxe: même verdict. Si la flexibilité permet l’écriture fluide de DSLs (et encore, Colebourne y préfère l’approche à la Fantom), les paramètres implicites ou encore les nombreux sucres syntaxiques du langage donneraient au code un côté obscur et hermétique. Utilisés à large échelle sur de grands projets par de vastes équipes, leur effet serait plutôt négatif sur la maintenabilité du code.

• Qualité: Colebourne rend ici la parole à Paul Phillips, un commiteur Scala, et cite des extraits d’un podcast datant de Juin 2011. Philips y évoque l’extraordinaire complexité du code et surtout avoue platement que Scala manque d’une « suite de tests extensive » couvrant l’ensemble du code. Pour Colebourne, c’est la preuve même que Scala n’aurait pas encore atteint les niveaux de maturité, maintenabilité et évolutivité que l’on est en mesure d’attendre d’un langage d’entreprise. (A quoi nous pourrions également rajouter que, comme le note Ceki Gülcü, Scala a à de nombreuses reprises brisé la compatibilité binaire entre releases: 2.7, 2.8, 2.9…)

En somme on pourrait résumer la pensée de Colebourne par « trop de flexibilité tue la flexibilité ». Il va de soi que ses opinions agacent bon nombre d’adeptes de Scala et n’ont pas manqué de déclencher de nombreux commentaires enflammés sur son billet, au milieu, il est vrai, de quelques réponses plus posées (et plus ou moins convaincantes). D’autres enfin ont préféré répondre point par point sous forme de billet.

Retour sur l’atelier Apache Mahout des Duchess France

La semaine dernière s’est tenu un atelier Apache Mahout organisé par les Duchess France et présenté par Michaël Figuière (Xebia) et Jean-Baptiste Lemée (Lateral Thoughts). Le but de cet évènement était de mettre en valeur les fonctionnalités qui peuvent être développées grâce à Mahout et qui sont encore très peu répandues dans les applications d’entreprise.

Apache Mahout est un framework d’apprentissage artificiel (_machine learning_). Il permet, entre autres, de réaliser des moteurs de recommandations, de la classification automatique de documents, ou encore du regroupement d’entités (_clustering_). Ce type d’algorithmique était principalement réservé au monde de la recherche il y a encore une décennie, avant de se répandre parmi les sites Web les plus populaires durant les années 2000, bien que restant une affaire de spécialistes. L’émergence de Mahout, projet initié en 2009, permet enfin la banalisation de ces fonctionnalités tant appréciées par les utilisateurs, grâce à son API Java simple. En cela Mahout devient à l’apprentissage artificiel ce que Lucene est devenu aux moteurs de recherche.

L’atelier Mahout a démarré avec une présentation générale et rapide du framework, suivie par un exercice pratique avec la mise en oeuvre de Mahout pour créer un moteur de recherche de recettes de cuisines, en seulement quelques lignes de code…

Si vous avez manqué cet évènement, vous pouvez retrouver les slides de la présentation ici.

La prochaine session du Paris Scala User Group aura lieu mardi 22 novembre 2011 à 19h30 dans les locaux de Xebia.

Lors de cette nouvelle soirée du PSUG, Jonathan Winandy et moi-même aurons le plaisir de vous présenter l’outil Simple Build Tool. Cet outil de build permettant de construire vos applications Scala et Java, se veut un remplaçant avantageux de Ant ou autres Maven pour tout développeur ayant quelques bases en Scala.

Il reste encore quelques places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Chaque article étudiera un ou plusieurs design patterns, rappellera la définition de chacun, et montrera les différences d’implémentation entre Scala et Java.

Je couvrirai dans cette série d’articles les 23 design patterns cités par le GOF et quelques autres design patterns propres à Scala et/ou provenant du monde de la programmation fonctionnelle.

Définition

Le design pattern singleton « garantit qu’une classe n’a qu’une seule instance et fournit un point d’accès de type global à cette classe » d’après le GoF.  Il permet d’avoir une seule instance d’une classe dans un espace et un temps donné. Il faut noter ici la différence entre le singleton dit « JVM » et les singletons que j’appelle de « plateforme », tels que les singletons Java EE, Spring ou autre. Lorsque nous parlons d’un singleton JVM, nous spécifions que la classe est chargée une seule fois dans la JVM. Le singleton Spring quant à lui implique juste l’existence d’une instance unique au sein d’un contexte Spring. Un singleton Java EE est unique dans le conteneur.

Cas d’utilisation

C’est le pattern le plus utilisé, souvent à tort par les développeurs juniors comme seniors. Aujourd’hui, on en voit très souvent dans le code. Tout est devenu prétexte pour introduire un singleton : les classes utilitaires (helper), les classes de services, etc.

Pourtant les cas d’utilisation du Singleton sont peu nombreux et doivent le rester. Parmi les cas d’utilisation, on peut citer :

• le gestionnaire d’affichage (DisplayManager),
• le gestionnaire de pilotes de base de données (DriverManager),
• le runtime,
• etc.

Bref une règle simple peut vous aider à prendre votre décision : un singleton est souvent lié à une ressource unique. Le développeur doit se demander si une classe qui n’a que des membres statiques (attributs et méthodes) et un constructeur privé n’est pas suffisante (ce qui est généralement le cas). 

Implémentation

Java

Plusieurs solutions existent en Java. Les principales différences entre les implémentations tournent autour de la simplicité d’écriture, l’aspect thread safety dans un environnement multi-threadé et l’initialisation tardive.

Vous trouverez ci-dessous trois de ces solutions :

La solution triviale

Elle consiste à créer une classe finale munie d’un constructeur privé, une instance statique, finale et privée et une méthode statique publique retournant une référence à l’instance statique.

public final class Singleton {
 private static Singleton instance = new Singleton();
 // accès global
 public static Singleton getInstance() {
  return instance;
 }
 // constructeur privé. Obligatoire pour empêcher l'instantiation ailleurs .
 private Singleton() {
 }
 // méthodes et attributs
}

Cette solution est simple à écrire et à comprendre. Elle ne présente aucun problème de synchronisation, puisque le chargement des classes est thread safe. Le seul souci qu’elle présente est que l’instance statique est initialisée au chargement de la classe ce qui rend le chargement coûteux. En effet, elle n’implémente pas l’initialisation tardive.

La solution enum

De plus en plus de développeurs préfèrent une implémentation à base d’enum à l’implémentation précédente.

public enum Singleton {
 ONE;
 // méthodes et attributs
}

Cette solution est encore plus simple que la précédente. Elle présente les mêmes avantages et inconvénients en plus du fait quelle n’est compatible qu’avec Java 5 et plus (et oui il y a encore des gens qui développent avec Java 1.3 et 1.4 !).

La solution avec inner class

C’est une adaptation de la première solution qui ajoute une classe privée chargée d’instancier le singleton.

public final class Singleton {
 private static class SingletonLoader {
  private static Singleton instance = new Singleton();
 }
 // accès global
 public static Singleton getInstance() {
  return SingletonLoader.instance;
 }
 // constructeur privé. Obligatoire pour empêcher l'instantiation ailleurs .
 private Singleton() {
 }
 // méthodes et attributs
}

Cette solution reste simple, thread-safe, implémente le chargement tardif et elle fonctionne sur toutes les versions des JVM. C’est ma préférée entre les solutions présentées.  

Scala

Les singletons dans Scala sont appellés Singleton Objects. Le but premier des Singleton Objects est de remplacer les membres statiques (attributs et méthodes). En effet, dans Scala, il n’y a pas de mot-clé static, il n’y a ni attribut de classe ni méthode de classe. Pour en avoir, il faut créer un Singleton Object. Voici comment :

object Singleton{
 // méthodes et attributs
}
// Voici comment l'utiliser depuis une autre classe, un autre object ou dans un script
val singleton = Singleton

 Scala compile un object en deux classes :

• Singleton : une classe finale qui ne contient que des méthodes statiques. Les méthodes statiques enveloppent l’appel à la vraie implémentation contenue dans l’autre classe générée.
• Singleton$ : une classe finale avec un constructeur privé et une instance statique d’elle même.

Avec le code décompilé (avec JD-GUI) ci dessous on en déduit que l’implémentation scala se rapproche beaucoup de la solution Java avec inner class.

public final class Singleton$  implements ScalaObject {
 public static final  MODULE$;
 static{
    new();
 }
 private Singleton$(){
    MODULE$ = this;
 }
}
public final class Singleton
{
}

Comme la dernière implémentation du pattern en Java, cette solution est thread safe et implémente l’initialization paresseuse.

Au-delà des détails de l’implémentation du singleton, il est important de rappeler que Scala distingue deux types de Singleton Object :

• Le Companion Object : un Companion Object est défini dans le même fichier qu’une classe portant le même nom. La classe et son objet compagnon peuvent accéder mutuellement à leurs membres même privés.
• Le Standalone Object : le Standalone Object est un objet défini seul.

Dans les deux cas, les singletons en Scala sont des « citoyens de première classe », pour les anglophones « first-class citizens ». Ce qui veut dire que ces entités peuvent :

• Hériter (en Scala on dit plutôt mixer) de traits ou de classes. Mais ils ne peuvent pas être hérités !
• Redéfinir (overwrite) les membres hérités.
• Être utilisés comme n’importe quel autre type.

Conclusion

Entre thread-safety et initialization paresseuse, l’implémentation du pattern Singleton n’est pas la plus intuitive en Java. Malgré cela, le pattern est l’un des plus utilisés. Scala l’intègre nativement en assurant la thread safety et l’initialization paresseuse. Ceci rend son utilisation encore plus facile. Cette simplicité d’implémentation ne doit pas inciter les développeurs à l’utiliser à tort n’importe où dans leur code.

La prochaine session du Paris Scala User Group aura lieu mardi 25 Octobre à 19h30 dans les locaux de Xebia.

A cette occasion, Jean Helou nous proposera la résolution d’un mastermind sous forme d’un kata TDD. Le but est de partir d’une version impérative du programme et la refactorer en utilisant les principes de la programmation fonctionnelle.

Il reste encore quelques places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Cette 15ème soirée du PSUG donnera lieu à un match au sommet entre Python, représenté par Sébastien Douche et Scala qui sera défendu par Alexandre Bertails. Nous espérons que le débat soit animé donc n’hésitez pas à venir défendre vos couleurs !

Il reste encore quelques places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Le thème de cette 14ème soirée PSUG sera Akka qui nous sera présenté sous forme de kata par Alexis Agahi, notre Gentil Organisateur du PSUG.

Akka est un framework écrit en scala et inspiré d’Erlang OTP, permettant d’écrire des applications concurrentes, scalables et tolérantes aux pannes grâce aux Acteurs.

Il reste encore quelques places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Pour cette 13ème session, le PSUG aura le plaisir d’accueillir Guillaume Bort, le créateur de playframework, qui nous fera une démonstration de son utilisation avec le langage Scala. N’hésitez donc pas à nous rejoindre si vous souhaitez en savoir plus sur ce très populaire framework.

Alexis Agahi, le maître de cérémonie du PSUG nous fera aussi un rapide retour sur la participation de quelques membres du User Group au challenge USI 2011.

Il reste encore quelques places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Premier Jour 

Tout commence par un petit mot d’accueil de Carl Azoury qui nous parle de l’investissement de Zenika dans l’organisation de l’évènement. Cinq mois de préparation, pour un budget total de 150k euros avec 35k d’entrée et 45k de financement par les sponsors. Bref, Zenika n’a pas ménagé ses efforts pour réussir cette grande première.

C’est ensuite au tour d’Adrian Colyer de venir nous parler des orientations prises par SpringSource. Voici les points marquants :

• SpringSocial permet de s’interfacer avec les SaaS des différents réseaux sociaux.
• SpringMobile facilite le développement d’applications Android et de sites web destinés aux WebPhones.
• SpringData vient faciliter l’utilisation de NoSQL sous toutes ses formes avec des annotations assurant le mapping des beans Java.
• CloudFoundry — le sujet principal de cette KeyNote — fournit un PaaS open source facile à utiliser permettant de faire du cloud publique, privé ou micro en local sur la machine du développeur.

Boris Bokowski prend la suite pour nous faire une démonstration autour d’Eclipse Orion, un IDE en ligne développé en HTML5. Il s’agit en réalité d’un IDE pour le développement web qui intègre quelques fonctionnalités basiques comme la coloration syntaxique, la recherche, l’auto-complétion des mots clés, l’intégration des SCM comme Git et la possibilité de publier son travail via FTP ou SFTP. L’outil possède un système de plugin que nous n’avons pas pu découvrir pour cause d’effet démo. Boris y voit la possibilité d’intégrer une multitude de petits outils en ligne en définissant un réel standard. Pour ce qui est de l’éditeur en lui-même, il faut reconnaître que les performances sont impressionnantes: le navigateur ne ralentit pas même en éditant de très gros fichiers (15k lignes et plus). Au final, Orion ressemble davantage à un éditeur texte avancé du même type que notepad++ mais pas à un réel IDE. L’idée est intéressante mais il y a encore beaucoup de travail à réaliser pour en faire un outil capable de supplanter nos IDE lourds.

Après une pause déjeuner régime (un sandwich) un peu courte, Howard LewisShip vient nous présenter Clojure. Clojure est un dialecte de Lisp (famille de langages fonctionnels) tournant sur la JVM. La syntaxe est sensée être plus légère que Java qui multiplie les accolades et autres crochets. Attention, le langage est presque purement fonctionnel et ne joue pas la mixité avec le paradigme objet. La présentation est parfaitement maîtrisée et Howard s’avère être un très bon speaker, malheureusement le langage apparait d’une complexité impressionnante avec une syntaxe très difficile d’accès pour les Javaistes que nous sommes. Comme souvent pour ce type de langage, Clojure se distingue dans la manipulation des collections. La grande majorité de l’auditoire est apparue quelque peu perdue dans la syntaxe, peut-être était-ce dû à l’effet digestion.

C’est ensuite au tour de Jevgeni Kabanov de prendre la parole dans une présentation pleine de vie sur la gestion de la mémoire dans la JVM. Tout commence par le CPU qui embarque sa propre gestion de la mémoire dans ses caches, puis Jevgeni nous parle de la mémoire paginée de l’OS pour finir par s’intéresser à la JVM proprement dite. Par exemple, l’utilisation du mot clé volatile empêche la mise en cache CPU de la donnée, tandis que le mot clé synchronized crée des points de synchronisation dans les registres du CPU. Jevgeni enchaîne avec le fonctionnement des différents garbage collectors et le problème des pauses GC qui bloquent la JVM. Il met en avant le ConcurrentMarkSweep qui permet d’obtenir des temps de pause courts mais au prix d’une forte fragmentation de la mémoire alors que le G First permet d’obtenir des temps de réponse courts sans fragmentation.  La conclusion vient enfin avec une courte introduction du travail réalisé par Azul sur la plateforme Zing qui permet de faire tourner des JVM sans pause GC. Une présentation très intéressante par un speaker de grande qualité.

Jags Ramnarayan vient nous présenter SQLFire, qui n’est ni plus ni moins qu’un moteur SQL pour Gemfire. La solution permet de travailler en SQL sur la grille de mémoire. Parmi les points intéressants, on pourra noter que cela permet de travailler directement en JDBC sans avoir à utiliser une nouvelle API spécifique à la mode des NoSQL standards. La solution propose des transactions distribuées sans réaliser de verrouillage globale. SQLFire utilise quelques modifications du DDL pour gérer la distribution des données comme la réplication, et la co-localisation pour les données liées. Bref une solution intéressante qui peut avoir l’avantage de réduire le temps de prise en main des NoSQL pour ceux qui sont prêts à en payer la licence.

Le dernier slot est présenté par Brad Drysdale qui vient nous présenter les WebSockets d’HTML5. Cette nouvelle technologie portée par le W3C permet de réaliser des communications Full Duplex entre le serveur et le navigateur. Le gros avantage de cette solution par rapport aux autres techniques comme le polling et le long-polling, est de ne pas reposer sur le protocole HTTP qui est par essence très verbeux. Brad nous indique que cela permet de réduire drastiquement la consommation de bande passante pour les échanges client-serveur. La présentation est très didactique et sans démonstration, le but n’est pas de mettre en avant les solutions de Kaazing mais bel et bien la technologie en elle même. Brad est très convaincant, et la grande majorité de la salle semble vouloir se mettre aux WebSockets.

La journée se termine par une soirée organisée par Atlassian avec boisson et gâteaux apéritif, l’occasion idéale pour discuter de cette première entre auditeurs ou avec les speakers qui sont tous présents et disponibles.

Deuxième jour

Neal Gafter ouvre le bal de cette deuxième journée par une présentation retraçant l’histoire de Java et son avenir « proche ». Nous ne décrirons pas ici la chronologie complète de Java. Depuis la première release en 95, la technologie connaît un succès croissant jusque dans le début des années 2000 ou le nombre de participants à la JavaOne commence à fluctuer à la baisse. Les évolutions du langage sont très importante jusqu’en 2004 à la sortie de la J2SE 5.0.
Là, Neal en profite pour nous parler de Java Puzzler publié en 2005 et nous donne 2 exemples tirés du livre ; l’assemblée se prête volontier à cet exercice amusant. Puis viens 2006 avec la publication de Java 6, de JEE 5 et la distribution de la JVM HotSpot sous GPLv2. Les nouvelles versions se sont enchainées tous les deux ans, mais en 2007 alors que SUN travaille à l’OpenJDK sous licence GPL, Apache annonce Harmony, son implémentation de Java sous licence ASF. La discorde commence entre SUN et Apache au sujet de la licence du TCK qui n’est pas compatible avec la licence d’Harmony, interdisant du même coup la validation du projet Harmony comme compatible Java 5. Oracle demande d’ailleurs courant 2007 à SUN de supprimer les limitations de la fameuse licence pour permettre la validation d’Harmony. A noter tout de même qu’en 2002 SUN avait annoncé être prêt à ouvrir la licence du TCK. En 2009, JEE 6 est finalement approuvé malgré de nombreuses discordes. Pour en finir en 2010, année du rachat de SUN par Oracle, qui fait bouger les choses, en forçant le JCP à approuver les futures version 7 et 8 de la J2SE. IBM le contributeur principal va aussi abandonner Harmony au profit de l’OpenJDK. Apache claque la porte du JCP, Oracle lance un procès contre Google au sujet de Dalvik la VM d’android qui repose en partie sur Harmony et confirme que la licence du TCK ne changera pas. Voilà pour la chronologie, Neal passe ensuite naturellement aux évolutions embarquées dans Java 7 et 8 avec des exemples de code source à l’appui, petit rappel utile de ce qui nous attend pour 2011 et 2012. Il conclut que le progrès et l’innovation fonctionnent mieux quand il y a quelqu’un pour tenir la barre.

Il passe enfin la parole à un collègue qui nous présente rapidement Windows Azure - le cloud par Microsoft – qui supporte beaucoup de plateformes de développement. L’offre permet de déployer ses applications sans se soucier de la scalabilité ou des VM qui font tourner le service. La solution rappelle fortement CloudFoundry, mais c’est encore un système propriétaire. Parmi les service embarqués on retient la mise à disposition d’une base SQL. Il y a un plugin eclipse Azure4J, la base est disponible en SQL par JDBC, elle serait d’ailleurs compatible avec JPA (étonnant pour une base distribuée). La solution a l’air intéressant et il est agréable de constater les efforts fournis par Microsoft pour les développements Java. Pour plus d’information consultez le site Waz4j. 

C’est ensuite Rob Harrop qui prend la parole et nous présente RabbitMQ ce bus de message multi-protocole basé sur AMQP. RabbitMQ supporte la plupart des langages Java, Python, Ruby, NodeJs et j’en passe. Il développe sous nos yeux un petit système envoyant le cours des actions de plusieurs groupes, il développe ensuite des consommateurs en Python en Ruby et va jusqu’à se connecter en Telnet sur son instance RabbitMQ pour recevoir les messages. Le système permet de convertir les messages vers STOMP, XMPP et HTTP en transmettant toujours le même contenu. Rob Harrop développe un serveur web NodeJs qui reçoit les messages du bus et les transmet dans une WebSocket. Après quelques passages d’un terminal à l’autre, Rob affiche la page dans son navigateur et les chiffres défilent instantanément à l’écran. La démonstration est vraiment convaincante et l’assemblée l’accueille avec enthousiasme. 

Après un déjeuné frugal, nous accueillons Theo Schlossnagle qui vient nous parler d’architecture. Il commence par prendre le contre-pied de la mode cloud et NoSQL en avançant que nous avons déjà bien assez de puissance de calcul chez nos clients et qu’il faut commencer par faire fonctionner nos systèmes avec les ressources dont nous disposons. Les systèmes distribués n’empêchent pas les défauts d’une architecture. Dans la majorité des cas, il faut repenser les systèmes. Le conseil majeur de Theo est d’éviter la complexité, les systèmes simples sont bien plus faciles à développer, tester et déployer. Il faut donc découpler les services afin de les maintenir simples et isolés.  Là, il nous met en garde, car cela nécessite l’utilisation de bus de messages, ce qui s’avère complexe. Voici quelques uns de ces conseils avisés :

• Utilisez des traitements asynchrones.
• Simulez l’ensemble du système en développement pour le faire tomber au plus tôt, car une architecture finit toujours par casser.
• Mettez en place du code défensif (timeouts, heartbeat, …)
• Assurez la supervision complète du système (Temps de réponses, Nombre de clients, Taille des files d’attente, …)

Pour tout dire une présentation riche et instructive.

Michaël Chaize, prend la suite pour nous présenter la plateforme Flex, dont nous avons déjà parlé sur le blog. Il nous présente d’abord quelques applications réalisées par Adobe, avec des interfaces tres graphiques et interactives.  Une petite pique au HTML5, puis il passe à une démonstration mobile en développant une application listant les Tweets #wsnparis. Michaël utilise FlexBuilder pour son développement, rapidement il lance l’application dans un simulateur Android. Il nous liste les plateformes supportées (Android, BlackBerry, ios). Un auditeur le rejoint sur la scène et nous présente une application développée par ses soins, déployée sur deux téléphones et une tablette. L’interface s’adapte bien à chaque taille d’écran et chaque définition. Les démonstrations ont l’air fluide sur les mobiles et Michaël insiste sur les efforts fournis pour optimiser les performances de la machine virtuelle. La présentation est convaincante et l’argument de la portabilité mobile pèse dans la balance, comme nous l’avions vu lors du XKE d’avril.

Jonas Bonér vient ensuite nous parler d’AKKA le framework développement orienté acteur.  Il nous présente d’abord ce que sont les acteurs à savoir des unités de traitements isolées orientées messages. Chaque acteur possède un état, une mémoire propre et s’exécute dans un Thread réservé. Akka tente de résoudre trois problèmes essentiels des systèmes informatiques :

• Scalabilté (fonctionnement réparti et distribué).
• Tolérance à la panne
• Concurrence d’exécution

Les acteurs sont asynchrones par essence, mais il est possible d’attendre le résultat du traitement d’un message via l’utilisation d’un Future. Les acteurs distants permettent d’assurer la distribution et la scalabilité. Le mode cluster sera disponible en version 2.0, il repose sur l’utilisation de ZooKeeper et permet de créer des grilles sans connaître la topologie réseau à priori. Jonas nous parle ensuite de la tolérance à la panne en nous expliquant la detection des noeuds cassés, et le système de recouvrement automatique. Sur le slide, le système à l’air réellement fiable, en cas d’erreur les noeuds sont d’abord tués puis redémarrés.  La présentation donne vraiment envie de tester cette technologie émergente issue de Scala et qui d’ailleurs fait parti de la stack TypeSafe. 

Shay Banon prend maintenant la parole pour nous présenter ElasticSearch une solution d’indexation et de recherche construite au dessus de Lucene avec la particularité de fonctionner en cluster avec la distribution des index et leur réplication sur un ou plusieurs noeuds du système. Tout se déroule dans un terminal dans lequel le speaker lance des requêtes en curl sur le serveur qu’il a lancé en local. Petit à petit il nous montre des exemples de plus en plus complexes, en commençant par la création d’un serveur simple puis d’un cluster. Il enchaîne ensuite avec une indexation basique en augmentant la complexité régulièrement. Tous les échanges sont réalisés en Rest Json. La recherche utilise directement la syntaxe Lucene, il est même possible d’utiliser des requêtes pré-définies avec Percolator. La démonstration est intéressante bien que cela manque un peu de vie, je ne suis pas vraiment convaincu par l’outil, la plus-value par rapport à Solr n’est pas évidente.

Pour conclure cette journée de conférences, Kohsuke Kawaguchi se lance dans une présentation sur l’avenir de l’intégration et des outils du développeur en général. Il constate que nous avons de plus en plus de machines de plus en plus puissantes, le développeur est le berger d’un troupeau d’ordinateurs. Il faut donc aider le berger à tirer partie au mieux de toute cette puissance de calcul. Pour choyer le développeur qui est une denrée rare par rapport au datacenter, Kohsuke nous donne quelques pistes: 

• Distribuer les builds
• Augmenter et améliorer le parallélisme (Compilation, Test unitaires, Parallel Junit, TestNG, …)
• Utiliser un SCM distribué

Cette liste n’est pas exhaustive et il faut bien reconnaître que Kohsuke a beaucoup d’idées pleines de bon sens. Il propose même de déporter définitivement la compilation et les tests sur le serveur d’intégration pour éviter au développeur la perte de temps considérable que cela représente. J’avoue avoir encore quelques doutes, mais en exécutant les tests unitaires avant de pousser vos sources sur Git ou Mercurial pourquoi pas.

Conclusion

La conférence est une réussite de mon point de vue d’auditeur, le contenu était dense mais cela nous a assuré deux jours de veille technologique fort sympathiques. L’ambiance était bonne et puisque Zenika l’a annoncée, ce sera un plaisir de venir à la prochaine édition. Voilà pour l’ambiance et l’organisation, mais je ne peux m’arrêter là sans faire le tour des grandes tendances ressenties à la What’s Next. La scalabilité est sur toutes les lèvres, l’idée ne semble pas nouvelle mais il n’est pas possible de parler de cette conférence sans écrire ce mot magique. Il faut aussi noter la presque omniprésence des langages fonctionnels, Scala et NodeJS en tête. Les systèmes sont de plus en plus polyglottes et il faudra compter avec ces nouveaux langages pour les futurs développements. Remarquez aussi, pour ceux qui ne l’avait pas encore en tête, que le standard HTML5 devient de plus en plus incontournable. Enfin, notez que le cloud est lui aussi sur le devant de la scène, les solutions PAAS de SpringSource et Microsoft annoncent à mon sens une démocratisation de ce type d’architecture. C’est aussi une démocratisation assez globale de l’utilisation des NoSQL ou plus exactement des bases de données distribuées. Après ces deux derniers points, je reprendrai les conseils de Theo Schlossnagle : avant de penser au cloud, commencez par résoudre les problèmes que vous rencontrez sur vos architectures en pensant aux traitements asynchrones, à la programmation défensive et à la simplicité avant tout.

Cette soirée donnera un petit avant goût de la conférence Scala Days 2011 qui aura lieu outre-atlantique dans la prestigieuse université de Stanford en Californie. Nous accueillerons donc Rémy-Christophe Schermesser qui nous déroulera en avant première le sujet qu’il présentera aux Scala Days : « Scala from a Rubyist point of view ».

Il reste encore des places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A — 7e étage

La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Création de TypeSafe et sorties conjointes de Scala 2.9 et Akka 1.1
• Sortie de Spring Roo 1.1.4

Le coin de la technique

• Sortie de IntelliJ IDEA 10.5 et baisse des tarifs

Actualité éditeurs / SSII

Création de TypeSafe et sorties conjointes de Scala 2.9 et Akka 1.1

Jeudi dernier, Martin Odersky a annoncé la création de la société TypeSafe avec d’autres acteurs importants du monde Scala tel que Jonas Bonér (créateur de la librairie Akka) ou encore Mark Harra (créateur de sbt) pour ne citer qu’eux. Notez qu’en regardant la liste des personnes impliquées dans la société TypeSafe, on peut voir que James Gosling et Doug Lea sont cités en tant que conseillers.

La vocation de cette nouvelle société est de promouvoir et de fournir un support commercial aux divers composants proposés :

• le langage Scala qui est un langage orienté objet et fonctionnel,
• le middleware Akka qui fournit les services de base permettant d’obtenir une scalabilité horizontale et verticale ainsi que la tolérance aux pannes de vos applications,
• l’outil Simple Build Tool permettant de construire vos applications,
• le plugin Scala IDE permettant de développer en Scala sous Eclipse.

Le langage Scala gagnant progressivement en popularité, notamment dans le monde bancaire et financier, il devenait nécessaire d’apporter un support commercial au travers d’une société regroupant les personnes et les moyens nécessaires (3M$ levés à l’occasion). Le langage Scala est par ailleurs toujours développé dans le cadre du laboratoire LAMP de l’EPFL qui à reçu récemment un financement de l’Union Européenne pour le développement de technologies liées à la scalabilité.

L’annonce de la création de TypeSafe à été accompagnée par deux autre annonces de tailles :

• la sortie de la version finale de Scala 2.9,
• et la sortie de la version 1.1 du framework Akka.

Vous pourrez trouver plus de détails sur les nouveautés de Scala 2.9 dans cette entrée consécutive à la sortie de la première Release Candidate. La principale nouveauté de cette version reste tout de même le support des Parrallel Collections permettant le traitement en parallèle des opérations sur les collections.

L’autre annonce concerne le projet Akka. Akka est un middleware permettant la mise en place d’architectures scalables, Event Driven et tolérante aux pannes, largement inspiré du monde des télécoms (notamment Erlang OTP). Les fonctionnalités offertes par Akka sont :

• support des Acteurs (dans un modèle un peu différent de celui fournit dans la librairie standard de Scala),
• la tolérance aux pannes et la haute disponibilité (utilisant le modèle « Let it crash / Embrace failure »),
• le modèle de Software Transaction Memory permettant la définition d’opérations transactionnelles sur des objets en mémoire,
• les Transactors appliquant le STM au modèle des Acteurs,
• les acteurs distribués (scalabilité verticale),
• la concurrence à l’aide d’Agents et de DataFlow,
• une API disponible en Scala ainsi qu’en Java (le middleware Akka est écrit en Scala).

La version 1.1 de Akka apporte notamment le support de la version 2.9 de Scala, une réduction des dépendances externes, l’amélioration des APIs et de nombreuses corrections de bugs et amélioration de performances.

Avec cette annonce, on peut espérer que le langage Scala gagne un peu plus de terrain dans le monde de l’entreprise.

Sortie de Spring Roo 1.1.4

Spring Roo vient juste de mettre à disposition sa version 1.1.4 disponible ici. Pour rappel, Spring Roo est un IDE texte pour le développement rapide d’applications Java. A la manière d’un Grails, vous pouvez générer une application complète en quelques minutes.

Cette version apporte de nombreuses corrections de bogues et améliorations dont les principales sont :

• Support de Google App Engine 1.4.3 et du plugin maven-gae-plugin en version 0.8.4
• Montée de version Hibernate, Spring Roo passe de la version 3.6.1.Final à la version 3.6.3.Final
• Montée de version du driver SolrJ en version 1.4.1

La prochaine version prévue portera le numéro 1.2.0 et apportera de nouvelles fonctionnalités (Support de JSF 2.0, amélioration DBRE, …).

Le coin de la technique

Sortie de IntelliJ IDEA 10.5 et baisse des tarifs

Jetbrains vient juste d’annoncer la sortie d’une nouvelle version de son produit phare Intellij IDEA.

Cette nouvelle version apporte un certain nombre de nouveauté dont :

• le support complet de Java 7 qui doit sortir cet été,
• un nouveau système de complétion (avec notamment un mode de complétion type camel-case sans utiliser de majuscules),
• le support de tout nouveau Groovy 1.8,
• le support amélioré de Spring et de Spring Integration ainsi que la prise en compte du futur Spring 3.1 ,
• le debug du code javascript dans Chrome,
• l’intégration du serveur Jetty,
• support de XSLT2,
• tout un tas d’amélioration dans le support de différents langages et framework : Grails, Flex, Javascript, Android …
• et les inévitables corrections de bugs et amélioration de performances.

A noter que le développement du plugin Scala (sujet d’actualité dans cette revue de presse) suit son petit bonhomme de chemin et apporte un confort de plus en plus grand aux utilisateurs de ce superbe langage.

Autre nouveauté qui coïncide avec cette nouvelle version : le prix ! Comme vous pouvez le constater, l’acquisition d’une nouvelle licence ou la mise à jours de la version « Ultimate » bénéficie de tarifs sensiblement moins élevés. Notez bien, en revanche, que pour les détenteurs d’une licence de la version 10, le passage en version 10.5 se fait gratuitement. Pour tous, la version « Community », open source mais aux fonctionnalités plus limitées, reste gratuite.

Pour faire le tour des IDE principaux, rappelons que Netbeans 7 est lui sorti courant avril, avec aussi le support de Java 7 en plus de nombreuses améliorations. Et pour finir, ce sera le 22 juin que sortira Eclipse 3.7, de son petit nom « Indigo ». Nous découvrirons alors si le plugin m2Eclipse a finalement été intégré à la distribution Eclipse (il n’est toujours pas dans les dernières version Milestone) et si le support de Git est désormais bien fourni de base. En tout cas, cette version supportera elle aussi la majorité des nouveautés de Java 7.

• Ses origines
• Les outils et frameworks de son écosystème
• Les difficultés et freins à son adoption
• Les nouveautés de la toute nouvelle version 2.9.0
• Les entreprises qui l’utilisent
• Une session d’une heure de live coding : exemples de programmation fonctionnelle, un S-99 et… du Play Framework !

Les inscriptions se passent par ici. Venez nombreux !

Cette soirée sera animée par Miles Sabin, un important promoteur du langage Scala. Miles nous expliquera comment Scala peut nous aider à simplifier notre code et à nous débarrasser de ce qui est inutile ou répétitif avec sa présentation « Scrap your boilerplate with Scala ».

Il reste encore des places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Actualité éditeurs / SSII

• IBM dévoile WebSphere 8
• Sortie de Play! Framework 1.2
• Nudge, une plate-forme hébergée de monitoring de performance applicative (SaaS)
• Sortie de Rails 3.0.6 corrigeant une faille de sécurité de type XSS

Le coin de la technique

• Red Hat prépare Ceylon, un nouveau langage pour la JVM

Evénements de notre communauté en France et à l’étranger

• Scrum Day 2011: comme si vous y étiez!

Actualité éditeurs / SSII

IBM dévoile WebSphere 8

Nos confrères du Monde Informatique et du Journal du Net reviennent sur la conférence Impact 2011, qui se tenait à Las Vegas les 12 et 13 avril derniers, au cours de laquelle IBM a notamment présenté les grandes lignes de la version 8 de son célèbre serveur d’applications.

Disponible en version bêta depuis le mois de mars — la sortie officielle étant prévue pour juin — cette dernière version est 100% compatible avec Java EE 6. Parmi la longue liste de fonctionnalités au programme de cette nouvelle mouture, citons le support des standards suivants :

• Enterprise JavaBeans (EJB) 3.1
• Java Persistence API (JPA) 2.0
• JavaServer Faces (JSF) 2.0
• JavaServer Pages (JSP) 2.2
• Servlet 3.0
• JAXB 2.2
• JAX-WS 2.2, et notamment le support de Web Services Security API (WSS API) et WS-Trust, censés faciliter le SSO à l’aide de web services.

WebSphere 8 devrait apporter également:

• une meilleure prise en charge des applications OSGi;
• une meilleure intégration des web services utilisant WS-Security SAML Token Profile 1.1;
• un support de SIP Servlet 1.1 afin de favoriser l’utilisation d’applications de communication;
• le support du cache L2 de JPA à l’aide de DynaCache (le cache par défaut utilisé dans WebSphere);
• une intégration simplifiée avec WebSphere MQ.

IBM semble également avoir voulu contenter les développeurs d’applications (il était temps, diront certains): non seulement le serveur semble démarrer plus rapidement, mais surtout le processus de déploiement a été simplifié, et il sera désormais possible de (re)déployer une application avec un simple drag’n drop.

Sortie de Play! Framework 1.2

La version 1.2 du framework Play! vient tout juste de voir le jour. Pour ceux qui ne le connaitraient pas encore, Play est un framework web orienté haute productivité. Comme son cousin Grails, il repose sur des conventions, est extensible via des plugins et supporte le rechargement à chaud des modifications du code.

Les nouveautés apportées par cette nouvelle version sont nombreuses :

• ajout d’un système de gestion de dépendances basé sur Ivy, permettant de récupérer des modules Play ou toutes autres librairies requises,
• support du Long Polling et des Web Sockets, pour les connections asynchrones,
• introduction d’un mécanisme de gestion des évolutions des schémas de bases de données,
• ajout du concept d’Invocation permettant la mise en place de mécanismes équivalent aux Servlet Filters ou à l’AOP (pour la déclaration des transactions à l’arrivée d’une requête par exemple),
• support des bases H2, maintenant embarquées par défaut,
• possibilité de lancer les tests JUnit directement dans Eclipse (sans passer par la page de tests),
• une meilleure documentation du framework, avec notamment une Cheat-Sheet, toujours accessible en mode déconnecté.

Cette version 1.2 est accompagnée de la version 0.9 du plugin Scala pour Play. Ce plugin permet l’utilisation du langage Scala pour développer vos applications Web avec le framework Play. Outre une meilleure intégration de Scala dans le framework Play, cette nouvelle version du plugin apporte une nouvelle couche d’accès aux bases de données nommée Anorm. Anorm permet l’accès en SQL à vos données et utilise des fonctionnalités du langage Scala (le Combinator Parsing) pour mapper le résultat des requêtes avec vos objets. D’importantes évolutions sont encore attendues dans la prochaine version de ce plugin, qui devrait encore améliorer son intégration et sa documentation.

Cette nouvelle version apporte donc d’importantes améliorations et confirme la simplicité qui est au coeur de la philosophie de Play.

Nudge, une plate-forme hébergée de monitoring de performance applicative (SaaS)

La société Level5 Consulting vient de sortir Nudge, une offre hébergée de monitoring d’applications en production. Les cibles sont des logiciels de type web ou batch développés en Java/JEE.

Utilisateurs, vous aurez à disposition des fonctionnalités permettant de :

• collecter et agréger des temps de réponse,
• identifier les requêtes SQL consommatrices,
• suivre la consommation mémoire et CPU,
• agréger des données par module et/ou processus métier,
• créer de métriques personnalisées par API,
• gérer des alertes et des SLA,
• collecter des informations sur les incidents de production.

Vous bénéficierez aussi d’un support d’expert sur l’optimisation d’application. Vous pouvez dès maintenant découvrir Nudge gratuitement ou bien tester une application de démonstration disponible sur le site de l’éditeur. Pour plus de détails, consultez l’article de Developpez.com sur le sujet.

Sortie de Rails 3.0.6 corrigeant une faille de sécurité de type XSS

C’est le 6 avril que la dernière version (3.0.6) de l’outils Rails est sortie. C’est une version importante puisqu’elle corrige, entre autre, une faille de sécurité. En effet, une vulnérabilité de type XSS (Cross Site Scripting) peut être exploitée si la méthode auto_link est utilisée dans les sources. Cette dernière en effet avait la fâcheuse habitude de marquer automatiquement ses paramètres comme étant html safe, et ce, quelle que soit leur origine: ceux-ci n’étaient donc en vérité jamais contrôlés. Il était donc possible d’exécuter du code javascript malveillant en l’injectant dans un paramètre de type string. Le billet mentionne trois solutions pour palier ce problème: mettre à jour votre version de Rails, installer un patch ou… ne pas utiliser cette méthode

Cette mise à jour apporte quelques autres ajouts, dont vous pouvez retrouver le détail sur le blog du projet.

Le coin de la technique

Red Hat prépare Ceylon, un nouveau langage pour la JVM

Le « buzz » de la semaine c’est bien sûr la diffusion d’une présentation (et de sa deuxième partie) que Gavin King a faite à Pékin lors de la QCon, où il révèle qu’il travaille pour Red Hat à un nouveau langage pour la JVM : Ceylon. Bien que Gavin ne prévoyait pas de parler officiellement du projet de son équipe aussi tôt, il a confirmé la nouvelle ; d’abord sur son blog, puis lors d’une interview pour InfoQ.

Alors de quoi s’agit-il ? La première chose à noter est que Gavin King se défend de vouloir créer le langage du futur pour la JVM ou un « Java Killer ». Il se dit d’ailleurs « fan apologétique » de Java et propose donc Ceylon comme un langage fortement inspiré de celui-ci, sans les frustrations qu’il occasionne. Les principales frustrations étant selon lui :

• les librairies du SDK, vieilles et mal conçues ;
• la difficulté de définir une interface utilisateur en Java (il blâme d’ailleurs le complément quasi-automatique de Java pour beaucoup de besoins : XML) ;
• le manque d’un vrai système de modules (il dénonce à cet égard la complexité de Maven et d’OSGi, en se prononçant en faveur du framework JBoss Modules) ;
• le manque de fonctions d’ordre supérieur et/ou de première classe ;
• la gestion de la concurrence (il fustige le fait que tout objet Java puisse être un sémaphore et juge qu’un langage ne devrait pas avoir de primitives de synchronisation, ce rôle devant selon lui être assumé par des librairies spécialisées) ;
• ce qu’il appelle les « verrues » du langage : getters/setters, tableaux et types primitifs, la gestion des valeurs null, les checked exceptions, la généricité (surtout des points qu’il juge obscurs comme la notion de type erasure ou les wildcards) et le système de typage d’une manière globale.

En pratique — et en résumé — Ceylon propose les points suivants :

• de garder tout ce qui fonctionne bien dans Java et en a fait le succès : la JVM, la garbage collection, pas de pointeurs, le typage statique, la lisibilité ;
• le tout objet : tout est type et il n’y a pas de types « primitifs » (mais on peut encore utiliser void pour spécifier le non-retour d’une fonction) ;
• la possibilité de faire des mixins, c’est-à-dire d’implémenter des méthodes dans des interfaces (tant qu’il n’y a pas besoin d’initialisation) — fonctionnalité sans doute inspirée du Projet Coin ;
• une généricité à la fois plus simple et plus restrictive : les paramètres-types (type parameters) peuvent, à l’aide des mots-clés in et out, être déclarés covariants ou contravariants, ce qui élimine la nécessité de passer par des wildcards, qui n’existent d’ailleurs pas dans ce langage: si Box prend un paramètre-type T covariant, une variable de type Box<Integer> est alors assignable, sans transtypage explicite, à une variable de type Box<Number>. Cela conduit Gavin King à imaginer deux interfaces List<T>, l’une covariante avec T et prenant en charge les opérations de lecture, l’autre contravariante prenant en charge les opérations d’écriture (qui modifient la liste) ;
• une structure intrinsèquement récursive: « une classe n’est qu’une fonction retournant à l’appelant une fermeture renfermant tous ses membres » (à la manière de ce que fait JavaScript) ;
• des fonctions d’ordre supérieur et de première classe : une fonction peut ainsi être passée en paramètre d’une autre fonction, une fonction peut contenir d’autres fonctions (ceci découle de la structure récursive du langage), une fonction peut être assignée à une variable, etc… — cependant, les fonctions anonymes (fonctions lambda) ne sont pas autorisées;
• classes et interfaces peuvent spécifier par avance l’ensemble des sous-types qu’elles peuvent avoir ;
• pas d’opérateur de transtypage (casting), mais la possibilité d’utiliser une structure switch particulière :

switch(maVariable) case (is UnType) {...} case(is UnAutreType) {...} else {...}

• des contrats plus forts :
  • des valeurs ne sont nullables que si explicitement déclarées comme telles (avec un « ? » derrière le type) et il faut alors obligatoirement les tester avec :

    if (exists maVariable) {...} else {...}

  • les attributs d’une classe ne sont modifiables que si déclarés comme tels avec variable, et il faut alors utiliser l’opérateur := plutôt que = pour leur réaffecter une valeur ;
• des niveaux de visibilité simplifiés : shared (public) ou privé par défaut ;
• des getters/setters implicites pour les variables d’instance ;
• pas d’exceptions vérifiées (checked exceptions) ;
• pas de surcharge (overloading) de méthodes mais en revanche des valeurs par défaut pour les paramètres ;
• pas de surcharge d’opérateur mais des équivalents/méthodes que l’on peut redéfinir pour un type les supportant. Par exemple > est équivalent à .largerThan() qui peut être redéfini par les implémentations de Comparable ;
• une syntaxe alternative où il est obligatoire de nommer les arguments des méthodes, ce qui donne au final un langage descriptif que Gavin envisage comme une solution face à XML pour décrire des interfaces — l’exemple suivant, tiré de la présentation de Gavin King, est en effet assez parlant:

Table squares {
    title = "Squares";
    rows = 10;
    Column {
        heading = "x";
        String content(Natural row) {
            return $row;
        }
    }
    Column {
        heading = "x**2";
        String content(Natural row) {
            return $row**2;
        }
    }
}

Au rayon des choses étranges :

• pas de mot-clé new ;
• un seul constructeur autorisé (définitivement pas d’overloading donc), qui plus est fusionné avec la définition de la classe :

class Counter(Natural initialValue) {
	if (initialValue > 100) {
		throw OutOfRangeException()
	}
	...
}

• le support de la curryfication ;
• la documentation est conçue comme partie intégrante du langage (un peu comme dans Noop).

Que penser de cet énième langage fondé sur la JVM?

On retrouve en effet dans Ceylon beaucoup de fonctionnalités également présentes dans d’autres langages dérivés de Java (Scala, Groovy, Gosu, Fantom, pour ne citer qu’eux). On les retrouve aussi dans la réflexion de Stephen Colebourne pour définir un futur grand langage pour la JVM, qu’il a notamment présentée lors de la réunion du Paris JUG du mois de mars.

On constate donc bien que le but n’est pas de révolutionner le monde Java, et par ailleurs beaucoup de critiques ont déjà fusé sur le fait que Scala propose mieux depuis longtemps ou que ce langage propose tellement peu qu’il pourrait être mort-né.

Cela étant, les idées proposées sont plus que jamais d’actualité, et l’initiative étant portée par Red Hat et Gavin King (Hibernate, JBoss Seam), on peut légitimement espérer qu’elle fasse bien plus d’effet qu’un pétard mouillé.

Quoi qu’il en soit, il y a encore beaucoup de travail sur le projet : bien que le langage soit en étude depuis deux ans, aucun compilateur n’a encore vu le jour.

Evénements de notre communauté en France et à l’étranger

Scrum Day 2011: comme si vous y étiez!

Les webcasts du Scrum Day sont en ligne sur le wiki du FSUG. Revivez l’intégralité de l’événement, comme si vous y étiez! Les présentations du grand amphithéâtre ont été filmées, les autres sont diffusées en commentaires audio accompagnés de slides.

La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• James Gosling rejoint Google !

Le coin de la technique

• Un grand verre de Guice 3.0
• Scala 2.9 est sur les rails

Actualité éditeurs / SSII

James Gosling rejoint Google !

James Gosling, l’emblématique père de Java vient d’annoncer dans un court billet qu’il venait de rejoindre la société Google. Nous nous rappelons qu’il y a tout juste un an, il annonçait son départ de la société Sun, peu après le rachat de Sun par Oracle. James Gosling s’est laissé une année avant de retrouver un nouvel employeur, lui permettant de prendre un break (en travaillant en freelance) et probablement de se libérer d’une clause de non concurrence.

James Gosling rejoint donc Google dans une période où les relations avec Oracle sont particulièrement tendues. Sa présence offrira un atout incontestable face aux poursuites effectuées par Oracle à l’encontre de la JVM Dalvik, et son expertise sera précieuse au développement d’Android.

Nous prêterons bien entendu une oreille attentive aux conséquences qui découleront de cette embauche et nous souhaitons à James bonne chance pour son nouveau poste !

Le coin de la technique

Un grand verre de Guice 3.0

TheServerSide nous apprend la sortie de Guice en version 3.0. Pour mémoire, Guice (prononcé « Juice ») est le framework d’injection de dépendance créé par Crazy Bob Lee de Google. Ce framework est souvent vu comme le concurrent historique de Spring. Et alors que Spring nécessitait d’écrire du XML à foison, Guice permit dès le départ de bénéficier des avantages liés au code Java et à son typage fort. On a d’ailleurs vu fleurir de nombreux articles vantant les mérites de Guice par rapport à Spring. Toujours est-il qu’aujourd’hui, Spring semble être encore le framework choisi par défaut la plupart du temps en entreprise. Sans doute parce qu’il fournit bien plus que de l’injection de dépendances. En même temps, Guice semble plébiscité pour sa légèreté. On le retrouve donc logiquement intégré à nombre des librairies comme le récent Maven 3. On notera d’ailleurs la cohésion de plus en plus grande entre les 2 projets, applaudie par Jason Van Zyl dans un post sur DZone. Guice est donc maintenant compatible Maven pour son propre build.

La grosse nouveauté est l’implémentation de la JSR 330. Avoir des annotations standard Java et pouvoir changer de provider de DI est un rêve qui prend forme ! Remarquons néanmoins que la documentation de Guice indique comme best practice de continuer à utiliser les annotations propriétaires Guice (que l’on différenciera donc à travers les packages des import les déclarant). On pourra aussi citer l’intégration de tierces librairies (Guava, CGLib…) qui a été refactorée pour les masquer à l’utilisateur et éviter qu’il ne les utilise. L’extension pour Struts 2, présente mais non fonctionnelle en Guice 2.0, a été corrigée. Vous trouverez la liste complète des nombreuses nouveautés sur le changelog.

Et pour coller à l’actualité, Techcrunch nous explique ce matin ce que fait Crazy Bob en ce moment: il vient d’être nommé CTO de Square, une startup spécialisée dans les moyens de paiement sur mobile. Au vu des logs svn de Guice, ca ne lui laisse plus trop le temps de s’occuper de son bébé !

Scala 2.9 est sur les rails

La première release candidate de la version 2.9 de Scala vient d’être annoncée.

Cette nouvelle version arrive après une petite année de développement et apporte un certain nombre d’évolutions dont :

• le support des collections parallèles dont nous vous parlions à l’occasion de la venue de Martin Odersky au PSUG. Pour rappel, l’idée des collections parallèles est de tirer parti des architectures multi coeurs pour traiter les éléments d’une collection (filtrage, map, regroupements …)
• l’apparition des blocs try-catch-finally génériques permettant de définir des handlers réutilisables pour traiter vos exceptions (plus de détails ici),
• l’amélioration de la console Scala,
• l’ajout du trait App qui a pour objectif de remplacer Application. Ce nouveau trait permet entre autre de récupérer les arguments passés au lancement de votre application,
• l’extension de l’API collections, avec par exemple les méthodes minBy and maxBy qui sont un raccourci à la composition des fonctions map et min (ou max)
• le support de l’annotation @strictfp utilisé pour le calcul en virgules flottantes.

Outre ces différentes évolutions, cette nouvelle version apporte un grand nombre de corrections de bugs et d’améliorations de performances.

Une description plus exhaustive des nouveautés de cette version est disponible ici.

Et comme une bonne nouvelle n’arrive jamais seule, Miles Sabin nous annonce la sortie de la première bêta du plugin Scala IDE 2.0 pour Eclipse. La grande nouveauté de cette version est qu’elle est en partie développée par Scala Solutions, la société fondée par Martin Odersky.

Cette version 2 du plugin Scala promet une amélioration sensible de la stabilité, des performances et de nouvelles fonctionnalités. Elle apporte notamment une utilisation confortable de la completion, de la vérification de type en temps réel (l’inférence de type c’est génial, mais ça demande beaucoup de travail au compilateur) et de la navigation entre les classes sur de gros projets. Les utilisateurs d’Eclipse pour développer en Scala apprécieront la bonne nouvelle !

Le problème

Le module gère des produits financiers ainsi que des tirages. Un produit financier possède un certain nombre d’attributs (montant plafond, nom de la banque, devise, etc). Un tirage possède également ses propres attributs (montant, devise, etc). La devise correspond par exemple à l’EURO (EUR), le DOLLAR (USD), etc. Enfin un produit financier peut être composé d’aucun ou plusieurs tirages.

Le module est composé d’un service (FinanceService) gérant des produits financiers. Ce service est composé de deux méthodes :

 public List<ProduitFinancier> getProduitsFinanciersParDevise(List<ProduitFinancier> produitsFinanciers, Devise devise) {
   List<ProduitFinancier> listProduitParDevise = new LinkedList<ProduitFinancier>();
   for (ProduitFinancier produitFinancier : produitsFinanciers) {
     if (produitFinancier.getDevise().equals(devise)) {
        listProduitParDevise.add(produitFinancier);
     }
   }
   return listProduitParDevise;
 }

 public Map<Devise, Double> getTotalMontantParDevise(List<ProduitFinancier> produitsFinanciers) {
   Map<Devise, Double> mapMontantParDevise = new HashMap<Devise, Double>();
   for (ProduitFinancier produitFinancier : produitsFinanciers) {
     List<Tirage> listTirages = produitFinancier.getTirages();
     for (Tirage tirage : listTirages) {
       Devise devise = tirage.getDevise();
       Double montantCourant = tirage.getMontant();
       if (!mapMontantParDevise.containsKey(devise)) {
         mapMontantParDevise.put(devise, montantCourant);
       } else {
         Double montantTotal = mapMontantParDevise.get(devise);
         mapMontantParDevise.put(devise, montantCourant + montantTotal);
       }
      }
    }
    return mapMontantParDevise;
 }

La première retourne une liste de produits financiers suivant la devise passée en paramètre.

La seconde retourne une Map totalisant les montants des tirages par devises.

A noter que les traitements dans ces deux méthodes peuvent être effectués à l’aide de librairies comme Google Guava notamment. Étant donné que le principal but de cet article est de montrer la cohabitation des langages Java et Scala, le code a volontairement été laissé dénué de librairies annexes.

Enfin une classe de test FinanceServiceTest, basée sur la librairie Fest, est également présente pour s’assurer du bon comportement du service :

public class FinanceServiceTest {
 private List<ProduitFinancier> produitsFinanciers;
 private FinanceService financeService = new FinanceService();
 private List<ProduitFinancier> genereProduitsFinanciers() {
     List<Tirage> tirages = new LinkedList<Tirage>();
     tirages.add(new Tirage(1, "tirage_1", 25000.0, Devise.EUR));
     tirages.add(new Tirage(2, "tirage_2", 15000.0, Devise.USD));
     tirages.add(new Tirage(3, "tirage_3", 20000.0, Devise.EUR));
     tirages.add(new Tirage(4, "tirage_4", 50000.0, Devise.USD));
     produitsFinanciers = new LinkedList<ProduitFinancier>();
     produitsFinanciers.add(new ProduitFinancier(1, "reference_1", "Xebia", 1000000.0, Devise.EUR, tirages));
     produitsFinanciers.add(new ProduitFinancier(2, "reference_2", "Xebia", 1500000.0, Devise.USD, tirages));
     return produitsFinanciers;
 }
 @Before
 public void init() {
     produitsFinanciers = genereProduitsFinanciers();
 }
 @Test
 public void testGetProduitsFinanciersParDevise() {
     List<ProduitFinancier> produitsParDevise = financeService.getProduitsFinanciersParDevise(produitsFinanciers, Devise.EUR);
     assertThat(produitsParDevise).hasSize(1).onProperty("reference").contains("reference_1");
 }
 @Test
 public void testGetTotalMontantParDevise() throws Exception {
     Map<Devise, Double> totalMontantParDevise = financeService.getTotalMontantParDevise(produitsFinanciers);
     assertThat(totalMontantParDevise).hasSize(2).includes(entry(Devise.EUR, 90000.0), entry(Devise.USD, 130000.0));
 }
}

Première étape : modification de la structure du projet

En premier lieu, configurons le projet afin de pouvoir compiler et exécuter du code Scala. Précisons qu’un archetype Maven existe (scala-archetype-simple). En se basant sur le résultat de la structure de l’archetype Maven, ajoutons les répertoires scala dans les arborescences main et test :

Modifions maintenant notre pom.xml : cela consiste à ajouter les dépendances pour le langage Scala ainsi que pour les tests unitaires qui seront basés sur la librairie ScalaTest :

<dependency>
    <groupId>org.scala-lang</groupId>
    <artifactId>scala-library</artifactId>
    <version>2.8.1</version>
</dependency>
<dependency>
    <groupId>org.scala-tools.testing</groupId>
    <artifactId>specs_2.8.0</artifactId>
    <version>1.6.5</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.scalatest</groupId>
    <artifactId>scalatest</artifactId>
    <version>1.2</version>
    <scope>test</scope>
</dependency>

Et dans la section build de Maven, ajoutons le plugin permettant de compiler et exécuter le code Java et Scala :

<pluginManagement>
   <plugins>
      <plugin>
         <groupId>org.scala-tools</groupId>
         <artifactId>maven-scala-plugin</artifactId>
         <version>2.9.1</version>
      </plugin>
   </plugins>
</pluginManagement>
<plugin>
  <groupId>org.scala-tools</groupId>
  <artifactId>maven-scala-plugin</artifactId>
  <version>2.15.0</version>
  <executions>
    <execution>
      <id>scala-compile-first</id>
      <phase>process-resources</phase>
      <goals>
        <goal>add-source</goal>
        <goal>compile</goal>
      </goals>
    </execution>
    <execution>
      <id>scala-test-compile</id>
      <phase>process-test-resources</phase>
      <goals>
        <goal>testCompile</goal>
      </goals>
     </execution>
   </executions>
</plugin>

Et voilà, le projet est prêt à compiler et exécuter du code Java et Scala. Passons maintenant à la deuxième étape.

Avant d’aller plus loin, précisons que dans un souci didactique les classes Scala seront créées séparément des classes Java.

Deuxième étape : migration des tests

Cette seconde partie va consister à migrer la classe FinanceServiceTest en Scala. Le but est de tester le service Java en Scala. Pour cela, il suffit d’ajouter la classe FinanceServiceJavaTest dans le package test/scala. Cette classe hérite de la classe ShouldMatchersForJUnit qui permet, à l’aide de DSL, de mettre en place des assertions sous la forme should have, should contain, etc. Ainsi les tests de la classe FinanceServiceTest deviennent :

@Test
class FinanceServiceJavaTest extends ShouldMatchersForJUnit {
  var produitsFinanciers = new LinkedList[ProduitFinancier]();
  var financeService = new FinanceService();
  @Before
  def init() {
    genereProduitsFinanciers();
  }
  def genereProduitsFinanciers() {
    var tirages = new LinkedList[Tirage]();
    tirages.add(new Tirage(1, "tirage_1", 25000.0, Devise.EUR));
    tirages.add(new Tirage(2, "tirage_2", 15000.0, Devise.USD));
    tirages.add(new Tirage(3, "tirage_3", 20000.0, Devise.EUR));
    tirages.add(new Tirage(4, "tirage_4", 50000.0, Devise.USD));
    produitsFinanciers.add(new ProduitFinancier(1, "reference_1", "Xebia", 1000000.0, Devise.EUR, tirages));
    produitsFinanciers.add(new ProduitFinancier(2, "reference_2", "Xebia", 1500000.0, Devise.USD, tirages));
  }
  @Test
  def testGetProduitsFinanciersParDevise() {
    var financiersParDevise = financeService.getProduitsFinanciersParDevise(produitsFinanciers, Devise.EUR);
    financiersParDevise should have size (1);
    financiersParDevise.get(0).getReference should be("reference_1");
  }
  @Test
  def testGetTotalMontantParDevise() {
    val totalMontantParDevise = financeService.getTotalMontantParDevise(produitsFinanciers);
    totalMontantParDevise should have size (2);
    totalMontantParDevise should contain key (Devise.EUR);
    totalMontantParDevise should contain value (90000.0);
    totalMontantParDevise should contain key (Devise.USD);
    totalMontantParDevise should contain value (130000.0);
  }
}

A noter que Scala et Java étant interopérables, le service Java FinanceService est appelé dans ce test.

Troisième étape : migration du service

Passons maintenant à la migration du service FinanceService en Scala. En premier lieu, créons la classe FinanceServiceScala dans le package main/scala. Ajoutons également la classe FinanceServiceScalaTest dans le package test/scala et dont le contenu est identique à la classe de test FinanceServiceJavaTest. La seule différence réside dans la création du service : la classe FinanceServiceScala est appelée :

@Test
class FinanceServiceScalaTest extends ShouldMatchersForJUnit {
  var produitsFinanciers = new LinkedList[ProduitFinancier]();
  var financeService: FinanceServiceScala = new FinanceServiceScala();
  @Before
  def init() {
    genereProduitsFinanciers();
  }
  def genereProduitsFinanciers() {
    var tirages = new LinkedList[Tirage]();
    tirages.add(new Tirage(1, "tirage_1", 25000.0, Devise.EUR));
    tirages.add(new Tirage(2, "tirage_2", 15000.0, Devise.USD));
    tirages.add(new Tirage(3, "tirage_3", 20000.0, Devise.EUR));
    tirages.add(new Tirage(4, "tirage_4", 50000.0, Devise.USD));
    produitsFinanciers.add(new ProduitFinancier(1, "reference_1", "Xebia", 1000000.0, Devise.EUR, tirages));
    produitsFinanciers.add(new ProduitFinancier(2, "reference_2", "Xebia", 1500000.0, Devise.USD, tirages));
  }
  @Test
  def testGetProduitsFinanciersParDevise() {
    val produitsParDevise = financeService.getProduitsFinanciersParDevise(produitsFinanciers, Devise.EUR)
    produitsParDevise should have size (1);
    produitsParDevise(0).getReference should be("reference_1");
  }
  @Test
  def testGetTotalMontantParDevise() {
    val totalMontantParDevise = financeService.getTotalMontantParDevise(produitsFinanciers);
    totalMontantParDevise should have size (2);
    totalMontantParDevise should contain key (Devise.EUR);
    totalMontantParDevise should contain value (90000.0);
    totalMontantParDevise should contain key (Devise.USD);
    totalMontantParDevise should contain value (130000.0);
  }
}

Le but est de migrer la classe FinanceService en Scala et de faire exécuter la classe de test FinanceServiceScalaTest.

Voici le résultat de la classe FinanceServiceScala :

class FinanceServiceScala {
  /**
   * Retourne la liste des produits financiers pour la devise concernée.
   */
  def getProduitsFinanciersParDevise(produitsFinanciers: java.util.List[ProduitFinancier], devise: Devise) = {
    produitsFinanciers filter (_.getDevise equals devise);
  }
  /**
   * Retourne une map avec le total des montants des tirages de tous les produits financiers par devise.
   */
  def getTotalMontantParDevise(produitsFinanciers: java.util.List[ProduitFinancier]) = {
    def sommeTirage(tirages: Iterable[Tirage]): Double = tirages match {
      case head :: tail => head.getMontant.doubleValue + sommeTirage(tail)
      case _ => 0.0
    }
    var mapResultat = new HashMap[Devise, Double];
    def mapDeviseMontant(mapTirage: Map[Devise, Double]) = {
      mapTirage foreach {m => mapResultat getOrElseUpdate (m._1, mapTirage.getOrElse(m._1, 0.0) + m._2.doubleValue)}
    }
    for (produitFinancier <- asScalaIterable(produitsFinanciers);
         mapTirages = asScalaIterable(produitFinancier.getTirages) groupBy (_.getDevise) mapValues {tirage => sommeTirage(tirage)}
    ) yield mapDeviseMontant(mapTirages);
    mapResultat;
  }
}

En premier lieu, précisons que quelques qualités fonctionnelles du langage Scala (la fonction sommeTirage) ont été mises en avant, tout en gardant un certain niveau de lisibilité.

Attardons nous sur le code Scala :

• les fonctions getProduitsFinanciersParDevise et getMontantTotalParDevise prennent des java.util.List en paramètre : pour rappel, le but est d’exécuter la classe de test FinanceServiceScalaTest, identique à la classe de test FinanceServiceJavaTest. Etant donné que la classe FinanceServiceScalaTest utilise des listes Java, ces dernières nécessitent d’être passées en paramètre de ces méthodes.

Etudions plus précisément la fonction getMontantTotalParDevise :

• Pour itérer sur les listes Java, la fonction implicite de JavaConversions est utilisée : cette dernière fournit un ensemble de fonctions permettant de passer de liste, collection Java à Scala. D’où la présence de asScalaIterable.
• Voyons maintenant la portion de code suivante :

for (produitFinancier <- asScalaIterable(produitsFinanciers);
     mapTirages = asScalaIterable(produitFinancier.getTirages) groupBy (_.getDevise) mapValues {tirage => sommeTirage(tirage)}
)

Cette boucle permet de regrouper, pour chaque produit financier, la somme des tirages par devise. Cette somme est effectuée par la fonction sommeTirage qui utilise le pattern matching de Scala.
A cette étape intermédiaire, la variable mapTirages a pour contenu :

Map(USD -> 65000.0, EUR -> 45000.0)
Map(USD -> 65000.0, EUR -> 45000.0)

C’est donc pour cela qu’avec la fonction yield, un appel à la fonction mapDeviseMontant est effectué : cette fonction se charge de fusionner ces maps et de remplir la map finale (mapResultat).
Voyons un peu plus en détail les fonctions bien pratiques que sont getOrElse et getOrElseUpdate :

• getOrElse permet de retourner la valeur correspondant à la clé passée en paramètre ou, si la clé n’est pas présente, la valeur par défaut passée en paramètre.
• getOrElseUpdate permet de retourner la valeur associée à la clé passée en paramètre si la clé existe.

A travers cet article nous avons vu qu’avec une configuration minimale, la cohabitation du code Java et Scala est possible. Si vous aussi vous voulez essayer de tester le langage Scala sur vos projets et vous faire un avis, une approche pourrait consister à migrer vos tests unitaires en Scala. En espérant que cet article vous donne envie de tester Scala.
Pour finir, comme nous l’avons dit au début de cet article, la solution proposée est une solution parmi tant d’autres. Si vous voulez proposer une ou des meilleures solution(s), n’hésitez pas !

Vous trouverez le projet Java de départ (myJavaProject) et le résultat final de la cohabitation Java / Scala (myScalaJavaProject) sur le SVN de Xebia France .

L’introduction de cette nouvelle session sera assurée par Alexis Agahi (le gentil organisateur du PSUG), qui présentera, dans un quicky de 15 minutes, les notions de apply et unapply. Elle sera suivi par une présentation du plugin Scala pour Eclipse par David Bernard, l’un des développeurs de ce plugin (ainsi que des plugins maven maven-scala-plugin et vscaladoc).

Lors de sa présentation, David abordera :

• passé, présent et futur du plugin,
• une démonstration du plugin,
• et pour finir, une visite dans les entrailles du plugin.

Il reste encore des places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Martin a commencé sa présentation par les enjeux de la programmation parallèle, et plus particulièrement le Popular Parallel Programming qui est actuellement un sujet de grande importance. En effet, les multiples cœurs de nos processeurs et la puissance fournie par les GPGPU ne demandent qu’à être exploités. Mais les difficultés inhérentes à la programmation concurrente rendent cette tâche complexe et favorable à l’apparition de bugs difficiles à identifier et à corriger.

Il n’en reste pas moins que le nombre de cœurs doublent régulièrement dans nos CPU, et que des architectures telles que Fermi de NVIDIA réclament un gros paquet de threads pour alimenter les quelques 512 cœurs CUDA du processeur. La course aux GHz étant maintenant terminée au profit de l’augmentation du nombre de cœurs, si nous souhaitons disposer de plus de puissance de calcul, le parallélisme est actuellement la voie à emprunter.

Le but du Popular Parallel Programming est de rendre transparent pour le développeur l’utilisation parallèle des processeurs multi-cœurs. En implémentant le parallélisme au cœur du langage, son utilisation se fait à moindre coût.

En programmation parallèle, les problèmes commencent à survenir lorsque que l’on se retrouve dans des conditions de course (race-condition) et que des états sont partagés entre plusieurs unités d’exécution :

parallel programming + shared state => unpredictable state

La solution la plus efficace pour remédier à ce problème est de ne pas partager d’état et de travailler avec des objets immuables. Comme tout langage fonctionnel, Scala encourage l’utilisation d’objets immuables. Combiné avec la richesse de l’API Collections et Acteurs, cela fait de Scala (Scalable Language) un langage parfaitement taillé pour exploiter toute la puissance de nos processeurs. Le laboratoire Programming Methods Laboratory de l’EPFL, à l’origine de Scala, a d’ailleurs obtenu un financement sur cinq ans de l’union Européenne afin de soutenir le développement de Scala et notamment son utilisation dans la programmation parallèle.

Après la présentation des enjeux de la programmation parallèle et de la réponse apportée par Scala, Martin est revenu sur le travail effectué sur l’API Collections de Scala et qui a mené à une version 2.8. Ce refactoring a grandement facilité l’apparition des Parallel Collections sur lesquelles nous reviendrons plus tard.
Le but de ce chantier était de rendre l’API Collection plus homogène et de simplifier le code en supprimant un grand nombre de duplications. De nouvelles méthodes ont donc fait leur apparition sur les collections comme partition() :

	val (minors, adults) = people partition (_.age < 18)

Outre l’ajout de nouvelles méthodes, celles-ci assurent une cohérence du type d’arrivée avec le type de départ :

scala> List(1,2,3) map (_ * 2)
res0: List[Int] = List(2, 4, 6)
scala> Array(1,2,3) map (_ * 2)
res3: Array[Int] = Array(2, 4, 6)

Martin nous a ensuite présenté le travail effectué sur les Parallel collections qui sera intégrée dans la version 2.9, dont la première Release Candidate est prévue courant Mars. Cette fonctionnalité permet l’exploitation des multiples cœurs de nos processeurs pour effectuer certaines opérations sur des collections. La plupart des opérations sur les collections comme les fonctions map(), reduce(), filter() … obtiendront un gain sensible de performance sur des architectures parallèles (Martin évoque un facteur 2,5x pour 4 cœurs et 4,5x sur 8 cœurs). La bonne nouvelle pour les développeurs est que ceci vient quasiment gratuitement. Il suffit en effet d’utiliser le bon type de collection ou d’utiliser la méthode par() retournant la collection parallèle équivalente pour en profiter. On aime !!!
Les Parallel Collections devraient donc nous permettre d’exploiter un peu mieux la puissance de nos processeurs sans entrer dans le casse-tête favorable aux erreurs qu’est la programmation parallèle.

Voici un exemple dans lequel on pourrait trouver un intérêt à utiliser les Parallel Collections. Nous allons chercher à compter le nombre de personnes par tranche d’âge. On commence par générer aléatoirement une liste d’années de naissance :

scala> val birthYears = for ( x <- 1 to 100000 ) yield 2011 - (Math.random * 77).round
birthYears: scala.collection.immutable.IndexedSeq[Long] = Vector(1951, 1991, ...)

Nous utilisons ensuite l’API Collections afin de regrouper les personnes (ce code est non optimisé afin d’améliorer sa lisibilité) :

scala> birthYears map (2011 - _) groupBy {
       case i if(i < 10) => "child"
       case i if (i < 20) => "teenager"
       case i if(i < 60) => "adult"
       case _ => "senior"} map { case (category, ages) => (category, ages.size) }
res0: scala.collection.immutable.Map1 = Map((child,12452), (senior,22917), (adult,51827), (teenager,12804))

Le traitement ici est assez simple. Il s’agit d’obtenir la répartition d’une population en fonction de son âge en quatre catégories : « child », « teenager », « adult » et « senior ». On peut imaginer que le traitement soit plus complexe et que l’on travaille sur un plus gros jeu de données. L’utilisation des Parallel Collections nous permettra un gain de performance sur une machine équipée de plusieurs cœurs :

scala> birthYears.par map (2011 - _) groupBy {
       case i if(i < 10) => "child"
       case i if (i < 20) => "teenager"
       case i if(i < 60) => "adult"
       case _ => "senior"} map { case (category, ages) => (category, ages.size) }
res1: ...

La méthode par sur birthYears retourne une version « parallèle » de la collection d’origine ce qui permet l’utilisation de l’implémentation parallèle des fonctions map et groupBy.

La soirée s’est ensuite poursuivie par une petite séance de questions réponses. Martin nous a indiqué souhaiter une plus grande régularité dans la livraison des nouvelles versions de Scala et nous a aussi rassuré quand à la pérennité du langage dans l’avenir. Comme indiqué plus haut, le projet a en effet obtenu un financement de la part de l’union européenne et il est aussi soutenu par la société Scala Solutions dont Martin est co-fondateur.
D’autres sujets ont été évoqués comme le changement de licence de Scala au profit d’un licence plus libre comme Apache par exemple. Sur ce point Martin est plutôt ouvert mais ce genre de démarche est généralement chronophage et ne figure actuellement pas dans le haut des priorités.

Un grand merci à Martin Odersky pour le temps qu’il a bien voulu nous accorder, pour la qualité de sa présentation et bien entendu, pour le langage Scala !
Si Scala vous intéresse, Xebia Training organise deux autres sessions de formation cette année, l’une aura lieu fin mars et l’autre en décembre.