Lessons Learned Upgrading Harvest to Ruby 1.9.3(techtime.getharvest.com)
techtime.getharvest.com
Lessons Learned Upgrading Harvest to Ruby 1.9.3
http://techtime.getharvest.com/blog/harvest-is-now-on-ruby-1-dot-9-3
4 comments
Does anyone know why String.each was cut? String.each was one of the cool things that attracted me to ruby in the first place. I loved that you could say myString.each and it would assume you meant linebreaks unless you told it some other delimiter.
Strings were revamped in Ruby 1.9 to have more robust support of Unicode and other encodings. One of the side effects is that both the semantics and internal representation of Strings changed such that treating a String object as an Enumerable no longer made sense.
There's a good treatment of this here:
http://blog.grayproductions.net/articles/ruby_19s_string
There's a good treatment of this here:
http://blog.grayproductions.net/articles/ruby_19s_string
Thank you very much. I didn't realize that string handling was changed so much in 1.9. This has got to be one of the best string encoding methods in any programming language to date.
Yeah, but String#each_line was already present in Ruby 1.8, why didn't you use this in the first place? Much clearer meaning and still available. #each is pretty neutral.
Working with Strings is so much better in post 1.8 ruby. Before it was hell with iconv especially for us guys who work primarily with non english languages.
The default splitter for split is newline:
The default splitter for split is newline:
"foo\nbar".split => ["foo", "bar"]
Now possible to get the individual letters as characters in a simple UTF safe way: "foobar".split(//) => ["f", "o", "o", "b", "a", "r"]
I like the stuff that has been done with enumerators, making it possible to map with index etc: "foobar".unpack("U*").enum_for(:each_with_index).map { |x,i| x + i }.pack("U*") => "fpqeew"Good post with some great details. I hope the holdouts on Ruby 1.8.7 REE look carefully at upgrading.
Rails 3.X is still a tough upgrade though. I'd be curious to see similar benchmarks with upgrading a large code base. I've heard a few stories of abandoned upgrades because of the slowness.
Rails 3.X is still a tough upgrade though. I'd be curious to see similar benchmarks with upgrading a large code base. I've heard a few stories of abandoned upgrades because of the slowness.
Ruby 1.9.2 was horribly slow when it came to #require. 1.9.3 is a much better release, especially in that regard.
There's also this for even better performance: https://gist.github.com/2113359
Don't forget to set your envvars!
Don't forget to set your envvars!
noticed a comment about rvm + pow. If anyone is having that issue, I solved it by doing: http://josephhsu.com/post/21386307243/tip-rvm-pow
Also, it shows that a lot of naming problems were actually corrected in the transition to 1.9, like the #type<>#class thing. Less is better and I am grateful that the core team actually made some cuts.
In the end, my personal experience is that upgrading to 1.9 is not that much pain as many say. Sure, for large projects, the work is substantial as an absolute value, but this sounded quite manageable. Sadly, their blogpost on their migration to Rails 3 doesn't mention any numbers in that regard:
http://www.getharvest.com/blog/2011/01/harvest-is-running-ra...