Vincent Ferries bio photo

Vincent Ferries

Apprenti artisan logiciel polyglotte

CV Email Twitter Github

Autant le dire tout de suite, Devoxx France est un évènement pour le moins enrichissant. La soif de connaissance et l’envie de partager des participants y est palpable, et on y apprend certainement plus en deux ou trois jours qu’en de nombreuses heures de R&D personnelle. Venu de Toulouse pour l’occasion, je n’ai pas été déçu du voyage !

Une meilleure diffusion de la connaissance

Dès la keynote d’ouverture, nous avons appris que l’intégralité des sessions enregistrées à Devoxx France seraient disponibles sur Parleys sur la chaîne dédiée sur laquelle les vidéos des différentes présentations seront ajoutées prochainement. Je vous encourage vivement à aller voir celles dont les sujets vous intéressent le plus (et accessoirement celles du Toulouse JUG que vous auriez pu rater). Avec la Google I/O qui approche mi-mai, ça risque en effet de faire beaucoup de choses à regarder, mais je vous assure, ça vaut vraiment le coup. Je vais essayer de vous détailler un peu ici les sujets ou présentations qui m’ont le plus marqué lors de la conférence. Pour moi ses 3 axes principaux pour cette année concernaient la programmation fonctionnelle (jdk8 et Scala), le JavaScript, et les visions du futur pour Java. Je vais essayer ici de reprendre un peu ces trois aspects. Chaque conférence aurait pu faire l’objet d’une présentation détaillée vu le niveau des intervenants, mais il faut bien faire des choix! Je n’ai malheureusement pas pu voir la présentation sur Java EE 7 par Arun Gupta que j’attendais beaucoup, je me rattraperai lors de la diffusion des vidéos.

What every Hipster should know about functionnal programming

Je dois saluer ici les qualités d’oratrice de Bodil Stokke et son énorme travail de préparation, qui a accessoirement donné deux conférences dans cette édition de Devoxx. Pour ceux qui ne la connaitraient pas, elle s’est illustrée notamment grâce à sa célèbre théorie : “Facial hair theory of programming language design”. Je vous conseille vivement d’aller y jeter un oeil. Cette conférence ayant déjà été donnée lors de JFokus, vous pouvez dores et déjà aller la voir.

Le titre évoque bien le contenu de la présentation. Elle s’est évertuée à vulgariser tous les mots barbares utilisés par ceux qui font de la programmation fonctionnelle. Sans être exhaustif, je sais maintenant mieux ce que sont les “functors”, “combinators” mais aussi les triples de Kleiski, la curryfication et les monades.

La présentation a consisté en un live coding en TypeScript, juste du JavaScript typé, de tous ces mots barbares sur fond de “My Little Poney” (thème récurrent à Devoxx cette année). Elle constitue une excellente piqûre de rappel de nombre d’aspects de la programmation fonctionnelle dont le map/reduce notamment à l’origine de bon nombre de moteurs Big Data que nous utilisons actuellement.

Les présentations autour de la programmation fonctionnelle devaient représenter un bon quart des conférences si on prend en compte Scala, la programmation fonctionnelle en tant que tel et qu’on ajoute une touche de Ceylon et du JDK8. Il y a de bonnes chances qu’on en croise de plus en plus dans le mode du développement logiciel durant les mois et années à suivre.

Du JavaScript propre ?

Voilà une question que je me pose depuis pas mal de temps. Je me penche réellement sur JavaScript depuis peu et n’ai jusqu’à présent abordé que les grands classiques tels que jQuery notamment.

J’ai vite compris la puissance cachée derrière ce vieux langage mal compris, ainsi que ses faiblesses (WAT ?), notamment au niveau de la lisibilité et capacité à être maintenu. Au vu des avancées des navigateurs (performances x20 notamment), JavaScript est désormais vraiment devenu une arme plus qu’intéressante. Si en plus on l’associe aux fonctionnalités offertes par HTML5, on obtient vraiment un outil puissant pour faire des sites flexibles rapidement.

Cependant, comment s’y retrouver dans un gros projet JavaScript? Comment le garder maintenable au fil du temps? C’est la questions à laquelle ont répondu Julien Jakubowski et Romain Linsolas.

