One day @ Devoxx

Devoxx: Dev comme Développeur, Voxx comme voix...en bref, la voix du développeur. C'est ainsi que débute la keynotes de la première édition de Devoxx, en fait la Nième du plus connu Javapolis et pour illustrer cette "voix", rien de mieux que celle d'un beat boxer ; franchement terrible !

javaFX à l'honneur de la Keynote

De la keynote matinale, l'envie est de ne retenir que la présentation sur JavaFX. Ils voulaient nous faire rêver mais on a vu des applications embarquant des vidéos...bref difficile d'imaginer de applications de gestion. JavaFX semble être une réponse de Sun au Adobe de Flex mais il reste quelques limitations: - La plateforme. Là où Flex fonctionne sur un plugin présent sur une immense majorité des navigateurs, javaFX nécessite un JRE, une JVM - Les nouvelles versions de JavaFX propose de faciliter l'intégration avec des outils classiques des designers comme PhotoShop et Illustrator. Reste que l'intégration avec Flex sera trés certainement plus évidente ne serait-ce que parce qu'il s'agit de la même compagnie et qu'ils ont bien compris cet enjeu de rapprochement des développeurs et des designers - On pourrait penser que JavaFX présente l'avantage du langage Java - massivement maitrisé -. Mais en fait javaFX est aussi proche de Java qu'ActionScript.

Java7 et les APIs concurrentielles

L'implémentation qui a été faite des Threads depuis la première version de Java jusqu'à Java5 permettait de gérer l'asynchronisme plus que le parallélisem; ie. l'utilisation des multi coeurs. Java 5 introduit les Executor et les Tasks pour faciliter ce découpage en tâche d'assez haut niveau. java 7 veut utiliser au maximum les avancés des processeurs et faciliter la résolution de tâche qui peuvent être parallélisée au niveau d'une JVM (on ne parle pas ici de système distribué...). Les Apis fork/join facilite les opérations de tri de tableau, parcours d'arbre...Cette session est également l'occasion de découvrir comment fonctionne les piles dans ce type d'implémentation, un mécanisme de "work stealing" où chaque Worker Thread gère sa pile en FIFO et où les Worker Thread "amis" ont le droit de dépiler la pile des autres en FILO...

Et si le futur des RIAs était à Flex?

Autant vous le dire tout de suite, la session est "sponsorisé" par Adobe :o) mais sera l'occasion de voir de surprenantes démonstrations, de celles qui font imaginer de nouveaux patterns d'usabilité mais égalemnet d'apprendre quelques nouveautés de la prochaine mouture de Flex : Gumbo. - le rapprochement Designer/Développeur. Des initiatives comme Catalyst, un nouveau format de fichier qui permet d'exporter/importer des fichiers d'outils comme Photoshop ou Illustrator vers Flex - des améliorations de l'existant qui permettent de mieux séparer le code de logique de la définition du visuel; ie Spark Component Architecture. La définition du visuel peut se faire dans une sorte de fichier XML où l'on peut définir l'ensemble des comportements visuels des composants graphiques) - des améliorations du modèle d'animations qui permettent la 3D, l'ajout d'effets. Ces améliorations sont principalement possibles grâce aux évolutions de la plateforme d'exécution: le player Flash - le rapprochement de Spring, l'idée étant de faciliter l'intégration de plateforme type BlazeDS ou Lifecycle (pour son "presque équivalent" commercial) - la nouvelle version du Flex Builder qui outille le développement jusqu'à faciliter le binding de table sur des DataGrid.

Quelques sessions sur JEE6

Une présentation de JPA 2.0 qui s'enrichi par rapport à sa précédente version. - les options de mapping (nouvelles possibilités sur les jointures, PK...) - la gestion des locks optimistes ou pessimistes. Certaines APIs évoluent également et permettent de mutualiser des opérations comme la sélection de l'objet et son lock... - JP-QL reprend le principe des Criterias déjà présents dans Hibernate ou comment créer dynamiquement une requête

Et Web Beans qui cherche à standardiser Seam et cherche à proposer une couche de liant au dessus des composants déjà présents dans JEE (EJB, JSF Managed Bean...). L'idée principale reste de pouvoir agencer, l'ensemble de ces composants via des annotations spécifiques, le tout en masquant le composant Java; ie EJB, Java Bean, JSF Managed Bean. L'envie de standardisation va un peu plus loin en gérant les notions de scope (classiquement un scope session, request...) et en proposant des mécanismes - au final complexes - permettant de remplacer au déploiement les implémentations à utiliser.

C'est séduisant mais cela parait complexe...

Silverlight

Une assistance beaucoup moins nombreuse que pour la sesssion Flex. Pourtant ces deux sessions se sont beaucoup ressemblées : - des widgets graphiques impressionants comme le "deep zoom" - un fort accent sur la relation designer/développeur - des outils de dévéloppements productifs (Visual Studio ou eclipse pour les uns, Expression Blend ou la suite Adobe pour les autres) A noter : la possibilité d'utiliser un panel de langage de développement (C#, vb.NET ou ruby).

Un nouvel acronyme : le BDD ou Behaviour Driven Desgin (et non pas Business Driven Developpement :o) )

L'idée générale : "du TDD où le test est écrit via un DSL". Cette approche rejoint celle poussée par les méthodes agiles et le pilotage par les tests: décrire fonctionnellement le système avant même de savoir comment il sera implémenté. Il s'agit alors de décrire le test via un langage plutôt fonctionnel (Given, when, then) et d'y ajouter des closures (qui jouent le rôle de fixtures dans des solutions comme Greenpepper ou Fitnesse) permettant de s'interfacer avec le "System Under Test". De la même manière, les assertions disposent d'une sémantique plus riche du type shouldBe plutôt qu'un simple assertEquals.

C'est un peu le même principe que des Fitnesse et des GreenPepper; à l'exception du wiki et en imaginant que le code des fixtures est fusionné avec la description fonctionnelle du test.

Des patterns et anti-patterns REST

Une session intéressante qui repose les points importants de REST : 1) Tout à un identifiant matérialisé par une URI 2) Lier les ressources les unes aux autres 3) Utiliser les verbes GET/POST/PUT/DELETE et donc éviter le "tunneling" sur POST et GET 4) Une ressource peut avoir plusieurs représentation (en conservant l'URI) 5) L'architecture REST est par essence sans état (Stateless)

L'objectif principal étant d'utiliser au maximum les possibilités du protocole HTTP et les services offerts par l'infrastructure comme les mécanismes de cache, de proxy ou d'indexation par des moteurs de recherche par exemple. Une piqure de rappel pragmatique qui fait du bien sans attaquer SOAP.

Envers (sans jeu de mot) et le versionning d'objet

Un framework s'intégrant nativement à hibernate et permettant par annotation de versionner les objets et de réaliser en quelque sorte une piste d'audit (ajout de metadata). Il devient alors possible de requêter un objet dans une certaine version, de savoir qui a modifié quelle propriété : un SVN pour Hibernate ;-). Une limitation soulevée pendant la présentation reste l'augmentation des accès/écritures en base. A chaque modification, insertion de la version principale de l'objet, une insertion est réalisée pour conserver les modifications.

Voilà pour l'essentiel de la journée. Stay tuned!

By Fabrice Robini, Benoit Lafontaine, Olivier Mallassi