It is usually after a disaster (small or big) that people start proclaiming: The application should NOT crash! The application should NOT block waiting for that downstream service! The application should NOT allow unauthorised access! And similar statements describing what the application should NOT do instead of what it should. After such a proclamation and since the statement, or at least the intention behind the statement is reasonable, people are left trying to figure out how to do that.

In my previous posts Sprint velocity, what is it good for? and Better sprint planning with Bayes, I talked about using statistics for more reliable forecasting and for quantifying uncertainty. In this post, I want to show you the code to automate the process, so that us humans can focus on making decisions based on the data. I am going to use Python for this example, because it has great libraries for data science and statistics.

Imagine you are working in a software development team doing Scrum with 2-week sprints. If you are part of a larger organisation, it is likely there are delivery goals that go beyond the next sprint, let’s call them milestones. Inevitably, someone from above is going to ask you: “Are you on track? Are you going to make the next milestone?” This is what happened to me recently, and I struggled to come up with an answer.

Software development teams doing scrum try in one way, or the other to measure their velocity. Velocity is usually measured as the number of completed stories or as the number of completed story points in a sprint. The first one is pretty straight forward, the second one is a bit more elusive, so I am going to explain it further in the next section. Especially, since I’ve seen teams spend quite some effort trying to get the story points right!

In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system. AWS defines serverless as: A serverless architecture is a way to build and run applications and services without having to manage infrastructure. You design your system as a collection of small runtime entities, often connected to queues to exchange messages. AWS offers services like Lambda and SQS to easily provision such systems.

Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck. I was amazed by the simplicity of his process, consisting of small pragmatic steps. So, I decided to put the process to the test in an unfamiliar domain. The kata In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway. I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test.

CloudFormation and Terraform are both tools to describe your infrastructure as code. They enable us to easily provision, re-provision and update our infrastructure without losing control of all the changes. I’ve used both tools many times in different products, and I was never in a situation that either tools let me down. That being said both tools have strengths and weaknesses. On the one hand, Terraform configuration files tend to be more concise and readable, on the other hand CloudFormation offers better support for rotating servers.

In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system. AWS defines serverless as: A serverless architecture is a way to build and run applications and services without having to manage infrastructure. You design your system as a collection of small runtime entities, often connected to queues to exchange messages. AWS offers services like Lambda and SQS to easily provision such systems.

Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck. I was amazed by the simplicity of his process, consisting of small pragmatic steps. So, I decided to put the process to the test in an unfamiliar domain. The kata In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway. I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test.

How should two microservices communicate? Let’s analyze two different communication patterns: Polling: Service B periodically query Service A for the current state of the users and updates its local storage. Event driven: Service A publishes in a queue every time user information is updated. Service B consumes the updates to stay up to date. Using TLA+ we are going to model the two different patterns to see how well they fit our requirements.

In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system. AWS defines serverless as: A serverless architecture is a way to build and run applications and services without having to manage infrastructure. You design your system as a collection of small runtime entities, often connected to queues to exchange messages. AWS offers services like Lambda and SQS to easily provision such systems.

It is usually after a disaster (small or big) that people start proclaiming: The application should NOT crash! The application should NOT block waiting for that downstream service! The application should NOT allow unauthorised access! And similar statements describing what the application should NOT do instead of what it should. After such a proclamation and since the statement, or at least the intention behind the statement is reasonable, people are left trying to figure out how to do that.

In my previous posts Sprint velocity, what is it good for? and Better sprint planning with Bayes, I talked about using statistics for more reliable forecasting and for quantifying uncertainty. In this post, I want to show you the code to automate the process, so that us humans can focus on making decisions based on the data. I am going to use Python for this example, because it has great libraries for data science and statistics.

Imagine you are working in a software development team doing Scrum with 2-week sprints. If you are part of a larger organisation, it is likely there are delivery goals that go beyond the next sprint, let’s call them milestones. Inevitably, someone from above is going to ask you: “Are you on track? Are you going to make the next milestone?” This is what happened to me recently, and I struggled to come up with an answer.

Software development teams doing scrum try in one way, or the other to measure their velocity. Velocity is usually measured as the number of completed stories or as the number of completed story points in a sprint. The first one is pretty straight forward, the second one is a bit more elusive, so I am going to explain it further in the next section. Especially, since I’ve seen teams spend quite some effort trying to get the story points right!

Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck. I was amazed by the simplicity of his process, consisting of small pragmatic steps. So, I decided to put the process to the test in an unfamiliar domain. The kata In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway. I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test.

This is a blog post about the trade-offs I’ve observed during agile software delivery with test driven development (TDD). Agile and TDD are amazing, and I use them daily. My hope is that by raising awareness about the trade-offs of our decisions, while applying Agile and TDD, will help us make better decisions. Agile software development Agile software development is a balance of two priorities. On the one hand, we need to develop an application that satisfies the current requirements completely, correctly and economically.

When developing a new feature, I found that the use of the Null Object pattern can help keep the code releasable and naturally leads to the creation of a feature toggle. Introduction Every time I need to add some new functionality in my application, I face the same challenges, I need to make sure that my every commit does not introduce any regressions and also that I commit often so that my teammates and I always work on the latest code.

How should two microservices communicate? Let’s analyze two different communication patterns: Polling: Service B periodically query Service A for the current state of the users and updates its local storage. Event driven: Service A publishes in a queue every time user information is updated. Service B consumes the updates to stay up to date. Using TLA+ we are going to model the two different patterns to see how well they fit our requirements.

In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system. AWS defines serverless as: A serverless architecture is a way to build and run applications and services without having to manage infrastructure. You design your system as a collection of small runtime entities, often connected to queues to exchange messages. AWS offers services like Lambda and SQS to easily provision such systems.