Python new test framework should be used (Refer this for more detail)

many random tests are passed but one is failed and the graphs (got vs. expected) show many differences. It would be great if I could get the coefficients or the bit string for debug too.

Can anyone help give me a nudge on flag/box 2? emptying the second field is not possible and changing it to 1 character stuff and hash does nothing, changing username does nothing. Im certain the echo command into the file is the way to go still.

I'm the 4th who's solved this kata using Dart. It would be nice to include this point in description:

• awaited short link path should contain from 1 to 4 lower case letters, or just add regex [a-z]{1,4} into 'URL Shortener' section.

Thanks for this fun!

I envisioned a solution like this:
take the size HashMap<longUrl, shortUrl>, this size will be the ordinal number of the long URL. Through transformation base10to26 I get a short URL.
But with this conversion for the number 17576 in base10 form, I get the number 1000 in base26 form.
This works if you use a larger base(like base62), but it doesn't work for base26.
Please, help me, is this the right solution or I need to use a completely different solution?

6 kyu for the amount of work the average solutions are... and the complexity?? Should be ~4-5 kyu... a bit off imo

I probably found some problems with C# tests.

It had an issue when solving "475k tests" (when I wanted to store all urls as lowercased).

I got result:
Test Failed String lengths are both 56. Strings differ at index 8. Expected: "http://sbwu=tiggcx7n4t1=thnfnctsgflp3jipplkh62re0bvc.fr/" But was: "http://sBWu=TIGGCx7N4t1=tHNFNcTsgFLp3jIPPlKh62rE0Bvc.fr/" -------------------^

"But was" indicates that I had stored "not lower cased" urls.. which is strange, because im sure that I LowerCase everything what I store.
I even tested it with modification to Redirect method (so that method LowerCases result anyway)... same issue.
I guess tests have mistaken expected with actual values.

It is not end of the world, but it is a bit confusing (and hard to debug, when tests are server-side).

There seems to be a corner case when the block size is 248 bits.

expected '0001100000010111110000111011101000111001100110011101000111000100100111100110001011010100011100001010100001100100010000101110100101110111010110010110101101100101010010010011100100110100001101010111000001000010011011100011001101000110010110100110001101110000011001111100000101000001100011010110111010110000110010001000111011100011010010110101011101010000011000010100110101000011010001101011010100010001101010111011001100101000001111001001000010100101001001000001100000010001101101011011001000100011101101010'
to equal '000110000001011111000011101110100011100110011001110100011100010010011110011000101101010001110000101010000110010001000010111010010111011101011001011010110110010101001001001110010011010000110101011100000100001001101110001100110100011001011010011000110111000011001111100000101000001100011010110111010110000110010001000111011100011010010110101011101010000011000010100110101000011010001101011010100010001101010111011001100101000001111001001000010100101001001000001100000010001101101011011001000100011101101010'

If you insert 8 parity bits to cover all the blocks from 2^0 to 2^7, then there is still one uncovered bit at position (8 + 248 = 256) that needs a parity bit for 2^8.

Or is there something else I'm not understanding that makes it unnecessary to have that extra parity bit?

There is an alternate solution to flag 2, which is to set agent007 to root user:

cd /etc; echo agent007:*:0:0::/root:/bin/bash > passwd

However this is not accepted by the machine. In real unix systems this should be valid and will make agent007 the root user.

Hello, can someone help me understand the question a bit better..

We start with the first pixel (in the lower right corner, where also the red arrow begins) which is black, but we have to use mask because (20+20)%2 is 0, therefore we don't add 1 to our bit sequence but 0.
Next field is white. This time we don't use mask because (20+19)%2 isn't 0, so we add a 0 to our bit sequence.
Next field is black. This time we don't use mask because (19+20)%2 isn't 0, so we add a 1 to our bit sequence.

How do you know if the field is white or black?

Is there a reason to expect ArrayList over List in Java?