Homemade Studded Tires

I bike everywhere I go. I’ve got a Peugeot that’s older than me that I’ve converted to a fixed-gear. Great in the summer, but after November it gets a bit more complicated.

Everybody at work is impressed that I’m still commuting without a motor. It’s not easy; this picture describes biking in Edmonton pretty well:

The weather hates you, the city hates you, and (most importantly) drivers hate you. Good times!

Snowfall and shitty roads complicate things. The roads are very slippery, I broke my left pedal by falling (unfortunately you can’t see how cool the crystals in the metal look):

The Edmonton Bicycle Commuters have instructions for making studded tires from knobby tires and metal screws. I picked up a(n outrageously expensive) tire at United Cycle, punctured some holes in it with an awl, stuck some screws through it and ended up with this:

Stuck an old tube between the tube and the tire to prevent too much rubbing. Much less slippy, and enough to get me to work without crippling injuries.

I’ve only done my front tire. My back tire skids all over the place and my knuckles are white but I manage to stay upright. I’ve earned the right to laugh at cars spinning out at intersections. Learn to drive!

Bikes: good transportation or best transportation? Discuss.

Boredom + data analysis

I wanted to do something creative today, so I scraped IMDB and wrote a program to do some basic analysis of the actors in the top 250 movies. (You won’t see the cool graphs unless you’re using a cool browser.) Nothing too interesting turns up. More recent movies are more popular than older ones. There’s an odd peak in the histogram of popular movies that occurs around 1957. The top actors are all men, to a rather shocking extent.

(Note that the data is not live, and probably won’t be updated after this is posted on 2009-11-08.)

Other things I did today: made some spicy fried tofu, watched freaky movies (1, 2, 3, 4) and read several months of I Blame the Patriarchy. A good day (except that tomorrow is Monday, and that the hair salon was closed).

Anil Dash on bigotry in open source

You have every right to say or do whatever you want. And you’re right — political correctness is totally stifling those who want to use racist epithets against minorities or who want to use sexist presentations to make a technical point. Here’s what I recommend: Get louder and more intrusive with your non-political-correctness. In fact, make the use of sexist and offensive commentary an even more intrinsic part of the fabric of the technologies you create. Regale complete strangers with the fact that you can’t distinguish between “pictures of naked women” and “an atmosphere that’s hostile to participation”.

Because if you aren’t willing to concede that technology is better when it’s inclusive, or you’re not willing to read the most thoughtful and heartfelt discussions of what it takes to be inclusive, and if you’re determined to respond to anything that offends your position of privilege, then maybe the best thing you can do is to make explicitly clear that the technology you create has the same insular, exclusionary values that you do.

Source.

