Yes, in most cases, self is the implicit receiver of a method call. I hesitate to say all cases, because I’m quite a newbie myself.

(Rubyists tend to use that word, “receiver,” which reflects the language’s Smalltalk influence, and its idea of “sending messages” rather than “invoking methods”. This threw me off for quite awhile.)

In general, it seems idiomatic Ruby prefers to have the receiver be implicit if it’s self. Private methods can’t have any explicit receiver, including an explicit self, so it makes a difference there. And when defining methods, adding self makes a big difference. Within MyClass, “def my_method” would define an instance method, while “def self.my_method” would define a class method.

The most helpful resource I’ve found on this stuff, covering all the fundamentals of Ruby’s object model, is Dave Thomas’s screencast series: http://www.pragprog.com/screencasts/v-dtrubyom/the-ruby-object-model-and-metaprogramming . Yehudah Katz’s blog posts are great, too.

Re: line 100, yes, I could have used the instance variables @values and @num_buckets, and in most intros to OOP I think that would be the recommended approach. But I chose to follow Jay Fields’s advice (link is in the code comments) to not make direct use of instance variables throughout a class’s methods. Rather, I’m wrapping these instance variables in getter methods. The getter is written out as a method in the case of @average_bucket_sum. For @values and @num_buckets, I’m using the shorthand declaration attr_reader :values, :num_buckets to get my getter methods on the cheap.

I didn’t give much thought to the issue of whether the two objectives might not be equivalent. I chose to go with the smallest variance option, as that seemed to reflect the spirit of “fair” distribution. The machines can go slightly longer as a whole, in the interests of solidarity.

I like the idea you pose at the end. I’ll give it a shot when I have some time.

As someone new to both Ruby and OOP, I found your program interesting and instructive. I have a few questions. I was surprised to see “clone” (line 23) and “map” (37) with no arguments. I made what I thought was a reasonable assumption: if a method’s object is not specified, it is to be “self”. Sure enough, when I replaced “clone” with “self.clone” and “map” with “self.map”, your program ran no differently. Then I shortened “self.each” to “each” in line 46, and again, it made no difference. Am I correct that “self” is assumed when a method’s object is not specified, and if so, when, if ever, is it considered good practice to include “self.” before the method?

Secondly, I do not understand why you do not need “@values” (as in line 72), rather than “values” (and @num_buckets rather than “num_buckets”), in line 100. I thought “values” would be regarded as a local variable to average_bucket_sum (and there is no method, “values”). I tried it both ways, but the inclusion of “@” made on difference.

Though not a Ruby question, I was wondering why you chose an objective different than the one given in the challenge. Considering that you enumerated all solutions, it would have been just as easy to find the one with the smallest maximum machine time (and, if there were a tie, find the one among them with the smallest variance).

By constructing the set of all solutions, then finding the best among them, as you have done, you would quickly run out of memory for larger problems (that have M^J/M! combinations, for M machines and J jobs). Here’s a challenge (perhaps an NP-complete one): is there a way to loop through all the possible combinations without constructing all of them first (and without repeating permutations, e.g., if you’ve examined [[2,1], [4,3]] you would not examine [[4,3], [2,1]], [[2,1], [3,4]] and so on)?.