Jack White takes development environment closer to production

I read in the news that Jack White performed the sound mix from his car during production for his 2014 album 'Lazaretto'.

I'm not the first one to reflect on Jack White's approach to music applied to software development. Basecamp guys already did.

You can check by yourself the results.

Git ahead

Almost since I started using git I found myself following the tip 'don't git pull, use git fetch and git merge'. I have found this tip useful specially to prevent unexpected disruptive changes to come to my local branch.

I used to fetch changes and take a look at incoming commits with the command:

git log <current branch>..origin/<current branch>

In my work environment, our git repo has grown quite a bit and the names of the branches have started to get longer and longer. Besides, I thought there should be a way to not have to tell git the name of the current branch, since it already knows its name. So I included this alias in my git configuration.

git config --global alias.ahead '!git log HEAD..$(git rev-parse --abbrev-ref --symbolic-full-name @{u})'

So now I can simply write git ahead after fetching from remote to get the log of incoming commits for the current branch I'm working on.

QA is not just testing

I recently faced a tough technical problem at work. We had an issue with a custom MySQL plugin that provoked a crash during reboots. The problem was introduced with a major change in our build system and development environment. It was kind of a big deal and a great stopper for a couple of weeks, during which we didn't know the solution, not even if the solution was in our hands. We had a lot of work to rollback if we wouldn't find the cause of the problem, so a lot of people got nervous. But we finally found the solution: we introduced a bug in our build scripts (more details).

Once it was solved, QA people asked to have a reboot test in our regression suite to prevent similar problems in the future, and immediately put hands on to create the test and include it in our regression.

I found that to be a bad idea, it would make our regression take longer time. It is the test suite we use to validate every change to the codebase, and it is already quite bloated. We are struggling to keep its coverage but reduce the time it takes for it to run. It is a priority target to improve time for the feedback loop. And now we will have a single test case rebooting our system, which will take around 5-10 minutes more.

Then I thought why it took us that long to find the bug in the build scripts for MySQL plugins. We would have found the source of the problem much faster if we had checked for dynamic linkage dependencies in two versions of the plugin binary: one compiled using the former build scripts and the new one. But we did perform that check by visual inspection of ldd command output, and we had around 50 items in both lists that looked the same at first sight.

The thing is our plugin actually needed just 10 out of those 50 dynamic linkage dependencies, and it would have been far easier to locate the offending libraries in a list of 10 items. So there was a lot of noise in ldd output, which was preventing us to locate potencial errors. It's a similar situation as when you don't care about compiler warnings and your compilation output gets filled with hundreds or thousands of warning messages that no one ever reads. You will eventually face the situation of finding a bug after several days or weeks of debugging and testing and then realize that there was a warning message for the very same code line you changed to fix the bug.

So quality assurance (QA) is not just bloating your regression test suite with one more test case every time a new, unforeseen scenario pops up. QA is also keeping the house clean and quite so that there is little place for bugs to hide. And that, my friends, is something beyond the scope of testing.

Two years gap

It's been more than two years between my two last posts on this blog. That's far away from my initial attempt to write one post a week.

It's not that I need to justify it, but I'd like to recall what's been going on in my life during this two years.

• My first son and second child was born in April 2013. We are four, and we are happier than before.
• I found a new job at Ericsson, as a research and development engineer. I joined the company in January 2012 and I'm currently playing a role as a technical team leader for a development team in SAPC.
• I had and overcame cancer. I had a rare kind of cancer: liposarcoma. I got a fat tumor removed from my right armpit in February 2012, followed by 6 weeks of radiotherapy between April and June. I currently have regular reviews and everything is fine. According to statistics, the probability of the tumor coming back after treatment is 5%, and decreases along time.
• I completed a Master in Software Engineering that started in February 2012 and ended in July 2013.
• I learned about Coursera and its wonderful course offering. I accomplished the course Functional Programming Principles in Scala in November 2013.

The main reason for not writing any posts during this time is that I was too busy taking care of my family, my own health, my job and my training. So almost any spare time that I could spend using my computer at home was devoted to studying.

I hope I can write here regularly from now on, but one post a week is probably a too ambitious goal to meet. Let's see how I get by and go on with it.

