Reboot 9.0 has been announced and is now in the planning phase. As usual, everyone is invited to participate in putting together two days of great talks and conversations.
This year it will be on the 31st of May and 1st of June, as usual in Kedelhallerne in Copenhagen.
See you there!
Sam Ruby: Of course, I would create the consolidated feed using Venus.
It’s really quite simple:
Through my use of Venus for e.g. Planet SF, I started using Bazaar, for which I created an Atom feed generator, the code for which is also stored in a Bazaar repository, which of course provides a feed and is being picked up by e.g. Sam, who in turn maintains another Bazaar repository that provides another feed, that gets picked up by my Venus installation, that then generates a global feed with all the changes — once.
Did I mention that I think Bazaar hits a sweet spot?
Inspired — again — by Sam Ruby, I have begun using Bazaar for source control. My first use case was creating a branch of Venus to implement a cache expunge mechanism. Also, I think Bazaar hits a sweet spot regarding ease of use for personal as well as distributed development, and once the prerequisites are in place, it’s easy to set up.
While doing that I learned some more about Python, and found out I wanted to be able to subscribe to the changes in a Bazaar branch.
Starting out with Sam’s tarify.cgi and Joe Gregorio’s sparklines as working examples I have managed to create a simple Python-script for generating an Atom feed: bzr-feed. You can of course subscribe to the changes!
On the TODO is creating RDF output with DOAP, but I think I might need to figure out a way to store and report more information than is currently available in the Bazaar repository.
To use bzr-feed, you will need something like the following in the .htaccess file in the directory containing the branches:
<FilesMatch ".*\\.cgi">
Options ExecCGI
AddHandler cgi-script .cgi
</FilesMatch>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule (.*).atom$ bzr-feed.cgi?dir=$1
As a bonus, while working on bzr-feed, I realized that Apache apparently supports If-Modified-Since out of the box for CGI scripts as long as the Last-Modified header is sent (though ETag support still needs to be implemented separately). Nice.
They may look cool on the surface, the URIs at Digg, but underneath the surface they are quite a lot more unfriendly. Not that this is really a surprise though, Digg doesn’t exactly shine when it comes to being web-friendly.
Exhibit A:
http://digg.com/tech_news/New_Interview_with_Kati_Kim_describes_harrowing_week_lost_in_woods
Earlier today, that new URI showed up in my aggregator. I opened the link in another tab of my browser, and was soon greeted by a rather disappointing message, including the word “Oops” and words to the effect of it being a symptom of a missing page.
Searching Digg for the story in general terms brought up the usual Digg dupes, but also what appeared to be the story I has been looking for, only with a different URI.
Exhibit B:
http://digg.com/world_news/New_Interview_with_Kati_Kim_describes_harrowing_week_lost_in_woods
Compare this with exhibit A, and you’ll find that the post title hasn’t changed, but what has changed is apparently the categorization of the post — instead of being filed under “Tech News”, it’s now filed under “World News”. That little change makes a big difference. While the change of category assignment doesn’t itself offer problems, it evens seems reasonable, the change of URI certainly does. It is obviously the same resource, so to change its identifier is a no-go.
But wait. It gets worse.
Exhibit C:
You’d think they would at least then redirect from the “old” URI to the new, making this entire post moot, and offering a pleasant user experience, but no. Instead we were shown a generic error page, offering no assistance in finding what we were looking for. At the very least they could have included a link that would make it easier to find the story in question.
But wait. There’s more…
Exhibit D:
http://digg.com/error
That’s the URI we end up with, showing the message in exhibit C, when following the link in exhibit A — a URI that may look cool, but really isn’t.
Usually, when you follow a link that is invalid for some reason, you get to keep the URI of what you were looking for in the address bar. As in this case, when you are presented with a less than helpful error message, you really could have used the URI for just a hint of what to do next.
But wait. It gets even worse.
I saw the original URI in my aggregator, because a lot of people had dugg the story. Some have likely submitted the URI to their blogs as well, making the URI quite widespread, not only directly via Digg’s RSS feed, as in my case. This means that robots will go look for the resource as well, and they will of course get presented with yet another view.
Exhibit E:
$ HEAD -S http://digg.com/tech_news/New_Interview_with_Kati_Kim_describes_harrowing_week_lost_in_woods HEAD http://digg.com/tech_news/New_Interview_with_Kati_Kim_describes_harrowing_week_lost_in_woods --> 302 Found HEAD http://digg.com/error --> 200 OK
Not a 302 to the new URI, not a 404 indicating that it was missing for some reason, not a 410 telling it was gone, but a 200 OK — an error page…
Sigh.
It’s a good thing Digg doesn’t offer tagging, or their URIs would be changing by the minute, exploding the number of published URIs and disrupting the space-time continuum…
Nothing has ever been said just once. (By the way, there are no google hits on that phrase.)
The above quote was dug up while trying to find the origin of another quote:
On the web, everyone is famous to 15 people.
Apparently, noone knows exactly who said that one first:
Appropriately enough, many people share authorship of that one.
— Andy Was Right, TIME (from the future!)