Rosetta ends its mission 

More than two years ago, when I was starting this blog, I  wrote a little post about Rosetta waking up. It was exciting to follow its progress during this time.


Time flies and today the guys in Darmstadt flew it into the comet it’s been orbiting all this time, thus ending its mission. 

Rosetta has been one of the most inspiring space missions in the last years. Its purpose is not just scientific. The Rosetta wake up campaign got children involved and hopefully inspired them. Space missions offer us a look into the unknown, allow us to think big, to imagine our future, to think long term, and to feel proud of what we humans can achieve when we work together.

Rosetta’s journey ended today but scientists and engineers will be learning from its data for years to come, and hopefully its legacy will inspire and amaze us for a much longer time.

Factory classes are (very often) a bad design choice

I’ve seen factory classes used in several of the projects I’ve worked on and in my experience they are misused more often than not. Please note that I am talking  about factory classes, not the factory pattern itself, which is useful in more cases. Let me explain.

Object creation in a factory🙂

One of the most important Object Oriented design best practices is the single responsibility principle. Some people argue that a factory class adheres to this principle: one class (the factory) is responsible for creating objects the right way, and another one to do its job. Following this, what you often find is something like this:

class EnterpriseyClass:

class EnterpriseyClassFactory:
def create_enterprisey_object(a,b): ...
def create_enterprisey_object_with_other_args(c,d): ...

The first problem with this approach is that it’s missing the point of the factory class pattern: the benefit of having a separate factory class is that it can return different object types. For example, you could have a database connection factory class that is able to return a MySql connection or an Oracle connection, each being a different class that follows the same contract. In this way, the class calling the factory doesn’t have to worry about which class should be created, and so the code can be simpler.

However, if the factory class only returns one type, I see no reason to have a separate class. I like to have interfaces that are as clear as possible, at every possible level, from the class design to the UI. Going back to the EnterpriseyClass example, when I am trying to create an object of that class, I don’t have any clear indication that I should use a factory class. You could document that or add a tip as a comment in the constructor, but that is just trying to solve a problem we have created ourselves. Just move the factory method inside the class and get all the benefits of the factory pattern without the problems.

Besides, going back to the topic of class responsibility, I think that the first responsiblity of every class should be providing the means to create a valid object. Moving that responsibility outside of the class is against the very foundations of OO.

The example about the database connections doesn’t have this problem. You still should be able to create a MySql connection if you need to. Using the the factory class gives you the benefit of an additional layer of abstraction, if  you need it, but doesn’t limit or confuse  you.

Code should be as obvious to use as possible. That will make developers who work with it happier, more productive, and their code will have less bugs. Moving  a factory method outside of its class just for the sake of it will make it more confusing. Just don’t do it. Unless you have a very good reason to. Then please comment!🙂

Getting GitPython to work on Windows

So I was getting this very annoying error trying to use GitPython on Windows:

git.exc.GitCommandNotFound: [WinError 2] The system cannot find the file specified

It’s easy to find lots of places advising you to set up the GIT_PYTHON_GIT_EXECUTABLE environment variable. However I still was having issues while trying to do it inside my script (I didn’t want to set up directly in Windows). The trick is that it has to be set not just before the GitPython classes are used, but before they are even imported! I really don’t like having imports in the middle of my scripts, but I guess we have to live with it for now!

Here is a little code sample to help you with that. For extra safety and convenience, I got the install path from the registry:

import os
import winreg

r = winreg.ConnectRegistry(None, winreg.HKEY_LOCAL_MACHINE)
k = winreg.OpenKey(r, r'SOFTWARE\GitForWindows')
install_path = winreg.QueryValueEx(k, 'InstallPath')[0]
git_path =  os.path.join(install_path, 'bin/git.exe')
assert os.path.exists(git_path), "Git path not found"
os.environ['GIT_PYTHON_GIT_EXECUTABLE'] = git_path
from git import Repo # Ugly place to have the import...
empty_repo = Repo.init('some\path') # ... but now we can use Repo succesfully!

A couple of tips to speed up your Maven builds

Maven might not be everyone’s favorite tool but if you work with Java it is very possible you will have to work with it sooner or later. One problem it has is that it is not terribly quick. While trying to save some time while doing builds, I learned a couple of tips that you might find useful. You can really cut your build times if you…:

  • Don’t repeat yourself: Use the -rf option! In a multi-module project, when building a module fails Maven will give you a little tip about using the resume from (-rf) option. Pay attention to it! It should be in the last few lines of the output. Once you have fixed the issue with the module, you can resume the full build with the command provided by Maven itself.
  • Use your hardware: Simply add -T1C to the Maven build command to use all your cores. You can really notice the difference in performance this way. I wonder why Maven doesn’t do this by default.

Hope that’s useful. Feel free to comment to add your own Maven performance tips!

Installing Python’s matplotlib on a clean Ubuntu system

It took me a while to figure out how to get matplotlib installed on my brand new Xubuntu 15.04. I assume the steps should be pretty much the same for other Ubuntu systems.

$ sudo apt-get install libpng12-dev
$ sudo apt-get install libfreetype6-dev
$ sudo apt-get install pip
$ sudo apt-get install python-dev
$ curl -O
$ python
$ pip install matplotlib

You can try that everything is ok by typing python in a terminal and pasting this code in it:

import matplotlib.pyplot as plt

If after that you want to install SciPy and pip install scipy fails take a look here.

I might have missed something, feel free to comment if you have problems following the steps.

What do a sail, a propeller, a F1 car wing and an aircraft wing have in common? (Or why airplanes fly)

They are all airfoils (or hydrofoils if we are talking about a ship propeller).

I have read lots of explanations about how aircraft fly, some better than others, some plain wrong; but I don’t remember (not that I have a great memory anyway) having read anyone where they explain that the concept of an airfoil is the same in all cases: an airfoil forces the air in a different direction (except in the case of some sails), thus creating a force.

In order to understand this, let’s think about how we swim. We basically push the water backwards in order to move forward. Or if we are in the bottom of the pool, we push the water down in order to go up. The air is a fluid, like the water, so we can move it. If we push air backwards, we move upwards too. But we need to push a lot of it to sustain ourselves.

Let’s use another example. You can try this at home. If you put the outer rounded part of a spoon under the flow of water, the water will “stick” to it as it flows down and by the time it leaves the spoon, it will have changed its direction, like this:

The flow of water changes its direction when it moves over the rounded surface. The same thing happens in an airfoil. (Image from

Now imagine the water flow is wind. If the wind travels through a sail with a similar shape it will end up being forced in a perpendicular direction, so the ship will move in t he opposite direction (as we do when we swim). A propeller does the same thing, when it moves through the air or water, it forces the fluid backwards. You can do the same thing with your hand in front of your face. Put your right hand in fron of it, with your palm facing 45º towards you (midway between left and backwards) and turn your elbow quickly to move your hand over your face. You will notice the air hitting your face. This is what a propeller does!

So as we can see the reason why airplanes fly is not such a mystery: when they travel through the air, the wing pushes some air down, in the same way as the spoon. In this case the force is called lift.

Wings have a profile that forces the air downwards. The air sticks to it as the water to the spoon. Since it forces the air down, it generates an upwards force, in the same way move up inside a pool when we push water down.

A F1 car wing does the opposite thing. It moves air up, thus pushing the car down and keeping it on the road.

An F1 rear wing, as we can intuitively see, moves the air up, thus creating downward force. (Image from

So that’s basically it. This is of course a very simplified explanation, but I really think that you don’t need to talk about mathematical formulas and complicated physics to have a basic understanding of how aerodynamics work.

Hope that was useful for someone!

Powermockito behaving differently on debug

Another issue that took me a long time to figure out. I had a failing test, so I started to investigate the issue with the debugger. I was getting close to the point where it failed and then I set up a new breakpoint and rerun the test and… it passed! I made completely sure that it was indeed like that: a breakpoint in one specific line made the test pass, but if I moved the breakpoint to the next line, it failed again.

My first thought was that maybe it was something related to timing, threading… it wasn’t.

In the end, the problem was that the test was using Mockito syntax to stub a method in a mock created with Powermockito. So the solution was just everything to Powermockito, which… well, kind of makes sense, doesn’t it? It was a silly mistake, right?

Yes… but, that very same code had been running successfully hundreds of times on another local checkout of the code. And it was running successfully with that magic breakpoint!

I still love Powermockito, you can do lots of cool stuff with it, but sometimes its behaviour seems a bit erratic. I share this story in case it’s useful for someone, and also in the hope that someone out there has any idea about why it was working before, and why the breakpoint made such a difference.

Happy coding.