Retour sur la conférence Devoxx France 2016 par les membres de l'équipe Java de Developpez.com

J'attaque fort avec une université, session de trois heures animée par Cyrille Martaire et Romeu Moura sur le Property-Based Testing. J'avais déjà eu un avant-goût de ScalaCheck lors du cours sur la programmation réactive que j'avais suivi sur Coursera. Je vous conseille d'ailleurs de le suivre, même si je l'ai trouvé beaucoup moins bien fait que son précurseur sur la programmation fonctionnelle.

Le but c'est de se rajouter un harnais de sécurité supplémentaire en vérifiant des propriétés mathématiques qui doivent toujours rester vraies dans notre système. Par exemple, on peut vouloir tester que a + b >= a si a et b positifs. Le système va alors faire des tests avec des valeurs aléatoires et vérifier que l'assertion reste vraie. Dans le cas précédent, il vous remontera par exemple les buffers overflow avec des entiers trop grands. Dur de penser à toutes les considérations techniques alors qu'on doit déjà se confronter à des règles de gestion métier compliquées. On peut exprimer des exceptions et/ou des préconditions pour nos différentes règles. En général, les bibliothèques utilisent « assumeTrue ».

Il y a quand même une chose à laquelle il faut faire particulièrement attention, le test ne doit pas être la même chose que ce qu'on cherche à tester, mais une version bien plus épurée. Tester que a = a n'a aucun intérêt.

Le concept a été introduit par John Hugues avec QuickCheck en Haskell et a fait des petits dans pas mal d'autres langages :

• ScalaCheck en Scala ;
• JUnit QuickChecker ;
• FSCheck en F# ;
• test.check en Clojure.

Les meilleures bibliothèques en plus de lancer ces tests aléatoires font du shrinking une fois des erreurs trouvées. Elles cherchent à réduire à leur plus simple expression les paramètres aléatoires utilisés pour tester, par exemple la chaîne de caractères la plus courte pour passer en erreur, la valeur la plus simple. Cela permet de comprendre ensuite l'erreur beaucoup plus facilement.

Le conseil de la fin : faites vous-même vos propres fuzzers, c'est le meilleur moyen d'assimiler le concept.

La vidéo de cette université est présentée ci-dessous :

Thierry étant très intéressé par Vert.x, j'étais emballé par ce hands-on. La séance durait 3 heures, mais j'en ai consacré une à télécharger des dépendances et des images Docker (wifi très vite saturé) ainsi qu'à installer ledit Docker. C'est dommage que la description du hands-on labs n'indiquait pas les prérequis. Ça aurait permis de les installer à l'avance, d'autant que Docker n'est absolument pas indispensable pour découvrir Vert.x. Il est vrai, cependant, que ça apportait un (gros) plus.

L'objectif de la séance était de suivre le tutoriel conçu par l'équipe et de poser des questions aux gentils organisateurs. Ce tutoriel était vraiment intéressant, mais un peu long. Je vais donc le finir à la maison. Dans les grandes lignes, on a utilisé Vert.x pour mettre en œuvre un web service.

vertx.createHttpServer()
    .requestHandler(request -> {...})
    .listen(port, resultHandler);

Celui-ci devait discuter avec d'autres verticles via l'event bus :

vertx.eventBus().publish("some adress", "msg in json");

D'autres verticles lancent des consommateurs pour écouter sur cette adresse :

