There can be only one
Hilanders goal is to encourage and promote awesome work through points and badges. Focusing on rewarding great work through positive point allocation instead of negative point deduction is a major goal of the project.
- Clone it
bundle installbundle exec rake db:create db:migrate db:data_migraterails s- Hit
http://localhost:3000
- Fork it
- Create your feature branch (
git checkout -b my-new-feature) - Commit your changes (
git commit -am 'Add some feature') - Push to the branch (
git push origin my-new-feature) - Create new Pull Request
We use the data_migrations gem for seed data
To keep our data migrations seperate from the schema migrations*, we use ashmckenzie's data_migrations gem.
To create a new migration (e.g. add a new metric):
$ rails g data_migration:new <name of migration> # similar to rails g migration <name of migration>
$ rake db:data_migrate # similar to rake db:migrate
Please see the data_migrations docs for further info.
*Please note this means the Rails migrations are for schema changes only
Adding a new Metric
(consider adding a wiki page for this)
- Write a capybara feature test (see spec/features for examples of what we test)
- Watch it fail
- Add your new metric to the database by running a data migration to add the new row to the metrics table (see above)
- Add the metric name to the Metric::NAMES array. This automagically creates a new post endpoint in the format "/api/your-metric-name.json" - see the routes file, or run $ rake routes to verify). All metric posts are redirected to the events#create action, with the metric name merged into the params with key :metric.
- Implement a PayloadAdapter for your metric only if the base one isn't compatible with the JSON payload you're expecting.
- Implement a PayloadValidator for your metric only if you require additional/customised checks before creating the event.
- Run your test again... watch it pass
Configuring badges for your new metric
TBC