Tea-Driven Development » patterns

Two Truths I’ve Learned About Writing Clean Rails Apps

Matt — Fri, 04 Mar 2011 13:28:01 +0000

In summary:

Implement every feature without javascript first, add javascript as a progressive enhancement
Stick to REST. Always.

Now I’m as suspicious of absolute rules as you probably are, but these two have served me extremely well in keeping my Rails code clean and easy to maintain. I’m happy to push the boat out and call them truths, my truths anyway.

Let me explain.

Progressive Enhancement

When I first started at Songkick, Cucumber was just emerging and webrat was the new kid on the testing block. Although using Selenium for full-stack javascript testing was possible with webrat, it wasn’t easy and we quickly made a decision: we would build the first iteration of every feature to work without javascript. This was mainly driven by pragmatism: we could easily use webrat to test the app through Rails integration testing stack, and these tests ran quickly rather than waiting for a browser to start up.

What happened surprised us. We would receive fancy designs from our designers which could only be implemented with fairly complex javascript. Because of our rule, we had to figure out how to deliver the same behaviour using basic HTTP posts and gets of forms and URLs. This required us to simplify the designs for our first iteration. We got a little push-back at first but we were a tight team and the designers quickly caught on. Especially when we started shipping these iteration one features quickly and reliably. And funnily enough, it turned out that often these simple HTTP-only versions of the features were actually fine, and the designers decided we should move onto other stuff, instead of building all that complex javascript that had been implied by their earlier designs.

So this rule had helped us to do the simple thing. We shipped features and moved on.

When we did have to add javascript, we added it on top of the existing working HTTP-only implementation, and we got another surprise: it was easy! Nearly every time, because we’d built the server-side infrastructure to a clean, standard pattern, the javascript we needed was clean and simple to write.

Which leads me to my next truth…

Stick to REST. Always.

I’ve always felt a little uncomfortable with Rails’ controllers. They violate the Single Responsibility Principle for me. I’d prefer a pattern where I had a separate Request class for each action, rather than a few largely unrelated methods on the same controller class. But Rails is there and there’s a lot else to like, so let’s not get into that.

We all know it’s a bad idea to let our controllers bloat and something I’ve been enjoying greatly lately is Jose Valim‘s Inherited Resources. By sticking to this pattern, you push all the logic into your domain model, and keep the controllers focussed on what they need to do: handling web requests.

You end up with more controllers, and more models too. You create model objects that — Gosh! — don’t represent database tables, but represent other domain concepts instead. Altogether though, you end up with smaller, more focussed classes that are easier to test and easier to read and understand.

Software as an Art Form

Matt — Thu, 27 Sep 2007 06:59:54 +0000

I just came across an article written five years ago by Richard Gabriel proposing a university course run along the lines of his own Master’s in Fine Arts in poetry. The idea evidently gathered some momentum at the time, but now seems to have come to a halt.

What a shame. I’ve had an idea to get back to university on a ‘some day’ list for a while, and this would have been pretty much exactly my thing, I think. Seems to me like it was just an idea ahead of its time… I wonder how popular something like that would be now, with the increased focus on Quality that is sneaking in the back door behind the noisy razzmatazz of agile adoption.

Model-View-Presenter (MVP) Anti-Patterns

Matt — Wed, 13 Jun 2007 19:07:50 +0000

As I work with the MVP / Passive View / Humble View pattern more in ASP.NET, I’m gaining an understanding of some common smells or anti-patterns that can happen when you try to implement this pattern and haven’t quite grokked it yet. Some of these are problems I’ve had to pull out of my own code:

TOO MANY PRESENTERS SPOIL THE BROTH

When you re-use a user-control or even just a view interface on different pages, it’s tempting to re-use a special little presenter inside each of those pages whose sole responsibility is for presenting that usercontrol. If you have two different flavours of page, you might even put the call to the presenter into a BasePage.

This is fine as long as those pages need no other pesenter logic, but there are usually other controls on the page too, and they’ll need to be presented, and before you know it you have two or three or a whole crowd of presenters yelling at different bits of your page, telling them what to do.

Lesson: This is the path of darkness and complexity on the tightrope of your untestable UI layer. Re-use presenter logic by all means, but do it inside the presenter layer, where you can test. Everybody say Ahh… Tests…

Maxim: No more than one presenter to be constructed per page / request.

THE SELF-AWARE VIEW

Within a request / response cycle, only the Page should be aware of the existence of a presenter. The HUMBLE VIEW (implemented in a UserControl) does what it’s told without any knowledge of who is dishing out the instructions. Find this smell by looking for UserControls which construct their own private little presenters, or worse still accept them as properties (usually so that they can do filthy things like call methods on them – see ARROGANT VIEW, below).

ARROGANT VIEW

The arrogant view is not only SELF-AWARE, but has the temerity to imagine that it has the right to give the presenter direct instructions. Thus a presenter can easily be relegated to nothing more that a PROXY MODEL, with logic creeping up into the untestable view layer. Find this smell by looking for presenters which offer public methods. Replace these direct method calls from view->presenter with a more humble OBSERVER PATTERN, where the view raises events containing the relevant information in the EventArgs, and the presenter reacts accordingly (or decides not to, as is its privilege).

PRESENTER BECOMES PROXY MODEL

When you have an ARROGANT VIEW that commits the crime of directly calling methods on a presenter, you start to see the logic in the presenter thin down to the point where it becomes little more than a proxy for the ‘model’ (in classic MVC terminology) or service layer. The whole idea of MVP is to delegate the responsibility of figuring out what to fetch from the service layer and when to fetch it, so that the view just gets on with displaying whatever the presenter decides it should display. When an ARROGANT VIEW gets these kind of notions, logic that belongs in a (testable) presenter is tangled up with display logic in the view, and it’s time to roll up your sleeves and refactor.