I’ve always assumed that the Free/open source community is pretty inclusive, but investigation into the proportions of women involved suggests otherwise. I wonder what they look like for other minority groups :(.

This is why I hate computer people

This message was posted to nepomuk-kde@semanticdesktop.org (a mailing list about a piece of software that I’m interested in) today:

Date: Sun, 23 Aug 2009 13:23:50 -0400

From: Alan Grimes agrimes@xxxxxxxxx.net

Subject: [nepomuk-kde] OUTRAGEOUS!!!! =|

I’ve decided to begin and end my brief tenure on this mailing list with a flame addressed to all of you fags who decided to fuck up KDE by ramming your gay little buzzwords into the very core of what I rely upon daily to get my work done.

[…]

If this were just a research project, It would be impossible for me to complain. Truly, one of the most manly things one can do with a computer is try to invent new ways of doing things. […] You cross the line when you adulterate the kernel of the KDE project with useless, unproven, example of computational faggotry.

[…]

Why in god’s name would I want a “social desktop” when my fucking computer contains more personal information about me than my own brain?? That’s insane!!! I mean I am seriously considering trying to find alternatives for all of the kde applications I use all day long just so that I won’t be living under the threat that the “social desktop” will be sharing my password files (or even more damning information!) to anyone and everyone. This may be paranoia but what evidence do I have? I have a bunch of buzzwords talking about how wonderful it is to share information with co-workers when I have no friends and work alone! =(

[…]

What’s more, I’ve never once encountered a hetereosexual who was even half so enthuseastic about pressing forward with these buzzwords as the kool-aid drinkers on this site. I wish the homosexuals could find a way to satisfy themselves in their bedrooms (or in each other’s bedrooms, I really couldn’t care less.) and not spread it out like an ooze across the whole of the world. =\

[T]hings I desperately need are being neglected in favor of things that I don’t even want, and that’s an outrage! =(

The confusion of the technical (I don’t agree with/understand/like your technical decisions) with the personal (you monster, how dare you do things that way!).

The inexplicable combination of egomania (if I don’t understand it it must be pointless) and self-pity (announcing to a bunch of total strangers that you have no friends).

The complete lack of perspective, the ridiculous paranoia, and the insistence that people work on the things that are important to him.

The way he’s applying his homophobia is a bit baffling to me, but the homophobia itself is not particularly surprising.

He’s even managed to mix in a bit of sexism (research is “manly”).

This kind of shit is far too common amongst people who are interested in computers, engineering, etc. I need new hobbies (and maybe a new career).

Introducing sloth-log

I’ve thrown away the second revision of the system that runs this journal. Its replacement is much simpler; I’ve gone from about 1300 lines of Ruby and 1000 lines of XSLT to 252 lines of Ruby and 194 lines of XSLT. It does a lot less - no AtomPub, no live XPath searches - but I doubt anybody will notice.

The idea is to store everything in git. When I’m ready to publish new entries or updates I can git push to a special repository. The repository has a post-update hook that transforms the entries into Atom, then runs the Atom through XSLT to create the final static XHTML and HTML files.

It was a bit of a pain to get set up; git push is a bit of a black art, and lighttpd doesn’t support content negotiation on its own. It seems to be holding together ok, though. Hopefully this new simplicity will encourage me to write more. If you’re intrigued, you can get your own sloth-log clone.

This entry also marks a total migration to my new server. May it never be forced to limp like its predecessor.

Why It's Worth Fixing HTTP Authentication (and How to Do It)

What's Wrong With It

HTTP authentication (which I'll refer to as "httpauth") is useful when you want to quickly control access to something; you only need a few lines in your web server's configuration file to get it set up.

Unfortunately it's not good for much more than that, due to the terrible interface that every browser I've ever used has somehow settled upon. This interface presents three major problems:

First, most sites want to give the user the option to log in even if the page they're looking at does not strictly require it. Httpauth supports this, but browsers don't.

Worse, browsers throw up an authentication dialog as soon as they encounter a 401 Unauthorized response, without any context. If the user does not have an account, or has forgotten their password, their only option is to "Cancel" the dialog (to which the site's response is usually a frightening, uncustomized Unauthorized page).

Finally, once the user is logged in there's no obvious way to log out. Closing your browser will generally log you out, but this is hardly obvious.* This is easy to implement on the browser side - simply stop sending authentication data to a site after the button is pressed.

(I'm not the first to observe these problems (1, 2, 3). Bookmooch seems to have worked around them, but it's still far from perfect despite their efforts.)

Why It's Worth Fixing

But why bother? These days we use HTML forms and cookies for authentication on anything that matters, and it seems to work. Isn't httpauth an outdated technique, incapable of providing the rich authentication experience that today's users demand?

Well, no. Httpauth is perfectly capable; in fact it is preferable to cookie-based authentication in several ways:

  • it can be more secure than HTML forms when SSL is not available. Digest authentication only sends hashed passwords. Servers can trade system resources for immunity to replay and session hijacking attacks (see section 4.5 of RFC2617).
  • it can be completely stateless; multiple servers running the same site don't need to share a session store when Basic authentication is used.
  • it simplifies caching. Responses to unauthenticated requests are cached normally, responses to authenticated requests go uncached.
  • it works well with AJAX and with automated clients. Do you really need separate authentication mechanisms for your front-end and for your API?

As a bit of a purist, I think the best part is that your authentication layer can be completely separated from the rest of your application. You shouldn't need to clutter your interface or your code with authentication trivia. It's a classic example of code reuse; we're extracting an incredibly common pattern and moving it so that we don't need to recreate it every time we use it.

But there's not much point if we have to confuse and scare users to get these things. What to do about that?

How to Fix It

The slide-in toolbar (apparently called an infobar) that browsers have adopted provides a solution. I've made some mockups of what it could look like (please excuse the programmer art).

The browser would notify the user that they can log in without interrupting their browsing:

The bar sits there quietly waiting for them to log in. If the user requests something private, then the server sends back a 401 Unauthorized. This would need to be something friendly that allows the user to create an account, reset a password, etc.

When the user is logged in they would see something like this:

I'm sure these can be improved upon. Some kind of immediate user feedback is still required for requests that happen in the background (i.e. AJAX). Browser real estate is precious and I wouldn't want to look at that on every site that I'm ever logged into.

Conclusions

Writing the authentication infrastructure for a web application is not difficult, but it's still more work than letting some standard component do the work. The unhelpful UI the standard component has been given is the only reason we can't do that now.

My proposal is very similar to at least one that has been suggested on Bugzilla; the long time that one has been ignored is not promising. I've looked into implementing this myself, but - to be frank - Mozilla's codebase terrifies me (please contact me if you have any guidance).

Coordinating big chunks of code is tricky. Coordinating big groups of people working on big chunks of code is trickier, but if we can't get something as obviously broken as this fixed, then I fear for the future of the web.


*: Some (most? all?) browsers forget credentials for a site if the site sends them a 401 Unauthorized. Websites could provide a "log out" link that always 401s, but this is awkward.

After watching some Skinny Puppy videos that used VHS artifacts to great effect I wondered how long it would be until we saw digital compression artifacts used similarly; I guess that time has arrived.

I must admit that I expected it to be used spookily, in the same way that (to coin a term) VHSpunk was. Cool effect, though.

A David Duke article posted to the openmoko-announce mailing list? I hope sean@openmoko.com has some bizarre virus.

Update: It was spam with a forged From address. Email is a broken, broken set of technical and social protocols.

Document == Interface?

Ran across a link to Last Week in HTML5 and spent the rest of the day catching up with the drama surrounding HTML5. I sympathise deeply with Mr last week.

Giovanni Campagna has summed up something I've been thinking for a while:

Actually the web, is already divided in two big groups:

  • Web of data
  • Web of interaction

Web of data means all the page whose primary objective is to provide some information, either user-readable or machine-readable to the users, while web of interaction include web application, whose primary purpose is to provide additional services to the users. These two groups have very different requirements (GMail doesn't need RDFa in application code, while Wikipedia doesn't need a progress element), so specific markup languages may suit better the web site.

It's very strange to try to write application interfaces and documents in the same language. Too bad XHTML2 was strangled in infancy.

It seems that Ruby is getting a reputation for having an argumentative community.

It's sad, the lack of standard Internet nastiness is exactly what attracted me to the language in the first place. Unfortunately Rails culture is not Ruby culture, and Rails still gets all the attention.

We need more _why and less Zed.

← older entriesnewer entries →