Build or Buy?

Now that my one-person software company is well-established, some decisions that used to be hard to make have become no-brainers. For example, should I code a Java component myself, or should I buy a quality third-party component that does the same thing? Unless it is outrageously expensive, the answer is easy: buy, buy, buy.

The back story

I’m in an ongoing battle to make Poker Copilot less resource-hungry. It is a battle on multiple fronts. One front is detecting updated hand history files.

Poker Copilot scans every few seconds for new or updated hand history files. The scanning is inefficient, especially if you have thousands of hand history file. If you are a hard-core techie who finds it fun to watch Activity Monitor, you’ll notice that every few seconds Poker Copilot’s CPU usage spikes. This is due to the scanning for changed files.

The scanning is necessary, because Java doesn’t provide a way to be automatically informed of file updates. The upcoming Java 7 promises to have this feature, but Java 7 is not yet released. Java 7 seems to be one of those products that is promised and promised and promised for years but is never delivered.

On Mac OS X you can be notified of file system changes in Objective C, using the File System Events API. So I could code a small component in Objective C that sends a notification to Poker Copilot’s Java code. But this is messy and I’m an amateur at Objective C. And frankly, I don’t like Objective C, with its multiple personalities. When I mess around in Objective C, I feel like I need to have a shower to cleanse myself.

Enter JxFileWatcher. This is a commercial Java component that hooks into Mac OS X’s native file notifications. It’s not cheap, but if makes Poker Copilot better, and saves me as little as a couple of day’s work, it is easily worth it.

I’ve been running some tests on JxFileWatcher using the brilliant JVisualVM to make sure it doesn’t eat memory or CPU. So far, so good.