Commit 8c41b3dc: Vigil Base Solution

I’ve finally done it; I finally ripped, twisted, and otherwise cajoled the default MVC template, Identity code, and a few other tweaks I wanted to make into something I am semi-confident will be a good starting point for future projects. Which is really to say – I’m at a stopping point and I’ll probably burn it all to the ground, tomorrow.

The Best Things In Life Are Passed Tests

Sometimes the best things is life are Passed Tests.

Sometimes, the best thing that can happen in my day is that all of the unit tests pass. Not just once, due to some odd coincidence with timing, but because they actually, legitimately pass. I am sure that veterans of Test Driven Development will scoff at a lot of these tests. However, it was fun to learn how to use xUnit and Moq. Previously, I had been determined that I was going to be able to write my tests without using external libraries. I was just going to extend the different classes that depend on external resources and change them all to work in memory. This was stupid, time consuming, and generally fraught with errors. My tipping point was when I realized I was writing tests for these Test classes. How awful is that?

I chose xUnit and Moq because they seemed to be the most popular. The primary difficulty that I have with mocking at this point are extension methods. Since I cannot mock a non-virtual member, mocking the extension classes is impossible. Thus, I need to find the source code, figure out exactly what the extension method is doing, and properly mock whatever method is used internally. It was a frustrating set of investigations, but I did enjoy digging into the internals of Identity and Katana.

Tests that Cover Code

MoveNext() – it is my new nemesis

It feels like half of my tests are in place just to improve my Code Coverage percentages. Even with that, there are two sticking points that I am having trouble getting over. The first are some the set portion of automatic properties in my Identity and TypeBase abstract classes. I have searched high and low and cannot find a solution to this. I am hoping that as I inherit from these classes, tests on those new classes will happen to start covering these properties.

The second part is managing to get the MoveNext() method to register as covered. It’s a pain to get Code Coverage with Async Await, but Dwayne Need’s blog post was very informative. It will be a while before I worry about getting that in depth with the code coverage that I will need to put all this work together for what amounts to no (seemingly) real gain.

Another Screenshot for Code Analysis

Another “close enough” was going over Code Analysis. Most issues that the utility would flag were ones that I was able to fix. Rules like “CA1063 Implement IDisposable correctly” and “CA2000 Dispose object before losing scope” are easy to correct. The two rules that I completely turned off were “CA1056 URI properties should not be strings” and “CA1062 Validate arguments of public methods”. The former, because it was a monumental pain to convert everything in my code to URIs, but return them back to strings when sending them to different frameworks; the later, because it did not account for Code Contracts.

The final block of rules that I am ignoring for now are “CA1020 Avoid namespaces with few types” and “CA1704 Identifiers should be spelled correctly”. CA1020 is a valid notice, but the project is still in its infancy and namespaces are going to be sparce. CA1704 is flagging the words “Owin” and “POST”, even though both of them are in my CustomDictionary.xml file, located in each project. I’m sure I’ll stumble on a fix for this at some point.

Code Coverage is down to only missing the .MoveNext() method calls.

Code Analysis is reduced to just “POST” and “Owin” identifier issues and Avoid namespaces with few types.

All tests are passing. Stamping this as the first official branch.
Commit 8c41b3dc782066e2c03d51633dc7e65e3df3d924

Tagged , , , ,

Commit 69a7825e: Letting Users Get Ahead of Me

Small Epiphany

In the quest to get to a Minimum Viable Product, I wanted to be able to wrap together a set of projects that would act as a complete framework for future projects. Every (nearly every) project requires users and a way for them to register and login. I had already tied myself to the IdentityDbContext for user and role management. Initially, I had my base context (VigilContext) inherit from IdentityDbContext. I had trouble coming to grips with having every project then required to bring in the Microsoft.AspNet.Identity.EntityFramework assembly. As I was explaining a completely unrelated problem to a coworker, it dawned on me that the whole point of Bounded Contexts was to have multiple contexts, and limit them to only a narrow scope. VigilContext was not going to be used everywhere; its purpose is for database initialization and future migrations.

Enter the ‘Vigil’ Solution

This is a terrible idea, and I am probably going to regret it later, but I do not have a better way to organize everything just yet. I started a new Solution that will be all-encompassing, containing all of the projects, neatly organized into Solution Folders. This will get unwieldy, eventually, but for now I know that everything compiles, all tests pass, and code analysis returns acceptable results. Creating new solutions down the line for specific sets of projects should be rather trivial.

Vigil Identity

