Hawk Notes, Volume 3

I just rolled out a new feature for my blog: Series.

Back when I was working for the IronPython team, I would write series of posts on a single topic, such as writing an IronPython debugger or using IronPython's __clrtype__ metaclass feature. I've also written series on building parsers in F#, a step-by-step guide to brokered WinRT components and the home grown engine I use for this blog. And with the new job, I suspect I'll be writing even more.

So I decided to make series a first class construct in my blog. You can go to a top level page to see all my series. Or you can go to a specific series page, such as the one for Hawk Notes. One thing I really like about Series is that they display in chronological order. That makes reading a series like the IronPython Debugger much easier to follow.

Implementing Series was fairly straightforward...or at least it would have been if I hadn't decided to significantly refactor the service code. I didn't like how I was handling configuration - too much direct config reading that was better handled by options. I made some poor service design decisions that limited the use of dependency injection. Most of all, I wanted to change the way memory caching worked so that more data loaded on demand instead of ahead of time. I also took the opportunity to use newer language constructs like value tuples and local functions.

I still have two different sources for posts - the local file system and an Azure Repo. I used to use Azure Storage but I got rid of that source as part of this refactoring. I have a simple interface PostLoader1 which the AzureGitLoader and FileSystemLoader classes implement. In order to select between them at run time, I have a third PostLoader implementation named PostLoaderSelector. PostLoaderSelector chooses between the sources based on configuration and uses IServiceProvider to activate the specified type from the DI container. PostLoaderSelector gets the IServiceProvider instance via constructor injection. I couldn't find a good example of how to manually activate types from ASP.NET's DI container, so for future reference it looks like this:

public Task<IEnumerable<Post>> LoadPostsAsync()
    // Look Ma, a Local Function!
    PostLoader GetLoader()
        switch (options.PostStorage)
            case BlogOptions.PostStorageType.FileSystem:
                return serviceProvider.GetService<FileSystemLoader>();
            case BlogOptions.PostStorageType.AzureGit:
                return serviceProvider.GetService<AzureGitLoader>();
                throw new NotImplementedException();

    var loader = GetLoader();
    return loader.LoadPostsAsync();

  1. Note the lack of the "I" prefix for my interface type names. Death to this final vestigal Hungarian notation!

Hawk Notes, Volume 2

Obviously, I've been pretty bad about keeping this blog up to date. That applies to both the content of the blog as well as the blog engine. Frankly, the last time I updated my blog code before last weekend was four years ago. At the time, ASP.NET Core was still called ASP.NET 5 and the latest version was Preview 7. Before posting my recent announcement, I thought it might be a good idea to get this blog running on a released and supported version of ASP.NET Core.

Once I got my code updated to the latest version of ASP.NET, I decided actually add some functionality. When I built Hawk, I focused primarily on how the site was going to render my existing content. I didn't give much though to how I would write new blog posts. That turned out to be a bad decision. Getting new posts published turned out to be such a huge pain in the butt that I bothered to write new posts. With the new job, I want to go back to blogging much more often. So I figured I should update the engine to make publishing new posts easier.

As I wrote in my previous Hawk Note, Hawk loads all the post metadata into memory on startup. It supports loading posts from either the file system as well as from Azure Storage. The master copy of my posts are stored in their own Visual Studio Online Visual Studio Team Services Azure DevOps Repos. Moving posts from the git repo into azure storage turned out the be the biggest publishing obstacle. So I decided to eliminate that step. If you're reading this, I guess it worked!

Since Hawk already supported loading posts from two different repositories, it was pretty straight forward to add a third that reads directly from the Azure Repo. I also added code to render the markdown to HTML using Markdig, eliminating the need to use Edge.js1.

Originally, I decided to store my blog posts in what is now called Azure Repos because it offered free private repos for personal use. While GitHub now offers free private repos, I've decided to keep my posts in an Azure Repos because I find the Azure DevOps REST interface much easier to wrap my head around than GitHub's GraphQL based approach. Yeah, I'm sure GraphQL is the better approach. But I was able to add the ability to load posts from Azure Repos in roughly 150 lines of code. For now anyway, easy and proven beats newer and more powerful.

Hawk pulling from the Azure Repo is the first step for creating a simple publishing process. Next, I will to set up a service hook to automatically trigger a Hawk refresh when I push to the post repo master branch. Eventually, I also want to add image publishing and maybe some type tool to help author the post metadata (auto set the date, auto slugify the title, validate categories and tags, etc). I also want to re-enable comments, though social media makes that somewhat less important than it was back in the day. Regardless, I figure it's best to tackle improvements incrementally. Last thing I want is another long silence on this blog.

  1. Note, I might not use Edge.js in Hawk anymore, but I still think Tomasz Janczuk must be some kind of a wizard.

My Next Adventure

Friday June 7th will be my last day at Microsoft.

I've been at Microsoft longer than I've been a husband, longer than I've been a father, longer than I've lived in the Pacific Northwest. It's been an awesome twenty year plus ride, but the time has come for me to take on new challenges.

I'm joining NEO Global Development's brand new Seattle office (which is really in Redmond). NEO is a community driven open source project delivering the technical underpinnings for the Smart Economy. NEO Global Development (aka NGD) is the technical R&D arm of the NEO Foundation, the NEO project's governing body. I'm going to be the Chief Architect for the Seattle office.

This move will reunite me with former colleague and long-time friend John deVadoss. I worked for John for back in my Architecture Strategy Team days. John is the director of NGD's Seattle office and I'm thrilled to be working with him again.

I had the privilege of presenting at NEO DevCon back in February. It was inspiring to meet folks from NEO's global community. NGD's main office is in Shanghai, NSPCC is in St. Petersberg, NeoResearch is in Brasil and the City of Zion community has team members from all corners of the Earth. I can't lie - the opportunity to work with this far reaching and diverse global community was a big selling point for me joining NGD Seattle.

NGD Seattle's primary focus is on developer tools and experience ('natch) for the NEO platform. John and my-soon-to-be-colleague Longfei Wang previewed a few things we're working on last month at Consensus 2019. In particular John showed off NEO Express Node, a private NEO blockchain management tool that I built. Of course, the Consensus preview is just a small taste of what we plan to deliver - especially once I join NGD full time and we build out more of our Seattle based engineering team.

While developer experience will be my primary focus, I also expect to pitch in on the core NEO platform. NEO 3.0 development is already in full swing. Core platform might not be my focus, but platform capabilities and developer experience go hand in hand. I'm sure I'll have plenty of opportunity to contibute to the core as we work towards our 3.0 release.

I'll miss Microsoft - especially the amazing people I've had the opportunity to work with over the years. It's particularly hard to leave the xlang project. Cross platform language projection has been a passion project of mine for several years now. Knowing xlang is in the capable hands of folks like Ben, Scott, Ryan and Kenny does make it easier. Besides, xlang is open source so I can still submit PRs if I get really Microsoft-homesick, right?