English version available

Cette année, j’ai assisté aux 2 jours de la conférence Devoxx UK à Londres les 10 et 11 mai. Cet article est un résumé des notes que j’ai prises pendant le premier jour. Si vous souhaitez obtenir plus de détails sur un talk, vous pouvez regarder la vidéo associée.

A Future without Servers, avec Danilo Poccia

Comment construire le meilleur logiciel avec la meilleure expérience utilisateur?

Travailler « en arrière » à partir des besoins du client (work backwards). Avant de commencer toute implémentation:

1. Ecrire le Communiqué de presse
2. Ecrire la FAQ
3. Définir l’Expérience client
4. Ecrire le Manuel de l’utilisateur

L’idée est de rendre votre système simple. Un système complexe était simple au début, il est devenu complexe!

L’architecture change:

• Il y a 10 ans: nous splittons nos applications monolithes en utilisant XML et SOAP pour la communication
• Il y a 5 ans: nous créons des architectures micro services en utilisant REST / JSON ou un protocole binaire pour la communication
• Maintenant: nous construisons des architectures événementielles (event-driven) avec des fonctions éphémères

Qu’en est-il des données?

Les référentiels de données deviennent des sources d’événements. Chaque événement est une information immuable du métier.

Il y a une évolution de ACID (Atomic, Consistent, Isolated, Durable) vers ACID 2.0 (Associative, Commutative, Idempotent, Distributed).

Avec la conception pilotée par les événements, nous pensons cause / effet plutôt que qui déclenche quoi: « Le service B est causé par A » au lieu de « Service A déclenche B ». Nous utilisons un mécanisme de notification et d’accusé de réception.

Alors, à quoi ressemblera le futur?

Nous écrirons seulement le code de logique métier!

Let’s Get Lazy: Exploring the Real Power of Streams, avec Venkat Subramaniam

Venkat Subramaniam est un très bon speaker. C’était la première fois que je l’écoutais et j’ai été impressionné par sa façon de présenter, je vous suggère de regarder une de ses vidéos.

Haskell est un langage paresseux par défaut, les opérations qui peuvent être différées le seront. Avec Scala, c’est possible en utilisant le mot-clé « lazy ». Mais qu’en est-il de Java? Le mot-clé « lazy » n’existe pas, mais c’est possible avec le code fonctionnel et les streams introduits avec Java 8.

Le code impératif a une cérémonie haute et une complexité accidentelle. Vous dites quoi faire et comment le faire.

Le code fonctionnel a moins de cérémonie et moins de complexité. Vous dites quoi faire et c’est tout. Le code est très facile à lire de haut en bas.

Cependant, si le code est « joli », il peut ne pas être durable. Alors qu’en est-il de la performance? Par exemple, est-ce que nous traitons toute la collection pour ne prendre que le premier élément? FindFirst() est l’opération d’exécution terminale. Jusqu’à ce que nous l’appelions, rien (c’est-à-dire toutes les opérations intermédiaires) ne sera exécuté.

Un stream n’exécute pas de fonction pour chaque objet de la collection, mais il exécute une collection de fonctions pour chaque objet, mais seulement quand c’est nécessaire.

Un stream n’est pas une collection d’objets, c’est une collection de fonctions.

Les lambdas sont stateless.

List<Integer> numbers = Arrays.asList(1, 2, 3);
Stream<Integer> stream = numbers.stream()
                            .map (e -> e * 2); // Ceci est une lambda
stream.forEach(System.out::println);

Les closures portent les états immuables, soyez très prudent en les utilisant.

List<Integer> numbers = Arrays.asList(1, 2, 3);
final int factor = 2;
Stream<Integer> stream = numbers.stream()
                            .map (e -> e * factor); // Ceci est une closure
stream.forEach(System.out::println);

La paresse rend possible l’utilisation de stream infini, sinon le programme ci-dessous serait une boucle infinie.

Stream<Integer> infiniteStream = Stream.iterate(0, e -> e + 1);
List<Integer> numbers = infiniteStream 
                          .limit(5)
                          .collect(Collectors.toList());

Kotlin for Java Programmers, avec Venkat Subramaniam

Je suis resté dans la même salle, car j’ai beaucoup apprécié le premier talk de Venkat. Avec la même façon de présenter, cette deuxième présentation était toute aussi bonne.

Comme je n’ai jamais expérimenté Kotlin, c’était une bonne introduction pour moi. Ce langage basé sur la JVM devient vraiment populaire de nos jours, d’autant plus que Jetbrain le pousse pour être le langage principal pour la programmation Android. Venkat nous a donné beaucoup d’astuces pour rendre le code concis et nous a suggéré de jouer nous-mêmes avec en utilisant le REPL (kotlinc). Sans doute moins verbeux que Java et livré avec des fonctionnalités intéressantes (notamment la gestion des null et le lazy…). Je vais probablement l’essayer à un moment donné.

How to use AI and Java to train your application to recognize people by name, avec Ruth Yakubu

Ruth nous a présenté Microsoft Face API qui s’exécute sur la plate-forme de cloud computing Azure (bien évidement de Microsoft). Face API est l’un des services « cognitifs » fournit par Microsoft, par ex. il existe un service pour reconnaître la parole et traiter le langage naturel.

