I was a little slow to pick up on the blogging thing. I have been writing in this particular forum for less than six months. Prior to that, I had a taste of blogging, through my connections with various friends on the LiveJournal site. Creating an ID at first just to post non-anonymous comments to friends’ blogs, I eventually started using the site as a podium for my occasionally funny and/or provocative observations on the world. It was nice to have a place to put humorous or sarcastic writing, where I knew I didn’t really have to own up to it. It’s just a LiveJournal ID, after all.

When I decided to start a technical blog, it was mainly because I wanted an outlet to share the results of my curiosity about the Mac. I’ve also learned a few things over the years, and a lot of the tricks and techniques might be put to even better use inside the minds of other people. It was clear to me, however, that my small but loyal group of LiveJournal readers was going to be utterly disappointed by a post like “Nerd Out with GDB” (my first entry on this site). Likewise, a Mac developer might think twice about subscribing to this blog if their first encounter with the site was reading about my foul-mouthed tuxedo tailor, or the fact that a highly esteemed restaurant in San Francisco has a name that is phonetically profane when read backwards.

I know some blogs try to get away with the “rounded personality” thing, but I’m just not into it. If I like your blog because you post really insightful things about programming or using the Mac, I am probably not that interested in hearing about your breakup with your girlfriend, or that you think you’re getting fat, or how the test at the proctologist turned out. I’m not even interested in reading that kind of crap from my close friends’ blogs! A lack of focus on a blog is a real killer for me. Some smart Mac users out there have blogs where half the postings are about the Mac, and half of the postings are about what CD they just bought, or something I don’t care about. I don’t subscribe to many blogs like that.

So I went the “split personality” route. I assume anybody who reads Red Sweater Blog does so because they’re interested in the aspect of my life that directly relates to using and programming computers. The downside to this decision is it presents a completely one-sided view of who I am. Sure, I’m a complicated person! Believe it! From time to time I try to inject a little more personality into my technical postings, occasionally going so far as to include something barely qualified for the blog like “Kool and the Nano Gang” (happily republished in the November 2005 About This Particular Macintosh). But mostly I just accept the fact that I’m going to be the “boring programmer” to this part of the universe. Heck, it’s my software business, so a certain lack of flair is probably appropriate!

Which is why it came as a surprise when Tim Gaden, whose prolific writings about Mail.app appear in his blog Hawk Wings, and who knows me purely through this “technical side” of my personality, sent me an email with the following question:

I nearly fell out of my chair with a mix of surprise and laughter. They’ve broken the code! Not that it’s too difficult to make this connection, but it doesn’t fall in your lap. My latest ego-googling on my own name reveals this funny truth about me in the first page of results. Still, I was wearing my “programmer hat” when this email came in, so I felt a little culturally displaced responding to this question. Umm, yes. Well, I suppose I am, aren’t I? Of course I am! Apparently one of Tim’s readers is an avid Trekkie and had recognized my name on Tim’s blog and made the connection.

The incident was amusing and reminded me that I’m a little jealous of the people who have their complete personality blogs on display for all to see. Thoughts on the world. Favorite music. Cool programming tricks. Last bowel movement. Etc. All wrapped up in a tidy, customized home page. When you come to Red Sweater Blog, all you get is “nerd this” and “nerd that.” And while the momentary jealousy did prompt me to write this entry, and to make an effort in the future to bring at least a bit more of “Daniel Jalkut: Cultural Superhero” to the blogging table, you’ll be happy to know that I will not be posting any updates from or relating to the restroom or devices contained therein. For that, you’ll have to find your way to my other blog.

I’m excited to see Xcode 2.2 unleashed for the world to enjoy. I’ve been using a pre-release of it for a week or two, and have been itching to share some of the less obvious improvements I’ve noticed in this release.

GDB’s Info Shared Command

Yee haw! How cool is this? The bug I described in this blog entry a while back is fixed! You can now use the powerful “info shared” command on variable arguments, for instance “info shared $pc” to see which library you’re currently stepping through.

Xcode’s Object File Targets

Xcode now supports a very convenient target type that bridges the gap between static libraries and dynamic libraries. With an “object file” target, you get all the export encapsulation offered by a framework, with the flexibility of compiling and linking afforded to static libraries.

