Dave van Herten

2018 Year in Review

Fri, 11 Jan 2019 00:00:00 +0000

As it is customary to do in January, lets look back at 2018. It was a very big year for me. You rarely achieve all the things you hope for in a year, but this year was definitely one to remember.

ZOEY!

First and foremost, in May my wife and I welcomed our first born Zoey into this world. She is an incredible baby and we couldn’t have hoped for more. I love being a father and it has really brought some perspective in my life. You really can’t understand what being a parent will feel like until you are one and you really can’t put it into words for some one who isn’t already a parent.

Event Sourcing!

I had the opportunity to introduce event sourcing at work to solve a multi-directional integration sync between some systems we use. We leveraged SqlStreamStore and it has been working great.

There will be more on this topic later as I re-implement some lessons learned into some demo applications and blog posts.

Javascript/Front-end

I spent a ton more time working with React and Javascript in general as it has been a weak spot for me. To improve I’ve started up a Warhammer 40k Math Calculator to better learn javascript and react. Currently I’m hosting it in an Azure static site.

Mathhammer doesn’t have the best UI as I’m using a drop-in Material library and haven’t spent any time on the mobile experience. I have some ideas for improving it and will implement them as I develop the project further.

Reading!

While I was hoping to hit 12 books for the year, I ended at 9 for the year. Considering I spend a decent amount picking up new things on Pluralsight and Egghead I’m pretty happy with the result as it is much more than I’ve done any other year.

Topics varied all over the place from Introducing Event Storming and DDD Distilled to a 40k novel and of course some baby books.

Summary

There’s a lot I’m leaving out, but the short of it is I’m pretty happy with what I accomplished over the year. Did I want to do more, sure, who doesn’t, but all in all I am pretty happy with the above list.

I’m looking forward to 2019 being a great year as well.

CI/CD with Azure Storage Static Sites

Sun, 09 Sep 2018 00:00:00 +0000

Static web hosting is now a thing in Azure Storage and is pretty easy to setup. There’s a small caveat with the CI/CD solution they’ve provided though.

Getting setup

I’m not going to go into it here because there a perfectly fine tutorial on how to setup the static site initially and also how to take that site and enable a CICD build around it.

This is what I followed and I recommend the same.

The Gotcha

In the CICD process suggested, they use an Upload Batch command. And this does exactly what you expect it to, uploads all of the files. So what could be wrong with that?

Well it’s subtle. Each time you run the build, it’s going to bundle everything up into a neat little JS file and change a little hash number so that if someone goes to your new site, it will pull down the new JS file and avoid caching.

What the default CI/CD process is doing is ignoring that clean up.

The HTML was uploaded to use the right one, so the site will work exactly as you expect and be properly updated. The downside is now you are filling up your storage with useless JS files. This is worse if you are including the mapping files as those are much larger.

Cleaning up

Regards to how I went about it, your mileage may vary. In my case, I was prefectly content to clear out the container before putting the new static site up. I’m not concerned with the type of site I’m making that theoretically someone might get a 404 for an extremely small moment in time.

If that sounds like your scenario, then the following task might work for you:

Put this task between the NPM build and the Upload site tasks in the VSTS build process and it’ll clean out the storage and you’ll only end up uploading your nice and fresh files.

Blog ported and next steps

Wed, 22 Aug 2018 00:00:00 +0000

Seems every time I logged into WordPress I’d have some kind of update to do and I had the bare minimum of plug-ins. Enough is enough.

I’d heard blogs with GitHub pages were pretty easy to setup and really it was! Github has even figured it out to the point that you can enable HTTPS and it works out all the details even when using a custom domain. Solid stuff. If you haven’t looked into it, you should. A lot of folks like D

Upcoming Posts

Comments were not retained during the port and as you can see I’ve moved to Disqus. There were some requests related to updating the Swagger Identity Server posts. I haven’t been playing in that space much lately, but since it seems to be a popular post I may look at updating it to the newest versions of Identity Server, Swagger & Asp.Net Core.

Current interests have me playing more in the front-end with React, Redux, Apollo and GraphQL so I’ll probably hit up some posts in that area.

Big News!

Anyways, thought I’d drop a short post to say I’m still around. Just had a little creature keeping me busy lately! Her name is Zoey and she was born on May 15th! This was taken 10 days later. ;)

