I’m registered for C4, Jon Rentzsch’s ambitious Mac developer conference in Chicago. Even though the event runs only one evening and the following day, it’s clearly a lot of organizing for one guy (even with help) to pull off. Kudos to Rentzsch!

Registration is limited to 75 developers, so I was quick to pull the trigger and sign up. Apparently there are only about 20 spots remaining, so I guess I was smart to do so. The quick enrollment is great news because I assume it all-but-ensures Rentzsch a break-even scenario (and hopefully he’ll even earn a little profit for his troubles).

While most of the session descriptions don’t exactly jump out and scream excitement to me, the people who are delivering them are top-notch and it will be fun to hear what they have to say. I’ll have to finally get around to reading the Subversion Book so I can grill Brian Fitzpatrick on anything I still don’t understand.

Mostly though, C4 is for me a chance to make up for the socializing opportunities I missed by skipping WWDC this year. I already know that several people I’ve been anxious to meet will be present (including Rentzsch himself), perhaps you’ll also be among them? Comment here if you are planning on being there, so I can keep my eyes open for you!

Update: Thanks to Jeffrey in the comments for pointing out just how insane lodging is the weekend of C4. It’s looking pretty much impossible to find anything for less than $300/night anywhere within a few miles of the event. I’m probably going to end up staying somewhere out near the airport and just suffer the train ride in and back. The airport train runs all night long so I think this is a pretty reasonable compromise (for a savings of around $400).

Just got back from Boston PodCamp, which was my first foray into the world of “UNconventions,” where attendees miraculously do not have to pay for anything. I’m impressed by the overall level of organization for a free event, though I was a little disappointed by the panels and seminars I attended. They were generally very short, and so short as to be pretty light on content. Still, can’t complain for the price.

The most inspirational session to me was a session presented by Larry Lawfer and Mark Blevis on interviewing tips and techniques. I’ve been mulling over the idea of giving the interview podcast format a try, because I think there are some not only interesting but very talented people in the Mac development community who would have a lot to say if given a chance.

Of course, I am a great fan of Blake Burris’s Cocoa Radio, which does a great job of introducing us to some of the platform’s leading developers. But I think there are so many voices to capture, that we need more podcasts tackling the same or similar material, from slightly differing angles. In particular I think I could, if I didn’t turn out to totally suck at interviewing, do a good job of extracting very technical information from Mac developers. While Cocoa Radio spends a lot of time talking about inspiration and history, sometimes I really want to know “how did you decide on the data model structure?” or “what are you doing to handle concurrency problems with your threads?”

Perhaps that would lead to the world’s most boring, unlistenable podcast. But then again, you’re reading this blog, aren’t you? Now … to decide on my first victim, ahem, guest. Quick, before the motivation wears off.

I’ll let you in on a little secret. Well, it shouldn’t be a secret by now, but you’ll know I’m talking about you when I say that not everybody has gotten the memo yet. Don’t be embarrassed – today is the day you come into the light (not the “just died and moving on to a happier place” light, but close to it).

Cocoa is better than Carbon. And Carbon is better than Cocoa.

If you admit to me with a straight face that you know only one and refuse to venture into the other, I will immediately form the opinion that you are a bad programmer. A programmer I’d hate to be stuck in a MacGyver episode with. You couldn’t program your way out of a box. Or an NSRect. Or a RgnHandle. You sad, pathetic sack of unadaptable protoplasm. I loathe you. Actually, I love you. You make it easier for me to shine. If you don’t embrace and use every appropriate tool at your disposal on Mac OS X, well, you deserve to write crappy software! (And yes, in case anybody is wondering, I do think this means sometimes POSIX is better than Carbon, and Python is better than Cocoa, or Ruby is Cocoa — it all depends on what you’re trying to do).

The saddest thing in all of Macdom is the sight of Cocoa and Carbon purists crying in their mailing list beers because a given task is “impossible” in the API of their preference. Often a fearless API-hopper like Jim Correia or John Stiles will pop up and cheerfully announce a one-line solution to their woes. In the opposite API than the original poster had hoped, of course.

“Thanks for the response, but I’d like to keep this as pure as possible.”

Excuse me, I thought you wanted a solution. You idiot! What they really mean to say is “I learned this framework 10 years ago and I’ll be damned if I have to learn anything new now.” Yes, believe it or not, even Cocoa has idiots from 10 years ago who refuse to admit that there is value in Carbon. But by sheer force of numbers, the Carbon idiots are the sadder of the bunch.

Wake up people! It’s 2006. It doesn’t matter what you program in, it’s how you get the job done. Arguing about whether to use Carbon or Cocoa is like arguing about whether to use a net or a hook to catch a fish. You use whatever the circumstances call for. If you don’t, you die. (This, from the vegetarian, city-dwelling Mac programmer).

Why am I rambling on in this unusually caustic mood? Just a good excuse to get this off my chest and toss some code out that I’ve been meaning to share. It’s nothing special, but it will be good to seed google with it, and it is very well suited to the genre of code that can only be accomplished by a Carbon/Cocoa double-play.

Download NSImage+RSCarbonIcon (Free MIT License).

[[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode([whateverTypeCode])]

This simple category on NSImage lets you easily produce an NSImage based on a Carbon “Icon Manager” type code. You’ll find a long list of these type codes in Icons.h, beneath the kSystemIconsCreator enumeration. Generic folder? No problem. Computer icon (inaccurate, but hey)? No problem. All of these NSImage at your disposal, which would otherwise “be impossible.”

It’s also useful in that it demonstrates how to properly make use of Carbon IconFamily data in a mixed-endian world. Thanks to a little documented caveat, these structures must always be treated as big-endian. So even if you figured out how to use the Carbon Icon Manager by yourself, maybe you’ll find it useful that this code sample ensures endian-safety across both PowerPC and Intel platforms.

I imagine FastScripts users might be feeling a little neglected, what with all the attention I’ve been giving FlexTime over the past several months. But worry not, I’ve been collecting improvements for FastScripts all along, and am nearly ready to release a 2.3 version of the app.

It’s actually pretty close to ready for shipping. But it would be nice to have a little 3rd party testing, because quite a bit has changed. Click here to download the 2.3b2 release.

The most “scary to me” parts that have changed are all infrastructure-level. At the user feature level there were a bunch of minor enhancements and these more substantial changes:

• Grayscale Menu Icon. For years a vocal minority has copmlained about the colorful FastScripts icon being both distracting and clashing with the appearance of Apple’s icons. They finally convinced me to agree with them. I know some people will miss the old icon, so I’ve left it in as a preference choice. The grayscale icon will probably see a few minor tweaks before 2.3 ships, so let me know what you think of it.
• Modifier-free Shortcuts. Up until now FastScripts has only supported keyboard shortcuts where some modifier key is held down (except for the special case of Function Keys). I was hesitant to add support for plain keystrokes, because it’s easy to imagine users getting themselves into trouble. But there are a few examples where overriding a bare keystroke (usually in an application-specific context) is a useful thing to do. Just beware that you won’t be able to type that keystroke into any text after you’ve set the shortcut. FastScripts will warn you when you attempt to set such a shortcut, so don’t worry too much.
• Preference Window Overhaul. Well, maybe overhaul is too strong, but things have been shaken up. I’ve added a new “General” tab to house a new UI for controlling whether FastScripts is in your Login Items or not. That feature is long overdue. I’ve also moved some other preferences into that pane, where they seem better suited.

I’m really looking forward to hearing your impressions. Please let me know especially if you run into any problems.