assaf / vanity Goto Github PK

Some of the gems unused in testing are not compatible on non-Mac platforms (Linux). I ran "bundle install" and got the following error:

Installing autotest-fsevent (0.2.2) from rubygems repository at http://rubygems.org/ with native extensions /usr/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:482:in `build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/usr/local/bin/ruby extconf.rb
extconf.rb:19: Only Darwin (Mac OS X) systems are supported (RuntimeError)

I was going to look into some new features (issue 11 "Graceful operation if redis is down?") but can't get the tests running.

I get this on the dashboard:

NoMethodError in Vanity#index

Showing /opt/local/lib/ruby/gems/1.8/gems/vanity-1.4.0/lib/vanity/templates/_experiment.erb where line #4 raised:

undefined method `strftime' for nil:NilClass
Extracted source (around line #4):

1: <h3><%=h experiment.name %> <span class="type">(<%= experiment.class.friendly_name %>)</span></h3>
2: <%= experiment.description.to_s.split(/\n\s*\n/).map { |para| %{<p class="description">#{h para}</p>} }.join %>
3: <%= render Vanity.template(experiment.type), :experiment=>experiment %>
4: <p class="meta">Started <%= experiment.created_at.strftime("%a, %b %d") %>
5:   <%= " | Completed #{experiment.completed_at.strftime("%a, %b %d")}" unless experiment.active? %></p>

I tried to fix it manually in my console, but I got this as a result:

>> Vanity.playground.connection.set_experiment_created_at(:rank_buttons, Time.now)
=> true
>> Vanity.playground.connection.get_experiment_created_at(:rank_buttons)
=> Thu Sep 16 14:28:36 -0400 2010
>> Vanity.playground.experiments[:rank_buttons].created_at
=> nil

Not sure how it got to be nil in the first place, but any ideas about how I could hack it back together?

If you create an experiment (in the experiments folder) and then try to run the vanity migrations you get an error because vanity tries to load the experiments, but the tables that the experiments rely on aren't in the database yet.

I didn't find this error while developing because I ran the migrations first, and then created my experiments. The error showed up when I tried deploying the code to our production server which had the experiments folder but the vanity tables didn't yet exist.

When I added vanity to my Rails 3.0.10 project's gemfile, some of my view specs stopped working. For whatever reason helpers are no longer available to views in a view spec.

Here's a minimal project that demonstrates it: https://github.com/bct/vanity-view-spec-test-case

bct:/tmp $ git clone git://github.com/bct/vanity-view-spec-test-case.git
bct:/tmp $ cd vanity-view-spec-test-case/

bct:/tmp/vanity-view-spec-test-case (master) $ git checkout working
bct:/tmp/vanity-view-spec-test-case ((working)) $ rake
.

Finished in 0.0376 seconds
1 example, 0 failures

bct:/tmp/vanity-view-spec-test-case ((working)) $ git checkout broken
Previous HEAD position was 4bf3af7... add a trivial view spec
HEAD is now at f4ea23c... installed vanity

bct:/tmp/vanity-view-spec-test-case ((broken)) $ rake
F

Failures:

  1) test/test.html.erb should use a helper
     Failure/Error: render
     ActionView::Template::Error:
       undefined local variable or method `helper_method' for #<#<Class:0x00000003e76eb0>:0x0000000443a590>
     # ./app/views/test/test.html.erb:1:in `_app_views_test_test_html_erb__1578304246889205864_35702020__3512587599061084354'
     # ./spec/views/test/test.html.erb_spec.rb:5:in `block (2 levels) in <top (required)>'

Finished in 0.03473 seconds
1 example, 1 failure

I get the same result with Ruby 1.9.2-p290 and Ruby 1.8.7-p334.

Hi,

In my Rails application I rescue_from the various :not_found errors (ActiveRecord::RecordNotFound, ActionController::RoutingError, etc.) to render a template. That looks roughly like this:
rescue_from ActiveRecord::RecordNotFound do
render :template => "pages/404", :layout => 'application', :status => 404
end
Now that I've installed Vanity, when I go to a page that returns a 404, I get an error: ActionView::TemplateError (No Vanity.context). It seems like the vanity_context_filter doesn't get run for these 404 pages, and then the ab_test call that's in my application layout causes this error. Here's the backtrace:

