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.

BTW, Ryan Bates’ Railscasts episode 200 is a great step-by-step screencast on this same process if you prefer his mellifluous tones.

The easiest way to do some checking seamlessly is to install RVM (Ruby Version Manager). This creates compartmentalized ruby environments for you which means you can leave your current ruby environment (system) in place while playing around with ruby 1.9.1 and Rails 3 (you only need 1.8.7 to use Rails 3 but ruby 1.9.x is much faster than 1.8.x so use it). Install rvm and then type

rvm install 1.9.1

Grab a cuppa joe as it’ll be a while downloading and installing. You can also add some options here to get the x86_64 version and such (since this’ll go 386 on ya), I’ve seen the following?

When it’s done, go rvm 1.9.1. Check it’s switched with ruby -v. You should see ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]

Then it’s a simple matter of installing gems. Make sure you don’t use sudo gem under rvm since rvm modifies the $PATH to work its magic, use rvmsudo. You can use straight up gem install but when I tried this I got permission denied errors.

So, then just paste the following in your terminal (you have to install dependencies manually) :

rvmsudo gem install tzinfo builder memcache-client rack rack-test erubis mail text-format bundler thor i18n
rvmsudo gem install rails --pre


You’l also need a database store of some desciption. sqlite is the default so you’ll need to install this :


rvmsudo gem sqlite3-ruby


Personally, I never use sqlite, and find MySQL is what I like for dev, and most people will be using it, so if that’s you too, you need to do the following :


env ARCHFLAGS="-arch x86_64" rvmsudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config


That’s it. You’re all set. To create your first Rails 3.x app, just type


rails your_app_here -d=mysql


And off you go.

He was right (of course) so I set about grabbing the heroku gem and did a quick once over on the documentation. The app was a fairly simple thing I threw together for an internal issue we have.

So, first off… Yeah, Heroku is dead easy. App create and app pushing from git is a dream. I have to admit, a git push, the spin up on the slug and the fact it was there and running were all a testimony to some very, very clever design and well thought out decisions in terms of making deployment painless.

Add-Ons are mind-blowingly great. Want custom domain configged ? Check! Monitoring, Exception and Performance checking? Check! Post deploy email notification? Check! Oh email send outs? Check! Cron set up? Check! And you can do it from the command line on top of that or the very slick web interface.

So, really this post is more about niggles than anything substantive since there is a part of me that felt deployment was a bit less than painless because of the things I didn’t know about Heroku. I’d also suggest Heroku needs something like a Rails scrubber to check those parts of your code which would work on a traditional server but won’t work on Heroku because of the differences that have been necessary there to make it work so flawlessly. Cause generally, if something works on my dev flawlessly, passes all tests and then flames out on Heroku when I spin it up, I personally find causes pain.

So, just some things I noticed that made it not so painless for me. And before anyone thinks I’m slamming Heroku, I’m not. I’m definitely, definitely impressed. This post is in the spirit of making Heroku better because, to be quite honest, I think they may have a knock-it-out-of-the-park winner here with a few tweaks and people becoming more familiar and comfortable with it as a service. And let me tell you how huge a fan of capistrano and having root access to my servers I am. In fact, Heroku’s caught my attention enough that I’m rethinking whether it might work for our new campaigning platform here at the ranch.

So…

