jasonrudolph/00-about.md

## 00-about.md

      
    Raw
  

              00-about.md
            
          
    About

This gist is a collection of my rough notes from Strange Loop 2012.
@jasonrudolph on Twitter
|
@jasonrudolph on GitHub
Did I Mention That They're Rough?

I posted these notes immediately after each talk.
Expect typos, formatting glitches, incomplete thoughts, and ...

  
## 01-in-memory-databases-the-future-is-now.md

      
    Raw
  

              01-in-memory-databases-the-future-is-now.md
            
          
    In-memory Databases - the Future is Now!

Michael Stonebraker
Abstract
|
Slides (PDF)
--- rough notes ---

"not your father's transaction processing"
how does this fit into big data?

big volume - I have too much data
big velocity - data is coming at me too fast
big variety


focusing on high velocity today
in 1985, 1,000 transactions/second seemed like an amazing stretch goal
today, you can do that on your iPhone
TP (Transaction Processing) is now a much broader problem (New TP)

massively multiplayer games
social networking
real time ad placement (i.e., you have 1 millisecond to decide which ad to show me)
real time couponing
etc.
sensor tagging generates new TP applications

marathon runners
taxicab
dynamic traffic routing
car insurance "by the drink"
mobile social networking
...
and TP volumes are ginormous!!
serious need for speed and scalability


wall street electronic trading
real-time fraud detection
micro transactions (e.g., buying a soda with your iPhone)


In all cases

workload is a mix of updates and queries
coming at you like a firehose
still and ACID problem

don't lose my data
make sure it's correct


tends to break traditional solutions


put differently

you need to ingest a firehose in real-time
you need to process, validate, enrich and respond in real-time (i.e., update)
you often need real-time analytics


if your data doesn't fit in main memory now, then wait a couple of years and it will

yes, Facebook is an exception; you are not Facebook
main memory is going down in price faster than the size of TP data is growing


2007 paper "Through the OLTP Looking Glass" found that traditional databases (e.g., Oracle, DB2, etc.) spend less than 10% of their time doing "useful work." The rest is the overhead of record-level locking, latching, recovery, and buffer pool management.
How do we go faster?

Main memory deployment gets rid of buffer pool (which eliminates 25% of the overhead); leaves other 75% of overhead intact


Solution Choices

OldSQL - legacy RDBMS vendors

Code lines date from the 1980s
30 years worth of "bloatware"
Mediocre performance on New TP
Slow because they spend all of their time on overhead
Would have to re-architect their legacy code to do better
They all face the "The Innovators Dilemma"
They'll ultimately drift off into the sunset


NoSQL - Give up SQL and ACID for performance

