July 25, 2014

TBD

July 11, 2014 Kickoff Meeting

Intros
Overview of purpose:
1. widgets built from ground up with cross-project reusability in mind
2. Flexible, use-case driven, results-oriented
  1. Fast prototypes of concepts ... iteratively improved ... scientists strongly in loop
  2. Not 6 month waterfall amongst SWEs before Line 1 of code is written
3. potential to change how SWE is approached at Broad: crack (if not break) silos
  
  July 1 2014 Email:
  By hiring/sharing Ben we’re creating a cross-cutting “graphical widgets toolbox” and dev team. This will help inform Broad-wide understanding of the sweet spot between centralization and federation for SWE … maybe even serve as a model for such … so IMO we should see Ben’s role as a means to eventually cultivate wider dev interest and involvement … not just diabetes or cancer-funded … maybe even as simple as a SIG and/or better advertising (or sharing) of code repos for potentially shareable viz code. It overlaps some with soa.broadinstitute.org, but for widgets not apis, although widgets will clearly need clean architecting so that apis can be easily swapped in/out per use case (e.g. expression in GTEX vs expression in TCGA). It’s possible that soa.broadinstitute.org/component_registry already fits part of the bill, but I’m not sure and it’s empty at present. Another simple thing for visibility would be to regularly post updates on the Broad kiosks & BroadCast.
  Ideally the widgets & toolbox evolve as open source projects tend to, where the first implementation might solve a problem for the original scientific use case, then maybe another interested coder comes along, sees promise in that original implementation to solve a significant fraction of their own science problem, and understands the code by virtue of clean implementation and then extends it to another use case with a bit more code. And/or (light) refactoring to separate I/O and rendering. Or to add a different data input. Or tests. Or docs. Etc. The benevolent dictator for toolbox or each widget can be figured out along the way as needed.
  Rather than wait for executive and/or other leadership to bless this top-down as part of a Roadmap, e.g., let’s just keep at it, bottom up, under radar as needed, because we need it and many devs already have some gut feeling that we’re a bit too federated/siloed and not sharing enough. Happy to talk more, but does this make any sense to you? It implies another form of regular-ish gathering and/or communication, but I’m open to tweaking the aim, approach, initial stakeholders, and to whom we extend under-radar invitations in the early going. Jim Robinson and his protege Kane Hadley are high on my list tho, b/c Jim has a no-nonsense lets-get-something-useful-done, cut-thru-bullshit manner that helps maintain focus.
4. Ben's comments
Deliverables
1. QQ plot
2. Table widget
  ---------------------- Initial Work ---------------
3. Linked Hierarchies visualization
4. CoMut plot
5. Heatmap?
How / when to reach out to others:
1. Jim Robinson / IGV
2. Mesirov portals group
3. Bang & Noam Viz Skunkworks
4. Broad-Wide Service Registry
General Approach
1. Architectural model
  1. Very clear separation of data and rendering functionality
2. Not clear yet which approach is right ... but Once a sufficient bolus of code is in hand ... think Shared Repo or Registry:
  1. Broad-Wide Component_registry
  2. nascent widgets ok to live in project-specific repo
    Example: https://github.com/broadinstitute/igv-js/tree/master/igv/igvexp
  3. but when mature/stable enough to share, list in common registry (or repo?)
    Example: https://github.com/broadinstitute/vizdev/expression
3. Build, share, increment
4. Data services (or object definitions) are not in scope for Ben
  1. He can mock input source JSON
  2. While RESTful api data source is being implemented or provisionied
5. Process stuff? Specs, requirements gather, etc?
Brief Review of State of Art & Toolchains
1. Bootstrap
2. D3
3. DataViva : additional description here
4. Other?