Before you can change a software project, you must understand how it works. The time to make a small change can be dwarfed by the months-long slogging chore of reading the code to conceptualize the software system. This barrier to entry causes errors, slows new-hire productivity and discourages new contributors to open source projects. That's why it feels like lip service when we say that software is meant for humans first and computers second. We build many tools to help us write code, but few to help us read it. I present a tool that aids software comprehension by leveraging program slicing, test suites, code coverage, and a few compiler techniques.
There is little guidance on the tradeoffs and decisions to make when using channels in a public API. The Go standard library provides very little guidance on this design issue. This talk covers in depth a set of principles and tradeoffs on how to use channels appropriately in public APIs. The talk is based off of this blog post.
At Twilio, I built Ratequeue, a fast, distributed, fault-tolerant task queue that can be used to rate-limit items from a very large, changing set of open queues. Ratequeue is a small Dropwizard web serivce that manipulates a set of Redis Lua scripts. This talk discusses the architecture of the system as well as the details of how the Lua scripts work to manipulate Redis into efficiently enforcing rate-limits for many open queues across a cluster. Ratequeue handles the queueing for millions of call and SMS originations per day in the Twilio platform.
NATs and firewalls have helped deter users from running their own cloud services by making it unnecessarily difficult for non technical users to configure their routers and firewalls to allow them to run public services on their machines at home. Services like ngrok and srvdir have the power to help rebalance the internet by lowering the barrier to entry for these users to run public-facing services behind NATs and firewalls with zero configuration. I discuss the programmatic APIs I created with the intention that developers integrate tunneling directly into their apps as a first-class citizen. This talk additionally dives deeper into the technical details of the underlying libraries muxado and go-tunnel that I created as the foundational primitives to enable these technologies.
The origin story of ngrok: what is it, why I built it, how it works and some other lessons along the way about product design and customer support.
A meetup talk about how how to make your Go applications update themselves from the Internet! The talk covers how to integrate the updating library go-update into your application so that it can update itself with just a few lines of code. I go on to discuss how to use equinox.io to automatically distribute application updates with advanced techniques like code signing, gradual rollout, binary patching, and stable/beta release channels.
Building and deploying ngrok is a difficult challenge because of how it is deployed. Unlike most applications which run on Linux servers in datacenters, ngrok is downloaded and run on every popular operating system and architecture (and many unpopular ones too!). Supporting ngrok in these untrusted and varied environments comes with an interesting set of challenges that most application authors don't deal with. This talk discusses thoughts and techniques used to build and deploy ngrok for those environments including automatic updates, building user-friendly terminal UIs, coping with very old hardware, working around uses of CGo in the standard library and more.