Rails 4.0: Final version released(weblog.rubyonrails.org)
weblog.rubyonrails.org
Rails 4.0: Final version released
http://weblog.rubyonrails.org/2013/6/25/Rails-4-0-final/
152 comments
That's unfortunate. Eloquent Ruby and POODR are two of my dearest Ruby books. Rails Anti-Patterns was another great book. If DHH and Co. don't want to recognize some of the great books you and others have churned out, at least take solace in the fact that many in the community appreciate your hard work.
Same here. My three favorite Ruby books are POODR, Eloquent Ruby, and Hartl's tutorial.
I LOOOOOOOVE Eloquent Ruby - Russ Olsen's writing style is so awesome.
Design Patterns in Ruby is just as enjoyable.
I have never heard of POODR before...but given that so many people are listing it in the same "top list" as Eloquent Ruby - I am definitely gonna get it.
Hartl's tutorial was a bit much for me. I don't think when I was just learning Rails, to be thrown into TDD was wayy too much and made it much less enjoyable.
I think if there was a "no-TDD" path, it would have been better....or maybe some way to explain the TDD aspect more clearly.
Design Patterns in Ruby is just as enjoyable.
I have never heard of POODR before...but given that so many people are listing it in the same "top list" as Eloquent Ruby - I am definitely gonna get it.
Hartl's tutorial was a bit much for me. I don't think when I was just learning Rails, to be thrown into TDD was wayy too much and made it much less enjoyable.
I think if there was a "no-TDD" path, it would have been better....or maybe some way to explain the TDD aspect more clearly.
Thumbs up for eloquent ruby, fantastic book
I'd figure that it's more due to differing opinions on things like Test::Unit vs Rspec, Haml vs Erb etc than your publisher. Still, not a good excuse to go unrecognized. RW3 was excellent, and I'm sure 4 is as well. Best of luck.
"The Rails 3 Way" certainly wasn't excellent, it was clearly a rushed update of the original "The Rails Way", it uses a lot of old practices all over the place and the stuff new in Rails 3 is just added as an afterthought.
Author here. It took nearly two years to get that rewrite done. A lot of things changed in Rails 3 right at the end of our production cycle so admittedly it was a challenge to get it all to the finish line in the best possible way. That won't be the case with the new edition. I have a stellar team helping me get this done properly and we're using the excellent Leanpub system to release the book incrementally and ensure the finished product is of the highest quality. Much different situation.
Just ordered tr4w - at leanpub it says "These authors use Leanpub to publish this book independently." I'm just curious whether that's accurate, since you refer to Addison-Wesley as
"us"? Thanks
I have a special arrangement with AW to publish independently via leanpub. Book will also be on sale via traditional retail channels once the hardcopy is ready later this year. We view it as separate channels. Traditional retail hits a different customer segment, especially when you start taking into account corporate subscribers to Safari and companies that do bulk purchases, etc.
Thanks for clarifying!
Co-Author here: I'm part of the team that is helping write The Rails 4 Way. Just to address your concerns, we have gone through the existing manuscript and removed everything that isn't best practice today. On top of that, we are covering all the new Rails 4 features, and important gems/techniques valuable to a Rails developer today. The second half of the book is going through a big revamp right now. Look for updates in the coming weeks.
Another co-author here. By now most people should probably already know that Rails has 2 default stacks: http://words.steveklabnik.com/rails-has-two-default-stacks
Since the Book is not 'the factory default stack of Rails' but rather the Rails "way" we certainly do have an opinion about what is considered the most popular and efficient way of building Rails apps. This does mean we use HAML throughout the book, because honestly, we all think its a better choice. Personally, since we converted to HAML at Astrails several years ago, I cringe every time I have to deal with ERB. Its just too verbose and it doesn't present the structure as obviously as HAML. Same for the rest of the 'opinions' in the book. YMMW
Since the Book is not 'the factory default stack of Rails' but rather the Rails "way" we certainly do have an opinion about what is considered the most popular and efficient way of building Rails apps. This does mean we use HAML throughout the book, because honestly, we all think its a better choice. Personally, since we converted to HAML at Astrails several years ago, I cringe every time I have to deal with ERB. Its just too verbose and it doesn't present the structure as obviously as HAML. Same for the rest of the 'opinions' in the book. YMMW
At one point Rails 4 was considering Test::Spec, and I for one was disappointed when that was dropped, as it was an opportunity to standardise on declarative style tests in a lightweight native library, and might have stood a chance of building enough momentum to build a groundswell of support.
As it is, while one can of course still use Test::Spec, you're likely to be in a small minority.
As it is, while one can of course still use Test::Spec, you're likely to be in a small minority.
I'm not sure about that. Rails Tutorial uses Rspec extensively and gets some great recognition.
That's unfortunate because, of all the Rails books I've purchased through the years, yours and Hartl's are the best for my particular learning style. Doubt it's just me...
It's not just you. Our sales are very strong and growing year on year. I'm very happy with the perfoance of the series. Sandy Metz's new book is getting rave reviews everywhere.
I just finished Sandy Metz's book, and it is fantastic. Easily one of the best ruby books I've read; I can't recommend it enough.
well, I purchased "merb in action" and waited for a while when it happend. But IMHO, rails4 books are good.
Your book for me is the de-facto standard Rails bible and it's what I always recommend to new learners. I find it very strange that it's not the top official recommendation.
This is exactly the comment I was looking for. Has anyone read both this and Hartl's tutorial? What are the strengths of this book over Hartl's?
The Rails Tutorial is a step-by-step approach to learning web development with Rails, which covers selective features of the framework as needed, whereas The Rails Way is a comprehensive reference covering the entire framework. Between them, they're a good one-two punch to go from Rails newcomer to expert.
On Hartl's site, the most recent update is from May 15th for Rails 4.0 rc1. I'll feel more comfortable when Michael confirms the tutorial is valid for the final release.
I updated the book for RC2 the day it came out (announced on Twitter at https://twitter.com/railstutorial/status/344981158825689088; it just didn't merit a post on the news feed), and I've just updated it for 4.0 final.
I know for a fact he's been working a lot on it. I'll give him a heads up to come comment on it here. Stay tuned
Just bought a copy. Was always a little bit tentative about reading Rails 3 way since 4 ways right around the corner. Glad to have it and you can't beat the price!
What does it mean when it says the book is 75% complete? If you purchase the book now, will it get updated later for free?
Yes. We're rolling out a new update this week. Been a tough confluence of events for me personally - demo day for my TechStars startup is 2 days from now
R3W was a great help when I was getting started with Rails. Thank you :)
I just purchased R4W, looking forward to brushing up.
I just purchased R4W, looking forward to brushing up.
I am so excited, as this is the first major release that I've contributed to! Thank you so much to all the other people who've put this release together, I really do think this is the best Rails yet!
http://contributors.rubyonrails.org/releases/4-0-0/contribut...
I mentioned this below, but I'll mention it here, as well: if you have gems that aren't ready yet for Rails 4, please ping me and let me know if I can help get them ready somehow. If you maintain a gem and want help running your tests on Travis against multiple versions of Rails, I can help with that as well.
<3 <3 <3 <3
http://contributors.rubyonrails.org/releases/4-0-0/contribut...
I mentioned this below, but I'll mention it here, as well: if you have gems that aren't ready yet for Rails 4, please ping me and let me know if I can help get them ready somehow. If you maintain a gem and want help running your tests on Travis against multiple versions of Rails, I can help with that as well.
<3 <3 <3 <3
Congratulations! That's truly awesome. Any tips for a novice developer who would love to start contributing?
Thank you! I started less than a year ago, and I was the #13th biggest contributor here, and received a commit bit a few weeks ago. It's not too hard to get involved if you'd like!
I wrote up my own personal 'contributing to Rails' guide here: http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-cont...
The official one is here: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_ra...
The easiest way is to write documentation; that's how I got started. It's not for everyone, though. The simplest possible way to get involved with writing code is to pick an open bug on the tracker and fix it.
Like most things, it just gets easier the more you do it. The first one seems hard, everything seems confusing. But by the time you've done two or three, you wonder why you ever thought it was difficult.
I wrote up my own personal 'contributing to Rails' guide here: http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-cont...
The official one is here: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_ra...
The easiest way is to write documentation; that's how I got started. It's not for everyone, though. The simplest possible way to get involved with writing code is to pick an open bug on the tracker and fix it.
Like most things, it just gets easier the more you do it. The first one seems hard, everything seems confusing. But by the time you've done two or three, you wonder why you ever thought it was difficult.
LOL. Meeting of the minds with my comment above :)
Thanks! I'll definitely check out the guides and try to get started!
Great! Ping me if you have problems.
I gave it a shot! [0] Hopefully everything looks okay. The hardest part was finding an issue. Thanks again for your advice!
[0] https://github.com/rails/rails/pull/11193
[0] https://github.com/rails/rails/pull/11193
I am sure Steve would say this as well (because he has said it many times). Start by improving the documentation of helping to regress bugs. These two items while seemingly inconsequential are actually a huge help to the core team and all developers who actually use rails (especially awesome documentation).
Once you get a certain level of familiarity with the way Rails is built, find a small bug and follow the contribution guidelines.
There is no magic :) Take small steps and continue to make any contribution you can. Ask a ton fo questions and work through issues, you'll get there.
Here's a blog post that Steve actually wrote about contributions:
http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-cont...
Congrats as well Steve! You should be really proud of this release with the rest of the core team.
Once you get a certain level of familiarity with the way Rails is built, find a small bug and follow the contribution guidelines.
There is no magic :) Take small steps and continue to make any contribution you can. Ask a ton fo questions and work through issues, you'll get there.
Here's a blog post that Steve actually wrote about contributions:
http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-cont...
Congrats as well Steve! You should be really proud of this release with the rest of the core team.
Thank you! I'll be sure to try and start taking my first steps :)
I would love any documentation/article/lead to help running and supporting older rails versions. I've published a gem that supports both rails-4 and rails-3 (https://github.com/oelmekki/activerecord_any_of), but it supports only rails-3.2.13 for the 3.x part as it is my current installed version. I would rather support at least all 3.2.x branch.
And thank you for contributing in making rails awesome :)
And thank you for contributing in making rails awesome :)
Wow, 3 of the top 4 contributors are Brazilian. Glad to see so much love towards Rails from Brazil :) I hope to make it into the contributors list for the next release.
Yep, Platformatec are great people.
You're awesome. Just upgraded to the latest! Thanks!
Ug. We have a new website that is coming out in about a month. Enough mileage on 3.2 that it's too painful to consider delaying, but hate the thought of doing the upgrade later.
Would love opinions from the HN gallery as to whether a delay now saves time later.
Edit: And thanks to the Rails team for providing me with this conundrum!
Edit2: Thanks for the info and opinions! I'll check back later too.
Would love opinions from the HN gallery as to whether a delay now saves time later.
Edit: And thanks to the Rails team for providing me with this conundrum!
Edit2: Thanks for the info and opinions! I'll check back later too.
Having played this game repeatedly, I suggest waiting until 4.1 or so. Point releases are often buggier than intended, such is life, and it's going to take another year before plugins start requiring it anyways.
If you're on 2.3.x upgrade, otherwise wait a bit.
If you're on 2.3.x upgrade, otherwise wait a bit.
I think Rails 4.1 is when all current deprecations are being removed, which is going to be a bit hairy for people accustom to <= Rail 3.x finder syntax and ancient plugins that somehow manage to still work.
To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
>which is going to be a bit hairy for people accustom to <= Rail 3.x finder syntax and ancient plugins that somehow manage to still work.
Yeah, but that pain will come regardless. Better I think to wait until the dust settles on turbolinks et al and plugin authors update. You could always update first to 4.0.x (for mild to large values of x) or what have you before jumping over to 4.1.
Point is, if you've got a large app it's not worth pushing back any deadlines. Someone's gotta do it! and much to love to the rails-core team, but being 3 months behind the release schedule still counts as "bleeding edge" in most of the rest of the software world ;).
Yeah, but that pain will come regardless. Better I think to wait until the dust settles on turbolinks et al and plugin authors update. You could always update first to 4.0.x (for mild to large values of x) or what have you before jumping over to 4.1.
Point is, if you've got a large app it's not worth pushing back any deadlines. Someone's gotta do it! and much to love to the rails-core team, but being 3 months behind the release schedule still counts as "bleeding edge" in most of the rest of the software world ;).
Last time we went through this, I wrote one app in 3.0, got a sense of the deprecations, started another at 3.1, then did straight 2>3 updates or new apps in 3.2 once I had it all down. There's no hurry.
> To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
I think this is the most likely outcome. Thanks again to everyone for the discussion too.
I think this is the most likely outcome. Thanks again to everyone for the discussion too.
> it's going to take another year before plugins start requiring it anyways.
If anyone has gems that don't work with 4 yet, please let me know. Most of them at least have a branch going, but I'm always curious, and am willing to help out to upgrade things.
If anyone has gems that don't work with 4 yet, please let me know. Most of them at least have a branch going, but I'm always curious, and am willing to help out to upgrade things.
The upgrade isn't that bad. Nowhere near going 2.x to 3.x.
Our application is still on 2.x and we were delaying migrating in hopes that we would have time to actually just refactor into a 3.x application. So this effectively means that we are going to either need to fast track this effort which is likely not going to happen, or make the attempt to migrate to 3.x with an application the size of an elephant.
Definitely not going to be fun!
Definitely not going to be fun!
Hello!
I have performed two rails 2 upgrades. Both cases they were smallish apps, but they took 3-5 days to feel comfortable with everything that's happened.
If this is an app that is still being actively developed, I highly recommend you fast track it.
[If not, look up the community-managed security back port branch and switch to that asap]
Basically, the problem stems from bit-rot and alas such is the nature of our industry. In a nutshell, the longer you wait the harder it is to find quality docs on what's changed and how to fix it. A lot of links are now gone.
The main challenge comes from: the change in the router, the changes in the view api (everything is escaped by default, and you will find a ton of string concats in your helpers that will now spit out garbage), migrating over to the asset pipeline (which I personally found confounding for a long time until I got the hang of it), migrating over to Arel queries and updating all of your plugins - many of which will stop working in quirky ways. You may also experience pain with updating your test suite.
So, there's a lot of yak shaving but you don't actually have to refactor your app much. Your controllers will remain basically untouched and so will your models modulo named scopes and certain now preferred validation patterns. Most of the pain is view-focussed.
Oh, and the attribute protection but that pain is a good pain, you really need to whitelist your attributes. IF YOU ARE READING THIS MAKE SURE YOUR MODELS HAVE AN `attr_accessible` THAT DOES NOT HAVE ANY ATTRIBUTE THAT ENDS IN `_id`.
There's a phenomenal plugin that will help a lot - https://github.com/rails/rails_upgrade - but it's not going to catch everything.
I have performed two rails 2 upgrades. Both cases they were smallish apps, but they took 3-5 days to feel comfortable with everything that's happened.
If this is an app that is still being actively developed, I highly recommend you fast track it.
[If not, look up the community-managed security back port branch and switch to that asap]
Basically, the problem stems from bit-rot and alas such is the nature of our industry. In a nutshell, the longer you wait the harder it is to find quality docs on what's changed and how to fix it. A lot of links are now gone.
The main challenge comes from: the change in the router, the changes in the view api (everything is escaped by default, and you will find a ton of string concats in your helpers that will now spit out garbage), migrating over to the asset pipeline (which I personally found confounding for a long time until I got the hang of it), migrating over to Arel queries and updating all of your plugins - many of which will stop working in quirky ways. You may also experience pain with updating your test suite.
So, there's a lot of yak shaving but you don't actually have to refactor your app much. Your controllers will remain basically untouched and so will your models modulo named scopes and certain now preferred validation patterns. Most of the pain is view-focussed.
Oh, and the attribute protection but that pain is a good pain, you really need to whitelist your attributes. IF YOU ARE READING THIS MAKE SURE YOUR MODELS HAVE AN `attr_accessible` THAT DOES NOT HAVE ANY ATTRIBUTE THAT ENDS IN `_id`.
There's a phenomenal plugin that will help a lot - https://github.com/rails/rails_upgrade - but it's not going to catch everything.
The problem that we run into is that most people haven't upgraded a 2.3 application that is our size. We're already aware of the community-managed backports, but ideally we will just be able to fast track moving towards 3.2 soon.
We have actually backported sprockets/asset pipeline quite awhile back and have been using it without any major problems.
Definitely aware of the benefits its just very hard to do something at the scale that we're at :). Earlier this year our REE -> 1.9.3 upgrade took about a month and a half. For the past year we've been moving to separate, smaller applications and then breaking those into mountable engines within each application.
Appreciate the feedback though and the links!
We have actually backported sprockets/asset pipeline quite awhile back and have been using it without any major problems.
Definitely aware of the benefits its just very hard to do something at the scale that we're at :). Earlier this year our REE -> 1.9.3 upgrade took about a month and a half. For the past year we've been moving to separate, smaller applications and then breaking those into mountable engines within each application.
Appreciate the feedback though and the links!
Some folks from New Relic gave a talk at RubyConf this year about upgrading their old-for-Rails project from 2 to 3, I found it pretty informative http://www.confreaks.com/videos/2425-railsconf2013-changing-...
I'll watch that video! Thanks!
I'm a stickler for attr_accessible, but I've never heard of avoiding _id attributes. If a have an Employee model, what is wrong with `attr_accessible :department_id` (assuming I want to permit changing the department)?
It depends on your app.
Suppose you have some kind of permissions model based around the department that a certain employee belongs to. Say, HR people can look at people's salaries.
If you allow mass assignment to department_id, someone can edit the form in the user page and assign themselves to ANY department and boom!, they're in.
You can fix this by having some sort of validation, but I find I prefer to have it in the controller.
Before:
Suppose you have some kind of permissions model based around the department that a certain employee belongs to. Say, HR people can look at people's salaries.
If you allow mass assignment to department_id, someone can edit the form in the user page and assign themselves to ANY department and boom!, they're in.
You can fix this by having some sort of validation, but I find I prefer to have it in the controller.
Before:
@model.update_attributes(params[:model]) # trololol
dept = params[:model].delete[:department_id]
@model.update_attributes(params[:model])
if current_user.can(:foo)
@model.department = Department.find(dept)
end
Okay, so it just comes down to whether or not the user should be allowed to edit the FK relationship or not.
You may be interested to know that you can have multiple attr_accessible declarations for different classes of user, and then when you call update_attributes you say which declaration should apply. But perhaps with strong parameters it's not worth going down that road.
You may be interested to know that you can have multiple attr_accessible declarations for different classes of user, and then when you call update_attributes you say which declaration should apply. But perhaps with strong parameters it's not worth going down that road.
Depends on the size of your Gemfile. There will inevitably be gems that have unpatched Rails 4 bugs.
> Depends on the size of your Gemfile.
Really, it's not large. The things I'm most worried about are
Really, it's not large. The things I'm most worried about are
gem 'carrierwave'
gem 'jquery-fileupload-rails'
gem 'jquery-datatables-rails'
gem 'jquery-ui-rails'
CarrierWave appears to support Rails 4; the rest are not doing anything special other than making jquery js acripts available in the asset pipline without manually installing them, so shouldn't cause any issues.
You'll have a bit of work to do to migrate to strong parameters, but you can always add the protected_attributes gem back to re-enable support for attr_accessible.
I'd suggest checking out the Rails 4 migration RailsCast.
You'll have a bit of work to do to migrate to strong parameters, but you can always add the protected_attributes gem back to re-enable support for attr_accessible.
I'd suggest checking out the Rails 4 migration RailsCast.
I've been using Carrierwave with Rails 4 RCs and haven't run into any trouble with it.
Thank you for this info.
As an aside, how is the jquery-fileupload thing? I was reading about it, and when I saw there was some weird iframe thing for IE... I closed the page and walked away. That kind of thing looks like it could be a nightmare if something goes wrong.
Having recently worked with this project I can say that it's pretty reliable and way better than most jQuery plugins you'll find out there.
The iframe transport method for uploads is useful for browsers that don't support XHR file uploads (basically IE < 10). You can read more a bit about how it works in: https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
The iframe transport method for uploads is useful for browsers that don't support XHR file uploads (basically IE < 10). You can read more a bit about how it works in: https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
> As an aside, how is the jquery-fileupload thing?
I don't have a good answer: Fine to program with, but certainly took some doing for our particular need. (We had a number of requirements that made the "easy" out-of-the-box jquery-fileupload not suitable.)
Ask me in a couple of months and I'll probably have a lot of opinions to give.
> and when I saw there was some weird iframe thing for IE... I closed the page and walked away.
We are migrating customers from a C++ desktop app to a web interface: So anyone on old IE with problems will be informed that they're not supported on the new system, so keep using the old and let us know after they upgrade. :) (Newer IE is OK.)
Deviously, this also prevents absolutely everyone from ditching the old app and swamping the new system on day 1.
I don't have a good answer: Fine to program with, but certainly took some doing for our particular need. (We had a number of requirements that made the "easy" out-of-the-box jquery-fileupload not suitable.)
Ask me in a couple of months and I'll probably have a lot of opinions to give.
> and when I saw there was some weird iframe thing for IE... I closed the page and walked away.
We are migrating customers from a C++ desktop app to a web interface: So anyone on old IE with problems will be informed that they're not supported on the new system, so keep using the old and let us know after they upgrade. :) (Newer IE is OK.)
Deviously, this also prevents absolutely everyone from ditching the old app and swamping the new system on day 1.
Unfortunately, that's the necessary hack, as far as I know, if you want to have an ajax submission.
I definitely agree, this is a lot less difficult.
This would in many ways seem to suggest a less urgent need to upgrade from 3 to 4 than there was from 2 to 3 though. It seems like a major focus of 4 was speeding up client/server interactions. If that's not a major concern, I don't necessarily think it's something to lose sleep over in the near term.
I'm in the same boat (having been building on Rails 3 for a good while) and for now I'm going to stay put. People who are more knowledgeable about the specific updates please correct me if my assumptions are off-base.
I'm in the same boat (having been building on Rails 3 for a good while) and for now I'm going to stay put. People who are more knowledgeable about the specific updates please correct me if my assumptions are off-base.
Make sure to read the maintenance policy [1]: starting from today:
- the bug fixes will only be included in 4.0.z releases
- the security issues will only be fixed in 4.0.z and 3.2.z
- the severe security issues will only be fixed in 4.0.z, 3.2.z
So you will want at least to upgrade to 3.2.z, or use Rails LTS ([2])
[1] http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...
[2] http://railslts.com/
- the bug fixes will only be included in 4.0.z releases
- the security issues will only be fixed in 4.0.z and 3.2.z
- the severe security issues will only be fixed in 4.0.z, 3.2.z
So you will want at least to upgrade to 3.2.z, or use Rails LTS ([2])
[1] http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...
[2] http://railslts.com/
There's at least two books I know of that cover upgrading to rails 4. Here's one: http://www.upgradingtorails4.com/
Full disclosure: I'm friends and work with Andy and he's super smart and I'm not getting a kickback. :)
Full disclosure: I'm friends and work with Andy and he's super smart and I'm not getting a kickback. :)
The intention is for 4.0 to be as close to drop-in as reasonably possible, obviously, if you use some of the removed features, you'll need to add some gems to your gemfile. As is now normal with big Rails releases, 4.0 mostly deprecates, 4.1 will remove.
Nobody wanted a 2 -> 3 transition again.
Nobody wanted a 2 -> 3 transition again.
I did a git branch for my app (https://www.wisecashhq.com/) - in 3 hours or so I was able to pass the tests and run the app properly.
For larger apps (which I maintain as a freelance) I would wait a bit more though, since some gems will still have little bugfixes related to Rails 4 compatibility, most likely.
For larger apps (which I maintain as a freelance) I would wait a bit more though, since some gems will still have little bugfixes related to Rails 4 compatibility, most likely.
Good things rarely come from making radical changes at the last minute.
If you see any failures in the days after upgrading you have a new variable to consider on the cause.
Look at what the best/worst outcomes are from making the change - does the risk justify the benefit?
Would I do it? yes probably, I can't sleep if I'm on a 3 when I know there is a 4 around.
If you see any failures in the days after upgrading you have a new variable to consider on the cause.
Look at what the best/worst outcomes are from making the change - does the risk justify the benefit?
Would I do it? yes probably, I can't sleep if I'm on a 3 when I know there is a 4 around.
I am the same way. I think it is "version OCD". lol
Is there something in Rails 4 that you desperately need? If not, wait. This looks like it will be a smother release than 2.x to 3.x was, but I wouldn't add this variable to the whole process this late in the game.
In the meantime you can watch bug / experience reports and get some info to make an educated decision.
In the meantime you can watch bug / experience reports and get some info to make an educated decision.
This is an awesome achievement.
There are so many improvements to this version that are not immediately visible, but which are maturing Rails in tremendous ways. I think it compares with the release of Mac OS X Snow Leopard (10.6). Especially in the perception on different types of users (experts to consumers).
On a different note, moving from 3.2 can best be done one gem at the time. For instance, implement strong parameters and you're one step closer to Rails 4. https://github.com/rails/strong_parameters
There are so many improvements to this version that are not immediately visible, but which are maturing Rails in tremendous ways. I think it compares with the release of Mac OS X Snow Leopard (10.6). Especially in the perception on different types of users (experts to consumers).
On a different note, moving from 3.2 can best be done one gem at the time. For instance, implement strong parameters and you're one step closer to Rails 4. https://github.com/rails/strong_parameters
So...what have people's experience been in trying to have fat-client-like speed with TurboLinks? Not necessarily with Rails 4.0, but in general? I imagine for some Rails users, the decision is not just whether to go from 2.x/3.x to 4, but whether to go to Sinatra + Backbone/Angular/Ember/etc
The speed improvement from turbolinks can be quite significant. I have an application that was purpose built for pjax and later converted to turbolinks. Page loads are noticeably faster than without turbolinks, and are on the same order as a fat-client application.
The beautiful part is that while writing most code in pure Rails you don't need to think about turbolinks at all - it just comes for free.
BTW, turbolinks is a bit improvement over pjax. It is much simpler (since the whole page is loaded), discouraging some of the complexity that you might be tempted to introduce by pjaxing different parts of the page.
Converting an existing app to turbolinks will take some work, especially with how JS is handled. The key is to run your JS on the turbolinks "page:change" callback and then call the same callback on the initial page load:
The beautiful part is that while writing most code in pure Rails you don't need to think about turbolinks at all - it just comes for free.
BTW, turbolinks is a bit improvement over pjax. It is much simpler (since the whole page is loaded), discouraging some of the complexity that you might be tempted to introduce by pjaxing different parts of the page.
Converting an existing app to turbolinks will take some work, especially with how JS is handled. The key is to run your JS on the turbolinks "page:change" callback and then call the same callback on the initial page load:
$ ->
# Simulate turbolinks page change on document ready.
$(document).trigger "page:change"Does it still break horribly and double-request everything if you have things like <link rel="canonical"> in your website?
I don't know when it was doing that, but the current version of Turbolinks only seems to affect the Asset Pipeline. It doesn't do anything to random link tags on your page. I specifically checked a page with rel="canonical" and Turbolinks only made one request.
Last I looked at it, Turbolinks parsed the <head> section of the incoming request to see if any assets (which was basically...count the script/link nodes) changed. If they did, it went ahead and redirected to the requested URL, since it couldn't be sure that assets hadn't changed.
This meant that anything page-specific in your <head> caused Turbolinks to double the work your app had do to, and provided no positive benefit at all.
I'll check and see how it's behaving now.
Edit: Looks like concerned assets are now tagged with a data attribute. Glad that's in there now.
This meant that anything page-specific in your <head> caused Turbolinks to double the work your app had do to, and provided no positive benefit at all.
I'll check and see how it's behaving now.
Edit: Looks like concerned assets are now tagged with a data attribute. Glad that's in there now.
You're taking a lot for granted if you think Sinatra can act as a replacement to the Rails backend (security, helpers, etc).
Even if your UI is all in JS, Rails still saves a ton of work as an API server compared to Sinatra.
Any examples? My experience with Rails and Sinatra on a daily basis for the last two years has proven the exact opposite.
That's definitely a decent list, but the problem for me is that you are also forced to have EVERYTHING ELSE! It's all nicely required in the for you in your app and there aren't straightforward ways to remove 90% of the stuff you don't want.
I work with rails every day for the last 6+ years and it was a revelation when I started. Now I still think it works decently well for large web-apps, but it's just grown way to big over the years. Basecamp is awesome and a great proving ground, but I'd wager the vast majority of apps written in RoR come no where close to needing most of what's included today.
I work with rails every day for the last 6+ years and it was a revelation when I started. Now I still think it works decently well for large web-apps, but it's just grown way to big over the years. Basecamp is awesome and a great proving ground, but I'd wager the vast majority of apps written in RoR come no where close to needing most of what's included today.
I'm curious as to why having that stuff available is a bad thing?
memory overhead (both for the machine and human), modifying core classes unnecessarily, complexity of third party software, setting defaults to on that aren't applicable to 90% of apps (see turbolinks which breaks the way the web and browsers work).
I'll admit to being on a hard-core minimalist, simplicity, explicit coding kick recently, so I'm already biased against behemoth frameworks. Rails is wonderful if you need that level of complexity/features. I don't think most apps do and we're "forcing" everyone to write basecamp when that is overengineering for most apps.
I'll admit to being on a hard-core minimalist, simplicity, explicit coding kick recently, so I'm already biased against behemoth frameworks. Rails is wonderful if you need that level of complexity/features. I don't think most apps do and we're "forcing" everyone to write basecamp when that is overengineering for most apps.
I'd add security to that list. Rails' most notorious vulnerability was the result of an on-by-default feature that 90% of developers never even needed. I'm not suggesting that Rails is inherently insecure or that Sinatra/Rack cannot be exploited, but less unnecessary code leaves less potential for vulnerabilities; this is especially true in the Ruby world where many developers are eager to `gem install` anything with a few stars on github.
meh, I'm not convinced. I've written some very complex APIs and sinatra-contrib covers most ancillary needs. I'm not saying Rails is always the wrong choice for an API, but most of the bullet points listed in this guide are covered or unnecessary. If you have tons of sprawling back-end logic that is exposed through your API, Rails makes sense, but time and time again I've seen first-hand how much more quickly Sinatra gets us up and going and it's always less work for new developers to grok the application flow.
After looking over the changelog and doing a little research: it seems like this Turbolinks thing is now default-on for Rails 4.
This screws up the normal .ready() stuff, right? Has this bitten anyone yet?
This screws up the normal .ready() stuff, right? Has this bitten anyone yet?
Yes, Turbolinks is included by default, but it's really easy to not use if you don't want to: http://blog.steveklabnik.com/posts/2013-06-25-removing-turbo...
Right, this is good--but are fears of mysteriously-breaking javascript depending on the ready event unfounded?
By 'the ready event' I'm assuming you mean the onload event. Those will break, you need to update them to listen to the 'page:ready' event instead.
The Turbolinks README has everything you need to do to make your applications ready, if you choose to use it: https://github.com/rails/turbolinks#turbolinks
The Turbolinks README has everything you need to do to make your applications ready, if you choose to use it: https://github.com/rails/turbolinks#turbolinks
If you're using jquery, then there is already a gem for that: jquery-turbolinks (https://github.com/kossnocorp/jquery.turbolinks)
jquery-turbolinks as a drop-in fix worked great for my application. The only tweaks my own code required at that point were resources I assumed would die and be recreated on the next page load, like doubling up setInterval handles in domready.
Maybe a little off topic... I just started a small project using Angular and Rails, learning both from scratch as I go. I am using Rails as a purely JSON server and handling all the templates in Angular and doing requests over $http. Is it worth using Angular just for the UI niceness and using more of Rails? I need things like authentication and sessions but at its roots it is a single page app. Would any of this new Rails 4 turbolinks stuff help?
If you want to learn Rails, you should choose a project that will teach you Rails. If all you're going to do with it is serve up JSON, then you're not really going to learn anything and will needlessly overcomplicate your app. Just use something like Sinatra in this case, Sinatra will get out of your way and allow you to focus on the front-end.
Using Angular with Rails is definitely a Good Thing(TM), but you really need a large enough project to justify, something both front- and back-end heavy. My current project is large enough to benefit from both, but unfortunately, I chose jQuery and Sinatra. Feeling the pain, for sure.
Using Angular with Rails is definitely a Good Thing(TM), but you really need a large enough project to justify, something both front- and back-end heavy. My current project is large enough to benefit from both, but unfortunately, I chose jQuery and Sinatra. Feeling the pain, for sure.
There is waaaay more to Rails than the view layer. If 'all you're going to do is serve up JSON', then you'll be using a very large amount of Rails: https://github.com/rails-api/rails-api#why-use-rails-for-jso...
Hmm. Thanks for this.
The Rails-API project is here to help! http://github.com/rails-api/rails-api
I don't personally know of anyone using Angular + Turbolinks, so I can't answer that.
I don't personally know of anyone using Angular + Turbolinks, so I can't answer that.
Thanks, I'm building Angular.js app and adopting Rails 4 for api backend, Will Rails-API be updated for Rails 4 ?
It should work today. If it does not, it's a bug.
By the way, ActiveModel::Serializers is part of the Rails API project[1], and we'd love some thoughts on how to make it work well with Angular.
1: https://github.com/rails-api/active_model_serializers
By the way, ActiveModel::Serializers is part of the Rails API project[1], and we'd love some thoughts on how to make it work well with Angular.
1: https://github.com/rails-api/active_model_serializers
The only issue that's been biting me when using ActiveModel::Serializers and AngularJS is that we must manually return the json with the root: false option set, otherwise the AngularJS $resource provider doesn't work correctly.
If it helps you can make that the default for all your serializers, by doing something like this in an initializer:
ActiveSupport.on_load(:active_model_serializers) do
ActiveModel::ArraySerializer.root = false
ActiveModel::Serializer.root = false
endLooks like it already is: https://news.ycombinator.com/item?id=5940484
Wow that looks great. Are there any benchmarks as to how much faster it is compared to a vanilla Rails app?
It's difficult to benchmark, to be honest: Rails apps depend on so many things, there are too many variables. I'd love to hear from some people who have tried it in their apps though!
I'm more interested in it as a place to explore best practices and work on useful things around names, than the speed aspects.
I'm more interested in it as a place to explore best practices and work on useful things around names, than the speed aspects.
Darn. I bought Crafting Rails Applications in paperback three months ago :(
On another note, I've been using Rails4 beta and RCs at home for the past couple months and it has been a joy. At work I've also been working on a Rails 3.2 app and incorporating routing_concerns and strong_parameter gems. I think upgrading from Rails 3 to 4 apps won't be as drastic as upgrading from Rails 2.x to 3 apps was (curse you asset pipeline!)
On another note, I've been using Rails4 beta and RCs at home for the past couple months and it has been a joy. At work I've also been working on a Rails 3.2 app and incorporating routing_concerns and strong_parameter gems. I think upgrading from Rails 3 to 4 apps won't be as drastic as upgrading from Rails 2.x to 3 apps was (curse you asset pipeline!)
There's a new edition of that out November:
http://pragprog.com/book/jvrails2/crafting-rails-4-applicati...
http://pragprog.com/book/jvrails2/crafting-rails-4-applicati...
I've been looking forward to this for a long time. Congrats to the Rails team!
Now I just need a good book on Rails 4.0 or for Michael Hartl to update the Rails tutorial.
Now I just need a good book on Rails 4.0 or for Michael Hartl to update the Rails tutorial.
He has already updated it, not sure if it is the final version yet: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book?ve...
Yea I've seen that but I don't want to start until I know it accounts for the final version of 4.0. When he first released it for 4.0 beta, there were major inconsistencies between that and one of the release candidates.
I've been going through the Rails 4.0 beta book over the past week or two. I'm just over 50% of the way through and have done all the optional exercises too. So far, I've not found a single problem.
Have you considered "The Rails 4 Way"?
When it's finished, I'm a fan of Rails 3 Way
Thanks to all the committers and releasers involved. The countdown to Rails 5 has begun :D
4.1 :)
Just wanted to point out this great resource for upgrading: http://railsdiff.org
It diffs the initial 'rails new' project between any two versions.
It diffs the initial 'rails new' project between any two versions.
I have been using 4.0.0.rc1 for about a month now and have enjoyed the process. There have been a lot of great updates since the previous versions.
I will caution all to be aware of the turbolinks included by default. I spent a while scratching my head why a setTimeout function worked every so often. I had no prior experience with turbolinks or the discussion thereof, though I believe it's a great feature.
I will caution all to be aware of the turbolinks included by default. I spent a while scratching my head why a setTimeout function worked every so often. I had no prior experience with turbolinks or the discussion thereof, though I believe it's a great feature.
The russian doll cache looks awesome, but I'm a bit worried about this bit in dhh's explanatory article :
> The beauty of that system is that you just don’t care. Memcached will automatically evict the oldest keys first when it runs out of space
Well, I do care : I use redis as cache backend. I guess it will not be as simple as that.
> The beauty of that system is that you just don’t care. Memcached will automatically evict the oldest keys first when it runs out of space
Well, I do care : I use redis as cache backend. I guess it will not be as simple as that.
To answer myself : it's possible to use a maxmemory-policy=volatile-ttl directive to tell redis to remove older keys. Problem is, it's not reliable at all : it will actually take a bunch of unpredictable keys and remove the oldest in the set.
http://stackoverflow.com/questions/9010789/configuring-redis...
I currently empty redis cache on each deployment, so that's not really a problem, but it will be when I use a less naive cache invalidation on code update (and I'm pretty sure some of you are).
So, we'll probably have to take a look in rails cache internal and force sweeping when computing a new key (this will not be a major problem on redis, since it supports wildcards in key names).
http://stackoverflow.com/questions/9010789/configuring-redis...
I currently empty redis cache on each deployment, so that's not really a problem, but it will be when I use a less naive cache invalidation on code update (and I'm pretty sure some of you are).
So, we'll probably have to take a look in rails cache internal and force sweeping when computing a new key (this will not be a major problem on redis, since it supports wildcards in key names).
Is it only me or anyone else facing issue installing the gem?
Getting this error
ERROR: While executing gem ... (Gem::RemoteFetcher::UnknownHostError) no such name (https://rubygems.org/gems/actionpack-4.0.0.gem)
Edit: Now it is working :)
ERROR: While executing gem ... (Gem::RemoteFetcher::UnknownHostError) no such name (https://rubygems.org/gems/actionpack-4.0.0.gem)
Edit: Now it is working :)
Trying to download the latest Agile Web Dev w/Rails from PragProg and just get the error, "File is not ready yet". On two separate accounts.
Also, this post describes today's book release as the "final" version, but the PragProg changelog calls it Beta 4.0.
Also, this post describes today's book release as the "final" version, but the PragProg changelog calls it Beta 4.0.
Congrats to the team on a great release.
I'm curious how does this affect the rails-api project?
I'm curious how does this affect the rails-api project?
It should work today, as we've been tracking edge Rails for a while. If it does not, that's a bug. Please file an issue if you find anything.
A question: Could someone tell me which types of application does Rails 4.0 solve, but the older versions couldn't ? In general, which types of application could not be solved by Rails 4 ? Thank you.
I'm basing this on what I've read, and my experience with Rails 3, so take it with a grain of salt. The type of application you couldn't do in the older one? Easy single-page apps. Of course you COULD do it, writing your own JavaScript or CoffeeScript. But Turbolinks and the Russian Doll caching give Rails 4 a way to get much of the speed of those custom-written apps and yet stay in Ruby/Rails.
I don't know of any type of application that Rails 4 CAN'T do, but it's still Rails and Ruby, so anything computationally intense would probably be better served (ha!) by a Java (or Go, or Scala, or...) framework. The further you get from a CRUD app, the less useful the Rails framework becomes.
I don't know of any type of application that Rails 4 CAN'T do, but it's still Rails and Ruby, so anything computationally intense would probably be better served (ha!) by a Java (or Go, or Scala, or...) framework. The further you get from a CRUD app, the less useful the Rails framework becomes.
Has anyone read any of the books mentioned in the link (or Rails 4 in Action)? Any recommendations for someone that is intermediate in Rails 3, but would like to become more advanced?
The Rails 3/4 Way by Obie Fernandez was really helpful to me. It's more of a cookbook or reference guide that really deep dives into each aspect of Rails.
Definitely not a good choice for 1st Rails book though.
Another recommendation for it below from jherdman & jazearbrooks.
Definitely not a good choice for 1st Rails book though.
Another recommendation for it below from jherdman & jazearbrooks.
The Rails 3 Way was the book that cracked it for me. Hartl's tutorial is a great start, but Obie's was the book that actually hit the 'why' on the head.
I've used Rails 4 in Action. It's in beta right now and definitely has a few problems. However, I believe Steve Klabnik has recently taken over updating the book, so hopefully things will start to come together soon.
Yup! I'm in charge these days.
I've updated the first half of the book, though the forums say there's still a few typos and such that made it through so far. I'm working on the second half now.
I've updated the first half of the book, though the forums say there's still a few typos and such that made it through so far. I'm working on the second half now.
I've read the updated chapters. Love it so far.
It'll be interesting to see how if and how you introduce concerns. So far I've seen no best practices on this. Just an empty directory created.
I personally do not think that Concerns are a good idea, so I probably will not include anything about them. I wrote a blog post a while back: http://blog.steveklabnik.com/posts/2012-05-07-mixins--a-refa...
Is there anything else Rails can do? I can only think of a unified queuing API (which was scheduled by dropped from this release). Has Rails reached feature completeness?
Try doing WebSockets in a Rails app for example. Rails was born in an age of request/response and sometimes it shows. And I say that as a Rails enthusiast.
Ya. I'd like to see better support for that. The problem is the ruby/javascript bridge.
Fukuyama, is that you? http://en.wikipedia.org/wiki/The_End_of_History_and_the_Last...
[deleted]
Great work guys. It shows.
The latest rewrite of my book for Rails 4 is available at http://leanpub.com/tr4w
Michael Hartl's Rails Tutorial has also been fully updated. See http://news.railstutorial.org/ruby-on-rails-tutorial-rails-4... for all links to relevant material.