Erik's blog

Code, notes, recipes, general musings

Notes from “Web Application Development with Closure Compiler” talk by Alan Leung on 6/22/11

leave a comment »

Alan visited Twitter on 6/22 and presented an introductory talk on Google’s Closure compiler for JavaScript. Alan is tech lead on Closure team.

Here are the slides:


* JavaScript was originally designed for small DOM operations. Now that we’re building large-scale apps in JS, we can use some help.
* Google uses Closure for all but a couple products
* The Closure compiler can perform ~55 optimization passes, including linting code, validating function definitions, performing gzip-optimized compression, trimming dead branches
* Closure can also provide compile-time constants, e.g., “if(INTERNAL){…”, and trim unused branches that result
* Closure uses a graph coloring heuristic for variable renaming



Written by Erik

June 25, 2011 at 11:43 am

A nice button

leave a comment »

input[type=submit] {

  font-size: inherit;

  padding: 0.5ex 1ex;
  margin: 0;

  border: 1px solid #ccc;

  /* */
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  border-radius: 4px;

  /* */
  background: #ffffff; /* Old browsers */
  background: -moz-linear-gradient(top, #ffffff 0%, #cccccc 100%); /* FF3.6+ */
  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#ffffff), color-stop(100%,#cccccc)); /* Chrome,Safari4+ */
  background: -webkit-linear-gradient(top, #ffffff 0%,#cccccc 100%); /* Chrome10+,Safari5.1+ */
  background: -o-linear-gradient(top, #ffffff 0%,#cccccc 100%); /* Opera11.10+ */
  background: -ms-linear-gradient(top, #ffffff 0%,#cccccc 100%); /* IE10+ */
  filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#cccccc',GradientType=0 ); /* IE6-9 */
  background: linear-gradient(top, #ffffff 0%,#cccccc 100%); /* W3C */

Written by Erik

June 5, 2011 at 1:10 am

Posted in code

Tagged with

Notes from Kyle Neath’s presentation at Twitter on 5/31

with 3 comments

  • Slides
  • 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
  • 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 much richer state management. See github’s new issues dashboard

Written by Erik

May 31, 2011 at 8:19 pm

Posted in notes

Tagged with , , , ,

Notes from Neil Gershenfeld’s 5/24 talk at Twitter

leave a comment »

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

Written by Erik

May 24, 2011 at 12:45 pm

Posted in notes

Tagged with , ,

Notes from Rob Pike’s 5/12 talk on Go at Twitter

leave a comment »

  • See 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


How is the language intrinsically safe?

  • no stack overflows


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


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

Channel implementation?

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


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


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


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

Written by Erik

May 12, 2011 at 11:24 am

Posted in notes

Tagged with , ,

Learnings from an attempted robbery

with 2 comments

My wife and I were waiting for the BART when a woman started yelling for help. She said, “they stole my iphone!”

Her voice was coming from the stairs leading into the station. I couldn’t see her, but there were two young men, boys, really, jumping down the stairs three at a time. They were yelling back at her, “shut the f**k up. I never took anything from you.” It was difficult to determine if we were really seeing a robbery or just an argument.

But if a woman is yelling for help, and there are a couple people running away, something’s probably amiss. I started walking towards the two guys as they rounded a corner away from the stairs. They were moving out of view, towards the platform of an inbound train. They were trying to blend into the crowd.

I shouted at them, but they didn’t stop or look back. A person they passed said to me, “they’re going around the other side.” It took me moment to understand what he was saying. I was confused why he was speaking so matter-of-factly, and otherwise doing nothing to help.

Finally, I understood and reversed my path to head them off. When I came around the other side, they had broken into a run, and were heading directly towards me. A few people now, men and women, young and old, were trying to stop them. As we moved to push one of them against a wall, he started swinging, hitting a woman in the face. I grabbed for his leg to get him on the ground. We all fell. I grabbed the guy’s arms and held them behind his back. We restrained him until the police came.

Both men were arrested, and the phone was recovered.

My takeaways:

1) Yelling “HELP!” as loud as possible is good

I was surprised by how slowly the crowd reacted. Luckily, the victim kept shouting, and “help” is a pretty disruptive word. At one point I needed assistance keeping the thief on the ground. Shouting “help!” worked (see below).

I’d like to get more practice shouting for help and reacting to requests for help. These seem like a couple good skill sets to have.

2) Awareness of surroundings while using an iphone, ipad, etc in public is good

The officer we talked with at the BART station said this type of crime is very common. A person will be looking at his/her phone and a thief will grab it and run.

3) Yelling a description of the attackers is good

For example, “HELP! Stop those two guys! They stole my phone!” (repeat)

This helps people like me, who didn’t witness the crime, quickly get a sense of things.

4) Holding the attacker’s arms behind his back worked well

Here’s a more detailed description:
We were both sitting. I was behind him. His arms were behind his back, and I had my arms between his and his back. As my arms became tired, I grabbed my elbows.

At one point, the guy tried to get his feet under him and stand up. My hold would have been weakened by this, so I shouted for help. A man standing next to us then put his foot on the assailant’s hip and held him down. From this I learned …

5) Standing on an attacker is good

If two or three people just put their foot on someone on the ground, it would be super-helpful in keeping the person pinned. I hadn’t thought of it before, but it really works, and it seems like a low-risk way to assist.

6) Hitting someone is illegal

The woman who was hit had the wherewithal to recognize it as assault. I might have overlooked this fact. I very nearly didn’t get involved in the whole incident, thinking I was misunderstanding what I was seeing, but I was witnessing theft and assault.

7) Being a part of a community feels good

The thieves were just walking away from the victim, as though they expected no one to do anything. Had the train come a minute earlier, they could have jumped on and disappeared.

I’m so happy things worked out differently. Thankfully, the assailants weren’t armed.

My thanks to all the people who helped. The BART employees and police were great, esp. Officer Rodriguez. I feel like we’re a community. It became easier to help as more people became involved, and I became comfortable shouting and grappling and trusting other people with my safety.

Written by Erik

April 21, 2011 at 8:51 pm

Posted in Uncategorized

Tagged with ,

Trying out posterous

leave a comment »

Written by Erik

March 15, 2011 at 12:42 am

Posted in Uncategorized