MADR template for capturing decisions

Ana Radujko Ana Radujko avatar

6 minute read

What is this post about?

Developing a project or a product implies, for the engineering teams, the need to make many decisions to reach their goals. Therefore, the teams are often faced with an inevitable and usually not-so-exciting step: capturing and recording significant decisions. This post will give you a taste of what it takes to make decisions during project or product development and will provide you with a standard that can be used in different contexts.

Building a scalable Redux web app

Pier Roberto Lucisano Pier Roberto Lucisano avatar

11 minute read

Introduction

There is inconsistency in the Redux community on how to use actions. Redux Toolkit documentation suggests the following approach:

[…] we recommend trying to treat actions more as “describing events that occurred”, rather than “setters”.

Why should we treat actions as events rather than setters? Dan Abramov, the founder of Redux, said that Redux doesn’t reinvent event sourcing. It’s up to people how to use it. It’s clear that there isn’t a well-accepted approach towards how to use actions.

How I became a GitLab contributor to fix an issue in our project's CI/CD pipeline

Stefano Tenuta Stefano Tenuta avatar

14 minute read

Introduction

During these months at Facile.it I had to face many challenges regarding the improvement of CI/CD pipelines for the Insurance team, with a strong focus on performance and reusability. The focus on these topics is very important as it allows us to follow GitLab best practices for CI/CD such as the fail fast principle.

💬

Fail fast: On the CI side, devs committing code need to know as quickly as possible if there are issues so they can roll the code back and fix it while it’s fresh in their minds. The idea of “fail fast” helps reduce developer context switching too, which makes for happier DevOps professionals.

– How to keep up with CI/CD best practices - GitLab Blog

On Living Documentation

Veronica Bolognesi Veronica Bolognesi avatar

10 minute read

Today I want to talk about living documentation, having just finished the aptly-named book by Cyrille Martraire, Living Documentation: continuous knowledge sharing by design, published by Pearson.

The need for documentation

Documentation supplements the knowledge we might not have. Lack of knowledge manifests in:

  • Wasted time (finding the missing points or guessing them).
  • Biased decisions due to this lack.
  • Hint: when you don’t know something, you are usually not aware that you don’t know it ;)

Therefore, the time spent harvesting knowledge should be considered as helping to build the stakeholders’ application mental model. This is important because that’s the mental model that developers will use to augment the code, that product owners will use to describe the stories to implement, and that business owners will use to describe their key goals and outcomes.