
10 Most Common Rails Mistakes - djug
http://www.toptal.com/ruby-on-rails/top-10-mistakes-that-rails-programmers-make?utm_source=Engineering+Blog+Subscribers&utm_campaign=cfd491c651-Blog_Post_Email_Top10RailsMistakes&utm_medium=email&utm_term=0_af8c2cde60-cfd491c651-109835873
======
3pt14159
Personally, I wouldn't make current_user return "guest". That would be
surprising. I would just return nil. There are lots of places in an
application that you'll want to conditionally show logic, like whether or not
to show a "reply" button, and it is more natural to say "if current_user" than
"if current_user.name != 'Guest'".

~~~
rubiquity
nil is annoying and should be avoided when possible. nil gives no useful
feedback when blowing up and communicates nothing about the intent of the
code. Using a Guest object is a great use of polymorphism and duck typing,
which are great features of Ruby (and object orientation). Having nils all
over the place and having to do `if some_obj` all of the time is messy.

Your example is pretty simple, so my solution will sound like overkill, but I
would use some other type of object such as a Presenter to handle the
rendering logic.

~~~
3pt14159
Naw, you're complicating things. Nil should not be avoided, it should be
accepted. If there isn't a current user then don't pretend that there is.
Anywhere you are doing `if some_obj` in view code you'll probably be doing `if
some_obj.is_a? Guest` or `if some_obj.guest?` anyway.

I've worked on very large and well used applications (billions of loads,
multiple data centers, hundreds of thousands of lines of code), not that that
should really matter to the argument (logical fallacy and all that), but the
thing that I've found messes up Rails applications is large model objects
("god objects"), poorly thought out data relationships, and inconsistent
assumptions across systems that lead to hacks. Not nils.

~~~
rubiquity
> _Anywhere you are doing `if some_obj` in view code you 'll probably be doing
> `if some_obj.is_a? Guest` or `if some_obj.guest?` anyway._

Sorry, you're completely wrong. Polymorphism and duck typing exist
specifically so that you don't have to do `is_a?` checks.

> _but the thing that I 've found messes up Rails applications is large model
> objects ("god objects"),_

How do you think god object models get created in the first place? By not
extracting out logic. When you have models that have very different state, you
actually have very different objects. Those differences should be extracted
into different classes.

------
enraged_camel
As a Rails newbie (~3 months), I found this list very useful. I'm very mindful
of the difference between doing something vs. doing that thing correctly, and
even when I write a piece of code that works, I often stop and ask myself,
"OK, but is this the best way to do it?" I try to avoid dirty hacks, and if
I'm on a time crunch where I don't have time to figure out the right way, I
postpone the feature to the next release rather than putting in a temporary
dirty implementation.

One thing I've been having trouble with as my project gets more complex is
when to refactor. I guess I'm not yet at the stage where I can accurately
judge the benefits of refactoring a code vs. the cost. To use an analogy, am I
just re-arranging the furniture to change the look-and-feel of the room
(superficial), or am I actually making it easier for the guests to make
themselves comfortable (real benefit)? I've read books like Pragmatic
Programming [1] that advise refactoring whenever possible to avoid technical
debt build-up. But it seems to be that there are times when working on a new
feature would result in more value-add for the project as a whole.

Another thing is motivating myself to write test cases. The Hartl tutorial
taught TDD, but when I started my project from scratch I quickly realized that
TDD would slow down my progress significantly, and I didn't yet have enough
experience to assess how a feature _should_ work to be able to write tests for
it. This did bite me in the ass just last night though, as I spent three hours
troubleshooting a bug that a test case would have caught. Oh well, live and
learn, right? :)

~~~
WestCoastJustin
> _Rails newbie (~3 months)_

Don't know if you have seen [http://railscasts.com](http://railscasts.com)
yet. But it really helped me.

~~~
enraged_camel
Yeah, I love Railscasts. I'm sad Ryan stopped doing them.

------
alphadevx
Not a bad list, but I think many of those are not unique to Rails and just
look like common anti-patterns.

------
hmans
This is the first article of this kind that I actually agree with. Usually,
these things are "5 Popular Rails Mistakes: 1) Your code Book Of Fours the SRP
concurrency something something don't use the database in tests blah."

------
sanderjd
Perhaps I'm in the minority, but I think "too much automated testing" is a
more common problem in rails apps than "too little automated testing". With a
corollary being that "too little non-automated testing" seems to be a common
problem with rails _teams_.

------
pothibo
I agree with the gem list. I think it should have been #1.

Using OpenStruct as a replacement for a user doesn't remove the conditionnal,
it just removes it from that use case. You still need to know if the user is
logged in or not.

~~~
BrianVanLoo
Glad to see some support on the gem list. That was one of the items I really
hadn't seen discussed anywhere else and was wondering if it only bothered me.
I did some dev ops for a project that turned out to be what would have sounded
like a fairly simple, small Rails app on a rather low-traffic site. I kept
having to increase the server instance size as the team cargo-culted more and
more gems into the Gemfile and the multiple Rails executables run under
Unicorn continued to grow in size and eventually run out of memory on the
server. I agree that my example using OpenStruct only moves the conditional
but in this case it moves it out of a place where I find conditional logic
much harder to reason about. Also, if there were more attributes than just
name that come out of that object you could potentially be eliminating many
more conditionals with just the one in current_user which also seems like a
win.

