Archive

Archive for October, 2010

Never Point the Skillet Handle Towards the Door

October 24, 2010 Leave a comment

In the bottom drawer of my oven there’s a little hooked lip on the inside. The lip is from the bottom cover of the oven and is just above the drawer. This lip catches handles, especially the handle of the skillet. The skillet gets caught when one places the skillet in the drawer with the handle towards the door of the drawer. Then when the drawer gets shut the skillet handle gets pushed down, ever so slightly as the drawer is shutting, but when the drawer is almost shut the skillet passes the lip and when the lip is no longer pushing the skillet handle down the skillet rebalances and the handle of the skillet ends up higher than the bottom of the lip. Most likely the person shutting the drawer didn’t even notice the bottom of the oven pushing against the skillet. The next person to open the drawer does notice, because they can only get it open by about two inches before the skillet handle is pushed up against the lip and the back of the skillet is pushed against the back of the drawer, preventing the drawer from opening any more.

This happened to me once when I was single. I laid down on the kitchen floor and could see that as the drawer was opening the skillet handle would catch the bottom of the lip and the drawer would open a little bit more, causing the skillet handle to get lifted up, just a little bit more, and then get caught, preventing the drawer from opening. I felt around the edge looking for a screw or release, but never found one. To take the door off of the drawer must require an angle of being inside the drawer, i.e. the drawer would have to be out of the oven. I was able to open the drawer about an inch, and with a screw driver I was able to leverage the skillet handle down and open the drawer. After that, I never put the skillet away with the handle pointing towards the door.

Today when Amanda told me that she needed help in opening the oven drawer, I knew exactly what the problem was. I was excited to come to the rescue and fix the problem right away. I knew exactly what I was doing. But it didn’t work. I got the screw driver on top of the handle, and pushed down and it didn’t budge. There must have been something on top of the skillet, pinning it down. There were two baking pans on top of the skillet, but I discovered that later. My next plan involved a screw driver and a pair of tongs to push the handle, rotating the skillet, getting the handle to be at a different angle, thereby making it possible to open the drawer. But no such luck. I think I was able to push the skillet over instead of rotating it. There was probably a little bit of rotation, but not enough before both the screw driver and the tongs were too short to push it any further.

At this point my current plan was to wait for the zucchini bread to finish baking, pull the oven out and tilt it on its side, causing everything to shift, and I’d open the drawer. While I was laying there my fingers felt something under the door of the drawer that I hadn’t noticed before. There were two socket screw heads. I don’t have a socket wrench, and even if I did there was no way I could have gotten it under the oven to unscrew the screws. But I was able to get a crescent wrench under there, and painstakingly unscrewed both screws. I was so excited, the screws would come out, the door would pop off and it was going to be easy to open the drawer. The second screw came out, and I pulled on the door and was able to pop the bottom of the door off. But the door was still attached to the top. I felt around the door and was able to feel two rivets on the other side of the door.

How was I supposed to get rivets out? They didn’t feel like screw heads, but maybe they were. I couldn’t tell if they were Phillips, or flat head, or stars.  I pressed my finger really hard against the rivet head and looked at the imprint in my finger. It was a Phillips! Success was nigh at hand. There was one problem, I didn’t own a screw driver that would fit into a two inch gap. I don’t  know if one even exists. Thankfully a screw bit to my power screw driver did fit into the tiny space. So with one hand holding the screw bit and the other hand holding a pair of pliers and the pliers holding onto the screw, I was able to unscrew the inside screws.

I pulled and popped the door off to reveal, the real door. The door I had just taken off was a decorative faux door to cover the real one. I was hoping to find hinges which I could use to lower this door and get access to the inside contents of the drawer. No such luck. Plus, this real door was connected to the drawer with rivets, not screws. But the faux door was a little bit wider than the door currently blocking me. I asked Amanda for a dowel and she brought me one under the condition that I didn’t break it. I had a little bit more room on the side and this time was able to push the skillet handle, off to the right, rotating the skillet, thus allowing me to open the oven drawer.

Moral of the story, when putting the skillet away, never point the skillet handle towards the door.

Categories: Hobbies

A Helper method that I kind of wish didn’t exist

October 21, 2010 Leave a comment
Something which has always annoyed me about .Net are exceptions without details. For example, there’s a FileNotFoundException and most of the time that comes bubbling up from some .Net class library, it doesn’t tell you the file that it couldn’t find. For years it’s been bothering me that whoever wrote the .Net library, didn’t include the name of the file. The method looking for the file, knows the name, why isn’t it in the exception?!
I think I now know why it’s the Marshal.ThrowExceptionForHr method. The method is a wonderful helper method that somebody pounded out, mapping error codes to english messages. Great idea for a helper method. It prevents everyone having to look up all of the possible errors which could occur from their P/Invoke call to native code. The downside is that because it’s so easy to use, that it’s used for cases where if it didn’t exist, we probably would have received a much more useful error message.
Let’s imagine a world where ThrowExceptionForHr doesn’t exist. The programmer writing some file I/O class gets to the point in the code where it has received the result of a method call. The code then checks for error or success. In the event of an error, the programmer would look up all of the different error codes, and instantiate an exception which matched the error code. When instantiating the exception they probably would have put in a useful error message (ie. a message which had the file name) because it would be so easy and useful to do so.
But since ThrowExceptionForHr does exist the programmer just checks for success and lets the Marshal class throw the appropriate exception. Now ThrowExceptionForHr has no idea what the name of the file was, and therefore can’t include it in the exception message.
If only I could find somebody’s arm to twist to check for common errors, and provide usefull error messages, before passing the error code along to ThrowExceptionForHr. 

When eye candy can hurt

October 20, 2010 Leave a comment
The phrase eye candy that I’m using here refers to when a programming language does things in the programmers behalf. An example for C# would be the lock statement. Everyone knows that when a lock statement gets complied, the compiler turns it into a try/finally block with a Monitor.Enter and Monitor.Exit call. A programmer can write it either way, but most everyone uses the lock statement, because it’s cleaner and more human readable.
I have just been caught off guard with how damaging a certain piece of C# .Net eye candy has been.
I have a little application which executes a series of permuations in parallel in an attempt to maximize the computing resources of the computer. When I profiled my application it was generally using all of the processor cores on the computer, but once in a while it was only using one core. All of the times when my applications CPU utilization dropped to one core I saw that the threads were blocked in the Garbage Collector as it was allocating new memory. I know that my application allocates a bunch of memory, but I figured I’d run the profiler in the memory allocation mode to find out if there was something being allocated that I wasn’t expecting; there was. My application was allocating a lot of WaitCallback’s.
If you look at the method signature for ThreadPool.QueueUserWorkItem you see that it takes a WaitCallback. But I was never giving it a WaitCallback object. I was just specifying a method name. The same method name, everytime. What’s happening is the complier is seeing my code and sees that I’m not passing a WaitCallback, but instead of erroring out it sees that I’m specifying a method whose signature matches a WaitCallback. So it creates a new WaitCallback at that point in the code. The end result is that everytime a queue’d up a call to the method a new object was being instantiated.
So in the constructor for the class I allocate a single instance of a WaitCallback. Then everywhere where I was calling QueueUserWorkItem for my evaluate method, instead of specifying the method I passed it the already instantiated WaitCallback. The result is more work on my part, less eye candy, but noticably better performance.
Before the change the profiler said that my application allocated 27,118,645 bytes. After the change it allocated 7,110,181 bytes. I’d say it’s worth the change.
Now am I going to stop using the eye candy of specifying a method instead of a delegate WaitCallback in my code? Most of the time, no. It’s rather conventient and usually doesn’t matter. But I’ll keep my eye out for those instances when it might.

A Must Do with Windows 7 libraries

October 19, 2010 Leave a comment
For all those using Windows 7 you probably know that the explorer window really likes the concept of libraries. Libraries are basically a folder with symbolic links to other folders. I have found that reorganizing the explorer window around libraries has made it more difficult to find files instead of easier. When I’m dealing with media in my user account I find the libraries to be nice, but I deal with a lot more than that. So, I’ve had to do three things to every Windows 7 computer that I have a profile on.
  1. Add my user profile to my favorites list
  2. Add the public profile to the favorites list
  3. Add the Downloads directory to the favorites list

By making these three directories easily accessible it has made using my computer much easier than the default library centric explorer.

The most serious discussion about invisibility that I’ve ever read

October 17, 2010 Leave a comment

Categories: Entertainment

Why adding features to cell phones wouldn’t have worked

October 16, 2010 Leave a comment

In my last post http://jader3rd.spaces.live.com/blog/cns!E1B1EA6459441949!5293.entry, I mentioned a great idea which is still an opportunity lost. Now I’m going to talk about why it wouldn’t have worked. The reason why Microsoft working with handset creators wouldn’t have worked is because of carries. Especially Verizon. Verizon loves charging for everything. Want a cord that will connect your cell phone to your computer? $20. It’s ridiculous. That should be an assumed part of the phone. Plus, Verizon cripples devices. We’ve seen it with Symbian and we’re seeing it with Android. For years Nokia has come to Verizon with a new phone and Verizon will pay Nokia to cripple features on the phone. Then it will sell us the phone, and sometimes charge us extra if we want the features uncrippled. It’s so wrong it’s disgusting.

That was part of the problem that Windows Phone had. Microsoft created the phone OS, gave it to device makers and said “It’s perfectly customizable, do what you want with it.” Part of the problem is that they did really crappy things to their phones to “differentiate” them from their competitors phones. Plus the carries (with Verizon being the most guilty) would then disable/cripple features of the OS before selling the phone.

So even if Microsoft and Nokia worked really hard on getting a great Sync story working between Windows and their phones, Verizon would have killed it.

Where Microsoft could have really succeeded

October 16, 2010 3 comments

Looking back, hindsight is always 20/20. But there was an opportunity that Microsoft had that I think would have really helped its position right now. And I don’t think that this wasn’t desirable at the time. The problem that Microsoft should have solved with Windows ME (and then subsequently Windows XP) is syncing devices. At that time Microsoft did have its Sync Center, but one had to go out of their way to get it, and I think it only worked with Windows CE devices. Should Microsoft have created the concept of Syncing with Windows instead of with individual programs they would have really set themselves up for the explosion of devices which came out in this last decade. Music players, cell phones, PDA’s, etc. Then Microsoft should have ensured that Nokia sync’d with Windows. It would have made for a much better experience than entering PIM data through a 10 key keypad. Just think, everyone with a cell phone would have received a better management experience with Windows XP, and the ability to sync with Windows would be a necessary feature that no one not having it could compete in the marketplace without.

Sadly this didn’t happen.