fightforthefuture.org

Campaigners

All your documentation has been moved to the wiki.

Developers:

https://www.fightforthefuture.org/ is hosted on Amazon S3 and CloudFlare.

Housekeeping

Dependencies:

• See .ruby-version for expected Ruby
• Node and npm versions are declared in package.json

Here’s a thing—this is not a willy-nilly slapdash combination of underscores, dashes, and camelCase. There is a method to its madness. Underscores are used in Ruby variables. All over the place in yml and Liquid. Dashes are used in Less/CSS. Because that is how it is done. And camelCase is BFFs with Javascript. They are meant for each other.

Frameworks and libraries

• Jekyll
• Grunt.js

Installing & running the server

• Copy the .env.sample file and name the new file .env.
• Copy the _config_petition_ids.yml.sample file and name the new file _config_petition_ids.yml.
• If don't have ruby installed, follow these instructions to setup your environment with rbenv, and then run gem install bundler.
• Run bundle install
• npm install. First this makes sure bundle is installed, then it installs npm packages & ruby gems.
• npm start to run grunt (compiles assets, then watches for changes and compiles those too.)

Deploying

Production: Amazon S3

fightforthefuture.org is hosted on Amazon S3. Here’s how it works: every time a commit is pushed to the production branch, Circle CI runs a build and deploys that to an S3 bucket.

Local Deploys

1. Ensure that you have the AWS CLI installed
2. Create a named profile in ~/.aws/credentials called fftf-s3-deploy with valid credentials.
3. npm run deploy

Blog

The blog content is pulled from Tumblr using scripts/sync_tumblr.js and an AWS Lambda function triggers a Circle CI build whenever a new Tumblr post is detected.

Code Structure

CSS/Less

• All Less files compiled and minified to public/css/core.css
• When in doubt, make a new Less file and import it in core.less—there’s no real performance hit as a result of good organization
• Don’t worry about browser prefixes. Grunt handles that too.
• Follow the 18F Front end style guide

Javascript

This is all aspirational, a boilerplate being applied to a legacy codebase

• js/main.js will generally be used to contain the main page logic.
• js/controllers will contain all Composer controllers
• js/models is there for Composer models and collections
• js/views not just for Composer views, but for individual page logic on pages that have absolutely zero relationship with Composer. Also, regarding Composer views: use raw markup where you can, for speed.
• This all compiles down to public/js/core.js via grunt, which also uglifies it - If you’re adding a javascript file that ought to be included in core.js, make sure to add its path to the files array inside the concat task in Gruntfile.js