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?

I'm primarily working in Rails nowadays if that makes a difference in the way you answer the question.

[1] http://jinfiesto.posterous.com/how-to-seem-good-at-everything-stop-doing-stu

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

[cicatriz]

The book Rails AntiPatterns addresses many: http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...

[geekfactor]

This looks like a really good resource. Thanks!

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

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

[techiferous]

Trying to fit the code all on one line.

[damoncali]

Excessive meta programming.

[danneu]

Rails implements a lots of metaprogramming, but what's an example of Rails programmers adding onto that? Only example I've come across is when Rails is being used to interface with another system/API.

[eric-hu]

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