September 21

gRPC + .NET: Lessons from the Trenches Retrospective

Now that I've had a chance to slow down a bit let's do some creative writing. Let's talk about the "gRPC + .NET: Lessons from the Trenches" talk I gave at the North Houston .NET User Group. As I said previously, the talk was received well and I was really happy about that.

The inspiration or the idea to talk about gRPC came from the work I was doing at a large oil & gas company located in the Energy Corridor in Houston, Texas. My stint on the project lasted about 20 months.

This was actually the 3rd time I've given the talk. The first time was for an internal BJSS event in April of 2024. The second was at the Houston .NET User Group back in June 2024. The neat thing about taking a talk from scratch all the way through several iterations is how the presentation "feels". You should find potholes as you go and make notes to double back to correct and/or add to them.

The intent with the talk was to answer the following questions:

  • What is gRPC?
  • Can you give some evidence that shows that gRPC out-performs REST API?
  • Have you ever used gRPC on a real project?
  • What were some of the issues/problems you encountered and how did you work around them?
  • When should you use gRPC?
  • When should you NOT use gRPC?

I feel like when I got to the 3rd iteration of the talk I was answering all those questions completely and coherently. Including the benchmarks in this version of the talk was a good addition and I'll credit Daniel Wright, Principal Technologist @ BJSS Houston with the idea for that one.

I was surprised that the audience this time around had more experience with gRPC than I was expecting. This lead to alot of good questions and some leading questions that came up right before I answered them on the next slide. The talk started to take on more of a conversation kind of feel than a lecture.

While I did have fun putting this talk together and giving it, I don't think I'm going to hang up my developers hat yet. I'm sure there is still a project out there that needs my help! Now it's time to find another topic to talk about and then probably re-do the circuit next year.

Category: .NET, BJSS, C#, gRPC | Comments Off on gRPC + .NET: Lessons from the Trenches Retrospective
September 20

gRPC + .NET: Lessons from the Trenches Powerpoint Slide Deck

Hey! If you were one of the people who came out to the September 2024 North Houston .NET User Group meeting tonight...thank you! You all were a great audience and I loved the interaction.

As promised, here is a copy of my Powerpoint slide deck (gRPC + .NET: Lessons From the Trenches). Feel free to ask questions if you still have any.

Have a suggestion for another talk I should do? Let me know and if there is enough there I can put one together.

Category: .NET, ASP.NET, ASP.NET Core, C#, gRPC | Comments Off on gRPC + .NET: Lessons from the Trenches Powerpoint Slide Deck
September 11

How to Host a gRPC Service With an Azure App Service (as of 9/10/2024 anyway…)

I'm giving a talk on gRPC next week and I wanted to add more content around some gRPC benchmarks. The recent work I was doing for a client with gRPC was hosted in containers and hosted in AWS. This worked well and we had minimal issues once we got it up and running. For the benchmarks I'm looking to run, I just needed to host the gRPC service in an Azure App Service. Now that I found the correct documentation, this is a piece of cake and I'd like to point it out to anybody else who might be looking for this information in the future.

This is the documentation for deploying a gRPC app on an Azure App Service:

I can confirm that this will also work for .NET 8. It was not working for .NET 9 as of 9/11/2024. I'd expect that to get fixed in the near future.

Category: .NET, ASP.NET, ASP.NET Core, Azure, C#, gRPC | Comments Off on How to Host a gRPC Service With an Azure App Service (as of 9/10/2024 anyway…)
April 26

Another Update to My High Score

I have a job change coming up and I thought it would be a good idea to do an update to New High Score (update)! and New High Score! posts. Since those 2 posts I've had a couple work items that required updates to that monster class. Here is what the metrics look like now.

Maintainability IndexCyclomatic ComplexityDepth of InheritanceClass CouplingLines of Source Code
5094872102660516
Code metrics covering the class in aggregate.
Maintainability IndexCyclomatic ComplexityDepth of InheritanceClass CouplingLines of Source Code
512237822
0215481180
0284221237
Code metrics covering the 3 longest methods in the class.

I'm a big believer in leaving a code base better than you found it. I had a couple work items that required me to go in and refactor this monster class a bit. As a developer I feel a lot more comfortable making these kinds of changes (i.e. Strangler Fig design pattern) when I have the proper tools such as JetBrains ReSharper. The payoff for this change was that it allowed me to write unit tests to cover the part of the class that I needed to complete the work items. When you have a code base that is this convoluted, it's nice to have a series of unit tests to proof that the changes you made to the code base work. This came in handy in a discussion with a QA guy. I was able to walk him through each one of the tests I had written. Turns out the issue was in a basic understanding of the work item the way it was written. However, my code worked correctly in the end and I could prove it.

I wasn't the only one working on this code. There were at least 2 or 3 teams making changes to this code.

Category: .NET, C#, Design Patterns | Comments Off on Another Update to My High Score
August 13

What Is Your Philosophy on Unit Testing?

The purpose behind unit testing is to help ensure the code you have written performs as expected. The running of unit tests can be more effective when it is automated on a developers machine and as part of your CI/CD pipeline. Automated unit tests can also take the load off of limited QA resources by letting them focus on higher level testing (i.e. integration testing, regression testing, and acceptance testing).

Nowadays, when I'm handed a new code base to work on, I treat it as suspect. I have no idea if the code base will even run. If it does run, how do I know that it runs correctly? Unit tests will help me determine what shape the code base is in.

In general, I follow the red-green-refactor approach when writing unit tests. I write my tests in this order typically:

  1. Cover the happy paths through the code you are testing.
  2. Cover the upper and lower ends of inputs to your code.
  3. Cover any know edge cases known at the time.
  4. As a follow on to this process, if and when bugs are reported against code that I'm maintaining, I can then write a unit test to reproduce the bug and it will also tell me when it is fixed satisfactorily.

What unit testing framework do you like the best and why?


xUnit.net hands down. xUnit.net requires fewer attributes to set your tests up (i.e. Fact and Theory). Another feature I think is neat is using a class's constructor (w/o any attributes) as a setup method for your unit tests. This is great because it follows the way classes work naturally.

What other unit testing frameworks have you used?


I have used NUnit and Visual Studio Unit Testing Framework (aka MSTest). I prefer NUnit to MSTest though.

What is the right amount of code coverage?


If I have to give a number, I would say between 70% and 80%. I would have a higher number for code that is heavily used and relied upon by other parts of the solution.

How would you go about writing unit tests?


I like using TDD on more complicated/intricate code because it let's you work your way through the code step by step. I prefer a Given-When-Then (GWT) approach over Arrange-Act-Assert (AAA). The GWT approach allows you to write more human-readable unit tests. The AAA approach works, but is not as easily readable. In general, writing clear and understandable code is the goal. Here are a couple links that talk about GWT vs AAA:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

John Woods

What other tools can be used to improve unit tests?

What are some pitfalls of unit testing?

  • Testing the wrong thing - Software development teams need to make sure they are writing unit tests to cover code that they have written.
  • Getting lost in setup hell - This occurs when the setup for your unit tests starts to become tedious and takes a lot of time to get right. Using a GWT style seems to help with this.
  • "I'll just comment out this unit test to get things working so I can check in my changes." - I think this is just developers being lazy and apathetic about the changes being made to the solution. It is not a behavior I would encourage on my software development team.

So that's my current philosophy on unit testing. What do you think? Am I wrong? Did I miss something? Feel free to post a comment or send me an email.

Thanks to Risa for the good question!

Category: .NET, C#, interview questions, unit testing | Comments Off on What Is Your Philosophy on Unit Testing?
August 7

Task From A Code Test

Earlier this week I took a coding test and the first task in the test was interesting and alittle fun to complete. At the start you are given a text file with integers (one per line) that are used as an input into another process. This process has been failing because of problems with the input file. You are tasked with writing a program to validate the input files and output any errors to a separate file for use in troubleshooting. The task is to validate the file according to a set of rules.

The rules are as follows:
1.Verify that all integers in the file fall between 1 and N where N is the total number of lines in the text file.
2.Verify that all integers between 1 and N exist in the file (So if the file contains 3 lines, they should be 1, 2, and 3 in any order).
3.Output any errors to another file.

Rather than use a bunch of loops directly to iterate through the lines, I opted for a LINQ approach. Having done LINQ for so long, that approach usually looks better to me than writing the loops directly. The code is on GitHub and is available by clicking here.

Category: C#, LINQ | Comments Off on Task From A Code Test
August 3

Registering Types With the SimpleIoC Container

I've been kicking the tires on the Command Query Seperation principle/pattern lately. I've been using the CQS-Sample as a starting point. So far, the approach to breaking things down into Commands and Queries is pretty slick and much easier to unit test. The interfaces are used for dependency injection with an IoC container like SimpleIoC (which comes with MVVMLight). If you have done any work with IoC containers, you'll know that you need to register your types with the container either explicitly or through some kind of convention. With a few classes it's easy to just bang out the few lines of code you need to do it. In this case, the number of commands and queries is growing and having to explicitly register each one is becoming monotonous. So how to I register my queries and commands without having to write any code to explicitly register my types?

Assumptions:

  1. We are working with MVVMLight and SimpleIoC.
  2. For any query or command processor interface there is exactly 1 implementation of it.
  3. All queries are marked with an IQuery interface.
  4. All commands are marked with an ICommand interface (not to be confused with the System.Windows.Input.ICommand).
  5. All command processors implement ICommandProcessor<TCommand> where TCommand is a class that inherits from ICommand.

Step 1: Get an instance of MethodInfo for SimpleIoC's Register<TInterface, TClass>() method.

Normally, getting the MethodInfo for a method you'd like to invoke is more straight forward. This method has 8 overloads so some LINQ was needed to get the correct one.

var registerMethodInfo = SimpleIoc.Default.GetType().GetMethods()
.Where(m => m.Name == "Register")
.Select(m => new
{
Method = m,
Params = m.GetParameters(),
Args = m.GetGenericArguments()
})
.Where(x => x.Params.Length == 0)
.Where(x => x.Args.Length == 2)
.Select(x => x.Method)
.First();

Step 2: Get a list of all types in the current AppDomain.

This step is pretty straightforward. Notice the .ToList() call at the end of method chain. This is to make sure that when we use types in the following steps, we won't be enumerating the IEnumerable of types more than once.

var types = AppDomain.CurrentDomain.GetAssemblies().SelectMany(a => a.GetTypes()).ToList();

Step 3: Get all query interfaces that inherit from IQuery.

var queryInterfaces = from t in types
where t != typeof (IQuery)
where t.IsInterface
where typeof (IQuery).IsAssignableFrom(t)
select t;

Step 4: Create a query implementation class to query interface mapping

This step creates the query interface to query type mapping. The result is projected into an anonymous type that will be easy to use in the next step.

var queryMappings = from queryInterface in queryInterfaces
from t in types
where t.GetInterface(queryInterface.Name) == queryInterface
select new {queryInterface, Query = t};

Step 5: Register the query types

This is the last bit of reflection needed to register the queries. This code iterates of the query mappings from the previous step, gets a generic MethodInfo using the interface and implementation, and then invokes it on the current SimpleIoC instance.

foreach (var queryMapping in queryMappings)
{
var genericRegisterMethodInfo = registerMethodInfo.MakeGenericMethod(queryMapping.queryInterface, queryMapping.Query);
genericRegisterMethodInfo.Invoke(SimpleIoc.Default, null);
}

Step 6: Get a list of classes that inherit from ICommand.

var commands = from t in types
where t != typeof (ICommand)
where typeof (ICommand).IsAssignableFrom(t)
select t;

Step 7: Make the ICommandProcessor<T> interfaces.

This is an interesting step in the process. The command processors do not have a common non-generic interface, so we'll have to make the generic type of ICommandProcessor<TCommand>.

 

var commandProcessorInterfaces = from command in commands
select new {CommandProcessorInterface = typeof (ICommandProcessor<>).MakeGenericType(command)};

Step 8: Map ICommandProcessor<T> interfaces to ICommandProcessor<T> implementations

Now we'll create the mapping between the ICommandProcessor<TCommand>s and their implementations.

var commandProcessorMappings = from commandProcessorInterface in commandProcessorInterfaces
from t in types
where t.GetInterface(commandProcessorInterface.CommandProcessorInterface.Name) == commandProcessorInterface.CommandProcessorInterface
select new {commandProcessorInterface.CommandProcessorInterface, CommandProcessor = t};

Step 9: Register the command processor types

Same thing as step 5. Just iterating over the command mappings to make the generic MethodInfos and then invoking them on the current SimpleIoC instance.

foreach (var commandProcessorMapping in commandProcessorMappings)
{
var genericRegisterMethodInfo = registerMethodInfo.MakeGenericMethod(commandProcessorMapping.CommandProcessorInterface, commandProcessorMapping.CommandProcessor);
genericRegisterMethodInfo.Invoke(SimpleIoc.Default, null);
}

And that's how I register all my command processors and queries through reflection. LINQ and Reflection FTW!

Are there better approaches? Sure. Are there better IoC containers out there? You betcha. But, this approach is Good Enough™ for now.

Category: C#, LINQ | Comments Off on Registering Types With the SimpleIoC Container
August 1

How to Detect Concurrent Events Using LINQ and Reactive Extensions

Here's the scenario...

I have 3 referees around a powerlifting platform. Each has a set of 4 switches in their hand that is used to indicate if they thought a lift was good or not. One switch indicates the lift was good and the other 3 indicate the lift was no good and the general reason why. A referee's light box displays the result by turning lights on and off. The individual lights should only turn on when all 3 referees have pushed their buttons. How do I determine when all 3 referees have pushed their buttons?

To get started, we need to create a simple event to indicate a referees decision.
public class RefereeDecisionEvent
{
public DateTimeOffset Timestamp { get; set; }
public DecisionCode Decision { get; set; }
}

The Decision property will hold a referee's decision represented as a DecisionCode enumeration.

public enum DecisionCode
{
White = 0,
Red = 1,
Blue = 2,
Yellow = 4
}

White indicates the referee decided it was a good lift. Red, Blue, and Yellow represent potential reasons why the referee decided the lift was no good.

We'll also need 3 event sources. Each event source represents a different referee; left, center, right. The actual implementation of the sources is outside the scope of this blog post. That said, I'll just generate some events for each source at different intervals to give us some simple test data.

Step 1 is to join the left source's events with the right source's events. Since the left and right event sources create new events at different intervals, the events will most likely not occur at exactly the same time. We can fix this by increasing the duration of both sequences of events by 3 seconds. Now, we are joining the events from the left and the right sources when they occur within 3 seconds of each other.

var step1 = leftSource.Join(rightSource,
l => Observable.Interval(TimeSpan.FromSeconds(3)),
r => Observable.Interval(TimeSpan.FromSeconds(3)),
(l, r) => new {Left = l, Right = r});

Step 2 is to join the center source's events with the now joined left and right side events. We'll extend the durations of the events 3 seconds so that we can get a combined event that shows the left, center, and right events that all occurred withing 3 seconds of each other.

var step2 = centerSource.Join(step1,
l => Observable.Interval(TimeSpan.FromSeconds(3)),
r => Observable.Interval(TimeSpan.FromSeconds(3)),
(l, r) => new {r.Left, Center = l, r.Right});

In Step 3, we'll project the results of step 2 into an event that is better laid out for our purposes. That Observable can then be subscribed to by an Observer that handles turning the lights on and off.

var step3 = from e in step2
select new
{
e.Left,
e.Center,
e.Right,
Status = new[] {e.Left.Decision, e.Center.Decision, e.Right.Decision}.Count(x => x == DecisionCode.White) >= 2 ? "Good" : "Bad"
};

And that's how it's done.

Category: C#, Reactive Extensions | Comments Off on How to Detect Concurrent Events Using LINQ and Reactive Extensions
July 27

Simplifying Switches Using Dictionaries

Have you ever had to write a long series of if/then statements or a giant switch statement that extends for a page or two of your code? Want an easy way to increase the readability of your code, increase it's maintainability index, and decrease it's cyclomatic complexity? Let's see an example problem and then a possible solution.

Let's start off by considering the following array of anonymous types:

var items = new[]
{
    new {Operation = Operation.Add, Value1 = 1, Value2 = 2},
    new {Operation = Operation.Subtract, Value1 = 4, Value2 = 3},
    new {Operation = Operation.Multiply, Value1 = 5, Value2 = 6},
    new {Operation = Operation.Divide, Value1 = 8, Value2 = 4},
    new {Operation = Operation.Add, Value1 = 9, Value2 = 10},
    new {Operation = Operation.Subtract, Value1 = 12, Value2 = 11},
    new {Operation = Operation.Multiply, Value1 = 13, Value2 = 14},
    new {Operation = Operation.Divide, Value1 = 16, Value2 = 4},
    new {Operation = Operation.Add, Value1 = 17, Value2 = 18},
    new {Operation = Operation.Subtract, Value1 = 6, Value2 = 3},
    new {Operation = Operation.Multiply, Value1 = 8, Value2 = 8},
    new {Operation = Operation.Divide, Value1 = 10, Value2 = 2}
};

I need to iterate over this array and execute the given Operation on Value1 and Value2 properties to produce a list of results A brute force method of doing this is as follows:

var results = new List<int>();
 
foreach (var item in items)
{
    switch (item.Operation)
    {
        case Operation.Add:
            results.Add(item.Value1 + item.Value2);
            break;
        case Operation.Subtract:
            results.Add(item.Value1 - item.Value2);
            break;
        case Operation.Multiply:
            results.Add(item.Value1*item.Value2);
            break;
        case Operation.Divide:
            results.Add(item.Value1/item.Value2);
            break;
        default:
            throw new ArgumentOutOfRangeException();
    }
}

The switch statement is pretty straightforward and simple to implement in this example. Visual Studio 2013 Code Analysis is giving the code a maintainability index of 54 and a cyclomatic complexity of 6. What if I needed more lines of code to handle each operation? This could turn into a mess to test, debug, and maintain.

A possible solution to this problem is to replace your switch with a dictionary. I realize that seems odd to replace a control statement with a data structure, but refactoring to this approach will simplify your code. In our example, each item in the array has an Operation to be performed on the Value1 and Value2 properties. I can setup my dictionary with the key value being the Operation enumeration, and the value being the Action, Func, or method group that performs the operation.

var operationMethods = new Dictionary<Operation, Func<int, int, int>>
{
    {Operation.Add, Add},
    {Operation.Subtract, Subtract},
    {Operation.Multiply, Multiply},
    {Operation.Divide, Divide}
};

In the example above, I'm using the following methods:

public int Add(int left, int right)
{
    return left + right;
}
 
public int Subtract(int left, int right)
{
    return left - right;
}
 
public int Multiply(int left, int right)
{
    return left*right;
}
 
public int Divide(int left, int right)
{
    return left/right;
}

With the dictionary approach, our code to iterate over the items and execute the individual operations looks like this:

var results = new List<int>();
 
foreach (var item in items)
{
    results.Add(operationMethods[item.Operation].Invoke(item.Value1, item.Value2));
}

VS2013 gives the refactored code a maintainability index of 63 and a cyclomatic complexity of 2. Our code is still doing the same thing as the switch was, but we have broken the code down to simpler pieces that are more readable and more easily to wrap unit tests around.

I find this to be a good approach to take when the "cases" of our switch statement are known up front (such as using an enumeration). If it is possible that you will not have all the cases or keys in the dictionary, you can still use this approach but you will want to handle things more gracefully with the Dictionary's TryGetValue method like so:

Func<int, int, int> operation;
 
if (operationMethods.TryGetValue(item.Operation, out operation))
{
    results.Add(operation(item.Value1, item.Value2));
}
else
{
// TODO: Handle case of the missing case/key
}

To tie it all together, here is a Gist with the code I discussed in this post.

I hope this helps. If you have any questions or comments, please use the comments form below. Thanks.

Category: C# | Comments Off on Simplifying Switches Using Dictionaries