Nadia Humbert-Labeaumaz

Change is hard.

However, sometimes it’s simply unavoidable — in life and in organizations. Take remote work: not long ago, many companies dismissed it entirely. Today, they’re drafting work-from-home policies they never thought they’d need.

Change will happen — with or without us. But what makes it last?

Today, social entrepreneurship is defined in many ways — an ambiguity that can blur social entrepreneurs’ identity, undermine their credibility, weaken the relevance of the guidance they receive, and ultimately hinder their impact. That’s why a shared definition is essential.

This article presents my perspective and insights into social entrepreneurs, based on primary research conducted with a small, random sample in Toronto, Canada.

In this video, I dive into debt funding for small to medium businesses in New Zealand. While the headlines often talk about how “cheap” money is — especially for homeowners — the reality for SMEs is quite different.

I’ll explore what current lending conditions mean for small businesses and share recommendations to help improve access to funding.

After WWII, Charles de Gaulle jumpstarted the French economy by cutting diesel taxes for the first time — supporting haulers, farmers, and artisans who relied on it.

Tests are an essential part of any codebase. At a minimum, they help prevent regressions as the code evolves. But not all tests are created equal — unit, integration, component, contract, and end-to-end tests each serve a distinct purpose.

This article outlines a practical testing strategy for Java Spring Boot microservices, covering the role, scope, and tooling for each test type to help you make the most of your test suite.

Component tests check full use cases from start to finish. They’re essential for verifying and documenting how an application or service behaves overall. But they can be expensive, especially in terms of setup and execution time — which is why it’s important to define their scope carefully.

That said, I’ve often found them cost-effective in distributed architectures. They’re usually simple to set up since you can reuse the service’s external API without needing extras like fake servers. And since each microservice tends to have a narrow focus, you can test behavior thoroughly in isolation.

This article explores how to make component tests more robust — with one key idea: keep them independent of implementation details.

In a microservices architecture, many things can go wrong: middleware can fail, the network may be unstable, or the service you’re calling might be down. In this uncertain environment, anticipating failures is crucial to prevent breaking the entire chain and delivering errors to the end user—when you could instead offer a partially degraded experience.

This article explains how to implement the circuit breaker pattern using Hystrix, Feign Client, and Spring Boot.

I often come across code snippets like this:

public class Day {
  public void start(Weather weather) {
    switch(weather) {
      case RAINY:
          takeAnUmbrella();
          break;
      case SUNNY:
          takeAHat();
          break;
      case STORMY:
          stayHome();
          break;
      default:
          doNothing();
          break;
    }
  }
}

Here, a specific action depends on the weather. This kind of code is difficult to test and maintain. This short article shows how to refactor it using a Map.

Recently, I conducted a workshop about how to go back in time with Git alongside Renaud. Here are the main points that we raised during this session.

Dans notre activité, nous sommes amenés à faire régulièrement des audits de code. Planifié ou forcé, un audit a pour but de déterminer la qualité logicielle d’une base de code et de faire des préconisations pour améliorer sa santé. L’objectif de cet article est de faire un retour d’expérience sur les différentes circonstances qui mènent à la réalisation d’un tel audit.

Durant mon travail, j’ai rencontré des dépendances circulaires dans une application sur laquelle je suis intervenue. Dans sa plus simple forme, il s’agit de deux classes qui dépendent l’une de l’autre. Ceci est, selon moi, un problème pour plusieurs raisons. L’objectif de cet article est de montrer ce qu’est une dépendance circulaire, en quoi cela peut poser problème, et comment les éliminer.

La version 1.4 de Spring Boot est sortie le 28 juillet 2016. Elle contient notamment des évolutions importantes au niveau de l’écriture des tests.
L’objectif de cet article est de voir comment migrer les tests d’un controller Spring MVC en utilisant les nouvelles fonctionnalités apportées par cette version.

CQRS, ou Command Query Responsibility Segregation, est une architecture où la partie Command (écriture) et la partie Query (lecture) du système sont séparées.

J’ai eu la chance d’assister récemment à une présentation de Tomasz Jaskula nommée Recettes CQRS, pour bien cuisiner son architecture. Je l’ai beaucoup appréciée, notamment car on voit les différentes étapes pour arriver à une architecture CQRS / Event Sourcing / DDD à partir d’une architecture N-Tiers “classique”.

L’objectif de cet article est de présenter ma compréhension et mon avis sur le CQRS en particulier.

L’Acceptance Test Driven Development est une pratique qui consiste à écrire un test d’acceptation dès la définition de la fonctionnalité à implémenter. Ce test permet ensuite de valider que l’implémentation de la fonctionnalité est terminée. En général, plusieurs composants unitaires sont nécessaires pour implémenter une fonctionnalité. Ces composants peuvent être développés en TDD dans une deuxième boucle de feedback.

L’objectif de cet article est de présenter l’ATDD et comment le mettre en pratique grâce à du TDD double boucle.

