资源：
http://blog.scribestudio.com/articles/2006/07/09/david-heinemeier-hansson-railsconf-2006-keynote-address
http://www.loudthinking.com/lt-files/worldofresources.pdf

TRANSCRIPT of
RailsConf 2006 Keynote Address
by David Heinemeier Hansson

Contents
01. Discovering Resources on Rails
02. Problem with CRUD?(DHH learns to stop worrying and love the CRUD)
03. Get, Post and Clean URLs(Don't Do Busy Work)
04. Accounts, Controllers and CRUD(Evaluating the richness of the domain)
05. CRUD is Not a Goal but an Inspiration(Not one paradigm captures all the world all the time)
06. Controllers, Design Patterns & MIME(Have one controller for many MIMEs)
07. Doing By Hand Leads to Good Design(IDE is not necessary)
08. Get, Find, Post Redux(Active record and assigning IDs)

02. Problem with CRUD?(DHH learns to stop worrying and love the CRUD)

The problem with CRUD is (that) it's got kind of a bad name, actually. (audience laughing) Not only it has a bad name, it has a bad reputation.

Oh, by the way, this talk is not in Japanese also because I can't write Japanese, but  because I was just there to (days ago) and gave this talk. And since there's(?) this wonderful ultimate universe thing, nobody from the west really had any idea of the talk going on, thereas I thought I just reuse it. So ... thanks for letting me do that, Japanese guys!

Well, what they told you about CRUD? Well, first of all they told you it was simplistic, so just doing CRUD is simply not enough:

[showing PPT page 3]

It's too simple. You can't just have these four operations and expect to do anything interesting. And the world is way more complex than what these four simple contexts or constructs can put together, it's simply too simplistic. And because it's too simplistic, it's unfufilling work. You're not really doing enough if you just doing CRUD. CRUD is not a satisfactory way of working, it's simply not enough to keep our great intellects occupied. And I really meant that it's unworthy. You shouldn't spend too much time on this CRUD stuff -- it's simply too basic, it's just an assumption, it's just there.

Really, if you are doing it, you should be somewhat ashamed. (audience laughing) Really, don't spend your time on this CRUD stuff -- you have much bigger and better things to do with your mind.

[showing PPT page 4 & 5]

Well, they were wrong. And this talk is in large part about how I learned to stop worrying and love the CRUD. (audience laughing)

[showing PPT page 6]

CRUD, of course, is represented in our world mainly in these kinds of operations. So, at the object level, we have find, creat, update and destroy -- those are the verbs we use when we manipulate Active records and other types of object-oriented things.

Well, in the database world, it's pretty much the same thing. We have SELECT, INSERT, UPDATE, and DELETE. But the thing that really got ME started thinking more about CRUD recently is not those basic constructs -- they've been around for a long time enough. And that is really what makes CRUD to seem as just this simplistic thing -- it's just there, not really worth talking about.

[showing PPT page 7]

Recently we've had somewhat(?) a renaissance -- a renaissance for HTTP. HTTP adds another layer on top of this CRUD stuff through the verbs GET, POST, PUT, and DELETE. Well, most of us, most of the time, are just thinking about HTTP and thinking about the web as GET and POST -- we're not really thinking about HTTP as a protocol that exhibits the four range of CRUD-ness.

(And) I'm certainly guilty of that, for the longest time my conception of HTTP was that it was just this GET-and-POST thing. That led me to have URLs like this:

[showing PPT page 8]

So this was how a CRUD application was exposed to the rest of the world. When you wanted to creat something, you would POST to this special URL for creating a new person(see PPT page 8); when you wanted to get something, you have to show verb(?) or word(?) inside that URL; when you wanted to update or destroy these, you're just to POST operations, or even worse sometimes, GET operations, on various URLs.

Well, just from looking at this picture now, I get a little bit of woozy(?). The fact is that all the stuff we're doing in Rails is largely about not repeating ourselves.

If you look at these verbs, POST, GET, and the URLs -- they're pretty much repeating themselves. Look at the number two (see PPT page 8 line 2), (so) we're getting the person number 1. Well, we're kind of presenting that term already in the URL -- the same 'show'(possible meaning: GET already meant "we're getting the person number 1", while 'show' is just repeating that term). But something's not quite right here. It's not quite right because we're not using the CRUD features of HTTP. When we are, we can get something that's nice and clean and beautiful, and it looks like this:

[showing PPT page 9]

The URL now becomes a way of identifying the thing we're working with, and the verbs become operations on that. Before, we mixed the two, so we both had identification, and we had what we were doing with that thing. Well, this(see PPT page 9) is obviously a lot nicer, but there's, of course, a reason why we haven't exposed this and used this very much. And how that part of HTTP in general has kind of got forgotten along the way? That's of course because it's a pain in the ass to use, and it's a pain in the ass to use because HTML and the rest of the web world wasn't really geared up for this beauty that was already present in HTTP.

Well, since what it is we're doing is, well, a framework, which is all about removing those (bad) things and exposing the beauty of beyond-the-line concepts, why wouldn't we tackle these problem too? The answer, of course, is exactly what I'll be talking about today -- how we've tackled this process of turning these URLs(see PPT page 8) into this(see PPT page 9):

And this is initially got to be a conquest in its own mind for some people. just to getting these URLs in itself held some great promise, some magical thing would happen once you got these clean URLs.

Well, not really. I guess it's not the clean URLs we're after, but I'll get to that in a moment. Now, in Rails, the way we get this started, and the way we'll get it started from the next major release (Rails) 1.2, is that in your r...ts(?) file, you can start talking about these things, you can start talking about the resources. So, if you want to expose this beautiful set of URLs to a given resource, which is often just a given model, you'll do something like this:

[showing PPT page 10]

In the r...ts(?) file you'll say

map.resources :person

Person is now available as that beautiful URL. Routing will start to happen automatically depending on the verb, instead of just depending on the URL. And you'll get something like this:

[showing PPT page 11]

You'll get, from the same example, that we can have a PeopleController as the four CRUD operations, create, show, update, and destroy. And we can direct people to them from the same URL. So the first one POST to people will lead to a create action, the second one will use the same URL as we'll use in update and destroy. But when GET operation is called, we're doing 'show'; when the PUT operation is called, we're doing 'update'; when the DELETE operation is called, we're doing 'destroy'.

This old(?) method should be somewhat familiar now because this is a convention. This is exactly what we've been doing in Rails all along. We've been making things, configurable(?) things, just disappear by inventing conventions, by inventing our own world where these rules just magically apply.

Now, how do we get to this? One thing is that, it's actually possible to do PUT and DELETE verbs against controllers, but as I've talked about just a minute ago, that's not very helpful from HTML because HTML doesn't expose these things natively. We fix that. (audience laughing)

[showing PPT page 12]

So, the first one(see PPT page 12) is doing a POST against 'people'. Well, that's pretty similar to what we've been doing all along. So that doesn't need any special introductions -- that's just a form as a textfield, and we'll do the normal things to forms in Rails too, which is POST. So far, so good.

[showing PPT page 13]

The 'show()' is, of course, just a normal GET, not very interesting -- we're linking to something, and we're given that URL and the GET automatically will happen.

Now the interesting parts are update() and destroy().

[showing PPT page 14]

For update(), we need a new way of describing that this form is not the regular POST -- it's actually a PUT, it's an UPDATE. This is how it should have been in HTML -- you should just have been able to destinate(?) on your form that the operation you're using was a PUT. Unfortunately, that's not quite the case. So, we have to fake it, and we're faking it in Rails by picking(?) backing(?) on POST. So, by making this construct, you'll actually make a form that will include a hidden field called underscored method that include the real method -- the one we're actually talking about. And when we then submit that, Rails will believe that what we're doing is actually PUT.

[TO BE CONTINUED]