1. First minor kvetch: Why on earth do you need to use a gem bundler or a .gems manifest (I used the latter)? Surely, with all the gems properly laid out in my environment.rb via config.gem, Heroku should just scan this and it should just work.
2. My second app blow up came when the front page wouldn’t load. Again, no really good error messages until I went to look at the logs (I do like heroku logs though) and it identified the line with the problem. Turns out Heroku has a read-only file system so you can’t do page caching and I had conflated the four stylesheets I had into one base stylesheet via the :cache symbol (who wouldn’t ? It speeds things up.). Removing that let me see the home page.
3. Surprisingly, a minor glitch with the SendGrdi add on caused quite a bit of time for me. Running heroku rake db:seed kept throwing errors apparently because it couldn’t connect to a mail server, but kept giving me the cryptic error Connection refused which made me think there was a problem with the database connection (Anyone know how to suppress a mail out for seed creation when you’re creating objects for a model with an observer on them?) Anyhow, I used heroku rake db:push via the taps gem in order to get round that, which was good, but felt a bit hack-y.
4. Normally, in my capistrano deploy.rb file I place a file of the latest git revision to be in the footer for bug reporting and just general “what did I put up there?” kinda review. Doing this on heroku is a bit tricky I gather. I installed a grit gem, and then used it in the application helper to reference my .git directory, created a last_commit method and then reference these in a partial in the layout. Kaboom. Turns out accessing a git repo is expressly forbidden, so removed the git revision. Minor, but annoying. Anyone got a workaround ?
5. Another minor kvetch is about how you access cron. OK, now this makes sense but doesn’t mean I can’t be crotchedy about it (in fact, it’s a good solution considering, but they should have a – “how you may need to change your app” kinda thing). So, normally, I use javan’s fantastic whenever gem (which is the bomb) through the cap deploy to have fantastic control of cron. Heroku only let’s you run crons daily (or, for a little extra, hourly) which means you need to add a cron.rake file with a rake cron task to your system which gets triggered via time checks. OK, fine, not so bad, but it’s not obvious and extra code you need just for Heroku. Fair enough though.
6. The last very minor issue was the fact I had a problem when I installed SendGrid as an add-on as I mentioned above. For some reason, it didn’t take and I couldn’t figure out why I was getting an auth error. Turns out it is automagically configured (bless you, heroku), but some weird glitch they’ve got going on means some accounts don’t work right away. You need to remove the add-on and add it back in again as per this post in the heroku google group and everything works aces. Special thanks to user hone in the IRC #heroku group who pointed me at that (you rock, sir). So, this is not really a problem though it did make me waste an hour thinking it was something I’d done wrong.

Overall though, I have to admit I am very,very impressed. The app is sitting there and running quite snappily (varnish, I assume?) and considering it’s the first time I’ve ever used heroku, I’m astonished. Using EC2 had an obviously much higher learning curve just to get the server set up to eventually deploy to.

It’s definitely got me thinking that I need to run some cost estimates on Heroku as an infrastructure competitor for the new platform (especially if we could somehow scale background workers and dynos automagically for when we do campaign send outs and actions. Hmmmm…. ).

I particularly like his point on diminishing returns to adding new features and maintaining things that new web frameworks take for granted (ok, mostly because I agree with it )

We’ve actually taken almost exactly the same decision at GetUp! though we’ve decided to standardize on Rails and Ruby as our weapons of choice.

Anyhow, will be looking forward to seeing more posts on this subject. Would love to know of any gotchas they ran across in the transition.

Rails + Google Analytics = easy goal tracking

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

The recent move and new architecture has resulted in noticeable speed benefits, at least from the user side. So, it’s super interesting to read about what they actually did backend to accomplish this.

Also, nice to see some cutting edge Rails performance and scalability architecture discussed.

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

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

Also, if you’re still listening to FUD about Rails not scaling, this is a good place to start your ed-u-ma-ka-shun.

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

Being an old unix dog, 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 and then come back screaming at you that your code doesn’t work.

Enter whenever. Basically, it’s a nice little gem you can install to handle all your cron pain. It’s one of those things you don’t even realize you really need till you install it and start using it.

Took me about 10 minutes to branch git, config whenever via the handy DSL in the schedule.rb file and then deploy it via capistrano to get auto-updated cron tasks on each deploy to an app I’ve got in production. Bliss.

I’ve liked it so much (and I use rake so much), I’ve actually dropped it into my alakazam Rails 2.3 template for revving up and starting new, and fresh Rails apps all the time (ok, admittedly, probably not the highest praise in the world, but I do only select the best… ).

If you’re thinking of using it but want some examples, check out the Ryan Bates’ RailsCast on whenever.

Dr. Nic still loves Cucumber too. Really like this article on the nitty-grtty details of testing outbound emails using Cuke.

Sphinx and Rails goes together pretty much like chocolate and peanut butter these days and we’re using it on at least two production projects at AI, as well as it being a favourite of mine for personal use.

The article is particularly good in showing how Sphinx evolved in response to search engine issues from using MySQL full text search and Apache solr and lucene in other places. Immensely useful to understanding the often murky world of search and information retrieval dark arts and why you want to use sphinx instead of just jamming in whatever seems like a safe bet for what is often one of business’ biggest beef with database systems (getting stuff back out of them). Particularly since scalability and relevancy of results are seemingly becoming increasing issues with both of the more traditional solutions to these problems.

Worth your time to read if you’re not up on Sphinx. I’ve been very surprised at how very few people seem to have heard of Sphinx outside of the Rails community.

“A very interesting observation during the talk was that Twitter started up with a CMS model and that they gradually moved towards a messaging model. I’ve seen this in a few applications so far, including a casino system, where the messaging model seems to fit best an application intended to power massive community of online users, it seems regardless of what the application actually does business wise. Applications start out completely different, but then more and more functionality gets bolted on top of user messaging capabilities that the whole architecture on the end gets refactored to utilise the messaging channels as the core information transport.”

