Sci-Fi Hi-Fi

Sheesh–sometimes I forget how many people actually read this stuff. Now that Robert Scoble and Daniel Jalkut have taken notice of my decision not to go ahead with my CocoaRadio interview, I feel compelled to offer some further context.

First, to address Scoble’s comment, I wasn’t ordered by Apple PR not to go through with the interview–I was simply reminded by a higher-ranking colleague that Apple has certain procedures employees are supposed to go through before talking to “the media,” and that I had not gone through them. So, to be clear: I was not “officially” shut down–I just hastily did what I thought was prudent in light of what I was hearing.

Second, to address Jalkut’s criticism: yes, I did silence myself. I do appreciate his appraisal of my legal situation, however, I would remind him that Apple is an “at will” employer, and as such, may terminate me without providing any reason (as long as it’s not related to age, sex, national origin or disability). I’m not saying that would necessarily have been the result of me going through with the interview, but I think it’s important to note that the legal protections he describes would probably not apply.

The issues involved in my giving an interview to Blake are complicated. I would argue that I wouldn’t have said anything on CocoaRadio that I wouldn’t have also said on my weblog, and that the interview would actually have been beneficial PR for Apple. I planned to tell the story of how I became a Mac developer (which I think could be very inspirational to aspiring shareware authors), what it takes to develop a successful Mac app, why the Mac is a great platform to develop for. I would also argue that what I would have done there was no different from what Apple employee/former indie developer Eric Peyton did by appearing on a panel for Evening at Adler. Essentially, I’d be talking enthusiastically about my personal interests. Unfortunately, my personal interests overlap pretty strongly with my employer’s, and my employer has policies (and cultural aversions, I might add) about employees being too visible in discussing Apple-related matters.

That said, I’m not really sure what I’ll do now. I may try going through the prescribed chain of command to get permission, but I’m not sure that would be worth the scrutiny it would bring me. Most likely I’ll just maintain the status quo, and continue walking the fine line I’ve been walking for years now.

Well, I know that every Apple employee reading this is going to raise an eyebrow when I make this announcement, but here it goes: I’ve agreed to be interviewed by Blake Burris for his CocoaRadio podcast.

If you’d like to ask me about something that doesn’t involve Apple too directly, Blake is currently soliciting for questions. This may, in fact, be your best opportunity to get a straight answer out of me given my abysmal email response record lately. I look forward to your queries!

(Update: It’s off. I’m getting the feeling that people at Apple would have a problem with me doing this, and it’s not worth risking my job, so I’m going to bow out. Apologies to Blake and everyone else–it was bad judgement on my part.)

(Update 2: Decided to remove a snarky sentence in the original post.)

I feel like I’m keynoting my very own MacWorld Expo today, what with being able to announce updates across the entire Sci-Fi Hi-Fi product line. In addition to a rather routine PodWorks update, I’m pleased to announce the first new release of Cocoalicious since I went on my summer hiatus, and, if I do say so myself, possibly the best release evar. As Steve would say, we think you’re really going to like it.

Here’s what’s new:

Favicons: Cocoalicious now displays favicons for each site in the main post list, in much the same way Safari does. Icons are automatically downloaded for new posts, and are refreshed every time the bookmark is viewed in the built-in browser. Thanks to Eric Blair for his work on this, as well as Ken Ferry for his help.

Automator: Cocoalicious AppleScript czar Armin Briegel has implemented some minimal Automator support for Cocoalicious. Examples of things you can do include finding every post within a certain date range tagged with “toread” and sending the URLs to Safari to open. My experience working with these actions so far has been a bit troublesome (I suspect due more to Automator wonkiness that anything else, but I’m not sure yet), so definitely treat them as beta.

(Slightly) Improved AppleScript: There is now an AppleScript property to get the current selected post (I implemented this to improve the Automator support).

“delicious:” URL scheme: I think this last minute contribution by Gus Mueller may steal the show for this release. What Gus has done is make Cocoalicious register to handle URLs beginning with “delicious:”, and automatically come forward with a pre-populated posting sheet when the system sends it one. So a URL like
“delicious:url=http://www.scifihifi.com&description=Sci-Fi%20Hi-Fi,” when clicked in a web page link, will cause Cocoalicious to bring up its posting sheet pre-populated with “http://www.scifihifi.com” for the URL and “Sci-Fi Hi-Fi” for the description.

What makes this extra cool is that it makes a “Send to Cocoalicious” bookmarklet possible. Just drag that link to the bookmark bar in a browser that supports bookmarklets (Safari, Firefox, Camino, OmniWeb releases greater than 4.5), and you instantly have a convenient button to send the current page to Cocoalicious.

Improved authentication: We all owe Mike Smochko a lot of thanks, because he’s been helping take care of some of the less glamorous coding chores in Cocoalicious–things like making sure errors get displayed for things that go wrong (something Cocoalicious is currently very lax about). For this release, Mike improved the login dialog to make it show an error (rather than simply fail silently) for incorrect logins. As a result of this work and some related improvements to Cocoalicious’ keychain support, I believe using multiple accounts with Cocoalicious should also be bit easier.

