Sci-Fi Hi-Fi

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

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?

I have to confess, it’s been way too long since PodWorks saw an update. Well over a year, in fact. Part of this is due to my work on Cocoalicious, which consumes most of my non-work programming time; part of it is due to the fact that I consider PodWorks to be fairly mature and not really in need of a whole lot of bling-bling new features; and part of it is due to the fact that it’s been a long time since an iTunes update broke my database parser.

This streak ended with yesterday’s release of iTunes 4.9. The new iPod database format contains a new record type somehow related to podcasting, and it caused my parser to go off the rails. Fortunately, it was an easy fix, and I posted a new release this morning. If you use PodWorks, you’ll definitely want to download it.

The good news is that I didn’t need to do any additional work to add podcast support to PodWorks. The “Podcasts” list simply shows up as a playlist in the drawer, and the files within it can be accessed just like any other songs on the iPod.

Now, of course, I’m a bit curious what those new record types are for. Time to break out the old hex editor…

Andrew Pontious over at Helpful Tiger recently posted about a piece of software he’d like to see: an application that would scan emails (and possibly other text) and automatically pull out addresses and other contact information. This seems like a good idea to me–so good, in fact, that I could swear I remember hearing it before. Does anyone else recall there being some sort of Apple research project back in the (pre-Steve Jobs return) day that was doing something similar? Apple text filters, or something like that?

I swear it rings a bell, but maybe it’s just my own version of Roo Puffs…

(Update: Daniel Wilson has it: Apple Data Detectors. There’s still an SDK for it and everything, evidently!)

I decided to take a break from my normal rock and roll lifestyle (ha!) this evening to get some work done on Cocoalicious, with an eye toward doing a new release sometime next week. Specifically, I’ve been working on integrating and tweaking Eric Blair’s lovely favicon support patch.

In the course of polishing the favicon support, it occurred to me that we could improve performance a lot by pre-sizing the cached version of each favicon on download, instead of always resizing them on display (as it turns out, favicons in the wild come in all kinds of sizes). So I set to work changing the code to do just that, only to run up against a lot of confusion about just how to resize an image using NSImage.

At first glance it seems like the task is fairly straightforward. NSImage has a method called setSize, which the documentation says “sets the width and height of the image.” It seems like one should be able to simply read the data into the image, set its size, get the TIFF representation, and write that to disk.

Not so. As it turns out, setSize() only specifies how the image is displayed when it’s drawn–it does nothing to the underlying data. The most straightforward way to actually resize the data is to create another NSImage with the new size, lock focus on it, draw the source image into the new image, and then get the TIFF representation of the new, scaled image.

This may be obvious to some, but it certainly wasn’t to me, and I had trouble finding illuminating examples or explanations through Google, so I thought I’d post my code here to help anyone else who is similarly befuddled. If anyone has anything interesting to add on the subject, do let us know in the comments…

[sourceImage release];
[resizedImage release];


I just remembered that I have an even better example of Flickr synchronicity that I amazingly neglected to mention in my previous post on the subject.

As some of you may remember, back when I used Blosxom I spent a chunk of time developing a Blosxom photo gallery plugin called Pixom. When I started working on Pixom, I spent some time looking at prior art, and discovered that a New Yorker named DeWitt Clinton had already developed a plugin called photogallery. I ended up borrowing a lot from his approach, but adding things like on-board EXIF parsing. Because I thought he was a smart guy, I started reading his weblog.

Before long, DeWitt moved to San Francisco to work for A9, and I followed his apartment hunt with great interest, since I was about to go through a similar search moving from Cupertino up to the city.

When DeWitt started using Flickr, he and I added each other as contacts and started following each other’s photos. Eventually, I posted a photo of the, shall we say, distinctive view out my back window, as well as several from my building’s roof. A little while later, I got an email from DeWitt asking me if I was aware that he lived right above me. As it turns out, he has nearly the same view from his window, one floor above, and based on my Flickr photos he was able to determine that we were, in fact, neighbors!

I finally met DeWitt for the first time today, at our building’s rooftop party for the Haight Street Fair. It was pretty crazy sitting there on the roof talking to this guy whose weblog I had found through a Google search back when he lived on the other side of the country. I guess sometimes this social software stuff really does work–score another one for Flickr world glue!

Cocoalicious on Intel

Originally uploaded by ldandersen.

As people who follow my Flickr photos have already seen, I spent some time at the WWDC Intel lab this week, creating universal binaries of PodWorks and Cocoalicious. Since people have expressed some curiosity about how it went, I thought I’d do a quick writeup on the subject.

Doing Cocoalicious was dead simple. It doesn’t rely on any embedded frameworks or other libraries that don’t ship with the system, and all of its networking code is handled by Web Foundation (which means endinanness is not something it really has to concern itself with), so getting it working was literally a matter of checking the little “Intel” box in Xcode.

