Saturday, July 02, 2011

What was the surprise?

Sorry, I left that last post a little vague -- I just didn't want to take the chance that Megan would check her email and stumble onto the details before she got home.

The surprise is that I decided to paint the upstairs guest bathroom while she was gone. I got tired of looking at the old and moldy paint, so I went down to Lowe's, bought a bunch of painting supplies, picked a color and went at it. Most of the work was done in one afternoon, and I spent a little time the next couple of evenings cleaning up.

(If you've seen our downstairs bathroom, you'll realize I was pretty tame on the color choice here... I didn't feel like choosing a really bold color as a surprise. :) )

Unfortunately, I forgot to take any "before" pictures -- but here's a few that I did take!

The first paint on the wall! (Stupid blue painter's tape. Next time I'm buying an edger and skipping the tape altogether.)

That same wall, now painted!

The wall on the other side of the doorway. I had no idea a small bathroom was so hard to photograph -- there's just not enough room to take a good picture of it!

I even bought some off-white spray paint and repainted the heater vent cover, which was rusting and chipping pretty bad.

Overall, this was a fairly easy project but I learned a bunch along the way. The big things:
  • Use an edger instead of tape in the future. The tape is just a pain. 
  • If you must use tape, take it off immediately after you're done with the first coat. Don't wait until after the next day's touch ups, because it will peel paint off the walls. 
  • Take the medicine cabinet out of the wall first, so you don't have to do it after you realize you couldn't get to the spot behind the far side which is visible in the mirror... 
(This post was pre-recorded -- it will go live on Saturday, after Megan should be home.)




Wednesday, June 29, 2011

A surprise!

Megan already knows about the patched hole in the wall but I've got another surprise ready for her when she gets back this weekend!

I hope she likes it...

I hope she notices it...

Saturday, June 25, 2011

Filling the hole in the wall

So, Megan left last night for an outrigger canoeing race and then a week at Anglican summer camp... and I'm already bored...

...so I decided to fix the hole in the wall that I left while hanging the punching bag. I think it turned out pretty well:


It still needs a couple of gaps patched up, some sanding, and a coat of paint but at least you can't see into the wall anymore!

Also, I ran across this picture I took a couple weeks ago while we were playing D&D. Apparently Imri likes my motorcycle!

Wednesday, May 25, 2011

Hanging the Punching Bag

So… this time I’m not making any promises or even suggestions that I’ll start writing here on any regular basis. Apparently that’s just not going to happen.

However, I just finished a fun project that I wanted to share. This one is a bit out of the norm for me – instead of computers, this one involves lumber, saws, drills and bolts!

Megan and I have both wanted to have a punching bag available to beat on for a long time (I remember having a conversation about it in the condo in Goleta, so we’ve been discussing it for at least 2.5 years). Well, she finally got tired of waiting on me and bought a big 80 pound bag. Funnily enough, however, just having a bag is just the start – we didn’t really enjoy using it while it was lying on the ground or propped against a wall!

And so began the project.  

I did some research, shopped around, and eventually decided that I wanted to mount it on the wall using this wall mount. Some additional reading convinced me that I also needed a heavy bag spring and a bag chain and swivel. A couple days later I received my items and was ready to go.

When everything showed up, I was pretty excited to get started on the project. So I immediately ran to the local hardware store, picked up a couple 2x4s and some bolts and washers. I cut the 2x4s to 52” so they would span across four studs (at 16” apart each) and mounted them parallel to one another for the wall mount to be mounted on. Unfortunately, I either pre-drilled the holes to large, or was plain unlucky, because three of the bolts refused to stay put properly, and when the bag was mounted, the weight of it's swinging was pulling the 2x4s away from the wall. Ugh.

I needed to try again. Back to square one.

The second time, I got more serious. I decided that I didn’t want the sheetrock between the studs and my lumber, and I wanted bolts made specifically for this kind of attaching. Also, I wanted 2x6s instead of 2x4s so I could fasten the lumber with pairs of bolts instead of single bolts.

Cutting into the drywall was a new thing for me, but it was fairly simple once I had a decent drywall saw (which I learned I needed only after I broke one of the blades for my sawsall). At this point, I realized that pictures would be nice!

(Pro tip: when removing drywall, you can find the screws/nails (mine had both!) that are fastening the drywall in place using a magnet! For people that do this all the time, that's probably obvious, but I was having a hard time finding them before I thought of that.)

There's a hole in the wall!
Up close and personal with the hole in my wall.
After the hole was done, it was time to add the lumber. The bottom one was pretty easy -- I had a 1/2" of drywall to rest the board on. The top one was a bit trickier -- I had to get creative and cut a bit of one of the old 2x4s to serve as a brace.
2x6s mounted with a small brace wedging the top board in place while I screw in the bolts to hold it.

Finally, I was ready to re-mount the wall mount for the bag. This was also pretty tricky, as the mount itself weighs 15-20 pounds and its really awkward to hold and I was working by myself. So I got clever again -- I laid the mount down on a piece of cardboard and traced it, marking where the holes for the bolts were. Then I used this template to put some small drywall screws in place that the mount could hang on temporarily. At that point it was a simple matter of removing one screw at a time and drilling the real bolt into place for the mount.
The bag hanging on its own. Finally!

And here's the bag in it's "resting position", folded away to the side.

I managed to save the majority of the drywall I needed to remove, so I'll use that to replace the middle section. I also plan on painting the boards to match the wall at some point. All that finish work is going to wait for a while though, so I can keep an eye on the mounting as we start using the bag, just in case.

Oh! I also finally decided that my tool management strategy was getting hopelessly behind the number of tools I have collected, so I got myself a new present:

Sunday, August 08, 2010

Python vs. C# - Exceptions

I briefly mentioned in an earlier post that I had left Cogi to start working for The Trade Desk. One of the many changes that this entailed was to stop working in Python, my preferred programing language, and start programming in C#. Both languages are quite popular, and each have their own merits: Python's "batteries included" standard library and programmer-centric philosophy allow a programmer to focus on producing software, while C#'s .NET-backed runtime and Microsoft integration give it a great backbone for software development.

As I've spent a good deal of time programming in both languages, it seems like it might be interesting to compare some aspects of the two languages. To avoid overwhelming either myself or my readers, I'll limit the discussion to one feature at a time. Assuming that anyone finds the articles interesting or informative, I will periodically post comparisons between the two languages.

Today's feature: Exceptions.

First off, I'm going to assume that it's a given that exception handling is a Good Thing. The only major alternative that I'm aware of is a combination of return codes and segmentation faults (for the lay-reader: crashes). Return codes mean you have to check the result of any potentially failing method call, making your code focus more on what can go wrong than on what should go right. This leads to fragmented code which leads to more bugs. Exception frameworks allow us to focus on what should happen, and deal with the consequences in alternative blocks of code higher up the stack where we can make more logical decisions. Both Python and C# fall into the exception-oriented camp (for the most part).

Both languages treat exceptions as first class objects and provide a good try/catch/finally mechanism that allows a developer to handle and deal with exceptions of both specific and general types:

Python:
def TestMethod():
    try:
        DoSomethingScary()
    except:
        print "Oops!"
    finally:
        Cleanup()

C#:
public void TestMethod()
{
    try
    {
        DoSomethingScary();
    }
    catch ( Exception )
    {
        Console.WriteLine( "Oops!" );
    }
    finally
    {
        Cleanup();
    }
}

Both Python (as of 3.0) and C# also support the idea of a "nested" or "inner" exception. This is a critical component of robust exception handling, as it can be used to ensure that an exception can always be traced back to its source. In my previous jobs, working with both C++ and earlier versions of Python, we implemented and maintained extensive libraries of code just to provide this critical debugging feature.

One area where Python and C# significantly differ from one another is in the detail included in exceptions. In particular, I'm referring to the built-in exceptions in the language libraries, since the language obviously has no control over how a developer chooses to write their code. Consider the following algorithm:


  • Create a dictionary of key-value pairs.
  • Populate the dictionary with some well known or required data.
    • Let's say the keys we're trying to put in are "a", "b", and "c".
  • Get input from somewhere.
    • Let's say we get "c".
  • Use the input to attempt to retrieve a key from the dictionary.
    • The key doesn't exist, so an exception is raised.

"Ok", you think, "that's no big deal. I just have to figure out which key it was that was looked up and figure out why it didn't exist in the dictionary." In Python, you would have no problem, as the exception tells you what you were looking for:


    Traceback (most recent call last):
      File "", line 1, in
    KeyError: 'c'


Given that info, we know that something was wrong with the code populating the dictionary, since the expected key "c" didn't exist. If that KeyError had indicated that "x" was looked up, we would know that the input we were given was bad, since we didn't expect "x" to exist. From there, it's just a matter of tracing down the code that caused the problem.

On the other hand, in C# all you're given is that the data wasn't found:


    Unhandled Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
       at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
       at ExceptionExample.Program.Main(String[] args) in     C:\Users\chris\AppData\Local\Temporary Projects\ExceptionExample\Program.cs:line 13

Well, what do we do with that? At this point, we have to start debugging manually -- either by adding some print statements or by setting a breakpoint at the indicated line. Remember that in Python, we already had a starting place -- we knew in which direction we had to look for the bug, and possibly could have solved the problem without ever starting a debugger. In C#, we can't even begin to investigate the problem without a debugger because we weren't given enough information to start with -- information that was obviously available at the time the exception was thrown!

And it's not just KeyNotFoundException that has this problem; it's nearly every exception I've seen thrown by .NET that could contain information about the problem that caused it. Another example is the dreaded NullReferenceException. Where C# forces you to drop into the code and hope the line numbers line up (and let's hope you're not trying to use reflection -- but that's a Python vs. C# topic all on its own!), Python handles its equivalent beautifully:


    >>> a = None
    >>> a.hi
    Traceback (most recent call last):
      File "", line 1, in
    AttributeError: 'NoneType' object has no attribute 'hi'


Winner: Python.

Monday, July 19, 2010

Moblie Device Antennas

I'm neither a mobile device expert nor a wireless antenna expert, however I'm getting a bit tired of this iPhone 4 attenuation issue and am now ready to weigh in. In particular, I'm quite annoyed with Apple's dodge of the issue. Yes, all antennas have attenuation issues when they come into contact with a conductor (like a person's hand). However, despite all the manuals that have discussed this and the many phones that have had this issue in the past, it's never become a big deal until the iPhone 4.

The reason it's different in this case is Apple's innovative design that places the entire antenna on the outside edge of the phone.

I don't personally mind that they did this in terms of design -- Apple is great at design, everyone knows that. However, in this case the design bit them in the metaphorical ass and they're not willing to own up to it. Pointing out that all phones have the problem just shifts the blame; it reminds me of a mother's saying "If everyone else jumped off a bridge, would you?"

Now Apple has managed to get all of their fan boys parroting out their phrases and trying to catch everyone else -- as if other people claimed that there were no attenuation issues in other phones.

I don't think Apple necessarily should have had a full recall for the phone -- but then, I didn't drop $500 on it either. I don't think the free bumpers were a "bad" solution, just the way the presented them. The honest response to the problem would have been to say: "The phone has a problem which will be addressed in the next revision of the phone. We feel that the best response for our customers and stockholders is to give out the rubber Apple bumpers or a full refund for unsatisfied customers." It's essentially exactly the same conclusion without the dishonest misdirection that has resulted from their response.

Saturday, June 12, 2010

Waking up from the dream

Yesterday afternoon I woke up from a dream I've been trapped in for ten long years. In this dream I would look across the room at a clock and not be able to tell what time it was or look at a TV and not be able to make sense of what I was seeing. That has all changed.

This dream, of course, is my poor eyesight and reliance on glasses to be able to read anything further than a foot away from me. I started wearing glasses in high school ( I think during my junior or senior year ) when Madeline, Katrina, and Stephanie kept harassing me about my squinting to read what was on the board in class. Since then, I've been wearing glasses or contacts every day.

A few months ago, I finally decided that I had had enough of it. I was tired of having to put on glasses first thing in the morning, just to be able to see myself clearly in the mirror; of having to clean my glasses every time I accidentally touched them and left a smudge; of worrying about losing or breaking my glasses and not being able to function until I got replacements. So, I decided to start looking into LASIK surgery.

So I did some reading and discovered that LASIK is expensive but not prohibitively so. I scheduled an appointment with my optometrist for a general check up and consultation about LASIK. He indicated that I was an "ideal candidate" for LASIK and recommended me to an ophthalmologic surgeon named Dr. Winthrop in Santa Barbara.

A few days later I went in to see Dr. Winthrop who confirmed that my eyes were perfect for the operation and outlined the procedure for me. I decided to have the procedure done and we agreed on a date one week in the future.

Yesterday was that day.

Since Dr. Winthrop's office is near Megan's office, the morning of the procedure I went into work with her and waited around her office until time for the procedure. At eleven, I went over to Dr. Winthrop's and began. After some standard administrivia, they gave me some Valium and took me into the surgery room.

During the surgery, you are laying on your back, looking up at an array of red and white lights, with one green light in the center. The surgeon tells you that your only job is to look at that green light.

The first part of the procedure is the most uncomfortable -- and the main reason they give Valium to their patients -- the surgeon uses a suction device to hold the eye in place and cuts a small "flap" in the cornea. Since the eye has been anesthetized it doesn't really hurt but it's a bit unnerving and uncomfortable. However, 15 to 20 seconds later that part is done.

The next part is simple for the patient -- and actually kind of fun. The surgeon pulls back the flap he's just created and the lights you're looking at become really blurry. Then, for the next 10 seconds or so, the laser does it's work -- you can't feel anything, but your eye is being reshaped. Then the surgeon puts the flap back and makes sure it's clean and smooth.

Then repeat for the next eye. The whole procedure takes less than 10 minutes.

Afterwards, I was carefully walked back into a dim room with a comfortable chair to await the doctor. The nurse gave me some Vicodin to help me relax and brought my wife  in to sit with me. After a few minutes the doctor came in, took a look at my eyes, gave me some eyedrops, and sent me home with instructions to keep my eyes closed and try to sleep for the next four hours.

So Megan took me home and I slept.

When she came back home a few hours later, I opened my eyes and could see almost completely normally again.

Today I drove myself into the doctor's office for a follow up exam without glasses and was quickly told that I have at least 20/20 vision again.

The metaphor of a dream I used to start this post may seem a little over-poetic but it's apt. That same feeling of a dream being hard to remember after you've been awake for a few minutes is about how I feel now -- my eyes see so normally now that it's almost hard to remember them being any other way.