@madpilot makes

The second development tool in the “simple must have” category would be Capistrano. Capistrano is a deployment system that was written in ruby and is (not suprisingly) integrates quite nicely with Ruby on Rails. However! you can quite happily use it for any system, because at it’s heart, it is just a remote scripting tool.

When you run capistrano, you call a recipe, which is executed on the remote server or servers via SSH and it works really well.

Installation

The capistrano hand book has the latest installation instructions, so check there, but the basics (at the time of writing) are:

gem install capistrano

This will install the cap application. The tutorial from Simple Complexity – it deals with most of the difficult stuff (it’s actually really easy) and I don’t think I can put it any more eloquently.

Follow the steps and then you too can love the one-command deployment. I use it at MadPilot (for 88 Miles) and at Bam all the time. It’s great.

Next week: Part III

I’m sitting here watching the Poms getting destroyed by the Australians in the first test of the 2006/07 Ashes and just witnessed an interview with the man of the moment — Glenn McGrath. He just pulled a six wicket haul to knock off the fledgling English batting line-up in less that a day.

Anyway, during this interview he said the following when asked about what he thinks about when he is bowling:

It’s a simple game that we complicate. When you’re looking for that first wicket, your process is a little bit out

This sounds like the hype that is going around the web industry at the moment about keeping software simple – it is interesting to see how the theory translates to other facets of life.

The irony, I think, is that it takes much experience to be able to simplify a process down. An in-experienced person will probably see a simple solution, however they may fail to interpret potential problems down the track. semi-experienced people may not have used certain techniques long enough to be able to safely say in a given situation whether the procedure should be dropped or not. It is the experienced person that can see exactly what can be culled.

Ok, ok, I know I should be publishing part II of my fantastic “Three development tools you simply must have…” series, but I just got news of the following article about the WAWAs: http://www.onvoiceover.com/articles/wawa/. Not a bad write up if I do say so my self :)

A big thanks to John Lampard for the article.

As a web developer, there are a number of tools in my toolbox that I find it hard to live with out. These tools for the basis of my development and deployment procedures and have not only made my life easier on many occasions, but saved my arse on more times than I care to admit.

Although these tools excel when used by a team of developers and designers, I still use then when I’m developing my own projects, such as 88 Miles. I’ve split this mini tutorial up into three parts, so that I can be a little bit more descriptive about the actual process.

Application #1: Subversion

Developing without subversion (SVN) is like throwing rocks at your house. Sure it may be fun, but sooner of later you’ll hit a window and lose all of your source code… I’ll leave the unmixing of that metaphor as an exercise for the reader. Subversion is a source code versioning system which you can think of as a safe for your source code. The concept is simple:

1. You take a copy of the source code (checkout) and you work on it.
2. When you have made your change you save the change back in to the repository(commit)
3. When you delete or stuff something up, you check the previous version out of the repository and no one is any the wiser.

SVN uses a copy-merge system which allows many people to check code out and work on it at the same time. This is handy if you have a lot of developers. Many other version control systems use the exclusive-lock in model, where a developer checkouts the file, which locks it until they are finished, which is fine too – both have their pros and cons.

Copy-merge pros:

• You can have many developers working on the same code at the same time
• If a developer leaves a project, goes on holiday falls in to a mighty cravass, there is no risk that they will have an exclusive lock on a file, stopping other developers working on it.

Copy-merge cons:

• This can get messy if two developers work on the same file at the same time. At check in time, they will need to merge their changes, and if they have been making major changes, this might not be trivial. Solving the issue requires some heavy communication (not really a bad thing) and some planning (again, not a bad thing). On small projects, the likely hood of this is pretty small

Exclusive-lock pros:

• It is impossible for two developers to work on the same file at the same time, eliminating a situation where one developer destroys another developers work

Exclusive-lock cons:

• It is impossible for two developers to work on the same file at the same time :)
• See Copy-merge pros

One of the greatest things about SVN is it’s price tag – nothing! (Don’t let that freak you out though, there are many big projects that use it – Ruby on Rails is one that comes to mind) and there are clients and servers for Windows, Mac and *nix.

