/old.fightforthefuture.org

Old Homepage

Primary LanguageHTMLOtherNOASSERTION

fightforthefuture.org

CircleCI

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

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