Give up SQL? That's throwing away 30 years of RDBMS experience.
"Stored procedures are good! One round trip from app to DBMS rather than one round trip per record. Move the code to the data, not the other way around." (Editor's note: Hmm. Datomic anyone?)
Give up ACID? Can you guarantee that you won't need it tomorrow?
Eventual consistency does not mean "eventual consistency"; eventual consistency means "creates garbage"
Eventual consistency only works if the changes are allowed to happen in any order (i.e., commutative)
Appropriate for:

non-transactional systems
single record transactions that are commutative


NewSQL

Preserve SQL and ACID
Get performance from a new architecture
Scale by running on a cluster of nodes
Automatic sharding (parallelism)
Focus on OLTP workload

a few high volume transaction signatures; implement as stored procedures
occasional ad-hoc transactions


Issue #1: Buffer pool; Solution: Run in memory
Issue #2: Write ahead log; Solution: replication and tandem-style failover (and fail back); You need HA anyway for New TP
Issue #3: Multithreading; Solution: Don't do it, or get rid of all shared data structures
Issue #4: Record-level locking; Solution: run to completion in timestamp order => no locking


VoltDB is NewSQL

Open source
70x faster than OldSQL, running on the same hardware
5x faster than Cassandra on VoltDB key-value layer
Runs a subset of SQL
Scales linearly to 384 cores


## 02-functional-design-patterns.md

      
    Raw
  

              02-functional-design-patterns.md
            
          
    Functional Design Patterns

Stuart Sierra
Abstract
|
Slides
--- rough notes ---

The concept of design patterns have been largely overlooked in dynamic languages.

Norvig (1998) - 16 of the 23 patterns in the GoF book have qualitatively simpler implementation in Lip or Dylan than in C++ for at least some uses of each pattern


"Are there any Haskell programmers in the audience? Yeah: you're gonna be pissed." (i.e., not gonna talk about monads)
Pattern-Oriented Software Architecture

categories

architectural patterns
design patterns
idioms (specific to a single programming language)


we're going to focus somewhere in the middle between design patterns and idioms


State Patterns


State/event pattern

about

state is derived from previous state + input
many divers inputs
need to recover past states
need to visualize intermediate states


implementation

update-state function takes the current state and an event and returns the new state


can recreate any past state by reducing over events
great for logging (i.e., you store every event that happened in the system)
offers great flexibility for how you will store state in your system

one extreme: never store state; you can always rebuild it from events


Consequences pattern

about

each event can trigger multiple events
generated events cause state changes
need to visualize intermediate states


implementation

function takes the current state and an event, and returns a sequence of consequences
the consequences might be more events


consequence functions do not compose naturally; you have to update state in between


Data Building Patterns


Accumulator pattern

large collection of inputs; maybe larger than memory
small or scalar result
lazy sequences (i.e., map, mapcat, filter, etc.)
reduce is the universal accumulator


Map-reduce pattern

input is linear; maybe larger than one disk
motivated by things that were historically true, but are becoming less so:

disks are (were?) slow and local to one machine
networks are (were?) slow


prediction that map-reduce will become less important as the constraints above become less and less true
now quite map and reduce


Reduce/combine Pattern

example:

Clojure reducers

Reducers - A Library and Model for Collection Processing)
Anatomy of a Reducer


operates in parallel


Recursive expansion pattern

build up result out of primitives
build abstractions in layers
recuse until no more work left to do
e.g., macroexpansion, Dataomic transaction functions


Flow Control Patterns


Pipeline pattern


process with many discrete steps


similar "shape" of data at each step; usually a map or record


only one execution path


example:
  (defn large-process [input]
    (-> input
        subprocess-a
        subprocess-ab
        subprocess-c))

  (defn subprocess-a [data]
    ; ...
    )


useful to be able to easily the exact order of the steps; show it to business users to vet that you've ordered it correctly?


Wrapper pattern

about

process with many discrete steps
one main execution path
possible branch at each step


Clojure's Ring library is an example
implementation

input: a function
output: a function that does something before and/or after the given function; might not call the given function at all


Token pattern

about

may need to cancel an operation, but ...
the operation itself is not an identity


implementation

create a fn that performs the operation
returns a fn that allows you to cancel (i.e., undo) the operation


examples:

the scheduled thread pool in Java
Clojure watches


Observer pattern

yes, it's a GoF pattern
register an observer fn with stateful container
examples:

Clojure watches


Strategy pattern

yes, another GoF pattern
many processes with a similar structure
need extension points for future variations
examples:

Clojure protocols; very similar to the original OO approach
Clojure multimethods; dispatch on input


## 03-a-whole-new-world.md

      
    Raw
  

              03-a-whole-new-world.md
            
          
    A Whole New World

Gary Bernhardt
Abstract
--- rough notes ---
Gary introduces a side project that Gary has been working on part-time for a little over a year, including ...
a text editor, called "aneditor"


modal (like Vim)
terminal only
"much more powerful than Vim"
not an IDE
layers

overlay an orthogonal "layer" on top of the source code
examples:

diff layer
crash layer => overlay backtrace onto the source code
performance layer => overlay time profiling information onto the source code


interactions

the user experience:

one keystroke shows you all the code that the current line interacts with
renders a graphical tree-like display in the terminal
can navigate through the graph
uses GraphViz


Useful questions you can answer

what code does this test hit?
what code does this request hit?
what code might hit this crash point?


a terminal, called "anterminal"


raster graphics
24-bit color
italics, bold, underline
momentary keypresses


And, we've all been punk'd. All lies. None of the things above actually exist.

We were surprised (right?) when Gary said that he wrote his own terminal. Why? Why is it surprising that someone would write a terminal?

