leftees / scheduler

Scheduling solution for a content-heavy conference, built on Rails

scheduler

Scheduling solution for a content-heavy conference, built on Rails

Status badges

How to get started developing on this project

• Rails 4.2.5 is the current base install. Ruby version is defined in Gemfile as 2.2.1, with automatic RVM config in .ruby-gemset and .ruby-version.
• To get started, you should obtain RVM, and execute rvm install 2.2.1; rvm use 2.2.1; rvm gemset create scheduler
• PostgreSQL is the database, and requires setup on each development instance. development and test environments currently make the following assumptions:
  • The database is located on localhost and is accessible via UNIX socket
  • The PostgreSQL user matching your username can be authenticated as the current user via a passwordless authentication mechanism. You may need to edit your pg_hba.conf to achieve this - setting your user to peer authentication via UNIX sockets is a working method.
  • The PostgreSQL user has the CREATEDB privilege (as postgres execute ALTER USER {username} CREATEDB)
  • Heroku users should be fine, as long as the DATABASE_URL is set in the environment. Likewise, if you wish to override these settings, you can also craft a DATABASE_URL environment variable to do so.
• capybara-webkit is required by this project and will be installed automatically into your gemset by bundler.
  • It depends upon Qt being installed, and preferably Qt5. This can be achieved with brew install qt on OSX, or sudo apt-get install qt5-default libqt5webkit5-dev on Linux Mint.
  • It also depends upon a JS driver of some description, so you may need to sudo apt-get install nodejs too, if you don't already have one installed.
  • The approach to back and front end testing roughly follows this advice from Thoughtbot.
• Once these pre-requisites have been satisfied, you should be able to run the setup script at bin/setup.

Development process

• All work should be performed on a separate branch, which is then pushed to the Github repository.
• A pull request into master should then be created for that branch, which will trigger Hound, Travis and Coveralls.
• The pull request will be reviewed by another committer, and either merged, or have further changes requested.
• Pull requests which either break Travis or cause Hound style violations will not be merged until these are resolved.

Testing approach

We should ideally use a TDD/BDD approach:

• Start with a new issue / user story and branch, as described above.
• Write a breaking feature test in Capybara that describes expected behaviour, in spec/features/[behaviour]_feature_spec.rb. Consider using js: true to run tests in a headless browser when JS is likely to be used.
• Write subtests / unit tests as necessary to simplify requirements, going from the outside in, i.e. feature test, routing tests, view tests, controller tests, model tests.
• Unit tests should mock or stub code outside of their own purview, whereas feature tests can roam through the entire codebase. We should never make actual calls to live APIs or external services during test running though.
• Write code to solve the tests, working recursively up the chain of broken tests and ensuring that any knock-on test failures elsewhere are resolved.
• Do not make a pull request if you have any test failures. They need to be fixed. Ideally, don't make a pull request with any tests set to 'pending' either.
• We can't reasonably achieve full test coverage on code generated by Rails itself, but we should be able to get 100% coverage on our own code, using mocks and stubs as necessary.
• Code coverage is measured at time of pull request on GitHub, using Coveralls. SimpleCov is included in the Gemfile, but is not set up for local reporting. Less than 100% isn't a guaranteed blocker, but it will be taken into account in approving the request.

There are a few gems that may be included later in development to improve testing capabilities, notably FactoryGirl to generate test data, and Webmock to break on attempted external calls.

Style notes

• Hound CI uses Rubocop with the community Ruby style guide and so do we. All pull requests will return in-line comments on style violations.
• Rubocop is included in the Gemfile under dev and can be used to find and fix style issues on your local dev environment.

Deploying the project to Heroku

We're using Heroku as a handy way of trying out the project on a live platform with minimal fuss. To deploy to Heroku:

• You'll need a Heroku account. Sign up at https://www.heroku.com/ if necessary.
• Set up a dev environment using the instructions above, and use git to clone the project to your local environment.
• Follow these instructions from Heroku's site to set up Heroku toolbelt, log in to Heroku CLI, create a dyno, push your master branch to the dyno, and migrate the database schema.
• If you just want to deploy the master branch, the Heroku instructions will see you right. If you want to deploy a different branch, use git push -f heroku local-topic-branch:refs/heads/master to deploy your current branch to Heroku.
• Heroku run rake db:[whatever] is your friend for sorting out the database. We may add the option to generate test data at a later point.

There are some Heroku-specific modifications to the codebase:

• production.rb has a line that creates a secret key on the dyno.
• Gem rails_12factor in Gemfile is required for Heroku.

Contributor Code of Conduct

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.

Examples of unacceptable behaviour by participants include:

• The use of sexualized language or imagery
• Personal attacks
• Trolling or insulting/derogatory comments
• Public or private harassment
• Publishing other's private information, such as physical or electronic addresses, without explicit permission
• Other unethical or unprofessional conduct

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviours that they deem inappropriate, threatening, offensive, or harmful.

By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.

Instances of abusive, harassing, or otherwise unacceptable behaviour may be reported by contacting a project maintainer at [email protected]. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.

This Code of Conduct is adapted from the Contributor Covenant, version 1.3.0, available at http://contributor-covenant.org/version/1/3/0/