Add a person to a group

@ahdinosaur edits:

with an object of relationships the agent has indexed by type, for each type of relationship, render a section with the label of the relationship type and list of the other agents.

https://github.com/craftodex/app/blob/master/src/node_modules/ui/index.js#L16-L130

#populate-data

http://craftodex2.enspiral.info/

no idea why, as it works fine locally.

/cc @simontegg

/groups/enspiral-craftworks

root@craftodex:~# dokku logs craftodex2
Error: Requested Range Not Satisfiable
    at SendStream.error (/app/node_modules/serve-static/node_modules/send/index.js:239:16)
    at SendStream.send (/app/node_modules/serve-static/node_modules/send/index.js:533:19)
    at /app/node_modules/serve-static/node_modules/send/index.js:630:12
    at Object.oncomplete (fs.js:108:15)
Error: ENOENT, open '/app/data/groups/craftworks.yml'

/app/src/node_modules/fs-storage/index.js:116
          queue.push(this);
                ^
TypeError: Object #<Object> has no method 'push'
    at Object.<anonymous> (/app/src/node_modules/fs-storage/index.js:116:17)
    at null.<anonymous> (/app/src/node_modules/fs-storage/index.js:63:14)
    at fs.js:272:14
    at Object.oncomplete (fs.js:108:15)

npm ERR! [email protected] start: `node .`
npm ERR! Exit status 8
npm ERR! 
npm ERR! Failed at the [email protected] start script.
npm ERR! This is most likely a problem with the craftodex package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node .
npm ERR! You can get their info via:
npm ERR!     npm owner ls craftodex
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.13.0-43-generic
npm ERR! command "/app/vendor/node/bin/node" "/app/vendor/node/bin/npm" "start"
npm ERR! cwd /app
npm ERR! node -v v0.10.35
npm ERR! npm -v 1.4.28
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /app/npm-debug.log
npm ERR! not ok code 0

npm ERR! [email protected] prod: `NODE_ENV=production npm start`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] prod script.
npm ERR! This is most likely a problem with the craftodex package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     NODE_ENV=production npm start
npm ERR! You can get their info via:
npm ERR!     npm owner ls craftodex
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.13.0-43-generic
npm ERR! command "/app/vendor/node/bin/node" "/app/vendor/node/bin/npm" "run" "prod"
npm ERR! cwd /app
npm ERR! node -v v0.10.35
npm ERR! npm -v 1.4.28
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /app/npm-debug.log

@simontegg what do you reckon we should do with https://github.com/craftodex/core? i'm wondering if that would make a good top-level repo to put in the open-app org.

https://github.com/anvaka/ngraph.graph seems like a sweet data structure for graphs, it's even sweeter as we can use various rendering systems with this common data structure (including WebCola if we make it compatible).

i think a first pass at this means making a derived property in Agent called 'relGraph' that returns a ngraph.graph object of the agent's related agents and relationships.

this isn't a huge priority, but i think it's something we should keep in mind if we want Holodex to be accessible to as many people as possible. the size will certainly move up and down with changes, so this issue is more about how we can take size snapshots and a reflection on the current size snapshot.

right now, our current (refactor-api branch) minified bundle size is 911.87 kB, which after gzip is 209.61 kB.

npm i -g pretty-bytes
npm run build
cat src/assets/bundle.js | wc -c | pretty-bytes
cat src/assets/bundle.js | gzip | wc -c | pretty-bytes

most of these bytes are not from our own code, it's from our dependencies. we can nicely visualize our dependencies with disc, which allows us to browse the true size of Holodex here.

npm i -g disc
./node_modules/.bin/browserify . --full-paths | ./node_modules/.bin/uglifyjs > src/assets/bundle.js
discify src/assets/bundle.js curl -sT- https://htmlb.in

some random notes on our current dependencies:

• react is massive at 279.2kB, wow (is react worth it over the slimmer virtual-dom?)
• react-bootstrap is also decently sized at 87.8kB
• lokijs is reasonable at 42.3kB
• webcola is somewhat okay at 68.5kB (is webcola worth it over the slimmer ngraph.forcelayout?)
• we have two readable-streams at ~20kB each
• got requires browserify-zlib at 62.2kB in order to gunzip the response.

these are open questions, i don't have any answers, nor is this really a big deal right now. 🐁

User views enitities as nodes within a network of related entities.

• npm-ify webcola
• adapt webcola to React
• node-item (person)
• edge-item (memberOf)
• render @graph json as react-svg nodes and edges

Notes:
In a view "members of craftworks" the relationship "memberOf -> Craftworks" is redundant and gives a boring graph where everyone has an edge to the group. Solution: show subrelationships (other groups etc) using webcola's disconnect self option

