Weight Tracking – Part 2
So, in writing the previous post on my Weight Tracking spreadsheet, I came upon a bit of a conundrum. I wanted to export my graph as an image, but I could not figure out how to do that in Numbers. I am sure that there is a way to do so, but it was not immediately obvious, even with a brief Google search. So, being a good engineer, I decided to roll my own weight tracking script.
Writing my own script has several advantages. First, writing my own script gave me a simple project to begin learning Ruby, something I have been wanting to do. Second, it allows me to extend the script with functionality that might be clumsy in a spreadsheet. Right now, I am just keeping track of the same information that I did in the spreadsheet, dates and weights, only I track it in a simple text file. The script calculates the sliding average for me. If needed, I can easily munge the data in other ways or pull together a secondary text file with other information like my workout routine. I know that I could do the same thing in a spreadsheet, but I like the flexibility that a full programming language gives me over the comparative restraint that I feel when I am hacking together formulas in a spreadsheet. Additionally, my data is kept in a simple text file instead of being tied to a Numbers spreadsheet.
Finally, and most importantly, I was easily able to pull in a library that allowed me to plot my weight and the sliding average of my weight over time and export it as an image file.
There are two obvious improvements that I will likely implement. First, I am calculating the sliding window average of my weight as an integer. That is what causes the strange steps on the graph. I will probably change to calculating the average as a real number, just to make the graph a little smoother. Second, I think that I want to have more points on the X-axis of the graph. Looking at it, I think that the first of each month should be marked on the graph, possibly with lines of demarcation running in the Y-direction at each monthly border. I will have to play around with it and see what all I can do with the graphing library. That is the great thing about being a programmer; if the software you are using does not do what you want it to do, you can either fix it or write your own version.
Weight Tracking
In late March, I decided to do something about the abysmal shape I was in. On the exercise front, I started doing push-ups, sit-ups, and walking/running six days a week. Long before I started any of that, I began putting my data collection skills to use by tracking my daily weight. So, in the last few days of March, I set up a simple spreadsheet to log my weight every day just before I get in the shower. I graph my weight versus time off to the side of the spreadsheet. Additionally, I calculate a 7-day sliding window average of my weight to try and smooth out the little fluctuations that occur from day to day. I also graph this and overlay it on the raw weight data.
In the early April time frame, I was very carefully watching what I ate and, as the month moved on, I noticed my weight graph showing a nice, downward trend. Then, as I began seriously working through the push-ups and sit-ups, before I began walking and running, I started to notice the graph sloping back up. At the moment, I am attributing that to the muscle-building workout that I have been doing, since I have not changed my eating habits in the past several weeks. Starting the walking and running seems to have curbed the incline, but I am still not doing a large enough amount of cardio exercise to push the trend back downwards.
I am considering augmenting my spreadsheet with push-up, sit-up, and walking/running data per day to see if I can correlate a decrease in my weight to increases in my workout routine. If everything is going well, I would expect to see that correlation. If not, I suppose that means that my eating habits have changed and I just have not noticed.
Task Management – Task Tracking
As I mentioned before, Tasks has its share of warts, but it seems to work well enough for me at the moment. In keeping with the GTD tradition, I split my tasks into two categories — projects and actions. Tasks does not have the concept of projects; it only has the concept of tasks. However, I can assign sub-tasks to a task. Additionally, I assign a tag of my choice to a task. So, I combine those to features to give me project support:
- A project is defined as: a root-level task that is tagged with 'project' OR a root-level task that is tagged with 'someday'
- An action is defined as: either a sub-task of a project OR a root-level task that is not tagged with 'project' or 'someday' and has a date assigned to it.
I use these conventions to help me do my weekly review every Sunday morning. First, I scan the actions associated with my projects and try to schedule actions for the upcoming week. Next, I scan my someday projects and decide whether I want to promote them to projects or not. This all works fairly well in Tasks because I can look at my tasks by tag.
On a daily basis, I tend to heavily use the Upcoming screen in Tasks. The upcoming screen nicely breaks down in Overdue tasks, Due Today tasks, and Due within 7 Days tasks. So, at any point, I can see what I need to get done that day and in the near future. If, in some strange twist of fate, I run out of tasks to work on that are either overdue or due that day, I fall back to tags again. All of my actions are tagged with a context like 'home', 'work', 'web', 'errands', etc. When nothing else is pressing, I check the tag for the appropriate context I am in and try to see if there is anything that I have the energy to work on. If so, I work on that. Otherwise, I can rest.