This is simple and elegant and does what it says on the tin. A+.

I think I see what you're driving at - the inject method has to explicitly pass the hash along to the next iteration, while the each_with_object method does that for us. But I think I'd hesitate to call one less crufty than the other; each_with_object doesn't need a second statement in the block, but inject seems to keep the variables in a more straightforward order and is a few characters shorter. I ran benchmarks but they compare very closely for speed.

After looking at it, I'd say that the two solutions are pretty much equivalent and I don't see a strong case to favor one over the other. Is there a point I've failed to consider?

I'm familiar with #each_with_object, though I'll admit it doesn't often come to mind. That having been said, I don't see an obvious way to clean up the code with it - where would you apply each_with_object?

The existing user-facing test case either needs a little polish, or could probably be removed entirely. Otherwise, this looks good!

Fun kata! I think it's very nearly ready for production, but it needs a small adjustment to the test case messages - specifically, it seems like you're outputting instructions or advice for passing tests when you mean to output it only for failed cases (e.g., "including Enumerable is cheating," or "why are you messing with #count?"). Tweak those to only show up in failing cases and I think this is ready for prime time. :)

One small suggestion - if I only have one student, then technically they "all" have the same amount of money. I don't disagree with the test suite rejecting that answer, but I do think the instructions need a line about what you expect when only one student is presented.

As many others have mentioned, the definition of palindrome could use clarification here. Particularly, I need to know if "Racecar", "Race Car", "Race-car", and "Race car!" are palindromes for the sake of the exercise.

I disagree - it's common Ruby style to accept the falsy value of nil and the truthy value of everything else. The !! pattern is considered by many to be a code smell. I refactored my version of the solution to not use that at all; as you pointed out it doesn't have any bearing on the test results.

I do think the kata should be adjusted so that either the acceptance tests explicitly require boolean values, or the initial method does not have the !!. I'd vote for the latter, but either adjustment would help the consistency of the kata.

Solid kata! This is a premise that's easy to understand, but still requires some programming manipulation to get right.

Interesting kata! I think this is a good introduction to the kind of "hacky" concepts that we like to play with sometimes. If the provided test were different from the acceptance test, this would be a much harder kata, but as it stands it's relatively easy to see where the weak points in counterfeit checking are.

Your instructions ask for output different from what your test cases expect.

• You specify: "Write an method sing_bottles_of_beer that returns a string for that verse."
• But your test case requires: "Write a method sing_bottles_of_beer that returns a string for all verses, starting with the given number and iterating down to 0."
• You specify: "Take one down, pass it around,"
• But your test case requires: "Take one down and pass it around,"

Also, the test suite you provide to the user is broken - you're calling #split on a variable "expected_song", but you don't define "expected_song" for the user - so running the tests suite always throws an "undefined method 'split' for nil:NilClass" error.

One of my students was very confused and frustrated by the testing error, and I was embarrassed my advice to return only the requested verse and not the entire song was proved invalid. I applaud and appreciate the time you took to contribute to Codewars, and I certainly don't want to dissuade you, but please keep in mind that many people are using this to learn their first programming language and that's already a very frustrating endeavor. Having clear instructions and a working example test are great boons to these students.

Perhaps the kata would benefit from checking for something simpler, like one verse of the song or even just the "pluralize" method you suggest - either would exercise the student's grasp of method arguments and logic flow, without adding as much of the brittleness that comes with exact string matching.

Nice exercise! Just a couple points of feedback:

• Normal ruby style has parens on method definition (e.g., def line_types(lines), as opposed to def line_types lines)
• Would be helpful to have the usual test-starter language, or perhaps a fully formed first test.
• How should I handle "This is a beta alpha beta string"? I'm guessing I should return "alpha", but that's just a guess.