This is a Chrome App that acts as an uploader client for Tidepool. It is intended to allow you to plug diabetes devices into your computer's USB port, read the data stored on them, and upload a standardized version of the data to the Tidepool cloud.
This README is focused on just the details of getting the uploader running locally. For more detailed information aimed at those working on the development of the uploader, please see the developer guide.
Table of contents
How to set it up
- Clone this repository.
- Set the config for the environment you want to target (see Config below)
npm start(This will bundle the application with webpack and watch for changes. When it stops printing output you can continue to the next step.)
- Open Chrome. Go to chrome://extensions and turn on Developer mode (checkbox on the top line).
- Click "Load Unpacked Extension".
- Choose the directory where you cloned the repository and click OK.
You may see a warning from Chrome concerning the inclusion of a key file. (
This extension includes the key file '<project_path>/node_modules/webpack-dev-server/node_modules/sockjs-client/node_modules/eventsource/test/key.pem) This is due to the loading of all the
node_modulesand their various internal testing utilities. This isn't a security issue, nor is the associated key used or referenced anywhere in the running code and can safely be ignored.
- To run it, you can choose "Launch" from the chrome://extensions page. You can also run it from the Chrome App Launcher, which Chrome may install for you whether you want it or not.
index.htmllink in the section of chrome://extensions devoted to the uploader. (Note: this link will only appear after you've launched the uploader.)
Configuration values (for example the URL of the Tidepool Platform) are set via environment variables. If you need to add a config value, modify the
.config.js file. If you need to read a config value inside the app, use
var config = require('./lib/config'). To set config values (do this before building the app), you can use Shell scripts that export environment variables (see config/local.sh for an example that exports the appropriate variables when running the whole Tidepool platform locally using runservers), for example:
$ source config/local.sh $ npm start
For ease of development we have several debug features that developers can turn on and off at will (and to suit various development use cases, such as working on a new device driver versus working on the app's UI). Each of these debug features is set with an environment variable, but rather than being loaded through
.config.js (as we do for production configuration variables, see above), we load these through the webpack
DefinePlugin (see Pete Hunt's webpack-howto for an example, although note Hunt uses the term 'feature flag').
The environment variable
DEBUG_ERROR (boolean) controls whether or not errors sourced in device drivers are caught and an error message displayed in the UI (the production setting) or whether they are thrown in the console (much more useful for local development because then the file name and line number of the error are easily accessible, along with a stack trace).
DEBUG_ERROR mode is turned on by default in
The environment variable
REDUX_LOG (boolean) controls whether or not the redux logger middleware is included. This middleware logs all redux actions in the Chrome developer console, including the (entire) previous and following app state trees. It is primarily useful when working on the UI of the app, and in fact can be quite performance-expensive (especially when uploading a device, due to the fact that every update to the progress bar constitutes an action), so it is not recommended to turn it on while working on device code.
The environment variable
REDUX_DEV_UI (boolean) controls whether or not the redux dev tools UI is included. The redux dev tools add a UI interface for exploring - and, to a limited extent, manipulating - app actions and state. Even when
true, we have the dev tools hidden by default: the key combination
ctrl + h will toggle their visibility. The key combination
ctrl + q will rotate (clockwise) the location at which the dev tools are anchored; the default is for them to be anchored at the bottom of the app. Similarly to the redux logger middleware, the redux dev tools UI is also quite performance expensive and only recommended for use while working on UI code.
REDUX_DEV_UI are both turned on by default in
Local Development w/o Debug Mode(s)
All debug options are turned off by default in
There are two sets of (unit) tests for the code in this repository.
To run the tests in this repository as they are run on Travis CI, use:
$ npm test
To run just the UI tests in both PhantomJS and Chrome locally, use:
$ npm run browser-tests
To run just the device and data-processing tests in node, use:
$ npm run node-tests
To run just the UI tests in PhantomJS with webpack & Karma watching all files for changes and both rebundling the app and re-running the tests on every change, use:
$ npm run test-watch
Linting & Code Style
.eslintrc configuration file.
To run the linter (which also runs on Travis CI with every push, along with
npm test), use:
$ npm run lint
NB: Please keep ES5 and ES6/ES2015 code distinct. Do NOT use ES6/ES2105 features in ES5 modules (most easily recognizable by the use of
require rather than
Publishing (to the devel/staging testing & development Chrome store account or production)
When you're ready to merge your pull request, first
- Use the command
mversion minor -mto bump the version number and create a tag. (You will need to
npm install -g mversionif you don't have mversion installed already.)
- Push the new tag commit and tag up to GitHub with
git push origin <branch_name>and
git push origin --tags.
- Merge your approved pull request.
Assuming you've already merged any changes to master and are on master locally...
- Start with a fresh Terminal window and
cdinto the chrome-uploader repo. (Alternatively, just make certain you haven't set any environment variables locally; but jebeck likes to start fresh to be absolutely certain of this.)
- Checkout the tag you wish to build, using
git checkout tags/<tag_name>.
- Remove your node modules with
rm -rf node_modules/. (This may not always be necessary, but it's good to be safe in case anything has changed.)
- Make sure you are using node v0.12.7 and install fresh dependencies with
- Build the
npm run build. Look for the "Using the default environment, which is now production" message at the beginning of the build process. (You can check the success of a build (prior to publishing) by pointing 'Load unpacked extension' from chrome://extensions to the
- Follow instructions in secrets for actually publishing to the Chrome store.
- Fill out the release notes for the tag on GitHub and attach
dist.zipto your notes. This is so that if you built for the development Chrome store, you can then distribute the same
dist.zipto the production Chrome store without having to rebuild everything. If the tag is known to not be a release candidate, mark it as a pre-release.