Vita Rara: A Life Uncommon

Walking into the Light: A Week With Ruby on Rails

Categories: |

This past week or so two developers whom I greatly respect and admire really opened my eyes. It's been an interesting time since then. On October 23 on the Struts Developer list Craig McClanahan wrote:

Why the long winded diatribe? Because while I'd *love* to see life made simpler for Java web developers, and a lot of the things happening in Struts2 are going that way -- it won't be me doing it. I've gone over to the dark side :-) and much prefer to develop in Rails -- for the conciseness mentioned above, but also because I don't ever have to do a "build" or "deploy" step during my development cycle any more. But you guys and gals need to be reminded that *this* is the kind of thing you are competing against if you expect to attract Rails developers ... or to avoid even more "previously Java web developer" defectors like me :-).

To which Ted Husted followed up:

Personally, I'd characterize going over to Rails as walking into the light :)

Wow! Here are two of the leaders of the Java web development world extolling the virtues of Ruby on Rails. It was an eye opener to me.

I have respected and admired these two guys for years. I've used Struts 1 and 2. I learned Struts 1 from Ted's book. I've worked with Struts 2 for over a year now. Hell, I've bent Struts 2 to my Groovy will with help from the guys on the Struts 2 list. And here they are lauding Ruby on Rails.

Now, personally I've stayed away from Rails. I really didn't want to learn another language, another framework, another set of libraries, another, another, another... Yea, call me lazy, it's a virtue. (cf: man perl)

Well, I'm one week, well really about 12 hours, into playing with RoR, and I'm thoroughly impressed. I keep thinking to myself, "why have I been working so hard all these years?!?!" Where's the XML? Where are the annotations? Where's all the configuration? Where's the struggle to get Spring working with Hibernate/JPA, working with Struts 2? What you mean I don't have to compile, deploy, restart?!?! Huh?

I realize now that I've been trying to do with GroovyWorks what the Rails guys have already accomplished with Ruby. I sort of solved the deploy and restart problem by using Spring/Groovy/Struts2, but what a pain! If I change an interface I have to restart my container.

Now, I'm just at the banging rocks together phase with RoR but I see the promise. I see light and I don't hear any trains. The virtues so far:

  • Testing! Yea, I know Java has JUnit, but with RoR it's all there right from the get go. All packaged nicely, with support for unit, functional and integration tests. Integration tests! I love integration tests. I really like to know that everything hangs together the way it's supposed to. Plus, there is explicit and integrated support for fixtures.
  • Completeness, it just seems that everything is there, in a logical place.
  • Elegance, yes, it is in the eyes of the beholder, but Rails and Ruby are elegant to mine. The one that really impresses me is that Ruby supports the Uniform Access Principal[1] Right on!
  • Simplicity. The elegance and completeness just make the whole thing simple.
  • Well defined best practices. When the whole stack is well defined it's easy to come up with best practices. I've found Railscasts to be a good source of basic practices.
  • Ajax support baked in. I really like this. I looked at the Dojo support in Struts 2 and didn't care for it and started using Prototype, which Rails uses. So, my knowledge has carried right over.
  • No deploys and restarts. Need I say more. I can support more iterations on less powerful developer machines and save the money. We've been running on G5's and Mac Pros for some time now. They're just overkill for Rails. What a pleasure to have a responsive development environment that I'm not waiting for.

    This issue all on its own is what pushed me to get Groovy Works working. Groovy Works isn't as good as Rails, because all transactional classes must implement an interface, so if you change the interface you have to restart. Even with this deficiency it would be hard for me to calculate the amount of time not needing to deploy and restart has saved me over the past year using Groovy Works. I can't imagine how much more I'll save with Rails.

  • Oh yeah, TextMate. I know it's not RoR, but damn does it work nice with Rails. Twelve hours and my hands are already remembering the short cuts after using vi for 12 years every day for programming.

Well, as you can probably tell, I'm pretty excited about Rails. I'm going to keep walking toward the light.

[1] Myer, Bertrand, "Object Oriented Software Construction": Basically it boils down to being able to access a member or a method that takes no arguments using the same syntax. This allows you to change from a member to a method and not break your existing code.

Grails man Grails

I'm surprised that if you know Groovy and you like the Ruby on Rails paradigm that you haven't checked out Grails as well. It's Groovy and coding by convention. Under the covers it uses Hibernate, Spring and Spring MVC but you never need to know about them. All of the benefits you attribute to rails can be true of Grails as well.

Ruby on Rails vs. Grails

I really don't want to dive into this comparison, but when I wrote that article Grails was quite immature. I'm sure that has changed since then, but I have become pretty heavily invested in Rails and particularly in Ruby.

I spent too much time dealing with the constraints of the Java object model and the restrictions it causes in Groovy for my personal liking. So, I moved on and I'm really happy about it. For me Ruby is the nicest language I've ever worked in. It's brought joy back my development.