296 commits for a security patch is silly; What the shit tenderlove.
Rails 3.2.13 - Performance regressions and major bugs
31–40 of 76 posts
Re: Rails 3.2.13 - Performance regressions and major bugs
#32Earlier quoted context omitted.
How is this > […] handing that task to Sprockets instead of resolving internally […] even remotely related to performance issues because of random routing? You're mixing two issues that have nothing in common.
1) Grandparent has performance problems on Heroku. 2) The Rails release has performance regressions (i.e. in at least some scenarios is slower). In situation (1) you don't want to add further slowdown so (2) is a bad thing. Grandparent doesn't even blame his Heroku performance problems on the routing issue (although it is a plausible guess). Actually effect of the routing problem can be significantly worsened if even…
I'm under the impression that the Sprockets regression should not affect you in production, because your assets are precompiled.
Is that not the case?
Re: Rails 3.2.13 - Performance regressions and major bugs
#33At this point I'm seriously considering dropping Rails as my framework of choice and reverting back to ASP.Net MVC. Why? 1. Security fixes are released very quickly (good thing), but more often then not they break existing code (bad thing) - and while you _can_ wait for the next patch to fix those break points, you're left wide open since everybody can see what was broken and how to exploit it. 2. I'm not nearly smar…
You are now in the place I was recently -- the decision we tool was to migrate onto Python and their web ecosystem. We haven't looked back since -- well, we have given an glance or two back since, and viewing the slow-motion car crash that is Rails today, we just feel sorry for those left behind that are discovering 'The Rails Way'. Ironically, given DHH's comment on Rails about it being 'Omakase', I should point out…
[deleted]
Re: Rails 3.2.13 - Performance regressions and major bugs
#34Earlier quoted context omitted.
You do know there are other Ruby frameworks than Rails, and other development environments than ASP and Ruby right?
Yes, I used to use ASP.Net MVC for pet projects, then switched to Rails - I also use CakePHP and Django for actual paying work/contracting. But thanks for the passive aggresive comment.
> Yes
Because your comment didn't exactly hint at it considering its completely binary assertion of "Rails or ASP"
> But thanks for the passive aggresive comment.
I'm very sorry you found it passive, that was not intended.
Re: Rails 3.2.13 - Performance regressions and major bugs
#35Earlier quoted context omitted.
The point is, SO almost certainly aren't using vanilla ASP.net. Nobody can succeed for too long without maintaining and cultivating their stack.
I don't know about Vanilla ASP.NET but they are pretty much using stock config'd IIS and Servers. So I would be very surprised if they weren't using stock ASP.NET (with their own filters, etc using public APIs I'm sure)
Forgive me, I'm not an MS person, but is there no opportunity to augment/customise/replace/mix-and-match/etc the ASP.net components?
From what I've read on http://highscalability.com and the like, they love to tweak.
Re: Rails 3.2.13 - Performance regressions and major bugs
#36Earlier quoted context omitted.
Wow, you're either one of those incredibly rare ruby devs who actually run windows, or you're going to switch your entire environment in order to switch frameworks. Something doesn't smell right
I'm a polyglot. I don't encase myself in any 1-thing. I use Mac at work, Windows at home for media and games, and Linux Mint 13 on my laptop for Ruby/Rails. I only used Linux because of Rails, but since I'm switching back (I have Visual Studio 2012 downloading as I type this), I'll have no need for Linux on my end-user machines anymore.
If you do not know your language/framework well enough to adapt it to your circumstances, you certainly are not well qualified enough with said software to list it as something you "know".
This is one of the largest lies perpetuated on this site. If you know just enough of something to follow some tutorials and crank out cookie-cutter sites using Rails/Django/Asp/Grails/CodeIgniter/etc, but fail the moment you encounter basic ecosystem problems, you aren't a polygot. You're a liability to your team for not understanding anything well enough to work around common issues. You're probably curious and love to try new things, but the implied part of being able to proficiently wield whatever tool is correct, or at least on hand, is something escaping you.
If by polygot you mean you know some syntax, the basics of the ecosystem, and generic system design, algorithms, etc while expecting to dive as deep as necessary into any given environment, you're still failing the definition. This would be the point where you RTFS so you know where to override/monkeypatch/workaround.
Re: Rails 3.2.13 - Performance regressions and major bugs
#37Earlier quoted context omitted.
Wow, you're either one of those incredibly rare ruby devs who actually run windows, or you're going to switch your entire environment in order to switch frameworks. Something doesn't smell right
I'm a polyglot. I don't encase myself in any 1-thing. I use Mac at work, Windows at home for media and games, and Linux Mint 13 on my laptop for Ruby/Rails. I only used Linux because of Rails, but since I'm switching back (I have Visual Studio 2012 downloading as I type this), I'll have no need for Linux on my end-user machines anymore.
[deleted]
Re: Rails 3.2.13 - Performance regressions and major bugs
#38At this point I'm seriously considering dropping Rails as my framework of choice and reverting back to ASP.Net MVC. Why? 1. Security fixes are released very quickly (good thing), but more often then not they break existing code (bad thing) - and while you _can_ wait for the next patch to fix those break points, you're left wide open since everybody can see what was broken and how to exploit it. 2. I'm not nearly smar…
You're on the cutting edge of an extremely popular framework.
If you want, you're welcome to use Rails 2.3 or older and you'll encounter many fewer changes. I imagine the 3.0 branch will have much the same stability once major development moves to 4.0.
Re: Rails 3.2.13 - Performance regressions and major bugs
#39Earlier quoted context omitted.
1) Grandparent has performance problems on Heroku. 2) The Rails release has performance regressions (i.e. in at least some scenarios is slower). In situation (1) you don't want to add further slowdown so (2) is a bad thing. Grandparent doesn't even blame his Heroku performance problems on the routing issue (although it is a plausible guess). Actually effect of the routing problem can be significantly worsened if even…
I'm under the impression that the Sprockets regression should not affect you in production, because your assets are precompiled. Is that not the case?
To be honest I don't know and I wouldn't have negatively responded to a comment indicating that or questioning it. However reading the article it sounds like it is an issue resolving asset paths so may affect you even when assets are precompiled.
Performance Regressions
There are performance regressions in 3.2.13 for both view loading and asset loading. Rails 3.2.13 changed the way assets paths are resolved, handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues.
Re: Rails 3.2.13 - Performance regressions and major bugs
#40Not happy? Do something about it: try release candidates, report bugs, and help triage and fix reported bugs.
Ok, yes, that's an extremely great and open-source way to handle this.
But seriously, can we at least expect moderately stable releases? I do not think that's too much to ask, especially for a framework which has, in the past, achieved that.