Ask for Help

Bulk geocoding: What to do if you're importing millions of rows into your database and you need to geocode the address for each? Geocoding services like Google or Yahoo will throttle your requests, or shut you off completely.

Some options:

• Download freely available data (such as the Census data) and write your own geocoding process (ugh).
• Pay for a geocoding service (potentially quite expensive).

Interesting Things

• One projects was having significant performance issues on their EngineYard production and staging environments. As it turns out, EngineYard's default memory threshold for Mongrel is very low; the Mongrels were exceeding the threshold after two requests, so Monit was constantly killing and restarting them. The moral of the story: check the thresholds on your apps deployed to EngineYard.
• One project had a requirement to send a lot of email. ActionMailer was sending the emails in the Rails process it was tying up app servers and slowing down response times. Enter DelayedJob which allows you to, somewhat predictably, delay jobs. The day was saved.

Interesting Things

• A few people are looking for an electronics recycling center that doesn't charge an arm and a leg. Word is there are centers that will take pretty much anything electronic in San Carlos and by the Fruitvale BART.
• Ruby 1.8.6 segmentation fault: A couple teams have had trouble upgrading to the Ruby patch to fix the recent segfault bug. XML parsing and SOLR seem to be the most common culprits. They're working with EngineYard to figure out the problems.
• On a related note, EngineYard is now the official maintainer of Ruby 1.8.6.
• A few Pivots attended an RoR outreach meetup at Orange Labs this past Saturday. Sarah Allen organized the event with a focus on introducing more women to Ruby and Rails. It was, by all accounts, a great success.
• After seven months, and much rabble-rousing, this patch, refactoring the definitions of through association classes to use composition rather than inheritance, has been committed. Let this be a lesson to you: persistence can pay off.

Ask for Help

Non-numeric primary keys: fact or fiction?

We have one project that has considered using non-numeric primary keys in their MySql database. Enquiring minds want to know if this is a reasonable idea. General consensus was no:

• It makes Rails unhappy.
• It might make plugins unhappy.
• It might be slow (some debate on this; searching on an indexed string column is reportedly equal in performance to searching on an indexed numeric column in MySql).
• The benefits are unclear.
• Just don't do it. For reals.

A while back I made the point that the HasOneThroughAssociation class in Rails shouldn't be a subclass of HasManyThroughAssociation. I also submitted a Rails patch in which I changed the superclass of HasOneThroughAssociation from HasManyThroughAssociation to HasOneAssociation and moved the shared Through functionality into a module. Despite support from the teeming millions, Rails core team member Pratik rejected the patch for being "just a refactoring."

The concept of flow holds a mystical, holy place in the lore of software development. Nearly any programmer can tell you about being "in the zone," totally immersed in code, oblivious to the passage of time. Countless programmers have cited this apparently hyper-productive state when stating their need for enclosed office space, separation from their colleagues, working from home, working at night, or any other similarly isolated work situation.

I'm not going to dispute the existence of a flow state; I've experienced it myself. I know the feeling of looking up after solving an interesting problem to find that fourteen hours have passed, it's the middle of the night, and I haven't eaten anything since the previous morning. I've felt the satisfaction of burying myself in ideas until finally finding a way to convert them into code.

However, I will suggest that working in isolation in order to promote a flow state is not the most productive way to write software. It's better than working in an environment filled with distractions unrelated to the task at hand, but less productive than working in a collaborative space, or pair programming. To illustrate this, consider another, simpler task that also often involves working in a flow state: cruciverbanalysis.

I'm not sure a person can name a law after himself, but if I had a law I would want it to be this:

Any non-additive change to non-test code that causes no test failures is a valid change and does not reduce the correctness of the code.

I recently published the article There is no Agile, in which I stated that the principles of 'Agile' are nothing more than "a collection of good ideas, based on years of collective experience, for improving how we do our jobs." As an example, consider testing. Thorough testing is a ubiquitous principle of 'Agile;' thus, by logical extension, writing tests is a fundamentally important part of writing software well.

In short, if you write software, and you're not writing tests, then you're not doing your job.

There's a reason you don't stick your hand into fires, walk into traffic, or use Windows Vista. Humans, along with pretty much every other organism with a central nervous system, have evolved fear as a defense mechanism that protects us from doing things that cause us pain. We can override this to a certain extent, but fear is instinctual and basic.

On occasion, someone will ask me what I do or, more commonly, ask me what Pivotal does. The title on my business card says "Agile Developer," which nearly inevitably leads to one of a few reactions, almost all of which boil down to this:

"What exactly does Agile mean?"

You know what? It's a good question. And, after thinking about Agile for several years now, here's my answer: Agile originally was, and still is, a marketing term.

Allow me to explain.

With the recent holidays, along with a hint of flu season, things have slowed down a bit, and I've finally had some free time to go back and watch a few of the talks I missed at RubyConf this year (recordings are available here). Notably, I also took the opportunity to re-watch Jonathan Dahl's talk on Aristotle and the Art of Software Development. For anyone who missed it, I highly recommend you check it out. It was, in my opinion, one of the best talks of the conference.

You may be wondering what philosophy has to do with writing software. Watch the video. Listen to what Jonathan has to say. I believe fairly strongly that questions of how we think, how we communicate, how we interact with one another, etc. will become increasingly, and overshadowingly, important as the software industry continues to grope its way toward some sense of what it is we're all doing, and what it means to do it well.

How many times has this happened to you? You get a cool design for your website, and you spend a bunch of time lining up all of your images and roundy-corner widgets and input boxes just... so..., and everything looks great. But, then you submit a form without typing in your favorite ice cream (a required field, of course), and suddenly your layout is splattered about like an extra large scoop of rocky road in the hands of a two year old. It's enough to make you want to stab your eyes out with a hedge trimmer.