Rails 3.1: Release candidate | Hacker News Reader

Rails 3.1: Release candidate

weblog.rubyonrails.org

180 pointsSingAlong26 comments

Open articleView on HN

I am using Jammit for asset management and Barista for compiling coffeescript on the fly with a Rails 3.0.7 project.

Any comparisons between Jammit and Sprocket will be welcome.

So far, it looks like the only real differences are:

* jammit uses config/assets.yml, sprockets uses inline requires

* jammit loads individual files in development, sprockets concatenates

* sprockets compiles coffee with :bare => false by default. I don't know what barista's default is

for large js projects, sprockets is a nightmare. trying to add a breakpoint in a 5,000 line javascript file is really really frustrating.

Would love to see a workaround in sprockets (to make each js file included separately in dev mode), but until then I'd say Jammit is the way to go.

Kudos for bundling a simple BCrypt-based authentication.

I'm new to Rails and am currently working through the tutorial at railstutorial.org. I'm a PHP/CodeIgniter dev so a lot of the features are new but many concepts are familiar.

Browsing the linked GitHub code on the OP's link relating to the new secure_password stuff - does this make the authentication code used in the above tutorial obsolete - the commented example on GitHub indicated included BCrypt based password storage/authentication method ... ?

The SHA2 digest approach in the Rails Tutorial book is still the standard in many applications and authentication plugins, and is fine for most applications. The basic techniques you'll learn in the current 3.0 version are still useful. That said, I am working on a new version of the book that uses bcrypt.

Notice this in the new rake 0.9.0:

* Incompatible change: Rake DSL commands ('task', 'file', etc.) are no longer private methods in Object. If you need to call 'task :xzy' inside your class, include Rake::DSL into the class. The DSL is still available at the top level scope (via the top level object which extends Rake::DSL).

http://github.com/jimweirich/rake/blob/master/CHANGES

The fix has been included in Release candidate:

https://github.com/rails/rails/commit/8b719cf3f73cbce78506e3...

Right; my comment was for people who may encounter the incompatibility in their own Rakefiles.

I ran into this bug today in a fresh install of the latest Rails/Rake. If your rake tasks are currently exploding due to Rake 0.9.0, making your Rakefile look like this will fix it:

https://gist.github.com/4b4e24877b107b00bcba

On second thought, don't do this. Add rake 0.8.7 to your gemfile and bundle update. Rake 0.9.0 is insanely broken.

Anybody know how easy it will be to upgrade a 3.0 Rails app to 3.1? Especially in regards to changing it to use jQuery.

There is no need to change it to use jQuery, it's not enforced. If you specifically want to switch over, you can only expect rails helpers to work out of the box.

I just upgraded an app from 3.0.7 to 3.1.0 rc1

I use Devise and Mongo Mapper. The Mongo Mapper for Devise gem depends on Devise 1.1.x, and this causes a bunch of deprecation warnings, but it works. I don't know if the latest Devise has this fixed, as I can't run it due to the Mongo Mapper for Devise dependency.

Some hand editing of development.rb to remove the debug_rjs setting and some editing to change my use of stylesheet_tag and my app ran ok

I'm not using the cool new asset pipeline yet, but my app runs with 1 hour of work.

Did you just point the gemfile to newer version and did hand editing as you went along or is there a command for the upgrade?

I just manually changed the Gemfile to 3.1.0.rc1 and fixed things that broke.

My next step is to fixup my morass of CSS and JS files to use the Asset pipeline correctly. That's probably another hour or so.

I've had trouble with Mongo Mapper and Devise.

I've upgraded Mongo Mapper to 0.9.1 to take advantage of it's Rails 3 integration, and it works with Devise 1.3.4 which removes the deprecation warnings.

To do this, I had to pull down the devise-mongo_mapper plugin to avoid version conflicts - it works with the newer code with no changes.

Mongo Mapper 0.9.x has a new configuration hookup that I had already written myself, so that code had to get a small change.

Joint, a Mongo Mapper plugin, doesn't work. I was going to replace Joint anyway for my own needs, now I need to do it today instead of next week.

Now I'm 2 hours in, and still not working on the Asset pipeline work I want to do, but my app is running except for the Joint bits

I found this and it seems to be useful. https://github.com/rails/jquery-ujs/blob/master/README.md

Kind of a bummer that "HTTP streaming" only works with Ruby 1.9.2. I'm not against upgrading to Ruby 1.9.2, it's just that Puppet doesn't support it yet.

Will this make all my latest Rails 3.0 books worthless?

No.

edit: Your printed technical book was essentially worthless the moment you bought it, given how fast most software evolves these days. But, I'm guessing you mean: 'will this make my book so outdated as to be worthless in terms of learning.'

The answer is still no. All of the major new features are, essentially, optional, with the exception of jQuery, but hopefully you were already using that anyway.

The Asset Pipeline, SCSS and CoffeeScript are major new features, but you'd likely need to read up on SCSS and CoffeeScript separately anyway. The Asset Pipeline can probably be understood with a couple good blog posts.

HTTP streaming: same thing. Also, it's—again—an optional feature.

Thanks.

I was thinking how long it took for "Agile Web Development with Rails 4th Edition" to come out and now 3.1 is on the way. Luckily guides like railstutorial.org update along with new Rails releases.

I'll agree with aaronbrethorst here: your books are going to out-dated regardless; it's the major downside to software hardcopy these days, especially web-focussed stuff.

Saying that, Rails 3.0 to 3.1 isn't like 2.x to 3.0 (where your books WOULD have been useless). A lot of the changes are evolutionary, and there's nothing stopping you from learning on the latest 3.0.x branch with your book before tackling the (fairly straightforward) 3.0 to 3.1 upgrade process, once you've got your Rails knowledge bedded down.

My rule of thumb: only buy tech books that primarily contain good practices by experienced devs. Good practices tend to survive longer than APIs, and provide long-term value.

There are exceptions though for the base software... Stevens' TCP/IP illustrated and Unix programming will be relevant for many more years, since they describe some pretty much frozen standards.

I can't speak for other books, but by design the Ruby on Rails 3 Tutorial book is robust against this kind of change. The trick is to use explicit gem version numbers for everything. (I learned this lesson the hard way by watching my first book, RailsSpace, quickly go out of date.) Moreover, the differences between Rails 3.1 and Rails 3.0 are relatively minor, especially when considering how applications are structured. The Rails 3.0 knowledge you learn is still 100% useful.

That being said, I'm currently working on a Rails 3.1 version of the book. Stay tuned to http://news.railstutorial.org/ to get an announcement when it's ready.

Reply on news.ycombinator.com