The Sweet Spot
On software, engineering leadership, and anything shiny.

Backup, backup, backup

Well, the inevitable happened: I finally experienced a hard drive failure. It’s pretty incredible that in the twenty-odd years I’ve been around computers I’ve never had the horror of losing a drive.

Friday rolls around and my Macbook Pro decides to freeze up on me. _Strange, _I think to myself. It’s making a clicking noise. Crap.

Luckily, I’ve been fairly good about making backups and copies of my work. Here’s my general strategy:

  • Work/code: keeping local changes on a separate branch and pushing it to a remote Git branch every so often.

  • Everything else: I keep one local copy here with me in Oakland, and have another copy offsite. I rsync my files out to my server at home, which has a cronjob set up to sync with the offsite copy at my parents’ home (I run a Pogoplug with Archlinux and a couple of external drives connected to it – fantastic and totally recommended for a cheap and low-power server setup).

There was a minor scare this time around though – I had some photography work (and an engagement photoshoot!) lying around that almost didn’t make it to the first stage rsync with my local server. Fortunately, I had the foresight to keep my photos backed up to a random local hard disk, and the rest remained on the memory cards (and some even on a shared Dropbox folder that saved my butt!). Most frustrating thing was learning that I had forgotten to back up my Lightroom catalog, so all my edits were lost. At least I have the original shots.

One thing I think I’ll try doing from here on out – saving my Develop settings/presets directly to the DNGs themselves before backing up. That way if I ever lose my LR catalog, the edit settings are still embedded in the original files.

Jeff Atwood reminds us to keep backups around on multiple disks. With the price of storage so low, what’s your data worth to you? How are you keeping your backups?

HAML object references

Did you guys know that you can use the ‘[ ]’ brackets in HAML to automatically set the id and class on a tag, kind of like Rails’ tag helper?

# file: app/controllers/users_controller.rb

def show
  @user = CrazyUser.find(15)
end

-# file: app/views/users/show.haml

%div[@user, :greeting]
  %bar[290]/
  Hello!

is compiled to:

<div class='greeting_crazy_user' id='greeting_crazy_user_15'>
  <bar class='fixnum' id='fixnum_581' />
  Hello!
</div>

Keeps things nice, concise and DRY. See the HAML documentation.

RSpec order-agnostic array matching

What’s that? You want to write an expectation for an array but your method returns the Array in a nondeterministic ordering?

Simple. Write:

my_method.should =~ <my_expectation>

See the source.

Ohm gotchas

Here’s a list of things that have been annoying, or at least a bit frustrating using Ohm, the Redis ORM, in a Rails app. Beware to those who assume Ohm is ActiveRecord in new clothes. It is, but it’s not:

CRUD

Don’t make the mistake of treating your Ohm objects like AR:

ActiveRecord Ohm
destroy | delete`  
self.find(id) self[id]
update_attributes update
create create

Also note that Ohm’s update_attributes behaves differently from Rails` – it doesn’t persist the updates to DB. That owned me for the good part of the day.

Callbacks

Thankfully, these are ActiveRecord-like with the addition of ohm/contrib.

Associations

ActiveRecord Ohm
has_a or belongs_to reference
has_many collection

Read this article if you’re considering creating associations from AR objects to Ohm objects and the other way ‘round.

Now at Blurb

I should have mentioned this long ago, but I started work at Blurb in early August. It’s been a quick ramp-up and I’m loving it there, surrounded by smart engineers and great designers. I do Rails/JS work there, and I’m building a lot of chops around Agile/TDD methodologies.

Anyways, they had me do a Camera Thursdays blog post, which I wrote about my Nikon/1.8 camera combo: