6 easy steps to deploy a Ruby on Rails application to Brightbox

Ruby on Rails deployment is often regarded as a dark art. But the guys at Brightbox have made it simple with their Brightbox gem. I have recently moved three clients over - so I’m getting pretty good at deploying there. Here are the steps that I follow:

One:

Sign up with Brightbox and buy a box. You will need to know the account name, the ‘rails’ user password and the mysql password - all of which are available from the VM details page that is emailed to you. The brightbox will be provisioned with a name similar to “account-001.vm.brightbox.net”. I recommend ssh’ing into the box and changing the ‘rails’ user’s password - you will be typing it a lot - or installing your ssh keys.

Two:

Prepare your application in subversion.

You need to make sure that your config/database.yml file is included in your subversion repository (many developers prefer to leave it out for team reasons - don’t worry, you can take it out again later).

You should edit the production entry to point at your desired production database. Set the database name to account_database (where account is your Brightbox account name and database is whatever you want), set the user to your account name, the password to whatever you noted down above and the hostname to sqlreadwrite.brightbox.net (the Brightbox MySql cluster).

Don’t forget to set the svn:ignore property on your log and tmp folders.

Three:

Install the Brightbox gem on your development machine.

Use the brightbox command to generate the Capistrano file (telling it your application name, the name of your Brightbox and the desired domain name that your application will be running on).

At the same time, point your domain name (via an A record) at the Brightbox’s IP address and place a support ticket to set up a Reverse DNS entry (if you will be sending out emails). If you don’t have a domain name yet then use myapp.account-001.vm.brightbox.net.

Then open config/deploy.rb and edit the source code repository entry to point at your svn server (if necessary setting up scm_username and scm_password entries).

Four:

Run the cap setup command (if you have capistrano 2 installed, this becomes cap _1.4.1_ setup as, at the time of writing, the cap 2 version of the gem is still in beta). This will ssh into your server (so you will need that password) and set up the folder structure for you.

Then run the cap cold_deploy command. This tests whether things are working - as it tries to get your code out of svn and onto the server, sets up monit (to keep tabs on your app), uses the database.yml file to create a database and configures Apache with your domain name. If it fails you will need to edit your deploy.rb (and probably get rid of the created database so you can run it again).

You should see your application at your domain name. Stop a second and reflect on how much you have achieved :-).

Five:

Remove your database.yml from svn (set the svn:ignore property on it). Then copy it to the Brightbox (using scp) and place it in /home/rails/my_app/shared/ (where my_app is obviously your application’s name). If you have any file uploads (attachment_fu) or shared assets then copy them into the shared folder as well. Then edit your deploy.rb to add something similar to the following:

task :after_update_code do

  # link the relevant database.yml from the shared folder to the app's folder

  run "ln -nfs #{deploy_to}/#{shared_dir}/database.yml #{release_path}/config/database.yml"

  # link the file store to the application

  run "ln -nfs #{deploy_to}/#{shared_dir}/files #{release_path}/public/public"

end

This means that, after deployment, capistrano will create symlinks from your shared database.yml and shared files into your applications config and public folders respectively.

Six:

Try another deployment to test your symlinking. cap _1.4.1_ deploy - if all goes well then your application should still be running at your domain name, and monit will report that your processes are running correctly. From now on, all you need to do is commit to svn and then cap _1.4.1_ deploy.

The advantage of RSpec over Test::Unit

A while back, I wrote a post moaning about RSpec.

My basic point was that there is something that feels wrong about it, and at the time, I couldn’t put my finger on it.

Now I have been using RSpec solidly for a week, on a new project, I think I have it. It’s the syntax.

Everytime I start writing expectations I put my spaces and underscores in the wrong place.

@person.name.should_not be_blank versus @person.name.should not_be blank. The latter is what my fingers think it should be.

I understand that be_XXX is a particular RSpec construct. And should or should_not marks an expectation.

But somewhere in there, the word breaks feel arbitrary and wrong.

In RSpec’s defence, however, there is one advantage that puts it way ahead of Test::Unit.

You see, because of the above, I find RSpec hard to write. I keep getting bits wrong and having to retype lines.

However, when looking back through some Test::Unit code I had written for another project, I came across RSpec’s real advantage. Test::Unit is easy to write but practically impossible to read. I had no idea what was going on, and if a seemingly trivial change caused a cascade of errors, it took ages to root out the problem.

But RSpec is easy to read.

it "should not have a blank name" do
  @person.name = ''
  @person.should_not be_valid
end

And, ultimately, that means RSpec wins.

Why every small business needs an Organisation Chart

It may seem stupid, given that 3hv has one employee, but I have just created my Organisation Chart.

Why?

Well how else can I swan about on a golf course like a real corporate executive? You’re not no-one until you’ve got an Org Chart.