Case insensitive tags: The tag “Mac” is now treated exactly the same as the tag “mac.” I believe this is more in line with the way del.icio.us does things.

And, of course, who can forget assorted bug fixes!

All in all, I think this update does exactly what any good Apple software release should: it fixes a load of long-standing complaints, while providing some eye candy for the box. Thanks again to all the contributors who made it possible!

Last week I finally got around to fixing the problem that caused PodWorks 2.8.4 to break on Jaguar (thanks a lot Xcode 2.1/GCC 4.0!) and while I was at it I decided to fix a few long-standing bugs related to the iPod selection pop-up list. I also took advantage of the opportunity to confirm that PodWorks works correctly with iTunes 5.0 and my new iPod nano. If you’re a PodWorks user, be sure to get the update.

Today’s announcement of iTunes 5’s “folders” feature and the relatively small capacity iPod nano reminded me of something that I’ve been meaning to write about for a long time: my iPod management scheme. I’ve long been convinced, you see, that the iPod mini is (now was, sadly) the finest iPod Apple has ever released, yet I’ve got far more music than I could ever fit on mine at one time. Fortunately, I’ve developed a very effective scheme to help me choose what music stays on my iPod while still ensuring a steady diet of fresh content.

There’s definitely some distinguished prior art in the limited size iPod management field, ranging from Bill Bumgarner’s old random sampling method to Willo O’Brien’s more interactive multiple smart playlist method. My own approach is similar in spirit to Willo’s (which involves automatically syncing both a playlist containing checked songs and a playlist containing recently added songs), but it’s based more directly on actual listening patterns. I’ll call it the journaling method.

Here’s how it works:

1. Create a playlist called “iPod sync” (or something to that effect), and set iTunes to automatically sync it to the iPod.
2. As you get new music, add it to the iPod sync playlist manually. Usually I just drag whole albums in there.
3. Every month, compile a “Favorites” playlist containing the 10 or 12 songs you most enjoyed that month. I usually give priority to that month’s new music, although I try to simply make the list reflect whatever songs I really am enjoying. It may help to use On-the-Go Playlists created on your iPod as a sort of listening journal to remind you of what you were listening to at specific times (as you can see in this screenshot, I generate lots of them) and help you compile the final list. Lastly, you may also want to compile a yearly list of overall favorites, based on the results of your various monthly favorites lists.
4. As you create them, add your favorites lists to the list of playlists iTunes automatically syncs to the iPod.
5. As you get tired of old albums or start to run out of room for new albums on your iPod, begin to remove older music from your iPod sync playlist.

The beauty of this scheme, in a nutshell, is that it allows you to cull large swaths of old stuff from your iPod, while still ensuring that your absolute favorite songs stay on. Even though you may remove an entire album from the iPod sync playlist, your favorite songs from it won’t disappear because they’ll be present in the other playlist that get synced to your iPod (the favorites lists). And that’s a comforting thought.

Of course, like the other methodologies I mentioned, this scheme won’t work for everyone. It happens to suit me well because, first, I tend to be song rather than album-oriented (I subscribe–with a big grain of salt, of course–to the Phil Spector definition of most albums as 3 singles and 7 pieces of shit); second, because I’m incredibly fastidious and (as the British say) anorakish when it comes to music listening; and, third, because (like Jason Goldman in his excellent post on the subject) I tend to develop powerful enough associations between songs and times and places that keeping a sort of music journal is attractive to me.

Whatever the case, hopefully at least a few other music nerds out there will find this a helpful solution to their iPod mini or nano woes. I’d be curious to hear about other peoples’ novel solutions to the same problem…

After a long summer hiatus, I’ve finally started working on Cocoalicious again. A few nights ago I finally got around to converting the project to Xcode 2.1 (which means that, thanks to Xcode’s new file naming and CVS’s maddening inability to remove directories, contributors will now have to remember to open the “Delicious Client.xcodeproj” file, not the “Delicious Client.xcode” file). And, more interestingly, last night I checked in significant performance enhancements to the existing favicon code, meaning that the current CVS version is 75% of the way to a shippable favicon implementation (I just need to make it so that favicons are downloaded for new posts, and provide a menu item to refresh the entire icon cache).

Other priorities for the next release include improved authentication (which has mostly been implemented by Michael Smochko), some Automator actions (which have been mostly implemented by Cocoalicious AppleScript czar Armin Briegel), and a universal binary. I’ll also try to address as many of the bugs Jon Hicks and others have been good enough to report on the Sourceforge site.

Finally, if you’ve contacted me recently about contributing and I haven’t responded, please accept my apologies. Like Rentzsch, my email latency has been extremely high lately due to general summer busyness and my move to a new job, and the project (with its half-completed favicon implementation) wasn’t really in great shape for other people to work on.