For example, if somebody throws a pile of code your way that needs to be statically linked against your project, you can use the object file target to safely sequester all the symbols from that set of files into a single module that is linked with your existing code base. This is a real boon to avoiding conflicting symbols that may have otherwise needed to be marked as “exports” in a static library, in order to keep inter-module linkage working.

CHUD Tools “hwprefs” Permissions

On a less ecstatic note, the latest version of CHUD Tools includes a change in the security model surrounding the “hwprefs” command. In the past, anybody could use this command to, say, turn off CPU napping. If you’ve got a chirpy G5, you’re no doubt familiar with using this technique to work around the noise problems. Starting with this edition of CHUD Tools, if you’ve got a startup script designed to perform this task after every reboot, you’ll notice that it fails with a permission error.

A very helpful Apple employee pointed out that I can get the old behavior back by simply setting the sticky bit on the (root owned) hwprefs command:

sudo chmod ug+s /usr/bin/hwprefs.

Summary

Lots of great working coming out of the Xcode group. They are responsive and seem to be sensitive to the issues that really affect us developers. I’m looking forward to finding more happy (and hopefully no unhappy) surprises in the weeks to come.

I’m disappointed to see that Buzz Andersen has decided not to go through with a CocoaRadio interview he was slated for.

He’s entitled to make his own choices, but I just think this is ridiculous. Apple is not an oppressive authoritarian regime. It’s a company. A place you work for. A place that pays you to be there for part of your life.

California has some of the best laws in the country, by my understanding, for protecting the rights of employees to pursue endeavors freely outside of their employer’s control.

There only real restrictions on Buzz’s right to participate in a friendly developer community interview are that he:

1. Can’t do it at work, or via work’s equipment.
2. Can’t discuss information covered explicitly or implicitly by his NDA with Apple.
3. Can’t directly compete with Apple.

He also has the right to just plain not feel like doing it anymore because he’ll feel embarrassed, uncomfortable at work, whatever. These are all legitimate reasons for not wanting to do an interview – just wish he’d decided so before agreeing to do the show.

The way it has been presented on his blog make it sound like Apple employees are prevented from having public lives. This is obviously not true: just look at all the Apple employee blogs! It’s too bad Buzz is letting the flawed notion get to him as strongly as it apparently is.

For some historical perspective, the spirit of CocoaRadio is very much in line with the old “Factory Floor” articles done by MacTech, which *frequently* featured Apple insiders. These interviews spanned the ranks from Nick Kledzik down in the ditches working on Interfacer to Avie Tevanian shortly after he was brought in with NeXT.

This google search for MacTech “Factory Floor” articles featuring the phrase “at apple” yields a large number of these articles. While we’re suffering a drought of public representation from current Apple employees, at least we can still go back and browse these interesting developers from the past.

I like the Search-Fieldy kind of thing in Xcode. If you select the top-level project item in the “Groups and Files”, and then enter something in the search box, it makes it really easy to pinpoint a particular file that is contained by your project.

Apple even gave this search box thingy a keyboard shortcut, and include a menu item in the View menu for accessing it: “Detail”. I don’t really get the name of that menu, but needless to say it will switch you over to the search box thingy whenever you invoke it.

Problem is, I am almost 100% likely to want to search my entire project when I switch to it, but Xcode doesn’t do this for me. I hit shortcut and then I inevitably have to go click the project icon in the outline view before switching back to the search box to enter text.

Using GUI Scripting, I was able to solve this dilemma by writing a small script that simply clicks the project item for me before switching to the search field. The script asks the “Groups and Files” outline view for the “first top level item whose name is the same as the name of the project.” I’m pretty sure this will always be the desired row of the column, even if you’ve done some funky reordering of items.

Click here to download: Find Project File

I used FastScripts to assign an Xcode-specific shortcut override. Now when I hit the Cmd-Opt-F shortcut for “Detail” it behaves as usual, but clicks the project icon for me on the way.

Update: Xcode’s “whose clause resolution” started flaking out and giving me false hits, so I decided to just rely on the Project item being the first item in the Files and Groups list. This has the added benefit of making the script a lot faster, but it means it won’t work if your Files and Groups list is customized with the project not at the top.