Constraints

This month I'm participating in Health Month and one of my rules was to restrict myself to 21 cups of coffee per week.  That probably doesn't sound terribly ambitious, but I love coffee and without limits I drink it like water.  Now, I'm not really convinced that there's substantial health benefit to drinking less coffee (in fact I've seen a few studies talk about the benefits of it... antioxidants or something), but I'm at least willing to consider the possibility that all that caffeine isn't the best for me so one cup in the morning, afternoon, and evening seemed like a reasonable limitation to try out.

It's been a difficult goal to follow and one effect is that I've been drinking more green tea (probably still craving that little bit of caffeine in green tea but I also like having a warm drink around when I work) which is according to some studies really good)  But the more interesting effect is the effect what coffee I do drink.  If I'm going to only drink three cups of coffee during the day they better be darn good cups.  I no longer have ANY tolerance for mediocre coffee.  In fact I've dumped out perfectly good cups of coffee because they weren't GREAT.  The coffee that I do drink I've been hand roasting Sweet Maria's green coffee and making it in a french press.  I savor every last drop and truly enjoy coffee.

The right kinds of scarcity lead to excellence (what coffee I drink) and gratitude (loving good coffee).

Server Migrations

Migrating server hosts is a pretty daunting task.  While the mechanics of it are pretty straightforward the details are killer.  You can spend days planning, migrating the static pieces, doing dry runs, etc. only to find out that you forgot about some critical piece.  I'm not a sysadmin so it's quite likely that the process can be made much easier with tools like puppet but even still it must take a lot of work to get the puppet config setup reliably.  The server I just moved had around a dozen virtual hosts running some combinations of Apache, PHP, Rails, and MySQL.  In addition, the server runs a few mailman lists so I had to get postfix and mailman running as well.  Throw in some ancillary stuff like memcached, subversion, setting up logrotation, enabling additional logs in syslog, setting up backup scripts (for snapshotting EBS volumes), etc. and it's increasingly difficult to finally pull the trigger.  So tonight, I lift a beer to you sysadmins.  Thanks for the magic.

Scale testing Jimmy John's

Jimmy John's is a sandwich chain with a shop in town.  They pride themselves on fast delivery which you are often reminded of with ads like "Subs so fast you'll freak" on local buses.  The fact is though that they deserve it, and honestly I don't know how they do it.  I order from them for lunch at work a few times per month and they ALWAYS deliver within 15 minutes.  That's a pretty remarkable feat given that they're a 10 minute drive away if they don't hit lights, etc.  So basically, they receive the order, process it and get it out the door in 5 minutes reliably.  Plus it's a retail business so they're often dealing with customers in the shop too.  Oh, and by the way I customize my sandwich so it's not just that they pre-make the subs.

Today's lunch arrived in about 13 minutes so I started wondering how many sandwich makers they hire and how many drivers they have when I had a devious thought....  In software we will do scale testing of new services (what kind of request traffic can your service handle).  I want to scale test Jimmy John's.  Get a bunch of friends together distributed around the town and place an order simultaneously and watch what happens to the delivery speed.  Are they strategic about delivering orders?  Do they have back-up drivers they can call on in a pinch?  Are they able to drop all things and have the sandwich makes do deliveries?  They've either got some tricks up their sleeve or they've become pretty masterful at managing demand.

The danger of sedentary entertainment

A stunning piece of research

During the study’s follow-up period, from 2003 to 2007, 325 men died of various causes, and 215 suffered a heart attack or other cardiac event. Even after adjusting for differences in weight, smoking, occupational physical activity and risk factors like diabetes, high blood pressure and other longstanding illnesses, as well as marital status and social class, those who spent four hours or more of their leisure time in front of a screen each day were 50 percent more likely to have died. Those who spent two hours a day in front of a screen for entertainment were 2.2 times more likely to have had a cardiovascular event.

and remarkably in a similar study linked above:

[...] light activities adults filled their time with, like reading and playing board games, actually burned more calories than watching TV.

So turn off the TV, and stand at your desk to work...  You'll burn more calories and live longer and you don't have to do anything else differently.  Amazing.

Arduino Light and Temperature Logger

Hardware mostly been magic to me.  Except for the broad system categories of how it works I'm pretty ignorant.  It's kinda like the power coming out of the "holes".  I write software and something wonderful happens in the complicated looking green circuit boards inside.  And yet I've often had hardware ideas that I've always dismissed as "I have *no* idea how someone might build that."  For example a device controlled by SMS (e.g. an electronic lock so that you could let your friend into your house from work simply by texting a code to your doorknob).

So it is with some delight that I found Arduino.  It's an open source hardware prototyping platform with a simple language (similar to C) and slick IDE to compile and upload code to micro-crontroller.  One of the elegant things about how the Arduino is build is that you can stack "shields" on top of the board that add functionality.  There are several places online where you can buy shields such as Adafruit.

