Back in 2001, when I was still doing Java programming, I got tired of writing ad-hoc command line parsing code and wrote a small library to factor out the difficult bits. The Argv library is still available. If you want to know more about the library itself, I recommend the Dr. Dobb’s article that describes it.

Although I haven’t gotten around to porting it to ActionScript, Mark Northup has ported it to C++ and was kind enough to provide the sources for that version. They’re now posted to the Argv web page. Thanks, Mark!

I switched to using iCal when my MacBook Pro became my primary email machine a while back. Continuing to run Outlook was too much trouble because it meant keeping a virtual machine running all the time. I tried Entourage, too, but iCal was simpler yet sufficient for my needs. True, iCal doesn’t integrate with our corporate calendaring solution–but in my job that apparently doesn’t matter much.

I found that iCal under 10.4 was a bit on the slow side. Performance enhancements were rumored for 10.5; another reason to look forward to the upgrade. Yet after the upgrade, iCal seemed as slow as ever–and sometimes worse. It’s easy to find complaints about iCal on the web, I couldn’t find many practical steps for speeding up. Time to do a little digging.

My events are divided among five calendars. With all five displayed, even changing the view from week to week was slow. I’d seen one reference on the web about a particular calendar giving someone trouble, so I tried mine one-by-one. Sure enough, just one calendar–let’s call it “A”–was responsible for the slowdown.

This matched up with a hunch of mine: there was a repeating event on calendar A that was basically un-editable in iCal. It didn’t cause a freeze or crash, but it hung iCal up for so long that I never had the patience to wait it out. Searching through the calendar event-by-event for a troublemaker could take a long time; starting with this troublemaker seemed like a good idea.

First, I exported the calendar to an .ical file which–thankfully–is a line-oriented text format. It was over four megabytes. Running “grep SUMMARY A.ical | wc -l”–SUMMARY is the field that contains the name of each event–showed it contained about twelve thousand events. I’m busy, but I’m not that busy.

Following up on my hunch, I searched manually for the repeating meeting. There were many, many instances–over eleven thousand. That’s a lot–so many that if I’d been to this meeting once a day, every day since I was born I would had my eleven thousandth meeting just a few years ago.

How did there get to be so many instances? That I don’t know. I suspect it’s related to the fact that this meeting occurs four days a week, so there’s probably no built-in recurrence rule for it. Worse, on one of those four days the meeting is in an alternate location, so that’s an additional exception to the recurrence. Even so, eleven thousand is clearly excessive.

Should iCal have been able to handle this event without slowing excessively? Hard to say. It’s not a large number of events in absolute terms; someone with ten years of experience and eight meetings a day would have more events in their calendar. Still, I suspect iCal scales more gracefully across a large number of different events and that the culprit here is the bizarrely large number of instances for the same (recurring) entry.

I removed all instances of the meeting by hand, deleted the original calendar, and imported the patched up version. Result? iCal is fast again.

Bonus question: Given what little I’ve said about our development process, what meeting do I attend four times a week?

Fifteen years ago if you had to whip up some industrial strength tools from scratch there’s a good chance you’d have chosen C as your language. These days, there’s a much better chance you’d choose Java.

You can see this effect in the tooling for Flash and Apollo. Flash and Apollo are themselves both written in C++ and ActionScript. To create an ActionScript 3 application, however, you can’t avoid going through Java. Here are four examples:

You’ll be writing some ActionScript 3 code. That’s compiled to bytecode using a compiler written in–Java.

You might be using Flex. The Flex compilers (mxmlc and compc) are also Java wrappers around the underlying ActionScript 3 compiler. There are even Ant tasks for Flex on Adobe Labs.

If you use the Flex Builder IDE, you’ll note it’s a Java application written on the Eclipse platform. (You even have the option of installing it as a plugin to an existing Eclipse install–some Apollo engineers run it this way.)

If you’re creating an Apollo application then you need to package it in an AIR file for delivery. Packaging is done via “adt”, a little tool written in–yes, Java.

No doubt there’s more than one reason for this, and the simple fact that Java is now often the teaching language for first-year computer science courses may account for a lot of it. But I also think it’s got a lot to do with the fact that Java is a surprisingly good systems programming language–which is exactly what C was designed to be.

Java may not have thrived in its intended markets, but it has found a niche in a lot of developer’s toolboxes.