I just finished a much-too-long series of essays on Ruby from a whole bunch of angles, some here might enjoy it: http://www.tbray.org/ ongoing/When/200x/2006/08/17/JRuby
I found it interesting reading. It really felt like early explorations of the language. Here are some random thoughts I had while reading:
* There are multiple places to get XML escaping from the standard library, but since you are familiar with REXML I'll recommend: REXML::Text.normalize("Some & text < foo > \" bar")
* I really like that Ruby leaves the power to decide where to store code in our hands. Just to give random example of how this is cool, I purposefully keep my FasterCSV library in one long source file. When I'm working on some project and need to work with CSV, I drop the file in vendor/ and I'm all set.
* A DSL is slightly more than method calls without parentheses. The idea is to adapt your language to the problem domain, so the solution is very naturally expressed in the language of the problem.
* For markup generation: have you tried Builder?
* The "helper methods" referred to in the quoted Markaby documentation are a Railsism. I suspect that's why you had trouble understanding the quote.
* I mean this in the nicest possible way, of course, but you're dead wrong about that IDE thing. ;) I have a solution for each point you listed in TextMate and I would be shocked if you can't do similar things in emacs (the editor I believe you are using). I'm happy to post them, if there's interest.
* I'm looking forward to your Unicode talk. Just remember to start it with, "Ruby supports Unicode today." ;) It really, really bugs me that everyone claims Ruby has no Unicode support. Don't be like them. As long as you get off to a good start like that, I'll be very interested in the rest of your talk and I won't lead the lynch mod your essay hints at.
What do you do for 'rename method' in TextMate? I'm aware of the search and replace in file feature but I was wondering if there was something better.
Nice write-up by the way. Ruby IDEs might not do all that Eclipse or NetBeans does for Java, but they're not as primitive as Tim made them out to be! I was also surprised that he hadn't tried Builder.
-----Original Message----- From: James Edward Gray II [mailto:ja...@grayproductions.net] Sent: Thursday, September 07, 2006 9:22 AM To: ruby-talk ML Subject: Re: Thousands of words on Ruby
I found it interesting reading. It really felt like early explorations of the language. Here are some random thoughts I had while reading:
* There are multiple places to get XML escaping from the standard library, but since you are familiar with REXML I'll recommend: REXML::Text.normalize("Some & text < foo > \" bar")
* I really like that Ruby leaves the power to decide where to store code in our hands. Just to give random example of how this is cool, I purposefully keep my FasterCSV library in one long source file. When I'm working on some project and need to work with CSV, I drop the file in vendor/ and I'm all set.
* A DSL is slightly more than method calls without parentheses. The idea is to adapt your language to the problem domain, so the solution is very naturally expressed in the language of the problem.
* For markup generation: have you tried Builder?
* The "helper methods" referred to in the quoted Markaby documentation are a Railsism. I suspect that's why you had trouble understanding the quote.
* I mean this in the nicest possible way, of course, but you're dead wrong about that IDE thing. ;) I have a solution for each point you listed in TextMate and I would be shocked if you can't do similar things in emacs (the editor I believe you are using). I'm happy to post them, if there's interest.
* I'm looking forward to your Unicode talk. Just remember to start it with, "Ruby supports Unicode today." ;) It really, really bugs me that everyone claims Ruby has no Unicode support. Don't be like them. As long as you get off to a good start like that, I'll be very interested in the rest of your talk and I won't lead the lynch mod your essay hints at.
On Sep 7, 2006, at 2:11 PM, Molitor, Stephen L wrote:
> What do you do for 'rename method' in TextMate? I'm aware of the > search > and replace in file feature but I was wondering if there was something > better.
First, let me admit this is the point I have the least ideal solution for and I am interested in a Ruby Refactoring library I can wrap in TextMate commands. Remember though, knowing everything about a Ruby script is all but impossible until runtime. Given that, such a library would likely function off of heuristics, and that's about as accurate as...
I use TextMate's Find in Project with a hand rolled regular expression. For your example of a method call I might try something like:
I can sometimes refine that a little depending on my knowledge of the project at hand. I always do a Find first, reality-check the matches, then Replace All. I find this works a very high percentage of the time, though I do make mistakes, of course.
Here are my solutions to the other points:
> There should be a background parser running all the time so > that you always know if you have syntax errors and can jump to them > with one click; it is so totally a waste of time for me to save, > then try to run, a file that the computer is in a position to know > won’t work.
I built a TextMate command scoped to Ruby source with a key equivalent of apple-S that takes the document as input and asks TM to save the current document when triggered. (This essentially overrides Save in Ruby files, performs the Save, and allows me to hook in additional functionality.
I feed the document to `ruby -c`. If it checks out, I display a Syntax OK tool tip (default output for this command). If errors are found, I use the exit_codes.rb support library that ships with TextMate to switch the output to HTML and display hyperlinked-back-to- the-source error messages.
> I shouldn’t have to type the names of well-known methods, > like File.new or (anything).each, or type in closing parentheses or > the keyword end, or fill in more than a couple of characters of > begin/rescue/ensure structures; it is never correct for a human to > hit keys when a computer, in principle, could provide the input.
One word: snippets.
TextMate ships with all the snippets I have written for Ruby and then some.
> I should never have to scroll much; IDEs go to a lot of > trouble to make it trivial to jump from wherever to the source for > the method being called, or its docs, or the next compile error or > breakpoint, or variable declaration, or whatever. Scrolling back > and forth in a source-code file is just stupid.
Apple-T to zoom to the needed file, shift-apple-T to zoom to the needed method. Once you get use to how it matches names you can go anywhere in an instant:
1. apple-T 2. bit-return (takes me to test/functional/beta_invite_test.rb) 3. shift-apple-T 4. teir-return (takes me to test_email_is_required)
> Unit testing should be part of the infrastructure. To create > a test, or run a test, or look at test results, you shouldn’t have > to hit more than one keystroke.
Apple-R to run a test file, or shift-apple-R to run just the current test. Use zentest to auto-generate the tests (you can wrap that in a TextMate command with about three lines of Ruby, if you like).
-----Original Message----- From: James Edward Gray II [mailto:ja...@grayproductions.net] Sent: Thursday, September 07, 2006 3:11 PM To: ruby-talk ML Subject: Re: Thousands of words on Ruby
On Sep 7, 2006, at 2:11 PM, Molitor, Stephen L wrote:
> What do you do for 'rename method' in TextMate? I'm aware of the > search and replace in file feature but I was wondering if there was > something better.
First, let me admit this is the point I have the least ideal solution for and I am interested in a Ruby Refactoring library I can wrap in TextMate commands. Remember though, knowing everything about a Ruby script is all but impossible until runtime. Given that, such a library would likely function off of heuristics, and that's about as accurate as...
I use TextMate's Find in Project with a hand rolled regular expression. For your example of a method call I might try something like:
I can sometimes refine that a little depending on my knowledge of the project at hand. I always do a Find first, reality-check the matches, then Replace All. I find this works a very high percentage of the time, though I do make mistakes, of course.
Here are my solutions to the other points:
> There should be a background parser running all the time so that
> you always know if you have syntax errors and can jump to them with > one click; it is so totally a waste of time for me to save, then try > to run, a file that the computer is in a position to know won't work.
I built a TextMate command scoped to Ruby source with a key equivalent of apple-S that takes the document as input and asks TM to save the current document when triggered. (This essentially overrides Save in Ruby files, performs the Save, and allows me to hook in additional functionality.
I feed the document to `ruby -c`. If it checks out, I display a Syntax OK tool tip (default output for this command). If errors are found, I use the exit_codes.rb support library that ships with TextMate to switch the output to HTML and display hyperlinked-back-to- the-source error messages.
> I shouldn't have to type the names of well-known methods, like > File.new or (anything).each, or type in closing parentheses or the > keyword end, or fill in more than a couple of characters of > begin/rescue/ensure structures; it is never correct for a human to hit
> keys when a computer, in principle, could provide the input.
One word: snippets.
TextMate ships with all the snippets I have written for Ruby and then some.
> I should never have to scroll much; IDEs go to a lot of trouble > to make it trivial to jump from wherever to the source for the method > being called, or its docs, or the next compile error or breakpoint, or
> variable declaration, or whatever. Scrolling back and forth in a > source-code file is just stupid.
Apple-T to zoom to the needed file, shift-apple-T to zoom to the needed method. Once you get use to how it matches names you can go anywhere in an instant:
1. apple-T 2. bit-return (takes me to test/functional/beta_invite_test.rb) 3. shift-apple-T 4. teir-return (takes me to test_email_is_required)
> Unit testing should be part of the infrastructure. To create a > test, or run a test, or look at test results, you shouldn't have to > hit more than one keystroke.
Apple-R to run a test file, or shift-apple-R to run just the current test. Use zentest to auto-generate the tests (you can wrap that in a TextMate command with about three lines of Ruby, if you like).
> I built a TextMate command scoped to Ruby source with a key equivalent > of apple-S that takes the document as input and asks TM to save the > current document when triggered. (This essentially overrides Save in > Ruby files, performs the Save, and allows me to hook in additional > functionality.
>> I built a TextMate command scoped to Ruby source with a key >> equivalent of apple-S that takes the document as input and asks TM >> to save the current document when triggered. (This essentially >> overrides Save in Ruby files, performs the Save, and allows me to >> hook in additional functionality. >> <snip> >> This command is an example in my upcoming book: >> http://www.pragmaticprogrammer.com/titles/textmate/index.html
> Err, oh. I take it that means it'd be too much to ask how you > command TM to save?
The "Save" dropdown menu at the top of the Bundle Editor when you are editing a command. ;)
-----Original Message----- From: James Edward Gray II [mailto:ja...@grayproductions.net] Sent: Thursday, September 07, 2006 4:23 PM To: ruby-talk ML Subject: Re: Thousands of words on Ruby
On Sep 7, 2006, at 3:59 PM, Molitor, Stephen L wrote:
> Fantastic, thanks. One more minor question: what is 'bit-return' and
> I just finished a much-too-long series of essays on Ruby from a whole > bunch of angles, some here might enjoy it: http://www.tbray.org/ > ongoing/When/200x/2006/08/17/JRuby
> -Tim
I would highly recommend autotest, which is part of ZenTest, to take tdd to the next level. Autotest has your desired "one keystroke" beat, as its zero keystrokes to run any test. It monitors your files and automatically runs tests when it sees the tests or related files changed.
I'm using it for rails work and its great. There are some minor annoyances, such as not picking up integration tests or tests in /lib correctly right now, but its not very hard to hack stuff into the source.
> On Sep 7, 2006, at 2:11 PM, Molitor, Stephen L wrote:
>> What do you do for 'rename method' in TextMate? I'm aware of the search >> and replace in file feature but I was wondering if there was something >> better.
> First, let me admit this is the point I have the least ideal solution > for and I am interested in a Ruby Refactoring library I can wrap in > TextMate commands. Remember though, knowing everything about a Ruby > script is all but impossible until runtime.
Brainstorm just happened, so bear with me - this is straight off the top of my head, and may be stupid:
Ok, so it's a real bodge to try to rename a method before runtime. What happens if we annotate the method to be renamed the next time it's run? We could run the script in question under an environment not totally unlike xmp. The first thing it would do is alter the source file according to the annotation. It would then add an appropriate method_missing to Object to do a rename in the original source file whenever the method was called, and then load() the file.
> Ok, so it's a real bodge to try to rename a method before runtime. > What happens if we annotate the method to be renamed the next time > it's run? We could run the script in question under an environment > not totally unlike xmp. The first thing it would do is alter the > source file according to the annotation. It would then add an > appropriate method_missing to Object to do a rename in the original > source file whenever the method was called, and then load() the file.
And what happens if the execution never calls the given method, for whatever reason, or only reaches some of the places it is used?
>> Ok, so it's a real bodge to try to rename a method before runtime. >> What happens if we annotate the method to be renamed the next time >> it's run? We could run the script in question under an environment >> not totally unlike xmp. The first thing it would do is alter the >> source file according to the annotation. It would then add an >> appropriate method_missing to Object to do a rename in the original >> source file whenever the method was called, and then load() the file.
> And what happens if the execution never calls the given method, for > whatever reason, or only reaches some of the places it is used?
That's why you run your test suite through it. You do have 100% line coverage, right? :-)
> James Edward Gray II wrote: >> On Sep 9, 2006, at 9:41 AM, Alex Young wrote: >>> Ok, so it's a real bodge to try to rename a method before >>> runtime. What happens if we annotate the method to be renamed >>> the next time it's run? We could run the script in question >>> under an environment not totally unlike xmp. The first thing it >>> would do is alter the source file according to the annotation. >>> It would then add an appropriate method_missing to Object to do a >>> rename in the original source file whenever the method was >>> called, and then load() the file. >> And what happens if the execution never calls the given method, >> for whatever reason, or only reaches some of the places it is used? > That's why you run your test suite through it. You do have 100% > line coverage, right? :-)
Well it's a clever idea. Show us the prototype. ;)
>> James Edward Gray II wrote: >>> On Sep 9, 2006, at 9:41 AM, Alex Young wrote: >>>> Ok, so it's a real bodge to try to rename a method before runtime. >>>> What happens if we annotate the method to be renamed the next time >>>> it's run? We could run the script in question under an environment >>>> not totally unlike xmp. The first thing it would do is alter the >>>> source file according to the annotation. It would then add an >>>> appropriate method_missing to Object to do a rename in the original >>>> source file whenever the method was called, and then load() the file. >>> And what happens if the execution never calls the given method, for >>> whatever reason, or only reaches some of the places it is used? >> That's why you run your test suite through it. You do have 100% line >> coverage, right? :-)
> Well it's a clever idea. Show us the prototype. ;)
Well, you asked for it :-) The usual provisos for prototype code apply:
$ cat rename_method.rb $obj_replacement_table = {} class Object def method_missing(sym, *args, &block) if $obj_replacement_table.has_key? sym.to_s filename, line_num = caller[0].split(':')[0,2] l = line_num.to_i - 1 line_arr = File.readlines(filename) line_arr[l] = line_arr[l].sub(sym.to_s, $obj_replacement_table[sym.to_s]) File.open(filename, 'wb'){|f| f.write line_arr} self.send($obj_replacement_table[sym.to_s].to_sym, *args, &block) end end end
def process_file(filename) line_arr = File.readlines(filename) line_arr.each_with_index do |line,i| if line.chomp =~ /(\s+)def (\w+)(.*)#\s*becomes\s+(\w+)/ line_arr[i] = "#{$1}def #{$4}#{$3}# was #{$2}\n" $obj_replacement_table[$2] = $4 end end File.open(filename, 'wb'){|f| f.write line_arr } end
process_file(ARGV[0]) load(ARGV[0])
$ cat subject.rb class TestClass def my_method(foo) # becomes my_new_method puts foo end end
def meth_calling_renamed(t) t.my_method('Ok2') end
t = TestClass.new t.my_method('Ok1') meth_calling_renamed(t)
$ ruby rename_method.rb subject.rb Ok1 Ok2
$ cat subject.rb class TestClass def my_new_method(foo) # was my_method puts foo end end
def meth_calling_renamed(t) t.my_new_method('Ok2') end
t = TestClass.new t.my_new_method('Ok1') meth_calling_renamed(t)
There's a *lot* of scope for improvement in there, obviously, but that's the general idea.
|
