Sci-Fi Hi-Fi

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.)

One of the things I’m going to miss about working in Mac OS X Integration is having co-workers crazy and creative enough to actually write a spider to crawl the web in search of unusual (and often humorous) HTTP headers. As it happens, our own Andrew Wooster recently completed just such a survey, and the results are pretty amusing. My personal favorite excerpt from Andrew’s post is about the headers returned by the Democratic Party’s web server:

The Democrats called, they want you to know they found their sense of humor:

X-Dubya: You teach a child to read and he or her will be able to pass a literacy test.

Make sure to hit it a few times for optimum goodness:

X-Dubya: We’re in for a long struggle, and I think Texans understand that. And so do Americans.
X-Dubya: Africa is a nation that suffers from incredible disease.
X-Dubya: We’re making the right decisions to bring the solution to an end.
X-Dubya: Families is where our nation finds hope, where wings take dream.

See more over at Andrew’s site.

I’ve always thought that what makes del.icio.us so successful despite a lot of recent competition is that it exemplifies the same kind of thinking Tim Berners-Lee described in his “Axioms of Web Architecture” as the “Principle of Least Power,” or what the designers of the Internet called “end-to-end architecture.” Instead of trying to build a powerful, heavyweight system that would anticipate a user’s every need, Joshua and company have been building an extremely simple, general service that can be endlessly adapted and easily plugged into other systems.

The variety of “meta” tagging schemes del.icio.us users have evolved is great evidence of this. Probably the best known example, the “for:” tag prefix, has actually become commonly enough used that Joshua and company have given it formal recognition within the system, but there are lots of other schemes in usage. I’m a frequent user of “cite:” (to attribute links I get from other people), for example, and now that I’ve been using the new del.icio.us media support to run an ad-hoc podcast, I’ve been exploring the use of “meta” tags for music metadata.

It was this last usage that led me to an epiphany. As I started tagging songs I posted with metadata like “artist:thenational” and “soundslike:afghanwhigs,” I realized that I was, in effect, creating triples and using tags as a sort of poor man’s RDF.

For those who aren’t familiar with RDF (which is probably almost everyone, since RDF is rarely explained well), it might be helpful to pause for a moment to explain the concept of triples. The first thing you need to understand is that RDF is an attempt to standardize the way we represent the relationships between data, just as XML standardizes the way we represent that data’s structure. Information in RDF is expressed as a series of statements that each have a subject, verb, and object–triples. For example: The National [subject] sounds like [verb] the Afghan Whigs [object].

A collection of these statements is referred to as a “triple store,” which can be understood as a sort of ad-hoc database. While traditional relational databases require that new properties be formally added to the model either by adding new columns to an existing table or by adding additional tables, adding a new property in RDF is as simple as asserting in a triple that value X is a certain property of entity Y.

So, then, a collection of del.icio.us links containing “meta” tags can be thought of as a triple store. “Interesting,” you may say, “but why should I care?” Which is a very reasonable question given RDF’s current track record of real-world usefulness.

Well, as it happens, my del.icio.us/triple store epiphany has given me an idea for a Cocoalicious feature (yes, I do plan to release a new version of Cocoalicious some day). It occurred to me that I could turn Cocoalicious into a sort of free-form database by treating “meta” tags as triples, compiling a list of the implicit properties contained in these triples, and allowing the user to add columns displaying the values of those properties for each post to the main table view (probably by way of a context menu like the one you get by right-clicking on the iTunes column headers). That way the user could implicitly add his or her own metadata the Cocoalicious model, which could be used to sort and query the post list.

I suppose this feature might be too esoteric to be useful to that many people, and it has some problems (for example, how do we handle the situation where a single post has two values for the same property) but the Cocoalicious project is all about experimentation, so I think I’m going to implement it anyway. Anybody have any interesting thoughts on the subject?

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.