Envoyer nous votre CV à recrutement@xebia.fr ou via le formulaire de contact.

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.

Nous aussi ! C’est pourquoi nous avons demandé à Nati Shalom, CTO & fondateur Gigaspaces, et à ses ingénieurs de venir animer une  session de design d’une application DataGrid / NoSQL en reprenant un cas d’utilisation de la vraie vie : Twitter recodé avec Gigaspaces et Cassandra.

Ce ne sera pas la conception d’un autre, ce sera notre design influencé par une des stars du domaine !

Les participants feront chacun leur tour du « pair-design » avec Nati Shalom et un coding dojo avec un ingénieur R&D de Gigaspaces.

Cette soirée gratuite aura lieu le 25 Janvier. Comme d’habitude, c’est à 19 heures chez Xebia ; l’inscription et les détails se trouvent sur EventBrite ! 

Le matériel de la soirée :

• L’analyse de Dotan Horovits sur l’étude de cas :
  Analytics for Big Data – Venturing with the Twitter Use Case
• Les slides de Nati Shalom Real time analytics for big data a twitter casestudy,
• Le code source de l’implémentation avec Gigaspaces et Cassandra
• Vidéo : en cours de post production ….

• Comment troubleshooter des problèmes de performances : les points d’entrées de l’investigation,
• Nouveaux langages sur la JVM : Scala, Clojure, …
• Cloud computing et virtualisation,
• JVM et appliances Java : Hotspot, jRockit, IBM J9, Azul, ExaLogic, …
• Support des large heaps : G1, Direct Memory, …
• … et quelques recommandations de programmation en Java.

Bonne écoute !

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.

DevOps aborde le paradoxe entre des équipes projets qui cherchent à livrer toujours plus fréquemment des nouvelles fonctionnalités d’une part et d’autre part des équipes d’exploitation qui cherchent à stabiliser et fiabiliser les systèmes tout en maitrisant leur coût.

On peut décrire DevOps selon trois axes :

• Aligner l’exploitation sur les enjeux métiers comme l’agilité a déjà aligné le développement sur le métier.
• Aligner le développement sur les réalités de l’exploitation pour rendre possible la mise en production, la disponibilité et la fiabilité des fonctionnalités métier.
• La transformation du métier d’OPS pour gérer des topologies chaque jour plus grosses et plus complexes avec l’adoption d’infrastructure as code et d’outils comme Chef ou Puppet. Les nouveaux OPS sont des programmeurs ! Ils débattent à la machine à café de TDD, de Ruby vs. DSL, de choix d’IDE, de Git vs. SVN, …

DevOps est souvent associé à la mise en place d’un processus de Continuous Delivery qui, dans la mouvance Lean, vise à déployer les fonctionnalités en production au plus vite et de maximiser les feedbacks. Nous reviendrons dans un autre billet sur les processus de Continuous Delivery.

La mise en place d’une culture DevOps touche les humains, les processus et les outils. Nous proposons une démarche englobant ces trois aspects en prenant comme point d’entrée les processus et, de proche en proche, faire évoluer les humains et les outils.

Les processus

Tous les processus impliquant la collaboration des équipes de développement et d’exploitation sont sujets à la mise en place d’une culture « DevOps ». Nous proposons pour la première étape de nous focaliser sur les processus de livraison, de déploiement et de troubleshooting.

Processus de livraison

Le processus de livraison (aka processus de packaging de la release) est la première interaction entre les équipes de développement et de production. Ses défauts causent l’allongement des projets et des interruptions de service. A l’inverse, l’automatisation du processus de livraison concilie « time to market » et diminution des risques en déployant plus fréquemment des changements au périmètre limité.

Nous proposons d’accorder les équipes de développement et d’exploitation sur les points suivants :

• Périmètre du package pour éviter les transformations et manipulations de mise en production : binaires identiques sur tous les environnements, fichiers de configurations épurées, etc.
• Rôles et responsabilités des équipes de développement et d’exploitation dans le packaging : binaires pour les développeurs, scripts et paramètres de configuration gouvernés par l’exploitation, etc.
• Définition des outils et techniques de packaging : tag Subversion/Git, build Maven, repository Maven Nexus, etc.
• Alignement des environnements de développement, d’intégration et de production pour éviter les écarts dev/prod : on doit tester sur un environnement le plus iso-prod possible.

Processus déploiement 

Une fois le packaging clarifié, nous proposons d’automatiser et d’unifier les processus de déploiement du dev à la prod. Les bénéfices sont :

• L’accélération des feedbacks des équipes de Q&A par des déploiements plus fréquents sur les environnements de validation.
• La fiabilisation des déploiements en les testant avant la mise en production.

L’objectif est la banalisation : les déploiements deviennent des « non événements ».

Processus de troubleshooting et de diagnostique

Réussir l’analyse de problèmes en production nécessite une préparation et un entrainement conjoints des équipes d’exploitation et de développement.

Des répétitions impliquant à la fois OPS et DEV permettront de valider :

• Que les applications sont debuggables : clarté des messages de log, clarté des exceptions, indicateurs de monitoring (JMX), etc.
• Que les outils de diagnostique sont installés : activation et collecte de logs, accès sans problèmes de firewall, disponibilité des outils sur les serveurs (curl, screen, jstat, jmap, etc.).
• Que les OPS et les DEV ont les bons outils de collaboration lors de problèmes en production : accès en lecture seule pour les DEV, messagerie instantanée, partage d’écran, micro-casques, etc.