The primary usage that requires a class that inherits from IdentityDbContext is to use the rest of the Identity library and the OWIN authentication, including the RoleStore, UserStore, SignInManager. Therefore, a new project, created with the same naming pattern in the based modeling project, has a context that inherits from IdentityDbContext and all of the customized classes that inherit from the Identiy and Owin generics. The most common way of managing users is through a web application. Which means that any ancillary projects that do not actually manage users will be able to have bounded contexts that do not include the Identity assembly.

Got Ahead of Myself – Vigil.Web

I was so excited about being able to add and edit users that I jumped ahead and created a new web project utilizing the Owin context. What a terrible mistake that was. I spent too much time focused on converting the default template to utilize all of my Vigil classes, and then suddenly stressed over not having tests for this new web project. Then I got myself buried under needing to figure out how to mock a Role Store, User Manager, and User Store in memory; and then how to start a whole test Owin context; which lead to attempting to create a mock Owin server; which lead to despair and two months since my last post.

Paying Down Debt

Like missing a payment on a credit card, I need to get this debit under control right away. I cannot just make the minimum payment and figure out later how to pay off the balance and exploding interest. I am going to target just the unit testing surrounding the Identity Model project. Much of this will come from looking at the source code for the Identity Framework, and learning a lot from that.
That is my update – not much to say except for reminding myself to post more often, and make a meaningful, complete contribution to the project before spinning out of control.

Moved files around to better keep a uniform folder structure. Reduced the solutions down to one, though this will probably go back up once executables need creating.
Started adding testing framework for the OWIN and app server to be able to test Identity controllers.
Commit 69a7825ee77eea429e6e60ff3c6534b9febabed1

Commit bcc51aea: Preemptively Structuring the Chaos

Interfaces and Contract Classes

I have found that it is better to put structure in place around a project before going hog wild on implementation. While I recognize that some practices grow organically, a healthy amount of structure up-front can save a project from technical bankruptcy down the line. The two tools that I use early and often are interfaces and contract classes. There are a collection of interfaces that I regularly utilize throughout most projects.

  • ICreated
    • VigilUser CreatedBy
    • DateTime CreatedOn
  • IModified : ICreated
    • VigilUser ModifiedBy
    • DateTime? ModifiedOn
    • bool MarkModified(VigilUser, DateTime)
  • IDeleted
    • VigilUser DeletedBy
    • DateTime? DeletedOn
    • bool MarkDeleted(VigilUser, DateTime)
  • IOrdered
    • int Ordinal
  • IEffective
    • DateTime EffectiveOn
    • bool SetEffectiveOn(DateTime)
  • IEffectiveRange : IEffective
    • DateTime EffectiveUntil
    • bool SetEffectiveRange(DateTime, DateTime)

The Obvious – ICreated, IModified, IDeleted, IOrdered

These four interfaces serve to ensure that all properties are identically named throughout the solution. They also serve as a guide to future developers about what restrictions should be placed on the class. Every class that persists data to storage should implement ICreated – everything was created by someone and at some time.  An object that doesn’t implement IModified should never actually be modified. A class with IDeleted should not have the records actually removed from storage, but just fill in these fields to flag them as deleted. IOrdered means we know to set a default sort on the Ordinal field.

Instead of Deleting It – Effective It!

For values where we need historical data to be easily accessible, such as changing schedules or payment information, an interface is created to track the EffectiveOn date. Starting at that specific date and time, the new record becomes effective. There needs to be some way to group the different records, which is usually performed with a header type table. By definition, there can only be one effective record at any given date.

An example of its use is storing the payment information for a recurring transaction. The historical data for payment information is useful when looking into the past, and frequently the patron may want to change the payment option effective some future date. However, at no point will two or more payment methods be active. By implementing the IEffective and ICreated, the details of who made the change (and when) fully replace any functionality that might be lost by not implementing IModified.

Need Multiple, Overlapping Effectives – Range It!

When multiple records need to have their history saved or allow for changes effective in the future, the IEffectiveRange comes into utility. For IEffective records, the end of their effectiveness is the beginning of the next record’s effective date. However, for classes where there can be multiple records that come and go, an explicit range is required. This is useful for line items on a gift – do see when any given detail was the authoritative record, especially useful after the gift has been posted and receipted.

Contract Classes For

I battled back and forth with whether to include the shell for code contracts with every interface I write, or to only build it out when needed. I quickly found that I was including, at minimum, a contract invariant method on each interface, so I decided to just make it a standard part of every interface. Even if the Contract Class contains no Contracts, at least the shell is there, and I can easily add them later, as needed.

