Saturday, January 22, 2011

Hobos hacking on Rails

Testing my newly found programming confidence, I started hacking up an example survey form for a client. I tried Hobo, which led to some interesting observations about what Agile really means.

One moment my sample app was working, the next it was not. The problem was that I had generated a resources controller and model combination with a name that Rails did not like.

I checked over the model names and use ack to search for deviances. Convention over configuration, they say, except that nothing appears to be deviating. Somewhere along the line something got mixed up, and now it doesn't just work. Instead it broke the whole application.

Well, that points up a couple of ugly properties of Rails apps.

Small changes have an application-spanning impact

Pre-Web languages, such as C and Perl, have their issues with program structure and encapsulation, but Ruby on Rails (and other Web frameworks) have nothing to write home about in this respect: it is trivially easy to expose your system to breakage.

The thing Rails does right is to help ensure that such changes don't get pushed out to production. That's the test-first methodology. The thing it does wrong is a feature: the use of English language part-of-speech heuristics to create mappings amongst the MVC components. It gets it wrong about 10% of the time, that is to say, I get it wrong but the framework makes it easy to do so and hard to spot the location of the incorrect guesswork.

I'd rather not have to keep fixing the 10% or so times when the heuristics don't match the way I want to phrase the solution. But heuristic gaps are correctable; the persistent itch is that the framework wants to tell me to stick to a formula but hides all the wiring that would tell me where and how I'm crossing the lines, and translates tiny errors into epic fails.

A System That Uses HTML Is Not A Hypertext System

MVC frameworks are not really Web application frameworks but application frameworks that utilize the syntax of Web technologies to communicate. That is not easily correctable by slight alterations in practice.

State representations and transitions in a Rails app are all wired up through explicit code. Each entity is identified by a row number and associated by integer relations (this management strategy is reminiscent of DBase, but what "relational database" means and how Rails isolates the database layer is another discussion altogether). MVC uses views that spit out markup, but in themselves, views do not comprise state representations.

The RESTful Web uses links to stepping through the state space, and delivers markup documents that embody the current state representation along with the transition paths. That takes a kind of markup calculus to implement. Although Rails attempts to derive MVC patterns and hides a lot of its complexity in convention and meta-programming, there is an essential difference in the level of logic at play in the reduction of a solution.

A url format does not makes a system RESTful. A framework that stores almost all but not quite everything in sessions, and wires up features in point-to-point coding is doing what amounts to a Web algebra. That is very un-RESTful. Rails is on the top of the MVC heap, but what MVC platforms do is a little of the wrong sort of bespoke calculus mixed with a lot of idiomatic algebraic logic.

Bottom Line

MVC platforms are more than a slight inductive mismatch to the RESTful archetype. In my humbler opinion, REST requires a comprehensive markup calculus to accomplish. An effective REST platform should provide comprehensible algebraic representations and coherent integration and derivation techniques that do not require nail-up code to implement, conventions not withstanding.

No comments: