RailsConf 2006 Day 2
Ajax on Rails
“… to quote one of the eminent thinkers of our time, Paris Hilton, ‘That’s hot’” — Justin Gehtland
I’m always wary of people who talk about ajax within the context of a particular back end. Ajax shouldn’t care about what back-end its talking to, so I almost skipped this session. This wasn’t really about ajax, prototype and script.aclio.us were mentioned, but that was about it. He went through what rails can do for you from an ajax perspective without you having to write any javascript. He did acknowledge that
“This is normally a bad thing”
but argued that it is ok in this case as the javascript being generated can be viewed and edited, as can the code that is generating the javascript. Also the javascript being generated is clean. I still think if you want to get serious about Ajax your going to have to bit the bullet and learn javascript properly, but you can get a few ajaxian things done here.
They moved on to demo a replacement for scaffold that uses ajax. It’s called streamline and they will be open sourcing it about a month from now (basically ASAP). I believe it will push Rails way beyond where it is now. It’ll be even harder to ignore.
The only session worth talking about after that was “Using Rails on Legacy Database Schemas with iBatis for Ruby”. Very quickly, iBatis follows the “data mapper” pattern vs the ActiveRecord pattern used in Rails.
“Active Record leverages simplicity,
Data Mapper tackles complexity.”
What they have done here is very slick. You can write your own SQL and create mappings to build objects out of the ResultSet you get back. It then hands these objects off to ActiveRecord in Rails and Rails in none the wiser. The validation in your model still works the same way. However they warn you not to underestimate how much SQL you will have to write. If it is at all possible to do it the ActiveRecord way, they recommend doing that. Chad Fowler has been credited with summing it up best.
“I like what you’re doing, but I hope I never have to use it”
Next up, Mike Clark again, (he’s Java free for 15 months and 17 day now). They have opened up the three rooms into one again (yea, it’s a small conference) so there is no choice everybody is attending this session. I think it is indicative of the Rails comunity that they want (or expected) everyone to attend this session. Testing is at the core of Rails, when you create a Rails project; the test harness is already in place, making you feel guilty about not writing tests. This is what I love about Rails and indeed Ruby. It encourages and rewards you for doing the right thing. If your primary key is an auto-incrementing integer call id, you don’t have any code to write, if not you have to do some stuff, but more importantly you have to ask yourself why not. It educates you, but still gives you the choice. We get an overview of the five types of test that every rails app get the infrastructure for the moment it is created. unit for testing the model, fixtures for placing data in the db to test against, functional for testing controllers (without a web server running) and integration for user stories. This seem to end up heading towards a DSL and from what I saw would fit (on pun intended) very well with fit.
The final talk before the auspicious DHH. “Homesteading” This was a strange one, was a comparison between the Homesteading bill in the 1800 in America and the web today. At time it was like a religous sermon and at one point when he was talking about time a quote from furturama pop into my head
“Now you’ve watch it, you can’t unwatch it”
essentially he was encouraging people to start small companies out there on the world wild web.
The final session of the day was David Heinemeier Hansson (DHH). He talked about a CRUD constraint world.
“CRUD has a bad name”
He gave a few examples of using CRUD arguing that, like test driven design is more about design than testing, developing using only CRUD is more an aspiration or design technique. The first example he gave was groups and users. Users have to be added to groups or vice versa. If you add membership to the domain then simple CRUD operations on membership remove the need for a complex many-to-many relationship between group and user. This is covered well by Evans in Domain Driven Design.
Another advantage of limiting yourself to CRUD is the controller is greatly simplified. Most of the time you can get away with create, show, update and destroy.
“How I learned to stop worrying and love the CRUD”
And this advantage can be pushed ever further. Take HTTP for example. The spec defines a number of methods to be preformed on the object defined by the URL. GET and POST are well known as they are supported in HTML. However if you add PUT and DELETE you have the basic CRUD operations. This simplifies your URLs
POST /people/create
GET /people/show/1
POST /people/update/1
POST /people/destroy/1
Can become
POST /people
GET /people/1
PUT /people/1
DELETE /people/1
This lead to the introduction of ActiveResource. Taking all the advantages that Rails has exploited from ActiveRecord and applying them to web apps via HTTP instead of DB via a database connection. The whole web opens up as a potential resource for your application. This is the direction DHH see Rails heading.