A quick standard I have put together is that all Contract Classes are contained in the same file as the interface, in a child namespace of “Contracts,” and named after the interface. Keeping the classes as internal and abstract means it can only be called within the assembly,

Minimum Viable Framework

I finally feel that I am at a stage where I have the minimum of a framework on which I can start to build an actual product. From here, I will slowly add and expand modules, slowly drifting towards the user interface, and tool with refactoring, templating, scripting, and finding other ways that I can reduce the complexity of complex tasks.

Added generic interfaces, and began cleaning up some Code Analysis rules from the “All Rules” playlist.
Commit 4010e840a8b168a1ab65466fa5c61cc342b56d8e

Added new Code Analysis rule sets to eliminate rules that I would be ignoring anyway.
Resolved several Code Contracts and Code Analysis issues.
Commit 2b1ff8a55711cb585750d4241df9c97895b7edfc

Decided I didn’t like having fields for the context, testuser, and now. Put them back as variables in each test method, and added a ContractVerification(false) attribute to the whole class. I think I’m going to find myself adding that attribute to a lot of testing classes.
Commit df9e61081f22471546dd1fd1132c8ecfecc3a26c

Added Contract Classes for each of the Interfaces.
Created the Identity and TypeBase classes to expand the foundation of classes before working on POCO’s.
Need to add more unit tests to fill out the Code Coverage.
Commit 716da101f6da28158ab0ed52aaba037b4c027676

Added ExcludeFromCodeCoverage attributes to the ObjectInvariant methods in the interface contract classes.
Added tests for the TypeBase class (via inheritance through a TestTypeBase class).
Filled out the ChangeLogTests tests.
Commit bcc51aeaa46dc8780ffcd9c33f88d8ecb1c2fffd

Tagged , , ,

Commit 4b684657: Laying the Foundation

Entity Framework and ASP.NET Identity Framework

Two key library decisions needed to be made this week: choosing the object-relational Mapping (ORM) framework, and choosing a membership provider. To cut right to the end, Entity Framework and ASP.NET Identity were the solutions that I have chosen to utilize throughout the software. This week’s commit has been getting the initial implementation created, customized, and tested.

  • Create NotImplementedAttribute
  • Extend Identity membership classes
  • Create Interface for data context
  • Create Data Context
  • Create minimal tests
  • Minor Clean ups


Sort of like a TODO in the code, I pepper classes that still need work, or are just a placeholder shell with this attribute. This makes it so I can easily add a Code Analysis rule to mark it as incomplete, or I can add an ObsoleteAttribute to the NotImplementedAttribute. The compiler will issue a warning and I can easily track down any places I left marked as Not Implemented.

Vigil Identity Classes

By default, the Identity classes use a string as the primary key. Internally, it is a serialized Guid, but I could not find a good reason why this was masked. Also, I wanted to play with inheriting the classes – so I did exactly that. For now, the “System” classes are just the Identity classes, with a Guid key, and table names explicitly set to match the class name (thus overriding the IdentityDbContext’s default of naming them “AspNet_____”).

Data Context

Now is when the fun gets to start – time to start making some actual progress towards real data.

  1. Create the IVigilContext interface, to expose the bare minimums.
  2. Create the Database Context: VigilContext
  3. Inherit it from the IdentityDbContext generic class (so I can use those beautiful Vigil____ classes I created).
  4. Inherit it from the IVigilContext interface and implement the “AffectedBy” and “Now” properties.
  5. Create three tests:
    1. Initialize and Create the database – this runs Entity Framework model validation. I wish I could find a way to do this without actually having to create the database, but I was unable to find a way to expose the EF method that runs the validation.
    2. Verify that the explicit constructor is setting the AffectedBy and Now properties. It is a menial test, but it makes sure no one breaks it in the future.
    3. Assert that the Set method works for at least one model. This serves two purposes – it makes sure that the Context is calling its base class’s Set method, and it makes it so that code gets covered by a test, thus passing Code Coverage analysis.

Minor Clean Up Duty

I misspelled the name of the core project, spelling it “Vigi.Data.Core”. This meant renaming the project, updating the Assembly name, default Namespace, the folder name (which also caused a rename on all files in the project), the namespace in existing classes, and references to the project. Thankfully, I caught it before I was creating objects that referencing those elsewhere.

