a-laughlin / 3308proj

Experimental monorepo to develop/build/test/package/publish/import multi-langugage personal utilities. Currently includes functional-programming-focused JS and Python, plus a few experimental post-hooks-release React utils.

Tech: Lerna, Yarn Workspaces, React, Jest, XStream, and PyUnit.

3308proj's Issues

Command line function makes initial model output something

Model is outputting predictions based on test/input data.

The model is receiving and using input/test data that is then being outputted after some manipulation or transformation or interpretation.

build_api() and test_api() exist

once we start on the API, we need a command to trigger it during the build process

unnecessary since no build process at this time

mobile framework decided

Decision! React Native!

determine mobile build process

pytorch example works local machine

Find or create sample test data

We need some test data to check our systems with until we can gather data from a person. If you want to search Kaggle or elsewhere for data that already exists, that is great, but if you can create the data that will also work.

Acceptance criteria:

• Sample data placed in /sample_data/ml_input_foo.json

Depends on #68

something mobile-ish

separate git issue creation/editing messages from pushes/prs/etc messages into other slack channel

Just silenced them vs creating another channel since I couldn't see much actual value for having that channel, and it would just fill up our chat message limit

Display something in the mobile environment.

The mobile display shows when run in the environment.

API Implemented

Story
TBD

Acceptance Criteria
TBD

Depends on
#90
#91

Relates to

command line function runs initial data pipeline

once we start on the data pipeline, we need a command to trigger it during the build process

Mobile emulator works with initial build/framework.

As a dev, I want to compile/build mobile framework without issues

Find working example of ODEnet in Pytorch

add mobile build process to build.py

design first desired ui screenshot

design a chart chart that lets us see heart metrics over time - as an image, so we know what we're shooting for

Check out this for a start. Needs the finer details, but generally are these the features and level of simplicity that we are looking for? Are there buttons to see more?
https://www.draw.io/#G1SKYtFiFRkupw96zOcPijXFS53BzDOeZ3

Decision: Chart by itself!

ML frameworks decided

V0.0 React components written

Story

As a user, I should see a chart composed of react components displaying a time series with historical and predicted heart rates

