Bizarre nerdtastic uses of Beeminder, aka beeminding outside the box

I’m repeating this story from a daily beemail in hopes of collecting more outside-the-box use cases for Beeminder. It would be fun to do a followup post to this classic from 5 years ago: https://blog.beeminder.com/box/

Ok, here’s my entry!

On Apple laptops, if they’re overheating, a process called kernel_task takes up more and more of the cpu, to throttle it. If the laptop is very hot, kernel_task will crowd out everything and even typing and clicking becomes very sluggish.

I’ve had my laptop for almost 3 years now and don’t want to upgrade because the internet tells me that the new Macbooks are worse than the one I have. And I think the biggest problem with mine is that it’s full of literal dust. This is getting to be a long, boring backstory.

I wanted to see how much cpu time kernel_task was eating up so I made this graph:

Every day (or every few days – being an odometer goal it doesn’t matter) I tell Beeminder the total cpu time that kernel_task has eaten. Thanks to the odometer reset feature, if I reboot the computer I can just add a zero datapoint and keep reporting whatever total time the Activity Monitor app tells me.

And thanks to @saranli’s visual road editor I can retroactively make the yellow brick road match the data. I often find that eyeballing like that is better than the fanciest data-smoothing algorithms. For example, for the above graph I didn’t count the first week since I was traveling and thus had my computer off more than usual then (normally it’s on 24/7). Also starting with a flat week ensures I won’t derail if I actually fix my laptop.

So now I can try different things (the obvious one being opening this puppy up and blowing the dust out) and see what happens to the slope of those datapoints.

Anyone have a more unintended use of Beeminder than that? Stories of merely mildly-outside-the-box beeminding also solicited. We know from your emails there are a lot of gloriously convoluted ones out there!

1 Like

I use beeminder as a very fast and loose uptime monitor.

I have a server that I log into infrequently, that among other things, runs cron jobs to facilitate all of my “beedata” goals.

Most of those goals have a pretty wide berth (things like student loans, where they have to be paid no less than 7 days in advance, because that’s actually how long it takes their website to reflect that the payment has really been applied, … so the more buffer I get, the less interest I pay, but the interest rate is low, and the real deadlines are so far in the future it’s like they’re not even real… I might die before then, hope not, but who knows… side tangent!)

So back to the uptime monitor… if no data is reported for two or three days, I don’t expect most data points to land in the danger zone. But I do want to know if data stops being reported, and it might be nice to know if that machine went down in general!

Probably not like a pager though. It’s not that important. I’m not even sure I need to know within 24 hours if that machine went down. I just need to go shake someone on a Slack channel to bring the box back up when this happens once or twice every one or two years. So I’ve got this data point that gets reported once a day, that I move to alternate sides of the road every 400 days or so, to practice adjusting goals with tight constraints.

It just adds or subtracts one every time it sees that today is a new day and there hasn’t been a data point added yet. Depending on which side of the road I’ve set the point to be on, I might get some e-mail alerts from beeminder and derail if I’m not paying attention, or I might not even notice for a couple of days!

It took about 20 minutes to set up. (That’s my story and I’m sticking to it…) I think it was my first example beeminder autodata.

I didn’t know if it served any purpose at the time, the goal was to write an autodata in about 20 minutes. I’ve rewritten the thing several times to get more practice at doing autodata goals and to change the shape of the graph. The particular shape of the graph is not really important and the goal is not uptime, the goal is to get my attention when the event arrives without blowing the event out of proportion, and to give me something to look for when I visit Beeminder graphs.

What’s important is that whenever I do check on my goals, this one stands out if it has an unusual shape (because the machine went down), and in that case I get a reminder (one way or another) that something may have went wrong on my server, so I probably better go shake that person and find out!

2 Likes

Similarly, it’s my uptime monitor. I use Beeminder to monitor whether our webhook callbacks are working, and to record how long they seem to be taking in the datapoint comment:

This is because I chain together loads of goals using a dancer script

e.g.

  • doing a pomodoro in, say, Complice.co, adds a datapoint and a project-relevant comment to my pomodoro goal
  • that then adds 25 minutes and a project-relevant comment to my timelog goal. (Using my task-timer does the same, but with more arbitrary lengths of time!)
  • timelog entries get checked for billable-project tags and update my earn-more-money goal

Similarly, I used to have a general ‘sweat more’ goal that got a point if I did a swarm checkin at my gym, at the trapeze, at salsa class, or used run keeper to track a run of at least 5k, etc. All done with the same script.

2 Likes