- heroku toolbelt
- AngularJS
- UIRouter
- SASS (SCSS)
- Express
- Sequelize
- express-resource
- async
- promises (from Sequelize - it's a slight derivation from BlueBird's impl.)
- Mocha tests on B/E (nearly all HTTP-level integration tests)
- F/E is mostly untested (AngularJS)
To run the full test suite:
npm test
This drops the test database, downloads the latest snapshot (created by Thomas Ku, I believe) if neccessary (only if your locally-stored snapshot it out of date), and rebuilds a test database. Then, it runs the full test suite.
If you want to run the test suite without recreating the database (which takes a minute or so), do this:
./scripts/test-backend-mocha.sh nodrop
What happens when you make a request to http://localhost:8080/artists/Wrestlers/digital-distribution?
You hit this code in apps/www/routes.js:
app.get('/artists/*', function(req, res) {
return res.render("chrome");
});...which renders a file apps/www/views/chrome.ejs whose HTML includes script tags which bring in the AngularJS application. The AngularJS application starts up, one component of which is the router, defined in public/js/www/app.js. That file contains a bunch of patterns that AngularJS matches the URL against, ultimately instantiating a controller and rendering a template ("view").
- branch off of master
- work on branch until job is done, periodically rebasing onto master
- deploy to Staging environment(s... there are at least two that I know of: studio and www) from the branch
- grunt deploy:staging --branch=your/branch/name/here
- [optional step] run migrations manually
- heroku run bash
- ./node_modules/sequelize/bin/sequelize -m
- verify your work hasn't destroyed Staging
- deploy to Production from branch
- grunt deploy:production --branch=your/branch/name/here
- [optional step] run migrations manually
- heroku maintenance:on [--app....]
- heroku run bash
- ./node_modules/sequelize/bin/sequelize -m
- heroku maintenance:off [--app ...]
- verify your work hasn't blown up Production
- merge to master (--no-ff)
The build uses several custom buildpacks to download/install things like Node.js, sox, and R. These buildpacks are referenced in .buildpacks. This file is generated by the grunt deploy task, and will use either .buildpacks-production or .buildpacks-studio as a template. I dunno why the thing was built this way. There's probably a really good reason.
- Cloudinary stores all the images
- S3 stores all the releases' audio
AUDIO UPLOAD/VERIFICATION WORKFLOW
- User selects an audio file
- Browser issues HTTP request to Express app to get signed S3 upload URL
- Express app creates signed, one-off S3 upload URL and responds to browser
- Browser does a multipart upload direct to S3, which responds with the URL of the object
- Browser then issues an HTTP POST to Express app, giving it the URL of the object i) Server streams from S3 to disk (/tmp) ii) Server runs sox against asset on disk iii) Server verifies properties of asset from sox and responds to browser request
- You'll want to get a copy of the rbss-staging database to program against locally
- Periodically, the rbss-staging database is replaced with a copy of rbss-production's database. This means that you'll want to make sure that you've provisioned accounts for yourself in rbss-production. When the copy takes place, ids of all the rows in "Users" table will remain the same as they were in rbss-production, but the email addresses will all be changed. This means you'll have to either use the new email address when logging in - or update the rows in the "Users" table on rbss-staging to match whatever they were in rbss-production.