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.