# 16 Mar 2011
While testing a locally running web application in OS X 10.6.6, I discovered that DocumentRoot appears to be set incorrectly. I wasn’t able to refer to a file like
/style.css in the web app source.
If you have Web Sharing turned on, each user’s httpd DocumentRoot is not automatically set to
/Users/username/Sites, as I expected.
But each user does have there own personal
httpd.conf file in
Find yours, then add the following, replacing username with your own:
Toggle Web Sharing off/on, and it should be fixed.
# 14 Mar 2011
Capistrano makes deploying Ruby on Rails applications easy. Having experienced how easy, I was eager to use Capistrano to make deploying non-Rails applications just as easy. I wasn’t able to find comprehensive info on actually making this work from start to finish. Here’s how to do it.
Capifying Your Project
Capistrano has fairly good documentation for this step, and I don’t see this changing much in the future. Open Terminal.app and run:
Capistrano will create a couple of files for you. The important one is
config/deploy.rb. Open it. Then replace its contents with the following:
deploy.rb with your specific information. You have been Capify’d!
You will notice that in
deploy.rb, we have only told Capistrano about Bitbucket via the repository parameter, and that we are using a URL that begins with SSH. This means that authentication with the Bitbucket server will be via SSH, which will require that we have a public-private key pair. We will set that up now.
Bitbucket has a helpful page which covers how to access your Bitbucket repository via SSH. The important part of it for this discussion is to set up your public key with Bitbucket.
If you don’t have a public-private key pair, follow that guide to set one up. In Terminal.app, run:
And follow the prompts. Make sure to note the location of your public key so that you can get to it later. It is probably at
Now, you’ll need to give Bitbucket your public key (ends in .pub). Look in your Bitbucket Accounts page to find where to do that.
Also, update your local repository’s parent by updating
.hg/hgrc in your repository’s root with:
[paths] default = ssh://email@example.com/bitbucket_username/project
You should be able to connect to Bitbucket without typing a password.
Just copy your public key into
~/.ssh/authorized_keys on your deployment server. Assuming that you don’t already have any public keys set up already then run:
You should now be able to authenticate with your server without typing a password.
You’ll also want to change your Apache HTTPD document root to point to the current alias that Capistrano will create in your server’s www root. Different web hosts have different ways of allowing you to do this. Mine provides a web interface that can adjust this setting. Check yours.
This was, for me, the trickiest part. What Capistrano is going to do when you deploy your application is connect to your deployment server (authenticating using your private key on your development machine and your public key in
~/.ssh/authorized_keys on your deployment server), and then, from your deployment server, connect to your Bitbucket server to access your repository.
In order for this to work, SSH Agent Forwarding must be enabled on your development machine. Add this to
~/.ssh/config, creating the file if it doesn’t already exist:
Host * ForwardAgent yes
Open up Terminal.app, navigate to your project’s root directory, and run:
The most recent version of your application in Bitbucket should now be deployed to your server.
# 20 Jun 2010
I sometimes like do my development work in a local Mercurial repo even though I’m stuck checking into ClearCase in the end.
I create a fresh snapshot view in ClearCase, create a Mercurial repo on the view, then do my work in a clone of that Mercurial repo. It isn’t ideal, but it allows me to delay all the file checkin/checkout work required when dealing with ClearCase. The main advantage is that it frees me to use whatever IDE or text editor I want, without relying on an integrated ClearCase plugin.
The tricky part comes when it is time to push my changes from my clone to the hybrid Mercurial/ClearCase repository/snapshot view — or more accurately, after the push, during a hg update on the hybrid repo/view.
I’ve been using this bash script (run in Cygwin since ClearCase isn’t available for OS X) to help with that step.
It continuously attempts to update (via
hg update) the hybrid repo/view, and looks for files that need to be Checked Out in the ClearCase snapshot, and then checks them out.
# 05 May 2010
Rather than bury the actual “get fruit” logic inside of another function though, I’ve found it handy to use a Proc if that logic doesn’t need to be re-used elsewhere.