/fightforthefuture.github.io

Homepage

Primary LanguageHTMLOtherNOASSERTION

fightforthefuture.org

Campaigners

All your documentation has been moved to the wiki.

Developers:

Review apps are launched on Heroku automatically. The site itself lives on github, but there is a clone on Heroku. We don’t currently have any failover automation, but it’s definitely something to aspire to.

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

  • 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: GitHub Pages

fightforthefuture.org is hosted on GitHub Pages. Here’s how it works: every time a commit is pushed, Travis CI runs a build. Every time a pull request is merged on the the production branch, the result of that build is committed and pushed to master.

Heroku

Because having a backup plan is always a good idea, and the Heroku pipeline feature is awesome, we deploy there too. We get two great things out of this. First, every time a commit is merged into production—assuming the build isn’t broken—http://fftf-org.herokuapp.com/ is deployed, leaving us a backup plan for the next time GitHub does the angry unicorn dance.

The other fun part about having the site connected to a Heroku pipeline is that it gives us the chance to play with review apps. They're a one-click deploy from the app’s pipeline dashboard. If you want your review app to connect to (our internal middleman for) the Action Network API, make sure to set its URL and PETITIONS_API env variables. (note: you generally won’t need these for local or production deployment)

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.

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