The items are prioritized by value per size, not by size alone.

If you divide value by size for those 5 items, you get:

item[0]: 7.4 / 11.2 = 0.6607142857142858
item[1]: 17.8 / 25.6 = 0.6953125
item[2]: 41.2 / 51.0 = 0.807843137254902
item[3]: 15.6 / 23.9 = 0.6527196652719666
item[4]: 19.0 / 27.8 = 0.6834532374100719

So the item with highest value/size is item[2], (51.0, 41.2). You take 1 of them. The remaining capacity is 49.
The next highest value/size is item[1], (25.6, 17.8). You take 1 of them. The remaining capacity is 23.4.
The 3rd highest value/size is item[4], (27.8, 19.0). You don't have enough room to take any of them.
The 4th highest value/size is item[0], (11.2, 7.4). You have room for 2 of them. The remaining capacity is 1.
The least value/size is item[3], (23.9, 15.6). You don't have room to take any.
The result is [2, 1, 1, 0, 0].

Excellent point. :)

A hint: Count groups of 0s as well as groups of 1s in order to determine the time unit.

On python the test case is:

Test.assert_equals(knapsack(100, ((11.2, 7.4),
(25.6, 17.8),
(51.0, 41.2),
(23.9, 15.6),
(27.8, 19.0))), [2, 1, 1, 0, 0])

But if we are beeing "bad at math" and always getting the bigger value object that fits on the bag we should end up with:
[1,0,1,0,1]

Because we get the object with 41.2 (left with 49 on the bag) than the 19.0 (left with 21.2 on the bag), the objects with values 17.8 and 15.6 are too big for the room left on the bag and thus the object 7.4 fits once (leaving 10 on the bag)

Am I proceeding worng with this?

111 could only be either a single dot or a single dash, it can't be 3 dots like in "S", as that would require some 0's between 1's.

I must say I disagree with some of the Java tests.

On two of them:
testMultipleBitsPerDotHandling(MorseCodeDecoderTest) ---- Passed: 111
testExtraZerosHandling(MorseCodeDecoderTest) ---- Passed: 01110

The correct response should be to interpret it as a single dot ".", i.e. the letter "E", this is not a sensible test since the letter "S" is coded "..." and with the passed string as argument one could interpret as the letter "S" and rate of transmission = 1 (which my algorithm does).

Am I missing something? I am sorry if I am not correct and I hope someone can show me. But it doesn't seem to me as there were any restriction to something like "Rate is always greater than 1"

how about "fruitBasket" or just "basket"? Even "groceries" or "fruits"...

Yes in the test cases they are indeed correct. I meant on the test cases provided as default under "Your Test Cases:".
I know everyone can change these. I was just pointing out that typo.

actually the parameters in assertArrayEquals are (expected,actual) in the test cases.

The tests are in the wrong order providing a wrong feedback:

The API is: assertEquals(expected, actual)

and in this kata it is as: assertArrayEquals(FruitGuy.removeRotten(rotten),expected);

so just change the order of the parameters passed and it will be correct...

Minor issue ;)