ri/blog

Got a bunch of good debugging and polishing done this week, but no dramatic frontend improvements. The most important thing I really want to demonstrate this week is everything going smoothly, including things that I’ve tried to demo before, but couldn’t (due to various glitches).

It’s probably important to point out that the go-deje library, where most of the complexity is implemented (and where most of the bugs are) has had 100% coverage testing for awhile now. As good as it is, it does not catch every bug, it’s only a basic starting point that can be caught with a lint-y pass. I regularly have to write additional tests that cover functions that are already 100% tested by line, because covering every line does not guarantee covering every usage scenario. I can give two examples right off the bat, both of which were unearthed and headshot in a single ticket:

  • The golang JSON package treats all numbers as float64. When creating deje.state.Containers, we test what type an object is, and create a new underlying type accordingly (mapContainer, sliceContainer or scalarContainer). We raise an error for unfamiliar types. Because the list of valid scalar types didn’t include float64, any from-JSON numbers could not be converted to Containers, which made Event.Apply break. The fix was to add float64 as a valid scalar type.
  • The code to export a sliceContainer as an ordinary []interface{} works for any slice with at least one element. However, the algorithm fails for the zero-element case, by outputting [null] instead of []. The solution was to handle the zero-length case at the top of the function, before handling the general case with the existing algorithm.

For both problems, we started with 100% coverage, because the problem existed in lines that were not written yet. So while Go makes it practical and useful to achieve 100% coverage, try not to treat that as a guarantee of perfection.

Demo 04 - Fixie Bike Edition

Broadcasted on 7-27-2014

http://youtu.be/kHJuytrYDSA

One minor feature, but multiple bug fixes. We’ll see how much I’ll be able to visually demonstrate.

UPDATE: Was able to actually explain all the bug fixes that made this week’s demo a success. Everything went really smoothly. It was nice. Definitely need to ship a fix for that topic issue, though.

Changelog:

What next?

It would be really cool if CLI clients were better capable of bootstrapping themselves, when starting from a file, with no peers. Partly because this doesn’t require interaction with the browser client, which can fall over for complex documents. I’m hoping to accomplish this with a temporary approach to timestamps.

EDIT: As usual, I did something completely different from the plan.