phleet

10,000s of tons of CO2/year: how much we can remove from the air in 2023

1,000,000,000s of tons of CO2/year: how much we need to remove by 2050

We need to double our capacity every 21 months for the next 27 years

Hi! Author here. Agree it could be more discoverable. The feed is here: https://jamie-wong.com/atom.xml

I worked at Khan Academy for two internships and then just under 2 years fulltime, and don't know anyone that has anything less than positive to say about Kamens (nobody called him Ben because there were no less than 5 Bens at Khan Academy when I left).

One of his most memorable habits to me was coming into a meeting room where his words obviously had a lot of sway, then sitting on the ground when we were short on chairs.

He was an inspiration to many, first as an engineer, and later as a manager, and I'm excited to see what he takes on next.

(Author here) I cheated: to prevent that steady state (since it's ugly), I have 3 dye injectors strategically placed, causing certain areas to get redder, greener, and bluer over time.

Without that, yes, it turns into a muddy grey.

Author here -- I also just published a new post on ray marching, which you might find interesting if you find this post interesting: http://jamie-wong.com/2016/07/15/ray-marching-signed-distanc...

My luck on HN has been not so great. All in all, I think my posts have reached the front page ~5 times, only 1 of which I submitted. But oh well! Glad they get there somehow and people like them!

Webpack's algorithm for doing this is not black magic -- it has to consciously consider the same tradeoffs as were involved in this post. How many chunks should you have?

Haha, sorry, that was me. I was eating my words, because it looks like there is support!

The experiments described in this post were conducted early this year, and it looks like those developments are fairly new?

I just discovered this too: https://github.com/GoogleChrome/http2push-gae

Is this new-ish capability documented somewhere?

We're playing around with inline-styling our components, but pushing the inline-styles into CSS injected into `<style>` tags in the head. It's experimental at the moment, but it's being sent into production shortly: https://github.com/Khan/aphrodite

This is a hard generalization to make, but it's certainly true in the worst network condition case. Even if your client-side rendering happens instantaneously and your JS is (magically) 1kB, it's still 2 round trips before you can render anything instead of 1 (well, 4 instead of 3 for TCP connect, SSL handshake, HTML response). On poor mobile connections, a roundtrip will be 500ms+, so if you can render in less time than that on the server, it'll feel faster.

I've been looking for something like this forever! I loved AutoIt v3 on Windows, and osascript always felt super crippled in comparison (as well as impossible to look up documentation for). I've long since forgotten what I wanted to use this for, but I'll be sure to remember this for later!

It's a lot harder to reason about memory constraints on recursive programs.

The clearness and correctness of the code often ignores the possibility for stack overflow. Most naive implementations of DFS will hit the stack limit given trees that are all one long path from a single root to a single leaf.

Thank you for posting this!

We've done similar performance analysis at Khan Academy by using the navigation timing API and throwing the data into graphite. The most interesting part of this post for me is seeing that the numbers (server side times, median client times) are roughly the same as ours (http://i.imgur.com/wKglMTc.png)

One thing that I see in both GitHub's data and our data is this daily-periodic increase in both server and client times. Is that just load? We had theories that the clientside spikes may be caused by users in less CDN covered areas, or an increase in mobile usage, but were never fully satisfied by those explanations.

They don't inherently have to be sampled.

Just like you can define the perimeter of a circle given constants (x_0, y_0, r):

(x-x_0)^2 + (y-y_0)^2 = r^2

you can define the perimeter a metaball on a list of (x_i, y_i, r_i) as described in the post.

Beautiful page!

One small nit: when loading up the page on a mac, I see OS X window chrome around the examples, but Windows style C:\ file paths

The link to "Assembly" in the page footer is broken.

Can someone explain to me the migration path towards ES6 and syntax like this? This isn't syntactically valid ES5, so is there a reasonable path to making the browsers run ES6 directly?

If I just include it in a <script> tag directly, it'll throw syntax errors in any non-es6 compliant browser. So I'd have the transpile, and send down the es5 version of the code.

But if I'm transpiling, what's the point? I still have a build step, so why use ES6 over another compile-to-js language? The eventual promise, that years and years and years from now, all the non-es6 compliant browser will be dead, so I can send down the es6 code directly?