Forem: Nolan Miller

March 2026

Nolan Miller — Wed, 01 Apr 2026 16:51:47 +0000

Theme of the month: Endings. My wife and I sold our house in order to move and I wrapped up a big project at work so that I can tackle some accounting integrations.

Where My Time Went

I finished a big lift and shift project of over 20 years of sales data between database servers. It was one of the smoother projects that I've done so far. Not no bugs, but fewer! The difference was becoming obsessed with proving what I'm shipping which revealed a lot of incorrect assumptions that saved me in this project.

Small Wins

With fzf and tmux, I dramatically improved my ability to navigate my system on the command line and store windows associated with projects that I'm working on. Heavily inspired by tmux-sessionizer

Before some stakeholders were about to show off a feature I had worked on to the whole staff, it started hard failing. Under pressure, I was able to locate and fix the bug in about 5 minutes!

Worth A Read

Your job is to deliver code you have proven to work — reign it in, cowboy
AI makes you boring — creative ideas are born out of painful problem solving
What God Thinks About You — a 10 year old article that I am going to return to

Half-Baked

Vertical Slice Architecture is the best strategy for agentic workflows.
TestContainers for integration testing gives me way more peace of mind than the three unit tests that I added in 20 minutes.

Other Things

I shot a 116 on 18 and then a 50 on 9 in back to back days. If I can keep this level of improvement up, I'll be on the tour by July.

Started playing Fallout 4 finally. It turns out, I am not very good at role playing games. After about 7 hours of gameplay I found myself high-tailing it out of the castle with a .38 rifle with no armor and no ammo. I have not started farming food yet.

Thoughts After a Year of Software Development

Nolan Miller — Tue, 13 Jan 2026 12:41:32 +0000

After teaching myself to code, I landed a job a year ago in December. In no particular order, here is an assorted collection of thoughts, opinions, and tidbits that I've accumulated over the past year.

Typing speed and accuracy are important

As a junior, I do not spend "most of my time thinking." Many of the problems that I need to solve aren't very mentally taxing, they just need implemented. When I started training my typing speed and accuracy by bouncing between keybr and monkeytype, even repetitive "hammer-it-out" coding sessions became much more enjoyable (and shorter too). My backspace key appreciates the rest.

AI hype is mostly just that

When an application is even remotely complex, or the context needed to solve an issue is of any reasonable size, AI is practically useless. No, I'm not going to type up my organization's application and server architecture so that I can argue with AI to get it to stop hallucinating. AI can make "nice" looking websites and decent interactivity. I really use it to search for Microsoft documentation... which is abysmal. AI is pretty good at that.

I hate Microsoft

Windows sucks. VS sucks. (Except for the debugger, that's pretty good.)

Knowing how to host an app is a differentiator

Surprisingly, there's a large portion of developers who have never stood up a production server on a bare VPS. I'm no expert, but it's really not too difficult. Maybe I just enjoy working on servers, but knowing how to host your apps outside of Netlify or Vercel is a good skill to have.

I'm really good at making really bad code

Did you want to filter that list using 3 helper methods across two classes with injected services? I got you.

The next day, I usually realize that this could have been done in 3 lines and everyone can magically understand what it does.

I'm not rich

I make more money than I used to. But, it seems like most development jobs aren't the "f*** you" money that YouTube would have you believe. Lucky for me, I really like coding.

I really like developing

I don't know if its the sound of the keyboard, the hacker aesthetic that you get from using a shell for everything, or the feeling catpuccin gives, but being a developer is really fun.

Shortcuts will make you feel like a god

I have not measured whether or not it speeds me up a significant degree, but it feels very good to not have to reach for my mouse to perform really common actions. It is well worth taking the time and the initial slowdown to get system shortcuts into your fingers. Did you know that on Windows, you can open and focus applications in your taskbar by using Win + the number corresponding to it's order? Getting used to navigating your computer this way will immediately make everything feel more smooth.

JavaScript is the worst

But, it's not going away. The event loop is the death of me everytime I mess with WASM in highly-interactive apps. It's evil... but, you need to know it.

OOP is OOK

I work in C#, and everything is an object no matter what. For most data-heavy problems, I can usually create a pretty solid mental model with this paradigm, but sometimes it feels like I'm just trying to fit into the paradigm when all i need is a couple util functions. I don't know the number of abstractions that I've taken the time to write and then immediately deleted because it no longer makes sense.

Quality of life features live on the back burner

It's really hard to convince anyone that your "it would be really nice if" idea is worth the time when there are new features and projects that other teams are depending on. At best, I've had a bit of time when I can shove it into the mix when I finish a project early unexpectedly. Instead of creating the "quality of life" ticket for later, just lump it in with the feature that you're working on.

Nobody knows what you do, or how long it will take

My manager is great, has lots of industry experience, knows me and my work pretty well, and he still cannot figure out how much time it will take for me to complete something. Being a developer uniquely gives you a lot of trust and autonomy over your schedule. This is a privilege and a responsibility. Some of the best engineering work time can produce no quantifiable output. Don't take advantage of this.

Assume any data you don't own is toxic

When you don't have crystal clear visibility into a data source for your application, you need to treat it like it can and will be wrong or missing every time. Use fallback values, conditional rendering, and generally assume the worst. It's probably a good idea to do this when you have the visibility too.

The code I actually use is short and isn't elegant

The code I use the most are tiny scripts that I've written for myself. If they get used a lot, they can't break. If they can't break, they need to be easy to maintain. If they need to be easy to maintain, then they need to be short, and so clear a beginner could understand them. Automation doesn't save time if it's buggy and hard to understand. That said, I don't rela

Small problems need solved too

When I'm trying to find the biggest and most exciting and most impactful problem to solve, I can't think of anything. But, when I open my eyes to small annoyances, I start to see them everywhere.

Backend is way more interesting than front end

I wasn't counting on this to be true. A year ago, I thought that my bent towards things that are artistic would have drawn me to the front end more. But, in all the projects I've worked on, it's been far more exhilarating to solve the pivotal logical issue than it was to figure out how to show it to someone.

A fast/slow dev server makes a huge difference

Have you ever worked with the Blazor dev server? Maybe I'm doing it wrong, but getting that thing to load up a large project takes forever.

Don't repeat yourself... but don't not repeat yourself

I've rewritten logic in a few places that has bitten me. You will always miss at least one update if you have to go to more than one place. But, in my zealousness I've created some abstractions that make absolutely no sense to work with. DRY is for information, not code. Each piece of information, or logic, should have one authoritative implementation. Don't push things together just because.

There's almost always a better way

... and someone else thought of it first. You don't need to be a hero and try to come up with the most clever solution to prove you know what you're doing. Ask questions to people at your disposal. Collaboration leads to better ideas and a better team.

Version control everything

Use git repos and feature branches religiously and neurotically. I can't count the number of times that I've started on a bug fix while I was in the middle of working on a small feature only to realize that I never created a new branch. Not only do I have to start over the bugfix, but often, I also broke my feature branch and have to walk backwards for a while to get it fixed.

That it....

I learned a lot in year one, and I know I still have so much further to go. I've never stepped into a career that it feels like no matter how much you learn, you've only just scratched the surface. It's overwhelming. But, it's also exciting!

Hopefully some of this advice is helpful to you! Hopefully you agree with some of it. Hopefully you disagree with some of it. For what it's worth, these are my thoughts.

For now.

How to Build an API with Controllers

Nolan Miller — Wed, 26 Nov 2025 20:26:31 +0000

I starting working in ASP.NET after minimal APIs had already been released and reached popularity. My first professional project involved moving endpoints from a .NET controller-based API to the new minimal syntex. Unfortunately for me, that meant I was not going to be able to avoid the controller-based API even though I wasn't particularly comfortable with the paradigm... or C# for that matter.

To save you the headache, I will walk through the very basics of creating a controller-based API and explain what I spent hours staring at code to figure out (after all, 20 hours of reading code can save you 20 minutes of reading documentation). We will create endpoints, accept parameters and document the routes all in the controller-based syntax.

What is a controller-based API?

The controller-based API, is... well, an API whose endpoints are is organized with controllers, as opposed to the minimal API, whose endpoints are registered directly on the WebApplication using extension like MapGet and MapPost. The pattern is actually just the MVC (model-view-controller) architecture, but with the "V" left out. Since an API doesn't typically return formatted views, it doesn't need to worry about that. But, the routing and model construction all work the same way as it would in an MVC application. Instead of a view, our controllers will return data wrapped in HTTP responses that can be used by any other application that can make HTTP requests.

Configuring an API for controllers

That's enough background, let's get started by bootstrapping an application using the dotnet cli. In a new terminal window, run the following command:

dotnet new webapi -n "TodoApi"

Once this runs, we'll have a working API, but if you'll open up Program.cs, you'll notice that we already have a minimal API endpoint registered here. With a little extra work, we'll have this converted into a controller-based API.

First, DELETE the following lines of code from Program.cs:

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast");

// leave in app.Run();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast");

///////////////////////////
// do not delete app.Run();
///////////////////////////

record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

Now, replace var app = builder.Build(), with the following:

builder.Services.AddControllers();
var app = builder.Build();
app.MapControllers();

This small bit of code here enables the use of controllers in our web app. With the AddControllers() extension method, we're registering all the services that we might need for API development in ASP.NET. Once the services are registered and the app is built, instead of manually configuring all of our endpoints, .MapControllers() goes to look at all of our Controllers and turn the action methods into route endpoints!

Creating routes from actions

Now that our Program.cs file expects to search our app for controllers, we should go and make one. To support the quintessential "todo" app with our API, in the root of the project, create a folder called Controllers. Inside that folder, make a new file called TodoController.cs and add the following code:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;

namespace TodoApi.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class TodoController : ControllerBase
    {
    }
}

This is the controller that we will use to create endpoints for our API. This controller is just a C# class that inherits from the ControllerBase class that is provided by the Microsoft.AspNetCore.Mvc package. That base class gives us access to some helper methods that we will use later. We also have to include the [ApiController] attribute to tell the framework that we are creating a controller.

If we started our application now, the controller would be registered, but no routes would be added because we haven't added any action methods. So, let's do that right now. In order to add the endpoint, create a method on the controller that returns an ActionResult. Add the following method to the TodoController class.

// in TodoController
public ActionResult Health()
{
    return Ok("Healthy");
}

This is called an action method. It returns a controller action using the Ok() helper method provided by ControllerBase which returns an ActionResult that has a 200 status code and contains the string passed to it. If we build and run our application now, we have a new endpoint! Now let's talk about where we can find it when we're trying to call the API.

URL Routing in Controllers

ASP.NET does most of the routing for us when we are using controller-based syntax. If you're familiar with the MVC pattern, then you already know how this will work. Each endpoint is created using the name of the controller class, the name of the action method and optional input parameters.

The action method that we just created was inside of the TodoController and it's method name is Health. By default, to hit this endpoint, we have to send a GET request to /Todo/Health.

TodoController → Todo
ActionResult Health() → Health

Seems simple enough, but if you try this on your API now, you'll notice that you get back a 404. Sorry! I tricked you.

This controller isn't using the default routing scheme. If you've been following along with the code I've told you to put in, then you might have noticed, that we added:

[Route("/api/[controller]")]

... to the top of the controller.

This is an attribute that we can assign to a class or action method to tell the framework what pattern we want it to use when assigning an endpoint. The pattern syntax is dead simple, it will:

match any string that you pass literally,
statically replace wildcards passed between [], and
pass named parameters to action methods between {}.

The default pattern for a controller in ASP.NET is "/[controller]", where the wildcard controller is replaced by the name of the controller class with the word "Controller" stripped out.

With our custom Route attribute, we're using "/api/[controller]". So, to hit our controller endpoints, we would just have to use the base /api/Todo.

We didn't add a custom Route parameter to our Action method, so it will route using the default pattern "/[action]", where the wildcard action will be replaced with the name of the action method. If you're following from above, that makes the full pattern for our endpoint "/api/[controller]/[action]". So, to check the health of our API, get a GET request to /api/Todo/Health.

With the Route parameter, we can change the routes to whatever we would like. Let's illustrate this by adding another endpoint to this API.

