A little while ago I republished my guide to compiling the boost libraries on Mac OS X (You can still read it here if you're interested. Anyway, time has gone on and I've been involved recently with refactoring a large project that uses some bits of boost. During various discussions with people far cleverer than myself, it was pointed out to me that there is no need to precompile boost at all.

OK, so you probably know that you can use most of boost with only the headers, but when you want to get down and dirty with threads or regex you need to compile the sources. This has always been a bit of a pain as it involves messing around with bjam and command line options to get exactly the right bits you need. Then on the Mac you have to worry about all the linking crazyness of install names and run time search paths to get your application to load.

Anyway, forget all that. If you want to use boost threads, just drag the sources into your project. You can find them in under lib/threads/src (On Unix don't include win32 folder, and on Windows don't include the pthread one) in your boost folder and setup the correct header search paths. This allows you to compile the boost threads directly into your project, which is frankly much easier than messing around with linking to static or dynamic libraries in my opinion. You can do this with any bits of boost you want.

In future this is what I'll be doing. For larger projects it might make sense to go down the whole bjam route but for personal project this is the way to go.

Well, well, well, hasn't it been a while. My posting has reached an all time low over the last few months. I've been almost silent on the internet, even Twitter has mostly been devoid of my usual drivel. There's an excuse though, I've been busy moving house and stressing about all house moving related activities. We're not quite done yet, but we've sold my old abode and are looking forward to moving into our nice new house at the start of May. In the meantime we all shacked up with my parents, which as you can imagine is far from ideal, particularly with our rather noisy baby and my mums cats running wild.

Anyway, that one I can almost tick off of the years to do list. Now perhaps I can concentrate on some of the other things I wanted to do this year. Watch this space!

A long time ago on another blog, I wrote a quick guide for compiling the Boost libraries on Mac OS X. That blog has since gone the way of the Dodo but I forgot to make a copy of the guide. Since I've needed to compile Boost again I thought I'd recreate the guide here so I can access it easily and it can be available to anyone else who may need to do the same thing.

Working with plain old strings in C can be a bit of a pain, but one of the nice things about C strings and the Standard Libraries is the use of format strings. Apple have done a good job of carrying format strings over to its Cocoa framework but I’ve found that most of the C++ libraries I use don’t use support them.

While working on a bit of code today I figured out a nice way to convert a format string into a regular string. I’ve written a convenience method to demonstrate this technique that will output the string to a std::string. It’s quite straight forward if you understand how to work with variable argument lists. Here’s the source:

std::string formatString( const char *inFormat, va_list inVargs )
{
    std::string result;

    if( !inFormat )
    {
        // Return an empty string if we're passed a null pointer.
        return result;
    }

    // Copy the varg list so we can use it safely.
    va_list vargs;
    va_copy( vargs, inVargs );

    // Find the length of the buffer required for the string.
    int formatStringLength = vsnprintf( NULL, 0, inFormat, vargs ) + 1;
    va_end( vargs );

    // Allocate a buffer big enough for our format string.
    char *tempString = new char[formatStringLength];

    try
    {
        // Get a fresh copy of the varg list.
        va_copy( vargs, inVargs );

        // Convert our format string into a plain old string.
        vsnprintf( tempString, formatStringLength, inFormat, vargs );
        va_end( vargs );

        // Log the string.
        result = tempString;

        // Deallocate the temp string.
        delete tempString;
    }
    catch( ... )
    {
        // Clean up and rethrow.
        delete tempString;
        throw;
    }

    return result;
}


std::string formatString( const char *inFormat, ... )
{
    va_list vargs;
    va_start( vargs, inFormat );
    std::string result = formatString( inFormat, vargs );
    va_end( vargs );
    return result;
}

The magic here is in the use of the vsnprintf which is a safe version of sprintf. It will return the size of the string if the input buffer is not large enough. We can take advantage of this to ensure our string buffer is always big enough. I’m not sure how portable this code is. It works for me in XCode using GCC but your milage may vary.

Infinity Blade is currently on sale for half price on the app store. I figured I’d download a copy to see if it was as good as I heard. It was. The game play combines touch based sword combat with some RPG elements. You move through a somewhat linear path through a castle (Although there are some branches) battling imposing demons along the way.

Battles involve swiping the screen to slash with your sword. Blindly slashing away at the screen does little damage to your enemy, instead you must block, dodge or parry to open them up for combo attacks to deal real damage. It’s a simple concept that works well with the touchscreen. I’ve found it works better on the smaller iPhone screen than the iPad, as the iPad is a little difficult to hold while slashing and hitting the context buttons to dodge and cast spells.

After each battle you are awarded loot and experience points. Levelling up allows stat points to be invested to develop your character. Each equipped weapon or item item earns you experience until it is mastered, at which point it will unlock a new stat point for you. Once mastered a weapon no longer earns experience so you must turn to the shop to buy new kit and spend your hard earned loot. There are a ton of weapons to unlock, each with various stats that help to keep things fresh.

The game is short but has massive replay value. It’s the perfect mobile game as it can be played in short bursts. The end includes a little twist that will force you to continue to play and keep coming back over and over until you’ve unlocked all the gear and truly mastered the combat.

The presentation of the game is probably the best I’ve seen from the app store. Graphically it impresses, the Unreal engine showing the real power and potential of the iOS platform. The soundtrack is also worth mentioning as it really adds to the atmosphere, so plug in those headphones and jack up the volume.

Infinity Blade is highly recommended. All in all, for a game that costs less than the price of a beer you won’t be disappointed.

I said in a previous post that my team had decided to adopt a shorter 2 week sprint period. This has the advantages outlined in my previous post, but there are some problems that it introduces. As developers we are constantly trying to balance the amount of work we can do within a fixed period of time with the quality of that work. Quality is a catch-all term that covers everything from the number of bugs introduced, the look of the user interface and the general cleanliness of the code. Generally, when developers are rushed one or more of these areas become compromised.

The problem with Scrum, and Sprints in general is that we can end up trying to fit too much in. This can be down to either poor planning on our part when tasks are not sufficiently broken down, or just bad estimates in general. Even when we plan things well, the psychological impact of the pressure of knowing that the completion deadline is only a couple of days or weeks away can make developers feel rushed.

The Fix It Later Attitude

When we are rushing to complete a feature it can be easy to do minimal testing and then reply on the poor QA guy to find the actual bugs. Subconsciously I think we know what we are doing, but the safety net of the QA department and knowing that there is the potential to sneak finishing off work into the next sprint as bug fixes will lead a developer down this dark path.

Unfortunately this rarely works. For one, you’ve just made more unnecessary work for the QA guy who now has to investigate all the bugs and write the reports. Even worse, he may miss those insidious little bugs or even some massive holes in functionality. You’ll assume it’s all OK until it is released when your customers start to report problems.

One of the biggest things that can help us in this area is Test Driven Development, it won’t catch everything but it will force us to think in terms of tests that will reduce some bugs. Even without full blown TDD we should still ensure that we unit test properly and take the time to be thorough.

Prizing Function over Form

You might spend ages on the backend code, but end up rushing to finish the User Interface. Problems are usually easy to spot in testing but you’ll inevitably end up getting things bounced straight back to you to fix. In a way this is an extension of the bugs problem. The rush to complete means not spending precious hours aligning controls or making sure things are responsive.

User Interface should not be rushed, it’s the part of the program that the user sees and manipulates. If it doesn’t work well the user will hate it or at least tolerate it until something nicer comes along. So don’t rush UI into QA, instead talk to your peers about what you’ve done, if necessary prototype with a tool such as Balsamiq. Just make sure it’s of a good quality before you throw it over the wall.

Don’t look behind the curtain

The product may look great. The bugs may be few and far between. If the code behind it all is not clean and well put together you have a problem. In the rush to finish on time we can end up taking shortcuts in our code. We do weird things in the implementation, manipulate the meaning of functions and class members through inheritance so we can write less code. Rely on side-effect to make things work rather than having clear and logical paths of execution. It works, but its hard to understand how.

Don’t just judge quality by the end product, think about the code that makes it. In the rush to get things done, we can end up writing poor code. This can of coarse introduce bugs in the short term but it also makes long term maintenance and extension hard, particularly when other people work on your code. We are building up technical debt and one day we, or our team will pay the price.

Writing clean code is hard, but it’s worth doing. Don’t take shortcuts. Avoid over refactoring stuff just to do something else more quickly, only refactor when it makes sense. Make sure you understand the code you write.

To really avoid this we must inspect each others code, this can be done informally with someone around a monitor, but to be really effective use a review tool such as Kiln. This opens up the entire code-base for review. Nobody’s code is safe from review, and while it is scary to think your work will be inspected at this level, it should be embraced as we can all learn from each other and spot mistakes before they get out of hand.

Remember to Pace Yourself

I think these problems can be an inevitable part of Scrum. Particularly if its done badly. Even good developers will make these mistakes from time to time and there is no simple fix for this. I don’t believe that any amount of planning can be perfect. Since we are aiming for just enough planning to get things done in Agile, I think we need to be realistic. As Developers we need to work at a comfortable pace that allows us to get as much done in the given time whilst ensuring that we plan for testing and refactoring. Test Driven Development, Prototyping and Peer Code Reviews are tools that can help avoid mistakes.

As Managers in Scrum, the greatest thing we can do is ensure that the team has time to do things properly. Set realistic goals and if things don’t get finished within a sprint, judge what’s been done by the quality of the work so far and have confidence that a little more time will allow the developer to produce their absolute best work. Developers appreciate being trusted and allowed to set their own bar of quality.

As Developers we need to estimate and plan our work honestly. Take our time to do things properly and produce only our best work. Don’t say things are finished until they really are finished and don’t rush just to game the burndown chart and increase our velocity. Ultimately that’s all irrelevant when compared to good clean code and quality end products. What sets the best developers apart from the rest of the pack is the best take their time, and never compromise on the quality of their work.