Well, actually, there is a real reason for it. And it’s nothing to do with golf (thank goodness).

You see, this Organisation Chart isn’t about heirarchy or reports or line management. Instead it’s about communication. Who needs to communicate with whom. And as I grow my team it’s important to have an understanding of who does what and who they need to support them. I’ve already started outsourcing some of the bits I’m not too keen on (more on this another day) and if I really want to do a Ferris then I need to know what’s going on before it gets out of control.

Even this simple chart has shown me stuff that I like to do (grey) and stuff I’m not interested in (white). With the light grey development box being something I like to do but will have to (somehow) hand over - it’s the core of my business so I need to keep my hand in, but it’s also the single biggest bottleneck.

It’s also brought about some surprises. Who would have thought I would want to do QA? There’s a story to that - and that will probably be coming soon as well. As for marketing, I know very little, but I’m going to find out.

So why not give it a go? See which of the many functions you perform within your business; then decide which you like and which you would do well to get rid of.

My Macbook Pro has no soul

Over the years I have had a number of Macs (I was late to actually own a Mac - my first one ran OS9, despite having been a Mac user for many years before that).

I’ve already talked about my heavy heart as I freecycled my iMac (G3, 500Mhz).

But last night, my 12″ Powerbook G4 died. It had been my workhorse machine for four and a half years, spending the last six months in retirement as my daughter’s DVD/Youtube/iPlayer box. She woke it from sleep, it clicked, clicked, died. Repeat. Click, click, died.

The reason it was retired was because it was bruised and battered to fuck. Four and a half years of being lugged about, every single day, to and from work, to and from clients, upstairs, downstairs, all over the shop. The combo-drive didn’t work. The hard drive had been replaced once, as had the (removable) memory chip. The clasp was nearly unusable as the metal was buckled around it.

It was replaced late last year by a shiny (refurb) Macbook Pro. An Intel dual-core 2.3Ghz job. Appearance-wise, not too disimilar (although this was a 15″, not 12″). Spec-wise, it beats the pants off the Powerbook (1Ghz G4). Rails tests took seconds instead of minutes to run on large applications. Nothing seemed to beachball. Multi-touch scrolling on the trackpad is fantastic (and something I really miss when I use other computers).

But (and it’s a big but) - the Macbook Pro does not feel anywhere near as nice. I don’t know exactly what it is.

The Powerbook was personal, intimate - it was mine. The MBP is just another, expensive, computer.

The Macbook Pro has no soul. The Powerbook had bags of it.

Why science is wrong

It was the 2nd Leeds Ruby Thing last night and a great time was had again. A smaller turnout than last time but some of the highlights included:

• Jamie from Engine Yard in a Brightbox t-shirt
• Dom discussing the pain that the Northcrew feel about Tom Smith’s “Northpack must die” article
• The trouble with smoking crack (it’s very moreish)
• Paul’s plans to quit his day job and join the ranks of the mercenary freelancers

And myself and James talking about philosophy. In particular how Wittgenstein and Nietsche were idiots and Descartes was the greatest ever.

Mainly because Descartes signed up for the army, in order to see the world. He then proceeded to spend the vast majority of his time laid up in bed. That’s how to be a soldier!

But also because of his solution to the “Mind-Body Problem”.

For those that don’t know, the Mind-Body Problem is an intractable one. Our senses lie to us. That is apparent. I thought I saw a person out of the corner of our eye but it was actually a tree stump. You misheard what I said. The water feels cold to this hand and hot to the other hand.

Thinking this through to its logical conclusion (as philosophers tend to) this means that actually, you can’t really trust anything your senses tell you. How do you know that you are not a brain in a jar, being fed false sense data continuously by some evil demon? Logically, there is no way of knowing. So Rene concludes his treatise by saying that the solution to the Mind-Body Problem is to have faith in God, for God is good and would not consistently lie to us.

This is also why Science is wrong. Science depends upon inductive logic. The “Scientific Method”, at its core, is about repeatability. If you repeat an experiment with identical conditions then the same outcome will occur. It takes hypotheses and proves them through consensus. This is not logically consistent. What if the demon is feeding you false sense data? You think the scales read 15g but actually you are weighing a three ton elephant? Just because yesterday the three ton elephant read 15g, and Dave in Hawaii weighed his three ton elephant and reads 15g doesn’t alter the reality that you were both weighing a 3 ton elephant.

You see, ultimately, science relies on faith too. Faith that what happened yesterday, in the absence of any other change, will happen again tomorrow. That is experential, not logical.

Logically, science is wrong.

The Second Leeds Ruby Thing

The Second Leeds Ruby Thing happens on Thursday the 6th March at Mr Foley’s, purveyor of York Brewery ales. No agenda, just excellent beer and talk about Ruby, Rails and all things geeky. And I promise not to talk about punching dogs again (ok - maybe that’s taking it too far).

