Thursday, November 7, 2013

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.

Wednesday, July 31, 2013

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.

Saturday, July 6, 2013

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.


Friday, June 28, 2013

"Collected" vs "complete"

In my quest to reduce my dependency on printed books, I ordered a Kindle copy of "The Collected Poems of W. B. Yeats". I was "leafing" through it, re-reading my favorites, when I noticed that "Why Should Not Old Men Be Mad" was missing.

Looks like I'll be keeping my dog-eared paper copy of "Selected Poems and Two Plays of William Butler Yeats" (1962).

Google Tasks missing on my Samsung Galaxy S4

Got an S4 a couple of weeks ago as part of the renewal cycle with Working Assets for my cell phone.

I do like the phone (after turning off all the gesture stuff). However, I can't see my tasks (created in Google Calendar using the Chrome browser) on the phone. I've made sure that the calender on the phone is set to my calendar. I even tried adding a due date to the tasks (in the browser on my PC), to no avail.

Has Google gotten so big that they are unable to integrate this? Or is this the evidence of some internal marketing tug-of-war between Samsung and Google, where Samsung is trying to force users to their applications instead of the standard Google local applications / web applications?

Anyone from Google (or Samsung) care to help?

Wednesday, June 12, 2013

Google Maps: erratic "In Current Traffic"


Where'd it go?


It shows on my Android phone.

Friday, May 24, 2013

The Shape of My Commute, part 5



A simpler chart. This is only directly observed estimates (red line) vs. actual times (blue line). The point at noon is "fake" so that the shape of the commute is easier to see.

I still feel like the accumulated, averaged estimates from Google maps are too low, but that may just be the effect of the bad days having more psychological impact. This chart below shows directly observed estimates (red line) vs. accumulated, averaged estimates (blue line). I presume that, after some number of direct observations, the red line could be smoothed to something that would closely match the blue line, but I don't know enough about statistics to figure out what that number of observations would be.


Or maybe the commute is really getting worse.

Here, also, is a link to the Google spreadsheet with the data.

Monday, May 6, 2013

The Shape of My Commute, part 4


More actual data. More questions.

The Average Estimate numbers from Google Maps for the morning look slightly optimistic (5% - 10% low).

The evening numbers are much farther off, more like 25% low.

Don't know if I'll ever know why. I can, however, come up with a "realism factor" that I can apply to the Google Maps numbers to get something closer to my Actual observed numbers.

Wednesday, April 24, 2013

The Shape of My Commute, part 3


Starting collecting actual data. After three data points it's not looking good for the estimated times, but confirming my gut feel that the estimated times are too low. I added an "actuals" column of data (shown in red). The spikes show the data points I've collected.

Still, from the estimates I can get the overall shape (e.g., commute times at each slot relative to each other), even if the absolute values are wrong. Overlaying the actual data will then give me the picture I need.

I'm guessing that we will see a wider variation between estimated and actual close to the peak times. We'll see if that guess proves out as I collect more actuals.

Tuesday, April 23, 2013

What's The Next Big Thing?

www.google.com

http://blogs.denverpost.com/techknowbytes/2013/03/12/whats-the-next-big-thing-in-technology-lets-ask-sxsw-interactive-2013-attendees/9076/

 www.yahoo.com

 http://graphicsweb.wsj.com/documents/NEXT_BIG_THING/NEXT_BIG_THING.html

 www.bing.com

 http://www.pbs.org/wgbh/nova/tech/what-is-the-next-big-thing.html

www.wolframalpha.com

http://www.wolframalpha.com/input/?i=Next+Big+Thing+the+album&lk=1&a=ClashPrefs_*MusicAlbum.NextBigThing%3A%3A1ec1d438!-4621!-3769!-8ab4!-2d5590fbd44a-

Sunday, April 21, 2013

The Shape of My Commute, part 2

After collecting data for a couple of weeks, and throwing out the worst of the bad data days (why does Selenium in Firefox crash out so often? to be determined...), I now have this:


The blue line is my commute tolerance (currently at 40 minutes).

