(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.
-- show running queries (pre 9.2) | |
SELECT procpid, age(clock_timestamp(), query_start), usename, current_query | |
FROM pg_stat_activity | |
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 | |
FROM pg_stat_activity | |
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
(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.
let cache = new Map(); | |
let pending = new Map(); | |
function fetchTextSync(url) { | |
if (cache.has(url)) { | |
return cache.get(url); | |
} | |
if (pending.has(url)) { | |
throw pending.get(url); | |
} |
Moved to https://github.com/ebidel/puppeteer-examples |
I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
Version 2, December 2004 | |
Copyright (C) 2011 YOUR_NAME_HERE <YOUR_URL_HERE> | |
Everyone is permitted to copy and distribute verbatim or modified | |
copies of this license document, and changing it is allowed as long | |
as the name is changed. | |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE |
key /path/to/whatever.pem | |
user deployer-of-doom | |
addr n.n.n.n | |
repo git@github.com:visionmedia/express.git | |
path /path/to/www/whatever | |
branch origin/master | |
command /path/to/www/whatever/restart |
Pulling data from remote Postgresql can be really slow. Many people try this, once.
That said, here is a mini guide of things to think about if you are pulling remote data.
If network between you and the remote data is slow, try running TileMill on a remote machine. For example, if your data is on Amazon's network, short of running TileMill on the same machine, at least running TileMill on another AWS machine would be faster. This is because network access within Amazon's cloud is going to be reliably faster than between AWS and the outside. Here is a guide for how to run TileMill from the command line on an Ubuntu Server (with no desktop) that works with AWS: http://www.mapbox.com/tilemill/docs/guides/ubuntu-service/. For details on setting up an AWS instance see https://gist.github.com/springmeyer/b0bbcd976378cf3e4e44 and for details for how to automate this see https://github.com/miccolis/aws-tilemill.
Debug locally to make sure you know how fast data should show up in a normal situa
package main | |
import ( | |
"image" | |
"image/color" | |
"image/draw" | |
"math" | |
"math/rand" | |
"time" |