As a taster, here is an example of the kind of quality guest you can expect: Gravy in yer Server.

Goals for 2008: February update

Sorry - been busy.  Really busy.

Just enough time to update you on my goals.

• Revenue: Up.  By more than 10%.  Probably enough to give me grief in achieving the target next month.  But that’s the idea eh?  Also explains why I have been so busy.
  SUCCESS
• Hours: Still over 40 per  week, but down on last month.  In fact, they’re only just over 40. FAILish - half marks.
• Marketing: I’m turning down work.  SUCCESS
• People: Geekup and now the Leeds Ruby Thing.  SUCCESS

Not bad at all.  Just the hours to sort out.

6 Rules for Effective Conference Calls

In this day and age the conference call is a fact of life. It may no longer be on the telephone - Skype, VOIP and iChat have seen to that - but a group of geographically disparate people trying to speak without any visual contact is an increasingly common way of doing business. And it has to be said that nothing beats face-to-face contact for getting your point across and getting things done.

Given that, how can you ensure that your conference calls aren’t a massive waste of time?

1. Always treat your call as a meeting
2. Publish an agenda
3. Shut down your email client
4. Shut down your IM client
5. Switch off your phone
6. Start early

Treat the call as a meeting - cos that’s what it is. Yeah, you can’t see their faces and they can’t see you flicking the Vs at the phone but it is a meeting and, if you don’t want it to be a waste of your time, treat it as such.

Publish an agenda - like any meeting you don’t want it to drag on or go off at a tangent. So publish an agenda, circulate it beforehand and, if you can, stick a time limit on each item.

No Email, No IM - they can’t see you and you can see the “unread count” going up and up. It won’t do any harm will it? Well it will. You’re not paying attention and it’s rude. One trick with IM - if you know your attendees addresses you can see their status. Are they online or offline? If they are online are they “available” or “busy”?

Switch off your mobile - Much the same as above - you’re in a meeting, so it’s rude to allow interruptions.

Start Early - I admit it. I’m crap at turning up on time; but most conference calls are in my office (a handy one minute walk from my bed). So even I have no excuse for turning up late. Instead get started a couple of minutes early. Everyone always takes a while shuffling their papers, reading the agenda (you did circulate it didn’t you?) and making smalltalk. So get that out of the way so you can start at 10 on the dot. And get the whole shebang over and done with.

Conference calls will never come close to the effectiveness of a real meeting. But, given that yesterday I spent 7 hours travelling 100 miles (thank you Network Rail), if you can make them work, they are essential to running your business.

Oh, and lastly, if you have the option, choose iChat over Skype. For whatever reason the sound quality is vastly superior.

Goals for 2008: January Update

No point having goals if you’re not going to follow through on them.

So here is my January score-card:

• Revenue. No 10% gain, in fact, it’s down on December. FAIL
• Hours: Averaging about 50 hours a week. FAIL
• Marketing: Outside help contacted, beginnings of a plan is in place. SUCCESS
• People: The last geekup was great, Jeremy and I have plans for a monthly Rails meeting and Northpack gets my name out and about. SUCCESS
• Debt: Total failure. I’m crap at managing my own money (good at the company money though). FAIL
• Car: Smaller car, cheaper petrol bill and I spend the time listening to podcasts, so it’s not entirely wasted. SUCCESS
• Freecycle: Not given anything away this year. I tried but my emails were not reaching their destination for some reason (?). FAIL
• Cooking: Yum. Yup, lots of that, and it’s good. SUCCESS

So a 50% success rate. Must try harder. How are you getting on with achieving your goals?

How not to do it

Everyone’s favourite shared host, Dreamhost, has had a major fuck-up. They accidentally billed a lot of their customers for a year in advance. Some of them were billed repeatedly. Some had accounts suspended for non-payment, others incurred overdraft and credit limit fees.

Ignoring the fact that it never should have happened (test, test, and test again where money is concerned), Dreamhost responded in their standard way. An update on their status page and a jokey blog post. The status page is good - an apology, they pinpointed who made the mistake (rather than hiding behind corporate anonymity) and stated what they were doing to set things right.

It’s the blog post I have an issue with. When you have made a $7.5million mistake (that’s what they claim the extra billing adds up to), you shouldn’t make light of it. When you have caused your customers to incur bank charges and fees, you don’t joke around. But, fair enough, that’s Dreamhost’s style (and originally one of the things that I liked about them). Where I really have problems is with this statement:

Really, it’s sort of amazing this never happened before in the last ten years.

When you’ve fucked up royally, especially when it comes from not testing your systems properly, you can’t (in a joking manner) say “ho ho, well it was always going to happen one day, it just happened to be today”. It doesn’t exactly fill me with confidence that it isn’t going to happen again in a couple of months.

It just ain’t good enough, is it?