ActionView::TemplateError (No Vanity.context) on line #50 of app/views/layouts/application.html.haml:
47:       
48:         .sidebar_item.nav
49:           = link_to "Add a FAIL", new_fail_path, {:class => 'add_a_fail'}
50:           %ul{:class => ab_test(:signup_text_size)}
51:             -if current_user
52:               %li
53:                 = link_to "Your Account", account_path

    vanity (1.3.0) lib/vanity/experiment/base.rb:180:in `default_identify'
    vanity (1.3.0) lib/vanity/experiment/base.rb:176:in `call'
    vanity (1.3.0) lib/vanity/experiment/base.rb:176:in `identity'
    vanity (1.3.0) lib/vanity/experiment/ab_test.rb:190:in `choose'
    vanity (1.3.0) lib/vanity/frameworks/rails.rb:132:in `ab_test'
    app/views/layouts/application.html.haml:50:in `_run_haml_app47views47layouts47application46html46haml'
    haml (2.2.16) lib/haml/helpers/action_view_mods.rb:13:in `render'
    haml (2.2.16) lib/haml/helpers/action_view_mods.rb:13:in `render'
    app/controllers/application_controller.rb:13:in `__bind_1269023699_679185'
    haml (2.2.16) rails/./lib/sass/plugin/rails.rb:19:in `process'

Is my suspicion of what's happening here accurate? What might be causing this? How can I work around this?

Thanks,
Alex

So I setup Vanity to track some basic metrics initially, e.g. how many comments, registrations, etc... overtime. My Metrics look like this, nothing complex:

metric "Comments" do
  model Comment
end

I'm using rails 3.0 and mysql (ActiveRecord not Redis adapter). On the Vanity Dashboard, I receive all 0s for every date even though I know there has been comments in my test data in the last 90 days.

I've identified the issue to be with the Active Record Adapter implementation of the method metric_values @ https://github.com/assaf/vanity/blob/master/lib/vanity/adapters/active_record_adapter.rb#L121

I'm working on a fix, just curious if anyone else has had this issue and if there is already a fix out there.

Hello,

I've tried to use Vanity 1.8.0 or 1.7.1 and suffered issues due vanity depending on gems that are not marked as dependencies of the vanity gem, causing failures like this:

Version 1.7.1

$ vanity report --output vanity.html
Could not find gem 'jekyll (>= 0) ruby' in the gems available on this machine.
Run `bundle install` to install missing gems.


Version 1.8.0

$ vanity report --output vanity.html
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Could not find rake-0.9.2.2 in any of the sources
Run `bundle install` to install missing gems.

The issue seems to come from this:
https://github.com/assaf/vanity/blob/master/bin/vanity

Your script depending on Bundler, attempting to install dependencies in development mode, which is affecting the Gemfile of the Rails project.

I believe that Vanity should be explicit about it's dependencies in the gemspec, and those should be required by your scripts, not by using Bundler.

This affects bundle exec and any invoke of vanity from the command line, as shown above (this happens with 1.7.1 or 1.8.0)

Even worse on 1.8.0, which depends on rake 0.9.2.2 which contradicts my current application dependencies.

Please change bin/vanity script be a simple script that perform the CLI part of Vanity and don't attempt to load Bundler/RubyGems or anything from the Gemfile.lock that will affect other application running.

Thank you ❤️

rake test runs against the live redis server, not the MockRedis implementation as the task descriptions state. I sent a pull request for a patch that fixes this.

When load is very high, we randomly get
undefined method `call' for nil:NilClass
error

/usr/local/lib/ruby/gems/1.8/gems/vanity-1.2.0/lib/vanity/experiment/base.rb:108:in `identity'

/usr/local/lib/ruby/gems/1.8/gems/vanity-1.2.0/lib/vanity/experiment/ab_test.rb:190:in `choose'

/usr/local/lib/ruby/gems/1.8/gems/vanity-1.2.0/lib/vanity/rails/helpers.rb:91:in `ab_test'

