brandur

require "json"
require "time"

#
# usage: releases.rb <app>
#

def get_releases(app)
  # use curl for -n
  JSON.parse(`curl --silent -n -H "Accept: application/vnd.heroku+json; version=3" -H "Range: seq ..; order=desc, max=1000" https://api.heroku.com/apps/#{app}/releases`)

brandur

Force pull request's diff to reset itself against target branch

git checkout feature-branch
# empty commit; don't worry, this will not show up in the final pull
git commit --allow-empty -m "Empty commit"
git push origin feature-branch
# hard reset to before empty commit
git reset --hard HEAD~
git push -f origin feature-branch

brandur

gojsonschema issue #14 repro

Clone into $GOPATH and run:

git clone https://gist.github.com/fb3eb8e804cfbf9e1b7d.git repro
cd repro
go build
./repro

brandur

{
    "$schema": "http://json-schema.org/draft-04/heroku-hyper-schema#",
    "id": "http://json-schema.org/draft-04/heroku-hyper-schema#",
    "title": "Heroku JSON Hyper-Schema",
    "allOf": [
        {
            "$ref": "http://json-schema.org/draft-04/hyper-schema#"
        }
    ],
    "definitions": {

brandur

Validation Results

prmd verify

$ prmd verify docs/v3/schema.json
docs/v3/schema.json: Missing `#/id`
docs/v3/schema.json: Missing `schemata/build-result#/definitions/identity`
docs/v3/schema.json: Missing `schemata/config-var#/properties`
docs/v3/schema.json: Missing `schemata/config-var#/definitions/identity`

brandur

But why gen a new id if someone passes you an id? Just use the supplied id in the called srvc.

This is certainly disputable territory, but the main motivation is that depending on service architecture, a single incoming request can balloon out into a full tree of backend requests because requests can map 1:N between any two components. Assigning every request in every component a unique ID allows any particular request to be isolated, while still allowing the any subsection of the tree to be viewed all at once.

Visually, this might look something like this:

      Component 1            Component 2            Component 3
+----------------------+----------------------+----------------------+

brandur

diff --git a/lib/api/middleware/request_id.rb b/lib/api/middleware/request_id.rb
index 9367bf7..255f4e4 100644
--- a/lib/api/middleware/request_id.rb
+++ b/lib/api/middleware/request_id.rb
@@ -8,7 +8,8 @@ def initialize(app)
     end
 
     def call(env)
-      request_ids = [SecureRandom.uuid] + extract_request_ids(env)
+      extracted_request_ids = extract_request_ids(env)

brandur

Keybase proof

I hereby claim:

• I am brandur on github.
• I am brandur (https://keybase.io/brandur) on keybase.
• I have a public key whose fingerprint is FC35 6F94 2F12 2F7D 5B87 EB64 E906 76B1 78CC 90AA

To claim this, I am signing this object:

brandur

Coffee Collective Aeropress Recipe

• Use standard orientation (i.e. not inverted).
• 16g coffee.
• Add water to get to 40-50g combined. Allow grinds to bloom for 15s.
• Add water to get to 230g.
• Do not stir.
• Press over a period of 25s. Stop when you hit the top of the grinds.

brandur

Go Pipelines

This document demonstrates a basic pipeline in Go and talks about a risk in in implementing them. Keep in mind that:

• Using FizzBuzz here is contrived, but quite a nice way to demonstrate the concept. Obviously there is no advantage to running the basic workload of FizzBuzz in a Goroutine, but if the task involved heavy computation or long lived I/O, it starts to make a lot more sense.
• The problem discussed only applies to Goroutines that actually need to have a way to