Ruby on Rails: Common pitfalls/gotchas

Question

There is a similar question about Ruby in general but I am soon to be starting out using Ruby on Rails to develop a website or two.

What are the common pitfalls/gotchas that are specific to Rails.

Answer 1

Is it your first web framework or do you have existing experience with other web development? If you have prior experience the main gotcha is trying to do stuff the way you did it before in Rails. It's going to be a massive pain, Rails has its opinions even about details, and it's not much fun to develop Rails while going against them.

Another problem with Rails is that it changed its mind a few times about things, so for example you have REST-ful routes and normal routes in the same framework, and some tutorials will show you one, some will show you another, and if you try to mix them it doesn't work all that great. Every minor version does it - you can still code Rails 2.2 as if it was 1.2.3, but if you mix styles between Rails versions, not fun.

The last thing is h(). Erb by default does not do XSS protection of any kind. There are plugins like XSS Shield which do, if you don't use them you need to make sure you escape everything potentially dangerous. XSS is to Rails what SQL injections was to PHP.

Answer 2

I would say that a big gotchya in Rails is that with each action you do you need a Ruby process. This is important to know when you are sending an email from Rails. By default the email will be sent using the current ruby process and will be unaddressable until that action is completed. With processes like these you have options available like BackgroundDrb, Starling, Workling, and even just using rake. Consider checking out Spinning Background Tasks in Rails.

Answer 3

The mistake of putting too much logic in Views is a common one (guilty here). Once that's recognised, the next common mistake is putting too much of the removed logic into Controllers (guilty here, too). When starting, keep checking that you don't have business logic in Views and that your code meets the "Thin Controller, Fat Model" criterion.

Don't be afraid to create Models that don't inherit from ActiveRecord::Base. Some business functions sit well in models that draw from several physical tables. That's OK. Much of my Fat Controller/View problems stemmed from not realising this.

Consider deployment from a very early stage - start understanding what should and shouldn't be put on the server and how you're going to manage the process. It's something I wish I'd been able to do earlier. Once understood, deploy frequently - it'll work the glitches out over time and cease to be a painful process. Web apps like to be deployed regularly.

Consider Test-Driven Development: Rails apps are fairly decoupled and they're a good target for TDD. If you find testing Controllers and Views hard (I do) then either jsut build the models test-first (much easier) or bite the bullet and learn the hard part early so it isn't hard later. Having good test coverage is wonderful - I wish mine were better.

Don't ignore the community - chances are, if you having trouble with something, someone else has had it before and is just itching to tell about it. Indulge them!

Answer 4

Overriding one of ActiveRecord::Base's methods by defining a field with the same name. For example, calling a field callback will yield a wrong number of arguments (1 for 0) error because ActiveRecord tries to call this method when it saves objects.

Answer 5

I'd echo putting too much logic in views. Especially if you're new to the MVC model.

Similarly, not relying enough on helpers is pretty common. If you find yourself duplicating code or struggling with 'where this should go', think about adding some helper methods.

Finally take a long look at ActiveRecord documentation. AR and Rails are not the same thing and there's much to learn and understand with AR before you can be effective. I still find myself writing huge :conditions when I could have used nicer ruby-ish type syntax Ex

Class.find(:all, :conditions => "some_field = value and other_field > value")

instead of

Class.find(:all, :conditions=>{:some_field => value, :other_field_gt => value})

Answer 6

Naming a property in your model 'type' when you're not doing any kind of inheritence with it.

Not strictly a gotcha, but when I started learning RoR I ran into problems reading tutorials for older versions, quite a bit has changed and there's some out-dated stuff out there.