Unpopular Developer 4: Separation Anxiety, Part The First

The Unpopular Developer as been on a lengthy hiatus, for which I apologize. Frankly, my unpopularity has been flagging (or maybe more accurately upshown). I have really only gotten more impressed with Ruby and more specifically the Rails community over the last year, and the directions web development is taking under their growing influence, most notably, with the success of RESTful APIs.

REST & DDD

That, however, brings me to some remaining gripes, which are increasingly oriented toward the repercussions of implementing design driven development (don’t get me wrong, DDD itself is not merely a practical, but arguably the best way to approach software design, at least on the web-but I’m don’t want to get into that here). I think it is telling that DHH’s keynote at RailsConf was not quite as tumultuous this year, as compared to the announcement of Rail’s commitment to REST; he even took the time to reflect on that fact and defend it as a natural consequence of the growing maturity of the framework. But I think it also indicates that REST may be Rails’ best achievement to date-the ultimate convention of simplicity. As a developer, the immediate benefits of REST in terms of ‘for free’ setup it offers (I was giddy for hours after my first scaffold_resource) have given may to an almost mystical devotion to the purity of my controllers.

After pathetic attempts to get them to fit in as 9-5ers, it has become achingly obvious that they just aren’t cut out for business. They just can’t take the pressure. They need a day off, maybe even a relocation to France. The most they can handle and still maintain a friendly demeanor when they come home to their model spouses is a few quick GET/PUT operations. Why are they so overworked? Because they are enslaved by capitalist pig-dogs, also somewhat more commonly known as views. And nobody seems to notice, or care, not even the AFLCIO, because these views were spec’d by clients, mocked out by professionals, and look pretty damn fine. Pretty people catch all the breaks.

Conflict & Divorce

I am consistently having to implement unconventional logic, aka glaring hacks in my controllers to get them to display views correctly, and it makes me cry, if only a little, on the inside, at night when I’ve had a bit too much. What sort of hacks? Well…hacks like this (with the apologies to the code coach). “New” actions that fetch 3-4 objects. “Update” actions which create objects and redirect to arbitrary locations. “Show” actions which render editing forms. Is this my fault? Am I the cause of all this tension in my family of apps? “NO!” my RESTful therapy assures me What is this a violation of? Separation! What do we want? Dumber controllers! When do we want it? ASAP! YEÅH? OH YËAH!

By now, you’ve finally actually realized that I’m complaining about the lack of separation between HTML requests and controller responses. As ludicrous as it sounds, I believe that one of the most pressing issues in practical Rails development right now is disassociating views from controllers, so no matter what your page layout is, your controllers are free to be who they want to be: lazy, dumb and thin. Bizarrely, this will make them more popular with the ladies and the gents. Right now I’m seeing 90% of bugs generated by unconventional controller logic, rather than relatively stable view implementations, or well-tested model classes. But even in principle, if a view specification calls for a form with particular objects and and buttons and links which go to other views, the view logic should take care of making that happen. Don’t ask the controllers to do it, they’re already bringing home the data-bacon, what more do you want ?!1

In conclusion, do I have a practical solution for this? No. Well, there’s this. And for now, that’s all there is, a flashy graphic to tattoo on your face to cover your shame. But, also yes….if you’re willing to take the plunge….next week.

To be continued!