For founders of purpose-driven companies and initiatives who want to create a scalable, autonomous and focussed organisation structure and culture. Our simple online initiative mapping tool visualises who has taken responsibility for what and who is helping who to meet those responsibilities So that people throughout the organisation can:

• make autonomous decisions while at the same time supporting the autonomy of others, all the way up to the founder holding the overall vision
• see how responsibilities throughout the organisation feed into the greater system
• enjoy greater transparency
• avoid the tyranny of heavy-weight processes, bureaucracy and excessive management.

The latest version of the app is running at https://app.maptio.com.

To launch it on your local server, see the Setting up dev section.

• Angular
• Typescript
• Bootstrap
• D3
• Express

Additionally , we use these services/packages :

• Angular Tree Component angular2-tree-component
• Auth0 for authentication as a service
• Cloudinary for image storage/retrieval

You must have Node.js (> 7.10.1) installed. For local development please install MongoDB (Community Edition) too.

git clone https://github.com/Safiya/maptio.git
cd maptio/

Unforutnately, Maptio currently relies on external services, many of which need to be set up for the app to work. If you'd like to set them up, please use the .env.sample template to create a .env file in the root folder and use the environment variables there as a guide for what services to set up and what environment variables to obtain from them.

We're aware that this makes setting up Maptio for local development difficult and hope to be able to improve this - and all help is very much welcome! Please see #811 for a discussion and to share your thoughts.

To keep your data locally, create a new folder in the root of the repository called local_data and run the MongoDB demon pointing it to that folder:

mongod --dbpath=./local_data/

Next, point the app at the database by commenting out the MONGODB_URI environment variable and pointing to your new database, e.g.:

#MONGODB_URI=mongodb://<PRODUCTION URI>
MONGODB_URI=mongodb://localhost:27017/maptio

npm install
npm start

A webpack analyzer window might open at http://localhost:8888, ignore this for now.

Go to http://localhost:4200 to see it in the browser.

If you have previously logged in to the app locally using the production database, you will find it's now impossible to log in to the app locally if it's using your local database. To fix this, open developer tools and remove everything under Application > Local Storage > http://localhost:3000.

For development, it's enough to just use a trial account, because you can always clean up the database and start again (but ideally we should work out a better local development account workflow at some point!).

Using an empty database locally (as described above) is not always enough (e.g. performance issues only appear with sufficiently complex maps). Connecting to the production database locally is dangerous as it may lead to data loss. To avoid both issues, we can back up the production database and restore it to our own local MongoDB instance. To do this, please follow the instructions below.

If you followed the instructions above, you can simply delete the local_data folder (back it up first if that might be useful):

mv local_data local_data_backup
mkdir local_data

mongod --dbpath=./local_data/

First, you'll need to copy the production MONGODB_URI variable from the .env file. Then, paste it into the following command and execute the command:

mongodump --uri "<MONGODB_URI>" --out ./prod_db_backup

The mongodump command should be installed with the MongoDB installation (checked with MongoDB Community Edition 4.4 installed via homebrew on MacOS).

The previous command should have copied all data from the prod DB to the prod_db_backup folder. Now we need to populate our local MongoDB database with that data simply by running (note this will only work if an instance of MongoDB is running locally on the default port as it should be after step 2 above):

mongorestore prod_db_backup

You should now be able to see production data locally if you log in to maptio with an account that is part of an existing organisation.

By default source mapping doesn't work locally because of the integration with FullStory. It can be re-enabled by simply commenting out the scripts in index.html

The app is hosted on heroku. There are two heroku projects, one for the production server (app.maptio.com) and one for the staging server:

• maptio-eu (production) on heroku

The app uses MongoDB as its database. There is currently only one database set up in the cloud. It powers both the production and the staging sites (caution required!). It is hosted on MongoDB Atlas:

• MongoDB Atlas instance

CircleCI is used to run tests on every branch:

• Maptio on CircleCI Deployments are done on Heroku based on pushes to branches on github, which orchestrates the CI steps. See more below.

Authentication is managed through Auth0. The production account is used locally and on staging too for now.

• Auth0 productin account

Cloudinary is used to store user profile images, with the same account serving production, staging and local environments. The account can be accessed through Heroku login in the resources section.

• Cloudinary login through Heroku resources

At the start of the project Code Climate was used to keep track of code quality. It's not used that much anymore but might still be useful in the future.

• CodeClimate

The following services are used for analytics and/or logging:

• FullStory
• LogRocket
• Mixpanel - link to be added later

We use CircleCI, Code Climate and Heroku for deploying to https://app.maptio.com.

Any git push in the master branch will triggers the following events :

1. Build and run tests on CircleCI
2. If pass, analyse on CodeClimate and report test coverage & quality metrics
3. Deploy to Heroku at https://app.maptio.com

Each step is logged on our private Slack maptio.slack.com, in the #build channel

We use GitHub issue tracker.

Ideally Pull requests and commits should reference the issue number (See this guide)

Tests are written in Jest and ran with Jest.

• Single run

npm test

• Auto updated run

npm run test:watch

• Generate test coverage

npm run test:coverage

Locally, you can follow test coverate statistics by opening ./coverage/index.html in a browser (generated with Istanbul)

Enabled/disabled rules can be found in .codeclimate.yml

In general, we use standards rules from out of the box TSLint.

TODO

MongoDB hosted on MongoDb Atlas, ORM is MongoJS.