The Coming Collapse of the Middle Class

SeanK — Thursday, April 17th, 2008 @ 3:29 pm
Filed under: Family

I know 3 couples in the midst of divorces. Hmm… More food for thought.


The Ant and The Grasshopper

SeanK — Saturday, April 5th, 2008 @ 11:39 am
Filed under: General

Old Version

The ant works hard in the withering heat all summer long, building his house and laying up supplies for the winter. The grasshopper thinks the ant is a fool and laughs and dances and plays the summer away. Come winter, the ant is warm and well fed. The grasshopper has no food or shelter, so he dies out in the cold.

Moral of the Story

Be responsible for yourself!

New Version

The ant works hard in the withering heat all summer long, building his house and laying up supplies for the winter. The grasshopper thinks the ant is a fool and laughs and dances and plays the summer away. Come winter, the shivering grasshopper calls a press conference and demands to know why the ant should be allowed to be warm and well fed while others are cold and starving. All the networks show up to provide pictures of the shivering grasshopper next to a video of the ant in his comfortable home with a table filled with food. America is stunned by the sharp contrast.

How can this be, that in a country of such wealth, this poor grasshopper is allowed to suffer so?

Kermit the Frog appears on a talk show with the grasshopper, and everybody cries when they sing, “It’s Not Easy Being Green.”

A political activist stages a demonstration in front of the ant’s house where the news stations film the group singing, “We shall overcome.” He then has the group kneel down to pray to God for the grasshopper’s sake.

Politicians exclaim in an interview on a different talk show that the ant has gotten rich off the back of the grasshopper, and both call for an immediate tax hike on the ant to make him pay his fair share.

Finally, the EEOC drafts the Economic Equity and Anti-Grasshopper Act retroactive to the beginning of the summer. The ant is fined for failing to hire a proportionate number of green bugs and, having nothing left to pay his retroactive taxes, his home is confiscated by the government.

A senator gets their old law firm to represent the grasshopper in a defamation suit against the ant, and the case is tried before a panel of federal judges that the President appointed from a list of single-parent welfare recipients.

The ant loses the case.

The story ends as we see the grasshopper finishing up the last bits of the ant’s food while the government house he is in, which just happens to be the ant’s old house, crumbles around him because he doesn’t maintain it.

The ant has disappeared in the snow. The grasshopper is found dead in a drug related incident and the house, now abandoned, is taken over by a gang of spiders who terrorize the once peaceful neighborhood.

Moral of the Story

Be careful how you vote.


Open Source CD/DVD burning application.

SeanK — Saturday, April 5th, 2008 @ 11:23 am
Filed under: Software

Because of a weird twist of fate, my new computer did not come with any software to burn CDs or DVDs even though it has a burner. Last night, at 12:30am, I really needed to burn a CD before going to bed. I tried Microsoft’s built in CD burner, but it failed. Actually it never started. I couldn’t seem to convince it that I had actually inserted a blank CD. So I hit the internet trail and came across an outstanding open source CD/DVD burnning application called InfraRecorder. In the span of 15 mintues this application has earned a place in my short list of must install applications for Windows PCs.


Hope Lodge

SeanK — Monday, March 31st, 2008 @ 3:17 pm
Filed under: Family

Each year our family looks forward to going to Hope Lodge up on Steven’s Pass to spend a weekend with 5-6 families composed of several dozen children. This year one of older boys brough his camcorder and put together this video. Aside from a hike on the Iron Goat trail (I didn’t check this website until after got home) What you see in the video is pretty much all we did all day long.


Calling all wordsmiths

SeanK — Thursday, February 28th, 2008 @ 2:08 pm
Filed under: Interesting , Homeschool , Family

I came across a fun word game on the internet today.

Rules:

  • Take a word and remove the first letter.
  • Now make up a definition for your new word.

Examples:

FAMISHED
Hungering for a simpler way of life.
SHAMPOO
Soap for washing a pig.
SHAREHOLDER
Investor in a company that makes magician’s hats.
CHIPMUNK
Squirrel that digs jazz.
DIARRHEA
Running on about oneself.
PICKPOCKET
A place to put used Kleenex.
FRISKIES
Cat food made in China.
SUNRISE
Going back to bed in the morning.
FRANTIC
Desperately raving.
SOFTWARE
A program you use a lot.
TABLEWARE
Crockery that really does the job.
BLACKLIST
All the stuff you don’t have.

Food For Thought

SeanK — Friday, February 22nd, 2008 @ 4:27 pm
Filed under: Interesting , Homeschool

A friend mentioned this video playlist on YouTube. I have been pondering the ramifications ever since. As the author states, I never learned about this in school either. It certainly is a lot to think about.


Ron Paul for President

SeanK — Saturday, February 2nd, 2008 @ 2:44 pm
Filed under: General


Hope for the future

SeanK — Friday, January 18th, 2008 @ 1:26 pm
Filed under: Homeschool

This morning, Micah was holding Miriam while doing his reading assignment. Later he was asked in his English assignment to write a descriptiive paragraph and here is what he wrote.

A young child makes time go backwards. When you hold her, warmth bursts into your body. She is a rainbow, and her eyes are always watching. She removes your frowns and gives smiles to the world.


Miriam Marguerite Kelly

SeanK — Wednesday, December 19th, 2007 @ 2:20 am
Filed under: Photos , Family

12-15-07_0610.jpg
Saturday morning at a timely 5:59am, we welcomed our newest daughter. She showed up 3 weeks early weighing 6 pounds 12 ounces and was 18 inches long. This has probably been the most difficult pregnancy that Lisa has had and so this conclusion has been a bittersweet blessing.
dsc00099.JPG


Coding Style

SeanK — Tuesday, December 4th, 2007 @ 7:49 pm
Filed under: Programming

Coding Styles can be an almost religious issue among programmers and so I begin this post with a little trepidation but as I have been asked to document my particular coding style for my former team before I move on to a new team next week, I thought it would be best to do it as a post to my blog. In the over 20 years that I have been programming my style has only changed a few times. The first programming language I was ever formally taught was PASCAL so the issue of where to put curly braces has always been settled in my mind and I won’t be discussing that here. What I do want to discuss is code flow. All through high school, college and my first several jobs in the computing industry I used a code flow like the following sample.


HRESULT DoBazThroughFooAndBar()
{
    IFooThings* pFooThings = NULL;
    HRESULT hr = GetFooThings(&pFooThings);
    if (SUCCEEDED(hr))
    {
        IBarThings* pBarThings = NULL;
        hr = pFooThings->GetBarThings(&pBarThings);
        if (SUCCEEDED(hr))
        {
            IBazThings* pBazThings = NULL;
            hr = pBarThings->GetBazThings(&pBazThings);
            if (SUCCEEDED(hr))
            {
                hr = pBazThings->DoSomethingProfound();
                pBazThings->Release();
            }
            pBarThings->Release():
        }
        pBarThings->Release();
    }
    return hr;
}
 

This type of code flow should be very familiar to every developer out there. The only disadvantage to using this type of style is that complex functions will typically nest to absurd levels and that can make the code very difficult to read. The first change to my coding style happened when I joined Microsoft back in 1994. I came to work on the MFC team. Unlike most development teams at the time, MFC had the distinction of shipping not only binaries, but the source as well. Consequently, the team a developed very rigorous style guidelines well before I arrived. These guidelines abhorred the kind of nesting demonstrated above and instead opted for a code flow like the following sample.


HRESULT DoBazThroughFooAndBar()
{
    CComPtr<IFooThings> pFooThings;
    HRESULT hr = GetFooThings(&pFooThings);
    if (FAILED(hr))
        return hr;

    CComPtr<IBarThings> pBarThings;
    hr = pFooThings->GetBarThings(&pBarThings);
    if (FAILED(hr))
        return hr;

    CComPtr<IBazThings> pBazThings;
    hr = pBarThings->GetBazThings(&pBazThings);
    if (FAILED(hr))
        return hr;

    hr = pBazThings->DoSomethingProfound();
    return hr;
}
 

The thinking here was that since MFC was a class library we can assume that the programmer is using C++. So any type that needs to be cleaned up after being used should be wrapped in a class so it’s destructor can do the cleanup. This made the code much more readable. However, it had a few disadvantages. First, you often needed to implement one off classes to wrap types that needed to be cleaned up or alternately spend time looking for pre-existing wrappers for HANDLEs, HWNDs, HBITMAPs, not to mention memory that needed to be freed using delete, free, HeapFree or CoTaskMemFree. Because this isn’t always practical you would often end up with one or two types that were not wrapped and needed to be cleaned up inside of each FAILED case. This became a problem when code analysis tools hit the scene. Around 2002, it became vogue at Microsoft for the test team to measure the success of their automated tests by using code coverage tools to analyzed the percentage of code that was exercised. I remember one tester being particularly frustrated with me because he couldn’t get better than 40% of my covered because of all the error handling code to handle errors that almost never happened. The other disadvantage came when you needed to debug your application or instrument it with tracing since it was virtually guaranteed that you would have way more than one exit point within the function. So if you had a macro for tracing that needed to be placed at the beginning of every function and another one at the end, you would need to invoke that macro at every return. Consequently, this style was not popular outside of MFC. Instead most teams opted for a code flow like the following sample.


HRESULT DoBazThroughFooAndBar()
{
    IFooThings* pFooThings = NULL;
    HRESULT hr = GetFooThings(&pFooThings);
    if (FAILED(hr))
        goto Cleanup;

    IBarThings* pBarThings = NULL;
    hr = pFooThings->GetBarThings(&pBarThings);
    if (FAILED(hr))
        goto Cleanup;

    IBazThings* pBazThings = NULL;
    hr = pBarThings->GetBazThings(&pBazThings);
    if (FAILED(hr))
        goto Cleanup;

    hr = pBazThings->DoSomethingProfound();

Cleanup:
    if (pBazThings != NULL)
        pBazThings->Release();

    if (pBarThings != NULL)
        pBarThings->Release():

    if (pBarThings != NULL)
        pBarThings->Release();

    return hr;
}
 

Those who practice the art of programming and can trace their methodological lineage back to the school of the great Edsger W. Dijkstra) will immediately chaff at the thought of using gotos in their code. Consequently, many have sought other code flows that solve the same problems without the gotos. One in particular looks like the following sample.


HRESULT DoBazThroughFooAndBar()
{
    IFooThings* pFooThings = NULL;
    IBarThings* pBarThings = NULL;
    IBazThings* pBazThings = NULL;
    HRESULT hr = S_OK;
    do
    {
        hr = GetFooThings(&pFooThings);
        if (FAILED(hr))
            break;

        hr = pFooThings->GetBarThings(&pBarThings);
        if (FAILED(hr))
            break;

        hr = pBarThings->GetBazThings(&pBazThings);
        if (FAILED(hr))
            break;

        hr = pBazThings->DoSomethingProfound();
    }
    while(false);

    if (pBazThings != NULL)
        pBazThings->Release();

    if (pBarThings != NULL)
        pBarThings->Release():

    if (pBarThings != NULL)
        pBarThings->Release();

    return hr;
}
 

While it very cleverly coaxes a goto out of a loop, I dislike it for exactly that reason. A loop should be used for looping, not faking a goto semantic. Since code is read many more times than it is written, I believe a programmer should strive to make the code as obvious and readable as possible. Using the above trick may confuse the casual observer and risks making it hard to maintain even for the seasoned developer. Notice particularly that variables that require cleanup must be declared outside the loop.

I finally converted (see I told you it was religious) over to the style I use today after I realized that it addresses all the issues above. Not only that but using my style will get you near 100% code coverage as the successful execution path hits every line of code. Here is a sample using my current style.


HRESULT DoBazThroughFooAndBar()
{
    IFooThings* pFooThings = NULL;
    HRESULT hr = GetFooThings(&pFooThings);

    IBarThings* pBarThings = NULL;
    if (SUCCEEDED(hr))
        hr = pFooThings->GetBarThings(&pBarThings);

    IBazThings* pBazThings = NULL;
    if (SUCCEEDED(hr))
        hr = pBarThings->GetBazThings(&pBazThings);

    if (SUCCEEDED(hr))
        hr = pBazThings->DoSomethingProfound();

    if (pBazThings != NULL)
        pBazThings->Release();

    if (pBarThings != NULL)
        pBarThings->Release():

    if (pBarThings != NULL)
        pBarThings->Release();

    return hr;
}
 


Older Posts »