threehv

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.

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.

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.

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.

“Agile” software development states you should try and get software out in front of people as soon as possible. Specifications are just documents, software is real – and you can’t get feedback, see what works or improve until what you have is out in the real world. 37Signals, creators of Ruby on Rails and Basecamp, call this the “Race to Running Software“. They even went as far as to launch Basecamp with no billing capabilities – using the 30-day period post-launch to add it in time for invoice day.

For the most part, I agree. Specifications are a dream, not reality. Paying customers pinpoint the important issues much more accurately than the development team. Working in small iterations means you always know where you are.

But it does have its downside – as experienced by the Northcrew at the moment. For as soon as you launch, you become public property. And if you are a success, as Northpack undoubtedly is, the public immediately wants a piece of you. “What are your plans?“, “Why doesn’t X do Y?“, “What about ownership issues?“, “What’s in it for me?” – all get thrown at you. And, having concentrated solely on getting something out of the door, this barrage must feel pretty overwhelming. Especially when it’s something done in your spare time, that costs you money and is given away for free (in Northpack’s case).

To be honest, I’m not sure what the answer is – you have to focus on the next stage, otherwise you don’t have a product. But you need to be prepared for three or four stages ahead or the barrage will drag you down. This becomes even more important if this is a commercial service – if you are taking people’s money they need to know what they will be getting for it. However, I’m not sure how divide your time between the very real needs of now and the potential needs of the future. Any ideas?

“Cyclists Racing” by sritenou.

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 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.

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.