Software developer blog

The Bowling Game Kata with commentary

I have just released a code cast in which I do Bob Martins version of the bowling game kata in php, but take it further with a refactoring.

Test driven mockery

This year I have talked at different Hungarian venues about software development related topics several times. Although these presentations are captured on video and are available on the internet they are in Hungarian, so I decided that the next few posts will explore some of them in English, and in more depth.

I gave the Test Driven Mockery talk at the April event of PHP Meetup Budapest. Although code examples and frameworks are in PHP, the talk is basically language agnostic, and it's just as useful for PHP programmers as it is for Java, C#, Ruby or even C++ coders. After all: it's about test doubles in general.

At the time of writing this blog entry more and more software developers and companies decide to adapt test driven development as one of their primary practices to avoid code rot and fear of change. Of course there are crowds who still haven't even tried TDD either because they haven't heard about it, or it sounded too weird for them to try. However there is another lot more interesting group of educated professionals who after practicing TDD for a considerable amount of time decide to abandon it. As I was talking with a group of these people I recognized that most of the time their disappointment in the technique is easily tracked back to their misunderstanding of a very important related topic: test doubles and mocking. On one hand if you completely avoid using them you end up with a slow and fragile test suite that's hard to maintain, but if you use too many of them the promise of ease of change, well tested and flexible code becomes a lie. Finding a good balance is kind of an art.

Legacy Coderetreat

Yesterday we held our first Legacy Codereatreat in Budapest. While it is very similar in concept to regular Coderetreats, there are some very important differences. We start the day by introducing an existing legacy code base - a rather ugly one - and let the pairs figure out what it does. Yesterday we've been using the trivia code base on GitHub, so that participants could choose from a large variety of languages, but still have approximately the same code base.

Legacy coderetreaters at Emarsys Technologies Ltd., Budapest

Legacy coderetreaters at Emarsys Technologies Ltd., Budapest

According to Michael Feathers' definition of legacy code: "it is code without tests". So after the first getting to know session the next session was about adding characterization tests to the code that would help us during the remaining sessions. Since the only UI to the application are log messages, but they are scattered all around the code base, it is a relatively safe test suit to generate runs with random inputs, and save the output for reference. It won't help in figuring out where the error is, but it will catch most of the mistakes one makes during refactoring. They can also help when adding behaviour, but when fixing bugs they will brake, and need to be replaced.

@ //

Changing requirements

About 9 month ago as we were preparing for the next Coderetreat Athos came up with an idea for a game he called the changing requirements. I liked the idea from the get go, since I think that in becoming a software developer the hard part is learning how to react to business needs. At least for me that took a lot more time than to write my very first game in QBasic as a little kid.  The really sad part is that one can graduate university without ever even realizing that he is missing one of the software craftsmens most important virtues.

What I found really appealing in the concept of Coderetreats was that it provided a forum for professionals to learn about techniques that can help in dealing with change. On the other hand it is about getting away from the pressure of getting it done, and by that it takes these techniques out of context. It's kind of the price for letting you concentrate on practice.

The changing requirements game is something we like to play as the very last session of a Coderetreat. By that time the participants have learned a lot of new things, and have become familiar with game of life. The session is 90 minutes long  - enough time for a pair to finish the job - but we come up with requirement changes at times when it's already too late to incorporate that into the design without substantial refactoring. If the pair has already learned how to do evolutionary design they will easily adapt, otherwise they will have quite a bad time. Either way they will hate the facilitator for a second, and then they will get really excited about the problem.

Stare dad stirkes

Last week we had our 4th Coderetreat in Budapest with about 15 participants. This time I was an organizer along with Athos, and we decided to advertise the event at several different meetups. While preparing slides for the talks we realized that on one of the slides we had some free space we could not really fill... so we came up with the idea of putting an image macro there. And that's how Uncle Bane was born:

Uncle Bob will probably approve this message...

That kind of unleashed an entire flow of crazy meme ideas, so I decided to popularize the Coderetreat event by posting these memes on the groups Facebook page. (Check them here.) The meme that turned out to be the most successful was this one:

Stare dad

That's exactly how I'd react...

I talked about "The Clean Coder" by Uncle Bob Martin (HUN)

