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.
ThoughtBot: cd'ing to frequently-used directories in ZSH -
Josh just dropped some sweet, sweet ZSH knowledge. I spend a lot of time in the directories under
$HOME/thoughtbot/and$HOME/src, and to get there I type (for example)cd ~/thoughtbot/hoptoad. There is a better way!First, add this to your
~/.zshrcand source it:setopt...
What Someone (not me) Learned About Testing Over the Last Year -
Note that these three things cover the entire life cycle of code; correctness applies to the present of the feature, confidence comes into play when the feature is in the past, and design feedback sheds light into the future of your code.
Video from Glenn Vanderburg’s talk at Scotland Ruby 2011.
Software engineering is the science and art of designing and making, with economy and elegance, […] systems so that they can readily adapt to the situations to which they may be subjected.
In classical engineering, the construction is by far the most expensive part while in building software, the construction (done by compilers and interpreters) is by far the cheapest and designing is the most expensive.
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.
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.
Examples for responsive web design -
Found in this presentation.
Extensive list of OS X keyboard shortcuts and touch gestures -
“When your goals and your user’s goals are truly aligned, you don’t need pixie dust. Don’t out-spend, don’t out-friend, and please don’t out-badge. There is a world of difference between helping someone *appear* more awesome and helping them actually BE more awesome.” — Kathy Sierra in Pixie Dust & The Mountain of Mediocrity