Devoxx France 2014 – troisième jour

Keynotes

J’ai moins apprécié les keynotes du vendredi que celles du jeudi, très certainement parce que je suis moins sensible aux sujets qui ont été abordés. Je suis cependant ravi de constater qu’il y a des gens qui s’occupent de former le commun des mortels à notre magnifique métier. Dans tous les cas, ça fait du bien à l’esprit d’entendre aussi des choses qui ne sont pas directement en relation avec la technique, même si c’est vrai qu’à Devoxx on aime vraiment ça !

Crazyflie: Développement d’un quadrirotor miniature opensource

Ma passion pour l’aéronautique m’a conduit à aller voir cette conférence. Le Crazyflie est un petit hélicoptère télécommandé qui vole grâce à 4 moteurs et 4 hélices. Le projet est entièrement open source, que ce soit pour la mécanique, l’électronique et tout le logiciel qu’il embarque, mais aussi les outils qui servent à le piloter et à s’interfacer avec lui.

Ce drone est de petite taille, il pèse seulement 19 grammes et a une autonomie d’une petite dizaine de minutes. Il est capable d’embarquer une charge utile de 5 à 10 grammes.

5 grammes c’est suffisant pour embarquer une petite caméra. La vidéo ci-dessous a été filmée par un Crazyflie avec une transmission analogique en streaming des images. Le drone a également été utilisé pour filmer l’entrée des gens dans la grande salle pour la keynote de la veille, mais je n’ai pas trouvé la vidéo.

En fait, ce drone est conçu pour être extensible. Il est destiné aux bidouilleurs. Sa capacité en charge utile lui permet d’embarquer du matériel, et côté électronique des ports d’extension sont disponibles pour venir brancher ce matériel.

Ce projet existe depuis quatre ans et il vole depuis deux ans. Il a été monté si j’ai bien suivi par une bande de copains, un peu de la même façon que se montent un bon nombre de projets open source en informatique.

Le Crazyflie est en vente à partir de 150$ si je me souviens bien, et de plus en plus de gens s’amusent à le modifier. La popularisation des téléphones portables a permis de faire chuter les prix de certaines pièces électroniques telles que les accéléromètres ou les caméras. Cela permet de réaliser des idées de plus en plus folles en se basant sur cet hélicoptère, le tout à un prix très abordable.

The Art of Parsing

Cette présentation sur l’art du parsage était effectuée par deux développeurs de SonarSource. Ils ont commencé par quelques rappels qui ne font pas de mal sur la définition d’une grammaire.

Ils ont ensuite parlé des différents types de parseurs et des grammaires qu’ils étaient en mesure de supporter.  Ce domaine-là n’est vraiment pas ma tasse de thé, je n’ai vraiment pas tout retenu. Mais je me souviens qu’il a expliqué que C++ est un langage très compliqué à parser. Un peu de troll ne fait pas de mal !

Ils ont également expliqué que, même si il existe un tas d’implémentations de parseurs génériques, peu de langages reposent sur des briques existantes. La plupart des langages ont leur propre parseur. Ce n’est pas que parce que les développeurs aiment le faire eux-mêmes, c’est surtout pour deux principales raisons :

  • C’est plus performant, et c’est important d’avoir un compilateur rapide (n’est-ce pas les gens qui font du C++ ou du scala ?)
  • Cela permet de gérer soi-même les messages d’erreur de manière à être aussi explicite que possible

Je retiens également de cette session une anecdote amusante. Le speaker expliquait que depuis Java 8 il y avait eu des changements importants sur la distribution de la grammaire du langage (voire-même elle n’est plus du tout distribuée, je ne sais plus exactement), et qu’il ne savait pas pourquoi. C’est alors que Rémi Forax s’est manifesté et a dit : “moi je sais, et c’est à cause de moi”. Le conférencier, ne sachant sans doute pas à qui il avait affaire, lui a dit d’en parler pendant les questions. Rémi a pris la parole pendant les questions et a expliqué un certain nombre de choses et notamment que la grammaire distribuée était fausse depuis Java 1.2. Il a également précisé que Java 8 a complexifié la grammaire du langage car les lambdas nécessitent parfois de lire un nombre infini de caractères en avance (je ne me souviens plus du terme savant qui signifie cela) pour lever les ambiguïtés. Sacré Rémi !

La puissance de mon monoïde est supérieure à 9000

Je ne connaissais pas le terme monoïde, c’est la raison pour laquelle je suis allé à cette session de 15 minutes. Encore une fois, il s’agit d’un nom barbare de mathématiciens qui exprime quelque chose d’assez simple.

