Erik's blog

• Slides http://warpspire.com/talks/responsive/
• hashbang urls
  • are a kludgy workaround for lack of history api. Since history api is coming, they have no future. Since urls are forever, especially w/ tweets being stored in the lib of congress, use of hashbangs results in permanent support for a temporary condition.
  • break pre-existing url fragment behavior
  • result in confusing routing logic
• “responsive web design” is adapting to client and seeming responsive to user input
  • page load isn’t just a benchmark; a page is only “loaded” when the user can scroll, read text, and click links
• well-designed urls provide a command-line-like interface for web apps
• all web assets should have a url, i.e., navigation should not allow access to a resource that cannot then be accessed directly via a url
  • anti-pattern: infinite scroll that forces the user to scroll through pages of content every time the page refreshes
  • see http://warpspire.com/experiments/history-api/ for example of infinite scroll w/ useful url
• native elements should behave as the user expects
  • do not modify common key combos, e.g., shift + click
  • take advantage of the back button, tabs, links, etc
• responsiveness is as much about performance as perception
  • wait ~500ms before showing loader image; showing loaders immediately can actually make the page seem slower
• ssl
  • is required now that there are common, easy ways to sniff credentials
  • a new ssl handshake is very slow, and required for each domain
  • use http keep-alive to reuse ssl connections
  • multiple parallel requests to a new domain will each have to perform a handshake; instead, complete one fast request, and then reuse the connection for subsequent parallel requests
  • github optimized its backend to 40ms latency before realizing that the ssl handshake takes 500ms
    • a case of perception > performance
    • favor science over theory, i.e., test time-to-usable in multiple regions instead of just running perf tests on components
  • templates
  • use something simple, e.g., mustache
  • avoid rendering on client and server; pick one
  • kneath prefers server-side
  • for server-side rendering, passing html back as one value in a json object allows for passing data back in other keys
• html 5 history api
  • allows for partial page updates w/ real urls
  • history.js provides conditional history api support w/ fallback to hashbang http://plugins.jquery.com/project/history-js
  • fall back to full reloads
• allows for much richer state management. See github’s new issues dashboard

My mind was just blown by a talk from Neil Gershenfeld, director of the Bits and Atoms lab at MIT. His team created the fab lab. Here are  some notes

• This is a house created by a fab lab: http://www.fablabhouse.com/en
• This is a wireless network created out of junk in Afghanistan: http://www.npr.org/templates/story/story.php?storyId=125866561
• This is a next-generation learning environment he created because schools like MIT and Stanford cannot scale http://www.fabacademy.org/, and kids are now doing advanced material fabrication at fab labs around the world
• The only current US representative who was previously a scientist recently authored a bill for a national fab lab: http://scripts.mit.edu/~emu/fab/?p=2196
• Fab labs can create the machinery required to create fab labs. There are currently 100 around the world. That number doubles every year.

• See golang.org for language documentation
• W/in a factor of 2 slower than C/C++. Generally w/in 20% speed of c/c++ programs
• Intrinsically safe
• This talk has been presented before, so the slides may be online. see google io 2010 archive
• check out article in Register about Go that quotes Odersky: “I like a lot of the design decisions they made in the language … Basically, I like all of them.”
• built on 4 self-reinforcing principles: simple, ortho, succinct, safe
• see axiom of choice in type theory
• public/private hint in variable name is one of the best things about the language
• see CSP tradition
• uses a deterministic model, channels, for concurrency
• the “go” keyword launches a go routine
• “for { … ” declares an infinite loop
• expressiveness comes from orthogonal composition of constructs
• Go conceived while waiting for 45 min gcc compilation
• Go app engine sdk is a complete installation vs building from source

Questions

How is the language intrinsically safe?

• no stack overflows

Interoperability?

• native swig support for C/C++ progs
• no java interop

Exceptions?

• no try/catch
• uses panic/recover
• function-level, not statement-level

Channel implementation?

• not like erlang channels
• passing channel over netchan is coming

Generics?

• Core team has members that believe generics must and must-not be included

Upgrading?

• gofix rewrites code
• gofont pretty-prints/formats code

Inspirations?

• Oberon
• New Squeek
• Didn’t cherry-pick features to build an ideal language, but they did include elements that helped them be productive