- Site Reliability Engineering: How Google Runs Production Systems
- Operating Systems
- Operating Systems: Three Easy Pieces
- How Linux Works, 2nd Edition
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
- [Systems Performance: Enterprise and the Cloud](https://www.amazon.com/gp/product/0133390098?ie=UTF8&tag=deirdrestraug-20&linkCode=as2&camp=1789&creative=390957&creativ
I used to use NERD tree for quite a while, then switched to CtrlP for something a little more lightweight. My setup now includes zero file browser or tree view, and instead uses native Vim fuzzy search and auto-directory switching.
There is a super sweet feature in Vim whereby you can fuzzy find your files using **/*
, e.g.:
:vs **/*<partial file name><Tab>
I've had many people ask me questions about OpenTracing, often in relation to OpenZipkin. I've seen assertions about how it is vendor neutral and is the lock-in cure. This post is not a sanctioned, polished or otherwise muted view, rather what I personally think about what it is and is not, and what it helps and does not help with. Scroll to the very end if this is too long. Feel free to add a comment if I made any factual mistakes or you just want to add a comment.
OpenTracing is documentation and library interfaces for distributed tracing instrumentation. To be "OpenTracing" requires bundling its interfaces in your work, so that others can use it to time distributed operations with the same library.
OpenTracing interfaces are targeted to authors of instrumentation libraries, and those who want to collaborate with traces created by them. Ex something started a trace somewhere and I add a notable event to that trace. Structure logging was recently added to O
- Drift into Failure
- How Complex Systems Fail
- Antifragile: Things That Gain from Disorder
- Leverage Points: Places to Intervene in a System
- Going Solid: A Model of System Dynamics and Consequences for Patient Safety
- Resilience in Complex Adaptive Systems: Operating at the Edge of Failure
- Puppies! Now that I’ve got your attention, Complexity Theory
- [Towards Resilient Architectures: Biology
THEO SCHLOSSNAGLE (Circonus) - Techniques and tools for a coherent discussion about performance in complex architectures | |
MITCHELL HASHIMOTO (Hashicorp) - Automating the Modern Datacenter, Development to Production | |
MARTIN KLEPPMANN (LinkedIn) - Using logs to build a solid data infrastructure | |
CAITIE MCCAFFREY (Twitter) - Implementing the Saga Pattern | |
TAMMER SALEH (Pivotal) - Microservice AntiPatterns | |
PAUL BUTCHER (Ten Tenths Consulting, Pragmatic Programmers) - Concurrency: It's harder (and easier) than you think | |
JEREMY EDBERG (Netflix) - Building Reliable Distributed Data Systems | |
COREY HAINES (CoreyHaines) - Fun with the lambda calculus | |
DAVID NOLEN (Cognitect) - The Front End Architecture Revolution | |
MICHAEL NYGARD (Cognitect) - Architecture without an end state |
This gist started with a collection of resources I was maintaining on stream data processing — also known as distributed logs, data pipelines, event sourcing, CQRS, and other names.
Over time the set of resources grew quite large and I received some interest in a more guided, opinionated path for learning about stream data processing. So I added the reading list.
Please send me feedback!
# Original Rails controller and action | |
class EmployeesController < ApplicationController | |
def create | |
@employee = Employee.new(employee_params) | |
if @employee.save | |
redirect_to @employee, notice: "Employee #{@employee.name} created" | |
else | |
render :new | |
end |