Software developer blog

IDE vs. VIM

Have you ever seen people engaging in endless debates about what editor do real developers use? Sure you have. You might have even read the xkcd classic on the topic:

I'm sure you've been part of this discussion too.

I'm sure it's not much of a breaking news for you, that this is mostly a religious debate. Talking about it is just as pointless as trying to convince atheists about the existence of God, or vice versa.

That being said, I'd like to go further. Lately I've been hearing people debating about how much of an idiots are those who use vim instead of using an IDE and vice versa. You can go on and on about the wonderful features of Eclipse or InteliJ but you might easily get laughed at in certain circles for not knowing that modern vim versions support most of those things too. You might argue, that IDEs are slow, and can not be effectively used through an SSH link, and be called an idiot for that. You may even start a debate about how mode less mouse based software are for non technical people who can't keep in mind which key does what in which mode, and if they are in the right mode. Eventually someone will tell you that real programmers like modes, because they are effective, and he would be just as wrong as right.

@ //

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.

@ //

JavaScript based slide show

Although I think ActionScript is a well designed language one has to admit it's numerous drawbacks: it's a proprietary format, the interpreter is a poorly written black hole of resources and it is banned from Apple devices from time to time. Few years back one of my colleagues went as far as claiming that he only needs a dual core processor, so that one core is free for working while the other one handles YouTube videos. So here is an advice from me: try to avoid using flash as long as possible. JavaScript has it's own set of drawbacks, but at least it is widely available, and with the appearance of Google's Chrome the race between browsers shifted towards improving their JS platforms significantly in terms of speed, compatibility and reliability.

There are more than a handful of websites that include a slide show of images. However most of them uses a flash based solution. As fate would have it, slide shows are a perfect example of unnecessary usage of flash. In what follows I'd like to show you how easy it is to write one in JavaScript. I will use the Prototype and script.aculo.us frameworks for this example, but it should not take you more than a few minutes to make this work with jQuery. (I may even publish a jQuery version soon.) This is how it will look like:

The images are taken randomly from the website
of the Gallery Diabolus artist community.

@ //

Drop in, Drop out

Well... I couldn't come up with any better name for this:

My original aim was to create a website element, that provides an intuitive way to add, and remove certain things from the users inventory. I didn't really find any good use for it yet, so I decided to make it open source. (Well... you don't have many other choices with JS anyway, since obfuscators are basically useless in protecting code...) It's released under a GPL license, but if you use it be nice and drop me a comment with the link, so that I can check it out.

@ //

Postponable iterator

When I started this blog I had no idea how hard it will be to post useful things without revealing too much about the "top secret" projects we are involved in. 🙂 This time though I've been allowed to release an entire class that turned out to be useful in an application we were developing a while back. The piece of software below was created with a financial support by Uratim Ltd. and can be used under the terms of the GPL license. YAY for free software.

Postponable Iterator source

The iterator pattern is one of the most frequently occurring patterns used in software design. Even before one learns about design patterns inevitably implements an iterator without actually realizing. The problem I came across not so long ago was that I had an iterator that was returning  jobs from job packets that would have to be processed but there were a number of constrains I had to keep in mind:

  • For each job there is a resource assigned for the job. It can only be executed using the resource assigned to it.
  • As long as possible certain resources should not be accessed too frequently. (But they can be accessed more frequently when it is necessary.)
  • Packages are processed semi asynchronously: all jobs in one package are returned at once, but there may be more that one pending package. The maximal number of packages under simultaneous processing is a parameter.
  • When there are too many jobs waiting for a single resource than access times should be gradually decreased to avoid too long waiting times for jobs.
@ //

Gomoku perfect play

The other day I had a very boring job to do. I had to listen to a sound recording of a workshop I've been attending few weeks ago and sum up the ideas that appeared during brain storming. I couldn't come up with any other solution, but to listen to it while playing Gomoku. It's not a time critical game so I could switch back to writing LaTeX code whenever I needed, and since it's quite an easy game, I still had the brain computing power to multitask. (By the way I use GNU screen to manage my terminal sessions, and vim to code so it just seemed convenient to use the BSD Games implementation of Gomoku... pretty old school, huh?)

Anyhow... as most of you probably know Gomoku is a pretty unfair game, as the first player has a winning strategy... but how hard is it to memorize the winning strategy? Is it even possible? Well... I set out on a journey to find out about that. I spent about half an hour to research Google for any existing perfect play algorithms, but didn't have much luck. Next I tried to find out how computer plays Gomoku... The key concept seems to be Minimax search and Alpha-Beta Pruning, but that is a highly heuristic approach, and since I could beat the algorithm as second player, it does not result in a perfect play either. (Although I could guess that even without winning against the computer.)

Well... I'm stuck at this point. I think I'll read what L. Victor Allis has written on the topic in his thesis. But before doing so, I'll have to get back to coding for food. (-;

@ //

Remote editing

To achieve maximal productivity it is very important to choose the right tools for editing your code, and find the configuration that works best for you. When coding on a remote server one has several choices, but each has it's drawbacks. Let's sum up the possibilities.

@ //

Moving your PuTTY config

The general stereotype is, that geeky programmers don't like windows, and to be honest it really is like an annoying aunt: you hate her, but got to put up with her sometimes. Although one must acknowledge windows' virtues, and I'd find it inconvenient to get along without my windows box at home. Not because of windows, but because of software that is only available for windows and don't run on Wine. However when it comes to coding I inevitably find myself opening an SSH connection to my Linux based server. So not surprisingly PuTTY is among the first 3 or 4 applications I install on a fresh windows.

One of the most convenient features of Linux is that configurations are stored in simple files allowing you to just copy them to your new home directory without much trouble. On windows however configurations are hidden deep into the registry making it a real pain to re customize your windows desktop once you replaced your old PC with a new one. Not that if windows was so highly customizable, but it still takes like a day to get all of my settings right. Today was such a day...

@ //