Self-test modules now available

Feb 23, 2014 at 9:18 PM
In addition to the videos on the documentation page, I've created some self-test modules. Right now the self-test technology is a bit lame: you see a slide with a question, and then the next slide has the answer and an explanation for why that's the answer. I'm playing with tools that would let me embed a more interactive clicking option for true/false and multiple choice cases and so forth.

Please comment on these if you get a chance to try them. I want them to be useful but not painful to work through, and I want the questions to be interesting without being impossibly hard or seeming condescending and stupid. Perhaps I don't have this right yet; your feedback will really help me fine-tune them.

I decided not to include anything on the fancy aggregation and DHT collision resolution stuff the system includes. My feeling is that those features just don't lend themselves to true/false questions, may never really be widely used in any case, and are hard to ask about because they are a bit notationally cumbersome, with all the generic types and so forth. I do use them internal to the Isis2 system itself, but perhaps nobody else will do much with them. But if you think I really should make more of a stab at it, I'm game...
Mar 5, 2014 at 6:14 AM
Hello, Ken.
What do you think about SipHash as consistent hash function ? Link
Mar 5, 2014 at 10:11 PM
Edited Mar 5, 2014 at 10:11 PM
Siphash is quite good. I'm using SHA-256, which is also good and very fast, but Siphash is a very reasonable choice. With these kinds of hash functions the chance of a hash collision becomes extremely small -- way smaller than the chance of a bug, or of the International Space Station crashing into Gates Hall. But the kind of collision mentioned above is actually a different issue. That relates to how Isis2 should handle a "replacement" event. Suppose you Put "degot,71" and I put "degot,81". Which should be kept?

Isis2 calls this a collision (same key, two values) and has a default approach (it keeps the one with the larger timestamp). But you can provide your own handler and it can do anything you like -- average them, keep a list, keep the smaller one, etc. So a "DHT collision" isn't really a problem of a bad hashing function. It relates to the application putting multiple values in using the same key.
Mar 6, 2014 at 10:06 AM
DHT Collision can be solved with Vector clocks + custom handler that will use it to make a decision , am I right ?
Mar 6, 2014 at 4:20 PM
Yes, and in fact that is the default (automatic) behavior. You can also provide customized behavior. But if you use the system without adding a custom handler, you get exactly this behavior.