In order to get complete Code Coverage for unit tests, I created a test just to call the constructor for the NotImplemented Attribute (it throws a NotImplemented Exception). However, the last line in that test is an Assert.Fail, which should never be reached. This causes the Code Coverage to say that line was never executed, and thus not covered. Obviously, I do not care about Code Coverage in the Testing project, so I added a codeCoverage.runsettings file, which explicitly excludes the Vigil.Testing.Data assembly from analysis.

Added Vigil Users and Roles implementation of the Identity framework, and added two quick tests for VigilContext.
Commit 9bca8542c5a0f099032631c133215a5bd9c28aae

Added Entity Framework and Identity Framework.
Customized the Identity objects with Vigil objects, including using a Guid as the primary key, and adding a RoleType enum. Added a .runsettings file to exclude the Vigil.Testing.Data project from Code Coverage reports. Corrected the “Vigi.Data.Core” misspelling to “Vigil.Data.Core”.
Commit 8be35473aa84138f6ee362d083dd424726345089

Added tests to validate that the Vigil* tables have the correct names, since there was a problem with them being overwritten by the IdentityDbContext.
Commit 4b68465701f111a806a920e7ec4d12de697aeee7

Tagged , ,

Commit 527fabb8: Vigil.Data Solution and Initial Projects

After several false starts, the convention for how to organize a solution seems to have come together. This also includes how to change the default project settings, and how to keep everything tidy as the software grows.

Vigil.Data Solution

This solution will contain all projects in the Vigil.Data namespace. This includes the central collection of Entity Framework data models, projects for DDD Bounded Contexts, and each project needed for services. There will be future solutions for the web projects, automated routine projects, importing pipelines, export processes, etc.

  • Vigil.Data.Code: where the Entity Framework Code First data models exist, including necessary abstract classes, interfaces, and extension methods.
  • Vigil.Data.Modeling: contains all of the Entity Framework specific code that pertains to modelling the data into the data store (database), including the DbContext, Database Migrations, DbInitializers, and interfaces. This does not include any bounded contexts that may exist in the future.
  • Vigil.Data.Services: services (which handle the business rules and workflows), specific-use data models, data mappers, validation, and supporting interfaces will all reside in this project.
  • Vigil.Testing.Data: all unit tests will be rooted in the namespace Vigil.Testing, with the sub-namespaces reflecting the project(s) they are testing. Thus, this will have all of the tests for the Data projects.

Once these projects are created, there are three property pages that I immediately change from the defaults.

Assembly Information

  • Check the Company and Copyright information to make sure they reflect the project that I am creating (and not the computer’s defaults).
  • Set the Assembly Version to 0.1.* (default the Build and Revision Numbers)
  • Set the File version to

Later, as the project grows and meaningful features are added, I will manually increase the minor version number as appropriate. Maybe even increase the Major Version, too!


Benefits of strong naming your assembly first:

  1. Strong naming your assembly allows you to include your assembly into the Global Assembly Cache (GAC). Thus it allows you to share it among multiple applications.
  2. Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.
  3. Strong name protect the version lineage of an assembly. A strong name can ensure that no one is able to produce a subsequent version of your assembly. Application users are ensured that a version of the assembly they are loading come from the same publisher that created the version the application was built with.
  4. Strong named assemblies are signed with a digital signature. This protects the assembly from modification. Any tampering causes the verification process that occurs at assembly load time to fail. An exception is generated and the assembly is not loaded.

Why use strong named assemblies? answer by Kyle Rozendo

Code Contracts

  • Set the Assembly Mode to “Standard Contract Requires”
  • Enable Runtime Checking at “Full”
  • Set the Contract Reference Assembly to “Build”

Initial projects for the Core data models, data modeling objects, data services, and data testing.

Added public assembly signing, code contracts, application versioning, and copyright notifications.

Commit 527fabb81ff6383f8ece46848feb2e329c131201

Tagged , ,

Recurring Gifts – Part 1: Database Schema


There are many posts out there for how to configure a database schema to handle scheduling events.  The part that I found difficult to find was an algorithm for calculating future dates for each type of recurring schedule.  I have started this series on Recurring Gifts as a way to document the process I went through to build the current system.  Some features include:

  • Ability to scheduled gifts by daily intervals, weekly intervals, monthly (by date) intervals, and monthly intervals by relative point.  From there, it is simple math to do Quarterly, Yearly, or any other multiple.
  • Ability to place gift generation On Hold until a certain date.
  • Ability to Cancel gift generation on or after a certain date.
  • Ability to makes changes that apply on a certain date.
  • Easy to answer the question of “why was this gift created” because all gifts are linked to the schedule that generated it.