Les monoïdes sont tout simplement des ensembles de données sur lesquels on a une fonction qui prend deux paramètres du même type et les fusionne pour en retourner qu’un seul. Elle doit être associative, c’est-à-dire que si on inverse les paramètres d’entrée, la valeur de retour ne change pas. Il faut également un élément neutre dans cet ensemble, c’est à dire un élément qui, combiné à un autre donne cet autre élément.

La fonction addition et l’ensemble des nombres entiers forment un exemple simple de monoïde, l’élément neutre est alors 0.

Les monoïdes sont très utiles pour la programmation fonctionnelle et en particulier pour les opérations de réduction d’une collection, c’est-à-dire de passer d’un ensemble d’éléments à un seul. Lorsqu’une réduction est appliquée à un monoïde, les calculs peuvent être parallélisés sans limite et c’est très important lorsqu’on travaille sur des grands nombres d’éléments.

Ces petits rappels théoriques ne font pas de mal avec la démocratisation de la programmation fonctionnelle. Ils complétaient bien ce qu’avait expliqué José Paumard dans sa présentation de l’API stream le mercredi.

Pourquoi vous devriez essayer sérieusement les Object Calisthenics

Ce nom un peu barbare ne m’avait pas vraiment attiré au premier abord, mais la description de la session m’a convaincu d’y aller. En effet, il s’agit finalement de faire du beau code, d’appliquer enfin sérieusement toutes les bonnes pratiques. Du clean code poussé à l’extrême ! Il n’en fallait pas plus pour m’attirer.

Parmi les 9 règles qu’il a proposées, il y en a que je respecte assez souvent (comme un seul if par méthode, pas de else) et d’autres pas vraiment (aucun getter dans le code, un seul point par ligne). Comme il l’a expliqué, il vaut mieux s’amuser à appliquer toutes ces règles avec un petit projet tout seul dans son coin pour s’y faire. Il conseille d’y passer au moins 20 heures pour maîtriser le sujet et y voir de réels bénéfices.

Je suis assez convaincu de l’utilité de toutes ces règles, mais je ne pense pas qu’il soit envisageable d’imposer ces contraintes à tout une équipe. C’est à mon sens trop contraignant, même si ça permet de faire du vrai beau code. Il faudra que j’essaie sur un petit projet pour me faire mon idée sur le sujet.

Ceylon d‘ici à l‘infini : tour d‘horizon et le futur

J’ai hésité à assister à cette session et j’y suis finalement plus allé pour accompagner mon copain Loïc, parce qu’il contribue à ce langage et notamment à son système de build.

Ceylon c’est un peu le langage idéal, une sorte de Java sans ses défauts. J’avais peur de ne pas apprendre grand chose parce que je connaissais déjà pas mal le langage, mais Stéphane Epardaud n’a pas vraiment parlé du langage en lui-même, mais plutôt des outils, du SDK et des quelques frameworks qui existent déjà, et notamment de Cayla. Vu que Ceylon peut être compilé en Javascript, ce framework permet d’écrire son application web intégralement en Ceylon. Il est basé plus ou moins sur le même principe qu’AngularJS.

Finalement j’ai bien fait d’y aller car j’ai découvert des nouvelles choses qui sont en train d’émerger dans l’écosystème Ceylon.

Se plugger dans le compilateur Java

Je connais depuis longtemps l’existence du mécanisme d’annotation processing qui permet de générer du code à la compilation. Étant curieux de savoir comment ça fonctionne tout en n’ayant jamais pris le temps de me plonger dedans, j’ai saisi l’opportunité de découvrir ce puissant système.

La présentation était faite par un ingénieur de Google qui travaille sur ses 20 % de temps libre sur le projet Google Auto qui est en fait un ensemble d’outils basés sur ce principe qui permettent d’adresser certains problèmes de manière élégante.

Il s’est servi de Auto Value, un des composants de Google Auto, qui permet de créer des objets immuables en quelques lignes, pour montrer ce qu’on peut faire avec cette technique.

Il a également parlé de Dagger, qui est un outil d’injection de dépendances créé par ceux qui ont à l’origine lancé Guice. Il a expliqué pendant au moins un quart d’heure l’injection de dépendances, et j’aurais personnellement préféré qu’il passe ce temps à approfondir un peu le sujet d’origine, j’espère que ça aura permis à ceux qui ne savaient pas ce que c’est de le découvrir. Contrairement à Guice qui fonctionne au runtime, Dagger effectue la résolution de l’injection à la compilation grâce à l’annotation processing. L’intérêt principal est d’avoir une résolution statique et donc des erreurs à la compilation plutôt qu’au runtime, ce qui arrive régulièrement avec Guice. Par contre Dagger ne supporte pas toutes les fonctionnalités que supporte Guice.

