As if I wasn’t already jazzed enough, Day 2 finished with a surprising keynote address from David Heinemeier Hansson. But I’m just teasing you, you’ll have to read down to the end to find out what it was.
Rick Bradley and Charles Johnson talked about their large “enterprise” healthcare application that began its life in Java that was abandoned midstream and rewritten in Rails. The Java version the app (Struts, JSP, Hibernate, and EJB3) was never completed, but at the time its development was abandoned, it totaled about 250k likes of code. The Rails version reduced that code size by 25x (around 11k lines of code). Rick has blogged about it here.
I’ve used this photo in my own presentations, but I didn’t realize it cam from Rick’s project:
Glenn Vanderburg gave a very interesting talk about Testing Migrations. Testing changes to your database schema is hard, and usually not done at all. Glenn showed the beginnings of a testing framework, but there are still lots of unresolved issues. Besides the practical value, this turns out to be in interesting intellectual problem in its own right. How do you use a running system to test changes to itself?
In Mike Clark’s talk, Testing Rails Applications, he asks the question, “Testing: what’s in it for me?” Mike says that the traditional “guilt” reasons, like higher quality code, don’t cut it for him. No, his reasons are more selfish. He feels that programming should be fun and that tests are, in part, his insurance that working on the app will stay fun.
Mike said he was originally drawn to Rails because it strongly encourages and supports testing (”Rails makes it easy to do the right thing”). He demonstrated the testing support built in to Rails, and said that while he does do TDD (Test Driven Development) he doesn’t do TFD (Test First Development). But, he thinks that Rails’ new integration tests may be the thing that changes his mind about TFD.
Nathaniel Talbot gave what he described as a continuation of his RubyConf 2005 talk on the long tail of software development. He used the metaphor of Homesteading to talk about taking risks to do the things that were are passionate about, scary things like starting your own business.
But, of course, the highlight of the day was the keynote address by David Heinemeier Hansson. He started off by reiterating the fact that Rails is opinionated software, a that a large part of its success stems from saying “no” to adding superfluous features and keeping the core of Rails true to its original vision. He sees no reason to change and start bending Rails to the desires of the outside world when we are having so much success bending the world to Rails!
But the bulk of his talk revolved around a simple, but profound theme–the idea that CRUD (Create, Read, Update, and Delete) should be the basic building block for models, actions, and APIs, and that when you find yourself needing to go beyond CRUD, that should be a red flag that something is wrong with the design. He slowly built up examples that promoted the message that sticking with the simplicity and consistency of CRUD yields some surprising and unexpected benefits.
This culminated in David’s presentation a new Rails feature that is a direct result of this new focus on CRUD, one that promises to supplant and surpass Action Web Services: Active Resource. David said he’d only been working on it for two days, but it will let us create, share, and consume resources over the web in a transparent manner that requires almost no extra work. Instances of an Active Resource object (once they have been connected to their remote resource) will look and behave just like an Active Record object.
I know I’ve done a terrible job of describing Active Resource, but keep your eyes open for this one… I predict that it will have a huge and profound impact.