22 Month Status Report

Vigil Journey

As I was writing the previous post, it came as a shock how far behind my posts on the progress of the Vigil Donor Relationship Management System had gotten. I was going too deep into the code and making too many changes that I didn’t pause to write a post about my progress. My posts are 22 commits behind, and there are quite a few changes I’ve made to the workflow and to the application. As a way to catch up on all the missed posts that I should have written, I am putting this one together as a status report of the project/journey/solution.

In terms of workflow, I have embraced the GitHub Flow workflow (both for Vigil and for this blog). For my little project, since there is no discussion and no deployments (as of yet), the workflow is as simple as Branch, Commit(s), Pull, Merge, Delete. I like the way that a merge can squash all of the commits made on a branch, so that I have one summarized collection of everything that I did. This way, I can easily differentiate the content of a post by doing one per Pull Request / Merge. Hopefully, this process will now keep the posts coming regularly, help me be more concise about what should be in a post, and better contain runaway developing.

Introducing Vigil Web API

Vigil Journey

Thus far in the series, the Vigil Journey project has been able to create a patron, update a patron, and have those redefined as “a patron can be created and updated”. However, as acknowledged in those posts, this was all smoke and mirrors. Nothing was being persisted, and once the unit tests were run, there was no lasting effect of the code. All of the tests passed and there were lots of pretty green check marks, but no residual digital substance. Additionally, there was no application that could be left running with which someone could interact.

Illusions of Queues and Buses

Vigil Journey

There are many solutions on the market (including free open source) for creating both message queues and event buses. However, for example purposes - and as a simple proof of concept - I just wanted a simple way to store the contents of a Command, run the CommandHandler, receive Event objects, call the EventHandler actions, and save all of the results. Everything runs synchronously and there are no retry policies, topics, or request/reply patterns. It is a simple, nearly useless set of code - but it serves its very specific purpose.

Hydrating A Patron

Vigil Journey

There are two ways to retrieve the current values associated with an entity. The canonical source is the collection of events that describe how an entity came into existance and then was affected over time. The standard term for this seems to be “hydrating” the entity. Once the current state of the entity is found, it can then be persisted to a different medium for easier access. In the example of a Patron, there are few circumstances where the entire history of the entity is needed. Instead, most requests for the information will only be looking for the most current iteration - which is found in a snapshot database. One of the first challenges that I faced when building this initial prototype was proving that my code could rehydrate a Patron from only a list of events.

My 2017 Running Calendar

Exactly One Hobby

2016 was a busy year - in total, I ran eight races. While four of them were all in one weekend for Disney’s Dopey Challenge, it was still a lot of early mornings for me. For 2017, I am going to scale things back a bit - which really just means removing the one racing weekend.

Mock Controller's User and Url Properties in ASP.NET Core MVC

Vigil Journey

I have come to the point where I am building out the initial proof-of-concept for the WebAPI portion of this project. This gives me a place to continue testing out features, and see if how I envisioned things would work can actually work. One of the first parts of unit testing the controller was to mock any of the properties that I need to use that the web server would ordinarily wire up. In a Controller that primarily entails the ControllerContext, which would also wire the Controller.User, Controller.Url, and Controller.HttpContext properties. So how do I do that?