shipping culture => our "shipping culture" is poisonous to infrastructure replacement, even when the infrastructure sucks
legacy and paralysis

we overlook the things that have existed our entire programming careers (e.g., terminals)
we overlook their limitations and whether those limitations make sense in today's world


Advocating for thinking, hammock time, prototyping
Our "shipping culture", incremental changes don't allow for fundamental improvements (i.e., rethinkings) like the ones Gary described above


Editor's note: With Light Table, Catnip, aneditor/anterminal, and Bret Victor's upcoming talk, it seems like "Re-imagining Your Development Environment" will be one of the themes of Strange Loop 2012.

  
## 04-a-type-driven-approach-to-functional-design-1.jpg

      
    Raw
  

              04-a-type-driven-approach-to-functional-design-1.jpg
            
          
## 04-a-type-driven-approach-to-functional-design-2.jpg

      
    Raw
  

              04-a-type-driven-approach-to-functional-design-2.jpg
            
          
## 04-a-type-driven-approach-to-functional-design.md

      
    Raw
  

              04-a-type-driven-approach-to-functional-design.md
            
          
    A Type Driven Approach to Functional Design

Michael Feathers
Abstract
--- rough notes ---


Revised talk title? "Using Haskell Type Signatures as a Functional Design Notation"


Haskell type signatures useful for thinking about design


Even in Ruby code, Michael finds himself adding Haskell-esque type signatures as comments (i.e., documentation for methods)
   String -> [String] -> [[String]] -> [String] -> String


Look at the shape of your data and how each function transforms the data; doing so will influence how you want to name your functions

Example 1
Example 2


Focuses on data


Think of problems as transformations from one thing to another thing


## 05-the-higher-order-rubyist.md

      
    Raw
  

              05-the-higher-order-rubyist.md
            
          
    The Higher Order Rubyist

Robert Pitts
Abstract
--- rough notes ---

Ruby gives us many of the tools we need to write code in a more functional style

Enumerable includes most (all?) of your favorite HOFs (e.g., #map, #reduce, #filter, etc.)
First(ish) class functions

blocks, procs, lambdas, methods
Currying and partial application (via Proc.curry added in 1.9)


Continuations (via callcc)
Tail call optimization (as of Ruby 1.9)

not enabled by default
enabled by passing args when launching Ruby


Facets (added in 1.9)


hamster - persistent, efficient, immutable, lazy data structures in Ruby
stunted - not yet ready for production use
celluloid - actor-based concurrent object framework for Ruby
monads (e..g, ick)


Editor's note: If this topic interests you, you might also enjoy Alan Dipert's "Functional Programming in Ruby" slides from Ruby Hoedown 2011.

  
## 06-clojurescript-better-semantics-at-low-low-prices.md

      
    Raw
  

              06-clojurescript-better-semantics-at-low-low-prices.md
            
          
    ClojureScript: Better Semantics at Low, Low Prices!

David Nolen
Abstract
--- rough notes ---

Reiterating one of the key motivations for ClojureScript: JavaScript has reach.
Arms race among Google, Apple, Mozilla to have the fastest JS runtime. As a result, we (developers) win.
Argues that no browser (other than Chrome) will ever adopt Dart. [A]
"Lisp programmers know the value of everything and the cost of nothing." — Alan Perlis

And that's unfortunate, because efficiency is important (because performance is important)


ClojureScript is expression oriented (i.e., not a mix of statements and expressions)
ClojureScript's advantages over vanilla JavaScript

persistent data structures
functions are values
protocols
namespacing
browser-connected REPL
macros


Translations from JavaScript to ClojureScript
Admittedly, adopting ClojureScript does have some costs

debugging [B]
a lot of code generated for trivial programs (e.g., "Hello World")
some components of Clojure not yet present in ClojureScript [C]
not bootstrapped; requires Clojure
uses JavaScript arithmetic underneath (which is inferior); does not use Clojure numerics
performance enhancements are not evenly distributed (e.g., keywords, multimethods)


Live demo of spectralnorm benchmark

Java: 9 seconds
JavaScript (on V8): 12 seconds
Dart-optimized JavaScript (on V8): 13 seconds
ClojureScript-generated JavaScript (on V8): 13 seconds


Live demo of using core.logic in ClojureScript
Q & A

Is ClojureScript in use at the New York Times? No.
Source maps are coming along. Stay tuned.
What helps your dev workflow? lein-cljsbuild


[A] Editor's note: However, Dart can compile to JavaScript. (See notes from Lars Bak's talk.)
[B] Editor's note: Debugging is probably better than you expect. It's better than I expected.
[C] Editor's note: Check out the "Differences from Clojure" wiki page for a good breakdown.

  
## 07-types-vs-tests-an-epic-battle.md

      
    Raw
  

              07-types-vs-tests-an-epic-battle.md
            
          
    Types vs Tests : An Epic Battle?