/var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:172:in format_error_reply': -ERR unknown command (RuntimeError) from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:162:informat_reply'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:105:in read' from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:35:incall'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:63:in process' from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:245:inensure_connected'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:268:in ensure_connected' from /usr/lib/ruby/1.8/monitor.rb:242:insynchronize'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:264:in synchronize' from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:268:inensure_connected'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:61:in process' from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:199:inlogging'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:60:in process' from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis/client.rb:34:incall'
from /var/lib/gems/1.8/gems/redis-2.0.10/lib/redis.rb:127:in keys' from /var/lib/gems/1.8/gems/vanity-1.4.0/lib/vanity/commands/upgrade.rb:10:inupgrade'
from /var/lib/gems/1.8/gems/vanity-1.4.0/bin/vanity:66
from /var/lib/gems/1.8/gems/vanity-1.4.0/bin/vanity:56:in each' from /var/lib/gems/1.8/gems/vanity-1.4.0/bin/vanity:56 from /home/popster/var_lib_gems/1.8/bin/vanity:19:inload'
from /home/popster/var_lib_gems/1.8/bin/vanity:19

Currently the CSS class names used in the Vanity dashboard are a bit generic and could clash with users' already in-place class names.

Examples: .experiment .metric .type

This wouldn't cause issues with elements of the users' page (especially since the CSS is just for the Vanity dashboard), but it will cause issues with elements of the Vanity dashboard since existing CSS rules would be applied to those elements.

http://github.com/assaf/vanity/blob/master/lib/vanity/templates/vanity.css

The history file is only up-to-date as of 1.7.1. This should be updated with info from the 1.8.0 release.

When choosing an alternative from the dashboard, new or existing users still get to see a random alternative and not the chosen one. Tested with the MongoDB driver under development.

In Rails 3, when running rake assets:precompile, Vanity tries to access the production Redis database. It also tries to access the SQL database if model is specified in a a metric. Unfortunately, in an app that runs on Heroku, the production database is never specified and/or accessible from the local console.

I'm not sure exactly why it would be accessing the databases when even ActiveRecord doesn't, but it needs to somehow access the information lazily rather than actively.

Out of the box on ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux] and rails 2.3.5 Vanity::Rails::Dashboard rendering failed.

I fixed the issue by adding in my VanityController

def index
# original code: render Vanity.template("_report"), :content_type=>Mime::HTML, :layout=>true
render :template => Vanity.template("_report"), :content_type=>Mime::HTML, :layout=>true
end

Vanity is too nice to be missing the game with the new kid on the block !

It would be great to be able to run experiments in Vanity based on metrics from google analytics. It would be a little messier than the current A/B tests as it would probably have to depend on using analytics' _setCustomVar() in the view. Is this something you'd consider or accept as a patch?

I'm running Vanity (8a21724) in the context of a Rails application (2.3.8).

