4 ms·

"In addition, the names of Hazelcast’s datatypes, and the functions provided on those types, imply a certain fitness-for-purpose, e.g. that users can use these

"In addition, the names of Hazelcast’s datatypes, and the functions provided on those types, imply a certain fitness-for-purpose, e.g. that users can use these types and functions in a meaningful way. What is the point of an ID Generator which emits duplicate IDs? A lock that doesn’t lock? Who wants an AtomicReference which is not atomic? Of what possible use is a queue which doesn’t, well, queue?" Wow. I wonder if the documentation and naming schemes are bad because they're aspirational, or because the developers don't know what they're doing?

im_down_w_otp 9y ago
Not with respect to Hazelcast specifically, but it's often the latter, but not maliciously so. It's fairly difficult to implement a lot of those things correctly, and fairly easy to convince yourself you were thorough.
- deleted 9y ago
  [deleted]
- noncoml 9y ago
  That's why we have QA, no? A developer can only test up to the point that their code works as they thought it should work. QA takes over from that point.
  - im_down_w_otp 9y ago
    Probably not. You as a developer could write a Jepsen harness for your system and find the same results seen here. You could also write property-based tests to improve your testing model and input space coverage. You could also use mutation testing to see how good your tests are, etc. etc. etc. At my last job we held off running a chaos test suite against our platform in the certification environment until _after_ the QA department came back with their report and gave the platform all green checkmarks. This was an exercise in both validating the value of the chaos engineering/testing work as well as partially discrediting the idea that QA is capable of exercising enough of the system in enough ways to expose non-obvious/nuanced edge cases. I mean I guess there's an argument to be made that QA could be engineering and building their own rich tooling like a chaos testing framework, but that seems extremely unlikely to happen in the current typical formulation of QA.
threeseed 9y ago
The documentation/naming schemes comes from the Java interfaces which Hazelcast implements. The issue of course is those interfaces were I assume intended to only run on one JVM. And of course they knew what they were doing since that was the whole point of Hazelcast. You could use the same Java constructs you knew and loved but on a distributed grid. Problem is of course that it wasn't well implemented and likely not such a good idea to begin with.

im_down_w_otp 9y ago

Not with respect to Hazelcast specifically, but it's often the latter, but not maliciously so. It's fairly difficult to implement a lot of those things correctly, and fairly easy to convince yourself you were thorough.

deleted 9y ago
[deleted]
noncoml 9y ago
That's why we have QA, no? A developer can only test up to the point that their code works as they thought it should work. QA takes over from that point.
- im_down_w_otp 9y ago
  Probably not. You as a developer could write a Jepsen harness for your system and find the same results seen here. You could also write property-based tests to improve your testing model and input space coverage. You could also use mutation testing to see how good your tests are, etc. etc. etc. At my last job we held off running a chaos test suite against our platform in the certification environment until _after_ the QA department came back with their report and gave the platform all green checkmarks. This was an exercise in both validating the value of the chaos engineering/testing work as well as partially discrediting the idea that QA is capable of exercising enough of the system in enough ways to expose non-obvious/nuanced edge cases. I mean I guess there's an argument to be made that QA could be engineering and building their own rich tooling like a chaos testing framework, but that seems extremely unlikely to happen in the current typical formulation of QA.

threeseed 9y ago

The documentation/naming schemes comes from the Java interfaces which Hazelcast implements. The issue of course is those interfaces were I assume intended to only run on one JVM. And of course they knew what they were doing since that was the whole point of Hazelcast. You could use the same Java constructs you knew and loved but on a distributed grid. Problem is of course that it wasn't well implemented and likely not such a good idea to begin with.