This is a followup to our previous post on magic strings.
There are three (soon to be four) magic hashtags that Beeminder can add to a datapoint comment. They’re reasonably self-documenting and if you’re a newbee you probably don’t care about any of this nitty-gritty. But we just finished cleaning this all up in the codebase and we want to document how everything works now. Also we have a heads-up for veterans who may have been counting on some crufty backwards-compatibility for wild use cases that even we can’t fathom. You’ll need to get with the program, as laid out here. (But of course if this is ruining your day or murdering children, definitely let us know and we’ll help get you sorted.)
#SELFDESTRUCT (or #THISWILLSELFDESTRUCT)
We’ve talked about this magic string extensively in the forum and in our previous blog post, but we’ll repeat everything here for completeness.
First, a quick review of Pessimistic presumptive reports (PPRs). Think of them as the do-less analog of flatlining on a do-more goal. For a do-more if you don’t enter any data, Beeminder assumes you did nothing, and soon enough that’ll derail you. If you don’t enter anything on a do-less goal, it’s pretty critical that Beeminder not presume you did nothing, since that would have you safe forever and you could just stick your head in the sand and pretend the goal didn’t exist. Instead Beeminder presumes you did twice the daily amount you committed to stay below, on average, if you don’t report anything. Meaning that, as with a do-more goal, not reporting any progress means you’ll soon derail.
The other thing to know about PPRs is that they automagically self-destruct when you enter an actual datapoint. And the mechanism by which they do that is to include the string #SELFDESTRUCT in the datapoint comment. (Or #THISWILLSELFDESTRUCT — we use that variant to make it as self-documenting as possible.)
That means you can make your own datapoints self-destruct if you want! Why would you want that? Well, superuser Alys has a very clever use case. Suppose Alys has a lot of safety buffer on a goal, but wants to get herself to do at least some work on it today. She enters a #SELFDESTRUCT datapoint with a large negative value (for a do-more goal), putting the goal into the red, which sorts it to the top of her dashboard. Once she’s done some work and enters the data — voila! The #SELFDESTRUCT datapoint is automatically removed and her safety buffer is safely back where it belongs.
Now the fine print and a heads-up.
If for some reason you try to add multiple #SELFDESTRUCT datapoints for the same day, separately or as a batch, each will annihilate its predecessor and only the last of them will remain. Probably that’s the logical, natural thing to happen, but, again, wild use cases we can’t fathom, so we thought we’d spell it out.
And the heads-up is that in the past, datapoint comments that started with “PESSIMISTIC PRESUMPT…” were yet another way to make a datapoint self-destructing. That’s officially gone now and we appended ” #SELFDESTRUCT” to all such datapoints so nothing changes on you retroactively (we don’t think). (And actually we used @SELFDESTRUCT with an “@” instead of a “#” in this case, for a reason we’ll talk about at the end.)
#DERAIL
This one essentially marks a dummy datapoint indicating when a derailment happened. Such datapoints are displayed on your graph as a red triangle, pointing up or down depending on which side of the bright red line was the bad side to cross into.
We want this recorded as if it’s a datapoint in order to record exactly where you were at the point when you derailed. There’s not necessarily a real datapoint at that point due to flatlining. That is, there’s a good chance that if you derailed today, it’s due to not entering any data. For a do-more goal, we show a faint triangle today with the same y-value as yesterday, indicating a presumed zero for today. So the #DERAIL datapoint reifies that into an angry bright red triangle.
(This one also had some backward-compatibility that we ruthlessly excised. Derail datapoints used to be marked by a datapoint comment that started “RECOMMITTED ON”. No more!)
#RESTART
Restarting a goal that’s been archived is very similar to derailing a goal in terms of the dummy “#RESTART” datapoint, and what we do with your bright red line. First we lock the red line in place up until now, so we aren’t changing the past. Then we make the line jump to whatever your current y-value is and add an initial flat spot and the new rate. We also add a #RESTART datapoint, analogous to the #DERAIL datapoint, and as extra insurance that we don’t accidentally trigger the derail condition.
In the case of an ordinary do-more goal that was properly archived it’s probably superfluous, though still nice to have it demarcated.
In other cases it can be totally fluous. Take the case of restarting an odometer-type goal. Your current datapoint might have no correlation to your last datapoint at all. You might have gone back to start your book over again because it’s been so long, or you stopped beeminding your email inbox, and it ballooned back up from the optimistic 10 messages you’d committed to the last time you beeminded it. Or maybe the goal wasn’t archived in the usual way — say you lost your credit card and had to cancel it, and then an ordinary derail caused the graph to freeze because your payment didn’t go through. In any of those cases, the usual flat-lined datapoint from whatever your last entered value was might not be safely on yesterday’s red line. That’s when a #RESTART datapoint is required to keep it from insta-derailing when you restart. Because “red yesterday” is the core criterion Beeminder uses to decide if you derailed. A Beeminder graph matrix has to be continuous, so there’s no way to indicate that yesterday didn’t count because the goal was inactive so we have to retroactively make it have-been active and safe yesterday.
Ok, phew, that was really more than you wanted to know. Probably as a user you only care about this one as a marker of, as it says in the hashtag, when you restarted a goal.
Coming soon: #TARE
As in taring a scale. Tune in next time for the whole story on this one.
More Fine Print, The Hashtag Feature, and Alternate Syntax
All of these are case-sensitive — they have to be in all caps. And if there’s anything else in the comment, it has to be separated from the hashtag by whitespace. So if you make a datapoint comment like “I’m gonna #SELFDESTRUCT!” it won’t work unless you stick a space in front of the “!”.
Ok, do you know about the hashtag feature? It’s in the privacy section of graph settings: “Show hashtags from comments on the graph”. It lets you annotate your graph with any hashtags you like by including them in your datapoint comments. This includes all magic hashtags above. Mostly we think that’s right and proper, explicitly labeling derailments, PPRs, restarts, and tarings. But if don’t want those annotations, only your own custom-crafted annotations, we finally have a solution. Namely, all the magic strings work equally well with “#” or “@”. If you use the “@” versions — @SELFDESTRUCT, @DERAIL, @RESTART, and (soon) @TARE — then everything we’ve said about these magic strings still applies, but they won’t be hashtags and so won’t be shown explicitly on your graph, whether or not you have the hashtag feature turned on.
For now, those who want only their own hashtags annotating their graphs will have to manually change the “#” to “@” on the instances that Beeminder generates. We’re reluctant to add an explicit setting for this unless there’s enough demand for it. So let us know!