vertx.eventBus().<JsonObject> consumer("some address", message -> {
        JsonObject body = message.body();
        String quote = body.getString("name");

Notez qu'il est également très simple de lancer un serveur à l'aide de Vert.x :

vertx.createHttpServer().requestHandler(request -> {

    HttpServerResponse response = request.response().putHeader("content-type", "application/json");

    response.end("some html");

}).listen(8080, ar -> {
    if (ar.succeeded()) {
        System.out.println("Server started");
    } else {
        System.out.println("Cannot start the server: " + ar.cause());
    }
});

La présentation de Vert.x, quant à elle, s'est limitée à une description très succincte de l'emploi de l'event loop. Connaissant déjà un peu Vert.x et Docker, j'ai réussi à m'en sortir, mais j'ai bien vu que c'était loin d'être le cas pour tout le monde. C'est vrai qu'on a vite tendance à confondre conférences et Hands on Labs…

Mickaël : je me suis inscrit à cet atelier, car je souhaitais découvrir Vert.x. En effet à par les tutoriels de Thierry, je suis novice dans cette technologie. Malheureusement cet atelier s'adressait à des gens ayant déjà des connaissances en Vert.x et l'objectif était de montrer comment utiliser Vert.x dans une architecture microservice. L'eventbus a ici toute sa finalité, car il va pouvoir faire la communication entre les différents microservices qui sont alors décrits dans des programmes en Vert.x sur des conteneurs différents. Comme le précise Thierry, une bonne heure a été consacrée à la préparation des machines des participants. Dommage en effet que les prérequis logiciels n'étaient pas indiqués. À noter que j'ai testé avec succès les étapes de l'atelier avec Docker 4 Mac Beta. Je pense refaire l'atelier une fois les concepts Vert.x bien appréhendés.

Vous pouvez retrouver la page des ressources de l'atelier : http://vertx-lab.dynamis-technologies.com/

Je vais passer un peu plus vite sur cette session parce qu'il s'agissait en fait d'un atelier et que c'est plus difficile à retranscrire. Cependant, Igor et Laurent ont vraiment fait du bon boulot, tout était clair et bien construit. J'ai découvert SparkJava, à ne pas confondre avec le Spark d'Apache, que je ne connaissais pas et qui ressemble un peu à FluentHttp dans l'idée. Très facile de développer un microservice avec, je vois déjà une ou deux applications où il va venir s'intégrer bien vite.

Pour consommer ces microservices, on a ensuite utilisé Feign, le client http de Netflix. Les concepts sont assez similaires à ceux que j'utilise souvent côté Android avec Retrofit, de Square cette fois. Visiblement, un petit combat sera organisé bientôt à Toulouse entre les deux bibliothèques.

Vous pouvez retrouver la page des ressources de l'atelier : https://ilaborie.org/DevoxxFR/

Les transparents de l'atelier sont présentés ci-dessous :

Un tutoriel en français sous la forme d'un workshop, clair, étape par étape, avec des propositions de solutions à chaque étape. Les orateurs ont bien expliqué les enjeux. Les orateurs ont pris le temps de répondre aux questions, même à celles qui débordaient du sujet. Les orateurs ont indiqué les dépendances nécessaires une demi-heure avant le début de la séance, ce qui a permis de les télécharger et de tout installer avant le début de la séance. Et si vous connaissez un peu les stacks JavaScript, vous savez que ce n'est pas une mince affaire de tout préparer. En ce qui me concerne, je la connaissais de loin et j'ai pris une sacrée claque…

Durant la séance, on a donc codé une application web entière, à travers plusieurs étapes, incluant les tests et les refactos. J'ai surtout retenu comment organiser les composants et leurs responsabilités, notamment à l'aide de composants dumbs :

const Regions = React.createClass({
  render () {
    return (
      <div>
        { this.props.regions.map(region => <div key={region}>{region}</div>) }
      </div>
    )
  }
})

Ce Tools-in-Action était l'occasion d'en savoir plus sur l'état de développement de Maven pour la prise en compte de la prochaine version de Java 9. Arnaud et Hervé ont précisé que l'arrivée de Java 9 c'est pour très bientôt via ce site qui présente un compte à rebours très bien fait : http://www.java9countdown.xyz/ .

Une première expérimentation montre que pour l'instant un $ mvn clean package semble passer par contre pour la génération de la JavaDoc il y a encore du travail à accomplir. Ce problème est dû essentiellement au changement de la façon d'identifier la version depuis Java 9. Avant Java 9, la numérotation passait par un template 1.x. Pour revenir à la JavaDoc, Arnaud et Hervé ont montré une grosse évolution sur l'outil JavaDoc. Celui-ci évolue est supporte le HTML 5 et une barre de recherche est désormais intégrée. Concernant le support du projet Jigsaw (qui ressemble en gros à OSGi), les orateurs précisent que le développement de Java 9 s'est fait en collaboration avec les équipes qui fournissent des outils de build (Maven, Gradle…). L'idée voulue est que Java 9 sans les outils de build actuels n'a aucune chance de s'imposer. Les numéros de version ne seront pas supportés par Java 9, mais par les outils de build, ce qui se fait dans la balise version d'une dépendance Maven. Il a été question aussi du futur de Maven avec la transformation de Maven pour qu'il soit lui aussi modulaire. Finalement, une très bonne présentation agrémentée de nombreuses démonstrations : https://github.com/MavenDemo/maven-java9-jigsaw-fr

Les transparents de ce Tools-in-Action sont présentés ci-dessous :

La vidéo de ce Tools-in_action est présentée ci-dessous :

Pour ceux qui ne le savent pas, Quoi d'neuf Docker est une chaîne vidéo YouTube dont l'auteur est Nicolas De Loof qui présente des vidéos autour du système de conteneur appelé Docker. L'originalité des vidéos proposées par Nicolas est de rendre accessible la technologie Docker à un public non spécialiste. Le ton des vidéos est décalé et il y a beaucoup de séquences humoristiques. Concernant à proprement parler de ce tools-in-action, l'objectif était de réaliser une séquence en live de l'utilisation de Docker sur des Raspberry PI. Nicolas et Christophe ont apporté avec eux du gros matériel : un appareil photo pour filmer, une glissière pour déplacer l'appareil entre la zone où les orateurs parlent et la zone de l'expérimentation, un montage de quatre Raspberry PI reliés ensemble. Comme Docker n'est pas disponible sur ARM, un travail de l'équipe du groupe Hypriot ( http://blog.hypriot.com/) s'est occupé de réaliser ce portage.

Deux applications ont permis aux orateurs de montrer la mise en place du cluster de Raspberry PI. La première application est appelée Docker Coins https://github.com/jpetazzo/orchestration-workshop et la seconde est appelée Docker Vote https://github.com/docker/docker-birthday-3.

Ils ont montré la possibilité de scaler le nombre de conteneurs. Le clou du spectacle a été de simuler une panne. Pour cela Nicolas a sorti de son sac un lapidaire (sachant qu'initialement il voulait utiliser un chalumeau) et à détruit un raspberry en direct.

Personnellement je n'ai pas appris de nouvelles choses, mais l'ambiance de ce tools in action méritait d'être présent.

La vidéo de ce Tools-in_action est présentée ci-dessous :

Polymer est l'implémentation de Google des standards W3C de « Web Components ». Le principe des Web Components est d'enrichir le HTML avec de nouvelles balises correspondant à des composants plus complexes. Pour les connaisseurs d'Angular (par exemple), c'est un peu comme les directives. Sauf qu'il s'agit là d'un ensemble de standards W3C, et donc utilisables dans n'importe quelle page HTML, quel que soit le framework utilisé (si tant est qu'un framework soit utilisé). Une directive AngularJS, quant à elle, ne marche qu'à condition d'être gérée par une application AngularJS…

Prenons un exemple simple : je veux faire afficher une carte via le service de Google Maps. Grâce aux Web Components et Polymer, cela me prendra trois lignes de HTML :

<!-- Polyfill Web Components support for older browsers -->
<script src="components/webcomponentsjs/webcomponents-lite.min.js"></script>
<!-- Import element -->
<link rel="import" href="components/google-map/google-map.html">
<!-- Use element -->
<google-map latitude="37.790" longitude="-122.390"></google-map>

La première ligne correspond à une bibliothèque de « polyfills » : les standards des Web Components n'étant pas encore supportés nativement par les navigateurs (sauf pour les dernières versions de Chrome), il faut « simuler » ce qui n'est pas supporté par le navigateur de l'utilisateur. C'est le principe d'un « polyfill ».

La seconde ligne est un import du composant « google-map ».

Enfin, la troisième ligne est son utilisation.

Simple, concise, voilà la promesse des Web Components !

Une fois une bonne et complète introduction d'Horacio, place aux travaux pratiques. À travers huit étapes (voire un peu plus pour les téméraires), on s'est amusé à construire des Web Components pour afficher une liste de bières en passant en revue les principaux concepts de Polymer : bases, bindings divers, shadow-dom, interactions entre Web Components, mécanismes de routages, etc.

Un Hands-on-Labs plutôt bien mené, sur une technologie franchement sympathique et qui sera sans aucun doute de plus en plus utilisée dans les mois et années à venir.

Vous pouvez retrouver la page des ressources de l'atelier : https://github.com/LostInBrittany/polymer-beers

Vue.js est l'un des frameworks du moment. Cette présentation avait pour double objectif d'en présenter les principes fondamentaux et de comparer le framework avec les autres stars du moment : AngularJs et ReactJs. On peut dire que Vue.js reprend le meilleur des deux frameworks (enfin une bonne partie) même si les choix des créateurs ne conviendront pas à tout le monde.

Pour ma part, j'ai trouvé sympa de pouvoir écrire du « vrai » code HTML dans les composants et de ne pas avoir à passer par du JSX ainsi que les templates de Vue.js… En effet, vous pouvez créer des fichiers avec l'extension « .vue » que le framework va interpréter différemment des fichiers JS classiques. Dans les fichiers Vue, vous allez pouvoir mettre votre templace HTML, vos scripts et même des styles CSS. Notez dans ce dernier cas que les styles seront appliqués localement et uniquement pour les composants du fichier, ce qui peut être très pratique sachant que c'est le framework qui s'occupe de bien mouliner tout ça.

<style>
  .monstyle {
    color: blue;
    background: yellow;
    ...
  }
</style>

<template>
  <div class="monstyle">
    Mon prénom est {{prenom}}.
  </div>
</template>

<script>
export default {
  props['prenom']
  ...
}

</script>

Au moment de choisir son framework, Vue.js est clairement un bon candidat. Aujourd'hui, le framework qui a le plus la cote est plutôt React.js. Angular.js 2 se fait attendre. Angular 1 a clairement perdu une partie de ses adorateurs. Enfin Vue.js est le challenger qui monte. Et vous, vers lequel va votre préférence ? Dites-le-nous dans les commentaires…

La vidéo de cet atelier est présentée ci-dessous :

Le second jour de Devoxx France commence avec la keynote des organisateurs. Cette présentation a été précédée, le temps que tout le monde s'installe, par une animation offerte par les créateurs de Commit Strip, qui ont dessiné en direct une de leurs célèbres illustrations.

Dans les grandes lignes, cette édition 2016 aura été une réussite, avec un nombre de participants en augmentation. Ceci a été possible grâce à la réservation de salles supplémentaires au Palais des Congrès. En effet, la quantité de places ouvertes dépend de l'espace disponible. 2762 visiteurs seront venus à Devoxx France 2016, dont 234 orateurs, 2336 conférenciers et 192 organisateurs et exposants.

Cette année, le CFP (Call For Paper) a reçu 788 propositions pour 230 sessions possibles. L'équipe a donc fait un très gros travail de sélection, avec notamment la participation des Golden Tickets. Ces derniers avaient la possibilité de voter pour leurs sujets préférés. On retiendra que le processus de sélection a nécessité 243 heures de travail.

On regrette toutefois qu'il n'y ait aucun (ou peu) de retours par rapport aux propositions. Non seulement, cela ne permet pas de se situer et de s'améliorer, mais en plus je trouve ça injuste, voire insultant. Cela prend du temps de proposer un sujet, surtout si on le fait sérieusement. Quelle que soit la raison pour laquelle le sujet n'a pas été choisi, ce serait tout de même bien d'avoir un retour. Je comprends que ce soit difficile d'écrire à tout le monde, pour des raisons de temps et de logistiques. On pourrait imaginer que le système de vote envoie au moins des notations ou des classements. Les organisateurs encouragent à continuer de proposer des sujets, mais, personnellement, cette stratégie aurait plutôt tendance à me décourager.

Le reste de la matinée était animée par Charles Gournaouen qui, cette année, s'était déguisé en orateur antique.

À noter que le grand amphi (amphi bleu), dans lequel se tenaient les keynotes, ne peut pas accueillir l'ensemble des participants. Les keynotes sont donc retransmises dans d'autres salles. Personnellement, c'est une des choses que je n'aime pas à Devoxx, depuis que la conférence se déroule au Palais des Congrès. Je me dis que, quitte à regarder la keynote sur écran, autant le faire chez moi en étant bien installé. Et je comprends la déception des personnes qui n'ont pas pu entrer dans le grand amphi.

J'aimerais toutefois adresser une proposition aux organisateurs, qui n'est applicable que pour la keynote de l'équipe. Vous être trois sur scène. Vous pourriez vous séparer, en étant chacun dans un amphi différent, et animer la keynote un peu comme le faisaient Guy Lux et Léon Zitrone depuis des villes différentes dans Interville… J'avoue que c'est une organisation particulière. Qu'en pensez-vous ?

Keynote intéressante sur le fait que le génome humain est en passe de devenir l'une des ressources les plus importantes.

La vidéo de cette conférence invitée est présentée ci-dessous :

Thierry Natacha nous explique que les femmes ont peu/pas accès à certains travaux ou positions. On retrouve ainsi assez peu de femmes en informatique ou dans des conseils d'administration par exemple. NQS s'est fait connaître en défendant la cause féministe. Elle nous a présenté ses actions et les avancées qu'elles ont entraînées, notamment depuis que le hashtag #jamaisSansElles a été utilisé. On pensera à certains dirigeants qui refusent désormais de participer à l'assemblée lorsqu'aucune femme n'en fait partie.

Vincent Je le dis tout de suite, je n'ai pas du tout aimé cette présentation-là. Je n'ai aucune idée de quel était le but et d'où elle voulait en venir. Cela traitait un peu de la place des femmes dans entrepreneuriat, mais pas vraiment non plus. Oui, on a un problème d'attrait évident de personnes féminines dans notre secteur, et il y a du machisme à régler c'est évident. Mais selon moi il conviendrait d'agir plus en amont, sur l'orientation, sur la découverte de ce milieu-là aux plus jeunes. Je salue les initiatives telles que Devoxx for Kids, les Coding Goûters et j'en passe qui font bien plus de bien pour notre métier qu'un hashtag « #jamaisSansElles ». Il y a des filles (ou femmes) vraiment talentueuses dans notre métier c'est indéniable, et je suis persuadé qu'il y en aurait encore bien plus si on leur permettait d'exprimer pleinement leur potentiel, mais les quotas et la discrimination positive ne sont pas la solution.

La vidéo de cette conférence invitée est présentée ci-dessous :

Mickael Je suis venu à cette conférence pour en savoir un peu plus sur le langage Go d'une part et que Jean-Laurent est un très bon orateur d'autre part. Le titre est un peu trompeur, mais l'idée était de faire partager son expérience pour ceux qui souhaitent se mettre au langage Go. Les personnes ciblées sont les développeurs Java et Jean-Laurent a fait des parallèles entre le langage Go et Java. La présentation était dynamique via une séance de live coding en utilisant l'éditeur Atom et le module Go+. Jean-Laurent a insisté sur le fait que Go ne laisse pas trop de liberté, le langage impose beaucoup de chose « en go, il y a beaucoup de choses qui sont comme ça (et puis c'est tout) ». Un exemple concret concerne le nommage des variables. Si ces dernières n'utilisent pas les bonnes conventions, le compilateur rejette et refuse de continuer. Une fonctionnalité intéressante présentée par Jean-Laurent c'est la possibilité de construire un binaire qui peut fonctionner sur n'importe quelle plateforme : Linux, Windows, MAC☺… Le paradoxe a cela, c'est qu'un simple HelloWorld pèse plus de 2 Mo.

J'ai bien apprécié le discours de Jean-Laurent car pour une fois ce n'est pas un discours classique « Faites du Go c'est génial ». Il prévient sur tous les petits trucs qui peuvent rendre l'expérience désagréable.
Vincent J'apprécie particulièrement Jean-Laurent de Morlhon, un craftsman pragmatique. Il a rejoint Docker il y a quelque temps maintenant et a été plus ou moins contraint à basculer sur Go au détriment de Java qui était jusque là son langage de prédilection.

Il a présenté ce qui selon lui était un peu problématique dedans, en expliquant que si les équipes de Docker avaient eu le choix du langage à faire maintenant, ils seraient sûrement partis plutôt sur Rust. On peut citer : l'utilisation de pointeurs, un mauvais support des IDE (VIM/Emacs for the win), un formatage forcé, ne cherchez surtout pas à lutter, la gestion des erreurs en composant du tuple de retour, l'absence totale d'idiomes de programmation fonctionnelle, pas de generics ni de réelle gestion de l'héritage, pas de shared libraries, verbeux, lourdingue de tester du code legacy, des builds compliqués à base de makefiles, go dep est tout simplement un enfer.

Ceci étant dit, il s'agit quand même d'un chouette langage qui a quand même quelques atouts : il est lisible facilement, il embarque le runtime dans l'exécutable lui-même et ne nécessite donc aucune installation de VM ou quoi que ce soit d'autre, les artefacts sont autosuffisants, la gestion de la concurrence est super simple avec les go routines.

La vidéo de cette conférence est présentée ci-dessous :

J'aime bien sortir un peu de ma zone de confort et là je ne me suis pas trompé. C'est souvent là qu'on apprend le plus de choses. Je n'ai pas trop aimé la façon de présenter, un peu « show off » par deux architectes.

Les deux présentateurs nous ont montré plusieurs versions d'une architecture orientée Big Data. Il va me falloir pas mal de temps pour rattraper mon retard sur tous ces sujets, je me contente de mettre ici quelques noms en vrac avec les liens vers les technos quand je les trouve pour approfondir si cela vous intéresse. Les deux orateurs présentent l'évolution des architectures.

• V1
• SQL -> Hadoop, HDFS (Hadoop File System), YARN (du Map/Reduce) et HIVE (Data Warehouse)
• Spark SQL, Impala, Presto, Drill, Hawq
• V2
• Cube OLAP (même principe qu'une map, mais à N dimensions), online analytics processing à N dimensions
• V3
• Apache Kylin
• On peut agréger que certaines dimensions
• Spark Streaming, Storm, Google Data Flow
• V4
• Kafka + Spark + HBase
• V5
• Druid (time series)

On notera que la fondation Apache est quand même le vrai fer de lance de tout cet écosystème !

La vidéo de cette conférence est présentée ci-dessous :

On connait Jean-Michel pour son travail de documentation, en français, de Java. Son tutoriel, intitulé Développons en Java, qu'il continue de maintenir, est encore aujourd'hui une des pages les plus consultées de Developpez.com ( https://jmdoudoux.developpez.com/cours/developpons/java/). Le champion Java est revenu sur un certain nombre de bonnes pratiques, basées sur l'expérience qu'on peut avoir de Java.

Jean-Michel commence avec les Optionals qui permettent d'encapsuler une valeur ou une absence de valeur et, surtout, qui rendent le code plus fiable. Les optionnals ont néanmoins un coût et il faut les utiliser sans abus et sans oublier qu'ils ne sont pas serializables (donc à ne pas utiliser en variable d'instance, faute de rendre non serializable la classe). Jean-Michel déconseille notamment de les utiliser pour la définition des arguments des méthodes, car cela les pollue sans gain. Ça rend l'appel plus complexe également alors que le client sait déjà ce qu'il fait :

public int foo(int nb, Optional<Dog> dog) {
  …
}

int value = foo(123, Optional.empty())
Dog dog = …
int value = foo(123, Optional.ofNullable(dog))

Jean-Michel enchaîne avec les Paralles Arrays dont certains développeurs abusent à tort. En effet, le parallélisme, de par son principe de fonctionnement, permet de vrais gains de performance. Il faut toutefois faire attention à ce avec quoi on va les combiner et surtout à ne pas créer de point de contention (goulet d'étranglement) qui transformerait la bonne idée en défaut.

Avec Java 8, les dates ont pris un sérieux coup de jeune. Jean-Michel conseille d'utiliser les nouvelles classes de manière assumée, sans passer par les interfaces.

Quand on pense à Java 8, on pense forcément aux lambdas qui ont notamment ringardisé les classes anonymes. Mais les lambdas restent complexes pour la plupart des développeurs, même deux ans après leur sortie. JMD conseille d'abord ne ne pas en abuser lorsqu'elles n'apportent rien. Il invite ensuite à les garder simples, notamment en utilisant les références de méthode dès que possible et d'éviter les blocs de code dans les expressions.

L'autre gros ajout de Java 8 est l'API des Streams qui nécessite de raisonner de manière fonctionnelle et non impérative. Il faut enchaîner les méthodes dans le bon ordre, notamment en plaçant les filtres avant les transformations, pour des raisons évidentes de performance. Il faut faire attention aux appels bloquants et ne pas abuser de forEach. Et puisqu'on en est à parler de boucle, il faut admettre qu'une boucle for classique est parfois (souvent) plus lisible.

Si vous avez besoin de déboguer vos streams, n'oubliez pas d'utiliser peek. Et quand vous travaillez avec des types primitifs, souvenez-vous que Java propose des Stream adaptés, comme LongStream par exemple. D'ailleurs Jeam-Michel nous rappelle que ces streams spécialisés proposent des opérations additionnelles bien utiles dans le contexte. Ainsi, LongStream propose l'opération sum alors qu'il aurait fallu passer par un reduce beaucoup plus complexe avec un stream standard.

Enfin, JMD nous met en garde vis-à-vis de l'utilisation de streams infinis. Il conseille de mettre une limite, faute de quoi on risque de ne jamais pouvoir exécuter l'opération terminale. Enfin, n'oubliez pas que les Streams peuvent être parallèles. Je vous renvoie à ce qu'on a dit un peu plus tôt.

Les transparents de l'atelier sont présentés ci-dessous :

La vidéo de cette conférence est présentée ci-dessous :

Cette fois, c'est basé sur Scala qu'on a parlé de typage fort et encore une fois de tests sur les propriétés. Beaucoup de langages fortement typés permettent de faire des structures de contrôle typées. On peut par exemple différencier le cas de la liste vide ou de la liste non vide avec du pattern matching, utiliser les types Option et se servir des structures de contrôle de la programmation fonctionnelle.

Une autre erreur fréquente consiste à mélanger des unités différentes. Cela a posé quelques problèmes à des fusées notamment où des mètres ont été mélangés à des miles pour les calculs. Pour éviter ce type de problème, il suffit alors d'utiliser des types taggés avec l'unité. Un Int deviendra alors Meter ou Mile suivant le cas. On transforme alors ça aisément en monoïde.

Le présentateur nous a aussi conseillé de lire le papier Theorems for free, je ne l'ai pas encore fait et ne peux donc pas vous confirmer son intérêt, mais je le pose ici histoire de ne pas le perdre.

Quelques petits conseils pour vous lancer :

• bannir null, préférer des types spécifiques (None, EmptyList…)
• évitez les appels de méthodes sur la classe Object
• n'utilisez pas d'exceptions
• évitez les effets de bord
• apprenez au moins la syntaxe de types d'Haskell (non, pas que pour commenter vos fonctions JavaScript avec). On peut même chercher une fonction à partir de sa signature en Haskell avecHoogle et il est assez malin pour même proposer des versions plus génériques de ce qu'on cherche.

La vidéo de cette conférence est présentée ci-dessous :

Je suis venu à cette conférence, car je suis un utilisateur de Docker for Mac depuis le début avril et que je souhaitais en apprendre un peu plus et pourquoi pas avoir des astuces. Même s'il a fait une présentation sans utiliser de transparents, son discours était très accrocheur et très vivant. En effet, David Gageot est un très bon orateur tout comme son compère Jean-Laurent De Morlhon. Docker for Mac et Windows est une version qui vise à remplacer à terme Docker Toolbox. Comme Docker n'est pas utilisable nativement sur Windows et MAC, Docker Toolbox installait un VirtualBox avec une machine virtuelle minimaliste Linux. C'est sur cette machine virtuelle que Docker est installé. Docker for Mac et Windows ne s'abstrait pas de VirtualBox, mais utilise des hyperviseurs plus légers comme xhyve pour Mac et Hyperv pour Windows. La machine virtuelle très minimaliste se base sur Alpine Linux.

Un gros avantage avec Docker for Mac et Windows est une meilleure gestion des volumes et du réseau. Un point important durant la présentation c'est qu'il a montré sous Mac comment utiliser le domaine localhost et non docker.local. Pour cela il a utilisé l'outil pinata qui permet de configurer l'application Docker.app. À noter que depuis, une nouvelle version de Docker for Mac ajoute par défaut cette fonctionnalité. Enfin, David a expliqué que son rôle était de développer actuellement la version Windows et que celle-ci présentait un vrai challenge pour que la version soit aussi fonctionnelle que la version Mac.

La vidéo de cette conférence est présentée ci-dessous :

JWT est l'acronyme de JSON Web Token et, disons-le tout de suite, n'est pas du tout un produit Java, même s'il existe une implémentation dans ce langage. JWT correspond à la RFC 7519. Voici ce que j'en ai retenu. Avec JWT, on va déporter vers le client les informations qu'on aurait plus volontiers stocker dans une session côté serveur. Il y a de nombreux intérêts à cela, à commencer par rendre caduques les stratégies de load balancing complexes puisque le client renvoie toutes les informations nécessaires automatiquement. Vous gagnez donc mécaniquement en élasticité, ce qui n'est pas rien. On pourrait s'interroger sur la sécurité et plus généralement sur les problèmes de vérification des données. Tout est pris en charge par JWT, notamment au niveau des tokens qui sont chiffrés. Pour autant, même si JWT facilite la mise en place d'architectures décentralisées, il va toujours falloir faire face à des points de contention à un moment ou à un autre, par exemple pour valider des certificats.

La vidéo de cette conférence est présentée ci-dessous :

On a du mal à imaginer une présentation de Remi Forax sans byte code à la clé et cette session n'a pas fait exception. Rémi nous a montré, à travers l'exemple simple de la concaténation de String, comment la JVM transforme et optimise le code Java qu'on a écrit. Il nous a notamment montré comment la JVM reconnaît certains codes souvent écrits et les remplace par du code optimisé. Il nous montre également que des variantes ne seront pas nécessairement reconnues et donc pas optimisées.

La vidéo de cette conférence est présentée ci-dessous :

En un peu moins d'une heure, Mathieu nous a fait découvrir les concepts de base de React.JS ainsi que son écosystème.

La vidéo de cette conférence est présentée ci-dessous :

L'objectif de cet atelier est de se regrouper avec nos machines perso, d'installer Cassandra et de créer le plus grand cluster de machines. J'ai déjà participé à cet atelier pendant l'édition 2012 de Devoxx France. J'avais apprécié d'une part l'organisation geek de l'événement et d'autre part la présentation et l'utilisation du NoSQL Cassandra. Pour ce dernier point, on a pu voir comment se comporte Cassandra lorsqu'on débranchait une instance Cassandra du cluster. Suite à cela, je m'étais même essayé à découvrir le NoSQL Cassandra en publiant un tutoriel sur le sujet https://mbaron.developpez.com/tutoriels/nosql/cassandra/installation-outils-administration/.

À l'époque CQL, le langage d'interrogation était encore tout récent, on utilisait le Cassandra CLI avec nodetool pour faire de l'interrogation sur les différentes données.

J'ai donc décidé de retenter l'expérience pour en savoir plus sur Cassandra et surtout pour manipuler la bibliothèque Apache Spark utilisée pour faire du traitement sur de gros volumes. Dans cette édition, l'atelier s'est déroulé le dernier jour de la conférence et non pendant la journée du mercredi. Comme l'atelier durait 3 heures, il fallait forcément faire abstraction des conférences en parallèle. J'ai un peu galéré pour trouver la salle, car elle était isolée du reste de la conférence (à l'étage au niveau des vestiaires). Nous étions à peu près une vingtaine de participants. Malheureusement il y avait beaucoup d'utilisateurs de Mac et sur les nouveaux modèles il n'y a plus de connecteur RJ45. Les participants pensaient se connecter via le WIFI, mais les organisateurs n'avaient que des switchs filaires. Passer ce petit problème, nous avons fait trois groupes correspondant à trois clusters appelés (Lille, San Francisco et Singapour). Sur chaque cluster nous avions en moyenne cinq machines connectées. Les organisateurs nous ont transmis une IP statique à renseigner sur nos machines. Ensuite pour l'installation de Cassandra, elle s'est faite facilement puisque nous avions accès à une interface web minimaliste, mais efficace.

La première partie s'est focalisée sur la manipulation de Cassandra. Nous avons ajouté des données via CQL (un pseudo SQL) et nous pouvions alors voir que nos données étaient distribuées sur l'ensemble des trois clusters. Les organisateurs ont simulé une panne en rendant inaccessible le cluster Singapour. Nous avons pu voir ce qu'il se passait lorsqu'une même donnée (disposant d'une même clé primaire) était insérée sur deux clusters déconnectés et reconnectés par la suite. Cassandra ne considère que la donnée la plus récente.

La seconde partie s'est intéressée à utiliser Apache Spark. Nous avons dû paramétrer chaque machine pour déclarer les ressources qui seraient rendues accessibles pour le calcul massif. Dans les exemples à exécuter le langage cible était Scala.

Pour finir, nous n'avons malheureusement pas battu le record précédent. L'ambiance était très fun et on sent que la technologie est devenue mature (CQL, intégration avec Apache Spark). Cela donne envie d'expérimenter cela dans les détails et pourquoi pas réaliser cet atelier dans les locaux où je travaille.

Les transparents de l'atelier sont présentés ci-dessous :

C'était la dernière conférence avant de quitter Devoxx, j'avoue que je l'avais choisie un peu par défaut et j'ai été agréablement surpris d'apprendre beaucoup de choses autour de la JVM. L'objectif de cette présentation était de faire un état d'une expérimentation pour aboutir à une JVM très réduite, qui normalement devrait être possible dans la prochaine version de Java 9. Actuellement une JRE pèse 180 Mo. Quand on doit l'embarquer, ça coûte en place et on n'a pas forcément envie de garder des packages ou bibliothèques natives qui ne sont pas utiles pour le programme que l'on exécute. La démarche du conférencier a été expérimentale. Il a décortiqué une JVM et supprimé les éléments qui n'étaient pas utiles.

Les transparents de l'atelier sont présentés ci-dessous : http://zlika.github.io/presentations/devoxx_fr_2016/compile-openjdk8/slides_fr.html#/_la_modularisation_avant_l_heure_compiler_openjdk_8_en_10mo

La vidéo de cette conférence est présentée ci-dessous :

À noter qu'il y avait de nombreux lots, parfois très beaux, à gagner sur les stands. Nos amis de jFrog viennent de recevoir le titre de « best place to work ».

IV-G-2-a. Soirée vin et fromage▲

IV-G-2-b. Massages▲

IV-G-2-c. Seed Networking (résumé par Thierry)▲

Cette année, nous avons eu le plaisir d'accueillir d'Axelle Lemaire (Secrétaire d'État auprès du ministre de l'Économie, de l'Industrie et du Numérique, chargée du Numérique) qui nous a exposé sa vision.

Le seed networking est une sorte de speed dating dont la vocation est de mettre en contact des porteurs de projet avec des développeurs, et éventuellement des investisseurs. J'y suis allé pour la seconde année et c'était très sympa. J'ai toutefois l'impression que beaucoup d'étudiants en école de commerce viennent y faire leur marché, ou tout simplement leurs devoirs. Heureusement, les autres ont des projets intéressants à présenter. Seul bémol, c'est trop court, et bruyant…

IV-G-2-d. Overboard (résumé par Thierry)▲

J'ai testé les overboeards et skates sur le stand. J'ai trouvé les overboards très sympas. À ma grande surprise, la prise en main se fait relativement rapidement. Les animateurs étaient très gentils et s'occupaient bien des gens qui voulaient tester les appareils. Cela ne m'a pris que deux minutes pour me sentir à l'aise. J'étais à deux doigts d'en acheter un, mais le tarif m'a découragé. Le skate, quant à lui, demande un peu plus d'apprentissage et coûtait un bras.

IV-G-2-e. Commit Strip▲