Sunday, April 20, 2008

A much desired hack for IE 7

If you're like most people, you're using a version of Internet Explorer (abbreviated as IE). You might not have made the switch to IE7, but when you do, there is one hack that I highly recommend. By default, IE7 runs without a menu, like shown below:




To enable menus, simply go to tools (it's just a little bit underneath the 'X' in the upper right hand corner), and there will be an option near the bottom called 'Menu bar'. Click on this and the menu bar will appear, but not where you would expect:





(Do you see it?)

Ok, we can fix this. Fire up the old trusty 'Regedit' tool (** Disclaimer: only modify the registry if you are comfortable doing so. Failure to be cautious can cause you to be the owner of a $500 paper weight). Navigate to 'HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/Toolbar/WebBrowser/'. Now, left click below the current keys in this folder and select “New > Dword (32 bit) value”. Name the new value 'ITBar7Position'. Once created, modify the value and change it to be 1. Exit the registry and restart IE7. If successful, you should see something like this:




That's much better.

Monday, April 14, 2008

What I will do in the next 6 months to become a better developer

I've been on a quest in the last couple of weeks to discover tips on becoming a better developer when I ran across this podcast by Scott Hanselman which suggests a few ideas but largely states that whatever it is you decide on, that you write it down and you make it public. So this is my first blog post as part of my attempts to become a better developer in 6 months.


Instead of picking just one item, I've picked 5 items to work on and complete by October 11th, 2008.


  1. Post 26 blog entries, approximately one blog post a week.

  2. Read the source code for 2 open source projects.

  3. Read 2 books on development

  4. Start a local pub club for software development

  5. Publish 2 software applications


I think the first item is self explanatory. The second item is also courtesy of Scott Hanselman on this blog post. I've decided I'm going to tackle two related projects, NAnt and CruiseControl.Net. I've already glanced at the code for CruiseControl.Net for reasons that I'll explain in a couple weeks.


The idea for reading development books came from the original source for this idea, a blogger named Justice Gray. While I won't go to the extent that he planned (I say planned, because he never reported on his success or failure), I do plan to read two books. The first is a book my wife picked up for me because it had the word “Code” in the title, Dreaming in Code. I've read the first two chapters of the book and so far, it's better than I expected. The second book is more technical, Web Technologies: A Computer Science Perspective. I read a sample chapter of the book courtesy of TechRepublic, and I enjoyed the nature that the material was presented in.


The idea for a pub club comes from Scott Hanselman's podcast I mentioned earlier. I think it will entail only other developers that work at my company, but I hope to add other people as I get acquainted with other developers in the area.


Finally, I plan to release two software applications. I have several ideas for software projects floating around in my head, and I hope that giving myself a deadline is what I need to ensure these projects get accomplished. More on what these software applications are in a couple of months.


Now that I've laid down my 6 month plan, do you have a long-term plan to be a better developer?

Thursday, February 21, 2008

Learning and Fixing our Bugs

I had a particularly nasty issue assigned to me a week or two ago. It's one of those bugs that I spent so much time and effort on that it was difficult to enjoy my evenings and weekend. It was nasty for a variety of reasons.


First, it involved a program component which was originally written by a developer who had already decided he would no longer work for the company, but decided he'd finish this component. As you can imagine the code is in horrible shape. Few people have any knowledge of this component, and none of those who do understand the entire system.


Second, this component could be considered an entire software solution in its own right. The size of the project is large enough that it is often installed on its own machine in production.


Third, this component was installed in an environment in the testing environment which had taken 6 weeks to setup (normally, just a few days is required).


Fourth, the error message was one that had occurred before, and in most cases, pointed to some particular setting being incorrect. Thus, it made it very difficult to rule out environmental issues.


Finally, this component is not used by one software team, but three. Since all three teams use the same component, no one “owns” the component. However, there are “satellite” assemblies of this component which each of the three teams provide on their own.


Because of the third and fourth reasons (similar errors pointing to environment issues), I spent a good amount of time traveling down that path. In the end, it proved to be a very complicated issue. There were multiple reasons for the errors. Most of the errors could be tracked down to the final reason, no one owning the software component. Due to this fact, code for this component was not delivered correctly, because of the satellite assemblies.


I learned a couple valuable lessons from this error though. First, I had great difficulty recreating the error due to a poor setup on my development machine and I can never let that happen. While I normally detest debugging, debugging this component is absolutely essential, for the size of the project and the poor state of the code is to much for one developer to grasp at one time.


Second, and more importantly, I learned it is a VERY bad idea to have a large internal component which is used by several teams, but no one team is responsible for maintaining. In hindsight, this is obvious, and probably rarely happens in other companies (if does in yours, I'd like to know).


While I could have done a much better job in handling this error and I could have solved it in a much quicker fashion, I have at least taken a couple things away from my mistakes, and my boss has recognized that this component needs to be developed by one team, and one team only.


So, recognize that mistakes will happen, but always learn from them, especially in the field of Development.