Publié par

Il y a 7 années -

Temps de lecture 7 minutes

Revue de Presse Xebia

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

Actualité éditeurs / SSII

Web

Le coin de la technique

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

Actualité éditeurs / SSII

Roadmap Playframework 2.1 & 2.2

La core team playframework a publié dernièrement une roadmap indicative des fonctionnalités à venir dans les versions 2.1 et 2.2. Pas de date de release pour l’instant mais un point sur les fonctionnalités probables.

Pour la version 2.1, les principales nouvelles fonctionnalités sont :

  • Fichiers de route dans les sous projets
  • Injection dans les controllers
  • Support require.js

et les principaux changements techniques :

  • Passage à Scala 2.10 et sbt 0.12 ( avec entre autre une compilation plus rapide )
  • Migration à l’API Futures et Promises (SIP-14)
  • Amélioration de l’API de tests
  • Modularisation du framework

et bien sûr de nombreux autres changements.

Pour la version 2.2, la vision est un peu moins précise mais intéressante :

  • Support de Java 8 dans l’API Java de Playframework
  • Etude de diversification sur de nouveaux backends (Servlets 3.1, Spray)
  • Continuer la modularisation
  • Réduire les dépendances du framework
  • Fignoler IterateeIO
  • Améliorer le scaffolding
  • Intégrer/fusionner Anorm & Slick

Pour en savoir plus, il est maintenant possible de s’abonner à la mailing list de développement du framework.

Scala 2.10 RC-1

La nouvelle version de Scala est passée au statut de Release Candidate le 19 octobre. Généralement, les RC de Scala sont peu nombreuses comme on peut le voir dans le dépôt Typesafe.

Les principales nouveautés de Scala 2.10 sont :

et bien sûr de nombreux correctifs de bugs.

Impala, Hadoop Real Time par Cloudera

Hadoop et le temps réel sont des sujets qui ensemble suscitent beaucoup de discussions et parfois dévoilent des incompréhensions. MapReduce est actuellement l’approche standard pour traiter les données sur le système de fichier d’Hadoop HDFS. Il s’agit d’une approche par batch. Qu’un job mette 20 secondes à s’exécuter même pour traiter une seule ligne ne paraît pas aberrant car le framework a été architecturé pour gérer de gros volume de données, de façon distribuée et en gérant les pannes. Les mécanismes mis en place ont un coût, visible quand ils ne sont pas nécessaires. Quant au terme « temps réel », il faut bien faire la distinction entre les concepts de temps réel strict et souple. Dans un cas on peut considérer les corrections balistiques et dans l’autre plutôt une expérience utilisateur fluide.

Toutefois cela ne signifie pas qu’il n’est pas possible d’envisager des explorations dynamiques et interactives des données stockées sur un cluster Hadoop. Cependant, cela demande de mettre en place une structure de données particulière (pouvant potentiellement être persistée par des fichiers dans HDFS) et un traitement ne s’appuyant pas sur Hadoop MapReduce. Cloudera a annoncé sa solution, Impala, durant la conférence Strata. Il n’y a pas encore beaucoup d’information sur cette solution en phase bêta mais cela pourrait être un élément clef de sélection face aux autres solutions de packaging Hortonworks et MapR comme l’explique Marcel Kornacker, le lead engineer d’Impala. Vue de loin, il s’agit de Hive sous stéroïdes. Il est possible de manipuler les données en utilisant un langage proche de SQL mais au lieu que celui-ci soit interprété nécessairement en MapReduce, il peut également être interprété par Impala afin de fournir une latence de requête faible, idéale pour l’exploration dynamique et interactive des données.

Web

Vers une formalisation de la spécification Markdown

Markdown est un langage de mise en forme créé en Perl par John Gruber en 2004. Sa popularité ces dernières années a explosé grâce à son utilisation sur des sites à forte visibilité pour les développeurs (Stack Overflow et GitHub). Malheureusement, si le langage Markdown est décrit sur le site originel, il n’en existe cependant pas de spécification formelle, d’implémentation de référence ou de suite de tests pour en valider formellement les implémentations.

Par conséquent, les (nombreuses) implémentations de Markdown ont commencé a diverger de façon plus ou moins importante. Dans le cadre du projet Meteor, le créateur du défunt EtherPad se prépare a créer un composant d’édition Markdown standardisé. Il a demandé par mail à Jeff Atwood, l’un des créateurs de Stack Overflow, de se joindre à lui dans la création de « Rockdown », une version formalisée de Markdown.

Jeff Atwood a lancé un appel public sur son blog, pour essayer d’obtenir la collaboration de l’auteur original et des principaux sites utilisant Markdown aujourd’hui.
L’appel génère évidement beaucoup de commentaires, certains négatifs, la plupart contenant des références très intéressantes vers des projets de parseurs, de widgets ou d’applications utilisant Markdown, comme Markdownpad. Une affaire à suivre…

Le coin de la technique

Hadoop et Delay scheduling

Le motto d’Hadoop est de déplacer le traitement à la donnée mais bien sûr il est parfois nécessaire de faire des sacrifices. Si 10 machines sont libres alors que seulement 3 machines possèdent les données visées, il peut être pertinent de toutes les utiliser même si cela implique de devoir transférer les données. C’est ce qui est fait par défaut, quelles que soient les stratégies de scheduling mises en place (par défaut, fair-scheduler, capacity-scheduler…). Cela dit, lorsque plusieurs jobs sont lancés alors il peut être pertinent d’attendre la disponibilité des machines possédant les données. Le job unitairement prendra plus de temps à s’exécuter mais dans l’ensemble les ressources seront utilisées plus efficacement. C’est le concept de « delay scheduling ». Cette fonctionnalité était déjà disponible pour le fair-scheduler dans Hadoop 1. La dernière pré-release d’Hadoop 2 vient d’annoncer que le capacity-scheduler supportera désormais également cette fonctionnalité.

Cascading, nouvelle version et meilleur support

Cascading vient de sortir une release mineure, la 2.0.6. Dans la partie utilisabilité, on notera l’ajout d’une propriété « cascading.step.display.id.truncate » permettant de tronquer l’identifiant du step dans son nom afin de permettre d’avoir enfin des noms compréhensibles pour les créateurs des jobs, les humains.

Cascading est souvent cité comme une solution pour écrire des MapReduces plus simplement, tout comme Pig ou Hive. Mais bien que ces trois projets soient désormais sous licence Apache, Cascading n’est pas un projet Apache. Cloudera, Hortonworks et MapR vont par eux-mêmes expliciter leur support de Pig et Hive mais Cascading ne profite pas du même élan. C’est pourquoi il est important de se renseigner par soi-même sur la compatibilité de Cascading avec votre packaging d’Hadoop. La bonne nouvelle est qu’Amazon EMR, Hortonworks et MapR ont passé les tests de compatibilité avec succès cet été.

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

Hadoop User Group, le 7 novembre : Agile Data, Machine Learning et IBM Streams

Les inscriptions pour le prochain meetup de l’Hadoop User Group sont ouvertes. Comme toujours les places sont gratuites mais limitées. Il faut donc se dépêcher de s’inscrire. Au programme :

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.