Monday, September 03, 2007
Annual Report: Journaling
In the annual report, I want to have a graph showing me how I've done on my journal. Have I been writing regularly? Have I been writing substantially? Have written more or less than in previous years. I'm not sure if this graph would be useful on a timeline or if it's better as an independent chart. Regardless, for the annual report, I think I'll use the metric of "words written" instead of "journal entries" written. That'll help me answer the question about substantial entries.
Collecting the data will be easy since I write my journal entries on the computer (or Palm Pilot and sync them). I have a program that counts the number of entries and it should be easy enough to modify it to count words too.
Saturday, August 18, 2007
Annual Report: Reserve Savings
Everybody should have some reserve savings for the metaphorical
rainy day. How are the family and I doing on this worthwhile goal? As
I mentioned in my post about a life events timeline this data would be
interesting to see next to a list of significant life events to help pinpoint
cause-effect relationships. After doing annual reports for a few years, one
should be able to spot seasonal trends and better plan for them.
What I want is a graph of reserve savings showing the balance throughout the
year normalized against the balance at the start of the year. This won't
reveal to all the world exactly how much savings we have, but will show
how we did at building on (or burning up) the reserve.
The data is easy enough to get. E*Trade stores a list of all the
transactions for our money market fund and displays them in a table like a
checkbook register. Unfortunately, they only export the data in Quicken and Microsoft Money formats, neither of which include the balance data.
With a bit of Perl and some pedestrian Excel goodness, it all becomes a
beautiful graph. You'll have to wait for the report to actually see it of
course.
Monday, August 13, 2007
Annual Report: Life Events Timeline
Timeline widgets are great for seeing events
and how they relate to each other temporally. Synchronized graphs such as
those used in financial
charts and by Google
Trends further show temporal
relationships and even hint at cause-effect relationships between events.
I've thought of several graphs for the annual
report that would
have a chronological
X-axis and some
piece of data on the Y-axis. It would be interesting to put a timeline of
significant life events at the bottom of a page with all those graphs. The
X-axis would be synchronised across the graphs so that I could easily see how
the birth of a child affected my reserve savings or effective tax rate.
It should be easy enough to find data for the timeline from my own memory of life events such as getting married, children's birthdays, moving to a new house, starting a new job, etc.
Monday, July 30, 2007
Annual Report: Hours Worked Graph
In honor of the fun idea from Feltron Seven to publish personal annual
reports, I'm tentatively planning on creating my own report for 2007. I
don't want to spend much (if any) time collecting data, so this annual report
also serves as an experiment in locating data recorded about me and
aggregating it in a useful, queryable fashion.
This is the first post, in a five-month (crossing my fingers) series preparing
for my future report. The purpose is to help me flesh out ideas for content
and some techniques for creating it. As a convenient by product, these posts
will also serve as a handy scratch paper to remind me of good ideas when it
comes time to actually write the report. Each entry in this series will be
tagged with the label annual report, so they'll be easy to find later.
Now on to the first idea. Following on the heels of my recent post about
programmer context switching, and stealing Feltron's good ideas
with graphs of work and vacation, I want to include a graph showing the hours
I've worked. The graph will be a stacked, bar graph where the total bar height
indicates the number of hours I worked during each week of the year. There
will be pieces in each stack: context switching time and productive time. This
one graph should nicely highlight seasonal fluctuations in my workload and help
me see whether my efforts have reduced the overhead cost of context switching.
The data should be easy to find. I need to query my time clock database for
the total hours per week. The best bet would be to convert each data point
into RDF something like:
y2007:week_1 work:total_hours "38" .
y2007:week_2 work:total_hours "42" .
...
I'll get into my reasons for tentatively choosing RDF in another post, but
in this case, it might be easier to just generate the graph directly. Time
will tell.