Stupidfool.org

So Much Drama in the last.fm

I don't know why, but I've gotten into the habit of obsessively checking my last.fm profile over the last couple of days. And the thing is, nothing actually ever happens on my profile. I have no neighbors; I have no groups; I have no tags; I have just one friend.

The only thing that changes is my list of recently played tracks, & there's really no logical reason why I should obsessively check which songs I last listened to when I, um, just listened to them. But there's some bizarre pleasure that I get when, after reloading my profile, I see the song that I'm listening to/just listened to at the top of the list. Web services are magical!

Today, last.fm & I had some drama, because I'd listened to 8 songs that hadn't yet appeared on my profile! I kept checking, & the songs didn't show up. And when they finally did show up (they were queued, I guess), I must say, I was pretty relieved. last.fm was my friend, again.

I guess the point being that I feel like there's a lot of richness to last.fm that I'm somehow missing.

Math Quiz!

Via Jason I read & took this math quiz, which is a sample of a math test for 8th graders from the Illinois State Board of Education [1].

I scored only 8 out of 10, because I forgot the formula for the length of the diagonal of a triangle, and two of the questions were dependent upon that knowledge.

Stupid triangles!

[1] Note the smooth transition from my previous post!

"All things go..."

Inspired by the iTunes library of my co-worker Krissy, I listened to and, this weekend, purchased, Sufjan Stevens's "Illinois" (or as the cover—and CDDB—would have you believe, "Come On Feel The Illinoise"). Which I, never having heard Sufjan Stevens before, find fantastic.

Musically it reminds me of a mix between Mercury Rev's "See You on the Other Side" (without all of the feedback) and the community theater productions in Waiting for Guffman. Which I mean as high praise indeed, as I really love the songs in Waiting for Guffman. And thinking about it, there's another similarity, in the sense that I can't possibly imagine that an album all about Illinois would be that good, just as I spent most of Waiting for Guffman dreading how awful the production would be. And yet, both are inexplicably much, much better, warmer, funnier, sweeter, etc than I could've imagined.

It's funny, because a couple of years ago I got it in my head that I wanted to make a giant mix CD of songs about all 50 states. Some of the states were really easy, of course—and John Linnell's "State Songs" could've provided fodder for a number of, frankly, the more difficult states.

Where the whole operation fell apart was in Vermont. I couldn't find any music about, or mentioning, or even vaguely implying, Vermont. I searched and finally found Willie Nelson's version of "Moonlight in Vermont." The song itself is awfully boring, but I figured, hey, it's Willie Nelson, so he'll make it interesting, right? So I listened to it, and halfway through listening I got discouraged, and pretty much gave up on the whole project. [1]

But anyway, in part because of my own half-finished experiment, I must applaud Sufjan Stevens for even undertaking such a project, and on a much bigger scope: an actual album for each of the 50 states, that he actually has to write, perform, etc. It's enough to make me tired, just thinking about it. But also kind of excited, just for the possibilities.

[1] Seriously: that song is fucking boring.

"It's a hot August night and my sister and I..."

Wow, "Seven Silver Curses," one of the new Fiery Furnaces songs (from their "let's record an album with our grandmother, and have her sing on it" album) sure is jarring. (Listen to it on Fluxblog)

But somehow, it's refreshingly jarring, if that's possible! I'd really like to play it just to annoy people, and yet I really actually love listening to it. There's just something very fun about it.

BTW, if you like the Fiery Furnaces (and I do!) they're playing at Cafe du Nord in San Francisco on September 30 and October 1.

In which I reveal my pathetic love for TV

