A long time ago I read that you needed to see or hear something seven times before you’d take it in. It’s stuck with me.

I read a lot. Many of these things can be read once and then left to slowly accrete into my existing world view. But some I want to read again. Seven times, to make sure they go in.

For a year or so I’ve thought about writing an application to help with this, but never got around to it. I have added items to Omnifocus, but they get buried alongside other tasks. I wanted to work out a way to bring this… let’s call it “re-reading” into my usual processes.

About three weeks ago I came across two tools that excited me. Excited me enough to flounder about for things to build with them, and to pull “Seven Times” (for that is what I’d started to call it in my head) back to the surface. Those two things were Val Town and Xata.

But what would be my “usual process”? What user experience should Seven Times have? I am a heavy consumer of RSS feeds (using NetNewsWire and FeedBin). It took a while for me to connect the two, but once I’d had the idea of making Seven Times an RSS feed, I couldn’t shake it.

So here’s our goal: articles to be re-read appear in NetNewsWire, on my Mac or phone:

That screenshot isn’t a mockup, so let’s talk about Val Town and Xata, and how I used them to build a simple — but completely usable for just me — version of Seven Times in under a day.

This is part 3 in a short series about writing a simple index for JSON documents. Previously we talked about things in the abstract: how we’ll encode field names and values into our key-value store so they are easy to lookup. This time we make things a bit more real.

By the end of this post, we’ll have worked up to extracting the fields from our JSON documents, then inserting those fields into our PebbleDB key-value store. And we’ll look at querying for particular values with an equality query. Finally, the bare bones of a useful thing!

The title of the piece is actually Choose boring technology culture, but I don’t know whether I can get strike-through in titles. Regardless, I think the piece says a lot about how to create a workplace people want to turn up to on a grey, windy Monday morning:

Dan McKinley coined the phrase “choose boring technology” and the concept of innovation tokens nearly a decade ago.

“Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough… The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood. — @mcfunley

The moral of the story is that innovation is costly, so you should choose standard, well-understood, rock-solid technologies insofar as you possibly can. You only get a few innovation tokens to spend, so you should spend them on technologies that can give you a true competitive advantage — not on, like, reinventing memcache for the hell of it.

The same goes for running a business, and the same goes for organizational culture. We have collectively inherited a set of default practices that work pretty well, like the 40 hour work week and having 1x1s with your manager. You CAN choose to do something different, but you should probably have a good reason. To the extent that you can learn from other people’s experience, you probably should, whether in business or in tech; innovation is expensive, and you only get so many tokens. Do you really want to spend one on a radical reinvention of your PTO policy? How does that serve you?

Innovation gets all the headlines, but I would posit that what most companies need is actually much simpler: organizational health.

This is part 2 in a short series about writing a simple index for JSON documents. This index should automatically index JSON documents and enable a relatively simple set of queries over those documents, purely so I can learn more about the problems one encounters. The planned parts:

1. Encode primitive values.
2. Add field names to our index. (That’s this part).
3. Index JSON documents
4. Update and delete documents from the index
5. Find documents, extract a query planner and do an optimisation pass.

As a reminder, we want to take this JSON document:

{ "a": { "b": 12, "c": "foo" } }

And be able to find it using queries like:

"a.b" == 12
"a.c" == "foo"
"a.b" < 400
"a.c" > "e"

In part 1, we talked about how to take the primitive values in a JSON document — null, booleans, numbers and strings — and encode them into byte arrays in a way that a natural ordering between the values is maintained. This is the first step in creating the keys we need to be able to search for documents in our key-value store, PebbleDB.

In this part, we’ll see how to add the field name to this encoding. Then we’ll briefly cover how that enables equality and range queries. Let’s get going.

I’ve been quiet in November because I’ve been working on a small toy project. Now it’s become interesting, I want to write about it. In part, to prove to myself I actually understand what I’ve built, by showing I can explain it in words. I’ve been working through creating a simple database-like index, to understand the concepts involved more concretely.

(Where’s the code, you ask. It… requires some clean-up first. I’ll get there sometime soon!)

I’ve been reading Database Internals as part of a book club for the last few weeks. One of the noticeable things in the first few chapters is that nearly everything is based on a storage layer with a relatively simple interface, that of a key-value store where both key and value are byte arrays.

The stores are ordered by key and are used for both storing primary data (eg, key = primary key; value = relational row data) and for indexes (key = indexed value; value = referenced row’s primary key). Inspired by my reading, I decided to have a go at writing a simple index for JSON data.

I wanted to concentrate on the index part, so used an existing key-value store. Any would do, but I decided to use PebbleDB which is the underlying store used by CockroachDB. I chose PebbleDB because it was written in Go. As I was going to write my code in Go, using a Go storage layer meant that I could more easily peak at how the storage layer worked if I needed to.