jayrbolton

WARNING: exception encountered when trying to cache the index files:
Traceback (most recent call last):
 File "/kb/module/lib/kb_Bowtie2/util/Bowtie2IndexBuilder.py", line 178, in _put_cached_index
 save_result = ws.save_objects(save_params)
 File "/kb/module/lib/Workspace/WorkspaceClient.py", line 901, in save_objects
 [params], self._service_ver, context)
 File "/kb/module/lib/Workspace/baseclient.py", line 268, in call_method
 return self._call(url, service_method, args, context)
 File "/kb/module/lib/Workspace/baseclient.py", line 183, in _call
 raise ServerError(**err['error'])

jayrbolton

from datetime import datetime
from pynwb import NWBFile, NWBHDF5IO
from pynwb.ophys import ImageSegmentation, TwoPhotonSeries, OpticalChannel

nwbfile = NWBFile('a', 'b', 'c', datetime.now())

mod = nwbfile.create_processing_module('a', 'b', 'c')

optical_channel = OpticalChannel('a', 'b', 'c', 500.)

jayrbolton

- ability to iterate on anything in late stages - being able to deploy small updates to a late-stage tool
  without bottlenecks. this requires a lot of technical things in place (ie. modularity,
  versioning, CI). Eg: how can we add (or remove) a feature from the SDK and deploy that new
  version to users within a week or two?
- developers should work (and communicate) directly with users
- don't prioritize process tools and let devs choose those tools
- most of agile is not about process or ritual but about technical requirements such as modularity, versioning, CI, etc
- make sure you can refactor internals without breaking the interface (eg. versioning and dependency management in apps)
- don't add features to software until you find that you need them
- define the product, not the project

jayrbolton

import parsec as p

whitespace = p.regex(r'\s+')
ignore = p.many(whitespace)
lexeme = lambda parser: parser.skip(ignore)
lparen = lexeme(p.string('('))
rparen = lexeme(p.string(')'))
symbol = lexeme(p.regex(r'[\d\w_-]+'))
and_op = lexeme(p.string('and'))
or_op = lexeme(p.string('or'))

jayrbolton

Simple spec for small HTTP JSON APIs using JSON Schema

Throughout the spec we use JSON schema documents

Documentation

/docs serves a list of your endpoints.

["products", "orders", "customers"]

jayrbolton

package-name

jayrbolton

JSON generated by markdown

One downside of JSON is it is not very readable, especially when used as a configuration language.

To fix this, we can embed JSON data in a markdown file using a certain format that is readable and commentable. A script takes the markdown file and converts it into one or more JSON files.

Define the start of a JSON file in your markdown with a header that is a link to a local json file, such as:

## [my_config.json](my_config.json)

jayrbolton

Regexes could be a lot more readable with a little bit more verbosity

• Match characters in single quotes
• Use plain keywords for groups of chars (like whitespace)
• Slightly alter some syntax to make more explicit

Match an exact string with single quotes: 'hello world'

Match either strings: 'hello' | 'world' (matches 'hello' or 'world')

jayrbolton

const Component = require('..')
const h = require('../h')

// A single counter that can be incremented and decremented
const Counter = function (start) {
  return Component('div', {
    count: start,
    add: ({ count }, n) => ({ count: count + n }),
    view: ({ count, add }) => {
      return h('div', [

jayrbolton

Simple doc fetch

{
  coll: "wsprov_object",
  keys: ["1:2:3"],
  user_ids: [],
  page_limit: 10
}

produces aql: