

Rails Best Practices - edw519
http://www.slideshare.net/ihower/rails-best-practices

======
patio11
One tip (of the many, many good ones in there) that I'd like to pull out for
you is using scoped finds, as it establishes security by convention rather
than requiring programmers to make the right choices every time.

Actual examples from my code base:

@word_list = @user.word_lists.find(params[:wl])

versus the alternative (of which there are multiple variations):

@word_list = WordList.find(params[:wl], :conditions => {:user_id => @user})

This will work fine... right until one of your programmers forgets to put that
condition statement in there. Then, you'll allow folks arbitrary access to
other people's data, silently. I have seen a lot of Rails code that guards
against this by checking access before critical actions -- again, this will
work fine until you forget to do it. Instead, establish the convention that
you _only_ instantiate the model objects through something which guarantees
authorization, and then the existence of the model object is proof that access
to it is authorized. (Adjust as required if you work in banking or state
secrets. I write bingo cards for a living.)

------
dylanz
I love the "Always add DB Indexes" slide.

It's amazing how many projects I run across that completely lack proper
indexing. Many lack any indexes at all. It's almost like db:migrate should
warn you if you've run a migration that lacked any indexes.

Rails makes it so easy to forget about the database (yes, I'm talking about
you database constraints in the actual database), that users often forget that
it can be a pretty important piece of their application (especially when it
gets popular).

------
SlyShy
For a Rails newbie like me this was very, very helpful. I still haven't used
the framework enough to know what a complex code base looks like, so this is a
useful reference.

I hope this will be republished as a text article sometime, because that would
make referring to the code examples easier.

------
pie
The examples presented here could be handy for learning about Rails techniques
or (in my case, at least) helping you re-evaluate scenarios in your own code.

Very thoughtful presenation.

------
maurycy
Very good presentation. Of course, you can add few minor points (use publish!,
instead of publish etc.), but the overall message is excellent.

~~~
cglee
I agree, although I never liked using observers. I want to glance at the model
and know what's going on. But if you're going to use observers, do it as a
practice for all the callbacks on your models. Don't mix inline callback
methods with observers - that just adds confusion.

~~~
johnb
I always make the call on inline callbacks versus observers based based on
whether they're critical for the model's state. If your representation of
whatever domain concept your model is doing relies on the behaviour in a
callback - it belongs to the model. If not, in an observer.

The often suggested use for observers is for caching (which is a good
example). In our big app, if the cache expiry doesn't happen the site will
look a bit funny but the underlying transactional data is fine. Mixing those
together wouldn't communicate the difference in how important they are.

------
heimidal
Quick note: The "publish" method on slide 29 won't work as expected. You need
to pass in the current_user object.