It really is amazing how fast they grow! It’s been a little over three months now and she’s apparently super tall for her age, but that shouldn’t be surprising as my wife and I aren’t exactly short. :)

More soon!

Whirlwind of a Month

Sat, 30 Sep 2017 00:00:00 +0000

What a busy month! Taking a break from talking about the DieRoller (which I did put onto NuGet now), but so many other fun things have happened!

In the last 2 weeks I’ve been to 3 Meetups and a conference!

Mississauga .Net User Group

This was a lightning talk event where I was one of the speakers. It was super fun to get up in front of everyone and do a quick talk on using Swagger to make building dev tools for internal use even easier without having to worry about a UI. Very receptive crowd and the other speakers were on point and did great jobs. All in all a great event!

Burlington Php User Group

Not a Php guy, but topics these days are often cross language so I thought I’d check it out because it was held really close to home. I’m really happy I did as I got to meet Chris Hartjes who did a fantastic talk on the realities of trying to push testing into an organization. The talk is available on YouTube here and I recommend checking it out.

Silicon Halton Software Peer to Peer

I’ve been attending the Peer to Peer events put on by Silicon Halton for a few months now and the discussions have always been very informative that come out of it. This month we dove into Docker. None of us were overly familiar with it, albeit very interested in it, so it was a fun exercise to have the room breaking down what we found and saw within the eShopOnContainers example that MS has available.

HamOntJS Conference by Software Hamilton

This conference was an amazing event. It was a mere $20 to go to. I’ll say it again, $20. That’s amazing. The focus of the conference was on Javascript and I learned about some new things I hadn’t come across yet. Most importantly though I really need to start looking at JS more. While I’ve been mostly in .Net for my career so far I like to use the right tool for the job and sometimes JS and what I saw today feels like it might actually fit better in some ways. Definitely need to dig some more and bump the priority on some of these things that were already on my ever growing list of things to learn about.

Summing up

What a great couple of weeks. Participating in these events has been something I am finding I look very forward to each month. I hope to do more speaking in the future and will likely work on some longer topics to build talks around in the coming months. Event Sourcing maybe? It’s been a fantastic growth opportunity for me and everyone I’ve met have been really quality people. If you haven’t gone to a meetup before, I highly recommend checking out if there are some that are local for you. It will invigorate and motivate you! I promise!

Die Roller - Abstracting dependencies on Random

Sun, 27 Aug 2017 00:00:00 +0000

When building the Die Roller, I had two main use cases for it. Determine the probability of a given roll configuration and provide a simulation of the roll with all the information about what took place. When it comes to unit testing, probability calculations are more straight forward. They make sure that the code returns the expected result. Simulations are much more difficult to test because rolling a die is inherently random. Which means of course that you have to abstract the randomness away for the purposes of the tests.

My goals were:

Provide a mechanism to pass the exact numbers to use from tests to validate expected results.
Avoid having to know how many sides a die may have within the random abstraction
Attempt to make it as non-invasive as possible.

I ended up settling on the following interface.

public interface INumberGenerator
{
    int GetNumber();
}

Note how I don’t pass in any sort of condition to drive the number like the number of sides that the die may have. I didn’t want to become needlessly complex in the abstraction where knowledge would need to be passed around. I merely want any single integer number back because that’s what Random is going to do for me. I leave it up to the Die class to handle its concern that involves the number of sides the die has.

public class Die
{
    // ...

    public int Sides { get; }
        
    public SingleRollResult Simulate(INumberGenerator numberGenerator)
    {
        var number = numberGenerator.GetNumber();
        number = Math.Abs(number);

        var remainder = number % Sides;
        return new SingleRollResult(this, remainder == 0 ? Sides : remainder);
    }

    // ...
}

If we were always generating numbers that were less than the total sides of the die we would have a problem, but we have to remember the intent here. At run time we will always be using a random generator interface which will provide a positive integer. This will return lots of really big numbers and the Die class will handle it fine. Remember that our intention is to make testing easier, not make this harder than necessary to work with.

public class RandomNumberGenerator : INumberGenerator
{
    public static Random Random = new Random();
    public int GetNumber()
    {
        return Random.Next();
    }
}

So how do we get our own implementation in the tests? I’ve left this up to the RollBuilder. Yet another benefit of having this fluent creation pattern. Here is an example of the construction from one of the tests. If I leave out the WithNumbers call then it will fall back to the default of random numbers.

