Movie Review: Ender’s Game

Ender's Game came out very, very well!

I was amazed by how close to the book they kept the movie.  Some definite editing and abbreviating (unavoidable in the change from book to other media), but nothing that detracted from the story or the characters.

I went into the movie expecting it would either be amazingly good, or absolutely horrible, depending on what they did to the book.  It’s one of my favorite books, and has been for almost 30 years.  Didn’t much like the sequels when I was a teen, but I may need to give them another shot one day.  But the first book has always been a favorite.  Book-to-movie adaptations of favorite books, especially ones with strong political messages, seem to go to extremes in either direction.  Dune (horrible to whole new levels), Starship Troopers (pretty horrible, though I am a Dina Meyer fan and liked most of her scenes), vs. the Lord of the Rings trilogy (Fellowship, Towers, King), or Blade Runner (which is infinitely better than the book).

Fortunately, my expectations were met, and the movie was very, very well done.

10 out of 10

DBA Article: Learning By Teaching

“Those who can, do. Those who can’t, teach.” (Attributed to H.L. Mencken)

What this is meant to illustrate is that those who have top-notch skill in a field, make their money actually doing work in that field, while those without enough skill to actually do the thing, will end up teaching (at best). Of course, those who teach hate this quote.

But there’s a point in it that’s of interest beyond the immediate meaning. It’s that, if you can do the thing, you could teach it. It’s been said that anyone with a real understanding of a technical subject, can communicate it to others, clearly, even if the students don’t have the vocabulary of the subject.

For example, I’ve experienced two people with different levels of understanding, who were both trying to explain how air conditioners work. One, who knew how to install and repair air conditioners but didn’t know the theory behind them, confused the audience with detailed descriptions of “compressors” and “Freon pumps” and so on. The second, who actually understood the whole process, asked the audience, “Have you ever used one of those cans of compressed air to blow dust off of your keyboard?” Everyone said they had. “You know how the can gets really cold?” “Yeah. Yep. Experienced that.” “Air conditioning works like that. When gasses get compressed, and then expand suddenly, they cool down, just like that dusting can.” Everyone understood.

So, if you want to test your own understanding of a subject, explain it to someone who isn’t already an expert. Once you figure out how to do that, you’ll have proved how well you yourself understand it.

Years ago, I discovered online SQL forums. I found people asking questions. Some of those questions, but only a very small number, I could answer. So I did. Other questions, I could understand what was being asked, and could almost answer it. So I researched the subject till I could answer it, and then did.

Some of my answers were challenged by others. Those challenges forced me to either clarify or defend my answer, or to correct my answer when (more often than I like to admit) my original answer had been factually just plain wrong.

I learned to build tests and to try to break them, so when I gave an answer it was already tested and I knew it would work before I suggested it. This is the senior echelon, beyond teaching and into doing, and experience in it is critical to advancing any skill.

The more questions I tried to answer, the more I learned. I found answers to questions I would never have thought of asking. And, in many cases, those questions were ones I should have been asking, but didn’t realize it. So the answers helped me as much or more than the person with the original question.

And the challenges to my answers! Awesome! I had to eat some crow, and I had to unplug my ego from the discussions, but I made that easy on myself. In doing so, I unlearned a lot of things that were wrong, learned a lot of new things, and improved my own skill.

Even when my original answer had been correct, the challenges exposed weaknesses in the answer, and I learned how to communicate my answers in such a way that they prevented the challenges from having to be posted.

Most importantly, by this process, I found a number of my own blind spots. We can never see our own blind spots, unless someone else points out, directly or indirectly, what’s in them. (That’s what makes them blind spots, after all – we can’t see what’s in them.) By reading questions I never would have asked, or reading answers by others, or by being challenged on my own answers, my blind spots were exposed.

Later, I added presenting to a PASS group to my “learning by teaching” activities.

These days, I do a monthly lunch-and-learn for the software development department at my employer. Organizing the material so that I can communicate it clearly in that kind of time-limited format, really forces me to make sure it’ll be clear and will educate rapidly.

All of these ideas and anything similar, can really help you to advance your own skill. It’s also very, very enjoyable, all by itself. If you haven’t tried it, do.

Of all the lessons I’ve learned in my years as a DBA, all of the “I wish I’d known this when I started out”, I think this is the most important.

DBA Article: Documentation

