Tomas Varsavsky

Last weekend I had a blast attending my first BarCamp held at the ThoughtWorks office in Melbourne. The concept is powerfully simple: get a bunch of like minded people together and interesting conversations will ensue. The attendees represented a cross section of disciplines in the IT industry that you don’t usually find in technology specific user groups, producing a variety of interesting presentations.

Many thanks to Ben and the team for organising, I’ll be back next year.

I keep a list of “interesting things to look sometime maybe” which I add to when I come across something that I should learn more about. This list has grown over the last few months because I’ve been busy with client work, the birth of my daughter, landscaping my back yard and <insert more excuses here>. But today is my lucky day! I finished a client assignment last week and I have a few days up my sleeve before the next one starts.

Here are the high priority items on the list as it stands now.

• Scala
• Erlang
• RMock
• RSpec Story Framework
• Wicket
• Seam
• Ruby 1.9 new features
• Virtualisation with VMware and VirtualBox
• Git and Mercurial
• Read some of the books collecting dust on my bookshelf (Lean Thinking, User Stories Applied, Agile Estimating and Planning, Blink, The Tipping Point, Freakonomics)

Let’s see how many I can get through before consulting reality spoils the party.

Ruby development was always meant to be done on a *nix platform. For a while now I’ve been putting up with the Windows XP / Cygwin combination on my laptop to give me a pseudo-*nix environment. While this is a workable compromise, it is far from ideal. A lot of the Ruby tools don’t work well on Cygwin: crashes and mysterious hangings are common, execution times are slow and frustration is high.

The common solution to this problem is a walk to the closest Apple shop to get a shiny new Mac, but I’m not cool enough for a Mac so I decided to try something more befitting my coolness level: A Linux virtual machine running on my Dell laptop.

These are the steps you need to get a Ubuntu Virtual Machine running Rails over MySQL on your Windows machine.

Step 1: Setup a Virtual Machine (VM)

First we need to get a virtual machine configured and running with a *nix Operating System. I’ve chosen Ubuntu Server because all I need is shell access. You can use Ubuntu Desktop if you plan to use the VM as your development desktop.

1. Download the latest version of VMware Server or VMware Player. VMware Player is a lighter download but can only operate VMs, VMware server can operate and create VMs. Either will work for our purposes, I used VMware Server.
2. Download and unzip the latest Ubuntu Server VMware image. I used version 7.10 Gutsy Gibbon.
3. Start VMware Server, point it at the downloaded image and start it.
4. The virtual machine will start up and should come up with a login prompt. Hit Enter a couple of times on the console if it doesn’t.

Step 2: Get access

In this step we create a user on the VM and configure it for external shell access through SSH.

1. Login using the username “notroot” and the password “thoughtpolice”.
2. Install OpenSSH.

> sudo apt-get install ssh

3. Create yourself a user.

> sudo adduser –shell /bin/bash <user_name>

4. Add the user to the admin group (so they can do sudo, you can play around with sudoedit instead if you like).

> sudo usermod -g admin <user_name>

5. Get the IP address of the virtual machine.

> sudo ifconfig eth0

6. Fire up your favourite terminal program (I use PuTTY) and SSH to the VM using the user you created above.

Step 3: Install Ruby, Ruby on Rails and MySQL

Now we install some core development packages.

1. Update the package index.

> sudo apt-get update

2. Install Ruby and related tools.

> sudo apt-get install ruby rubygems irb ri rdoc ruby1.8-dev build-essential

3. Install Ruby on Rails.

> sudo apt-get install rails

4. Install MySQL.

> sudo apt-get install mysql-server

Step 4: Create a Rails project and fire it up

We have everything we need, let’s create a Rails project and access it from Windows.

1. Create a Rails project in your home directory.

> cd ~/projects
> rails killerapp
> cd killerapp

2. Create a database.

> mysqladmin -u root -p create killerapp_development

3. Configure the database in your Rail application config/database.yml.
4. Start the WEBrick server. You have to bind it to the external IP address (not localhost) to make it available though windows.

