Rails, where the boundries are pushed

So i had a bit of a break from developing rails apps when i first joined Yahoo. Pipes is php with a perl backend and a lot of javascript. Then i worked on an unnamed, and yet unlaunched, pure javascript app for a bit. Now i’m back doing some more rails work and I’m much happier. Not that i haven’t learned something by slipping in to other languages and frameworks. Most recently, like everybody else, i’ve been playing with Erlang and CouchDB. It’s interesting and i think there is something potentially important there where we can finally away from a relational database being the only backend for web applications.

But that’s not the point of this blog post.

What really has made me happy about getting to do rails stuff all day again is the rails community. There is a genuine debate about the state of the art. What is the best way to do web development. What’s the best way to write regression tests for our applications. People are writing libraries, creating solutions, experimenting with various ways of solving the problem of building quality applications. Rails is perhaps famous for being a quick and agile way of throwing up sites which have rounded corners and are all RESTful. There’s a backlash which says rails doesn’t scale, and we have the endless public discussions about scaling twitter.

But this is not a blog post about about rails stereotypes.

This is a blog post about innovation. There are many developers in the rails community who care deeply about the quality of their work. It’s that rails has drawn in many craftsmen, and craftswomen. The rails community has people who care about quality. The code shouldn’t just work, there should be elegance in our creations.

One place we see this craft is in the testing world. Tests have gone from the caugh syrup which everybody is supposed to drink but hates, to something people really do. People are passionate about testing, and making testing simple, fast, and clean. The ruby language has allowed flexibility and fancy meta programming to create custom DSL’s for a long time. But it is the culture of rails which has pushed testing forward.

A good example of this are the mocking libraries. The old guard mock library is FlexMock, it’s stable, quite functional, and it’s what rails itself uses for it’s mocks. Unfortunately, it’s also pretty clunky in comparison to Mocha.

FlexMock Example:

    flexmock(Item).should_receive(:find).with(1).and_return(
      flexmock("guitar",
        :name => "Deschutes",
        :description => "Deschutes model Guitar",
        :unit_price => Money.new(2400.00)))

A Mocha Example:

  product = Product.new
  Product.expects(:find).with(1).returns(product)
  assert_equal product, Product.find(1)

Both libraries work, but Mocha takes to heart that code should be super readable. It’s taking the possibility of ruby and crafting it in to a particular style.

This all brings me to a question Mike Clark asked this week, How do you test your controllers?

His question comes down to how do we test our controllers. It’s a slightly different question than how do we do functional testing in our rails apps. It’s a really good question. What do we test, and how. Mike wrote up some ways in which he does it and covered how to do it the test unit way and the rspec BDD way. Jay Fields responded with how he does controller testing using the test unit style, and the Elevated Rails folks showed how they are doing it with rspec.

What strikes me is that people are really trying to find out what a better way of doing it is. There isn’t a simple answer. Not one way of laying things out. More over, people aren’t punting on the problem and just doing some kludge. Many libraries are being created, modified, and pushed forward. This active debate and space for experimentation is part of why there is so much work around BDD in the rails community.

To me, rails a community of developers who want to build things fast, agile, and elegant. The community is far from having all the answers, but it’s a place where people are asking the question. Looking at our work as web developers and questioning our methods.