Based on the setting of the problem, this would only prevent the user from getting in when they, in actuality, have a valid ticket, but would not allow them to get in with a ticket that has been used and is actually invalid. No?

"Your task is to build a function that appends a string to a array."

should be "to an array"

This would allow you change the value of used as much as you want, as long as the useTicket method hasn't been called yet. So you can have a ticket that says it's used because you changed it, but it's not really used - you can change it back because you haven't called the useTicket method and it's not frozen.

Nice solution. I had the same layout with the tests but I didn't think to use a fn to resolve the undefined, just tried (x|0) in place and it didn't work :-x Awesome, this is why I love this site.

AWESOME kata. Thanks a lot. I was stunned that there weren're more tests... things that might trip up hacky parsing; or at least some larger tests to give some satisfaction :-) I'd appreciate anyone's feedback on my solution, as wel.

Now that I see test 25... :-O

I've only solved four or five 4kyu problems at this point, but IMO the last test I can see (timesFive) pushes this into 3 territory. One man's opinion.

The reason for this was mainly to encourage efficiency, instead of a naive implementation. I'd encourage you to use the example test fixture to do smaller tests for debugging. For example, if a particular test fails, take the details given you in the failure message and create a test for it in the example test fixture. This way, you can run the full tests when ready, but do quick little tests to fix problems. Hope that helps?

Might it make sense to reduce the number of tests run? At 500, if you leave a log output for anything, it times out. Wouldn't 50 tests work just as well as a proof?

Nothing fancy, it's just the formula for the sum of consecutive integers

Could you explain how this works, or why it works, or how you thought of it?

I mean, I'd love to upvote this, but I don't understand it :-)

Sounds fair to me. I'll change it.

Does anyone else feel like this is too inherently complicated to be a 7kyu problem? Sure, the syntax and the technicality of coding it might not be very complicated in the end, but it requires real critical thought, and I expect (not having yet tried it) a lot of iteration after trial and error.

I mean, in the last 7kyu I implemented Array.prototype.sum() and such. Now I'm finding the optimal solution for Towers of Hanoi?!