
Ask HN: What are the stupid things Rails developers do? - geekfactor
I liked the post "How to seem good at everything: Stop doing stupid shit" [1,2] and am wondering how to apply it to take my dev skills to the next level... What is the "stupid shit" that developers do that if we were to only stop doing would make us better developers?<p>I'm primarily working in Rails nowadays if that makes a difference in the way you answer the question.<p>[1] http://jinfiesto.posterous.com/how-to-seem-good-at-everything-stop-doing-stu<p>[2] http://news.ycombinator.com/item?id=2848041
======
davidst
Humility is your friend. There is so much to know you must assume that, in
areas where you are not already an acknowledge expert, you are already doing
stupid things and you don't know it.

Related to humility: Never forget the fundamentals. I'm talking about things
like basic sorting, searching, and big O estimating. Know what your data
structures and algorithms cost in terms of memory and performance. I'm
continually surprised by how many senior developers unknowingly drift away
from the fundamentals.

------
prodigal_erik
Assume no non-Rails code will be using the database. Use ActiveRecord
migrations to set up schemas completely lacking foreign key declarations.
Casually add caching without thinking very carefully about invalidation,
serving stale data for hours to months. Deploy manually without ensuring every
server always has the same package versions.

~~~
cubicle67
that and lack of indexes

fwiw, you can add indexes and foreign key constraints using migrations. I
don't see this done much, but I think it's good practice (adding indexes and
fks)

~~~
yxhuvud
FKs do require a plugin to be possible to add through migrations though.

------
cicatriz
The book Rails AntiPatterns addresses many: [http://www.amazon.com/Rails-
AntiPatterns-Refactoring-Addison...](http://www.amazon.com/Rails-AntiPatterns-
Refactoring-Addison-Wesley-Professional/dp/0321604814)

~~~
geekfactor
This looks like a really good resource. Thanks!

~~~
joshuacc
Refactoring Redmine is also good for detailed case studies.
<http://www.refactoringredmine.com>

------
techiferous
Not understanding the problem your customer/client/manager is trying to solve.

~~~
trebor
This is pretty ubiquitous to the industry, not only Rails.

------
jdeseno
\- Not writing tests.

\- Long finder methods instead of using named scopes.

\- Not using restful routes.

\- Too much code in their views.

\- After saves that should be validations or other confusing AR lifecycle
mistakes/abuses.

------
chsonnu
Relearn how to do something "the rails way" when they already know how to do
it elegantly in PHP or ruby/sinatra.

------
latch
fat controllers

~~~
jamesbritt
Fat anything. Classes should have limited, well-defined behavior, and call out
to other objects or use composition when needed.

~~~
philwelch
Absolutely. I think the confusion is between individual model and controller
classes and the collective model and controller components of the system as a
whole.

If you have one fat controller class, that's the worst of all worlds. If you
have a plethora of thin controller classes which collectively handle most of
the business logic, you still have a "fat controller" in aggregate, even if
these controllers have limited, well-defined behavior and call out to each
other. What you really want is a thin controller in aggregate, combined with a
large but well-separated ecosystem of model classes (which, in aggregate, is
going to outweigh the controllers).

~~~
jamesbritt
_If you have a plethora of thin controller classes which collectively handle
most of the business logic, you still have a "fat controller" in aggregate,
even if these controllers have limited, well-defined behavior and call out to
each other._

I don't follow this at all.

Anyways, what I was getting at was, as jarrettcoggin posted, Single
Responsibility Principle. Couldn't think of the name before.

A problem I see in Rails code is that some people think you have only three
places to put code: M, V, or C. Most people know enough to avoid stuffing code
in the view, so they stuff code into either a controller or a model. Not quite
"god classes", but demi-god classes at least.

~~~
philwelch
If you follow the Single Responsibility Principle well enough, you're going to
end up with most of your code in model classes most of the time. My point is
that it's possible (but still a bad idea) to have tons of tiny controllers,
each of them still doing stuff that's better served by a model.

------
yxhuvud
Too big ApplicationController/ApplicationHelpers.

------
amorphid
Never learn SQL.

~~~
trebor
As someone who knows SQL pretty well, it amazes me how Rails applications are
architected. Recently I needed to create a record without a primary key (as a
numerical ID). This isn't an issue to the database, but Rails would die any
time it attempted to either load or save an object. The exception this "id-
less" record threw was so ambiguous that I spent upwards of 6 hours
deciphering it. I solved the issue by including an unneeded ID field.

And another thing that amazes me is the frequent lack of indices. You want
slow searches for specific values? Okay, you got it!

I know that it's tempting to avoid SQL and leave it 100% to the code
generator—but the few edge cases you have with poor(er) performance could
really get a boost with even _minor_ understanding of SQL.

~~~
addandsubtract
I gave up on Rails, because I didn't want to unlearn SQL / relational DB
principles. Is there a good guide somewhere that will teach me how to stay in
control of my DB schema with Rails and not do dumb shit the framework wants me
to do?

~~~
trebor
I haven't found one. At least with Rails 3 / ARel you can do queries like:

    
    
        Posts.where("posted_on BETWEEN ? AND ?", Date.current - 2.months, Date.current)
    

But it still isn't the same.

You can create a Rails app without an ORM, but then you must do all your
queries and migrations in your own code. This is one of the reasons people
stick with the suboptimal SQL: it's faster to generate and lets you iterate
more quickly.

------
techiferous
Trying to fit the code all on one line.

------
damoncali
Excessive meta programming.

~~~
eric-hu
could you expand on that? What would an excessive meta-programmer be thinking
or doing differently?

~~~
damoncali
Not a rampant problem. I've just seen a few times where developers have been
clever just because ruby lets them. Makes things hard to read for no good
reason.

