Commute time code has moved to github

Since Google Code is going away my commute time code has been moved to github :

https://github.com/chrisxkeith/commute-time-aggregator

Note that I still haven't gotten it to work with the "new" version of Google Maps. If I ever retire...

Dryer Dreams, part 2: making the split extension cord

Getting the prototype to work with the kettle seemed straightforward. I was, however, concerned that the dryer would draw more current (and perhaps damage the split extension cord).

Searching for something that I now have forgotten took me to this link.

I ended up wiring a "split power cable". The colors represent the electric current (I wish I knew more about electricity terminology)? Red == hot, Black == ground, White == "not hot (?)"

Dryer Dreams, part 1: Overview

Some people dream about world domination, or the perfect margarita. I dream that my clothes dryer will tell me when its cycle is done, so I can pull my clothes out before they get wrinkled. I'm a software guy, rather ignorant on the hardware side. So I thought I'd start experimenting and learning.

I first tried putting a Quirky Spotter on the dryer to detect the sound of the buzzer. However, the sound of anyone closing the door of the room containing the dryer would set it off.

I then tried an Insteon Syncholink, but was unable to get the Android app to work. I'm guessing the lath-and-plaster walls (or something) in our old house blocked the wireless signal to my phone.

I then found this project in Make Magazine that seemed to fill the bill. Wiring diagrams are, however, Greek to me. I therefore took a weekend workshop in Ardunio programming. Luckily, I connected with one of the instructors, Michael C. Toren, who happened to be working on a similar project.

I was not looking forward to digging into the guts of my dryer as described in the Make Magazine article. Michael, however, had made (what I called) a "split extension cord" (picture to come) that worked well with our first minimal prototype. Not having a dryer handy, we used an electric kettle. The code for that prototype is here.

In future posts, I'll record (in pedantic, OCD, anal-retentive detail) the various steps I went through to get this working.

Heart-felt thanks to MCT, as well as Rolf Widenfeld, J.D.Zamfirescu, Malcolm Knapp, Lee Sonko and the rest of the team for their help.

More commute data

After changing jobs, I revived my commute time data collector for my new commute. The end-result is much the same, e.g., Google Maps underestimates the commute time by an average of 20%. The range of underestimation (from the average time) was from 4% to 48%.

I programatically collected Google Maps estimates for a few days and averaged them, while manually collecting my actual commute times. The morning commute looks like this:

The evening commute, like this (don't ask me why Google spreadsheets chose a different display format):

The underlying data is here.

Healthcare.gov : really 500 million lines of code?

There have been a number of articles quoting the 500 million LOC (Lines Of Code) that were created for the healthcare.gov web site (e.g., in Slate).

Without getting into the debate about how reliable LOC are as a way of measuring complexity, here's a back-of-the-envelope calculation, including my assumptions.

500,000,000 LOC

Assume 50 LOC of debugged and tested code per day per developer:

10,000,000 "developer-days"

Assume 250 workdays per year:

20,000 "developer-years"

Assume 2 years of development:

10,000 developers

That number seems high to me, even if we include Quality Engineering, Documentation and Management. Or maybe I just don't understand.

Or maybe the 500 million number is really meaningless.

The Shape of My Commute : Wrapup

I've stopped accumulating data about my commute (for a while, anyway). Here's the summary of what I did and what I learned.

I first wrote a program using Selenium to extract estimated trip times from Google Maps. I doubt this will work with their new end-user interface, but I got the data that I was interested in. I accumulated the estimated trip times from 4 a.m. to 8 p.m. over the course of a few days. This graph shows the average: 
I added a line for my "tolerance". My hope was to stay under 45 minutes each way. One minor interesting point: the estimated trip time is not symmetrical. You can see the "bump" at noon, when I switched the commute direction.

I then manually collected estimated times and actual times:
I also put my "tolerance line" at 45 minutes. Here the reality sinks in. Google Maps underestimates the commute time (during commute hours) by 5% - 25%. I've read a number of posts that complain that Maps overestimates trip time, but those seem to apply mostly to longer, non-rush-hour trips.

Don't name your Samsung Galaxy S4 with a long name with spaces...

... if you want to be able to see the device from Windows.

I had originally named it "xxxxxxxxxxx yyyyy zzzz", and couldn't see it from either Windows 7 or Windows XP.

Renamed it to "xxxxxx" and it's visible.

I'm guessing this has something to do with MTP, but can't really say for sure.

And I thought the days of 8.3 filenames were long gone.

P.S.: Still doesn't work reliably. I just switch back and forth between MTP and PTP until my desktop computer recognizes the phone.

P.P.S.: Now I think it's a security issue. Seems to work reliably if I connect, then unlock the phone with my PIN.