.
I. Les keynotes d'ouverture▲
Le premier jour lors de la keynote d'introduction, Antonio Goncalves nous confiait que l'orientation voulue pour ce Devoxx était « passé, présent et futur ». En ce qui concerne le passé on peut dire que nous sommes entrés de plein pied dedans avec la conférence de Clarisse Herrenschmidt sur l'histoire des écritures.
En prenant le parti de commencer cette journée par une conférence à mille lieues du domaine informatique, les organisateurs font un choix audacieux mais payant si on en juge par la standing ovation qui se déclencha à la fin de la présentation. Le ton universitaire du propos aura certainement rebuté les plus virulents mais pour ma part je salue ce choix. Une telle conférence est la preuve d'une ouverture d'esprit assez rare dans notre communauté qui a tendance à vivre en vase clos et constitue finalement une parenthèse assez rafraîchissante. J'en viendrais presque à plaindre Martin Odersky avec sa keynote « Objects and functions, conflict without a cause ? » qui fut pour le coup quasiment éclipsée malgré un propos de grande qualité et empreint de beaucoup de réalisme quand au soi-disant conflit opposant la programmation orientée objet et la programmation fonctionnelle.
Dans la même lignée la première keynote du vendredi intitulée « Normal ou décaféiné ? » et animée par Alexis Moussine-Pouchkine m'a permis de découvrir un autre speaker de qualité dont le ton posé et la clarté des explications mettaient avantageusement en valeur ses idées. La seule ombre au tableau pendant ces keynotes fut peut-être l'intervention d'Habib Guergachi doctement intitulée « Web Oriented Architecture, une transmutation des pratiques de construction des SI ». Je ne m'étendrai pas sur le contenu mais à mon sens trop faire d'effets de manche ne parvient qu'à diluer la force du message que l'on souhaite faire passer. Et ce fut le cas ici. Mais entrons maintenant dans le vif du sujet avec les conférences du jeudi et du vendredi.
II. Les conférences▲
Une fois les keynotes (et le petit déjeuner) digérées j'attaque ma première journée de conférences
II-A. FLATMAP ZAT SHIT : les monades expliquées aux geeks.▲
Auteur : François Sarradin (@fsarradin)
Je l'avoue je suis un parfait novice du Scala et c'est volontairement que je choisis une présentation très orientée technique. En effet pourquoi aller au Devoxx si ce n'est pour se faire un peu remuer les méninges ?
Hé bien non, à force d'exemples très concrets et bien documentés François arrive à nous présenter des fonctionnalités avancées et pousse même le vice à coder l'équivalent en Java 8 (de manière beaucoup moins élégante et tout en restant impartial).
Bref une présentation sans prétention ni fioritures mais qui donne simplement envie de coder, il n'en fallait pas plus pour bien commencer la journée.
II-B. Architecting for Continuous Delivery▲
Auteur : Axel Fontaine (@axelfontaine)
Contrairement à la conférence précédente, le processus de Continous Delivery ne m'est pas étranger car je le pratique au quotidien depuis plus d'un an à présent et qu'au précédent Devoxx je m'étais déjà fait l'écho d'une présentation un peu similaire disponible ici ([Devoxx FR 2012] - import continuous.delivery.*). Notre speaker, Axel Fontaine, nous délivre un message plein de bon sens au sein d'une présentation claire dans laquelle de vraies solutions techniques sont abordées. Pour en savoir un peu (voire beaucoup) plus je vous invite à lire mon compte-rendu plus détaillé sur ce même blog.
Au final une très bonne présentation qui nous rappelle que notre responsabilité de développeur ne s'arrête pas après avoir packagé son livrable. Il y a donc une vie après la release !!
II-C. Boucles étranges : étranges boucles (puzzlers et curiosités)▲
Auteurs : Eric Lefevre-Ardant (@elefevre) et Guillaume Tardif (@gtardif)
Parfois au détour d'un trou dans son emploi du temps, il arrive que l'on tombe sur une conférence un peu décalée et sortant des sentiers battus. Ce fut le cas avec cette intervention orchestrée par Eric Lefevre-Ardant et Guillaume Tardif. Une conférence que je qualifierais de cabinet de curiosités tel qu'on pouvait l'imaginer au XXe siècle. La plupart des lignes de code exposées pendant cette heure auraient été dignes de figurer dans les annales pour recruteurs techniques vicieux.
Néanmoins, au-delà de ces casse-tête et autres bizarreries qui sont plus du folklore qu'autre chose, nos deux orateurs orientent subtilement leurs propos vers les conséquences d'un code qui pourrait se répliquer et de ce que cela entraînerait notamment au niveau du compilateur. On rentre alors dans le domaine des quines, des petites choses assez fascinantes mais pouvant faire de gros dégâts si utilisées à mauvais escient.
Quelques liens pour en savoir plus sur ces objets.
- Définition des quines, Wikipédia : http://en.wikipedia.or/wiki/Quine_%28computing%29
- Des exemples de quines : http://research.swtch.com/zip
- Reflections on Trusting Trust by Ken Thompson : http://cm.bell-labs.com/who/ken/trust.html
II-D. The adventurous Developper's guide to JVM laguages▲
Auteur : Simon Maple (@sjmaple)
Ma première journée se termine par une conférence animée par Simon Maple et se voulant un tour d'horizon rapide des langages alternatifs utilisant la JVM.
Le constat de départ est assez simple selon Simon. Depuis 2010 nous assistons à la prolifération des langages alternatifs sur la JVM. Pourquoi ? Principalement parce que l'écosystème gravitant autour de la JVM est aujourd'hui très mature (près de 20 ans d'existence), qu'il fournit un grand nombre de services de manière native (Garbage Collector pour ne pas le nommer) et qu'il est finalement bien plus facile aujourd'hui de développer un langage. Néanmoins cette multiplication ne vient pas sans risques. Simon identifie principalement les obstacles suivants :
- Une dilution de la communauté : Plus de langages, moins de temps pour les maîtriser, phénomène de zapping.
- Un support de moins en moins important : Beaucoup d'initiatives individuelles, reposant sur une équipe réduite de développeurs/mainteneurs quand ce n'est pas sur une seule et unique personne.
- Un ralentissement de l'innovation : Chaque langage tend à reprendre les bonnes idées des autres mais peu de grosses nouveautés entre les versions.
- Une visibilité réduite et apparition d'un cimetière des langages : Concurrence forte entre les langages, les moins pérennes se verront rapidement abandonnés.
Grâce à cette diversité il existera forcément un langage dynamique adapté à vos besoins. Néanmoins il faut inciter à un peu de prudence en soulignant que ce monde est encore vert. Certes, l'exploration et l'expérimentation sont motivantes. De même, garder un côté aventurier et à la pointe apporte son lot de satisfaction mais de grâce ne vous débarrassez pas trop vite de votre sens critique. Et s'il ne fallait retenir qu'une chose c'est bien qu'on ne sait jamais ce que l'avenir informatique nous réserve…
II-E. Du javascript propre ? Challenge accepted !▲
Auteurs : Julien Jakubowski (@jak78) et Romain Linsolas (@romaintaz)
En tant que développeur Java pur jus, le JavaScript a toujours été ma bête noire même si la situation s'améliore d'année en année. Pour s'en convaincre je vous laisse lire ce billet qui dévoile les solutions possibles pour faire en sorte que coder en JavaScript ne soit plus un chemin de croix mais presque (et j'insiste sur le presque) une agréable randonnée.
II-F. What I want in Java 9▲
Auteur : Rémi Forax
Que dire de cette conférence ? Ne connaissant pas Rémi Forax je découvre avec étonnement une fusion très improbable entre le professeur Tournesol, le docteur Frankenstein et le Schtroumpf Grognon. Mais bizarrement ce cocktail insolite fonctionne bien voire même très bien. Après avoir présenté les différentes avancées de Java 8 auxquelles il a collaboré, Rémi nous expose son point de vue assez particulier sur la stack de Java EE.
Pour résumer un certain nombre de techniques soi-disant réservées aux langages dynamiques existent déjà dans la JVM sans que personne ne s'en rende compte. Au niveau des spécifications un principe de modularité existe et permettrait de se détacher de l'utilisation de tel ou tel container. Malheureusement les implémentations telles que nous les connaissons aujourd'hui (dans Spring, Hibernate, Tomcat ou JBoss par exemple) ne permettent pas une telle souplesse. La simple observation à partir du debugger ou du bytecode généré fait ressortir l'emploi massif à des proxys ou a du code enrichi à l'exécution. En déplaçant cette responsabilité du côté du compilateur (qui en a théoriquement les capacités) on augmenterait de facto les performances en éliminant les phases de recherche des beans, de création des proxys et de création du bytecode.
Devant ce tableau presque idyllique on se demande alors pourquoi rien n'a été mis en place. À cette question, Rémi voit plusieurs réponses :
- des questions sémantiques et un travail sur le langage devrait être fait en amont ce qui pose certains problèmes de rétrocompatibilité. Un obstacle important mais pas forcément le plus insurmontable ;
- un besoin d'ouverture beaucoup plus important pour comprendre et étudier les mécanismes de la stack Java EE. Ce qui ne va pas forcément dans le sens d'Oracle qui finalement n'a ouvert que certains pans de la JVM.
- un manque de volonté au niveau des instances directrices du JCP et finalement peu de pression de la part des développeurs qui ne sont pas au fait de cette problématique.
Finalement en sortant de cette conférence je comprends pourquoi Rémi avait fini sur le podium officieux des meilleurs conférenciers de la session 2012. Pour ce qui me concerne le message fut très clair, il est grand temps de faire du lobbying envers Oracle.
II-G. Challenging the myths and folklore in developping high-performance systems▲
Auteur : Martin Thompson (@mjpt777)
Ma dernière conférence pour cette année fut un peu l'écho de la première car je décidais encore une fois d'assister à un talk très technique (en anglais qui plus est). Au programme de cette session Martin nous a présenté dix « lieux communs » sur les performances informatiques qui reviennent nous hanter à intervalles plus ou moins réguliers.
Le but de Martin n'était pas tant de faire la liste la plus représentative possible mais plutôt de nous faire réfléchir sur les points communs de ces fausses affirmations. Or dans chacun des cas exposés la propagation de ces rumeurs repose uniquement sur l'absence d'expérimentation (par soi ou par autrui). La question à se poser est pourtant relativement simple : « Quelle expérience mettriez-vous en place pour prouver cette affirmation ? ». Et c'est ce qu'a fait Martin item après item. Qu'obtient-on au final ? Que seuls les tests de performance permettent d'identifier les vrais goulots d'étranglement et que les recettes miracle entendues de-ci de-là ne mènent nulle part tant que ces dernières n'ont pas été jaugées par vous-même dans votre cas particulier.
III. Que retenir de ce Devoxx FR 2013 ?▲
Dans ma vision des choses les conférences comme le Devoxx servent surtout d'étalon pour détecter l'émergence de telle ou telle techno car on y rencontre des vrais utilisateurs. Bien sûr avec la densité d'informaticiens au mètre carré vous risquez de tomber sur le 1% de la population utilisant le framework « bidule » même pas encore en version alpha mais une fois ces interférences filtrées et après avoir recoupé avec les résultats de votre propre veille technologique, le Devoxx reste un indicateur de tendances fiable.
En effet, après une édition 2012 à l'orientation « web » beaucoup plus marquée, j'ai senti que cette édition 2013 se concentrait beaucoup plus sur l'écosystème Java. Le choix des conférences auxquelles j'ai assisté n'est bien sûr pas anodin dans ce ressenti global mais ce retour aux basiques correspondait bien à ce que j'attendais du Devoxx cette année.
Mais attention, retour aux basiques ne veut pas dire revenir sur de vielles technos. Pour s'en convaincre il suffisait de compter le nombre de conférences dédiées aux langages dynamiques et/ou aux langages alternatifs tournant sur la JVM. Ces derniers ont été fortement mis en avant lors de ce Devoxx et ce qui n'était qu'une tendance fébrile il y a encore un an se transforme petit à petit en vraie lame de fond. Certes, la révolution n'est peut-être pas encore pour demain mais rien n'empêche de s'y préparer dès maintenant. Néanmoins à plus long terme des conférences comme celles de Rémi Forax laissent entrevoir un futur un peu plus lointain mais finalement assez enthousiasmant.
En attendant que tout cela devienne réalité je vous laisse, j'ai du Scala à potasser.
Cet article a été publié avec l'aimable autorisation de la société SoatSoat.
Nous tenons à remercier f-leb pour sa relecture orthographique attentive de cet article et Keulkeul pour la mise au gabarit.