Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "After two years of gestation, 4 betas, 2 release candidates and thousands of commits by 1600+ contributors, the result of the succesful merge of the Merb and Rails frameworks (and teams) is now out and ready to transport your web applications on all new shiny tracks."

Very true. I started the new app I'm developing at work on Rails 3/ruby 1.9.2 b/c I needed newer features... but there are no plans to stop developing Rails 2.3.x or Ruby 1.8.x for the immediate future.

I find it a bit hard to keep up with rapid changes to Rails. But that's my problem anyway. I think the changes and additions in Rails 3 are wonderful and the team did a good job on this. Congratulations and thank you!

2.3.x is still supported, actually they're working on 2.3.9 as we speak.It's true that the Rails eco system moves forward at a good pace, but that's a good sign to me. it means ideas are brewing and accepted.A sign of good health:)

I've avoided Rails for years due to the community's reputation. So against my better judgement, I decided to build a project on the Rails 3 Beta, thinking that some of frameworks new features made it hard to ignore.

And you know what? It's a really nice framework. Nice enough that in the future, I'll probably be using Ruby on Rails instead of PHP or Python when the project allows.

"Wait, wait wait... somebody says that the Rails community is immature, and you respond with "I know you are, but what am I?""

No, I did not call you immature at all. Maybe you should work on your reading comprehension a bit. What I wrote was that you were not being rational.

And I did not refer to myself at all. Why do you include me in the "Rails community"? Just because I have some familiarity with it? Hey, I can program using.NET, too... that doesn't make me a Microsofty... or even a regular user of Windows.

Could you give some examples from your own experience where the community has been problematic or not "grown up"? I've been using Rails for awhile now and have yet to run into anyone besides people trying to get good stuff done for their clients or companies, just like everyone else. What I *have* run into is a willful ignorance on Slashdot surrounding Rails, and more seriously, Ruby, which is a great language and really very similar to perennial Slashdot favorites Python and Perl.

One assumption is that the Rails community -- as you said, "straight from the top" -- embraced unsafe GETs and tried to block GWA in order to keep using unsafe GETs.

I don't know if this was ever true, but it hasn't been true for at least two years, probably longer. Rails has embraced REST to an obsessive degree, which means not only are GETs never used for unsafe operations, but if your UA supports PUT and DELETE, Rails will accept those. (If not, PUT and DELETE are emulated over POST -- still not GET.) I m

First, I apologize for getting you mixed up with the person who wrote that Rails had implemented PUT and POST backward, which simply isn't the case. That's what I was mainly referring to when I wrote that you were wrong. But do have another issue with the things you wrote.

You equated one or maybe a few specific people with the "Rails community". David Heinemeier Hansson might be the original author of Rails, but he is not -- even remotely -- the "Rails community", nor is 37 Signals. And you made that error not once, but twice.

First, you describe how GET was often used for unsafe operations (a good description of that is available HERE [moertel.com]). However, using the link_to method as described is hardly "standard practice". In fact it is anything but, regardless of whether DHH and 37 Signals have used it that way. In general, link_to was designed simply for navigating among web pages. The fact that it allows GET to be used for unsafe operations is unfortunate, but the fact is that I know few people who would ever actually use it that way. As someone else mentioned in one of the replies to that post, any framework can be abused. That is generally the fault of the developer, not the framework.

Further, the "rails developers" you accuse of being immature for complaining about it consisted of -- who else? -- David Heinemeier Hansson. Not the "rails community". If you were not aware of this already, then let me inform you: that was 5 years ago and since then the "rails community" itself, on more than one occasion, has derided DHH for his frequent immature behavior.

Your last point, about the word "professional", was again a reference to DHH personally and not "the rails community". Further yet, what he was referring to was the way the word "professional", like some other phrases, has been abused... he was not insulting professionals. In fact he made no references at all to "professionals" or "professionalism".

In summary, you are guilty of accusing a whole multitude -- thousands of people -- of being immature, almost entirely because of the actions of one person. Remind me again... who is being immature here?

I'm not the parent; but statements to the effect by 37 Signals that they "don't
hire people unless they use a Mac" probably have a lot to do with this.

That immediately alienated what, 90, 85 percent? I forget the market share
stats; but it alienated a lot of people. Yeah, I really want to spend extra
money for a proprietary white box so I can be cool like you.

Even if it weren't for the 'tude; I still wouldn't be interested. You pay
a high performance price for the dynamic nature of Ruby whether you need

Just curious, if Ruby is fading what do you see taking its place? My opinion is that it is just coming into its own. YARV and other proper vms are maturing at a rapid rate and Rails 3 seems to be a pretty nice framework. The testability with Cucumber and/or the other types of frameworks is beyond most anything I've seen lately. This is all coming from one who has been exploring Ruby and Rails for the last couple months.

