elisp solves problems

Automated canary analysis is a deploy strategy wherein you direct a subset of your (production?) traffic to a canary version of your application. The idea is that your baseline application and your canary application will then be shipping metrics off to your metrics provider, and Kayenta + Referee help you determine whether your new code fails any metrics! This replaces developers manually looking at dashboards & logs during deploys.

Kayenta is an open source Java microservice for performing automated canary analysis - it's just one microservice of many that make up Netflix's Spinnaker platform. Referee is an open-source React frontend that sits in front of Kayenta and allows for rapid iteration of your canary configurations. This blog post will outline the steps I took to get this set up at $WORK recently!

You can read through the details below in this blog post, or go straight to the kayenta-referee-quickstart repo to get started right away.

This was a minor annoyance, but since my Google searches were particularly unfruitful, I figured I'd make a note of it. Our WeWork uses the Mersive Solstice client for broadcasting our devices to the meeting room televisions. It has the option to install its own audio driver to try to mirror the audio on its own.

At $WORK, we're creating an internal platform on top of Kubernetes for developers to deploy their apps. Our Ops people have graciously provided us with Mongo clusters that all use certificates signed by a self-signed certificate authority. So, all our clients need to know about the self-signed CA in order to connect to Mongo. For Node or Python, it's possible to pass the self-signed CA file in the code running in the application.

But, things are a little more complicated for Java or Scala apps, because configuration of certificate authorities is done at the JVM level, not at the code level. And for an extra level of fun, we want to do it in Kubernetes, transparently to our developers, so they don't have to worry about it on their own.

Recently at $WORK, we were writing a data migration script in node that needed to make a couple hundred requests. The first attempt was just to wrap everything up in a Promise.all:

const rp = require('request-promise-native');
const urls = [
    'url1',
    'url2',
    // ...,
    'url300'
];

Promise.all(urls.map((url) => rp.get(url)
                     .then(sendRelatedRequests)));

I use Emacs compilation mode to execute most of my scripts - it has a lot of nice built in things, including error highlighting with automatic navigation. But, I've noticed that with really long lines, the compliation buffer gets so slow that it makes Emacs unresponsive to input, and I end up having to frantically Ctrl+G and hope that I can stop the compilation before I lose Emacs and have to Force Quit it.