#Rails

I’m a big fan of Padrino . It’s always filled this “more than Sinatra, no Rails bulk” gap for me while still being batteries included. Friendly community. Easy to understand and use. Most importantly, it’s helped me get apps built. Fast. And have them run well and without issue in production.

Case in point: A scientific app for a conservation NGO, chugging away happily without bugs or major issues for almost a decade ago (with a big upgrade 5 years ago) and despite traffic and time.

[Updated: 2013-01-08 - A lot of people asked for Postgres instructions]

After my faithful Macbook Air went down hard in Tonga, I was really surprised at the number of outdated posts, misinformation and general number of questions (even on Stack Overflow), on how to install a Rails dev environment from scratch on a new OSX 10.8 Mountain Lion machine.

This HOWTO runs from zero to getting you to what I consider a naked dev environment where you’re good enough to start and source control a project and issue a rails new command. It starts from a totally fresh install of Mountain Lion with all system updates.

You know, one of the things I love best about the Rails community is its sense of fun and how damn helpful everyone is in helping you learn in novel (and yet, really useful) ways. Cause, seriously? Programming shouldn’t be as hard as your first year comp sci class made it out to be.

Enter Rails for Zombies . Check it out, sign up and get learnin'.

Brrraaaaiiinnnnnzzzz…

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.

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

Um, I’ve done more than a few of these things with ActiveRecord in a Rails app. You probably have too. From the fine folks at the Engine Yard.

That’s Not a Memory Leak, It’s Bloat

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 !