Things you shouldn't do in Rails
Posted by josh August 30, 2006 @ 03:41 PM
Kevin Clark was written a nice piece on things you shouldn't be doing in Rails. It starts with a reminder about not using various deprecated pieces of the API, and goes from there into recommendations based on Kevin's personal experience with Rails. It's worth checking out. Remember, half of knowing what to do is knowing what not to do.
Many folks (myself included) seem to be a bit confused with the remark about pagination. What’s the alternative? Displaying 10,000 items on a single page doesn’t work well.
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.
Yeah but what’s the alternative?
I find changes in the “right” way to do things frustrating. I’ve still been writing all my code using @params, for example, because that’s how all the examples and documentation were written when I started using Rails. How are we supposed to know about these changes? Is there a document somewhere that lists changes in best practices? There has to be a better way for developers to find out about them than catching a post on someone’s blog.
While this article may prove useful for some, it is not a good solution to the problem. It is another piece of information that just won’t make its way to the people it is supposed to help.
A better solution to most of the problems covered would be:
1. Keep documentation updated, well. Do not include examples that use deprecated methods. Update the wiki when things become deprecated. This takes time and effort, and Rails is OSS, but if newcomers are going to learn correctly, they need good “official” documentation.
2. Make every effort to BREAK old methods, don’t support them in newer rails versions to ween people off of them. You can freeze rails if you need to. If you want to move your app to a newer rails version, and something breaks, fixing it is just something you have to do.
3. DHH made a comment on here about components never having been in style. Remove them!
I’m with Jake. What then?. Wait for a better paginator from someone or the core team?. A better implementation?. Create our own?.
How about a plugin that flags deprecated/out of style coding practices? Any takers?
Isn’t the solution to the pagination helpers problem to fix them and make them better? I’d hate to see them removed from core and left to whither as an unsupported plugin.
Pagination is important, we all use it all the time. I don’t know what’s wrong with the current helpers (outside of them being inflexible), but I’d prefer to see them given some love and kept in core.
Such a concentration of people suggesting that we need some sort of documentation of all these revisions, and the ‘better’ replacement methods.
It can’t be a great thing if you’ve only just heard about Rails, you look at the website, you excitedly buy the book, and then while you are reading the blog, you find people telling you that things in the book are bad or foolish or wrong.
We all understand that things move on quickly, and that these days if you weren’t there for the beginning of a trend it can be hard to catch up, but it’s getting rapidly to the point of silliness that there is not one central, authoritative place to make sense of the changes; instead we have a variety of fascinating, provocative opinions but no sense of how close to ‘orthodoxy’ they are.
It’s huge fun, but not when you are trying to make decisions that have to last a year or so.
A perfect example: In the documentation for ActionController::Flash, in the first example:
It seems foolish to say both engines and components are bad. Code reusability is a big deal in the real world. Rails needs a good solution to this and it seems to be engines.
This is one thing asp.net does so well. You can find all kinds of controls to add many kinds of easy-to-use functionality. Without engines, what would rails have? Little more than PHP.
Welcome to the beauty of agile and open source software.
No API is set in stone, and changes are made for the benefit of the framework hoping that you; the developer are paying attention enough to keep up. It’s your perogative to aggregate information from people with good opinions.
Following best practices is a good thing but it isn’t the be all and end all, it’s still possible to create applications that work well by not following them.
For the people crying out against having to revisit their code, surely that’s a good thing. Testing and Refactoring your code are better practices than languague specific implementations and it sounds like you could solve your problems and be more flexible by doing so.
In the old days, the scaffolding that was generated did not use pagination. Perhaps a return to that would be in order so that people don’t come to rely on the inefficient helper methods. I tend to remove them right away any time I scaffold things. That would certainly help out the newcomers who learn controller logic by looking at the generated code.
Pagination of “next / previous” is pretty useless on large data sets anyway. Alphabet bars or searches are much better approaches for filtering data in my opinion and they’re easy to implement.
The rails paginator is fine for simple cases. Larger, complex cases usually have special needs, which means custom code or plugins.
Turd Ferguson: turn that into a patch and post to trac and it’ll probably get committed right away.
rick: Do you have examples of such custom code or plugins?
Pagination works fine for me right now, in fact I love it. I also don’t have millions of rows yet. I’d hate to see it go away or not improved (why can’t it be?) or everybody having to have monolithic pages like on Trac.
josh: I get an input/output error trying to comment on your blog:
http://habtm.com/articles/2006/07/01/if-your-models-arent-namespaced-why-should-your-controllers-be-or-how-i-learned-to-stop-worrying-and-love-the-crud
Documentation got you down?
http://caboose.stikipad.com/documentation
I’d also like to note that there are edge dogs hosted there…
The 2nd edition of Agile Web Dev w/ Rails on PDF is pretty good about outdated stuff. I’d really recommend it, even if you read the 1st edition and don’t mind spending the money.
I’ve never understood why each version of rails doesn’t have a changelog posted right next to it when you download it, or when a new release is announced. I have to hunt high and low or just plain get lucky to find out about some things that are fairly important. Even if the changelog just covered changes that might possibly impact users, that would be enough.
Agreed, the perldelta documentation that comes with each iterative release of Perl is a teriffic example.
Need I say more?
(Yes I’m talking to you, developers :)
I’m frankly surprised to find this overlooked considering Perl’s been setting the example (and quite frankly the benchmark) for this for so darned long.