Brian Nipper

As of late I have been spending a lot of time working on a “legacy” system. The term legacy means different things for different groups, in the circle I’m working with these days it means a system that is no longer being actively developed. As has been stated by mean, software isn’t “dead” it’s “done”. The catalyst for the work I’m doing is security requirements that need to be applied. While applying the updated security polices I’ve also been tasked with migrating the system from our data center to our cloud data center. As I move through the system I’m confronted with implementations that looking at now seem crazy; however, it’s these situations where it is important to apply two mindsets. One is giving others the benefit of the doubt. In a case like this, those that were working on this system used, for the time, the best options the technology stack could offer. For example, the extensive use of WCF seems silly now; however, at the time it was a recommended approach to hooki

I'm often told that I deal with difficult situations in a way that results in getting what I want. To me this is quick an interesting observation because I find that most often what people mean when they say that is, when I receive a poor customer experience I'm able to turn things around so that I obtain a desirable outcome, thus turning a bad experience into a good one. This manifest itself most often when I'm out and about with my wife. We will be at a retail store, or out to dinner and something will go wrong. Often my wife will turn to me and suggest that I handle it since "I know how to deal with these things". So what is the secret to my taking a bad situation and turning it around... being a good customer. As it turns out business want to make money. Shocking, I know. The way they make money is by advertising to attract customers to frequent their brick and mortar locations to use their services or purchase their goods. Knowing this puts the customer

* Working with a queue in .NET is an excellent experience and provides a great way to decouple execution paths. Once you start working with in memory queues your just a hope, skip, and a jump away from using "infrastructure" queues such as Service Bus, RabbitMQ, or even MSMQ on Windows Desktop. While it is quite possible to work with the standard .NET Queue<T> object if you find that you are in need of using a lock to ensure consistent results with putting things in the queue (i.e. Enqueue) and taking things off (i.e Dequeue or Peek) or even just to obtain a consistent reliable count, well then you should probably take a look at ConcurrentQueue<T> . There is a whole section of the .NET Framework with deals with concurrency concerns by creating specific objects for Dictionaries, Stacks, Queues and more that are considered thread safe. When I started working with ConcurrentQueues I found it helpful to put my own wrapper around the concurrent queue object and