I just discovered through Technorati that Peter Rukavina posted a screencast explaining how to use Cocoalicious and NetNewsWire together. I’m always excited to see people doing stuff like that, since I think a lot of users are unfamiliar with the fancier things Cocoalicious can do (other examples include Services support, AppleScript-ability, Full Text Search, etc.), and I barely have time to work on the thing these days, let alone document it. If anybody else has put together useful how-to’s like Peter’s, let me know and I’ll link to them.

(Update: Peter’s site seems a bit slow right now, but hopefully that situation is only temporary.)

Now that I’m leaving my position in Mac OS X Integration for a spot in Pro Apps, my team is going to have a job opening to replace me. This position is a great opportunity for a recent college graduate or less experienced person to get a foot in the door at Apple and work with a fantastic team (I’m not just saying that, by the way–they really are the finest group of people I’ve ever worked with) on an operating system that is used and admired by millions.

If you have good CS fundamentals, know your way around UNIX, have enthusiasm for making OS X the best it can be, and are creative and entrepreneurial, we would very much like to talk to you. Feel free to drop an email to “buzz” at this domain if you’re interested!

(Update: Please note that current geographic proximity to Cupertino is not necessarily a prerequisite here. We’re interested in hearing from qualified candidates wherever they may be.)

As many of you may have guessed based on my weblog post about interviewing, I’ve been in the market for a new job recently. My current gig with Software Update Integration (a branch of Mac OS X QA) at Apple has been a great experience, and I owe an enormous debt of gratitude to people like my boss, Dennis Gately and my colleagues Andrew Wooster and Peter Ammon, who moved me to California and gave me the biggest break of my life. In many ways, their willingness to take a chance on me has had a decisive impact on my life, and I have benefitted enormously from the time I’ve spent with them.

Even so, I came to Apple almost exactly two years ago with one goal in mind–to eventually do development work on a shipping Apple product–and I’ve never lost sight of that. Thus, while I’ve been working to ensure the quality of Mac OS X updates, I’ve also been looking around for an engineering position that would be a good fit for me. Today, I finally accepted an offer for what I think will be a fantastic opportunity: an engineering position on the Soundtrack Pro team.

I’m excited about this position for a number of reasons. First, it will be an opportunity to finally devote my full attention to what I consider to be my real interest and forté: Cocoa programming. Second, in the long-term it could give me exposure to some fascinating programming topics I’d be unlikely to encounter otherwise (e.g. real-time programming, signal processing, Core Audio, etc.). Third, it gives me an opportunity to reconnect with one of my earliest uses of computers (I’m fond of telling people that my first use of the Internet was to FTP guitar tablature from OLGA, and my favorite thing to do with my old Amiga 500 was to spend hours with my friends constructing primitive mashups using a crude, serial port-based sampler). And lastly, corny (and vaguely Marxist) as it may sound, it allows me to be a part of the ideology that, in my estimation, has always made Apple special as a company: the quest to democratize creativity by bringing powerful production tools to the masses.

Many thanks to Corey Peterson, Dan Schimpf, Jason Marr, and everyone else on the team for giving me the opportunity. I look forward to learning a lot from you and, as my colleague Jonathan Deutsch is fond of saying, exceeding your expectations.

It has not escaped me that both Macintosh applications I have released use the controversial metal window style, and, though I’ve been known to defend metal windows against charges of ugliness, I do occasionally find myself apologizing to people who think they’re getting out of hand. Every time I do, however, I remind myself that, unlike most indie developers out there, I at least understand the cardinal, unwritten rule of metal window design: for God’s sake, minimize the amount of visible metal!

Look at iTunes, iPhoto, iCal, NewsFire, Cocoalicious, or Delicious Library, and you’ll see this principle followed religiously. Compare this with the vast majority of metal indie apps out there (see, for example, Cinematics, which I’m not picking on–I just happen to have found it through Daniel Wilson’s del.icio.us links today), and you’ll see a different story. Notice the wide margins, all metal drawer, metal inset boxes, and the vast sea of metal at the bottom of the window? This kind of thing is what makes metal windows look heavy, and why they have a reputation for being ugly.

If you plan to develop a metal app, here’s my advice:

• Use small window margins. Even smaller than the ones specified by Apple’s UI guidelines. Look at iTunes, iPhoto, or iCal for examples.
• Use iTunes style bezels around table views and other boxes. AppKit doesn’t provide them out of the box, but the Cocoalicious project contains a class to draw them.
• Try not to use a toolbar, but if you must, follow Adam Betts’ advice about using back shadow instead of floor shadow on your icons. Or, do what Cocoalicious does and use NSSegmentedControls on a very thin toolbar.
• Try not to use a drawer, because metal drawers look icky. If you do, remember to follow the principle of minimizing the visible metal (see iCal and PodWorks).

Contrary to the common perception, metal apps need not be ugly, and I think that if more developers were to keep these principles in mind, they wouldn’t be.