Il a insisté sur le fait que les IDE prennent entièrement en charge l’annotation processing. Je me suis alors demandé pourquoi lombok (bibliothèque similaire à Auto Value) nécessitait d’installer une extension dans l’IDE. Je pense avoir trouvé la réponse ici, il semblerait que lombok utilise de la tambouille complexe pour modifier la classe annotée, alors qu’Auto Value génère une sous classe de la classe annotée, et lombok va visiblement au delà de ce que les IDE supportent.

50 nouvelles choses que l’on peut faire avec Java 8

Il faut croire que je n’avais pas eu assez des 6 heures d’université du mercredi sur Java 8. Me voilà reparti avec José Paumard qui nous présente des nouveautés autres que l’API stream. Décidément, José connaît cette nouvelle version de Java comme sa poche, et sa présentation était très intéressante !

L’apparition des lambdas ouvre une grande porte vers la programmation fonctionnelle. L’API stream s’appuie intégralement sur ces concepts, mais l’ensemble du JDK n’est pas non plus en reste, il a été enrichi de manière à simplifier la vie du développeur en s’appuyant encore une fois sur les lambdas. J’ai retenu par exemple l’arrivée de CompletableFuture qui permet de déléguer au JDK la parallélisation d’opérations et d’attendre par exemple que toutes les opérations soient terminées, ou encore qu’une seule le soit (dans le cas où on envoie une requête à plusieurs serveurs et on prend juste le plus rapide).

En dehors de l’aspect programmation fonctionnelle, on peut citer d’autres choses comme l’arrivée de l’API time qui permet enfin la manipulation simple et native de dates, heures et fuseaux horaires.

Java 8 est décidément une vraie révolution du langage, et j’ai vraiment envie de m’y mettre dès que possible, et je pense que je ne suis pas le seul…

Extremist Programming : l’art de s’amuser avec du code

Ambiance détendue dans cette session. Il s’agissait véritablement d’un sketch. En se basant sur le constat que certaines innovations étaient accidentelles, ils nous ont encouragé à essayer des choses bizarres, même quand on a l’impression que ça ne fonctionnera pas. Comme ils l’ont expliqué, au mieux on trouve quelque chose d’intéressant, au pire on aura appris qu’il ne faut pas faire cela.

Ils ont parlé par exemple de Brainfuck ou de whitespace qui ont au moins pour intérêt de montrer que c’est important d’utiliser un langage simple. Certaines blagues se glissaient dans leur présentation, comme la suggestion aux développeurs C d’appeler certaines variables u pour pouvoir avoir malloc(u).

Ils ont également proposé d’essayer de faire du pair programming à 6, ou alors d’essayer de pair programmer sans se parler, en communiquant uniquement avec le code. Bien entendu, on sait que la productivité ne sera pas à son maximum, mais c’est une expérience qui permet sans doute d’apprendre à mieux communiquer.

Ils ont lancé un compte Twitter (weirddev) qui propose tous les jours une idée débile pour les développeurs.

Les Cast Codeurs reviennent et ils ne sont pas contents !

Toute l’équipe de cet incontournable podcast de développement français était présente, ils étaient déguisés avec leurs marinières et leurs bérets rouges.

Les Cast Codeurs en direct
Les Cast Codeurs en direct

L’ambiance était excellente. Atlassian avait offert les bières. Antonio était visiblement très fatigué après ces trois jours d’organisation de Devoxx puisqu’il parlait dans sa bière au lieu du micro. En revanche, Guillaume était en pleine forme et fidèle à lui-même avec ses blagues habituelles. Emmanuel était visiblement toujours blasé de ne pas avoir pu présenter une session à Devoxx.

Ils ont mangé un gâteau pour fêter le centième épisode, et ils ont allumé les bougies juste en dessous des capteurs de fumée. Ils ont expliqué qu’il était prévu à l’origine de faire le centième épisode à Devoxx mais que l’épisode avec Tariq Krim, assez fortement lié à l’actualité, est finalement passé devant Devoxx. C’était donc l’épisode 101.

Ils (et particulièrement Emmanuel) ont fait leurs retours sur ce qu’ils ont vu à Devoxx. Antonio a de son côté parlé de l’organisation et des coulisses. Il a remercié tous les pull rouges qui ont abattu un travail formidable. Et moi aussi je les remercie encore une fois.

L’épisode 101 des Cast Codeurs en direct de Devoxx est désormais en ligne.

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.