var roll = RollBuilder.WithDie(Die.D6)
           .WithNumbers(new ForcedNumberGenerator(initialRoll, reroll))
           .Targeting(Target.ValueAndAbove(targeting))
           .WithReroll(Reroll.Ones)
           .Build();

As you can see I pass the numbers I want directly into it. There is a little bit of internal knowledge that the tester needs to be aware of. The first number will be used by the initial roll. The second number will be used for the reroll. The ForcedNumberGenerator implementation returns the numbers in the order they are passed in so this knowledge is required when building a test. I was okay with this trade-off because in any single die roll that is exactly what happens in life. You make your first roll and you may or not make your second. It feels natural so it should not be overly confusing.

Anyways, that’s my little story about how I abstracted a system dependency on Random. It’s a common enough practice to handle this in some fashion for testing and often also comes up for DateTime.Now as many applications have a dependency on dates.

I’m well on my way with implementing the modifier requirement of the Die Roller (tests first!) which has me wondering what best practices are when it comes to validating and testing complex calculations. I’ll be writing something up about that experience soon. As always you can check out the project as it is coming along over on Github.

Die Roller - Outside In

Sun, 20 Aug 2017 00:00:00 +0000

So I went and did it again. Not too long after writing the last post did I realize I started from an angle I shouldn’t have. Again.

Fluent Syntax

I knew when I started this that I wanted to have a fluent syntax for setting up the roll scenarios. This will allow the user of the library (me) to determine the conditions of constructions more easily without worrying about the underlying dependencies and construction rules. I’ll also be free to leave things internal to make things easier to change later as long as I allow the RollBuilder to continue functioning the same way.

Essentially something like this:

var roll = new RollBuilder(DetermineDie())
               .Targeting(GetTarget())
               .WithRerolls(GetRerolls())
               .WithModifier(GetModifier())
               .Build();

Essentially it allows the consumer to build mechanisms around the components of a roll. The GetTarget() or GetRerolls() will likely be based on some kind of ruleset and I believe the fluent syntax caters well to how that would work.

So great. I knew I wanted to do a fluent syntax so why didn’t I start here? Good question. I had intended to, but for one reason or another I started on the implementation of a Roll first when I should have been thinking about how it was going to be used. Which brought me to the tests and a much more TDD approach.

The Tests

So I started by re-writing the tests. Here’s what the body of a simple test looked like with no reroll and no modifier.

Before:

var die = new D6Die();
var expectedProb = (7 - requiredRollOrHigher) / 6m;
var roll = new Roll(die, requiredRollOrHigher);
_output.WriteLine($"Probability: {roll.Probability}");
roll.Probability.Should().Be(expectedProb);

After:

var roll = RollBuilder.WithDie(Die.D6)
    .Targeting(Target.ValueAndAbove(valueAndAboveTarget))
    .Build();

// Calc - SuccessfulSideCount / Sides
var expectedProbability = (7 - valueAndAboveTarget) / 6m;
CheckProbability(roll, expectedProbability);

The initial test would break if I changed aspects of the constructor or other Roll concerns. There was no abstraction from the construction process and it required understanding the inner workings of the classes more than I liked. The test as it is now will only change if I actually change something about the public interface of the builder or the method to calculate the probability. As I plan to treat this as an API on Nuget with Semantic Versioning, I want to be aware of when I break the public interface. I do not expect as much churn on the builder side of things so the fluent syntax isn’t just nice to work with, it also serves as a separation from how the classes work. So it makes perfect sense for why the unit tests would want to be written the same way as the consumer would be using it.

Validation of Feelings

Gregory Brown tweeted this out a few days ago and it really hit home on why this worked out for me. OUTSIDE-IN!

Outside-in thinking and an emphasis on avoiding incidental damage to systems is the main takeaway from #TDD. Automated testing isn't. — Gregory Brown (@practicingdev) August 16, 2017

This change was because I was thinking about my API from the outside. How I wanted to use my API was driving the decisions around the public API as it should. By knowing how I wanted to use the library it made filling in the implementation much easier. It also feels more domain driven since it matches what you would be thinking in 40k.

I’m making a hit roll. I have to hit on a 3+, I get to reroll my ones, and then I’ll apply the -1 to hit because my enemy is in stealth