The actual numbers (e.g., Google Maps estimates) feel low. I realize that time spent sitting in traffic seems longer than it actually is, but I would have guessed +5 minutes at peak times.

In the past I've tried to keep track of my actual commute times, but lost patience after taking a few samples. Maybe it's now time to revive that practice and do some "reality vs. Google maps estimates" validation.


Part 1

Sunday, April 7, 2013

The Shape of My Commute



I've been commuting from the east bay to the peninsula for many years, to many different locations. I realized that I've never had any reliable data about the best and worst times to leave home or work.

I decided to use the estimated times that Google Maps provides to try to get a clearer picture. I first wrote code to use the Google Distance Matrix API to get estimated driving times. I got that working, but got a nice (but useless) flat line when graphing estimated commute duration by departure time. I now assume that the API provides the first number shown on the web page, not the second:

I then re-wrote my code to use Selenium to grab the data off the web page. Those numbers made more sense. I don't have many days of data yet. I'm assuming that, as I get more data and average it in, the bumps in my graph will smooth out a bit.

If you want to do this, my code is available from Github. You will need to download a few Java jar files to get it to run.

Sunday, February 10, 2013

Kindle stand using GorillaPod and Koala Mount

Ingredients:
Even though my Kindle Fire is only 14.6 ounces (0.4 kilograms) I bought the GorillaPod Focus which can handle up to 5 kg.

Steps:
  • Hang one of the Koala Mount units on the GorillaPod to determine the "center point".
  • Mark that center point. I just scratched the Koala unit.
  • Measure the Kindle to find the center point of the Kindle.
  • Attach the mount to the Kindle. 45 degrees worked well for me.
Sit up in bed, sit the unit on yourself, arrange the GorillaPod legs as necessary, plug in your earbuds and watch your stuff.

Saturday, February 9, 2013

Copying files directly vs. through the router


I have this much in my music library on one machine:


Started a copy, let it run for a couple of minutes. It reported this:


I then set up a direct connection. I had bought a cross-over cable but didn't need it. Started the copy again, let it run for a couple of minutes. Got this:


Well, it was an experiment.

Sunday, January 27, 2013

Hands-free tablet holder, first prototype

One of my current projects is to build a hands-free tablet holder that so I can watch Netflix videos in bed on my Kindle Fire. My first attempt is here.

Using cardboard made it easy to quickly prototype this "head cave", and easy to recycle it (once it had served its purpose). I cut the square notches on the sides of the "Kindle hole" for the ear-bud cable.

This placed the Kindle close enough to my face that I could remove my glasses. I have bad eyesight. If I want to really look at something carefully, I always take off my glasses and hold the item within a few inches of my face. I don't know if there is something optically (as opposed to psychologically) different about looking at things this way. I do, however, feel like I really see what I'm looking at when I do this.

I watched a few hour and two-hour videos this way, but have consigned the box to the recycling bin. My eyes do not have the same prescription, so one eye has to dominate when focusing this closely. This leads to occasional strange effects when (I believe) the dominance switches from one eye to the other.

I'm now working on something using a Joby GorillaPod Focus that rests on my chest whilst in bed, so I can wear my glasses while watching.

Friday, January 11, 2013

Erratum (part 4) for D. S. Malik's "Data Structures Using C++"

Page 478 shows the "ADT" for a queue. I tend to read the code and skim the comments, given that I've been fooled more than once by out-of-date comments. I was therefore confused by the "addQueue" method. My first take was that it did what it said, e.g., added a queue to the existing queue. Going back through the comments, however, I found that it really was an "enQueue" operation.

When I looked up the STL syntax, I found that it uses push/pop (which I associate with stacks, not queues). In any case, it just seems confusing to use the name "addQueue" for this functionality.

See also other errata.


Are there any human proofreaders left?

"Watership Down" by Richard Adams, Scribner trade paperback edition 2005, page 14:

I daresay a good many rabbits would have kept quite and thought about keeping on the right side of the Chief...
Oh God, not Google Calendar spam!