Jason Morrison

Make stuff.

Reading List: February 2014

I am maintaining a reading list:

http://jayunit.net/reading-list

I’m choosing a theme per month, with several works on the theme. I’ll try to collect notes at the end of each month about what I read and wrote, what I thought, and how I might revisit that theme in the future.

Take “reading” loosely – presentations and podcasts definitely count.

What did I complete in February?

My high level goals for February were to:

  • Read about Meteor, FRP, and React.
  • Do some toy projects with these.
  • Skim a finance book.

Meteor

What did I read?

Thoughts:

Lots of interesting ideas, but I’m not sure I’ll use Meteor. Maybe I’ll use parts (DDP).

  • Isomorphic (same code for the client and server) is interesting. I would have to build a large app to see demonstrated advantages, but can imagine.
  • Seems to work best when all used together, but no reason you couldn’t extract e.g. DDP or Deps and use in an existing application. (Right?)
  • There are three places to get packages – core, Atmosphere, and, as of June 2013, NPM. It’s nice that they bless a small set of core packages as a stdlib of sorts, although I don’t understand the need for Atmosphere and NPM to be separate.

  • The Deps module, especially Deps.autorun, is a particularly elegant approach to automatic dependency registration that avoids the need for static analysis. The clever part relies JavaScript’s single-threaded nature, and tracks the current computation as Deps.currentComputation.

    • At first I thought this could break down if you depend on a boolean expression a() && b(). If a() returns false, the language short-circuits evaluation so that b() is never invoked, so the dependency is not registered. However, once a() returns true, b() will get run and the dependency is registered correctly. There must be some shortcomings? External data is a clear example, but that is covered by the more explicit Deps.Dependency facilities.

Questions:

  • What effect does DDP and the use of a document storage model inform data modeling? How would you build a system like DDP atop a relational model? One system I work on uses multiple steps of data mapping (SQL –> Python objects –> JSON –> Backbone models and back). This seems like unnecessary layers of complexity, and replicating a datastore into the client, like minimongo does, seems like a preferable situation in many cases. How might you introduce DDP to an existing rich-client application without rewriting it in Meteor?
  • How do you build for reliability atop DDP and RPC? (E.g. ensuring all RPC endpoints are idempotent.) How does DDP navigate timeout/retry/backoff? See Andrew Wilcox’s meteor-offline-data work.

  • How does operational transform (OT) fit in? Compare to the Derby framework and its Racer library, which uses ShareJS for OT:

    • OT is one approach to conflict resolution. I assume there are many. What are the tradeoffs?

    • What other conflict resolution approaches exist? Maybe some in the thinkdistributed.io Causality episode.

      The correctness problems of OT led to introduction of transformationless post-OT schemes, such as WOOT, Logoot and Causal Trees (CT). “Post-OT” schemes decompose the document into atomic operations, but they workaround the need to transform operations by employing a combination of unique symbol identifiers, vector timestamps and/or tombstones.

      http://en.wikipedia.org/wiki/Operational_transformation

    • If you use OT, can you use tree-structured data? Is the scope of OT limited to a document? Can you coordinate operations across documents?

What would I study about this next?

  • How does the very new (documented February 27) Blaze rendering system compare to React?
  • How well does Meteor play with other libraries? I recall seeing a “modularized” version of Meteor where some parts were available a la carte. What does it look like to involve something like Backbone for models? React for DOM computation?
  • What is the multi-server story (for performance and for availability)? I think that the new oplog work is supposed to support this.
  • SQL bindings

Functional Reactive Programming (FRP)

What did I read?

There are a bunch more resources in my 2014-February reading-list page that I collected but didn’t get to.

Thoughts:

Seems like a solid theoretical underpinning for complex dataflow apps.

FRP concepts (behaviors) have similarities to promises – they represent an abstraction of a value. Promises represent a future value. Behaviors represent a value which may vary continuously over time, they are functions of time.

From reading the papers, I also learned a more general concept – that of a paper separately introducing formal semantics from a specific implementation. I haven’t read enough CS papers to know how typical this is.

That reminds me of a thinkdistributed.io podcast on Raft (a consensus algorithm) which was designed for understandability, seemingly a novel goal in CS research. The result is a large number of (attempted) implementations, because the theory was so approachable. Does the Raft paper propose a formal semantics? See in May/June.

Questions:

I’d like to try out https://github.com/baconjs/bacon.js and read about underlying ideas.

If I were to study further/return to this, what would I look at?

I didn’t get to read too much about FRP. I would like to try some of the JS implementations to build some small dataflow applications. I’d like to build some medium-sized React.js apps and compare that experience to the FRP libraries.

React.js

What did I read?

First, I read about React from other people:

Then I react the docs themselves:

And aimed to get my hands dirty:

Thoughts:

Looks good, I want to do more with it.

The design of React is very appealing; using functional composition, cohering templates with view logic, implementing synthetic DOM events atop delegation, and providing an immediate mode atop the DOM’s retained mode Not sure on the JSX syntax, but I think I’ll like it as soon as I install vim-jsx.

If I were to study further/return to this, what would I look at?

  • Build something more substantial with React
  • Om, a CLJS wrapper atop React enjoying advantages from immutable data structures and presumably other CLJS fanciness
  • What does this discussion mean by “UI as value”?

People:

https://twitter.com/sgrove https://twitter.com/floydophone https://twitter.com/swannodette

Finance

On my friend Mac Cowell’s recommendation, I skimmed some of The Little Blue Book That Still Beats the Market. I maintain a healthy level of skepticism, but underneath the “wow it’s pure magic!” skin appears to be a proxy for value investing that identifies underpriced companies. Time will tell if broad dissemination of this valuation strategy will correct the underpricing, or if it holds.

I’d like to, as an exercise, build a software implementation of this strategy and backtest it. I’d also like to understand if there is affordable historical market information that avoids survivorship bias, and to understand what other backtesting blind spots I may have.

I’ll follow this up (also on Mac’s recommendation) with Graham and Zweig’s The Intelligent Investor, maybe in March or April.

Links from an hour-ish of searching about building trading simulations:

Retrospective

The pace for this month was quite high, but I enjoyed keeping up with it. I’ve found it helpful to schedule reading nights on my calendar to try and block some time off for paying attention.

I could not read some of the FRP papers for lack of understanding of some foundational functional programming concepts (applicatives, monoids), so I will read on those next month.

I wish I had done more hands-on programming with these new tools.

The part I have enjoyed the most is discussing these ideas with others. I’d like to try small reading groups or journal clubs around some of my future readings.

Next, onto March reading: including Clojure, FP concepts, and core.async.

Comments