Props to Gregory Brown for putting what I was feeling so succinctly into words.

Moving on

I’ll likely post next about an abstraction that was necessary when it came to testing the roll simulations. That’ll give me some time to figure out how roll modifiers will work. Here goes!

Die Roller - Starting off on the wrong foot

Wed, 26 Jul 2017 00:00:00 +0000

So as I alluded to in the first post, I wasn’t happy with the tiny bit of code that I had done so far. I literally had one class and one test just to get some probability calculations going. But there were two things that I didn’t like.

Problem #1: It was wrong

You’ve probably heard it a million times. Don’t write your test after your implementation or you’ll just end up writing a passing test for a failing implementation. Yep. That’s exactly what I did. The test simply used the same calculation I used in the implementation to vet the calculation was correct. But of course it wasn’t.

That test wasn’t supposed to serve much of a purpose initially, but I knew I was going to be changing this code to be a little more involved and wanted the backing test. However, I totally had the calculation backwards.

So word to the wise, write your test first, ensure it is actually validating what you want it to, and then implemented it. A face palm moment for sure.

For the curious, here’s the commit.

Problem #2: Wrong responsibilities

The moment I had finished writing the first Die class I realized I’d goofed. There were two responsibilities in the 6-sided die class. One was the fact that the class was intended to be a representation of a THING. A die and a die does not have a probability on its own.

What I had introduced was a second consideration of a scenario. Passing in the desired roll to calculate probability shouldn’t have been a responsibility of a die. So as a first order of business I’ve gone and addressed that by shifting some of the code around. The main change I made was introduced the concept of a scenario and called it a Roll. When you Roll a Die, you have a desired result in mind. We’ll see if that sticks.

I knew I was going to have at least two types of dice for my situation (D3/D6) so I went ahead and created an abstraction for it. I hummed and hawed a little bit over interface vs abstract class, but as I didn’t have any base behaviour I decided to move ahead as an interface. Easy enough to change later.

Summary

So as you can tell, I’ve already made some bumps along the way. That’s totally normal. The only difference here is that I’m telling the world about it. This all took place in a very short amount of time. Thinking about how I was going to write this up and then actually writing it was considerably longer, but it was fun to do and a good exercise for documenting my thought process.

More soon!

Die Roller – A Github Nuget Experiment

Wed, 12 Jul 2017 00:00:00 +0000

So a few friends of mine recently decided to take up collecting and playing the table-top miniature game Warhammer 40k. I collected a bunch of this stuff when I was a kid and I’m excited to finally have a reason to unpack it from storage and give it another go. Why is this relevant to a development blog? Simply because I now have a reason to make a small little library that would be useful for doing some number crunching related to the die rolls that take place in the game.

Enter DieRoller

I’ve been looking for an excuse to make something open source and push it to Nuget. Having a simple generic dice rolling library would be a perfect trial run. It gets my feet wet in the building, packing, and pushing process using GitHub and NuGet so it’s a win on both those fronts. If I happen to take it farther and actually utilize it in an app then bonus, but this is more of a learning experience.

Throughout the process I’ll document my thinking around the implementations of the various required features. I’m certain I’ll end up changing my mind a bunch and refactoring as I go. Who knows how usable it will be when we are done, but it should be a fun journey.

Requirements?

I threw together some basic requirements around what this little library would need to do. The Die Roller library should:

For a given roll, provide the probability and a simulation of the roll.
- Consider D6 and D3 as those are the main things used in 40k even though 40k references will not be present in this library specifically.
Apply options to the roll such as re-rolling fails or just ones. You can only re-roll once.
- This is an influenced rule from 40k. It is common to be able to re-roll any failed roll or just the ones.
Apply a modifier to the roll such as +1 or -1.
By default a roll modifier would come AFTER a re-roll, but ideally this would have an ability to toggle
Simulation should provide a roll result of exactly what happened.
- Rolled 5 dice targeting a 3+
- Roll results 3, 5, 2, 1, 6. Re-rolling 2 & 1. Reroll was 2 & 4.
- Modifier applied of +1.
- Final result is 4, 6, 3, 5, 7 meaning all 5 pass the requirement of 3+.

Follow along