The code protection smell

I like the concept of code smell. It recalls the idea of identifying something that you dislike, but cannot tell exactly why. You don't have a good reason, but just a feeling that it's wrong.

I recently found a new type of code smell at work. One of my colleagues - a highly skilled developer who I respect and enjoy working with -, told me he was taking a concrete design decision pursuing that other programmers could not later misuse it. He was implementing a C++ class hierarchy and he wanted to prevent others to freely instantiate objects using operator new.

We discussed technical options to achieve what he wanted but I had a weird feeling during the conversation. In the end I recommended him to discard the idea and simply don't implement what I then called a bad programmer protection. I call it simply code protection now. Second thoughts on the matter led me to identify a twofold kind of code smell.

First, it is a pure technical smell in the sense that you are writing code in order to implement what is not a business requirement. One may argue here that proper code formatting is not a business requirement but accepted to be good practice. Code readability might not be a business requirement itself, but it is important for maintainability, and that is (or should) always be a business requirement.

The other side of the smell is organisational. Even if you implement your design in a way that makes it hard for others to misuse it, you cannot prevent others to rewrite it in a way that protection gets nullified or just removed. So it is an indicator that you doubt about your co-workers capability and good judgement.

Syntax Highlighting II

The first time I looked up for a method to include code snippets into my blog entries, I came up with a solution based upon using the service provided by the site tohtml.com. I blogged about it.

This approach had a couple of drawbacks:

1. Highlighting is based upon HTML tags. Hence code edition is a cumbersome task since the easiest way to do it is to take te code snippet back to tohtml.com, edit it, generate the HTML code again and replace it in the post.
2. The generated HTML code doesn't use CSS. So customizing it is hard and changing its style requires to generate the code again.
3. The code snippet is part of the articles text so its width is limited. This affects readability and requires some custom line breaking.

So after I read the post How to embed snippets in your blog, I gave it a try and switch to use GitHub's gists.

Using this approach overcomes the first and third drawbacks. And the second is not a serious problem since now code snippets appear enclosed into a text box, so even if I would change the background to a dark color, snippets will still look good.

The only disadvantage is that I lose the possibility of highlighting parts of the code snippet (e.g. using a bold font or yellow marker style for just one line), but I certainly like it much more the way code snippets look in the blog now.

The rename command

I bought a new home NAS drive and started copying the bunch of pictures in my computer to it. So I faced the problem that either nautilus, SMB or the network drive's filesystem couldn't manage file names having special shell characters.

I happened to have some old picture files that I initially stored in a Windows machine and later moved to my current linux system. The pictures were taken during my semester abroad in Copenhagen, and I found it nice to use the danish name of Copenhagen for the picture file names. So the names of these files initially looked like

København-21042003 <three digits>.jpg

and after moving them into my linux ext3 drive they looked like

K?benhavn-21042003 <three digits>.jpg

which has an interrogation mark ('?') instead of the danish letter 'ø'.

Besides the fact that this kind of file names becomes a shell issue, it's been a while since I decided to avoid file names having spaces and/or letter that are not in the english alfabet, e.g. my beloved 'ñ'. It's a simple rule which is not a pain to follow and just makes life easier.

So I could manually rename all the files one at a time using the nautilus interface (right click menu). But considering that the amount of files raised up to more than 50, I thought it might be easier to use the shell.

I remembered that a while ago, at work, I had to write a script that copied some files renaming them performing a substitution of a pattern in the file names like

literalfoo.ext -> literalbar.ext

and I used a variable to store the file name, then edited its value using sed, and then actually copying the files. So my first thought was to do the same moving instead of copying. But I suspected there should be a tool for easy multiple file renaming and I googled it.

So that's how I found this article in the Debian Adminstration Site and learned about the rename command. So I just had to use this command line

$ rename 's/K.*-(.*\.jpg)/Koebenhavn-\1/' *.jpg

to turn all the file names into

Koebenhavn-21042003 <three digits>.jpg

And the best thing about it was the '-n' option that performs a dry run that just prints out what the command would do, so it lets you try and refine your regular expressions if you are not too familiar with them (as is my case).