I think that Guster might be my new favorite band of the moment. Thanks Ananda and Akilla.

It’s amazing how little changes between the time you go to bed and the time you get up when you go to bed at 3 and get up at 8.

I woke up to a Guster track that Robyn sent me. It’s on my top ten favorite songs list, for sure. When nobody’s looking, I dance to it.

My cat is a pain in the ass. He got his dinner last night, but I think he’s being preemptive about making sure he gets fed, and we have no food for him until I go to the pet food store. A few minutes ago, he jumped up and hung on my back. Now he’s in my lap, kneading my thighs with more claw than is really neccesary. All the while, he acts so cute you could hardly tell him to get lost.

http://www.livejournal.com/community/transnews/481667.html: My day just got much better,

I completed 1/4 of what’s needed to get rid of LDAP in my infrastructure for The Internet Company, and replace it with PostgreSQL.

Complete: Replication with Slony-1

Remaining: Convert DNS and users to SQL. Enable nss_pgsql. Write web interface for DNS in particular.

In the future: Integrate the user management with the billing management.

Too much time spent on interfaces makes too many special parts, and too much assembly required.

Too much time focusing on the whole with no thought of re-use makes a hard to maintain solid whole.

Too much time spent writing tests makes code that fails where the tests don’t cover

Too much time spent writing untested code makes code that fails where the tests should be.

Too much time focusing on the right way to make something Object-Oriented or Functional makes one forget the user interface, or worse, the user.

Too much time finding patterns means code that isn’t gets neglected.

Too much time just coding means ignoring the obvious patterns you repeat.

The theory is that one shouldn’t be able to tell what parts of a site are dynamically generated and which parts are static, except that the dynamic parts are dynamic. The W3 Style Guide makes some specific reccomendations. Dates as heirarchy make sense, because they won’t conflict over time, so you can keep the same URL valid forever, without namespace collision with future content. URLs specific to a certain set of server software should be avoided: no cgi-bin, no .cgi, and if your resource could theoretically be served up in a new content type in the future, no file extensions. It may be .html now, but maybe next year .xml will be in vogue, and ten years from now, .xht7 files will be the rage. If you leave it off and let MIME types do the describing.

For a web app framework, this means that whether or not to dynamically generate a page can’t be drawn from the URL in the general case. Should /products/foospray be static or dynamic? It should probably be static, updated when product information changes. Perhaps the output code would filter the page to include information about a user’s shopping cart, but hopefully that could be handled client-side, so that every user accessing the same URL at a similar time sees the same page.

One could probably conclude that locating a web app at a particular URL (or collection of URL space) is not the best option for flexibility. One needs a level of indirection for large sites, so that dynamic requests get handled by the right handlers, and static pages are served as fast as the machine can do it.

In an apache-like web server, I’d like apps to be able to be named independently of their URL, so that something like mod_rewrite can direct requests to the right app. I can imagine this registration resembling registering a remote procedure — after all, most web app frameworks have an entry point that looks remarkably like handle_request(request_object).

Perhaps it would look like this: RegisterApplication shoppingcart /usr/bin/carthandler Route "/products/([0-9a-z]+)(.*)" shoppingcart product=$1 info=$2 URLFor product,info "/products/#{product}#{info}" It’s a little ugly, but I think it would work really well. The URL parsing is handled by the web server, where I think it belongs, but enough context about the request is passed on to the web app that it can make self-referential URLs without too much problem. How the arguments are passed to an application process is grounds for another rant, not this one which is more concerned with routing and URL spaces.

The neat thing about that is that one can re-arrange the URLs in the web server, and assign them a semantic meaning there. If one wanted to develop a standard for configuring these things in a webserver-independent way, that would be nice, but hardly neccesary if the app had enough information to just do the Right Thing.

I think a limitation of having user-exposed keys like URLs is that they are subject to configuration, not just being simple opaque identifiers. It’s not as simple as an auto-numbered field in a database. URLs have to be designed, not just created. Most non-trivial systems are going to have to have some configuration of their URL spaces, because auto-generation just isn’t going to get it right.

In the example above, the instructions for building a URL from a keyed set of information is provided in the configuration. This can be passed on to the app, so that it can generate URLs refering to itself and to others, without major hassle and with a central, well-defined place of control. No need to repeat yourself all over the code, or make undue assumptions (like that /appname/thiing1/thing2 is magically going to be self-referential.)

I remember why I don’t eat Bear Mush (cream of wheat or whatever).

It’s because I cannot focus at all afterward.

I’m annoyed that I haven’t had a dream that I can remember in probably a year. I don’t think I’ve had more than a handful since moving out of Colorado. I think that’s sad, even if my waking hours are dreamy.

I just watched Waking Life. Darn good film.

Dirty Pretty Things is amazingly good. It’s also dark, disturbing, and occasionally hard to watch.

It put me in a weird mood all night. I really liked it, but it’s Björkishly dark and scary.

I got Ruby on Rails working last night. It’s not that friendly to RPM, so it took some heavy patching to get it installed, but it works now. It’s pretty amazing, even if it doesn’t embody some of what I consider best form in Ruby.

Finishing my database project has given me the free time and impetus to start working on my business again. I’m glad to be doing it, and I’m starting to build a todo list a mile long.

I just came out to someone unintentionally. Oops.

Three things I wish had been implemented in CSS much earlier if at all:

1. An `underline-style` property.
2. `position: fixed;`
3. XPath selectors
4. And not technically CSS, but the `<object>` tag, and CSS support for it.

I woke up feeling lost and abandoned for no reason at all. Then I realized I was feeling ill, and that’s now the most pressing thing on my mind. Bah.