Because you work with CouchDB indexes using JSON and Javascript, it’s tempting to imagine there is something JSON or Javascript-y about how you use them. In the end, there isn’t: they end up on disk as B+ Trees, like pretty much every other database. In order to create appropriate indexes for your queries, it’s important to understand how these work. We can use tables as an easy mental model for indexes, and this article shows how that works for CouchDB’s Mango feature (also called Cloudant Query).
Avoiding using docker build --build-arg
to inject secrets or passowrds into
Docker image builds is established wisdom within the Docker community.
Here’s why.
TLDR: Using build args for secrets exposes the secret to users of your
image via docker history
.
Today I needed to take a HTTP request and extract the etag
header; the etag
was used as part of an
MVCC
implementation in a service I was using and I wanted to script an update to a
resource. I was doing this in a Makefile
so wanted to do this without firing
up a scripting language.
It turns out this is the domain of tools like sed
. sed
stands for stream
editor. It applies scripts to text streams which edit the content of the
stream. When you watch someone using sed
, the scripts look super-cryptic,
but in fact they’re not too bad. Like a regular expression, they benefit from
reading left to right; when viewed as a whole they are just a mess. In fact,
half of a sed
script is often a regular expression!
tl;dr If you are using stale=ok
in queries to Cloudant or CouchDB 2.x, you
most likely want to be using update=false
instead. If you are using
stale=update_after
, use update=lazy
instead.
This question has come up a few times, so here’s a reference to what the situation is with these parameters to query requests in Cloudant and CouchDB 2.x.
When I first came across docker a few years ago, probably late 2014, so a year after it was introduced at PyCon during 2013, I found it a confusing concept. “Like GitHub, but for containers” was a phrase that I recall from that period, which I think ended up causing a lot of my confusion – I conflated Docker Hub with docker the tool.
Since then, I’ve learned more about docker, particularly in the last year. I think that things started to click around a year ago, and over the past few months as I’ve looked further into Kubernetes and written my own pieces of software destined for container deployment I’ve formed my own mental model of where docker fits into my world. This post is about my writing that down to understand its coherency.