SteveStreeting.com

This is just a quick post to help someone out on Twitter, and the blog seemed the best place to post it.

If you make Mac apps, you probably use Sparkle to manage your auto-update process, outside the Mac App Store anyway. And so you should, it’s awesome, and makes keeping software up to date much easier. But what about the download link on your website for new users? Wouldn’t it be nice not to have to manually update that every time?

For SourceTree, I use a PHP script which just parses my Sparkle appcast and reads the latest release from there, generating a download link automatically. So whenever I update the Sparkle appcast (and I have scripts to do this from XCode, which I may share in a subsequent post if there’s interest), the download link for new users is always up to date immediately.

The full code is after the jump if you want it. As usual, feel free to use this for whatever you want, but there are no warranties for anything whatsoever; don’t blame me if it doesn’t work, or dissolves your website into a pool of steaming alien slime.

Read the rest of this entry »

I think most people are now aware of how much damage sitting down for long periods does to the human body – aware doesn’t necessarily mean that they change their behaviour of course, until something starts going badly wrong (as it did for me a few years back).

Quite a few people recommend stand-up desks as a solution to this problem. I tried it myself in fact, firstly with a jury-rigged version, then after it seemed to help some I spent a bunch of money on both a desk and chair with a very high range of movement to accommodate both standing and sitting. It’s been just over a couple of years since my back problems started in earnest and I’ve actually concluded that (for me at least) stand-up desks don’t really help directly – the benefits are actually circumstantial, and unfortunately relatively short-lived.

Here’s why – when I first started using a stand-up desk, it was really uncomfortable. That required that I regularly took breaks to sit down (my feet hurt), or walk around and change position – this helped my back. But over time, here’s what happened – I got used to standing up for long periods, and as such I got ‘better’ at staying at the standing desk anyway. And all that happened is that I got yet more back problems, this time resulting from my back muscles locking up in a standing position rather than a sitting position. Not really progress.

The real key to avoiding back pain in my experience is not to stay in one position for too long. A standing desk may force that behaviour on you for a while, but the chances are that you’ll overcome it with time and just get locked in a different position (or maybe 2 positions if you alternate between standing and sitting). Sure, you could go for one of those treadmill desks, but IMO they’re a bit stupid. The thing is, the principle behind all these things is that our our bodies did not evolve to spend long periods sitting down – but they also didn’t evolve to spend long periods standing in one place, or walking on the spot, or alternating between 2 limited positions, either. In practice there was some walking, some crouching, some standing – all sorts. Variety of movement is what we were designed for, and while standing up may alleviate the problem for a while because the discomfort makes you move, it’s not a long-term solution IMO.

So really, keeping your back healthier is simple – keep moving around, take regular breaks, and try to avoid stress (this bunches up muscles, encourages unusual posture and suppresses the immune and natural recovery systems). Switching sitting for standing isn’t enough IMO, and can be quite misleading, implying you can still stay at your desk for the same number of hours and avoid back problems (win-win right?). I think most people would be better off saving their money and just learning to change their behaviour, building regular breaks / stretching / walking around into their day instead.

Perhaps there’s a small risk of someone starting a file on me for saying this, but I’m willing to be we all have voices in our heads. I don’t mean the type which whisper murderous thoughts or paranoid conspiracy theories (if you have those, this blog really isn’t an adequate place for you to obtain consultation), but some kind of internal dialogue we have with ourselves, often to justify the decisions we take, or don’t take.

One of the things that voice in our head often does is provide us with excuses. Maybe you have a project which you keep saying you want to start, but you “don’t have time” (probably the most common excuse for everything), or maybe you want to change jobs completely but “I can’t throw my career away”, or “I don’t have the training”. People in corporate IT departments are especially good at excuses – trying that new platform / environment is “too risky” or allowing the CEO to use the device he wants to use would “break corporate standards” or “risk network security”. Maybe that customer or employee has a great idea for a new service or change in approach, but it’s “too hard to get there from here”, or “would probably cost too much”.

Very often, excuses are just people building a natural safety buffer about themselves to avoid having to deal with something that’s a little bit scary, difficult or unknown. If you tell yourself (or other people) that there’s some considered reason or analytical risk which stops you from going out on that limb, for taking a bit of risk, then that’s a comfy position to leave yourself in. It’s not you making the decision to resist taking that step, it’s an unavoidable environmental factor. A global immutable constant. It’s comforting to think about it like that, because then it’s not your fault that another year passed and you feel like it’s a re-run of the one before.