PodWorks was a bit tricker. First of all, like NetNewsWire, it relies on several frameworks embedded within the app bundle, both of which need to be built as universal binaries before PodWorks itself can (this actually only caused build problems, most of which only happened because I was trying to get the projects set up on an unfamiliar machine with a new version of Xcode). Second, it statically links eSellerate’s serial number validation library, which is currently only distributed as a built PowerPC binary. This meant I had to strip out the serial number code before I could get it to build. Third, though I swore up and down to people that PodWorks uses NSSwapShortToHost to reverse the byte order of the iPod database’s little endian strings, I was in fact using NSSwapShort instead, meaning (rather embarrassingly ) that I was depending on the host processor being big endian.

As bad as all of that sounds, they’re still (mostly) fairly minor problems that I was able to resolve while sitting there in the lab with people looking over my shoulder, so I think my experience bodes well for 90% of the Mac developers out there. I’m with James Duncan Davidson and Brent Simmons in calling for Steve to bring the Intel based Macs on!

The first person I ever got to know at Apple was a really smart guy named Eric Albert. I read his weblog back when I was an Apple-obsessed Java developer in Colorado, eventually he started reading mine, and when I started interviewing for my current job, Eric helped me a lot by explaining how the Apple interview process works and what I should expect.

When I finally got to California, Eric and I would do lunch occasionally and talk shop. The only problem was, it tended to be a bit of a one-sided conversation. I would tell Eric about how the latest OS update was going and so on, and he would tell me…not much. Eric was unusually secretive about his work–even by Apple standards.

More recently, though, Eric started talking optimistically about his super secret project actually shipping. My co-workers and I thought we had a pretty good idea what he was working on (based on his background and the kinds of bugs he tended to file), but we all had a fun time coming up with wild, rumor site-grade theories about what it would actually be used for.

Then, last weekend, while I was hanging out in Los Angeles, I woke up to find CNet’s scoop on Apple’s Intel switch in my del.icio.us links, and I immediately knew that Eric’s long hours at work recently were about to pay off.

Yes, it’s true: Eric is one of those mysterious people Steve Jobs mentioned in the keynote–the people who have been secreted away making sure OS X works on Intel. Now that the truth can be revealed, I think Eric and the rest of his team deserve a hearty round of applause–both for doing a lot to improve the long term prospects of the Mac platform, and ensuring that what could have been a nasty transition will likely be almost transparent (he even spent a lot of time enthusiastically helping developers port their apps in the Intel lab at WWDC, as the screenshots I posted to Flickr attest).

Nice work Eric–enjoy your vacation!

Before I post in detail about last night’s dinner (long story short: it kicked so much ass), I just wanted to take a moment to congratulate Dan Wood and Terrence Talbot on announcing their new app, Sandvox, yesterday at WWDC. Dan demoed it almost non-stop during the dinner last night, and I think everyone was pretty impressed.

Sandvox was intriguing to me because, while at first glance it appeared to be merely a very stylish WYSIWYG HTML editor, Dan’s demo quickly made it clear that a lot of its features (Blogger-style templates and automatic RSS generation, for example) are aimed squarely at the personal publishing/weblogging space (even its name hints at the goal of giving people a voice). I was also very impressed at the lengths Dan & company have gone to to hide the complexity of web publishing from the average user, ensuring that someone like my Mom would never have to deal with FTP (but without requiring her to sign up for a specific hosting service like .Mac). I won’t go into detail about it, but suffice to say their solution to the problem seems very clever.

Also, as everyone who was present last night probably heard me say at least five times, I do have a personal interest in Sandvox, since my little brother Bobby designed its lovely app icon. Now that his work with Dan has calmed down a bit (at least for now) Bobby has finally had time to put up his own weblog, and an interesting post discussing the evolution of Sandvox’s icon.

I’m back in Denver for Memorial Day, but the weather is so lousy that no one in my family has been able to build up the motivation to do much besides sit around my parents’ house. Fortunately, I’ve at least been able to use the downtime to get a lot of work done on Cocoalicious. The changes in 1.0b35 are mostly UI-focused, and include the following:

• Star Ratings: Cocoalicious now recognizes tags that consist entirely of repeated asterix characters as star ratings, and displays the ratings in the post table as graphic stars, à la iTunes. The ratings can also be manipulated directly by dragging in the rating column (again, just like iTunes). See the screenshot I uploaded to Flickr if you’re wondering what this looks like.
• Sortable Table Columns: This has to be the all-time winner for most inexcusable unimplemented feature in Cocoalicious. Fortunately, it’s finally in.
• “Type-to-Select” in Tag Table: Typing while the tag table has focus will now cause the first match for the letters typed to be automatically selected (à la Address Book). This extremely useful and timesaving feature is courtesy of Ken Ferry’s excellent KFTypeSelectTableView class.
• Delay of API HTTP requests: The del.icio.us API docs stipulate that clients should never submit more than one request to the API per second, and since the star rating feature makes that scenario a lot more likely, my del.icio.us API access code will now check to see if a second has elapsed since the last API request, and delay the request if it hasn’t.
• Assorted bug fixes: Including one for a crasher that could happen on reload.

I’d also like to preemptively say that I realize not everyone will use the ratings, and that some people will want to be able to hide the ratings column. I ran out of time to implement that in this release, but will work on it for the next one.

Update: Damn–it looks like Jonathan Deutsch has found a crasher in b35 that eluded me. Stand by for a fix.