I need a television recommendation service, or something. (And it shouldn't be TiVo, because its suggestions just are so not helpful.)

Or maybe there just needs to be more interesting stuff to watch on TV.

But please, people, I'm watching Octopussy right now! Octopussy! And I don't want to be watching Octopussy.

I watched some of Rock Star: INXS tonight, and that was pretty good for the little that I saw of it. I generally really like shows on Bravo, like Blow Out, Project Runway, etc. But there's nothing good on Bravo right now.

I want Survivor to start!

BTW, the cast mini-bios for this season's Survivor cast are fucking awesome. "Favorite Scent: Scent of a woman". Oh, come on! That's just ridiculous.

The Folly of the Ping

I have to admit: I really don't understand the pinging hysteria. Everyone wants to be pinged, and I really wonder if everyone thinks that's the best we (as an industry) can do.

Don't get me wrong--our tools have pinged weblogs.com and blo.gs for years. But of late, there are more and more parties interested in receiving direct pings, rather than federating based off of the updates that weblogs.com and blo.gs have always propagated. [1]

And frankly, it just makes it wonder: it's a bit ridiculous to suggest that direct pinging is the only possible technical way to find out about updates to a site. Google and other search engines seem to do pretty well in keeping their indexes current, even though they don't receive any pings. And they're indexing billions of web sites, while there are only tens of millions of weblogs.

So when our tools all ping weblogs.com and blo.gs, why is it so crazy to assume that an update on a TypePad weblog, for example, would propagate as a ping around all interested listeners within 5 minutes? Or even 5 hours?

I had high hopes for FeedMesh, because I believed that ping federation would solve at least some of the problems that we see. But alas, I don't really see that effort going anywhere. [2]

So we decided to do something about it. For services like TypePad and LiveJournal, the issue of authentication & spam pings is not as problematic--if you connect directly to us, we can provide a stream of updates to blogs on our services that listeners can watch.

And starting today, that's what we plan to do. Read Brad's post to find out the technical details, but basically, you'll be able to make an HTTP request to http://updates.sixapart.com/atom-stream.xml, and have Atom updates from LiveJournal and TypePad streamed directly to your client. [3]

And if you're interested in consuming the stream, take a look at Tatsuhiko's post about his new XML::Atom::Stream module, which provides an event-based wrapper around the stream and integrates easily with XML::Atom.

In order to solve the real issue of spam blogs--particularly the huge number that are being produced by the same weblogging tools that you or I use--I believe we'll need to think about reputation built upon identity systems like OpenID. But in the meantime, we're happy to provide a valid source of pings from millions of weblogs powered by our tools, and we'll see where it goes from here.

[1] Yes, obviously, those updates are not without issues. Weblogs.com pings often time out, and requesting their changes.xml may not be that much more reliable.

[2] I even developed a CPAN module for receiving FeedMesh pings, back before I knew it was FeedMesh. Which is why it's called POE::Component::BlogCloud instead of Poe::Component::FeedMesh. But of course, I don't actually know if that cloud really was the FeedMesh, which may be the least-documented protocol ever. Yes, I realize I'm not really making a good case for FeedMesh.

[3] TypePad updates will start to be added to the stream tomorrow.

I use "Loudsp." daily. Really.

I was just watching Cellular, and considering that they even make a sort-of-joke out of this:

Why is it so fucking difficult to mute a Nokia phone while on a call?

My First Plugin

Well, not really... but my first Movable Type plugin in a while.

I've been looking at the Movable Type 3.2 beta quite a bit from the outside in--i.e., by using the web application--but I wanted to explore the new options in the API. So (with Anil's prompting) I decided to write a plugin for 3.2 that would allow transferring posts--with all of their comments and TrackBacks--from one weblog to another.

There may be existing plugins that already enable this, but I wanted to take advantage of the new action pulldowns in the List Entries screens (both per-weblog and the global overview).

As an aside, what's amazing to me--and probably to everyone else who remembers the first release of Movable Type plugins--is how much plugin functionality has evolved over the years, and how well integrated into the UI plugins have become, particularly in 3.2. The first plugin-enabled release, Movable Type 2.2, allowed plugins to add new template tags, not touching the UI at all; Movable Type 2.6 allowed plugins to add new text formatting filters; Movable Type 3.0 and 3.1 allowed plugins to build applications that looked like Movable Type, but looking back, they always felt like separate applications.

With Movable Type 3.2, the plugin interfaces have evolved to the point where plugins are completely transparent: there doesn't have to be a difference in look-and-feel between plugins and core functionality. The two key areas of evolution are the listing screens and the plugin management and per-weblog configuration settings. This is great.

