A lot of people have asked “What is the best way to get started with Ruby on Rails?”. The first thought I (and probably lots of others) have is to start out with the basics of Ruby and work your way up. After all, this is typically how programming is taught in school – you start out learning lower-level basics and then after some time start actually building useful stuff.
I’ve come to think that maybe learning Rails itself first and then learning Ruby and more advanced Rails concepts as you need is probably a good thing. I wouldn’t recommend cranking out an important production website your first weekend using Rails, but you certainly can go beyond the usual “Hello World!” apps. The benefits to this are:
1) It keeps you interested.
2) You get something immediately useful.
3) You can learn the stuff that is most important.
4) You’ll probably learn better if you actually apply the stuff you learn in an interesting way.
So, where to start?
There is a great online tutorial here. I’d recommend reading Agile Web Development with Rails to start getting into Rails. After you are done with that, the Rails Cookbook book is pretty cool. It has solutions for a bunch of common tasks you’ll face.
After you learn a bit of Rails, you’ll quickly find yourself needing to learn a bit of Ruby. Programming Ruby: The Pragmatic Programmer’s Guide is a great book for that. Like the Rails Cookbook, there is a Ruby Cookbook that is pretty handy to have around.
You’ll probably want to start deploying your Rails apps before long – after all, what good is a web app that is just running on your computer locally? We have a great directory of shared Rails hosts that will be cheap for you to use while you learn Ruby on Rails. DreamHost seems to be a favorite of developers starting off with Rails – they support Rails, are pretty cheap, and have lots of developer tools. I personally use them and highly recommend them. (Be sure to use the coupon RAILSSTARTER to save $40!)
Now, where to head for help? RailsForum is quite active and you can usually get help pretty quickly there. SitePoint also has a Ruby forum, although it isn’t quite as active.
Good luck, and have fun learning Ruby on Rails :)
Creating web applications with Ruby on Rails is extremely easy. Deploying them isn’t always as easy. I set up my Rails Hosting website to organize information about various Rails hosts, and thought I’d write a guide to choosing a host.
Let’s start off by taking a look at what isn’t very important.
Space and Bandwidth
Lots of hosts try to lure people with generous space and bandwidth (or transfer) allowances. Indeed, they are easy to compare on because you can compare two numbers quite easily, but are they really that important? Probably not. Most web apps are never going to come close to needing GBs worth of space, and the same goes for transfer. Don’t follow the temptation to worry too much about these unless you know for sure that you are going to need a ton of space and/or bandwidth.
Price
Price is another thing that is easy to compare, and a lot of people do use price as the primary factor in choosing a host. Why is that bad? Well, sometimes you get what you pay for. If your site is down or really slow for even a small amount of time, is it worth the $5 a month you saved? This is less so for developer accounts where you just want to mess around, but even then, dealing with a bad host is usually not worth any money you save.
So, what are the important factors?
The Type of Server
If you are running a big site, or lots of smaller sites, you probably should look at VPS solutions instead of shared accounts. If you get really big, you’ll want a dedicated server.
What software are they running?
A lot of people like Mongrel instead of the typical Apache + FastCGI setup. Mongrel is generally more reliable, but the Apache + FastCGI setup usually lets you host more sites. Be sure you find out what software your host uses. You can use our site to see hosts that use: Mongrel, Apache + FastCGI, or even allow multiple types. If you buy a VPS with the intention of hosting a lot of sites, Mongrel may be tough to use – it generally needs between 30 and 60 MB of RAM per process, and you can only tie one application to a process.
How much control will I have?
Some shared hosts give you very little control. DreamHost is a shared host, but you do have SSH access and a fair amount of control. SliceHost gives you root access to your box and very little else – great for people who know what they are doing and want to setup everything for themselves. SpeedyRails is on the other end of the spectrum, handling virtually everything for you but not even giving you FTP or SSH access.
How knowledgeable are they about Rails?
Good Rails hosts that know a lot about Rails are very good at helping you out when you run into weird problems. Companies like RailsMachine are focused on Rails hosting, whereas some shared hosts you see only offer Rails as one of many options and don’t have a lot of in-depth knowledge.
How good is their support?
Before you buy, check for documentation on their site, browse their forums, and look through their Wikis. Read reviews on them where you can.
These are just a few thoughts I had after a week or so of messing with various Rails hosts. Feel free to add your own tips.
I wanted to display posts from this blog onto another site I run that is written in Ruby. I found a quick way to do this.
First, you’ll need to install the simple-rss gem (gem install simple-rss).
Next, require it and open uri in the class you are editing, ie:
require 'rss/2.0' require 'open-uri'
Now, use code like this to grab the first n headers (5 in this case) and put them into an array that you can use on your frontend somewhere:
begin
open('http://articles.rails-app-hosting.com/?feed=rss2') do |http|
return RSS::Parser.parse(http.read, false).items[0..5]
end
rescue Exception
return []
end
I am rescuing the exception in case the site is down or the feed gets messed up – you don’t want your whole site to quit working because an rss feed is down!
One problem with how easy it is to get a lot done with Rails is that you don’t always have a good idea of what is going on if you don’t know much about the underlying Ruby language. I have to confess – I am pretty guilty of this at times. One problem I ran into was building select boxes. I saw an example that looked like:
<%= form.select :rating, {"5 - Best" => 5, "4 - Good" => 4, "3 - OK" => 3,
"2 - Not Good" => 2, "1 - Poor" => 1, "0 - Just Terrible" => 0}%>
This worked, but my options were out of order! Looking around, a lot of other people ran into similar problems. The problem was simple – the example was using a Hash, which is unordered. Switching to an array like this:
<%= form.select :rating, [["5 - Best", 5], ["4 - Good", 4], ["3 - OK", 3], ["2 - Not Good", 2],["1 - Poor", 1], ["0 - Just Terrible", 0]]%>
Fixed the problem, because arrays are ordered.
So, it is important to learn the underlying language, even if a lot of stuff is really easy :)
I think I’ve gotten the art of deploying a rails app on a DreamHost down, and a few friends have asked for a quick tutorial, so here it is. Once you learn how to do it, you can get a new app up and running in 5 minutes or less.
This assumes you know how to use Subversion and want to use it. It also assumes (of course) that you are using DreamHost. If you are using another host, some of the steps may still be helpful. If you are interested in trying out DreamHost, read our review here.
1) Make sure your current domain has FastCGI support (you can view/change this on the manage domain -> edit screen).
2) Setup a subdomain for your site. I use something like resources.mysite.com, then setup a mySQL database and SVN repository using the subdomain you just created. This takes a few minutes to do.
3) If you haven’t started your Rails project yet, checkout the project and then run rails to build the project in the svn managed directory. If you are trying to deploy an existing Rails app, you can use svn import to import your files into the repository.
4) Update the production section of your database.yml file to point to the database you just setup. You’ll need to add another attribute called ‘host’ that points to the subdomain you just setup, ie – host: resources.yoursite.com.
5) Check everything in.
6) On the server, check the project out into a subdirectory of the site you just setup.
7) You’ll want to go into that directory and run your migration scripts. First, you’ll need to set the RAILS_ENV variable (ie, export RAILS_ENV=production).
8) In config/environment.rb, there is a line that says “ENV['RAILS_ENV'] ||= ‘production’” – remove the # to uncomment the line.
9) In public/.htaccess, on or around line 32, it says “RewriteRule ^(.*)$ dispatch.cgi [QSA, L]” – change the dispatch.cgi to be dispatch.fcgi.
10) Now you need to get the dispatch.fcgi file. The easiest way to do this is to go to a different directory and create a new rails app (ie, rails temp). There will be a dispatch.fcgi in the public directory – copy this over to your real project’s public directory. I did this once and then copied the file to a common place so I wouldn’t have to create a new rails app for each project.
11) In your DreamHost control panel, edit the domain this application is running on. There is a setting called “Specify your web directory:” that probably currently has “yoursite.com” in the text box. Change this to “yoursite.com/your_app_directory/public”.
Your app should be up and running now – try it out :)