Rails Best Practices | Hacker News Reader

Rails Best Practices

slideshare.net

43 pointsedw5198 comments

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.)

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).

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.

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.

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

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.

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.

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

Reply on news.ycombinator.com