| /* | |
| * This work is free. You can redistribute it and/or modify it under the | |
| * terms of the Do What The Fuck You Want To Public License, Version 2, | |
| * as published by Sam Hocevar. See the COPYING file for more details. | |
| */ | |
| /* | |
| * Easing Functions - inspired from http://gizma.com/easing/ | |
| * only considering the t value for the range [0, 1] => [0, 1] | |
| */ | |
| EasingFunctions = { |
| Latency Comparison Numbers (~2012) | |
| ---------------------------------- | |
| L1 cache reference 0.5 ns | |
| Branch mispredict 5 ns | |
| L2 cache reference 7 ns 14x L1 cache | |
| Mutex lock/unlock 25 ns | |
| Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
| Compress 1K bytes with Zippy 3,000 ns 3 us | |
| Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
| Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
An ongoing project to catalogue all of these sneaky, hidden, bleeding edge selectors as I prepare my JSConf EU 2012 talk.
Everything is broken up by tag, but within each the selectors aren't particularly ordered.
I have not tested/verified all of these. Have I missed some or got it wrong? Let me know. - A
A friendly reminder that you may need to set this property on your target/selected element to get the styling results you want:
-webkit-appearance:none;
| #!/usr/bin/python3 | |
| # By Steve Hanov, 2011. Released to the public domain. | |
| # Please see http://stevehanov.ca/blog/index.php?id=115 for the accompanying article. | |
| # | |
| # Based on Daciuk, Jan, et al. "Incremental construction of minimal acyclic finite-state automata." | |
| # Computational linguistics 26.1 (2000): 3-16. | |
| # | |
| # Updated 2014 to use DAWG as a mapping; see | |
| # Kowaltowski, T.; CL. Lucchesi (1993), "Applications of finite automata representing large vocabularies", | |
| # Software-Practice and Experience 1993 |
This is a strawman proposal for adding pattern matching to ECMAScript. Pattern matching is useful for matching a value to some structure in a similar way to destructuring. The primary difference between destructuring and pattern matching are the use cases involved - destructuring is useful for binding pieces out of larger structures whereas pattern matching is useful for mapping a value's structure to data or a set of behaviors. In practice this means that destructuring tends to allow many shapes of data and will do its best to bind something out of it, whereas pattern matching will tend to be more conservative.
Additionally, the power of pattern matching is increased substantially when values are allowed to participate in the pattern matching semantics as a matcher as well as a matchee. This proposal includes the notion of a pattern matching protocol - a symbol method that can be implemented by objects that enables developers to use those values in pattern matching. A common scenario w
| # Download latest archlinux bootstrap package, see https://www.archlinux.org/download/ | |
| wget 'ftp://ftp.nluug.nl/pub/os/Linux/distr/archlinux/iso/latest/archlinux-bootstrap-*-x86_64.tar.gz' | |
| # Make sure you'll have enough entropy for pacman-key later. | |
| apt-get install haveged | |
| # Install the arch bootstrap image in a tmpfs. | |
| mount -t tmpfs none /mnt | |
| cd /mnt | |
| tar xvf ~/archlinux-bootstrap-*-x86_64.tar.gz --strip-components=1 |
| ❯ rollup --version | |
| rollup version 0.25.3 | |
| ❯ time rollup -c ./rollup.js | |
| rollup -c ./rollup.js 4.65s user 0.22s system 118% cpu 4.131 total | |
| ❯ time webpack | |
| Hash: ebb00bbccd954c114d3c | |
| Version: webpack 2.0.7-beta | |
| Time: 3623ms |
A maintainable application architecture requires that the UI only contain the rendering logic and execute queries and mutations against the underlying data model on the server. A maintainable architecture must not contain any logic for composing "app state" on the client as that would necessarily embed business logic in the client. App state should be persisted to the database and the client projection of it should be composed in the mid tier, and refreshed as mutations occur on the server (and after network interruption) for a highly interactive, realtime UX.
With GraphQL we are able to define an easy-to-change application-level data schema on the server that captures the types and relationships in our data, and wiring it to data sources via resolvers that leverage our db's own query language (or data-oriented, uniform service APIs) to resolve client-specified "queries" and "mutations" against the schema.
We use GraphQL to dyn
| import { h, Component } from 'preact'; | |
| import Markup from 'preact-markup'; | |
| import register from './preact-custom-element'; | |
| // just a proxy component: WC -> Preact -> WC | |
| const A = () => <x-b foo="initial foo from <x-a>" />; | |
| // stateful component that can re-render | |
| class B extends Component { | |
| render(props, state) { |
| // this is a generic runner for iterators | |
| // for every yield, it checks to see if any time is remaining | |
| // on the idle loop, and executes more work if so. | |
| // else, it queues up for the next idle period | |
| function go(it, callback){ | |
| requestIdleCallback(deadline => { | |
| let val = it.next() | |
| while(!val.done){ | |
| if(deadline.timeRemaining() <= 0){ |