[Route("/api/[controller]")]
public class TodoController : ControllerBase
{
    public ActionResult GetTodo(int id)
    {
        return Ok(id);
    }
}

Since we didn't add a Route parameter to this action method, we have inherited the default. So, to hit this endpoint in it's current state we would send a GET request to /api/Todo/GetTodo/23. This would return an action result that would presumably return a Todo that had the ID of 23. So, how is this 23 passed into the id parameter of the action method?

There is one more section of the default route pattern for ASP.NET.

/[controller]/[action]/[id]

That means that without adding a custom attribute, we have access to an id input parameter that can be submitted as a URL parameter by a user. In order to accept it all we have to do is add the parameter to the action method with the name id.

This method seems like a good candidate for customization though. Sending a GET request to an endpoint containing GetTodo seems redundant and sloppy. So, let's use the Route attribute to create our own pattern. While we're at it, our users likely know that they're hitting an API, and we don't have anything else hosted at this address, so we can adjust that too.

[Route("todos")]
public class TodosController : ControllerBase
{
    [Route("{id}")]
    public ActionResult GetTodo(int id)
}

By combining these two Route attributes, we've created a new pattern: /todos/{id}. To make the same request as earlier, we would send a GET request to /todos/23. Using Route, we kept the user from having to type out the name of our implementation method, while still leaving it intact for our developer to use. I'll also note that we switched the pattern to the curly brace syntax to better identify that id is a route parameter that will be passed in the action method parameter named id.

Now that we've got the request side of things figured out, let's take a look at how to handle getting information back to the user.

Constructing responses

So far, all we've returned is Ok(). ASP.NET also provides us methods like NotFound() and StatusCode() that return different status codes. Along with these three, we have access to a long list of helper methods through the ControllerBase class to send responses to the user. Feel free to peruse them in your own time, but today, I'll just look at four.

Ok() - Returns a 200 status code. Pass any model into it as a parameter to send this back as serialized JSON.
Created() - Returns a 201 status code, indicating a successful model creation or update.
NotFound() - Returns a 404 status code. This is useful if you have a "get one" route that is passed a failed id.
StatusCode() - If you don't have time to look up the built-in method, or you find they don't have a method that satisfies your needs, you can just pass the status code as a parameter to this method to return a response with that code.

Let's use a couple of them. Here's a SaveTodo method that uses Created and NotFound.

    [Route("{id}/Save")]
    [HttpPost]
    [ProducesResponseType(201)]
    [ProducesResponseType(404)]
    public ActionResult SaveTodo([FromBody] Todo todo)
    {
        var success = _todoService.SaveTodo(todo);
        if (success)
        {
            return Created();
        }

        return NotFound();
    }

In this example, notice the decorations. We have an [HttpPost] and two [ProducesResponseType] attributes.

The SaveTodo method takes in a Todo class instance. With what we've seen so far this wouldn't be possible without creating a horribly-long URL that took in all string parameters. Not a great interface selection. So why couldn't we pass objects with our request before? By default, action methods will represent GET request endpoints. In order to pass a body to our method, we'd send a POST request and our endpoint wouldn't match anymore.

Luckily, making this change is as simple as including the attribute [HttpPost] before the method as shown in the example.

What about the [ProducesResponseType] attribute, though? While not vital, it serves two purposes. If you use OpenAPI to generate your documentation, then these attributes can be used to add helpful details about your route. And even if you don't use OpenAPI, they're a way to provide some in-code documentation for future developers. In a simple method like this, that may seem silly, but as controller methods and their logic grow, it can certainly be nice to know at a glance what the success/failure results for your endpoint are.

Conclusion

If you've only had exposure to the newer minimal API syntax, then I hope that this makes the controller-based API pattern a bit more approachable. As with many things in "approaching-legacy-status" .NET, it is fairly verbose to get to a working API, but in my next few posts, I'll be exploring some features that you'll need a controller-based API to take advantage of and hopefully give you a reason to actually use them!

Until then!

Build a Database Connection Framework In 133 Lines Of Code

Nolan Miller — Fri, 24 Oct 2025 12:13:31 +0000

Entity Framework is a popular database connection choice for .NET developers. It's fairly simple to use but, what if I told you that we could create a connection framework on top of ASP.NET that would allow us to get total control of the SQL that we write? The cherry on top is that it will take about as much code as it takes to configure Entity Framework.

In this article, I'll show you how to connect an ASP.NET minimal API to a local SQLite database Entity Framework. We will still map tables into classes allowing us to interact with our data in C#. I'll include every line of code you need, so let's get started.

The data

First, we have to do is set up a database. I decided to use SQLite since I've never had an excuse to before. Make sure that you have SQLite installed and that you've connected to a database. (You could also connect to a MySQL, SQL Server or Postgres database using the following method too, but this article will focus on SQLite.)

With our database, we'll track student information and grades. First, connect to SQLite and create a database, we'll call it Students.db, then create a students table and a grades table.

sqlite3 Students.db

sqlite> CREATE TABLE students (
...>        id INTEGER PRIMARY KEY,
...>        name TEXT,
...>        school TEXT
...> );
sqlite> CREATE TABLE grades (
...>        id INTEGER PRIMARY KEY,
...>        scored INTEGER,
...>        out_of INTEGER,
...>        student_id INTEGER,
...>        FOREIGN KEY (student_id) REFERENCES students(id)
...> );

Drop these two table definitions into ChatGPT and have it script you out some sample data for both of the tables. This isn't necessary, but it will make your API more interesting to work with once we're done. Once you've done that, we're ready to get started.

The connection

Instead of using Entity Framework, we'll remove that layer of abstraction to use ADO.NET. These are the libraries that EF uses in its implementation. Microsoft was kind enough to wrap them up in a NuGet package for us. In the root of your project, run the following command:

dotnet add package Microsoft.Data.Sqlite

With that installed, we can work on getting our application connected to the database. First, grab your connection string. Each database provider has their own format for these, but I'll trust that you can find that and configure it on your own. Sqlite's format is below:

"Data Source=path/to/database_file.db"

The best way to give your application access to this is through a configuration object that you supply through dependency injection. I wrote an article about how to get that set up if you need help. Or you can decide to be a lawless cowboy and hard-code it... I'm not your mother.

It's finally time to write some code. In order to interact with our database, we need a class and a matching interface that will provide the connection to the rest of our application. We will call it, somewhat unimaginatively, DatabaseConnectionProvider.

// DatabaseConnectionProvider.cs
using Microsoft.Data.Sqlite;

namespace Students.Repository.SQL;

public class DatabaseConnectionProvider : IDatabaseConnectionProvider
{
    private readonly string _connectionString;

    public DatabaseConnectionProvider(IConfiguration config)
    {
        // Don't you hard code it, cowboy...
        _connectionString = config["ConnectionString"]!;
        if (string.IsNullOrEmpty(_connectionString))
        {
            throw new InvalidOperationException("Connection string not found.");
        }
    }
}

Since we'll be injecting this provider into other classes later, we'll create an interface and include a preview of the first method that we will create!

// IDatabaseConnectionProvider.cs
namespace Students.Abstractions;

public interface IDatabaseConnectionProvider
{
    List<T> GetRecords<T>();
}

Now back in our provider class, create the database connection inside this GetRecords method.

// DatabaseConnectionProvider.cs 
// after DatabaseConnectionProvider(IConfigration)

    public List<T> GetRecords()
    {
        using (var connection = new SqliteConnection(_connectionString))
        {
            connection.Open();
            var command = connection.CreateCommand();
            command.CommandText = "SELECT * FROM students;";

            var reader = command.ExecuteReader();
            while (reader.Read())
            {
                Console.WriteLine(reader["name"].ToString())
            }
            connection.Close();
            return new List<T>();
        }
    }

The SqliteConnection class is provided to us by that NuGet package that we installed earlier. This gives us the building blocks of database interaction: connection, issuing commands, and reading the results.

This isn't our final GetRecords implementation, but it will work and you can test that (if you seeded some sample values into your database). When you run it, the method creates Sqlite database connection and issues a SELECT * command to return all the students. We get back a DataReader, also provided by the NuGet package from earlier, that we can use to read the "name" column of each row before disposing the connection.

We're connected! Take a moment to celebrate.

The models

Now that we can get the data out of the database, we have a bit of grunt work to do in order to be able to work with it. For each of our database tables that creates a record we want to use in our code, we need to create a model in C# using a class.

In this small sample project, we just need two.

// Student.cs
public class Student
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string School { get; set; } = string.Empty;
}

// Grade.cs
public class Grade
{
    public int Id { get; set; }
    public int Scored { get; set; }
    public int OutOf { get; set; }
    public int StudentId { get; set; }
}

One of these models represents a single row in a table. Right now, they are sad and empty. Okay, maybe not sad, but definitely empty. But, now we have a problem. How do we get a DataReader to spit out these models that we just created?

Once we get into our read loop, we could access all of the columns by name and manually assign them to the model properties. That would work, but we would have to rename our method to GetStudentRecords, since attempting to query for grades would throw an exception when looking for the "name" or the "school" columns.

Well, then we could create a new GetGradeRecords, but then, of course, we would be rewriting all of the logic inside our original method except for where we construct and return a model.

Instead, we need to offload the parsing responsibility from our DatabaseConnectionProvider. Instead of making our provider responsible for reading data, we can make each model responsible for knowing how to construct itself by giving each one Parse method.

// In Student.cs 
    public string School { get; set; } = string.Empty;

    public Student Parse(IDataReader reader)
    {
        Id = reader.ParseInt("id");
        Name = reader.ParseString("name");
        School = reader.ParseString("school");

        return this;
    }
}

// In Grade.cs
    public int StudentId { get; set; }

    public Grade Parse(IDataReader reader)
    {
        Id = reader.ParseInt("id");
        Scored = reader.ParseInt("scored");
        OutOf = reader.ParseInt("out_of");
        StudentId = reader.ParseInt("student_id");

        return this;
    }
}

If you're typing along, you probably noticed that ParseInt and ParseString are red. In order to clean up the syntax a bit, I added a couple static extensions methods on the DataReader class. You can add those in a new file.

using System.Data;

namespace Students.Repository.SQL;

public static class ReaderExtensions()
{
    public static int ParseInt(this IDataReader reader, string columnName)
    {
        return reader.GetInt32(reader.GetOrdinal(columnName));
    }

    public static string ParseString(this IDataReader reader, string columnName)
    {
        return reader.GetString(reader.GetOrdinal(columnName));
    }
}

Now all we have to do is let the DatabaseConnectionProvider know that our models have this parse method. We will do this with generics, but we are also going to need to define an interface to expose this method generically...

// ISqlDataParser.cs
using System.Data;

namespace Students.Abstractions;

public interface ISqlDataParser<T>
{
    T Parse(IDataReader reader);
}

... and make sure that our models are inheriting it.

// Student.cs
public class Student : ISqlDataParser<Student>

// Grade.cs
public class Grade : ISqlDataParser<Grade>

Now, let's update our GetRecords declaration to finish making our Parse methods available.

// In DatabaseConnectionProvider
// Replace public List<T> GetRecords()
public List<T> GetRecords() where T : ISqlDataParser<T>, new()

What this says, is that we can only call GetRecords<T> if the type that we insert for T implements the ISqlDataParser interface and has a parameter-less constructor.

Now that we can safely access Parse we can use it in GetRecords<T>.

// In DatabaseConnectionProvider.cs
// In GetRecords<T>
// Replace everything after:  var reader = command.ExecuteReader();

        var returnList = new List<T>();
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                returnList.Add(new T().Parse(reader));
            }
        }
        connection.Close();
        return returnList;
    }
}

The query

Right now, we're in an interesting state. The GetRecords method is able to parse theoretically infinite data types, but it never will. Why? Because we've hard-coded a query into the command object that we're sending to the database.

Similar to what we did with the Parse method, we need to take away the DatabaseConnectionProvider's responsibility to choose the query it should run. That means that we're going to have to move the query up into a parameter, but, we run into a problem there.

If only add a string parameter to the method, but then we don't have access to the Command object.

So what?