Amélioration continue dev/prod

Les sujets d’amélioration continue transverse développement / exploitation sont gérés à la fois dans la continuité avec des réunions « dev/prod », et lors d’événements particuliers sous forme de points « post mortem » (panne, mise en production importante, etc.). Les sujets abordés relèvent d’enjeux à court, moyen et long terme :

• Monitoring & KPI : mise en place d’indicateurs techniques et métiers de bonne santé des applications (choix des outils, adaptation du code métier, health checks, etc.).
• Gestion des logs et des exceptions : amélioration des messages, outils de concentration et d’analyse de logs.
• Robustesse, tenue à la charge et capacity planning : suppression des points de faiblesse, mise en place de modes dégradés et de mécanismes de protection contre les saturations (e.g. : circuit breaker pattern), plans d’action de test en charge, plan d’ajout de capacité.
• Sécurité : patchs à appliquer, règles de sécurité de l’entreprise, etc.
• Fiabilisation des mises en production : activation progressive (feature toggle) ou partielle (canary testing) de fonctionnalités, etc.
• Processus et outillage : amélioration des processus dev/prod, alignement et partage des outils.
• Suivi du schéma directeur : gestion des montées de version des middlewares, migrations techniques, rationalisation des environnements.
• Evolutions de l’application et de l’infrastructure : refactoring de l’infrastructure, introduction de nouvelles technologies, plan de montée en compétence.

L’organisation : You build it, you run it ?

L’organisation est le sujet le plus complexe à aborder dans la mise en place d’une culture « DevOps ». Certaines entreprises comme Amazon ont intégré les équipes de développement et de production au point d’avoir pour devise « You build it, you run it ».

Un point essentiel est de s’assurer que les objectifs des différents acteurs soient alignés vers une amélioration de la disponibilité et de l’évolutivité des applications. Si les intérêts des uns et des autres sont contradictoires et ne sont pas alignés sur ce même objectif, l’adoption d’une culture « DevOps » touchera vite ses limites.

Nous proposons d’étudier les changement organisationnels au fur et à mesure de la mise en place des principes DevOps dans les processus que nous avons cité en veillant à prendre en compte les réalités de chaque entreprise.

Les vidéos de la soirées :

• Vidéo de la présentation de Sacha Labourey sur le Cloud
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 1
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 2
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 3
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 4

Actualité éditeurs / SSII

• Hadoop 1.0 (par Bertrand Dechoux)
• JavaFx 2.0.2 inclut dans Java 7u2 (par Romain Schlick)
• Sortie de Gatling 1.0 (par David Galichet)

Actualité éditeurs / SSII

Hadoop 1.0

Après six ans de gestation, Hadoop est enfin en 1.0.0! Cette release fut réalisée à partir de la version 0.20-security. On notera que:

• Kerberos peut être utilisé pour contrôler les accès;
• webhdfs, une API Rest sécurisée permet un accès plus simple à HDFS;
• l’accès aux fichiers locaux par HBase est plus performant.

Diverses améliorations de performance, corrections de bug et fonctionnalités font également partie de cette mouture, dont le détail se trouve dans les notes de release.

JavaFx 2.0.2 inclut dans Java 7u2

Décidément, ça bouge beaucoup du côté de JavaFx 2. Après une early access release de la version 2.1 sortie récemment, une nouvelle annonce vient d’être faite. JavaFx est intégré directement dans la nouvelle version de Java 7 update 2.
Ainsi, le JDK intègre le SDK de JavaFx, pendant que le JRE intègre son runtime.

Oracle a toujours l’intention de rendre open source l’intégralité de ce projet en l’intégrant à OpenJDK sous le nom de OpenJFX. Une JSR dédiée devrait même apparaître pour Java SE 9.

L’avenir des applications web semble se tourner vers HTML 5. On voit aussi que les RIA tel que Flex ou Silverlight sont en perte de vitesse. On peut se demander si JavaFx n’arrive pas trop tard ? La réponse serait que JavaFx se destine principalement aux applications desktop, qui ont toujours un rôle à jouer surtout que les API comme Swing ou SWT se font vieillissantes.

Sortie de Gatling 1.0

Gatling est un outil de test de stress (comme JMeter ou Tsung).

Gatling est écrit en Scala, utilise Netty et Akka. Les scénarios de test peuvent être générés à l’aide d’un outil (non recommandé), écrits à l’aide d’une DSL ou encore implémentés directement en Scala. Cette dernière option offre un grand nombre de possibilités comme requêter une base de données pour récupérer des données et constituer des jeux de test par exemple.

Gatling a été conçu dès le départ comme une solution de test haute performance, ce qui lui permet de simuler un grand nombre de clients tout en consommant peu de ressources. Il comble un défaut souvent reproché à JMeter qui était de consommer parfois plus de ressources que la cible que l’on souhaite tester.

Gatling enregistre les différentes sessions de test dans un fichier de log qui est ensuite analysé pour générer une série de graphes montrant les différents temps de réponse (global, par type de requête), les erreurs, les taux de succès etc… Vous trouverez de plus amples informations dans son aide en ligne.

Un programme standalone parse un fichier et insère les données parsées dans une base de données. Le même programme est exécuté dans trois régions différentes à savoir l’Europe, l’Amérique et l’Asie. Les entités persistées ont toutes un champ uid unique. La valeur de ce champ doit être sous la forme ‘E-1234′ ce qui est interprété comme l’enregistrement n° 1234 d’Europe. La base de données est la même pour les trois régions.

Lorsqu’on lance le programme dans les trois régions en parallèle, une exception est levée, laquelle et pourquoi est-elle levée ?

La solution sera détaillée sur cette même page dans les jours à venir.

N.B. certaines parties du code ont été omises pour garder la simplicité.

public class Region {
        public static final char EUROPE = 'E';
        public static final char AMERICA = 'U';
        public static final char ASIA = 'A';
}
public class UIDGenerator {
    private static Map<Character, Integer> ids = new HashMap<Character, Integer>();
        public static String generateRegionUid(char regionCode) {
            Integer lastId = 0;
            if(ids.containsKey(regionCode)) {
                lastId = ids.get(regionCode);
            }
            int nextId = lastId++;
            ids.put(regionCode, nextId);
            return new StringBuilder(regionCode).append('-').append(nextId).toString();
        }
        public static void main(String[] args) {
            String ordersFileName = args[1];
            char region = getRegion(args);
            List<Object> parsedOrders = parseOrder(ordersFileName );
            for(Order order:parsedOrders) {
                order.setUid(UIDGenerator.generateRegionUid(region));
            }
            //persist orders into dataBase.
    }
}

Actualité éditeurs / SSII

• Ceylon « Newton » M1 est disponible
• WebStorm 3.0 est disponible !
• Google sera le moteur de recherche par défaut de Firefox pour 3 ans
• Spring est sur GitHub
• Sortie de Spring Data Mongo 1.0

Actualité éditeurs / SSII

Ceylon « Newton » M1 est disponible

Ceylon est un langage de programmation fortement et statiquement typé destiné à la JVM, interopérable avec java, concurrent direct de Scala et de Clojure et soutenu par JBoss. Gavin King (créateur d’Hibernate et de Seam) et son équipe ont annoncé la mise à dispostion de la première release officielle de Ceylon. Cette première version executable du langage est dotée de nombreuses fonctionalités :

• Utilisation de classes pour les types primitifs de la JVM
• Inférence des types et du typage des arguments
• Paramètres optionnels avec valeur par défaut
• Argument nommés
• Types intersection, union et type vide
• Typage statique de la valeur null et des séquences vides
• Fonctions imbriquées
• Immutabilité par défault
• …

Même s’il manque encore quelques fonctionnalités présentes dans Java (enums, user-defined annotations et la réflexivité), le langage propose déjà des améliorations dans plusieurs domaines. Ajoutons que ce n’est que la première version (Milestone 1) et que la liste de fonctionnalités à venir est encore longue. Vous pouvez télécharger le langage et son code source, ou encore consulter la roadmap pour voir toutes les fonctionnalités à venir.

Sur le google group ceylon-dev, Gavin King indique sa volonté de sortir une nouvelle version « Milestone » tous les deux mois, jusqu’à atteindre la M5, qui sera la version 1.0 de Ceylon.

En même temps que cette première version du langage, un plugin eclipse 3.7 en béta a été mis à disposition des curieux.

WebStorm 3.0 est disponible !

C’est au tour de JetBrains d’offrir un joli cadeau de Noël aux amateurs de JavaScript !

WebStorm, un IDE JavaScript basé sur IDEA IntelliJ, est désormais disponible en v3.0 avec de nombreuses améliorations :

• Validation et mode debug des fichiers javascript pour Node.js
• Vérification de la qualité du code intégrée grace à JSLint
• Support des tests unitaires via JsTestDriver
• Détection des duplications de code Javascript, CSS et HTML
• Support du langage CoffeeScript
• Améliorations du debugger Javascript
• …

Contrairement à IntelliJ, il n’existe pas de version gratuite pour WebStorm. Une version d’évaluation de 30 jours est néanmoins disponible. Notons que des tarifs réduits sont pratiqués pour la sortie de cette nouvelle mouture.

JetBrains a également annoncé que la sortie de WebStorm 3.5 se fera au premier trimestre 2012.

Le langage JavaScript est décidément de plus en plus populaire et incontournable. Nul doute que cette popularité ne s’estompera pas en 2012, tant le web est un sujet en ébullition.

Google sera le moteur de recherche par défaut de Firefox pour 3 ans

Le 20 décembre, Mozilla a annoncé que Google sera le moteur de recherche par défaut de Firefox pour 3 ans. Cela fait suite à un accord dont les détails, financiers entre autre, restent bien sur confidentiels. C’est un événement important, indépendamment du navigateur que vous utilisez. En effet, Mozilla est une fondation à but non lucratif, ce qui n’est pas le cas des acteurs principaux du marché des navigateurs ou de la recherche : Microsoft, Google, Apple.

Spring est sur GitHub

Cela faisait longtemps que certains projects du framework Spring étaient sur GitHub. Voici l’annonce officielle dans laquelle SpringSource explique ce mouvement afin d’être plus proche des contributeurs grâce aux fonctionnalités offertes par GitHub. Cela ne vous empêchera cependant pas de devoir signer un accord pour toutes les contributions ‘non triviales’.

Sortie de Spring Data Mongo 1.0

Utiliser Mongo DB depuis le framework Spring est devenu encore plus facile avec la sortie de Spring Data Mongo 1.0. Ce cadeau de Noël contient :

• un template, MongoTemplate, pour faciliter les opérations classiques, avec une API fluide pour vos cas plus complexes;
• un namespace, mongo, permettant une configuration succinte des instances, de la réplication et du monitoring mais également d’enregistrer vos propres converteurs si la configuration du mapping par metadata ne convient pas à votre contexte;
• un support avancé des repositories grace à Spring Data: on notera par exemple le fait qu’il suffit de déclarer dans une interface votre requête suivant une convention définie et que le framework se chargera de l’implementation, qui est ‘juste’ une transformation du nom de la méthode;
• le support de QueryDSL pour ceux qui préféreraient une approche plus type safe;
• un appender vers mongo pour log4j : MongoLog4jAppender;
• un support pour de la persistance cross-store JPA + Mongo DB, permettant ainsi de prendre le meilleur du monde relationnel et NoSQL pour vos requêtes.

Hands On 1 : Fonction récursive

// test unitaire
fact(0) = 1
fact(1) = 1
fact(5) = 120
fact(10) = 3628800

Voici l’implémentation en Java qui suit assez bien la définition mathématique récursive de la fonction factorielle.

public static int factorial(int n) {
    if (n == 0) return 1;
    else return n * factorial(n - 1);
}

Voici l’équivalent avec Guava qui ressemble beaucoup à l’implémentation précédente.

Function<Integer, Integer> factorial = new Function<Integer, Integer>() {
    @Override public Integer apply(Integer n) {
        if (n == 0) return 1;
        else return n * apply(n - 1);
    }
};

Pour utiliser la fonction Guava, il suffit de taper :

Integer result = factorial.apply(5);

Passons à la version récursive terminale en Java.

private static int fact(int n, int k) {
    if (n == 0) return k;
    else return fact(n - 1, n * k);
}
public static int factorial(int n) {
    return fact(n, 1);
}

Et l’équivalent Guava.

public class FactorialFunction implements Function<Integer, Function<Integer, Integer>> {
    @Override
    Function<Integer, Integer> apply(final Integer n) {
        return new Function<Integer, Integer>() {
            @Override
            public Integer apply(Integer k) {
                if (n == 0) return k;
                else return FactorialFunction.this.apply(n - 1).apply(k * n);
            }
        };
    }
}
FactorialFunction fact = new FactorialFunction();
Integer result = fact.apply(5).apply(1); // factorial of 5

La version Guava est étonnement plus complexe au regard de la version Java. Ceci s’explique par deux difficultés :

1. la fonction factorielle récursive terminale prend deux paramètres,
2. la fonction factorielle récursive terminale est… récursive.

Pour le premier point, il faut savoir que Guava ne définit que des fonctions ne prenant qu’un seul paramètre en entrée. Pour avoir une fonction prenant en entrée deux paramètres, nous avons alors deux possibilités :

• une fonction qui prend deux paramètres équivaut à une fonction qui prend en paramètre un élément, sachant que cet élément est un couple de valeurs ce qui nous obligerais à créer un type Pair<T1, T2> ou Tuple2<T1, T2>,
• une fonction qui prend deux paramètres équivaut à une fonction qui prend un premier paramètre et retourne une fonction qui prend le paramètre suivant et retourne le résultat final.

Cette seconde solution s’appelle la curryfication. Elle correspond à transformer une fonction de n paramètres en un chaînage de n fonctions prenant chacune un des paramètres et se renvoyant les unes des autres. Ce qui est très utile par exemple pour évaluer partiellement une fonction.

C’est la solution choisie ici. Ce qui explique la signature un peu particulière : Function<Integer, Function<Integer, Integer>>. Autrement dit, notre fonction factorielle est une fonction qui prend un entier et retourne une fonction qui prend un autre entier et retourne un nouvel entier en résultat. Pour rappel, l’interface Function prend deux types en paramètre : le premier correspond au type du paramètre en entrée et le second au type retourné par la fonction.

Concernant maintenant le fait que la fonction soit récursive en plus du fait que j’ai choisi d’utiliser la curryfication, cela nous oblige à nommer explicitement notre fonction, ou plus exactement à définir une classe nommée. Ceci permet d’utiliser la notation : FactorialFunction.this.apply(...). Grâce à cette notation, on demande à Java de ne pas faire un appel à la méthode apply() dans laquelle se trouve directement notre instruction, mais plutôt à la méthode apply() de la classe FactorialFunction.

Hands On 2 : Filter

// test unitaire
Iterable<Double> salaries = Arrays.asList(1000.0, 2000.0, 2500.0, 3000.0, 4000.0);
Iterable<Double> newSalaries = HandsOn.lessThan(3000.0, salaries);
assertThat(newSalaries).containsOnly(1000.0, 2000.0, 2500.0);

Cet exercice se résout simplement. À noter, qu’au vu de la verbosité de Java (et en attendant Java 8), il vaut mieux utiliser une variable intermédiaire avec un nom significatif pour la fonction que de créer la fonction dans l’appel à la méthode filter(). Ainsi, la lisibilité du code s’en trouve améliorée.

private Predicate<Double> isLessThan(final double threshold) {
    return new Predicate<Double>() {
        @Override
        public boolean apply(Double salary) {
            return salary < threshold;
        }
    };
}
public static Iterable<Double> lessThan(double threshold, Iterable<Double> salaries) {
    return Iterables.filter(salaries, isLessThan(threshold));
}

Hands On 3 : Map / Transform

// test unitaire
Iterable<Double> salaries = Arrays.asList(1000.0, 2000.0, 2500.0, 3000.0, 4000.0);
Iterable<Double> newSalaries = HandsOn.increaseSalaries(salaries, 0.02);
assertThat(newSalaries).containsOnly(1020.0, 2040.0, 2550.0, 3060.0, 4080.0);

