Halogen Labs Weblog

This layout needs to go. See those links to the right (if you’re reading this on the site)? Worthless.

I know Google loves the link juice. The site’s too narrow.

Lately, I’ve had the need to sort ActiveRecords by a certain attribute, but the order is completely arbitrary, and supplied by the user.

Take, for example, the following call to a model in Rails:

input = %w(MN CO TX CA)
State.find_by_state_code(input)


This generates SQL that looks something like:

SELECT * FROM states WHERE state_code IN('MN','CO','TX', 'CA')

state_code
----------
CA
CO
MN
TX


Seemingly random results (actually alphabetized, but still worthless to me), but I have a specific requirement to process the results in the order the user specified (MN CO TX CA).

We can solve this by using Array#assoc to build a simple index of States and their codes:

input = %w(MN CO TX CA) # user-supplied
states = State.find_by_state_code(input)
states.map! { |state| [state.state_code, state] }
# states now looks something like:
# [["CA", #<State state_code="CA">], ["CO", #<State state_code="CO">], ["MN", #<State state_code="MN">], ["TX", #<State state_code="TX">]]


Now we iterate over the user-supplied list, and use assoc to pluck out the state that we want:

input.each { |s| puts states.assoc(s).last.inspect }
#<State state_code="CA" ... >
#<State state_code="CO" ... >
#<State state_code="MN" ... >
#<State state_code="TX" ... >


Previously, I was doing some ugly mumbo-jumbo with creating a hash, but assoc is a much cleaner solution. This also allows me to stick to using the SQL IN() operator, instead of iterating over the user input and doing a single call to the database, which obviously gets expensive.

This sort of reminds me of a Schwartzian Transform, although it’s not exactly the same.

I found this little nugget while surfing the “Selling Agile” Yahoo group (My emphasis added):

Lean/Agile is at it’s foundation, the fourth industrial paradigm, the first being Craft Production, Factory Production with machine tooling, Automation and Taylorism. These come along every hundred years or so and take a few decades to work through. Each paradigm includes the preceding one and makes it dramatically more productive.

There is no need to sell agile except to organizations that want to survive long term. If they don’t see the threat/opportunity they cannot succeed with agile or lean nor can they sustain economic viability in the long run.

I recently got the following email from Apple, asking for 15 minutes to fill out a survey:

Apple Customer Survey

————————————————————-

Help us develop better products for you.
Please complete the Mac survey.

Thank you for your purchase of a Mac computer. Please take a moment to complete a fifteen minute survey to help us understand how to better meet your needs.

Your responses will remain strictly confidential and results will only be viewed in aggregate.

To take the survey, click on the following URL or copy it into your Web browser: [url removed]

Thank you for your participation.

Now, why should I fill out a survey you dumped into my INBOX? The email you sent provides no benefit to me, besides helping you develop better products for me. Where’s the reward in that?!

15 minutes is 15 minutes I could spend working (or blogging about an annoying survey email!). Without any incentive to fill out the survey, why would I even bother?

Update: I took the survey and they didn’t give me a single stinkin’ thing.