jayrbolton

// With asynchronous functions that take callbacks, it'd be easy to compose them if they were all curried
// This could create an interface very similar to Promises, but with plain, easy-to-use callback functions

const ch = require('callback-heaven')
const fs = require('fs')

// Contrived example function to open a json file, merge the data with an object, write the result back to the file, and read the file again
// (of course you could also just use writeFileSync and readFileSync, but this is just an example)
function mergeJson(path, obj, cb) {
fs.readFile(path, function(err, data) {

jayrbolton

function model({ fahrenInput, celsiusInput }) {
  const fahrenChange = fahrenInput.map((ev) => ev.currentTarget.value);
  const celsiusChange = celsiusInput.map((ev) => ev.currentTarget.value);
  const fahrenToCelsius =
    fahrenChange.map(parseFloat).filter((n) => !isNaN(n)).map((f) => (f - 32) / 1.8);
  const celsiusToFahren =
    celsiusChange.map(parseFloat).filter((n) => !isNaN(n)).map((c) => c * 9 / 5 + 32);
  const celsius = stepper(0, combine(celsiusChange, fahrenToCelsius));
  const fahren = stepper(0, combine(fahrenChange, celsiusToFahren));
  return Now.of([{ fahren, celsius }, []]);

jayrbolton

interface Functor (F) {
  map: (a => b) => F(a) => F(b)
}

interface Applicative(M) > Monad (M) {
  andThen: M(a) => (a => M(b)) => M(b)
}

type Maybe (a) {

jayrbolton

const R = require('ramda')
const stream = require('../stream')
const h = require('../html')

const multiCounters = initial => actions =>
  stream.scanMerge([
    [actions.addCounter, R.append(0)]
  , [actions.remCounter, R.init]
  , [actions.increment, (counters, idx) => R.update(idx, counters[idx] + 1, counters)]
  , [actions.decrement, (counters, idx) => R.update(idx, counters[idx] - 1, counters)]

jayrbolton

const R = require('ramda')
const stream = require('../stream')
const h = require('../html')

const counter = (initial) => {
  const [inc, dec, reset] = [stream.create(), stream.create(), stream.create()]
  const sum = stream.scanMerge([
    [inc, R.add(1)]
  , [dec, R.add(-1)]
  , [reset, R.always(0)]

jayrbolton

Instead of the model of one dat being one web page / app, you could split it into four dats

1. Schema: a syntax describing the content format (eg filenames, datatypes, lengths, etc)
2. Content: the actual content itself (social feeds, videos, map data, etc)
3. Application code: the javascript code that turns the content into a user interface, and handles updates.
4. User identity: crypto keys (signing and encryption public keys, with self-signed cetificate, etc) for the user

The advantage here is that there would be some nice decoupling and standardization when making apps:

• Different application dats can render the same content
• Apps can be considered compatible when they render and update content using the same schema

jayrbolton

// Usually, streams for the app are created in a tree:
// - different event streams from different parts of the page get passed into functions that create objects of streams
// - those streams can also get passed into other functions down the tree to create nested objects of streams

// The downside of this is that it's hard for different sections of the app to communicate. You might want to access and modify a stream from a branch that is living far down on another branch. Sometimes the order of how streams get created becomes circular
// An example is a global notification message stream. You might want to set this in 100 places in your app, but you only want to handle and render it in one place. With the tree structure, you get a lot of repetitive code

// To solve this, we can treat the app's object of streams as shallow & *concatenative*, rather than a nested tree
// Models take the app's object of streams as parameters and returns an object of streams
// Models are chained together in this way; one mode

jayrbolton

Cryptographic user profiles could be used to exchange keys, sign, and encrypt data in-band across many dats or apps. Every user has an id, encryption public/private keys, and signing public/private keys.

There are a couple ways I've been thinking about how to implement this:

Method 1: discovery-swarm server

• Every user listens to a discovery-swarm with their user id
• Other users can join the swarm and send messages to that user, encrypted to that user's pubkey
• We can use signal's double ratchet algorithm here for user-user messaging over the swarm
• The user data (keys and contacts) are all saved in a hyperdb and can be replicated across many devices

jayrbolton

SDK developer experience feedback

This doc contains some initial dev feedback as a first-time SDK app developer. Some of the feedback might be in the form of confused questions, which could give some ideas about usability of the SDK.

My feedback generally fits into a few categories:

• Faster testing turnaround
• Code mixing/stubbing and package management
• Config consolidation
• Docs on SDK apps

jayrbolton

git submodule init
git submodule update
cp submodules_hacks/AuthConstants.pm submodules/auth/Bio-KBase-Auth/lib/Bio/KBase/
Running unit tests
nose2 -s test_scripts/py_module_tests -t src/java/us/kbase/templates
Loading test config from /vagrant/kb_sdk/test_scripts/test.cfg
Authorization url: https://ci.kbase.us/services/auth/api/legacy/KBase/Sessions/Login
ant test -DKBASE_COMMON_JAR=kbase/common/kbase-common-0.0.23.jar
Buildfile: /vagrant/kb_sdk/build.xml