brandur

SF Traffic Rules

1. Don't run red lights by more than 5 seconds. 20 seconds if you're in a bus or large truck.
2. Rule 1 doesn't apply during high traffic situations. If your green is ending and traffic hasn't moved on the other side of the light, it's okay to block the intersection as long as you're not doing it by more than four or five cars deep. Remember, pedestrian walks are a nice place to come to rest as you won't be blocking cross traffic.
3. Know the SF intersections controlled by red light cameras, and be careful with rules 2 and 3 in them. Red light cameras are blatant revenue-generating scams cooked up by malicious and profiteering governments, but receiving a ticket from one may mean that you'll have to inconviently attend court before it can be properly thrown out.
4. If you didn't see that your light was changing, it's fine to park on top of the near pedestrian walk. In these cases pedestrians must go around you, even if it means edging into oncoming traffic. Remember, you're in a car and

brandur

gem install oauth
irb

consumer = ::OAuth::Consumer.new(
  "OAUTH_KEY", 
  "OAUTH_SECRET", 
 :site=>"https://www.readability.com/",

brandur

Engineering API-driven Applications Using Service Stubs

Developing applications against foreign services like the Heroku Platform API can unlock a powerful set of otherwise unavailable features, but can come with drawbacks: development must occur online, valid credentials are required, calls your code makes will reveal and manipulate real data, and API calls in tests have to stubbed out individually.

This article will offer a short overview on how these pain points can be

brandur

# ab -n 1000 -c 10 -A :xxx https://api.brandur.herokudev.com/apps
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking api.brandur.herokudev.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests

brandur

%h1 No

brandur

  $.ajaxSetup
    headers:
      Authorization: "Basic #{toBase64(":supersecretpassword")}"

brandur

> u = User.first
=> #<User id: 23, email: "brandur+t003@heroku.com", created_at: "2012-03-13 14:38:11", invited_by_id: nil, last_
login: "2012-03-13 14:39:46", reset_password_hash: nil, salt: nil, password_hash: nil, heroku_garden: nil, last_
git: nil, deleted_at: nil, payment_session_key: nil, confirmed_billing_info: nil, beta: nil, zendesk_created_at:
 nil, verified_at: nil, billing_name: nil, billing_address: nil, billing_card: nil, invited_on: "2012-03-13 14:3
8:07", invite_converted_on: nil, pending_payment_session_key: nil, cached_usage_total: nil, confirmed_billing_at
: nil, max_apps: nil, api_key: "ca0ff390071bf08e038752154dd2c05533a810a9", signup_source_id: 6, rate_limit: nil,
 first_name: nil, last_name: nil, invitation_secret: nil, password_hash_v2: "$2a$10$5PKpvQaDF2Lp0iGFl9KxKuoLO76s
4lMTFdizjxpgGqY4...", pref_site_version: nil, full_name: nil, accepted_tos_at: "2012-03-13 14:38:11", receive_ne
wsletter: false, suspended_at: nil, suspicious_since: nil>

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
+----------------------+----------------------+----------------------+