While I find this humorous (which I assume was the goal), I think using common development terminology could be worse than complete jibberish since you start to apply irrelevant meaning when reading the beautified code.
>Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.
What is the proposed change, exactly? Do you have more information?
It looks like the asynchronous interface to debasishg/scala-redis is synchronous under the hood, using a pool of blocking connections. This means that there is no pipelining. Each of these blocking connections must wait for a request to travel over the wire, be handled by redis, and travel back before it can be reused. An asynchronous client allows full pipelining automatically, which is a much more efficient use of a single connection.
> we have noticed performance issues as redis serves only 1 req every time there was too much time spending in thread-join
Performance should be better with an asynchronous client. When I've benchmarked e.g. jedis vs various async clients, that's been the case.
It's definitely a real, common problem, but I think the article obscures it a bit. Blocking I/O operations using the Akka dispatcher will block that thread while the command executes. Doing this too often will cause all the akka threads to be blocked, stopping the dispatcher from processing more events. Therefore, one should avoid performing blocking operations on akka threads.
In my experience, one of two things will happen in practice:
1) You use an asynchronous library for I/O calls, which will maintain its own threadpool. This is no problem, because the I/O threadpool is independent from the akka theadpool.
2) You want to use a synchronous library that performs I/O operations using the caller's thread. If you must do this, you should use a separate threadpool (ExecutionContext).
...bah. I keep forgetting that 64-bit C/C++ compilers are generally LP64 (or even LLP64) instead of ILP64, so "int" being possibly too small is in fact typical.
Still. In the example (Java) implicit down-converting isn't allowed, so this is a result of the spec putting arbitrary limits on array size (must be indexed by nonnegative 'int' values). In C or C++ there is no such limit and I think more modern compilers (llvm) will give a warning on loss of precision, so either you have that warning ignored/disabled/unavailable or you have 32-bit code with a billion-element array. I guess what I'm thinking with this is, with a sane language/compiler, the only way to trigger this should be to fill half of your theoretically-logically-addressable memory with an array with single-byte elements.
There seems to a lot of confusion, both in the article and in the comments, about the "3 trusted friends" password recovery. You have to manually select your trusted friends . A fake account mimicking one of your friends will not be a "trusted friend" unless you make him or her one.
You need to trick an account into accepting three fake friends, since those users will receive the code to change the password. Hardly seems like obvious security flaw, more like a long, complicated piece of social engineering. Which is what all hackers do....
You need to trick an account into adding three fake friends as "trusted friends", a feature that most people do not know about or use. This is much harder getting someone to friend three fake accounts.
I agree but set B is not a uniformly chosen subset of A in this case. That is the core of the trick. The rule for choosing B is intuitively uniform but actually slightly favours families with a girl and a boy over those with two boys.