If you actually care to I have pushed the first commit up to GitHub here so you can track the progress as we go along. The first commit has almost nothing in it and it already has something I’d like to change in it. I wasn’t kidding when I said I’d probably change my mind a bunch. I’ll write more about that shortly.

Away we go!

Dev Talks at Work

Mon, 26 Jun 2017 00:00:00 +0000

Steve Smith blogged a while back about how one of the best times to teach something is while you are learning the topic or right after. You will still remember the steps it took to reach your conclusions and the hardships you found along the way. These are important for those who are also learning and easily forgotten when you’ve been involved in the subject matter for a while. I don’t plan to re-blog his blog, but rather share an experience.

In recent months I have been giving user group style talks at work to share things that I have been learning. I’ve been using the Lunch & Learn style format as to not take too much away from our work day. The first I did was a brief talk to just go over the Solid Principles, but relating it to code we had been writing. Where we were practicing them well and where we could use them to better structure our code. Most of this wasn’t news for people, but it was nice to put a spotlight on some areas and it sparked some good conversation around improving the code.

The second one I did this month was on the topic of Swagger and Identity Server. I essentially took my recent blog posts and put it into Demo form. The demo took about 30 min to run through all the steps I had in the blog posts and then I finished with demonstrating how Swagger could make for a mini-UI for an internal tool for developers that we later could throw a real UI around if we cared enough to. This topic also sparked conversation around where we could leverage the API docs that Swagger could generate for us. It was a good session even though I have only scratched the surface on Swagger.

Practice

Speaking well takes practice and it is something I’d like to learn to do better. This is one of the reasons I’ve decided to do these internal talks at work. I also have been regularly attending a .NET User group near me and hope to do a short talk there in the near future so this practice is valuable to me. The talk I’m planning for that group is the Swagger one I mentioned above so having a dry run at work to test length of the talk with a group and get a sense for the value people got from it helped me get perspective for how I’d change it up for the User Group version. I definitely have to shorten it up as I went into much more detail at work.

Just Do It!

People like to learn and I find it helps to do it in a setting people can ask clarifying questions. Sometimes you’ll know the answer, other times you wont. That’s OK! The things you don’t know the answer to provides potential topics for more learning! Embrace it.

Final Note

Don’t go off and organize this without getting some approval first. Get the OK from your boss as you will be sapping some time away from those that attend if you end up going a little longer. If your topics are on point with sharing knowledge around the direction your boss wants the team to start heading then I doubt you’ll run into problems. I’d lean more towards they’ll appreciate the initiative.

Configuring Swagger to handle MediatR Commands and Queries

Mon, 27 Mar 2017 00:00:00 +0000

If you are following Jimmy Bogard’s style of MediatR commands and queries that he did within his Contoso University example you’ll find that Swagger does not play nice by default with that type of class nesting.

Snippet Example:

Thankfully there is a solution!

Lets say I have two commands. One called DeleteAllTheThings.cs and another called DeleteAllTheOtherThings.cs and both have a nested class called Command. By default Swagger will start to complain with an error about duplicate schema ids because it is only looking at the Command class of which there are now two. We need something a little more robust than that in how we generate a name. Thankfully when registering Swagger in the Startup.cs we can add an option to customize how Schema Ids get generated.

This bit of code is simply using the full name of the type instead and gluing the wrapping class type name with the nested Command or Query. The result is you get a nicely named class in your documentation too!

Dave van Herten

2018 Year in Review

ZOEY!

Event Sourcing!

Javascript/Front-end

Reading!

Summary

CI/CD with Azure Storage Static Sites

Getting setup

The Gotcha

Cleaning up

Blog ported and next steps

Upcoming Posts

Big News!

Whirlwind of a Month

Mississauga .Net User Group

Burlington Php User Group

Silicon Halton Software Peer to Peer

HamOntJS Conference by Software Hamilton

Summing up

Die Roller - Abstracting dependencies on Random

Die Roller - Outside In

Fluent Syntax

The Tests

Validation of Feelings

Moving on

Die Roller - Starting off on the wrong foot

Problem #1: It was wrong

Problem #2: Wrong responsibilities

Summary

Die Roller – A Github Nuget Experiment

Enter DieRoller

Requirements?

Follow along

Dev Talks at Work

Sharing Knowledge

Practice

Just Do It!

Final Note

Configuring Swagger to handle MediatR Commands and Queries