Absolute BS

My wife is taking an online class that has a requirement that she make some number of forum posts on their blackboard. This is not uncommon for online classes to encourage participation. The ridiculous part is that she is required, at the end of her post, she needs to include the number of words she wrote so that the instructor knows the post is long enough. So she ends up launching Word and writing her post over there so she can use the word counter over there to make sure she gets all her words. So I thought I’d be nice and write a little bookmarklet that does this for her:

Word Count

Drag this link up to your bookmarks bar and click on it and it will tell you the number of words you’ve typed into all of the text areas on the page. It reports the count back using the internal name of the field, but that will usually be enough to figure out which field you’re typing in. It also counts the number of words you have selected in the web page, just because its easy to do. I hope this helps somebody else out there meet arbitrary post length guidelines.

Either that or programmers are lazy. I’ve been working on an App at work that requires internationaliztion, and until you get used to doing it, its very easy to let strings just leak through. I just installed Google Chrome, and right there on the first prefs page is a whole slew of I18n bugs:

They missed a translation and another couple don’t fit in the space and just run off the page into oblivion. These bugs are annoying to fix, but at least they are easy to find: Just change the locale on your computer while you develop. Only one person on the team really needs to do this.

I have my computer’s language set to spanish, so I notice these problems right away while testing, which is certainly something you should do for at least a round of QA before you ship, but preferably while you develop. You can make it fun if you write a pirate locale or something, but you should absolutely be running your app in a language other than english before you can even come close to calling it finished.

I’ve been developing rails apps for over a year with Six Fried Rice, and we’ve been using ExtJS as our Javascript framework. As is quite common in industry, we’ve developed internal libraries for Ruby, Rails, vanilla Javascript, and ExtJS. When I used to write Java, we would have our shared libraries in separate source control projects, package them up as JARs and just distribute binaries, which we would check in to each project that used them. This worked fairly well because of 2 important reasons:

1. Our libraries were mature
2. They could be developed independently of a certain project

Number 1 is nice because the libraries don’t need to be updated often, so you usually only needed to spend time getting them set up at the start of a new project. Number 2 was true because our libraries usually revolved around authentication/single sign on and they were maintained by an entirely different group in IT. This is more typical of large enterprise development.

So when I wanted to do something similar for our rails/js libraries, I initially turned to gems and plugins. Either of these solutions would work fine for our modifications to Ruby, and we do currently maintain 2 internal rails plugins that handle our ruby convenience methods and also some changes we’ve made to rails (that haven’t made it into core rails yet….). We keep those plugins in separate subversion projects, and everything work great.

Now enter Javascript. We write lots of javascript. Many times as much as we write ruby. The Javascript also tends to be dirtier than ruby, and we run into a lot of problems that are much harder to reproduce so I usually prefer to test changes to the libraries in the context of the applications that use them. This JS code is also very immature and changes frequently, often daily. The traditional method of developing a library on the side and updating it occasionally breaks down for this case, so the situation for the JS libraries is the opposite of the traditional way I described above:

1. Immature code that changes frequently
2. Development depends on applications that use the library

It turns out that there is a nice property that is supported by subversion called externals. This allows you to set a directory in one repository to link right to another repository. You can make changes to the library right there, commit it back, and then go run update on a different project and it will go grab the changes. This is perfect, except for one thing. Say I branch off of trunk to write a big new feature that ends up adding a lot of code to the Javascript UI library. This branch may take a few weeks to finish and the whole time I’m committing new code to the javascript, which gets propagated to trunk everytime I update, which could certainly introduce bugs that we might not want in other branches.

This leads me (finally) to the point of this post. I solved this by writing a rake task to “freeze” and “unfreeze” the library. When it is frozen, the library just stays at a version we know to be stable. When you want the latest code, or if you need to make changes, you unfreeze it and test. We’ve been using this solution for a few weeks now and its works really well, so I decided to post the rakefile that handles installation and freezing of a javascript library, called ‘jslib’ by default.

external_js_library.rake

Now I can do cool stuff like

rake jslib:freeze

which makes sure that the library stays at whatever version it is at right now forever, or until I issue:

rake jslib:unfreeze

which sets it back to HEAD and updates. I don’t think this is a replacement for gems/rails plugins, but it does a very good job of handling our shared javascript library. Thoughts?

Copied from an email. I’m just going to stick this here for a while just in case I need to point at it in the future