We’re all complex and I’m not going to tell you what’s right or wrong for you, but here’s my experience: taking a few risks, trying new things, embarking on something when you have no idea where it will take you – these are all good things, and you do yourself a disservice by avoiding them. Now, I’m not a huge risk taker, I’m not high-rolling in Vegas or blagging my way into risky business ventures or anything, but I recognise that taking some considered risks, and putting yourself outside of your comfort zone, is necessary to get anywhere – something that I’ve come to appreciate a lot in the last few years particularly. Besides, it’s almost never as bad as you imagine, and having taken the plunge you might be surprised how well you can figure stuff out as you go along.

So when I find myself coming up with a list of reasons why I can’t do something, I find it useful to roll out a simple mental phrase: ‘No Excuses’ . For added effect, imagine it’s being boomed out by James Earl Jones, who is staring down at you with that intense, serious gaze of his – there’s just no bullsh*tting him . There’s a decent chance that some or perhaps all of those things that you think are impediments are really just excuses – and you’re really better off without them. No excuses, just try it – what’s the worst that could happen?

Decisions are hard. Well ok, not all decisions are hard – given the choice of whether or not to receive a swift kick to the gentleman’s area, most of us would politely decline without having to give it much thought. So let’s rephrase – making an important decision for which there is no clear optimal answer is hard. And yet, making these kinds of decisions, in a theoretically unbounded possibility space with uncertain and/or unknown variables, is the one thing we humans still do considerably better than machines, and it forms the basis of pretty much every important event in our lives – who your partner is, what you do for a living, what projects you work on, what your hobbies are, where you live, and so on.

The thing is, in the developed world in particular, our options are almost limitless – in practice we have very few real constraints on what we choose to to, barring a few fairly sensible laws. Barring a small number of hard factors, such as poverty, discrimination, and oppression (which should be fought wherever they are found), the only limits to most people’s decision making are those which they impose on themselves, resulting in a large number of options. This is a good thing, but it does make decision making complicated. How on earth do you sift through all those alternatives?

Opportunity Cost

Understanding the concept of opportunity cost is vital to any decision making process. It’s just as important to consider what you won’t be doing as a result of a choice, as what you will be doing. Picking contract project A might mean you don’t have time for personal project B, taking that corporate job might mean you can’t dedicate time to developing that business idea you have, and so on. For a while, I tried to defy the reality of opportunity cost by ‘cheating’ – I would do multiple things at once, and just put in very long hours. I worked on projects in my spare time while being employed, I would multi-task between many projects (contract, open-source and personal). That works to a degree, but it’s important to realise two things:

1. There’s a limit on how long you can burn the candle at both ends.
   I speak from experience here, burn-out and work/stress related health problems are very real, whatever you might think as a young, healthy, workaholic programmer. You can work 12-16 hour days for a while, but eventually you’re going to have to stop, or something will make you stop. If you need to do it to bootstrap, fine, but always remember the clock is ticking – plan for that.
2. The more you divide your time, the less efficient / productive you will become.
   If you spend 10 hours a week on each of 4 projects, in 4 weeks you will have done a weeks worth of work on each, right? Wrong. In fact, you’d probably be lucky to get half that. The more you divide yourself, the less you’re going to get done on each thing, just because of a lack of focus and a need to keep context-switching.

So, my message here is that you can’t cheat opportunity cost – things conflict, and it’s best to not to pretend that they don’t. This should not only inform your decision process, but it should also bring it into sharper focus – accepting that you can’t have your cake and eat it means you’re less likely to let yourself wiggle out of making an actual either/or decision when really it’s there.

Evaluating the options

The logical person’s approach to evaluating their options tends be be analytical, gathering as much information about each option in front of them, and quantifying each of the pros and cons, risks and opportunities, and so on. This is fine, as a starting point, and teases out a lot of fundamental ‘hard’ information that you need to have available. But in my experience the best you can hope for from this kind of process is that you will eliminate the outliers; those cases which will never work, or which you definitely don’t want to do (although it’s of course worth making sure you understand your own assumptions and biases here), leaving you with a pool of ‘maybe’ options. It  won’t, in any non-trivial decision space, provide you with an absolute dead-cert answer; or if it does, you probably haven’t considered enough alternatives