• receive flat graph
• for each entity in graph
  • parse for relation links
  • construct and register model
• link up relations across models in graph
• return requested model

it seems as though visualizing data is well-described as a constraint satisfaction problem. i wonder what would be possible if we were to build some tooling around this idea, where not only can we do node layout through solving constraints but also the size of the nodes, etc.

begin link dump:

• http://gridstylesheets.org/
• https://github.com/petehunt/react-gss
• https://github.com/slightlyoff/cassowary.js
• https://www.npmjs.com/package/verlet-constraint (uses WebGL)
• https://github.com/anvaka/ngraph.forcelayout

atm it's shit.

possibly related to livereload:server

some console output:

...
livereload:server LRWebSocketConnection(C5) received {"command":"hello","protocols":["http://livereload.com/protocols/official-6","http://livereload.com/protocols/official-7"],"ver":"2.0.8","snipver":"1"} +489ms
wsio:hybi websocket writing +643ms {"command":"hello","protocols":["http://livereload.com/protocols/connection-check-1","http://livereload.com/protocols/official-7","http://livereload.com/protocols/saving-1"],"id":"default id","name":"default name","version":"1.0"}
...

....
livereload:server LRWebSocketConnection(C5) received {"command":"info","plugins":{"less":{"disable":false,"version":"1.0"}},"url":"http://localhost:3000/"} +179ms
wsio:hybi websocket writing +115ms {"command":"reload","path":".bundle.js","liveCSS":true}
wsio:hybi websocket writing +136ms {"command":"reload","path":".bundle.js","liveCSS":true}
....

should we do it or not?

i'm starting to think maybe we should.

possible code styles:

• standard.

the router singleton is available with require('router') and then you can use router.navigate to set the router state (which should trickle the state back down, however now i realize this will cause the fetcher to re-fetch but that's why i'm keen to tackle this so it informs what needs work).

initially between 'list view' and 'graph view'.

View a person's account info

• name [string]
• handle [string]
• location [array]
• relationships the person has by type [object of arrays]

I'm currently implementing very simple semantic queries in the ui:

• [People in] [Group]
• [People who] [belong to] [Group]

this might get more complex:
[Groups to which] [Person] [belongs]

I collect research on how to do this here

Sort a list of people in a group by relevant account details

rcss
Khan Academy on RCSS.

Version 8.0.5 (10600.5.3.1)

Value: Several people have expressed interest in holodex. We can direct them to the production site to gauge market interest

assuming we continue to use feathers and our YAML database, here's how we can make it better:

• on initial load, suck up all the data into memory as ampersand collection and state (which we already have for each type of data)
• operate in memory with find / get / create / update / remove where there is a store front and a store back (as we have already with base-service as the store front and fs-storage as the store back but needs cleaning to be more like level up and down)
• on change to memory data (which we can listen to thanks to ampersand), flush to YAML files as necessary

some other ideas:

• send all data with page requests
• fetch that data and populate client store
• relay server store changes to client stores

an example of a contextual relationship is a stewardship relationship between two people in a group.

this is prettier :

• no dropshadow
• 80px dia avatars

this is what it looks like in list-view. r-dom on npm.

i think i'd prefer this as then it'd reduce the lag between server reloads where we're running the node-jsx transform on every require. also more javascript-y. 🃏

@simontegg how do you feel about this?

Just thinking out loud:

The usual idea is to have state defined in one top-level component and then pass down state through props. We can also pass down a single actions object bound to the top-level object and have subcomponents call these from their own UI actions. This way a UI interaction will travel back up to the top-level component, change state there, and new state will flow down to the sub-components.

Client -> UI (top-level component) -> graph-view -> nodes

With graph view, there are lots of micro-state changes to node and edge coordinates as the graph animate. It feels wrong to put these into UI.

https://github.com/gaearon/react-document-title

Value: Raises the profile of Holodex within Enspiral

maybe dataplex.

right now it's always set to *, which is useless as it logs everything. initially i started commenting out or removing debugs, but then you lose them for the next time you need to debug that area, so i've been learning how to actually properly use the DEBUG environment variable as described in the debug docs on the server-side, like DEBUG=holodex:module:* etc, and i recommend we make this work on the client-side too.

how to reproduce:

1. go to person profile
2. scroll down
3. click on group and keep scrolled down through the re-render

patterns:

• isomorphic
• query language
• kappa architecture
• immutable

tools:

• level
• mynosql
• observ

i've been doing a lot of thinking around this since #55, need to post a dump at some point.

Value: Raises profile of holodex in amongst stakeholders