View .zshrc
# If you use bash, this technique isn't really zsh specific. Adapt as needed.
source ~/
# AWS configuration example, after doing:
# $ set-keychain-environment-variable AWS_ACCESS_KEY_ID
# $ set-keychain-environment-variable AWS_SECRET_ACCESS_KEY
# provide: "j1/yoursupersecret/password"
export AWS_ACCESS_KEY_ID=$(keychain-environment-variable AWS_ACCESS_KEY_ID);
export AWS_SECRET_ACCESS_KEY=$(keychain-environment-variable AWS_SECRET_ACCESS_KEY);

Internet Scale Services Checklist

A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."

Basic tenets

  • Does the design expect failures to happen regularly and handle them gracefully?
  • Have we kept things as simple as possible?

Keybase proof

I hereby claim:

  • I am adamvduke on github.
  • I am adamvduke ( on keybase.
  • I have a public key ASAdtHkKYGody9mlJ2r3_QeHa2uCosnLTuc9xRNrv8fdxwo

To claim this, I am signing this object:

View Caddyfile {
root /srv/
proxy / localhost:5000 {
except /assets
View postgres-replication-lag-functions.sql
CREATE OR REPLACE FUNCTION primary_streaming_byte_lag() RETURNS TABLE (client_hostname text, client_addr inet, log_location_diff_bytes numeric, total_byte_lag double precision, total_byte_lag_pretty text, replay_byte_lag double precision, replay_byte_lag_pretty text)
AS $$
( (cur_xlog * 255 * 16 ^ 6) + cur_offset) - ((replay_xlog * 255 * 16 ^ 6) + replay_offset) AS total_byte_lag,
pg_size_pretty((( (cur_xlog * 255 * 16 ^ 6) + cur_offset) - ((replay_xlog * 255 * 16 ^ 6) + replay_offset))::numeric) AS total_byte_lag_pretty,
View HTTP-1.1-400-Not-Found
curl -i ""
HTTP/1.1 400 Not Found
Content-Type: text/plain
Server: proxygen
Timing-Allow-Origin: *
X-Cache-Ts: 1447545792
Date: Sun, 15 Nov 2015 00:03:12 GMT
X-FB-Edge-Debug: BBUHPNJ58swqQlRj0vjMAzLKyzlubMK_sF7iftGX9VpdYAnw9_02fPGxmEeelkNXf_DeSr0oNybV0ztpT-DAjg
Connection: keep-alive
Content-Length: 9
View gist:99d5ddc67365ea814d8e
$ dig ANY
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.8.3-P1 <<>> ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62516
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
View nginx.conf
# nginx Configuration File
# Run as a less privileged user for security reasons.
user forge;
# How many worker threads to run;
# "auto" sets it to the number of CPU cores available in the system, and
# offers the best performance. Don't set it higher than the number of CPU
# cores if changing this parameter.

My largest Sidekiq application had a memory leak and I was able to find and fix it in just few hours spent on analyzing Ruby's heap. In this post I'll show my profiling setup.

As you might know Ruby 2.1 introduced a few great changes to ObjectSpace, so now it's much easier to find a line of code that is allocating too many objects. Here is great post explaining how it's working.

I was too lazy to set up some seeding and run it locally, so I checked that test suite passes when profiling is enabled and pushed debugging to production. Production environment also suited me better since my jobs data can't be fully random generated.

So, in order to profile your worker, add this to your Sidekiq configuration:

tar -zxvf credis-0.2.3.tar.gz
cd credis-0.2.3