When too much is too much ... #2

I'm finally putting the final touches to my NSKeyedArchiver/NSKeyedUnarchiver replacement. It's not that it's a complex things to do really, it's just that finding the time to do it with a 4 weeks old baby around is I found, a major challenge. Overall, I'm satisfied by how my archiver is doing since it's packing that simple object (1 uint + 1 float) I was talking about in my previous post into 44 bytes instead of the wasteful 232 bytes of NSKeyedArchiver (while still supporting keyed encoding, of course). That 44 bytes include a preamble which ,when needed, could be skipped, for example when storing a collection of objects into a same file, so the archived object really only take 35 bytes, which isn't bad all considered :-)

Mars Pathfinder

11 years ago, like many other space geeks, I was captivated by the Mars Pathfinder mission. It was the very first mission to have an Internet coverage (If I'm not mistaken), and it was also (of course) the first mission to feature a rover (only 10kg, compare this to MSL's 900kg!). Looking back at the mission pictures, it's amazing how we have grown accustomed to high-res imagery from the twin MER, to the point that pictures from their older cousin seems amateurish (likely your cell phone, an iPhone hopefully, as now a better resolution than Pathfinder's cameras had).

Anyhow, I'm talking about this today, 'cause I stumbled on a couple of YouTube videos, which are part of a 35 minutes documentary on the mission, which I though was good enough to share. So here are, in order, the 4 segments:

From Newton to iPhone ...

As nicely pointed out by John Gruber on his blog, Deep Green is back (from the dead)! As soon as I saw that, I rushed to the App store and grabbed it (for it's introductory price of $4.99) mostly for pure nostalgia reason since I had it on my trusty Newton, even though I'm not a big Chess player (I do play occasionally). The iPhone's version, which is coming out 10 years after the Newton's version, is seriously beautiful and sports a nice minimalist UI. Well done Joachim Bondo! I'v got to said that it is nice to see a Newton old-timer transitionning to the platform :-)

When too much is too much ...

To store the data generated with my iPhone application, I have been using the facilities provided by the NSCoding protocol in cooperation with a NSKeyedArchiver, and it works quiet well even if it is likely not what I should be using since it force all my data to be saved or loaded all at once. Nevertheless at this stage in the development process, this is a good enough solution since my data-set is relatively small (less than 30 items). The whole concept of archiving object isn't new to me since I was using it back in my BeOS days (BMessage with the BArchivable class), however the NeXT's take on this old favorite is a little much more handy to use, thanks to Objective-C dynamic nature (compared to C++ more rigid nature) . Since the name of the class is archived at the same time than the object data, it can be later used to recreate the object automatically (granted that the executable unarchiving your object knows about that particular class).

Unfortunately, there is (of course) a price to paid for using NSKeyedArchiver. The end result bytes consumption is criminally high. For example a simple NSObject derived class, encoding a uint and a float, requires a 232 bytes long buffer. 8 bytes of real data (not counting the class name), flattened into 232 bytes ... So obviously, lots of the overhead won't be duplicated if I was encoding more than a single object, but if you want to archive a single object for transmission or storage (bytes oriented kind of storage), the cost is a little too high.

Hopefuly, since the NSCoding protocol is based on using the abstract class NSCoder, one could create its own archiver, with hopefully similar capabilities, but lower memory footprint. I know, I shouldn't waste my (limited) time making my own, and instead focus on the app, but I can't help ...

Happy b-day, Mouse!

Well, the mouse is officially turning 40 years old today. Well, to be exact, it's a little more than 40 years old, since it was first publicly demonstrated 40 years ago by Douglas Engelbart during what is now known as the Mother of all Demos. If you have 74 minutes to spare, make sure to watch the video of that demo from some pretty cool stuff ... that is if you are digging computing archeology ;-)

While, I'm on the subject, I'd like to point out also, an interesting interview of the legendary John Draper, which was recently published on Stories of Apple. The interview mainly focus on the early days of Phreaking and Apple, but here's an excerpt related to the main preoccupation of this blog (no, it's just not about weird music!):

"Yeah, it’s wired up, man. Fuckin’ wired up man. [...] It was borrowed from NeXT. Jobs owned all the code from NeXT, he brought it in to Apple. It’s part of Xcode, part of Cocoa."

Über fiasco ...

I was feeling pretty confident when the contractions started to come, because I had my little app on my iPod to deal with them, and somehow help with the excruciating pain which was to build-up over the course of several hours ... that is until I realized, with horror and tremendous shame, that it kept on crashing. Of course, this was purely my fault. Just the day before, we had a perfectly working application. Sure, it was far from perfect, and there was a lot of polishing still to be done, but it had been tested and was fulfilling its purpose. I should have avoid touching anything since we were getting close to the due date, and thus we could need it at any time. And yet, on the morning of the 19th, I decided to start implementing some of the changes Susan and I had talked about. I was so certain that my changes will have minimum impact, and that we will have time to re-test it, that I didn't even register that I was stomping all over one of the most fundamental law in life: "if it ain't broke, don't fix it!". The results of my risky endeavour, was a fiasco (the baby still made it out A-Okay, so not everything bombed).

What is even more annoying, is the cause of the crash was pretty dumb, and only took a couple of second to figure out. If I had run into it while testing the app within Xcode, I will have seen it within the debugger.

Alas ... lesson harshly learned.