The simple reason for this is that for any significant decision there are bound to be many factors and variables which are unknown, poorly quantifiable, subjective, or incomparable with each other. There won’t be some magical formula which you can plug all the variables into and come out with a single best answer, nor will the factors usually be clear enough even for you to rank them in any sort of objective order – or if you can establish a discrete ranking, it probably just means you’ve identified some more to discard, or you’re kidding yourself.

Making the decision

OK, so assuming you’re now left with a bunch of ‘maybe’ options, all of which have many uncertainties and incomparable pros and cons. How do you make that decision? You’re probably going to think this is a cop-out, but here’s my personal answer; sleep on it, and then follow your gut. Seriously, forget the analysis, and turn off your brain; it’s already contributed as much as it’s capable of doing in the previous step. Hard as it may be, particularly if you’re a naturally logical, analytical person, there are some things that simply cannot be analysed and quantified. Probably any of the remaining options in your list are good (or if this a case of choosing the lesser of N evils, equally bad) – so going with the one that you have an emotional attachment with is usually the right one, because that’s the one you’ll fight hardest for when things get tough. Which they probably will at some point, right? Never underestimate the power of emotional attachment and enthusiasm to the success of any endeavour when things get difficult. You can’t engineer this kind of affinity, and your gut will tell you when it’s there, more reliably than any checklist can ever hope to do.

Living with it

While it’s important to be nimble in many respects (in business, you can’t sit still and periodic course corrections are essential), you do need to give any decision a fighting chance to develop before you change tack. Try not to second-guess yourself too much in the early stages – it’s hard, and this is something I struggle with all the time, but it’s ultimately counter-productive in the shorter term. By all means it’s important to reflect periodically and learn from what worked and what didn’t, using that experience to influence your future decisions, but equally for your own sanity you have to be able to drive a metaphorical stake into the ground representing a decision you make, and only look forward from that point, for long enough to see what happens, for better or worse. Glancing over your shoulder from the outset wondering if you made the right decision is never helpful and is likely to undermine what you’re doing.

Conclusion

So, that’s my 2 cents on the decision making process. Thanks to @GeekAndDad for triggering me to finish the half-written post I had on this subject

A little while ago I blogged about setting up a MIDI interface for a Roland TD-9 (KX in my case – I love my mesh heads ) so it could be used to drive Rock Band. I’ve had that setup for almost 18 months now and it’s served me well, but the main problem with it is that the older Rock Bands only recognised 5 different triggers, with many doubled-up – so Yellow was both closed high-hat and high tom, green was floor tom and crash, and blue was over-used as mid tom, ride cymbal and open high-hat. I compensated for this by trying to play the songs properly anyway, by listening to the track and figuring it out for myself, or by getting sheet music for the tracks in question, which worked quite well.

In Rock Band 3 however, they introduced Pro Drums mode, which separately charts the cymbals and toms, leaving the only doubled-up trigger on blue, which still serves as open high-hat and ride cymbal. Unfortunately, my MIDI interface didn’t comply with Pro Drums mode and the new official Pro MIDI Adapter was stupidly hard to get a hold of in the UK – luckily I finally managed to get hold of one this week via Gameshark.

The good news is that the new MIDI interface almost works out of the box; they clearly decided to pre-configure it to many of the common MIDI setups of electronic drumkits, so you can actually start playing straight away (so long as you don’t use the customised setup I posted previously, in which case you’ll need to reset most of it). There are only a few small tweaks you need to make from the stock MIDI configuration on a TD-9:

1. Dual / triple triggers don’t generally work out of the box. If your kit (like mine) has dual or triple-triggering snares, toms and cymbals, you’ll need to configure the alternate triggers to be the same MIDI note (these are listed in the manual).
   You do this on the TD-9 from the home screen by pressing FUNC (F2) > MIDI (F3), then hitting the pad / cymbal in question in the appropriate place (head, rim, bow, bell etc), then using the adjustment dial to set the MIDI note to the correct value in the table.