Amanda Laucher and Paul Snively
Abstract
|
Slides (PDF)
--- rough notes ---

Logic programming is in the air

Datalog
MiniKanren
core.logic


Assumptions for this talk

you've used a REPL
logic programming is upon us; see above
some languages are better suited for correct code; admittedly a potentially controversial assumption
we spend way more time reading code than writing it
we are lazy bastards!


Quotes

"When it doubt, create a type." — Martin Fowler
"Make illegal states unrepresentable." — Yaron Minsky
Michael Feathers defines legacy code as "code without automated tests"
"In 5 years, we'll view compilation as the weakest form of unit testing." — Stuart Halloway
"Given a good test suite, the return on investment simply does not justify the use of static typing." — Jay Fields


Stereotypes

It's easier to refactor with tests that types
No tests = no trust
Tests take a long time to run and types to compile
Property-based testing can replace unit testing
Modular design only occurs with TDD
I don't get errors than can be prevented by types
Ivory tower vs. hippies
100% test coverage or bust [A]
Typed code is verbose
Types take too long
Testing is for QA


They individually worked through code katas. In an effort to see the other side of the "tests vs types" debate, they each approached the kata in ways that were different than their usual approach.
Amanda coming from an F# background (strong emphasis on testing than types); Paul coming from a Scala background (stronger emphasis on types)
Amanda's approach:

F#
Signatures first
Types first (as opposed to tests first)
All algorithmic development via REPL experimentation
Tests for validation


Amanda's lessons learned:

types saved me from even having to think about certain categories of tests
tests help me out when I get stuck, but I mostly run them in the REPL and delete
structured her code differently to make it more friendly to work with in the REPL
most modern languages don't have a strong enough type system to make illegal state unrepresentable
it's easy to get lost in a space where you never deliver
tests verify when types can't prove


Paul's approach:

Scala
Tests without types (as opposed to preferring types first)
Property-based testing
Types
Delete some tests


Paul's lessons learned

even for such a small problem, spelling out unit tests made me want to gouge out my eyeballs with a rusty spoon; 32 unit tests for just 4 small user stories
when developing property-based tests, every forAll made me think, "could/should that be a type?"
for some use cases, having examples of correct input/output gave no real guidance whatsoever
test code is still code, with its own correctness, maintenance, etc. burden


Amanda's and Paul's discussion (i.e., things they seemed to agree upon) as they worked through these katas:

small codebase = little value for the type system
types scale better than tests (i.e., scaling as the code base grows)
types have little value when talking with non-technical users
the hardest part is understanding the requirements
we are rarely handed sample input/output as part of the requirements (which makes it harder to write tests) [B]
tests can be good for forming ideas, but then can be deleted


Paul's and Amanda's kata solutions will be up on GitHub soon


[A] Editor's note: Testing Anti-Patterns — How to Fail With 100% Test Coverage
[B] Editors note: This might be a problem if you're coding in a cave. But you're not. So, go talk to your customer. Just sayin'.

  
## 08-the-database-as-a-value.md

      
    Raw
  

              08-the-database-as-a-value.md
            
          
    The Database as a Value

Rich Hickey
Abstract
--- rough notes ---

What is Datomic?

a new database
a sound model of information, with time
provides database as a value to applications


We program in a functional style to help get a grip on complexity

Paper: Out of the Tar Pit - Mosely and Marks (2006) (PDF)
Complexity caused by state and control