On Thursday I was talking about Uncle Bob Martins book, "The Clean Coder" on a meetup organized by Agile Hungary. The talk was in Hungarian, but it's already available on YouTube (not embeddable, so please follow the link), along with the slides on SlideShare:

@ //

Unit test framework for C++ in about a 100 lines

Those who know me well are also aware of the fact, that I'm a very strong proponent of test automation and test driven development. Unfortunately there are times in our lives when installing an existing framework is not an option. So when I've been challenged to write a test framework that is so simple one can memorize it, and flush it out of their brain anytime needed, I was up to the task. The entire framework is 113 lines of C++ code, and using it is just as simple as using google test. Of course it doesn't come with all the features, it's fragile and has a good number of limitations, but it's good enough if you have absolutely no other option.

Here is how to use it, along with a sample output:

#include "TestBase.hpp"
 
class TestGroup : public TestBase {
};
 
TEST_F(TestGroup,PassingTest)
{
	EXPECT_TRUE(true);
	EXPECT_TRUE(true);
}
 
TEST_F(TestGroup,FailingTest)
{
	EXPECT_TRUE(true);
	EXPECT_TRUE(false);
	EXPECT_TRUE(true);
}
 
TEST_F(TestGroup,SecondPassingTest)
{
	EXPECT_TRUE(true);
	EXPECT_TRUE(true);
}
Sample output

Sample output of a simple unit test framework

Game of Life on the GPU

Conway's Game of Life is one of the most popular code katas, and the one we will exercise on our next code retreat this Saturday. I have done this kata, quite a number of times, but this time there was a twist: I used the GPU on my Nvidia GTX 560 to calculate the steps of evolution, and to draw them as well. Here is how the result looks like:

Puffer train in Game of Life

Puffer train in Game of Life. Living cells are green, they increase the blue chanel by 1 in each generation, and leave a faiding red trail after they die.

The igniter of this exercise was that I read a book on CUDA programing, and it was quite a disappointment. The examples were really far from anything I would call clean code, or at least easy to understand: it was spaghetti with huge meatballs in it. That kind of examples require a lot of explanation, which basically took up most of the books volume, and there was little left for the useful stuff. So I got curious: is it CUDA that promotes bad code, or the writers of the book didn't care enough? I had a preconception that there was nothing wrong with CUDA  - and actually it's a pretty neat language - so I set out on a quest to code Game of Life in CUDA, and try to make it as clean as possible.  I don't claim, that my code is perfect, but I hope it's going to be an easy read for anyone who tries.

You can download the result of my quest by clicking here, or just browse it as HTML by clicking here. The rest of the blog entry - basically a retrospective of the project, and a few remarks on CUDA features - might not make much sense without looking at parts of the code. If you'd like to compile, than you will need the nvcc compiler for CUDA, the CUDA Toolkit, GLUT and GoogleTest to run my unit tests. Please note, that the code is not production quality: it may well throw exceptions at you, it's only tested on Ubuntu, and it is not performance optimized in any way. (Even the algorithm is the most naive one.)

@ //

How to generate a random binary tree and visualize it with Graphviz

Yesterday I was testing a small piece of code, that was capable of finding the nth item in the in-order traversal of a binary tree. It was a template function with the root node and n as arguments, and only required that the children nodes should be pointed by public members "left" and "right", while unused children pointers are NULL. (Pretty much the old school way of doing it.)

Of course I didn't want to manually generate test cases. Instead I wrote a little function that can generate a large tree on demand, and used that. Since the boost random library uses a constant seed by default I can rely on the tree to be the same each time the test is ran.

@ //

Code for fun

Yesterday I was participating in the Budapest event of Global Day of Coderetreat. It was a very intensive day of coding in pairs. The basic idea is that the same programming task - specifically the implementation of Conway's Game of Life - is repeated in six 45 minute sessions. Since the pairs were switched after every other session, and people came from different backgrounds, this was a great opportunity to learn from each other. Also one could try different design decisions, and see what are the benefits and liabilities of each.

Pair coding on the Global Day of Codetreat, Budapest

For me this was the first time I did real pair coding, and the most important experience of the day for me was that pair coding is good, good, GOOD. 🙂 Even better for me was when we were doing TDD ping-pong with Athos.

@ //
Next Page »