For Christmas I got several shields, one of which was a light and temperature logger.  The base of the shield was an interface to an SD card.  On top of that you added a light sensor and a temperature sensor.  After soldering it all together (I've come to love soldering) you upload the code attach a battery pack and then start collecting data.

Data is written out into a CSV file on the SD card that looks something like this:

millis,light,temp,vcc
1998,613,68.46,1.84
3000,628,68.46,1.79
3999,669,68.46,1.68
4999,671,68.46,1.68
5999,628,68.46,1.8
7000,385,68.46,2.99
7999,628,68.46,1.79

I left my device outside over night on a particularly cold night and generated a bunch of data.  So much so that I ran into the nasty limit that Excel doesn't deal with more than 32,000 data points.  So I whipped out Octave to look at the data.  I just wanted the light and temperature data, so after grabbing only those columns I whipped up the following Octave code:

d = csvread('cabin.csv')
statistics(d)
figure(1)
plot(d(42000:55000,1))
legend('Light', "location", 'southeast')
print('light.png', '-dpng')
figure(2)
plot(d(42000:55000,2))
legend('Temperature (F)', "location", 'southeast')
print('temperature.png', '-dpng')

It was a little painful to get Octave working on my mac with AquaTerm and all of the octave-forge contributed code building from MacPorts (there is a binary distribution, but I was determined to win and the key thing I ended up learning is that Octave wants/needs AquaTerm... not just any old X11 server)

The statistics line from above generated some basic summary statistics.

octave:2> statistics(d)
ans =

    39.0000    17.9900
    48.0000    18.5700
    48.0000    19.7300
    61.0000    22.0500
   948.0000    68.4600
   188.2125    21.4046
   307.3645     4.9441
     1.8685     3.6643
     1.5966    21.1867

From that data we can see cool stuff like the high temperature was 68.46 (inside the house before I too the device outside), the low temperature was 17.99, the average was 21.4 with a standard deviation of 4.94.  The numbers for light are a little more abstract to me because I didn't look up the units on the photo sensor was measure. (NOTE in octave do "help statistics" to figure out what the other values mean).

The plot commands were used to generate a plot of the data for a slice of time that seemed interesting to me:

What you see here is the temperature rising from the low back up to the mid-twenties as day broke.  An interesting thing to observe is the tiny oscillation of the data.  I doubt the temperature was actually changing like that, but rather the degree of sensitivity of the sensor was such that it sometimes was one value and other times was another.

Finally here's the light plot.

From here you can see daybreak happen until you hit the maximum reading from the light sensor.

Overall I've been loving the Arduino and projects like this are just plain awesome.  You get to build stuff that actually interacts with the world.

The Decemberists: The King is Dead

By now you probably can't escape talk about The Decemberist's new album The King Is Dead, but to my way of thinking all of the talk is merited.  I've been listening to them since Picaresque and they're probably my favorite band since REM.  Colin Meloy's heady (and often dark) lyrics and unique voice combined with a catchy melodies is a winning combination.  Their previous work, The Hazards of Love, a concept rock opera piece, was quite a bit different than the album before, The Crane Wife, which was a folk rocky album thematically based around the eponymous Japanese folk tale.

The King is Dead returns to a form that is closer to The Crane Wife.  Closer both lyrically and stylistically.  The music is upbeat folk/roots style.  They've found some strong support in other artists as well.  Peter Buck plays his unmistakable style of guitar on "Calamity Song" and Gillian Welch sings a subtle backing vocals on most tracks.

NPR has a nice review of the album and until January 18th you can stream the whole thing.  Do yourself a favor and give it a listen.

The Grass is Always Greener

I hate the phrase "the grass is always greener on the other side".  It purports to be about the grass on the other side, but it's not.  It's about the grass on this side is often used to make soul squashing statements.

• The pessimist: You'll never be really happy so stop trying.
• The "benevolent" dictator: You have everything you could want here.  You're just going to be unhappy on that side.  In fact on that side it's probably worse.
• The cult leader: Their grass isn't really grass.  It's poison.  Eat our grass.

The phrase is never (rarely?) used to inspire joy/peace/etc.  It should be used in a "both and" way.  That is you should BOTH appreciate the grass you have with all of your heart AND constantly seek better grass.

I also don't like that the phrase isn't axiomatic.  That is, it's not applicable equally to all things (further proof that it's being used as a tool of the dictator or cult leader, etc.).  For example a manager might say to a disgruntled employee "competitor X has problems too...  you won't be happy their either... you need to find a way to find job satisfaction here...." ("the grass is always greener").  That SAME manager is NOT going to make a similar statement about their product; "customers will never really be happy and our current offering does enough so why look for a better solution?"  So basically the person saying that "the grass is always greener..." will say it when it serves them (to retain an employee, etc.) but won't say it when it doesn't (i.e. when it stifles innovation).