2. Open / closed high-hat notes aren’t quite right. Most songs are charted so that an open high-hat is blue cymbal, but out of the box the high-hat is configured to trigger yellow cymbal in all cases, so you need to change the binding through FUNC (F2) > MIDI (F3) as above. First, hit the HH with the pedal depressed and set this to 22 (again for dual triggers, make sure you repeat this for the bow / rim), then do it again with the pedal released and set the note to 51.
3. HH Pedal setting - you only need to mess with this if you want the HH to sound different in Freestyle mode when it’s open/closed. The blue/yellow bindings in the previous point are what you need to match the song charts, but in Freestyle mode you can set the pedal to send a MIDI control signal when it changes state so that it sounds different when you play. To do this, go into Setup > MIDI (F2) > CTRL (F2) and set Pedal CC to FOOT (4).
4. Rock Band 3 config – to use all this you need to tell RB3 to use it, so pull up your options via Start > Options and enable all the cymbals and the secondary pedal option (as mentioned above, this only affects Freestyle, the yellow/ blue cymbal bindings control open/closed HH in songs)

That’s it! It’s a bit less complicated than my original instructions with the non-official MIDI interface, but it won’t be quite right unless you perform those steps too. I hope that saves someone a bit of time, the HH situation certainly confused me at first.

I’m pleased that I can already play Pro Drums pretty well, because I’ve been teaching myself to play the tracks correctly anyway over the last year and a bit, even though the non-Pro charting didn’t force me to. It’s really nice to have confirmation on the charting though! Lots of fun ahead.

As many of you probably know, almost a year ago now I decided to take the plunge and move my primary development activities to the Mac. I taught myself Objective-C, got properly to grips with Cocoa at last, and started a new Mac OS X-specific project which would eventually become SourceTree, learning a ton along the way (a process which is by no means complete!).

Happily, things have turned out very well – SourceTree continues to sell, reassuring me that there’s enough interest out there for me to keep expanding and improving it (I’m looking forward to getting the next major release in people’s hands soon), and I’ve also been getting some Mac/Ogre-based contract work which I’ve enjoyed a great deal. In short, my Macbook Pro and I are now pretty inseparable, Windows 7 is powered off 99% of the time, and I saved hundreds of pounds by not upgrading to Visual Studio 2010

Out of interest, I thought I’d share some of my SourceTree sales information, in terms of the country distribution. Mac use is typically associated primarily with the USA, and while that’s certainly reflected in my absolute numbers, there’s some quite interesting figures revealed when you take into account population size. SourceTree is aimed at developers of course, so all numbers reflect this audience alone (and of course those that chose to buy it) but in practice I suspect that the proportions of developers to non-developers is fairly uniform in most developed countries.

So, firstly the absolute distribution:

No surprises there, the USA is the single largest source, followed by Germany and the UK (who are constantly scrapping over second place!). To me though, Switzerland stuck out as the most interesting, because it’s up there in 4th place yet has a relatively small population (under 8m). So I wondered – what would the chart look like if I scaled it by the population size? Here’s the result:

And there you go – as expected Switzerland jumps right to the top, and to my surprise Luxembourg and Denmark are up there too, beating the UK which I expected to come in second. Quite a lot of European countries are punching above their weight in per-capita Mac development, if SourceTree sales are any indication. In fact, on a per-capita basis, the USA is only just sneaking into the top 10, despite it being by far my best overall customer in sheer sales volume.

I’m aware that scaling by population isn’t all that scientific, since it is sensitive to the proportion of non-developers (and even non-computer users), but as I say, I think in developed countries at least, the comparisons are reasonably valid.

So the perception that Mac development is more popular in the USA than elsewhere may be inaccurate, based on my numbers at least (which of course are not massive in the grand scheme of things, but still a statistically relevant sample I think). Sure, simply because of the sheer population size of the USA it’s bound to dominate anyone’s sales numbers, but if you asked the question ‘of 1000 randomly selected developers in a country, what percentage are using a Mac?’, the result may not be skewed in the way you might expect. It was surprising to me, anyway.

I wonder if anyone else who has been doing this for longer has had similar results?

Cocoa is already quite good at handling localisation – you have a folder per language where all your resources are loaded from, and you get tools for exporting your strings from your code (genstrings which exports NSLocalizedString macros) and from your user interface components (ibtool which can process nib files to export & import strings).

What isn’t covered very well in the docs though is how you might automate all this so that it’s efficient, incremental, and idiot-proof. And by idiot, I mean me after more than 7 days since reading the docs.

There are tools out there that purport to make this easier, such as AppleGlot and iLocalize, but to be honest I found they just made things more complicated. All I really wanted was an efficient way to batch export and import localised strings, to know what changed between versions, and to keep my previously localised strings automatically without overwriting them. Translators should need nothing more than a Unicode-capable text editor – no complex tools, no training, just their natural ability to turn English into a different language and type it into a text file.

I ended up with two Python scripts to handle this – one to handle the genstrings/NSLocalizedString route, which I wrote a while back and covered in a previous blog post. The second I wrote today to handle nibs, and also to build the individual language folders. I needed it to do this:

1. Export strings from nibs for each language, merge with strings already translated, or
2. Import strings for each language and create localised nibs based on the master English versions

Here’s my Python script to do this: localise_nibs.py

Usage:
  localize_nibs.py --basedir=<base> --stringsdir=<strdir>
    [--langdir=<langdir>] export|import

  export: Reads all the xib files in <base> and generates .strings files
        for every 2-char country code directory under <strdir>
        New strings will be added to existing files.
  import: Reads all the xib files in <base> and looks for .strings files
        in <strdir>/<lang> with the same name. Replaces strings in xib and
        writes the output to <langdir>/<lang>.lproj

So basically, you start with a base folder full of nib files (in English in my case), and point –stringsdir at a folder which contains (empty to begin with) subfolders corresponding to languages (like ‘fr’, ‘de’, ‘ja’ etc). When using the ‘export’ option, it will go through all your .xib files and generate strings from them using ibtool, once for each language. It will also turn these files into UTF-8 rather than UTF-16 (as ibtool exports them), so that you can put the files in hg/git without losing text diff support. You can give all these files to your translators.

The nice thing is that if you add a new control to your user interface, and you’ve already got translations in the –stringsdir folder, the script will merge the output from ibtool and the existing translation, only adding the new strings. You can then simply give the files to your translator with a ‘diff’ report (this is why you want UTF-8) to show them what they need to look at. The Apple localisation docs talk about ‘incremental’ localisation, but they totally miss this part – by ‘incremental’ they just mean taking a localised nib that you’ve manually changed and merging geometry settings, not generating a new strings file which doesn’t lose the previous translation.

The ‘import’ option does the reverse, it takes the translated strings and the base nibs, and creates localised nibs in the –langdir folder. Mostly the script just automates everything so it finds the files on its own, processes all languages, and highlights when there’s a missing translation (and uses the base version temporarily so the app still works). Note that I assume that you only manually author one nib (the base version) – personally I don’t have the resources to tweak geometry in every language so if you do, you’ll need to alter the script to cope with the ‘incremental’ localisation as Apple presents it in the docs.

Anyway, I just thought I’d post this in case it helps someone else – I experimented with a few different options and I found this one to be the best – it’s simple, uses tools you already have, and plays nice with source control. Result?

I was thinking the other day about how many version control systems I’ve made my way through over the years of being a professional developer, and I figured it would be fun to put it in graph form. Of course, this is entirely from memory and gives the illusion of being more empirical than it actually is, but hey, everyone loves graphs, right?

Yes, I really didn’t use any source control back in 1994, barring backing up to 3.5″ floppies. ‘Custom’ refers to a system I wrote myself in 1995 to do version control on a mainframe system I was working on at the time; really it wasn’t a proper VCS system as you would think of it now, but it did the very basics to make sure we knew what was being developed and deployed at any point in time. You could think of it as a VCS system that only had history at the tags

As you can also see, Visual SourceSafe was the first packaged system I used – you can pity me now – as more of my work started to involve PCs instead of ‘big iron’. At that stage, the concept of ‘checking out’ and ‘checking in’ was normal. Oh, how naïve we were.

I discovered CVS at the turn of the millennium, at the same time I started Ogre. The ability to work without checking anything out was a revelation! I went on to use that on all my projects for quite a few years, at least until I considered Subversion stable enough to base production work on. Even then, I only moved new projects to Subversion mostly (Ogre eventually moved in 2008 – was it really that recent?), and kept CVS for many existing projects.

