(void* dan)

If you don’t believe backing up your data is important, come back when (not if) you lose some important information.  Sensible (Rails) developers, read on…

I’ve seen (and used) decent backup solutions involving mysqldump, sftp and an additional server.  They’re okay, but with a few plugins/gems your DB backup can be elegant (and Amazon secure).  I happen to like db2s3.  Configure the gem like the README says.  Then add a couple of whenever tasks:

every 1.hour { rake “db2s3:backup:full” }

every 1.day { rake “db2s3:backup:clean” }

Holy shit done.  But you will have to pay the S3 bill.  So pick up a penny from the ground every day.  You’ll be $.25 ahead of the game at the end of the month.

Gotchas?  Of course.  db2s3 relies on aws-s3, so you must have that gem installed (this is not explained in the README).  NBD, but if you happen to be using right_aws with paperclip, like me, you may run into issues due to the gem load order.  So, keep your house in order:

config.gem “aws-s3”, :lib => “aws/s3”, :version => ‘>= 0.6.2’

config.gem “right_aws”

Thoughts?

Many Ruby on Rails decisions are guided by the motto “convention over configuration.”  This makes Rails opinionated software and allows one to get up and running quickly and easily, so long as you follow the crowd.  I love this.  It makes you confident you can try something new, get it up and running fairly easily, then start adding functionality, breaking and tweaking iteratively.  They so to err is human.  It’s also Rails…

I’m a very organized person; it helps me get things done.  So when I recently started building some Rails billing functionality, I decided I would namespace it.  Shouldn’t be too bad…

script/generate model billing/Account ...

This created the model Billing::Account in the file models/billing/account.rb.  Nice.  Turned out to be less-than-nice when I tried to start working with it.  I’ll spare you the details of how much I hated my life that day and get straight to the caveats:

1. The migration generated created a table called “billing_accounts” which seemed correct (and great!) to me.  But ActiveRecord doesn’t care about your namespace, so you have to manually add “table_name :billing_account” to the Billing::Account model.
2. For testing, a new directory was created: test/fixtures/billing, but it was empty.  The file billing_account.yml was added to the base fixtures directory.  Don’t do what I did and move that file into the billing/ directory: those fixtures don’t get loaded.  So leave it, or move it and update Rails’ load path to look through fixtures/ recursively.
3. Foxy fixtures do not work with namespaced models.  Not at all.  If there’s a way to get them to play nice, I couldn’t figure it out before deciding to hand out a couple of id’s manually.  Fuck it, that’s why.

It puzzles me that Rails’ generator seems to handle namespaced models so gracefully, but actually creates these incompatible time-sucking gremlins.  Did I do something completely wrong here?

During our meeting with Fred Wilson last week he mentioned something fairly obvious about our company: we have too few engineers  (i.e. just me).  He was making the point that one particular path for our company could see it thrive (netting a few million a year in profits) with a small 10-12 person staff (7 engineers or so).  But it started me thinking about it from the other angle: what if we had too many engineers?

I firmly believe one of the reasons startups create some of the most beautiful and expertly crafted products is that they have limited resources with which to produce them.  Startups therefore, by necessity, build only to create value and build the smallest solution possible.  This viewpoint is bolstered by 37signals’ Getting Real, Paul Graham in many of his excellent essays, and the principle of least effort (or path of least resistance, if you will).  It’s why Rob Pacheco says, “to find the most efficient way to accomplish a task, give it to the laziest guy in the kitchen.”

Conversely, when a startup grows (or starts) too big, it produces decreasingly beautiful products.  Engineers, by definition, like to engineer.  An average engineer - which most of them are, by definition of the word average - will not achieve perfection.  Since these engineers have to do something with their time, the company they work for ends up with an over-engineered product (by definition!).  It is the rare exception (i.e. Apple) that can produce many beautiful products by the labor of many engineers.

-A Lazy Engineer

In development of a new, greenfield application I had flash messages popping up twice: once for the current page, and then again on the next page.  It turns out I was using flash[]= and then rendering within the same action.  As flash[]= is designed to carry over to the next action (i.e. after you redirect, a new action is performed) it was showing up again.  The solution: flash.now[]=.  This hash is cleared after the current action.  The following code illustrates when to use each:

def create_application
  #do work
  if it_worked?
    flash[:notice] = "Great success!"
    redirect_to @cash
  else
    flash.now[:error] = "Let's try that again"
    render :action => "new"
  end
end

The flash[:notice] must be carried over to the action that handles the @cash path (following to the redirect), whereas the flash.now[:error] will be shown for the current action (even though it renders a different view) and should not be carried over to the next action.

It seems somewhat strange to me that I’m just discovering this now.  I suppose that as I learn more about Rails and web applications in general, I adjust my techniques and start experimenting with new ones (that aren’t always better).  The fact that flash[]= carries over to the next action and flash.now[]= doesn’t has only come into play now that I’m using flash as more of a central messaging system than just the standard notices from scaffolds.