De même, cet exercice se résout simplement.

private Function<Double, Double> increaseSalary(final double rate) {
    return new Function<Double, Double>() {
        @Override
        public Double apply(Double salary) {
            return salary * (1.0 + rate);
        }
    };
}
public static Iterable<Double> increaseSalaries(Iterable<Double> salaries, double rate) {
    return Iterables.transform(salaries, increaseSalary(rate));
}

Hands On 4 : Fold / Reduce

// signature
// <T, R> R fold(Iterable<T> values, R init, Function<R, Function<T, R>> function)
// test unitaire
List<Integer> values = Arrays.asList(1, 2, 3);
Integer result = HandsOn.fold(values, 0, sum);
assertThat(result).isEqualTo(6);

La fonction fold est en réalité assez simple.

public static <T, R> R fold(Iterable<T> values, R init, Function<R, Function<T, R>> function) {
    return fold(values.iterator(), init, function);
}
public static <T, R> R fold(Iterator<T> values, R init, Function<R, Function<T, R>> function) {
    R result = init;
    while (iterator.hasNext()) {
        result = function.apply(result).apply(iterator.next());
    }
    return result;
}

On aurait pu résoudre l’exercice avec une structure for-each sur l’Iterable values passé en paramètre. J’ai fait le choix d’avoir une fonction disponible à la fois pour les Iterable et les Iterator.

Pour le test unitaire, nous avons besoin de la fonction sum. Voici comment la définir :

Function<Integer, Function<Integer, Integer>> sum = new Function<Integer, Function<Integer, Integer>>() {
    @Override
    public Function<Integer, Integer> apply(final Integer a) {
        return new Function<Integer, Integer>() {
            @Override
            public Integer apply(Integer b) {
                return a + b;
            }
        };
    }
};

Hands On 5 : Zip

// signature
// <T1, T2, R> Iterable<R> zipWith(Function<T1, Function<T2, R>> function, Iterable<T1> list1, Iterable<T2> list2)
// test unitaire
Iterable<Integer> result = zipWith(sum, Arrays.asList(1, 2), Arrays.asList(3, 4, 6));
assertThat(result).containsExactly(4, 6);

Voici l’implémentation de la fonction zipWith à la fois pour les Iterable et les Iterator.

public static <T1, T2, R> Iterable<R> zipWith(Function<T1, Function<T2, R>> function, Iterable<T1> list1, Iterable<T2> list2) {
    return new Iterable<R>() {
        @Override
        public Iterator<R> iterator() {
            return zipWith(function, list1.iterator(), list2.iterator());
        }
    };
}
public static <T1, T2, R> Iterator<R> zipWith(Function<T1, Function<T2, R>> function, Iterator<T1> iterator1, Iterator<T2> iterator2) {
    return new AbstractIterator<R>() {
        @Override
        protected R computeNext() {
            if (!(iterator1.hasNext() && iterator2.hasNext())) {
                return endOfData();
            }
            return function.apply(iterator1.next()).apply(iterator2.next());
        }
    }
}

On voit ici l’utilisation de la classe AbstractIterator qui simplifie l’écriture d’instances d’Iterator. On voit aussi comment utiliser la méthode endOfData() pour marquer la fin du flux. La fonction sum qui apparaît dans le test unitaire est exactement la même que la fonction sum de l’exercice précédent.

Hands On 6 : Liste d’entiers infinis avec Guava

// test unitaire
Iterable<Integer> fiveInts = Iterables.limit(HandsOn.enumPositiveInts(), 5);
assertThat(fiveInts).containsExactly(0, 1, 2, 3, 4);
Iterable<Integer> fiveNextInts = Iterables.limit(Iterables.skip(HandsOn.enumPositiveInts(), 5), 5);
assertThat(fiveInts).containsExactly(5, 6, 7, 8, 9);

On peut caractériser la notion de suite infinie avec un Iterator.

public static Iterable<Integer> enumPositiveInts() {
    return new Iterable<Integer>() {
        @Override
        public Iterator<Integer> iterator() {
            return new AbstractIterator<Integer>() {
                private int nextValue = 0;
                @Override
                protected Integer computeNext() {
                    int current = nextValue;
                    nextValue++;
                    return current;
                }
            };
        }
    };
}

On peut voir que « l’infini » est représenté par le fait que nous ne faisons pas appel à la méthode endOfData().

Hands On 7 : Fibonnacci sous forme de liste infinie

// test unitaire
assertThat(Iterable.limit(HandsOn.fibs(), 8)).containsExactly(0, 1, 1, 2, 3, 5, 8, 13);

Cette exercice ressemble au précédent, sauf qu’il faut pouvoir conserver les deux étapes précédentes.

public static Iterable<Integer> fibs() {
    return new Iterable<Integer>() {
        @Override
        public Iterator<Integer> iterator() {
            return fibIterator();
        }
    }
}
public static Iterator<Integer> fibIterator() {
    return new AbstractIterator<Integer>() {
        private int a = 0;
        private int b = 1;
        @Override
        protected Integer computeNext() {
            int result = a;
            a = a + b;
            b = result;
            return result;
        }
    }
}

Il faut savoir que cette façon d’écrire la suite Fibonnacci est très efficace par rapport à la version connue utilisant une double récursivité (fib(n) = fib(n-1) + fib(n-2)). La version ci-dessus est complètement linéaire et la récupération de l’élément suivant ne nécessite pas d’explorer une arborescence.

