Rails, and contract-based design.

I've just finished my first Rails web application (link) and now it's time for a debrief - since I've actually produced and deployed something, and thus, am not nearly as scrubbly as I once was. Since I actually have a blog now, hopefully that also serves to elevate me above plebeian status.

Rails is fast.

Your friends didn't lie to you. Rails is damn fast. I created the website in probably only two to three hours of actually sitting down and making keystrokes.

Rails documentation sucks.

RDoc is a wonderful, powerful, amazing tool for the creation of great web-based documentation. And Rails doesn't use it. The reason being because the biggest method in any class in any rails app is method_missing, since that's where all the magic happens, and that's really hard to make documentation for.

Rails lets you write some really bad code.

Rails is so amazingly productive, you'll get carried away by developing incrementally and iteratively. At least while you learn it, you'll have absolutely anemic models and bloated controllers with redundant, ugly, logic-filled views. This is not very Rails-like. Yet, if you're like me, you're so focussed on getting to the next milestone and getting the next iteration out the door that unless you've been drilled with good practices, you're likely to forget them.

So what's a developer to do?

Enter Ruby Design By Contract. (Note that, according to wikipedia, 'Design By Contract' actually might be a registered trademark, so use it with caution.) RDBC is available through gem, and it actually has a pretty good readme, so just do a "gem install rdbc ; gem_server" and read all about the spec. Done? Ok, good. Basically, rdbc allows you to create a number of pre and post-assertions that execute in your code, which is great if you're creating a library, say, and you need to unit-test it. But what about if you're creating a rails application, and you have all of this magicks going on that you need to keep track of?

That's where this next project will come in - I'm going to write a rails plugin that allows you to define, from a top-down perspective, everything in your application, which controllers require what inputs and what views they call, what methods are available to each of your method objects... everything.

The end result?

Domain-specific documentation. Fat models. Anemic controllers. Beautiful, #HAML-expressible views. An order of magnitude more productivity, and a logarithmic decrease in bugs.

Interested? Stay tuned.