Lessons Learned Upgrading Harvest to Ruby 1.9.3 | Hacker News Reader

Lessons Learned Upgrading Harvest to Ruby 1.9.3

techtime.getharvest.com

A thing that I noticed in this post: some changes relate to "improper usage". Yes, Array#to_s did perform a join, but it was never the method intended to do a join - thats #join. This should never be done in the first place. Use the tools that are meant for the job, even if the other is more convenient (although I never understood this specific case, I always used #join). It will bite you if you don't. Another example was using #map without block as a #to_a alternative (which now returns an Enumerator).

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...

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

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:

    "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.

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!

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

Reply on news.ycombinator.com