Hacker News Reader

Comment by ludicast | Hacker News Reader

The article brings up a great point wrt XSS. I'd say the new XSS stuff was responsible for 2/3 of the upgrade-errors my automated testing didn't catch, so pre-fixing this like they did would have had big rewards. But I was too impatient so after the upgrade I let my client feedback cover the edgecases :).

I'd actually say upgrading to Ruby 1.9.2 gave me more headaches than upgrading Rails.

View on HN

Cool that you managed to upgrade to 1.9.2. The encoding issues have us scared. We do have a few special purpose webapps that run 1.9.2 because of very high performance requirements.

The encoding issues bit me in a few places (especially with paperclip), and I have some hacky initializers running that monkeypatch a few libraries to behave well enough.

I'm knee deep in encoding hell right, I'd love to hear more about how you patched it to work with 1.9.2

You can fix most encoding problems with doing

  Encoding.default_internal = Encoding.default_external = "UTF-8"

but as JEG states in http://blog.grayproductions.net/articles/ruby_19s_three_defa..., this throws warnings and may still not fix things.

Encoding issues rank up there with Array.to_s pains when moving to 1.9

Ha! Glad to know I'm not the only one hitting the Array.to_s surprise!

My favorite issue in 1.9.2: "." is no longer included on the $LOAD_PATH.

Why aren't you on jruby if you have serious performance requirements? A sufficiently warmed-up jvm will outpace 1.9.2

with shopify's code size jruby needs 2gb of memory per process and we found that it spends almost all the time in GC.

which version of jruby? is 2gb per process an issue if you can run it multithreaded?

Reply on news.ycombinator.com