5 ms·

Rails 2.0 Released

50 points by carpal 19y ago

icey 19y ago
A 2.0 release seems like a big deal; is there a rails practitioner around who could describe the magnitude of these changes to those of us who don't use rails?
- carpal 19y ago
  I've been developing off of the preview releases for a few weeks, and there's nothing earth shattering. Generally, it just makes things nicer. I don't do a lot of AJAXy stuff, and I don't talk very frequently to clients that aren't standard browswers. If I did, I think I would have a lot more to gain from this release.
  - michaelneale 19y ago
    That is probably a good thing. Rails is a great fit for what it does, a 2.0 danger was to do beyond its strengths. It seems to have evolved nicely. I look forward to using it. As for the questions about the lack of "scalability" improvements, I don't really care. Its not needed for what I use it for anyway (and probably the same for most people).
- jraines 19y ago
  One new thing is the ActiveREST module, which provides a lot of neat support for creating RESTful services. Between this and Ruby 1.9 there's some fun new stuff for RoR folks to play with.
- qaexl 19y ago
  The change between 1.1 and 1.2 was much more disruptive than the change between 1.2 and 2.0. The biggest changes are in reworking the RESTful controllers and cutting down the cruft. 2.0 is more polished and shinier now. The 2.0 release may be coming in close with the upcoming Ruby 2.0 release, which will be highly disruptive (YARV bytecode backend), though I'm not sure if Rails 2.0 will work fine without any changes in Ruby 2.0. Besides, I'm not really sure when Ruby 2.0 is coming out.
  - russ 19y ago
    I've been hearing that by Xmas for Ruby2 and the Rails guys have been doing quite a bit of work to make sure Rails2 is compatible with the upcoming Ruby release. I'm not sure how much will need to change, but they have indeed been working towards making it compatible.
- palish 19y ago
  Keep in mind that as a tool approaches "optimal", it needs to be changed less and less. So if Rails' new features don't justify the jump to "2.0", its stability and user-adoption may.
nanijoe 19y ago
Its already 2.01 !!!
hello_moto 19y ago
I'm seeing "Agile Web Development with Rails 3rd Edition" coming out soon!
mattmaroon 19y ago
I know we're pretty excited. Performance is going to be a major issue for us once we get into providing live stats for people. We'll see how this helps.
russ 19y ago
Nice summary for you: http://blog.viget.com/whats-coming-in-rails-20/ http://blog.viget.com/whats-coming-in-rails-20/ A big part about Rails2 is also to take the cruft out of the framework. In other words, moving things out into plugins and cleaning up the core.
kingnothing 19y ago
Does anyone have anything to add about the security of this: Action Pack: Cookie store sessions The default session store in Rails 2.0 is now a cookie-based one. That means sessions are no longer stored on the file system or in the database, but kept by the client in a hashed form that can't be forged. This makes it not only a lot faster than traditional session stores, but also makes it zero maintenance. There's no cron job needed to clear out the sessions and your server won't crash because you forgot and suddenly had 500K files in tmp/session. This setup works great if you follow best practices and keep session usage to a minimum, such as the common case of just storing a user_id and a the flash. If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can't be forged (so is_admin = true is fine), their content can be seen. If that's a problem for your application, you can always just switch back to one of the traditional session stores (but first investigate that requirement as a code smell).
- deleted 19y ago
  [deleted]
- qaexl 19y ago
  Yeah. There was a discussion about it in an earlier thread. Unfortunately, I can't seem to find it anymore. If you look at the code, the session store is stored in plaintext with the hash. Rails rehashes the plaintext in the cookie and checks it against the hash to make sure it has not been tampered with. The last time I checked, the hashing uses OpenSSL's HMAC hashing rather than the SHA1 in earlier versions of Rails. You, as the developer, are responsible for entering in the site's secret code. It should be possible to write a Rails 2.0 initializer in config/intializer to check the presence of config/secret.yml and if not, generate it in runtime. This keeps you from having to save the secret in the version control, but unfortunately, doesn't work well when you deploy it across several machines. Note that the cookie store was available in 1.2. Seems as if the core developers like it enough to enable it by default. As for me, I think I'll stick with ActiveStore for a while until my sites needs more drastic means, such as memcached or even cookie store.
  - carpal 19y ago

