Pragmatic Geek

It’s so easy to let our web app performance degrade as it evolves, each architectural decision and framework adding a nearly imperceptible bit of overhead to the process until eventually people start asking “when did it get so slow?” After a while, we’ve reset our expectations of what “fast” is.

I’ve been tinkering with the simplest use cases to remind myself of how fast things really can go, and it’s worth a reminder of our various orders of magnitudes. When we talk about requests/second from a single machine, what makes us happy? 10′s? 100′s? or 1000′s? These days, we’re dealing with multicore processors, each running gigahertz clocks. That means 1000′s of requests/second is still granting us millions of cycles per request. That’s a lot of instructions! [1]

On my 2+ year old laptop, Apache serves plain files at 1000 files/second. I can also get it to dynamically render a web page with a database query result at the same rate! [2]

That’s an interesting reminder of how fast things can go. Maybe it should cause us to pause and consider all our beloved abstractions and whether they are really helping us, or are they just helping us mask the inadequacies of an earlier abstraction?

[1] Yes, I know cycle != instruction, but I’m talking about orders of magnitude.

[2] I’m getting contention between JMeter and the server itself, so those aren’t upper numbers. I’m also getting benefits of OS-level IO caching.

I’ve seen various posts that describe what it means to be “on rails” but none that actually address actual physics of it, and why it’s such a perfect metaphor for what Ruby on Rails is.

Why do trains stay on their tracks? Contrary to popular opinion, it’s not the flanges. If it were the flanges, there’d be lots of wear and noise by passing trains. Instead, it’s because treads of the wheels are tapered, and this taper causes the wheel pair to naturally “hunt” for the center of the rails. Richard Feyman explains it quite well on YouTube. Or for even more detail, read about rail adhesion on Wikipedia.

I like to think of the Ruby on Rails framework as the software equivalent of the taper. The conventions that are built into RoR continually drive us back towards making a maintainable application, with good separation of model, view, and controller, test driven development and rich testing frameworks, and the rich ecosystem of gems to avoid reinventing the wheel (pun intended) in common features of applications. Add in some DRY (Don’t Repeat Yourself), and the bevels increase, and the result is like having the two rails turn into a V-groove that your application just rolls smoothly down.

I’ll go even further (and abuse the metaphor) to compare other platforms to the rails. Java is like a railroad without any taper, and it depends on the flanges to stay on track. Java’s flanges include the static typing and the multitude of frameworks that try and help make a better flange (Spring, Struts, Hibernate, J2EE, etc). And oh, does it make a lot of grinding noises!

But thank goodness for the open source community creating all those flanges faster than the Java train can derail, because the .NET world is like a a railroad with the bevels getting wider toward the outside, which is a terribly unstable configuration. (I wish I could find the video I have such a vivid memory seeing as a child (PBS?) showing the comparison of the conical configurations). Sure, really good engineers can create a workable train route, but it’s just too easy for an inexperienced developer to create a train wreck from all the wizards.

RoR is the first framework in my 18+ years of server-side web development that makes me regret all the flanges I had to make in the other frameworks. Thank goodness for those tapers!

All Aboard!

Whenever I start a new web application, it seems that there’s a fair amount of reinventing the wheel in terms of navigation and UI structure. There are tons of tools to help with the individual widgets on the page, including JQueryUI, ExtJS, Dojo, to name a few. They all offer buttons, dialogs, accordions, tabs, etc, that make up the page. Some have built-in layout managers, others leave it to you do separately, in which case you can roll your own, or base it on a grid layout like Blueprint CSS.

However, I haven’t come across a unified package that takes a well documented and rational approach to laying out the elements of a rich application. A framework would help you through questions like:

• How to navigate between modules of the application
• How to provide “grounding” (inform the user where they are in the app)
• where to place “action buttons”
• When to use sidebars, tables, portlets, etc

• Be well documented
• Include helper methods for the views/controllers to work with
• Be flexible enough to support the uniqueness of the actual app
• Integrate with Rails

Well known application suites have already figured all of this out. Whether it’s Atlassian (Jira, Confluence, Bamboo), 37signals (Basecamp, Highrise), or even Google’s suite, there is obviously something internally leading the consistency in design and layout principles.

It seems this would be a natural fit for Rails. For all its reputation as opinionated software, there should be a gem for opinionated application design that provides all the features above. There are things like web-app-theme, but they don’t really help you understand what to use when.

What’s out there? Or why isn’t there one? Drop a line to deafgreatdane@gmail.com, or leave a comment.

Often, an app’s models need a lifecycle, transitioning between different states according to different business rules. The leading contender for abstracting this is the state_machine gem for Rails. (There are other options too, but not as rich.) It allows you to create a finite state machine on top of ActiveRecord, including all the goodness of events, constrained transitions, and many others.

As much as I believe the code should be legible enough for easy reading, sometimes a picture is a worth a thousand words. This gem comes with GraphViz integration, enabling to you create visual representations of your state machines. (GraphViz is a tool for turning textual descriptions of directed or undirected graphs into pictures) This feature is almost a footnote on the gem documentation, but it’s the killer feature for any skeptics that might be tempted to roll their lifecycle management code (usually by a simple “state” string in the model).

The picture to the right is generated with the following command:

rake state_machine:draw CLASS=Vehicle

That’s all pretty nifty, but what if you need an even fancier picture? OmniGraffle to the rescue! The mac’s über diagraming tool can import graphviz files directly, so it’s just a matter of calling the rake task with the right FORMAT, and opening it:

rake state_machine:draw FORMAT=dot
open -a /Applications/OmniGraffle\ 5.app Vehicle_state.dot

And now you can make graphic changes to your heart’s content. My tinkering for a few results in the image to the left.