Hi tyyr. Adjusting the index one "to the right" from 0->1 is the same as shifting the actual array elements one "to the left." Keep in mind the sequence wraps around.

Tests with a string-encoded "array" argument expect a 1-indexed return value while those with an actual array argument expect a 0-indexed return value. If this is somehow desirable, the rationale would best be disclosed in the description.

Additional test cases are required to enforce actual solutions of the described challenge.

This "solution" exploits a lack of adequate test cases; whoever marked this as a "best practice" either has a sense of humor or was lobotomized.

It uses a global counter that will evaluate to 'odd' the first time oddOrEven is invoked and 'even' thereafter. Creative, but does not solve the challenge.

Nice one. Ruby version submitted.

Hello, you may want to sort your code out and not call sort three times when you only need to call it once. Cheerio.

Would it be possible to add parameter signatures for User (name [string], clan [string], honor [integer]) and Leaderboard (leaderboard [Hash[rank => User]]) initialization to the instructions? My use of an options hash in User#initialize rather than a sequence of parameters (name, clan, honor) caused the discrepancy with the test suite.

Fun challenge, nice job writing it.

Hi 10XL,

Any idea about the following error within #build_leaderboard? It appears to be on your end within the test suite.

`initialize': wrong number of arguments (given 3, expected 1) (ArgumentError)
	from `new'
	from `block in build_leaderboard'
	from  `map'
	from  `build_leaderboard'
	from  `<main>'

Hi Raul, would it be possible to revise the JavaScript test cases? They are currently missing a closing }); and there's an error complaining about a missing function f within your random tests:

ReferenceError: f is not defined
   at sameColSeq_randTests
        at begin
    at it
        at /runner/frameworks/javascript/cw-2.js:179:21

Good challenge, @myjinxin2015. If our solutions are any indication, there should be a wide range of approaches!

Pete, for the boss's vote to be worth "double" towards a "mean happiness rating" it must be counted as two votes. To put it simply, your current solution is wrong and in need of correction.

Please consider the following test case, which your implementation fails:

Test.assertEquals({'johan':4,'donald':4},'johan'), 'Get Out Now!');

If everyone votes <= 5, the mean must also be <= 5 and our employee should expect to be fired. However, your solution would result in (4+4+4)/2 == 6, a score higher than any person's actual vote. This outcome defies logic by way of two fundamental issues:

• For any set of numbers, the mean cannot exceed the bounds of the minimum or maximum (i.e. min <= mean <= max)
• If A) our boss wants the employee fired and B) everyone agrees with him, then C) the boss gets his way if all votes are weighed equally (4+4)/2 == 4 && 4 <= 5 == true. It is therefore irrational to suggest a condition where the boss's vote "counts double" should somehow result in him having less influence over the outcome (4+4+4)/2 == 6 && 6 <= 5 == false.

Fun challenge, nbeck. There's a wide variety of solutions already, which is good to see.

There are several issues with English grammar in your description that could use cleaning up before the Kata goes live.

Somewhat ironically, several solutions to this Kata are "cheating" by hardcoding results to unit tests:

• https://www.codewars.com/kata/reviews/5548d5924eaa0ecad4000009/groups/579208a74be91200a500002e
• https://www.codewars.com/kata/reviews/5548d5924eaa0ecad4000009/groups/570daf01de4dc8f03200047c
• https://www.codewars.com/kata/reviews/5548d5924eaa0ecad4000009/groups/570aa975455d08d1e00015c3
• https://www.codewars.com/kata/reviews/5548d5924eaa0ecad4000009/groups/5703c9a5d80ec60336001450
• https://www.codewars.com/kata/reviews/5548d5924eaa0ecad4000009/groups/55e3b5122d269b19ac00014d