March 2014 | while (2)

The 0 Ohm Resistor

If you have some experience in electronics you should know that a resistor with no electrical resistance is (apparently) useless. Why should you pay for this component?

Obviously Wikipedia has the answer for your question. But if you are wondering what this has to do with Computer Science, keep reading and I'll try to explain.

The Zero Ohm Code

One of the purposes of the Zero Ohm resistor is to be a placeholder in case another component is needed in the future. When requirements slightly change, there is no need to change the PCB, but it's sufficient to substitute that resistor with something else.

In software development we can use the same concept. Even if a feature is not needed now, it's not said that in the future a customer won't ask for it. At design time, it cost nothing to you for example to add an unused field in a structure, but when the project is shipped an extra field can require a change in the format of the saved files.

There are many things that can be done with the purpose to write easily extensible code. I will write about some of these in a future post.

Stay tuned for more happy coding!

Update

Here you can find 6 + 1 tips to write easily extensible code.

development, electronics Friday, March 28, 2014 No comments

Everyone Matters

Steve Jobs with the first iPad
(via Matt Buchanan)

As early as 2003, a handful of Apple engineers had figured out how to put multitouch technology in a tablet. “The story was that Steve wanted a device that he could use to read e-mail while on the toilet — that was the extent of the product spec,” says Joshua Strickon, one of the earliest engineers on that project. “But you couldn't build a device with enough battery life to take out of the house, and you couldn't get a chip with enough graphics capability to make it useful. We spent a lot of time trying to figure out just what to do.”

- via New York Times

This is the starting point of the first Apple iPad. At present I don't think that "to read e-mail while on the toilet" is the main purpose of a tablet. Nevertheless we all admire the visionary genius of Steve Jobs, don't we?

But between the vision and the final product there is the work of many people, a lot of sweat and many other strokes of genius. Don't forget this next time someone will say that a complex product is successful only because of a single person.

Apple, specifications, working life Sunday, March 23, 2014 No comments

Useful Git Commands: Blame

How many times, looking a piece of shared code, have you thought "who the hell has written this?!?!" With other VCS all you can do is to scroll the list of changes made to that particular file and look at what is changed.

But Git provides you the blame command that eventually answers your question in a fast and easy way. And, most of the times, you will not like the answer.

You can see a whole file (or just some rows, with the flag -L) annotated with the author and the hash of the commit where each line has been added or changed. And you can also ignore changes in whitespaces with -w.

Sometimes it may be useful to detect if the same lines have been moved inside the file: the flag -M cover this requirement. But what if the lines have been moved from a file to another?

This is the purpose of the flag -C. If the move has been done in the same commit (typically during a refactoring session) the output shows also the file name where those rows originally were.

Check out the man page for all the other options.

Git Tuesday, March 18, 2014 No comments

[Solved] D-Bus Method Call Stops Working After Few Days

D-Bus diagram

This is an issue that I've found some months ago. I've set up a communication system using asynchronous calls made with D-Bus. It all seemed to work fine for a couple of days but suddenly the entire mechanism stopped working without returning any error.

I've searched around if there was a known bug or if someone else was having the same issue but without result. For this reason I write here the solution, hoping this can be useful for other developers.

The Situation

This is the sequence:

create a new method call
append the parameters
send it
free the memory.

Or if you prefer the code:

DBusMessage *msg = dbus_message_new_method_call(dest, path, iface, method);
dbus_message_append_args(
 msg,
 DBUS_TYPE_UINT32,  &int_par,
 DBUS_TYPE_STRING,  &string_par,
 DBUS_TYPE_INVALID  // closes the function parameters
);
dbus_connection_send(bus, msg, NULL);
dbus_message_unref(msg);

Quite linear, isn't it? Unfortunately after a while (I've estimated after 50.000/100.000 calls) the wanted method is no more called but no error is returned when the message is sent.

The Solution

My assumption was that some kind of memory limit was reached, so I've read the documentation carefully and I've found the following function:

dbus_message_set_no_reply(msg, TRUE);

Adding it before dbus_connection_send() made the whole system run for weeks without any problem.

D-Bus, development, solved Thursday, March 13, 2014 No comments

Has Open Source Failed?

Image taken from here

This week has been pretty embarrassing for GNU/Linux estimators. According to ArsTechnica a bug has been found on the GnuTLS library. Basically the authenticity of SSL/TLS certificates was not granted (a similar issue has been found recently on Apple iOS - I mentioned it here).

This bug is present since 2005 (a century in computer science) and it seems to affect a wide range of devices - not only PCs.

During these days I've read several commentators pointing their fingers against the open source philosophy. Probably they are the same people that exult when an error is found on Wikipedia.

To those, I just want to remind that, for example, inside Windows XP Professional there are still 44 unpatched vulnerabilities and a couple of them are present since 2003 (two centuries in computer science).

What we can say is that software - every software - has bugs (by design, let me say). What makes the difference is the speed in fixing them once they have been discovered. And in this case the open source community has been very fast.

So, if you are asking me if open source is perfect, I have to say no. But, in my opinion, is better than closed source under many points of view. And bug fixing is one of them.

bugs, Linux, open source, security Saturday, March 08, 2014 No comments

Indentation Matters

Last week my colleague +Daniele Veneroni told me: "You chose the wrong timing to write a post about the usefulness of goto. Have you heard what happened to Apple?" To make it short, there was a vulnerability into the validation of SSL/TLS connections in iOS devices. According to Sophos, this is the broken code:

. . .
hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
    goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;  /* MISTAKE! THIS LINE SHOULD NOT BE HERE */
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

err = sslRawVerify(...);
. . .

The error is probably a result of a bad copy 'n' paste, not the goto itself. Nonetheless if that line would have been correctly positioned (i.e. at the same level of the if statements), it would be immediately clear to everyone looking the code that something was wrong.

This event gives me the opportunity to talk about something that I consider very important when writing code: the coding style.

Matters of Style

Believe me, I've seen code less readable than this!

When there are at least two people working on the same code, the first thing that can cause problems is the coding style. Tabs versus white spaces, bracket placing, naming style, case, and, over all, indentation.

What is the purpose of the indentation? To make more readable the code. And why you should use descriptive names for variables and functions? For the same reason: readability. Your code should not only be executed by a processor, but also understood by other programmers.

And other programmers are full of laziness, impatience and hubris just like you. So they don't want to read every single row of your code just to add a trivial feature. This is true both in the open and the closed source worlds because if your code is not easy to maintain, it will be abandoned or someone will decide that is cheaper to rewrite it.

My Choices

I have to admit it. Often in the past I've used two-characters indentation and CamelCase names for functions and variables (you know, once I was also known as Mr Pascal).

But now those days are over. What I've decided to do some years ago is to use a different style for every programming language: so, for example, for Python I use PEP8. For C there are at least ten different styles, each one with his supporters (or should I call them ultras?). After a short research I decided for the Linux Kernel coding style.

If you read the document, you'll find that every choice is there for a good reason and the main guideline is always the readability. Because, as Guido Van Rossum said: