These are programming specific articles that will be published to CodeProject. They should be complete tutorials with code examples for you to use!
In this article I'll be going over one of my most used design patterns called the facade (or façade), and explaining why I like to use it. As with all things I share information about, it's important to remain pragmatic as software engineers. With that said, this article is not to persuade you to use this pattern exclusively or that there are not alternatives. Instead, I'd like to arm you with another design pattern tool in your figurative coding toolbox. The more tools you have available, the better prepared you are to go build awesome stuff. What We're Trying to Achieve With a Facade When I am developing software, whether it is personally, professionally, or as someone that is influencing the direction of software I am not directly coding myself, I encourage a focus on flexibility in software. I have…
I wanted to create a follow-up post in my series on IEnumerables, iterators, and collections focusing on performance characteristics. When checking out the runtime performance and memory characteristics between these materialized collections and iterator benchmarks, I was very surprised! Check out this article for performance benchmark characteristics and some curious finds.
As C# programmers, we've all been burned by asynchronous EventHandlers. And if you still haven't yet, then hopefully this article will arm you for being able to better navigate long debugging sessions where functionality mysteriously stops working in your application. While there are several different solutions for dealing with async event handlers, either by avoiding use of async void or even by embracing async void, in this article we will explore another option which is Task EventHandlers. Disclaimer: this article was originally written with the perspective that this solution feels close to bullet-proof, but there are important limitations. These limitations are addressed later in the article, and I felt it would still be valuable to explore the space (both positives and negatives). A Companion Video! https://www.youtube.com/watch?v=QVGjpRz0JZU What you DIDN'T know about C# Async EventHandlers The Source of the Problem Normal…
When we discuss async EventHandlers, the first thing that comes to mind for many of us is that it's the only exception that we seem to allow for the dreaded async void setup. When I had written about this before, I was excited that I was exploring a solution that involved actually allowing async void to exist (without wanting to pull the rest of my hair out). For me, this was much more about some clever tricks we can use to overcome async EventHandlers than it was to provide solutions for avoiding the problem entirely. With that said though, there was a lot of traction on the article, which I am very thankful for, and some folks expressed opinions that they'd rather solve async EventHandlers a different way. I thought this was a great point, so I wanted to come…
In C# 9.0 we received access to a great quality of life type called the record. You can read more about that from Microsoft here. Record types allowed us as dotnet programmers to skip a lot of boiler plate code, thereby saving us time and making code more readable. Wins all around! Before record types, we might have simple data transfer objects (called DTOs) that would look something like the following: public sealed class MyData { public MyData( string value1, int value2) { Value1 = value1; Value2 = value2; } publc string Value1 { get; } publc int Value2 { get; } } And for a simple class with two properties... I think we can all agree that the verbosity here is just over the top. With the record type that we were given access to, we can now write…
You're an intermediate dotnet programmer and you mostly know your way around using Tasks. You sprinkle async and await through your code, and everything is working just as expected. You've heard time and time again that you always want the return types of your asynchronous methods to be a Task (or Task<T>) and that async void is essentially the root of all evil. No sweat. One day you go to wire up an event handler using the syntax myObject.SomeEvent += SomeEventHandler, and your event handler needs to await some asynchronous code. You take all of the right steps and change your method signature to get that beautiful async Task added in, replacing void. But suddenly you get a compile error about your event handler not being compatible. You feel trapped. You're scared. And then you do the unspeakable... You change…
(This article is intended to be a spiritual successor to this previous entry, and now includes Tasks!) Even if you're new to C#, you've probably come across at least one of Tasks, Threads, or BackgroundWorkers. With a bit of additional time, it's likely you've seen all three in your journey. They're all ways to run concurrent code in C# and each has its own set of pros and cons. In this article, we will explore how each one operates at a high level. It's worth noting that in most modern .NET applications and libraries you'll see things converging to Tasks. The Approach I've gone ahead and created a test application that you can find here. Because this is in source control, it's possible/likely that it will diverge from what we see in this article, so I just wanted to offer…
Python is a powerful and versatile programming language that has become increasingly popular. For many, it's one of the very first programming languages they pick up when getting started. Some of the highest traffic posts on my blog many years after they were written look at using C# and Python together. Today we're going to explore how you can use Python from inside a C# .NET Core application with much more modern approaches than my original articles. Enter Pythonnet! Pythonnet Package & Getting Started We're going to be looking at Python for .NET in order to accomplish this goal. This library allows you to take advantage of Python installed on the running machine from within your .NET Core applications. You must configure it to point at the corresponding Python DLL that you'd like to use, and after a couple of…
If you have an internet connection then you have probably heard of ChatGPT from OpenAI by now. Odds are you might have even given it a whirl to see what it's all about. Personally, I know that I was quite skeptical at first but I've been blown away at how well it's able to converse about topics I ask it. I've even asked it to generate various scenarios for me and it will conclude by explaining why the different facets it chose were good choices. Incredible stuff. I'll be using this to help chip away at content for my role playing game. When it comes to using OpenAI effectively, I have a great deal to learn. It's all very new to me, especially with respect to how to structure prompts and get the most out of the interactions with such…
(You can check out the prior week of RPG development here) Well, so far not so great for getting weekly posts on RPG development! It's probably better for me to aim to do these periodically and summarize the last week or so of work. Fewer commitments that way and it's a bit more realistic for me to achieve. With that said, let's dive into it! Entity Filtering in an RPG Our RPG has had some notion of entity filtering for a long time, but to understand the current state of filtering, it's important to understand the two major sets of entities and components we have: Game Objects + Behaviors: Everything in our RPG game world is represented as a "game object" and the properties/capabilities are captured by components called "behaviors" Definitions + Generator Components: The content for our game is…
