After some talking with Mr Spiff in Feb this year, and copping some harsh criticism on the last method, it became apparent that work was needed.

Firstly – accuracy. It is hard to get your address in places like Asia and Latin America (generally the places where you need it the most). Chinese addresses are über-long, but at least they have them. In Peru? Forget about it! Even the taxi drivers can’t find addresses that are printed on Peruvian business cards.

GPS fixes this, with your position down to 47m on average, after 30 seconds. More than enough to guide the cavalry (green smoke would help too – but doesn’t fit in your pocket, and may raise questions on a date). The iPhone GPS can even work without a data connection (handy also if you are lost in the bush).

GPS Log now has an export to SMS option that allows you to send your GPS position to your friend by SMS. I have also created a stand-alone product focusing on this feature (this is the product that evolved out of the stand-alone “kidney watch” product ideas). http://gpsme.cc/ (if you have GPS Log, no need to try this one)

This is actually a very useful, potentially life-saving feature. Mum tells me the sad story of a guy who died in Queensland when he got lost in the bush. He had cell-phone signal and phoned 000 nine times but they couldn’t find him. 2 floats that could save your life…

The second, more concerning feature is verification.

i-think22 proposes duress words. My only problem with that is that if you are under duress you may not be able to reach your phone. I prefer the Dead Man’s Switch approach where if you don’t perform an action in a fixed timeframe, the cavalry roll in. Of course, both together may provide even more optimal coverage.

The issue with the Dead Man’s Switch is the possibility that your antagonists may intercept the signal and duplicate it (e.g. Speed), or that you may accidently forget to activate the switch, and be rather red-faced when the cavalry roll up.

I would like to see a customised version of the SMS feature, designed for Kidney Watch. So tell me – what should be in it?

So my unibody mac has passed it’s one year birthday. Awesome piece of hardware (and software), been really great to me.

One complaint - occasionally my fan starts making abnormal noises. Not just the high RPM noise, but another more disturbing rattling noise. I may need to get it repaired, which I’m OK with – just not OK with the downtime…

Some useful tools I have found while running some MacBook health checks…

• smcFanControl – a cool tool shows you core temp, fan RPM’s and best of all lets you tweak the RPMs (I’m trying with setting a higher minimum speed to combat the rattle)
• Coconut Battery – sweet App that tells you how many times you have recharged your battery, and it’s current capacity (compared to new capacity). Remarkably, mine is 97%! This just saved me a few hundred bucks because I was thinking of replacing the battery to refresh it.
• iStat Pro – awesome dashboard widget showing you many vital statistics of your mac.
• Disk Inventory X – useful tool to show disk utalisation, cousin of WinDirStat

It was tempting to upgrade to the new Unibody 13″ Macbook Pro with it’s 7 hour battery.  For me that is a very compelling feature, in that it greatly enhances productivity (more than a few extra CPU cycles or RAM).  However it is hard to justify the ~$1000 upgrade price tag (assuming a good ebay sale).

The amount of times I had to stop work this year due to my battery being empty is probably only 2 or 3.  Even on a long 9+ hour flight, I generally only clock a few productive hours working, and the remainder resting off the travel, or watching movies on the inflight entertainment.

This MacBook line upgrade was released in June 2009.  My guess is they will next update the model on around June-October 2010 which seems to be their standard release cycle.  I’ll upgrade then.

PR NEWSWIRE: After some weekend deliberation over a bottle of scotch in a scientific setting, Tony Abbot amends list of things he “doesn’t believe”:

• Humans are not the cause of climate change
• Smoking doesn’t cause lung cancer
• and even if it did, then second hand smoke certainly wouldn’t anyway
• HIV doesn’t cause AIDS
• The earth is not spherical

Sorry mate. But some things you are free to “believe” or “not believe”. These are things like your religion (for you, apparently in the “believe” category, at least on paper). But when it comes to science. Either get a qualification and debate the science in the right forum, or shut the fuck up.

$1 apps are one thing. Now people are releasing 15 games in 1, for $1. Wow…

Seems like Apple needs to add some new pricing categories, especially for games. I suggest:

$0.19
$0.09
and, my personal preference:
$0.01

Just think about it – at 0.01, your audience could be HUGE!!!!!!!!%!!!!! Enjoy your instant noodle dinners!

I’ve got no issue with people modding/hacking their iphones (even as a developer myself), or any hardware they own for that matter.

But please. Don’t blame Apple for viruses/malware that f*ck you up when you do. This “worm”, and the subsequent more malicious versions only run on hacked iPhones. You run unauthorised software on the iPhone – you’re on your own…

The BBC (and the rest) really should make it clear that “anyone running Apple authorised software are completely unaffected”. And put that in the first paragraph.

Rather than screaming “Worm attack bites at Apple iPhone” what about “Worm attack bites at Hacked iPhones”. At least they didn’t spell bites, “bytes” :-S

Don’t fret… you can reset the count once every 12 months.

Archiving dSYM for production builds is a good idea.

An easy way to do it is to add a build script at the end of your build.

in XCode->Targets->YourBuildName
right click, and select Add -> New Build Phase -> New Run Script Build Phase

and copy in this script. ArchiveDSYMScript

Repeat for all targets. Ensure the order is after the ‘Link Binary With Libaries’ task.

NB. This excludes “Debug” and “Release” build types, as I use “Distribution” and “Distribution Ad-Hoc” for my distribution builds. Easy to change, if you need.

If you get the error “[: too many arguments" in your bash script - check that you have wrapped your variables with quotes.

if [ $X = "y"]

will cause this error if $X is a string with a space in it. Change to :

if [ "$X" = "y"]

If you are sent a crash dump by the Approval Team, download it through iTunes Connect or some other way you need to be able to interpret them into something usable. Here’s how:

Run
/Developer//Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash xxxx_2009-11-12-140756_iPhone.crash > crash_with_symbols.txt

This is the difference in knowing the exact line of code that crashed, and knowing it crashed. Make sure your have your dSYM files though – read on.

Useful options for the script are -v (verbose) and -A (just search for Application symbols).

HOWEVER: You MUST keep the dSYM file for every build you do. Even doing a rebuild off the exact same source code produces a dSYM file that is not compatible with the script. So archive those dSYMs!!!

Check out my automatic dSYM script here: dSYM Archive Script

MKMapViews seem buggy when created problematically. The current recommendation is to never release them (make them a static so you don’t leak like crazy), and set the delegate to nil when the delegate dealloc’s.

my comment on that blog:
I applied this fixed which fixed all crashes except the (less frequent, but still easy to reproduce) MKDotBounceAnimation animationDidStop:finished one that others also reported.

My fix for *that* crash was to never dealloc the MKMapView instance. I set it up as a static so there is only one copy and I just re-used it.

Scratch my last comment. Now what I do is instead of calling release directly, I call it after a delay of 4 seconds. This is easy with this statement:
[mapView performSelector:@selector(release) withObject:nil afterDelay:4.0f];

Just gives the internal stuff a chance to clean itself up before the release is sent.

It seems this MKDotBounceAnimation problem only occurs with problematically created MKMapViews (not XIB ones), as my XIB one never seems to crash with that error.