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.

I’ve been trying to learn a bit of Python for various reasons over the last week or so. I’ve always hated the look of any code written in it, but I’m slowly being won round by how expressive the language is. It’s amazing what you can do with a tiny fraction of the code required in C++. I’m at the stage now where I’m thinking of how I might use Python scripts to extend a C++ application or drive a game engine that I’ve written.

First things first, how can I run a Python script from within my own C code? I read through the guide at Python.org that makes it seem simple enough. However there is a massive omission from this guide as far as I can tell. On my Mac it seems that the PyImport_Import command always fails when I try to import any script in the working directory of my code. I could import the built in modules susch as Sys but nothing from a script I’d written.

After a bit of googling and experimentation it seems like you have to add the path to the folder that the script is in to the Python search directory. If I use the following code snippet to initialise Python it works:–

// Initialise Python.
Py_Initialize();

// Add our working directory to the system path.
PyRun_SimpleString("import sys");
PyRun_SimpleString("sys.path.append(\"\")");

If you want to use an absolute path to the script you will need to strip off the script name. Add the path to the system path and then load your script.

It’s also worth mentioning you can do this using a combination of Py_GetPath and PySys_SetPath calls from the C API to append the new path. The downside to this is that your code will be less portable because of the difference between the way Windows and Unix Python systems separate the path strings. Windows uses a semi-colon while Unix uses a colon “:”.

Another thing I’ve found is that a shortcut to loading a module is to use the PyImport_ImportModule function rather than plain old PyImport_Import. This takes a c string as a parameter rather than a PyObject which makes the code a little cleaner.

Now that’s working I’m going to attempt to get code from the application called from the script I’m loading. Exciting stuff! If you’re into that sort of thing. No doubt I’ll be posting more on this later. For now, let me know if this was any help or you’ve anything to add in the comments.

Ignore this, just testing.

int main(int argc, const char *argv[])
{
    int i = 0;
    printf("Hello World!");
}

Little XCode tip for you. Using the #pragma mark directive is great for adding some structure to your source code. I won’t go on about that as there a great article describing it here. Just to add to that, I’ve found that when I’m knocking out code it’s sometimes good to add comments in place of the code when you haven’t thought about the implementation of something. If you write “// TODO: ” followed by a comment, the comment will appear in the method list just like the #pragma mark. This allows you to build a little To Do list and clearly mark in the code where you need to do something.

I found that by accident. Anyone know any other code documenting tricks in XCode like that?