1. Writing code well in a way that you could keep adding developers and they could each increase productivity linearly.
2. Writing code that will work for increasingly larger sites.
3. Writing code that is maintainable, testable, and extendable.

I know others have thought about this, some people call it “best practices”, some people call it frameworks, Yahoo even went as far as to create the YUI family of libraries. I think deep down, most people were trying to think about how to “scale” whatever it was they were doing.  This entry is the first in a series of writing jQuery code that “scales”.

Another thing I probably need to address before we get started is “Shu”. It comes from the Japanese phrase “Shuhari“, which I learned from Alistair Cockburn and is common in the Agile circles, and “describes the stages of learning to mastery”. Once you’re aware that there are certain levels of mastery of something, you start asking yourself which level you’re at and what level others are.

JQuery is awesome, and I love it. For along time, I treated javascript as a 2nd class citizen, but I’ve recently been really digging into it and making it “scaleable”.

In Dan Cederholm’s recent book, he introduces some jQuery that I’m lumping into the “Shu” box (ba-da ching!).

$(document).ready(function(){
$("#loc-adv a").click(function(){
$("#map").slideToggle("slow");
return false;
});
});

Now don’t get me wrong, this code is perfectly acceptable, especially for the situation it’s presented in (a small, static site, built by 1-2 developers). I’m all for not complicating things if they don’t need to be. This code is the simplest thing that could possibly work, and that’s awesome. However, we’re talking about scaling javascript up to larger sites, more developers, and maintainable in legacy applications, and there are some things about this code which don’t make it very scaleable.

First, it’s not really re-useable. Sure, you could include it in any page that has the `#loc-adv` a link and a map, and it’s going to work, but what if  you needed multiple maps in one page or had multiple links. All of a sudden, you’re going to need to repeat yourself, and we don’t do that.

Second, if you put this right in your page, as it’s presented in the book, you can’t use it on other pages without repeating yourself. Maintaining this code could be painful if you put it in more than one page.

Third, the only way this code is going to fire is if you click the link. There’s no way to call it from other code, or test it, and you’ll have to attach it to multiple elements if you add another link or some other element that needs to reveal the map.

What if you want to link to the page with the map open? This code won’t account for that.

I’m not going to address all these issues in this post. I’m going to leave that up for the “Ha” and “Ri” posts. Look for them in a couple days.

I’ve had this technique validated by my former boss Ward Cunningham. He (famously) worked with Kent Beck at Tektronix and they were research partners. During this time, they came up with lots of really great ideas, design patterns, and methodologies. And the technique they used for exploration went something like this (paraphrased from Ward):

Kent and I would get to work in the morning, and we’d just start writing code. If it went well, we might right code all morning and maybe all day. If it went really well, we’d work on the same project all week and get something great out. Usually these ideas then got turned over to other teams to keep working on.

But usually, these ideas didn’t work out very well. So we’d stop at lunch, throw it all away, and work on whatever we were supposed to be working on.

The next morning, we would both show up and Kent would usually say “I have an idea on that thing we were working on yesterday” and off we’d go.

Great things came out of this, TDD, some notable design patterns, and really XP.

The thing that holds me back from doing this more, is that frankly, it’s a pain in the ass to get all the basics in a rails app installed. Just to do anything, I usually like to have Rspec, rspec-rails, cucumber, authlogic, jquery, 960gs, and a handful of other plugins and libraries installed. They all need to be configured, databases need to be set up, etc.

Worst of all, most things need authentication, you know, so that you can actually have users. That means you need sign up, login, activation, password resets, emails, the list goes on.

Where am I going with this? Well, the ability to generate rails apps via custom templates was added in Rails 2.2. So I took it upon myself to stop shaving small yaks every time I wanted to hack on a new project and shave a big one. I present, the science department rails template.

rails my_app -d postgresql -m http://github.com/BJClark/rails-templates/blob/d8889e1c771847f75641503e478c130e959e1686/scidept.rb

Run this little command, answer 3 questions, change 1 line of code, and run

 rake spec && rake features

You now have a fully implemented and tested, rails/rspec/cucumber/authlogic/resource_controller/lesscss/jquery/960gs app, with signup, login, and password resets, checked into git and ready to hack.

Hack, fork, and profit!