Skip to content

Instantly share code, notes, and snippets.

@pkuphy
pkuphy / RxJava.md
Created March 7, 2017 09:16 — forked from cesarferreira/RxJava.md
Party tricks with RxJava, RxAndroid & Retrolambda

View Click

Instead of the verbose setOnClickListener:

RxView.clicks(submitButton).subscribe(o -> log("submit button clicked!"));

Filter even numbers

Observable
    .just(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
// npm install eosjs-ecc
const crypto = require('crypto');
const assert = require('assert');
const eosecc = require('eosjs-ecc');
const publicKey = 'EOS5bmVmmRRRcdNERtn23Sc4H32e7rGLLXS8hvajUZVfP2PDicBCH';
const hash = (s) => {
const hash256 = crypto.createHash('sha256');
# Do the first 6 steps only once.
1. pip install --user alembic
2. bash: ``cd {{my_project}} && alembic init alembic``
3. bash: ``text_editor {{my_project}}/alembic.ini``
4. Change: "sqlalchemy.url = postgres://{{username}}:{{password}}@{{address}}/{{db_name}}"
5. bash: ``text_editor {{my_project}}/alembic/env.py``
6. Now, import your metadata/db object from your app.:
# {{my_project}}/{{my_project_dir}}/app.py
@pkuphy
pkuphy / keybase.md
Last active September 11, 2019 10:38

Keybase proof

I hereby claim:

  • I am pkuphy on github.
  • I am caigen1337 (https://keybase.io/caigen1337) on keybase.
  • I have a public key ASBfQLIxQeVd6Nwi79AZ8zO_o3xfrXZjWirPqIrRcmKHpwo

To claim this, I am signing this object:

@pkuphy
pkuphy / gist:de78d6e8ceab2c1a28af298b4ce648d1
Created November 14, 2019 22:22 — forked from chanks/gist:7585810
Turning PostgreSQL into a queue serving 10,000 jobs per second

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t