Guide: Things You Shouldn't Be Doing In Rails
Posted by kev Wed, 30 Aug 2006 05:32:00 GMT
Koz recently checked code into core that kicks and screams all the way home if you’re using deprecated methods or instance variables. In honor of this I’ve decided to give you a list of things I still see over and over in Rails code that you really shouldn’t be doing anymore. Really. Trust me on this.
Update: There’s been enough controversy over this article that I’ve responded.
Accessing Instance Variables You Didn’t Create
It’s time to stop using the instance variables for
response and all of their formerly preceded by an
@ friends. This has been deprecated for a while but it looks like it hasn’t circulated well. When you use the instance variable directly it makes it hard for the core devs to change the implementation. It also means you’ll have broken code sooner than later so kindly remove your
@s. Yes, I know there’s still documentation that uses it. Please file a ticket.
rabble (who you’ll hear more from later) also suggests that you not intermix usages of
flash['notice'] and the like. I personally prefer the symbol version and I’d encourage you to use that. You save yourself an entire keystroke and memory usage. What’s better than that?
Using Deprecated Finders
find_first have been deprecated over a year now. Stop using them. While you’re at it, stop using render_partial. Their better educated cousin
find can handle all their needs. Use
Getting Ahead of Yourself
Stop asking for things not directly related to your problem. If you’re seeing an exception you don’t expect ask about that. Don’t ask about if anyone has heard of problems in some library. This really should be generalized for asking all questions: Ask your question directly and with as much information about the problem as possible. This doesn’t mean I want to see all of your logs and your codebase. This does mean that I’d like to hear what the error message is or what isn’t working. If you’re not using the latest version of Rails, please specify.
Fallin’ off the wagon
Scaffolding isn’t for production. Overcome your addiction. It shouldn’t be modified to be more customizable. Developers should instead learn to write Rails code. It takes far less time and should produce less mediocre code. It’s good for the screencast and not much else. Leave it alone. If you insist on a bootstrap database administration interface take a look at Streamlined.
Components don’t belong in Rails. Don’t use them. They weren’t an extraction. They weren’t well planned. When you want to use a component it is probably because you misunderstand them or really want a partial. Rethink what you’re doing. The rest of the Rails world has written off components for a reason and they’ll probably be deprecated by 2.0. Resist.
Using Engines (Improperly)
Yes, I know you’d like to have an authentication system without doing any work. Yes, I know Rails preaches convention over configuration. This is not a place where it applies. This is, as we say back in the hood, “too much software”. It’s also a nasty hack that breaks every new version of Rails because it hooks into internals that aren’t publicly supported. These are akin to scaffolding. You’ll be happier without them.
Update: This could use some clarification. Engines aren’t de-facto evil. However, the way most people use them _is_. If you’d like to have the same functionality across several of your apps you may want to use engines. My problem with them is that they become a slipperly slope for drop-in turn-key applications. Don’t use them like that. As long as you’re not using them as a once size fits all solution, you’re probably ok.
Not Using Layouts
Please, take advantage of layouts. I’m tired of seeing broken views that include 40 lines of container stuff. Using layouts means that you and I both have less to look at to fix your bug. It’s also much DRYer so you get to make a single change to a layout instead of lots of changes to lots of views. I had to do that for a client once. Two hours spent on a tiny crappy website reworking headers. Don’t do this to yourself. I’ve reopened old wounds just thinking about it.
Using (The Built In) Pagination
A core member chipped this one in (which I’d been contemplating). I haven’t used pagination in my last 15 projects. The pagination code is ugly. Ugly ugly. Many of us would love to see it gone. It’ll probably be extracted to a plugin though so if you need it you’ll be ok. Look for this to be deprecated in the next few versions of Rails.
The paginator produces horribly unscalable code which will bring your server to a halt. – rabble
See? A halt! Sufficiently frightened? You should be. Update: If you’re one of the apparent many who took offense to these last few statements, you missed the grin I had when I wrote it. Don’t run screaming. Just be aware that using things that are (or will be) deprecated can cause you problems.
Now, stop using these things. It’s for your own good. I may do an article on the things I’m really happy about in Rails in the near future. Let me know what you think.
Oh, and take interest in your fellow coder and let them know about their mistakes by digging this guide.
Updates: The concept of pagination isn’t a problem. The rails implementation of pagination (and the associated helpers) can be. As for the scaling comment, pagination will work fine for a blog. You’ll start seeing problems when you’re working with tables with millions of rows. If you don’t need to deal with that it may not be a problem. Just be aware.
Update #2: I’m adding this just because Rick Olson of the core team says it so much better than I do:
Kevin’s speaking out against the Rails Pagination classes, not pagination itself. The Rails Paginator is difficult to use for all but the simplest of queries. It’s also inefficient in various ways.
Via Riding Rails.
Putting Controllers in Namespaces
This is really more trouble than it’s worth. You run into all sorts of crazy errors if you do this and you’ll be confused and frustrated. You’ll then ask other people about it and they’ll either blow you off for using namespaces with controllers or procede to get confused and frustrated as well. Then you’ll say, “I with I had listened to Kevin and Chris”. If you want
/admin/some_controller as an URL that’s fine. Use the routing that’s built into rails.
For The PHP Trolls and Frightened Ruby Devs
I’m sorry if you took this the wrong way. This article is purely my opinion and some obviously disagree with me. The important thing to note is that although I consider these things rough spots, I’m still a die-hard Ruby and Rails coder. The feeling (and speed) I get from working with these tools can’t be found in any other language or framework. Period. Don’t be afraid because there are pitfalls – that’s true in any situation. Just be aware of these things. I’ll post a list of the things I love about Rails (and you may want to use) later in the week.
Book-wise, you’re still in good hands. Agile Web Dev with Rails is being cleaned up for the second edition. Ruby for Rails is quite good. These guys won’t lead you down the wrong path. This article is just meant as a wake-up call to those who still haven’t heard about the updates.