2008-03-04 : Feeding The Daemons

For over a year, the home page of husk.org has been a collection of content elsewhere. The reason's pretty simple; I don't write long form posts often enough for a standard blog to work as a front page, but I didn't like the static nature of a plain index either. Keeping things updated with links and photos as well seemed like a plan. (Nowadays, you can do this sort of thing within Movable Type itself, but a year ago, you couldn't. Also, I'm rubbish at getting around to upgrades anyway.)

The code that generates the front page is pretty simple, really; it fetches four RSS feeds, does a bit of data munging to group them by day then source, with a bit of caching around the edges. However, despite relying on RSS for the content, there wasn't a syndication feed of the aggregated material. Now there is, and, perhaps sensibly, it uses the same Perl library (XML::Feed) to generate as it uses to consume the feeds elsewhere. (There's actually another post in the technical problems there, if I find time.)

So, if you're following this blog via a feed, why not switch to one of the aggregated ones instead? There'll be more content (as they pull in my more-regularly-updated Vox blog, as well as other stuff), and you might even find it interesting.

There's actually a choice of four feeds; one that shows everything, two that show text (one for long form writing, like this post, only; the other, posts and links combined) and finally one for images, which, right now, is just my Flickr photos, but that might change. If I do add feeds, there'll be a post about how to exclude things. (It's already there in the code.)

Speaking of excluding things, I've started using a feed reader again, a little. This time, I'm not using it for news (I know to check that), or sites that have aggregation (like Twitter, del.icio.us, Flickr, or LiveJournal), but for those one-off blogs you don't check otherwise. Unfortunately, there are a few people I'd subscribe to, but they insist on posting either their del.icio.us links, twitters, or both, to their feed. I can understand why - hell, I bring in links - but I also offer a feed without, and that's what I'd really want from them, too.

It might just be me (after all, I already see things via the sites mentioned above), but I've also started seeing grumblings about this from other people. With the launch of friendfeed and other lifestreaming/aggregation services, for example, people are flagging "duplication, or the infinite echo problem" as an emerging problem. Meanwhile, others are finding that infrequent blogging suits them fine. The comments note that an RSS feed lets you subscribe to someone who posts interesting stuff, but rarely; I'd argue that bringing in links to pad your content might actually drive people to leave again.

Just to make this a constructive criticism, here's how I'd work around this if I was using a blogging engine alone. All my long-form posts would get a category or tag (say "longform") and, as well as an overall RSS feed, I'd advertise a feed for original posts only. The bottom line? Aggregation's good, but let your consumers choose what they want to subscribe to.

posted by paul mison at 23:37	|	meta [on blogging]
[ 2 ] comment	|

2007-08-24 : Search Shared iTunes Libraries

A couple of days ago, Chris Heathcote asked "has anyone developed something to search over all networked itunes libraries?" I had a quick think and realised that it was somewhat possible using AppleScript. (Once, I would have recommended a solution using the underlying sharing protocol, DAAP, like my old freshtunes.pl script, but the still-unbroken encryption added in iTunes 7 means that's no longer possible.) It only took about twenty minutes for me to put together a quick and dirty proof of concept yesterday.

However, there's a problem. The iTunes scripting interface only allows searching through already connected iTunes libraries, so you'd have to connect to all of them manually. This is tedious, especially in a campus or company where Macs are widespread. Apple provide the workaround, though: GUI Scripting using Scripting Events. You need to enable "access for assistive devices", and working out the object heirarchies can be very painful (although Prefab's UI Browser makes it a lot easier). So another half an hour or so of poking had a script that will automatically connect to all the libraries, wait half a minute for them to connect, and then search them. So, in case it's useful to anyone, here's the code:

Connect To and Search iTunes Shared Libraries.scpt

Here's the instructions and caveats bit. Copy and paste the above script into a new Script Editor window, save it (to make sure it compiles- watch out for the "not equals" symbol towards the end) and then run it, changing "Orbital" to the name of the band you want to search for. You might find it useful to split it into two scripts, one for connecting to libraries and another for searching.

There are two problems I can think of. Firstly, I don't know how the connection part of the script copes with password-protected shares (or shares that disallow connections because they're too popular), but I suspect it might produce some dialogs that aren't handled well. Secondly, the script uses the visible name for the "Shared" divider in the iTunes source list to choose which libraries to connect to, but this may be different if you're not using iTunes in English, so you might have to edit that part of the script.

Nonetheless, despite the rough edges, I'm fairly sure this will be useful, either as it is for experienced users, or as an starting point for developers. I hope it's useful to you.

posted by paul mison at 15:12	|	computing
[ 2 ] comment	|

2007-07-23 : Remote Playlists with iTunes

A few weeks into my time with a MacBook Pro, I finally opened up Front Row, Apple's "ten foot" interface for media viewing. Being mildly obsessed with iTunes library sharing, I thought I'd see if it was possible to connect these days (when I tried with Front Row 1.0, way back when, it wasn't). I was surprised to see, upon swapping back to the normal UI, that not only had it worked, but that there was a playlist connected to my remote library.

iTunes, you see, only supports the creation of playlists for your primary (local) library. (There's a bit of half-hearted support for playlists of iTunes Store previews, but let's ignore that.) Everyone says creating playlists from shared libraries is impossible. So how was Front Row managing to create this playlist? I suspected AppleEvents (the infrastructure underlying AppleScript), and a bit of command-line fu from Tom Insam proved that not only was it right, but that it was possible to replicate the effect.

It turns out that the process is pretty straightforward. Front Row selects the tracks that you're viewing, sets up an XML file in a temporary directory referencing the tracks, and then tells iTunes to add that file as a playlist to the shared library.

Unfortunately, there were a couple of setbacks that stopped me releasing a version sooner. Firstly, the XML file requires persistent IDs, but these are returned by iTunes as a double, but AppleScript itself couldn't handle the resulting data; it was too long. However, it's not a problem with the underlying infrastructure, so I moved to Ruby and rb-appscript. Once again, though, I was foiled; I had no joy getting the portion of the script that adds the playlist to work, even with some convoluted workarounds.

After all that, I ended up leaving the script for a couple of months, always intending to return to it. When I did, I found that the persistent ID property has changed; since iTunes 7.2 it returns a string, not a double. This let me return to AppleScript, where I had working code for adding the playlist, and the result is a working application (well, script) to Add Remote Playlist.

It's easy to use the application. You can either run it from the desktop or put it in your iTunes Scripts folder (in the iTunes folder in your Library; you can open it with the Script Menu, if iTunes is frontmost). Once run, if you have a selection of shared tracks, a remote playlist will be created (called, imaginatively, Remote Playlist). You can rename the playlist, and create as many as you like by re-running the script.

There are a number of limitations. You can't reorder the tracks, and they're added in the order they're shown, not the order you select them. The remote playlist only persists as long as the library is connected, too. However, hopefully this is still useful - and it's certainly better than the nothing there was before. Although I'm distributing this as an application (oddly, it's saved as a PowerPC native binary), you can look at the source by dragging it to Script Editor. Enjoy.

posted by paul mison at 23:08	|	computing
[ 0 ] comment	|

2007-03-23 : Blue Coconut, iTunes 7, and You

This is a post that I've found incredibly hard to bring myself to write, but a few events have combined to prompt me to finally get this entry out.

Firstly, Blue Coconut still doesn't work on Intel Macs, and I still don't have a machine to force me to make it work. That's going to happen next week though, all being well.

Secondly, there's the issue of iTunes Library Sharing encryption. iTunes 7 changed things. It introduced a scheme that broke Blue Coconut (annoyingly, in a manner that it doesn't report well), along with every other client and library that talks DAAP. Initially I hoped that, as with the 4.5 change back in 2004, a patch would emerge quickly, but it's now clear that that's not going to happen.

However, I recently came across the Save OurTunes site, which is aiming to get donations to revive the Java-based downloading tool. Since it's GPL, Blue Coconut will also benefit if the encryption is broken by this project. Therefore, the best thing you can do to help get my application to work with iTunes 7 is to support them.

Thirdly, I realised that I could cut through the issues with both encryption and the Intel build by removing authentication from Blue Coconut entirely, as an interim measure. This would mean that it wouldn't any longer work with any version of iTunes (except 4.0 and 4.1), but it would be able to use the open source reimplementations of DAAP, of which there are many. Not coincidentally, this is my use case, and as people have said recently, build something you need.

So, no promises, but with luck the next month or so should see at least a sprucing up of the app's site and also, maybe, a release. In the meantime, I can only apologise for the lack of support for what is still evidently a somewhat popular application.

posted by paul mison at 13:45	|	computing
[ 2 ] comment	|

2006-09-03 : iTunes Music Store Survey

Almost a month ago, now, I recieved an email from Apple asking if I'd like to take part in a survey about the iTunes Music Store. Now, I hardly use the thing, so I assume this was down to luck rather than anything else, but I suddenly realised at the end that maybe other people would be interested. Thankfully, there was no anti-back-button detection, so I was able to capture a few of the, to me, more interesting screens.

more...

posted by paul mison at 18:54	|	computing
[ 0 ] comment	|

chaff archives by date by category
rss 0.91 1.0 short 1.0 full