Pour ce premier article de 2019, je vous propose un voyage dans le temps, au contenu plus personnel. J’ai récemment dîné avec mon vieil ami Nicolas Lidzborski qui travaille chez Google aux US et que je n’avais pas revu depuis une dizaine d’années. Comme toute retrouvaille, nous nous sommes remémorés des souvenirs du Lycée, ses profs et son club IF. De sa chambre d’ado, Nicolas a retrouvé une illustration que nous avions réalisé pendant le concours Soft la Nuit de 1996, un marathon de 24h pendant lequel 20 équipes de 4 jeunes devaient développer un logiciel. Et oui, mon premier hackaton commence à dater. Afin de pouvoir se qualifier, nous avions du présenter des projets personnels. Mon jeu vidéo Black Hell en faisait partie. Par curiosité, et avec un brin de nostalgie, je suis parti à la recherche d’un backup de disquette. J’en ai ressorti code source et binaire. Et surprise : avec l’émulateur DOSBox, j’ai réussi à le faire tourner, à la fois sous Windows 10 et MacOS.
Archives de catégorie : Retour d’expérience
Configurez Logback en Java
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. Continuer la lecture
Build Gradle en Kotlin d’une webapp Spring Boot
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. Continuer la lecture
Découvrir Kotlin en migrant une webapp Spring Boot
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.
Implémentation Java de l’algorithme de Kruskal
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.
Continuer la lecture
Implémentation Java de l’algorithme de rendu de monnaie par programmation dynamique
Dans ce billet, j’ai eu l’envie de vous partager mon implémentation Java du très célèbre problème du rendu de monnaie dont voici l’énoncé : étant donné un système de monnaie, comment rendre de façon optimale une somme donnée, c’est-à-dire avec le nombre minimal de pièces et de billets ?
Par exemple, dans le système monétaire de l’Euro, la manière la plus optimale de rendre 6 euros consiste à rendre un billet de 5 € et une pièce de 1 €, même si d’autres combinaisons existent (ex : 3 x 2 € ou 6 x 1 €).
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. Continuer la lecture
Formulaire dynamique en Vue.Js
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 Streams Java 8 par l’exemple
Bien que Java 8 soit sorti il y’a 2 ans, tous les développeurs n’ont pas eu encore la chance de pouvoir utiliser, en entreprise, tous les concepts issus de la programmation fonctionnelle et qui ont été introduits dans cette version majeure : expressions lambda, interfaces fonctionnelles, méthodes par défaut, Optional, références de méthode, Streams …
Pourtant, Java 8 est à nos portes : des projets de migration de serveur d’application se terminent, les socles d’entreprise se mettent à jour, des frameworks exploitent ces nouveautés (ex : JUnit 5) … Et on va enfin pouvoir exploiter à bon escient toutes ces nouvelles fonctionnalités. Mais avant cela, une mise à niveau est indispensable. Et c’est dans cet objectif que j’ai récemment initié mes collègues aux Streams.
A partir d’un jeux de données réduit (une liste de 3 clients), j’ai implémenté quelques règles de gestion à la fois en Java 7 avec des boucles et en Java 8 avec des Streams, histoire de leur montrer la différence.
Ces outils qui nous font gagner du temps
Au quotidien, tout développeur Java utilise un IDE, un JDK, un outil build et un navigateur. Ce sont des standards. A côté, chaque développeur utilise un ou plusieurs petits outils permettant d’améliorer son quotidien. Par outil, j’entends aussi bien un plugin, un logiciel ou une fonctionnalité avancée de son IDE.
Dans cette présentation, j’ai eu envie de partager des outils fonctionnant sous Windows (mais pas que). J’utilise certains depuis des années, d’autres depuis seulement quelques semaines suite aux recommandations de collègues.
A vous de voir si vous souhaitez les tester puis les adopter, ou non.
Formatez votre code
Lors du démarrage d’un projet sur lequel plusieurs développeurs vont être amenés à travailler, se pose très tôt la question des styles et règles de formatage à appliquer au code. En effet, afin de pouvoir comparer l’historique des révisions d’un fichier, une bonne pratique veut que l’on ne change pas les règles de formatage au cours de route. Si tel était le cas, les changements importants seraient noyés par les changements d’indentations et autres retours à la ligne.
Parmi les normes de développements d’une entreprise ou d’un projet Open Source, un chapitre couvre généralement les règles de formatage. C’est par exemple le cas du guide de style de code du projet Spring Framework. Ces règles peuvent également être définies au sein d’un outil de qualimétrie comme SonarQube. Chaque violation de règle entraine alors un défaut.
Ce billet propose 2 solutions permettant à des développeurs IntelliJ, Spring Tools Suite (STS) et Eclipse de travailler ensemble.