Start with the Functional Spec which also gives the backstory for this project.
Follow the steps below. Please make a pull request if any of this isn't super straightforward or you need to do additional steps to get up and running!
Set Up The Database
Start it with running either
brew services start postgresql
to have it as a background service that will restart if you reboot or
pg_ctl -D /usr/local/var/postgres start to start it just once.
Start it with the command
sudo service postgresql start
to have it run as a background service that will restart if you reboot or
sudo -u postgres /usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start
which runs the script as the automatically created PostgreSQL user account to
start it just once.
postgresql is running on
localhost:5432. If you run
/tmp:5432 - accepting connections.
Run the following to create a user and a database. If prompted for a
password, use the password
createuser -P iwill createdb -O iwill commitsto
sudo -u postgres createuser -P iwill sudo -u postgres createdb -O iwill commitsto
Create Environment File
.env file in the root of the project directory with the following contents,
<yourname> with your name:
Run The Application
If you are running the app for the first time, or have recently pulled changes, you should run
Start each process in a separate terminal pane
- Build server in watch mode:
npm run dev:build:server
- Build client in watch mode:
npm run dev:build:client
- Start server:
npm run dev:server
Try The App
Just navigate to localhost:5000/
If you have problems connecting to the application via your browser, check that you have
made the necessary changes to the
/etc/hosts file for the subdomain you are using.
You may also need to flush the DNS cache to ensure those changes are recognized.
On Ubuntu, you can use the name service cache daemon (nscd) to flush the DNS cache.
sudo apt-get install nscd sudo service nscd restart
On MacOS, the command to flush the DNS cache will depend on your exact OS level. See How To Clear Your DNS Cache for detailed recommendations by OS version.
Run Mocha tests with
The structure and naming inside the
test/ folder should mirror the root structure and file names.
Writing code with well-contained classes or functions will be the most straightforward to unit test.
Automatic Heroku Deployment
Issue tracking labels follow the Beeminder Label Ontology. The following abbreviations, acronyms, and amusing shorthands are employed in service of bug zapping and feature enhancing:
|BUG||Opposite of feature|
|RFE||Request For Enhancement, aka feature request|
|STY||Style/polish/CSS, or think of it as in pigsty or an eyesore|
|MEN||Mendoza = need to resolve before accepting more beta users|
|SKY||Pie in the sky (would be awesome but not necessarily worth the effort)|
|ABC||Non-technical, like prose or webcopy tweaks|
|ADO||Consensus needed on what to Actually Do (or "much ado about ∅"), AKA question|
|aok||Feature, by design|
|cnr||Could not reproduce|
|nix||Won't fix or invalid|