Some time ago I had the great privilege of working for a week in New York City at the Fog Creek headquarters. Aside from getting a chance to meet Joel and the rest of the staff, I was also able to do some early exploratory work on the Mac version of Copilot, which went live today. This is a product based on a fantastically simple idea: VNC with no configuration hassles. Anybody who’s ever tried to set up a remote access connection to a person who may be technically naive, behind a firewall, etc., knows how significant removing the hassles is.

My trip to Fog Creek was a Copilot-heavy experience. Though only one of the original Aardvark interns was present at the time, the company was in the final stages of post-production for their Project Aadrvark movie. So I showed up just in time to meet the film’s director and join in company screening just before it went to production.

Up to now Fog Creek was “the best software company that doesn’t make Mac products.” Now I guess I’ll have to drop that qualification. Maybe now that one of their brightest engineers has been bitten by the Mac bug, we’ll be seeing other interesting stuff in the future. (Actually, they have shipped FogBugz, and an associated screen capture tool for Mac for some time).

One of the interesting aspects of this commercial venture is that both the helper and helpee processes are completely open source, GPL licensed code. How does Fog Creek make money by having customers download GPL applications? The mojo is all in the server. This is simultaneously how the company eliminates the configuration hassles and adds a monetary bottleneck to the offering. But at the new price of $5 for a full day’s use, I think many will find it’s worth every penny.

If you use Xcode often, surely you appreciate the “Code Sense Index.” This is the magic cache of symbolic info that allows tricks like command-double-clicking a variable name to jump to its declaration, or Opt-Period to complete a function name. Indexing makes life for programmers about one bajillion times easier.

Unless. Ughh!!!!! Angst, angst, angst! It’s got crap in the index. You jump to a definition, make a load of changes, build, run, and … nothing’s changed. What on earth? You thought for sure you fixed it. Finally you stumble upon the nuanced fact that the source file you’re editing isn’t located in your project directory. In fact, looking at the full path you see fragments like “.bak” or “old” or “copy” in the hierarchy. This is some bogus copy of your source base that you moved aside, but somehow Xcode caught up with it.

I’m not exactly sure how this happens, but I suppose the recommended procedure for fixing it is to click the “Rebuild Code Sense Index” button from the Project Inspector window. Heck, for all I know this might work. But it gives no feedback – no sense of whether the reindexing has started, or when it will be done. And especially no feedback about what it chose to index. Well, truth be told you can see some vague feedback about the indexing progress if you open the “Activity Monitor” window. But it’s still not completely reassuring.

I stumbled on the “xcodeindex” command-line tool, which is a real gift. With this you can not only explicitly remove the index, but you can recreate it with a variety of debugging log levels set, to see exactly what’s going on.

But Apple really made my day by including a “dump” option. For instance:

% xcodeindex -project FlexTime.xcodeproj dump > MyIndex

Yields a tab-delimited file containing all the indexed terms that Xcode knows about for my project. Nifty!

Anatomy Of An Index Dump

The index file contains thousands of rows divided into 5 tab-delimited columns detailing the symbol name, description, type, language, and file. Let’s take a look at a sample line from my FlexTime index, column by column:

adaptPlaybackToDisappearingItem:

This is the symbolic name, what I would have to double-click on to get Xcode to wake up and notice it was an indexed term.

-[RoutineDocument(Running) adaptPlaybackToDisappearingItem:]

This is the description, which seems to be what Xcode displays for instance in the popup menu when there are more than possible choices. Clearly this description will vary based on the language the symbol happens to belong to.

Instance Method

The type is probably the most interesting column, after name. In this case I’m told it’s an instance method. Other rows in the output include types like “Instance Variable,” “Function,” and “Type.”

Objective-C

Language. Well, that’s pretty obvious.

/Users/daniel/Sources/FlexTime/RoutineDocument+Running.m

