Rails 2.0 Released(weblog.rubyonrails.org)
weblog.rubyonrails.org
Rails 2.0 Released
http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done
15 comments
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.
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.
Heres the thread:
http://news.ycombinator.com/item?id=81932
http://news.ycombinator.com/item?id=81932
[deleted]
Nice summary for you:
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.
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.
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?
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.
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.
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).
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).
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.
Between this and Ruby 1.9 there's some fun new stuff for RoR folks to play with.
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.
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.
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.
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.
I'm seeing "Agile Web Development with Rails 3rd Edition" coming out soon!
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.
Its already 2.01 !!!
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).