A few limitations that may constraint its universe utility:

  • Only one active schedule can be created.  Can only do “first Friday of every Month”, not “first Friday of every Month, and third Tuesday of every other Month.”
  • Cannot schedule by the phase of the moon (not even joking – this was an actual request) – though it could be fudged by using a Daily schedule.
  • Cannot schedule based on National Holidays (also an actual request).
  • Schedules can only pause and restart once (via the Header.HoldUntilDate).

Database Schema

Instead of inventing a database schema from nothing, I did what I do best – stand on the shoulders of giants, and Microsoft’s SQL Server team is a pretty huge giant.  Turning to their documentation on the SQL Server Agent job schedules, I opened up the msdb.dbo.sysschedules table.  I adjusted some of the definitions to fit my need and built my schema from there.

Schedules Data Schema

There were three major changes that I made to the SQL schedule.

  1. Frequency Interval, for weekly recurrences, is a bit flag in the SQL Agent schema.  Since there is already an enum in the mscorlib, I changed the schema to use the System.DayOfWeek enum values.
  2. Frequency Interval, for monthly relative recurrences, uses 1-7 for Sunday-Saturday, 8 = Day, 9 = Weekday, 10 = Weekend day.  I only need the days of the week, so it made sense to also adjust this to use the System.DayOfWeek enum values.
  3. I dropped all notion of “sub day” scheduling.  There is no need to have gifts created at multiple points in a day.

A common approach to handling querying the event dates is to store a list of all future dates.  I can also use this to determine when the gift was actually created, and use this as an audit for gift creation.  By tying the Audit to the Schedule, it is very easy to find out exactly why an Audit was created.

Recurring Schema

Evolution Path

There were two mistakes I made in the original implementation of this schema.  First, I had the End conditions on the Schedule.  The thought was that this would be mildly helpful with knowing why the generation of gifts might have started and stopped.  Potentially, a termination point would be reached, gifts would stop being generated, then a new schedule would be added, thus resuming creation.  However, the actual hit rate for this situation was zero.  All it did was ridiculously complicate the algorithm for parsing the schedules.

Additionally, I previously had the Start Date on the Schedule.  This also was confusing, as two schedules could be created and cause a gap in the timeline.  It is much more easier to implement one “pause until” setting than try and handle skips.  My use case was exactly zero for needing multiple start and stops, which is why I have pulled back on the complexity a bit for this second round.

Up Next

The next post is going to start to demonstrate how I implemented various parts of the c# algorithm to generate the dates in a schedule.  These collections then are combined to provide for a final list of all dates.

Tagged , ,

Naming the Patron Object

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

