MatthewStyles.com

Testing Gist Embedding

Mon, 09 Jan 2012 08:51:39 -0800

1 2	# Usual Hello World script in Python. Hey look, this comment is longer than the code! print "Hello World"

If this works, you should be able to see a Hello World script embedded in this post.

Now move along, nothing to see here.

Permalink | Leave a comment »

New Years Goals for 2012

Sun, 01 Jan 2012 05:41:13 -0800

Well here we are, 2012 and this is the first post of the year. I'm sure there will be lots of posts like this one cropping up over the internet over the next few days. This is the post where I vow to blog more often blah blah blah. I think I've written one of these posts at least twice a year for the last couple of years on various blogs and I never manage to stick to it. So why is this year going to be different? I guess it probably won't be but there's no harm in trying.

Rather than ramble on any further, I thought I'd just list my current goals for the year. These aren't Resolutions, they are just things I would like to do or achieve by the end of the year. Over the next few months I'll review my progress and maybe add a few more as I think of them.

Write more blog posts
Start Tweeting again
Publish something on the App Store
Move house
Lose weight (Maybe do some exercise)
Maintain a good work, life balance
Be a good father

Permalink | Leave a comment »

Compiling Boost libraries on Mac OS X

Fri, 09 Dec 2011 12:17:00 -0800

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.

The first thing to do is to download the lastest Boost distribution from the Boost downloads page.
Unpack the archive somewhere sensible, I’d suggest the desktop. Don’t do it where the absolute folder path will have any spaces in the name e.g. “/users/matt/code/bad folder/”, this will prevent the install script from working later. I found this out the hard way.
Next open a terminal window and navigate to the Boost root folder you just unpacked. An easy way to do this is to type "cd" followed by a space, then drag the boost folder onto the terminal window to complete the command and hit return.
Next run the bootstrap script by typing “./bootstrap.sh“. This configures the install tools for your environment. Check it for error messages, this is where I found out my path was bad.
To compile Boost, type “./bjam architecture=x86 address-model=32_64” and press enter, this will build both 32 bit and 64 bit binaries that you can easily link to from XCode.
Make a cup of coffee and wait while the libraries build.

After following the above steps you should end up with dynamic libraries in the stage/lib sub folder of your Boost folder. The above steps have worked for me on both Snow Leopard and Lion with Boost version 1.48.

You can provide some extra options to bjam to get more control over the output, by default you'll get dynamic libraries. These can be a bit of challenge to get working with XCode projects as they don't integrate easily with Cocoa application. To make life a bit easier I prefer to link statically to the Boost stuff. Adding the option link=static will force the output to be static libraries. There's more about the arguments here.

At the time of writing the bjam command has been deprecated in favour of the b2 command. I've experimented with this and at the minute there seems to be a bug which means I only get 64 bit binaries, using bjam with the same options gives me the correct output so I've not switched.

Permalink | Leave a comment »

Ice flows on the Canadian coast

Mon, 04 Apr 2011 13:54:50 -0700

Permalink | Leave a comment »

Converting Format Strings To std::string

Thu, 10 Mar 2011 11:44:00 -0800

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.

Permalink | Leave a comment »

Infinity Blade Review

Tue, 08 Mar 2011 12:56:56 -0800

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.

Permalink | Leave a comment »

Scrum - The Problem with Sprints and Quality

Fri, 04 Mar 2011 06:13:31 -0800

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.

Permalink | Leave a comment »

Running a Python Script from C Code

Sat, 26 Feb 2011 05:34:00 -0800

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.

Permalink | Leave a comment »

Testing Syntax Hilighted Markdown

Sat, 26 Feb 2011 05:10:00 -0800

Ignore this, just testing.

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

Permalink | Leave a comment »

XCode Tip: Adding a To Do Comment

Fri, 25 Feb 2011 07:19:43 -0800

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?

Permalink | Leave a comment »

Scrum - In Favour of Shorter Sprints

Mon, 14 Feb 2011 10:31:16 -0800

My team has recently decided to switch from doing 4 week long Sprints to shorter 2 week sprints. When we started working with Scrum I was against doing short sprints because it just didn’t feel like long enough to get anything done. After 2 years of working this way I’ve changed my mind and we’ve now switched to 2 week sprints. There was some debate about doing this, but I was convinced by the members of my team, and here’s why.

Nothing focuses the mind like an imminent deadline. Knowing that we only have two weeks to get stuff done means we are less likely to be over optimistic in our planning. That doesn’t mean we will plan to do less work, it just means that we plan to do lots of smaller tasks in favour of fewer large tasks. This forces us to break things down into more manageable chunks beforehand.

A developer can dedicate a whole sprint for writing a spec. Writing a spec should never be done within the same sprint as the development, it’s too risky. We can only make a reasonably reliable estimate on the size of the development when we have the spec. So allocate a whole sprint for writing a spec first. It shouldn’t take the whole time but this means the developer is free to do maintenance tasks such as fixing bugs as well. Spending 2 weeks writing a specification and then fixing bugs seems like time well spent to me, while if we do it over 4 weeks it will be too late to start development in order to fit our release schedule.

The Sprint Review is a great time to demo the completed work to the project stakeholders and is often the only opportunity to do it. Making the meeting more often means we can get feedback from stakeholders quicker, which means we can reassess and change coarse more quickly and lessens the risk of a project going off track. Feedback is vital during development, and the early the feedback and more often the better.

