Cities evolve constantly, but in most cases, it's still only city councils and various committees that decide on the scope, schedule and nature of changes made to city infrastructure. The decision makers could be greatly helped by an app that would:
- Let people rate the places they visit or pass every day on their way to work or school and suggest improvements (renovation, creation of green spaces, etc.).
- The app should consider the direction from where the user is coming.
- User ratings could then be combined with traffic information and the density of nearby attractions (shops, cinemas, monuments, etc.) to identify which places/elevations would be best the candidates for improvement.
- Decision makers could thereby focus on improving the everyday lives of people by making small incremental changes in their surroundings.
You can use the Map, Search, Routing and Traffic APIs and SDKs to create this app on mobile or web. The TomTom Maps APIs and SDKs (for Web/JavaScript, Android, iOS) are available on http://developer.tomtommaps.com and can be used for free once you create an account.
Now that you've got the code, follow these steps to get acclimated:
-
Update project name and description in
package.json
and.travis.yml
files -
npm install
, oryarn install
- whatever you're into -
Create two postgres databases:
boilermaker
andboilermaker-test
(you can substitute these with the name of your own application - just be sure to go through and change thepackage.json
and.travis.yml
to refer to the new name)- By default, running
npm test
will useboilermaker-test
, while regular development usesboilermaker
- By default, running
-
Create a file called
secrets.js
in the project root- This file is
.gitignore
'd, and will only be required in your development environment - Its purpose is to attach the secret env variables that you'll use while developing
- However, it's very important that you not push it to Github! Otherwise, prying eyes will find your secret API keys!
- It might look like this:
process.env.GOOGLE_CLIENT_ID = 'hush hush' process.env.GOOGLE_CLIENT_SECRET = 'pretty secret' process.env.GOOGLE_CALLBACK = '/auth/google/callback'
- This file is
-
To use OAuth with Google, complete the step above with a real client ID and client secret from Google
- You can get them here: https://console.developers.google.com/apis/credentials
-
Finally, complete the section below to set up your linter
npm run start-dev
will make great things happen!
If you want to run the server and/or webpack separately, you can also npm run start-server
and npm run build-client
.
From there, just follow your bliss.
Ready to go world wide? Here's a guide to deployment! There are two (compatible) ways to deploy:
- automatically, via continuous integration
- manually, from your local machine
Either way, you'll need to set up your deployment server to start:
- Set up the Heroku command line tools
heroku login
- Add a git remote for heroku:
-
If you're creating a new app...
heroku create
orheroku create your-app-name
if you have a name in mind.heroku addons:create heroku-postgresql:hobby-dev
to add ("provision") a postgres database to your heroku dyno
-
If you already have a Heroku app...
heroku git:remote your-app-name
You'll need to be a collaborator on the app.
(NOTE: This step assumes that you already have Travis-CI testing your code.)
CI is not about testing per se โ it's about continuously integrating your changes into the live application, instead of periodically releasing new versions. CI tools can not only test your code, but then automatically deploy your app. Boilermaker comes with a .travis.yml
configuration almost ready for deployment; follow these steps to complete the job.
- Run
git checkout master && git pull && git checkout -b f/travis-deploy
(or use some other new branch name). - Un-comment the bottom part of
.travis.yml
(thebefore_deploy
anddeploy
sections) - Add your Heroku app name to
deploy.app
, where it says "YOUR HEROKU APP NAME HERE". For example, if your domain iscool-salty-conifer.herokuapp.com
, your app name iscool-salty-conifer
. - Install the Travis CLI tools by following the instructions here.
- Run
travis encrypt $(heroku auth:token)
to encrypt your Heroku API key. Warning: do not run the--add
command suggested by Travis, that will rewrite part of our existing config! - Copy-paste your encrypted API key into the
.travis.yml
file underdeploy.api_key.secure
, where it says "YOUR ENCRYPTED API KEY HERE". git add -A && git commit -m 'travis: activate deployment' && git push -u origin f/travis-deploy
- Make a PR for the new branch, get it approved, and merge it into master.
That's it! From now on, whenever master
is updated on GitHub, Travis will automatically push the app to Heroku for you.
Some developers may prefer to control deployment rather than rely on automation. Your local copy of the application can be pushed up to Heroku at will, using Boilermaker's handy deployment script:
- Make sure that all your work is fully committed and pushed to your master branch on Github.
- If you currently have an existing branch called "deploy", delete it now (
git branch -d deploy
). We're going to use a dummy branch with the name "deploy" (see below), so if you have one lying around, the script below will error npm run deploy
- this will cause the following commands to happen in order:
git checkout -b deploy
: checks out a new branch called "deploy". Note that the name "deploy" here isn't magical, but it needs to match the name of the branch we specify when we push to our heroku remote.webpack -p
: webpack will run in "production mode"git add -f public/bundle.js public/bundle.js.map
: "force" add the otherwise gitignored build filesgit commit --allow-empty -m 'Deploying'
: create a commit, even if nothing changedgit push --force heroku deploy:master
: push your local "deploy" branch to the "master" branch on herokugit checkout master
: return to your master branchgit branch -D deploy
: remove the deploy branch
Now, you should be deployed!
Why do all of these steps? The big reason is because we don't want our production server to be cluttered up with dev dependencies like webpack, but at the same time we don't want our development git-tracking to be cluttered with production build files like bundle.js! By doing these steps, we make sure our development and production environments both stay nice and clean!