I think this is a good change. However, might I suggest that instead of #identify only taking a 'name' parameter and then trying to determine how to use it, why not have #identify take a block which yields the item and returns the identifying key. You could leave the original signature of #identify as a shortcut for hash access.

# still provide hash access shortcut
processor.identify(:id)

 # arbitrary key access or calculation
processor.identify { |job| job.id }
processor.identify { |user| user.email.downcase }

Both ways of calling identify should still respect the duplication restrictions. The return value from the block form would be the basis for determining that it is a duplicate or not.

Since this whole kata is a large exercise in playing with blocks, I think this is a more fun than simply calling #send on user input.

I still don't believe the description and test cases entirely match up.

I'm getting "can't convert String to Integer" for an implementation I test drove locally with rspec.

Can you make sure the test cases and description work with an example implementation?

value / total * 100 != value * 100 / total

Implementation specific percentages.... :(

I think the test cases are throwing exceptions? The first line in my solution is "class ItemProcessor" and it gives me "ItemProcessor is not defined."

"I can't tell you the rules"

This makes is difficult to know what "the correct number" would be...

Nil case:

Test.expect(calc_mean(nil)) == 0

What should it do for:

[6, 8, 11] # handle floats or truncate?