Litho Graph is now in beta!

I’m aiming to submit to the App Store sometime mid-January, and after that it’s up to them how long it will take ’til it’s on sale.

Still, exciting times! This is my first product, so I’m looking forward to hearing your thoughts on it. If you’re not already trying the beta, feel free to ask to and I’ll consider the request!

After far too long a wait, I’ve finally launched the new Monochrome Industries site. This design is roughly a year in the making—I hope you like it as much as I do!

Yep, that’s right—I’ve submitted Litho Graph to Apple for review1; the ball is officially in their court. This has been a very exciting process, and an equally draining one. I’ve learned a lot about the iPhone (and about foreign tax policy) and look forward to v1.0 being released as I work on v1.1.

1: If you want to get technical, I’ve actually submitted it twice. The first time it was rejected due to having a representation of an iPhone drawn on the icon artwork, which they took exception to.

I am extremely pleased to introduce you to Litho Graph 1.0, now available on the iPhone app store!

I’d like to thank my wife, Kelly, my beta testers (Dad, Jason, Joe, Jonathan, Melissa, and Melanie), Andrew, Andy, and Nathan for all their help and encouragement. Couldn’t have done it without you all!

Litho Graph 1.1 has been approved and is now available on the iPhone app store. Updates include but are not limited to:

• Fewer drawing artifacts.
• More usable screen space.

It’s a free update, of course, so get it while it’s hot.

The other day I realized that I don’t actually have a good performance metric for the speed of drive operations, for example compiles. Compiles are potentially quite slow since they can hit files all over the platter; random access reads, and especially writes, are brutal: it’s the worst-case performance for hard drives, and it is almost exactly what most normal everyday computing operations are limited by. How normal and everyday? Application launch time, for example, is bottlenecked by random-access read performance.

Lacking such a metric makes it difficult to assess the potential costs or benefits of putting files on one drive or another. For example, my boot volume is a RAID stripe of two 7200rpm drives; another volume is a 40GB 10,000rpm Raptor. Which is the better place to put /Developer and ~/Developer, when looking to optimize compile times?

I downloaded Xbench and ran a few tests of random access reads and writes to each volume, plus to a sparse disk bundle stored on the RAID stripe. And the winner…?

The RAID stripe, every time. Fascinating! For the curious, the difference between the RAID stripe

There are other metrics that are much harder to get but important to daily use of the system, too: How long does it take to spin up the drive? If I put /Developer and ~/Developer on another drive—which I did until I measured this ☻—and that drive spins down, how long will it take to spin up when I need to access something on it? This is annoying to measure, in practical terms, but it turns out that the fundamental answer is really easy: too long. Far, far too long. And it’s even worse if you boot off a single drive and have other stuff on the RAID stripe, since if that spins down, both drives will need to be spun back up, and the OS does it one at a time, not in tandem. (Why would it do that to me?)

There are two morals to this story:

1. Measure, measure, measure! Without measurements, you’re guessing, and even clever guesses are still guesses. (The above-mentioned Xbench is a great tool for turning hunches into figures, incidentally. Give it a shot.)
2. Bring on the SSDs! Random-access speeds are by far the best aspect of SSDs with proper firmware (i.e. not enterprise-oriented ones), and from what I’ve heard from colleagues of mine who have saved their pennies and taken the plunge, the result ought to embarrass hard drive vendors: application launch times, for example, are “lightning fast”.

Now we just need to get SSD capacities up and prices down, stat!

Precompiled (or, prefix) headers (.pch files) are a great way to speed up compilation, and also appear to let you save some lines of code; instead of writing #import <Cocoa/Cocoa.h> for every class header that derives from NSObject, you can just import that in the prefix header and be done with it.

This works, but unfortunately it conflates their purpose slightly. This becomes apparent if you build a framework that uses a prefix header and excludes the #import directives from its headers; clients of that framework will miss out on the headers imported in the prefix header, and may not be able to compile until they figure that out!

Another place this can crop up is in your unit test bundles; if your application uses a prefix header to import files not imported in the individual headers, your test suites may fail to compile until you import those files manually.

The good news is, being clever, this probably already occurred to you; if not, you’re still clever, just busy. ☻

I’ve been steadily my open-source projects (some trivial, some significantly less so) to my github for the past while, and as it approaches critical mass I thought it would be useful to link to them from this site.

Ergo, there is now a page for my released code, generally BSD licensed, and hopefully useful to you. I’ll likely be adding project-specific pages here with more information in my copious free time™, so it might be worth checking back occasionally. At the least, I’ll update the repos on github to link to new project home pages as I make them.