/img/cartoon-avatar.jpg

Ryan Rinaldi

Staying Technically Relevant

In the comments to my post yesterday (comments meaning the only one I got), my friend and coworker Richard Lowe pointed out that working with new technology also adds business value. I have to agree with him. Staying up to date with technology, whatever technology you use day to day, does increase business value. I took that as a given because, in my opinion, if you don’t stay up to date then you become technically irrelevant and technical irrelevancy adds negative business value.

Business value

Anybody that has worked with me knows that I tend to be an early adopter of technology. I love playing with Beta, Alpha, CTP and “Here is my bin folder” builds. But sometimes as an early adopter I run into trouble. Not the kind of “This build borked my machine” types of trouble, but more along the lines of “Boy this is neat but what value does it give me?” kind of trouble.

Messaging

Something that has running on a background thread for awhile is “How do we implement pub/sub messaging?". One of the cons to having very silo-ed systems is how do you handle the cross-system reporting? For instance: When you want to get a list of all the customers that have more than 10 licenses and have more than 20 open tickets (totally contrived but you get the idea). That query spans 2 different domains: Billing and Support.

PDC 2008 Reflections

When I left the LA Convention Center on Thursday I was saddened. I had so much fun at PDC that I didn’t want it to end. I wanted to stay there forever and learn all about all the new and interesting things coming out of MSFT and MS Research. As soon as I got back to my hotel, however, I was eager to get home. The more I thought about it, the more I realized that my brain was full and it was time to head back to home and bother my coworkers.

Programatically change the identity of an AppPool

A couple weeks ago we were making some changes to our web servers that required all the Application Pools to be running as a known domain user. While it’s not hard to change it by hand, I figured it would be smarter for me to have 2 scripts, one to make the changes and the other to roll them back. So in the interests of the greater good, here they are:

Never ever catch System.Exception

…except when you should. :) Patrick Cauldwell wrote a great post on how to handle exceptions and I agree with everything he says except for this: “If you find yourself arguing for catching Exception, you probably have a design problem.” In most cases he is completely right. In every web app I write I never catch System.Exception and I have no reason to. If I’m code reviewing and I see somebody catch System.