Thanks for your comments. I fixed the first two issues—thanks for catching them!

There are plenty of situations where having this in a separate class would be useful: you may want to initialize an instance once with an unknown parameter and then use that same instance a number of different times throughout your application, without having to specify unknown again.

You could compare it to Redcarpet's API, e.g. (taken from its Readme):

# Initializes a Markdown parser
markdown = Redcarpet::Markdown.new(renderer, extensions = {})

markdown.render("This is *bongos*, indeed.")
# => "<p>This is <em>bongos</em>, indeed.</p>"

What would you have done instead?

Using rand for the keys is a bit dicey as you can (or at least I did) run into floating point rounding errors. My submission failed the test suite the first time on one of the rand keys and then succeeded on the second go.

Maybe you should change the rand tests to rand.round(10).

Fun kata.

I think you should clarify in your description and test suite whether if we have two users, each with the same and lowest nexus (e.g., {5 => 5, 10 => 10, 1 => 100})

1. both matches should be returned in an array ([5, 10])
2. one or the other match should be returned (5 or 10).

This bug still seems to be kicking around.

Agreed.

Great! I'm glad you got it to work.

The description is very unclear and should be improved before release. Otherwise, a good idea for a starter kata.

Many of the tests require true/false values, whereas idiomatic Ruby allows for truthy and falsey values in situations like this. (The fact that some but not all of the tests require true/false makes failures even more confusing.) A number of previous comments on this kata seem to stem from this feature of the tests.

I would recommend changing all positive tests like Test.expect(validate( 'joe.m@server.com') == true) to Test.expect validate( 'joe.m@server.com') and all negative tests like Test.expect(validate( 'joe.m.k@server') == false) to Test.expect !validate( 'joe.m.k@server').

I got it to work eventually, but I ran into the same problem you mention for a long time.

What finally made my solution fast enough was switching to the stochoastic acceptance method (via Wikipedia, as described here: http://www.staff.amu.edu.pl/~lipowski/roulette.html/). Were you using that, or were you instead using some other algorithm? With this algorithm I was able to support a population size of 100.

Did you trim the spaces from the end of each line?

The description is very unclear.

Good concept, but the description is very difficult to read and understand, as it is not in very idiomatic English. I had to read it a number of times to get the gist of the task.

Test error messages could be improved to show actual/expected result.

I believe the test suite and description miss an important PascalCase -> snake_case scenario: multiple capital letters in a row.

As I understand it, 'ThisHHHasManyCapitals' should yield 'this_hhhas_many_capitals', not 'this_h_h_has_many_capitals'. Along the same lines, 'CSSSelector' -> 'css_selector.'

As it stands right now, all of the top voted Ruby solutions fail to translate 'CSSSelector' et al. correctly.