Although setting up SVN itself is probably beyond the scope of this article, I’ll out line the basic procedure to set up a repository, and to work with that repository.

Setup

There is a command line utility bundled with the package called svnadmin. This, funnily enough, is the administration tool for subversion. To create a repository, you do the following:

svnadmin create /path/to/repository

Where /path/to/repository is the location of the repository. So, say you want to create project called foo in the directory /home/subversion, you would execute

svnadmin create /home/subversion/foo

And it is setup! You will probably have to play with the permissions by editing the /home/subversion/foo/conf/svnserve.conf file, for the sake of this excercise, we will allow unlimited access to the world. Obviously, in real life, you would lock it down so only those that you wanted to be able to access the code could. Check out the subversion manual for details on how to do this.

Open the svnserve.conf file and find the line that says:

# anon-access = read

Change it to

anon-access = write

SECOND WARNING: THIS IS INSECURE. DON’T DO THIS FOR A SERIOUS PROJECT. And if you do, don’t come looking for me when some one steals your code.

Now you can checkout the empty repository in to your working directory – so called because it is the directory that you work in. The command will probably look something like this (depending on our server setup of course)

Right! now you are read to start coding! Once you have finished, you can add any new files, delete any old file and then commit the changes. Just so I know what is going on, I will first check the status of the directory

A new_file_2

U modified_file

D deleted_file

The letter before the filename gives you a hint as to what you need to do – A is add, D is delete, U is modified. To complete this commit, I would run the following commands:

/path/to/working/directory% svn delete deleted_file

/path/to/working/directory% svn commit -m “Created some files, deleted a file, modified a file”

And if all goes well, subversion will return the new revision number. Revision numbers in SVN are global, so every time you run the commit call, the number will be incremented. The -m flag stands for message, if you don’t put it in, a text editor will pop up asking you to add a message. The message you enter needs to be descriptive of what you do, so that others (or yourself) can go back and see why each commit was done.

Want to rollback the changes from a commit? Say you made a BIG mistake in revision number 5 and you need to go back to revision number 4, running the following command should do the trick:

_/path/to/working/directory% svn merge -r 5:4 svn://svn.myserver.com/foo

/path/to/working/directory% svn commit -m “Undoing BIG mistake”

So revision 6 will now be the same as revision 4. Notice though that revision 5 still exists, so if you later realise that the mistake wasn’t that big after all, you can revert back to revision 5!

This is just touching the tip of what subversion can do – you can do all sorts of other funky stuff, but I’ll leave that up to you to read up on. 99% of the time, this is what a subversion session looks like for me.

Next: Trac bug tracking

I just received an email a couple of days ago from one of the developers of a new JavaScript framework called Tennaxia. The point of the email was to ask permission to use my JavaScript colour picker as part of the library which is pretty cool. They also included the fabtabulous library from my mate over in Queensland, Andrew Tetlaw.

The library is a group of JavaScripts based on Prototype which provide widgets to use on web pages. Andrew’s widget, for example converts divs into panel tabs. There are a number of demos on the Tennaxia page.

It all looks pretty cool, so go and check it out.

Now that I’m back from Sydney, I have had a bit more of a change to play with my shiny new MediaTemple grid server account. It looks like I will be pushing 88 Miles over to it over the weekend – everything is setup and ready to go, and just have to do the migrating. I though I would share with you a few thinks I found out along the way…

Setting up the Rails environment

The instructions on the media temple site are pretty good, there are just a few caveats I would make. Firstly, I’ve now started using capistrano to deployment, so I decided to change a few of the directory structures away from how MT suggests. The steps I took are as follows changes from the MT instructions are emphasised (replace testapp with you apps name – obviously):

cd $HOME/../../containers
mkdir rails && cd rails
mkdir testapp && cd testapp
mtr add testapp $PWD/current

For those of you playing at home, you may have noticed that the /current directory, doesn’t yet exist. Correct! This will get created by capistrano.

Setting up Capistrano

Everything was pretty straight forward in the deploy.rb file. The only gotchas I cam across were specific to my installation:

If your svn repository has a space in it, wrap it in single quotes when assigning the :repository variable, i.e:

set :repository, “‘svn://svn.server.com/path/to/your repository'”

