Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000
|-- show running queries (pre 9.2)|
|SELECT procpid, age(clock_timestamp(), query_start), usename, current_query|
|WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%'|
|ORDER BY query_start desc;|
|-- show running queries (9.2)|
|SELECT pid, age(clock_timestamp(), query_start), usename, query|
|WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'|
|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|
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.
In August 2007 a hacker found a way to expose the PHP source code on facebook.com. He retrieved two files and then emailed them to me, and I wrote about the issue:
It became a big deal:
The two files are index.php (the homepage) and search.php (the search page)
GitHub supports several lightweight markup languages for documentation; the most popular ones (generally, not just at GitHub) are Markdown and reStructuredText. Markdown is sometimes considered easier to use, and is often preferred when the purpose is simply to generate HTML. On the other hand, reStructuredText is more extensible and powerful, with native support (not just embedded HTML) for tables, as well as things like automatic generation of tables of contents.
This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.
Update: Woah, thanks for all the attention. Didn't expect this simple rant to get popular.
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
I've heard this before:
What I really get frustrated by is that I cannot wrap
console.*and preserve line numbers
If you blackbox the script file the contains the console log wrapper, the script location shown in the console will be corrected to the original source file and line number. Click, and the full source is looking longingly into your eyes.