Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

Rails 3.0 Released 110

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

Rails 3.0 Released

Comments Filter:
  • Too many changes? (Score:3, Interesting)

    by p0 ( 740290 ) on Monday August 30, 2010 @08:06AM (#33414050)
    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!
    • Re:Too many changes? (Score:4, Informative)

      by Anonymous Coward on Monday August 30, 2010 @08:12AM (#33414096)

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

      • Agreed. Rapid changes are also more expected since it is a (comparatively) new framework. Development of fancy features is likely to slow down as the code base matures.
    • Re:Too many changes? (Score:4, Informative)

      by ojustgiveitup ( 869923 ) on Monday August 30, 2010 @09:03AM (#33414520)
      They've been working on Rails 3 for more than a year now... not really so rapid. For instance two versions of Ubuntu have come out since then.
  • by Anonymous Coward on Monday August 30, 2010 @08:11AM (#33414090)

    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.

    But I do wish the community would grow up.

    • But I do wish the community would grow up.

      But from my experience, I think the community is already big and grown up enough to base your serious application on Rails.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        But I do wish the community would grow up.

        But from my experience, I think the community is already big and grown up enough to base your serious application on Rails.

        No, not grown up as in scale (*ahem* twitter, twitter) but grown up as in *not* arrogant ranting pricks.

        • If you are basing your development decisions on the perceived attitudes of other people who use it, what does that make you? (Hint: "rational" isn't it.)

          And if people who use Rails are "ranting pricks", what does that make the Pythonistas? Not to mention that's supposedly a more "mature" environment.
          • Re: (Score:3, Funny)

            by Anonymous Coward

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

            Seriously?

            • That's a pretty standard political move -- though I would like to think our development communities are more mature than American politics, I'm not sure it has to be.

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

    • by ojustgiveitup ( 869923 ) on Monday August 30, 2010 @08:55AM (#33414458)
      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.
      • Re: (Score:1, Informative)

        by Anonymous Coward

        Python a favourite of slashdot? Woa, where did the whitespace-as-indentation haters go? Where are the pry-my-curly-braces-from-my-dead-fingers people? Is this some sort of alternative universe I'm in?

        • The same place the perl-is-line-noise people went -- nowhere.

          Bring up pretty much any language on Slashdot, and you're going to get hate.

      • by Bogtha ( 906264 ) on Monday August 30, 2010 @10:05AM (#33415232)

        This is something I wrote a while back: These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention. [slashdot.org]

        I haven't kept up with Rails development, precisely due to attitudes like these, but hopefully the injection of Merb will bring with it an injection of - yes I'll say that word - professionalism.

        • Sure. The only problem being that, as replies to that post show, you were wrong in your assumptions.
          • by Bogtha ( 906264 )

            Which assumptions and replies are you referring to?

            • Re: (Score:3, Informative)

              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

            • by Jane Q. Public ( 1010737 ) on Monday August 30, 2010 @03:11PM (#33419000)
              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?
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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

        • Re: (Score:3, Insightful)

          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

          • by Forbman ( 794277 )

            And, plenty of companies won't hire you if you know how to use SharpDevelop or Eclipse for C# programming, because everyone else there uses Visual Studio.

            What 37Signals chooses for its internal development environment is its choice.

          • 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

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

          Erm, so what? I use Rails, and I have no ambitions to ever work for 37signals.

          Yeah, I really want to spend extra money for a proprietary white box so I can be cool like you.

          I showed up to Railsconf with a Dell running Ubuntu. I wasn't the only one, and I noticed another one of the conference-goers had set up a wireless access point called "I Hate Mac Fags."

          Even if it weren't for the 'tude

          Problem is, the Rails community is getting a little too diverse for this "tude" you describe to apply to any significant chunk of it.

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

          You do. Or, specifically, Rails does -- it wouldn't be the framework it is without a language like Ruby to support

          • Show me a Rails-like framework in PHP, and I'll bet money it'll perform worse.

            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

        • by mini me ( 132455 )

          That immediately alienated what, 90, 85 percent?

          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.

      • Community issues (Score:3, Insightful)

        by gwolf ( 26339 )

        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

        • Agile and Rails do not necessarily have anything to do with each other. Lots of Rails coders do not work in Agile environments, and vice versa.
          • Agile and Rails do not necessarily have anything to do with each other.

            Other than the fact that the main purpose of Rails around which many design decisions are made is enabling Agile web development, sure, they don't have anything to do with each other.

            Sure, you can use any toolkit with any development approach, but that doesn't mean that the toolkit is approach agnostic.

            • "... the main purpose of Rails around which many design decisions are made is enabling Agile web development..."

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

              • 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

      • by XorNand ( 517466 )
        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."
      • by bonch ( 38532 )

        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

    • But I do wish the community would grow up.

      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

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        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.

          The others to compare would be things like Ramaze.

          • 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?

      • by nvrrobx ( 71970 )

        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

    • Re: (Score:2, Interesting)

      by VGPowerlord ( 621254 )

      Rail is a nice framework.

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

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

      • Re: (Score:3, Interesting)

        Rail is a nice framework.

        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.

          Earli

      • Yes, it's true that historically, Ruby has been slow. Ruby 1.9.x is a LOT faster than Ruby 1.8.x though, and Rails 3.0 is fully compatible with the latest Ruby 1.9.2.

        There are also other Ruby implementations under way, most notably Rubinius [rubini.us] which is often even faster already and has potential to become REALLY fast once they start optimizing it.
      • The major problem with Rails is that it's tied to Ruby. Historically, Ruby's interpreters have not exactly been speed demons.

        Non-rhetorical question: when you write web applications, do you ever do anything performance-intensive in the framework/application layer?

        I don't know about you, but in my experience with small/medium sites, the execution time of the ASP.NET/Ruby/whatever code is absolutely dwarfed by the execution time of the database calls.

        Usually, all the framework/application layer is really doi

    • by wmac ( 1107843 )
      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.
        • "Not flexible enough" is not an objection I have ever heard from ANYBODY who knew much about Rails.

          I'll say it, then: Rails 2 wasn't as flexible as I wanted it to be. More than once, I had to monkey-patch things to make it do what I wanted. It was flexible because of Ruby and in spite of Rails.

          Rails 3 changes a lot of that, but it's not a completely baseless accusation -- though the "I would do in PHP in 10 minutes" makes me a little scared of what kind of PHP code it would be.

          • But neither of you has supplied an example. That's what I was asking for: an example, not just another opinion.
            • 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

          • by Forbman ( 794277 )

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

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

              While that's often the case, I've got a patch in rails-core, I've got over a year of Rails experience, and I've written a few Sinatra toys which run on Google App Engine.

              So yeah, I think it's reasonable to say that I know Rails and Ruby.

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

      • Re: (Score:2, Informative)

        Ruby 3.0 is a long ways off. You probably want Rails 3.0 and Ruby 1.9.
      • 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.
  • Great release (Score:5, Informative)

    by jgeiger ( 1356045 ) on Monday August 30, 2010 @08:13AM (#33414110)
    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...
    • by Anonymous Coward on Monday August 30, 2010 @08:57AM (#33414474)

      When RC2 was released they said that they had to work on the ORM layer to speed things up before final release, less than a week later and the final release is here without any significant speed-up...

  • 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.
  • It might just be my configuration (installed Ruby 1.9.1 via MacPorts). Here's my Rails 3 install attempt:


    bash-3.2# /opt/local/bin/gem1.9 install rails --version 3.0.0
    Successfully installed rails-3.0.0
    1 gem installed
    Installing ri documentation for rails-3.0.0...
    ERROR: While executing gem ... (Errno::ENOENT)
    No such file or directory - lib

    The gem installed, but without docs. WTF.

    I spent the last month fighting with Ruby 1.9.1 + RoR 2.3.8 on OS 10.6, trying to get it to connect t

    • I think RVM [beginrescueend.com] is exactly what you're looking for.
    • 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.

      Apple's 1.8.7 sits where it's always sat and, wheneve

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...