296 commits for a security patch is silly; What the shit tenderlove.
Seriously. Usually Rails feels like riding in an Uber, but this release felt like Crazy Taxi.
Rails 3.2.13 - Performance regressions and major bugs
41–50 of 76 posts
Re: Rails 3.2.13 - Performance regressions and major bugs
#42You know when you're already having performance issues on Heroku having a performance regression is not fun.
The asset path and sprocket performance hit doesn't seem to affect most Rails apps, they precompile their assets, so that shouldn't be a problem.
But it does slow down dev, which doesn't not suck.
Re: Rails 3.2.13 - Performance regressions and major bugs
#43There's been a few people suggesting that, if you are bitten by a bug, you fix it and submit a pull request. That's a good idea. I did exactly this to a regression introduced in 3.2.9, complete with a unit test and a pull request against 3-2-stable and one against master. It took two months to get anyone to look at it, and while one of the two pull requests has a thumbs-up, it's still not been merged. Admittedly, this isn't a security issue as far as I can see, but still.
Re: Rails 3.2.13 - Performance regressions and major bugs
#44Earlier quoted context omitted.
>If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), of any framework at all. In fact, developing larger more complex software might not even be possible without adapting frameworks for your specific problems. Huh what? Stack Overflow with it's extreme load works quite well with ASP.NET. >try a google search on asp.net…
The point is, SO almost certainly aren't using vanilla ASP.net. Nobody can succeed for too long without maintaining and cultivating their stack.
We're on ASP.NET MVC4, a stock build.
We've configured route registration a little bit specially* to speed up some common cases and we don't necessarily use every feature in the framework; but we're far from a proper fork.
ASP.NET MVC performs well enough that we get more bang from focusing on our own code basically.
*This amounts to registering our highest traffic routes _first_, and checking left-hand matches before Regex'ing (since we have a ton of "/foo/\d+/bar"-ish routes).
Re: Rails 3.2.13 - Performance regressions and major bugs
#45At 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…
I've been running Java and Rails since 2006 in my company (large), we use C# for a small number of desktop applications. This will come out harsh, but I'm being honest: If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), or any framework at all. In fact, developing larger more complex software might not even be possible…
It's really nice being able to trace into the guts of hibernate, spring, etc to see what the heck is actually going on and fix it if it's broken. When I used to do Microsoft stuff, I'd run into bugs in the stack that I couldn't fix. This was enormously frustrating and time wasting. The typical advice given out by support was re-install or buy the latest upgrade. There were also a lot of deliberately imposed architectural limitations to prevent you from working around lack of "enterprise" features in the basic versions which were incredibly frustrating and the enterprise version pricing was astronomical.
Re: Rails 3.2.13 - Performance regressions and major bugs
#46There's been a few people suggesting that, if you are bitten by a bug, you fix it and submit a pull request. That's a good idea. I did exactly this to a regression introduced in 3.2.9, complete with a unit test and a pull request against 3-2-stable and one against master. It took two months to get anyone to look at it, and while one of the two pull requests has a thumbs-up, it's still not been merged. Admittedly, thi…
I personally read every single issue and comment filed against rails/rails. I often don't comment if it's not a part of the codebase I'm not familiar with, and it's the same with merging.
Can you point me to the specific ones so I can look at them again?
Re: Rails 3.2.13 - Performance regressions and major bugs
#47Earlier quoted context omitted.
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…
Actually, the performance degradation to the precompiled assets is minimal - for a typical production environment it only effects your asset compiling time as the assets are served statically from your public directory.
Re: Rails 3.2.13 - Performance regressions and major bugs
#48Earlier quoted context omitted.
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 encoun…
I disagree. I count writing and selling commercial software with said technology as 'knowing' something. Academics be damned.
Re: Rails 3.2.13 - Performance regressions and major bugs
#49As someone who is relatively new to Rails can someone explain to me why it seems to update more than anything else I've used?
You don't have to stay on the bleeding edge. We're stuck with Ruby 1.8.7, and we've got a mix of Rails 1, 2, and 3 apps. For better or for worse.
Re: Rails 3.2.13 - Performance regressions and major bugs
#50I disagree with the final statement of this, that a "security only" release would have somehow helped the situation. I feel like part of the problem is that things are being merged into 3-2-stable and nobody is using them because they're never put into a release.
3.2.11 and 3.2.12 were both security-only releases, and so fixes and patches that were not security-related have just been piling up for the longest time.
Seems like a "release often" mindset might be better and might ensure that things are actually being used. Sure, I know someone is going to blast me saying that bugs like this shouldn't make it into 3-2-stable at all, and since this is Hacker News so whoever says that knows they're ten times the developer that everyone on the Rails core team is. But the reality is that bugs make it into stable branches, and almost nobody is running against the stable branch (Rails core people are probably mostly running against the 4.0 branch, everyone else is running against the latest release).