Follow @behrends
Showing posts tagged ruby

Threads in Ruby

The current (as of Ruby version >= 1.9) situation concerning threads, concurrency and parallelism in Ruby is nicely explained in this article.

The GIL (Global Interpreter Lock) in the MRI Ruby interpreter gets mentioned and its purpose of data protection is exemplified here. The same author previously published a piece that described threading in Ruby in a more general way, including the topic of fibers. 

Finally, I found an interesting discussion addressing this subject in the Ruby forum.

Talk on fast Rails tests (Corey Haines)

At GoGaRuCo 2011, Corey Haines shared ideas about how to speed up a unit test suite in Rails by treating Rails as a third-party component that can be isolated. He extracts business/domain logic into plain old Ruby classes which can be tested without the framework overhead. He maintains a github repository with an example Rails app that illustrates his approach in branches. 

About (not) testing private methods

Gregory Brown (author of Ruby Best Practices - available for free as PDF) discusses the issues around tests involving private methods. The gist of it is that private methods should only encapsulate auxiliary functionality that is so trivial that it doesn’t need to be tested. Any more complex code found in private methods can be regarded as code smell indicating that the method should be exposed as public or that there are more serious underlying design flaws.

Private methods in Ruby

Method visibility in Ruby is different from other languages, especially Java. In Java, public methods or data members are accessible from everywhere, protected ones can only be accessed by the containing class or subclasses and private members are visible only to the class where they are defined. In contrast to that, method visibility in Ruby is all about the receiver of the message as this blog post by Jamis Buck from 2007 explains very clearly with some example code. 

Ruby allows public methods to be called with explicit receiver, self or implicit receiver. Protected methods may be called if the receiver is of the same class as “self” (explicit or implicit) and private methods cannot be called with an explicit receiver at all.

This is how private/protected/public are designed to work in Ruby and it is helpful to not think about method visibility in terms of inheritance - it avoids a lot of confusion because for example in Ruby, a subclass can call the private method of its parent.