A tweet-sized debugger for visualizing your CSS layouts. Outlines every DOM element on your page a random (valid) CSS hex color.
One-line version to paste in your DevTools
Use $$ if your browser aliases it:
~ 108 byte version
| // @flow | |
| // Helper to extract inferred return type of a function | |
| type _ExtractReturn<B, F: (...args: any[]) => B> = B; | |
| type ExtractReturn<F> = _ExtractReturn<*, F>; | |
| // Use constants as normal | |
| const AGE = 'AGE'; | |
| const NAME = 'NAME'; | |
| // only need to provide types for arguments in action-creators |
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| server { | |
| index index.php; | |
| set $basepath "/var/www"; | |
| set $domain $host; | |
| # check one name domain for simple application | |
| if ($domain ~ "^(.[^.]*)\.dev$") { | |
| set $domain $1; | |
| set $rootpath "${domain}"; |