Skip to content

Instantly share code, notes, and snippets.

@Randommood

Randommood/00-about.md

Forked from jasonrudolph/00-about.md
Created September 27, 2012 18:41
Show Gist options
  • Save Randommood/3795636 to your computer and use it in GitHub Desktop.
Save Randommood/3795636 to your computer and use it in GitHub Desktop.
Download ZIP
Rough Notes from Strange Loop 2012
Raw
00-about.md

About

This gist is a collection of my rough notes from Strange Loop 2012.

Follow me on Twitter to get updates as they're posted.

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

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

In-memory Databases - the Future is Now!

Michael Stonebraker

Abstract

--- 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
Raw
02-functional-design-patterns.md

Functional Design Patterns

Stuart Sierra

Abstract | Slides on GitHub

--- 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
  • 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
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?
    1. shipping culture => our "shipping culture" is poisonous to infrastructure replacement, even when the infrastructure sucks
    2. 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.

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

  • Focuses on data

  • Think of problems as transformations from one thing to another thing

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.

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.

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

Types vs Tests : An Epic Battle?

Amanda Laucher and Paul Snively

Abstract

--- 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'.

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 ;-)
Raw
09-pushing-the-limits-of-web-browsers.md

Pushing the Limits of Web Browsers ... or Why Speed Matters

Lars Bak

Abstract

--- 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
  • 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
Raw
10-computing-like-the-brain.md

Computing Like the Brain

Jeff Hawkins

Abstract

--- rough notes ---

  • Jeff's book: On Intelligence
  • Approach to the goal of "computing like the brain"
    1. discover operating principles of neocortex
    2. 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
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
    • 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.
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
  • 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."
Raw
13-building-visual-data-driven-uis-with-clojurescript.md

Building Visual, Data-Driven UIs With ClojureScript

Kevin Lynagh

Abstract

--- 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
  • 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?
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:
    1. read the vocabulary
    2. follow the flow
    3. see the state
    4. create by reacting
    5. 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?"
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)

Macros in JavaScript

More Innovation

  • Cross-compile XNA (jsil.org)
  • Cross-compile Android (xmlvm.org)
  • Parallelism in JavaScript
    • River Trail
    • PJS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment