The EFF is starting up a new patent-busting project aimed at VoloMedia’s podcasting patent. Even if you’re a fan of software patents, it’s obvious bad patents screw up the whole intellectual property system. So I thought I’d check out if VoloMedia’s patent is legit, or if those cypherpunks at the EFF are onto something. Turns out someone beat VoloMedia to the punch by at least half a year.

VoloMedia applied for their patent in November 2003 but wikipedia’s history of podcasting mentions quite a few pieces of podcasting prior art. But it’s not good enough to say podcasting existed before the patent, therefore the patent is invalid. The real task is to figure out which prior art knocks out which of VoloMedia’s claims, and see if there’s anything left standing. So what are the actual claims? In their patent submission they’re laying claim to software that can:

1. Subscribe to and automatically download from a feed of episodes
2. Indicate new episodes are in the feed
3. Sync the episodes to a portable device
4. Sync to the device based on settings
5. Sync to the device manually
6. Share the episodes over a local network
7. Limit automatic download based on feed priority
8. Sync less than all of the feed’s episodes to a portable device
9. Sync when the feed removes episodes

That describes every podcatcher available these days. But we’ve got to find out prior art published before the patent was submitted. So key is finding out what the state of podcasting was before November 19, 2003.

There are a whole bunch of standards docs (and conversations about them) from the people implementing this sort of tool. Searching around for the history of the RSS enclosure tag will find a bunch of people talking about downloading media through aggregators. But you don’t often get a big picture in these conversations, hardly anything focused on how the client actually goes about handling feeds.

But I did stumble accross Mark Pilgrim writing in February 2003 about some features in a brand new feed aggregator that sound a lot like the first claim in VoloMedia’s patent:

Ignoring for the moment all the things it doesn’t do yet (which all sound quite cool), it has one particularly disturbing feature: extracting full HTML content from linked RSS items. The feature is off by default, but once turned on (one checkbox during installation), every time it finds a new RSS item in your feed, it will automatically download the linked HTML page (as specified in the RSS item’s link element), along with all relevant stylesheets, Javascript files, and images.

But wait, there’s more! Deep in the comments, Kevin Burton mentions that one use case for sync is accessing that data on a PDA. Bam! Claim 3. In the same comment, he makes a big deal of the fact that this syncing only occurs based on user preferences, taking out claim 4. He later mentions the standard (and for patent purposes, obvious) way to indicate that a feed has been updated using ETags. Yes, that’s claim 2. And that second comment also mentions sharing NewsMonster downloads on the local network using the same protocol Apple uses in iTunes today, stardardized as ZeroConf. Claim 6, down.

Only syncing less than all the episodes so they fit on the device seems novel, if a bit obvious. The rest of the claims (manual sync, prioritized download, and syncing when a feed removes old content) were common in feed aggregators of the time. But considering NewsMonster’s coming soon features of the time, I’d bet that NewsMonster supported every single feature claimed by VoloMedia’s patent. I’d love to get my hands on an old beta 1 just to check.

For what it’s worth, podcasting is a terrificly successful and useful idea. It took plenty of great ideas to invent it and make it successful. And like it or not, those people who created it deserve the rights to those ideas. If Winer kept his RSS work to himself, it would still be as useful as it is today. But he gave it away and now everyone profits from his ideas.

The thing is, VoloMedia didn’t invent podcasting and they don’t deserve exclusive rights to it. So we’ve got to get rid of this patent, or we’re punishing all the podcasters, fans and real inventors that made podcasting awesome. If you’ve got any more information to help, get ahold of the EFF or let me know.

It must be very difficult to be a Daring Fireball. Not only must he suffer the indignity of being the world’s foremost Apple fanboy and a tragic follower of the Yankee franchise, recently he’s had to endure a little purple cowlick infringing on brilliant design.

So with a few minor changes to Mr. Knauss’s snarky swipe at our dear Yank, I’ve taken a comb to that little logo.

Damned Flickr

Damned Flickr is a userscript to make everything better. If clicking that link doesn’t just work, you’ll need to install a plugin for Firefox or Safari.

A coworker of mine wants to stub out our access to external services so our tests work faster and better. Trouble is, he seemed to be pointing at our end-to-end testing when he said he wanted to stub things. And that’s exactly where you should stub as little as possible.

