[erlang-questions] Managing Experiments

[Gordon Guthrie]

Jeremy

Run the old and new functionality in parallel in the backend and do the
switching in the GUI.

So you would have module1.erl and module2.erl which are branched versions of
each other with the same/similar interface, the same/similar supervision
tree and the same/similar startup process.

Each user either gets GUI1 which maps to module1 or GUI2 which maps to
module 2 - this can be static hmtl/javascript switching or dynamic on some
A/B parameter.

The module that you use to switch web requests (out/1 in yaws or the mochi
equivalent) then needs to switch based on request_type1 or request_type2

This will work fine in a development style web-app where there is no
published API.

For changes behind an API you will need to implement the switching in out/1
or the equivalent.

Gordon

On 27 June 2010 04:58, Jeremy Raymond <jeraymond@REDACTED> wrote:

> I have a web application and need to manage functional 'experiments'. An
> experiment is some functionality that's new that we want test out with a
> subset of the application's users before rolling it out to everyone,
> basically A/B testing new features. I'm looking for a clean way to manage
> the code for experiments, in essence something equivalent to:
>
> case user_in_experiment(UserId, new_feature_x) of
>   true ->
>      % do experiment functionality for new feature 'x'
>   false ->
>      % do current functionality
> end
>
> And then once we're happy with new feature 'x' make it the default
> functionality. There may be several different experiments in the code at
> any
> given time. Possible ways of accomplishing this that I've thought of are:
>
> - case statements littered throughout the code
> - encapsulating the functionality in funs and somehow do a lookup and
> select
> the right one for the current user
> - encapsulating the functionality in custom behaviors and somehow do a
> lookup selecting the right one for the current user
>
> Basically I need to be able to encapsulate and dynamically swap out
> different bits of functionality throughout the application based upon who
> is
> the current user. Anyone done something similar to this or have any
> insights
> into how they might approach such a problem?
>
> --
> Jeremy Raymond
>



-- 
Gordon Guthrie
CEO hypernumbers

http://hypernumbers.com
t: hypernumbers
+44 7776 251669