Ruby 3.0 should be enabled, read this to learn how to do it
Please organize the structure of test fixture as following (although it has been mentioned in the attached link, I'm repeated here again)
describe "<This message should describe the categories of test groups inside this block>" do
it "<A short message describing this test group>" do
expect(...).to eq(...) #Assertions
#Or Test.assert_equals(user_response, reference_response)
enlarge the window (or stop coding on your phone x) )
I will try to publish other kata soon and I ask you to please detail if I fail in some point.
Maybe I don't understood all clearly, I think that I will understand in future.
floating point calculations?
Yes, and such a kind of identifier is not flagged as unused declared variable by linters.
unused declared variable
In interactive/console mode, yes, _ is the last evaluated expression. But that's a different context.
Possibly (not that I fully understand what you mean), for .. in requires valid identifier (and _ is such) to bind each element of traversed generator to, additionaly _ is commonly used to denote that identifier is syntactically required here but not used anywhere (wildcard pattern).
for .. in
Not sure on this one but is the underscore _ between for and in. Something about holding the last expression in Python?
Errr... would have been better to ask last month ('cause I don't remember your kata, now x) *)
About the "expectations", might be I overlooked some things when I posted this. Or maybe you applied some changes in the meantime? Again, I don't remember (*).
Might be I took the new ruby 3 assertions for the old (bad) test.expect too (*! ;) )
About the ref solution, you already have one in the random tests, to compute the expected value. Note that you need to avoid to put that in the same statement/expression than the call to the users solution (because it can become visible the the solver in a stack trace)
now about rejection: avoid too much simple tasks. Guys solving beta don't like them, unless there is a special additionnal value (and still, most of them will downvote the kata anyway). There a good reason to that: we already have too much of those in the data base (end guys solving beta generally have already done those. There is sort of an "epidermic" reaction going on, there. You'll see a section about "novelty" of the ideas for creating a kata, in the documentation btw)
last thing: don't base your judgment about quality content on existing old kata. A lot of old kata are rather bad (some even very bad) and totally do not fit in the current requirement. Those requirements are specifically here to try to avoid to end up with that kind of quality. ;)
'hope that helps? If you have other questions, go ahead.
Guy, thanks, good afternoon.
I don't see where the Kata doesn't fit with the best pratices in the documentation of your link. I read the content that your link pass. Obs:
There is a lot of text in the link. A lot! I read it quickly.
I will try to publish other kata today and will be cool to know the problems in my Katas. I don't know the difference of my approved Kata and my Kata rejected.
If anyone has time to spare. How do you learn things like this?
Thanks a lot man
in python or ruby, it's very hard to achieve. But anyway, as I pointed above, your kata is way too close from others that are already approved so it most probably wouldn't leave the beta phase anyway.
Some info about the beta process and authoring here and there
So there's no way to get people to do the problem from scratch?
just don't bother. That honestly is not worth the effort (especially in python, where almost nothing is actually enforcable)