Database is a giant, shared global variable
DB Complexity

stateful, inherently
same query, different results (over time)

no basis


the data is "over there" (i.e., in some far off place away from the code, outside of the application)
"update" poorly defined

current databases are place-oriented (regardless of whether your database has "rows" or "documents")


What does "update" mean?

Does new replace the old?
What is the granularity? Record? Document?
Who sees the update?  (If you've ever used SQL, you've seen a bug related to this question.)


Terms

Value - immutable
Identity - a putative entity we associate with a series of casually related (states) over time
State - value of an identity at a moment in time
Time - relative before/after ordering of casual values


Implementing values (efficiently)

persistent data structure
via trees with structural sharing


On existing databases being "place-oriented"

"I don't mean to disparage any particular database. Let's just disparage them all equally."
This is the same problem we see with object-orientation: conflating identity with value


Perception should not require permission (i.e., you shouldn't need a transaction in order to read)
Database state

the database has an expanding value

an accretion of facts
the past doesn't change — immutable


new information needs new space
fundamental move away from places


We're stuck in a decades-old model that was designed to fit a relational model into a tiny machine
Facts

Fact is "an event or thing known to have happened or existed"

derived from: "factum" with means "something done"
must include time


Atomic Datom => Entity/Attribute/Value/Transaction (i.e., RDF, plus time)


If you've ever looked at the database and wondered, "Wow! I wonder how it got like that." ... then you know (one reason) why this is important.
Deconstructing the things we associate with databases

Process

Transactions
Indexing
Output


Perception/Reaction

Queries
Indexes
Input


Diagrams of Datomic architecture (i.e., things that are difficult to capture in text ;-)


## 09-pushing-the-limits-of-web-browsers.jpg

      
    Raw
  

              09-pushing-the-limits-of-web-browsers.jpg
            
          
## 09-pushing-the-limits-of-web-browsers.md

      
    Raw
  

              09-pushing-the-limits-of-web-browsers.md
            
          
    Pushing the Limits of Web Browsers ... or Why Speed Matters

Lars Bak
Abstract
|
Video
--- rough notes ---

Lars has spent the last 26 years optimizing implementations of OO runtimes
Experience includes work on Strongtalk VM, Hotspot VM, OOVM Smalltalk, V8, Dart, and more
Motivation for VMs

platform-independent execution
sandboxing
optimizations can take place at runtime (e.g., you can decide what to inline at runtime; you're not forced to decide at compile time)
debugging is possible in production
loading of third-party code at runtime


When the VM gets faster ...

existing programs run faster
programmers get room for software innovation


OH "Hands-up: who knows what inline caching is? Ooh. That's not many people."
Overview of the journey from Self to Strongtalk to Hotspot
Strategy for Chrome: simple, secure, and fast
Speed enables new kinds of applications, and you cannot predict the kinds of apps you'll get
Original V8 goals

make JavaScript 10 times faster
enable JavaScript programs to scale
open source the project
and raise the industry performance bar as a result


After the first four months, V8 was 24 times faster than code running inside Firefox
Making V8 a separate project led to unexpected uses (e.g., node.js)
JavaScript is now faster but ...

promotes spaghetti style programming
OO programming is hard
objects can change on-the-fly
no support for libraries
tool support is weak
slow application startup
runtime performance is unpredictable


The web is great

developing small applications is easy
platform independence
no installation of applications
supports incremental development
... but innovation is crucial for survival


Goals for a new web platform (i.e. Dart)

support for programming in the large
compared to V8 performance

ultra-fast startup => 10 times faster
predictable performance => 2 time faster


avoid fragmentation of the web


simple and unsurprising OO language

class-based single inheritance
interfaces with default implementation
optional static types
real lexical scoping
single-threaded
compact and readable


Inspiration for Dart

object model inspired by Smalltalk
compilation strategy inspired by Self
optional types inspired by Strongtalk
... and more


Dart was designed for a VM

straightforward semantics
simple object model
no class initialization
applications are declared


OH (while showing some Dart sample code) "I guess you all can read that. No monads!"
Dart's optional type system

not your traditional static type system
used for specifying programmer intent
types can be introduced gradually
adding types to fields, variables, and method signatures does not change behavior
allows implicit downcasting
types are only verified in checked mode
type checker only issues warnings


Platform independence

Dart can run on the Dart VM in Chrome
Dart can also compile down to JavaScript to run on other browsers


Can write server code in Dart as well
Dart SDK coming soon, including ...

language spec
libraries
VM
translator to JavaScript
IDE


Things Lars has learned

always start small with a small team
focus on solving the hardest problem first
competitive situation fuels motivation
only people that are smarter than you
open source projects are great

helps industry
keep your work honest
not forced to wait for your vendor's release cycle in order to get a bug fixed


when building for performance, be sure to track performance from day one

run all benchmarks
on all revisions
on all platforms
and do it automatically (and have your build show you performance over time)
... or don't, and performance will deteriorate


Keep in mind

Speed will continue to drive innovation for web apps
Programmer productivity will be key as web applications get larger


## 10-computing-like-the-brain.md

      
    Raw
  

              10-computing-like-the-brain.md
            
          
    Computing Like the Brain

Jeff Hawkins
Abstract
|
Slides (PDF)
--- rough notes ---

Jeff's book: On Intelligence
Approach to the goal of "computing like the brain"

discover operating principles of neocortex
build systems based on these principles


Or ...

start with anatomy and physiology of the brain
identify theoretical principles
build software


Neocortex is a predictive modeling system

all high-level intelligence occurs in the neocortex
retina, cochlea, and somatic feed a high-velocity data stream into the neocortex
neocortex builds online models from streaming data

makes predictions
detects anomalies
generates actions (e.g., speech)


"The brain doesn't actually compute; it's a memory system."
Neocortex uses ...

a hierarchy of similar memory regions
sequence memory in each region
sparse distributed representations (SDRs)


Dense representations (used in computers)

few bits (8 to 128)
all combinations of 1s and 0s
example: 8-bit ASCII
individual bits have no inherent meaning; representation is assigned by programmer


Sparse distributed representations (used in the neocortex)

many bits (thousands
few 1s and mostly 0s
example: 2,000 bits, 2% active
each it has semantic meaning
meaning of each bit is learned, not assigned


SDR properties

similarity: shared bits = semantic similarity
store and compare

store indices of active bits
subsampling is OK


union membership


Intelligent machines will be built on SDRs
Online learning

train on every new input
if pattern does not repeat, forget it
if pattern repeats, reinforce it


Predictive analytics

Today

data comes in
we store it
we visualize it
we make predictive models


Tomorrow

data streams directly to online models
generate actions from online models acting on data


Grok: An engine for acting on data streams

Runs on Amazon AWS
Example application: energy demand/response

Each night at midnight, Grok predicts the factory's energy use for the next 24 hours (based on patterns from recent time periods)
Predictions used to bid on energy at optimal prices


Example application: managing server capacity

Grok used to predict server demand
Used to provision instances ahead of time
Results show approximately 15% reduction in AWS cost


Example application: predictively and proactively optimize maintenance schedule for windmills


Future of machine intelligence

more advanced than the (admittedly impressive) things we're seeing now (e.g., Watson beating Jeopardy pros, Google's self-driving cars)
a lot more theory still to be developed
embodiment

today: cloud-based
eventually ...

embedded
distributed (benefiting from billions of distributed sensors)


advances in hardware
applications

today: prediction, anomaly detection
classics: vision, language, speech
the big wins will be way more impressive than these things; the big wins will be things we cannot possibly imagine today
things that can benefit from systems that are thousands of times faster than the human brain, and that don't get tired


## 11-cross-browser-testing-with-browserstack.md

      
    Raw
  

              11-cross-browser-testing-with-browserstack.md
            
          
    Cross-Browser Testing with BrowserStack

Scott González
Abstract
--- rough notes ---

Scott is the project lead for jQuery UI
jQuery tests against ...

current and previous version of Chrome, Firefox, Safari, and Opera
IE 6, 7, 8, 9, 10


Testing on mobile devices introduces even more challenges; you often need physical hardware
"All developers on the team should be able to test on all environments at all times"
BrowserStack

multi-desktop OS
real browsers (no testers and fake browsers)
official mobile emulators
fast, web-based access
can test against local server running on your laptop
change browser and/or OS on-the-fly while testing

"show me this page in Chrome 21 on Windows 7"
"show me this page in the Android browser on a Motorola Droid Bionic"
"show me this page in Safari 5.1 on OS X Snow Leopard running at 1024x768"


RESTful API

Node module

npm install browserstack
Example usage: github.com/scottgonzalez/node-browserstack


Use the API to kick off workers to run your tests
Can specify the device, OS, browser and version that should run your test
Can get status of the worker (e.g., running, terminated, etc.)
Can get the results of the tests
jQuery uses this approach for CI on all jQuery-related projects


Q & A

Can you request a screenshot your page/app as it rendered in a given browser? Not yet, but they know that this is a feature people want.
How do you handle testing behind a firewall? It sets up a tunnel through a Java applet.
Pricing plan? See browserstack.com/pricing

Starts at $19/month for an individual
1 hour free trial (I think)


Does it support file uploads? Yes; it's a full browser.


## 12-programming-by-voice-becoming-a-computer-whisperer.md

      
    Raw
  

              12-programming-by-voice-becoming-a-computer-whisperer.md
            
          
    Programming by Voice: Becoming a Computer Whisperer

Tavis Rudd
Abstract
--- rough notes ---
Editor's note: you'll definitely want to see (and hear) the video for this talk.

"If you only take away one thing from this talk, it should be: 'Holy shit! He actually did that by voice, and it was faster than I can type.'"
Motivated by severe RSI: fingers would go numb on each hand if Tavis touched the keyboard
Coding by voice. Demonstrated:

ability to write an incredible variety of Clojure syntax
ability to code in Elisp (to show that it's not limited to Clojure)
ability to perform operations at the command line (to show that it's not limited to writing code in an editor)
impressive code navigation/manipulation abilities (e.g., "yank", "copy", "snap", "slurp", "swap", "search next")
selecting and running code via Slime (e.g., "slime compile", "slime eval buffer")
navigating between files


Tavis is releasing the "incredible pile of duct tape that makes this work" later this year

built on Dragon NaturallySpeaking
running inside a Windows XP VM running on OS X


Humorous interactions

Tavis: "Start Emacs." Laptop: "You have 20 minutes. Do you really want to wait 10 minutes for Emacs to start?"
Tavis: "Go-go gadget." Laptop: "Go fuck yourself." Tavis: "Typical compiler warning."


Q & A

Q: "Have you tried OSS voice recognition solutions?" A: "I wish I could use them, but they were all unworkable."
Q: "How much do you use this approach in practice?" A: "It's good enough to use full-time. In practice, I use it 60% of the time."


## 13-building-visual-data-driven-uis-with-clojurescript.md

      
    Raw
  

              13-building-visual-data-driven-uis-with-clojurescript.md
            
          
    Building Visual, Data-Driven UIs With ClojureScript

Kevin Lynagh
Abstract
|
Slides (PDF)
--- rough notes ---

Visual interfaces enable analysis for experts (non-programmers) to access data in their domain

example shown for data visualizations built for Harvard Medical School
example shown for wind energy data


Biggest win of using ClojureScript: the Clojure philosophy (especially its approach to state)

"mutable state is the 21st century equivalent of GOTO"


When you're designing your application, be explicit about mutable state; identify the essential state in your application
But we need to update the view, so we need side effects. What now?

treat your views like data (e.g., using hiccup)
map domain data to markup data (which is still data!)
pass the markup data to a render! function to update the DOM (i.e., side effects are isolated to the render! function)


Or, we could define a bind! macro to always sync the DOM to match the domain data
c2 implements this approach

github.com/lynaghk/c2
TodoMVC written with c2


Decouples the specification of the markup you want from rendering the markup; You're no longer coupled to the browser, which ...

makes it easier to test
opens the door to rendering in non-browser environments (e.g., SVG)


Tradeoffs

performance hit; DOM walking is always slower than direct references (but how often does this actually matter?)
coupling markup with dev; leads to angry designers?


## 14-visible-programming.md

      
    Raw
  

              14-visible-programming.md
            
          
    Visible Programming

Bret Victor
Abstract
--- rough notes ---
Editor's note:
You'll definitely want to see the video for this talk once it's available.
In the meantime, check out Bret's amazing essay on the topic.
Seriously, don't bother reading the notes below. Go read Bret's essay. You'll be glad you did.

Original title: "Taking off the Blindfold"
Revised title: "Visible Programming: Designing a Programming Environment Around How Human Beings Do Human Being Things"
Current emphasis in development environments seems to assume that the speed of entering/editing the program is the highest priority
Bret disagrees. Development environments should instead emphasize the ability to see and understand what the program is doing
An environment should enable the programmer to:

read the vocabulary
follow the flow
see the state
create by reacting
create by abstracting


Read the vocabulary

make meaning transparent
explain in context (i.e., don't just tell, also show)


Follow the flow

make the flow tangible and visible

give the programmer control over the execution of the program
example: "slider" metaphor allowing programmer to navigate forward and backward through the execution of the program
example: the usefulness of driving directions shown on a map versus a plain text list of directions


make time tangible and visible


See the state

show the data

example: when viewing the code, show the values plugged into variables as they would be when the code is running


show comparisons

example: don't just show numeric values; when a number represents a degree of rotation, actually show a graphic representing that rotation


eliminate hidden state

one way to eliminate hidden state: show it (i.e., we still have state, but it's no longer hidden)


Create by reacting

get something on the screen as soon as possible

"If you're composing things in your head, you're limited to the resources of your head."
Why do I have type an entire line of code before I see the results? What if I don't know what line of code I want in the first place?
example: autocomplete plus sample argument values (as opposed to just argument names) and sample output associated with those argument values


dump the parts bucket onto the floor

make it easy to see all your options
when you can see all your options, it generates new ideas
emphasizing recognition as opposed to recall


Create by abstracting

state concrete, then generalize

state constant (i.e., concrete), then vary
start with one, then make many


enable the programmer to see all the "knobs" and to understand how each one influences the results


After seeing these ideas, people often ask, "How do these ideas scale to real-world programming?" Asking this question is like asking, "How does the internal combustion engine benefit horses?"
After seeing these ideas, people often say, "But my data structures don't lend themselves to visualization. So, how do these ideas apply to me?" Bret argues that this is thinking about the problem the wrong way. Instead ask, "How do we design data structures that can be visualized?"


## 15-the-state-of-javascript.md

      
    Raw
  

              15-the-state-of-javascript.md
            
          
    The State of JavaScript

Brendan Eich
Abstract
--- rough notes ---
Comedy / Memorable Quotes


On client-side JavaScript alternatives:

"Java on the client is pretty much dead, except as an attack vector."
"Thanks to Mr. Jobs—rest in peace—Flash is going down."


"In 1997, I said, 'Hey, we should fix that equality operator.' They said, 'No. Too late. You'll break the web.'"
"The simplest thing that can possibly work sometimes turns into the 'Parade of Stupid.'"
Channeling Wesley Snipes' character from Passenger 57: "Always bet on JS." (alwaysbetonjs.com)

ECMAScript 6


is on its way
aims to be a better language for:

applications
libraries
code generators (e.g., CoffeeScript, ClojureScript, etc.)


adds:

classes
modules
imports
symbols
default parameter values
rest parameters; example: function f(a, b, ...r)
generators (which help replace "callback hell" with "shallow coroutine heaven")
comprehensions
maps (which overcome some of the existing shortcomings in hashes)
sets
proxies
proper tail calls


What About Native Client (NaCl)


Google Native Client (NaCl)

impressive engineering
driving competition
not portable
no ability to "view source"


Argues that JavaScript will prevail

Demo of JavaScript-based 3-D first-person shooter running at 60 frames per second; running on BananaBread 3-D JavaScript engine
Low-Level JavaScript (LLJS)


Macros in JavaScript


sweetjs.org
github.com/mozilla/sweet.js

pull requests accepted
"please help us"


hygienic macros for JavaScript
could make it into ECMAScript 7

More Innovation


Cross-compile XNA (jsil.org)
Cross-compile Android (xmlvm.org)
Parallelism in JavaScript

River Trail
PJS