After extensive tests, it is clear that the simplistic hashing algorithm is better in most cases. The Murmur Hash 3 creates a better distribution with more than 2 test groups, but this new simplistic hash should be sufficient as a base case.
When we call the callback, we now pass it both the user's ID (key) as well as the group number. The key is either the "key" named parameter, the generated value from `getId()`, or the first non-function value passed into the labrats()` function.
A hash function can be given as a parameter in order to specify how key values (as strings) are converted into numbers (than can then be divided into the different test buckets). This overrides the global configuration setting.
If you don't want users to be involved with more than one test group, then you can takes a pool (specified by the 'name' parameter) into a number of slices. Each slice can have one or more groups.
fixed missing quotes after flashy-blue
Using the "multigroup" example, I explain how the distribution is likely to overlap and put some people into multiple tests. While I think this is a "good thing", it may not be what some people want.
The comments from the plugin source code are now more clear, and are written to the end of the README file to make it easier to render on Github.
What if you are running concurrent tests? How many people will end up being a test subject for more than one experiment? This example attempts to show this sort of re-distribution. We take 1,000 generated GUIDs and put them in two separate tests and visually display the results.
Instead of splitting the entire population into test groups, you can create a testing pool of a particular size. The test groups will be found from user keys in this pool, and the rest may form a "control" group. This allows you to have a two 5% test groups with a 90% control. Each of these three groups can get a callback function.
While I'm not fond of a global "number of groups" setting, if it is set, but overridden with a specific list of callback functions, we reset it back to its original value.
Our hashing function (that we use to split users into test buckets based on keys that might be similar to GUIDs) is pretty simplistic. But the goal of uniform distribution may or may not work well. In this experiment, we create thousands of GUIDs and use our hashing function as well as a Murmur Hash function and graphically show how they compare.
If a "key" isn't specified for a user account, then we can just randomly assign the user account to a test bucket without resorting to hashing functions. However, since our default hashing function is pretty simple, we document ways to use other routines.
For the $.labrats() function, we can figure out how many possible groups there are based on the number of functions given, so this can be optional. Obviously, for the $.group() and $.isGroup() functions, that value must still be specified.
If the user 'key' value is not specified, then a key is retrieved from the brower's cookie jar. If it isn't there, a unique ID is created (and put back into the cookie jar).
Created a $.labrats() function that can dispatch to multiple callback functions based on a given "key" that represents a user account. Exposed all of the supporting functions for fine-grain control.