Java Instrumentation

L’API instrumentation a vu le jour avec Java 5. Elle décrit le mécanisme de manipulation du byte-code utilisé par les outils d’analyse, afin de collecter des données relatives à l’exécution des programmes. Avant la version 5 de Java, les programmes utilisaient d’autres techniques pour analyser les programmes pendant leur exécution, notamment JPDA (présentée dans le précédent article). L’instrumentation est réalisée avec les « agents » Java. Un agent est un programme Java qui se déploie sous forme d’un jar. Il est lancé au démarrage de la JVM en ajoutant l’option « -javaagent:cheminAgent=options » à la ligne de commande (on remarquera au passage la similarité avec le lancement de JPDA). « cheminAgent » est le chemin pointant vers le jar de l’agent et « options » la liste des arguments sous forme d’une seule chaine de caractères.
Pour qu’il soit valide, l’agent doit contenir:

• Une classe qui implémente la méthode premain dont la signature doit être:

  public static void premain(String agentArgs, Instrumentation inst);
  

  ou

  public static void premain(String agentArgs);
  

  Cette méthode ressemble à la méthode main d’un programme Java. Elle sera appelée par la JVM au lancement de l’agent en lui fournissant une chaîne de caractères, à analyser par le programme, représentant les options de l’agent et un objet instrumentation. Typiquement, la méthode premain décompose les options et ajoute un ou plusieurs ClassFileTransformer à l’objet instrumentation.

• Une classe qui implémente ClassFileTransformer : La méthode transform() de la classe sera appelée pour chaque chargement de classe. S’il y a plusieurs transformateurs, ils seront invoqués dans l’ordre dans lequel ils ont été ajoutés. La méthode reçoit parmi ses arguments le byte-code original de la classe, et elle retourne le byte-code après modification s’il y en a eu.
• Un fichier META-INF/MANIFEST.MF : ce fichier doit contenir un attribut Premain-Class désignant le nom complet de la classe qui implémente la méthode premain, et optionnellement un attribut Boot-Class-Path qui référencera les librairies externes. Pour les autres options, le lecteur pourra se référer à la spécification.

ExceptionHandlerAgent

Pour résoudre le problème des exceptions Java levées par l’application, nous allons créer notre propre agent ExceptionHandlerAgent. Celui-ci modifiera le byte-code des classes afin de rajouter le traitement des exceptions. Il implémente donc l’interface ClassFileTransformer. La manipulation du byte-code Java n’est pas chose facile. Elle nécessite une connaissance approfondie du format du byte-code. Heureusement, il existe beaucoup de frameworks (ASM, BCEL, Javassist…) qui rendent cette tâche plus facile. Dans notre exemple, nous allons utiliser la librairie Javassist. Elle nous offre un ensemble de méthodes haut-niveau pour la manipulation du byte-code ainsi qu’un micro-compilateur intégré pour la compilation des petits bouts de code Java. Nous présenterons cette librairie en détail dans un prochain article.

La méthode premain se contente d’ajouter une nouvelle instance d’ExceptionHandlerAgent

public class ExceptionHandlerAgent implements ClassFileTransformer {
    public static void premain(String agentArgument, Instrumentation instrumentation) {
        instrumentation.addTransformer(new ExceptionHandlerAgent());
    }
...
}

La manipulation du byte-code est effectuée dans la méthode transform(), qui est appelée à chaque chargement de classe. Instrumenter les classes de la JVM ne nous intéresse pas et peut même être dangereux. Il en est de même pour les classes des librairies utilisées par l’application. Nous nous intéressons donc uniquement au classes du package fr.xebia.

public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined,
            ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
        if (className.startsWith("fr/xebia")) {
            ClassPool pool = ClassPool.getDefault();
            CtClass cl = null;
            try {
                cl = pool.makeClass(new java.io.ByteArrayInputStream(classfileBuffer));
                if (!cl.isInterface()) {
                    CtBehavior[] methods = cl.getDeclaredBehaviors();
                    for (int i = 0; i < methods.length; i++) {
                        if (!methods[i].isEmpty()) {
                            enrichMethod(cl, methods[i]);
                        }
                    }
                    classfileBuffer = cl.toBytecode();
                }
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                if (cl != null) {
                    cl.detach();
                }
            }
        }
        return classfileBuffer;
    }

Notre but est de traiter les exceptions « catchées » et non « catchées ». Pour les exceptions non catchées, nous pouvons utiliser Thread.setDefaultUncaughtExceptionHandler(eh), qu’il suffit d’insérer au début de la méthode main. Javaassist ne permet pas de compiler les classes internes et anonymes, nous allons faire en sorte que la classe contenant la méthode main implémente l’interface UncaughtExceptionHandler. Il suffit alors de passer une instance de cette classe à la méthode statique setDefaultUncaughtExceptionHandler(). Pour les autres exceptions, nous pouvons modifier les clauses catch afin d’insérer le traitement d’exception au début de la clause. C’est ce qui est fait par la méthode enrichMethod.

