Those of us who have been working in strongly-typed OO languages for a very long time – since, say, the GOF Design Patterns book was first published – learned not only OO concepts and the syntactic idiosyncrasies of our language, but also design patterns – commonly-accepted ways of solving recurring problems in our applications.

If you’ve been with Java over the years – say, from Java 3 to 4 to 5, you’ve seen the language evolve to include features formerly relegated to the domain of the design pattern. Java’s for-each loop is one such example – once that became a language feature, it was suddenly less important to know about the more generalized Iterator pattern.

Enter Ruby (and dynamic languages in general). It turns out that many of the design patterns in that grand old Gang of Four book were situational – they apply generally to strongly-typed languages. If there is one “metapattern” that describes most of the original design patterns, it is this: “Use composition rather than inheritance in order to introduce runtime flexibility into your designs.” Quite simple: object composition – relationships between objects – can be changed at runtime in a strongly-typed language like Java. Inheritance – the only other way of introducing externally-defined capabilities to a class – cannot.

In Ruby, the very nature of the language makes much of that line of thinking obsolete. Through its dynamic nature, Ruby classes can be modified programmatically, at runtime. This statement often scares the daylights out of a Java developer when it hits them for the first time. Upon closer inspection, though, this language feature can be used to great effect. Behavior and associated information can be ascribed to specific instances of classes based on the situation in which they find themselves. Imagine a Person object who happens to walk into a busy bank and gets into the back of a queue. In a Ruby system describing this Person, we could blend in methods like start_waiting and elapsed_wait_time? – and those methods could then be discarded later when the Person finishes its transaction and leaves the bank.

How might we have done this in Java? After all, situationally-appropriate behavior is not unique to Ruby – it’s a generalized concept that could be expressed in any language. In Java, where class behavior is fixed at compile time, we use a specialized form of composition. The Gang of Four called it the Decorator pattern. So we have a situation where an inherent language feature of one language (Ruby) completely obliterates the need for a design pattern that helped legions of OO problem-solvers in earlier languages.

It turns out that the evolution away from patterns toward language features is something that has been noted by many others. Suggested reading for those interested:

• http://designpatternsinruby.com/section01/article.html
• http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html

Just as a more or less holistic picture of this “new world” was beginning to form in my head, Adam Wiggins of Heroku published a very nice, quick-read “web booklet” – The Twelve-Factor App. It’s not deep, but does a great job of circumscribing the set of concerns one should have in mind when building an app that is destined to be deployed in the cloud.

If you are relatively new to cloud-based deployment of web applications, it may not be obvious that deployment to a cloud-based server should affect your application in so many ways (thread management, stateless processes, absolute separation of configuration data from source code, etc.). Build, deploy and manage an app or two, and you’ll learn some of these lessons the hard way.

If you do open source development (like Ruby on Rails), learning the hard way has probably become a way of life. Do yourself a favor and remind yourself how nice it is when someone takes the time to put up a few guideposts to mark your way, to keep you on the trail and out of the weeds (or over the cliff’s edge). Check out this informative site. You can get through the content in fifteen minutes. Thirty if you take time to let the points sink in a bit. You’ll save yourself a lot more than that if you use these concepts when you build your next hosted application.

Most of these features – closures, ultra-convenient collection-oriented operators like the spread-dot (*.), etc., are well-documented. Some, however, are a bit more arcane, and not realizing they exist can actually cost you a lot of time if you stumble into them inadvertently.

The feature I have in mind at the moment is a very convenient but somewhat surprising bit of collection behavior in Groovy. I’ve been working with the language for quite a while, and have dutifully pored over books and language reference documents to become familiar with all of the groovy goodness at my disposal, but somehow I missed this one until someone on my project team found it – quite by accident.

Here’s the magic find. In Groovy, if you have a list of objects, you can access, on the list itself, properties that belong to objects within the list. The result, somewhat intuitively (but somehow quizzical at the same time), is a list of values of that property across all the members in the list. Here’s an example to illustrate what I mean – just copy this and run it as a Groovy script.

class Player {
def name
def teams

public String toString() {
"${name} - played for ${teams}"
}
}

def players =
[
new Player(name: "Greg Maddux", teams: ["Cubs", "Braves"]),
new Player(name: "Ron Santo", teams: ["Cubs", "White Sox"]),
new Player(name: "Billy Williams", teams: ["Cubs", "Athletics"]),
new Player(name: "Bruce Sutter", teams: ["Cubs", "Cardinals"]),
new Player(name: "Lou Brock", teams: ["Cubs", "Cardinals"]),
new Player(name: "Gary Gaetti", teams: ["Twins", "Cubs"]),
new Player(name: "Ron Cey", teams: ["Dodgers", "Cubs"]),
new Player(name: "Ryne Sandberg", teams: ["Cubs"]),
new Player(name: "Mark Grace", teams: ["Cubs", "Diamondbacks"]),
new Player(name: "Goose Gossage", teams: ["Athletics", "Yankees", "Cubs"]),
new Player(name: "Sammy Sosa", teams: ["Rangers", "White Sox", "Cubs"]),
new Player(name: "Larry Bowa", teams: ["Phillies", "Cubs"]),
new Player(name: "Rick Monday", teams: ["Dodgers", "Cubs"]),
new Player(name: "Dave Kingman", teams: ["Rangers", "Mets", "Cubs"]),
new Player(name: "Joe Girardi", teams: ["Cubs", "Cardinals", "Yankees"])
]

