It’s all over the news: due to budget problems, NASA puts Spirit into hibernation and cuts back on the activity for Opportunity. Where do I sign the protest list?!

One thing I love about Java development is the ease of finding bugs through stack traces. Unfortunately, it doesn’t seem that Cocoa likes being so verbose about it, it prefers just giving memory addresses to the function. CocoaDev has a nice article about how to add this that’s based on Apple’s documentation, but it requires /usr/bin/atos that I cannot find in the iPhone SDK. That doesn’t mean it’s not installed, but at this time I have no way of knowing that it is. I have no idea how I should let people beta-test my products and sending automatically back intelligent bug reports without this tool. Ok, I have no idea on how Apple plans to allow for betatesting applications if the AppStore is the only application distribution method, and I have no idea how people do this otherwise as atos(1) isn’t included with the default OS X system either. But I would really, really like to include stack traces with bugreports from beta testers.

Being fairly new to Cocoa I enjoyed reading O’Reilly’s MacDevCenter’s article on exception handling with Cocoa.

According to iPhone Atlas, Google has pushed out a new release of its GData Objective-C Client Library that can be used with the iPhone SDK. Yay for Google! Check it out! For my last job I used Google Spreadsheets and Google Documents quite a bit, and it’s great being able to integrate it. Making a little word processor with synchronization to GDocs should be fairly trivial now.

class-dump is a great tool for getting information about how private frameworks work that you may want to use. For example, iPhotoAccess.framework gave among other classes the following:
`
@interface Base64 : NSObject
{
}

+ (id)stringForBase64:(id)fp8;

• (id)base64ForString:(id)fp8;

  @end
  `