Simple Boost Spirit example.

Here's an example of a parser for a really simple domain specific language (DSL) created with Boost's Spirit framework.

Download the full source code

The parser accepts the following input:
new order
*(buy|sell amount stock_name price)
end order

Here are a few examples:
new order
buy 10 ABC 2.50
sell 20 QWE 5.00
end order

new order
buy 10 ABC 2.50
buy 10 ABC 2.50
buy 10 ABC 2.50
sell 20 QWE 5.00
end order

As you can see the input the parser accepts is really simple and I could have probably saved lots of time by writing the parser manually without using any framework. If you download and look at the source code you see it's fairly easy to extend the parser to take much more complicated input.

JUnit reporter for Unitest++

The C++ testing framework Unittest++ includes a XML reporter but it is not directly usable with most continuous integration (CI) servers such as Hudson and TeamCity. I wrote a XML reporter for Unittest++ that uses the same format as JUnit, the reporter will split test suites into different files and they can be directly used by for example the junitreport task in ant or in your CI build. Download the header and cpp files below and add them to your Unittest++ build.

This is how you normally use Unittest++'s built-in XML reporter:

std::ofstream f("test-report.xml");
UnitTest::XmlTestReporter reporter(f);
UnitTest::TestRunner runner(reporter);
return runner.RunTestsIf(UnitTest::Test::GetTestList(), NULL, UnitTest::True(), 0);

Simply replace it with the following,

std::string f = "TESTS-";
UnitTest::JUnitXmlTestReporter reporter(f);
UnitTest::TestRunner runner(reporter);
return runner.RunTestsIf(UnitTest::Test::GetTestList(), NULL, UnitTest::True(), 0);

Note that the JUnit reporter does not take a complete filename because the JUnit format requires that different test suites are split into different files. The output files are named TESTS-suitename.xml.

Download
JUnitXMLTestReporter.h
JUnitXMLTestReporter.cpp

Testing blogging from my iPhone, this seems to work ok. Yay.
Keep an eye on this blog if you are interested in continous integration methods for improving your software team. I am preparing a post on the subject....

Improving upon continuous integration

I am quite a big fan of continuous integration and other automatable "agile practices" for improving performance in software teams. Roughly half a year ago the team I am the scrum master of started improving upon our practices, one of the first tasks was to create a script that made it able to create a release with a single command. With this done we added a continuous integration server (CruiseControl) and started down the path of automated tests & tasks. A couple of months later this has had measurable impact on the time it takes to make releases and as we've added compile & test tasks that run for each commit to SVN, this makes us more confident about the quality of the software we make.

I also hold the believe that nothing is ever perfect and it's always possible to improve and tune your software process. The problem I've been seeing lately is that, yes the continuous server helps us easily find compilation errors, bugs and broken tests. But once the code is in our SVN the damage is already done, we are working on a product with multiple teams in multiple time zones. It's very easy for someone to make a commit that breaks the build and then leave for the day, national holidays, other work assignments etc. I'll shortly outline our current process:

1. Write code & test
2. Check in your changes to the version control system (VCS), such as SVN, GIT etc.
3. Continuous integration server sees a change in the VCS and starts a build, tests and so on.
   
4. If your code fails to compile or have broken some tests you will be notified and hopefully you are able to fix it before other developers update from the VCS.
5. Other developers update from the VCS. They might update before you have had time to fix problems in the code you checked in.
6. The bad code propagates to the whole team or the team might be sitting idle waiting for a fix for the bad code that is already in the VCS.

If you look at this process the crucial part is step 3, this where we get our benefits by finding bugs early but why not move this step to take place before the commit is made? Many teams I've heard about have policies that all developers must run the build and the tests prior to a commit but this breaks down every once in a while. Developers are stressed, they forget, they are lazy (yes!) and make mistakes. So, I've been on the look out for a more robust solution to this problem. I was long aware of SVN various commit hooks but didn't really think of it as being a viable option since it would involve a lot of scripting, configuration and time that we do not just have. Luckily one of the team members pointed out TeamCity to me. TeamCity's pre-tested commit features solves exactly this kind of problem. See there homepage for some nice diagrams.

TeamCity allows us to have the following process:

1. Write code & test
2. Send your code to TeamCity, which can run the same checks and builds as the continuous integration server but before the code is committed to the VCS.
3. TeamCity automatically commits to the VCS if your code compile, pass all tests etc.
4. Other developers update as normally from the VCS but they only get good code.
   

Yes! And it actually works. Well it took two days to set it up and get everything working. The trick was that the build agent must run as the same user as I am normally using since our build process is using cygwin and various cross compilation tools that for some reason didn't work otherwise. I've only been running this for a limited time but I am impressed with TeamCity and it will probably help us in the long run to make better software and more effectively.

A couple of minor caveats:

• TeamCity has no command line tool, so there is no way to script commits. Everything is done with IDE plugins.
  
• Java centric, be ready for a lot of scripting & configuration if your build is complex using lots of different build systems (makefile, vcproj/sln, cygwin etc).
  

Increasing java heap size when using maven

If you get out of memory exceptions while using maven you can tweak the amount of heap space available to the JVM with the following environment variable,

export MAVEN_OPTS=-Xmx512m

I didn't test any other but i presume you can set other Java options also with the same variable.