Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ruby on Rails 2.0 is Done

Posted by CmdrTaco on 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.

7 of 385 comments (clear)

  1. I don't understand the fuss. by Russ+Nelson · · Score: 4, Interesting

    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?

    --
    Don't piss off The Angry Economist
    1. Re:I don't understand the fuss. by pestilence669 · · Score: 4, Interesting

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

  2. Sites Moved to Rails? by markmcb · · Score: 4, Interesting

    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.

    --
    Mark A. McBride -- OmniNerd.com
  3. Re:ORM still broken? by thammoud · · Score: 4, Interesting

    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.

  4. Re:ORM still broken? by crayz · · Score: 5, Interesting

    If you do a search for "composite keys rails", hit #1 is this, 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

  5. Re:Scaling matters if you're Digg. Are you Digg? by slaingod · · Score: 5, Interesting

    Every time a RoR article hits Slashdot, there is a scale/speed question that gets raised. Realistically, there are a ton of things you can do to get performance where you want it to be. The first is to dump mongrel and use FastCGI or similar. FastCGI is 3-5x faster than mongrel. Mongrel is great for low traffic sites, and for dev, don't get me wrong.

    The upper limit I see with RoR/FCGI is around 2500 requests per sec, for a 'is the server alive' ping, that simply returns 'Yes'. Typical, results are in the ~100 requests per second range with moderate db access, and rendering to xml or html. 100 requests per second was enough to handle a 24 hour media buy on the frontpage of myspace for example (100,000k unique visitors-ish).

    Moving your static assets off of your server and on to S3 or another CDN is obviously a big help here, so your server/bandwidth is only taken up with requests that need/affect the db. From the example above, with the MySpace media buy, the total for that day was $20-30 I believe in bandwidth costs, and this was a site with a video mixer that had tons of images/video/mp3 and large flash objects. Obviously, mongrel shouldn't be delivering your assets locally anyway, apache/lighty etc should be.

    Ultimately it comes down to design and caching when it comes to getting that top performance out of it. My 100 requests/sec wasn't using MemCached or fragment caching, and the mysql db was local. Caching in Rails is a little less than helpful for highly customized for each user sites, but there are plugins that extend it like extended_fragment_cache(ing?), that allow you to templatize things like ID's, etc. Think of say a forum topic listing, where only the topics change as you paginate. With extended fragment caching, you basically draw the page once, and then pass in a hash of the variables that replace the placeholders each time you draw a new page.

    Another big thing with ajax sites, is to use link_to_remote with the :update => 'some_div', rather than using the rjs/render :update stuff in the controller. escape_javascript is one of the BIG performance issues in Rails, as it is basically just multiple gsubs. Designing around that is a big win. A native C escape_javascript should be a high priority for the rails/ruby devs, with optimization for the memory allocations (ie. scan the string to see how much it will grow, allocate, and just do one pass to expand).

    --
    http://blog.slaingod.com
  6. Comment removed by account_deleted · · Score: 5, Interesting

    Comment removed based on user account deletion