digg

Join DiggAbout

Discover the best of the web!
Learn more about Digg by taking the tour.

Things You Shouldn't Do In Rails

glu.ttono.us — The Rails core team recently checked in code that kicks and screams all the way home if you ’re using deprecated methods or instance variables. Here's 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.

Bury
show profanity settings
expand all
  • Mislav, on 10/12/2007, -1/+4Thank you, Kevin, for an excellent heads-up! Most of the things I knew already, but warnings about Engines and paginators were new to me. I always felt something was wrong with Engines (that is probably I avoided ever installing one), but this is the first time I hear about paginators being bad. Maybe they need a rewrite? Extraction to a plugin sounds reasonable, especially when it's not the only thing that is being prepared for extraction
    • rjonesx, on 10/12/2007, -1/+3Anything, but especially not program.
  • MoeB, on 10/12/2007, -35/+12Things you shouldn't do in Rails: Anything.
    • RidinDirty, on 10/12/2007, -13/+6I think you mean "Everything!" HAHA!
    • MacGeekGuy, on 10/12/2007, -2/+2Well I'm still deciding if this has to do with software development or if it's a Nancy Regan speech. The last time I did anything in rails I was young, stupid and up for 4 days straight. So I know of a few things that shouldn't be done in rails either. *g*
  • thread, on 10/12/2007, -2/+8From the title, I thought this article was going to be about types of applications rails is not suited for... This is a great article, though. Kudos to Kevin!
  • garrettmurray, on 10/12/2007, -2/+6In general, I disagree about pagination. It might be that the current code is slow or whatnot, but for nearly all uses the pagination works very well. For instance, in a list of articles in an admin section, the paginator is just fine.

    Some good notes in there, although I wish the article wasn't written with such a jerky attitude. We want to attract people to the framework, not tell them they're stupid if they do things incorrectly. Sometimes I think a lot of the RoR development/expert community could use a dose of being nicer about things.
  • Snuffkin, on 10/12/2007, -6/+10Article summary: Loads of the 'useful' features built into Rails actually suck and you should write your own implementation, and scaffolding was just to amaze people on the screencast.
    • Otto, on 10/12/2007, -20/+16Things you shouldn't be doing in Rails:
      1. Writing code in Rails.
    • pumacub, on 10/12/2007, -16/+9Exactly... Hey, you know all those things in Rails that make it so popular and worth using? They suck, don't use them, write your own.

      And thus Rails quickly descended into the mangled hell PHP exists in. Seriously, Rails seems like just a rehash of PHP, even repeating all the same mistakes.
    • SleepJunkie, on 10/12/2007, -6/+4Have you ever in your life looked at Rails code? Scaffolding was more "cool" than useful. And you know what? If someone wants to go ahead and scaffold all day long on a site, let them, it will work. It was never meant to be used on huge websites.

      And pumacub: You shouldn't try to compare the two. They're very different. And Rails is most definitely *not* in "PHP mangled hell".

      Please know something before you comment.
    • alienz, on 10/12/2007, -1/+13@pumacub

      What a brilliant idea, instead of using code that has been worked on by dedicated team for some time now, let's go ahead and roll our own framework. That's not a waste of time or resources.

      If you don't like Ruby as a language and prefer PHP feel free to choose a PHP web framework, there are some nice ones sprouting up.

      So let's recap Rails is a web framework, PHP is not, CakePHP is a web framework, Ruby is not.
    • Bloodwine, on 10/12/2007, -3/+4Except PHP already has a large enough install base that they can get away with a bit more than RoR can this early in the game.

      It will be interesting to see what happens to the PHP community when PHP6 rolls out. PHP6 and this RoR article are not too dissimilar. PHP6 will be like, "Yeah this is how you've done it all along, BUT IT'S WRONG! Change your ways ASAP!!"

      I feel sorry for PHP developers still writing code for PHP4, as PHP5 is much nicer, albeit slightly slower performance-wise. Imagine maintaining code for a project that needs to run on PHP4, PHP5, and PHP6. Yuck.
    • UnknownRelic, on 10/12/2007, -1/+6@alienz, you realize that pumacab just (bluntly) summarizing some of what the article says don't you?:

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

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

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

      The things the article says "don't use" are the same things that get all the focus in rails' "marketing".
  • spadin, on 10/12/2007, -4/+4This seems like everything you learn in the Pragmatic Ruby on Rails book.
    • jgwhite, on 10/12/2007, -2/+0Absolutely, although in fairness the Pragmatic book did warn against components for anything other than the line-items list.
  • ClassicResort, on 10/12/2007, -7/+9Did anyone else initially think this article was about what not to do on the subway?
  • dante2010, on 10/12/2007, -6/+14So what yer saying is don't use all the things in Rails that were meant to make programming in the framework easier.

    Natch.. I'll stick to my PHP codings.
    • alienz, on 10/12/2007, -3/+7@dante2010

      I'll take that troll bait. That's not what it says at all. The article simply highlights that some decprecated code should be reflected in your own code. It's not that big of a deal to use params[:foo] instead of @params['foo']

      It also says to start using things properly is all and you'll save everyone trouble.

      Hardly taking away from the framework.
    • lumbergh, on 10/12/2007, -3/+2beeotch. the big sell for rails, for me, was the extremely well-integrated testing framework. write tests for all your code and go home rest assured that you didn't break some core functionality of your app with that Friday 5pm check-in. This is a huge win, the idea that all your code can get tested. I haven't gone as far as the zen-like TDD methodology, but I do write tests for all functionality. You would be sold on it too if you weren't stuck in procedural scripting land. Have fun.
    • dante2010, on 10/12/2007, -3/+4@alienz

      I disagree. The article explicity said NOT to use a bunch of features in Rails that just happen to be the big "selling points" of that framework. At least by looking at the "Get Excited" section on rubyonrails.com. Basically this article is telling me not to bother with any of those exciting features because they were implemented poorly and will be deprecated with upcoming versions of Rails.

      So why bother switching from a programming language/framework that I already know? I was at one point contemplating learning Ruby with Rails, but not if it's not going to offer me easier methods of doing what I already can in PHP.
    • kevinclark, on 10/12/2007, -2/+5@dante2010

      I generally don't respond to Digg comments but I thought this one need some clarification. I came to Rails because of the flash but I stayed because it fundamentally changed the way I develop web applications. I have cleaner more maintainable code with integrated testing and a language that simply kicks ass. I love Ruby aside from Rails, but Rails makes web dev sweet again. Anyway, my 2c.
    • nofxjunkee, on 10/12/2007, -1/+3Even without Rails at all I'd take Ruby over PHP in a second. I'm more experienced with PHP and for my last project I had to use PHP and the Zend Framework and all I could think about was how much nicer things work in the Ruby and Rails world.

      IMO the biggest selling point of Rails is Ruby, not scaffolding or other stuff that is trivial for us to do manually. PHP5 still has some ugly warts from tacking on OO. Class methods and instance methods can be called in either class or instance context, on the class itself or an object of that class and PHP will execute it, with just a warning. That's not right. Class methods are evaluated at compile time and you can't call a class method in the context of a subclass. Ruby being completely dynamic and passing messages like smalltalk and Obj-C is a big win over PHP's poorly implemented attempt to clone Java's OO capabilities.

      I don't think Rails is a PHP-killer and I don't think PHP is dead or anything stupid like that, I just think it's really dumb for people to close their minds and just stick to PHP. What's wrong with having a broad set of skills? I'll work a job in PHP, Ruby, Python, whatever someone needs or wants. My choice is Ruby followed by Python and then PHP, but I don't hate any of them. They all have pros and cons. PHP has a lot of pros, even with it's somewhat ad-hoc implementation and 400+ commiters.
  • v3xt0r, on 10/12/2007, -16/+12Things You Shouldn't Do with Rails: develop, test, deploy, use
  • alienz, on 10/12/2007, -3/+7"Stop trying to write “neato ajax driven thingies” before you understand how to write it properly without ajax."

    "Scaffolding isn’t for production. Overcome your addiction."

    Yes please, you know how much time is wasted trying to help people who are jumping right into using AJAX without a working backend?

    Add to that the fact people are using it when it's not even a good place depending on what the user is expecting.
    • noodlez, on 10/12/2007, -1/+4"Stop trying to write “neato ajax driven thingies” before you understand how to write it properly without ajax. In fact, write the non-ajax version first. Always."
      i'd say that second/third sentence are also just as important.
  • inajeep, on 10/12/2007, -2/+4I must be really far from 'open source web development' cause I never heard of Rails. That's not a big thing but I'm surprised it got that many diggs. I think I'll look into it.
    • Bloodwine, on 10/12/2007, -3/+6Rails is a Ruby framework (often referred to as RoR for "Ruby on Rails"), and it's the flavor of the month. Developers jump from language to language every few years and denouncing the old language they used.

      Last year's flavor was Python.
    • mratzloff, on 10/12/2007, -1/+5"I must be really far from 'open source web development' cause I never heard of Rails."

      Well, it's been out there for a little over two years now.

      Rails leads the Web 2.0 Hype Machine. That's not to say Rails or Ajax are bad ways of doing things (they're not)--they're just misused regularly. Of course, PHP is in that boat, too.

      I saw an online DVD store awhile back where literally everything was Ajax. Why? Why?
    • lumbergh, on 10/12/2007, -2/+2Wow man. Get on the Internet much? ;) Perhaps you don't code web apps for a living...
    • commandar!, on 10/12/2007, -1/+5Not to be rude, but what rock have you been living under?

      I wish I could avoid even half the hype Rails gets.
    • Herolint, on 10/12/2007, -2/+4No, Python is still very cool. Django uses Python and is every bit as cool a Rails is. The added benefit is that Python has a very clean syntax while Ruby doesn't. Oh, and it also supports Unicode really well whereas Ruby kind of sucks at it.

      What isn't cool is *.NET, PHP, and anything done in Java. :)
    • cdcarter, on 10/12/2007, -0/+2I think which one has the cleaner syntax is up to the user. I prefer the Ruby syntax. The white space requirements and no 'end' statements bugs me. I think:
      def managers(emps)
      return emps.select {|e| e.isManager}
      end
      is prettier than
      def managers(emps):
      return filter(lambda e: e.isManager, emps)
  • daldredge, on 10/12/2007, -8/+6Program in it? :)
  • DeadWisdom, on 10/12/2007, -6/+3#1 Use it.

    Try Django (www.djangoproject.com) instead.
    • alienz, on 10/12/2007, -0/+1@DeadWisdom

      Django is good, I'd suggest some of the PHP ones out there as well for anyone who doesn't have a server with mod_python or good Rails support.
    • jayunit, on 10/12/2007, -1/+2I'm genuinely curious (read: not trolling): what does Django offer over Rails? (Particularly helpful would be a link to an article discussing the merits of each.) Is its application "sweet-spot" similar to Rails', or Django more applicable for particular types of apps? I've been developing in Rails for ~1 year, maintaining several stable and performant apps on a variety of server combinations, 90% of my work is blue-sky CRUD-centric web apps. I'm interested in learning Python, and have heard great things about Django, but not enough to justify spending enough time to learn Python and Django properly to give them a fair shake.
    • kelyar, on 10/12/2007, -2/+1isnt Django just a clone of Rails ?
  • ThinkFr33ly, on 10/12/2007, -1/+2In slight defense of the RAILS framework, pagination is *very* difficult to get right.

    Most of the time it requires changes to DB schema to do it correctly, usually in the form of a pagination index field that has a constantly updated row number value. (So select statements can include something like WHERE RowNumber BETWEEN X and Y).

    One approach I use quite often is table variables (in SQL Server) or temp tables so I can do my select into the temp table / table variable, adding the rownumber field on the fly, then doing another select off that. This has the added benefit of not having to maintain the rownumber field on deletes and inserts. It's a good solution for tables of moderate size that change often.

    Another option is a server side curors, but nobody likes that because it's slower than hell.

    Completely client-side (not user-side, but framework-side... like in RAILS or ASP.NET or whatever) paging solutions will never scale because they always bring back all of the rows than just don't show some of them.
    • lumbergh, on 10/12/2007, -0/+0I'm pretty sure all of the popular DB's have SQL options to select a subset/range of the result data and I actually believe that if you use the "paginate" method, it uses those calls. As opposed to using a Paginator object, which DOES retrieve the entire result set and then chop it up for the screen.
    • whosyourtator, on 10/12/2007, -0/+0@lumbergh

      I was thinking the same thing. You can see the sql in the rails console uses those database calls you mention. When running rails against mysql you get:

      SELECT * FROM Junk LIMIT 100, 10

      How is this slow? I ran it against a table of 2 million rows and its lightning fast.

      I can understand it would not scale in the "interface" level to have to paginate through 2 million records. In that case its a big duh that one should use a search to find the record you need.
  • Jack9, on 10/12/2007, -3/+1Not all popular DBs have SQL limits.
    • Otto, on 10/12/2007, -0/+3Name one.

      mySQL: Has LIMIT.
      MS-SQL and Access: Has the TOP option in a select.
      Oracle: Has a ROWNUM psuedocolumn on every select, which can be used in the where clause.
      Informix: Has a FIRST N capability with a select. Newer versions also have a LIMIT and SKIP clause.

      All databases have them, one way or another. You just have to do some research, since it's not standardized.
  • cdcarter, on 10/12/2007, -2/+3To all the trolls that say this is saying to not use everything that makes rails popular:
    First up, it does not say never use scaffolding, it says not to use it in production code. Scaffolding is a scaffold to get you started, and to rewiite, and it has always been advertised just as that. And pagination is never touted as a major feature anyways.
    • dante2010, on 10/12/2007, -0/+2My impression of the scaffolding feature was always that it would be used to get your app up and running quickly in the development mode, and then would be tweaked and customized from there in an effort to create an application that was ready for production.

      So really any application you start with scaffolding will (hopefully) move to a production version at some point.. so how do you get around not making use of scaffolding in your development? Is there like code that scaffolding puts in that you need to replace before you go live?
    • cdcarter, on 10/12/2007, -0/+1@dante2010:
      If you don't want to use scaffolding in your development, then you don't. You just write code by hand. The current project of mine has no scaffolding (except for a copy of the default scaffold css file) and it works wonderfully. Also, the scaffolding generator has not been updated in quite some time, and does use a few depricated methods, and the next release of Rails will probably break most of the scaffold based code out there.
  • esuomynona, on 10/12/2007, -4/+0Yeah CakePHP!

    http://cakephp.org

    PHP 4 and 5, write your code with cake, it will work on both.
    • stupidStan, on 10/12/2007, -0/+3shutup... this has nothing to do with the article
  • fenris6644, on 10/12/2007, -0/+1Distributed transactions. Don't try that with Rails (or more accurately, Ruby)!
  • powderedsnow, on 10/12/2007, -1/+0coke
  • CaughtThinking, on 10/12/2007, -1/+1Ruby on Rails, the honeymoon is over! But but but, they said it would never happen!
  • lpicanco, on 10/12/2007, -0/+1These trolls are so funny !!!
  • elliotlarson, on 10/11/2007, -0/+0I'm getting the sense that the "trolls" knocking Rails here haven't even tried the Framework. I'd love to hear some educated knocking of Rails, but instead it seems like all the negative viewpoints are being offered up by those who are ill equipped to comment intelligently on the matter.

    IMO the issues brought up in the article are pretty minor. Scaffolding and pagination helpers are fairly superficial pieces of functionality. There are a whole host of other, more meaty reasons to dig Rails and what it can do for you.
  •  

    Login or register to add a comment

    Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.


© Digg Inc. 2008 — Content posted by Digg users is dedicated to the public domain.
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.