SXSW 2006 (Saturday)
Originally uploaded by Laughing Squid.
Just thought I’d break weblog silence to mention I’m currently sojourning in my favorite home away from home, Austin, Texas, for South by Southwest. I’ll be here for a good long time (for both the Interactive and Music parts), and I’m all about meeting new friends (or old friends I only talk to online), so drop me a line (my first name at this domain) if you’re around and would like to say hello!
Now that I’m finally spending a quiet night at home, and working hard to get through the 500 odd unread items I have in NetNewsWire (to say nothing of my unanswered email!), it’s becoming painfully apparent to me just how out of the weblog loop I am. People I once considered “light” posters are now producing three or four posts in the time it takes me to do one, and the Mac developer blogging torch seems to have been passed to a new generation of people like Daniel Jalkut, Jonathan Wight, and Blake Seely. Sigh.
The other thing about my absence from the blogosphere is that I haven’t really kept up with what all webloggers fundamentally care about: what people are saying about me! Because of this I failed to notice that Aaron Feaver tagged me with a dreaded meme! Since I’m no longer the type of blogger who has, you know, delusions of importance, I’ve decided embrace a little blog candy and run with it. And awaaaay we go!
Four Jobs I’ve Had
Four Movies I Can Watch Over and Over
Four Places I Have Lived
Four TV Shows I Love to Watch
Four of My Favorite Dishes
Four Websites I Visit Daily
Four Places I Would Rather Be
If you’ve been reading Dan Wood’s weblog or my del.icio.us links recently, you may have noticed that I’ve become something of a Javascript Object Notation enthusiast. Though JSON, an object serialization technology for Javascript, has languished in relative obscurity for awhile, I think there’s a lot of evidence that it’s about to assume a new prominence in the coming post-XML age.
Awhile ago it dawned on me that JSON bears more than a passing resemblance to old-school NeXT plists, and that it would be pretty natural to write an NSDictionary category that could deserialize a JSON string into a Cocoa object graph. I set about working on it whenever I could find the time (on the plane to NAMM last month, for example), but, sadly, my spare coding time just isn’t what it used to be these days (blame it on my daytime coding job and an increasingly busy social schedule).
Fortunately, it appears my LazyWeb influence is now strong enough that I no longer need to code my own ideas. I happened to mention my idea to Blake Seely during dinner at MacWorld, and he ran with it. Then, not to be outdone, Jonathan Wight revealed that he too had been working on a Cocoa JSON implementation. I haven’t had the time to look at either implementation yet, but at the very least I think the fact that we have not one but two really confirms JSON’s status as the web services technology of the moment.
Since I’m at home sick today, and I’ve been a little bored just laying in bed, I decided to look into a small project I’ve been meaning to tackle for awhile: integrating Andy Matuschak’s excellent Sparkle software update framework into Cocoalicious.
If you’re a small developer looking for an easy way to add a software update mechanism to your application, I can’t recommend Sparkle to you in glowing enough terms. I tend to have a lot of admiration for no fuss, minimal-yet-powerful Cocoa code (think NSString+Templating), and Andy’s framework is a true marvel in that department. I wrote literally no code to integrate Sparkle into Cocoalicious–including an application menu item that manually checks for updates and a preferences window checkbox that controls whether or not Sparkle should check for updates on startup. Once Sparkle discovers that there is an update, it even handles all the details of downloading it for the user, decompressing it, and quitting and relaunching the app! The whole package makes good on the promise of Fraser’s appcasting idea in a very, very slick way.
And, what’s more, now that Cocoalicious 1.0b40 has automatic updates, you officially have no more reason to read my weblog! Perhaps I’ll have to actually come up with something interesting to say rather than simply blathering on about Cocoalicious updates…
Since Jonathan Deutsch finally got around to writing about the experimental tag UI he implemented for Cocoalicious, I thought I’d do a quick post of my own to point everyone to his write-up and mention that I’m curious to hear peoples’ feedback about the design.
As Jonathan mentions, he, Andrew Wooster, and I demoed this UI at TagCamp back in October to what I would characterize as a mixed reaction. Many people loved it, but others were concerned that the effect of the tags constantly re-ordering themselves was too disorienting. I, on the other hand, would argue that when you reach something like 900 tags (as I have on del.icio.us) spatial orientation is practically useless for navigation, and what you really need is something to help you quickly explore the relationships between your tags. And besides, the only alternative approach anyone suggested at TagCamp was the Treemap, which I think is a lot more confusing than what we came up with.
One of the things I personally love about this interface is the way it helps me discover unexpected connections in my accumulated del.icio.us knowledge. When you have 2000+ bookmarks, as I do, it’s very likely that you only remember a tenth of what you’ve actually bookmarked, and, while it may be a given that my related tags for, say, “intellectualproperty” would include “music,” it might be less obvious that they would also include “ireland” or “cooking.” It’s certainly possible to uncover such unexpected connections using the normal del.icio.us “related tags” interface, but Jonathan’s UI makes this process of drilling down almost as fast as thought itself.
Tagging (at least del.icio.us-scale tagging) presents what is almost certainly one of the most difficult UI challenges I can imagine. I’ll be interested to see how useful people find our solution once it makes it into a released build.
I’ve been slowly hacking away at one of the holy grails of Cocoalicious development–local caching of posts–for quite sometime now, and I think I finally have a build ready for public consumption. That is to say, it’s very far from perfect, but I’ve been living on it for about a week now, and it seems usable and unlikely to do much harm. And, really, what more can we ask from our software?
As a del.icio.us user, I’m thrilled to finally have local persistence going, because it means:
That’s the good news. The bad news is that local persistence still has a lot of rough edges. Here’s some caveats to be aware of:
All of that aside, though, I think this release greatly bolsters Cocoalicious’ utility by adding a feature that almost certainly could only be done on the client side, and it hopefully paves the way for some more interesting features in the future. Be sure to give it a whirl!
I’m pretty mired in a variety of difficult Cocoalicious “science projects” right now (including local caching of del.icio.us posts and improved full text indexing), but I keep getting emails asking me to integrate a new patch Gus sent me to improve his original del.icio.us URL scheme support, so I’m rolling a special build just to do that.
The new patch adds “extended” and “tags” parameters to the URL scheme, which means that now we can offer an improved bookmarklet that takes advantage of the Javascript window.getSelection() method to send the browser window text selection to Cocoalicious for use as the new post’s extended text. I think Gus and I will both be a bit curious to see if anyone figures out a clever way to take advantages of the new “tags” parameter.
You can get the update from the usual place. Enjoy!
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.)
When I interviewed for my current job, one of my interrogators asked me an interesting question: if Apple gave me carte blanche to pursue any project that interested me, what would I work on? My answer? Easy: social software for audio! No other project could combine my various passions (web services, audio and music, the iPod, social software, esoteric machine learning/psuedo-AI stuff) in such a complimentary way. I still find myself thinking quite often that if I was to leave Apple for anything it would be to start some sort of social music software company.
The question, though, is what should social software for music look like? I think my most important insight on the matter comes from an offhand remark someone (who I’m not sure if I should name) made to me about Odeo: that to really separate themselves from Apple and everyone else in the podcasting arena, Ev and company need to build “Flickr for audio.”
This struck me as a perceptive observation, because it squares very well with something I’ve long thought of as the first rule of social software: to really work, it must be a game. This idea was first suggested to me by Giant Ant Design’s seminal weblog post arguing that Flickr is actually a MMORPG, and I’ve noticed it holds true for all of the social software I really enjoy using. Even with the seemingly utilitarian del.icio.us, I have to admit to checking my bookmarks page once in awhile just to see how many people in my informal social bookmarking network have approved of the links I’ve posted by bookmarking them themselves.
Apple isn’t (at least that I know of) really aware of this principle yet, but the folks at Odeo do seem to understand it intuitively. I’ve already added my Odeo music podcast to the list of my social outputs I idly survey while I’m waiting for world builds at work. This also includes weblog stats, my del.icio.us page, Technorati ego searches, del.icio.us linkbacks to weblog posts, and my Flickr stream’s recent activity. Like all of those things, my Odeo podcast provides some basic ways (episode downloads, podcast subscribers, comments, Odeo rank) for me to “keep score” and know how I’m doing in the Odeo “game.”
As important as all of that is, though, I think the seed of the true killer social music app might lie in an interesting phenomenon I’ve noticed on del.icio.us–something I’ve dubbed “recombinant podcasts.”
You see, while the front end of my podcast is handled by Odeo, the back end RSS feed is actually generated by del.icio.us–that is, when I want to add something to my podcast, I just upload the file to my web server and bookmark it in my del.icio.us feed, which Odeo then picks up.
Since my entire podcast is also available via del.icio.us, and the underlying files on the server are available for anyone to link to, I’ve noticed that a number of del.icio.us users have actually added songs I’ve posted to their own del.icio.us bookmarks by using del.icio.us’ “copy” feature. The really interesting thing about this, though, is that several of them (including Dom, Odeo’s cracker jack new QA lead), have clearly added them to their own podcasts (as evidenced by the “dom.net:podcast” tag Dom added in this example).
This is notable because it reminds me of another thought I’ve had about how a social music application would differ from Flickr: with Flickr, you’re selling either your skills or experiences; with a social music app (such as my Odeo podcast), you’re selling your taste. It’s therefore very easy for me to imagine a social music sharing application built on Flickr-like MP3 streams, episodes of which could be copied from one stream to another (giving rise, naturally, to the power laws, A-lists, tastemakers, and so forth that make social applications such compelling games to so many people).
Of course, all of this is assuming someone could solve the copyright problems involved. A big “if,” to be sure, which is why you won’t see me quitting my day job just yet.