Sean’s Mental Walkabout

I’ve always felt the root of the emacs vs. vi holy war (which is one of the longest standing holy wars in free software) basically came down to the following key point:

When you first were learning Linux / Unix, did your mentor use vi or emacs?

The answer to that is at least 90% correlation to your preferences. Much like most people share the politics of their parents, most people share the editor preferences of their mentors. Switches don’t tend to happen unless mentors switch as well.

And in that camp, I’m an emacs guy. I learned it in college when I took my first programming class (which was in lisp). Our professor gave us a starting .emacs file, pointed us at the tutorial, and built macros that helped us out in our efforts.

A near decade with XEmacs

Then I graduated from college, and my first mentor at IBM was also an emacs guy, except he was an xemacs guy. It was emacs, but prettier. So I piled on, and was there ever since. Over the years I tried a couple of times to go back to emacs, but their font handling was never as good. I love programming in arial, as it’s just really pleasant on the eyes (this shocks and horrifies people that line up = signs in declarations, but I don’t much care. ).

A few years ago, just as emacs was getting reasonable variable width font support, xemacs integrated anti-aliased fonts into their CVS tree, and now I had another reason to stay on xemacs, because now everything looks pretty. Using xemacs was sometimes a pain, as a number of modes didn’t really work right on it. I never had a reasonable html mode working that did indentation like I wanted.

Steve Yegge’s Rant

Last month Steve Yegge had a post entitled Xemacs is Dead, Long Live Xemacs which was basically a call to unify around emacs because it had finally caught up, and it is being very actively maintained. I was skeptical, but decided to try again. Using the Ubuntu packages I lost my anti-aliasing, which meant this was a failed experiment.

But, after some research, I realized that emacs cvs not only has xft support in the tree, but that since March it’s been the default. This is what will be emacs 23. I was already running xemacs out of cvs, so taking the same leap with emacs cvs wasn’t such a big deal.

It’s taken a couple of weeks to tweak my configuration to get me the same, or better, results with emacs as I had with xemacs. Last night I finally understood what I needed to get nxhtml to do my html.erb files correctly (ruby and html bits independently highlighted, and mode switching automatically when moving between code blocks). Minus 1 font issue with planner, I can definitely say I’m fully converted.

I’m also enjoying diving into elisp again. For whatever reason, life seems a bit more stable on emacs than it did on xemacs. And once emacs 23 actually makes it to distros, I won’t even need to have my own binary builds.

A couple weeks ago I found phusion’s passenger (aka mod_rails), and it’s great. Passenger compiles an apache module which manages a rails app server for each application. It is on par with mongrel on speed, and so much easier to integrate into an average Linux environment for rails app hosting. Here’s my new standard rails development environment (3 applications right now, with a couple more in the works).

Development with Mercurial

Distributed Source Code Management is the wave of the future, and I can’t say enough good about it. My prefered system is Mercurial (aka hg), which I got to know why working on the Xen project. While git is getting a lot more hype of late, I still think hg is easier to use, and an easier switch for people that know subversion.

Rails makes it very easy to run a server locally for development, so having versioning locally makes perfect sense. I can hack away for days making changes on my laptop until I get to a point where I want the code to see the light of day. Then it is an easy hg push to put my code either into production, or into a repository for sharing.

Deployment with Passenger

Passenger is a god send. Getting mongrel to do the right things on init on an ubuntu box was just a pain in the rear end. I like apache, I know apache, having to configure a web app outside of apache sucks. Passenger builds an apache plugin that is an rails app server. You don’t need to know any more than that, because it just works.

Actually, you need to know 2 things, both of which add to passenger’s awesomeness.

• The rails app will run as the uid of the owner of your environment.rb file. This means you need to take care on how your permissions work on you deployed rails app. This is a good thing, as we’ll see in a minute.
• You don’t need to restart apache to restart the rails app. You just need to touch tmp/restart.txt in the rails directory, and the app server restarts. This is very handy.

Bringing it all together with Mercurial Hooks

On my box where I’m deploying applications I created a new rails user, with a scrambled password, and just my ssh key to get in. This is the account in which I push production versions of apps to. It means that the rails apps run as user rails, which is ever further issolated than user www-data. You could even go a step further and have each rails app under a different user, but for me that’s overkill.

The .hg/hgrc for one of my local projects looks as follows (with myhostname, myrailsapp, and myrailssite replaced to protect the innocent):

[paths]
default = ssh://myhostname.org/code/myrailsapp/
production = ssh://rails@myhostname.org//data/site/myrailssite/

Now my push targets are in place.<br /><br />The last bit is adding a set of hooks on the target repository so that on each push the repo is updated, migrations are run, and the app is restarted. I’ve created /data/site/myrailssite/.hg/hgrc as follows:

[hooks]
incoming = hg update -C && RAILS_ENV=production rake db:migrate && touch tmp/restart.txt

And that’s it. Now an hg push production force syncs the remote repo, runs any new migrations, and restarts passenger. A 1 step command, and everything is live.

While I’ve been a huge Ruby on Rails fan for the last year, deployment always sort of sucked with it. Now I’m a very happy camper with this setup which makes for very seemless development of rails applications.