The Command object is where we add SqlParameters. The only option that we would have at this point would be to use string interpolation to add the values in manually. Forcing users of our provider to build queries this way is not only poor etiquette, it is also a potential security vulnerability. Microsoft has already (hopefully), done a lot of work to secure this Command object against SQL injection attacks. No matter the sanitation that we do, adding the parameters to the correct property on the Command object is the smartest way forward.

In order to keep our provider's methods modular, we need to abstract this into a class that could be used in conjunction with any model that we create. It will wrap up our intended query with placeholders for parameter values, and a dictionary of our parameters. We'll call it DataCallSettings (naming is hard).

// DataCallSettings.cs
namespace Students.Models;

public class DataCallSettings
{
    public string SqlCommand { get; set; }
    public Dictionary<string, object> Parameters { get; set; } = new();

    public DataCallSettings(string command)
    {
        SqlCommand = command;
    }

    public void AddParameter(string name, object value)
    {
        Parameters[name] = value;
    }

}

This class is now the only parameter to GetRecords<T>. This is a significantly better developer experience than passing in positional parameters. This is a simple implementation, but if we ever decided to extend it to include support for stored procedures, retry logic, transactions or caching, we can do that without breaking our existing codebase.

Take a look at the finished method with all of the changes that we made.

// In DatabaseConnectionProvider.cs

public List<T> GetRecords<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()
{
    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        var command = connection.CreateCommand();
        command.CommandText = dcs.SqlCommand;

        foreach (var key in dcs.Parameters.Keys)
        {
            command.Parameters.AddWithValue(key, dcs.Parameters[key]);
        }

        var returnList = new List<T>();
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                returnList.Add(new T().Parse(reader));
            }
        }
        connection.Close();

        return returnList;
    }
}

As a bonus, I'll also give you two lines of code that will let us get single records using all the hard work we did earlier.

public T GetRecord<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()
=> GetRecords<T>(dcs).FirstOrDefault() ?? new();

The command

Sometimes you will want to issue a query to the database that won't return anything. So, our database interface isn't quite complete. We need to build a method that allows us to send database queries without creating an empty model at the end. It will look very similar to our GetRecords method, but we will use the .ExecuteNonQuery() method instead, and we'll call it Execute. Creative... I know.

// In DatabaseConnectionProvider.cs
// After GetRecord<T>

public int Execute(DataCallSettings dcs)
{
    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        var command = connection.CreateCommand();
        command.CommandText = dcs.SqlCommand;

        foreach (var key in dcs.Parameters.Keys)
        {
            command.Parameters.AddWithValue(key, dcs.Parameters[key]);
        }

        var result = command.ExecuteNonQuery();
        connection.Close();
        return result;
    }
}

This is fine, but we're duplicating some logic between GetRecords and Execute. Let's lift it into a fancy new BuildCommand method.

// In DatabaseConnectionProvider.cs
// After Execute()

private SqliteCommand BuildCommand(DataCallSettings dcs, SqliteConnection connection)
{
    var command = connection.CreateCommand();
    command.CommandText = dcs.SqlCommand;

    foreach (var key in dcs.Parameters.Keys)
    {
        command.Parameters.AddWithValue(key, dcs.Parameters[key]);
    }

    return command;
}

And refactor both methods to use it.

// In DatabaseConnectionProvider.cs

// In GetRecords<T>
    connection.Open();
    var command = BuildCommand(dcs, connection);

    var returnList = new List<T>();

// In Execute()
    connection.Open();
    var command = BuildCommand(dcs, connection);

    var result = command.ExecuteNonQuery();

Ah, much better. But, we're not done yet. Let's add one more method that we will wind up using a lot in practice. When we perform an INSERT, the database will set the identity column, so let's make sure that we get that back out.

// In DatabaseConnectionProvider.cs
// Below Execute()

public int ExecuteWithIdentity(DataCallSettings dcs)
{
    if (!dcs.SqlCommand.StartsWith("INSERT"))
    {
        throw new InvalidOperationException();
    }

    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        dcs.SqlCommand = $"{dcs.SqlCommand} SELECT last_insert_rowid();";
        var command = BuildCommand(dcs, connection);

        var identity = Convert.ToInt32(command.ExecuteScalar());
        connection.Close();
        return identity;
    }
}

And with that... drumroll please.

We've done it! We've created, by hand, an way to interact with a database that is extensible and easy to use.

The repository

Now that we're done creating this database interface, I want to quickly walk through how you can use it. One design pattern that I use daily is the repository design pattern. This is a fancy (and admittedly somewhat confusing) name that we can give to a file that wraps up our data transfer logic, keeping our modules less coupled.

Adding a separate layer allows us to ignore the database's implementation details when we finally want to send this data to a front end somewhere. So, let's create a StudentsRepository.

// StudentsRepository.cs
using Students.Abstractions;
using Students.Models;

namespace Students.Repository.SQL;

public class StudentsRepository : IStudentsRepository
{

}

And here's the interface, complete with the methods that we're going to create.

using Students.Models;

namespace Students.Abstractions;

public interface IStudentsRepository
{
    Student GetStudent(int id);
    List<Student> GetStudents();
    int SaveStudent(Student student);
    bool DeleteStudent(int id);
}

Then, back in our repository, we will inject our DatabaseConnectionProvider. Make sure that it's registered in your Program.cs file first though. Here's an article that walks through DI in ASP.NET if you need some help with that.

Finishing the implementation now is as simple as calling the appropriate provider method with a DataCallSettings instance with a SQL query. Instead of walking through step by step, I'll just include the whole file below, so that you can see how it will look.

// in StudentsRepository.cs

public class StudentsRepository : IStudentsRepository
{
    private readonly IDatabaseConnectionProvider _provider;

    StudentsRepository(IDatabaseConnectionProvider provider)
    {
        _provider = provider;
    }

    public Student GetStudent(int id)
    {
        var dcs = new DataCallSettings("SELECT * FROM students WHERE Id = @Id;");
        dcs.AddParameter("Id", id);
        return _provider.GetRecord<Student>(dcs);
    }

    public List<Student> GetStudents()
    {
        var dcs = new DataCallSettings("SELECT * FROM students;");
        return _provider.GetRecords<Student>(dcs);
    }

    public int SaveStudent(Student student)
        => student.Id == 0 // new student
            ? InsertStudent(student)
            : UpdateStudent(student);

    private int InsertStudent(Student student)
    {
        var dcs = new DataCallSettings("INSERT INTO students (name, school) VALUES (@Name, @School);");
        AddStudentParameters(dcs, student);
        return _provider.ExecuteWithIdentity(dcs);
    }

    private int UpdateStudent(Student student)
    {
        var dcs = new DataCallSettings("UPDATE students SET name = @Name, school = @School WHERE id = @Id;");
        dcs.AddParameter("Id", student.Id);
        AddStudentParameters(dcs, student);
        return _provider.Execute(dcs) > 0
            ? student.Id
            : 0;
    }

    public bool DeleteStudent(int id)
    {
        var dcs = new DataCallSettings("DELETE FROM students WHERE id = @Id");
        dcs.AddParameter("Id", id);
        return _provider.Execute(dcs) > 0;
    }

    private void AddStudentParameters(DataCallSettings dcs, Student student)
    {
        if (student.IsNew) { dcs.AddParameter("Id", student.Id); }
        dcs.AddParameter("Name", student.Name);
        dcs.AddParameter("School", student.School);
    }
}

The conclusion

Okay, I'll admit that this more code than you probably need if you were using Entity Framework. But... it's not that much more. I find myself far more comfortable working in an application that has this level of transparency and flexibility than one that does mapping magic. To me, this is an easy trade-off.

This implementation isn't clever, it's not complicated, and it's easy to work with, even if it takes a little bit of getting used to. Over the past two years I've been programming, a significant percentage of bugs I deal with are caused by data being malformed. Maybe this is skill issues, but it has made me slightly paranoid about data handling in apps that I work on.

Using this pattern, it's being handled completely by me. If there's a problem, I know that it was something I wrote (read: something I can fix). I created the database, I wrote the SQL queries. Since I am responsible for this system, I want to know how it's handling my data.

This isn't to say that ORMs are bad. I might not be very good at working with them (see my reference to skill issues above). But, if you've never tried to use ADO.NET, I hope you feel that you have the tools to get started.

The Perfect Programming Environment

Nolan Miller — Fri, 15 Aug 2025 13:43:24 +0000

I often encounter programming terms and lingo that goes way over my head when I'm browsing software engineering content on the internet. I wish that I could say that I drop everything and search these terms as soon as I see them, but this is rarely the case. But, this article is about a time that I took my medicine and not only looked up something I didn't understand, but implemented it into my daily workflow.

The term? —dotfiles

Centralized and Modular Configurations

What are dotfiles?

Maybe you're more hip than I was, but if you're not, let me fill you in. Dotfile is technical shorthand for a hidden file on your system that provides configuration settings to your operating system, shell, or applications. Most systems' preferred method of hiding files s to add a . at the beginning of the file—hence, dotfile.

Many developers choose to alter these files to exert a level of god-like control over their own computers (i.e. to change the color of their terminal prompt... ). Having these files spread across the computer can make them difficult to update and maintain, so it's convenient to package them together into a personal dotfiles git repository.

Alright, you're filled in, and I'll admit that on the face of it, dotfiles sound pretty boring. I expected this project to fulfill my neurotic need to organize, but in the end, I found that it presented interesting challenges to solve, and that this project represents the only project that I've built that I use daily.

Why I created my own dotfiles

I hesitate to write this, but Pewdiepie (yes, the Fortnite streamer) was actually the first inspiration for this project. After watching him install Arch, I went down a rabbit hole of customization possibilities for my own devices.

The discovery of this video coincided pretty closely with the beginning of my transition to Neovim (by the way). Neovim's configurations are all stored in text files, text files that are notoriously easy to break and hard to recover if you've made too many changes at once. It's a good idea to keep these tracked in a git repository, and to change them intentionally so that you can run git reset HEAD --hard when the worst happens.

I am not an Arch Linux user quite yet, but my current OS's were another motivation. I work on Windows and do personal development on Mac. If I want to make a change to my dev environment, I'm adjusting it in two places. Not all of the applications that I use are cross platform, but I still like to keep as much of the workflow the same as I can. This means that I wind up translating keyboard shortcuts and other configurations from one DSL to another. This is much easier, when everything is centralized.

Writing my own version-controlled and modular dotfiles repository solves all of these problems. But, I'd be lying if I said that the primary reason wasn't just that I like to tinker, and this may be one of the most fun ways to explore your operating system.

Making it your own

In 2010, developer and startup advisor, Zach Holman, wrote a piece called Dotfiles Are Meant To Be Forked, where he argues that some of the best developers have horribly disorganized configurations, and that a dotfiles repo should be well designed, personalized and extensible. He ends the article with an encouragement to get started:

So, fork it. Or, if not mine, then fork some of the awesome other projects I mentioned. Or come up with your own way of organizing your stuff and share it. Everyone’s got their own way of streamlining their system, and sharing dotfiles helps everyone.

I would only alter this advice slightly. If you haven't created your own dotfiles repository before, start from scratch. Before going to see what other people have done, find out what problems you are trying to solve for your workflow. Once you've done this, digging into someone else's configurations can give you inspiration for things to change. But, I've found that adding configurations from others has led to creating features that I never use, and a more difficult to maintain repository that is cluttered with unnecessary configurations.

This might sound strange coming from a blogger who is about to tell you about his own dotfiles. My goal with this article is not to show you every inch of my configuration. In fact, I won't discuss most of the configurations at all. Rather, I want to give you a skeleton that will get your own repository working. The questions that I will answer today are: "How do I centralize my config files?" and "How can I make them modular?"

I'm hoping that removing this barrier makes it easier for you to joyfully discover your preferences, your operating system, and new tools and applications shared by the community.

Building Dotfiles

Centralizing configurations

The first problem to solve when creating a dotfiles repo is getting all of your configurations into one directory without breaking all of the software and firmware that read from them. These files are typically located in a few different locations on your computer. That means the configurations aren't portable or easily maintainable. To solve this we need a way to tell our computer where to look for our configuration files.

