Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rails and Merb Ruby Web Frameworks Merge

kdawson posted more than 5 years ago | from the flattened-red-gem dept.

Programming 80

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

cancel ×

80 comments

Sorry! There are no comments related to the filter you selected.

WTF (0)

Anonymous Coward | more than 5 years ago | (#26216725)

I'm sorry, what and who???

Re:WTF (0)

LiteralKa (1273510) | more than 5 years ago | (#26216769)

Read the story before posting.

Re:WTF (0)

Anonymous Coward | more than 5 years ago | (#26217749)

Read the story before posting.

"You must be new here."

Re:WTF (4, Informative)

larry bagina (561269) | more than 5 years ago | (#26217029)

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.

Re:WTF (3, Informative)

SanityInAnarchy (655584) | more than 5 years ago | (#26218451)

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

Re:WTF (1)

Sentry21 (8183) | more than 5 years ago | (#26219507)

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.

Re:WTF (2, Interesting)

ComaVN (325750) | more than 5 years ago | (#26220383)

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.

Re:WTF (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26225115)

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?

Re:WTF (1)

Sentry21 (8183) | more than 5 years ago | (#26226221)

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.

Re:WTF (1)

GreyWolf3000 (468618) | more than 5 years ago | (#26227155)

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.

Re:WTF (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26228579)

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.

Re:WTF (1)

GreyWolf3000 (468618) | more than 5 years ago | (#26230087)

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.

Re:WTF (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26231529)

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.

Re:WTF (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26228561)

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 understand, and it probably does violate a strict class hierarchy -- this is not, after all, what Symbols were designed to do. It's also less than ten lines of code to augment Symbol in this way -- could probably be made a one-liner, if I wanted -- and it's damned convenient, and I can't think why I wouldn't do it, other than sheer stubborn purism.

Re:WTF (0)

Anonymous Coward | more than 5 years ago | (#26231277)

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.

Win - win scenario. (1)

LiteralKa (1273510) | more than 5 years ago | (#26216739)

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

Re:Win - win scenario. (4, Funny)

eln (21727) | more than 5 years ago | (#26216863)

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.

Re:Win - win scenario. (1)

just_another_sean (919159) | more than 5 years ago | (#26217137)

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.

Re:Win - win scenario. (1)

dkf (304284) | more than 5 years ago | (#26221547)

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.

Re:Win - win scenario. (1)

jadavis (473492) | more than 5 years ago | (#26220507)

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.

Rails community grows up (2, Insightful)

spinkham (56603) | more than 5 years ago | (#26216805)

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.

Reinvent the wheel (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26216955)

Reinventing the python wheel will still need some spokes until they are ready (performance and maturity are the big ones), Before that, it's business as usual in the ghettoooo...

Re:Reinvent the wheel (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#26218517)

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.

Rails 3 - Rails and Merb Merge (0)

Anonymous Coward | more than 5 years ago | (#26217111)

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

Tags (0)

Anonymous Coward | more than 5 years ago | (#26217251)

I love them.

Good lord, what is with the taggers? (3, Interesting)

ShadowRangerRIT (1301549) | more than 5 years ago | (#26217275)

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.

Re:Good lord, what is with the taggers? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#26217459)

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.

Re:Good lord, what is with the taggers? (0)

Anonymous Coward | more than 5 years ago | (#26217867)

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.

Re:Good lord, what is with the taggers? (2, Informative)

SanityInAnarchy (655584) | more than 5 years ago | (#26218561)

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 [slideshare.net] , 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.

Re:Good lord, what is with the taggers? (2, Informative)

knewter (62953) | more than 5 years ago | (#26218655)

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

Re:Good lord, what is with the taggers? (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26219207)

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.

Re:Good lord, what is with the taggers? (1)

tcopeland (32225) | more than 5 years ago | (#26218673)

> 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 [blogs.com] to the deployment tasks.

Re:Good lord, what is with the taggers? (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26231551)

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.

Re:Good lord, what is with the taggers? (1)

tcopeland (32225) | more than 5 years ago | (#26231857)

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

Re:Good lord, what is with the taggers? (1)

tcopeland (32225) | more than 5 years ago | (#26217635)

> 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 [militarypr...glists.com] site, Rails is awesome. Plus Sphinx for searching, of course.

Re:Good lord, what is with the taggers? (2, Interesting)

mypalmike (454265) | more than 5 years ago | (#26217793)

I just finished my first rails project, a caption contest [mypalmike.com] . 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.

Re:Good lord, what is with the taggers? (3, Informative)

tcopeland (32225) | more than 5 years ago | (#26217977)

> 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 [mypalmike.com] ) up and running. It opens a lot of doors; good times indeed!

Re:Good lord, what is with the taggers? (2, Interesting)

poulbailey (231304) | more than 5 years ago | (#26218043)

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

Re:Good lord, what is with the taggers? (0)

Anonymous Coward | more than 5 years ago | (#26219897)

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?

Re:Good lord, what is with the taggers? (1)

larry bagina (561269) | more than 5 years ago | (#26222659)

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

Re:Good lord, what is with the taggers? (1)

Ant P. (974313) | more than 5 years ago | (#26222667)

Stick this in your userContent.css:

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

Re:Good lord, what is with the taggers? (1)

poulbailey (231304) | more than 5 years ago | (#26223757)

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

Re:Good lord, what is with the taggers? (0)

Anonymous Coward | more than 5 years ago | (#26219113)

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?

Re:Good lord, what is with the taggers? (1)

LiteralKa (1273510) | more than 5 years ago | (#26224613)

Now we have "willyonwwheels".

Who cares (0, Redundant)

moniker127 (1290002) | more than 5 years ago | (#26217837)

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

Re:Who cares (3, Insightful)

Allador (537449) | more than 5 years ago | (#26218039)

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.

Re:Who cares (2, Interesting)

Enry (630) | more than 5 years ago | (#26218253)

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

Re:Who cares (2, Informative)

Allador (537449) | more than 5 years ago | (#26218345)

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

Re:Who cares (1)

Enry (630) | more than 5 years ago | (#26222797)

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.

Re:Who cares (1)

hamoe (260438) | more than 5 years ago | (#26218407)

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.

Re:Who cares (4, Informative)

KagatoLNX (141673) | more than 5 years ago | (#26218671)

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 [engineyard.com] 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.

Re:Who cares (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26219063)

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.

Re:Who cares (0)

Anonymous Coward | more than 5 years ago | (#26219219)

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.

Re:Who cares (1)

Enry (630) | more than 5 years ago | (#26222699)

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.

Re:Who cares (4, Insightful)

Sentry21 (8183) | more than 5 years ago | (#26219337)

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!

Re:Who cares (1)

John_Booty (149925) | more than 5 years ago | (#26219799)

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.

N+1 problem (0)

Anonymous Coward | more than 5 years ago | (#26220797)

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.

Re:N+1 problem (1)

mtarnovan (1337149) | more than 5 years ago | (#26222903)

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 [rubyonrails.org] ). 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.

Re:N+1 problem (0)

Anonymous Coward | more than 5 years ago | (#26226943)

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

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

Re:N+1 problem (1)

mtarnovan (1337149) | more than 5 years ago | (#26229239)

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

Re:Who cares (1)

mtarnovan (1337149) | more than 5 years ago | (#26222567)

I understand you woes with deploying Rails application. I highly recommend you check out Passenger (mod_rails): http://www.modrails.com/ [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 ?

Re:Who cares (1)

Sentry21 (8183) | more than 5 years ago | (#26226181)

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.

Re:Who cares (1)

Sentry21 (8183) | more than 5 years ago | (#26227359)

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.

Re:Who cares (1)

mtarnovan (1337149) | more than 5 years ago | (#26229245)

You should also see better memory management if you're using Enterprise Ruby (from the same developers as Passenger: http://www.rubyenterpriseedition.com/ [rubyenterp...dition.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.

Re:Who cares (1)

hubert.lepicki (1119397) | more than 5 years ago | (#26223693)

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.

Re:Who cares (1)

InterBigs (780612) | more than 5 years ago | (#26223709)

Well the deployment of Rails is getting easier every day. It now integrates nicely in your LAMP stack thanks to Fusion Passenger [modrails.com] .
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.

Re:Who cares (1)

Ant P. (974313) | more than 5 years ago | (#26222703)

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.

Re:Who cares (1)

Enry (630) | more than 5 years ago | (#26223053)

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.

Re:Who cares (2, Funny)

An Onerous Coward (222037) | more than 5 years ago | (#26218085)

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.

oh ffs... (0)

Anonymous Coward | more than 5 years ago | (#26218327)

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

Re:oh ffs... (1, Informative)

Anonymous Coward | more than 5 years ago | (#26218701)

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

Re:oh ffs... (0)

Anonymous Coward | more than 5 years ago | (#26223331)

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?

Really great news (2, Interesting)

astrashe (7452) | more than 5 years ago | (#26218365)

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.

Doh. (2, Interesting)

Anonymous Coward | more than 5 years ago | (#26218931)

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.

I'm more than a little worried.... (1)

dstar (34869) | more than 5 years ago | (#26219963)

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.

The curse of hype... (1)

Per Wigren (5315) | more than 5 years ago | (#26225935)

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.

DHH's response to people (0)

Anonymous Coward | more than 5 years ago | (#26224077)

Slide 1
=======

There are some who oppose the merger

Slide 2
=======

Fuck You

Re: (1)

clint999 (1277046) | more than 5 years ago | (#26225359)

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.

Re: (1)

clint999 (1277046) | more than 5 years ago | (#26231373)

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

tongue twister (0)

Anonymous Coward | more than 5 years ago | (#26290093)

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

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?