A system dynamics modeling tool developed by the Multilevel Computational Modeling and the Transitioning to Remote Science Teaching & Learning projects at the Concord Consortium and the CREATE for STEM Institute at Michigan State University.
See the application running here: http://sage.concord.org/branch/master
- Codap – The Data Analysis Platform we are using.
- Codap Sage Icons – A shared icon font for Building Models (ivy) and CODAP.
- MySystem – a simple concept mapping with node/edge graphs.
- Model Survey – Assessing available node/edge graphing tools.
- jsPlumb – The graphing toolkit we are currently using.
- React – Javscript component development toolkit.
- MIT License – The license we are using.
-
Install the global dependencies:
- Node.js:
brew install node
on OS X `
- Node.js:
-
Check out the project and install the local dependencies:
git checkout https://github.com/concord-consortium/building-models.git
cd building-models
npm install
-
Run:
npm start
— watches the project sources in./src/
and builds artifacts intodev
and starts webserver.- Edit code in
./src/
, watch live changes in browser. (Webpack will build your changes automatically to./dev/
and will automatically refresh your browser when it sees changes there.) - Place static files you want to be copied to
dev/
insrc/assets/
If you get an node error about "too many files open," try running
ulimit -n 2560
-
Test (after
webpack
has run, or while it is running):./node_modules/mocha/bin/mocha -w
to run mocha tests (located in./test/
)
The
-w
flag should keep the tests running everytime you make a code change (ifwebpack
is still running), but occasionally a hard-error of a test will force you to start them up again. -
Test Sage running in CODAP:
- Open CODAP
- Drag a bookmark or tab pointing at http://localhost:8080 onto the CODAP pane
- For more in-depth testing, build your own copy of CODAP from GitHub
Deployments are based on the contents of the /dist folder and are built automatically by GitHub Actions for each branch and tag pushed to GitHub.
Branches are deployed to https://sage.concord.org/branch/<name>/
.
Tags are deployed to https://sage.concord.org/version/<name>/
You can view the status of all the branch and tag deploys here.
The production release is available at https://sage.concord.org
.
Production releases are done using a manual GitHub Actions workflow. You specify which tag you want to release to production and the workflow copies all of the files in that tag's version folder to the root folder.
To deploy a production release:
- Update the version number in
package.json
andpackage-lock.json
npm version --no-git-tag-version [patch|minor|major]
- Verify that everything builds correctly
npm run lint && npm run build && npm run test
- Create
release-<version>
branch and commit changes, push to GitHub, create PR and merge - Test the master build at: https://sage.concord.org/index-master.html
- Push a version tag to GitHub and/or use https://github.com/concord-consortium/building-models/releases to create a new GitHub release
- Stage the release by running the Release Staging Workflow and entering the version tag you just pushed.
- Test the staged release at https://sage.concord.org/staging/
- Update production by running the Release Workflow and entering the release version tag.
NOTE: This repo and the sage-modeler-site repo should be released at the same time, with the same version numbers, even if one of the two repos has no changes, in order to keep their version numbers in sync so that the splashscreen and top nav bar show the same version numbers. Refer to the readme in that repo for release steps.
The master English strings file is src/code/utils/lang/en-US-master.json
, which is a standard JSON file except that JavaScript-style comments are allowed. (Comments are stripped before use.) Changes to English strings should be made in the master English strings file. All other language files in src/code/utils/lang/*.json
are output files generated by script. Translations for other languages are managed via the Building Models project (authentication required) on POEditor, which provides free hosting services for open source projects.
After making changes to the master English strings file (src/code/utils/lang/en-US-master.json
), run the strings:build
script to strip comments and deploy the src/code/utils/lang/en-US.json
file for building:
npm run strings:build
To push changes to the master English strings file to POEditor, run the strings:push
script:
npm run strings:push -- -a <poeditor-api-token>
The API token must be provided as an argument to the strings:push
script or it can be set as an environment variable:
export POEDITOR_API_TOKEN=<poeditor-api-token>
To update the strings files within the project, run the strings:pull
script:
npm run strings:pull -- -a <poeditor-api-token>
As with the strings:push
script, the API token must be provided or be set as an environment variable. The strings:pull
script builds the English strings as well so all strings files will be up to date.
After pulling updated strings, the modified files can be committed to git, turned into a Github Pull Request, etc. Note that POEditor supports Github integration which could potentially automate part of this, but that requires further investigation.
Unicode escapes are converted to their UTF-8 equivalents when pushed, i.e. strings are viewed/edited in their "user" form in POEditor, and they remain in their UTF-8 form when pulled. For characters that are better left in their Unicode escape form, such as non-printable characters like ZERO-WIDTH-SPACE ("\u200b
") and the RIGHT-TO-LEFT-MARK ("\u200f
"), the scripts support a custom Unicode escape sequence such that "[u200b]
" and "[u200f]
" are converted to "\u200b
" and "\u200f
" respectively when pulled.
The ZERO-WIDTH-SPACE character can be used to indicate that the empty string is the correct translation for a string in a particular language. If the string were simply left untranslated, then POEditor would 1) show it as untranslated in the POEditor UI and 2) replace it with the English string when pulled. The ZERO-WIDTH-SPACE prevents POEditor from treating the string as untranslated, but it is rendered like an empty string.
To add a new language:
- Add the language to the POEditor project
- Add the language code to the list of languages in
bin/strings-pull-project.sh
- Add the new language file in the
languageFiles
map insrc/code/utils/translate.ts
Note that there is probably a way to eliminate the need for step 3 above by requiring all JSON files in the src/code/utils/lang
directory (except for en-US-master.json
), but that has not been implemented yet.
To update the icon fonts used in this project:
- Checkout and modify the shared icon-font project Codap Sage Icons
- Follow the directions there to deploy to github pages.
- Run
curlfonts.sh
to download a local copy of the CSS and fonts to this project.
If you want to disable Rollbar integration on your development machine just add a disableRollbar
local storage option with the value true
(as a string, all local storage values are strings). This value is checked in the index.html file prior to defining
the Rollbar configuration object and loading the Rollbar remote Javascript.
Tool for education researchers to report on Sage Modeler diagram topology. For more information see: https://www.pivotaltracker.com/story/show/177674195
- Simply browse over to /report.html and follow the instructions
- install
npm install
- Run a local webserver
npm run start
- upload files using http://localhost:8080/report.html
- Make sure you have npm & node installed.
- Install node dependencies
npm install
- Place your reporting sources (
*/.xlsx
) into theinput
folder here. - Run
npm run convert
- Output CSV files will appear in the
output
directory here.