4 ms·

Rails 2.3: Templates, Engines, Rack, Metal, much more

80 points by sant0sk1 18y ago

icey 18y ago
Can a Rails person tell us if this is a big deal or not?
- teej 18y ago
  This is a significant release. Many of the changes include modularizing Rails' internals. This reduces Rails lock-in and keeps the core more stable. I'm a fan of the performance tweaks in this one, but the important bits are the Rack integration and Ruby 1.9 compatability
  - icey 18y ago
    Thanks for that. Is this the release in which Merb becomes integrated with Rails?
    - teej 18y ago
      This is the first release to have major Merb influence. Rails 3.0 (possibly in May) will be the true merging of the projects.
      - icey 18y ago
        I'm very excited for the confluence to occur. I've been looking around for a good web development stack to switch to for personal projects. I'm a .net guy during the day, but it's not enjoyable for me to work on. I have basic proficiency with Python, but I don't care for Django and Pylons doesn't have very good documentation. I am currently learning Clojure, but I get the feeling that I'd have to reinvent a lot of wheels to bring up a basic web development platform (on top of Compojure, I'd imagine). I plan on using Clojure down the road for some business logic I'm working on. It would be very nice to be able to keep all my heavy logic work in Clojure while using Rails on JRuby at some point down the road, so I think it's worthwhile for me to learn both. It's good to hear that they are making so much progress on the Rails core in the meantime. It is starting to sound like a much more robust platform than it did a couple of years ago.
- patio11 18y ago
  The templates feature ("start every Rails project with a default stack") is a godsend to folks who routinely start new projects, such as freelancers with quick turn around times or internal IT folks who crank out mini-applications. I do a bunch of little utility projects for work (e.g. "Report X was previously generated based on five Excel files which had to be manually synched and executed, now the information is in one place on the intranet and updated every night via a cron job.") When you have a project which takes under a man-week a significant portion of the time is "Oh bloody heck I didn't install the auto-complete gem", "Oh bloody heck I forgot I'd need Google charts again.", "Oh bloody heck where did I put that syntax highlighter plugin", etc. This lets me spend less time fighting Rails configuration and more time fighting Java XML configuration, like God intended.
  - mdemare 18y ago
    Yes, this is a great innovation, and really according to the Rails Way. My favorite among the new features (and the other ones are good too.) Now combine this with GitHub (search for rails-templates) and you've got a evolutionary algorithm for discovering the best rails default stack.
  - gsiener 18y ago
    Just curious, what gems do you use for those sorts of projects? Any of them on github to learn from/check out?
    - patio11 18y ago
      I have about 15 that I keep coming back to. Most deal with boring business requirements: charting (I use two different variants of Ruby wrappers for the Google Charts API, plus OpenFlashChart 2), data entry, parsing, etc. I have no clue where they're hosted since I use Google as my own personal link memory service.
    - mtarnovan 18y ago
      Some of the gems worth checking out (you can find most of them on github): * authlogic for authentication * openrain-action_mailer_tls for using smtp with tls with ruby <1.8.7 * mislav-will_paginate for pagination * rspec/rspec-rails/shoulda for testing * settingslogic for application configuration * haml/sass for templating Also some useful plugins: git://github.com/Bertg/i18n_action_mailer.git (i18n support in mailers) git://github.com/iain/i18n_label.git (translate labels) git://github.com/thoughtbot/limerick_rake.git (lots of useful rake tasks)