- from Gojko Adzic » Upgrading Twitter without service disruptions

I can’t agree with this statement enough. It’s amazing the assumptions starts with and how a system really get used and evolves (particularly, one that’s actually useful).

We just ran into this same problem in a big way with an in-house ProjectsDB system that aligns money, people and effort with organizational goals. Originally, this system started off as a way to propose projects and quickly bolted on functionality to do many sorts of things (and was originally planned to have a datamart complement project for reporting and analysis to work across this and a handful of our systems).

As the org needs evolved, though, and as the appetite for the value of the app increased, the initial model and assumptions for the application changed dramatically, which ended up pushing the app in a direction untenable with its original architecture and design.

We just finished a new release (live Friday!) which refactored the underlying code base and data store (it’s now running on a MySQL RDBMS and a CouchDB key-value store) as well as doing a big usability pass on it (Have I mentioned lately how much I lurv Rails ? I can’t imagine having done this refactor in another language and framework).

This is one of the reasons Agile as a dev methodology has been working so well for us in the switch away from more static waterfall models at Amnesty (read: Prince2). We’re still working on educating senior management on what that exactly means, as I think the prevailing model in business here in the UK is more about buying or building a system and then just “maintaining” it into decay and replacement rather than having systems continually evolving, but the benefits in terms of what we’ve been able to get out the door has been impressive compared to (IMHO) what’s been done in the past.

How does this sort with other experiences of systems they’ve had to construct in-house, or implemented ? (actually, I imagine this would bring out some pretty big disaster stories actually since fixed and unchanging initial assumptions seems to equate with software death) Wondering. Seems a big sea change being driven in web deevlopment but taking a long time to trickle down to enterprise IT.

Oh, also here I should also thank the hard work of our patience-of-a-saint, long suffering dev, Matt F. (who we wish the best of luck to as he’s leaving to go indie and start his own dev shop with his fiancé) and the continued support of our face Rails propellor-heads, the jolly pandas over at New Bamboo.

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.

Easy to use ? Haven’t tried it myself yet (will post when I have), but this little howto from one of the boffins at github makes it sound like it’s super easy peasy. Going to try it with one of the smaller apps I’ve got running to see how it runs. Will post impressions. You don’t even need to use capistrano for the deploy (though I really love cap personally and think that’s a downside.).

Admittedly, I’d rather deploy via capistrano anyway (cause even php boffins should be doing it that way) since it is fabulous and does deployment like it should be done, but there is something to be said for the wonderful mod_php under apache. Configuring proxying and mongrels under either apache or nginx is simply not fun. It feels like work.

This blog, and other subdomains on wakatara were first running on nginx and mongrels for the longest time. I’d since moved back over to apache since I needed the domain to do a few other things that nginx would have required too much futzing over, but with people like 37Signals moving over to passenger (or mod_rails as it’s sometimes known) it seemed like a good move to simplify the overall fussiness of running too many mongrels behind apache and simplifying my maintenance, deploy and monitoring complexity.

Anyhow, moved things over in roughly half an hour of work (and that’s erring on the side of long, it was very fast to make the move) and the server now seems to have a _lot_ more free memory overall, as well as definitely being way more responsive. Where I had roughly 10 MB free before, killing off 2 mongrel clusters of two mongrels each and a single mongrel for a wiki has freed up a whopping 175 MB (!) when the site is being hit (300 MB when it’s not that active !). And that’s ginormous memory savings. We’ll see just how stable that is over time and load though.

I also have to admit to loving how to bounce the servers as well as it no longer requires clustering commands and the like.

Will follow up with some “living with” posts later on over the end of year break I’m taking from work.

In case you wanted to repeat the same, here’s how to install Phusion Passenger (mod_rails) on Ubuntu 8.04 server.

Passenger compiles a module for apache2, so requires Apache2′s development headers. Ubuntu being minimal doesn’t put this in up front, so install the following (the passenger install would tell you to anyhow) :


sudo apt-get install apache2-prefork-dev


Once that’s all done, then it’s time to install Passenger itself. Couldn’t be easier if you’ve already got your Rails and gem stacks installed


sudo gem install passenger


yep, that easy… then you need to compile the apache2 module. Quite simple as well :


sudo passenger-install-apache2-module


The command id nice and walks through the compile and lets you know what you need to do.

After it’s done, it tells you to copy the following lines into your /etc/apache2/apache2.conf


LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.3/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.3
PassengerRuby /usr/bin/ruby1.8


