You can never have too many.

Much like every new version of OSX, there have been a plethora of "How to install BLANK on Snow Leopard" blog posts and walk-throughs detailing all the little tips and tricks around how to install some tool or piece of software.  Having a lot of options is awesome, but in the words of the great Biggie Smalls, "mo' blog posts, mo' problems".

That IS how it went, right?

Anyway, with all of these walk-throughs, how do you know which ones are good, and which one just suck.  Well, you don't really...

So here's a list of a few [confirmed] valid and useful dev setup walk-throughs:


First, this is actually a series of posts, as opposed to one single write-up.  Actually, its not even a series of posts.  Its just the search results for 'Snow Leopard' on the Hive Logic site.  So really, its only the first 3-5 posts that matter.

http://hivelogic.com/search/results/a7a831b978f2667fa301ea095d3d8fa7

This is the route that I personally followed after a fresh install of Snow Leopard, and I had everything up and running in no time.


Next, Robby On Rails did a thorough and entertaining post on Snow Leopard Rails dev env setup, or SLRDESU for short.  Acronyms make everything better (AMEB).  I don't know about you, but Robby's older post about getting setup with Passenger came in handy for me on more than one occasion.

http://www.robbyonrails.com/articles/2010/02/08/installing-ruby-on-rails-passenger-postgresql-mysql-oh-my-zsh-on-snow-leopard-fourth-edition

His latest post covers everything from start to finish, and he even included a few video to pass the time while waiting for binaries to build and whatnot.  I haven't personally used this walk-through, but based on my previous experience with Robby's posts, and the recommendation from coworkers, I'm sure it'll get you where you need to be.


Another noteworthy mention comes from the guys over at Thoughtbot, the makers of such wonderful tools as Shoulda, Paperclip, and Factory Girl.  Their robot-laden guide goes beyond just Rails/dev-related stuff, and covers the likes of several generally useful OSX tools.  Things like Quicksilver, Fluid, and Firefox/Firebug.

http://robots.thoughtbot.com/post/159805668/2009-rubyists-guide-to-a-mac-os-x-development

This is another one that I haven't personally used, but I think we can trust the guys over at Thoughtbot.  After all, their company reputation depends on it!


So there you have it.  Three different hand-holding recipes for getting you set up on Snow Leopard.  If you haven't upgraded yet, what're you waiting for?  Get to it!

Remember my post from a few weeks back about temporarily disabling ActiveRecord callbacks?  Well, I decided to extend the functionality a bit and wrap it all up in a plugin.

You can now specify one or more callbacks to disable, or specify nothing and disable all callbacks by default.

You can check out the project page or jump over to the Github repo.

I ran into a strange issue while attempting to checkout a remote tracking branch of an Intridea project earlier today, so I thought I'd post up my work around.

I ran my normal checkout command, like so...

brent:~/Intridea/earthaid[master]$ git checkout -b prod origin/prod

which resulted in this error message

fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/prod' which can not be resolved as commit

After a bit of googling, I'm still not sure of the cause as most of the search results were related to issues around deploying tags, and I was merely attempting a checkout.  What I did find out was that I could specify the start point of my new branch by the revision/commit sha instead of the remote branch name, like so...

brent:~/Intridea/earthaid[master]$ git branch prod 02314583a99abdc276cde968c20babbadd23
brent:~/Intridea/earthaid[master]$ gc prod
Switched to branch "prod"
brent:~/Intridea/earthaid[prod]$

Once I had applied my changes, I just had to make sure to push them to the proper branch.

[update]

Ok, I'm a retard.  About a minute or two after I typed up this post, it occurred to me that Git couldn't resolve the remote branch name because I hadn't pulled first.  Yeah, that's right.  All I need to do was pull and then everything worked properly.

Today I began helping out on an Intridea project that (by the client's request) uses Subversion as their revision control system instead of Git.  Initially I was a bit dismayed.  Hell, I actually felt a little sick to my stomach.  Git has treated me very well over the past year, and I hadn't touched a Subversion repo in even longer.

Git-svn had crossed my mind, but it wasn't until a coworker suggested it that I decided to give it a try.

The first thing was to get it installed.  I followed this tutorial and only had to make one small change.  Adding /opt/local/libexex/git-core to my path didn't work.  I did a quick whereis to find out that my git-svn executable is in the /usr/local/git/libexec/git-core/ directory.  I updated my path and everything was kosher.

Now to set up the repo.  Most of the tutorials that I found covered setting up a new svn repo with git-svn like this one, but in my case, the svn repo had been around for quite some time.  Being the wannabe-know-it-all that I am, I decided to just go ahead an clone the svn repo, like so:

git-svn clone http://path-to-the-svn-repo

After about ten minutes of watching the clone chug away, I thought something was up.  Well, it turns out that if you don't include the proper options, the clone will pull down all branches, tags, whatever.  I didn't want, or need all of that.  All I wanted was trunk.  After a brief glance at the git-svn docs, I tried again with the --trunk flag.

git-svn clone --trunk http://path-to-the-svn-repo

Aparently, the -s option also works.  It tells git-svn that you svn is in the standard layout with trunk, branches, tags, and whatnot.

This time it ran for only five minutes before I asked myself wtf was going on.  I realized that it was pulling down every single revision, which I really didn't need.  I would've stopped it and tried again with the --revision (-r) flag which allows you to specify a revision number, or range of revision number, but the clone was already at rev 900 out of 1100, so  I just let it ride.

Once that was done, I was good to go.  I could pretty much just treat it as a regular Git repo until I was ready to push any changes back to the svn repo.  I used this tutorial by Clinton Nixon, who I had recently seen do a talk on Scala at the Developer Day in Durham, to help guide my general git-svn workflow.

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.