Ruby on Rails: Out of the Box Improvements 6
I've written several Rails apps that are in production use, and I love working in Ruby on Rails as my daily development platform, but let's face it, it has a bunch of problems. Just because the Rails team did a lot of things right doesn't mean that there aren't a bunch of things that can be improved right out of the box. Here are the first couple of things that I would do if I was starting a new Rails Project tomorrow:
Install HAML. I can't stress enough how much better your life will be if you use HAML instead of rhtml. Imagine DRY templates, less view code, and perfectly formatted XHTML every time. Imagine the sky opening up and angels coming down and lifting you up to templating heaven (it's next to dog heaven). That's what HAML gives you. We've solved the problem of looking at ugly HTML with embedded code a hundred times now, so why do we keep going back to it? Don't subject yourself to that sort of pain again! Install HAML and don't look back.
Dump the integrated testing framework and install RSpec. It's great that Rails has a testing framework integrated with it, but it has a number of problems. It confuses well known testing terms such as functional tests, there's no way to test views separately from controllers, etc. RSpec blows it away. Not only does it give you all of the advantages of doing Behavior Driven Development, it fixes the a bunch of the inherent problems with the Rails testing framework. No longer are controller tests called functional tests and model tests called unit tests. Now you just have model and controller specs. It also allows you to group your use of fixtures into different contexts for for different sets of tests, although you shouldn't really have to use fixtures much anymore because of RSpec's great built in mocking support. Overall it's a big step up from the built-in testing framework.
Just doing those two things will make your development faster by making your code easier to understand and by cleaning up a lot of the rough edges of the Rails framework. At this point I can't imagine going back to the standard Rails way of doing things.
Trackbacks
Use the following link to trackback from your own site:
http://kurt.karmalab.org/trackbacks?article_id=ruby-on-rails-out-of-the-box-improvements&day=08&month=05&year=2007
Both of those two points are very useful. However, I strongly believe that the very needed feature is Just in time compiler to get Ruby runs faster on rails.
Nice blog
Is HAML really that good?
How do you do integration type testing with RSpec?
bryanl: HAML is really that good. It significantly slims down your templates and gives you perfectly formatted XHTML as output. Just install it in your Rails app and convert a couple of pages from rhtml. It only takes a minutes, and if you're like most of the people I know who've tried it you'll never look back.
Integration testing can't be done in RSpec yet. We still do ours using a combination of the built in Rails integration testing framework and Selenium.
HAML is great when one developer is doing everything. However, I tend to work on large development teams and one of the great things about MVC platforms is that a web designer can work independently of the developers on the view code. The designer, and the designer's tools, tend to be a better fit with RHTML.
Mark: We give our web designers nice clean XHTML example pages and they style it with CSS. Then we just drop in the CSS and run with it. You can't get much of a better fit for their tools then that.
If changes need to be made on our side they're usually minimal (add in a div, change an element's class, etc).
I've never had much luck with allowing the designers to edit the template code directly. Too many problems tend to crop up.
I think we are in agreement. It all depends on who you want working on the XHTML: the developer(s) or the web designer(s). HAML is great for the former, not for the latter.