1. 6

It’s a short talk about an even shorter idea, but I find it entertainingly and engagingly presented, and the idea is so refreshingly simple – and the problem it solves, so important. It’s one of my favourite talks out of at least the last couple of years.

  1.  

  2. 1

    I love the suggestion, but, reasoning about it, it’s not so simple.

    I suspect some piece of code is dead, so I put Tombstone("2015-11-10") at the top of the method, branch, function, etc. Great now what? Tombstone has to log more than just the date, or I don’t know which code it’s referring to. Ok. I do, Tombstone("2015-11-10", "util.c", "first branch in funky()"). So, now I have log statements that describe when code is run, but I don’t really have a good way to check this.

    Perhaps I can do something like: grep -roP 'Tombstone\("\d+-\d+-\d+"', which gives me a list of the tombstones in the code, but then I have to do a pretty expensive search over the logs for the last 30 days against all the tombstones and find those that don’t return results?

    In addition, I better ensure that these Tombstones are rarely called, cause logging tends to be one of those things that isn’t cheap, and results in loss the more you do it.

    1. 3

      Frankly all of these questions are already adequately answered by the talk itself, therefore the only way I know how to answer you is basically to repeat its main points. So here goes:

      1. In at least some dynamic languages it’s very easy for the tombstone() function to figure out where it’s being called from. Perl has caller() which you can introspect the entire stack with, f.ex. In static languages it depends, in C/C++ you’d write it as a macro. I’m guessing you’d use reflection or something in Java and C#. In Go, well you got me, beats me. Anyway. So it was in my head canon for the presentation that obviously the tombstone function/macro logs source file and line number along with its parameters. Grep never even enters the picture for finding a tombstone, it’s just self-identifying.

      2. The tombstone logger must obviously stay out of the way of code that does actual work. There is no reason it can’t be extremely lossy and/or asynchronous, so that’s not a problem. You just write it to obey hard resource caps: rate limit it, use buffering to return quickly and write the buffer back asynchronously, drop any buffer overflow – you name it, whatever keeps its impact near zero. (This is the only part of the approach that takes some chops to implement.)

      3. When a tombstone pings back you know the code is alive so you remove that tombstone (which is easy, because, see above: you have the file and line). So then at some point you just grep for tombstones and sort them by date (which is a cheap operation performed off-line on a checkout of the code). Any tombstones that have stuck around for weeks or months or years (depending on the system and your level of confidence etc.), you can take that code back out and bury it.

      And that’s the gist of the talk.

      1. 1

        I thought the talk was light on details. I have to watch it again. That said, I probably lacked imagination when I wrote my previous comment.