I've been watching refactoring in Ruby for quite a while and have long believed that while tools would be nice, Ruby itself made refactoring (and other things) pretty easy. (You can read a bit about that here.) I've also mentioned that this might be the year we get some real refactoring tools. It looks like I might be right.
Martin Fowler wrote an article called The Refactoring Rubicon. He suggested that there are a lot of 'toy' approaches to refactoring built atop regular expressions, but that these will fall over pretty quickly. It's only once you start analyzing the parse tree of a program that you get ability to handle significant refactorings. The simplest refactoring that requires this kind of peeking under the hood is Extract Method, and this is Martin's 'Rubicon'.
Smalltalk crossed the Rubicon long ago. Java crossed it in 2001. And now, Ruby's finally crossed it as well. Jon Tirsén wrote about Ruby crossing the Rubicon. Surprisingly, this advance didn't come out of the Ruby or Smalltalk worlds, it came out of the Java world.
Perhaps, it shouldn't be such a shock. The loudest cries for tools like this have always come from Rubyists with a Java background. Now that JRuby is pushing Ruby deeper into Java-land, it's only natural to see some of the good ideas from the Java community starting to leak into the Ruby community too. It'll be interesting to see what shows up next.
 Well, rrb (the Ruby Refactoring Browser) sort of crossed it a couple of years ago,
but it was using regular expressions (the regexps that I remembered dealing with were all in the elisp interface to emacs), and wasn't foolproof in its approach (it had a hard time dealing with Extract Method when working with class methods, see bug # 2507) , so I don't think it counts.