brandur

redis-cell Informal Benchmarks

I got these results when comparing CL.THROTTLE to SET on my early 2015 13" 3.1 GHz i7 MacBook Pro (not connected to a power source at the time):

$ ruby bench.rb
SET
Took total of: 5.975439 s
Per iteration: 5.975439e-05 s (0.05975439 ms)

brandur

RE: RE: gh-ost

• Post #1: http://githubengineering.com/gh-ost-github-s-online-migration-tool-for-mysql/
• Post #2: https://brandur.org/fragments/gh-ost
• Post #3: http://code.openark.org/blog/mysql/mysql-vs-postgresql-gh-ost-perspective

Hi Shlomi,

First of all, my apologies for the tone of my original post. It was written without much reflection, and reading back through it, I see that it does in

brandur

Probably issues (see details below):

• The certificate returned is invalid.
• You are not using SNI.

The server is returning an invalid SSL certificate. By the "ST=Some-State" note, I would guess that this was probably self-signed at some point:

$ openssl s_client -showcerts -connect stoicreviews.com:443
CONNECTED(00000003)

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

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

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

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

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

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

{
    "$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": {