Once you have your development environment setup as a VMware VM, you will want to access it with applications running on your host OS.  For example, you want to test your new shiny Ruby on Rails web application (running in your VM) with Internet Explorer on Windows or Safari on OS X

There are three ways to configure the network connection for your VM:

  • host-only
  • bridged
  • NAT

Host-only is not interesting for web applications that interact with APIs and services on the internet.

With a bridged connection and DHCP, your VM will have a different IP address as you go from home to office to coffee shop.  It becomes annoying to open a terminal in your VM, run /sbin/ifconfig, copy the IP address, and then go back to the host OS and adjust your hosts file accordingly.  Do this a few times and you will clamor for a better way.

Enter NAT and a static IP address for your VM.  You will have a consistent IP address no matter which network your host is on. Enter this IP address into your hosts file once and you’re done.  Let’s walk through a real life example.

You have 3 in-progress client projects.  You have configured your development VM with the same stack that’s powering your staging and production servers.   In this example, you have a Ruby on Rails application running apache, Ruby Enterprise Edition, Phusion Passenger, and MySQL.  You configure each project with  its own VirtualHost : project1.dev, project2.dev, and project3.dev.  On your host OS, you have a host file entry like this:

192.168.154.100 project1.dev project2.dev project3.dev

Now whether you’re at home, at the office, or sipping some chai tea at a coffee shop, you can access your client projects the same way from a browser on the host OS: http://project1.dev, http://project2.dev, and http://project3.dev.

This seems simple enough, but it turns out that defining a static IP address in your guest Ubuntu VM and having that IP address accessible from the host is not trivial.  Start by running ipconfig (Windows) or ifconfig (OS X) on the host OS and look for the IPv4 Address for the VMnet8 adapter.  On my Windows machine, that address is 192.168.154.1.  On my OS X machine, that address is 172.16.252.1.

Now in your Ubuntu VM, configure it to use a static IP address.  This example uses 192.168.154 for the first three octets.  Substitute the first 3 octet values corresponding to your VMnet8 adapter.  In Ubuntu, System -> Preferences -> Network Connections.  On the Wired tab, select the network adapter (usually Auto eth1) and click on Edit.  Select the IPv4 Settings tab and enter/select these values:

  • Method: Manual
  • IP address: 192.168.154.100
  • Netmask: 255.255.255.0
  • Gateway: 192.168.154.2
  • DNS Servers: 8.8.8.8, 8.8.4.4

192.168.154.100 was chosen for the IP address because 100 is a) easy to remember and b) far enough away from the reserved low single digits to avoid conflicts.  The gateway value was the tricky one.  Most references instruct you to use the IP address, but substitute 1 for the final octet.  However, that IP address was already being used on the host for the VMnet8 adapter.  After much trial and error, it turned out that 192.168.154.2 was the ticket.  The DNS servers are Google’s.

After making the settings, restart your networking with /etc/init.d/networking restart.

For many years, I developed software (mostly LAMP and Ruby on Rails) on a MacBook and MacBook Pro. It was always a struggle to have the right stack installed for various projects.  Mac Ports became my weapon of choice. Even then, there were enough differences between my development, staging, and production environments to cause unexpected problems. Managing different versions of databases, libraries, etc. was never simple.

At the beginning of 2010, I was fed up with Steve Job’s reality distortion field and defected back to the PC camp. Greeting me with open arms was Windows 7, an OS that I continue to praise. However, I longed for my bash prompt and open source stack.

The solution was to run a VMware VM with Ubuntu as the guest operating system. This solved many problems.

  • My development machine became consistent with my staging and production servers.
  • I can have a different VM for projects requiring different stacks. No more trying to make my laptop a superset of all environments.
  • When bringing on additional developers to the project, I simply hand them a copy of the VM. Voilà. Their entire development environment is ready to go. No more wasting an entire day on configuring your laptop.
  • I chose VMware because it is available on Windows, OS X, and Linux and the same VM can run unaltered on all three platforms.
  • VMware offers snapshots, so you can easily roll back to a known state if you really mess things up.

Now that it’s 2011, a client project requiring OS X has forced me back into Apple’s extortion pricing. This time, however, I will be using the VM solution. I highly recommend it.

git is the current hotness in source control. One of its main strengths is cheap and easy branching and merging. As a result, git users tend to use branches often. This is a good thing. However, when working on multiple repositories with multiple branches, it can be easy to lose track of your current branch.

While a simple git status will yield the current branch, it is often convenient to have the current branch displayed in your prompt. The magical incantation to add to your PS1 variable is $(__git_ps1). This function is defined in /etc/bash_completion.d/git. If you don’t have access to that file, you can find it in contrib/completion/git-completion.bash after cloning this repo:

git://git.kernel.org/pub/scm/git/git.git

Here is a snippet from a .bashrc file for displaying the current git branch in your bash prompt:

source /etc/bash_completion.d/git
export PS1='\w$(__git_ps1 "(%s)") > '

© 2011 Technically Speaking Suffusion theme by Sayontan Sinha