My daughter found some broadcasts of a show named "Ninja Warrior" (originally named Sasuke in its Japanese broadcast), which is currently running on G4TV. It's an elaborate obstacle course show, with an English voiceover on top of the Japanese commentary.
Not only do you get to see some really talented athletes, you also get to see ordinary people crash and burn on the first stage, falling into the muddy water.
A topic came up yesterday in the forums, and I thought it was of general interest.
HealthVault is different from a lot of information systems - at least the ones I've worked with - in that there is a break between the concept of "user" - the person who authenticates into the application - and "record" - the thing that holds information about specific individual.
This is to support two scenarios.
The first one is for parents, who want to track the health information of their children. They can create a separate record (that they have access to) for the child.
The second one is when an adult is managing the health of another adult - that adult can be granted access to another adult's record.
If you are writing an application, this is something that you need to deal with. If I'm using an application and then I come back to it after I've gotten access to another record, I need to provide the following:
For an example of how to do this, take a look at the HealthAndFitness application.
The existence of multiple records explains why you need to use PersonInfo.SelectedRecord to access the data - it belongs to the current record, not to the current user.
That's the overview. The specific point that came up yesterday was around the ids for users and records. An application can access PersonInfo.PersonId and SelectedRecord.Id, and use those to uniquely identify that user and record.
But, to make it harder to correlate information between applications, the same person using two separate applications is going to have two different values of PersonInfo.PersonId and SelectedRecord.Id, and, in fact, the record ID will change if the application is de-authorized and then re-authorized.
So, you may need to keep this in mind if you are doing anything with those IDs...
I'm back at work today, after spending a record (for me) 23 days away from the office. The last time I spent that much time off was one of those involuntary vacations that happens sometimes ("the investors decided that they aren't going to fund us any more").
Of that time, I spent a few days shopping, the week of Christmas in San Diego (beach/zoo/wild animal park/sea world/lego land/aquarium/balboa park), and then a few days skiing. Going from 65 and sunny to 20 and snowing was a bit hard, but we all have our crosses to bear.
We also bought a wii, which has been a fair bit of fun. I got mine through the services of wiialerts.com, which will send you both an email and a text message on your phone when stock shows up at one of the online retailers. You may be saying, "great, why didn't he tell me that before the holidays?", but I couldn't because a) my massive number of readers might have overloaded the site and b) my wife reads this blog, and she didn't know about the Wii (a risky move, but I got away with it). Probably more of "b" than "a". Anyway, a great site, and I'm sure I would not have gotten my Wii without it.
Back at work, my group has moved to building 113, which is one of the old MS research buildings. It's pretty nice, though it isn't as nice as the brand new research building, which is both very pretty and has lots of innovative spaces (team rooms, working lounges, etc.) Plus, instead of glass doors between the lobby and the 4-story atrium in the middle of the building (I said it was pretty, right), it has some high-tech turnstiles that are operated with your badge.
As some guessed, a snowblower.
More specifically, an Ariens 824E snowblower, from SnowblowersDirect.com.
Some of you know that I ski in the winter, and keep a ski cabin to make ski mornings much nicer. The ski cabin is at about 1000', and traditionally, there really isn't that much snow at that elevation around here - it tends to snow a bit, and then warm up.
But - as we've found over the last few years - if you have a house that sits on the north side of a hill, you don't get any solar radiation at all, and any snow that you do get is amazingly resilient - it will stick around for months. Though I can usually push the outback into our driveway with the new snow, it doesn't really work on deep slop, unless you're fond of severe drivetrain abuse and the smell of burning clutch(es).
So, we park at a small spot on the road to our lot. If it's snowed, I have to either move the plowed snow to the side before we park, or just muscle over it. And I need to cut a path through the snow to the cabin so we don't slip and fall over.
We've had this tentative plan to get an ATV and put a small plow on it, but I pretty much just lazed on that one. And then it started snowing, and snowing, and snowing around here, and I started thinking in terms of snowpack. We've probably had a good 4-5 feet of snow fall, and the snowpack is around 24-30" right now (it was a bit higher a week or so ago). I'm tired of digging.
Hence the snowblower. I couldn't find any stock here or close on the east side of cascades, so I ended up buying online, which was surprisingly easy. The blower showed up on Friday, we took it up Saturday, and found that it's a nice machine. And, amazingly, it started on the first pull in 20 degree weather, which shows that small engines have improved a bit since the lawn-mowing days of my youth.
It made quick work of the top 8" of snow, which was still sort of powderly. I had little luck at all with what was underneath, but given the fact that the blower doesn't sink into the snowpack, I'm not surprised. It would have been fine if I could have attacked it incrementally, and I'm hopeful that when it warms up a bit, the pack will soften and I'll be able to get back into the driveway.
Or, I could try to borrow one of these...
When I first started using the HealthVault SDK, I wrote some code like this, based on what I had seen before:
HealthRecordSearcher searcher = PersonInfo.SelectedRecord.CreateSearcher();HealthRecordFilter filter = new HealthRecordFilter(Height.TypeID);searcher.Filters.Add(filter);
HealthRecordItemCollection items = searcher.GetMatchingItems();
So, what's up with indexing into the result from GetMatchingItems()? Why isn't it simpler?
The answer is that queries can be batched up into a single filter, so that you can execute them all at once. So, if we want to, we can write the following:
ReadOnlyCollection<HealthRecordItemCollection> results = searcher.GetMatchingItems();
HealthRecordItemCollection heightItems = results;HealthRecordItemCollection weightItems = results;
Based on a partner question today, I got a bit interested in what the performance advantages were of batching queries up. So, I wrote a short test application that compared fetching 32 single Height values either serially or batched together.
Here's what I saw:
This is a pretty impressive result - if you need to fetch 4 different items, it's nearly 4 times faster to batch up the fetch compared to doing them independently. Why is this so big?
Well, to do a fetch, the following thing has to happen:
When a filter returns small amounts of data, steps 1, 3, and 5 are pretty fast, but steps 2 and 4 involve network latency, which dominates the elapsed time. So, the batching eliminates those chunks of time, and we get a nice speedup.
We would therefore expect that as we fetch more data in each request, batching would be less useful. Here is some data for fetching 16 items:
Which is pretty much what you would expect.