def playerNames = players.name
println "Here, amazingly enough, is a list containing the names of all those players:\n $(playerNames)"

Once you know this behavior exists, it’s pretty easy to find situations where it’s an insanely convenient feature. If you don’t know it exists, you can get some pretty confusing results. In our case, we were running a GORM query to retrieve a domain object using an alternate ID (expecting a single result), and incorrectly used the list() method (we should have used get(), which returns the domain object, whereas list() always returns a list).

In our code, after querying for the domain object, we accessed properties of the object, and were puzzled when instead of getting Strings and Integers and Dates, we were getting single-member lists of Strings and Integers and Dates. Each list contained the value we expected, inexplicably embedded in a List instance. It took a little head-scratching before we figured out that the root cause was that our query was returning a list containing our domain object, and our code that accessed the properties, which would have failed miserably in Java if attempting to treat a List as though it were a domain object, was happily drilling through the wall of that list and getting at its contents.

Syntactic sugar? Definitely. Violation of the principle of least surprise? Maybe. Will I use it, now that I know it’s a tool at my disposal? Absolutely.

Stay Groovy, my friends…

But such peace of mind comes at a cost. I’ve heard estimates from various teams I’ve talked to stating that the cost of writing unit tests for adequate code coverage (usually 50% to 80% on Java projects) can range from equivalent to the production code itself, to five times that. The problem with these estimates, of course, is subjectivity. For example, if you have found a bug using a test and work to fix the test, are you mentally counting that time as test-writing or code-writing?

Estimating factors aside, the plain fact is that testing does amplify the cost of software development – at least in the short term. Which means that a software engineer who really cares about his customer’s bottom line should always be on the lookout for ways to avoid the increased cost of testing.

This line of thinking arose the other day on the project I’m currently working on. It’s a Groovy/Grails web application with some public, customer-facing components and some internal-use components. We’re using Grails scaffolding as much as is practical for the relatively infrequently-used internal-use features to save time and money. In most cases, we have generated and tweaked the UI components (GSP pages) to smooth over some of the uglier bits of scaffolded pages, but we have tried not to generate any of the controller code, instead relying on Grails’ generate-at-runtime approach by including def scaffold = true in these controllers.

Why not generate the source? Because generated code is deceptively expensive! The minute a feature springs into existence in your code base, it needs to be tested – even if that code was generated by a framework like Grails. And Grails controller closures – insert and update, as the case in point here, do a significant amount work for you. Data binding. Optimistic locking exception handling. Routing of validation errors. All things that “just work” in scaffolded code, but which might be broken by someone once the code actually becomes part of your code base.

So when the need arose to customize part of the logic in insert and update closures (to do some custom interpretation of a series of check boxes on a form that couldn’t be made to conform to the default binding mechanism), we began looking for ways to override binding logic without generating and modifying the closures themselves.

As usual, Grails has a solution at the ready – controller interceptors. All we had to do was declare an interceptor that fires before insert and update closures, and in that closure, inspect our list of check boxes and set a params value that would then be assigned to our domain object through the normal binding process.

By using an interceptor, we completely avoided the need to generate (and assume custodianship of) the insert and update closures in this controller – which means we didn’t have to spend valuable time writing unit tests to cover these Grails-supplied features that could be broken once the code actually exists.

I guess I can summarize this little victory this way: Having tested code for an application feature is far better than having untested code. Having no code at all is better than either.

Stay Groovy, my friends.

When I first started test driving the Magic Mouse, I happened to be in iTunes, and happened to need to adjust the volume – which is a horizontal slider in the UI. I thought to myself, “This mouse has the ability to do scrolling in any direction – I wonder what happens if I hover over the volume control and swipe right?” Bam. Of course it worked. It’s Apple, and they think of *everything.*

I was truly impressed. And, being an engineer and naturally inquisitive, I took notice that I was impressed – particularly by such a “little thing.” I then realized that I was impressed not despite the fact that this was a little thing, but because it was a little thing. The sort of thing that other user interface and hardware designers might well have missed.

Which brings me to the moral of this story. I work in a consulting firm, and our goal is not merely to meet our customers’ expectations, but to surpass them. In short, to impress them. I think that sometimes we find this hard to do. We need to remind ourselves that sometimes it’s just the little things we do – things that others might have missed – that will make the biggest impression.