Il y a 10 ans -
Temps de lecture 8 minutes
Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Actualité éditeurs / SSII
Mobilité
Web
Le coin de la technique
- Scala plus rapide que Java? (par Xavier Bucchiotty)
- Une nouvelle fonction de hachage : SHA3 (par Jean-Eudes Couignoux)
Actualité éditeurs / SSII
Release de NoSQLUnit 0.5.0
La nouvelle version 0.5.0 de NoSQLUnit est sortie vers le 15 octobre 2012.
NoSQLUnit est une extension de JUnit facilitant l’écriture des tests unitaires et des tests d’intégration pour les systèmes qui utilisent les bases NoSQL en backend. Il permet de gérer le cycle de vie de bases de données NoSQL ainsi que de les maintenir dans un état « connu ».
- Deux modes de gestion de cycle de vie de bases sont prévus :
- « in-memory mode » – démarrage d’une instance de la base dans la mémoire. Ce mode est plus adapté aux tests unitaires ;
- « managed mode » – permet de démarrer/arrêter le serveur NoSQL dans un processus séparé. Ce mode est habituellement utilisé pour les tests d’intégration.
- Maintenance de la base dans l’état ‘connu’ – permet d’injecter les données au début de chaque test ainsi que de faire le ménage à la fin.
Actuellement NoSQLUnit supporte plusieurs bases NoSQL : Mongo, Neo4j, Cassandra. Cette version apporte en plus le support de Redis dans « in-memory mode ».
NoSQLUnit est un projet jeune et dynamique qui évolue très vite. Il peut d’avérer très utile, pour les projets utilisant une base NoSQL, en facilitant considérablement les tests de la couche persistance.
Quelques défauts restent à régler, notamment au niveau de la gestion des erreurs, ainsi qu’ajouter le support pour plus de systèmes NoSQL (la version 0.6.0 contiendra le support de HBase).
Vous trouverez tous les détails dans la documentation officielle.
Mobilité
Déjà plus de 2000 projets initiés avec AndroidKickstartR
AndroidKickstartR est un générateur de squelettes de projets Android mis en ligne le 11/10/2012 et plus de 2000 projets ont déjà été générés.
Le principe de ce générateur est le suivant :
- Vous saisissez les paramètres de votre projet dans le formulaire du site (nom, librairies, etc…).
- Le site vous génère le projet et vous propose de le télécharger en dossier zippé.
- L’archive mise à disposition contient le projet, ses librairies, leurs dépendances et toute la configuration nécessaire à leur fonctionnement.
Pour ceux qui veulent y contribuer, le projet est disponible sur Github à cette adresse.
Web
Sortie de la M1 de Dart pour ses 1 an
Le jeune langage de chez Google vient de fêter ses un an, et nous livre sa première milestone. C’est donc l’occasion de faire une petite rétrospective du langage sur l’année passée.
Pendant ces mois, l’équipe Google, mais aussi les contributeurs (oui car il ne faut pas oublier que le langage est Open source) ont tâché de corriger plusieurs centaines de bugs ainsi que d’implémenter nombres de feature requests venant de la communauté. Le but pour Google étant vraiment d’être à l’écoute de la demande pour orienter le développement du langage. Parmi ces nouvelles fonctionnalités, il y a l’interoperabilité avec le Javascript, chose particulièrement plébiscitée par la communauté afin de pouvoir intégrer Dart à leurs applications JS déjà existantes. On peut aussi voir la suppression de l’opérateur “+” sur l’Objet String (WTF ?, non mais ils ont vraiment des arguments, l’operateur “as” pour le cast comme en ActionScript, du sucre syntaxique avec le “..” pour avoir des interfaces “fluent”, la définition de raw string via le marqueur r (Ex: var str = r”Foo\nBar”), l’opérateur “?” pour tester la présence d’un paramètre optionnel. (la liste complète des changements de la M1 est disponible ici)
Un des principaux arguments avancé pour l’utilisation de Dart est aussi les performances. A l’heure actuelle, la VM Dart devance le moteur V8 sur plusieurs épreuves du benchmark Octane, mais pas encore tous!(cf diapositive 32 de cette présentation de Nicolas Geoffray au dernier GDG-Paris) Une nouvelle fonctionnalité “snapshot” va permettre de démarrer des applications Dart dix fois plus vite qu’avant… comment ça marche ? En résumé, le mode “snapshot” va faire une sauvegarde du HEAP de votre application dans un fichier qui sera chargé au prochain démarrage juste avant le main. Le gain de temps se situe dans la construction du graphe d’objet qui n’est plus à faire par son application (plus de détail ici : What is the Snashopt concept in Dart ?)
L’éditeur Dart quant à lui commence à inclure des features d’IDE digne de ce nom, comme une palette d’outils de refactoring, du debugging sous l’éditeur et donne même la possibilité de débugger du code Dart directement depuis le browser via l’utilisation de l’option Source Map qui permet de mapper les fichiers Dart au fichier JS. La vidéo ci-dessous montre tout ça.
Une autre nouvelle importante, c’est l’ouverture du Pub! … Non c’est pas le dernier bar du coin avec de la bière pas chère… Mais bien le système de dépendance pour Dart comme on a avec Maven pour Java ou Bundler pour Ruby. Pub vous donnera la possibilité d’importer directement des sources depuis le repository Dart mais aussi depuis un repository Git. L’équipe mise beaucoup sur cette plateforme car elle considère que Dart n’est pas uniquement un langage, mais doit être une solution complète pour le développement web, avec tout l’outillage moderne que l’on connaît dans le monde Java.
On peut déjà trouver sur Pub le projet Dart Web Component qui vise à aider les développeurs à faire des applications MDV (Model-Driven-Views) comme on commence à avoir avec Ember.js, Backbone, ou encore Angular.js. Il utilise les fonctionnalités de Shadow DOM et Web Components ou les émule si elles ne sont pas implémentées.
Qu’est ce que Dart nous réserve maintenant ? La M1 implique plus de stabilité dans le langage, et donc beaucoup moins de changement cassant, mais le langage continuera quand même d’évoluer. Dans les cartons de Google, il y a l’ajout de mixins, une implémentation plus complète de l’API I/O côté serveur et l’amélioration des performances, le but étant d’être plus rapide que Javascript.
Sources:
http://blog.chromium.org/2012/10/dart-m1-release.html
http://news.cnet.com/8301-1023_3-57533571-93/dart-googles-attempt-to-outdo-javascript-passes-first-milestone
http://blog.sethladd.com/2012/10/a-more-stable-dart-m1.html
Le coin de la technique
Scala plus rapide que Java?
Si vous vous posez cette question, vous devriez lire ce billet paru dernièrement. L’auteur propose un micro-benchmarking sur un algorithme de quickSort, codé de la même façon en Java et en Scala, les premiers résultats montrent Scala plus rapide (852 ms pour Java contre 695 ms).
Comment expliquer cette différence? Le code exécuté reste du bytecode dans les deux cas avec la même JVM. La petite différence en faveur de Scala est due à une optimisation du compilateur Scala sur les fonctions tail-recursive (le dernier appel de la méthode est un appel vers elle-même). Sur ce sujet, vous trouverez des informations ici.
Mais l’auteur précise que ce microbench n’est pas pertinent et s’en explique.
Si on écrit l’algorithme de quickSort en Scala dans un style plus « fonctionnelle », les résultats s’inversent. On passe alors à 13 951 ms!
Scala serait-il plus lent que Java?
L’auteur explique bien sûr que non. La question à se poser n’est pas de savoir quel langage sera plus rapide que l’autre. La question repose plutôt sur les possibilités qu’offre le langage au développeur pour résoudre un problème. Certes la seconde solution en Scala paraît plus élégante, pour un oeil averti, mais est plus lente. C’est au développeur de choisir la bonne manière de faire.
De plus, ce n’est pas la problématique quotidienne de tous les développeurs de gérer des algorithmes de quickSort. Dans les applications les plus communes, il est souvent plus judicieux d’écrire un code lisible, facile à maintenir, d’optimiser si besoins les I/O (réseaux ou disques) avant même de penser à optimiser son algorithme.
Une nouvelle fonction de hachage : SHA3
Suite aux vulnérabilités trouvées sur les fonctions de hachage cryptographique MD5 et SHA1, le NIST a lancé un concours en 2007 pour définir un algorithme de hachage nouvelle génération.
Ce concours s’est achevé le 2 octobre, et Keccak a été désigné comme algorithme gagnant. Cependant, il est présenté comme complémentaire aux fonctions existantes (SHA2, famille d’algorithme comprenant en autre SHA-256 et SHA-512 ), et non comme un remplaçant.
L’annonce du vainqueur du concours sur le site du NIST se trouve ici.
Commentaire