Ask HN: What are the stupid things Rails developers do? | Hacker News Reader

Ask HN: What are the stupid things Rails developers do?

26 pointsgeekfactor28 comments

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

View on HN

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.

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.

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)

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

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

This looks like a really good resource. Thanks!

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

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

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

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

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

fat controllers

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

Single Responsibility Principle for the win.

Definitely comes into play in good design. One of the biggest things I've found is that to constantly look at new ways to approach a problem. Don't just assume you've learned it all.

One thing I'd like to learn how to do better is to refactor better.

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

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.

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.

Too big ApplicationController/ApplicationHelpers.

Never learn SQL.

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.

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?

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.

Trying to fit the code all on one line.

Excessive meta programming.

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

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.

Here is a good discussion about overriding include to act like extend. This craziness is all over the place.

http://yehudakatz.com/2009/11/12/better-ruby-idioms/

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.

Reply on news.ycombinator.com