Skip to content

Latest commit

 

History

History
90 lines (64 loc) · 5.1 KB

README.md

File metadata and controls

90 lines (64 loc) · 5.1 KB
Raw

MindMup - Zero Friction Mind Map Canvas

Build Status

MindMup is a zero-friction mind map canvas. Our aim is to create the most productive mind mapping environment out there, removing all the distractions and providing powerful editing shortcuts.

This git project is the server-side portion of MindMup. It provides a web interface that serves maps, allows users to edit and save them, provides menus and feedback forms and links to analytics. You can see an example of this live on http://www.mindmup.com.

Dependencies

  • This app is designed to run in the Heroku cloud or as a standalone Sinatra application.
  • It depends on the MapJS javascript canvas for client side rendering, and imports a compiled single-file version of that project as /public/mapjs-compiled.js
  • It uses Google Drive and Amazon S3 AWS service to store maps
  • It uses Google analytics to track feature votes, usage patterns and report error rates
  • It uses JotForm to send e-mails and submit user feedback
  • It uses Google URL shortener to produce short links for sharing

Configuration

The server depends on the following environment variables:

  • GOOGLE_SHORTENER_API_KEY Google shortener API key
  • GOOGLE_CLIENT_ID Google Drive Client Id
  • GOOGLE_ANALYTICS_ACCOUNT Google analytics ID to use for tracking. Don't use the production IDs in staging. Not used in dev and testing
  • S3_BUCKET_NAME Only the name of S3 Bucket where files are located (eg mindmup)
  • S3_KEY_ID AWS Access key ID that has write access for the bucket
  • S3_SECRET_KEY AWS Secret key corresponding to the ID above
  • S3_UPLOAD_FOLDER folder within the bucket where user maps are stored. (eg map). Avoid using the same folder for production and testing
  • S3_WEBSITE website domain name where user files are publicly accessible. Don't specify protocol or slashes (eg mindmup.s3.amazonaws.com)
  • SITE_URL public URL for the web site instance, used to get S3 to redirect back to us. Include protocol and slashes (eg http://localhost:5000/)
  • JOTFORM_CONTACT ID of the form that will receive feedback on JotForm
  • JOTFORM_SHARE ID of the form that will receive share by email requests on JotForm
  • DEFAULT_MAP name or key of the map to be shown on homepage (eg default)
  • RACK_SESSION_SECRET hashing key for rack sessions (should be relatively random, alphanumeric)
  • MAX_UPLOAD_SIZE in KB, maximum size allowed for the users to upload. If not defined, 100 is the default value
  • NETWORK_TIMEOUT_MILLIS number of milliseconds before we start reporting to users that there is a problem, in case of a timeout. Default is 10000.
  • CURRENT_MAP_DATA_VERSION prefix for files signaling the data format. For now, we use a1. This is to help in the future with format versioning

Running standalone

To run the application in standalone mode (without Heroku), create a .env configuration file (don't commit this to git) and put your S3 account info and other stuff mentioned above into that. You don't need a JotForm account to run the site (but sharing and feedback won't work without it). Then execute:

gem install foreman
bundle install
foreman start

See Heroku Configiration Local Setup for more information.

Note: Unless RACK_ENV is production, Google analytics is not used, the analytics information is instead logged to the JavaScript console.

Running offline

We don't package any of third party javascript dependencies (and there are plenty). In order to deploy faster and provide users with a better page loading experience, all third party dependencies are retrieved from CDNs where available or the S3 file storage. To run offline, set the environment variable OFFLINE to true, and run the setup_offline.sh script in the root folder to download all the dependencies to /public/offline. This enables development and testing without an internet connection.

Executing tests

We do a bunch of exploratory tests and some manual sanity tests before each release, and use this ACC Matrix to guide testing. Most client tests are in the MapJS project, so see that as well. This server does very little apart from some basic routing, so there are not many automated tests in this project. For server testing, there are a few RSpec tests that should run before commiting. Execute them with:

rspec test/*.rb

The tests don't depend on the .env file intentionally. Supply your own config as part of the test if needed.

All JavaScript widgets are tested using Jasmine, here are two ways of running tests:

  • Visual: Open test/SpecRunner.html in a browser, this will run all Jasmine tests

  • Automated: Using PhantomJs, in the test folder, run

    sh runtests.sh

Please note that the CI server uses phantomjs, so make sure that tests run with phantom before committing.