steve-chavez

version: '3'
services:
  db:
    image: timescale/timescaledb:latest-pg10
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: devices_small
      POSTGRES_USER: app_user
  pgrest:

steve-chavez

({ lib, newScope, stdenv, pkgs }: let

  # nicer aliases
  derive = stdenv.mkDerivation;
  concat = builtins.concatStringsSep " ";

  # vendored libuvc: don't build, just make sources available
  libuvc-src = derive {
    name = "libuvc-src";
    # using fetchgit instead fetchFromGitHub because

steve-chavez

FROM postgres

RUN metaDependencies="git \
    ca-certificates \
    build-essential" \
    && apt-get update \
    && apt-get install -y --no-install-recommends ${metaDependencies} \
    && apt-get install -y build-essential \
    && apt-get install make \
    && cd /tmp \

steve-chavez

There's no history in the database itself, if you're using psql you can use "\s" to see your command history there.

You can get future queries or other types of operations into the log files by setting log_statement in the postgresql.conf file. What you probably want instead is log_min_duration_statement, which if you set it to 0 will log all queries and their durations in the logs. That can be helpful once your apps goes live, if you set that to a higher value you'll only see the long running queries which can be helpful for optimization (you can run EXPLAIN ANALYZE on the queries you find there to figure out why they're slow).

Another handy thing to know in this area is that if you run psql and tell it "\timing", it will show how long every statement after that takes. So if you have a sql file that loo

steve-chavez

all: spi.so

spi.so: spi.o makefile
	g++ -shared -o spi.so spi.o
	cp --remove-destination spi.so /var/lib/postgresql/spi.so

spi.o: spi.cc makefile
	g++ -g -O2 -Wall -std=c++11 -fpic -c -o spi.o -I/usr/include/postgresql -I/usr/include/postgresql/9.4/server spi.cc

clean:

steve-chavez

./manage.py shell

from django.contrib.auth.hashers import make_password, HASHERS
make_password('test')
'pbkdf2_sha256$10000$vkRy7QauoLLj$ry+3xm3YX+YrSXbri8s3EcXDIrx5ceM+xQjtpLdw2oE='

make_password('test', 'abc')
'pbkdf2_sha256$10000$abc$MqJS5OAgSmf9SD9mfoY8fgLo8sSKmEcef0AjjMp1Q7w='

steve-chavez

-- From
-- + http://duspviz.mit.edu/tutorials/intro-postgis.php
-- + http://duspviz.mit.edu/web-map-workshop/leaflet_nodejs_postgis/
CREATE TABLE coffee_shops
(
  id serial NOT NULL,
  name character varying(50),
  address character varying(50),
  city character varying(50),
  state character varying(50),

steve-chavez

-- from https://gist.github.com/ruslantalpa/b2f10eb1b5f6dd0fc1c154e071a1c91b

\set API_SCHEMA_NAME test

with tables as (
    -- Return a list of entities in the database (tables/views/materialized views)
    select
        n.nspname as table_schema,
        relname as table_name,
        case

steve-chavez

Scaling your API with rate limiters

The following are examples of the four types rate limiters discussed in the accompanying blog post. In the examples below I've used pseudocode-like Ruby, so if you're unfamiliar with Ruby you should be able to easily translate this approach to other languages. Complete examples in Ruby are also provided later in this gist.

In most cases you'll want all these examples to be classes, but I've used simple functions here to keep the code samples brief.

Request rate limiter

This uses a basic token bucket algorithm and relies on the fact that Redis scripts execute atomically. No other operations can run between fetching the count and writing the new count.

steve-chavez

-- This script was generated by the Schema Diff utility in pgAdmin 4
-- For the circular dependencies, the order in which Schema Diff writes the objects is not very sophisticated
-- and may require manual changes to the script to ensure changes are applied in the correct order.
-- Please report an issue for any failure with the reproduction steps.

BEGIN;

-- Cast: money -> bigint