A while back, I wrote a series of articles for beginning DBAs.  Not on the technical side of how to handle SQL Server, but on the subject of “things I wish I’d known when I was starting out”.

Here’s the first:

DBA Tips & Tricks: Document “Why” Not “What”

One thing I find in reviewing and refactoring older database code, that makes it much more difficult to figure out what to fix and how, is the documentation provided.

We’ve all run into situations where there simply isn’t any documentation, or it consists of “--TODO: Document this section” or something equally unhelpful.

Many DBAs and developers will even claim that “good code documents itself” as a justification for never getting around to documenting it. Sometimes this is seen as lazy, sometimes it’s seen as clever. What it really amounts to, in my opinion, is a complete misunderstanding of what documentation is about.

Here’s an example of what some might call “well-documented code”:


--smalldatetime fix
ALTER FUNCTION [dbo].[fDateFix] (@dateval DATETIME)
RETURNS SMALLDATETIME
AS
    BEGIN
    -- Declare Variables 
        DECLARE @sdate SMALLDATETIME
        DECLARE @edate SMALLDATETIME
        DECLARE @newdate SMALLDATETIME
  
    -- Set values
        SET @sdate = CAST('1900-01-01' AS SMALLDATETIME);
        SET @edate = CAST('2079-06-06' AS SMALLDATETIME);
  
    -- Check value of input, correct if needed
        IF @dateval IS NOT NULL
            BEGIN
                IF @dateval < @sdate
                    BEGIN
                        SET @newdate = @sdate
                    END
                ELSE
                    IF @dateval > @edate
                        BEGIN
                            SET @newdate = @edate
                        END
                    ELSE
                        BEGIN
                            SET @newdate = @dateval
                        END
            END
        ELSE
            BEGIN
                SET @newdate = NULL
            END
 
    -- Return corrected date         
        RETURN @newdate
    END


Each section says what it does. It clearly states that the function has the purpose of “smalldatetime fix”. The first part declares the variables, the next part assigns values to some of them, and so on.

This is a clear example of where “the code documents itself” is both true, and completely and utterly useless!

Why is it necessary to “fix” a smalldatetime? What are those “magical number” type dates that those variables are assigned to? Why does this function exist?

How about this, instead:

/*
   Purpose:    This takes DateTime input, checks if it is out-of-range
               for datatype SmallDateTime, and sets to the closest
               allowed value for that datatype if so.

               Use when tables are designed with SmallDateTime and inputs
               are not policed (free-form) in applications.
*/
ALTER FUNCTION [dbo].[fDateFix] (@dateval DATETIME)
RETURNS SMALLDATETIME
AS
    BEGIN
        DECLARE @sdate SMALLDATETIME
        DECLARE @edate SMALLDATETIME
        DECLARE @newdate SMALLDATETIME
  
        SET @sdate = CAST('1900-01-01' AS SMALLDATETIME); -- Minimum allowed SmallDateTime value
        SET @edate = CAST('2079-06-06' AS SMALLDATETIME); -- Maximum allowed SmallDateTime value
  
       -- Check value of input, correct if needed
        IF @dateval IS NOT NULL
            BEGIN
                IF @dateval < @sdate
                    BEGIN
                        SET @newdate = @sdate
                    END
                ELSE
                    IF @dateval > @edate
                        BEGIN
                            SET @newdate = @edate
                        END
                    ELSE
                        BEGIN
                            SET @newdate = @dateval
                        END
            END
        ELSE
            BEGIN
                SET @newdate = NULL
            END
 
        RETURN @newdate
    END


(Note, this function is one I copied out of a third-party application and is not intended to be an example of good code. It could obviously be improved by a blind man with a sledgehammer. It is used here simply to show the difference in documentation styles.)

Note that anyone reviewing the “what it does” version gets no help at all from the “documentation”. “Oh really? So this part declares variables? I would never have guessed that!”, isn’t something that one says without sarcasm.

But the “why was this written” documentation says things the code itself can’t say, and is useful to someone reviewing the code at a later time. It raises questions like, “Is there a comparable function that corrects from DateTime2 to DateTime? If so, why isn’t it a single function with the output type determined via a parameter?” And, “Why don’t they just police this in the application? Shouldn’t this be handled closer to the user, so they know that we’re just going to arbitrarily change their input?” And so on. Very useful to someone doing a refactor.

Documenting why changes were made, in the DDL scripts that implement the changes, can allow for a chronological study of either source control or a DDL log. Imagine the different between logging “Updates the table” type comments, vs “Per meeting with John Doe and Sue Smith on 1 Jan 2013, changed business rules to use UpdateDate column for the record instead of AuthorizationDate”. Suddenly, code changes that might otherwise be mysterious a year from now, are quite clear.

Keep this in mind when writing and reviewing code. In later years, you’ll be glad if you implement it.

If you have a good project ticketing system, “why” documentation can be as simple as “Purpose: See ticket DB-1103, notes from 3 May 13”. It adds a level of work to reading the documentation, since it’s not contained in the code, but allows for much richer “why” where that’s needed.

Ultimate SEO Fail

Did a Bing search for “search” and, not only does Google come up first, but Bing wasn’t even in the first seven results.

That’s Ballmer’s legacy, just like that.

Spiders and Wasps

Last night, I found some black widow spiders nesting in the garage.  Sprayed them with some Raid, which says on the spray can that it kills spiders.  It does, but it takes a LONG time to do it.  At least in this case it did.  Sprayed them last night, and they were dead by late this morning.  One of three was still moving a little bit first thing, but by late morning they were all dead.  They have another product that I might try if there’s a next-time.

Then I saw some wasps building nests on my patio this afternoon.  I’ve dealt with those before.  Raid Wasp & Hornet spray is pretty much insta-kill on them.  Worked immediately this time too.

Adventures in owning a house!

Good thing I’ll be doing the Purification Rundown later this year, with all these insecticides and such I’m having to use!

New House: It’s Curtains for This Place!

		Curtains (and Blinds) are Up VIEW SLIDE SHOW DOWNLOAD ALL

It was interesting installing these.  I keep thinking in terms of wood-frame structures, but when I was drilling the holes for mounting the curtains, the drill suddenly hit “something hard” and “gray powder” started coming out.  Duh!  The outside walls are all cinderblock!  Not sure how I forgot that, but it sure made the whole thing a bit different.

Had to wear a dust mask to keep from breathing too much powdered silicon.  Had to use a concrete drill bit.  Takes more time and patience to drill into it as well, of course.

Anyway, adventures in getting up the curtains are done for the living room, bedroom, and dining room.  The kitchen has flowery plastic on its window.  All that remains is the TV room, and I’ve got ideas for that (it needs to be darker in there).

Movie Review: Red 2

Saw Red 2 last night.  Loved the first movie (Red), and loved the sequel!

There were a few jokes that struggled a bit, but most were hilarious.  There were a few action scenes that lasted a bit too long, but they were all very good nonetheless.

Marvin (John Malkovich) rocked the movie.  Frank (Bruce Willis), Sarah (Mary-Louise Parker), and Victoria (Helen Mirren) were all as great as they were in the first movie.

And because it could get pretty much straight into the action, without having to spend time introducing characters, it had a significant advantage over the first.  (Though that may leave it less than fully comprehensible to anyone in the audience who didn’t see the first one.)

9.5 out of 10

New House: Yard

I just went walking barefoot in my back yard.  It’s been so long since I did anything like that, that it felt weird (but nice) on my feet!

New House: Adventures in the Land of the Blinds

The back door is no longer naked!  Woot!

(Here’s a before-shot.)

These things are easier to install than I feared.  Put it in this afternoon with very little trouble/effort.

The ones on the dining room windows (different make/design) are, however, seriously attempting to drive me to drink….

New House: Paintings Up

Just put up some art in the house:

		Works of Art VIEW SLIDE SHOW DOWNLOAD ALL

The first picture is the view to the left as you step in the front door (facing towards the living room).  Followed by the view to the right.

The second two are the views from the living room (towards the front door).

The final picture is the only one that aren’t of Mom’s paintings.  I’ve got two cheap-but-nice pictures of the rock escarpments and isles off the Pacific coast of Washington, and a clock that I like.

None of these are monetarily valuable, but the emotional value is inestimable!

(And, yes, the picture backgrounds definitely show that we’re still moving in.  Pardon the mess, please.  It’s temporary!)

New House: Pictures

		New House 2013-07-08 VIEW SLIDE SHOW DOWNLOAD ALL

Some are from it was under construction, some are finished.  None are post-move-in, so no furniture, etc., in these, except the welcome mats.  We put those in as soon as the deal was closed and the mortgage signed for.  Kind of “We’re Here!” markings.