Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • RAPID-MIX_API RAPID-MIX_API
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 31
    • Issues 31
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • rapid-mixrapid-mix
  • RAPID-MIX_APIRAPID-MIX_API
  • Issues
  • #30

Design patterns for using the RAPID-MIX API

RAPID-MIX API users, as developers, would benefit from design patterns for macro or frequent use operations, that should be consistently implemented across examples.

Recommendations:

  • Users would benefit from having the "record", "train" and "run" controls and modes made as visible and explicit as possible. A design pattern that unifies this kind of usage across examples, would provide a stronger scaffolding for understanding the RAPID-MIX workflow.

  • Participants didn’t explore much feature selection in their process, sticking to what was given by default. Participants would benefit from a design pattern, or any scaffolding, that structures feature selection and the features meta-information across the examples.

  • There aren’t many examples that save/load the “configuration data” (training data set or model). It would be useful to provide a design pattern for API examples that offers selection between pre-trained models (inputing stored training data, either from local or remote storage) and a new model to be trained from scratch, so that they can explore other features of the pipeline working with data, a feature selection and ML algorithms and parameters tuning.

  • A design pattern that makes explicit the fast, realtime, and iterative nature of data streams, could benefit the users in understanding how to design with data. This could be achieved by rendering the feature vector or frame of data that is passed as input for training

Assignee
Assign to
Time tracking