sfentress

biologica 2.0 RFC

Motivation 1

To have a more maintainable library with type definitions

Motivation 2

I have always hated needing to transform organisms back and forth between the BioLogica.Organism class objects and plain-object formats. Frequently in Geni*

sfentress

// This is what using the connected-spaces library would look like from the
// perspective of the application that is consuming it, such connected-bio.

/**  **** app.js **** */

import ConnectedSpaces from 'conected-spaces'
import PopulationsSpace from './wrapped-components/populations-space'
//...etc

render () {

sfentress

Sending message to ITS: {username: "https://learn.concord.org/users/139672-9ad0bca4", classInfo: "https://learn.concord.org/api/v1/classes/7300", studentId: "139672", externalId: 185748, session: "9ad0bca4-ef98-4b08-ad3a-309ba7fde81d", …}action: "SUBMITTED"actor: "USER"classInfo: "https://learn.concord.org/api/v1/classes/7300"context: {species: "Drake", challengeCriteria: {…}, userSelections: {…}, correct: false, incrementMoves: true, …}externalId: 185748sequence: 27session: "9ad0bca4-ef98-4b08-ad3a-309ba7fde81d"studentId: "139672"target: "ORGANISM"time: 1522956006997username: "https://learn.concord.org/users/139672-9ad0bca4"__proto__: Object
Message received from ITS: {"type":"Debug","message":"Tutor - handling: USER-SUBMITTED-ORGANISM user=139672","time":1522956007076}
Message received from ITS: {"type":"Debug","message":"Load rules from: https://docs.google.com/spreadsheets/d/1QWdalhsSfdiREucjH77Rrh8dIOdXDCbivFHxiT4RC_0","time":1522956007078}
Message received from ITS: {"type":"Debug","message":"Load rules

sfentress

sfentress

json = {...}
printDialog = function(lines) {
   for (line of lines) {
     console.log(line.character + ": " + line.text)
   }
}
levelN = missionN = challengeN = 0
for (level of json.levels) {
    levelN++
    missionN = 0

sfentress

/************************************************
FILENAME
server_simple.js
DESCRIPTION
creates a simple web server that
display "Hello World"
HOW TO START SERVER:
1) npm install firebase-admin --save
2) node simple_server.js
3) open web browser visit http://127.0.0.1:8080

sfentress

{
  "studentModel": {
    "traitScores": [
      {
        "trait": "forelimbs",
        "score": 0.5
      },
      {
        "trait": "sex",
        "score": 1

sfentress

{
    "filter": [
        {
            "key": "application",
            "list": [
                "CODAP"
            ],
            "remove": false,
            "filter_type": "string"

sfentress

Thoughts on making state-saving to Firebase, along with authoring etc., as future-proof as possible

Issues:

1. We may want to support multiple versions of the same game concurrently. E.g. two different treatments in schools, with different authoring. Or we may want a new version of authoring, but to keep the old data. (Note: this does not refer to old versions of the software -- we assume all users always have the most recent version.)
2. We may want to change the user data in breaking ways.

For (1) we can put the version number/name of the application at the root of the tree. Nothing in one version ever needs to refer to anything in another, so it should all be contained in the same branch. Possible issue: If we have permissions based on paths, every time we release a new version of the game, we need to update the permissions. The alternative would be to put the appVersion further down the leaves, but it makes it much messier and the user may have to download much more data.

For (2) we can add a version

sfentress

Thoughts on making state-saving to Firebase, along with authoring on firebase etc., as future-proof as possible

Issues:

1. We may want to support multiple versions of the same game concurrently. E.g. two different treatments in schools, with different authoring. Or we may want a new version of authoring, but to keep the old data. (Note: this does not refer to old versions of the software -- we assume all users always have the most recent version.)

2. We may want to change the user data in breaking ways.

For (1) we can put the version number/name of the application at the root of the tree. Nothing in one version ever needs to refer to anything in another, so it should all be contained in the same branch. Possible issue: If we have permissions based on paths, every time we release a new version of the game, we need to update the permissions. The alternative would be to put the appVersion further down the leaves, but it makes it much messier and the user may have to download much more data.