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.