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}"; |