I’ve been meaning to write a compilation of what are some good books on software engineering, for quite some time. Although I previously wrote here some reviews for specific books (for example for Release It!), I wanted to do a general roundup of several titles in a more lightweight fashion rather than some in-depth comment.

I’ve finally compiled such a list in a page for book DNA titled The best books on building high-quality enterprise software.

Sometimes I review code and find some nitpicking issues like trailing white spaces, and missing new lines at the end of files, and they annoy me. I feel this is something that automatic tools should catch, but regardless of whether I should comment that on PR or not, I’d like to elaborate on why it bothers me.

This was a long time ago, circa 2014, I was working on a distributed system. This system was in charge of scanning and monitoring ERP servers, and its architecture was comprised of a main server (a web service), and several sensors which were other agents (in charge of the specific scanning and monitoring). These sensors reported the results back to the main server which contained all the data to display to the users.

Ten years ago, I had very different opinions with respect to some software engineering topics, and in fact, I have even blogged about it. But recently, I’ve come to realize I think differently, so let’s see.

Changing your mind about something is not bad, since it can mean a number of different things: for example, that you have more data that you didn’t have before, that you have more experience, or simply that the facts have changed.

Yeah, I know, it sounds kinda obvious. Read on. That seemingly obvious statement is not actually what I mean.

I'm not talking about a specific programming language. I'm talking about coding as a practice in general. We're used to understanding common languages, from informal ones (like human languages such as English or Spanish), to more formal or restrictive ones (like math).

But all in all, a language is anything you can use to express ideas with. In that sense art is also a language: for a musician music would be his/her language, painting, and so on. For expert chess players, the rules of chess would constitute a language.

An overview of the concept of Hexagonal architecture, also known as ports an adapters. It's a well-known good practice of software engineering to keep the business logic separated from external, uncontrolled dependencies (implementation details), yet something that keeps on happening repeatedly. A design with an hexagonal architecture aims to solve this problem, helping to achieve a clean architecture.

The main idea

The main idea behind the hexagonal architecture is to design our software in a way that external dependencies, or implementation details don't pollute the main purpose of the software we're building: the business logic. Put in a different way: an information system is a solution to a particular problem. We build software because we want something done. In that process, of course we'll have to deal with accidental complexity (the technical nuances of the technology involved in what we're building), after all, software doesn't run in the vacuum. But we don't build a software solution just to tinker with technology, we do it because we want something done. And those technical nuances do tend to change over time. This hinders the maintainability of our software, making it more fragile over time. That's why both aspects need to be as isolated as possible.

Clean code in Python, second edition has been published, and here are the main highlights!

What's new from the previous edition?

The main change is that the book has been updated to Python 3.9. The previous edition was started when Python 3.6 was new, and by the time it got published, Python 3.7 was just recently released. Since then, a lot has changed in Python and the book addresses the new features.

I've been meaning to read this book for a long time, and finally got the chance and finished it! It's been a fantastic journey throughout the main important topics of modern software architecture.

Following the DRY principle, I won't repeat myself, so here's the review I left on GoodReads.

Release It!: Design and Deploy Production-Ready Software by Michael T. Nygard
My rating: 5 of 5 stars

It's a fantastic book about good software engineering from non-traditional viewpoints.

It takes another approach on good practices of software architecture: it considers more than just classic quality attributes, and it makes you think you to architect your system in a way that's not only reliable and with good quality, but also easy to operate with. Concepts such as evolutionary architecture, adaptable architecture are reivewed throughout the chapters on the last section. In particular I enjoyed to read more about how to make the architecture easy to build and integrate continuously, deploy it safely to production, and make changes on it (because, of course, "change is the defining characteristic of software"). It finishes with a great introduction to chaos engineering.

It covers all important topics on good software architecture: stability patterns, deployability, security, how to avoid typical errors (like cascading failures, and what to do in such scenarios), 12-factor app, and more.

I really liked the concept of cynical software: rather than assuming everything is going to be fine, ask what could possible go wrong, and expect (and be prepared to) the software to fail. Failures will inevitable occur, and we have to think what to do about it.

As an experienced software engineering practitioner, it was highly enjoyable for me to read the case studies presented, as their analysis and conclusions were deeply enlightening.

All in all, a fantastic read, which gave me a lot of food for thought.

View all my reviews

Another year, another FOSDEM edition. As always, since this conference grew so big (fact: if you tried to watch all videos in a row, it'll take you about 9 weeks!), chances are, every review you read from the conference will contain something different, and therefore, complementary.

This is what I was able to experience. Let's take a look.

A recurrent theme in FOSDEM seems to be the high concurrency. There were lots of people attending, which made it difficult to make it into some dev-rooms, as they were overcrowded. In addition, some very popular dev-rooms got regular-size rooms where not enough people could fit (for example the PostgreSQL one, as opposed to last year). Because of this, I missed quite a few opportunities.

Another year went by, and although I haven't blogged that much this year, quite a few things did happen. Let's take a quick review of them.

As you know, I attended FOSDEM 2019, back in February, and it was an exhilarating event.

I also took the opportunity to dive more into functional programming with Scala, by completing the online course in Coursera (which I highly recommend).

On the open source front, I started with some humble contributions to the grpc project, with the goal to add asynchronous support for the Python implementation.

FOSDEM19 it's just over, and here are my main highlights!

Saturday

After arriving to Brussels, and then to the venue, I wasn't on time for the first talk that interested me, and then I couldn't make it into the HTTP/3 talk because the room was full, so I decided to get an introduction to the conference by visiting the stands, and networking.

The first talk I attended was VNF development made easy with netmap, which was very good. Even though it's a topic different than what I usually work with, it was a really interesting talk with snippets of C code and low-level operations in the slides, deep technical insights into the details of networking, and quite enjoyable.