Spotlight update

I've deployed some new code for the spotlight app, which you can find at http://spotlight.heroku.com. I'd like to point out two updates in particular: There is a new Javascript parser thanks to Fred and I've changed the html rendering scheme to allow you to highlight the code without highlighting the line numbers as well.

What makes a pattern?

Every Tuesday the Obtivians have a lunchtime gathering at our Chicago office. These gatherings are pretty informal and usually start off with a few folks presenting technical topics followed by the general sort of heckling and mischief that you'd expect a room full of guys to get into.

This last Tuesday found us with no one prepared to present a topic, so we broke off into small groups and quiet conversation. I sat down with my lunch among a few of my colleagues and engaged in the conversation they were having. About exactly what I can't remember now, but trust me - it was geeky.

I finished my lunch as the conversation wandered toward design patterns and Ruby on Rails. I made the casual comment that I thought it was a bad idea to name a framework after a design pattern (Rails ActiveRecord, I'm looking at you) and that sparked a furious debate.

My argument was that somewhere along its evolution ActiveRecord the framework ceased to incorporate Active Record the pattern as it had evolved into a Data Mapper which eventually became a full ORM framework, having heritage in the Data Mapper pattern . Thus rendering the name "ActiveRecord" quite misleading if you're familiar with the PoEAA definition. A few of my colleagues believed otherwise.

However, the core of this debate and the topic of this blog post is not about the implementation of ActiveRecord. It is about what defines a design pattern in software and how you identify code that implements a particular pattern in the field. So let's get to that, we'll finish the debate later.

I'm fairly young as programmers go, but I've read most all of the current literature on patterns as well as having the opportunity to work with some truly exceptional individuals. So while I may not be prepared to give a three day lecture on the topic I do believe I've formed some worthwhile opinions.

My belief is that a design pattern in software is defined by two things: The particular problem the pattern addresses and the manner in which that problem is addressed. In my mind the interface, the UML diagram, and the implementation in code that often accompany the patterns in a book have very little to do with the definition of the pattern itself. All of these things are the artifacts of one specific implementation of said pattern. If you read the GoF book carefully you'll find that they point this out directly. They warn us against misinterpreting the examples as the literal pattern. A lot of us didn't listen very well.

Patterns are conceptual entities and that can make them especially difficult to grasp for the newcomer. Examples help with this, I get that. However, the unfortunate side effect being that these early students often latch on to the well-meaning examples and miss the underlying concept of the pattern itself, the one thing that really matters. Even worse, it can take a long time to get out of this rut.

What I try to do is identify what makes a pattern's solution conceptually unique among its peers. Let's take PoEAA Active Record versus Data Mapper, which was the topic of our debate. An Active Record is a simple row-level representation of a table in a relational database. What makes it unique is that the data to be persisted and the logic that handles that persistence all reside inside the same object - the Active Record.

In contrast, the Data Mapper creates a separation between the data and the logic that persists it. How that separation is achieved, to me, is unimportant. How I interact with the persisted object is unimportant. The UML definition is unimportant. What is important and what makes Data Mapper different from Active Record is the separation of the data to be persisted and the logic that handles that persistence (yes, I said that twice). That is the essence of Data Mapper.

Therefore, Rails' Active Record is more of a PoEAA Data Mapper than it is a PoEAA Active Record.

Now let's entertain the counter argument for a minute. What if a pattern is defined by the way in which you interact with it (its interface). And what if we apply that to patterns we see in another field, say architecture?

In your lifetime, how many thousands of doors have you interfaced with? How many of those doors had the same interface? Not many. The doors in my house have a knob to engage the latching mechanism and a hinge at one side, but the door to my garage curls up over the cars on rails when I push a button. The door at the grocery store moves out of my way automatically.

Are we wrong to say that all of these things are Doors? That there is One True Door and all other impostors must be called something else? Of course not, that's silly. Why? Because the concept - the pattern - of a door has nothing to do with its interface, or the materials it is made of, or its picture in a book. A door is a conceptual thing. If I was to define Door I would say it is "An easily removable barrier between two spaces".

What I really want to know is how each of you feel about this? What defines a pattern in your mind? Please, leave a comment.

Pretty code snippets for the masses

In my last blog entry I pointed out a tool called Coderay for generating syntax-highlighted html for blog posts. Two train rides later and I've launched an application that should make life a whole lot easier for folks who want pretty code on their blog.

I give you Spotlight:

http://spotlight.heroku.com/

In other news, heroku is awesome.

I can stop whining about syntax highlighting for my blog

I've been googling off and on in what turned out to be a rather futile attempt at figuring out how to get the cute syntax highlighting you see on a lot of the major rails blogs working. Via The Rails Way I discovered the feature was apparently related to Mephisto, for which I promptly downloaded the source.

A few minutes later I found what I was looking for:

http://rubyforge.org/projects/coderay/

Debugging ERB Rendering In Rails

I had a helluva time figuring out that attempting to output a scriptlet that begins a block segment causes ERB to generate bad ruby code. Here's an example:

1 <%= tag_with_body do %><%end%>

What I really needed was a way to dump the generated ruby code from ERB. Turns out you can. On the last line of my controller action I added the following:

1 puts @__erbout

will_paginate remotely

I've patched the awesome will_paginate plugin from Mislav Marohnic to support rails' link_to_remote helper. Now you can easily tell will_paginate that it should update an element in the DOM instead of doing a full request cycle:

1 <%= will_paginate @pages, :update => "story_box", :params=> {}%>

I submitted a patch to Mislav, but I can't tell you when or if it'll get into the official release. For the more adventurous hackers out there here's a messier but more concise version of the patched code:

monkeypatch the page_link_or_span method in will_paginate/lib/will_paginate/view_helpers.rb:

 1 def page_link_or_span(page, span_class = 'current', text = nil)
 2   text ||= page.to_s
 3   if page and page != current_page
 4     if update = @options[:update]
 5       @template.link_to_remote text, :update => update, :url =>    url_options(page)
 6     else
 7       @template.link_to text, url_options(page)
 8     end
 9   else
10     @template.content_tag :span, text, :class => span_class
11   end
12 end

Spring IOC in JRuby - life outside the container

If you're a JRuby aficionado you probably read about the Spring IOC Plugin for rails, but what if you want to get spring IOC running outside a servlet container? Here's how.

Now, the first important thing I learned is that spring uses the Java Thread's context class loader to load its resources. If you're using JRuby's $CLASSPATH to set up your test environment this poses a problem. So, first thing I override the current Thread's context class loader at the end of my test.rb environment file:

require 'java'
require 'jruby'

java.lang.Thread.current_thread.context_class_loader = JRuby.runtime.getJRubyClassLoader

Now we can move on to Spring. We can't use the WebApplicationContext that the Spring plugin uses because it'll (obviously) complain that there isn't a servlet context. So let's fall back on the ClassPathXmlApplicationContext. Add this wherever you'd like to hook in and replace the spring context from the plugin:

config = ["classpath:applicationContext.xml",
          "classpath:applicationContext-service.xml"]
ctx = ClassPathXmlApplicationContext.new(config.to_java(:string))

And there you go! Provided you've configured the $CLASSPATH correctly you should be on your way.