50 points by carpal 19y ago

icey 19y ago

A 2.0 release seems like a big deal; is there a rails practitioner around who could describe the magnitude of these changes to those of us who don't use rails?

carpal 19y ago
I've been developing off of the preview releases for a few weeks, and there's nothing earth shattering. Generally, it just makes things nicer. I don't do a lot of AJAXy stuff, and I don't talk very frequently to clients that aren't standard browswers. If I did, I think I would have a lot more to gain from this release.
- michaelneale 19y ago
  That is probably a good thing. Rails is a great fit for what it does, a 2.0 danger was to do beyond its strengths. It seems to have evolved nicely. I look forward to using it. As for the questions about the lack of "scalability" improvements, I don't really care. Its not needed for what I use it for anyway (and probably the same for most people).
jraines 19y ago
One new thing is the ActiveREST module, which provides a lot of neat support for creating RESTful services. Between this and Ruby 1.9 there's some fun new stuff for RoR folks to play with.
qaexl 19y ago
The change between 1.1 and 1.2 was much more disruptive than the change between 1.2 and 2.0. The biggest changes are in reworking the RESTful controllers and cutting down the cruft. 2.0 is more polished and shinier now. The 2.0 release may be coming in close with the upcoming Ruby 2.0 release, which will be highly disruptive (YARV bytecode backend), though I'm not sure if Rails 2.0 will work fine without any changes in Ruby 2.0. Besides, I'm not really sure when Ruby 2.0 is coming out.
- russ 19y ago
  I've been hearing that by Xmas for Ruby2 and the Rails guys have been doing quite a bit of work to make sure Rails2 is compatible with the upcoming Ruby release. I'm not sure how much will need to change, but they have indeed been working towards making it compatible.
palish 19y ago
Keep in mind that as a tool approaches "optimal", it needs to be changed less and less. So if Rails' new features don't justify the jump to "2.0", its stability and user-adoption may.

nanijoe 19y ago

Its already 2.01 !!!

hello_moto 19y ago

I'm seeing "Agile Web Development with Rails 3rd Edition" coming out soon!

mattmaroon 19y ago

I know we're pretty excited. Performance is going to be a major issue for us once we get into providing live stats for people. We'll see how this helps.

russ 19y ago

Nice summary for you: http://blog.viget.com/whats-coming-in-rails-20/ http://blog.viget.com/whats-coming-in-rails-20/ A big part about Rails2 is also to take the cruft out of the framework. In other words, moving things out into plugins and cleaning up the core.

kingnothing 19y ago

Does anyone have anything to add about the security of this: Action Pack: Cookie store sessions The default session store in Rails 2.0 is now a cookie-based one. That means sessions are no longer stored on the file system or in the database, but kept by the client in a hashed form that can't be forged. This makes it not only a lot faster than traditional session stores, but also makes it zero maintenance. There's no cron job needed to clear out the sessions and your server won't crash because you forgot and suddenly had 500K files in tmp/session. This setup works great if you follow best practices and keep session usage to a minimum, such as the common case of just storing a user_id and a the flash. If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can't be forged (so is_admin = true is fine), their content can be seen. If that's a problem for your application, you can always just switch back to one of the traditional session stores (but first investigate that requirement as a code smell).

deleted 19y ago
[deleted]
qaexl 19y ago
Yeah. There was a discussion about it in an earlier thread. Unfortunately, I can't seem to find it anymore. If you look at the code, the session store is stored in plaintext with the hash. Rails rehashes the plaintext in the cookie and checks it against the hash to make sure it has not been tampered with. The last time I checked, the hashing uses OpenSSL's HMAC hashing rather than the SHA1 in earlier versions of Rails. You, as the developer, are responsible for entering in the site's secret code. It should be possible to write a Rails 2.0 initializer in config/intializer to check the presence of config/secret.yml and if not, generate it in runtime. This keeps you from having to save the secret in the version control, but unfortunately, doesn't work well when you deploy it across several machines. Note that the cookie store was available in 1.2. Seems as if the core developers like it enough to enable it by default. As for me, I think I'll stick with ActiveStore for a while until my sites needs more drastic means, such as memcached or even cookie store.
- carpal 19y ago