Welcome back to the future-proof series! Today I thought I would present to you a case very close to a code refactoring I made recently…
Category: Building future-proof software
Future-proof software. For the longest time, I thought that future-proof software consisted in writing software so good you never need to change it. Over the years, I learned that it is actually software you should be able to change easily. Software that would adapt to future requirements while satisfying the current. Testing is a massive part of that. So is refactoring. Here are some blog posts around these topics.
If you are to embrace new requirements, you must design software so that you can refactor it. If you want to refactor your code, you need to have a way to test its current behaviour no matter how. For a web API, you may even go as far as using Postman to build a test suite.
And remember, whenever you build new production code. Write failing tests. Make the failing tests pass. Push to production. That way you never write unneeded code and if a refactoring is needed you have less to worry about. Yet you have enough to be confident while writing changes.
Git squash merge: non, no, nein, nee, na, nej, não, net
Posted in Building future-proof software, and Did you notice?
Today I will tell you why you should say no to git squash merges. Even better I will show you. First, I will explain what lead me to write this post. Then, I will provide you with steps to reproduce a problem that seems ignored. A problem that will eventually bite you if you keep using git squash merges. No spoilers until you get there. Hopefully, you will get my point. Since the aim of this post is to save you time in the future or even now this will also be the latest entry of my future-proof series.
About a year ago, I wrote a really short post about failing fast not meaning that we should not think first. Now that I think about it, I don’t believe I was fully in the right. The saying about failing fast was never about not thinking too long. It seems to be about experimenting with what you have in mind. We all have great ideas 24/7, cool software designs, new paradigms to try and so on. The point is to try to make things work in your first try, and the next one and so on. Which makes me think about refactoring.
Continuous delivery for free using Docker, CircleCI and Heroku
Posted in .NET Core, Building future-proof software, and Tutorials
Continuous what?
Continuous delivery. You may recall that in my previous post I announced that today’s entry would be revolving around continuous integration. And technically it can count as such since we will cover continuous integration along the next step. That next step is continuous delivery. If you are not familiar with these terms and the concepts behind them I will sum them up briefly.
Basically, continuous integration allows verifying that your codebase still builds and passes tests passing whenever you push changes. Add a trigger to deploy your code to production upon success and you pretty much have the idea around continuous delivery.
.NET Core CLI Tools: Build a web API in 10 minutes
Posted in .NET Core, Building future-proof software, and Tutorials
This tutorial is an introduction to .NET Core CLI tools. More precisely it is about creating a web API using the CLI tools provided for .NET Core. Whether you are a beginner in development or just new to .NET Core this tutorial is for you. However, you need to be familiar with what an API is and unit tests to fully enjoy this tutorial. Today, we will set up a solution grouping an API project and a test project.