Acceptance Criteria (from

• svg for container
• Text axes markers
• Lines for axes
• Lines for axes tick marks
• Polyline for historical rendered from faked data
• Dashed Polyline for predicted trend from faked data
• tests written (that the chart has all the right components and they look correct)
• styling work in desktop and mobile (check using chrome dev tools)

Depends On

• #85

Relates To

• react components decided in meeting with @cspowell1225 and @a-laughlin. Documented (here)

add thomas to repo collaborators

project parts (e.g., ML, mobile) buildable/testable from command line

Closing until we know more about API decisions, heroku, etc. We'll actually have deployment then.

Story: as a dev, I should be able to build any part of the project from the command line without going into python.

Maybe something like
$ build.py <part> <action>
e.g.
$ build.py mobile build
$ build.py mobile test
$ build.py ml test
$ build.py api test
$ build.py * test tests all of the above
$ build.py * build && build.py * test builds and tests all of the above
$ build.py mobile build && build.py * test builds mobile then tests all of the above

determine mobile test process

duplicates a subset of #67

Risks/Mitigation Strategies

pm tool documented in readme

duplicates #12

add ML build process to build.py

Story
As a dev I should be able to run the ML part with a command line function, which creates an output file with some arbitrary data, so we know pytorch is working as expected.

Acceptance Criteria
build.py build_ml() creates an output file with arbitrary content
assert output file exists
assert file contents is what's expected

Depends on

• NA

Relates to

• #51

Build initial ML model that accepts heart beat data as input

Update torchdiffeq example to work with our own input (1d array).

decide v0.0.0 outcome

• command line function makes initial mobile part display initial ui on mobile simulator
• command line function makes initial ML part output something
• we have initial architecture document
• code pushing flow diagram works with github/travis
• build.py integrates all command line functions and tests

------- ^^ v0.0.0 outcome ^^ --------

prerequistes (tickets to add)

• mobile framework decided
• ML frameworks decided
• model is outputting predictions from working sample
• display 1 time series of random numbers
• display on mobile
• mobile emulator working
• mobile emulator running tests
• decide mobile framework

v0.0.1

• command line function runs initial API
• command line function runs initial data pipeline

integrate mobile build and test process in to build.py

we have initial architecture document

duplicates #30

command line function displays initial ui on mobile simulator

Optimize ML model architecture

code "Definition of Done" in README

Before merging into master, each code issue should include tests and documentation.

Until a testing framework is implemented, assertions are fine.

we have initial architecture document

data pipeline build process added to build.py

split github process flow messages into separate slack channel

command line function makes initial mobile

unnecessary

ML directory with README created

#36 depends on this

command line function makes initial ML part output something

command line function calls pytorch example

Unnecessary currently. Will become so if API needs it. Closing as clutter for now.

Milestone 1 items broken down

Split these into cards:

• Add initial project info to a README.md file in the repository:
  • Project title
  • Team members' names
  • Vision statement: what would you tell potential customers?
  • Motivation: why are you working on this project?

• Risks to project completion, possibly including
  • new language or working environment
  • no prior experience working with these team members
  • lack of some needed resources

• Risks1 documented in Readme
• Risks1 Mitigation Strategies documented in Readme

• Risks2 documented in Readme
• Risks2 Mitigation Strategies documented in Readme

• Project Management process decided: (e.g., scrum, kanban: with specifics!)
  • issue ownership
  • issue selection
  • issue flow
  • done defined (should include documentation - docs should generally not be separate tickets)
  • project tracker supports pm process stages
  • project tracker supports dev process stages (coordinate with dev process person)
  • project tracker comm channel integration
  • project tracker Issue type templates (to ensure we include all necessary things in each issue)
  • meeting scheduling strategy decided
  • schedule coordination method/tool chosen
  • calendaring tool chosen
  • comm channels decided
  • pm process communication plan decided (tentatively, pm process state updates notified in slack channels/github for flexible subscription)
  • process reviewed with team
  • initial meetings scheduled

• Development processes decided:
  • Create a github repository with all team members as collaborators
  • dev process communication plan decided (tentatively, dev process state updates notified in slack channels/github for flexible subscription)
  • project tracker supports dev process stages (coordinate with pm process person)
  • dev process supports done definition
  • Branching/Merging process
  • code/functionality review process
  • project tracker supports dev process stages
  • project tracker version control integration
  • version control comm channel integration
  • continuous integration + version control integration
  • continuous integration + comm channel integration
  • CI server comm channel integration
  • Issue type template checking (to ensure we include all necessary things in each issue)
  • integration testing framework decided

• mobile|ML|dpipe|api development process decided
  • mobile|ML|dpipe|api linting/prettifying automated
  • mobile|ML|dpipe|api unit testing framework
  • mobile|ML|dpipe|api unit testing framework CI integration
  • mobile|ML|dpipe|api behavior testing framework
  • mobile|ML|dpipe|api behavior testing framework CI integration
  • mobile|ML|dpipe|api dev process integrated with github
  • mobile|ML|dpipe|api dev process documented in readme

pm process documented in readme

command line function displays initial ui in mobile emulator

duplicates a subset of #67

2/17 Notes

initial build script created

creating mobile directory README

as a dev, I should see blank README file in the src/mobile directory so I have something to document in

Process tooling added to readme

Basically a discussion of how github project is configured to work with our dev process

code pushing flow diagram works with GitHub/travis

Story:
As a dev, I should have a basic CI dev flow working on each push, so that I can add code changes to master safely and efficiently.

Acceptance Criteria:

• Pushing to our personal branch should build the project on Travis
• Travis should build and test the project's various parts with build_all() and test_all() on each new push to our branch
• we can open a PR from our branch to master any time, but the PR cannot be merged into master until test_all() passes on Travis
• Explicit override to merge a PR even when tests don't pass should be possible, in case Travis is having issues. I think the override ability is Github's default, so likely nothing to do on this one.

Depends on:

• #48
• #51
• travis config permissions (can get from Adam)
• github repo settings config permissions (let adam know what you need)

Relates to:

• #63 phase 1 (travis configured to build mobile)

For reference, though the order is slightly different:

Move stuff in meeting notes into tickets

build py integrates all command line functions and tests

Project Management process added to readme

(e.g., scrum, kanban: with specifics!)

process diagrams added to readme

done before we had story parts.

get Travis CI working with tests, so we can see them pass before merging

#21 depends on this