Elle nous a montré une application écrite avec Spring Boot qui interagit avec Face API. Tout d’abord, elle a uploadé une série de photos de l’acteur Matthew McConaughey (si vous ne le connaissez pas, il était le personnage principal dans Interstellar) pour former le modèle. Puis elle a uploadé une nouvelle photo de lui et de sa femme que le système ne connaissait pas encore. L’algorithme a reconnu l’acteur avec une grande précision alors qu’il ne savait pas qui était la femme l’accompagnant, mais il a été capable de donner une description précise d’elle (une femme souriante dans la trentaine, etc.).

Il est possible de créer votre propre algorithme d’apprentissage automatique avec Java, par exemple en utilisant la bibliothèque DeepLearning4J. Lors de la formation d’un modèle, il est important de séparer les données en 2 groupes, les données d’entraînement (80%) et les données de test (20%) afin de pouvoir vérifier que votre modèle a une bonne prédiction. Il est également important d’utiliser les GPUs et pas seulement les CPUs pour améliorer les performances, maintenant les bibliothèques en profitent, y compris DL4J.

Building a self-driving RC car, avec Tim van Eijndhoven

Ce fut une présentation intéressante pour suivre l’expérience de Tim et son équipe qui se sont lancés dans la création d’une voiture (jouet) autonome sans chauffeur basée sur un kit Radio Control (RC). Ils ont construit ce prototype dans le cadre d’un challenge. L’idée est que la voiture conduise de manière autonome et suive un itinéraire (tracé délimité par 2 lignes blanches) avec des courbes et des obstacles potentiels.

Si Tesla peut le faire, alors pourquoi pas nous? À notre échelle, bien sûr…

En plus du kit RC, ils ont ajouté un Raspberry Pi, un convertisseur de puissance/alimentation, une caméra et un mécanisme d’arrêt d’urgence (utile quand la voiture est hors de portée du WiFi et peut se crasher n’importe où…). Le budget total est d’environ 300 euros.

En ce qui concerne les technologies, ils ont utilisé:

• Vert.x, application réactive sur la JVM, événementielle et non bloquante
• La librairie OpenCV (Computer Vision) pour traiter le flux vidéo en temps réel et s’assurer que la voiture reste entre les lignes blanches

Il y a beaucoup de choses à penser, l’environnement est probablement la variable la plus incertaine. L’algorithme peut se tromper en fonction de:

• La surface (moquette à motifs, carreaux, route sombre)
• Le temps (ensoleillé, pluvieux, le programme est très sensible au changement de luminosité)
• Et d’autres facteurs (réflexion sur une fenêtre, effet miroir)

Ils ont beaucoup d’idées d’amélioration pour le futur:

• Il n’est pas nécessaire d’analyser toutes les images provenant du flux vidéo (en particulier sur une ligne droite). Actuellement, ils analysent une image toutes les 100ms (pourquoi 100ms?) Car c’est le temps qu’il faut pour en traiter une)
• Il n’est pas nécessaire d’analyser toute l’image (certaines parties peuvent être ignorées, ce qui est au-dessus de l’horizon n’est pas nécessaire par exemple)
• Déporter la logique de calcul sur la voiture elle-même au lieu d’un ordinateur portable sur le WiFi, pour éviter la latence du réseau (cependant la puissance de calcul de Raspberry Pi peut être limitée)
• Utiliser l’IA et le Deep Learning pour que la voiture puisse apprendre à naviguer en utilisant des vidéos d’entraînement: des vidéos lorsque la voiture est contrôlée à distance par un humain (cependant, cela peut prendre beaucoup de temps et de nombreuses vidéos seront nécessaires sur des circuits et avec des conditions différentes)

Cloud Native Java, part deux, avec Josh Long

Josh est Spring Developer Advocate chez Pivotal, c’était la première fois que j’assistais à une de ses conférences. J’ai vraiment apprécié et j’ai été très impressionné par son débit de parole et de code simultané sans oublier de nombreuses blagues. Un brillant orateur.

Josh a utilisé https://start.spring.io/ pour générer un petit projet pour gérer des réservations en utilisant Spring Cloud (construit sur Spring Boot). Pourquoi devriez-vous utiliser cet outil en ligne pour initialiser votre projet? Regardez la vidéo pour obtenir la réponse de Josh, c’est amusant!

Il a choisi Kotlin pour le service (car pourquoi pas?) avec des endpoints pour obtenir les messages et les réservations en utilisant un datastore réactif MongoDB. Le service chargeait les données de manière réactive pendant le démarrage.

Il a choisi Java pour le client en utilisant diverses technologies out-of-the-box grâce à Spring (Eureka, Spring Security, Hystrix pour le load balancer interne et gestion du fallback). Le client a pu interroger le service pour récupérer les données.

A la fin de la démo, il nous montre également une architecture sans serveur utilisant RIFF, un FaaS pour Kubernetes. Il a écrit une fonction pour transformer une chaîne de caractère en majuscules, puis utilise le terminal pour invoquer la fonction déployée sur Kubernetes. Il n’a pas eu le temps de nous montrer l’appel à partir d’un service, mais nous avons compris le principe.

Ma première journée à Devoxx était géniale, cette année j’ai essayé d’assister à des conférences plus innovantes sur le Serverless et le Machine Learning, un mélange live-coding et de théorie. Je posterai bientôt mon résumé du jour 2, alors stay tuned!