Rails 5.0.1 has been released(weblog.rubyonrails.org)
weblog.rubyonrails.org
Rails 5.0.1 has been released
http://weblog.rubyonrails.org/2016/12/21/Rails-5-0-1-has-been-released/
56 comments
TLDR: Definitely worth upgrading.
Approximately hundreds of small bug fixes, across much of Rails. The fixes include some important ones for database types, time comparisons, thread issues, record reloading, etc.
IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.
Thanks to all the contributors for excellent work on this release.
Approximately hundreds of small bug fixes, across much of Rails. The fixes include some important ones for database types, time comparisons, thread issues, record reloading, etc.
IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.
Thanks to all the contributors for excellent work on this release.
> IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.
That has been the reason I always avoid huge frameworks like RoR.
If I was to hit a bug like this, I wouldn't know where to start debugging. How do people deal with obscure bugs in the framework with something like RoR?
That has been the reason I always avoid huge frameworks like RoR.
If I was to hit a bug like this, I wouldn't know where to start debugging. How do people deal with obscure bugs in the framework with something like RoR?
You start by boiling it down to an executable test case, for which there are templates here here:
http://guides.rubyonrails.org/contributing_to_ruby_on_rails....
Then you share the test case in a bug report, and collaborate to fix it. Fixing it usually involves a source code dive.
With Rails's reasonably well documented and reasonably well written codebase it's usually possible to grok the source and dependencies even coming to it cold. With the possible exception of arel.
Ruby's dirty tricks department (monkey-patching third-party objects) and duck typing together are a real boon to debugging.
Then you share the test case in a bug report, and collaborate to fix it. Fixing it usually involves a source code dive.
With Rails's reasonably well documented and reasonably well written codebase it's usually possible to grok the source and dependencies even coming to it cold. With the possible exception of arel.
Ruby's dirty tricks department (monkey-patching third-party objects) and duck typing together are a real boon to debugging.
Nice, thanks. Pretty impressive documentation.
Seeing the praise it gets here, I will definitely give RoR a chance for my next side-project. Thanks again.
Seeing the praise it gets here, I will definitely give RoR a chance for my next side-project. Thanks again.
I think you will like it!
Github, Shopify, AirBnB, Indiegogo, Kickstarter, Twitch, Zendesk and many others run on Ruby on Rails. You'll be in good company!
Github, Shopify, AirBnB, Indiegogo, Kickstarter, Twitch, Zendesk and many others run on Ruby on Rails. You'll be in good company!
Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.
That's a separate statement, and they are not contradictory.
Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon.
The grandparent didn't claim the former to be false, only the later to be true.
Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon.
The grandparent didn't claim the former to be false, only the later to be true.
This is a correct reading of my remark. I happen to agree with the opinion of the followup as well, monkey-patching in production is a code stench.
Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
Once you understand how it all works, I'll grant that that can take years, it doesn't take much time at all to debug upstream code. Just last night I was playing around with the jsonapi-resources gem, and found an issue that was keeping me from being able to dynamically generate resources. After realizing I couldn't work around the issue through more metaprogramming, I set about monkey-patching the code.
It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself.
Ruby is definitely wizardry but it's accessible wizardry.
It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself.
Ruby is definitely wizardry but it's accessible wizardry.
i think different areas of Rails codebase vary here, some are pretty legible, some less so.
They probably do it with all the spare time they have from using a framework to handle so many other features.
If you are lucky enough to hit it during development or testing, then yes, fair point.
If you hit however in production and only under load or some corner cases, it must be a real bitch to try to debug code that you haven't wrote yourself.
But since my original post is being seen as a troll, I think I will just shut-up and go hide under a rock or something. :D
If you hit however in production and only under load or some corner cases, it must be a real bitch to try to debug code that you haven't wrote yourself.
But since my original post is being seen as a troll, I think I will just shut-up and go hide under a rock or something. :D
Definitely not a troll I think. I guess downvoted because of disagreement.
I'll also try to explain why:
A few weeks later I have forgotten the specifics about my own code as well.
Also: often there are fewer bugs in library code.
And: getting help (paid or through stackoverflow) is probably easier.
I'll also try to explain why:
A few weeks later I have forgotten the specifics about my own code as well.
Also: often there are fewer bugs in library code.
And: getting help (paid or through stackoverflow) is probably easier.
> I guess downvoted because of disagreement.
Fair enough :D
> A few weeks later I have forgotten the specifics about my own code as well.
> Also: often there are fewer bugs in library code.
> And: getting help (paid or through stackoverflow) is probably easier.
I can definitely see your point, especially about being easier to get help. I imagine if you are anything other than a one man shop, you will be in much better position debugging Rails or Django, rather than trying to figure out the mess you ex-employee left.
Fair enough :D
> A few weeks later I have forgotten the specifics about my own code as well.
> Also: often there are fewer bugs in library code.
> And: getting help (paid or through stackoverflow) is probably easier.
I can definitely see your point, especially about being easier to get help. I imagine if you are anything other than a one man shop, you will be in much better position debugging Rails or Django, rather than trying to figure out the mess you ex-employee left.
> That has been the reason I always avoid
> huge frameworks like RoR.
Finding bugs for something you wrote yourself is easy because you WROTE it and can easily reason about what each method does, what data/methods does it have access to etc. etc.
Anyways, I unfortunately work with Rails and I hate it. To me Rails stresses and encourages bad practices, everything has an implicit environment inherited from a massive hierarchy of classes with their own implicit environment that will only work if the current state of the app matches what each classes assumes it will be.
Data changes and morphs during the initialization and creation of class instances causing shitty bugs. EVERYTHING needs careful consideration of all of these relations and class hierarchies before writing simple things.
Everything is highly coupled and interwoven making a change one place break something somewhere else. Rails should be taught in Universities as a case study in the pitfalls of Object Oriented Design
Also essentially all of the major players have left and moved on to new things. Most Ruby Gems haven't been updated in years!
Anyways, I unfortunately work with Rails and I hate it. To me Rails stresses and encourages bad practices, everything has an implicit environment inherited from a massive hierarchy of classes with their own implicit environment that will only work if the current state of the app matches what each classes assumes it will be.
Data changes and morphs during the initialization and creation of class instances causing shitty bugs. EVERYTHING needs careful consideration of all of these relations and class hierarchies before writing simple things.
Everything is highly coupled and interwoven making a change one place break something somewhere else. Rails should be taught in Universities as a case study in the pitfalls of Object Oriented Design
Also essentially all of the major players have left and moved on to new things. Most Ruby Gems haven't been updated in years!
> Because alternative is to hunt obscure bugs in the framework you built yourself.
That's a false dichotomy, there are also smaller frameworks available.
That's a false dichotomy, there are also smaller frameworks available.
Appreciating the sentiment, I would like to add that a great framework builds a great community around itself, which helps (A LOT) sort out (in the worst case work around) all sorts of issues. And this holds for Rails.
These are bugs from the 5.0.0 release. I can't really think of a time where Rails itself cause issues in my day-to-day (other than missing a timezone which was something I could easily fix).
Because small frameworks don't have bugs, right?
One of the best (or worst) bugs fixed was the aborted transaction for PGsql. I am pretty sure hundreds of Rails developers are battling it every day and don't understand where it's coming from.
Even if you don't upgrade, this is something you should backport using a monkeypatch.
Even if you don't upgrade, this is something you should backport using a monkeypatch.
I think that might be a 5.0.0 change, not a 5.0.1 change, if you're referring to:
> Restore aborted transaction state when disable_referential_integrity fails due to missing permissions.
> Restore aborted transaction state when disable_referential_integrity fails due to missing permissions.
Do you have a link to that?
> Approximately hundreds of small bug fixes, across much of Rails
Bugs from 5.0.0 or from 4.whatever? If it's the latter then bug fixes should be going there, not in a new major release.
Bugs from 5.0.0 or from 4.whatever? If it's the latter then bug fixes should be going there, not in a new major release.
This is 5.0.0 -> 5.0.1
(there is a separate branch for 4.x.y releases, but that's only security patches nowadays)
(there is a separate branch for 4.x.y releases, but that's only security patches nowadays)
If anyone's been holding off on upgrading to 5.x because of the deprecation warnings you get about requiring `params` as w keyword argument in keyword tests, I wrote a gem that could help: https://github.com/tjgrathwell/rails5-spec-converter
This is awesome.
Are there other gems and resources available for accelerating the migration from 4 to 5? Been thinking about doing it for a project for a little while.
Are there other gems and resources available for accelerating the migration from 4 to 5? Been thinking about doing it for a project for a little while.
Slightly off-topic: is learning Rails still a good career choice? I'm not particularly keen on JavaScript on the server and I think I am slightly tired using .NET on a daily basis.
It's worked out well for me. I started picking it up almost 2 years ago and I make more than I ever did before. Where I work we are always advertising for Senior Rails Devs.
There are plenty of stable companies out there running Rails apps and I'd venture a guess that a lot of start-ups probably still use it as it's great for small teams and rapid-prototyping.
On a side note, we also have hired devs who don't have Ruby experience but who are generally smart, experienced people, who know more than one programming language and are willing to learn whatever stack they need to for getting the job done.
There are plenty of stable companies out there running Rails apps and I'd venture a guess that a lot of start-ups probably still use it as it's great for small teams and rapid-prototyping.
On a side note, we also have hired devs who don't have Ruby experience but who are generally smart, experienced people, who know more than one programming language and are willing to learn whatever stack they need to for getting the job done.
Where I'm from (Toronto, Canada), Rails development pays significantly more than any other stack and there is substantially more work available.
I'd love to DM you with some questions about Toronto. Can you ping me via my profile info?
Same here, on the other side of the country.
In Bangkok the demand for Rails developers is as strong as ever. With enough experience you will have no problem finding a job that pays better than other stacks. There are a number of companies like ours that'd be happy to help you with visa if you're willing to relocate. Happy to answer any questions! (contact info under my profile)
In Northern Europe the demand is high too. Would definitely recommend it!
If anyone is using Rails together with Docker, I just updated orats[1] to use Rails 5.0.1.
[1]: https://github.com/nickjj/orats
[1]: https://github.com/nickjj/orats
How is Rails still doing in the world of NodeJS, Microservices and React?
In the world of Hype, I still use Ember at the frontend and Rails API at the backend.
Why use js in the backend if you don't have to? It's hard to read, maintain, and debug.
pretty well actually. not much hype or talks about it anymore, but it's still used to get the job done.
react-rails is really good.
react_on_rails is even better.
Not really. Depends completely on what you need. Not integrating with your existing asset pipeline isn't necessarily a plus depending on what your goals are.
There's also a weird amount of self promotion going on with that repo. Not sure what it is about that but it's kind of been a turn off to me.
There's also a weird amount of self promotion going on with that repo. Not sure what it is about that but it's kind of been a turn off to me.
Its not so different from thoughtbot's repos, just a different personality.
[deleted]
Anyone have a tl;dr?
The changelogs on the point releases for each gem are essentially TL;DRs. It took ~10 minutes to read through all of them. The meatiest one is probably ActiveRecord: https://github.com/rails/rails/blob/v5.0.1/activerecord/CHAN...
JQuery is not by default anymore.
Updated and testing...
Thanks!
Thanks!
Updated and testing.
Thanks!
Thanks!
We contacted the Rails team early on about this issue and worked closely with them to have this issue solved. Now that 5.0.1 is released we are at liberty to disclose details about this security issue.
I've written a blog post[2] on the problem, using OS X network shaping tools and a simple app to demonstrate it. Rails apps running on Passenger were never affected as Passenger implements response buffering for regular requests as well as websockets connections. Note that even popular reverse proxies like Nginx don't perform response buffering for websockets as far as I know, so this is something to be aware of if you're running on other frameworks than Rails as well.
[0] GH merge of patch: https://github.com/rails/rails/pull/26646
[1] GH related issue: https://github.com/rails/rails/issues/26409
[2] Blog post: https://blog.phusion.nl/2016/12/21/actioncable-under-stress-...