I'm noticing that some settings in config/vanity.yml are honored (e.g. -- the Redis database location) but others aren't (e.g. -- "collecting", which I had to explicitly set in config/environments/* via Vanity.playground.collecting = true).

The rails_xss plugin simulates Rails 3.x's XSS protection by auto-escaping "unsafe" html in strings. The Vanity dashboard's use of html-in-strings, e.g.
%{

Howdy,

Vanity currently has a dependency on redis-namespace of '> 0.7', meaning that the recent version of 1.0 isn't compatible. Assuming there aren't any breaking changes, can you loosen or update that dependency? It's preventing me from updating Resque, which depends on '> 1.0'.

Thanks!
Mat

Would be nice if the plugin continued to silently work if the redis server is down -- yes, the data may not get logged, but it should not bring down the entire site. In other words, same behavior as default cache logic in Rails. If the memcached is down, it'll complain in the logs and serve everything without cache, but it continues to render the pages.

We want to stop(mark as completed) an experiment from the web-interface.

The docs link to http://vanity.labnotes.org/dashboard.html but that page is a 404. Did such a page ever exist?

I'm upgrading a rails app from 3.0.9 to 3.2.1 (ruby 1.9.3-p0). Everything is working nicely except vanity, which appears to be require a vanity_records table but provides no means to create one. I have one experiment in my app. I have vanity installed like so in my Gemfile: gem 'vanity', '~> 1.7.0', :git => 'git://github.com/assaf/vanity.git', :branch => 'rails3'

Here is the stacktrace:

** Invoke cucumber (first_time)
** Invoke cucumber:ok (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
Mysql2::Error: Table 'my_app_development.vanity_records' doesn't exist: SHOW FULL FIELDS FROM `vanity_records`
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:233:in `query'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:233:in `block in execute'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:280:in `block in log'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:275:in `log'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:233:in `execute'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/mysql2_adapter.rb:214:in `execute'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:247:in `execute_and_free'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:414:in `columns'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/connection_adapters/schema_cache.rb:12:in `block in initialize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/model_schema.rb:228:in `yield'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/model_schema.rb:228:in `default'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/model_schema.rb:228:in `columns'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/model_schema.rb:248:in `column_names'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/attribute_methods.rb:44:in `block in define_attribute_methods'
<internal:prelude>:10:in `synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/attribute_methods.rb:41:in `define_attribute_methods'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/validates_timeliness-3.0.8/lib/validates_timeliness/orm/active_record.rb:8:in `define_attribute_methods'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/attribute_methods.rb:43:in `block in define_attribute_methods'
<internal:prelude>:10:in `synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/attribute_methods.rb:41:in `define_attribute_methods'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/validates_timeliness-3.0.8/lib/validates_timeliness/orm/active_record.rb:8:in `define_attribute_methods'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/attribute_methods.rb:145:in `respond_to?'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/callbacks.rb:398:in `__run_callback'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/callbacks.rb:385:in `_run_find_callbacks'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/callbacks.rb:81:in `run_callbacks'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/base.rb:520:in `init_with'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/inheritance.rb:76:in `instantiate'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/querying.rb:38:in `block (2 levels) in find_by_sql'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/querying.rb:38:in `collect!'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/querying.rb:38:in `block in find_by_sql'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/explain.rb:40:in `logging_query_plan'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/querying.rb:37:in `find_by_sql'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/relation.rb:170:in `exec_queries'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/relation.rb:159:in `block in to_a'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/explain.rb:40:in `logging_query_plan'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/relation.rb:158:in `to_a'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/relation/finder_methods.rb:377:in `find_first'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/relation/finder_methods.rb:122:in `first'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/relation/finder_methods.rb:263:in `find_by_attributes'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activerecord-3.2.1/lib/active_record/dynamic_matchers.rb:45:in `method_missing'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/adapters/active_record_adapter.rb:148:in `set_experiment_created_at'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/base.rb:172:in `save'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/ab_test.rb:430:in `save'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/base.rb:22:in `define'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/ab_test.rb:502:in `ab_test'
~/Developer/Projects/Freelance/my_app/experiments/downgrade_subscriptions.rb:1:in `new_binding'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/base.rb:53:in `eval'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/base.rb:53:in `block in load'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/base.rb:51:in `instance_eval'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/experiment/base.rb:51:in `load'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/playground.rb:140:in `block in experiments'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/playground.rb:139:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/playground.rb:139:in `experiments'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/playground.rb:157:in `load!'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bundler/gems/vanity-4a1385954cb9/lib/vanity/frameworks/rails.rb:10:in `block in load!'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/lazy_load_hooks.rb:34:in `call'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/lazy_load_hooks.rb:34:in `execute_hook'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/lazy_load_hooks.rb:43:in `block in run_load_hooks'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/lazy_load_hooks.rb:42:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/lazy_load_hooks.rb:42:in `run_load_hooks'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/application/finisher.rb:59:in `block in <module:Finisher>'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/initializable.rb:30:in `instance_exec'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/initializable.rb:30:in `run'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/initializable.rb:55:in `block in run_initializers'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/initializable.rb:54:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/initializable.rb:54:in `run_initializers'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/application.rb:136:in `initialize!'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/railtie/configurable.rb:30:in `method_missing'
~/Developer/Projects/Freelance/my_app/config/environment.rb:5:in `<top (required)>'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/dependencies.rb:251:in `require'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/dependencies.rb:251:in `block in require'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/dependencies.rb:236:in `load_dependency'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/activesupport-3.2.1/lib/active_support/dependencies.rb:251:in `require'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/application.rb:103:in `require_environment!'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/railties-3.2.1/lib/rails/application.rb:292:in `block (2 levels) in initialize_tasks'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:176:in `block in invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:157:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:176:in `block in invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:157:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:176:in `block in invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:157:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:176:in `block in invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `invoke_prerequisites'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:157:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
~/.rvm/gems/ruby-1.9.3-p0@my_app/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bin/rake:19:in `load'
~/.rvm/gems/ruby-1.9.3-p0@my_app/bin/rake:19:in `<main>'
Tasks: TOP => cucumber => cucumber:ok => db:test:prepare => db:abort_if_pending_migrations => environment

Using rails 2.3, Bundler 0.9.26
When I have
gem 'vanity', '1.3.0'
in my Gemfile, everything works fine.
If I change that line to
gem 'vanity', '1.4.0'
my deploy blows up with:
/opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:49:in `initialize': not in gzip format (Zlib::GzipFile::Error)
at the point that it tries to do a bundle install --relock
I have no clue as to what or why this is.

I am using MongoDB, Rails, Ruby 1.9.2, and vanity was working in 1.5.1. Received Errors about Redis connection after upgrading to 1.5.2. Partial error log is pasted below.

/Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:213:in rescue in establish_connection': Connection refused - Unable to connect to Redis on localhost:6379 (NameError) from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:199:inestablish_connection'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:23:in connect' from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:224:inensure_connected'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:114:in block in process' from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:183:inlogging'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:113:in process' from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis/client.rb:38:incall'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis.rb:667:in block in setnx' from /Users/jeff/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/monitor.rb:201:inmon_synchronize'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-2.2.0/lib/redis.rb:666:in setnx' from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/redis-namespace-0.10.0/lib/redis/namespace.rb:190:inmethod_missing'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/vanity-1.5.2/lib/vanity/adapters/redis_adapter.rb:83:in set_experiment_created_at' from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/vanity-1.5.2/lib/vanity/experiment/base.rb:170:insave'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/vanity-1.5.2/lib/vanity/experiment/ab_test.rb:405:in save' from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/vanity-1.5.2/lib/vanity/experiment/base.rb:22:indefine'
from /Users/jeff/.rvm/gems/ruby-1.9.2-p180/gems/vanity-1.5.2/lib/vanity/experiment/ab_test.rb:477:in `ab_test'

Provide a method to show which tests and alternatives the current user (identity) has in an easy to use way so that you can use it as a cache string to cache a/b tested templates correctly.

having an initializer initializers/vanity.rb with
Vanity.playground.logger = Rails::logger
works, but
Vanity.playground.load_path = "app/experiments"
is ignored, the problem seems to come at rails.rb

Rails.configuration.after_initialize
Vanity.playground.load_path = "#{RAILS_ROOT}/experiments"

should be
Vanity.playground.load_path ||= "#{RAILS_ROOT}/experiments"

or something like that.

We'd like to use Vanity metrics with our project using Mongoid. After a bit of looking, it doesn't look like there is any support for it. Is anyone working on this? Would it just be another class under metrics that follows the same api as the Active Record one?

/Users/agentrock/.rvm/gems/ruby-1.9.2-head/bundler/gems/rails-5d3e8ee/railties/lib/rails.rb:44:in configuration': undefined methodconfig' for nil:NilClass (NoMethodError)

from /Users/agentrock/.rvm/gems/ruby-1.9.2-head/bundler/gems/vanity-dd154a9/lib/vanity/frameworks/rails.rb:192:in `<top (required)>'

The config does not support a password for redis. Also the redis url string doesn't seem to follow the typical scheme. For example:

mongodb://app:[email protected]:7067/app

So redis would be:
redis://user:password@host:port/

I believe I have found two bugs with Vanity when it is running inside a functional test. Before I submit a Pull Request, I wanted to make sure that what I have found are indeed bugs and not just an test implementation issue.

First off, my test looks something like this:

context "A GET to :foo" do
  context "while the 'bar_3' Vanity experiment alternative is chosen" do
    setup do
      Vanity.playground.experiment(:my_experiment).chooses('bar_3')
      get :foo
    end
    should_render "my_controller/foo/bar_3"
  end
end

I ran into two problems with this test case.

1. in lib/vanity/frameworks/rails.rb, the use_vanity method initially sets @vanity_identity to "test" which is later used to store the index of the alternative which has been specifically chosen ("bar_3" in the above example)

The problem occurs once the Controller Action is executed. the use_vanity method now sees a response object, so it then generates a new @vanity_identity which will then default to an entirely different test alternative index.

Adding an additional test to see if there is a response and it is not an instance of ActionController::TestResponse allowed Vanity to correctly set the @vanity_identity every time.

The real problem might be that @vanity_identity seems to be losing its value at some point during execution. Not sure where that would be occurring and the vanity_identity method was run once... so I'm sort of lost on that one.

def use_vanity(symbol = nil, &block)
  if block
    define_method(:vanity_identity) { block.call(self) }
  else
    define_method :vanity_identity do
      return @vanity_identity if @vanity_identity
      if symbol && object = send(symbol)
        @vanity_identity = object.id
      elsif response and not response.is_a?(ActionController::TestResponse) # everyday use
        @vanity_identity = cookies["vanity_id"] || ActiveSupport::SecureRandom.hex(16)
        cookies["vanity_id"] = { :value=>@vanity_identity, :expires=>1.month.from_now }
        @vanity_identity
      else # during functional testing
        @vanity_identity = "test"
      end
    end
  end
  around_filter :vanity_context_filter
  before_filter :vanity_reload_filter unless ::Rails.configuration.cache_classes
  before_filter :vanity_query_parameter_filter
end

2. in lib/vanity/experiment/ab_test.rb, the choose method is correctly choosing an alternative to display, but it is never saving that value to the index variable for use later on in the method. That means that it will always choose the first test (since nil.to_i == 0) which is obviously not what was explicitly chosen by the chooses method.

Adding a simple variable assignment resolved that issue.

def choose
  if @playground.collecting?
    # snip #
  else
    identity = identity()
    @showing ||= {}
    @showing[identity] ||= alternative_for(identity)
    index = @showing[identity] # Assign showing value for the current identity to index so the correct Alt. can be displayed
  end
  @alternatives[index.to_i]
end

Hopefully this was helpful. Please let me know if anymore information is needed to reproduce the bugs, I will be more than happy to provide what I can.

If the above looks good, I will submit a Pull Request once I double check Vanity's tests.

I believe I'm seeing an issue with when vanity opens a connection to redis. In particular, I believe it happens before Passenger forks the app spawner for children processes. Has anyone else seen this?

It looks like there's an issue using Vanity with redis-rb 2.2.0 if you specify the DB. The new driver accepts both :path and :db values. The old driver must've only accepted one or the other, or at the very least ignored :path if :db was provided. I'll send a pull request for the change I made to fix it, but I wasn't able to verify the problem on older redis-rb versions.

All 51 builds on http://travis-ci.org/#!/assaf/vanity/builds have failed so far.

vanity should only track "human" user agents, e.g. not google, curl or services like pingdom

Attempted using gemsets, with and without bundle exec, and several different interpreters and kept running into this issue. Was hoping to commit something back to mainline, but would love to run tests first :) Any advice on how to resolve?

Stack trace:

** Invoke test (first_time)
** Execute test
/Users/Nick/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -I"lib" -I. -I"/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib" "/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rake_test_loader.rb" "test/adapters/redis_adapter_test.rb" "test/experiment/ab_test.rb" "test/experiment/base_test.rb" "test/metric/active_record_test.rb" "test/metric/base_test.rb" "test/metric/google_analytics_test.rb" "test/metric/remote_test.rb" "test/passenger_test.rb" "test/playground_test.rb" "test/rails_dashboard_test.rb" "test/rails_helper_test.rb" "test/rails_test.rb" 
/Users/Nick/Projects/Estately/vanity/test/experiment/ab_test.rb:4:in `<class:AbTestController>': undefined method `use_vanity' for AbTestController:Class (NoMethodError)
    from /Users/Nick/Projects/Estately/vanity/test/experiment/ab_test.rb:3:in `<top (required)>'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `block in require'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:547:in `new_constants_in'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rake_test_loader.rb:15:in `block in <main>'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rake_test_loader.rb:4:in `select'
    from /Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rake_test_loader.rb:4:in `<main>'
rake aborted!
Command failed with status (1): [/Users/Nick/.rvm/rubies/ruby-1.9.2-p290/bi...]
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils.rb:53:in `block in create_shell_runner'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `call'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `sh'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `sh'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils.rb:82:in `ruby'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `ruby'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/testtask.rb:99:in `block (2 levels) in define'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:60:in `verbose'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/testtask.rb:98:in `block in define'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/Users/Nick/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/bin/rake:19:in `load'
/Users/Nick/.rvm/gems/ruby-1.9.2-p290/bin/rake:19:in `<main>'
Tasks: TOP => test

First problem I've found with the tests is that they are written with the assumption that rubygems is required automatically, which I feel is bad form.

The second problem is that they seem extremely brittle and environment-dependent. I'm curious if they pass for anyone.

Example:
#test/rails_test.rb:162
ensure
File.unlink yml
end

In this case, yml is a file, but File.unlink takes a path to a file as an argument, not an actual file object.

Changing this to:
ensure
File.unlink yml.path
end

Makes this test pass.

For the most part, Vanity is running great for us on our production site. However, once every few days I see an exception looking something like :

RuntimeError: No Vanity.context
vendor/gems/vanity-1.2.0/lib/vanity/experiment/base.rb:180:in `default_identify'
vendor/gems/vanity-1.2.0/lib/vanity/experiment/base.rb:176:in `call'
vendor/gems/vanity-1.2.0/lib/vanity/experiment/base.rb:176:in `identity'
vendor/gems/vanity-1.2.0/lib/vanity/experiment/ab_test.rb:190:in `choose'
vendor/gems/vanity-1.2.0/lib/vanity/frameworks/rails.rb:132:in `ab_test'
app/views/shared/_header.haml:20:in `_run_haml_app47views47shared47_header46haml_locals_header_object'

but of course I can never actually reproduce it, and it goes away again as soon as it appears. Any bright ideas what might cause that?

-Jonathan

This bug from MRI 1.9, http://redmine.ruby-lang.org/issues/show/3140, shows that an incorrect behavior was introduced which makes it possible to autoload modules from gems.

This is actually incorrect, a formal require is needed instead. Also, other implementations need to require rubygems explicitly.

Going forward, the loop will be closed on 1.9, so Vanity will have issues with it as well.

This is the outcome of the discussion on Vanity tests running over Rubinius:
http://github.com/evanphx/rubinius/issues/issue/388/#comment_288977

We run daily security scans against our site and the scanning host is showing up in experiment results. Is it possible to ignore hosts and subnets so they don't pollute our tests?

Getting the following deprecation warning in rails 3.2.2

DEPRECATION WARNING: Passing a template handler in the template name is deprecated. You can simply remove the handler name or pass render :handlers => [:erb] instead. (called from block in vanity_js at /Users/Hiroki/.rvm/gems/ruby-1.9.3-p0@grapi/bundler/gems/vanity-5ab986ba8026/lib/vanity/frameworks/rails.rb:220)

Seem to be able to fix this by removing the .erb in line 220 of rails.rb, however haven't tested this extensively. (https://github.com/assaf/vanity/blob/master/lib/vanity/frameworks/rails.rb#L220)

Suggested fix:

from:
render :file => Vanity.template("_vanity.js.erb")
to:
render :file => Vanity.template("_vanity.js")

https://github.com/assaf/vanity/blob/master/lib/vanity/frameworks/rails.rb#L220

As far as I can tell the namespace option is not actually getting used for the redis keys, is that the case?

The following error is shown when trying to access http://localhost:3000/vanity

Template is missing

Missing template c:/Ruby192/lib/ruby/gems/1.9.1/gems/vanity-1.7.1/lib/vanity/templates/_report with {:handlers=>[:erb, :rjs, :builder, :rhtml, :rxml, :haml], :formats=>[:html], :locale=>[:en, :en]} in view paths "c:/Users/epetre/Burndown-Charts/app/views", "c:/Users/epetre/Burndown-Charts/vendor/plugins/xss_terminate/app/views", "c:/Users/epetre/Burndown-Charts/vendor/plugins/dynamic_sitemaps/app/views", "c:/Ruby192/lib/ruby/gems/1.9.1/gems/openid_active_record_store-1.0.1/app/views", "c:/Ruby192/lib/ruby/gems/1.9.1/gems/devise-1.4.5/app/views", "c:/Users/epetre/Burndown-Charts", "c:/"

When launching rake resque:work on my rails 3.1 application I get an "undefined 'metric'" error. Seems like resque inspects the milestone files before Vanity is loaded. Any idea on how I can fix this ?

Using the latest vanity from git, and the latest resque gem.

Thanks for the support !

rake resque:work
 ** Invoke resque:work (first_time)
** Invoke resque:preload (first_time)
** Invoke resque:setup (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute resque:setup
** Execute resque:preload
rake aborted!
undefined method `metric' for main:Object
path_to_my_ruby_app/app/experiments/metrics/milestone_one_visits.rb:2:in `<top (required)>'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:456:in `load'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:456:in `block in load_file'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:640:in `new_constants_in'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:455:in `load_file'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:342:in `require_or_load'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:302:in `depend_on'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:214:in `require_dependency'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.1.1/lib/rails/engine.rb:417:in `block (2 levels) in eager_load!'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.1.1/lib/rails/engine.rb:416:in `each'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.1.1/lib/rails/engine.rb:416:in `block in eager_load!'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.1.1/lib/rails/engine.rb:414:in `each'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.1.1/lib/rails/engine.rb:414:in `eager_load!'
/home/rodrigob/.rvm/gems/ruby-1.9.2-p290/gems/resque-1.19.0/lib/resque/tasks.rb:47:in `block (2 levels) in <top (required)>'

(and more....)

This page says that redis.yml will be used if present in a Rails project. It doesn't say what the file's contents should look like. since lib/vanity/frameworks/rails.rb does sets Vanity.playground.redis, the config needs to be a string as in:

development:
  "localhost:6379"

The commit at akahn/vanity@2029de5 adds this to the documentation.

Cheers,
Alex

I tried to use vanity with rails 2.3.8 and mysql adapter.

When I call track! helper, I get error:

"Vanity::Adapters::ActiveRecordAdapter is not missing constant VanityMetricValue!"
/rails_app/vendor/rails/activesupport/lib/active_support/dependencies.rb:417:in load_missing_constant' /rails_app/vendor/rails/activesupport/lib/active_support/dependencies.rb:96:inconst_missing'
/rails_app/vendor/rails/activesupport/lib/active_support/dependencies.rb:98:in rescue in const_missing' /rails_app/vendor/rails/activesupport/lib/active_support/dependencies.rb:95:inconst_missing'
/rails_app/vendor/rails/activerecord/lib/active_record/base.rb:1:in block in compute_type' /rails_app/vendor/rails/activerecord/lib/active_record/base.rb:2232:inclass_eval'
/rails_app/vendor/rails/activerecord/lib/active_record/base.rb:2232:in block in compute_type' /rails_app/vendor/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:11:insilence_warnings'
/rails_app/vendor/rails/activerecord/lib/active_record/base.rb:2230:in compute_type' /rails_app/vendor/rails/activerecord/lib/active_record/reflection.rb:156:inklass'
/rails_app/vendor/rails/activerecord/lib/active_record/reflection.rb:187:in quoted_table_name' /rails_app/vendor/rails/activerecord/lib/active_record/associations/has_many_association.rb:97:inconstruct_sql'
/rails_app/vendor/rails/activerecord/lib/active_record/associations/association_collection.rb:21:in initialize' /rails_app/vendor/rails/activerecord/lib/active_record/associations.rb:1306:innew'
/rails_app/vendor/rails/activerecord/lib/active_record/associations.rb:1306:in block in collection_reader_method' /home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/adapters/active_record_adapter.rb:115:inblock in metric_track'
/home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/adapters/active_record_adapter.rb:114:in each' /home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/adapters/active_record_adapter.rb:114:ineach_with_index'
/home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/adapters/active_record_adapter.rb:114:in metric_track' /home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/metric/base.rb:140:intrack!'
/home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/playground.rb:217:in track!' /home/vitali/.rvm/gems/ruby-1.9.2-p290@shoedazzle/gems/vanity-1.8.0/lib/vanity/helpers.rb:59:intrack!'


I am getting the following error when running my tests with after
setting up vanity with postgresql.

PGError: ERROR: relation "vanity_metrics" already exists

The only way to work around this error is by removing the vanity code
from the schema.

What is the proper way to handle this? Is this a known issue?

Hi,

I'm having an issue where Vanity is successfully tracking a metric, but not giving me numbers for the alternatives. This screenshot shows the problem. Out of 1,245 participants, 0.0% for each alternative. But I know that people have signed up. 16, in fact. Looking at my data in Redis, vanity:1:signup_text_size:alts:0:conversions is 10 and vanity:1:signup_text_size:alts:1:conversions is 6.

Here's my a/b test:
ab_test "Signup text size" do
description "Does increasing the size of the signup text increase signups"
alternatives "big", "normal"
metrics :signup
end

Here's the metric:
metric "Signup" do
description "Measures how many people signed up"
end

Here's UsersController#create:
def create
@user = User.new(params[:user])
if @user.save
track! :signup
flash[:message] = "Thank you for signing up! You are now logged in."
redirect_back_or_default account_url
else
render :action => :new
end
end

And then in the layout template I have:
%ul{:class => ab_test(:signup_text_size)}

Any idea what I'm doing wrong here? I can verify that folks are seeing each alternative. Vanity is clearly tracking the metric. Why is there no percentage for each alternative?

Thanks,
Alex