Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Ruby on Rails 2.0 is Done

Posted by CmdrTaco on Sat Dec 08, 2007 12:26 PM
from the i-miss-perl dept.
Jamie noted that ruby on rails 2.0 is done. In addition to upgrade and installation instructions, the article lists a number of the more interesting new features in the release which appears to be quite extensive.

Related Stories

[+] Rails Bigwig Rails on Rails Community 227 comments
Zed Shaw, creator of the popular Mongrel HTTP daemon / library, has decided it was high time to tear into the Ruby/Rails community for many different complaints that he has been collecting over the last few years. "Rails is a Ghetto" is Shaw's self-proclaimed exit strategy from the Rails community. "This is that rant. It is part of my grand exit strategy from the Ruby and Rails community. I don't want to be a 'Ruby guy' anymore, and will probably start getting into more Python, Factor, and Lua in the coming months. I've got about three or four more projects in the works that will use all of those and not much Ruby planned. This rant is full of stories about companies and people who've either pissed in my cheerios somehow or screwed over friends. I can back all of them up from emails, IRC chat logs, or with witnesses. Nothing in here is a lie unless it's really obviously a lie through exaggeration, and there's a lot of my opinion as well."
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • ORM still broken? (Score:5, Informative)

    by poet (8021) on Saturday December 08, @12:30PM (#21624985) Homepage
    I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key.... The Rails developers could learn a thing about databases. Start here: http://en.wikipedia.org/wiki/Database_normalization [wikipedia.org] . Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases.
    • RRN? (Score:5, Insightful)

      by raftpeople (844215) on Saturday December 08, @12:42PM (#21625093)
      Back when I was a young whippersnapper, we called that thing a relative record number!
      [ Parent ]
      • Re:RRN? by skoaldipper (Score:2) Saturday December 08, @01:04PM
    • Re:ORM still broken? (Score:5, Insightful)

      by FooBarWidget (556006) on Saturday December 08, @12:51PM (#21625167)
      People have discussed this over and over and over again. I presume you're talking about support for composite primary keys. They aren't necessarily a good thing. Go read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html [blogspot.com]

      I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Just because normalization is "good" according to ivory-tower database theory, doesn't mean that anything that isn't fully normalized is "bad" or "broken".

      "Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases."

      Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)
      [ Parent ]
      • Re:ORM still broken? by JoeCommodore (Score:2) Saturday December 08, @01:05PM
        • Re:ORM still broken? (Score:5, Insightful)

          by FooBarWidget (556006) on Saturday December 08, @01:13PM (#21625363)
          That's great for you, but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications. Ruby on Rails is not trying to be the thing for everybody. And that's exactly what makes it so powerful and easy. Indeed - turning it into something for everybody actually makes it worse. I'd like to see some proof that composite primary keys are so important in web applications. So far I've seen no convincing evidence. Despite all the complaints about composite primary keys, new Rails websites are written everything, even by high-profile organizations like IBM, NASA, Oracle and Yahoo. And they seem to function just fine.

          If you really, really, really, really need composite primary keys, you can still fallback to raw SQL queries in Rails.
          [ Parent ]
          • Re:ORM still broken? by CastrTroy (Score:2) Saturday December 08, @01:20PM
            • Re:ORM still broken? by FooBarWidget (Score:2) Saturday December 08, @01:33PM
            • Re:ORM still broken? (Score:5, Interesting)

              by crayz (1056) on Saturday December 08, @02:36PM (#21626025) Homepage
              If you do a search for "composite keys rails", hit #1 is this [rubyforge.org], a gem written by a fairly prominent ruby programmer that makes it trivially easy to use composite primary keys within ActiveRecord. My guess is if you actually cared about this issue, rather than just raising it as a canard to bash Rails with, you would have found this solution to your problem and wouldn't be posting here
              [ Parent ]
            • 1 reply beneath your current threshold.
          • 1 reply beneath your current threshold.
        • Re:ORM still broken? by mweather (Score:1) Saturday December 08, @08:14PM
        • Re:ORM still broken? by Allador (Score:2) Sunday December 09, @02:12AM
        • Re:ORM still broken? by TheSunborn (Score:2) Sunday December 09, @04:18PM
        • Re:ORM still broken? by DragonWriter (Score:2) Monday December 10, @12:17PM
      • Re:ORM still broken? by Anonymous Coward (Score:3) Saturday December 08, @01:27PM
        • Re:ORM still broken? by larry bagina (Score:1) Saturday December 08, @01:43PM
        • Re:ORM still broken? by Bill, Shooter of Bul (Score:2) Saturday December 08, @01:46PM
        • Re:ORM still broken? by FooBarWidget (Score:3) Saturday December 08, @01:50PM
          • Re:ORM still broken? by CrazedWalrus (Score:2) Saturday December 08, @02:53PM
            • Re:ORM still broken? (Score:4, Insightful)

              by FooBarWidget (556006) on Saturday December 08, @04:04PM (#21626737)
              "Holy. Crap. You're not the guy that writes Active Record, are you?"

              If you're referring to DHH, then no, I'm not him. My stance isn't as extreme as his ("database is just a big hash") but I do agree with some of his points. Transactions = good. Foreign key constraints = good. Stored procedures = only use when absolutely necessary. Normalization = weight between pros and cons in application code complexity and data redundancies. Etc.

              "The thing a lot of OSS developers seem to forget is that many applications are primarily for data processing with user interfaces thrown on top. I.e. Not every damn "web app" is a blog or wiki, where it's primary purpose is to be a web app."

              Not every, but *a lot* of them are. Very often they're systems for displaying, storing and retrieving small to moderate amount of information (unless you're working on a really really big multi-million system).

              "Fact is that, if Rails wants greater acceptance (and, yes, I realize it is already widely accepted -- I'm talking about continued growth), then it's going to need to support things like composite keys. Why? Because people use them, and the application may have come years before the web interface."

              I don't think so. I'm pretty sure that people complain about composite primary keys because it's so easy to complain about. Most of them probably wouldn't consider using Rails even if it fixes all its "flaws". *
              There was a time when I took all Internet complaints very seriously. I worked very, very, very hard to meet peoples' demand, and I did it for free. In the end, it didn't help. Whenever I publish a fix for one complaint, they complain about other things. It's an endless cycle. The complainers can never be satisfied no matter what I do.
              For example, people complain about memory usage in Rails. I've developed a way to reduce the memory usage by 30% [plan99.net], and look - very few people are interested! The people interested in my work are extremely disproportional to the number of people complaining.

              * But by fixing Rails "flaws", you've just made it worse. The reason why Rails is so great in the first place is because it's a very specialized framework. It's not trying to be the thing for everything, like J2EE. If you make it the thing for everything it'll be a lot more painful to work with. It's like saying that your television can't wash your clothes. While it's possible to make a television that does that, it would be a royal pain to make and to work with.
              [ Parent ]
            • Re:ORM still broken? by Allador (Score:2) Sunday December 09, @02:28AM
            • Re:ORM still broken? by Eivind Eklund (Score:2) Friday December 14, @02:54PM
          • Re:ORM still broken? by coryking (Score:2) Saturday December 08, @03:15PM
          • Re:ORM still broken? by TheSkyIsPurple (Score:2) Saturday December 08, @03:28PM
          • Re:ORM still broken? by Raideen (Score:1) Saturday December 08, @03:30PM
          • Re:ORM still broken? by jadavis (Score:2) Saturday December 08, @03:53PM
          • Re:ORM still broken? by jjn1056 (Score:2) Saturday December 08, @05:43PM
          • Re:ORM still broken? by DragonWriter (Score:2) Monday December 10, @01:16PM
          • 1 reply beneath your current threshold.
        • Re:ORM still broken? by smallpaul (Score:2) Saturday December 08, @02:10PM
        • Re:ORM still broken? by dubl-u (Score:2) Saturday December 08, @06:23PM
        • Re:ORM still broken? (Score:5, Insightful)

          by Ilan Volow (539597) on Saturday December 08, @06:25PM (#21627603) Homepage
          When you as a DBA use anything other than a surrogate primary key, you are making the exceptionally dangerous assumption that the client has the correct understanding of what their model entails, that there will be no exceptions to the rules of that model, and that the model they gave you will never, ever change.

          Borrowing from your SSN example, let's say that your client tells you the main way they identify customers is through the SSN, and you go by that, and then there's a case of identity theft and the customer's SSN number has to be changed? Now you've got potentially thousands of records with a bad primary key that you have to change (and mitigate constraint issues as well). What if privacy issues require the company dropping SSN's as an identifier, and now the company will be forbidden from asking customers their SSN's? You'll no longer be able to generate primary keys compatible with the same ones used before.

          What truly separates a good DBA from a bad one is the good DBA's ability to anticipate change, design for change, insulate existing stuff from change, and basically save the client from any flaws in their own conceptual model (while making it look like they've followed the client's conceptual model to the letter). A bad DBA simply trusts whatever his client says and believes it to be correct and forever immutable.
          [ Parent ]
        • Re:ORM still broken? (Score:5, Insightful)

          by Allador (537449) on Sunday December 09, @02:23AM (#21629451)

          If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as the compound key for order items. If the client says "customers are identified by an arbitrary customer number", then it's okay to use an artificial ID. If the client says "customers are identified by SSNs" then that's your key.
          I hate to feed the cowards, but I just cant let this go.

          You are completely incorrect.

          If your domain model describes the way an actor finds an entry is by Order# and Line#, that should in no way, shape, or form decree what your technical artifacts look like.

          The correct thing to do in that case is to have a unique, opaque, identity key (numeric or guid, just so long as its unrelated to the record data, and has no additional meaning beyond the unique value of that record).

          Then you can also add unique constraints or indexes to the composite key, and/or you can enforce that unique constraint in the application. Or both, for the smart ones.

          But you need to have a unique way to identify the record THAT IS NOT SUBJECT TO CHANGE. In your example, you could re-order the lines, or one line could have been a mistake and you need to move it to a different order.

          If you've used composite keys on order# and line#, then you've got alot of cleanup work to do after your change.

          If you've used proper opaque identity keys, then you just change the data, and there are no side effects.

          Since in that case your joins are also done on the identity keys, your relatinoships are stable even when you change order# or line#.

          The SSN one is even worse. I can guarantee you that if you do that, someone will have the wrong SSN, and it will need to be changed in your data.

          If you've used SSN as the primary key, then its a pain in the ass, and you have to do data integrity cleanup.

          If you've used a proper opaque identity key, then you just change the SSN, and there are no side effects.

          This is stuff you learn the first time you write an app as a junior developer without a mentor, and use SSN as a key. A year or two later you come to regret it, and the lesson is learned for a lifetime.

          [ Parent ]
        • 1 reply beneath your current threshold.
      • Re:ORM still broken? by poet (Score:2) Saturday December 08, @01:35PM
        • Re:ORM still broken? by FooBarWidget (Score:2) Saturday December 08, @02:13PM
          • Re:ORM still broken? by crayz (Score:2) Saturday December 08, @02:56PM
          • Re:ORM still broken? (Score:5, Insightful)

            by coryking (104614) * on Saturday December 08, @03:21PM (#21626425) Homepage Journal
            That stored procedure is awesome (well, it actually isn't very good sql, but it doesn't matter right now). As the developer, you just need to worry about passing the monster name and the database spits out everything you want.

            If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too.

            Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming. Now every change in the database requires you to go into every single application and change something. Kinda like when you get slutty with your code and copy & paste it rather than abstract it out into a library.

            And I'm aware stored procedures don't play nice if you are worried about cross-database issues because you sell the software. This only works when you get complete control over the application & database stack.

            PS: MySQL stored procedures suck. Use a real database with a better stored procedure language.
            [ Parent ]
          • Stored prodcedures can improve performance by Knetzar (Score:3) Saturday December 08, @03:41PM
          • 1 reply beneath your current threshold.
        • Re:ORM still broken? by jadavis (Score:2) Saturday December 08, @04:09PM
        • Re:ORM still broken? by Allador (Score:2) Sunday December 09, @02:56AM
        • 1 reply beneath your current threshold.
      • Re:ORM still broken? by erwan (Score:1) Saturday December 08, @01:35PM
      • Re:ORM still broken? by dfdashh (Score:1) Saturday December 08, @02:09PM
      • Re:ORM still broken? by digitig (Score:2) Saturday December 08, @04:20PM
      • Re:ORM still broken? by EraserMouseMan (Score:2) Saturday December 08, @07:00PM
      • Re:ORM still broken? by Xendarq (Score:1) Sunday December 09, @12:30AM
      • Re:ORM still broken? by A Pressbutton (Score:1) Sunday December 09, @07:33AM
      • Re:ORM still broken? by Espectr0 (Score:2) Sunday December 09, @10:30AM
      • Re:ORM still broken? by mabhatter654 (Score:2) Sunday December 09, @03:47PM
      • Re:ORM still broken? by FooBarWidget (Score:2) Saturday December 08, @01:21PM
      • Re:ORM still broken? by jadavis (Score:3) Saturday December 08, @03:17PM
      • 3 replies beneath your current threshold.
    • Re:ORM still broken? by heinousjay (Score:1) Saturday December 08, @12:54PM
    • Re:ORM still broken? (Score:5, Interesting)

      by thammoud (193905) on Saturday December 08, @01:22PM (#21625449)
      A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change. Use business keys for that.
      [ Parent ]
      • Re:ORM still broken? (Score:5, Insightful)

        by CarpetShark (865376) on Saturday December 08, @03:31PM (#21626521)

        A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change.


        You're assuming that all composite primary keys use values that do change. That's highly unlikely, given the number of tables in the world filled with historical data. That said, I agree (for other reasons) that surrogate keys are much better.
        [ Parent ]
      • 2 replies beneath your current threshold.
    • Re:ORM still broken? by Enahs (Score:2) Saturday December 08, @02:20PM
    • Re:ORM still broken? by arevos (Score:2) Saturday December 08, @03:26PM
    • Re:ORM still broken? by leonbloy (Score:1) Saturday December 08, @03:28PM
    • Re:ORM still broken? by lymond01 (Score:2) Saturday December 08, @03:50PM
    • Re:ORM still broken? by rbanffy (Score:2) Saturday December 08, @05:57PM
    • Re:ORM still broken? by drew (Score:2) Saturday December 08, @09:05PM
    • Re:ORM still broken? by EricTheGreen (Score:2) Saturday December 08, @10:13PM
    • Re:ORM still broken? by F1re (Score:2) Saturday December 08, @11:48PM
    • Re:ORM still broken? by qb001 (Score:1) Sunday December 09, @01:20AM
    • Re:ORM still broken? by Allador (Score:2) Sunday December 09, @01:59AM
    • Re:ORM still broken? by mini me (Score:2) Monday December 10, @01:49AM
    • Re:ORM still broken? by DragonWriter (Score:2) Monday December 10, @12:07PM
    • Re:ORM still broken? by aevans (Score:1) Sunday December 16, @07:42PM
    • Re:ORM still broken? (Score:5, Funny)

      by K. S. Kyosuke (729550) on Saturday December 08, @12:48PM (#21625145)

      Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

      What a relief... As a lisper and rubyist, I'm glad to hear that Python is going to die! Good riddance!
      [ Parent ]
    • You don't have to use ActiveRecord by Anonymous Coward (Score:1) Saturday December 08, @01:07PM
    • Re:ORM still broken? by crayz (Score:3) Saturday December 08, @02:49PM
    • Re:ORM still broken? by smackjer (Score:2) Saturday December 08, @03:06PM
    • Re:ORM still broken? by doupatex (Score:1) Sunday December 09, @08:59PM
    • 6 replies beneath your current threshold.
  • Fresh Meat! (Score:2, Interesting)

    by TechyImmigrant (175943) * on Saturday December 08, @12:30PM (#21624991) Homepage Journal
    Fresh Meat, full of bugs, for the hackers to hack.

    If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.

    • Re:Fresh Meat! by TechyImmigrant (Score:2) Saturday December 08, @01:14PM
      • 1 reply beneath your current threshold.
    • 2 replies beneath your current threshold.
  • by Anonymous Coward on Saturday December 08, @12:35PM (#21625029)
    This new antigravity [xkcd.com] feature is astounding.
  • I don't understand the fuss. (Score:5, Interesting)

    by Russ Nelson (33911) on Saturday December 08, @12:36PM (#21625039) Homepage
    I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?
  • Sites Moved to Rails? (Score:5, Interesting)

    by markmcb (855750) on Saturday December 08, @12:43PM (#21625095) Homepage
    OmniNerd.com [omninerd.com], a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since. Our site has even survived a few Slashdottings and Diggs since the switch, which used to murder it before. (Granted, the PHP code wasn't the best.) I've heard the "doesn't scale" debate a million times, but I'm curious if there is anyone out there who has recently moved a project from one language/framework to Ruby/Rails and whether you're glad you did or if it's been a nightmare. We're a medium-to-low traffic site with big surges every few weeks and it's worked well for us.
    • Re:Sites Moved to Rails? by stuartrobinson (Score:1) Saturday December 08, @01:08PM
    • Re:Sites Moved to Rails? by Bonus_Eruptus (Score:1) Saturday December 08, @01:26PM
    • Re:Sites Moved to Rails? by robinw (Score:1) Saturday December 08, @01:53PM
    • Re:Sites Moved to Rails? by mali_iz_rs (Score:1) Saturday December 08, @01:58PM
    • Re:Sites Moved to Rails? by Tablizer (Score:1) Saturday December 08, @02:49PM
    • Re:Sites Moved to Rails? (Score:5, Interesting)

      by tentac1e (62936) on Saturday December 08, @03:35PM (#21626549) Journal

      We do millions of searches a day at yellowpages.com [yellowpages.com]. One day the order came down that the site was getting rewritten, on a hard deadline. In four months 125,000 lines of Java became 14,000 lines of Ruby, and yellowpages.com became (most likely) the second largest Rails site on the internet.

      The site scaled just fine because we have a team that knows what they're doing. Above all, they did research. They wrote prototypes in other frameworks before settling on Rails. They benchmarked different features and decided what to turn off. Rather than create one giant dumb app, we have a web-tier app for interacting with the user, and a service tier for processing searches with our search cluster.

      Anyone noticed people who say "Rails doesn't scale" never tried to scale it? I am part of a team that has successfully scaled to the second largest Rails site on the internet, and I will always tell people who say "Rails doesn't scale" that they have no idea what they're talking about.

      [ Parent ]
    • 1 reply beneath your current threshold.
  • by sof_boy (35514) on Saturday December 08, @12:45PM (#21625119)
    I am like the 10th comment and it is already slashdotted!
  • Science (Score:3, Interesting)

    by Cache22x (1056176) on Saturday December 08, @02:02PM (#21625797)
    Okay, all I see on here is negative comments, what ever happened to the concept of "the right tool for the job"? Ruby on Rails is a gem (excuse the pun) in the realm of bioinformatics and chemical informatics. I don't need to be concerned with "scaling" when I am building a site with a maximum of 10 users. For labs and small companies everywhere needing to create and support small or large databases, RoR is fast and easy. It also has major industry backing from the likes of IBM and Apple. It may be a bigger problem for high-volume sites, but I have found it extremely useful. I am using it on the backend (for data management - the data is exported from the database to the legacy perl system daily) for sites like http://www.drugbank.ca/ [drugbank.ca] http://www.hmdb.ca/ [www.hmdb.ca] and on the frontend for sites like http://hmdb.med.ualberta.ca/foodb/ [ualberta.ca].
  • by ThinkFr33ly (902481) on Saturday December 08, @02:13PM (#21625879)
    Perhaps a web development framework's web site should be designed in such a way that it can handle a burst of traffic from Slashdot.org and Digg.com.

    Otherwise, one might think that RoR doesn't scale.
  • Does it still require Mongrel? (Score:2, Insightful)

    by ibbie (647332) on Saturday December 08, @02:56PM (#21626213) Journal
    Or rather, since I haven't been keeping up with the development process, perhaps I should ask, is there a viable apache 2.x module for ruby that allows one to run RoR sites without relying on mongrel/other web servers?

    Because, frankly, if it can't be run on apache 2.x, I (and the company I work for) won't touch it. We have already seen the scalability nightmare that RoR was, of course, so obviously we're a bit skeptical about performance optimizations. (:

    Note: I have nothing against using new technology, even if it requires learning a new language, but when one has a hundreds of sites that require web server A, and a framework requires the shoehorning of web server B, well, the aforementioned framework loses its appeal.

  • At this point...JAF (Score:2, Interesting)

    by sigzero (914876) on Saturday December 08, @03:02PM (#21626261)