The SourceTree 1.2 launch sale is now over, and I thought I’d post some indicative results. I went for a fairly large discount of 40% over a full week, and some people I know commented to me along the lines of ‘what about all that money you’ll be losing on each sale?’. I decided on a large discount because SourceTree 1.2 was a major update that I was actually quite proud of, so I wanted to get it in front of as many people as I could.
Since I’m trying to spread this news as far and wide as I can, I might as well say it here too 😀 Since the approval light just went green on the Mac App Store, I’m happy to announce the launch of SourceTree 1.2! In celebration, I’m having a crazy-bonkers 40% off sale just for one week, so get it while it’s hot! There’s loads of things that are new or improved in this release, but here are the headlines:
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.
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.
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.
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.
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.
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.
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.
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.