RailsConf 2006: Day 2 (part 2)
by Curt Hibbs
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.
Reminded me of Adam Bosworth's 2005 MySQL talk.
Excellent coverage ... definitely wish I had gone.
|About the "tower-book picture": a picture is worth than thousands of words.... really true!!!!|
I dont know much about Rails but I know that Rails makes the development of CRUD based applications simple and easy. I am Java/J2EE developer trying to learn Ruby and Rails because I heard it's good for small web apps. But dont you think the picture is exagerated?. Why do you need XDoclet, XSLT, JFC for that? How many Struts books you need to learn Struts?. Dont tell me there are no best practices in Ruby world. What webservices has to do with it?. Ask any J2EE developer, one need not learn all the details of JBoss server to develop a app.
Unless those two Ruby books cover XML parsing, webservices, best practices, Object Relational mapping, deploying and managing the app, automated tests this picture doesnt make sense. You are simply sending wrong information to new J2EE developers.
|Adi, of course the picture is exaggerated... all good comedy/satire is exaggerated!|