August, 2009

Posts
  • Eric Gunnerson's Compendium

    Ratings from Eric's Vacation

    • 0 Comments

    I've decided to be totally derivative (and likely considerable less good) than "The Book of Ratings".  A great book.

    State highway signs

    California

    It's really a bit sad. They spend all that time putting up "enforced by radar" or "enforced by aircraft" signs, but deep down they know that nobody is going to pay any attention.

    To distract themselves, they amuse themselves by putting "80" at the end of all the freeway names around San Francisco.

    Rating: C

    Washington

    Boring signs, though the state highway signs do have a nice outline of George's head on them.

    Or perhaps I'm just jaded from my long association, and am desperately seeking my midlife crisis of signs.

    Rating: C

    Oregon

    Perhaps the Oregon highway department was beaten up by the other highway departments when it was little, but for whatever reason, Oregon likes to do things big, with an outsize "55" telling you that they really mean business, and colossal "do not enter" signs at least 10' on a side. Definitely signs with an attitude.

    On the minus side, they insist on putting up "end of speed zone" signs, forcing me to try to remember how fast I was allowed to go at some point in the past.

    Rating: B

    Vacation Vehicles

    Mom's Old Car

    Mom's old car - chosen so the offspring could drive in WA and OR - is a sweet nicely-preserved 1998 Honda Accord, returning a bit over 30 MPG for the trip.

    Rating: B-

    ATVs

    5 minutes of recorded safety lecture, and we're out in the largest sandbox on the west coast, 32000 acres of duney bliss. The last off-road experience I had was a 50cc Honda when I was 12, but I do remember the most important rules - a) You get it stuck, you dig it out, b) don't cross over the unmarked boundaries, and c) you break it, you pay us.

    Not really useful for getting from here to there, but a hecka lot of fun (as the kids would say).

    Rating: A

    Sand Rail

    First off, "Sand Rail" is a killer name, beating up on "Dune Buggy", and taking the lunch money of "ATV" ("Hey, I know! People love names that are acronyms").

    Four point racing harnesses, goggles, and a suggestion to keep our hands off the top rail "in case we roll", and the first pass is a 30 mph trip down a 45 degree slope and up another. Great fun once I pried my eyes open.

    Sand Dunes Frontier

    A++

    Aquatic Creatures

    Hippocampinae

    Sometimes confused with the hippocampus. Yeah, we get it, they're shaped like horses, and there are tiny fish who act as jockeys, riding them around the tanks is daily races.

    Sure, the dudes are the ones that give birth, guaranteed to make all the guys in the audience wince a bit.

    Rating: C

    Cephalopods

    The 007 of the water, with adaptive camo, water-jet propulsion, super grippers, and a built-in smoke screen.

    Rating: B

    Pinnipeds

    Cute and cuddly, intelligent, mischievous - everything you want in an aquatic animal. Except for the fact that they mostly swim under the water and when outside the water spend their time doing impressions of jumbo furry sausages.

    Rating: B+

    Missing mountains

    Mount St. Helens

    A bit less known as its larger and better-behaved brother to the north, St. Helens is widely held up as the epitome of a missing mountain.

    2/3 of a cubic mile of mountain disappeared in 30 seconds, killing 57 humans, 7,000 big game animals and 12 million hatchery salmon. It inconvenienced people throughout the state, causing millions of people to have to wash their cars ahead of schedule.

    The glowing growing dome is a nice touch if you can see it at night, but it could really use some daytime pizzazz.

    Rating: B

    Mazama

    First of all, erupting 3000 years before the advent of mass media is a bad career choice, and the PR is largely non-existent. You still see Jordan's name all over the place, so I think Mazama needs a new agent.

    But it's hard to fault it on execution. 25 cubic miles of mountain vanish. What do you put in it's place? A 2000' deep lake.

    Brilliant.

    Rating: A

  • Eric Gunnerson's Compendium

    Introduction to HealthVault Development #13: More more than one person

    • 1 Comments

    In the last installment, we modified our application so that it could switch between family members for data display and entry. This time, we’re going to add a table at the top that shows the current weight for all family members.

    We add the table right after the <h1> title:

    Family Summary <br />
    <asp:Table ID="c_tableSummary" runat="server" BorderWidth="1px" CellPadding="2" CellSpacing="2" GridLines="Both"/>
    <br />

    Then we need a method to walk through the records and fetch the current weight from each of them. The following will do that:

    void GenerateSummaryTable()
    {
        TableHeaderRow headerRow = new TableHeaderRow();
        TableHeaderCell headerCell = new TableHeaderCell();
        headerCell.Text = "Name";
        headerRow.Cells.Add(headerCell);

        headerCell = new TableHeaderCell();
        headerCell.Text = "Weight";
        headerRow.Cells.Add(headerCell);

        c_tableSummary.Rows.Add(headerRow);

        foreach (HealthRecordInfo record in PersonInfo.AuthorizedRecords.Values)
        {
            HealthRecordSearcher searcher = record.CreateSearcher();

            HealthRecordFilter filter = new HealthRecordFilter(Weight.TypeId);
            filter.MaxItemsReturned = 1;

            searcher.Filters.Add(filter);

            HealthRecordItemCollection weights = searcher.GetMatchingItems()[0];

            if (weights.Count == 1)
            {
                TableRow row = new TableRow();

                TableCell nameCell = new TableCell();
                nameCell.Text = record.Name;
                row.Cells.Add(nameCell);

                Weight weight = weights[0] as Weight;

                TableCell weightCell = new TableCell();
                weightCell.Text = weight.Value.DisplayValue.ToString();
                row.Cells.Add(weightCell);

                c_tableSummary.Rows.Add(row);
            }
        }

    Currently, there is no way to make a single request that fetches data for more than one record, so we need to create an execute a separate query for each one.

    Next Time

    With all the operations that we are performing, the application is running a little bit slowly. We’ll do some investigation into what’s going on, and see if we can’t make some improvements.
  • Eric Gunnerson's Compendium

    Thoughts on agile design and platforms

    • 3 Comments

    I started by writing a broad post about design, and it got away from me (apparently I should have spent some time designing the post first…), so I deleted it all and decided to write something shorter, and, with any luck, more understandable and useful.

    I’ve been reading some discussions about how design relates to Agile. Some teams get into trouble because they think that agile means “no design”, when in fact it means “right design”.

    The whole point of design in my mind is to save you work later on. There’s a sweet spot between no design and big design that makes sense in a particular situation. I don’t think that’s a unique insight at all, though I have seen groups how use the “design document” approach where there’s a document with 18 sections in it that everybody has to use.

    The two areas I would like to talk about are about what you are building and the scope of what you are doing right now. I’ll talk about scope first.

    The amount of design you should do depends on the scope of what you are doing, and scope in this situation doesn’t mean “amount of code change” (though it often correlates somewhat with that), it means “impact of code change on the customer”. This is obviously different for every change you make to the code, and my general guideline is that spending 5 minutes bouncing your thoughts off of somebody else generally gives you a good enough conclusion about how much design is required. Notice that I said “guideline” – I expect that developers can use their best judgement about when they can make changes without consulting with others.

    Some people would say that not having the opportunity to make a wrong choice about when to consult with others is a strength of pair programming. I think that’s probably true, but obviously only works for teams that do pair, and that’s not that common in my neck of the woods (and, I suspect in others).

    So, anyway, that’s what I think about scope, and, once again, I don’t think it’s a unique insight.

    My second point – that the amount of design depends on what you are building – is something I haven’t heard talked about much, especially in agile circles. Because most software developers deliver applications, the agile processes are described in that context.

    And in that context, I think that many developers do far too much design up front. You can spend 3 days writing something up that covers how you will do something, or you can spend 2 days doing early implementations and then know which one works better, and have real code to show people. Trying to figure out how things should work before you write them is often less efficient than just writing them when you need them.

    Given that I consider premature generalization to be the #1 sin of developers, no surprises there.

    But – and I think I may be finally getting to the point – that perspective comes from applications, where you own the code that you’re building, and refactorings can be done when you learn more.

    Platforms are different.

    If you are building a platform, things get a bit schizophrenic. Internally, you are an application – you can refactor the internals without a lot of impact elsewhere, and therefore the amount of design you do should keep that in mind.

    But externally, people depend on your APIs to stay the same. This means that, for a given feature, you need to get it right (or as close to right as you can) on your first release. It also means that you need to think about how the feature that you’re doing right now might be extended for things you might do in the future.

    Which is exactly the thing that you shouldn’t be doing if you’re building an app, because it’s a pain, it’s expensive, you’ll make the wrong choices, and you’ll have to throw work away.

    In my current team, we own both applications and platform API, so we get to spend time in both of these areas.

    And now it’s lunchtime. I may write a future post on how I think you should do platform design.

  • Eric Gunnerson's Compendium

    RAMROD 2009 ride report

    • 0 Comments
    http://riderx.info/blogs/riderx/archive/2009/08/06/ramrod-2009.aspx
Page 1 of 1 (4 items)