urgetopunt technologies

Open Source Bridge — Day One

Amber Case on our gradual transition into cyborgs. Very funny talk. I wouldn’t normally think of myself or any of my fellow human beings as cyborgs, but when you stop to think about the gadgetry that we keep on our persons at just about all times nowadays…

Kurt von Finck and the “hacker business model”. What if, instead of specifically asking employees to put in 7.5 hours a day, you asked them to put in 75 hours every two weeks? It’s an interesting idea. While many programmers do their best work with fixed-width, evenly-spaced work shifts, others thrive on binge coding. Perpetual binging is unmaintainable, but with nice, long breaks between sprints, it can be quite productive.

J. Chris Anderson presented Deploying to the Edge from CouchDB. A good overview of CouchDB which seems to get more and more attention these days. CouchDB is not a traditional relational database but rather a document-based database. It’s written in Erlang and communication is based on HTTP and JSON. Among its most appealing features is its capacity for distributed and even embedded operation. It has enticing potential for offline applications.

Scott Becker spoke about Agile Javscript Testing. Informative presentation on a topic on which I really need to get up to speed. He demonstrated Screw.Unit, a BDD framework inspired by RSpec. He also demonstrated Blue Ridge, a Rails plugin which combines several Javascript-testing tools (including Screw.Unit) and paves the way for integrating Javascript tests into the rest of the test suite for Rails applications.

There were some promising sessions in the afternoon schedule, but, tragically work beckoned and I spent the better part of the afternoon on the computer.

The Importance of Being Specific

Do not do this in your .autotest file.

Instead, be specific.

One of the benefits of autotest is that it can save you time. It’s not saving you time when you spend 15 minutes trying to figure out why it isn’t running any of the tests from vendor_controller_test.rb. Be good to your tools, and they will be good to you. Tell them exactly what it is you’d like to do, and they will be happy to oblige. Read the documentation about a feature when you use it — then maybe you’ll realize that a method actually expects a Regexp as an argument.

If you don’t read the documentation, you risk being a tool… Like me.

Refactoring Views for Clarity

I recently found myself doing some work on the views of an application I developed more than 18 months ago. As seems so often the case when looking at something I wrote long ago, I found myself somewhat dissatisfied with the way some of the code had been written. The partials I was looking at were DRY but long. In Ruby I’ve learned to extoll the virtues of shorter, more focused methods, and in Rails, by extension, I think these same virtues apply to smaller, more focused views.

The controller I was working on handled the usual RESTful actions for a resource named billable, but in addition to the usual suspects, the billable resource also had several custom collection actions named day, week and month. As you might guess from their names, they returned collections of billables by day, week and month, respectively. The base views were simple — they displayed a title and rendered a _billables partial which displayed a table summarizing the collection. The _billables partial was my primary concern as it had grown too long. (See the original code below).

I decided to address the problem breaking the _billables partial up. I created _head and _foot partials to display the header and footer sections of the table, and I created a _billable (singular) partial which displayed a row for individual billables. I opted to shed some of the original approach’s DRYness by replacing the one call to #render in each view with two calls for the _head and _foot partials and a third call for the _billable partial for the entire collection. (See these changes below).

While I am not necessarily wed to the details of this new approach, I do think the result is a net gain. There are more files, more lines of code and there’s more duplication. But I believe everything is clearer. I also believe the duplication I’ve added is unlikely to add maintenance headaches — it’s hard to imagine it changing in any way that wouldn’t require significant updates with or without the duplication. (As long as I am using a table to display the collection, I will have a header, footer and main body).

These are the partials I started with:

These are the partials I ended with: