Mike's Idiosyncratic Rails FAQ

The Rails Guides site has a good deal of reference material for intermediate developers, including a "Getting Started" tutorial. The Rails Wiki has information on installing Rails, as well as another tutorial. If you prefer a printed book, the best reference for beginners is Agile Web Development With Rails, which is available in both electronic and printed form. Be aware, though, that Rails moves so fast that every printed book is out of date before it is published.

This is an IRC channel full of Rails developers. We use Rails because we find it to be productive and enjoyable. "Better" is a meaningless term in a vacuum, and most of us don't use anything else. So you're not likely to get a balanced view of the differences between frameworks in #rubyonrails - or, really, anywhere else on IRC.

Generally, you should use the most recent stable Rails in production applications. In late 2009, this means Rails 2.3.5. If you run into a specific bug, you may want to move to "edge Rails" - the most recent version at Github. If you do move to edge Rails, stick to the 2-3-stable branch in the repository: the master branch is where the work for Rails 3 is currently being done, and it's not stable enough for most production applications.

There are many choices for getting pages from a Rails application to the user's browser. For beginners, the easiest one to start with is generally Phusion Passenger.

There is no "best" - it depends on what you need. The cheapest possible hosts can be tricky to set up for Rails, though people have reported success with Dreamhost. Slicehost, Linode, and Rimuhosting are among the hosts that provide affordable VPS's with easy Rails setup. At the high end, you can move to a fully-managed host from RailsMachine or EngineYard, though that's seldom necessary for beginning developers. Heroku and WebbyNode are doing good work in integrating Rails projects for easy hosting as well.

Rails 2.3.2 (the first release version of Rails 2.3) is the first version of Rails to be tested with Ruby 1.9 (specifically, with Ruby 1.9.1), and all of the internal Rails tests pass with that combination of versions. But it's important to realize that your Rails application will use a great deal of code that is not a part of core Rails, including database adapters, gems, plugins, and servers. Whether you have a successful experience with Ruby 1.9 will depend on the compatibility of those other pieces with Ruby 1.9.

You can, but you may not find it a pleasant experience. The Rails core team does not use or test on Windows, so bugs have a higher chance of showing up there. And many of the most prolific Rails developers use OS X or Linux, leading to much of the online advice being directed to those operating systems. Nevertheless, there are certainly people managing to develop, and even deploy, Rails sites on Windows. A good starting point if you choose to travel this path is the Rails Wiki Installation Guide.

You need to do two things. (1) Update the old, old rubygems that OS X ships with. See the Rails Wiki Mac Installation page for instructions. (2) Install Xcode from your OS X distribution disk. You may not want Xcode for anything, but that's where Apple hides a bunch of necessary header files.

You're not alone. Actually, getting MySQL itself installed is pretty easy, but getting MySQL and its Ruby bindings to work with Rails on OS X is a nuisance. Two things to try: (1) Use 32-bit MySQL instead of 64-bit (2) Use Macports to install everything you need to get started with Rails on OS X; Justin Blake has written some simple instructions for this.

Oh, you want my Migrating to Snow Leopard for Rails Development - A Definitive Guide.

Whichever one you like. You will find proponents in #railsbridge of Test::Unit, Shoulda, RSpec, Cucumber, and others, along with a variety of factories and generators. The important thing is that you do test, not so much which library you test with.

Yes. For small Rails applications, it doesn't really matter. Any performance issues you hit in your database are more likely to be related to a lack of indexing or poor application design than any real difference between the various database engines. If you're careful in your coding, switching databases later is not that difficult, but that isn't a problem you'll need to face until you get substantial traffic.

Yeah, good question. You'll find some information at the API topic for TableDefinition#column, but a better source is the Rails Migration Cheatsheet from Dizzy. The Migrations Guide is also helpful.

Rails dynamic scaffolding no longer exists. It turned out to be a bad idea and was removed from the framework. Rails still has scaffolding to help you build things quickly, but now it's implemented as a generator rather than built-in framework magic.

Great! Go use Django if you like it better than Rails. Rails doesn't do that, and so far it appears unlikely that it will do that, despite a constant flow of people comparing Rails with Django. Or, go have a look at admin_data, which does a pretty darned good job of building a CRUD admin UI for you.

