Since I started using Google test , I thought I would post a quick note about test driven development.

You can read more about Test Driven Development over on Wikipedia.

Test-Driven Development is related to the test-first programming concepts of Agile development methods, so you could think of it as tests at the start of each Scrum.

So here is Test Driven Development in pseudo code.

{ Remember that the point is to write a good test and then write the least amount of code you can to satisfy that test. }

    Write a test
    Write the least amount of code to pass the test
    WHILE Failing Test DO
    {
        fix bugs, Refactor if necessary
    }
    Have a Beer

I am starting to use GoogleTest in development. I have not started using it YET, but I plan to roll it into my test framework. My little framework connects to a test database, and that is the thing I need to add to Google test.

I will still use my old framework. When I send work out to others , I use my framework so others do not have to worry about a xUnit framework. Not everyone uses xUnit you know.

I am a big believer in test driven development. That is just me and it has served me well.

Google’s framework for writing C++ tests on a variety of platforms (Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit architecture. Supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal and non-fatal failures, type-parameterized tests, various options for running the tests, and XML test report generation.

I think it is great that Google released it.

Now, I write this , and I hope the people that read it take it in the way that it is intended. Light, humorous , constructive criticism. You guys know who you are, and if you read this I owe you a beer.

Messaging systems are becoming just part of the infrastructure. A commodity product in the last couple of years. As an end user, would you write your own mail server ? Your own word processor ?

In the distant past, like 2005, you may have had a lot of good reasons to write your own messaging systems. Cost, dealing with TIBCO, etc. But this is 2008, and times have changed. You did not have the open source software you have today back then.

So here are the five reasons you would want to write your own messaging system.

[1] YOU ARE STUPID

Really, why would you spend all the time and man power to build a messaging system ? If you really wanted some feature, you could put your time into one of the open source messaging systems. Think about it, how long would it take you to build a messaging system and how long would it take just to make sure one of the open source ones fits your needs?

Think about sunk costs, time to market and anything else you want and it is a losing situation.

[2] YOU ARE UNIQUE IN THE WORLD AND HAVE A NEED NO ONE ELSE HAS IN THE WORLD

Sure there are specific needs, but I have not seen a specific need that could not be met by extending a current messaging system. That being said, not everything needs to be on a messaging system. If you are that unique, a different system may be better anyway.

[3] YOU DO NOT REALIZE THAT THERE ARE OPEN SOURCE MESSAGING SYSTEMS

This is common. AMQP has only been around for a couple of years. It is not as mature as one would like, but they are up and coming. RabbitMQ, OpenAMP, Qpid. Check them out. JP Morgan Chase uses them for millions of messages a day in production, so it is pretty good.

[4] YOU WANT TO SELL/WRITE A MESSAGING SYSTEM

Yeah, then you would have to write your own.

[5] THERE IS NO FIFTH REASON

If you disagree just leave a comment in the box below. Or any other place you want, I just might not read it.

Is dead….

I got rid of it over the summer. Raydo started out doing it’s own messaging/server/client thing. That was fine, it needed its own backing store then.

Now since we are using a message store, the message store can take care of persistence now.

The most interesting store is the BDBMessageStore on Qpid. The BDBMessageStore module utilises the BerkelyDB to provide persistence. Cool.

Anyway, the backing store code has been ripped out, thank you very much.

Well, some of you may have wondered what I have been up to. Or maybe not. It has been a while and I have been doing a lot of things and some of them even with Raydo.

So in a way to catch up, here is one thing I did. I moved away from SVN to Mercurial (hg). I did it in steps, first running svn and hg at the same time, and later just stopped committing to svn. Then i just went cold Turkey and turned off SVN, deleting all the files from the public server.

MADE THE SWITCH

First, I have switched to a DVCS, Mercurial.

Mercurial is a cross-platform, distributed revision control tool for software developers. It is mainly implemented using the Python programming language, but includes a binary diff implementation written in C. Mercurial was initially written to run on Linux. It has been ported to Windows, Mac OS X, and most other Unix-like systems.

That blurb, was courtesy of WikiPedia. hg makes it very easy to switch. They are used to co-existing with svn servers. They play nicely together and that is good for everybody. They use two different directories , .hg and .svn so they do not conflict.

WHY?

One of the main problems when working on multiplatform code, is the version control system. a DVCS is so much nicer ( In addition to just being plain better ) when throwing code around. Say I am working on a getting some code working on Linux that works fine on the mac. I want to test out things to see if they work. I can check in code locally, and develop until it works. Sync with the mac, then once I am done , send it to the canonical mercurial server.

I was running on a local svn server , which was fine, but I did not want to constantly leave it on AND I wanted to be able to check code in when [1] I was not on my local network, and [2] I was not online.

THE OTHER DVCS

Yeah, I tried Git, and it was just a pain on Windows. Sure, I am not a big fan of windows by any means, but Git is just hostile toward Windows. With the linux kernel guys using Linux, I think Git will be around for some time. In fact, I would say going forward Git is the leading contender if they can get their stuff together. bzr is coming up a distant third in the race behind mercurial.

I will be back in Chicago for about a little over a week. Just catching up with everybody and doing meetings.

Mmmmmm hot dogs. Only in Chicago…..

Drop me a line if anybody else will be free next week.

Valgrind is a memory checker and dynamic analysis program, named after a Norse myth. So the obvious question is how to pronounce “Valgrind”?  The “grind” is pronounced with a short ‘i’ like “grinned” (rhymes with “tinned”) rather than “grined” (rhymes with “find”). One of the big bonuses is Helgrind, a tool for checking race conditions in multithreaded code. It is still ‘experimental, but you now how ‘experimental’ is when it comes to open source codes.

    I am trying to integrate Valgrind with my unit testing framework, but I haven’t had the time. For Raydo, I develop on OSX, and run the Valgrind & unit tests on Linux, since Valgrind only works on Linux. This will catch Linux memory leaks and memory leaks from my code, but not any memory leaks that are specific to the Window platform or the GUI kit that you are using. Those leaks are the platform’s problem anyway. You will see a lot of memory leaks from other parts of you software , including wxWidgets, when you run Valgrind on Raydo. Such is life.

    Valgrind supports Linux on x86, x86-64 and PowerPC. There are ports to other the *BSD Unixes. There is no port for Microsoft Windows nor are there any plans for one. Valgrind works much better with C++/STL than with straight C. Valgrind does not check ranges in arrays, such as strings in C, which can be a problem.

So if you code C++/C on Linux, I highly recommend Valgrind.

WikiOverlords
Valgrind home page

    Stupid phrase, but a good one. According to Wikipedia, the term came from inside Microsoft. Despite the origin of the word, I still think it is quite descriptive.

    For the last few weeks, as my home grown code has been rolled into Raydo, I am using complete Raydo applications daily, instead of the piecemeal applications I was using before. You know what I mean, first you write an application, then you find another use and you extend it, and on and on and on.

According to our Wiki overlords, eating one’s own dog food has four benefits.

Using one’s own products has four primary benefits:

1. The product’s developers are familiar with using the products they develop.
2. The company’s members have direct knowledge and experience with its products.
3. Users see that the company has confidence in its own products.
4. Technically savvy users in the company, with perhaps a very wide set of business requirements and deployments, are able to discover and report bugs in the products before they are released to the general public.

    I say, sure. Whatever. But I think I have found a fifth benefit. You realize what is annoying to the end user using your product everyday and you want to change whatever feature. People say that writing open source software is like scratching an itch. Well, fixing an annoying GUI is drinking a Old Milwaukee. You deal with it, but you would really rather have a Heineken.

    So you use the application , and the same thing keeps buggin you so you end up tweaking the GUI. Does it a something to the bottom line, not but doing a GUI right is soooooooooo much better than just slapping any old GUI on an application. I guess my time spent at a company that really cares about user interfaces has permanently warped me. User interfaces should be all about the user. Not how the person designing it THINKS the user would use it. I think I am unique, because I wear both hats, I write software for trading , I trade everyday, and I love designing GUI’s. Well, that is more like 2.5 hats, but you get my meaning.

    If you are an engineer designing a GUI, please take a look at this book. Designing bad user interfaces is no way to go through life.

    Well, the build process is going well. On the mac, I have made a shell script that creates the applications for you. For those of who who have not developed on a mac yet, mac applications are actually disguised folders that hold the application along with other information on running the app. Sure, it looks like just an app if you are looking at it in the finder, but it is really folder. Before, we had to build with X-Code ( the free gcc development kit from Apple Computer ) using project files and such. I really did not like going from the command line and make files to xcode JUST to make the application I could click and run. So now there is a new command in the makefile to build all the apps, or you can build the apps by doing a make in the application name and adding ‘.app.

Now onto windows … again.

    Compiling with pthreads-win32 has tons of gotcha’s. Really read the faq on the website. Some of the things I really need to stress is that if you are using an old version of MingW to develop on windows, please get the latest version. Older versions have ‘weirdness’ when it comes to pthreads. And by weirdness, I mean crashes.

    I have to hand it to the developers for putting pthreads ( POSIX 1003.1-2001 ) on Windows. They had to build it on top of the Win32 event model which is not the best. Windows NT, 2000, and XP models are different from Windows Me and the Windows 9X series. Do I think Microsoft will ever put a stake into this things and release a nice built in POSIX pthreads library that runs on all the above platforms? Not likely. Windows Me and the Windows 9X series are pretty close to dead anyway, so just do the NT kernel.

    Now Microsoft does have a pthreads implementation in Microsoft Windows Services for UNIX Version 3.5 from Interix. That runs on NT based systems, and is basically UNIX running inside of a Windows NT based box. Supposedly they have support in SUA 5.2 that I could use to build against. But I won’t. Feel free to try it yourself, but I am going to stay away from the kool-aid. If you are going to install Microsoft Windows Services for UNIX , which is basically a UNIX box, why not just install Fedora or Ubuntu and call it a day?

I know ‘Databased’ is not a word. But it was the best word I could come up with. What I am doing now is connecting my unit test output to a MySql database.

By putting the unit tests, I can look back and see when things failed, which help when I pull old files out of svn. So I can sort by pass/fail test ( which is the most common method ) , the test performed and the class.

This image above is RUnit.php . I will include this file in the php/ subdirectory. It only has three parameters to modify at the top of the file and that is about it.

I use a simple homegrown unit test framework. Yet another C++ unit test framework, like we need another one. I needed a much less specific framework. But a very simple framework.

I use cron to do automated tests. I pull the latest copy out of svn, compile run the unit tests, and store the results in the database. It is pretty sweet, but I do not have the failed compiles feeding into the database yet.