L’intégralité des vidéos des conférences et universités présentées lors de Devoxx France 2018 sont disponibles sur la chaîne Devoxx FR de Youtube.

Si vous souhaitez rapidement vous faire un avis sur leur contenu avant de les visionner ou si vous souhaitez garder une trace écrite de ce que vous y avez appris, je mets librement à disposition mes notes prises au cours de ces 3 jours.

Les sujets sont variés : le langage Java bien évidemment, des frameworks comme Spring et RxJS, de l’outillage pour vos test tests et vos builds, de l’infrastructure avec Docker et Kubernetes, de l’architecture avec DDD et OpenAPI, sans oublier des sujets plus connexes tels la place du développeur en entreprise ou bien l’apprentissage du code aux enfants.

Lors de Devoxx France 2018, j’ai participé au Hands-on Lab d’initiation à Apache Cassandra. Animé par Alexander Dejanovski (The LastPickle) et Maxence Lecointe (Ippon), ce Lab m’aura enfin permis de découvrir cette base de donnée NoSQL, d’appréhender ses concepts fondamentaux, de jouer avec un cluster en local et d’écrire quelques requêtes CQL par le biais de son client Java.

Le Lab était construit autour d’un support de présentation et de 5 exercices pratiques. Les slides Devoxx France – Initiation àApache Cassandra - Avril 2018.pdf et les exercices sont disponibles sur le dépôt GitHub thelastpickle/devoxxfr2018.

Ce billet a pour objectif de permettre aux développeurs n’ayant pas eu la chance de suivre ce Lab de profiter du travail préparatif des 2 speakers (un grand merci à eux) en lui donnant de la visibilité. Vous pourrez ainsi vous former par vous-même à Cassandra. Les explications données dans ce billet complètent les slides mais ne remplacent pas leur lecture.

Afin de normaliser la configuration Logback des applications web sur lesquelles j’interviens, j’ai récemment eu besoin de programmer Logback via son API en Java et non en utilisant la syntaxe XML Joran. Moins courant que le traditionnel logback.xml, cette possibilité de configurer Logback par le code offre davantage de possibilités, ne serait-ce que par son caractère dynamique.

Par le passé, j’avais déjà eu l’occasion de manipuler l’API Logback dans des tests unitaires afin de changer dynamiquement le niveau de log des loggers. Cette fois-ci, je l’ai utilisé pour déclarer les différents appenders et configurer toute l’infrastructure applicative de logs:

• Activer l’appender Console uniquement sur le poste de dév (afin qu’en prod, les logs ne se retrouvent pas en double dans le fichier server.log de JBoss)
• Factoriser la stratégie de journalisation des différents appenders fichiers (troubleshooting, overview, soap …)
• Récupérer différentes informations applicatives (ex : nom de la JVM, application, nom de l’environnement, login de l’utilisateur authentifié) à destination du collecteur de logs (Logstash ou Splunk)
• Exposer l’accès aux loggers au travers d’une API REST

La configuration des logs reste paramétrable via un fichier de properties externe. En effet, le paramétrage peut différer d’un environnement de déploiement à l’autre (ex : chemin du répertoire des fichiers logs). La configuration Logback reste extensible par l’inclusion d’un fichier XML au format Joran.

Dans cet article, je vais vous présenter quelques bouts de code simplifié manipulant l’API Java de Logback.

Spring WebFlux est une fonctionnalit é majeure de Spring Framework 5. Disposant de son propre module Maven (spring-weblux), ce nouveau framework web se positionne comme une alternative à Spring Web MVC. Ce dernier a été conçu par-dessus l’API Servlet. Spring WebFlux l’a été pour les applications r éactives, avec I/O non bloquantes, asynchrones, à faible latence, basées sur des serveurs comme Netty, Undertow ou compatibles Servlets 3.1 et +. Spring WebFlux s’éloigne du modèle d’un thread par requête HTTP et se base désormais sur le projet Reactor pour orchestrer le traitement des requêtes. Conçu avant tout pour exposer des API REST attaquant des bases NoSQL non bloquantes dans des architecture micro-services, Spring WebFlux peut être utilisé sur des applications web dont les IHM sont rendues côté serveur (ex : avec Thymeleaf ou Freemarker).

J’ai récemment migré vers Spring WebFlux la version Kotlin et Spring Boot de l’application démo Spring Petclinic. Dans ce court billet, je voulais vous lister les adaptations mises en œuvre dans le commit 279b2e7.

En guise de conclusion de mon précédent billet, je proposais de migrer le build Maven d’une application web Spring Boot 2 en un build Gradle basé sur le langage Kotlin. C’est désormais chose faite. Mais bien que Gradle privilégie aujourd’hui l’usage du DSL Kotlin au détriment de Groovy, son guide d’utilisation n’a pas encore été actualisé et il est difficile de trouver de la documentation. Il faut passer par le projet GitHub kotlin-dsl pour accéder à quelques tutoriaux et des exemples. Heureusement, GitHub fourmille d’autres d’exemples, notamment du côté des projets soutenus par les contributeurs Pivotal sur Spring Boot.

Sans plus tarder, voici le fichier de conf build.gradle.kts de la version Kotlin de Spring Petclinic.

Lors la dernière conférence Google I/O qui s’est tenue en mai 2017, Google a officialisé le support de Kotlin sur Android. Google n’est pas le seul acteur de l’IT à miser sur ce nouveau langage créé par JetBrains (l’éditeur de l’IDE IntelliJ) et s’exécutant sur la JVM (mais pas que). En effet, dès février 2016, Pivotal proposait de développer des applications Spring Boot avec Kotlin. En janvier 2017, ils annonçaient que la version 5 du framework Spring proposerait des fonctionnalités exclusives à Kotlin. Chez Gradle, le langage Kotlin est désormais privilégié au détriment de Groovy.

Pour découvrir ce nouveau venu dans la galaxie des langages de programmation, je me suis intéressé à migrer vers Kotlin l’application démo Spring Petclinic développée en Java et Spring Boot. Je souhaitais ici partager son code source : spring-petclinic-kotlin et énumérer les différences notables avec sa version Java.

Faisant partie des algorithmes de la théorie des graphes, l’ algorithme de Kruskal permet de rechercher un arbre recouvrant de poids minimum.

Une application pratique de l’algorithme de Kruskal consiste à relier tous les ordinateurs d’un même réseau local avec une longueur optimale de fibre optique.

Dans ce billet, vous trouverez une implémentation Java de cet algorithme. Il m’aura permis de résoudre le problème Fibre Optique donné en finale du concours du Meilleur Dev de France 2017.

Dans le cas d’un système monétaire non canonique, utiliser un algorithme glouton ne donnera pas nécessairement un résultat optimal. Il est nécessaire de passer par la méthode algorithmique dite de programmation dynamique.

Dans ce billet, nous allons mettre en pratique l’initiation à Vue.js reçue le mois dernier. Je vous propose de coder un pseudo Google Form avec l’aide de Vue.js, de Bootsrap et du framework de validation VeeValidate. Le formulaire HTML est généré automatiquement à partir d’un paramétrage JSON récupéré par une API REST. Nous n’aborderons pas ici la partie serveur. Un utilisateur peut sauvegarder son formulaire à l’état de brouillon afin de poursuivre ultérieurement sa saisie. Le formulaire à afficher peut donc être pré-saisi. La validation est dynamique: elle se fait au fur et à mesure de la saisie du formulaire. Voici un exemple de formulaire :

Les vidéos des présentations données lors de l’édition 2017 de la conférence Devoxx France sont d’ores et déjà disponibles sur la chaîne Devoxx FR de Youtube. Si vous n’avez pas le temps de toutes les visionner, si vous souhaitez vous faire un avis avant de les regarder ou si vous souhaitez garder une trace écrite de ce que vous y avez appris, je mets librement à disposition quelques-unes de mes notes. Il y’en a pour tous les goûts : du Java pur et dur, du framework avec Spring, du front avec Vue.js, des conteneurs avec Docker Swarm mode, des nouvelles approches de développement avec la programmation réactive, des patterns d’architecture avec les microservices, CQRS et l’Event-Sourcing, du legacy tendance avec les logs, et du Big Data avec Elasticsearch.