Opinion

Recently I got to be an admin over a few hosts. These hosts were all CentOS-based and in terrible shape. Missing repos, different versions, weird software installed on them. It turns out administrators cloned the VMs, and as time passed, they updated some of them, leaving some behind.

I had an interesting discussion today that I think is worth writing about. I mentioned having a problem with having a very fat component in a system since integration tests usually become a nightmare. The idea was raised that architecture should not be driven by integration tests, but rather by customer requirements and value. While at face value, this seems intuitively correct, is that so?

Having the adhesive build process as code it's a nice feature to have. In combination with containers it makes the source code the only truth on how the build is being performed. But that still means we have a dependency now on the build system itself. So how do we get rid of it? We're going to containerize the local build system.

Sometimes things in life are simple. Python in particular allows checking if iterables or strings are empty, and if values are False, with just the not operator. Sometimes life is not that simple :).

Since 2014 I was using Pathogen to manage my Vim plugins. This Tuesday (19th of March, 2019), after a lot of deliberation I finally moved to Vundle. I couldn't be happier.

Roughly 10 years ago, there used to be a time when I really believed Java was the answer to almost everything. JSF2 was just appearing, and the component model they had was amazing. GWT was out in full swing, with the plan to conquer the world. EJB3 were the next big thing. Ten years later it is all dust. Sic transit gloria mundi.

So in the yesterday's article I ranted on why shell scripting in general, with bash in particular is terrible. But there's a reason why we write shell scripts, namely that we're in the same domain of the commands that we know. Here's how to use the same knowledge in the python scripts:

I have a love hate relationship with Bash. On one hand, I have a lot of scripts still running on it. On the other hand, almost all of them were started before I consciously decided that for most things I'll switch to Python. Here are 5 problems that I see with Shell programming:

After the article from yesterday where we got to see some code where code duplication actually improved the tests, we'll look at something similar today, but this time in unit tests, and why I'm not a big fan generally speaking of test parametrization.

This time we're going to look at a simple example of well written, compact code, and make it larger. And better.