Despite rapid tool advances and cheap hosting, deploying and maintaining a production Web application is labor-intensive. The labor overhead grows with each new application you deploy. This overhead constitutes an drag force on innovation for small teams. The problem is especially acute for the solo entrepreneur.
I'm sharing some of my recent work on the problem and facilitating today's Streamline Multi-Application Maintenance with One Big Rails App O.B.R.A. session at 1PM at BarCamp Portland 2009. The O.B.R.A. is an approach that aims to remove that drag force. I'll outline the approach and describe a Ruby on Rails 2.3.2 plugin (Bill/merb_routing) that makes things easier. Come and join and bring your experience and opinions.
In integrating The Mighty Dan Webb's code highlighter on this site I was faced with a familiar task: developing a stylesheet to match the current site style. As I was groveling around for the original Photoshop compositions and stumbling through the CSS it occurred to me that it would be really handy if the site had a "swatches" page. You know, just a simple page that displayed the swatches for the current color theme. Each color would have it's CSS color value and other little things readily accessible and ready for cutting and pasting into new code. So I made a swatches page:
It made developing the highlighting styles easy but perhaps no easier than a swatches page in Photoshop would have. The real value of something like this is accrued next time, and the time after that.
You see, next time I won't have to look for the swatches because they are baked in to the site. And if the site colors change these swatches will too because they are dynamically generated the same way all the site colors are. This is an example of what Richard P. Gabriel, in Patterns of Software, calls "habitability":
Habitability makes a place livable, like a home. And this is what we want in software—that developers feel at home, can place their hands on any item without having to think deeply about where it is.
Habitability is perhaps most readily achieved in a controlled, closed environment. Gabriel is one of the original LISP hackers and cites examples from that ethos often in his musings on habitability. LISP is sort of the ultimate closed environment when it comes to programming languages.
It's at the edges of our software systems where habitability can be the hardest. The interfaces. The interface between our software and the graphic design is a paradigm. That space, between our CSS and our Photoshop compositions and our browser compatibility and our programming languages is fraught with rabbit holes, big carnivores and super bugs. Where are the connections? They're juggled in our heads. By bringing more of the graphic design into the actual software product, and reifying the pieces in our programming environment we move the software system edge to encompass more territory. By expanding that perimeter we can spend more time inside our nice cozy, efficient, habitable environment. Ah.
I've been on a bit of a CSS quest lately (think Jason, Argonauts, white whales). Inspirations include Nicole Sullivan's larval Object Oriented CSS and Chris Eppstein's Compass. Like the lion an the tin man each has its strength but they really need each other. It's encouraging that Chris answered my recent plea for philosophical coherence by actually implementing an experimental OOCSS pattern in Compass.
At the core of Compass' goodness is Syntactically Awesome CSS or SASS. The big thing about SASS is it gives CSS real programming language features like variables and expressions and macro substitution. That stuff is critically important. I remain on the fence however as to whether we need another programming language (SASS) to achieve it. Right now, instead of SASS this site is using Ruby ERB templates to render its CSS (dynamically).
The value of this approach is there's one less language to learn if you already know Ruby and ERB. The downside is that the ERB code might be a little more verbose than the equivalent SASS. Here's an example:
.button {
background-color:<%= @c_a %>;
color:<%= @c_a_w4%>;
border:1px solid <%= @c_a_k4%>;
}
You can see that we're using plain old Ruby variables to define our CSS colors for a button. The equivalent SASS wouldn't have the ERB goop around the variables but I'm willing to pay for Ruby's familiarity and power with a little extra goop.