Luckily, the solution for this is built into your operating system. It's called symbolic linking or symlinking.

When we boot up, say, Neovim (by the way), the application tries to set its configuration by looking for files. By default, it goes to my user directory for this path ~/.config/nvim. We could just put the configuration files there, or we could put a symlink there that basically says, "This file that you're looking for is over there." The computer will redirect to the linked file or files and read them as if they are in the location of the symlink.

Let's take another example, a .zshrc file that contains some customizations on my terminal prompt. For my terminal to read this file, it has to be in my user directory. If I want to keep this file in my dotfiles repo I'll create a symlink at ~/.zshrc that points to /Projects/dotfiles/.zshrc. Now when the computer goes to ~/.zshrc it's invisibly redirected to the file at /Projects/dotfiles/.zshrc. My terminal can read its configurations and I get to keep them in a tidy folder with all my other configurations.

Implementing a link in a unix-based environment is as simple as running the command:

ln -sf [source] [link]

... where source is the file in your dotfiles and link is the location that you want to put the link.

The following script will allow you to quickly add source/link pairs.

# Create an associative array for source/target pairs
typeset -A links
links=(
  "$DOTFILES/mac/.zshrc" "$HOME/.zshrc"
  "$DOTFILES/mac/.zprofile" "$HOME/.zprofile"
  "$DOTFILES/mac/.zshenv" "$HOME/.zshenv"
  "$DOTFILES/shared/nvim" "$HOME/.config"
)

# Loop through each key in the associative array
for source in "${(@k)links}"; do
  link="${links[$source]}"
  backup="$link.backup"

  # Check if the link target or [target].backup exists
  if [[ -e "$link" && ! -e "$backup" ]]; then
      if [[ ! -d "$link" ]]; then
        # Backup any existing configuration files (just in case)
        mv -f "$link" "$backup"
        echo "Backed up: $backup"
      fi
  fi

  # This section handles making sure that parent directories exist
  #
  # Checking if the source is a directory and the
  # target doesn't exist
  if [[ -d "$source" && ! -e "$link" ]]; then
      mkdir -p "$link"
  else
      # We need to split the file name off of the path to 
      # create all the parent directories.
      parent_dir="${link:h}"
      mkdir -p "$parent_dir"
  fi 

  # Create the link
  ln -sf "$source" "$link"

  if [[ -d "$source" ]]; then
      echo "Linked ${source:t} directory to $link"
  else
      echo "Linked ${source:t} to $link"
  fi
done

As you need to centralize more files, and create more links, they can quickly be added to the links array at the top, and the links will automatically be created. As I encounter more configurations across my system that I'd like to change, it's very simple to add them here, link them, and run the script. The friction to making changes now is pretty much gone.

Making them modular

While having everything in one place makes things easier to maintain, if the files get unmanageably long, then that friction comes back. So, combining related configurations into well-named files is a must. I'll focus here on two methods to modularize your configuration files, one for language-based configurations and one for plaintext configurations.

If you're interested in the structure that I use to modularize the configurations of my different operating systems, check out the repository.

Scripting-Language Configurations

When splitting up configurations into multiple files, it's important to know the configuration language of the application. Sometimes, this is a Turing-complete language like Bash or Lua, but other times its a domain specific language (DSL) that can only be used with that piece of software.

When we scripting languages, the way that we make things modular is a bit more straightforward. Let's look at my .zshrc for example. I want to customize my prompt, add some functions and keep aliases as shortcuts to different locations on my drive. Since, the .zshrc is written in Zsh (very similar to Bash), I can organize my configurations into separate files like this:

dotfiles/
├── shell/
|   ├── aliases.sh
|   ├── functions.sh
|   └── prompt.sh
├── .zshrc
└── bootstrap.zsh

My shell is still going to look for a .zshrc file, not our modules. Instead of jamming all of our configurations in the file, we will tell it to look for our dotfiles repository and loop through the shell subdirector and source every readable file that ends in .sh.

DOTFILES="$HOME/Path/To/dotfiles"