I first encountered Distributed Version Control at a Git presentation at the Summer of Code mentor summit at Google HQ in late 2007. I have to admit, I didn’t really ‘get it’ at first – it just seemed to make things more complicated and most of those promoting it were mostly die-hard Linux fans and wide-eyed early adopters that didn’t make you want to put your production code on it yet. There was also no GitHub at this time so the benefits weren’t really very visible. It took me until 2009 to really start evaluating DVCS in earnest, and decided that I liked Mercurial best, due to its equal treatment of all platforms, good diagnostic reporting, easy extensibility and intuitive interface that gave power without over-complexity. Today, all my own projects are in Mercurial, but I use Git a lot too, not least because I support it in SourceTree, and get involved in other projects which use Git.

There are a couple of randoms thrown in there – I used Alienbrain for a few months on a client project and totally hated it (think Visual SourceSafe with a few bells – it may be useful for artists but for coders it was horrid), and I did play with Bazaar for a bit but didn’t really warm to it, even though it had some quite nice ideas.

So there you are – my VCS experience over ~17 years in professional development. It kinda makes me want to do a language / platform graph now

We hear a lot about globalisation these days; how money, people and business move freely around the world (although that has had a few teeny problems of late) and how countries must therefore compete in that market for investment, and ultimately jobs and economic success in general. Much of this is true and common sense, however, I do object to the tone and emphasis that is used whenever this argument is made. There seems to be a preference of late for attracting external players to flirt with local economies for as long as possible before they get bored and move somewhere cheaper, rather than focussing on organic growth of businesses from within the existing local entrepreneurial base. You can do both of course, but in recent years I’ve observed that here and in some other places in the world, the balance is strongly in favour of the short-term plan of courting of large, external players, versus the long-term prospects of ‘growing your own’.

Of course, inward investment is a good thing, but too often this investment isn’t in new local businesses, it’s simply about grafting a globally mobile business to the local economy for a while, usually as a result of some kind of sweetener (a tax break, a public private investment, etc).  It’s a ‘quick fix’, injecting money into the economy quickly (perhaps most importantly, within the time frame of a politician’s tenure), but when viewed at a macro scale it’s also very much a temporary one which can be pulled out at almost any time.

Global companies don’t even hide their temporary commitment; in fact, quite the opposite – they are always exploiting this to lobby governments into making changes which favour them, the line is usually “You’re dependent on us now, so you’d better keep things attractive for us (subtext: at the expense of others if necessary), or we walk.”. You see this all the time – the shrinking of the UK games industry because the UK doesn’t  have tax breaks like Canada, and here in my local jurisdiction the introduction of a tax regime which shifts the tax burden to ordinary people and away from companies in order to appease the financial services industry. In the end, being so dependent on such fickle and demanding ‘friends’ is not the greatest of strategies. At times, it can almost be a protection racket – “Nice economy you’ve got here, it would be a shame if something happened to it” (see this Monty Python sketch).

Every economy needs a bedrock of locally-driven, independent entrepreneurship, made up of of people who do business in that economy because they want to, or because it’s their home, not because someone bribed them to bring their money here and are constantly looking for the next sweetener. There are countless success stories of businesses that went global from a local, organic base, such as Ben and Jerry’s and Specsavers, and these companies have kept their attachment to their origins. Such businesses are ‘stickier’ and less fickle, and I’m willing to bet they require only a tiny fraction of the overall cost (once you count tax breaks, subsidies, and other policy changes / deals) to attract and retain than an equivalently sized global player. It takes more time to get there, but when it does, it’s far less likely to be going anywhere.

I’m not suggesting that we somehow cling on to protectionism, nor do I deny the benefits of globalisation. What I am saying is that in my experience, the balance of policy making is way off in favour of the global players at the expense of others. Maybe if politicians weren’t so easily impressed by financiers in expensive suits with their short-term promises of wealth injection, and learned instead to see the long-term sustainable potential in that garage-dwelling startup, they’d be better at not skewing the economic landscape towards the ‘floaters’ rather than the ‘stayers’.

It’s actually why I shake my head when I see people claiming that the UK needs tax breaks for games companies, to compete with Canada and other places. Personally, I think that even if you gave a tax break to the companies that are relocating away from the UK because of this, they’d just be asking for something else next year. Where does the bribery end? I think that games companies that only go where the tax breaks are, are probably not worth trying to hold on to. I sincerely hope that the talented people who are sadly left out of a job because of this are able to start up or join independent game businesses of their own, and dare I say are likely to be a damn sight more creative in that environment too. The UK games industry has lost much of its individuality in recent years, and who knows, this process might well regain some of that.

