Archive for Category ‘Life‘

 
 

Getting Rails 3 Beta Setup

If you use Ruby on Rails, you’ve probably heard by now about the release of the Rails 3.0 betayesterday. There’s been a lot leading up to this release, so naturally most of the rails world is eager to jump in and give it a try. Saturday morning is a great time to get started, so I decided to give it a try.

First off, I wanted to make sure I had a more up to date version of Ruby. Rails 3.0 beta and up will require Ruby 1.8.7 or higher. If you’re running Snow Leopard you probably already have this, but can always do a ruby -v to check your current Ruby version. The easiest way I’ve found to run multiple versions of ruby is using the rvm gem. It handles everything needed for running multiple versions of Ruby, including Rubygems. Just install the gem and go from there:

link:~ adam$ sudo gem install rvm
link:~ adam$ rvm-install
link:~ adam$ mate ~/.bash_profile
link:~ adam$ ruby -v
link:~ adam$ rvm install 1.9.1
link:~ adam$ rvm use 1.9.1
link:~ adam$ sudo gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
link:~ adam$ sudo gem install rails --pre

At this point, I tried to create a new rails project using the usual rails [projectname], but I ended up getting the following error:

link:research adam$ rails beta
/Library/Ruby/Site/1.8/rubygems.rb:384:in `bin_path': can't find executable rails for rails-3.0.0.beta (Gem::Exception)
	from /usr/bin/rails:19

A lucky comment in another blog showed a fix for this:

sudo gem install railties --pre

After that I was able to create a project the usual way, and start messing around the latest version of Rails. Looking forward to upgrading some existing sites!

link:research adam$ rails testsite
link:research adam$ cd testsite
link:testsite adam$ rails server

Giving Heroku a Try

If you haven’t heard of Heroku, you’re not alone. Heroku is a cloud host for Ruby on Rails driven sites that is relatively new on the scene. They’ve been in private mode for nearly a year, but recently their growth has skyrocketed. This growth is based on a few core features of their platform which are typically pain points for getting projects deployed.

What is Heroku

The trouble with most sites and descriptions of Heroku, is that they boil the service down to too small a line. The description on their site even goes this far — “Ruby Cloud Platform as a Service”. To put it in laymans terms, they’re a Cloud host for ruby websites (Rails, Sinatra, Rack, Merb). All Heroku sites run the same base base platform which includes some familiar faces if you’ve looked into Ruby hosting.

  • Operating System: Debian 4.0
  • Ruby: MRI 1.8.6
  • Ruby App Server: Thin
  • Web Server: Nginx 0.6.32
  • Database: PostgreSQL 8.3.5
  • HTTP cache/accelerator: Varnish 2.0.2

One of the most important things to me is that Heroku handles keeping all of these running and up to date. You don’t have to worry about getting a call that the database server has crashed, or one of the servers is out of memory — they do all that for you. You can think of it as managed hosting, but they’re managing a cloud rather than single servers.

  • Insanely easy setup
  • No Capistrano for Deployment – instead you just push to a git repository on their servers
  • No worrying about apache/nginx/mongrel/passenger – they just spin up a thin clients behind nginx.
  • Methods for simplifying many common tasks including database importing, exporting and site backups

Setup is Almost as Easy as They Say

Setting up you application to get on Heroku doesn’t take very long. Actually, during lunch at work today I got a Heroku app setup, just to try it out. You can follow the Heroku Quickstart Guide, so I won’t repeat it here. My only advice is to do everything you can from from the command line, rather than editing settings on the website. If your local copy and the remote copy get out of date (like if you rename an app for example), you’ll hit a speedbump and have to sift through the docs. The web management interface for Heroku is a beauty though, and coupled with the robust heroku gem, you can do a lot right out of the gate.

So after you get your database on Heroku migrated, you’ll probably want to load some data in it. Heroku has a very helpful command to get you started.

$ heroku db:push mysql://root@localhost/arcadefly_development?encoding=utf8

You only need db:push, but without the “utf8″ encoding specification, you may run into some problems converting from mysql to PostgreSQL. So far the only main difference in Mysql to Postgres for ArcadeFly (temp Heroku url until dns updates) is that I used 1 or 0 for booleans as strings in a few places. I changed these to true/false instead, pushed out the change and it worked fine.

Pushed out? Yeah you can deploy a heroku site with a simple git push. The initial setup already added Heroku to your git setup, so deploying is just pushing.

$ git push heroku master

They posted a Vimeo video about getting started that should help get an idea of just how easy setup is:

Creating an app on Heroku in < 5min from heroku on Vimeo.

Limitations when Using Heroku

Under Heroku you’re set a very specific set of server software, as you know from the above listing. These luckily cover the vast majority of Rails sites, so there’s nothing wrong with that. What you don’t get is full SSH access to the server that you may have become used to. Instead, most access is done using the Heroku gem. Here’s a few things that you can do.

You can jump right into a console on production:

link:arcadefly adam$ heroku console
Ruby console for arcadefly.heroku.com
- a = Arcade.first
=- #<Arcade id: 1, created_at: "2008-07-27 21:30:09", updated_at: "2008-07-27 21:30:09", name: "Rocky's Replay", permalink: "rockys-replay", phone: "(407) 260-0043", website: nil, notes: nil, profile_id: nil, playables_count: 44, frequentships_count: 3, owner_email: nil, owner_name: nil>

Using the heroku logs command, you can get the last bit of your production log real fast. Running rake tasks is as simple as heroku rake db:migrate. You never need to specify environment with Heroku — everything on Heroku is production.

Probably the biggest limitation is that there is no access to the filesystem except in /tmp. In order to save and manage files, you should instead use S3. Since Heroku runs on EC2, there is no file transfer charge for files between your S3 account and your Heroku servers since they are both in the same data center.

Expanding Heroku

It’s free to get started on Heroku. You can create a rails site with 1 Dyno (1 Thin server), have a daily cron job, get a PostgreSQL database and even point your own custom domain there. You can expand this with more thin clients, delayed_jobs and much more at a price. I like the idea of having delayed_job processes running in the cloud rather than possibly slowing down the site. Unfortunately there’s no public memcache yet, although it’s in private beta. I’m still just getting my feet wet with Heroku, but look forward to seeing how ArcadeFly does there.

Design Books for Developers

Designing the ObviousDesigning the Obvious is a book I ran into at Books a Million a few months ago. Usually when I head out to bookstores I grab a handful of books and end up scanning over them for tips, maybe reading a few relevant chapters, then putting it back. Very rarely do I end up reading through the entire book at one sitting at the bookstore. That’s just what happened with Designing the Obvious. After reading through the entire book I put it back on the shelf as usual. On a second trip to the same bookstore later I ended up reviewing most the book, gleaming new shreds of information from each chapter. Rarely have I spent so much time on a book, better yet seen relevant bits a second time through. Eventually I ordered it from Amazon and have re-read most of it since then. If you want to check out a sample chapter from the book, it’s available for free on the authors website.

Designing the Moment The author, Robert Hoekman, Jr., also has a second book coming out just this week called Designing the Moment which seems to pickup with more concrete examples and run with them. Obvious was more general in what you want the user to think and what you want to convey in your app, while Moment seems to be more about analyzing actual examples. Anyone interested in creating kick-ass interfaces that people love to use should consider reading both of these. Moment comes out this week, so it’s a good time to grab one or both if it’s a topic you enjoy. Like Obvious, there’s a sample chapter on the authors website.