Comments for Stefan Kleine Stegemann

Comment on Capture standard output in Ruby by Lancer Kind

Lancer Kind — Tue, 19 Feb 2008 19:57:06 +0000

Great article! This outlines a solution that goes a long way into solving unit testing of stdout that is a problem with Java/C#. It’s also great that based on the need you’ve set up for code reuse, you introduced blocks/yield.

The problem around StringIO not working is interesting. I agree with your conclusion about the code not using duck typing. Duck typing is something new that a lot of us are going to need to work at to get used to. Checking the type of the superclass in order to make decisions about its capabilities feels like the developer was still stuck in the strong type checking paradigm in Java/C#. When Java was the new cool OO kid on the block in 1995, one saw a lot of Java code that was written as if it was C (poor encapsulation, lots of public fields, few/really-long methods, checking return codes instead of using exception handling). I expect a lot of Ruby code is going to look like Java/C# code but implemented in Ruby for a while until people unlearn some habits. (I know I’m working to do that.)

Bravo! Reading this has been a great use of my time!

Comment on Capture standard output in Ruby by Nick

Nick — Fri, 21 Sep 2007 18:24:44 +0000

This rocks. I wrote a couple of scripts to check on mysql replication. The scripts write to a log file and stardard out, but I want to send a daily report on the replication, and this should make it easy to capture the output from the script and stick it in an email. Thanks

Comment on Mixin Module Methods by Stefan Kleine Stegemann

Stefan Kleine Stegemann — Sat, 19 May 2007 16:40:26 +0000

Thx, I changed this in the example. I also added a link to http://redcorundum.blogspot.com/2006/06/mixing-in-class-methods.html.

Comment on Mixin Module Methods by Gregory

Gregory — Sat, 19 May 2007 15:40:17 +0000

This is nit-picky, but it’s not ModuleMethods, but ClassMethods.

To see why, have a look at the docs for module_function

-greg

Comment on Mixin Module Methods by Stefan Kleine Stegemann

Stefan Kleine Stegemann — Sat, 19 May 2007 12:27:39 +0000

@Gregory: Thanks for the comments, I updated the post with your solution. And sorry for the lost indenation. I think you have to use

 instead of .



Comment on Mixin Module Methods by Gregory Brown
Gregory Brown — Sat, 19 May 2007 05:55:40 +0000
also, if you’re *only* looking for class methods, you would extend rather than include a module, no singleton hacking needed 



Comment on Mixin Module Methods by Gregory Brown
Gregory Brown — Sat, 19 May 2007 05:53:38 +0000
whoops, looks like it killed my indentation :-/



Comment on Mixin Module Methods by Gregory Brown
Gregory Brown — Sat, 19 May 2007 05:53:11 +0000
The way you describe this works, but it’s usually better to use the hook that is meant to handle this:


module MyModule

  module ClassMethods

      def my_class_method

      end

  end

  def self.included(base)

      base.extend(ClassMethods)

  end

end


This is the standard idiom most Rubyists use because it’s more friendly to letting multiple modules be mixed in as nothing is directly overwritten.