D.A.T.A.E

Damn Acronyms, They Are Everywhere. I'm working on a project which is named as an acronym (IWC) of acronyms (IW CWMP) of acronyms (IW CPE WAN Management Protocol). You need a parser just to understand the project's name. Gotta love it.

Retrofitting unit tests for legacy code

Some time ago I saw a discussion at google test mailing list which made me ask myself how would I go about implementing TDD for a legacy codebase project, based from previous experiences. I came up with a list, open to discussion, which may be useful as a guideline for someone in this situation.

Start with integration tests

Integration tests are ugly and won't give you a lot of information about what went wrong when something does, but you have no chance of running real unit tests in non-injectable code.

Use the integration tests as a safenet to refactor the critical methods, those which will be changed the most during the projects lifetime, which leads me to the next point;

Test as you refactor (or implement new functionality)

If you plan to stop the business and write a kabillion tests for your legacy codebase you're out of luck. Not only you'll fail because the lack of value but you'll spend weeks writing tests and never see the ROI - you'll quickly grow tired.

With integration tests in place take your time to write real unit tests as needed, that is when you implement new functionality or when you plan to refactor something - which should be to implement new functionality or to fix a bug.

KISS

Can't stress this enough: keep your tests simple. You'll notice you end up with 80% boilerplate code, setting up mocks, creating test objects, etc. When that test fails you'll have no clue why was it there in the first place.

This happens a lot with legacy codebases, where stagnant code tends to get quite coupled and messy. If you plan to write a big mega test to cover every use case with a single test, the day it fail you'll quickly know it's not production ready but you'll have no clue why is that.

Mock layers

If you have a project divided in components (even the ugliest legacy code tends have some sort of layers separation, even if coupled with other components) try to create mocks for a whole layer of the application (I ended up with a complete mock of a DB, for example). This will help you in the long run to isolate troublesome modules.

Have a team commitment

If you're working on your own or with a team, make it mandatory to run the tests for each commit. Even better if you can implement a continuous integration server.

Vim Tip: Open file in new tab

How many times have you been on a project which #includes another file and wanted to see what that file was? Well you can navigate the source code tree in a gui if you use eclipse. You can go to File > Open and, again, fight with a nice gui in Notepad. Or you can open up that file with four keystrokes in a real editor, THE real editor. Just use "C-W g f" with the cursor over the filename and it'll open in a new tab, ready for you to hack away more code.

Methods and instance variables: should there be a difference?

Many times I find myself forgetting the parenthesis for a method with no arguments and a nasty compiler error. This reminds me of my Rubyst times. There's no difference between methods and instance variables in Ruby, so this:

class Foo
  @bar
end

foo.bar = 1

Could be changed to

class Foo
  @bar
  def bar=(val) @bar = val end
end

foo.bar = 1

and the dependant objects using the property would use the new behaviour without ever needing a change in the way bar is accessed.

In languages like C++ the parentheses are mandatory so you can have a clear difference between instance variables and methods, and between a method call and a function pointer (which should be referenced as &Foo::bar and not Foo::bar anyway).

All of this always leads to the same conclusion: closing parenthesis should not be needed!

Zomg! happy (late) birthday

Can't believe it... a whole year has gone by and I didn't even notice. The frist psot was over a year ago and now with over a hundred posts in the archives, a second blog [spanish only] starting, many changes in the directions of the articles and a timidly and ever quiet growing reader base, I can say I didn't learn anything at all from the experience.

I bet that's not the kind of speech you were expecting but the message I would like to transmit today is this: to all the people trying to start a blog, do it for fun, nothing more nothing less. Don't expect any kind of epiphany (not even in a web browser form) nor a sudden burst in online popularity (what for anyway?). You may get those as a byproduct of the experience but starting a blog only for that is a recipe for boredom and frustration.

Write, for a whole year, just because it's fun

Write in C

From http://www.youtube.com/watch?v=J5LNTTGDKYo&feature=related Write in C

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
"Write in C."

As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers:
"Write in C."

Write in C, write in C,
Write in C, oh, write in C.
LISP is dead and buried,
Write in C.

I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C.

If you've just spent nearly 30 hours
Debugging some assembly,
Soon you will be glad to
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
BASIC is for wimps.
Write in C.

Write in C, write in C,
Write in C, oh, write in C.
Pascal won't quite cut it.
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
Don't even mention COBOL.
Write in C.

And when the screen is fuzzy,
And the editor is bugging me.
I'm sick of ones and zeros,
Write in C.

A thousand people swear that T.P.
Seven is the one for me.
I hate the word PROCEDURE,
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
PL1 is '80s,
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
The government loves ADA,
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
Java's not quite there yet,
Write in C.

Lighty WTF

Seen @ Lighttpd

242:	srv->srvconf.reject_expect_100_with_417 = 1;

That line should totally be "= 42"

What I like about Linux and C++

Some time ago I worked in a team with a guy who liked programming in Java. Really like it, to the point where the weaknesess of the language were all in his blindspot. I did the only sensible thing a guy like me can do, sent him a mail stating that the lack of closures in Java would doom the language as soon as C++0X comes out.

That is not really my opinion but it sure served my pourpose. Trolling. Obviously I recieved a three page email back, explaining why adopting closures as part of the Java specification was irrelevant due the use of inner classes (?) or something like that, I don't remember now.

I must admit this was not my first time trolling around a language zealot (and it IS fun, let me say it) may this post serve as a public apollogy for those who have suffered it.

What was that long introduction for? There are lots of religious wars amongst programmers. Vim vs emacs, Windows vs Linux, tabs vs spaces. We all know (Vim, Linux, tabs) what are the best options, but fighting is still fun and with due respect for each other quite healthy.

It's difficult to distinguish when "religious fantatism" for a tecnology overcomes pragmatism, making a task much more difficult than it should, instead of simplifing it, because of the use of a specific tool. Take for example watching a movie in console mode. Kudos to whoever can do it, I have better things to do in my spare time.

How does all this relate to Linux, C++ and programming in my twisted mind? What I've noticed about (most) people using C++ and GNU/Linux as a working platform is that we are always complaining. No, I don't mean we're grumpy old dinosaurs (altought you can certainly find a fair share of those too) but you tend to meet people who are much more aware of the limitations they platform of choice has.

In my years as a programmer I've worked with PHP, Java, .NET, Ruby, Linux, Windows, etc. From all these platforms I could say I found people truly offended when told their platform sucks. Most, if not all, C+++Linux (lol, ain't I smart?) programmers I've found so far have one thing in common: they (we) all know both Linux AND C++ suck. They suck hard, C++ syntax is messy, Linux has configuration and portability problems, pointers will screw you at any chance. But we know this.

Far more important than actually choosing the perfect OS, the perfect language, the perfect whatever, choose what better fits your skills and your team, then know your limitations by hearth. It'll save you lots of trouble.

PS: I like the new category, "Grumpy". Here I'll post all kind of rants and subjective opinions I feel like posting.

Grumpy Old Man: What I Hate About SQL

SQL is ugly by itself, it may rightfuly be considered so by its pseudo standarization, the ugly syntax and many other things which don't matter here, but there's something really really stupid, one bit of its syntax which drives me crazy.

Why, why oh why, doesn't the standard allows "SELECT Foo, FROM TABLE" to be valid syntax? I always forget to remove the last comma when there are lots of fields and don't tell me you don't, I know that is a lie!

</rant mode off>

Vim Tip: Folding FTW

I always say methods should have two levels of indentation at most, but even if your code is perfect like mine you may still have to dwell with other people's code (which, obviously, is ugly code), people how may have lots of fun shaping the program like a pyramid.

Not all is lost, you don't have to commit sepuku (at least not for this one). Just use Vim's indent method like this:

:set foldmethod=indent

That should give you a better view of the code flow. As always, use '%' to navigate all those pesky { and }.

Your money or your life!

The sad truth

gdb: debugging multithreaded applications

Few things look cooler than debugging a multithreaded application using TUI through ssh on a client, halfway across the world. There you are, felling the geek of the century when all of the sudden gdb starts jumping from one thread to the other. OMFGBBQ! What are you going to do now?

The scheduler locking policy defines when will thread context swtiches occur. If you are debuging a thead and don't want to be bothered by another then just lock the scheduler.

gdb has a default scheduling locking which defaults to "most annoying", but fortunately you can easily change it: set scheduler-locking

The possible values are:

• off: Disable locking, switches threads whenever gdb damn pleases
• on: Enable locking, won't (ever) switch threads. Beware of deadlocks!
• step: Disable locking while running only

Hopefully this will save you some time.