We can plan for new things more often. A common complaint from people outside of the Scrum process is that when they report a bugs or new features we always say that they won’t be looked at until the next Sprint. This is particularly a problem when it comes to bugs related to customer support incidents. With 4 week sprints it could be up to 8 weeks between a bug being reported and a fix being rolled out in a beta release. With 2 week sprints we can halve this time making us more responsive and leading to happier customers.

Those are just a few of the benefits I can list. If you have any of your own, why not list them in the comments? Even better, if you have any arguments against shorter sprints or would argue for going even shorter, I’d love to hear those too.

Permalink | Leave a comment »

Developers, Stop Complaining About the App Store

Fri, 11 Feb 2011 12:47:00 -0800

The Internet is chock full of articles from technology commentators and software developers on how evil Apple’s App Store is. I was reading this particular article on the Register this morning and it made me a little cross.

The App Store exists to make money for Apple. As it’s custodians, Apple have the power to choose what is distributed and promote the Apps they feel are most deserving. Many argue that this is unfair, and that Apple can’t be trusted and that they will use their monopoly to stifle competition and innovation. Perhaps this is true, but I am sure that some of what Apple is trying to do is ensure that only high quality apps are published and prevent the inevitable flood of crap-ware on their platform.

Then there’s the problem people have with taking a 30% cut of the retail price. Many argue that this is too much, but how can it be? If developers were sensible about their pricing and didn’t race to be a cheap as possible, then they could pick a price, and then add on 30% so they make sure that they get a fair cut. It’s that simple. There’s an article on how to price software by Joel Spolsky that I’d recommend. If we were selling boxed software, the store would add a markup, this is no different as far as I’m concerned. Ok so it still smells like a rip off as the cost of digital distribution is small compared to the cost of selling boxed software, but that’s just the Market.

Come on developers, the App Store has done something great for us. It’s got people paying for software again. I’d not bought software for years until I got my iPhone. I’ve always stuck to free stuff, downloaded from the web and I’m willing to bet I’m not the only one. The App Store has given software value in peoples eyes and its made them more willing to pay for it. What other platform has managed to do that? It has also created an environment that consumers trust. People are much happier with charging stuff over iTunes than tapping their credit card details into a random shareware site.

OK so the platform is closed and the App Store submission process can seem flawed, but really, customers don’t care and it’s the customers that count. Developers should follow the money, and be prepared to jump ship to another platform when the tide turns against Apple. I won’t say I like the system as it is, but it seems to be working so I will work with it until there’s more choice.

Permalink | Leave a comment »

Yet Another Lame Post

Thu, 10 Feb 2011 11:44:19 -0800

I've been thinking about getting back into blogging again. It's been about a year since I posted to my wordpress site. I had a vision for the site and but I've struggled to find the motivation to keep writing about stuff that followed it's technology theme. So I've decided, that while I think about whether to let that site die or to breath life back into it, I'm going to use my old under used Posterous account to post things I find interesting or general rants about my life.

You may be thinking that this is just another of those vanity blogs, filled with photos of the owners cats and foul mouthed rants about noisy neighbours and dog doo on the park. I'm afraid you're probably right. I'll do my best to prove you wrong, stay tuned 'cos things might get interesting over the next few weeks!

Permalink | Leave a comment »

Good morning Tallinn! Time for breakfast.

Mon, 18 Oct 2010 22:05:43 -0700

Permalink | Leave a comment »

Last look at the sea before we head home. The holiday is now over. Fun while it lasted.

Sat, 03 Jul 2010 01:20:38 -0700

Permalink | Leave a comment »

Problem Solving Flowchart

Wed, 26 Aug 2009 06:43:03 -0700

If you got a kick out of yesterday's flowchart, I know Keiron did, here's another one. This one has been kicking around our office for years, there is a crumpled up coffee stained copy sat on the desk behind me. It always gets whipped out whenever we find one of those killer bugs on the day of a big software release, or when somebody decides to flip a power supply to the wrong voltage when it's plugged in. You know, all those stupid things you do that you hope won't get noticed.

Anyway, that's probably it from me for a while. I'm off on holiday for a few days, and for the first time in ages, won't have access to a computer. I have some articles in the works for when I get back, so watch this space for something a little more interesting.

Permalink | Leave a comment »

Tech Support Cheat Sheet

Tue, 25 Aug 2009 00:54:18 -0700

Ah this comic is so true and should probably be read by all my friend, family and co-workers. Us computer types don't know how to use every computer program in the world. What we are good at is working out how they are used based on a few simple rules. Most computer software is designed with the same basic principles in mind so it is familiar and easy to work out where things are, think of the items under the standard Edit menu as a perfect example. However, I do remember when the latest version of MS Office came out with the new Ribbon interface, which left me completely confused, it truly was an experience of walking in another man's shoes, actually, it was a woman's shoes, my mums.

Permalink | Leave a comment »

Code Canvas Demonstration

Mon, 13 Jul 2009 03:08:01 -0700

http://www.langnetsymposium.com/2009/talks/26-HermanVenter-CCI.html

You have to wait about 5 minutes into the lecture. Demonstrates what could be a really useful tool for software developers.

Permalink | Leave a comment »