Skip to content

Instantly share code, notes, and snippets.

@alexmoore
alexmoore / about.md
Last active Sep 26, 2015 — forked from jasonrudolph/about.md
Programming Achievements: How to Level Up as a Developer
View about.md

Programming Achievements: How to Level Up as a Developer

  1. Select a particular experience to pursue.
  2. Pursue that experience to completion. (Achievement unlocked!)
  3. Reflect on that experience. Really soak it in. Maybe a blog post would be in order?
  4. Return to Step 1, this time selecting a new experience.

This gist is a fork of the gist from this blog post.

@alexmoore
alexmoore / latency.txt
Created May 31, 2012 — forked from jboner/latency.txt
Latency numbers every programmer should know
View latency.txt
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 25 ns
Main memory reference 100 ns
Compress 1K bytes with Zippy 3,000 ns
Send 2K bytes over 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns
View Functional Core, Imperative Shell
http://www.infoq.com/presentations/Simple-Made-Easy
http://www.infoq.com/presentations/integration-tests-scam
http://blog.thecodewhisperer.com/2010/09/14/when-is-it-safe-to-introduce-test-doubles
http://youtu.be/yTkzNHF6rMs
http://pyvideo.org/video/1670/boundaries
http://skillsmatter.com/podcast/ajax-ria/enumerators
http://alistair.cockburn.us/Hexagonal+architecture
http://c2.com/cgi/wiki?PortsAndAdaptersArchitecture
http://www.confreaks.com/videos/977-goruco2012-hexagonal-rails
http://www.confreaks.com/videos/1255-rockymtnruby2012-to-mock-or-not-to-mock
@alexmoore
alexmoore / service-checklist.md
Created Sep 27, 2016 — forked from acolyer/service-checklist.md
Internet Scale Services Checklist
View service-checklist.md

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?