private void enrichMethod(CtClass cl, CtBehavior ctBehavior) throws CannotCompileException, NotFoundException {
        if (ctBehavior.getName().equals("main")) {
            CtClass eh = ClassPool.getDefault().makeClass("java.lang.Thread$UncaughtExceptionHandler");
            cl.addInterface(eh);
            CtMethod m = CtNewMethod.make("public void uncaughtException(Thread t, Throwable e){System.out.println(\"An Uncaughed exception is thrown\");e.printStackTrace();}",cl);
            cl.addMethod(m);
            ctBehavior.insertBefore("Thread.setDefaultUncaughtExceptionHandler( new " + cl.getName() + "());");
        }
        ctBehavior.instrument(new ExprEditor() {
            @Override
            public void edit(Handler h) throws CannotCompileException {
                h.insertBefore("System.out.println(\"Caugh an Exception\");");
            }
        });
    }

Conclusion

Contrairement à la solution avec JPDA, cette solution n’ajoute pas d’overhead à l’exécution de l’application. Cependant, le pré-requis de bien comprendre un minimum le format byte-code avant de pouvoir en profiter reste un handicap pour la démocratisation de cette API, qui reste réservée aux développeurs de frameworks. La simplicité de l’API et la complexité des librairies de manipulation de code font de cette solution une arme à double tranchant.

Mais comment peut-on mettre en pratique le TDD sur du code déjà écrit, parfois mal pensé et non testé. Cet article va partir d’un exemple concret, une classe comme on pourrait en trouver sur tous les projets. Le but est de commencer une démarche TDD et de pousser au maximum son efficacité (mise en évidence d’un bug potentiel, ajout d’une nouvelle fonctionnalité, refactoring du code et refactoring des tests). Au final, la classe sera beaucoup plus apte à subir le changement et surtout, elle sera testée et couvrira tous les cas d’utilisation.

Au commencement était le code existant

L’exemple est tiré du site The Daily WTF. C’est en regardant la photo ci-dessous que je me suis dit que le code serait un bon candidat au refactoring. Il n’y a pas de frameworks, de règles de gestion complexes et c’est pourtant ce genre de code « simple » qui peut nous ralentir au quotidien.

Vous l’aurez compris, il s’agit d’associer des mots que nous appellerons flag à des valeurs booléennes : par exemple ON correspond à true, OFF à false. De plus, les flags peuvent être orthographiés différemment : ON, On, on doivent tous correspondre à true.

Voici l’adaptation Java du code legacy ci-dessus. J’ai introduit la méthode publique asBoolean(), utilisée par le code appelant, renvoyant la valeur booléenne d’un flag. Si aucun flag ne correspond, la méthode renvoie null.

public class StringSettingBool {
    private Map<String, Boolean> boolFlag = new HashMap<String, Boolean>() {
        {
            put("NO", false);
            put("No", false);
            put("no", false);
            put("YES", true);
            put("Yes", true);
            put("yes", true);
            put("OFF", false);
            put("Off", false);
            put("off", false);
            put("ON", true);
            put("On", true);
            put("on", true);
        }
    };
    public Boolean asBoolean(String flag) {
        if (boolFlag.containsKey(flag)) {
            return boolFlag.get(flag);
        }
        return null;
    }
}

Le Cycle TDD

Pour rappel, le TDD consiste en 3 étapes :

1. Écrire un test qui échoue
2. Écrire le code suffisant pour passer le test
3. Refactorer le code

Couverture du legacy

Dans notre cas, nous devons d’abord écrire une suite de tests couvrant le code déjà écrit avant de pouvoir le modifier (correction d’anomalie, refactoring, ajout d’une évolution).

Voici les tests que j’ai écrit :

public class StringSettingBoolTest {
    StringSettingBool stringSettingBool = new StringSettingBool();
    @Test
    public void should_be_false_for_no_flag() {
        for (String noFlag : { "NO", "No", "no" })
            assertFalse(stringSettingBool.asBoolean(noFlag));
    }
    @Test
    public void should_be_false_for_off_flag() {
        for (String offFlag : { "OFF", "Off", "off" })
            assertFalse(stringSettingBool.asBoolean(offFlag));
    }
    @Test
    public void should_be_true_for_yes_flag() {
        for (String yesFlag : { "YES", "Yes", "yes" })
            assertTrue(stringSettingBool.asBoolean(yesFlag));
    }
    @Test
    public void should_be_true_for_on_flag() {
        for (String onFlag : { "ON", "On", "on" })
            assertTrue(stringSettingBool.asBoolean(onFlag));
    }
    @Test
    public void should_return_null_when_flag_is_null() {
        assertNull(stringSettingBool.asBoolean(null));
    }
    @Test
    public void should_return_null_when_flag_is_unknown() {
        assertNull(stringSettingBool.asBoolean("garbage"));
    }
    @Test
    public void should_return_null_when_flag_is_empty() {
        assertNull(stringSettingBool.asBoolean(""));
    }
}

Comme vous pouvez le remarquer, je vérifie simplement les deux règles précédemment citées :

1. Les flags doivent correspondre aux valeurs booléennes attendues (yes -> true, no -> false, …)
2. La valeur null doit être retournée en cas d’utilisation d’un flag invalide (valeur nulle ou inconnue ou chaîne vide).

Démarrage du cycle

Pour les besoins de l’article, nous imaginerons qu’un bug a été détecté par l’équipe QA. L’application n’a pas le comportement attendu si la valeur nO est passé en paramètre d’un formulaire.

TDD étape 1 – Écrire le test qui échoue

Si le flag NO est orthographié nO, la méthode asBoolean() ne renverra pas false mais null. Comme première correction nous pouvons rendre la méthode asBoolean() insensible à la casse.

Nous faisons du TDD, nous écrirons donc un test qui doit mettre en évidence le bug.

@Test
public void should_be_false_for_no_flag_ignore_case() {
    assertFalse(stringSettingBool.asBoolean("nO"));
}

