The link is broken :(

.

Hardcoding results for a limited number of inputs surely isn't cheating?

Call it precomputing, efficient, inflexible, but not cheating.

Check out my funHackishBadPractices approach :) PS. Probably it's a good idea to outfilter such "solutions" by setting performance constraints.

Not sure I completely understand getSolutionRankingScore and getUpvoteBonusScore,

but it seems that upvote points don't decay over time.

Wouldn't the concept fail to produce the desired effect if upvote points don't decay?

I was pretty stoked to pull 2,200k/s, but I'm not sure how much of that should be attributed to server performance increases.

Thanks a lot. Needed exactly this after completing the kata!

> 6 Kyu: Fizz/Buzz

This is a bit surprising for me. FizzBuzz is maybe 7kyu if not 8kyu. Some 6kyu katas are brain-teasers while FizzBuzz is "supersimple no-brainer" when one knows at least the basic flow-control structures...

Regards,

suic

Sorry, I've havent noticed how old this reply is. :)

0<5 get 10pt

5=5 get 5pt

10<=10 get 5pt

10.5>10 get 0pt

4.5<5 get 10pt

10+5+5+10=30

How does [0, 5, 10, 10.5, 4.5] == 30??
I don't understand the scoring here, it should either be 20 or 25, depending on the rounding:

0 = 10 pts
5 = 5 pts
10 = 0
10.5 := 11 = 0
4.5 := 5 = 5 pts

10 + 5 + 5 = 20

Or, if I were to not round up/down and only use the integer value, the score is still wrong:
0 = 10 pts
5 = 5 pts
10 = 0 pts
10.5 := 10 = 0 pts
4.5 := 4 = 10 pts

10 + 5 + 10 = 25

Yeah, thanks for your prompt.

Dependency Injection also allows fakes/mocks to be injected in unit tests.

Consider a function that processes orders.

function ProcessOrders(orders) {
  var transactionApi = new transactionApi();
  
  for each (var order in orders) {
    if (!order.IsProcessed) {
      var transaction = new transaction(order);
      transactionApi.ProcessTransaction(transaction);
}}}

We'd like to write a test that verifies that an order that has already been processed is not processed again. But any test written against this function will actually hit the transaction API and process the transaction because it is tightly coupled to the function.

Now let's refactor using Dependency Injection.

function ProcessOrders(orders, transactionApi) {
  for each (var order in orders) {
    if (!order.IsProcessed) {
      var transaction = new transaction(order);
      transactionApi.ProcessTransaction(transaction);
}}}

By having a higher application layer do the binding of the transaction API to the ProcessOrders function, we can now write a test using a fake transaction API. This fake transactionApi won't actually process a transaction. Instead, it will only record when ProcessTransaction is called. And our test can use this record to verify the desired rules.

@tianshuo: Think about why you can't overwrite length, then change that.

Is there some codewars integration with some CPU or memory benchmark? This is good info.