To any seasoned developer, this is entirely too true, and many people have written extensively on why this is so hard.  For this particular exercise, I have to decide what to the call the core object that represents a (potentially) giving unit in Vigil.  Trolling through existing applications, here some options I have come across, and why I rejected them:

  • Client – feels too impersonal for a DRM, though I know there are non-profits that use this as their preferred term.
  • Constituent – the term is mostly used with voting system.  Also, I am really loathe to type out “Constituent” thousands of times.
  • Customer – this term is associated more with a point-of-sale system than a donation tracking system.
  • Donor – not all names in the database are going to be actual donors.  Some will just be people that purchased something, many will not even have given (in a system I recent worked on, around 55% of the names were non-donors.
  • Entity – this conflicts heavily with Entity Framework, where the Entity object is used everywhere.
  • Patron – this is a compelling term, since it has the dual definition of being both a person who give financially, and a customer to a store.

The other part of the name is that it needs to pair with all of the auxilary tables that will be prefixed with:

  • ______Address
  • ______Attachment
  • ______BankAccount
  • ______Code
  • ______ContactBase
  • ______CreditCard
  • ______Date
  • ______Email
  • ______Identifier
  • ______Note
  • ______Number
  • ______Payment
  • ______Person
  • ______Phone
  • ______Relationship

And that’s just the preliminary list!

I had initially gone with Entity, since that it is what our current system uses.  However, I quickly tired of running into the namespace conflicts with EF, and thus went searching for alternatives.  I had almost settled on Constituent, until I went to start the re-factoring and after the twelfth time of typing it, realized it was going to cause CTS.  Patron was a late find that I stumbled upon.  Thesauruses are my friends.  So far, I am really digging it.  I figure I get one re-factoring before I hit the point of no return.  I am hoping this is the right one.

Tagged , ,

Knockoutjs Tutorials Suck (but not as much as the documentation)

I am not sure why I started using Knockout, but I have had an overall positive experience with the framework.  I was very intrigued with their hands-on tutorials built into the site, which made getting started fairly easy.  I walked through them step-by-step, writing out all of the code examples by hand, and diligently debugging typos when the example would not execute as expected.  From there, I took the simple step of starting a small side-project just to see how it would all interact.  At that point, it became quickly obvious that the tutorials suck and are missing large pieces of information that are vital to get just a basic application going.  I also found that there are two tutorials that are completely worthless in terms of getting start – they are advanced topics that I still have not found an applicable usage.

However, the tutorials were just an hour or two of my time, and at least got me started.  The most bothersome part is the official documentation on the website.  It is terribly incomplete, and just leads to frustration.  There are lots of hidden features and unexplained function arguments that force me to take trips through search engines, which inevitably lead to a question that someone else posted on Stack Overflow, which might hint at the answer to my problem.  It has been frustrating to have to wade through the tangled mess of tangential questions and obscure answers to maybe find something similar to my problem.  However, it has also been immensely rewarding to discover new methods of working with JavaScript, better tools for debugging, and simpler ways to manage my code.

The GitHub wiki is sparse and filled with many empty templates.  The information is not reliable – I am not sure how much of is it accurate as of Knockout 3.1.  So, I am working on slowly putting together better documentation.  As I discover something new or expand on something I already know, I am adding it all to a little sidebar of notes that I keep.  My hope is that I will get enough information that I can meaningfully contribute to the wiki.  I like this project, and it is clear that plenty of other people like it.  I just wish the difficulty to realistically get started was a little lower.

I am trying – this is going to be my first little tiny toe dipping in the big ocean of open source development.  We shall see how it goes.


All I Wanted Was an Integer Primary Key

The ASP.NET Identity system is designed to replace the previous ASP.NET Membership and Simple Membership systems. It includes profile support, OAuth integration, works with OWIN, and is included with the ASP.NET templates shipped with Visual Studio 2013.

In and of itself, it is a very nice and pleasant library that really does integrate nicely into a WebAPI or MVC project.  The template project that comes with VS2013 spins up very quickly and provides the illusion of something that the developer can just forget about.  Were that the case, I would not have this post.

All I wanted was to change the default primary key from a GUID to an int.  My initial thought was to change the default ApplicationUser from inheriting from the non-generic IdentityUser to the generic IdentityUser<int, VigilUserLogin, VigilUserRole, VigilUserClaim>.  Compiling worked just fine, running caused all kinds of type casting problems.  Why?  Because all of the other classes surrounding the IdentityUser were all coded to the string type (which internally is a GUID).

Thus began the big hunt to find out all of the places where I needed to override, inherit, or otherwise manipulate the library to get the primary key to be an integer. This meant replacing the five main classes that create the authentication and authorization schema:

  • IdentityUser
  • IdentityRole
  • IdentityUserRole
  • IdentityUserClaim
  • IdentityUserLogin

Then I had to create a new UserStore and UserManager to utilize these new classes, and create a new ClaimsPrincipal to store and retrieve the new security identifier (Sid) for the user. Finally, a new BaseController class was created that all other controllers must inherit from, in order to utilize all of this new code.

At this point, I am wrestling with the fact that now my domain model has a hard requirement on the Microsoft.AspNet.Identity library. I had initially hoped to have my User and Role domain models be completely separated from the actual authentication/authorization system. This creates a hard link that is going to be the death of me unless I can find a way to isolate the framework and run unit tests without requiring the database. For now, though, I am going to continue in this direction, and turn a blind eye to the technical debt accruing from this decision. Maybe before I ship this, I will find a better way to do it all, but for now at least I have my integers.

Creating Blogs is like Crack

The titles of blogs are like creating awesome band names or fantastic guild names; it is terrible addictive, easy to register, and a pain to maintain.  However, as I explore this phenomenon of converting my thoughts to characters, I have realized that I really do want to start segmenting various categories of posts into their own set of blogs.  For now, I am starting with moving all of my running-specific posts, fitness articles, and posts related to fatherhood into Exactly One Hobby.  The title of the blog is based off of a post I wrote several months ago about what happens when you mix being a parent with attempting to accomplish your own goals.  I have lots of posts in the pipeline for these topics.  As such, Rovani in C# will become more focused on application development, politics, and people being stupid.

The best part about this being an experiment is that I get to do whatever I want!