Introduction Après des années de pratique du TDD et la satisfaction d’en avoir tiré une amélioration nette de mon workflow quotidien, j’ai souhaité me plonger dans le classique de Kent Beck “Test Driven Development By Example”. Test Driven Development qu’il a très fortement contribué à populariser au début des années 2000. Le livre date de cette période et a donc près de 20 ans. Mais ses leçons sont elles encore valables après toutes ces années ?

Introduction Le plus simple pour mapper des propriétés issues d’un fichier application.properties (ou application.yml) reste d’utiliser l’annotation @Value(${ma.super.propriete}) : 1 2 @Value("${ma.super.propriete}") private String maSuperPropriete; C’est plutôt direct, et relativement bien intégré à Intellij (il nous interpole sa valeur et propose même de l’autocomplétion dans le @Value si c’est un fichier .properties). Mais on pourrait aller plus loin. En premier lieu, aucune autocomplétion n’est disponible dans le fichier de propriétés. En second lieu, on ne peut pas réellement faire de validation de données sur le contenu renseigné dans ce fichier.

Le matériel Un module nodeMCU Lolin V3 Un capteur de température/humidité DHT22 Une résistance de 10K Ohm Une pile 9V Préambule à la gestion d’énergie : Le mode DeepSleep Sur les ESP 8266 il existe trois modes de gestion d’énergie : » Le mode ModemSleep qui va éteindre le modem Wifi tout en gardant la connexion wifi sans transmission de données, le CPU du modem reste donc actif pendant ce temps et consomme de l’énergie » Le mode LightSleep va également conserver la connexion Wifi pour pouvoir la réactiver rapidement tout en éteignant l’horloge interne du système et le cpu ce qui provoque le fait que les interruptions système ne sont plus écoutées » Le mode DeepSleep est le plus économe en terme d’énergie, pour ce mode tout est éteint sauf l’horloge interne, ce qui permet de réveiller le système via la commande interne de RESET Le mode DeepSleep nécessite des branchements particuliers ainsi que des appels fonctions pour pouvoir être activé, ils seront détaillés plus loin dans l’article.

Introduction Slack est un outil utilisé dans de nombreuses entreprises pour faciliter la communication au sein des équipes. Et il est possible d’augmenter les fonctionnalités de Slack via des commandes personnalisées. Parmi les plus utilisées, on retrouve la commande /polly pour créer des sondages, ainsi que la commande /giphy pour aller chercher des gifs et participer de façon constructive à une conversation. Dans cet article, nous allons présenter une façon d’ajouter ses propres commandes via la création d’un bot Slack fait en Rust.

Intro Une des premières choses que l’on fait quand on configure son poste pour utiliser Git, c’est de renseigner notre nom d’utilisateur et un email qui sera utilisé pour tous les commits fait sur notre machine. Pour cela, soit on édite à la main le fichier ~/.gitconfig soit on lance les deux commandes suivantes : 1 2 git config --global user.name "François Dubrez" git config --global user.email francois.dubrez@whatever.com Un commit avec cette configuration donne quelque chose du style :

Intro Il existe un choix pléthorique de framework front pour prototyper rapidement des applications web. On peut aussi utiliser du VanillaJs car les APIs standards ont quand même pas mal évolué ces derniers temps. Pour ma part j’ai testé React et l’utilise régulièrement quand je veux faire du prototypage rapide. Dans l’écosystème React, le réflexe pourrait être d’utiliser un projet comme create-react-app mais c’est un peu overkill pour aller rapidement. Le premier npm install fait mal si on a une mauvaise connexion internet.