Kotlin est un langage de programmation créé par JetBrains. Il est exécuté sur la JVM et est 100% interopérable avec Java 1.6+. J’ai découvert récemment ce langage et j’ai réalisé un ensemble de katas pour le pratiquer. Le code source de ces katas est disponible sur GitHub :

• Prime factors
• String calculator
• Game of life
• Mars rover

Dans cet article, je vais présenter des particularités de Kotlin que j’ai pu rencontrer.

Ce kata est tiré d’un exemple du livre “Refactoring, Improving the Design of Existing Code” de Martin Fowler, et a été créé par Emilie Bache. L’exemple contient des signes de mauvais design et permet notamment de pratiquer le polymorphisme.
Dans cet article, une solution à ce kata sera développée. Le projet qui a servi de support se trouve sur GitHub avec la solution respective.

Once upon a time, a young woman had plenty of projects and passions and was a bit hyperactive. She doesn’t really enjoy talking about her life and asks herself, very seriously, how she will write this post.

Among her early age dreams were learning many things about science and software engineering. She started with biosciences (by the way, they are fascinating, nothing is more complex and well crafted than the human body) and then she decided to continue with software engineering. However, the software engineering program she completed only lasted one year (6 months of classes and 6 months of internship). Of course, this was only a door to access the world that she wanted to discover so much.

Bob is a developer. He has been asked to add a brand new feature to the application. So, he would like to take this opportunity to refactor the code a little bit since it doesn’t respect the good practices that he learnt from the last Software Craftsmanship meetup. However, Bob was told that he couldn’t do it because there was not enough time to do anything other than producing features. So, Bob thought, “there is never enough time anyways”…

Sounds familiar? Indeed, refactoring is often seen as an activity without any value. Other things in life can also seem worthless. There is one that takes almost a third of our lives during which we do nothing literally: sleeping!

Les tests automatisés servent à vérifier le bon comportement d’un objet (ou d’un ensemble d’objets), indépendamment de la manière dont ce comportement est implémenté. Le comportement d’un objet est décrit par son API publique (constructeurs, constantes et méthodes publiques). Les tests ne devraient donc utiliser que cette API.

Les méthodes privées (et protected) ne faisant pas partie de l’API publique d’un objet, elles ne devraient pas être appelées directement par le code de test.

Cet article a pour objectif de montrer comment réagir lorsqu’il paraît nécessaire de tester une méthode privée.

L’héritage est une composante très importante des langages orientés objet tels que Java. Cependant, il doit être utilisé à bon escient afin de respecter les bonnes pratiques de programmation.

Il m’est arrivé de rencontrer des cas où l’héritage était utilisé afin de ne pas dupliquer du code. Le but de cet article est d’illustrer une telle utilisation, d’analyser ses inconvénients et de montrer une manière possible de la corriger.

Since Spring 3.2 (January 2013), it has been possible to test Spring MVC controllers without an external framework. This article aims to show how to test Spring MVC controllers using only Spring testing capabilities.

Il est souvent nécessaire d’exposer des ressources statiques telles que des images, des fichiers pdf, des vidéos, etc. dans une application web. Ces fichiers sont stockés sur le serveur et ne sont donc pas accessibles à l’utilisateur via une URL.

L’objectif de cet article est d’exposer des fichiers stockés sur le serveur via une URL dans une application Spring MVC.

Dans une application web, il est courant d’effectuer une redirection après la soumission d’un formulaire. Cette redirection permet notamment de rendre l’url bookmarkable et d’empêcher l’utilisateur de resoumettre le formulaire par erreur (suite à un refresh, par exemple).

Il peut être intéressant de passer des paramètres à travers ce redirect. Par exemple, pour indiquer à l’utilisateur que son formulaire a bien été soumis. Pour ce faire, il est possible d’ajouter des paramètres directement dans l’url : redirect:/path/to/endpoint?formSubmitted=true. Cette solution n’est pas toujours adpatée pour des raisons de confidentialité, de taille d’url ou simplement d’esthétique.

L’objectif de cet article est de démontrer comment transférer des paramètres à travers une redirection avec Spring MVC en utilisant des flash attributes. L’exemple utilisé consistera en un formulaire qui permet d’envoyer un nom. Ce nom s’affichera ensuite une fois le formulaire soumis.

Depuis Spring 3.1, il est possible de configurer Spring en Java. La configuration Java de Spring Security est supportée depuis sa version 3.2 (source).

L’objectif de cet article est de montrer comment configurer Spring Security en Java config, dans une application Spring Boot, avec une base de données qui contient les utilisateurs et leur mot de passe hashé. De plus, une authentification HTTP basic sera mise en place.

Il existe plusieurs méthodes pour injecter une dépendance dans un objet Java :

• Injection sur un setter
• Injection sur le constructeur
• Injection directe sur la déclaration de l’attribut

Cet article a pour objectif de définir ces différentes méthodes, de décrire leurs avantages et inconvénients et indiquer leurs cas d’utilisation.