Le test échoue, c’est l’occasion de toucher au code !

TDD étape 2 – Faire passer le test

Rien de bien compliqué, nous allons convertir en minuscule le flag reçu en paramètre.

public Boolean asBoolean(String flag) {
        if (flag == null) {
            return null;
        }
        flag = flag.toLowerCase();
        if (boolFlag.containsKey(flag)) {
            return boolFlag.get(flag);
        }
        return null;
    }

Le test est vert, profitons-en pour réduire la quantité de code !

TDD étape 3 – Refactorer

Depuis que nous utilisons les flags en minuscule, nous pouvons supprimer toutes les insertions superflues. Le code lié à l’initialisation de la Map est désormais plus concis.

private Map<String, Boolean> boolFlag = new HashMap<String, Boolean>() {
    {
        put("no", false);
        put("yes", true);
        put("off", false);
        put("on", true);
    }
};

Nouvelle fonctionnalité

Il devient dorénavant plus simple d’ajouter un flag comme par exemple start.

TDD étape 1 – Écrire le test qui échoue

On commence par écrire les tests qui couvrent le flag start

@Test
public void should_be_true_for_start_flag() {
    String[] startFlags = { "START", "start", "Start", "STart", "STArt" };
    for (String startFlag : startFlags) {
        assertTrue(stringSettingBool.asBoolean(startFlag));
    }
}

TDD étape 2 – Faire passer le test

Une seule ligne est nécessaire (contre trois dans la version originale) :

put("start", true);

TDD étape 3 – Refactorer, les tests cette fois-ci !

La batterie de tests ne comporte pas toutes les possibilités d’écriture des flags (ex: STARt, StArT, STARt, …). Nous pourrions profiter d’une fonctionnalité de JUnit permettant de paramétrer l’exécution des tests avec un jeu de données préalablement généré. Ce que nous voulons, c’est qu’un test prenne en paramètre un flag et la valeur booléenne attendue en résultat de l’appel à la méthode asBoolean(). Le jeu de données serait constitué de toutes les combinaisons de casses possibles d’un flag.

@RunWith(Parameterized.class)
public class StringSettingBoolTest {
    StringSettingBoold stringSettingBool = new StringSettingBool();
    private String flag;
    private boolean expectedBooleanValue;
    public StringSettingBoolTest(String flag, boolean expectedBooleanValue) {
        this.flag = flag;
        this.expectedBooleanValue = expectedBooleanValue;
    }
    @Test
    public void should_return_boolean_value_for_valid_flag() {
        assertEquals(flag + " should be " + expectedBooleanValue, expectedBooleanValue,
                stringSettingBool.asBoolean(flag));
    }
    @Parameters
    public static Collection<Object[]> createDataSet() {
        Collection<Object[]> data = new ArrayList<Object[]>();
        addItem(data, false, "no", "off");
        addItem(data, true, "yes", "on", "start");
        return data;
    }
    private final static StringUtil stringUtil = new StringUtil();
    private static void addItem(Collection<Object[]> data, boolean flagBooleanValue, String... flags) {
        for (String flag : flags) {
            Set<String> findAllCases = stringUtil.findAllCases(flag);
            for (String flagName : findAllCases) {
                Object[] item = new Object[2];
                item[0] = flagName;
                item[1] = flagBooleanValue;
                data.add(item);
            }
        }
    }
}

Note: J’ai écrit la classe StringUtil et la méthode findAllCases() pour l’occasion, en TDD bien entendu. A partir du mot passé en paramètre, la méthode renvoie un Set de tous les combinaisons de casses possibles : start -> start, Start, STart, STArt, staRT, …

Les bienfaits des refactoring successifs

Le résultat est obtenu est désormais entièrement testé. De plus, la méthode asBoolean() accepte un paramètre dont la casse n’est plus importante.
Il suffit de trois étapes pour ajouter un nouveau flag, les étapes du cycle TDD :

1. Modifier l’un des deux appels dans la méthode createDataSet() de la classe de tests paramétrée. Ajoutons par exemple le flag stop en paramètre de la méthode addItem.

addItem(data, false, "no", "off", "stop");

Vérifier que les tests nouvellement générés échouent.

2. Ajouter le flag stop à la Map dans la classe StringSettingBool

private Map<String, Boolean> boolFlag = new HashMap<String, Boolean>() {
    {
        put("no", false);
        put("yes", true);
        put("off", false);
        put("on", true);
        put("start", true);
        put("stop", false);
    }
};

Vérifier que les tests nouvellement générés passent tous.

3. Refactorer si nécessaire

Que remarque-t-on ? Ajouter un nouveau flag prend désormais moins d’une minute ! Les risques d’erreur sont faibles (plus besoin de penser à ajouter une ligne par combinaison de casse). Le code est pleinement testé !

Conclusion

Ce premier billet consacré au TDD sur du code existant s’achève. Comme vous avez pu le constater, il est possible de se lancer dans l’apprentissage du TDD en prenant une partie de code peu complexe. Ayez toujours comme objectif d’avoir un code plus simple, plus court et mieux testé. Une nouvelle fonctionnalité devrait dorénavant être testable et implémentable plus facilement et plus rapidement.

Le prochain article sera consacré à l’extraction de dépendances et à l’utilisation de bouchons.

Les vidéos de la soirées :

• Vidéo de la présentation de Sacha Labourey sur le Cloud
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 1
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 2
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 3
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 4