I'm not the parent; but statements to the effect by 37 Signals that they "don't hire people unless they use a Mac" probably have a lot to do with this.

That immediately alienated what, 90, 85 percent? I forget the market share stats; but it alienated a lot of people.

37signals is a business. They do Mac-based development. Not hiring people that don't use Macs may not be the best business decision (simple litmus tests usually aren't), but its not an insane one, to be sure, and it has just about nothing to do w

That's a legitimate concern, though there are good reasons that performance of the runtime isn't the overwhelming concern when choosing a platform for a project, but the speed with which something can be developed, tested, and deployed is more critical, and the Ruby ecosystem and Rails have features that lots of people find attractive in that direction.

This is absolutely true. Developer time is in shorter supply than CPU cycles. Additionally, in most web applications, it's the data storage layer that's d

Umm, CakePHP. A quick google doesn't show me any comparative benchmarks less than 2 years old though.

I'll take another look at Rails now. Haven't tried in 3+ years, and at the time I had trouble with inconsistent library calling conventions (same gripe I have with Java Swing and AWT before it) and significant challenges making it play nice with Apache in a manner comparable to mod_php. (has mod_ruby come of age, yet?;3)

You pay a high performance price for the dynamic nature of Ruby whether you need it or not.

I don't think that's accurate at all. Typically, your choice of web framework/language is never even close to being your performance bottleneck anyway - it's the data storage layer that's doing all of the heavy lifting. MySql isn't any faster or slower whether you're calling it from Ruby, C#, COBOL, or hand-tuned machine language.

When I say "typically," I realize that's a nebulous term and that there's no "average" web application. What I'm thinking of as typical is a small/medium server that's serving u

I believe that was their intention. Many companies use university degrees to filter out 90% of their potential application base, but 37Signals have stated on many occasions that they do not hold a degree to any kind of standard (it is not good to have one, and it is not bad to have one, it just doesn't matter). Therefore, they need to find some other way to scare off people who are not really serious about the job, so to speak.

I am a long-time Rails user - Started playing with it before 1.0, and have applications in production since the 1.1 days.

Rails is _great_, and it helps lots to productivity. However, its community is too young - the whole "latest version or deep-fried" attitude really hurts.

A community of assorted modules' authors has sprung around Rails and its Agile practices, which is good. However, most of those modules (gems) have (contrary to Rails, which at last has grown and is a mature project by now) very unsound

Can you give me a specific example of a design decision that enables Agile development more than it enables other development paradigms?

I can certainly name design decisions that appear to be directed at enabling Agile development (or, perhaps more specifically, iterative development around evolving specifications) -- migrations, scaffolding, and much of the "convention over configuration" approach which is are all obvious examples.

These things that reduce the workload to get something working when some asp

Python and Ruby are in no way similar, other than the fact that they're both open-source OOP languages. They have completely opposing design philosophies: Python's "one right way to do it" vs. Ruby's "give the developer enough rope to hang himself."

One of my biggest issues with Ruby on Rails at the beginning was how difficult it was to find real documentation. Everything was a tutorial or "screencast" about scaffolding. They were so obsessed with doing CRUD in 5 minutes that it was hard to find out how to go outside the bounds and write anything real. There was a ton of hype over the framework until everyone found out how slow it was and how rigid things were if you didn't follow its conventions. But the community was just so into the very idea of Rub

You're preaching to the choir, but I seriously doubt that the Python or PHP community you're referring to will grow up enough stop the needless and harmful proliferation of ORM frameworks (Django, Turbogears, Zope, PHP Cake, Symfony, Codeigniter) that wastes developer time and store bookshelves and instead learn from Rails and Merb's excellent example of putting community ahead of ego's and redirecting the entire community's programming and documentation efforts int

Not sure if you're aware of this but Rails isn't the only widely used Ruby web framework. There's also Sinatra, which is quite popular, and then there is Camping and a handful of other lesser know options. The really nice thing about all of them though is that they are all built on Rack which means they can all play nice together. That is the real beauty of the Ruby community, even our different projects can play nice together because we have common points of integration.

But these serve different purposes. The kind of app you'd use Sinatra for is the kind of app Rails would be worse at, and vice versa. Sinatra is more in the same space as Camping, and I don't know if anyone still uses Camping.

But these serve different purposes. The kind of app you'd use Sinatra for is the kind of app Rails would be worse at, and vice versa. Sinatra is more in the same space as Camping, and I don't know if anyone still uses Camping.

Sure, but hasn't the Python community kinda imbraced Django as the One True fullstack framework?

Except the fact that Django, TurboGears, Zope, etc are not ORM frameworks. They're entire web frameworks, that happen to have an ORM inside them.

The work on multiple frameworks helps to innovate and drive the others - one monolithic technology stack as the only option is double-plus-ungood. Sure, it's good for those who can't do research and choose the right tool for the job.

I was personally turned off by the attitudes I saw on the mailing lists for Rails. Granted, this was a few years ago, and I hope th

The major problem with Rails is that it's tied to Ruby. Historically, Ruby's interpreters have not exactly been speed demons.

That hasn't been the only big problem with Rails. Rails. Indeed, one of the problems with (pre-3.0) Rails is that was particularly inefficient in many key areas of how it used Ruby; one of the big motivations for the myriad other Ruby web frameworks that came out after Rails was using Ruby more efficiently than Rails (Rails 3.0 incorporates many of those lesso

No, seriously, when a JVM-based Ruby interpreter can outperform the C Ruby interpreter, the C version has speed problems.

Or the JVM runtime is better?

Hint: It's not an interpreter. It's a JIT-compiler which translates Ruby to Java bytecode. It's no surprise that this performs better than the C version, which is a bytecode interpreter -- the Java bytecode will be JIT-compiled again by Java into native code.

I don't disagree that there's room for improvement, but this whole "Ruby is slow" meme has got to stop. Slower than what, at doing what, and why do you care? Answer those questions, and we'll have something to talk about.

It's a JIT-compiler which translates Ruby to Java bytecode. It's no surprise that this performs better than the C version, which is a bytecode interpreter -- the Java bytecode will be JIT-compiled again by Java into native code.

The only current benchmarks I've seen (which can't be trusted any further than most benchmarks, but what else are you going to use) show the current, bytecode interpreting, C-based Ruby (Ruby 1.9.2p0) outperforming JRuby 1.5.1 everywhere where the two aren't approximately equal.

Not for me. As a programmer of 25 years, I developed a relatively big website (a shop) using Rails. But it was such a pain for me. I was spending a lot of time just to find workarounds and to see how can I do a simple thing in Rails (which I would do in PHP in 10 minutes).

It is not flexible enough for me. If I really want to force myself into a framework I'll stick with Zend. For smaller websites I just use my own small framework.

The fact that you don't know how to do something with a framework (especially on your first real project) does not mean that the feature isn't there. If you were to give me specific examples of what you were trying to do, I suspect that I could show you how it is already implemented in Rails.

Seriously. "Not flexible enough" is not an objection I have ever heard from ANYBODY who knew much about Rails.

One example was the ability to override controller_path on a controller instance, or with at least some context from the current controller, rather than only on the class. I was using this to have one controller masquerade as another, depending on the context.

I don't remember why I was doing it that way, and it's entirely possible there's a better way. That's one thing I like about Rails being rigid sometimes, and about working with a framework at all -- it sometimes forces me into doing things the right wa

or, another translation, "I can't wrap my brain around Rails/Ruby, and wish I could do things the way I would do them in [fill in the blank]".

If I didn't like SQL joins, and all my experience was with non-SQL databases, I'd probably feel at home using cursors. Doesn't make it right (but they do have a few uses, but they don't call those edge cases without reason...).

As a ruby newb and future ruby web developer, what did you find better in terms of programming versus the usual python or PHP? What would you also consider telling someone starting off with ruby3.0 to avoid any unnecessary lost time (setup,modules,etc...) and help a newcomer start programming quickly.

I would start HERE [railstutorial.org]. It starts from the beginning, and covers Rails 3.

You'll probably find, though, that most developers aren't that familiar with Rails 3.0 yet, even though most of the features have been known for some time and betas have been out, because what they're actually doing at work is still in 2.3.5 or earlier. So you might actually get a leg up on some of the established developers if you get to know 3.0 early.

A lot of the changes have made the code much more modular. You don't need to include everything if you don't need it. This also allows you to plug in other database adapters if you want.
One of the nice routing changes allows you to call Rack or Sinatra applications from within your Rails application.
I'm really looking forward to using this going forward.

I just upgraded an app we've been developing in 3.0.0.rc2 and it went smoothly. Looking forward to actually having the docs in place.
It's really been a lot of fun implementing the new changes and I'm excited for everything - hopefully the performance issues will get there, though, I've heard (though not personally observed) that the ActiveRecord in rails3 is something like 50% as fast as 2.3.5 was...

I've been a C/C++ programmer for a fair bit, and am starting to dabble in some web-dev for a startup idea a couple friends have.
Can someone tell me how the newer versions of Rails/Ruby compare against the newer versions of Grails/Groovy?
I don't want intend for this to be a troll/flame fest, I'm just under-informed on the tradeoffs.
Thanks in advance for any info.

I do my Rails dev in OS 10.6 and, frankly, stopped using MacPorts some time ago. I try to keep my machine as vanilla as possible but...

I install a few special libraries and other things by hand to/usr/local using --prefix= and make sure that everything in/usr/local takes precedence over/usr. I just upgraded to Ruby 1.9.2 today to go with Rails 3.0 (since it complained about my 1.9.1 install) and this setup has worked for for me since 10.6 was released.