Braindump and various thoughts

Hi,

While I'm discovering alephet, I'm going to write down here all the things that I find a bit surprising. It might be that there is a good reason to do it that way that I don't understand yet, a matter of personal taste or, hopefully, an opportunity to finetune the api before it gets viral;)

existing syntax (the example)

var button_color_experiment = new AlephBet.Experiment({
  name: 'button color',  // the name of this experiment; required.
  variants: {  // variants for this experiment; required.
     blue: {
       activate: function() {  // activate function to execute if variant is selected
         $('#my-btn').attr('style', 'color: blue;');
       }
    },
    red: {
      activate: function() {
       $('#my-btn').attr('style', 'color: red;');
       }
    }
  }
});

##Are they other stuff that can be put in each variant beside the activate?

I'd like to duck type so:

var button_color_experiment = new AlephBet.Experiment({
  name: 'button color',  // the name of this experiment; required.
  variants: {  // variants for this experiment; if the attribute is a function, it's the activate
    blue: function() {  $('#my-btn').attr('style', 'color: blue;'); },
    red: function() {  $('#my-btn').attr('style', 'color: blue;'); }
  },
});

[@gingerlime]: this is a possibility and I was considering this as well, because it's simpler. However, it's also less extensible if you do want to add stuff later, OR you need more code to check for different styles of parameters (both with and w/o the activate key). I found the activate param more explicit, and the extra verbosity cost is relatively small in my opinion.

[@tttp]: my point was to keep both versions (duck typing), so you got a simplier version OR the more complete one.

extra param in the activate()

I'd want to be able to use the name of the experiment and the name of the variant in the activate function, so

   activate: function(variantName, Experiment) {
     $('#my-btn').attr('style', 'color:'+ variantName;);
     console.log("Experiment "+ Experiment.name + " variant "+ variantName);  
   }

[@gingerlime]: I'm not sure I understand why you'd need those params. When you assign the activate function, you already know the experiment and variant you're assigning it to. How much re-use is there for variant functions to warrant adding this? Maybe I'm missing the point here, but I can't see a huge benefit for adding those.

[@tttp]: is there a way already from within activate function to know what is the variantName now?

[@gingerlime]: Not currently. I could pass the experiment to the activate function, and then you can pull this out, but I'm not sure I see much use for this. As I mentioned, when you assign the activate function, you know the experiment and variant you assign it to. Can you explain the use-case for dynamically pulling this data at runtime? (passing the experiment seems like a simple way around this, but before implementing this, I'm trying to understand the use-case).

link better the goal and the experiment

It feels like the goal is hanging away from the experiment, not sure why. I would find clearer to have

var button_color_experiment = new AlephBet.Experiment({
  name: 'button color',  // the name of this experiment; required.
  variants: {  // variants for this experiment... }
  goals: {  
    'button clicked': function (goal) { $('#my-btn').on("click", function() {goal.complete()}:}
  }
});

[@gingerlime]: Separating the experiment and goals is deliberate, but optional. In my use-case, we re-use goals quite a lot. We have different goals that apply to many experiments (registration, buying, visiting key pages etc). So I'd like to define those goals once, and then "bind" them to different experiments using the add_experiment or add_goal methods. Under the hood however, all these functions do is add a reference between the goals and the experiment, and then when the goal is complete(), it fires the goal_complete method on the experiment. Passing the goals over when you create the experiment is an interesting option. I like it. I would still probably prefer passing a goal "instance" rather than creating it on the fly, since this leads to more spaghetti in my opinion. Although I'm still not 100% sure about this. It does seem like a positive direction, but I'd be careful not to tangle things too much. (you can see the "old" way of using goals here - you can still use it in the same way pretty much, but I didn't document it explicitly, because it feels more messy to me personally)

[@tttp]: "why not do both?" being the usual answer ;) I think in this case it's even a valid one, it cost one extra if to test the type of the goal param and either create the "proper" goal object implicitly or to use the one given as param (yes, I like duck typing ;)

[@gingerlime]: yes, if we are going to implement this, then we should support both. Although, I keep reminding myself the zen of python (there should be only one, obvious, way to do things) :) I'm open to this idea. Do you want to submit a PR or at least a code snippet on how this would be implemented?