Getting back to my plugin, then, I used the new APIs for adding hooks to the listing screens to enable the following flow:

1. Go to List Entries (either in a specific weblog or in the System Overview).
2. Select the entries you'd like to transfer.
3. Select "Transfer Entries" from the "More actions..." pulldown menu.
4. Select the weblog to which you'd like to transfer the entries.
5. That's it!

If you have Movable Type 3.2 (you'll need a recent version of the beta), you can try out the plugin:

• Transfer 1.0
• The source code, if you just want to look at that

Update: a new ProNet post shows the plugin in action, along with describing the plugin functionality in more detail.

Open Data

Cory writes about the rumors of the new Intel Macs using Intel's Trusted Computing hardware:

It means that the price of being a Mac user will be eternal vigilance: you'll need to know that your apps not only write to exportable formats, but that they also allow those exported files to be read by competing apps.

Exactly. In some sense, open data is more important than open source. Your data is more valuable than the tools you use--you can always find new tools, but if you lose access to your data, no tool in the world will give you access to it.

It's similar to what we've always called our Philosophy of Yes at Six Apart:

The "export" button in Six Apart's products keeps us on our toes. Knowing that you can leave at any time is our motivator to keep on developing stable, intuitive and flexible applications. We want you to stay because you like the product, not because you can't get out.

For me, it's always been easier to trust a tool that allows me to get my data out if I watch to switch tools.

And so, since day one, Movable Type and TypePad have had the ability to Export your posts--not because we wanted people to leave, but because we wanted people to stay.

Design Patterns & Data::ObjectDriver

It's sad to see that the Class::DBI mailing list and wiki have closed down, for a number of reasons...

For one thing, I can feel for Tony--it's always hard to have a project that you're working on (out of your own time, for a job, or whatever) criticized, and to have customers--whether they're developers or end users--not happy with your decisions or the pace of your releases. That said, I don't know enough about the situation to say much more than it looks to have gotten out of control much more quickly than it should have.

But from another angle, the discussion about design patterns is really interesting to me (and, I gather, to a lot of people on the cdbi list).

It's a really fascinating problem, designing an extensible object-relational mapper (and a common one for people on CPAN). We've had a good, working mapper in Movable Type and TypePad since the first release of Movable Type (the venerable ObjectDriver code), which works with Berkeley DB, MySQL, PostgreSQL, SQLite, and a number of other databases that people have hacked it to work with.

Over the past couple of months, we've been revisiting our ObjectDriver code with the idea of keeping (mostly) the same calling structure, but adding layers for caching and database partitioning, and releasing the entire mess to CPAN as a module called Data::ObjectDriver. (Brad wrote about this, as well.)

The idea is to make application development simple; if that makes creation of new database-backed objects a little more difficult, then so be it. For example, with partitioning, we're not attempting to go the DB2 route of saying "anything can be partitioned in any which way, and we'll handle it all!"--frankly, while I honestly think that database partitioning is a feature any database platform should have, it's a hard problem, and is pretty application-specific. So what we're doing is preventing a mental model for doing partitioning: figure out what objects you want to use to partition your data on, and we'll do the mechanical work of automatically connecting to the right database and performing all operations there.

But the applicable part here is that we've talked a lot about getting the design pattern first for all of the drivers. In particular, we're converting TypePad to use the new Data::ObjectDriver, but we have a couple of extensions we want to make to it. We've talked through multiple inheritance, delegation, mixins, etc. Eventually we settled on using delegation, with a DBI-like system of a core Data::ObjectDriver::Driver::DBI class, which provides the main driver functionality, and Data::ObjectDriver::Driver::DBD subclasses for specific database platforms (MySQL, PostgreSQL, etc).

In addition, I've long thought that one of the main problems with Class::DBI is the fact that it's two things in one class: it's simultaneously the base class for all database-backed objects, and the class with all of the mechanical code to generate SQL statements.

Some of the design decisions that have always been in the ObjectDriver code--the separation of the core into a BaseObject and Drivers, which are 2 separate classes--will help to solve some of the Class::DBI problems. That's not to say that we won't replace those with other problems, of course. :)