Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
It's important to note that running this reset will drop any existing data you have in the application
- Step 1:
heroku restart
- Step 2:
heroku pg:reset DATABASE
(no need to change theDATABASE
) - Step 3:
heroku run rake db:migrate
- Step 4:
heroku run rake db:seed
(if you have seed)
One liner
# See http://m.onkey.org/running-rails-performance-tests-on-real-data | |
# fixed to work with Rails 3.2.8 | |
# START : HAX HAX HAX | |
# Load Rails environment in 'test' mode | |
RAILS_ENV = "test" | |
require File.expand_path('../../config/environment', __FILE__) | |
# Re-establish db connection for 'performance' mode | |
silence_warnings { RAILS_ENV = "performance" } |
after "deploy:symlink", "deploy:restart_workers" | |
after "deploy:restart_workers", "deploy:restart_scheduler" | |
## | |
# Rake helper task. | |
# http://pastie.org/255489 | |
# http://geminstallthat.wordpress.com/2008/01/27/rake-tasks-through-capistrano/ | |
# http://ananelson.com/said/on/2007/12/30/remote-rake-tasks-with-capistrano/ | |
def run_remote_rake(rake_cmd) | |
rake_args = ENV['RAKE_ARGS'].to_s.split(',') |
# See http://m.onkey.org/running-rails-performance-tests-on-real-data | |
# fixed to work with Rails 3.2.15 | |
# START : HAX HAX HAX | |
# Load Rails environment in 'test' mode | |
ENV["RAILS_ENV"] ||= "test" | |
require File.expand_path('../../config/environment', __FILE__) | |
# Re-establish db connection for 'performance' mode | |
ActiveRecord::Base.establish_connection(:performance) |
# here's a quick recipe to run a performance test | |
# with this method, you can: | |
#-> easily choose the examples you want included from your existing specs | |
#-> define the target number of total iterations you'd like, no limit | |
#-> tune the transaction mix by specifying frequency metadata for each example | |
#-> be happy that the transaction mix is fairly homogeneous over the test interval | |
# (ideally you'd run this with acceptance (webrat/capybara) specs, but you | |
# could employ this technique for any rspec test) |
namespace :deploy do | |
# To avoid having to add a password for sudo, visudo and add | |
# deployusername ALL=(ALL) NOPASSWD: /etc/init.d/unicorn reload | |
task :start do | |
sudo "/etc/init.d/unicorn start" | |
end | |
task :stop do | |
sudo "/etc/init.d/unicorn stop" |
I want to build a system which uses rules. These rules will change hourly (i.e. "this rule is effective from 2pm to 6pm"). The rules must support arbitrarily complex logic on just 2-3 pre-defined variables and result in a boolean:
item.a > 10 && item.b == 0 || item.category == FOOTWEAR
These rules will be executed hundreds of times per second so I can't afford the overhead of plain old eval
. I want to reload the current effective ruleset from the database hourly, precompile each rule's logic string and execute it via the quickest method possible. It might look something like this:
class Rule