The Money Advice Service's improved website.
Ruby HTML CSS JavaScript Gherkin CoffeeScript Other
Switch branches/tags
Latest commit 008225a Apr 24, 2017 @thecountgs thecountgs committed on GitHub Merge pull request #1715 from moneyadviceservice/8125_homepage_floati…

[DEV APPROVED] #8125 Floating homepage chat
Failed to load latest commit information.
app Merge pull request #1715 from moneyadviceservice/8125_homepage_floati… Apr 24, 2017
bin Make SHA refs links in version diff Mar 10, 2016
config Merge pull request #1705 from moneyadviceservice/8056_endofyear_warning Apr 4, 2017
db #6931 & #6876 Remove Survive January Jan 21, 2016
features added rspec tests for floating chat feature Apr 19, 2017
lib Merge pull request #1691 from moneyadviceservice/7938-resize_promo_ar… Mar 16, 2017
public change deadline for deprecation email Jan 16, 2017
spec added rspec tests for floating chat feature Apr 19, 2017
vendor/assets/javascripts add new env variable for webchat client testing (#1533) Sep 15, 2016
.bowerrc Add HTML5 Shiv dependency Jan 13, 2014
.csslint Revert "csslint does not recognise flexbox - fixed" Jun 25, 2014
.env-example [WIP]Ignore env file to remove sensitive app variables from repo (#1689) Mar 1, 2017
.env.test fix change of api endpoint Sep 8, 2015
.envrc Use Spring binstubs without having to think Jan 9, 2014
.gitattributes Update .gitattributes Jan 29, 2014
.gitignore [WIP]Ignore env file to remove sensitive app variables from repo (#1689) Mar 1, 2017
.hound.yml Revert "Change rubocop path in hound config" Oct 15, 2014
.jshintrc Fix missing trailing comma in JSHint config. Oct 31, 2014
.node-version Add .node-version config for those using nodenv May 2, 2014
.rspec Remove CI rspec config to the main file and move to CI test file Feb 6, 2015
.rubocop.yml Bin callback requester feature Nov 26, 2015
.ruby-gemset Adding gemset Jan 14, 2014
.ruby-version Use ruby 2.2.5 Oct 5, 2016
Gemfile TP: 8038, Comment: Updates version number for rio to 1.18.0 Apr 6, 2017
Gemfile.lock update newrelic_rpm agent gem to latest version (#1712) Apr 10, 2017
LICENSE Initial commit Dec 19, 2013
Procfile Manage application processes with Foreman Dec 19, 2013 [WIP]Ignore env file to remove sensitive app variables from repo (#1689) Mar 1, 2017
Rakefile Rubocop fixes Mar 17, 2015
apiary.apib Add Apiary prototype for static pages. Jun 3, 2014
bower.json.erb TP: 8107, Comment: Updates version of Yeast Apr 11, 2017 add ${ASSET_CONTAINER} variable to build script Jul 28, 2016 Skeleton Rails 4 application Dec 19, 2013
package.json Removing flickering cucumber test Dec 2, 2015 Make sure is running CI tests using features.yml Nov 7, 2016


Code Climate

The Money Advice Service's responsive website.



Clone the repository:

$ git clone --recursive

Make sure you've added the following line to your /etc/hosts file gems.test.mas

Make sure all dependencies are available to the application:

$ bundle install
$ bowndler install

Install Mysql 5.5

$ brew tap homebrew/versions
$ brew install mysql55

Make sure MySQL is running.

$ brew services start mysql55

Setup the database:

bundle exec rake db:create && bundle exec rake db:schema:load

Copy the features.yml.sample to the config dir:

cp config/features.yml.sample config/features.yml

Make sure to copy the .env-example file:

cp .env-example .env

then set .env variables (i.e. GOOGLE API KEY) stored in KeepassX to run tests locally

## Usage

To start the application:

$ foreman s

Change CMS URL Path

In development, frontend will use the local CMS for convenience. You can change the MAS_CMS_URL on .env file. Use to point to LIVE content, for testing Or http://localhost:PORT to point to a local running CMS.

Don't forget to restart the server after the modification.


  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Keep your feature branch focused and short lived
  4. Commit your changes (git commit -am 'Add some feature')
  5. Push to the branch (git push origin my-new-feature)
  6. Create new Pull Request

Feature Toggles

We favor Feature Toggles over Feature Branches. To define features create a configuration file, config/features.yml with toggles for various features that are pending:

  an_active_feature: true
  an_inactive_feature: false

At runtime you can use these toggles in order to decide whether or not to show a feature: # => true/false

Feature.inactive?(:an_active_feature) # => true/false

Feature.with(:an_active_feature) do
  # code

Feature.without(:an_active_feature) do
  # code

Our feature toggles are designed to be used to hide partly built features, often referred to as release toggles. A toggle and any conditional behaviour must be removed once a feature is complete.

Note that the local configuration file config/features.yml is ignored in git so make sure to run any acceptance tests with the feature toggled on and off locally.

If you need to enable a feature in any tests you can use tags. For example, in feature tests you can use:

Scenario: View great new feature
  When I visit the website
  Then I should see this great new feature

Where the cucumber tag @enable-feature-name will enable the feature feature_name for the cucumber scenario.

Feature Development

We like to develop features from the outside in. We write our user stories in a declarative style. When contributing a feature:

  1. Create a new feature file in features.
  2. Write scenarios to exercise the scope of the feature in it's entirety.
  3. Create page objects in features/support/ui and expose them to the world in features/support/world/pages.rb.
  4. Start with a failing scenario then make it pass.
  5. Write unit tests for the objects you identify for your feature.
  6. Start with a failing unit test then make it pass.
  7. Keep your unit tests isolated.
  8. Test the Routing, Models, Controllers, Decorators, Helpers and JavaScript of your feature.
  9. Test your features against the mock API and record interactions with VCR.


The application is backed by a RESTful JSON API. This is described for humans as a blueprint file using the API Blueprint Language Specification. Changes you make to the blueprint file will be automatically reflected in the online API documentation and mock API.


The application includes an internal styleguide for contributors. It contains a living CSS styleguide, JavaScript styleguide and some recommendations on how to write Ruby code. As a contributor you should update the styleguide as you update the application. The CSS styleguide is powered by KSS, a documenting syntax for CSS.

### Writing front-end code

There are a number of documents to help everyone write maintainble, performant and readible HTML, CSS and Javascript.

We recommend having a flick through these when working on new features:

Front-end Package Management

The application uses Bower to manage front-end packages. Dependencies should be defined in the bower.json configuration file. Once installed they will be automatically available to the asset pipeline.

Consuming the front-end without having to manually import dependencies

We have a couple of projects that live outside of this website, but benefit from having the generated HTML and CSS. I.e. they don't need to manually import Dough, Yeast, and MAS Dough Theme, etc.

Useful if you're an agency and want to get up and running quickly, we render both English and Welsh versions of our 'empty' template. This can then be pulled in via curl or good old view-source and copying & pasting.

There are minor differences to the header and footer in the empty template, to enable the HTML to run in a static fashion. For example, we remove the authentication links in the header as they require knowledge about the user's sessions – which can't easily be shared across multiple sites, domains, etc.

This is done via a hide_elements_irrelevant_for_third_parties? flag in the views.

Projects such as RAD keep this stored in their repo, and have a simple CSS file that overrides or adds the bits they want.



We use Draper for decorators. Decorators help us to keep logic out of our views, avoid procedural helpers and ensure our models are free of any presentational concerns.

Running Karma javascript tests

Run the following in the command line.

RAILS_ENV=development bundle exec rake karma:install karma:run_once

Deploy to staging and production

Today the current process occurs in GO. You need to change the build number here:

Make sure before you changed and open a PR to run the follow script and paste on the PR description:

./bin/mas-version-diff 1869 1870

Obs.: 1869 and 1870 is just an example of versions to be shown. Use the GO build number in ascending order.