Tout d’abord, s’il y a un livre à avoir dans sa bibliothèque sur JavaScript, il s’agit de JavaScript : The Good Parts. Ensuite, pour contourner le problème, vous pouvez vous tourner vers CoffeeScript ou Dart, mais ce n’était pas l’approche abordée ici. A la place, les orateurs ont proposé une myriade d’outils afin de faciliter la maintenance de gros projets :

  • Angular, Backbone et Ember afin de déporter le MVC côté client
  • Asynchronous Module Definition (AMD) tel que require.js pour aider à modulariser le code
  • JSLint (équivalent de checkstyle et PMD) afin de trouver des erreurs fréquentes
  • jQuery pour rendre plus lisible les parcours du DOM
  • Mustache.js pour le templating (handlebars + underscore)
  • Pour les tests d’intégration, l’indétrônable Selenium ou Windmill
  • Pour vos tests unitaires : Jasmine (+CoffeScript?), QUnit, Mocha
  • Karma, PhantomJS, Casper…
  • build maven + jenkins + Sonar pour automatiser les tests
  • Yeoman (Yo pour le scaffolding, Grunt comme task launcher et Bower pour la gestion des dépendances)

Autant dire que les outils et les solutions sont nombreux! Cependant, il est facile de se perdre dans une telle effervescence, des frameworks JavaScript sortent tous les mois. En résumé, utilisez du MV*, modularisez votre code, évitez les “parties sales” de JavaScript, mettez en place des tests et automatisez vos tests, déploiement etc.

What I want in Java 9

Autant le dire tout de suite, cette session est celle qui a le plus piqué ma curiosité au vif. Je ne vais pas ici vous décrire ce que sera Java 9, il y a cependant déjà des choses prévues (Jigsaw, l’Arlésienne des JDKs?) auxquelles je m’attaquerai dans un prochain post. Je vais plutôt essayer de retranscrire ici ce que j’ai compris et ce qui m’a plu de la vision de Rémi Forax. A l’origine était invokedynamic, ou du moins depuis le JDK7, vous savez le truc utilisé par à peu près tous les langages de programmation basés sur la JVM sauf Java pour augmenter de façon drastique leurs performances. Le principe est simple : noms et typages symboliques à la compilation. On référence ensuite des pointeurs de fonction au moment des appels et on gagne énormément en performances pour les langages dynamiques. Je ne vais pas m’étaler dessus, ce n’est pas là le fond de notre problème, le truc important est que ça permet de comprendre un peu que la JVM gère déjà des choses (du moins des langages) dynamiques. La réflexion qui en découle consiste en une phrase : “Pourquoi ne pas utiliser aussi ça depuis Java?” On se retrouve enfermés depuis un moment dans des frameworks complexes pour gérer l’inversion de contrôle, nous obligeant à écrire des proxys pour appliquer nos concepts d’AOP, d’injection de dépendances et j’en passe. Du coup, on se trimballe dans la JVM à la fois la classe et la définition de son proxy, qui embarque toutes ses méthodes notamment. De plus, Java EE définit des services que doivent fournir les conteneurs de nos serveurs d’application avec les problèmes de compatibilités inter conteneurs qu’on leur connait.

Selon notre cher conférencier, il y aurait un moyen d’unir ces deux mondes de Java SE et Jave EE qui ne se sont plus beaucoup parlé depuis un petit moment. Pour cela, il propose un nouveau mot clé dans le langage Java : interceptable. Ce mot clé magique permettrait de définir qu’une classe peut être interceptée, écoutée. La JVM se chargerait ensuite simplement d’appeler les intercepteurs enregistrés. Je n’ai malheureusement pas toutes les informations nécessaires pour rentrer plus dans le détail, mais à priori, cette amélioration du langage ne demanderait que relativement peu de développement dans javac et permettrait entre autres choses :

  • De ne plus avoir besoin d’autant de boxing et des stack traces toute pourries!
  • De baisser fortement le coût d’entrée des technos Java EE
  • D’utiliser simplement des concepts avancés disponibles sous Java EE en Java SE

Il proposait aussi un mot clé ghost qui permettrait que le typage soit connu par le compilateur mais pas par la VM (dans un souci de gain de performance je présume).

Apparemment, il cherchait du monde pour faire pression avec lui pour qu’Oracle écoute ses dires, je manque de précisions à ce sujet, mais si on me dit où, je signe de suite!

Au final, Devoxx a été pour moi une expérience très enrichissante. C’est vraiment le genre d’évènement qui vous redonne la foi dans votre métier et vous rappelle pourquoi vous vous levez tous les matins, pas juste pour vous nourrir, mais parce que vous faites un boulot qui vous plait. Vivement l’année prochaine! D’ici là, n’hésitez pas à demander des précisions ou à me compléter si vous avez des informations supplémentaires !