I've hosted acts-as-blogr on Slicehost for a while now, but I recently signed up for shared hosting through Dreamhost.  They had a promotion of 2 years of hosting for $22 which I couldn't pass up now that they support Passenger for Rails apps.  Anyway, I finally got around to deploying an app with Passenger and I had a little problem.

Upon doing the initial 'cap deploy:migrations', it failed with this error

  * executing "cd /home/brentmc79/brentmc79.com/releases/20090122070240; rake RAILS_ENV=production  db:migrate"
    servers: ["brentmc79.com"]
    [brentmc79.com] executing command
 ** [out :: brentmc79.com] (in /home/brentmc79/brentmc79.com/releases/20090122070240)
 ** [out :: brentmc79.com] rake aborted!
 ** [out :: brentmc79.com] uninitialized constant User::Authentication
 ** [out :: brentmc79.com] 
 ** [out :: brentmc79.com] (See full trace by running task with --trace)
    command finished
failed: "sh -c \"cd /home/brentmc79/brentmc79.com/releases/20090122070240; rake RAILS_ENV=production  db:migrate\"" on brentmc79.com

This was clearly something to do with restful_authentication since it was complaining about User::Authentication.  I did a bit of googling, but I didn't come up with much.  Somebody mentioned renaming the plugin to not have a hyphen, but that just seemed silly.  Someone else mentioned some session/cookie issue, but I hadn't even made it to the browser.  It was failing on db:migrate.  Finally, someone mentioned that they had forgotten to include the plugin in their repo.  This got me to thinkin...

I knew that I had included the plugin, but I decided to take a look at the Github repo in the browser.  Here's what I saw:

The restful_authentication plugin was actually a cloned repo sitting inside my working copy.  I'm sure there's probably some clever way to enable a repo inside of a repo, but it was 2am and I just wanted it to work.  So I just rm'd the restful_authentication plugin from the vendor directory, download the tarball from Github, and extracted it back into vendor/plugins.  Using the tarball instead of the clone gives you all the code without all the git info.

I committed/pushed, then ran 'cap deploy:migrations' again and the database migrated with no uninitialized constant error.   Viola!  Unfortunately, then I just moved on to the next issue...

After a couple more tweaks and deploys, I finally had it up and running.

I've been using Git for almost a year now, but I didn't really start using Git until recently when I began working for Intridea.  Once I started using Git on a daily basis, dealing with multiple projects, and multiple branches per project, I would occasionally make the mistake of changing code on the wrong branch.  While annoying, it was easily fixed by stashing the changes and applying the stash to the proper branch.

As much as I love git stash, this began to get old, and constantly hitting up 'git status' to check the current branch wasn't cutting it.  After a bit of googling, I found this.  It describes how to add the current branch name and its clean/dirty status to you terminal prompt.

Just add this to your .bash_profile: 

function parse_git_dirty {
  [[ $(git status 2> /dev/null | tail -n1) != "nothing to commit (working directory clean)" ]] && echo "*"
}
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/[\1$(parse_git_dirty)]/"
}

export PS1='\u:\[\033[31;40m\]\w\[\033[0;33m\]$(parse_git_branch)\[\e[0m\]$ ' 

And you should end up with something that looks like this:

As you can see, I like to use a bit of color to help things stand out.

So far this has been immensely helpful.  With this info at a glance, I always know where I am and how I last left things.