Gnubbs Blog

Saw this on Ongoing today, and got sucked in.

steves-MacBook:~ gnubbs$ history|awk ‘{a[$2]++} END{for(i in a){printf "%5d\t%s \n",a[i],i}}’|sort -rn|head
   92    svn
   76    cap
   58    cd
   57    ssh
   55    ls
   26    ~/rdiff
   22    exit
   13    export
   12    mate
    7    vi

"svn" allows me to make stupid mistakes without regretting them.  "cap" allows me to roll out those stupid mistakes from Subversion to my web servers.  "ssh" shows that I upgraded servers lately so was stuck doing a bunch of SysAdmin work. "rdiff" is a piece of code that I stole off the intar-webs that allows me to run diff on two pieces of code reguardless of what computer they are actually on.

I mentioned the other day that I am working on some new servers at work.  I am replacing one ancient web server with two modern ones — staging and production.  I need this two servers to be basically identical, but I wasn’t looking forward to configuring everything by hand on both of them.

My solution was pretty simple.  I built up the staging server, got everything working, and then today yanked out one of the mirrored drives and swapped in a blank one from the production server.  I told that one to rebuild the mirror, popped in the drive with data into the other server, and told that one to rebuild the mirror as well.  Now I have two identically configured servers.  All I have to do is change some network settings, and I am good to go.

It might not be for the faint of heart, but worked great for me.

In the interest of not coming across as a total rails fan boy, I have a beef to share today.  I am moving servers for some work webapps, and have hit two distinct snags:

1.  Getting Mongrel_Cluster and apache to play well together is not trivial.  If you are working green field, the instructions in the Rails books and blogs work just fine.  Unfortunately, I have been using a hybrid of Rails and PHP apps on my servers for a couple of years now.  Getting my rewrite rules to work has not been fun.  They work finally, but there is some kludginess involved.

2.  I like the syntax of "form_for" more than "form_start_tag" a lot.  Unfortunately, I have dozens of forms using the old style.  They haven’t been updated since the deprecation warnings started popping up because I have had actual work to do.  Now that I am upgrading servers, I am switching to a newer version of rails.  This means there are a whole lot of forms to go back and update.

I will give props to one part of the Ruby/Rails world — Capistrano.  I have finally configured my servers to use it, and it makes life very nice.  "cap deploy" deploys to my staging server, and "export DEPLOY=PRODUCTION; cap deploy" deploys to my production server.  Nice. 

Well, i should quit writing this and get back to updating forms.