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.

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 good reads.

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 tought, and lots of materials and references to follow up on! 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.

It was a great year, let's take a look at the main highlights.

Early in January, I presented a talk at a local meetup, which had a good reception amongst the audience. The fist part of the year was a great period for learning more about distributed systems, event sourcing, and event-driven architectures. The peak of which was attending the Kafka summit in London.

By late August/early September I finished my book Clean code in Python which was a quite challenging experience.

In our profession, attention to detail is of utmost importance. Any good software engineer understands that details matter a lot, as they make the difference between a working unit or a disaster¹.

This is why clean code is not just about formatting or arranging the code. It's neither a foible. It is instead, paying attention exactly to those details that will make a big difference in production.

Let's see some examples of this in Python.