LINQ is terrible to debug. We have no way of knowing what goes on inside that query. We can see the input, we can see the output, but that’s about it. What happens when something goes wrong? Do we just stare at the code, trying to get some kind of insight? There’s got to be a better way…
One of the most commonly used patterns in software development is Caching. It’s a simple, yet extremely effective concept. The idea is reuse of results. When performing a heavy operation, we will save the result in said cache
I’d like to tackle an old dilemma: Class instantiation. Which pattern do you use to create a class? Do you always use a new statement? Do we still need to use Singleton or Factory? Should we always use dependency injection? How about static classes, are they truly evil?
How many times did you use a desktop application to end up with a frozen unresponsive window? This article is about what we are to do when our .NET application freezes. We’re going to explore tools and debugging techniques to see where the program is stuck and to find the core cause of the issue.
Memory leaks are sneakily bad creatures. It’s easy to ignore them for a very long time, while they slowly destroy the application. With memory leaks, your memory consumption grows, creating GC pressure and performance problems. Finally, the program will just crash on an out-of-memory exception.
In this article, we’ll see how to implement Job Queues with TPL Dataflow, including implementations of several of the said variations. We will dive into the Dataflow mindset along the way, figuring out this awesome library.