MPOV

It occured to me that my gems of wisdom on my Snippets page likely go unnoticed by you faithful blog readers, so you might want to subscribe to my snippets feed as well so you don’t miss beauties like this (yes, I know this will seem lame to some, but I think it’s clever):

class Object
 def in?(object)
   object.include? self
 end
end

>> 1.in? 2..3
=> false
>> 1.in? 1..3
=> true

Here's my Ten Rails Tips, expanded a bit to try to explain my thinking…

1. Scaffolding won't write your app for you, otherwise DHH would have called it "foundationing".
   Too often I see people addicted to the Rails scaffolding feature. I've found that it's often a crutch for actually thinking about the problem at hand. Scaffolding is great for a one-table model, but breaks down quickly when you have has_manys and other such relationships.I almost wish the Rails screencasts didn't include the demonstration of this feature, because it makes people think that's how you really start a Rails app. In reality, I rarely use scaffolding.
2. Find inefficiencies using the development log.
   There's good stuff in there! Much of the time, looking through the log is unnecessary simply because Rails gives you such descriptive and pretty error messages inside the browser. But seeing the SQL being executed is invaluable for finding where your app needs to improve on the ActiveRecord side of things.
3. Use :include where possible to minimize the number of db queries.
   This is where the dev log comes in handy; it will point out places in your code where you probably should have used Eager Loading (:include => :whatever). Seeing the (mostly) same SQL query repeated over and over again is good motivation for using this handy feature. When used correctly, multiple queries are combined into one, thus reducing the overhead of communicating with the database.
4. Learn SQL, including joins; it will help you to make your queries more efficient.
   You can probably go your whole life without ever learning a drop of SQL (thanks to ActiveRecord), but I would recommend getting a decent grasp of it, because the fact is, it's still handy to know what the heck is going on. I've found that ActiveRecord isn't the silver bullet for ridding the world of SQL forver. Instead, it simply makes the mundane stuff a lot funner.
5. Learn to "feel" the presence of helpers and shortcuts — chances are, if you think there should be one, there probably is one.
   Few things are more irritating than writing a bunch of code and then finding a one-liner in the Rails API docs that does the same thing, especially when it does it better! Turns out, you can start to get pretty good at "feeling" the existence of such things. When writing stuff that seems redundant, think to yourself, is this a task specific to my application, or is everyone dealing with this? If the latter, then there's probably a helper/shortcut/whatever to do it for you. Don't waste lines of code on stupid stuff.
6. Create models to handle your data. Models aren't just database tables.
   Rails doesn't care if your models are ActiveRecord or not. Create models to do your heavy lifting. If you find yourself writing more than a few lines in a controller method, ask yourself, is this something the model could be doing itself? If yes, move it to the model. It's easier to work with models on the console than controllers and views.
7. Write a plugin if you think you'll ever use the code in another app or across different controllers and models.
   Don't repeat yourself. If you need the same bit of code again, put it in a plugin so it's available all over your app. Then, it's also easy to reuse that code in your next app.Creating a plugin is as easy as "script/generate plugin my_plugin".
8. Learn to use the console. Try out complex code there before you put it in your app.
   "script/console" is a command line for your Rails app. Use it. Learn to live in it.
9. Instead of just "testing your app," write "tests for your app."
   Grep (or "tail -f" rather) your brain for the word "test". When you think I should test that. Don't! Write a test to do it instead… then run the test. It only takes a tiny bit more time, then you get the added bonus of being able to run all your tests again later.
10. Keep http://api.rubyonrails.com in a Firefox tab and turn on "begin finding when you begin typing."
    I live in the API docs. Firefox has a nifty feature that makes finding stuff in the docs much easier… just start typing! Need to know what arguments the render method takes? Type render and hit enter!