How should your broadcasting fees be spent? Publish your support and improve the program.
Public broadcasting in Germany receives €8,000,000,000 (eight billion euros) annually, yet it is subject to no public feedback, ranking, or even debate on what constitutes value or quality.
On rundfunk-mitbestimmen.de you can say how your €17.50 per month should be spent. It is a proof of concept how digital democracy can work for publicly funded media and it is a win-win situation for both sides: More influence for the audience. More data for broadcasters.
Rundfunk mitbestimmen is maintained by the community. We have regular meetings, run online pair-programmings and tutorials in our online learner community at Agile Ventures. You can join our Slack here and then find us in our channel #rundfunk-mitbestimmen. Here is the Youtube Playlist of our recent meetings or pair-programmings:
This repository contains three important folders:
The backend is responsible to store the data. Who wants to pay for which
broadcast and how much? Users are related to broadcasts via impressions
in the
database. The response
on the impression model can be either negative
,
neutral
and positive
and indicates whether a user wants to give money to a
broadcast. If the response
is positive, the amount
further specifies how
much to pay for a broadcast. So, the sum of all amounts per user must not exceed
the monthly fee of 17,50€ per month.
The frontend should be as easy to use as possible. The user can login and register, fetch a set of not yet voted broadcasts, decide about broadcasts, assign money and see the public statistics. Most of these actions will send requests to the backend. The frontend should be comfortable to use, e.g. by default amounts are evenly distributed with the option to set the amount explicitly.
We do full stack testing with Cucumber and Capybara. We specify the requirements as user stories in our Github issues and implement them as cucumber features. The cucumber features are a good starting for you to understand the current behaviour and the reasoning behind it.
Here is our model how to write tests. The cucumber tests are at the top. As they test the entire stack, cucumber tests tend to be rather slow in execution but in return they deliver some confidence that the system works.
Make sure you have docker
and docker-compose
installed:
$ docker --version
Docker version 18.05.0-ce, build f150324782
$ docker-compose --version
docker-compose version 1.22.0, build unknown
Clone the repository:
git clone https://github.com/roschaefer/rundfunk-mitbestimmen.git
You can setup the development environment with:
cd rundfunk-mitbestimmen
docker-compose up
This can take a while... As soon as this is finished, create the database and run migrations with:
docker-compose run --rm backend rails db:create db:migrate
App is running on localhost:4200
If you want, you can create some seed data
docker-compose run --rm backend rails db:seed
Run frontend tests:
docker-compose run --rm frontend ember test
Run backend tests:
docker-compose run --rm backend bin/rspec
For fullstack testing, use the provided docker-compose override:
docker-compose -f docker-compose.yml -f docker-compose.fullstack-testing.yml up
When all containers are up, run the cucumber tests in the fullstack
service with:
docker-compose run --rm fullstack bundle exec cucumber
Make sure that you have a recent version of node, yarn, EmberJS, ruby, Redis and postgresql installed before you proceed. E.g. we have the following versions:
$ node --version
v10.4.1
$ yarn --version
1.7.0
$ ember --version
ember-cli: 3.1.4
node: 10.4.1
os: linux x64
$ ruby --version
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
$ psql --version
psql (PostgreSQL) 9.6.5
$ redis-server -v
Redis server v=5.0.1
git clone https://github.com/roschaefer/rundfunk-mitbestimmen.git
cd rundfunk-mitbestimmen
bundle
cd frontend
yarn install
cd ../backend
bundle
(OPTIONAL): Customize the file backend/config/database.yml
to match your local database configuration.
Now make sure that postgresql database is running
[linux]$ sudo systemctl start postgresql
[macos]$ brew services start postgresql
Create the databases and run the migrations:
rails db:create db:migrate
You need to have redis running
[linux]$ sudo systemctl start redis
[macos]$ brew services start redis
Then you can seed the data
cd backend
rails db:seed
cd ..
Start the backend and sidekiq:
cd backend && rails s
cd backend && bundle exec sidekiq
Open another terminal and start the frontend:
cd frontend && ember server
App is running on localhost:4200
Run the frontend server:
cd frontend && ember server --environment=fullstack
Open two more terminals and run the backend server and sidekiq:
cd backend && rails server --environment=fullstack
cd backend && bundle exec sidekiq
Open yet another terminal and run the tests:
bundle exec cucumber
These environments serve the purpose to
If you want to run chrome or firefox instead of headless chrome, you can set an environment variable:
bundle exec cucumber DRIVER=chrome
or
bundle exec cucumber DRIVER=firefox
cd frontend && ember test --server
cd backend && bin/rspec
See our detailed contribution guidelines :mag:
We use this project board as our central issue tracker. Issues are ordered by priority and you can filter for good first issue
if you are interested in a beginner-friendly task.
Additionally, issues are tagged with backend
and frontend
depending on where code needs to be changed.
Don't be afraid of our identity provider Auth0. In development environment your login will reach the "rundfunk-testing" instance of Auth0. This will not pollute the Auth0 instance used in production.
git checkout -b [issue number]_my_new_feature_branch
features/[site of change]/your.feature
and copy+paste the feature description from GitHubbundle exec cucumber
features/step_definitions/steps.rb
and write expectationsbundle exec cucumber
- tests should failbundle exec cucumber
- tests should passgit commit -am 'Add some feature'
git push origin -u [issue number]_my_new_feature_branch
Our build server Travis CI takes care about automatic deployment. Approximately 15 minutes after your pull request was merged into master, you should see the changes in production.
See the LICENSE file for license rights and limitations (MIT).