for FILE in $DOTFILES/shell/*.sh; do
    [ -r $FILE ] && source "$FILE"
done

DSL / Plaintext Configuration

While DSLs can still be Turing-complete, many configuration languages aren't, which means that we don't have access to helpful things like conditionals or loops. To make modular configurations, we are going to have to construct the source files from our modules using a scripting language.

For my tmux configuration I have a similar directory structure to my shell configurations.

dotfiles/
├── tmux/
|   ├── theme.conf
|   ├── bindings.conf
|   └── general.conf
├── .tmux.conf
└── bootstrap.zsh

Notice that we still have a modular structure. But, our .tmux.conf file is written in plaintext, it's not executable, so we can't loop through the tmux/ directory there. Instead, we have to write a function that can write our .tmux.conf to use in bootstrap.zsh:

write_conf () {
    local dir=$1
    local out=$2

    cat $dir/* > "$out"
    echo "# Conf written on $(gdate)" >> "$out"
}

write_conf "$DOTFILES/tmux" "$DOTFILES/.tmux.conf"

Now for every plaintext configuration, we can write every file in a given directory to a single file. I also added a timestamp to the end of the file to make sure the bootstrap script ran properly.

Why I don't like forking

You can get a lot of ideas for your own configurations by perusing my dotfiles, or any of the dotfiles that many people share on reddit, or GitHub or other sites. However, I think that if you're just starting, forking someone else's configurations can side-step the the self-discovery and growth than comes from starting from scratch.

By all means, take inspiration from others, but the goal is to solve the problems that you have on your system. If you start with a fork dotfiles, you're getting someone else's solutions to someone else's problems. Often, these solutions have way more configurations that you want or need, because you're jumping into a repository that may have been built on for years. For me, that kind of starting point is overwhelming and adds friction when there are changes that I want to make.

But, they're your dotfiles.

So, do what you want. If you want to fork, fork. If you want to start from scratch, start from scratch. Nobody's opinion on your dotfiles matters because they are uniquely yours, for your computer, your workflow, and your enjoyment.

Happy scripting!

Quidditch - Powered By PostgreSQL and ASP.NET

Nolan Miller — Thu, 24 Jul 2025 19:24:06 +0000

As a software developer, it's important to work on your craft. That's why I've been studying ASP.NET for the past few months. In my last article I walk through how to set up an ASP.NET Minimal Web API. Today, I'll be building on that foundation, by adding a persistent data store, a la PostgreSQL. In order to configure a .NET API to communicate with a PostgreSQL database, I'm going to use Entity Framework.

Though I could have worked with my animal sounds API, I decided to implement the database for an app that scores a road trip game that my wife and I took this summer.
I recently saw a video about a new road trip game that's inspired by Harry Potter (my favorite book series). I knew that my wife and I had to try it. If you're interested, the rules of the game are described in this video, and you can play using my score tracker at https://quidditchtrip.nolanmiller.me.

In this article, I'll go over making sure that you have PostgreSQL installed and running, and then how to install and configure Entity Framework to read to and write from the database.

What you'll need to start:

A .NET Web API (that you've created using the dotnet CLI)
Access to an internet connection
A little bit of patience

Install Postgres

There are a few different methods to installing and starting a Postgres server on your machine, but the easiest route is downloading Postgres.app, a MacOS postgres server interface that comes bundled with the psql CLI. If you're not on Mac, or if you're interested in other installation methods the official Postgres website has installation instructions for every operating system and includes instructions for other installation methods.

Once you're done you should be able to start your Postgres server and also connect to it using the psql command line interface.

Create a database

Before we can start creating our models and writing data, we need to make sure that we have a database for our application. To do this, connect to psql using the following command:

psql -U postgres

This will connect us to the Postgres server with the default user postgres. If it prompts you for a password, it should be the default password, postgres.

Once you're connected you should see a prompt that ends with # and we can issue the following SQL command:

postgres=# CREATE DATABASE Quidditch;

Since this database is for my Quidditch app, I'll name it Quidditch, just replace this with whatever name makes sense for your application.

Connect to your database

With a database set up, it can be connected to our .NET application using Entity Framework, an object-relational mapper for the .NET ecosystem. EF will automate reading and writing data on our database, and handle table creation and modifications through the development process.

To get started with EF for Postgres, install two NuGet packages by running the following commands from a terminal in your .NET project:

dotnet add package Microsoft.EntityFrameworkCore.PostgreSQL
dotnet add package Microsoft.EntityFrameworkCore.Design

To interact with a database we have to create a database context to allow us to interface with the database, configure the context object to use the proper connection string, set up models and create a migration using EF that will scaffold our database.

1. Database Context

To create a database context, create a class that inherits from EF's DbContext class, like so:

using Microsoft.EntityFrameworkCore;

public class QuidditchContext : DbContext
{
    public QuidditchContext(DbConextOptions<QuidditchContext> options) : base(options) { }
}

Then wire it into your Program.cs file.

// in Program.cs
var connectionString = "[Your connection string]";
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<QuidditchContext>(options => options.UseNpgsql(connectionString));

This way of setting a connection string isn't secure, and should only be used for testing. Make sure that you load these in via a config file!

And with these two small additions, Entity Framework can access your database server.

2. Set up models

The next step in configuration is defining the models that we want to persist. For my Quidditch game, since it's a simple score tracker, I really only need to capture two data models: games and teams. Instead of creating two database tables for these and setting up their columns, I can just create the model in my C# code and EF will reason out the structure of the database!

public class Team
{
    public int TeamKey { get; set; }
    public string Name { get; set; }
    public int Score { get; set; }
    public bool IsActive { get; set; }
    public DateTime CreatedDateTime { get; set; }
    public int? GameKey { get; set; }

    [JsonIgnore]
    public Game Game { get; set; }
}

public class Game
{
    public int GameKey { get; set; }
    public DateTime GameStartDateTime { get; set; }
    public DateTime? GameEndDateTime { get; set; }
    public bool IsActive { get; set; } = true;
    public bool IsFinished => GameEndDateTime != null;

    public List<Team> Teams { get; set; } = new List<Team>();
}

A couple of things to point out here. First, I'm using the terminology [Entity]Key to define my primary keys. This is not automatically picked up by EF. They would prefer that you use [Entity]Id instead. Unfortunately, I am stubborn and would have been mistyping "Key" instead of "Id" of for the whole project, so I took the extra couple of steps to define my keys and relationships.

When I add these models to my database context in the next step, EF will use these models to set up tables and columns based on them. Not everything will be one for one though. There are two special properties here. The Team.Game property and the Game.Teams properties are called Navigations.

A Navigation property models a relationship between two tables. They work by associating related models using primary and foreign keys on the models and are kept in sync by EF.

Before these will behave as expected, we need to register these models in our DbContext with DbSet properties. This can be done as easily as adding properties to any other class, but set the type to DbSet<[Entity]> where [Entity] is the model that you want to register.

// QuidditchContext
public class QuidditchContext : DbContext
{
    public QuidditchContext(DbConextOptions<QuidditchContext> options) : base(options) { }

    public DbSet<Team> Teams { get; set; }
    public DbSet<Game> Games { get; set; }
}

The DbSet<> class comes from Entity Framework and inherits from IEnumerable<T>, which allows us to use LINQ (and some Entity Framework specific versions of LINQ) to access our models.

Since I decided to use a different convention for my primary and foreign keys, I have another configuring step to define the relationships between my tables. To manually define table and column relationships, override the OnModelCreating method in DbContext. The relationships that I used are below.

public class QuidditchContext : DbContext
{
    // ...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // .HasKey tell EF what the name of the primary key should be
        modelBuilder.Entity<Team>()
            .HasKey(t => t.TeamKey);

        modelBuilder.Entity<Game>()
            .HasKey(g => g.GameKey);

        // These methods define the one-to-many relationship in
        // what looks like plain language. 
        modelBuilder.Entity<Team>()
            .HasOne(e => e.Game)
            .WithMany(e => e.Teams)
            .HasForeignKey(t => t.GameKey)
            .OnDelete(DeleteBehavior.SetNull);
        // .OnDelete can set what happens to related tables
        // when the record they reference is deleted.

        // I don't want a table to be created for this model.
        modelBuilder.Ignore<LeaderboardEntry>();
    }

Even if you're not using custom naming for your properties, it is probably a good idea to override this method so that your complex relationships are explicitly set by you. This will help mitigate unexpected behavior and has the added benefit of providing some in-code documentation.

Now that configuration is done, it's time to create a database through a process called migration.

3. Create a migration

As you work on a project, inevitably the shape of your data will change here and there. Instead of manually updating your database tables, Entity Framework handles this through migrations.

Since the models are already defined in the code, Entity Framework can scaffold and re-scaffold database, throughout the lifecycle of the application. A migration can be created using the dotnet CLI with the following command.

dotnet ef migrations add InitialCreate

With dotnet ef the Entity Framework-specific tools are specified, and then using the migrations add command a migration is created called InitialCreate. A migration can have any name, but it's a good idea to give it a descriptive title for when you need to roll your changes back.

To finalize the changes on our database (or "creation of" in this instance) we still have to run one more command. EF separates this process of updating the database into two steps. In the first step, a few things happen:

a Migrations directory is created in the root of your project if not already there
a [TIMESTAMP]_InitialCreate.cs file is generated, containing the steps to implement the changes to your context, and steps to walk it back if needed.
a [TIMESTAMP]_InitialCreate.Designer.cs file is generated with metadata for EF to use.
a MyContextModelSnapshot.cs file containing a current snapshot of your context model is created.

The syntax in these files is fairly easy to interpret, so it's a good idea to do a once-over of the Up method in the [TIMESTAMP]_InitialCreate.cs method so that you aren't surprised by any changes!

Now to finalize those changes and apply them to the database run the following command.

dotnet ef database update

This will updates the database to the most recent migration. Be careful as you do this, there is potential for data loss when running this command! Now, the database and it's tables are set up and ready for you to start querying!

Using LINQ to access your data

To illustrate how to query a database using Entity Framework, take a look at one of the service methods that I created for my application:

public async Task<ServiceResponse<Game>> GetGameByKey(int gameKey)
{
    var game = await _context.Games
        .Include(g => g.Teams)
        .SingleAsync(g => g.GameKey == gameKey);
    if (game == null) { return ServiceResponse<Game>.Failure("..."); }
    return ServiceResponse<Game>.Success(game);
}

If you're familiar with LINQ syntax, then this should be familiar.

public async Task<ServiceResponse<Game>> GetGameByKey(int gameKey)

First, I'm declaring a method called GetGameByKey, that returns a custom response object with the generic type Game. I just created a response class with a generic Payload property so that I can send back metadata along with the requested models if needed.

var game = await _context.Games
        .Include(g => g.Teams)
        .SingleAsync(g => g.GameKey == gameKey);

This line queries the database, translating the database record into a usable model and assigning it to a variable that we can return from the method! By default, navigation properties are not included, but using .Include() and specifying the navigation property includes the related navigation in the query.

Query execution is signaled by the .SingleAsync() method, which works the same way as .Single() in LINQ. So this query, will return a only a single record where the GameKey column's value is equal to the gameKey argument passed in when this method is called.

Here's another method example:

public async Task<ServiceResponse<Game>> SetGameInactive(int gameKey)
{
    var gameResponse = await GetGameByKey(gameKey);
    if (!gameResponse.WasSuccessful) { return gameResponse; }
    var game = gameResponse.Payload;

    game.IsActive = false;
    _context.Games.Update(game);
    var changedRows = await _context.SaveChangesAsync();
    if (changedRows < 1) { return ServiceResponse<Game>.Failure("Failed."); }

    return ServiceResponse<Game>.Success(game);
}

There's a little more logic going on in this method. The goal is to find the Game with the matching GameKey and then set its IsActive property to false. The Game is retrieved in the same way as the first method we looked at. Once it's been accessed, then it's properties can be updated like any other class instance in C#.

The _context.Games.Update() method prepares EF to send the command to the database. Unlike the first query, the execution is started by SaveChangesAsync(), which returns the number of affected rows. This is the EF pattern for modifying existing data. The changes are made in the code, and SaveChanges() or SaveChangesAsync() must be called.

I hope that this shows just how simple it can be to access the data from a database using familiar C# list patterns. For a full list of methods available to Entity Framework, check out their documentation.

Summary

If you made it this far, thank you for reading! I hope that you found it helpful and I wish you the best of luck in implementing EF Core into your own C# applications.

This was a unique challenge for me. I primarily write in C# for my job, but we use a custom data access library that requires mapping our models manually. While Entity Framework has some nice quality-of-life features, I found that lose some of the flexibility gained by writing your own SQL.

This was a very simple project, but even still, it felt like I didn't save much time by using an ORM. Rather than save time on having to write SQL, I traded that time for configuring my database and tables in C#.

In my day job, I rely on libraries that have been provided for me, so I'm looking forward to learning how to implement database connections on my own. I don't know that I would choose to use Entity Framework again. I liked how easy it was to set up my models and navigations made implementing business logic very nice, but the configuration of relationships just wasn't as straightforward as it is in SQL.

Regardless, it is always good to take some time to learn new technologies.

Thanks again for reading!

Intro to .NET APIs for a JavaScript Developer

Nolan Miller — Tue, 27 May 2025 12:34:27 +0000

When I was applying like crazy to developer jobs, I'd scroll past so many .NET focused ones, thinking, "I'm only a JavaScript developer."

I felt lied to.

The internet told me "JavaScript can do it all," but, I felt like the skills that I'd learned would never land me a job. When I did find a primarily JavaScript job, it always had so many applicants that I felt like I didn't have a chance.

As of October 2024, JavaScript was still the second most used language on GitHub (though it was just over taken by Python). Check out this blog post from GitHub. But even though there's so much JavaScript code, that doesn't mean that the job market for it is thriving.

In my experience, the jobs with a .NET focus on job boards were:

... looking for more experience, but appeared to be more flexible.
... were paying higher starting salaries, and
... not attracting very many applicants AT ALL.

JavaScript's reputation for being easy to learn, means that WAY MORE people know it, paradoxically requiring you to be even more experienced to compete in the job market.

I just started programming, I can't code in C#!

The first time I looked at C#, it was intimidating. Sure, it uses curly braces, but the boilerplate code is deeply nested, I don't know any of the libraries available, and EVERYTHING IS IN PASCAL CASE.

The .NET ecosystem is a mature, reliable framework used to develop stable applications in many environments, but it can feel pretty unapproachable to newbies.

But, C# has a template that will feel very familiar to an intermediate JavaScript developer. A starting place, where you can begin to create useful apps and also begin to wrap your mind around the syntax and features of C# in ASP.NET.

An unconventional starting point

Start with a simple API. To be more specific, use the Minimal API template. The MVC model, especially when you're starting out, can be overwhelming. So, why start with an API? Because it's a simple way to integrate .NET into something that you're already working on. Have a React application? Well then let it consume your ASP.NET Minimal API as the backend.

You'll probably be surprised that the things you learned as a JavaScript developer (especially if you're using Express.js to build your APIs), will have strong carry over into the .NET ecosystem.

So, let's get up to speed on what a Minimal API even is, and then I'll walk you through how to get your own Minimal API up and running by the end of this post!

What Are Minimal APIs?

With .NET 6, Microsoft released Minimal APIs. This is opposed to the Controller-based API pattern that is common in .NET. Minimal APIs is that remove a lot of unnecessary boilerplate code that you need to create endpoint routes in a controller-based APIs.

Here's why this is good news for Javascript developers looking to get into .NET. The removal of this boilerplate code makes the syntax look very similar to the syntax used to build an API on Node with Express.js.

Side-by-Side Comparison: Express.js vs. Minimal APIs

To show you how approachable this can be, I'm going to create a GET and POST route and point out the similarities between the C# Minimal API version and the Express.js version

So let's set up the .NET Minimal API first.

// set up api
using Microsoft.AspNetCore.Mvc;

namespace MinimalAPI
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);
            var app = builder.Build();

            // ... add endpoints and middleware here

            Console.WriteLine("Server is running on port 3000.");
            app.Run("http://localhost:3000");
        }
    }
}

If this syntax is new to you, let me walk you through it. We're first referencing the Microsoft.AspNetCore.Mvc which contains the Builder class that we will use to construct our application. We call the build() method on the builder and then run our application while specifying the port.

Now, to set up the same application on Node in Express.js we would write the following.

// set up express app
const express = require('express');

const app = express();

// ... add endpoints and middleware here

app.listen(3000, () => {
    console.log("Server is running on port 3000");
})

Notice how similar. We require Express, which abstracts our builder logic. Then we run the application, specifying the port!

Creating Endpoints

The syntax is even more similar between these two frameworks for endpoint creation. Using the app that our builder created we the correct endpoint verb creation method to create the endpoint listener. In ASP.NET, this will look like this.

app.MapGet("/", (HttpRequest request, HttpResponse response) =>
{
    return "Hello World";
});

This pattern is nearly identical to what we would write in Express.js.

app.get("/", (req, res) => {
    res.send("Hello World");
})

In both the Minimal API and the Express API, we pass the endpoint route as the first parameters, and the callback function as the second.

Get started with ASP.NET

If you're tired of seeing job postings you feel that you can't apply for, then start learning C#! It doesn't have to be scary, or overly complex. And, I hope that I've shown that with the knowledge that you have already, you can get started in creating a useful application that has the potential to solve real world problems.

There are numerous free resources to get started with the basics of C#, and if it's your first strongly typed language, there will probably be some hurdles. But, once you get through the initial learning phase, so many of the skills you've already developed will transfer over.

Over the past several months, I've been diving deeper into ASP.NET. Check out some of my posts that detail my journey!

Learn Application Configuration in ASP.NET

Nolan Miller — Mon, 24 Mar 2025 12:20:52 +0000

As a self-taught developer, a part of software development that I didn't know much about when I started my first development job was configuration.

When I was building solo projects, it was hard to see the value in loading configurations rather than just hard coding. Why would I introduce complexity? It would take time learn how to load them in. Maybe I'll learn how to do it later, but that's just a waste of time.

I knew that these thoughts weren't true, but the excuses kept me from learning. As I got some experience with larger codebases, however, I started seeing the clear need for configuration objects. We have to able to change specific behaviors of our application without releasing. This is what enables us to connect one release of an application to different databases or APIs, to change features for development or production, and make many other important changes.

If you follow along with this article, we will create a basic console application that shuffles through the titles of songs to demonstrate how to load values into a configuration object and access them to change functionality in .NET.

Let's create a music player!

Okay... only sort of. Unfortunately, we won't be sending anything to your speakers. For the purpose of learning how to load and use configurations within ASP.NET, I created a console application called SongShuffle!

To follow along with the sections in this article, go ahead and clone the GitHub repo by running the git clone command below in your console.

git clone https://github.com/nmiller15/SongShuffle/

I've created branches to guide you through the codebase in this article, at any point you can checkout the branches and arrive at a working application at a different step! I encourage you to experiment and load some of your own configurations and functionality here though!

To make sure you're on the correct branch, run the following in your console.

git checkout 1-start

A tour of our music player

If you launch the SongShuffle console application by clicking Run/Debug, or using dotnet run in the project directory, you will see a modest user command line interface that asks you to press any key to start listening.

The song screen shows the title, artist and year of the current song's release at the top of the screen and will allow you to select a new song by pressing enter. If you type in q before pressing enter, the program will exit.

This is the basic function of the music player that we will configure. Go ahead and play around with it!

Take some time to familiarize yourself with the classes that we have here that create the behavior for this application: Song.cs and SongProvider.

If you're digging around in the song bank in the SongProvider, you might notice that we only have 80s music loaded into the application. While this might be all that I play, others might want their music player to be a bit more versatile, so this is going to be the first configurable feature that we are going to add to the music player.

Configuring for the 90s groove

To add this feature, we have to add another song bank and a way to select those banks. To see my implementation, run the following command in your console.

git checkout 2-pick-a-decade

Most of our changes are in the SongProvider class. I've added three more song banks, containing music from different decades. I've created an Enum Decades that will select the song set for the SongBank. And I've added a switch statement in the SongPovider constructor, that sets the SongBank property.

With these changes the SongProvider is able to change its selection of songs without having to alter it's implementation details. We've now moved control of the song bank selection outside of the provider. That means that we'll have to define our Enum to pass in before we can instantiate our SongProvider.

// SongProvider.cs
public SongProvider(Decades decade)
{
    switch (decade)
    {
        case Decades.Eighties:
            SongBank = EightiesSongs; break;
        case Decades.Nineties:
            SongBank = NinetiesSongs; break;
        case Decades.TwoThousands:
            SongBank = TwoThousandsSongs; break;
        case Decades.TwentyTens:
            SongBank = TwoThousandTensSongs; break;
        default:
            throw new ArgumentException("Must include a valid decade.");
    }
}

// Program.cs
public static void DisplaySong()
{
    var userResponse = string.Empty;
    var decade = SongProvider.Decades.Nineties;

    var provider = new SongProvider(decade);

    // ... 
}

And now we can rock out to some Madonna!

If we wanted to change the decade we can do that a bit more easily now, but its still a developer task. Someone without any code experience would have issues working with this. We'd have to go in, change the value of the Decades Enum. Then, we'd also have to create a release and push it.

Man... That's a lot of work for a small feature.

So, we've moved the song bank selection out of the SongProvider but, what if we pull it out of the application itself. This would keep us from having to deal with this release issue.

Loading our first configuration

Checkout the next branch to see how we can load values into our .NET program from external files.

git checkout 3-config-from-json

The first thing I'd like to point out is the LoadConfig() method that I've created which has a fairly straightforward goal.... to load the configuration. But, how is this handled in .NET?

static void Main(string[] args)
{
    var config = LoadConfig()
    Welcome();
    DisplaySong(config);
}

The configuration interface

Microsoft has an IConfiguration interface built into the framework. The interface allows us to attach key-value pairs from multiple sources and then access them later. These values are what we will use to configure parts of our application.

The LoadConfig() method that I created, just returns an instance of IConfiguration loaded with our configuration values. The configuration object that is returned by this method will be passed around our application with values being accessed and determining app behavior.

Accessing values from a config object

There are a few ways that we can use to access these values. First, is using the Indexer syntax, borrowed from the dictionary.

var value = configuration["KeyName"];

This is the way that we will access them throughout this article, but also know that .NET provides other ways to access complex configuration objects using methods like .GetSection() and .Bind(). If you'd like more information on those, check out this article from Microsoft's documentation.

Registering key-value pairs to a config object

The most common way to register key-value pairs is through an appsettings.json file. This is a file that contains a valid JSON object that sits at the root level of your project.

Note: It is common for appsettings.json to be checked into source control, so do not store sensitive data like API keys or connection strings here.

In our example appsettings.json, we have a simple JSON object that defines a "Decade" key.

{
  "Decade": "TwoThousands"
}

Now, to add this file to our configuration object, we need to use the built-in ConfigurationBuilder and use the AddJsonFile method. Pass the relative path of the JSON file that you want to add to register the key-value pairs inside it.


public static IConfiguration LoadConfig()
{
    var builder = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json");
    return builder.Build();
}

When we run LoadConfig() any values that we have in our appsettings.json file will be accessible within our application in our IConfiguration object!

Using our configuration object in the application

To actually make use of this IConfiguration object, we have to pass it into our DisplaySong method. You can take a look at the necessary changes below.


public static void DisplaySong(IConfiguration config)
{
    var userResponse = string.Empty;

    var decade = config["Decade"] switch
    {
        "Nineties" => SongProvider.Decades.Nineties,
        "TwoThousands" => SongProvider.Decades.TwoThousands,
        "TwentyTens" => SongProvider.Decades.TwentyTens,
        _ => SongProvider.Decades.Eighties
    };

    var provider = new SongProvider(decade);
}

With this method, the selection of the decade is decoupled from the logic that displays the song. The selection of the decade is being set outside of our application.

If this isn't working for you...

Try the following steps if the configuration isn't loading for you.

Right click on appsettings.json in Visual Studio.

Properties > Copy To Output Directory. Make sure it is set to "Copy Always".

What did I just do?

Your application runs from the /bin/Debug/netX.X directory when you run your application in Debug mode. When Visual Studio tries to compile and run your project, it's looking for the appsettings.json file relative to the file that it complied (in the bin).

By setting the "Copy Always", whenever we click "Debug" our appsettings.json will be copied into /bin/Debug/netX.X so that we can access it in our program.

While we don't have to release another version of the application to change this behavior, it's still a little bit involved. We still have to find the right text file and change the correct value to get this to happen. Now let's explore how we can change the behavior of our application without having to edit any additional files!

Passing command-line arguments

With only a few changes to our application, we can take in strings from outside the application by allowing command line arguments. Run the following command to see the changes.

git checkout 4-config-from-commandline

You may not notice the change at first because it's so small, but there is one. We've added one line which calls the .AddCommandLine(args) to the ConfigurationBuilder.

public static IConfiguration LoadConfig(string[] args)
{
    var builder = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json")
        .AddCommandLine(args);
    return builder.Build();
}

By chaining this to the .AddJsonFile() method, we're adding all the values from both to our configuration object.

Command line arguments are key-value pairs declared after the execution command. To attach a key-value pair you would run the program like this:

dotnet run --Decade "TwentyTens"

The key "Decade" would then be passed into the program with the value "TwentyTens". Luckily, we don't have to type these arguments into the program every time we want to Debug our program.

In order to add a command line argument to your Debug profile, first, right-click your project and click Properties.

In that window, select Debug from the sidebar, and click Launch Profiles UI. After you click this, you will see the following UI window. Under Command line arguments you can type in anything you like.

Command line arguments can be passed in four different syntaxes.

[command] --key value
[command] --key=value
[command] /key value
[command] /key=value

I'm not sure what the advantage of having these different syntaxes is, but I prefer the first, since it is the most common way that I've seen arguments passed.

Didn't we just pass `"Decade"` twice?

If never removed our appsettings.json file, it's still being loaded into the configuration with a Decade key, meaning that the "Decade" key was loaded twice.

Our ConfigurationBuilder doesn't handle key collisions. It doesn't check to see if a key has already been assigned before binding a value to it.

What does this mean?

If you have two configuration files or methods that assign the same key, the key that was loaded earlier will be overwritten by the one loaded later.

If you go back to the appsettings.json file, you'll see that we still have a "TwoThousands" value there. That value was successfully loaded, but immediately after that, our command line argument with the same key overwrote it with its value "TwentyTens". In our final configuration object, the key "Decade" will have the value of the command line argument.

This behavior allows us to keep configuration files that are subsets of other configuration files. Take for example an application that uses a different API in production and development. We can create a config file that only have the values that we need to overwrite, like a API key and endpoint that is only loaded in development.

var builder = new ConfigurationBuilder();
builder.AddJsonFile("appsettings.json");
if (env.IsDevelopment())
{
    builder.AddJsonFile("appsettings.development.json");
}
return builder.Build();

If you're going to use this approach, make sure to be mindful of the order that you add your files and configuration sources in. There are no priority rules, so keys will always be overwritten load methods later in the chain.

Environmental influence

There may by instances in which multiple applications will all share the same configuration values if they're running in the same environment. In that case, we can also load these into our program. Run the following command to see the changes that we make:

git checkout 5-environment-variables

Just like the above methods, environment variables will be added as key-value pairs . It goes beyond the scope of this article to talk about how to set these on various systems, but I'll show you how you can set them in Visual Studio for development.

If you open up the Launch Profiles UI that we accessed to set our command line variables (Properties > Debug > Launch Profiles), you can also set environment variables!

Since we already have sources defining our decade, let's use a new variable ShowImage that we will use to decide whether or not you see my beautiful ASCII rendering of an iPod.

In the Environment Variables section, under "Name", write "ShowImage", and for it's value, type "false".

Now to access these when we run our code, all we need to do is add the .AddEnvironmentVariables() method to our ConfigurationBuilder.

public static IConfiguration LoadConfig(string[] args)
{
    var builder = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json")
        .AddCommandLine(args)
        .AddEnvironmentVariables();
    return builder.Build();
}

All we have to do to get this configuration up and running is to use our Boolean conversion in an if statement and put our image inside it.

public static void DisplaySong(IConfiguration config)
{
    // Additional setup ommitted for space

    while (userResponse != "q")
    {
        song = provider.ShuffleSelect();

        Console.Clear();
        Console.WriteLine();
        Console.WriteLine($"Now playing {song.ToString()}");
        Console.WriteLine();

        if (config["ShowImage"]?.ToLower() == "true")
        {
            Console.WriteLine(@"
                ╔═══╗
                ║███║
                ║(O)║♫ ♪ ♫ ♪
                ╚═══╝
            ▄ █ ▄ █ ▄ ▄ █ ▄ █ ▄ █
            ");
        }

        // ...
    }
}

Now, our iPod will only be displayed if the configuration is set to "true".

But, I like to see my ASCII masterpiece while I'm "listening" to music, so I'm going to change this configuration back!

It's worth noting here that this is a fairly atypical usage of environment variables. Since both environment variables and command line arguments come in as strings, it isn't wise to use them as Booleans or integers or any other type unless you're parsing or validating them into another object.

Let's add one more configuration to this application, I'd like to make the songs play automatically, but again, I don't want to have to change any code. I could add another configuration in a JSON file or any of the other methods that we've discussed, but I want to show you how to do this with a .NET-specific solution, User Secrets.

Setting up User Secrets in .NET

See the code changes to accept user secrets by running the following command, but keep it open, we'll have a few more to run to make sure that we're all set up.

git checkout 6-user-secrets

User Secrets is a Microsoft-created, development-only solution for storing sensitive strings outside of source control. It's built right into the .NET SDK and makes loading sensitive information into your application very simple for development.

You do not want to use this in production because this offers no encryption for your sensitive information, you would be better off using some sort of secrets manager.

How does User Secrets work?

User Secrets is very similar to adding a JSON file to your application. We will create a file with key-value pairs and tell the framework where to look for the file.

We identify the file using the <UserSecretsId> tag with a Guid value in our .csproj file. Then in our %AppData%\Microsoft\UserSecrets\{project-guid} we can store our secrets in a file called secrets.json.

Don't worry though, you don't have to set this up manually.

Setting up User Secrets

Using the .NET CLI, all we have to do is run one command to get set up.

dotnet user-secrets init

When you run this command a few things happen:

an ID is created
the ID is saved to your .csproj file in a <UserSecretsId> tag
a directory named for the ID is created
a secrets.json file is created

The CLI also provides us a method of adding values to our secrets.json file without having to dig through our user directory.

dotnet user-secrets set {key} {value}

Using User Secrets to auto-play our songs

In our LoadConfig method, we only have to add one line to bind our user secrets.

public static IConfiguration LoadConfig(string[] args)
{
    var builder = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json")
        .AddCommandLine(args)
        .AddEnvironmentVariables()
        .AddUserSecrets<Program>();
    return builder.Build();
}

We also have to add a little logic to our DisplaySong method to create our auto-play behavior.

public static void DisplaySong(IConfiguration config)
{
    var userResponse = string.Empty;
    var counter = 0;

    var decade = config["Decade"] switch
    {
        "Nineties" => SongProvider.Decades.Nineties,
        "TwoThousands" => SongProvider.Decades.TwoThousands,
        "TwentyTens" => SongProvider.Decades.TwentyTens,
        _ => SongProvider.Decades.Eighties
    };

    while (userResponse != "q")
    {
    // ... existing logic remains unchanged ... after 

        if (counter == 4)
        {
            Console.WriteLine("You've listened to 5 songs! Want to keep going?");
            Console.WriteLine("(Type q to quit.)");
            userResponse = Console.ReadLine()?.ToLower();
            counter = 0;
        }
        if (config["Autoplay"]?.ToLower() == "true")
        {
            Thread.Sleep(2000);
            counter++;
        }
        else
        {
            userResponse = Console.ReadLine()?.ToLower();
        }
    }
}

These variables also come in as strings, so they carry the same warning as environment variables did above.

Adding the `"Autoplay"` key

Run the following command to write the "Autoplay" key to our secrets.json file.

dotnet user-secrets set "Autoplay" "true"

We can quickly check what keys are accessible in our secrets.json by running the following command:

dotnet user-secrets list

Oh no! Did you verify and see that you misspelled something? That's okay, we can remove the key using:

dotnet user-secrets remove {key}

... or, we can clear out all the keys by using:

dotnet user-secrets clear

... and you can add the key again to correct any misspellings.

And we're done! If we start up our application, now, a new song will appear on the screen every two seconds until 5 consecutive songs have played!

Misusing configurations

As I previously stated in some asides, this is a wild misuse of the ConfigurationBuilder, but I believe it demonstrates the ways in which you can pass data from different sources into your application.

So, if this is wrong, what is the right way to use a configuration object?

The most common use-cases for configurations are storing connection strings for databases, external API keys for authentication, setting logging behaviors, to turn on and off features, and configuring environment-specific variables.

While we may not be using it to select the specific decade of music that you're listening to, you no longer have to look at your Program.cs file and wonder how these values are making their way into the projects that you work on.

Using configurations on your own

In your next project, give the ConfigurationBuilder a try! A good time to think about this is in the deployment phase of your next personal project.

What are the lines of code that you're changing because you're about to load the application on another machine? These are great candidates to load into an IConfiguraiton object!

If you're getting value out of these posts, consider subscribing using the link below to receive these posts straight to your inbox!

Click here to subscribe!

Interviewers Will Ask You About This: .NET Dependency Injection Made Simple

Nolan Miller — Mon, 24 Feb 2025 16:21:34 +0000

My heart rate was elevated and my hands were clenching the plush armrests of a very comfortable chair in a board room. He knew.

After thinking about it way too long, I'd just called a singleton a factory method in a code example that was broadcast onto one of the two flat screens on the far wall.

"So, what do you know about dependency injection?"

Strike 2. I remembered reading something about this when I was panic studying for this interview, but I didn't really understand it. "I've... um... never used it before, but I think I understand the concept..."

Sigh. This is over isn't it.

Since I started teaching myself to code, one of the things that's frustrated me the most about this space, is how big all the freaking words are. Dependency Injection? What is that? What does it mean to have a dependency? What the heck is injecting it?

I struggled through figuring this out so that you don't have to. The concept is not as hard as it might seem, and it can dramatically increase your code quality. If you're self-taught, this is a concept that will come up in job interviews, because in any project of a reasonable size, it is probably being used.

Let's dive in, so that your interview doesn't go how mine did.

What is a dependency?

In short, a dependency is a piece of code that is depended upon for functionality.

When we talk about dependencies, we will talk about clients and services. The client is the class that depends on something else, the class that takes the injection. The service is what is injected, it is the dependency.

It's not always this clean though. Often services will also have a long list of dependencies, creating a chain of interrelated classes. But, to keep things simple for now, we'll just focus on the relationship between one client and one service.

Real World Dependencies

Dependencies don't only exist in your IDE. This pattern is modeled after the real world, as many concepts in object oriented programming are.

If you live some distance from your workplace, it is likely that you are dependent upon a car. You are the client, and the service is your car! A dependency relationship.

Let's quickly create a program that reflects this relationship. First let's create a person and give it some properties.

public class Person
{
    // Descriptors that are related to a person
    public string Name { get; set; }
    public string Workplace { get; set; }
    public int Age { get; set; }

    // A constructor for our class.
    public Me(string name, int age)
    {
        Name = name;
        Age = age
    }
}

public class Program
{
    public static void Main(string[] args)
    {
        // An instance of Person with my information
        var nolan = new Person("Nolan", 27)
        nolan.Workplace = "Certified Angus Beef"
    }
}

Now, lets create a car, and use it to get to work!

public class Car
{
    // ... Properties

    public bool Drive(string destination)
    {
        Console.WriteLine($"Arrived at {destination}");
        return true;
    }
}

public class Person
{
    // ... Properties and things

    public void GoToWork()
    {
        // Becuase this class needs instantiated
        // for this behavior to work, it is a 
        // service that Person depends on.
        Car car = new Car();

        var hasArrived = car.Drive(Workplace);
        if (hasArrived) { Console.WriteLine("Made it to work!") }
    }
}

This is all a dependency is. Try looking at some of your own real world relationships and identifying the dependencies that you have. What people do you rely on? What possessions? etc.

There's nothing wrong with relying on other people or things to accomplish goals and tasks, but it does become a problem when these things we rely on are the only way we know how to accomplish those goals.

In this example, the only way that the Person class knows how to GoToWork is by using a Car. We have to use this implementation of Car no matter what. What if Car breaks? We can't borrow a car, or get a rental? We need to introduce more flexibility into this class.

Create flexibility with interfaces

I thought this was an article on dependency injection.

Yes. It is. But, the concept of interfaces is tightly coupled with dependency injection... 😉

To solve our problem of rigidity in GoToWork, let's say that at minimum we need a vehicle to get to work. I don't care what kind it is, how many wheels it has or what kind of gas it takes, I just need it to be able to drive.

We can create an interface for that:

public interface IVehicle
{
    bool Drive(string destination)
}

Now, with one tweak to our GoToWork method, we begin to decrease our reliance on Car specifically.

For the sake of illustration, let's say that my Car has broken down, I still need to get to work. So, instead I'll use my wife's SUV to get there!

public class SUV : IVehicle
{
    public bool Drive(string destination) { ... }
}

public class Person
{
    // ... Properties and things

    public void GoToWork()
    {
        // Using the interface we created,
        // we can add any implementation 
        // of a vehicle here now.
        IVehicle vehicle = new SUV();

        var hasArrived = vehicle.Drive(Workplace);
        if (hasArrived) { Console.WriteLine("Made it to work!") }
    }
}

Now that we've achieved some flexibility, we need to address another issue. If we were to translate this GoToWork method back to real life, we'd notice something strange.

Every time this person tries to go to work, they're building a vehicle (and taking it back apart once they get there).

Not very smart is it?

But, who cares, this isn't real life.

Well, no, but there are two programming-related reasons that we don't want to build our dependency inside our method. Single-responsibility, and efficiency.

The way our code is built right now violates the single-responsibility principle. This feature of object-oriented design states that the components of our application should have one responsibility. GoToWork, despite the name, doesn't just GoToWork. It creates an outside class instance and goes to work.

What if I want to create a GoToSchool method? Or a GoToTheStore method? I'd have to duplicate my code in every one of the methods (violating the DRY principle). Now imagine that my Car breaks again, and I need to use the SUV class! I need to change it in every place I create that class.

It's also less efficient. Every time I need to use the Drive method, I need to create a new class instance. With a small class like this, there may not be much performance overhead, but as classes get bigger and code gets more complex, this becomes an issue. What if I wanted to track the mileage on the car? Or know how many trips it took? This becomes far more complex if every time I'm using the Car I create a new one.

We can solve this though. You might think that we can just move the implementation into a property and instantiate it there, but we can take this one step further, by removing the creation of the instance outside of the class entirely.

Injecting your first dependency

Let's start by adjusting our Person class to make sure that we have somewhere to store the dependency. We don't want our class methods to be able to adjust it, and we don't want it to be accessible outside of our class either, so we'll use a private readonly field.

public class Person
{
    private readonly IVehicle _vehicle;

    // Other properties and things
}

Now... we inject.

We're going to create a constructor that has IVehicle as a parameter, then we assign this parameter to our new field.

public class Person
{
    private readonly IVehicle _vehicle;

    // Other properties and things

    // Inject the IVehicle through this
    // constructor
    public Person(IVehicle vehicle)
    {
        _vehicle = vehicle;
    }
}

Now take a look at how this simplifies our GoToWork method:

public class Person
{
    private readonly IVehicle _vehicle;

    // Other properties and things

    public Person(IVehicle vehicle)
    {
        _vehicle = vehicle;
    }

    public void GoToWork()
    {
        // This will now work with any implementation
        // of IVehicle!
        var hasArrived = _vehicle.Drive(Workplace);
        if (hasArrived) { Console.WriteLine("Made it to work!") }
    }
}

The reason the GoToWork method is simplified is because it is no longer responsible for choosing an implementation or creating an instance of IVehicle. That now takes place outside of the Person class entirely!

Take a look at how we might call the GoToWork method.

public class Program
{
    public static void Main(string[] args)
    {
        // Pick and instantiate an IVehicle
        IVehicle car = new Car();
        var nolan = new Person(car);
        nolan.Workplace = "Certified Angus Beef"

        nolan.GoToWork();
    }
}

This is the basic concept of dependency injection. Notice that our Main method actually got a bit more complex. While the design pattern has its advantages, like testability, separation of concerns and single-responsibility, one of the tradeoffs is that we have made our code a bit more complex to work with.

Luckily for us, we can take advantage of all the benefits of this pattern and sidestep some of this complexity by letting a DI framework do the work of injecting the instances for us.

Inversion of control with DI containers

There are many DI frameworks, but the one we'll go over today is the DI container that's built into ASP.NET. No matter the framework that you're using, the goal is the same: automatically provide services to clients that are generated by your framework. Put simply, to inject your dependencies.

The concept is called Inversion of Control. Instead of the client controlling the dependencies that it has, the control structure is flipped. The framework is given control over the dependencies and the client is allowed to use it.

All these "i" terms...

It is important to make a distinction between the terms **interface, **implementation, and **instance*. Naturally... they all had to start with "i".

An interface is a set of specifications for class definitions. A contract.
An implementation is a definition of a class that adheres to that interface or contract.
An instance, is the usable object with property values and behavior that represents a real-world object. The class definition in actual use somewhere.*

Just remember: Create **instances* from implementations of interfaces.*

When we're using a DI container, we have to bind (either manually or automatically) our interface requests to an instance that implements it. When you define a relationship between an interface and an implementation to the DI container, it will fulfill any request for the interface with the bound implementation.

You can also explicitly attach implementations without an interface. When this is done, the framework will respond directly to requests for that implementation with the implementation.

In the following example, we will look at how to bind interfaces and implementations as this is the most common pattern that you will see.

Bind services to your DI container

To illustrate how to bind services to your DI container, we will start in the context of an ASP.NET MVC application. The main method of this creates a web app builder. Taking advantage of boilerplate middleware, the controllers and views are collected and instantiated by the framework.

Let's take simple web application that displays facts. It has a FactsController with a few routes and related Views. Let's create this controller now.

public class FactsController : Controller
{
    public FactsController()
    {
    }

    public IActionResult Index()
    {
        return View();
    }
}

We will take for granted that we have a view for Index and that we have a FactsViewModel that will hold a Fact string that we can display.

Now, we want to generate random facts. We could put all of that logic here in a private method, or in one of our action methods, but that would violate the single responsibility principle and make our project much harder to maintain.

So, let's inject a service to do that for us!

public class FactsController : Controller

private readonly IFactGenerator _factGenerator;

public FactsController(IFactGenerator factGenerator)
{
    _factGenerator = factGenerator;
}

public IActionResult Index()
{
    var viewModel = new FactsViewModel();
    // The Generate method takes an enum value that lets
    //   us choose the category of fact that is generated.
    // The Fact property of our FactsViewModel is then displayed
    //   in the Fact.cshtml view.
    viewModel.Fact = _factGenerator.Generate(FactTypes.Animal);

    return View(viewModel);
}

This looks very similar to what we did above with our manual dependency injection. We defined a field _factGenerator, injected the interface through the constructor, and then we accessed the method of our service from within our client: the .Generate(FactTypes) method.

However, this won't work yet.

We still need to bind our service within our DI container. We do this by adding a service to the service collection on our WebApplicationBuilder. So head over to Program.cs and add the following line.

public static void Main(string[] args)
{
    var builder = WebApplication.CreateBuilder(args);

    // AddSingleton<TInterface, TImplmentation>
    // This line creates a singleton instance of a service.
    // Whenever this interface is called, the instance created by
    // the builder will be delivered.
    builder.Services.AddSingleton<IFactGenerator, FactGenerator>();

    // This is added by the template
    builder.Services.AddControllersWithViews();

    ...
}

Now, if we boot up our application and navigate to /Facts we should see the output of the FactGenerator. Using the .AddSingleton method, we have told the DI container that wraps our application, "Whenever a class that you build requests an IFactGenerator, give them the instance of FactGenerator that you've created."

Deciding what instance to be delivered using binding

In addition to the .AddSingleton() method, we can also make decisions about which instance of our implementation is injected by our DI container.

We can use singletons, transients, or we can scope our instances. Here's how each of these behave:

.AddSingleton() - Only one instance of this type will be created. Every request for an implementation will be fulfilled with the same instance.
.AddTransient() - For every request for a service, a new instance will be created to fulfil it.
.AddScoped() - For every request made of the application (not the DI container) a new instance will be created. The same instance will be used for the duration of the request.

To illustrate how this works, I've adjusted the FactGenerator and the FactController to show off the differences between the binding types.

In my FactGenerator, I've made it so that each instance can only generate one unique fact. After the .GetFact method has been used, it will return the initially generated fact. This will give us a very clear look at the instance lifetimes.

In FactController, I've created Action Methods for Singleton, Transient and Scoped. These correspond to more or less identical views that all use the FactsViewModel.

To get the facts for these views, I've bound and injected 6 different fact generators, two of each binding type. With two of each, we can explore the differences in lifetime between transients, singletons, and scoped.

public class FactsController : Controller
{
    private readonly TransientRandomFactGenerator _transientRandomFactGenerator1;
    private readonly TransientRandomFactGenerator _transientRandomFactGenerator2;
    private readonly SingletonRandomFactGenerator _singletonRandomFactGenerator1;
    private readonly SingletonRandomFactGenerator _singletonRandomFactGenerator2;
    private readonly ScopedRandomFactGenerator _scopedRandomFactGenerator1;
    private readonly ScopedRandomFactGenerator _scopedRandomFactGenerator2;

    public FactsController(
        TransientRandomFactGenerator transientRandomFactGenerator1,
        TransientRandomFactGenerator transientRandomFactGenerator2,
        SingletonRandomFactGenerator singletonRandomFactGenerator1,
        SingletonRandomFactGenerator singletonRandomFactGenerator2,
        ScopedRandomFactGenerator scopedRandomFactGenerator1,
        ScopedRandomFactGenerator scopedRandomFactGenerator2
    )
    {
        _transientRandomFactGenerator1 = transientRandomFactGenerator1;
        _transientRandomFactGenerator2 = transientRandomFactGenerator2;
        _singletonRandomFactGenerator1 = singletonRandomFactGenerator1;
        _singletonRandomFactGenerator2 = singletonRandomFactGenerator2;
        _scopedRandomFactGenerator1 = scopedRandomFactGenerator1;
        _scopedRandomFactGenerator2 = scopedRandomFactGenerator2;
    }
    ...
}

Let's take a look at how we can call these generators from our action methods.

Singleton binding

// Program.cs
builder.Services.AddSingleton<SingletonRandomFactGenerator>();

// FactsController.cs
public IActionResult Singleton()
    {
        var viewModel = new FactsViewModel();
        var fact1 = _singletonRandomFactGenerator1.GetFact(FactTypes.Space);
        var fact2 = _singletonRandomFactGenerator2.GetFact(FactTypes.Animal);
        viewModel.Fact = fact1;
        viewModel.Fact2 = fact2;
        ViewData["Title"] = "Singleton";
        return View(viewModel);
    }

When we bind our SingletonRandomFactGenerator and inject it twice, once for each fact. What do you think the output will be?

We got the same fact back! Why is this?

When we bound the SingletonRandomFactGenerator implementation to our builder as a singleton, only one instance is created. We called for an injection twice in our controller and the same instance was delivered to both references. So, it didn't matter that we called the GetFact method again on our second reference, we still got the same fact back since the GetFact method only returns one unique fact.

Let's see how this is different with a transient binding.

Transient binding

// Program.cs
builder.Services.AddTransient<TransientRandomFactGenerator>();

// FactsController.cs
public IActionResult Transient()
{
    var viewModel = new FactsViewModel();
    var fact1 = _transientRandomFactGenerator1.GetFact(FactTypes.Space);
    var fact2 = _transientRandomFactGenerator2.GetFact(FactTypes.Animal);
    viewModel.Fact = fact1;
    viewModel.Fact2 = fact2;
    ViewData["Title"] = "Transient";
    return View(viewModel);
}

In this example, we are calling for two injections of TransientRandomFactGenerator, just as we did with SingletonRandomFactGenerator. And this is the output that we get:

Two different facts!

Since we used AddTransient, when we call for two different injections of the same implementation, two separate instances are injected. So when we call GetFact on the first, it doesn't affect the second!

Now that we understand the difference between transient and singleton, let tackle scoped, which is a little more subtle.

Scoped binding

// Program.cs
builder.Services.AddScoped<ScopedRandomFactGenerator>();

// FactController.cs
public IActionResult Scoped()
{
    var viewModel = new FactsViewModel();
    var fact1 = _scopedRandomFactGenerator1.GetFact(FactTypes.Space);
    var fact2 = _scopedRandomFactGenerator2.GetFact(FactTypes.Animal);
    viewModel.Fact = fact1;
    viewModel.Fact2 = fact2;
    ViewData["Title"] = "Scoped";
    return View(viewModel);
}

With this action method set up the same as the other two, what do you expect will happen?

Hm... the same fact? So... it's a singleton?

It is. But, only for a while.

When we called for two injections of the generator here, it built them upon request. Since the calls for both of the injections happened on the same request, we got the same instance injected for both, just like a singleton.

We can create a second request by refreshing the page.

After our refresh, we get a new fact! This is due to the fact that once we entered a new request, a new instance was generated and injected.

This still seems like it's just a singleton.

Yep, I get it. They're very similar. But, watch what happens if I click back over the the singleton.

The same fact as the first time we loaded the page!

The singleton binding doesn't care that we've made a separate request. It is still delivering that exact same instance to our controller no matter what.

If I click back over to see the scoped binding, we will get yet another random fact!

Wrapping up

Now you don't have to be nervous like me in your next interview. If you've never worked with dependency injection before, take an afternoon and create a small project like this one to get a handle on some of the concepts.

I would suspect that a great majority of codebases use dependency injection in some form or another, and if you're self-taught it's a topic that doesn't seem to come up in the learning paths online.

Thanks for taking your time to read this, and it is my sincere hope that it makes your life and coding journey a bit easier than mine was!

If you found value in this, share it with a friend who wants to learn about dependency injection!

Interested in getting these blog posts direct to your inbox?

Click here to sign up!

Cure Depression with Software Development

Nolan Miller — Wed, 19 Feb 2025 17:56:41 +0000

Quotes in this post are courtesy of Liam Galvin in his article, Despair-Driven Development: Harnessing Malaise for Effective Software Engineering

Anxiety and depression are at all time high levels this generation, and rather than pointing fingers at causes, Liam Galvin points to a solution: develop more software.

No joke! Liam's outlook, while bleak, is that developing software and achieving the flow state is the only escape from a reality filled with despair for some.

For many despair-driven developers, flow state is the closest thing to peace. It is not joy in the traditional sense but an absence of suffering, a momentary relief from the crushing weight of existence. While the world outside may be collapsing, in the confines of a well-structured function or an elegant algorithm, there is clarity, purpose, and even a strange form of tranquility.

Liam's cheeky "Despair-Driven Development" model champions pragmatism a functionality. He says that this is the model that those with steep requirements and little support fall into, and in some ways, it makes them better at their jobs.

In a despair-driven mindset, there is no time for over-engineering or gold-plating solutions. The key question shifts from “Is this the best way?” to “Will this work well enough to avoid catastrophe?” The result is a stripped-down, functional approach that prioritizes what actually matters over idealized abstractions.

There's something to be taken here, even if you aren't as ruthless as Liam.

A snatched moment in the quiet focus of a well-structured function can provide something resembling peace. And sometimes, that is enough.

Do The Work That Needs Done

Nolan Miller — Tue, 11 Feb 2025 14:51:06 +0000

Quotes in this post courtesy of BrainBun Labs in the article, I conditioned myself to fail.

This article from BrainBun hit a little too close to home. I want to start a business, or sell a product, or something. But, I know that there's something that's holding me back. I think that it might be what the author talks about here.

Today I think I finally figured out what’s causing it.

I became an information junkie over the years.

That’s right, I’m addicted to information. I get my dopamine from feedback, from new information.

When I’m building something, that information is the thing coming to life in front of my eyes, every new button etc is awesome. I can see the changes in the UI from the code I’m writing.

But then when I launch, I either don’t get much feedback at all, or I get a lot of feedback for a day, which then dies down completely after the launch.

And I can’t find the motivation to get back to work.

For me, I will quickly launch myself into a project, or a new technology to learn, and then my focus changes when the work actually gets hard. I tell myself, "Well this actually isn't pushing the needle." But, that's not true always.

But, I also avoid doing the hard work by doing the opposite too. I'm in the middle of a larger project that I will use as an excuse to put off working on something that would actually start my business.

The constant mantra, is "I need to learn more about X to do that." It is the first thing that I think when I get a piece of business advice, but it would be better to take Noah Kagan's advice "Now, not how."

I partly blame the algorithmic feeds a la Twitter/X. It’s a lot easier to get your dopamine from reading than it is from building.

Take action. Be naive. Look stupid. Make mistakes.

Can we add AI to that?

Nolan Miller — Mon, 10 Feb 2025 18:19:13 +0000

Quotes in this article are courtesy of Lawrence Jones in his article, Beyond the AI MVP: What it really takes.

A little over a month ago, I was in a conference talk about the value of adding AI to products. The speaker asked the room, "Who has been asked to incorporate AI into a product you've already developed in the past year," and the amount of hands up around the room was staggering.

While it may seem simple on the face of it to load up a model and incorporate a chat interface in your app, the software development lifecycle around AI is much different than traditional software.

Lawrence Jones argues that there are many challenges that you don't see up front. He points out that you need robust test suites, hefty ai-integrated programs to evaluate ai responses, a test runner, and hosting strategies to keep costs manageable. On top of all of this, the languages of many of the frameworks is in the way:

Honestly, writing the tests themselves is the easy bit! Almost all AI tools and frameworks are written in Python, reflecting the origins of AI in the research teams who built the models and the machine-learning community who first adopted them.

But most product teams don’t use Python, which means you need to create a lot of these tools from scratch. That’s big undertaking, and almost no one is talking about how to integrate this stuff into a normal software development lifecycle.

The biggest issue with AI is what Jones calls the "Deceptive MVP." Have you built a basic chat interface with OpenAI's API? It's not all that difficult or complex to do, and if you're using a framework you're familiar with, you could probably piece something together in an afternoon. But, once you begin adding requirements for this application, and expecting it to behave in deterministic(-ish) ways, you're going to run into issues.

You start iterating on your MVP, trying to improve it. But as you add complexity, the system becomes increasingly unpredictable. You’re making changes based on vibes, improving some edge cases while (invisibly) breaking others.

This is the stage 90% of companies building AI are in. You can even see it in FANG: the AI features Google have added to GCP feel very much like an engineers first attempt to use an LLM in a product, spitting out terrible SQL suggestions in BigQuery. Apple’s message summarisation features cross-pollinating between messages and providing horribly inaccurate headlines is another.

Adding AI to an application is not just a peel-and-stick solution that will dramatically increase the impact of your product. While it may be easy to implement, if you're making any meaningful measurements of the efficacy of your product, it will be much, much, much more difficult.

Adding the connection to an API, or downloading and hosting a model for your codebase to interact with is the easiest part of the product development stage. Brainstorming ways to leverage this technology in a meaningful way, ensuring that it performs tasks reliably, and setting up systems to monitor the efficacy of your product are where your time is going to be spent. So, before you think about building out your AI side-project, thinking that you'll be able to turn this into the next big thing, make sure to evaluate the massive hidden costs first.

The companies that will succeed with AI won’t be the ones with the biggest budgets, access to the latest models, or even the most ML expertise. They’ll be the ones that invest in understanding their systems, that build the tools to measure and improve them, and that take the time to do things right.