Sci-Fi Hi-Fi

I’ve kind of been asleep at the Cocoalicious wheel for awhile now, which is a shame because not only have there been some well known problems, I also left the CVS repository in a bad enough state to prevent anyone besides me from fixing said problems. What can I say: it’s summertime, and the living is easy.

Fortunately, I have finally managed to scrape together enough time to get the two biggest problems (a crasher, and a bug that would allow the post cache on disk to be overwritten by blank data in some conditions) fixed. Check out Cocoalicious 1.0b43 for the fixes.

In case anyone’s wondering, the crashing problem that I got so many complaints about had to do with URLs containing literal percent signs, such as the following:

http://www.urbandictionary.com/define.php?term=%s

Basically, the issue was that if you pass NSURL’s URLWithString: method a URL like that, it will simply return nil instead of a new NSURL, because it tries to interpret the “%s” as an escape code, and it’s not a valid escape code. I wasn’t checking for nil before I tried to insert the new URL into an NSArray, which is what would actually cause the crash. The solution would seem simple: just escape the percent sign before you turn the string into a URL object, so you end up with:

http://www.urbandictionary.com/define.php?term=%25s

And this does indeed work, until you submit the URL to del.icio.us and then re-download it. When you get this URL back in the del.icio.us post XML, what you end up with is:

http://www.urbandictionary.com/define.php?term=%2525s

In other words, del.icio.us escaped the percent sign again (”%25″ is the escape code for the percent sign), which means if you edit that post in Cocoalicious and re-submit it, you’ll end up with an incorrect URL.

I’m not sure whether I can consider this a bug or not (it seems to me that del.icio.us shouldn’t naively re-escape the percent signs at the beginning of valid escape sequences), but until I figure out what to do about it, this is going to be a known issue in Cocoalicious.

Lately a lot of people have been asking me questions about whether or not I’m going to be putting on a dinner or party in conjunction with WWDC. The answer is: yes, of course! The problem is, this year my plans for the shindig are a bit more ambitious, and I simply haven’t had a lot of time to investigate the logistics yet.

Because I have yet to finalize any of my grand plans, and I don’t want to disappoint people if they don’t work out, I’ve been intentionally tightlipped so far, but I do realize people want to make plans, so I’ll provide a few details now:

• This year I plan to transition completely away from a dinner held in a restaurant and toward a proper party in a dedicated venue. I do still hope to have some refreshments provided by a local San Francisco legend (more on this later if it actually works out).
• The party will be held, as always, on the first day of WWDC–which this year means August 7th.
• If everything works out as planned, this year’s will feature some additional attractions beyond the party itself.
• There’s a good chance that the venue will be 21+, which, sadly, means many students will be unable to attend. I’m going to try to work around this, but if not, my apologies to our undergrad friends.
• I eventually plan to gauge attendance by posting an event on Upcoming.org, but it would be interesting to see through the comments here what peoples’ reactions to the above are.

Thanks everyone for your patience as I figure this out, and I look forward to seeing you August 7th!

I’m off to Las Vegas tomorrow evening for the National Association of Broadcasters show. If you happen to be attending the show and feel like saying hello, I’ll be demoing Soundtrack Pro in the Apple booth Wednesday and Thursday afternoon. See you there!

Thanks to some gentle prodding from Ted Leung, I finally got around to producing a Cocoalicious Universal Binary release (b41) this week. This version also has support for del.icio.us’ long awaited private bookmarking feature (if you check the “private” box while posting, Cocoalicious marks the post in its own local cache as private and flags it as private when uploading to del.icio.us). Finally, I also incorporated the latest version of the Sparkle Software Update framework (which just keeps getting better and better, by the way). Enjoy!

It’s 2 AM, and I should be going to bed after a hard day’s night, but I just discovered something in NetNewsWire that I have to share (even though it’s probably old news by now): my friend Peter Ammon finally got to release his long-awaited hex editor for OS X, Hex Fiend.

Peter started working on Hex Fiend back when he and I worked together in OS X QA, and he approached the project of filling the OS X hex editor gap (a gap I definitely can vouch for, having worked extensively with frustrating hex editors to develop PodWorks) with the kind of megalomania readers of his weblog have come to expect. Not content to simply develop a nice tool for the job, Peter set about creating an editor that allows users to edit arbitrarily large files and do so using an NSTextView. An impressive feat by any standard.

Here’s hoping some of Peter’s work here eventually finds its way into the Cocoa text system!

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:

• I now have an automatic local backup of my del.icio.us bookmarks.
• I can actually access my bookmarks during del.icio.us’ occasional hiccups. Now, if you start Cocoalicious while del.icio.us is down (or your computer is off the network), it will fall back on its local post cache (and display “[Offline]” in the window title to let you know you’re actually looking at the cache).
• I no longer have to wait for Cocoalicious to download my entire post list unless there has actually been a change on the server side. Cocoalicious now stores its last refresh time locally and consults the del.icio.us API’s last modified time to make sure a refresh is actually needed.

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:

• Currently, if you do a post, it will cause the API’s last modified time to get updated, meaning that the next time you refresh or restart Cocoalicious, it will think it needs to do a full download (since the API’s last modified time is after the local last refresh time) even though that may not be necessary.
• You will only be able to log in in offline mode if you have the preferences set to automatically log in with a certain account. This sucks big time, but I’m going to need to overhaul the authentication code to fix it.
• If you try to post while del.icio.us is down, your post will get written to the local cache but not del.icio.us, meaning that the next time you do a refresh, it will disappear. I plan to eventually fix this by giving Cocoalicious the ability to queue posts for later submission to del.icio.us.
• I really should add a way to force a full download in case of weirdness (for example, I have occasionally seen the API last modified date be off in strange ways). Perhaps holding down shift while launching the app or refreshing?
• Syncing is currently quite dumb. In fact, what Cocoalicious does right now isn’t really syncing, since the del.icio.us API makes true syncing nearly impossibly to do. It can only tell you when a user’s bookmarks were last modified, not how (e.g. what was modified, what was added, what was deleted), so it’s essentially impossible to get away from always downloading the user’s entire collection of posts. Not sure I’m going to be able to solve that one without some help from the del.iciol.us side, although I’m open to creative suggestions.
• The local cache is in the form of an XML plist, which actually gets completely rewritten every time you post. Ideally, Cocoalicious would be able to simply insert new posts to the cache without rewriting the entire thing. Perhaps someday we’ll move to Core Data (or simply SQLite)…
• One of the obvious killer features of a local cache would be the ability to maintain private bookmarks. I’d eventually like to provide a facility for this in Cocoalicious, although this build doesn’t have it.

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!