mdemare 18y ago
Is it me or has the development of Rails accelerated drastically lately? It used to feel quite slow, and now it's very fast. Is it because they switched to git? Any core developers here?
- defunkt 18y ago
  I would say there are a few factors responsible for this. First, Jeremy Kemper got hired by 37signals which seems to give him a lot more time to work on Rails. Next, around the time of the move to git, the existing Rails core team was shuffled a bit. Older members were retired (http://rubyonrails.org/core/alumni http://rubyonrails.org/core/alumni) and more active contributors (Josh and Pratik) were added to the team. Then you've got the Merb merger which brought in Yehuda who works full time on Rails now, afaik. If you look at http://github.com/rails/rails/commits/master http://github.com/rails/rails/commits/master you'll see commits from Josh, Pratik (lifo), and Jeremy, while http://github.com/rails/rails/commits/3-0-unstable http://github.com/rails/rails/commits/3-0-unstable shows commits from those three, Yehuda, and Michael Koziarski (who is still quite active). Not to mention Rick Olson and all the patches from contributors, which now make their way more easily into core thanks to the streamlined contribution process and more active 'gatekeepers.' So fresh blood, more time, easier to contribute, and exciting new ideas would be my guess.
- simon_kun 18y ago
  One of my favourite graphs for explaining the power of git is the Rails traffic graph at github: http://github.com/rails/rails/graphs/impact http://github.com/rails/rails/graphs/impact . Track right until the beginning of April '08. That's when Rails moved to git.
  - ankhmoop 18y ago
    Are you sure that's not just presenting the "authorship-preserving" nature of git, rather than a significant increase in contributor diversity? Note that as contributor diversity appears to increase, LoC/primary contributor decreases.
bryanwoods 18y ago
Nested Model Forms are a timely addition. When I was learning Rails, I always kind of assumed forms could work more like this. More information: http://weblog.rubyonrails.org/2009/1/26/nested-model-forms http://weblog.rubyonrails.org/2009/1/26/nested-model-forms The 2.3 release seems to go a long way to limiting the amount of configuration required for all sorts of these slightly-bothersome tasks, which is really nice.
- zaius 18y ago
  It's been cleaned up a bit since that was posted. The release notes have a nicer, more concise example: http://guides.rubyonrails.org/2_3_release_notes.html http://guides.rubyonrails.org/2_3_release_notes.html
ionfish 18y ago
Perhaps some of the other Rails developers around here could satisfy my curiosity: when do you do the work (minor or major) to update your applications to use new releases? When the first or second RC comes out, or only once the 'official', final release is ready? Or are you tracking edge with an 'upgrade' branch or some equivalent?
- jherdman 18y ago
  Generally speaking I upgrade whenever I get the chance, but I always wait for an official release. Sometimes I let some of my smaller apps lag, but I try to keep fairly recent so as not to hold back any other apps that might be relying on major external requirements, such as Passenger ("mod_rails"). In the past I used to track edge, but that proved to be far too cumbersome.
- evdawg 18y ago
  I always update when the first RC comes out. I figure I can do my part and submit bug reports that way, but I've never actually run into any bugs. The RCs have been totally stable. Go figure.
- jaaron 18y ago
  I test against the RC releases and have found some bugs that way. This time, it was testing mod_rails that led me to testing my apps against Rails edge. I wanted to make sure I could run mod_rails on open solaris in this next release cycle, so I was running things on edge earlier than I typically do. Also, there was (is) an issue with Rails 2.3 and paperclip due to changes in how Rake handles empty file fields. There's been back and forth between the three projects on who needs to fix what. At the moment, the latest paperclip should work against Rails 2.3.
- mtarnovan 18y ago
  We've been branching to a 2.x tree and slowly adapting to the latest stable release (up until yesterday 2.2.2). Surprisingly plugin compatibility was not the biggest issue we faced (and we use many plugins) - most problems caused by plugins were solved by installing newer version. Our biggest problems come from subtle changes in HAML syntax, which causes syntax errors in a myriad of views. As you can imagine, it's rather tedious to hunt down those incompatibilities, as our application is rather large.

80 points by sant0sk1 18y ago

icey 18y ago

Can a Rails person tell us if this is a big deal or not?

teej 18y ago
This is a significant release. Many of the changes include modularizing Rails' internals. This reduces Rails lock-in and keeps the core more stable. I'm a fan of the performance tweaks in this one, but the important bits are the Rack integration and Ruby 1.9 compatability
- icey 18y ago
  Thanks for that. Is this the release in which Merb becomes integrated with Rails?
  - teej 18y ago
    This is the first release to have major Merb influence. Rails 3.0 (possibly in May) will be the true merging of the projects.
    - icey 18y ago
      I'm very excited for the confluence to occur. I've been looking around for a good web development stack to switch to for personal projects. I'm a .net guy during the day, but it's not enjoyable for me to work on. I have basic proficiency with Python, but I don't care for Django and Pylons doesn't have very good documentation. I am currently learning Clojure, but I get the feeling that I'd have to reinvent a lot of wheels to bring up a basic web development platform (on top of Compojure, I'd imagine). I plan on using Clojure down the road for some business logic I'm working on. It would be very nice to be able to keep all my heavy logic work in Clojure while using Rails on JRuby at some point down the road, so I think it's worthwhile for me to learn both. It's good to hear that they are making so much progress on the Rails core in the meantime. It is starting to sound like a much more robust platform than it did a couple of years ago.
patio11 18y ago
The templates feature ("start every Rails project with a default stack") is a godsend to folks who routinely start new projects, such as freelancers with quick turn around times or internal IT folks who crank out mini-applications. I do a bunch of little utility projects for work (e.g. "Report X was previously generated based on five Excel files which had to be manually synched and executed, now the information is in one place on the intranet and updated every night via a cron job.") When you have a project which takes under a man-week a significant portion of the time is "Oh bloody heck I didn't install the auto-complete gem", "Oh bloody heck I forgot I'd need Google charts again.", "Oh bloody heck where did I put that syntax highlighter plugin", etc. This lets me spend less time fighting Rails configuration and more time fighting Java XML configuration, like God intended.
- mdemare 18y ago
  Yes, this is a great innovation, and really according to the Rails Way. My favorite among the new features (and the other ones are good too.) Now combine this with GitHub (search for rails-templates) and you've got a evolutionary algorithm for discovering the best rails default stack.
- gsiener 18y ago
  Just curious, what gems do you use for those sorts of projects? Any of them on github to learn from/check out?
  - patio11 18y ago
    I have about 15 that I keep coming back to. Most deal with boring business requirements: charting (I use two different variants of Ruby wrappers for the Google Charts API, plus OpenFlashChart 2), data entry, parsing, etc. I have no clue where they're hosted since I use Google as my own personal link memory service.
  - mtarnovan 18y ago
    Some of the gems worth checking out (you can find most of them on github): * authlogic for authentication * openrain-action_mailer_tls for using smtp with tls with ruby <1.8.7 * mislav-will_paginate for pagination * rspec/rspec-rails/shoulda for testing * settingslogic for application configuration * haml/sass for templating Also some useful plugins: git://github.com/Bertg/i18n_action_mailer.git (i18n support in mailers) git://github.com/iain/i18n_label.git (translate labels) git://github.com/thoughtbot/limerick_rake.git (lots of useful rake tasks)

mdemare 18y ago

Is it me or has the development of Rails accelerated drastically lately? It used to feel quite slow, and now it's very fast. Is it because they switched to git? Any core developers here?

defunkt 18y ago
I would say there are a few factors responsible for this. First, Jeremy Kemper got hired by 37signals which seems to give him a lot more time to work on Rails. Next, around the time of the move to git, the existing Rails core team was shuffled a bit. Older members were retired (http://rubyonrails.org/core/alumni http://rubyonrails.org/core/alumni) and more active contributors (Josh and Pratik) were added to the team. Then you've got the Merb merger which brought in Yehuda who works full time on Rails now, afaik. If you look at http://github.com/rails/rails/commits/master http://github.com/rails/rails/commits/master you'll see commits from Josh, Pratik (lifo), and Jeremy, while http://github.com/rails/rails/commits/3-0-unstable http://github.com/rails/rails/commits/3-0-unstable shows commits from those three, Yehuda, and Michael Koziarski (who is still quite active). Not to mention Rick Olson and all the patches from contributors, which now make their way more easily into core thanks to the streamlined contribution process and more active 'gatekeepers.' So fresh blood, more time, easier to contribute, and exciting new ideas would be my guess.
simon_kun 18y ago
One of my favourite graphs for explaining the power of git is the Rails traffic graph at github: http://github.com/rails/rails/graphs/impact http://github.com/rails/rails/graphs/impact . Track right until the beginning of April '08. That's when Rails moved to git.
- ankhmoop 18y ago
  Are you sure that's not just presenting the "authorship-preserving" nature of git, rather than a significant increase in contributor diversity? Note that as contributor diversity appears to increase, LoC/primary contributor decreases.

bryanwoods 18y ago

Nested Model Forms are a timely addition. When I was learning Rails, I always kind of assumed forms could work more like this. More information: http://weblog.rubyonrails.org/2009/1/26/nested-model-forms http://weblog.rubyonrails.org/2009/1/26/nested-model-forms The 2.3 release seems to go a long way to limiting the amount of configuration required for all sorts of these slightly-bothersome tasks, which is really nice.

zaius 18y ago
It's been cleaned up a bit since that was posted. The release notes have a nicer, more concise example: http://guides.rubyonrails.org/2_3_release_notes.html http://guides.rubyonrails.org/2_3_release_notes.html

ionfish 18y ago

Perhaps some of the other Rails developers around here could satisfy my curiosity: when do you do the work (minor or major) to update your applications to use new releases? When the first or second RC comes out, or only once the 'official', final release is ready? Or are you tracking edge with an 'upgrade' branch or some equivalent?

jherdman 18y ago
Generally speaking I upgrade whenever I get the chance, but I always wait for an official release. Sometimes I let some of my smaller apps lag, but I try to keep fairly recent so as not to hold back any other apps that might be relying on major external requirements, such as Passenger ("mod_rails"). In the past I used to track edge, but that proved to be far too cumbersome.
evdawg 18y ago
I always update when the first RC comes out. I figure I can do my part and submit bug reports that way, but I've never actually run into any bugs. The RCs have been totally stable. Go figure.
jaaron 18y ago
I test against the RC releases and have found some bugs that way. This time, it was testing mod_rails that led me to testing my apps against Rails edge. I wanted to make sure I could run mod_rails on open solaris in this next release cycle, so I was running things on edge earlier than I typically do. Also, there was (is) an issue with Rails 2.3 and paperclip due to changes in how Rake handles empty file fields. There's been back and forth between the three projects on who needs to fix what. At the moment, the latest paperclip should work against Rails 2.3.
mtarnovan 18y ago
We've been branching to a 2.x tree and slowly adapting to the latest stable release (up until yesterday 2.2.2). Surprisingly plugin compatibility was not the biggest issue we faced (and we use many plugins) - most problems caused by plugins were solved by installing newer version. Our biggest problems come from subtle changes in HAML syntax, which causes syntax errors in a myriad of views. As you can imagine, it's rather tedious to hunt down those incompatibilities, as our application is rather large.