Nadia Humbert-Labeaumaz

Change is hard.

However, sometimes, we cannot avoid it. This state of fact applies to our personal lives, as well as at the organizational level. For instance, companies that did not even consider remote working as an option less than two years ago must let us work from home now.

Changes will happen whether we want them or not. But what can make these changes successful in the long run?

Nowadays, several definitions of social entrepreneurship coexist. I think this ambiguity might sometimes dilute social entrepreneurs’ image, reduce their credibility vis-a-vis other entrepreneurs, weaken the relevance of the insights they receive and, ultimately, harm their purpose. Therefore, having a shared understanding of what social entrepreneurship means seems essential.

This article will cover my definition of a social enterprise and share insights regarding social entrepreneurs inferred from primary research performed in a small random sample in Toronto, Canada.

In this video, I will be talking about debt funding for small to medium businesses in NZ. Currently, we see how the media often underlines the low cost of money. While this might be true for individuals, especially for mortgages, the reality of SMEs is completely different. My goal will be to provide insights into the implications of the existing lending conditions for SMEs and some ideas for recommendations on improving the situation.

After WWII, Charles de Gaulle boosted the French economy and helped road haulers, farmers and artisans who depended on diesel by reducing the taxation on this fuel for the first time.

Tests are an essential part of our codebase. At the very least, they minimize the risk of regression when we modify our code. There are several types of tests, and each has a specific role: unit tests, integration tests, component tests, contract tests and end-to-end tests. Therefore, it is crucial to understand the role of each type of test to leverage its potential.

This article describes a strategy to use them to test Java Spring Boot microservices. It presents each type of test’s role, scope, and tooling.

Component tests allow testing complete use cases from end to end. However, they are often expensive, especially in terms of setup and execution time. Thus, thought needs to be given to defining their scope. Nevertheless, they are required to check and document the overall behaviour of the application or the microservice.

I have noticed that, in the context of microservices, these tests are cost-effective. Indeed, they can be easy to set up as it is often possible to use the already existing external API of the microservice without needing additional elements (like a fake server, for instance). Moreover, the scope of a microservice is generally limited and can be tested exhaustively in isolation.

This article aims to show how to make these tests robust. The main idea is to make them independent of the implementation.

In a microservices architecture, several things could go wrong. For example, a middleware, the network or the service you want to contact could be down. In this world of uncertainty, you have to anticipate problems to avoid breaking the entire chain and throwing an error to the end-user when you could offer a partially degraded service instead.

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

I often encounter pieces of code that look 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 must be taken depending on the weather. This kind of code is pretty hard to test and maintain. This short article aims 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.