AWebFactory
Thorough critique of Chapter 5

Home Page |

First of all, let me state, I’m plum happy the AWDWR book was written. Why else would I go without pizza 3 nights (Argentine instantiation of pizza)? Without a book like this all of us would be sunk. So much thanks to its authors.

(Of course, there is the lingering question of the Java Tutorial always having been free on-line as well as available in commercial hard-copy + CD, so why…? But I suppose Sun gets their pound of flesh anyway…).

So where am I coming from? I have said I am a refugee from J2EE. First of all because EJB has been up till now the biggest flop in framework history (you have to end up doing DAO’s (data access objects) and even stored procedures to get the performance you need on industrial projects, so… the heart of the application ends up being in the procedural code stored in Oracle; apart from the huge anti-DRY overhead).

Even promising “light” J2EE frameworks like Spring and Struts have an incredibly steep learning curve, and layers upon layers must be penetrated so as to be able to see clearly where the request flow really fits the model-view-controller pattern, something, on the other hand, crystal “ruby” clear and easy to explain in just a few words, for example, in the fourth chapter of the AWDWR book (and in our tutorial dealing with it here where it says “Object Soup revisited”, about half-way down the page). Ruby On Rails is an open book and you can always clearly see what you are doing.

As AWDWR states in Chapter 2,

“One of the joys of Rails is that this knitting process is based on the use of intelligent defaults so that you typically don’t need to write any external configuration metadata to make it all work. This is an example of the Rails philosophy of favoring convention over configuration.”

So Ruby On Rails is a breath of fresh air, in the host of free tutorials available on the web you can get the gist of it, and if you have ever used any kind of framework before, you are up and running; and if you are used to learning, or dealing with, new languagues, Ruby (especially because of its beautiful Smalltalk-like object-orientedness) is certainly no obstacle.

But also in Chapter 2, it is acknowledged that Ruby On Rails recognizes the fact that you need some kind of process, that complex Multi Tier Architecture is being dealt with, something you cannot just waltz into, no matter how Agile we may come to be:

“In the software world, we often ignore good ideas from the past as we rush headlong to meet the future. When developers first started producing web applications, they went back to writing monolithic programs that inter- mixed presentation, database access, business logic, and event handling in one big ball of code. But ideas from the past slowly crept back in, and folks started experimenting with architectures for web applications that mirrored the 20-year -old ideas in MVC. The results were frameworks such as WebObjects, Struts, and JavaServer Faces. All are based (with varying degrees of fidelity) on the ideas of MVC.”

All well and good. And, it is only fair to point out that the book is mainly concerned with presenting Ruby On Rails programming gradually, and in a coherent order, and not in developing a project.

But this may result, in many cases, in quite some confusion on when developers finish the book and say, “OK, now, how do I use this for a real world Web App of my own?”

In other words, traversing that bridge between your project’s requirements and MVC and beyond, and arriving at a clear and concrete use of Rails as a great and easy-to-use framework is not an intuitive undertaking. The truth is that Object Oriented Process is required, whether on a full blown demanding, engineering level, or on an Agile level, or on any kind of scaled-down or informal level, but a process, nonetheless. In other words, planning, process and iterations: incremental development cannot be reduced to implementation alone. This is my main criticism of Chapter 5, it suggests that Ruby On Rails can somehow reduce everything to implementation by a magic application of the DRY principle.

Once you do cross that bridge, as expressed above, Rails is easy and intuitive to use, it is clear where to get at things. But without process, questions will and do arise, such as “Where does that piece of code go? In the model, in the view, in the controller?” Often the “piece of code” are snippets spread all over the place, and the result is slippery spaghetti, not your ball of mud. Or, when is the view top heavy with code that should be in the controller, and when should the controller delegate to the model.

And this is not a question of good style. It is a question of work that is going to be hard to debug and impossible to modify and maintain.

This is what I mean when I say that Ruby On Rails and Object Oriented Process are born at the hip.

Within this process, within each incremental phase, or iteration, you must have a bare minimum of the following, as proven by the AWDWR Depot app process in the book itself:

• Business Modeling
  At the very least, within what kind of environment will or does the system operate?
  What knowledge do we have of the client and his operations, out of which the requirements are emerging?

• Requirements Management (gathering, validation, verification…)
  Even though UseCases and Use Case Analysis are pooh-poohed as a way for consultants to charge more (well, it can happen…), this is recognized very clearly by the authors of AWDWR in Chapter 5 itself:

“Talking of getting feedback, let?s not forget to get some right now?let?s make sure our initial (admittedly sketchy) use cases are on the mark by asking our user. Assuming the use cases pass muster, let?s work out how the application will work from the perspectives of its various users.”

• Use Case Analysis
  And then “Dave speaking” pulls the web flow pages diagram out of… thin air. It’s and/or based on previous apps (having nothing to do with the requirements gathered in the form of the UseCases) or (more to the point) the result of an unspecified and hidden, and absolutely essential, process of analysis of the UseCases.
  This is completely hidden in Chapter 5: Where did the pages and the diagrams come from? They can only come from Use Case Realization, the method with which we dynamically map out the domain of objects capable of implementing all the steps specified in the Use Case Model (even if that model is drawn on a scrap of paper). We would then end up with some idea of an Object Soup that AnalysisAndDesign could allocate to classes, patterns, MVC.
  What seems clear is that these web flow diagrams, for the buyer and the seller, are really the Use Case in disguise.
  A better, clearer approach would be to use User Experience Storyboards to model the steps outlined in the Use Cases into User Experience Elements, on the one hand, and a Screen Navigation Diagram, a storyboard, on the other.
  This gives us perfect traceability from the requirements gathered from the client to Dave’s page web flow in Chapter 5, as well as a huge sigh of relief that we are actually implementing something that has to do with the requirements, and a method which we can reuse in confidence for other projects. And a huge Simpson “duh” moment of insight as we realize that we have put our finger on the missing link between the Use Cases approved by the customer and Dave’s web flow diagram.
  Another approach to bridge this gap, apart from User Experience Storyboards, and as we shall see in Depot App Process, where we make a synthesis of both approaches, is to use (elements of) the Robustness Diagram from the ICONIX pre-RUP methodology.

• Analysis And Design
  This is the static part, which will map the output of the Use Case Analysis work to the controller, model, and view classes in the Ruby On Rails app.

• Implementation
  Write the code (I was wondering when you were going to get to that…)

• Test
  Built-into Ruby On Rails, we’ll see how!

• Deployment
  Built-into Ruby On Rails, and the Environment we create for ourselves, and also connected to Configuration&ChangeManagement, a discipline affecting all phases of the life cycle.

• Project Management
  Here’s where the iterations get planned, or at least jotted down before being embarked upon.

I feel that AWDWR is a great book and extremely worthwhile; but to really apply its content to real world projects, it must be recognized that the worthwhile use of any MVC framework relies on the proper scaffolding of Object Oriented Process. The great thing is, Ruby On Rails really deserves it.

• Continue to Depot App Process
• Skip the damn process, take me to Fitting Depot Storyboards With Rails
• Back to Rad Rails Tutorials

Content Victor Kane (ProjectMaster) and awebfactory.com.ar
Email me at info at awebfactory dot com dot ar
Full content (RSS 2.0) and Headlines (RSS 2.0)