Today I decided to take a real Sunday. That is, to turn the computer off and do some massive chore-handling that I’ve been putting off for too long. I decided to clean and reorganize my office. Or at least get started. At around 1:30PM EST, I shut off my computer determined not to turn it on again until around 7:00PM.

Everything went great. That is, I got a lot done. I took my entire desk “apart” and put it back together, in a new location. Rerouted a bunch of clumsy wires. Mopped the floor. Went through files, etc. Hours later, I hooked everything up and turned the computer back on, to make sure it all still worked.

I so picked the wrong day to do this. Upon returning to my Mail inbox, I was greeted by news of a comment on my blog, regarding FlexTime 1.2: “So how come when I go to download it via MacUpdate I get a ‘file not found’ error.” Nightmare scenarios immediately passed before my eyes. I put the wrong URL into MacUpdate? I forgot to upload the file to the server? Surely if something that wrong had happened, I’d have heard by now?

I decided to take a browse to MacUpdate and then to my server. Sure enough, the file was not found. What the heck? I typed “www.red-sweater.com” into the URL field and decided to browse my way to the problem. Here’s where Groundhog Day Syndrome set in: I’m staring at a several-months old version of my site. Old design. Old software releases. What on earth? How could this possibly have happened?

A couple days ago I decided to perform some good housekeeping of a different nature. Although my site has been hosted on Pair for several months, and was hosted on DreamHost before that since April of last year, my domain name registration has been maintained on a pretty user-unfriendly Tucows-based registrar called OpenSRS.net. Since I’ve registered some new names since then on DreamHost, I decided it was time to bite the bullet and consolidate everything into one place. DreamHost has been good for this type of administrative stuff, so why not?

Apparently everything finally kicked in some time this afternoon, as I was knee-deep in cleaning supplies and for once every computer in my office was unplugged and stacked in corner. No problem, right? They just took over the registration of the domain. Yeah, no problem, if you overlook the minor problem that they changed the root nameservers to their own! Ugh! So the reason I’m looking at a months-old version of my site is because I just so happen to have the account with them that red-sweater used to be hosted on, and that old stale directory is still there, unchanged.

I immediately try to rectify the situation by changing the root nameserver values back to their correct, Pair.com based values. In response to this I’m greeted with a lovely internal error from the bowels of DreamHost:

Can't call method "request" on an undefined value at

/usr/local/lib/site_perl/Ndn/Registrar/Registry/NewEPP.pm
line 2137.

Oh, that’s just great. I also notice in looking at my DNS configuration on DreamHost that I actually have a custom A record entry pointing red-sweater.com to my Pair site. Unfortunately, they insist on keeping their own A record pointing at themselves. So if you ask DreamHost for my domain’s lookup, they’ll give you a schizophrenic response pointing both to Pair and to DreamHost.

So I decide the only thing to do is get in touch with DreamHost support. For the first time, I feel sufficiently screwed by the situation that I choose for the severity of the problem the typically cheeky:

“OMG! EXTREME CRITICAL EMERGENCY!! EVERYTHING’S BROKEN! People are DYING!”

The only part that’s not literally true is the part about people dying. But I decided to choose it anyway. An hour later, people are still not dying, but everything is still OMG broken.

I took matters into my own hands. I could either stand by and watch while my customers are treated to a version of my site fit for a museum, or go into damage-control mode. Since I keep my web site’s files in a Subversion repository, it wasn’t too hard to go back to the DreamHost version of reality and “svn update” everything to match the modern-day Pair site. Of course I’m a bit lazy about adding and committing every thing as I do it, so I had to go back into Pair and do some heavy committing. Then do some heavy updating on DreamHost.

But aside from the fact that the speed of the site is back to the lackluster DreamHost level, everything appears to be more-or-less back to normal. I’ll wait patiently now for DreamHost to fix my registration to point back to Pair. But in the mean time, I guess nobody is going to die.

One thing I almost overlooked is the PayPal “IPN” payment notification, which is configured to bounce back to my site and let me know when somebody has paid for one of my products. I have this implemented on my Pair account in a way that relies on some full paths and such to log files on Pair. I really didn’t want to hack this together on DreamHost just to survive the unfortunate retransition. Then I remembered that thanks to Pair’s “one IP per domain” approach to shared hosting, I can point PayPal (temporarily) at the raw IP address version of my site. I’ll breathe a sigh of relief and assume that PayPal purchases will be fulfilled as usual. If anybody wants to buy something just to check, that’ll be fine by me :)

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.