> ./scripts/server -b <vm_ip_address> &

5. On your favourite Windows browser, navigate to: http://<vm_ip_address>:3000/.The default Rails landing page should come up! You can add this IP address to the Windows hosts file to avoid having to remember it.

Step 5: Set up Samba (optional)

It’s useful to be able to share files between the VM and Windows, especially if you plan to use a Windows based IDE like Eclipse to craft your code. VMware has a “Shared Folders” feature but I gave up trying to get it to work after several hours of bashing my head against Google. I reverted back to Samba, which is trivial to configure.

1. Install Samba.

> sudo apt-get install samba

2. Add the user to the smbpasswd file.

> sudo smbpasswd -a <user_name>

3. Open the Samba configuration file for editing.

> sudo vi /etc/samba/smb.conf

4. Remove the ‘;’ from the line that says “security = user,”.
5. Add the following to the end of the file.

[<user_name>]
path = /home/<user_name>
valid users = <user_name>
read only = No
create mask = 0777
directory mask = 0777

6. Save and close the file.
7. Restart Samba.

> sudo /etc/init.d/samba restart

8. On Windows Explorer, Map Network Drive \\<vm_ip_address>\<user_name>, login using “<user_name>”.

That’s it! I haven’t used this environment in anger yet so there are bound to be some holes, let me know if you fall into any.

Steve Yegge (one of my favourite bloggers) recently posted about the maintenance problems exhibited by a large Java code base. I agree that software bloat is one of the biggest problems in our industry right now.

His proposed solution is to re-implement the 500,000 lines of Java code into 150,000 lines of a more concise language such as Ruby or JavaScript (ES4). This approach seems misguided to me because software complexity is not directly proportional to number of lines of code. The fact that 5 lines of Java can sometimes be compressed into 1 line of Ruby does not make the logic less complex or easier to maintain if they are essentially doing the same thing. In fact, I would argue that often 1 line of clever Ruby is actually less maintainable that 5 lines of Java because it requires a deeper understanding of what’s going on underneath the covers.

A good case study is Perl where developers seem to be a mind set of “how clever can I be” and write one liners that become indecipherable even by the author within days. You might be able to get away with this if you’re a gun developer working on your own but not if you’re working in an average team of average developers. I think Ruby has actually struck a nice balance between readability and conciseness and this is one of the reasons why its popularity has surged. Still, the thought of a 150,000 line Ruby code base scares me and would keep me up at night if it was left in the hands of average developers.

A code base with 1000 Java classes is just a complex as a code base with 1000 equivalent Ruby classes even if the number of lines per class is less. Reducing complexity and therefore increasing maintainability is all about applying good software engineering principles and frequent doses of my favourite refactoring — Delete.

In my current project we have some deployment scripts written in Ant. We can deploy a new version of the application as built by CruiseControl by running the command “ant deploy-war -Dwarfile=http://cruise-box/artifacts/killer_app/BUILD_TIMESTAMP/killer_app.war“.

Most of the time we want to deploy the latest successful build. We manually get the timestamp of the build from the CruiseControl dashboard and substitute it into the command above. It would be nice to default the warfile property to the latest successful build. For that we need CruiseControl to give us a well known link to the latest successful build.

I solved this problem using symbolic links. We can do this because our CruiseControl server runs on Linux but we could have achieved a similar result with a file system copy or an artifact publisher under Windows. I created the following helper Ant script to create a symbolic link using the Symlink task.

I then added a call to the helper script in the CruiseControl config.xml as an Ant publisher executed after a successful build.

I had to do it in an Ant script rather than calling the ln command directly with an execute publisher because I couldn’t work out how to access the build timestamp from within CruiseControl’s config.xml.

We can now access the latest successful build through the URL http://cruise-box/artifacts/killer_app/latest-successful/killer_app.war. The last step is to default the warfile property in our deployment scripts to this URL. We can now run “ant deploy-war” to deploy the latest successful build, or provide the property as before to deploy a different build.