If you haven’t got it already going, make sure you’ve got mod-rewrite enabled on apache2. You can check your /etc/apache2/mods-enabled directory to see if it’s active or just run the following :


sudo a2emod rewrite


Now you’re basically good to go. Create a nice vhost file like subdomain.domain.com in /etc/apache2/sites-available with something like the following :


ServerName subdomain.domain.com
DocumentRoot /path/to/subdomain.domain.com/public/


Note, that if you’re like me and have deploying via capistrano, the DocumentRoot will be something like /path/to/subdomain.domain.com/current/public . Quite important, as the next step is to change your cap deploy recipes to make your life easier.

That’s about it actually (I had to shut down some mongrels and comment out some stuff in my vhost files from the old apache to mongrel cluster setup but basically if you’re starting from scratch, right now you just have to upload your files or cap deploy them to the same location).

Then to get it all going just :


sudo /etc/init.d/apache2 restart


And you should have everything running on passenger instead of mongrels.

We do have some of the issues he mentions in Prioritizing Your Product Backlog in our agile development, and I’d have to say we don’t spend enough time “grooming the product backlog.” We do spend a good week between iterations, thinking of the focus of the design goals of the next iteration and writing new user stories.

Interestingly, we have noticed as well, the difficulty in prioritizing at the story level rather than epic or theme level so I thought this was a pretty nice presentation.

Really liked the idea of Kano analysis as an additional screen on the product backlog : exciters/delighters, and mandatory/baseline. Particularly the idea of driving that via a simple survey of just a few tens of users – a functional questioning asking how people feel if it’s present and a dysfunctional question asking how people feel if it’s absent.

Bit long, but definitely worth your time if you’re using doing agile development and working with a product backlog (doubly so if your backlog is more of an attic that never gets looked at). Weird little thing, note the slides appear below the video of Mike doing the hand waving and talking which makes full screen not so useful on it. You’ll miss important stuff… so maybe move the browser down 1/8 of the screen before starting the presentation.

(via someone, but I don’t remember who… =< )

I’m here attending RailsConf Europe 08. Some of it’s been incredibly interesting and useful, some of it strange and almost incidental (why is everyone obsessed with performance and JRuby all of a sudden ?).

More details and write up to follow when I’ve got a chance.

Very nicely executed social networking site based on activism, sharing and discussion. Just wondering what they used to get the base done. Inososhi ? LovdByLess ? They even managed to incorporate the new visual Global Identity and reconcile it with AI UK’s current visual scheme.

That is one of the things I love most about this stuff; the fact that with a laptop and a connection to the internet, you can mock something up, deploy it across the globe and have a site up and running in no time flat (or a little longer if you’re me).

Anyhow, merhaba de turkiye everyone. The weather is absolutely brilliant here and (while I’ve managed to get a vicious sunburn somehow) I have to say it’s a nice break. Here for a few days for work and then going to be kicking around the Turkey’s Western Med coast and the South Aegean and terrorizing the poor, unsuspecting local populace. Details for the trip are here

Anyhow, along with the move I decided to also drop WordPress . Don’t get me wrong, it’s an excellent piece of blogging software and I have to admit, I may be back there if blogging becomes a bigger dev chore than I want, but the fact is, one of the main reasons I keep these servers running is to keep my hand’s on skills from getting too rusty and blunt and I simply wasn’t learning anything from having wordpress as the bog platform. And fact is, I’m really loving my re-discovered interest in programming and webdev while working with Rails , so I took a loook at the options, and in the end it came down to the excellent mephisto or simplelog . I chose simplelog because of its more compact feature set and the fact mephisto 0.8 has stripped out xml-rpc posting which is kinda key for me (I’m using the excellent MarsEdit to post this up now).

The theme is a bit barebones but as soon as I’ll get some time, I’ll change it to something I like. One of the nice things about the theming is that it’s straight up Rails, no templating or other stuff, so I can do something hopefully simple and elegant without getting myself into too much trouble.

A few little things need to be fixed up. Migrating from wordpress was a bit rough and I also wanted to clean up a whack of kruft that has accumulated over the years in the blog as wordpress changed the way it did things, so needed to actually write migration scripts to get things over and then also wanted to move all the photos I’ve posted statically over the years to flickr (which has now been done !).

Anyhow, welcome to the new blog. Hopefully, it’ll also give me a better excuse to not let it lie fallow as well.

Ruby on Rails is astounding. Using it is like watching a kung-fu movie, where a dozen bad-ass frameworks prepare to beat up the little newcomer only to be handed their asses in a variety of imaginative ways.

- Nathan Tarkington, O’Reilly Publishing