Entries classified under weblog created during Apr 2005

Mr. McGrath is looking for a few good docheads (oxymoron, <ducks>) for an upcoming project. Experience in working with massive amounts of content a must, yadda yadda yadda.. But here's why I love Sean: he doesn't hire people (yes, docheads are people too) without the following qualification:

If you cannot think of 3 good reasons why dynamically typed programming languages have a role to play in this universe, you don't want the job.

There's been a lot of good discussion around Udell's End HTTP abuse article. We need to get this figured out because it's almost embarrassing to be an advocate of standard approaches to building web applications when something as fundamental as the correct use of HTTP GET is butchered so often. Unfortunately, misuse of HTTP GET is just the tip of the iceberg. There's a whole slew of HTTP abuse going on out there (often in the form of neglect) that can be laid at the footstep of two parties: frameworks and evangelists. The frameworks suck and the evangelists aren't trying hard enough (I consider myself in both camps, btw).

The small community that is coalescing around REST/HTTP should prioritize the following objectives above anything else at this point:

1. Raise awareness of what HTTP is capable of.
2. Fix the tools.

HTTP Kicks Ass

We need to raise awareness of what HTTP is really about. If you're reading and understanding this, then you've likely had the Ah-ha moment based on the realization that HTTP isn't just a beat up old protocol for transferring files from a web server to browsers (if you haven't, read this); but this understanding is not common. The large majority of smart technical people believe that HTTP is legacy technology: an old protocol, maybe a step above gopher, that has somehow hung around through the years. Something to be dealt with, not taken advantage of. We need to show how limiting this mind-set is.

Many of us were first introduced to the true capabilities of HTTP via the REST architectural style. If you were like me, Mark or Paul (or both at the same time) forcefully induced the REST epiphany on you against your will and then you went and re-read RFC 2616 while slapping yourself on the forehead repeatedly. The correlation between the architectural concepts described in Roy's thesis and the implementation semantics described in the RFC were clear as a bell. HTTP was no longer a simple mechanism for exposing a directory of files and executable processes to a browser, it was the essence of web architecture.

Here's the thing though: most people don't read RFC's! They hate RFCs. Reading RFCs ranks close to doing taxes for most people. The only thing worse than reading RFCs is reading PhD thesis'.

The evangelist needs to reach these people somehow and I really don't think it's going to be through describing the architectural concepts of REST so much as it will be through describing the here's-what-you-can-do-right-now-in-the-real-world benefits of HTTP. It's a fine line, I know, but I think it's important.

How do we give people the Ah-ha! without requiring that they read a thesis and an RFC?

A Three Legged Dog

I look at what Zeldman, Meyer, and others are accomplishing with the Designing with Web Standards movement and it seems a good model. They emphasis the correct use of standard CSS, (X)HTML, and DOM scripting (the three legged stool) to achieve enormous benefits over proprietary web design techniques. They have books and a cluster of weblogs that show designers how to reap the rewards of this system. It's been a smashing success and is only gaining traction.

Can we take a page from their book? In my opinion, we're just as entitled to the phrase Designing with Web Standards as they are. We have a three legged stool too: HTTP, URIs, and XML. Except our stool is more like a three legged dog - you can get around but it is not quite optimal. Why is this?

My feeling is that we haven't done a good enough job of showing examples of what the correct use of HTTP, URIs, and XML looks like in the real world. Joe Gregorio's excellent column aside, there just is not a lot of here's-how-you-get-shit-done-with-http type content available on the web, led alone books or magazine articles. We're amazingly talented at pointing out when something is being done wrong (e.g. WS-*, non-safe/idempotent GET, incorrect charset, etc.) but we suck at showing how to do it right in the first place.

(Here's some more pictures of three legged dogs because three legged dogs are the shit.)

To Hell With Bad Web Frameworks

Why are we having such a hard time showing correct use of HTTP and URIs? Because our tools suck. How are we suppose to show how to use HTTP and URIs properly when the tools and frameworks actively discourage practicing standards? Our incessant ranting on correct use of web technology is filed by many into the not living in the real world drawer. We're assholes.

In many ways this is the same battle that the Designing with Web Standards crowd has been fighting with their tools - the browsers. How can you preach standard use of (X)HTML, DOM, and CSS when the browsers have such poor support for them? Those guys drew a line and said To Hell With Bad Browsers and it's paying off. I think we need to take on a similar attitude and start expecting more from our web frameworks.

Every web framework I've ever worked with (Apache, CGI, Java Servlets, Quixote, Webware, Ruby on Rails, PHP, ASP.NET, CherryPy) were extremely limited in their support for the full set of capabilities provided by HTTP.

For instance, which frameworks ...

• ... help implement content negotiation properly?

• ... provide facilities for implementing a smart caching strategy for dynamic content? (proper use of If-Modified-Since, Expires, Cache-Control, etc.)

• ... make dealing with media types easy?

• ... make dealing with character encodings easy?

• ... encourage the use of standard HTTP authentication schemes?

• ... have a sane mechanism for attaching different behavior to different verbs for a single resource?

• ... help ensure that URIs stay cool?

• ... make dealing with transfer encodings (gzip, compress, etc.) easy?

• ... help you use response status codes properly? (e.g. Nearly all dynamic content returns either a 200 or 500).

Sure, some frameworks have tricks for portions of the list but there should be documented, well-thought-out mechanisms for implementing these facets of HTTP. Let's face it, if you want to do something outside of exposing well-known static representation types from disk for GET, or process application/x-www-urlencoded data via POST, you're off the radar for most web frameworks. I'm not saying that other things aren't possible, I'm saying they aren't supported well.

Shutting this one down

I've rambled for to long already. I have more to say on this but I'll try to keep it to short and focused posts over the next week or so.

To sum up, we need a good implementation of HTTP/1.1 that provides a real framework for building standards based web applications. We then need to advocate and illustrate the correct use of HTTP/URIs/XML as a killer technology that has been hiding right under our noses by showing the benefits of using the system correctly. Until we get this stuff straightened out, expecting people to use GET properly is unrealistic.

...

Sidebar: I just noticed that Leigh Dodds beat me to it:

[Udell] then continues by exploring the ease of using GET versus POST on the client-side. I think the fault actually lies on the server-side. Specifically, with existing web applications frameworks.

Word.

... I was running through the archives and found an interesting entry that could have been written about the Google Auto-Link fiasco. The title was, Who Owns Your Browser? and it is about per-site user style sheets. I had forgotten that Simon Willison, Adrian Holovaty, myself and many others hashed through a lot of this stuff almost a year and a half before Google's auto-link even hit the street and the issues are pretty much the same.

The discussion came out just as fractured then as it has this time around with the A-listers. Adrian's friends thought people using per-site user stylesheets to modify content would be a serious issue and that content providers would eventually sue, Simon was open to the idea that there might be some questions around ethics but didn't want to hurt innovation, and I said screw the content producers it's my goddam browser and I'll do whatever I please, thank you. :)

Maybe next holloween we can dress up like Winer, Scoble, and Doctorow and yell a lot? :)

The blogosphere is truly weird and amazing. I found out that there's a book I have to read that goes into the peak oil situation, expanding on this article. What's interesting is to follow the chain of events that will lead me to purchasing this book:

1. I wrote about the potential for a Ruby on Railsish stack for Python.

2. People link to this entry quite a bit placing it first in Google's results for the query python+"ruby on rails".

3. Alec was looking for info on Python and Rails earlier today and finds my ramblings.

4. Alec sees a totally unrelated link on my site to The Long Emergency, an article on peak oil that I read and bookmarked a couple of days ago.

5. Alec had been interested in peak oil for a while and jots down his thoughts on The Long Emergency article.

6. My technorati watch list notifies me that Alec linked to me.

7. I read Alec's piece and decide I need to purchase the book version of the article.

8. I purchase book.

Who could have predicted that web programming and the energy problem could possibly be related? The only real link between these two topics is interest on the part of a few individuals.

IMO, it's these types of serendipitous connections that make blogging a really interesting and unprecedented communications medium.

Jon was a Computer Science major at Ohio State University taking a course in artificial intelligence. The professor had set up an interesting group project where each student was responsible for writing an insect program that would be matched against all the other student's insect programs in a really cool network based insect war simulation environment thing that rocked.

The insect programs had certain constraints set by the professor. Size, shape, speed, and other traits were selected by each student but there were rules such that you couldn't just turn all the dials to full.

Once the basic properties of the insect were fleshed out, code was written to specify how the insect should act. There was an API for determining where your insect was located on the grid, approximating positions of other insects, moving your insect, attacking, rotating, etc. Pretty standard stuff.

The professor decided to pair students up: one smart kid with one dumb kid; the students who were having a hard time in the class would be able to work closely with a student that was excelling. Each student was responsible for their own insect but they were to debate their designs with each other.

Jon was one of the smart kids and was paired with a kid that wanted to change majors. Jon's dumb kid rarely attended class and seemed to dislike CS in general. He wasn't even in class the day the assignment was handed out and so Jon set out on his own to build the coolest and most advanced insect program ever created.

Over the course of a few weeks he burned through code until his insect was capable of responding intelligently to a myriad of changes in environment. It knew to run when outmatched by judging the relative strengths and weaknesses of an opposing insect. It would attempt to strafe and stay behind other insects. It would stay close to corners to reduce the potential attack positions of other insects. It was The Coolest Insect Ever.

The day before the competition, Jon's dumb kid decided to come to class. Jon asked him if he had finished his insect, to which the dumb kid replied he hadn't even started but would finish it that day, in class. Jon grinned smugly and tried to explain to the poor fool that he himself had spent all week working on his insect and that it still was not yet complete. The dumb kid shrugged and started in coding something that would get him the damn credit for the project.

Right before the class ended the dumb kid asked Jon to take a look at his insect. Jon had to fight the urge to laugh out loud when he saw that the entire insect was a mere 25 lines of code that barely made it through the compiler and with some lines having no chance of even being executed. The dumb kid had not even configured his insect's basic set of traits but had left them at the professor provided defaults.

Looking more closely, Jon found that the insect was programmed to do the same thing every time it had a turn to move:

1. Rotate 90 degrees.
2. Attack.

Turn and then attack. That's it? Jon asked, to which the dumb kid replied, Do you think I'll pass?

Jon tried to give the dumb kid some ideas on making his insect more advanced but the dumb kid wasn't interested. Jon decided that the dumb kid would most assuredly not pass.

The next day the competition was on. The professor loaded up the simulation program and everyone hooked their insects into the system. The dumb kid was late and then couldn't figure out how to get his insect loaded up. Jon helped him out while mumbling something about futility...

Finally the simulation began and Jon was excited to see his insect perform well through the first full round. In the second round, Jon's insect would get stuck in one of the corners, enter an infinite loop, and be forcefully removed by the professor. One by one all other insects would be killed by other insects or removed by the professor due to logic problems - that is, all but the dumb kid's insect.

As he sat watching the dumb kid's lonely insect turn-and-attack, turn-and-attack, turn-and-attack, as if to mock the whole class, Jon was forced to re-evaluate his definition of cool in relation to computer programs.

This story was told to me by Jon Miller (UNIX sysadmin) in the first person. It has stuck with me as an excellent illustration of the power of simplicity and the devil that is the human tendency toward complexity.