But you ask, aren’t all the cool kids are using mocking frameworks? Yes, they are. And so should you. Especially in your unit tests. You should learn the difference between a stub and a mock. And you should remember that really complicated mock expectations mean you’re probably doing something wrong. And that the the harder it is to mock out side effect behavior, the harder it is to make concurrent and thread safe. But you should totally be using test doubles as much as you possibly can in your unit tests, and using the stupidest ones that could possibly work. If you’ve managed to build an app with good test coverage without test doubles, and didn’t suffer in the process, contact me immediately. I’ve got to see that in action.

But theres a maxim that you shouldn’t mock code you don’t own. Instead, it’s generally a good idea to stub out interfaces. And not just to externally developed services, but to externally developed libraries too. Totally makes unit testing more sane.

That’s because unit testing is about creating a suite of assertions that say “it’s not this part that’s broken”. If (and when) that test fails, you can be sure that something in the test is broken. But if that test does alot, then you haven’t got a clue which of the things the test does didn’t get done right. Which makes it about as useful as a bug report from my sister the graphic designer. Pleasant, better than nothing, but sightly twitch-inducing.

But you don’t want the external stuff doubled out in integration tests. Actually, I hate calling it integration testing. ‘Integration’ is what you do when you need to know the volume of a space. End-to-end testing has less sylables and actually means something. But I personally call it smoke testing as in home inspection. Because you really need to push stuff through every pipe to make sure it isn’t squirting out somewhere.

If you’re doing smoke testing, you shouldn’t be doubling out your services. And you really should be smoke testing. Cucumber makes this stuff dead simple. Especially compared to calling DOM events through the COM interface of Internet Explorer from inside an NUnit test. Cucumber tests are even obviously useful, unlike unit testing. They’re useful because they can check that your app actually does stuff. Just like you would do a million times if you didn’t know how to automate tests.

But back before you knew how to automate tests, didn’t you have the program set up to actually talk to everything it would actually talk to? So you’d know if someone updated the database, or reorganized the file system, or the network was down. At the end of the day, that stuff has to get delt with or the app won’t actually work. Which means it won’t make anyone happy. Which means you won’t get paid. Glum face.

So automating smoke tests means you know if you deserve to get paid. That makes it totally the most important testing you could do.

So why is my friend, who is no fool, trying to screw with the most important testing we have so that it wouldn’t actually tell us if we can get paid?

Because he isn’t, of course. He’s got a hankering for a different kind of test, sometimes called an acceptance test or an integration test or a functional test, depending on who you’re talking to today. I like calling them functional tests, but yeah, that’s at least as bad as ‘integration’. But the point of a functional test is to make sure that your code provides the functionality you expect. If the network is down, that’s not your code’s fault. Where unit tests exist to say, “it’s not this part that’s broken,” functional tests exits to say “it’s not my stuff that’s broken.”

Why would you need three different kinds of tests? If you’ve smoke tests to tell you if you can get paid, and unit tests to tell you if you’ve got bug regressions, what’s the point of functional tests? To winnow decision trees. When you get a bug report, the entire reproduction scenario is the functional test. The fencepost error that causes the scenario to fail is the unit test. As a developer with a good testing suite, functional tests can let you inject whatever you like into your app without having to fire up the debugger.

If your fuctional tests are working, then you know it’s not your problem. Well, it’s almost certainly your problem, but that problem is something more like sitting on the phone all day explaining the bug to your service provider’s tech support instead of twiddling with edge cases in the deepest recesses of your code.

So please, write smoke tests. Write other tests if it suits your fancy, and please write tests for any bugs you find to avoid regression. But don’t cripple your existing smoke tests in the name of TDD. Not unless you don’t care to get paid.

It seems Jonathan Palardy doesn’t like my old prev/next bookmarklets. He thinks I should actually include code that works, even if it means having people pull some javascript library from my site. So do I.

Trouble is, I don’t use those anymore. It’s a real hassle to negotiate Prototype to play nice with everyone else’s javascript, so I’ve moved onto a simpler approach. Like Mr. Palardy, I wanted something using something standard and with builtin support from modern browsers. But I thought I’d give CSS selectors a shot using the Selectors API, available in Firefox 3.1+, IE8, Safari 3.1+, and Opera 10.

What we want is very simple: elements with a rel value of prev or next. You find those easily with the CSS selectors [rel~=prev] or [rel~=next]. We need to get the link those elements are pointing to, so we just pull that from the href attribute. Finally, we tell the browser to update the document location with that URI. Like so:

location = document.querySelector('[rel~=prev]').getAttribute('href');

Of course, I took a second to wrap this stuff up as proper bookmarklets. Just drag these to your link bar: prev and next.