So I guess my main point is that bribing and paying protection money is not a sustainable way to run an economy. Sounds obvious really?

I don’t blog as much as I used to, for reasons which are somewhat relevant to this post – rather you can usually find fragments of my consciousness floating around the Twittersphere instead, since its enforced brevity requires considerably less of my time to populate. Maybe I’m old fashioned, but I believe that if you’re going to write a blog post about something, you should probably make sure it’s written in a half-decent way, and that’s fairly time consuming, particularly when you’re ever so slightly anal about language as I am. Nevertheless, the receding silhouette of 2010 is a worthy enough subject to invest a bit of time in, so here I am, verging once again on being dangerously verbose. I guess the post should have started with a warning banner or something – but if you’re a repeat visitor, you know the score.

So, 2010. I started this year with three significant and intersecting goals: to significantly simplify my working life, to reduce my stress levels, and to spend more time in the company of my own creativity by working on my own projects. The reason was this: by the end of 2009 several factors had led me to a situation where I had my fingers in too many pies, too many balls in the air, too many – well, you get the picture. The thing with being a consultant / contractor is that work comes in with a very uncertain frequency; projects have a tendency to ‘bunch up’, and because of the inevitable lean periods in between you don’t really want to say ‘no’ to anything. The economic situation since late 2008 also led to projects being noticeably more cost-sensitive, meaning more juggling required to fill out a coherent schedule than it had been before that. All this could get quite stressful, and with a back problem to nurse and an open source project to run on top, things weren’t that much fun at times. So my resolution for 2010 was to stop just trying to make the status quo work, and instead to do things my way – to ditch smaller pieces of work, to only get involved in larger projects that I found personally interesting, and to spend the rest of the time investing in my own projects instead. Fundamentally it was about taking control back.

At that time I didn’t plan to retire from OGRE, but in hindsight I think subconsciously I’d made the decision already, I just hadn’t admitted it to myself yet. I’m extremely proud of what I managed to accomplish with OGRE with the help of countless contributors, and was sad to put that role aside after 10 years, but in many ways it had become a rod for my own back. Not only was it a hugely time consuming, 24/7 job to look after, but there was an inherent assumption, from others and from myself, that projects I chose to work on would naturally be associated with OGRE in some way. That was quite a pair of blinkers to have on, even if I didn’t know I was wearing them. If success with a product or in a subject area has a downside, it’s probably that it can become a gravity well which resists you exploring other areas of interest. So while I’m sad to have retired from OGRE and look back on my time on the project with a great deal of fondness and pride, I can’t deny that I don’t regret casting off and returning to the open seas, even if the security of the harbour was comforting. Ok, I’m done with the sailing metaphors now.

One unexplored continent (damn!) which was calling me siren-like (ok, I really am done now) was native Mac development. I bought my first Mac in 2007, initially only to support OGRE on it (before masterfalcon came along with his superlative Apple-fu), but I’ve since been converted to a fully card-carrying Mac nutcase. So, I decided to finally go all-in and learn Objective-C and Cocoa, and make my own Mac-only tool, which of course turned out to be SourceTree. I’m very pleased with it, and if anything my predilection for the Mac platform has increased significantly during this time – I’ve barely used Windows in the last 8 months, and now when I do I find it quite unpleasant. I also went from hating Obj-C (as a C++ user) to really liking it in the space of a few months, and I’m quite happy to include it on my resume now.

The other thing I find, now that I’m juggling fewer balls and am less narrowly focussed, is that my creativity has ramped up considerably. My ‘Project Ideas’ file has swelled significantly during 2010, and I hope to have chance to pick off some of the juiciest of them later in 2011.

So, I guess the important thing in a retrospective is to decide whether I achieved my goals in 2010. Given that my back is much better now, I’m less stressed, more creative and I have a new product out, I guess the answer is yes. Not everything went to plan of course – SourceTree launched later than I’d intended (isn’t it ever thus?) and still has quite a way to go to recoup its investment, my only Mac died a month into me starting Mac-only development (but on the plus side that gave me an excuse to buy a new one, and Apple ended up repairing the other one free even out of warranty), and I’m still not completely recovered health-wise, but all in all, even if it’s not a double rainbow, it’s gotta be at least a rainbow and a half.

My best wishes to everyone for the New Year celebrations, and I hope we’ll all have a happy, healthy and prosperous 2011.