If your svn repository requires a username and password for checkout or export, use the :svn_username variable, i.e:

set :svn_username,
Proc.new { “username –password password” }

The only other modification I needed to make to the deploy file was the addition of the restart task. Because MT uses custom scripts to restart containers, the restart script needs to call them reather than trying to mess with the Apache or Mongrel processes. I also discovered that my secure certificate wasn’t functioning correctly (I’ll explain why in a second) so there is a fix for that here as well.

desc “Restart the rails container”
  task :restart, :roles => :app do
    run “mtr generate_htaccess test_app”
    run “echo ‘RequestHeader set X_FORWARDED_PROTO “https“ env=HTTPS’ >> #{deploy_to}/current/public/.htaccess”
    run “mtr create_link test_app”
    run “mtr restart test_app”
  end
end

Line 3 uses a MT script to make some modifications to the apps .htaccess file. Because Mt proxies all requests to the apps Mongrel server, the standard .htaccess doesn’t cut the mustard.

Line 4 makes another modification to the .htaccess file. Because I’m slack, I pull a neat trick when I do SSL. I maintain a global list of pages that require SSL – when a user browsers to that page, they automatically get redirected to the secure version if required. And the same works the other way – if they browser away from a secure page to a non-secure page, they get re-directed to the non-secure version. Unfortunately, because of the way MT proxies the request, the Mongrel server knows nothing about whether the connection is secure of not (i.e request.ssl? always returns false). Thankfully, there is a fix for this in Rails – if you include the X_FORWARDED_PROTO=https header in the request, rails knows what is going on. This line checks for the environmental variable HTTPS (Which is a flag that is set if the server is in SSL mode) and if it is, sends the modified header, which makes everything good again.

Line 5 links the web directory to the rails container and line6 restarts the server. Nice and easy!

What can you get for $20 per month these days? A Basecamp account? 4 88 Miles accounts? An account of a Grid server with 100Gb of disk space, 100Tb of traffic with support for upto 100 sites? Yeah. Media Temple has just released an insamely priced grid server setup that offers all of that FOR $20 PER MONTH. They even support Ruby on Rails using containers and mongrel. Needless to say, I signed up for account. hopefully it will come through before I leave for Sydney tomorrow afternoon, otherwise I’ll have to wait a week to play.

What is a grid server?

A grid server is basically lots of little servers that acts like one big server. This means that if a server becomes loaded, they can through more hardware at the problem. Google and Amazon use similar systems, infact Amazon offers a service where you can upload a virtual linux machine on to their grid.

If they pull this off, it will pretty much revolutionise server hosting. I’ll keep you posted how I go with my 88 Miles migration.

And what a rich, long living and all-encompassing tradition it is. Ok, there is actually only two of us, and I’m the one that has been in the web biz for the longest, but I’m sure that there may or may not be more to follow in our footsteps. And no, I haven’t gone nuts and started speaking in the third person again – the additional body that makes up the other half of “our” is my little brother, Cyrus, who just released his new and improved portfolio and blog site.

He obviously has a designer bent, which is cool because it means he might be useful to me some day :)

Seriously though, I quite like the look. So a big “Nice” goes out to him. Check it.

I was just catching up on the tawdry adventures of workmate Simon’s trip around Europe. Possibly one of the funniest travel blogs I’ve read (Also probably the ONLY travel blog I’ve read, but if I’d read more, I reckon it would still be up there) and I got a flash back to a couple of weeks ago when he popped up on MSN.

He was in the middle of Sweden and we were basking in the light of umlets and agraves (As we do – Simon is a typography enthusist and I just love the sound of the word umlut). Of course funky inflections on characters is almost exclusively an Ikea thing over here in Australia, our alphabet isn’t blessed with anything more interesting than an X. So, anytime I see a swedish word, I immediately think flat-pack furniture, and so our new swedish car game was borne…

Wow. I’ve been blogging for 12 months today. Crazy. So as a birthday present to my blog, I decided to give it a nice coat of (pixilated) paint. Still needs a little work, but it definately an improvement :)

Thankyou to those that still read this thing. I’ll send you all a virtual hug.