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.