Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming The Internet IT Technology

Ruby on Rails 2.0 is Done 385

Posted by CmdrTaco 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.
This discussion has been archived. No new comments can be posted.

Ruby on Rails 2.0 is Done More

Ruby on Rails 2.0 is Done

Comments Filter:

  • ORM still broken? (Score:5, Informative)

    by poet ( 8021 ) on Saturday December 08, 2007 @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, 2007 @12:42PM (#21625093)
      Back when I was a young whippersnapper, we called that thing a relative record number!

    • Re:ORM still broken? (Score:5, Insightful)

      by FooBarWidget ( 556006 ) on Saturday December 08, 2007 @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?)
      • If you are working with a redundant distributed DB (where the satellites don't always have connection so the data is mirrored) trying to integrate added data among the nodes is a nightmare with an auto incrementing numeric key.

        • Re:ORM still broken? (Score:5, Insightful)

          by FooBarWidget ( 556006 ) on Saturday December 08, 2007 @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.
          • See there you go generalizing about web applications. Here's a hint. Web applications could be just about any application in the world. There's nothing in particular about a web application that makes it web, Except the web interface. And that may be only one interface to the application. There may very well be other interfaces that connect to the same data. So if there is a need for compound primary keys in any application (which there is) then there are uses for compound primary keys in web applica
            • While theoretically you are correct, it doesn't apply to 99% of the web applications. Most web applications are very CRUD-like and deal with small to moderate amount of data. Most software on this planet is written to be used internally by an organization. Not everybody is building the next MySpace or the next Google search engine.

              So one one side, we have J2EE (and similar frameworks), which is "enterprisey", flexible-until-your-head-pops-off, can-be-used-for-anything, etc etc. The downside of all that flex

              • Re: (Score:3, Insightful)

                by orasio ( 188021 )

                While theoretically you are correct, it doesn't apply to 99% of the web applications. Most web applications are very CRUD-like and deal with small to moderate amount of data. Most software on this planet is written to be used internally by an organization. Not everybody is building the next MySpace or the next Google search engine.

                Some software on this planet might be very CRUD-like. In my experience, all web aplications, specially those for internal use, are CRUD apps with a twist. I haven't seen any CRUD-like app that I could solve in a straightforward way. In general, that twist takes longer to implement than the CRUD part does. In fact, it takes longer to define accurately. Development time is important, but not even that important. The strength of using JEE, or any other big, flexible technology, is that you can define (or get

            • Re:ORM still broken? (Score:5, Interesting)

              by crayz ( 1056 ) on Saturday December 08, 2007 @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
              • You're right, I'm not a Rails developer. I haven't looked up composite keys. What I was doing in my post was responding to the parent, who thought that composite keys weren't supported, and his short-sighted, narrow minded view that you should never need to use composite keys. It's great to hear that Rails supports this, because it actually lets me take Rails seriously. I wasn't raising the issue, I was responding to other users to seem to think that composite keys is an unneeded feature.

      • Re: (Score:3, Interesting)

        by Anonymous Coward
        Getting a *PROGRAMMER'S* opinion on data modeling is probably not a good idea. The view everything as objects or records, which is what they use in their programming. That's a subset of what the relational model allows.

        Here's the simple, easy-to-comprehend reason why surrogate keys should not be used universally: Your logical model should exactly correspond to the client's conceptual model.

        If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as t
        • "If you denormalize, but add constraints to maintain integrity, then you've killed performance for no reason (however this is useful when transition from denormalized designs back to normalized designs)."

          You can't say that will be the case 100% of the time. Most of the times denormalisation is chosen to improve the performance. In which case its faster to be denormailized, even with constraints. There are many different variables that come in to play when discussing database design that can't be accoun

        • Re: (Score:3, Insightful)

          by FooBarWidget ( 556006 )
          Yeah, blame it on the programmers. Taking elitism (or perhaps "anti-programmer-ism" is a better word) to a whole new height.

          Yes, my database theory knowledge is limited. I admit it. I passed the 'database systems' course, but I'm not a professor in database systems, so *of course* my database theory knowledge is limited. That's why DBAs exist and why they are paid to do their job in the first place.
          But you know what, the database isn't the only thing that exists. There's also the actual application. If, by
          • Holy. Crap. You're not the guy that writes Active Record, are you?

            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.

            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?

            • Re:ORM still broken? (Score:4, Insightful)

              by FooBarWidget ( 556006 ) on Saturday December 08, 2007 @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.
          • What are you going on about? Are you afraid of JOIN's or something?

            Have you ever worked on a properly normalized database schema? I have, and it is a dream. When your database is designed correctly, you can mine it for pretty much any kind of information that you dream of.

            As a bonus, a properly normalized database is self documenting. Presented with nothing more than a database schema drawn on a white board, you should be able to deduce how a business works to a fairly detailed level without ever readin
          • My database theory is weak as well, but doesn't normalization basically mean to ensure everything is represented in the database exactly once... no duplicate information and no extraneous information. Checking Wikipedia... http://en.wikipedia.org/wiki/Database_normalization [wikipedia.org]... yep, that's pretty close.
            (At least until you bring on a specific normal form)

            We know nothing about the data space itself, or the constraints in which it will live, and no key info was specified, so we can't even intelligently determ

          • Re: (Score:2)

            by jadavis ( 473492 )
            If, by normalizing stuff to the extreme, makes the application 6 times harder to write

            Well, it certainly is clear that your "data theory knowledge is limited". What does "normalizing to the extreme" mean? There are 5 (or 6, if dealing with temporal data) widely recognized normal forms, each with a very formal definition.

            Most well-designed databases are already in 5NF. If a relation is in 3NF, it's probably also in 5NF, unless you are dealing with multi-valued or cyclic dependencies, something that occurs ra

        • Pretty simple concept, but completely lost on programmers who think the database is the "backing store" for their code (which will likely be replaced or rewritten in few year anyway, especially stuff like PHP, Ruby, etc). No, the database is the foundation of the business. It should be properly designed.

          You're generalizing from your specific situation. Often the goal is to sell the company in a few years to another company that will require you to integrate with their databases in any case. In that case

        • Re:ORM still broken? (Score:5, Insightful)

          by Ilan Volow ( 539597 ) on Saturday December 08, 2007 @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.

        • Re:ORM still broken? (Score:5, Insightful)

          by Allador ( 537449 ) on Sunday December 09, 2007 @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.

      • Re: (Score:2, Insightful)

        by poet ( 8021 )
        Actually no I am not talking about compound keys (although yes that is very, very important). I was talking about:

        CREATE TABLE foo (company_name text PRIMARY KEY)

        Which as I understand it, Rails is too stupid to understand. Granted, the only ORM that I know of that isn't is the one being used by Catalyst but still. It is a major design mistake to assume that your data can be correctly represented in a normalized structure using (id serial PRIMARY KEY).

        I am also not talking about extreme normalization. I am t
        • "Proper design is impossible with rails without reducing performance (the requirement to have a serial primary key and then a natural unique just to satisfy proper data requirements). Rails also increases database maintenance through mention of the above, and increases resource utilization (disk space and IO), reduces transactional velocity (having to update multiple indexes that shouldn't be required) etc..."

          In theory you are true. But I'd like to see some evidence that proofs that lack of support for non-

          • Re: (Score:2)

            by crayz ( 1056 )
            And then I think "Doh! Why does this exist in the first place? Why not just write that SQL query inside a GetMonster() function inside the application?"

            Heh. In Rails that would be Monster.find_all_by_name('whatever'). Without creating any methods at all - ActiveRecord 'created' it for you. The guy below mentioning protecting data from programmers - if that's the philosophy you want to use, why not just quit now?

          • Re:ORM still broken? (Score:5, Insightful)

            by coryking ( 104614 ) * on Saturday December 08, 2007 @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.

            • Re: (Score:3, Insightful)

              by dubl-u ( 51156 )
              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. [...] 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.

              That's a good point, but I think you're learning the wrong lesson from it.

              Yes, duplicating
          • Stored procedures can improve performance by reducing the amount of data that needs to be returned from the DB. Instead of getting a ton of data from the DB, the application can make a call and only get the data it wants. This simplifies application development and improves performance. You can think of things like MAX, MIN, etc... as stored procedures (I don't know if they are or not)

            I have been at places were the DBAs have found very expensive calls to turn into stored procedures and the net result has

    • Re:ORM still broken? (Score:5, Interesting)

      by thammoud ( 193905 ) on Saturday December 08, 2007 @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.

      • Re:ORM still broken? (Score:5, Insightful)

        by CarpetShark ( 865376 ) on Saturday December 08, 2007 @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.

    • Re: (Score:2)

      by Enahs ( 1606 )
      Not true. You can work with a number of different conventions...easier on the DBA, but harder on the person developing the Rails app.

      I don't think this is entirely the best way, but here's ONE way I found by Googling: http://lindsaar.net/2007/11/28/connecting-active-record-to-a-legacy-database-with-stored-procedures [lindsaar.net]

      I know I've seen tips and tricks for PostgreSQL before, but I'm having trouble locating them at the moment. D'oh!

      It's even covered in the Pragmatic Programmers' book on Rails. My copy is in a

    • Re: (Score:2)

      by arevos ( 659374 )
      Meh, all SQL-based databases are broken to some extent, and ActiveRecord requiring primary keys on all tables is less an affront to Codd's design than the things built into any SQL database you care to name. SQL is as much a hack as ActiveRecord, and not as concise.
    • Yes, back in my first foray into web/middleware/database design, I used Apache/PHP/MS Access. With autoincrement. On a production server. The Access database got corrupted, had to be repaired, and then would no longer auto-increment. So my Primary Key was useless, I had to shut down the application, move data around and learned to increment manually through the code. It was in the middle of recruitment, so it was sort of worst case scenario.

      So yes, I agree with not forcing auto-incrementing fields.

  • Fresh Meat! (Score:2, Interesting)

    by TechyImmigrant ( 175943 ) *
    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.

  • I don't understand the fuss. (Score:5, Interesting)

    by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Saturday December 08, 2007 @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?

    • Re:I don't understand the fuss. (Score:5, Insightful)

      by JudicatorX ( 455442 ) <rernst@ s h a d o w l i f e .ca> on Saturday December 08, 2007 @12:40PM (#21625061) Homepage Journal
      You are, or at least so far as hype == marketing.
    • My productivity has been boosted four fold (not a joke!) compared to when I was still developing in PHP. *And* my code is now shorter, more readable, more maintainable, and more secure. I'm not looking back to PHP anymore except for the most simplistic (= less than 500 lines) web applications.
      • comparing php to anything isn't worth the keyboard wear.

      • Re: (Score:3, Informative)

        by CastrTroy ( 595695 )
        Yeah, but PHP is one of the least productive environments there is, at least as far as web development goes. You could switch to .Net, and you would increase your productivity 10 fold. That is, if you stick to the .Net way of doing things. You're application might not scale that great, and you might not have any idea what's going on under the hood, and you might have a 20K viewstate submitted with every form, but you will be really productive in the sense that you can turn out a lot of features in a ver
        • I tried. I seriously considered ASP.NET. And I didn't use it.

          First of all, ASP.NET is almost Windows-only. Mono support is not ready for prime time. This would mean I'd have to use Windows for development work, and it'd significantly lower my productivity. For a while, I installed Visual Studio and played around with ASP.NET. I borrowed an ASP.NET book. But I didn't like the experience at all. Everything is tied to the IDE. I have reasonable C# experience and I quite like the language, but ASP.NET doesn't a

    • Re:I don't understand the fuss. (Score:5, Interesting)

      by pestilence669 ( 823950 ) on Saturday December 08, 2007 @01:23PM (#21625463)
      "Web guys" will never understand the hype behind RoR. For the average PHP coder, RoR is slower and more restrictive... A hindrance. To a software engineer, however, RoR's great use of design patterns and best practices compliments what they should be doing already. Just as an example, if you're not writing unit tests, then you aren't very serious about your software to begin with. RoR's test facilities will bore you and nag you death. What Rails does is force you to consciously decide to not do something you should probably be doing, like testing. If MVC and encapsulation mean nothing to you, then RoR can't help you much. You still need you own discipline, or you can still write abominable code. RoR embodies many practices from how the big boys write software, few from the basement hackers.

      • Re: (Score:3, Informative)

        by CastrTroy ( 595695 )
        But you could do the same thing in PHP. The fact that most people don't doesn't really say anything bad about PHP, but just bad about people who generally use it. A lot of people who write PHP leave SQL injection problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in PHP. Just because most people don't, doe
        • PHP is a language, not a framework. Cake, Akelos, Symfony... Those are valid comparisons. Sure, you can use the raw facilities of the language to build a site, install libraries and tools (PhpUnit, PhpDoc, xdebug, prototype.js, ADOdb, etc.) If you are already building good software, Rails gives you a nice toolbox and prevents you from perpetually reinventing the wheel. Its the layer you should be writing for every project. PHP doesn't provide anything out of the box. In fact, it even discourages best practi

        • Re:I don't understand the fuss. (Score:5, Insightful)

          by crayz ( 1056 ) on Saturday December 08, 2007 @02:20PM (#21625935) Homepage
          Please just try Rails for a little while. While Rails has its flaws, overall it's a highly productive framework - and much of the credit for the terrific code clarity goes to Ruby, which is much more powerful and dynamic than almost any other mainstream language(other than maybe Javascript)

          Some things to read about and try within Rails:
          * ActiveRecord's ability to introspect the DB schema at runtime. e.g. autocreating the method to allow: User.find_by_name('Joe')
          * ActiveRecord's magic-fields, e.g. created_at/updated_at
          * the ActiveRecord associations, and the easy DB queries that come with them, e.g. @user.posts.find(:all, :conditions => {:status => 'pending'})
          * the scope_out plugin, which provides some nice additions to 'with_scope'. e.g. in the Post model you could do scope_out :pending, :conditions => {:status => :pending}, and then be able to change the previous example to:
          @user.posts.pending
          * ActiveRecord callbacks and the controller before/after filters
          * the RESTful routing and easy links that come with it, e.g. link_to(@user.name, @user) will create a hyperlink to the correct URL for that user record's 'show' page
          * the form/field helpers which also integrate with the routing, so you can now do just form_for(@user) - it will create a proper form tag for hitting either the create or update method for that @user, depending on whether the record has already been saved to the database - the form_for/fields_for block syntax is also very powerful, especially when you add your own form helper methods
          * all the convenience methods provided by active_support, like 5.minutes or 1.month.ago
          * Ruby itself - Ruby is simply a joy to code in. even if I were going to dump Rails, I would now strongly prefer to find a new Ruby framework(like Merb) than using another language

          I'd strongly urge you to pick one or more of the PHP MVC frameworks to look at while you read about Rails. Most of them are copies or at least inspired off Rails to some degree, so they often use similar conventions. You'll see the difference between what's possible in PHP and Ruby - PHP doesn't come out looking too good at the end

          • and much of the credit for the terrific code clarity goes to Ruby

            Parenthesis in function calls are optional! That's not what I would call "clarity".

            My impression after using RoR for a few months is that "what seems logical" to Ruby's creator is not what seems logical to me.

        • But you could do the same thing in C. The fact that most people don't doesn't really say anything bad about C, but just bad about people who generally use it. A lot of people who write C leave memory leaks and buffer overrun problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in C. Just because most people don't, d
    • You're absolutely right: Rails is just a framework on top of Ruby, and neither are very special. Except in that a lot of people were still using crap coding techniques like mixed PHP and HTML, until frameworks like RoR and Django introduced them to MVC, ORMs, templates, and Unit Testing --- AND the speedups and elegance that go with those things, once you have an actual framework that does the boilerplate for you.

      There's nothing special about RoR, no. But compared to tools like PHP, it's a godsend.

  • Sites Moved to Rails? (Score:5, Interesting)

    by markmcb ( 855750 ) on Saturday December 08, 2007 @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.

  • Science (Score:3, Interesting)

    by Cache22x ( 1056176 ) on Saturday December 08, 2007 @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].

  • I guess they didn't fix the scalability issues (Score:5, Funny)

    by ThinkFr33ly ( 902481 ) on Saturday December 08, 2007 @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.

    • Re: (Score:3, Interesting)

      by abigor ( 540274 )
      That's why I'm curious as to why Django (Python framework) doesn't get more press. It's fast and, unlike Rails, it's been proven to scale (ie washingtonpost.com). The languages have more similarities than differences, so it can't be that. Better marketing/hype, maybe?

      • Re: (Score:2, Interesting)

        by ibbie ( 647332 )

        That's why I'm curious as to why Django (Python framework) doesn't get more press. It's fast and, unlike Rails, it's been proven to scale (ie washingtonpost.com). The languages have more similarities than differences, so it can't be that. Better marketing/hype, maybe?

        I think you hit the nail on its head. Django fricken rocks, in my experience, in both speed and usability.

        It just doesn't have the hype engine going for it the way RoR does. It's for this reason that I'm hoping the Perl on Rails thing that the BBC wrote gets some momentum - the MCV/MTV approach is a Good Thing, for web-based development. It's not a change in language, so much as a change in how it's laid out. One must note that CGI::Application (found here [cpan.org]) has existed for Perl for quite some time

        • Re: (Score:2)

          by abigor ( 540274 )
          Yeah, it's not so much a language thing either - yes, Ruby is slow, but Django also has sophisticated caching support, for example, which is a framework design issue that is language agnostic. I just think the framework itself, all talk of language aside, is really well designed. I like how you define your db scheme in Python (of course, it's possible to introspect an existing db to create the Python model classes as well), the loose coupling of urls, and so forth. The whole thing feels very practical and g
        • ``I do have to note that, having had experience with both Perl and Python, Ruby isn't bad at all. It's different in some ways, yeah, but so is Java, or C++, or C#. It's more a matter of taste, for a developer.''

          I am not sure how you intended this to be taken, but if you meant to imply that the differences between all the languages you mentioned are just a matter of taste, I must disagree.

          The languages you mentioned differ on features that have a very real impact on productivity, reliability and maintenance.

      • Re:I guess they didn't fix the scalability issues (Score:4, Interesting)

        by pavera ( 320634 ) on Saturday December 08, 2007 @08:16PM (#21628133) Homepage Journal
        I prefer django over RoR hands down. I drank the RoR cool aid about 8 months ago, started working on a couple projects... after the initial "oh wow, that was easy to get started" RoR got significantly more difficult, I didn't find the documentation particularly helpful, and things that I thought intuitively would work and made sense were "not allowed" because the RoR conventions forbade them.

        Enter django. Wow, all the power, none of the "Hansson said this is how it should be, so no other way is possible" handcuffs.

        To me django is a much better designed framework, it has in my opinion a much more powerful database abstraction layer, it is more intuitive too. working in Rails for > 4 months I still had to look up the syntax for doing activerecord queries every single time. django's query syntax just makes sense to me, and is much more intuitive. And what can I say, I've never enjoyed making HTML forms more than using the newforms library that builds them for you (oh yeah, and validates them for you, and marshals form input into objects automatically...).

        Also, the simplicity of setting up a production django server is so much easier than RoR. Sure, once you start having lots of traffic, building a fully scalable system is probably going to be similar. But to set up a single server for a low traffic site, or a small company intranet, apache+mod_python is great. mod_ruby has huge performance issues, ror+fastcgi in apache is atrocious, mongrel can be ok.. but then you still have to set up apache in front of it, and its not a simple apache set up as you have to configure all the proxy stuff...

        Besides the fact that python is ~10 times faster than ruby (just at the interpreter level) and you've got yourself a nice little powerful system with django.

        Maybe once django hits version 1.0 they'll get a bit more hype, but I've actually seen more posts on this story saying "check out django" than I've seen people saying they absolutely love rails.
    • Ironically, I believe the rubyonrails.org site was built with PHP.
  • 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 technol

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

    by sigzero ( 914876 )
    RoR is just another framework now. Almost everything has caught up to it. The biggest question to ask yourself is "Do I want to program in Ruby?". If the answer is "no" then meh who cares about this.

    • The biggest question to ask yourself is "Do I want to program in Ruby?". If the answer is "no" then meh who cares about this.


      The other one is, "can ruby perform well enough for any reasonably loaded webapp?". So far, most of the answers I've heard amount to "no", or "well, if it gets to that stage, you can always buy a cluster".
  • Apparently the server's done (like Nixon, not like Dinner).
  • Having worked on web sites using Rails in a previous job, I have to say I love many things about the framework. Like Ruby, it gets a lot of things right, and a few things very wrong. On the whole, I found it great to work with.

    Recently, a friend told me that scalability was a major concern with Rails. I am not aware of any issues with that with the sites I worked on (which are pretty high traffic), but I left the project before the sites went live, so I can't say for sure that there weren't any issues. Can
    • It depends. There have been cases (such as Twitter) where Rails apps have run into problems at high load. However, there are always solutions. Twitter's problem wasn't caused by Rails, it was caused by how they were using Rails. Their bottleneck was actually in the database, and Rails doesn't support multiple databases. Within 2 or 3 days of the issue becoming public a plugin was released. The nice thing about Rails and Ruby is that they are flexible. The dynamic nature of Ruby makes it easy to extend, and

  • It is a pity ... (Score:3, Interesting)

    by jopet ( 538074 ) on Saturday December 08, 2007 @03:27PM (#21626475) Journal
    that one cannot simply deploy RoR on Apache. That is what remains the big advantage of perl and especially PHP-based solutions and frameworks.

  • Why the hate? (Score:3, Insightful)

    by devjj ( 956776 ) * on Saturday December 08, 2007 @04:01PM (#21626711)

    Seriously.. why does Ruby on Rails get so many people so fired up? If you don't like it, don't use it. If you do like it, feel free. There's no one-size-fits-all solution, but for many people Rails comes pretty close. If you're not one of those people, there are plenty of other frameworks and languages.

    Why do people in any kind of IT have such huge egos? It's counterproductive and at the end of the day, if you're making the client happy, and that makes your boss happy, you've done your job.

Slashdot Top Deals

Repel them. Repel them. Induce them to relinquish the spheroid. - Indiana University fans' chant for their perennially bad football team

Close