Source file. Everything has a source file, including items from the System APIs, which point into the root volume or the appropriate SDK.

Great Expectations

What’s really exciting about this index dump file is that I can read it. You can read it. We can write scripts to do nifty analysis tricks with it. Xcode’s standard project indexes are kept in some (presumably) proprietary binary format that we dno’t have easy access to, but the dump file opens things up to the masses.

For instance, sometimes I’d really like to know the answer to questions like “which of my custom classes is depended upon by the fewest of its peer classes?” I’m not sure how I would figure that out (no doubt some of you will comment with another clever solution), but I’m pretty sure I can whip up a Python script to do the trick with this dump file.

Update: Well, call off the party balloons. The index dump file is cool, but not quite as cool as I was imagining. I just realized that because the “Instance Variable” types don’t indicate the type of the variable, they’re not very useful for tracking down dependencies.

We in New England and points north were treated to a Leopard Tech Talk from Apple today, held in glamorous Dedham, MA. I was very shocked and pleased to observe a huge crowd of attendees, and when I asked a member of Apple’s staff, he suggested that the number of registered attendees was around 400 people!

I never knew I was surrounded by so many Mac nerds.

Overall I had a great time, in spite of the fact that I woke up at an hour normally reserved for long-distance air travel. I started up my mostly-neglected car at 7:30AM, waited for it to warm up, and putted through the light snow to arrive in Dedham shortly after 8:00AM.

They reminded us early on that everything we would learn was subject to NDA. Well, not everything. Some of it is already public knowledge, or serves no purpose is staying secret, so I’ll share these vague observations:

1. Apple is delivering a kick-ass collection of developer-happy features in Leopard. Developers who see the set of features thus far revealed are inclined to ask: “Can I make my app 10.5 only?”
2. Sal Soghoian, who has graced this blog with comments, is a stellar speaker. I’ve never had the pleasure of seeing him perform before, and he’s got great style and grace, while making it look effortless. A real diamond for Apple.
3. Apple remembers the HIG, and may find time to prove it to us one of these days. They also understand the need to “violate” the HIG. Duh, that’s why it’s a guideline, and not a rule.
4. Apple has a magic quality that few other companies have. No, I don’t think this is just because I drank the Kool-Aid. Apple cares about quality. And they care about the user. This is evidenced by the raised eyebrows and the strained passionate voices of their employees as they explain the importance of various system improvements that will cause a better user experience.

I’m not exactly sure what the purpose of the Leopard Tech Talk Tour is, but I’m guessing it’s mainly to connect with developers and plant the message that Leopard is awesome. And if it’s important to plant that message, then they must realize that they need us. The goal of the talks is to excite my little developer brain, encourage me to renew my ADC membership, cause me to download and experiment with nifty new APIs, and pledge to remain a dedicated Mac platform developer. And, to feed me some cookies.

Mission accomplished.

As much as I basically like Xcode, let’s just say it’s not without its infuriating quirks. Among these quirks are a number of subtle bugs that seriously degrade its usability, but that only seem to appear after using it for several hours or days. Your text editors stop showing your changes, the spinning pizza of death is appearing more often, the index doesn’t quite seem to be working. Xcode has poor uptime, when compared with Mac OS X itself.

The workaround is, of course to simply restart Xcode when it gets flakey. But often this is an ordeal because you then have to go through your recent projects and manually reopen the one (or ones) that you were working on. I found myself frequently cmd-clicking the project window’s title to get a Finder reference to the project, so I could quickly reopen it after quitting.

Restart Xcode does all of this for you. Save the script to your ~/Scripts/Applications/Xcode folder, and keep it at easy reach from FastScripts or the Apple Script Menu. When you run it, it asks Xcode to quit, but not before accumulating a list of all the project documents you’ve got open. It waits for the quit to finish, then promptly reopens Xcode and all the documents.

Until Apple improves the uptime of Xcode, this script is going to save me a lot of frustration.