#Ruby

If you’re a CTO moving heavily into cloud services, one of the things that keeps you awake at night is what happens if one of your providers goes under or just becomes so unreliable you have to move. Let’s face it, lock in goes along with the cloud as the fact of the matter is you code to exploit a specific platform.

The amazing thing about Fog is that it acts as a universal interface in front of the cloud, allowing you to control a variety of cloud services though a unified API. It deals with both servers and storage already supporting EC2, Rackspace servers, vCloud and Slicehost and numerous cloud based storage vendors S3 and Rackspace Files.

I’m posting this because someone I did a Hack night with hadn’t yet checked out the awesome rvm in order to muck around with Rails 3. If you’re a Rail or Rubyista you need to install it and start messing around with 1.9.x and the wonders that are Rails 3. Here’s how.

Rails is now at beta 3 which means a release candidate is right around the corner. While fundamentally more complex under the hood than 2.x (though the devs claim it’s easier to understand now), 3 provides some fundamental advantages (and some key changes) you probably need to get up to speed with if you don’t want to be left behind.

One of the things I really love about the ruby community is its inherent sense of fun. Beside the fact there are a lot of really smart, talented and very creative devs in it and at the RailsCamps (at least here in Aus), and some of the best stuff is just the things they whip up in their more whimsical moments.

One of these has to be rubywarrior (thanks to <Ritchie K. for introducing me to this one at Railcamp 7 in Canberra). Written by Railscasts stalwart Ryan Bates it’s there to teach you Ruby. And it rocks.

I have to admit to have become more and more enamoured of heroku for production class hosting of Rails and Ruby applications. It makes things pretty painless (see my first post on gotchas for my first deploy there) and for Nunemaker’s rather strong sentiment, You’re An Idiot for Not Using Heroku .

It does kick ass if you’re getting stuff up fast, but if you’re moving into more serious production environments with multiple devs and you also need a staging environment, the simple git heroku push master gets to be too simple. You really need something capistrano -esque for managing deployment even to heroku.

My new place is moving from being a startup to having to put in places some things you need for the longer term running of a charity. So, I’ve been fiddling with a few apps. I’d deployed one which works perfectly in dev and test and one of my staff, when I said i was about to spin up an EC2 instance to host it, mentioned it was small enough we could run probably run it for free on the everyone-gushes-about-it Heroku (which is something I’ve thought about some of my other personal apps).

If you’re upgrading to Snow Leopard this week, and a rubyist, you’ll need to sort out your dev environment again and the awesome HiveLogic has provided some great updated instructions (though I can’t tell if this works with 64bit MySQL as I know that was a gotcha for me last time I upgraded).

Happy upgrading my geeky friends ! I will be doing the same as soon as I get to Oz (or slightly sooner if stuck in Honkers longer).

At some point all web applications and sites, if they’re popular, need to think about how to scale past their database bottleneck. All the big boys these days are using memcached, and with very good reason (even those not using Rails).

Rails has fantastic support for memcached and this great screencast bad link from the guys at RailsEnvy goes over when and how you should use it in your app with some very good real life examples.

I use rake tasks pretty much, well… everywhere in my Rails programs. They’re amazingly handy for automating things I want to keep track of, mailing things out to people regularly and just generally doing useful stuff.

Firing them on a timer though usually involves going in and manually editing cron with the infamous crontab -e

Hand-edited is no problem for me, but when distributing code it is a little annoying since you usually have to put instructions in for people to do it manually and its one of those things people always forget to do.

I’ve become a big fan of Cucumber in a very short amount of time. Mostly, because it’s enabled us to translate user requirements quickly into step by step instructions we can then code to. Especially with the turnover in staff at AI this means that business logic, reasoning and behaviour lives in the app and can be reviewed without a lot of overly hefty documentation and such. Write code to reflect behaviour, test, deploy. Voila, app done !

Devs hate dealing with infrastructure. They’d much rather code solutions than worry about whether the servers have been updated, a piece of software is there or the environment differs from what they have on their development boxes.

Amazon EC2 started it (though really you still need to manage the hardware), Google app engine (if you like python) followed, and Heroku made it seemingly effortless to deploy and run Rails apps. It’s now following with pricing plans, both Shared and Dedicated that can handle production deployments (I love the pricing tier names : Blossom, Koi, Crane, Ronin, Fugu and Zilla… ;-) ). IaaS (Infrastructure as a Service) is now becoming the increasingly accepted standard for devs in both startup staging and business production.