Austin Heller recently interviewed me and has just published the results.

An Interview with Daniel Jalkut

I like the interview format because it takes all the work out of blabbing my mouth off! It’s sort of like blogging, only I get to talk about several things at once, and don’t have to think of the topics myself.

Reading back over it, the topics range from my first Mac to how I feel about iPhone development. Austin did a great job of posing the questions and I did an acceptable job of answering them. Check it out!

Iron Coder 7 is coming up, and Jonathan Wight just announced that the top prize will be an iPod Touch! In other news the contest will run over the course of a week this time around, instead of the usual 48 hours.

I am going to need something to develop my iPhone/iPod applications on pretty soon.

Leopard brings so many little features that I am having a hard time devoting time to playing with many of them. One of the best-designed of these features is called Spaces, and supplies a familiar feature to anybody who has used virtual desktops on any platform. The basic gist is that you can switch between “virtual monitors”, each of which holds a different set of running applications.

In many ways Leopard is all about the animation, and it’s used very effectively in Spaces, where switching between virtual desktops comes with an instantaneous (even on my PowerMac G5) slide animation, as if your monitor was connected to a camera that is suddenly picked up and swept over to land on some other area of desktop real estate. Pretty nifty.

But I haven’t really gotten into the habit of using this feature, and therefore didn’t notice one way in which it sort of behaves awkwardly with MarsEdit. Fortunately, one of my customers noticed the problem and dropped me a line. I did some research and discovered what I believe to be the following truth:

Dismissing a modal sheet in an application causes Spaces to awkwardly zoom that application’s space back into vision.

This is particularly awkward with MarsEdit because while a post is being sent to the server, the post window puts up a sheet conveying that information to the user. If you send a post and immediately switch spaces, then when MarsEdit finishes publishing, it Spaces will zoom you right back to MarsEdit’s space!

I filed a bug, and Erik filed one as well. Hopefully Apple will agree it’s egregious and fix it in an update.

If you, like me, have essentially kept a single keychain from the dawn of time, there’s a feature in the Keychain Access application you need to know about: “Keychain First Aid.”

You find it under the Keychain Access menu, just below Preferences. Whenever I see anything unusual happening with my keychain, I try to remember to hop into Keychain Access and re-run this. Putting aside the question of why my keychain is allowed to get so routinely screwed up that it requires “first aid,” let me say that I appreciate this repair functionality because it generally solves problems quickly and effectively.

Starting with Leopard 10.5, I saw some really strange behavior. Sometimes keychain seemed to contain my web passwords, for instance, and sometimes not. I hopped into Keychain Access and did the first first aid dance. Whoah, mega-red warnings. The first thing that stood out for me is that I somehow had come into a situation where I have two keychains named “daniel”, each configured as part of my keychain search list.

It turns out that in my ~/Library/Keychains folder there exist two keychain files, but one of them contains the “.keychain” extension, while the other does not. I suspect what happened is at some point (in 10.5?) Apple decided to require that keychains have this file extension, so they quietly upgraded my existing keychain without removing the original. This explains my feeling that keychain was mysteriously showing duplicates for many keychain items!

What’s really mysterious though is the way it continued to access both keychains, apparently sometimes choosing from one and sometimes from the other. It made me wonder which was most up to date, but I couldn’t really guess since each had recent modified dates. I picked one and moved the other to the side as a “backup.” Now I’ve got a single “daniel” keychain, and everything should be fine. If I find myself missing a password, I’ll have to rename the backup to “bogus” or something, import it to Keychain Access, and search it for the password to copy over into the one-true-keychain.

(Note: Unless you’re a really old-timer like me, chances are your “daniel” keychain is called “login”. It’s probably wisest to keep it this way, because Apple’s First Aid also seems to get upset sometimes if there isn’t a keychain in the search list with that name. I stubbornly refuse to change, for now.)