Did I say that? script/generate scaffold is a fine way to get a new model and controller and views with CRUD functionality up and running quickly, especially if you're not real concerned with the UI. Plenty of Rails developers start with generated scaffolds and move on from there.

That's right. Rails scaffolding is now static and not re-entrant. That means it generates files for you one time, and then you get to modify them by hand after that. If you need to add a new attribute, you'll need to build the add_column migration and edit any views that need to display the new attribute. Let's move on to some other topic.

There's no such thing. Many Rails developers prefer a text editor, such as vi, emacs, or TextMate. Others prefer an IDE, such as NetBeans, RadRails, or RubyMine. There are no right or wrong answers; choose whatever fits your budget and your preferences.

When it's done. There was some discussion of Rails 3 at RailsConf in May 2009, but as yet there's not even an official alpha release. Some people think late 2009 is a reasonable date for a Rails 3 final release. Some are less optimistic than that. If you want to keep an eye on progress, follow the Riding Rails weblog.

In addition to following the edge Rails updates at Riding Rails, you can simply watch the source code on Github. The master branch of the rails/rails repository is where the action is. You can even subscribe to the RSS feed for commits if you want to see everything as soon as it happens.

Fix it yourself. No, seriously: you can post bugs to the Lighthouse, but unless you can contribute at least a failing test, it's unlikely that anyone will be motivated to scratch your itch for you. Review the Contributing to Rails guide to see what you can do to actually help. Or get involved with the next RailsBridge BugMash.

The Top 100 Rails Sites list suggests otherwise. There are certainly well-tuned Rails sites that support staggering levels of traffic. There are certainly other Rails sites that fall over dead under moderate load. This is no different from any other language. If you need to learn about scaling, you either learn it or go out of business. New Relic's Scaling Rails screencasts are a good place to start if you need to learn.

While you can install all the necessary pieces using apt-get, many developers have reported issues with this approach not working well down the line. Debian's repackaging of Rails does not track Rails releases that closely, and may not play well with gems. Most Rails developers prefer to use apt-get to install ruby, build rubygems from source, and then use gem to finish installing Rails and other gems.

Probably. Try searching the Rails Plugin Directory. Caveat emptor when it comes to plugins, though: you need to satisfy yourself that whatever you find runs on your version of Rails, and is adequately tested.

Whichever one works for you. I can tell you some of my favorites, but your mileage may vary. For attachments, I like Paperclip. For trees of ActiveRecord models, I prefer AwesomeNestedSet. For tagging, I use acts-as-taggable-on. For authentication, I'm currently using Authlogic. For seed data, my own db-populate suits my needs fine. Or check out my BigOldRailsTemplate project to bring up a new Rails application with a variety of plugins and features.

WordPress. No, really. None of the available blogging software written in Rails is worth a bucket of warm spit. If for some reason you feel like a traitor for using a tool written in something other than Rails, write your own blog software with just the features you want.

No. RESTful routing in Rails is just a set of conventions for making it simpler to work with resources via HTTP. It's not magic beans, and it's not a straightjacket that you are required to put on. If some part of your application is easier to write without REST, you have my blessing to do it that way. RESTful routing does make some things much easier, though, so if you're just being scared or lazy about learning it, you should look at some examples and figure it out.

You can use either has_and_belongs_to_many or has_many :through for this. habtm is fine for simple joins where you do not need any attributes on the join itself; if you do need to track extra data about the join, or only have room for one way of doing things in your brain, use hmt instead. The Active Record Associations Guide goes into this in more detail.

There are a variety of potential explanations for this: (1) Your question is so poorly-stated that no one can figure out what you're asking. (2) Your question is so large that you're basically asking us to write your application for you for free. (3) You're trolling and no one cares to rise to the bait. (4) It's a great question, but no one knows the answer. In any of these cases, simply asking the same question over and over in the same words will only cause people to dislike you.

Then come visit us over in #railsbridge, which has lower traffic and a higher ratio of helpful people. We don't have any tolerance for trolling or other bad behavior, though.

So try another one, like the list of Frequently Asked Questions maintained by Ryan Bigg.

Railscasts is an extensive selection of free Ruby on Rails screencasts that will get you through all sorts of things. If you prefer reading to watching, you can find the same material at ASCIIcasts. PeepCode and Envy Casts are two good sources of commercial Rails screencasts.