Skip to content

Instantly share code, notes, and snippets.

@tautologicc
tautologicc / lmdb.tcl
Created April 6, 2022 14:48 — forked from antirez/lmdb.tcl
LMDB -- First version of Redis written in Tcl
# LVDB - LLOOGG Memory DB
# Copyriht (C) 2009 Salvatore Sanfilippo <antirez@gmail.com>
# All Rights Reserved
# TODO
# - cron with cleanup of timedout clients, automatic dump
# - the dump should use array startsearch to write it line by line
# and may just use gets to read element by element and load the whole state.
# - 'help','stopserver','saveandstopserver','save','load','reset','keys' commands.
# - ttl with milliseconds resolution 'ttl a 1000'. Check ttl in dump!
@tautologicc
tautologicc / Makefile
Last active April 18, 2022 17:13
Self-documented Makefile
.SUFFIXES:
help: Makefile ## display this help and exit
@echo 'Usage:'
@grep -E '^[a-zA-Z0-9_-]+:.*?## .*$$' $< | sort | awk 'BEGIN {FS = ":.*?## "}; {printf " %s\n %s\n", $$1, $$2}'
hello: ## emit the "hello, world" message
@echo Hello, world!
.PHONY: help compose
@tautologicc
tautologicc / presentation-tips.md
Created May 28, 2021 16:10 — forked from macintux/presentation-tips.md
Public speaking tips

1. Separation of immutable and mutable logic

Quite a lot of different people have been on the same trail of thought. Gary Bernhardt's formulation of a "functional core, imperative shell" seems to be the most voiced.

"Boundaries" - Gary Bernhardt

"Imperative shell" that wraps and uses your "functional core".. The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately. Functional core — Many fast unit tests. Imperative shell — Few integration tests

https://www.youtube.com/watch?v=yTkzNHF6rMs

@tautologicc
tautologicc / gist:ae97524b8a935e9ffa81c1f7e2fc408d
Created September 11, 2020 05:43 — 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