Slashdot Mirror

← Back to Stories (view on slashdot.org)

Rails and Merb Ruby Web Frameworks Merge

Posted by kdawson on from the flattened-red-gem dept.

An anonymous reader writes "The Merb and Rails Core Teams today announced a major merger; the two projects will become one, and be released some time in Q2 of 2009 as Rails 3. This is great news for lots of folks who worried about the potential community fracture, as well as great news for all the developers who will now have an all-around better option for programming Ruby. Read more about the details in Yehuda's blog post, or at the Ruby on Rails blog."

80 comments

  1. WTF by Anonymous Coward · · Score: 0

    I'm sorry, what and who???

    1. Re:WTF by LiteralKa · · Score: 0

      Read the story before posting.

      --
      nonconformity at work
    2. Re:WTF by larry+bagina · · Score: 4, Informative

      Merb is like a lightweight RoR. Lightweight because it's more optimized and leaves more decisions up to the end user (as opposed to RoR's one size fits all). Ruby on Rails v3 will be more modular so if the shoe fits, you wear it. But everyone else can replace the parts they don't need or want.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    3. Re:WTF by Anonymous Coward · · Score: 0

      Read the story before posting.

      "You must be new here."

    4. Re:WTF by SanityInAnarchy · · Score: 3, Informative

      It's also been lightweight in that Rails has always had everything you need, in some form. All kinds of Rails plugins that won't work with Merb. All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.

      This move is good for Rails for obvious reasons, like the ones you've outlined -- even just ActiveSupport takes something like a half second to load on my machine. But it's also a good move for Merb -- probably the single biggest problem Merb had, for many people, was "it's not Rails."

      --
      Don't thank God, thank a doctor!
    5. Re:WTF by Sentry21 · · Score: 1

      All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.

      That's one thing that's always stuck out as unusual and unnatural to me - making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.

      It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds" (or something, however the syntax works).

      It just comes across like Rails tries to make things convenient that were never really THAT difficult, or which could have been done in a far more sensible way, rather than with contrivances. It's as though, when designing features, special-cases are as equally valid as generalizations, which leads to a lot of what most programmers I know would call silly features.

      I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations. Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.

    6. Re:WTF by ComaVN · · Score: 2, Interesting

      I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations. Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.

      Agreed, but note that it's rails that adds the date/time functionality, not ruby. While I think it's great that it's *possible* to change the behaviour of core classes, this should be done with extreme restraint, and rails seems to have gone a bit overboard with it.

      --
      Be wary of any facts that confirm your opinion.
    7. Re:WTF by SanityInAnarchy · · Score: 1

      making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.

      Not at all required, but that's one of the things I love about Ruby -- that you can do that, which makes the code extremely readable. Whether or not you like the fact that these methods exist on integers, it doesn't really hurt, and at a glance, even a non-programmer understands.

      It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds"

      So, instead of adding methods to an integer, you'd be parsing strings? I like the Rails way better.

      Oh, and it's a bit more flexible than that -- because 5.seconds is actually a value of time, and 5.seconds.ago is actually a datetime.

      But then, if you don't like this, you'll hate rspec...

      It just comes across like Rails tries to make things convenient that were never really THAT difficult, or which could have been done in a far more sensible way

      Perhaps not, but Rails is targeting the first 80% -- and while it takes some time to get used to, it's now at the point where I get quite annoyed when I can't do 5.seconds.ago, and instead have to do something like Time.at(Time.now.to_i - 5) -- and that's not even equivalent (5.seconds.ago handles usecs).

      So, while it's not that difficult, it's also damned convenient, and if Rails stopped doing it, I'd find something that did, or write it myself. Hopefully Merb/Rails3 will split it out into some small time-manipulation library, so that a Rails app can be built without it, and a separate app can be built with it but without a huge pile of ActiveSupport.

      I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations.

      You'll hate the Inflections library, then.

      Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.

      I really don't see the connection to this, though. What's spaghetti about having a convenient way to create and manipulate time durations?

      --
      Don't thank God, thank a doctor!
    8. Re:WTF by Sentry21 · · Score: 1

      The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly. Maybe I'm too much of a purist, but clearly-defined modules with clear delineation points between them makes it easy to conceptualize the code.

      In Python for example, if I want date/time manipulation, I import the requisite module. Same with threads, process manipulation, file path handling, and so on. In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.

      I think that, more than anything, is what unsettles me about the whole affair, but then I guess not knowing what's going on under the hood is part and parcel if you're using a giant framework like Rails.

    9. Re:WTF by GreyWolf3000 · · Score: 1

      Ruby does not stick date/time functionality into integers (or Fixnums, in Ruby lingo). Rails has extended Ruby's Fixnum class to provide methods that convert and operate on dates. It's also added methods to convert 1.thousand into 1000. Since you deal with and compare datetimes SO often when building database-modeled GUI applications, this is a Good Thing in that context. When I write rails code, it's convenient. When I write Ruby code outside of rails, I almost always don't want that.

      The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes. But I must admit, when I resign myself to doing things the Rails way, I can get things done quickly, and reliably.

      --
      Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
    10. Re:WTF by SanityInAnarchy · · Score: 1

      The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly.

      If you say so -- keep in mind that not much has to be done within the integer class, other than creating and referring to objects of more appropriate classes. I am not sure if this is actually what Rails does, but it would make sense.

      And in that sense, I don't see 5.seconds as being uglier than seconds(5) -- after all, it is unlikely that anyone would create a "seconds" method on integers except for that purpose. Beyond that, I'm sure you will agree, methods like 'ago' or 'from_now' make sense.

      There are Time, Date, and DateTime classes in Ruby, and they work more or less the way you expect. Time is available out of the box, and Date/DateTime is available in the standard library. This is just a convenient interface for dealing with them -- 5.seconds.ago will, in fact, return a Time object.

      And if you really don't like it, just don't use Rails. Ruby itself has nothing related to dates in its Integer class. Rails (specifically, ActiveSupport) adds them.

      In Python for example, if I want date/time manipulation, I import the requisite module.

      And that is still true -- here, if you want to manipulate dates and times in this way, you require activesupport, which requires date and a few other things. The good news about Merb is, it's likely that you won't need all of activesupport to make that happen.

      In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.

      This is not the case -- you're confusing Ruby and Rails. If you have an environment set up, you can easily compare by running a simple irb, which will give you a bare Ruby, versus opening a Rails project and running script/console, or requiring activesupport in another irb.

      More importantly, why would it bother you? What possible disadvantage could there be to having methods like seconds, minutes, and hours on integers, other than seeming conceptually odd?

      not knowing what's going on under the hood is part and parcel if you're using a giant framework like Rails.

      Perhaps. I found Rails code needlessly long and complex, but it was readable, and open source. So it's not actually that difficult to figure out what's going on, especially if you know Ruby well.

      And we haven't really touched on symbols. One trick adopted by Rails, which is actually built into Ruby 1.9, is Symbol#to_proc. I don't have an example offhand, but I'll try to explain what it does:

      Symbols are, effectively, frozen strings which are faster to compare. That's oversimplifying, but it's enough to give you an idea.

      Procs are chunks of executable code, much like an anonymous function. Ruby methods often take procs as arguments. Contrived example:

      ducks = [Duck.new, Duck.new, Duckling.new]
      ducks.each do |duck|
      duck.quack!
      end

      That each method, on that array, is taking the do..end block as proc argument, and calling it once for each duck in the array. Rails changes the Symbol class like this:

      class Symbol
      def to_proc
      Proc.new do |object|
      object.send self
      end
      end
      end

      send, in this case, means "send this message to this object" -- effectively, "foo.send :bar" is equivalent to "foo.bar". So now, I can actually do this hack:

      ducks.each(&:quack!)

      That ampersand effectively means, turn this into a proc. So, the result of :quack!.to_proc is passed to ducks.each. More compact, more readable once you've seen it used.

      It takes a bit to

      --
      Don't thank God, thank a doctor!
    11. Re:WTF by SanityInAnarchy · · Score: 1

      The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes.

      That's not metaprogramming, that's Rails, or at least, Rails 2. Check out Merb for a counterexample.

      Better yet, learn how it works, and then see if you can do better. I remember digging into ActionMailer, and being frustrated at the sheer bloat, but when I wrote something similar (wrote to the database, rather than to SMTP), it was much smaller.

      --
      Don't thank God, thank a doctor!
    12. Re:WTF by GreyWolf3000 · · Score: 1

      I consider code that runs when a class is inherited from another, and dynamically defines a set of methods for that class, naming them on the fly to be meta-programming. Maybe my definition is wrong. This kind of programming is ugly almost by definition; and if I wrote it, anyone else would also consider it a mess. That's just the nature of the beast.

      --
      Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
    13. Re:WTF by Anonymous Coward · · Score: 0

      In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.

      Rails is not Ruby. Rails is not Ruby. Rails is not Ruby. Those Rails people try to be so fucking clever all the time, and they more often than not, do things any professional programmer would find questionable. And every time they do, I have to hear that it's Ruby's fault. The two are not equivalent.

      Why anyone would want to merge their project with rails is beyond me.

    14. Re:WTF by SanityInAnarchy · · Score: 1

      Sorry, I guess I wasn't clear...

      Yes, it is meta-programming. However, I don't think it's an inherent property of metaprogramming, that it has to be ugly, spaghetti, or convoluted.

      My point was that yes, Rails metaprogramming is ugly. However, that's Rails. Metaprogramming can be done properly.

      --
      Don't thank God, thank a doctor!
  2. Win - win scenario. by LiteralKa · · Score: 1

    Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.

    --
    nonconformity at work
    1. Re:Win - win scenario. by eln · · Score: 4, Funny

      Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.

      I agree. They can really leverage synergies and break down some silos with this.

    2. Re:Win - win scenario. by just_another_sean · · Score: 1

      Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.

      I agree. They can really leverage synergies and break down some silos with this.

      Well then I'm excited.

      --
      Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
    3. Re:Win - win scenario. by jadavis · · Score: 1

      Why do you say that? Making an effective release of any platform is no easy task.

      It seems easy with the exponential growth that Rails saw in the past, because you don't have to care about the existing users. Just break everything, whenever you want, there are plenty of new users. You don't care if a library has bugs in it, because users are starting from scratch, so they'll just be happy it does anything at all.

      Now, with adoption growing at some more reasonable pace, they'll need to satisfy existing users. If they don't, nobody will use the new version, and the old version will stick around. Then they have to maintain two frameworks, and they have a mess. Half the libraries work on the old version and are broken on the new version, and vice versa.

      I'm not saying they can't do it. It may go just fine, and I hope it does. But if you only see the benefits, and you don't see the costs (or dangers), you are better off blind.

      If you have difficulty imagining a bad release and its impact on a project, look at MySQL and the 5.1 "GA" release. Or Vista.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    4. Re:Win - win scenario. by dkf · · Score: 1

      Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.

      I agree. They can really leverage synergies and break down some silos with this.

      They're not breaking down silos. They're just building a bigger silo.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
  3. Rails community grows up by spinkham · · Score: 2, Insightful

    Either today is April 1st.. (Checks calendar). Nope. I guess Rails is no longer a ghetto. (Sorry Zed) The rails and merb teams collaborating on making a good project... It just brings tears to my eyes to see these boys grow up and play nice.

    --
    Blessed are the pessimists, for they have made backups.
  4. Rails 3 - Rails and Merb Merge by Anonymous Coward · · Score: 0

    See details: http://railsgeek.com/2008/12/23/rails-3-rails-and-merb-merge

  5. Tags by Anonymous Coward · · Score: 0

    I love them.

  6. Good lord, what is with the taggers? by ShadowRangerRIT · · Score: 3, Interesting

    At time of posting we have:

    • rubyonrailssucks
    • rubysucks
    • rubysucksdonkeyballs
    • fuckruby
    • rubyblows

    ...

    Either the taggers got up on the wrong side of bed today, or my general impression of Ruby is horribly wrong.

    --
    $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
    1. Re:Good lord, what is with the taggers? by Anonymous Coward · · Score: 2, Insightful

      Every technology has it's haters. Especially when it comes to web. Any post about PHP is bound to have the phpsucks tag. Java, Flash, etc. have their own hate tags too. PERL is pretty much the only one with sufficient amount of fanboys here to avoid any negative comments...

      But in the end tags are never about consensus. They are about the consensus of the loudest people. If such people were smart and knew what they were talking about, democracy would have made the world perfect long ago.

    2. Re:Good lord, what is with the taggers? by tcopeland · · Score: 1

      > Either the taggers got up on the wrong side of bed today,
      > or my general impression of Ruby is horribly wrong.

      Quite so. For my military reading list site, Rails is awesome. Plus Sphinx for searching, of course.

      --
      The Army reading list
    3. Re:Good lord, what is with the taggers? by mypalmike · · Score: 2, Interesting

      I just finished my first rails project, a caption contest. Took about 3 days to implement. OK, yeah, the ugly html layout sucks at the moment, but the backend functionality works pretty well considering the time invested.

      --
      There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
    4. Re:Good lord, what is with the taggers? by Anonymous Coward · · Score: 0

      You know, people hate rails because, ruby is slow and rails is hard to deploy.
      But then again, there are some graphs regarding the upcoming ruby 2.0 performance and it may be on par with python and php if not even faster. As for the ease of deploying, you can do it seamlessly with mod_passenger nowadays (which shouldn't take more than two minutes to compile and configure in the first place).
      So Ruby On Rails definitely has a bright future ahead.

    5. Re:Good lord, what is with the taggers? by tcopeland · · Score: 3, Informative

      > the backend functionality works pretty well considering the time invested.

      So true. I think Rails (especially when combined with Passenger) really lowers the bar for getting a dynamic web site with readable URLs (e.g., /captions/public/posts/4/entries/new) up and running. It opens a lot of doors; good times indeed!

      --
      The Army reading list
    6. Re:Good lord, what is with the taggers? by poulbailey · · Score: 2, Interesting

      Speaking of which, why won't Slashdot let me turn the tags off?

    7. Re:Good lord, what is with the taggers? by SanityInAnarchy · · Score: 2, Informative

      You're absolutely right that Ruby is slow, and Ruby 2.0 will make it faster. But relative to what?

      It turns out, someone has done benchmarks, and the results may surprise you. It turns out, Ruby really isn't that slow.

      As for the ease of deploying, you can do it seamlessly with mod_passenger nowadays

      You know, I really don't get this -- how, exactly, is Passenger easier to deploy?

      For that matter, how is Rails hard to deploy? I've always found Capistrano to be much easier (and more powerful!) than sending PHP files over FTP.

      --
      Don't thank God, thank a doctor!
    8. Re:Good lord, what is with the taggers? by knewter · · Score: 2, Informative

      Passenger is crazy easy to deploy. It also allows you to use Enterprise Ruby, with it's COW GC. It's a much better deployment strat. than a pack of mongrels in my extensive production usage. Your mileage may vary, but I doubt it.

      I currently run a lot of sites both ways. Nothing wrong with either. But my passenger deploys are simpler (I have a single cap script that also sets up my vhost, reloads apache...basically puts the site live in one step. This was a ton harder in mongrel setups.)

      --
      -knewter
    9. Re:Good lord, what is with the taggers? by tcopeland · · Score: 1

      > is Passenger easier to deploy?

      It's easier because you can replace a mongrel cluster with mod_passenger which dynamically configures the cluster size. Kind of like you configure an Apache web server - you don't set it to have 10 instances running all the time, instead you set it to never exceed 100 process and let Apache manage how many processes it needs under that maximum threshold.

      But you're right - the actual deployment is still done with Capistrano, albeit with some minor tweaks to the deployment tasks.

      --
      The Army reading list
    10. Re:Good lord, what is with the taggers? by Anonymous Coward · · Score: 0

      I like to think of it this way: If you had the choice to setup from scratch, would you want to go with the crowd who have just put aside their differences to create a better product, or go with people who are immature enough to use language like "sucksdonkeyballs". They certainly don't seem to be doing their anti-Ruby cause any favors. What are all these RoR-hatters running, anyway?

    11. Re:Good lord, what is with the taggers? by SanityInAnarchy · · Score: 1

      It also allows you to use Enterprise Ruby, with it's COW GC.

      This is something Merb is likely to support out of the box, soon, if it doesn't already.

      --
      Don't thank God, thank a doctor!
    12. Re:Good lord, what is with the taggers? by Anonymous Coward · · Score: 0

      Because they assume, for some crazy reason, that you are not a fucking idiot and can JUST IGNORE THE GOD DAMNED TAGS.

      Just like the pack of cretins that absolutely MUST piss and moan on every "idle" type story, as if some evil little elf forced them to read each and every story on the site.

      Repeat after me: "I can ignore any slashdot features which I do not find useful. I do not have to read slashdot stories I do not find interesting."

      There, was that so hard?

    13. Re:Good lord, what is with the taggers? by larry+bagina · · Score: 1

      There's a preference to ignore Idle stories on the front page.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    14. Re:Good lord, what is with the taggers? by Ant+P. · · Score: 1

      Stick this in your userContent.css:

      @-moz-document domain(slashdot.org) {
          div.tag-widget-stub { display: none !important }
      }

    15. Re:Good lord, what is with the taggers? by poulbailey · · Score: 1

      Thanks. I hadn't thought about outright blocking it.

    16. Re:Good lord, what is with the taggers? by LiteralKa · · Score: 1

      Now we have "willyonwwheels".

      --
      nonconformity at work
    17. Re:Good lord, what is with the taggers? by SanityInAnarchy · · Score: 1

      I see...

      So, Passenger won't be needed as soon as Merb completes its own, similar project. It is already able to fork, which is especially useful in development mode, and there has been talk of having it fork on demand, to dynamically scale your cluster up and down.

      That's good, because Passenger is a little too tied to Apache for my tastes. I much prefer a pure-Ruby solution which I can throw behind any old load-balancer.

      --
      Don't thank God, thank a doctor!
    18. Re:Good lord, what is with the taggers? by tcopeland · · Score: 1

      > I much prefer a pure-Ruby solution
      > which I can throw behind any old load-balancer

      Right on, yup, that sounds better to me too. But, for now, Passenger is a vast improvement over mongrel_cluster.yml and all that.

      --
      The Army reading list
  7. Who cares by moniker127 · · Score: 0, Redundant

    I'm sorry if i'm missing something, but I never understood the point of ruby on rails.

    1. Re:Who cares by Allador · · Score: 3, Insightful

      Ridiculously fast development time. It's insanely productive for the 80-90% cases that you run into.

      Really nice schema/db migrations system built in.

      Ridiculously simple to take a web app built with it using standard postbacks, and make it all super-fancy ajax, in-place-editing, and lightbox goodness.

      Ridiculously easy to turn the whole thing into a REST engine for some other front-end or machine-to-machine usage.

      My (un-quantified) perception is that its running about 1/3 the size (lines of code) of a similar php app, and even a smaller percentage compared against asp.net/java.

      For a certain segment of app development needs, its really quite compelling.

    2. Re:Who cares by An+Onerous+Coward · · Score: 2, Funny

      Depending on who you ask, it's either to make good web developers more productive, or to make idiot web developers marginally productive. As an idiot web developer, I can only vouch for the latter. But I must say, I do love me some Rails.

      --

      You want the truthiness? You can't handle the truthiness!

    3. Re:Who cares by Enry · · Score: 2, Interesting

      It may be easy to write and deploy, but as a sysadmin that builds the systems that run RoR apps, it stinks.

      There's little to no debugging, we've gone through four different ways to run RoR apps, and there are new versions every few weeks.

      For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.

    4. Re:Who cares by Allador · · Score: 2, Informative

      I agree that there are lots of gotchas in your first few deployments before you learn all the unwritten rules.

      Nowadays though, its not much different than deploying a PHP app, using mod_rails/passenger.

      svn up your changes (or capistrano or whatever you like), then touch tmp/restart.txt and thats it.

      It's not quite to the level of simplicity of PHP, but it wont take long.

      For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.

      I'm not entirely sure what you mean here, other than you're obviously frustrated with the platform.

      I've never tried to run a rails server with the app content on a network-mounted filesystem, but I have done that with assets (images, etc). And I'm not sure why you would ever run Rails via CGI, unless this was several years ago, predating mongrel.

      I could see that its possible certain parts of the app folder structure may not play well with NFS, but you could keep those on a local fs (ie, everything under log/ and tmp/).

      Were you running a cluster for example, with all of them mounting the same app filesystem for simplicity? If that were the case, each server would almost certainly need their own local tmp/ and log/.

    5. Re:Who cares by hamoe · · Score: 1

      Yes, it has changed a lot in the past few years, but it has only been around for four years and took time to mature. Deploying it has not been that difficult for a while now in a dedicated environment, and with Passenger (mod_rails) it is ridiculously simple even in a shared environment. Running Rails apps via CGI has not made sense for quite a while, even if you were using Fast CGI, Mongrel and a load balancing proxy have performed better and been easier to set up for quite some time.

      Also, I'm not sure exactly what you mean about no debugging. ruby-debug works well, you can catch exceptions and do what you want with them, there are plenty of monitoring options, etc.

    6. Re:Who cares by KagatoLNX · · Score: 4, Informative

      For debugging, New Relic provides some awesome tools that allow introspection of delay and timing at a function dispatch level. If you're serious about Rails, New Relic is for you.

      As for file-backing your Rails app, my company has had huge success with GFS. It can be a beast to maintain sometimes, but it will crank out the IOPS behind very hungry RoR apps fairly well. It also requires shared block devices, though, so it may not be for you. The S3 plugins for Merb and Rails also go a long way to scaling everything but the code itself (which should be manageable on even the surliest NFS deployment).

      We've done some really good work with Rails deployment. There are a ton of ways to deploy it, but I think that is more reflective of the variance in people's deployment requirements more than anything else. Phusion's Passenger and Engine Yard's deployment work are helping to lay down best practices here, and we'd be glad to talk to you about smoothing out the deployment process.

      Rails is definitely a good application for teasing out some of the pathological behavior in NFS, but that's not necessarily a bad thing about Rails. It's already used by some to test the pathological niches in new Ruby releases (e.g. "Does it pass the Rails test?").

      Working with Yehuda and Ezra on a daily basis, I can safely say that you can expect to see a lot of attention to performance and refactoring some of the cruft that has inevitably popped up in Rails' large codebase. DHH has a great vision and Yehuda has great attention to detail. I don't want to imply that "Rails needs Merb" or "Merb needs Rails", but I expect some really good results from the collaboration.

      --
      I think Mauve has the most RAM. --PHB (Dilbert Comic)
    7. Re:Who cares by SanityInAnarchy · · Score: 1

      There's little to no debugging

      Doesn't sound like a sysadmin, but I'll bite.

      Yes, the debugging does kind of suck. On the other hand, Rails is pretty easy to test. I do still occasionally break out the debugger -- which does exist, and isn't actually that bad, just isn't good -- but for the most part, unit tests work well enough.

      we've gone through four different ways to run RoR apps

      And they do seem to be improving... Right now, Rails apps are generally run as a standalone webserver, which can (if needed) be placed behind a load-balancing proxy like nginx, making it easy to scale horizontally.

      I don't really see that going away. Everyone seems to be wetting themselves about Passenger, but really, I suspect I'll be running little embedded Ruby webservers for awhile now. Rack makes them pluggable, so if you don't like Mongrel, you can use something else. It also means that they can be put behind any frontend you like, and it means you can run whatever you like on the backend, without having to think too hard.

      Rubygems make it easy to maintain multiple versions of Rails -- not that you really have to care. It's not hard to bundle Rails itself with the app -- thus, the system I've described above is really more a Ruby app deployment, not just a Rails app deployment.

      --
      Don't thank God, thank a doctor!
    8. Re:Who cares by Anonymous Coward · · Score: 0

      There's little to no debugging, we've gone through four different ways to run RoR apps, and there are new versions every few weeks.

      What exactly are you trying to debug? As for deploying new versions, It's dead simple to bundle rails with the application, and then all you are doing is an application deploy.

      For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.

      Why were you running as a CGI in the first place? Did you do any research before hand? I don't understand how you would do any reading about ruby without stumbling across it's relative slowness, and then you tried to add another layer to the process? And then you add NFS for good measure?

      Rails is optimised for developer productivity, not for raw execution speed. As a sysadmin, you need to run it with either a pack of mongrels or phusion passenger. If you're debugging for more than 15 minutes per deployment, you need to get your developers to write some more unit tests.

    9. Re:Who cares by Sentry21 · · Score: 4, Insightful

      I'll second this. Deploying a RoR app for a (reasonably large) website, I've seen all manner of issues. We're proxying to Mongrel on the backend, but it's a huge hassle.

      It's been a rollercoaster ride of excitement, as each new feature, daemon, or cronjob has required not only programming by the developers, but hours of time spent by me writing shell scripts to wrap Ruby scripts because the framework either doesn't allow for something, or does it in a silly way. Rails devs/users will argue that 'You can do [x], just do [y], [z], and [q], and voila,' but I'd prefer things to be straightforward, rather than what seems to be ad-hoc design-philosophy-of-the-week.

      Maybe I'm just frustrated, but it seems like the Rails devs develop in a vacuum, ignoring the practical concerns involved in actually *deploying* code. I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret. It almost reminds me of qmail, famous for doing things its own way, even if that completely goes against everything else everyone else does.

      Not to mention that it's easy to do something idiotic in Rails. For example:

      Orders.all.each { |order| ... code goes here ... }

      Simple task - iterate over each order and run code on it. In practice?

      End result is that code that works fine on your test machine (with a hundred orders) fails miserably on the live DB (with several hundred thousand), crashing the server by allocating all the memory available. We also found that Rails (the framework itself, not our code using it) was leaking huge amounts of memory, upwards of 14M (yes, megabytes) per request in some instances, and the GC seemed incapable of cleaning up.

      I've dealt with a lot of systems, and I hate PHP more than anyone, but Rails is just full of pitfalls, gotchas, and 'magic' (where it tries to be clever for corner cases at the expense of clarity or efficiency in all cases). It's ugly, bad, and wrong in many situations, and I look forward, honestly and truly, to the excellent Merb developers and what they can do when given their time in the spotlight.

      Go guys! We're counting on you!

    10. Re:Who cares by John_Booty · · Score: 1

      How is that any worse than traditional web development environments, where it's equally easy to a "select * from orders" ? It's so easy to forget a WHERE clause.

      If anything, I think the presence of "all" in "Orders.all.each { |order| ... code goes here ... }" is much easier to spot than a missing SQL clause.

      Not that that excuses any of Rails' other flaws that you pointed out.

      --

      OtakuBooty.com: Smart, funny, sexy nerds.
    11. Re:Who cares by mtarnovan · · Score: 1
      I understand you woes with deploying Rails application. I highly recommend you check out Passenger (mod_rails): http://www.modrails.com/ However I have no understanding for most of your complaints.

      I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret.

      So what's Ferret or you inability to manage system services got to do with Rails ?

      Not to mention that it's easy to do something idiotic in Rails. For example:

      Orders.all.each { |order| ... code goes here ... }

      With power comes responsibility - something you ought to know by now. You can do something just as stupid using _any_ other web framework + ORM; this is not a problem in Rails, it's a problem with the way you choose to solve the problem at hand.

      Go guys! We're counting on you!

      How about counting on yourself and getting some work done (on the Rails framework) without waiting for others to solve your problems ?

    12. Re:Who cares by Enry · · Score: 1

      What exactly are you trying to debug? As for deploying new versions, It's dead simple to bundle rails with the application, and then all you are doing is an application deploy.

      I'm trying to track down problems that the coders are having. We're not sure if the problem is in the RoR end or the Apache/mongrel end.

      Why were you running as a CGI in the first place? Did you do any research before hand? I don't understand how you would do any reading about ruby without stumbling across it's relative slowness, and then you tried to add another layer to the process? And then you add NFS for good measure?

      Rails is optimised for developer productivity, not for raw execution speed. As a sysadmin, you need to run it with either a pack of mongrels or phusion passenger. If you're debugging for more than 15 minutes per deployment, you need to get your developers to write some more unit tests.

      Why as CGI? Like I said above, we're trying to debug problems. The response that Rails developers have to problems is pretty poor. And to add to that. mongrel isn't being developed anymore (from what I'm told), and mod_rails is the new hotness. Running separate servers for each RoR app just won't cut it - there's too much that requires interaction between the developer and sysadmin to get it working quickly.

    13. Re:Who cares by Ant+P. · · Score: 1

      For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.

      Anyone running a performance-sensitive webapp over NFS as a CGI application doesn't know what they're doing. Regardless of the programming language.

    14. Re:Who cares by Enry · · Score: 1

      We were running as CGI to debug problems between Apache and mongrel. Turned out it was the rails app causing our grief, but that led into my debugging issues. I had almost nothing in log files to tell me what was going on.

      But strace was a big help when I tried to run as CGI. The problem was not log/ and tmp/, but more like rails (or ruby) doing over 20k file lookups all over the system looking for various files. On a local disk, that can be pretty quick. Over NFS, that large number of searches really bogs down. There's no reason for all those searches, especially when you should be able to set the locations as options.

      I'm more frustrated over the notion that the developers keep changing their requirements. Their development time may be fast, but building the systems to handle their code isn't, especially when we have to toss out the previous 2-3 months worth of work because some new shiny shiny came out, the developers are asking for it, and it's brand new code that barely works. Then you go through the same exercise 2-3 months later.

      Sure I know mongrel, but that knowledge is useless now. I don't mean to sound bitter or angry, but more seasoned (if undesirable by coders) languages like PHP/Pyhton/Perl are easily understood and work well for what they do. For us to integrate those into our hosting environment is a no-brainer. Even application servers like tomcat and jboss are easier to set up now as well.

      Then again, that's why I'm a sysadmin and not a coder.

    15. Re:Who cares by Enry · · Score: 1

      Go read my other comments where I explain what I was doing, why, and why the performance was so terrible.

      Perl CGI doesn't have this problem, nor does python.

    16. Re:Who cares by hubert.lepicki · · Score: 1

      I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret.

      Well, Ferret is not a "common service" anymore. Most of people already switched to Sphinx. I had horrible experience with Ferret myself, and I wouldn't say it's reliable. It's not even developed anymore. The thing that you mention Ferret in this context just confirms that you don't have much experience with Rails. It's not a standard Rails feature, it's a 3rd party addon. You don't judge framework by quality of addons, just like you don't judge operating system by quality of programs written to it.

    17. Re:Who cares by InterBigs · · Score: 1

      Well the deployment of Rails is getting easier every day. It now integrates nicely in your LAMP stack thanks to Fusion Passenger.
      Or if you want more scalability, spead and general coolness you can use JRuby (with Warbler) to deploy a Rails application on a J2EE application server of your choice (e.g. Glassfish, Tomcat, Websphere). This also allows you to leverage technologies such as JMS or JDBC connection pooling from your Rails application.
      Deploying Rails application has been a mess since it's inception, but with Passenger and JRuby we have two very mature options.

    18. Re:Who cares by Sentry21 · · Score: 1

      I can manage intelligently-designed services, but services that are designed with no regard for sane UNIX behaviour become tricky. I can work around them, but people shouldn't have to do extra work every time they deploy something if this could be solved by sane design considerations in the first place.

      Likewise, I'm not going to 'fix' rails because I'm not a Ruby developer, I'm a sysadmin. My job is to get Rails running on test and production servers, and in that regard Rails is a huge hassle, far more than it ever should be.

      I'm not saying it can't be done or that I can't do it, I'm saying that there's no reason, other than laziness or cluelessness, that Rails should require such hoops to be jumped through.

    19. Re:Who cares by Sentry21 · · Score: 1

      Oh, I failed to mention that we had looked at mod_rails (Passenger) and it looks completely awesome in the context of Rails websites that are capable of running on a single machine. Unfortunately, our site is such that more machines are required, at which point it's actually easier to run multiple machines with multiple Mongrel processes than to run multiple machines with multiple Apache processes, ironically enough.

      It may actually be more sensible to rearrange our architecture to attempt to take advantage of mod_rails, as preliminary benchmarks seemed to indicate an anecdotal increase in pages served per second by about 5-12% depending on the page. Unfortunately, without more benchmarks, more hardware, and more time before Christmas crunch season, we didn't have sufficient time to test it.

      Regardless, mod_rails is yonks ahead of anything else I've seen and if you know how to manage Apache, or at least know how to copy-and-paste, everyone should be using it in every possible situation.

    20. Re:Who cares by mtarnovan · · Score: 1

      You should also see better memory management if you're using Enterprise Ruby (from the same developers as Passenger: http://www.rubyenterpriseedition.com/). Also if your application fits the 'share-nothing' paradigm you could try to put a load balancer in front of multiple machines running mod_rails. Anyway, Rails deployment has come a long way from FCGI to Mongrel then Passenger. I think things look good for the future.

  8. oh ffs... by Anonymous Coward · · Score: 0

    I just spent 3 days - 3 whole days trying to do the demos in the current edition of agile web development with Rails - apparently the bloody bible for Rails.

    Only to find out that you cant get past page 60 becasue the documentation has not caught up with the current version of rails.

    So you have a dilemma.

    1 Try to work round the changes (hard with a framework you are trying to learn)

    2 scour the web for more current tutorials, and try to map these back to AWDR

    3 downgrade your rails to 1,2,X.... which seems counterproductive as v3 is comming now.

    4 give up.

    I opted for #2 - and that was fun. Even Rails own web-site publishes howtos which are completely out of date.

      Try: rails -d mysql myapp
    Just about the FIRST command you type(as per the notes, and just about every blog and tutorial) what this will do is create 2 App folders (one called mysql, and one called myapp)... and setup foy sqllite3 instead! In the latest rails its: rails -D mysql myapp....

    Stupid mistakes in the documentation like this suckie real bad.

    It is very, very interesting when it does (eventually) work though

    1. Re:oh ffs... by Anonymous Coward · · Score: 1, Informative

      Goto pragprog.com and order the Beta of the 3rd edition.

    2. Re:oh ffs... by Anonymous Coward · · Score: 0

      The thought is simple. WTF should we have to purchase a book, for a framework that does point releases that can completely break a host of plugins EVERY FREAKING 2 MONTHS. Hell, if the authors of the books (about the only source of GOOD docs for Rails) can't even keep up with whats going on in the Rails world, how are WE going to?

  9. Really great news by astrashe · · Score: 2, Interesting

    This will give the Merb people a lot more momentum, and their project will have a really big community, a thriving job market, and lots of books written about it.

    And it will give Rails the value of all of the good stuff that Merb brings to the table -- Rails will be more modular and less monolithic, easier to learn, and easier to move forward because people will be able to split off smaller pieces and improve them.

  10. Re:Reinvent the wheel by SanityInAnarchy · · Score: 2, Insightful

    Python started in 1991, Ruby in 1995. Are you telling me you're still mad about that?

    Or are you talking about something of substance -- like, say, frameworks? Because here, Merb has done some things that make Django developers jealous. (And vice versa, of course.) And Python still hasn't figured out how to write a decent package manager -- "easy-install" is anything but.

    And your "performance" comment, as it turns out, really isn't justified. I don't know about Python, but it turns out that Merb is faster than PHP, and absurdly faster than CakePHP.

    --
    Don't thank God, thank a doctor!
  11. Doh. by Anonymous Coward · · Score: 2, Interesting

    Hmmm. Merb was awesome because it was a lighter, faster, less bloated Rails. I'm not convinced that merging the two will result in anything other than dragging Merb down to Rails' level.

  12. I'm more than a little worried.... by dstar · · Score: 1

    I didn't switch to Merb primarily for technical reasons; I switched to Merb because I got tired of being insulted whenever I asked for help on #rubyonrails (my very first experience there was being told to go back to Perl if I didn't understand Ruby (note, not if I didn't _like_ Ruby, if I didn't understand it), and my last was being told to 'drop the gimme gimme gimme attitude' when complaining about something that wasn't documented -- _AND OFFERING TO PROVIDE A DOCUMENTATION PATCH IF SOMEONE WOULD HELP ME UNDERSTAND IT_).

    By contrast, both the Merb IRC channels and mailing list have been nothing but helpful. I'm afraid that will change when the two communities merge.

  13. N+1 problem by Anonymous Coward · · Score: 0

    One really common problem is when the block above operates on an association. Each iteration over the orders is a separate database call unless you've explicitly eager loaded the association.

    1. Re:N+1 problem by mtarnovan · · Score: 1

      You're just wrong. Order.all is simply an alias for Order.find(:all), and as such and array of Orders - *not an associations*. (see http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001966). There's no N+1 problem here.

      p.s. I just noticed the grandfather quotes code in the form Orders.find. This is clearly a sign the author isn't even used with basic Rails naming conventions.

    2. Re:N+1 problem by Anonymous Coward · · Score: 0

      Order.find(:all) { |o| puts o.customer.email }

      Separate db call for every customer email unless customer has been eagerly loaded.

    3. Re:N+1 problem by mtarnovan · · Score: 1

      Wrong. That would only happen if email would be an association (i.e. another table), not an attribute of customer (a field in the orders table).

  14. DHH's response to people by Anonymous Coward · · Score: 0

    Slide 1
    =======

    There are some who oppose the merger

    Slide 2
    =======

    Fuck You

  15. The curse of hype... by Per+Wigren · · Score: 1

    Ruby on Rails has a great community, but the only ones (with few exceptions) hanging out on #rubyonrails are newbies and/or fanbois.

    It was long ago that the pros left the places where newbies also could hang out and ask questions. There are a couple of half-anonymous invite-only communities where hundreds of already semiprofessional Railsers (including core developers of Rails, major sites and plugins) hang out and help each others and life there is great and very friendly and helpful.

    Unfortunately that also means that there aren't very many seasoned devs left to help the newbies, only people who are newbies themselves, and annoying loudmouths who think that platform choice is a war or something.

    This is the curse of being hyped.

    --
    My other account has a 3-digit UID.
  16. tongue twister by Anonymous Coward · · Score: 0

    "Rails and Merb Ruby Web Frameworks Merge"
    Try saying that 10 times fast.