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.

I upgraded from an iPhone 13 Pro to a 15 Pro about a month ago. I enjoy looking back at older first impressions pieces, such as AirPods Pro: first impressions. So herewith, first impressions of the iPhone 15 Pro.

• I really like the update to the shape. Rounded rather than chamfered edges feel a lot better in my hand. I ended up using a case for the 13 Pro to round off its almost sharp edges. I’d never used a case before, and being able to go caseless once again makes me very happy.

• Titanium’s slightly lower conductivity of heat also contributes to a more pleasant hand-feel. It doesn’t take the heat from your skin so quickly as aluminium or steel. A friend commented this felt a little plastic-like, and I can see why. But I like it.

• The weight difference is surprisingly noticeable. It took me by surprise when I picked the phone up in store. This discussion around moment of inertia rings true for me — it feels more than 10% lighter.

• The Dynamic Island has really grown on me. I love the way it anchors animations to the hardware, bringing software and hardware together in a way I’ve not felt before. Some of the animations still seem a little “look at me using this new feature!”; maybe they will be moderated over time. Anyhow, a much larger difference than I anticipated.

• I found choosing a colour harder than usual. None of the colours really grabbed me, but I did feel something pulling me towards the Natural titanium colour. It’s grown on me over the month I’ve had it; I’m now rather pleased with the choice.

• Like the always-on face for Apple Watch, I’ve quickly grown used to the always-on screen. One touch that I find almost endearing is the way the phone sneakily turns off the screen when no-one’s looking. When I catch the phone doing this, and it quickly re-illuminates the screen like nothing happened, I like pretending it’s a little embarrassed to be caught out.

  Clearly there’s a lot of continual environment scanning going on. It’s impressive this is less power-hungry than a screen nowadays.

While the camera is improved and the screen is creeping ever closer to being completely flush with the edge, in the end it is the feel of the hardware that really pulls me to this phone. It’s one of the nicest iPhones in the hand since the iPhone 4 or even perhaps the 3GS, with its sublime curved back.

I’m really happy with this phone. To the extent I plan to keep it three years rather than my usual two. We’ll see if I can stick to that.