Image via Pinterest (

The Future of Federal Safety Oversight, originally published at

— — — — — — — —

Dear Honorable Pete Buttigieg

The subject of my writing today is to introduce the life-saving opportunity that the leader and future leaders of the Department of Transportation, and other government safety oversight organizations, have before them, provided by the unique benefits of technology and, especially, modern data analysis.

I do not write today in my professional compacity, in which I help develop digital applications for the Department, or to suggest that my opinion is shared by those with whom I worked while…

This code strikes me as exceptionally readable - due to good work by the author and/or the advancements in language syntax.

Cloud-Based System Architecture for the Federal Domain, originally published at

— — — — — — — —

This article describes a proposed system architecture for a cloud-based, web-centered enterprise-level system for use within the federal government domain.

This is written in the context of a notional scenario in which the architecture is being described to an interested system stakeholder, though one who may not be an expert in system infrastructure and design.

Things to note before we jump in:

  1. This is a bit of a work in progress. And represents a “jack-of-all-trades / master of none” approach. …

Agile Software Development in the Federal Government Domain, originally published at

— — — — — — — —

As a web developer, the word “agile”, when used in the context of product implementation work, sometimes seemed to me to be little more than the corporate, flavor-of-the-month buzz term.

Now, as a product manager, overseeing the development of an application, the team building it, and interactions with the stakeholders requiring it, agile methodologies have proven to me to be invaluable to implementation success.


Utilizing the Scaled Agile Framework for Lean Enterprises (SAFe®), we’ve delivered an internal tool for…

Migrating From MongoDB to SQL, originally published at

— — — — — — — —

This blog recounts my Veterans’ Day, 2020 project — migrating data from MLab to a SQL database on Azure.

Problem Statement:

  • As a user, I want to be able to view a revised log of Steve’s daily runs.
  • As a developer, I want to migrate data from the old run log, on MLab, to a new run log hosted on Azure with data stored in a SQL Server database.

This isn’t a tutorial. There was work completed previously that isn’t addressed in detail…

This article is a work-in-progress and, hopefully, the first in a series as we learn more about implementing the Okta API.

In my role at my company, I do mostly system architecture but, on the side, play around with prototypes and build out proof of concept models.

So, primarily, I’ve recently been developing the solution for incorporating Okta into a user role management implementation for an enterprise application on behalf of our client and, supportive of that, have been doing some of my own building to better learn the Okta API. …

In search of the all-encompassing, enterprise-level user role management / authentication service provider.

Because there may be fruitful relationships to be had with these organizations, their real names are being disguised in this sordid tale. Let’s call the Identity-Proofing provider: “ApexOpus”. And the user role management provider: “Tako”.

If some endeavoring venture capitalist would like to endow me with resources in funds and engineers, I’ll guide the development of the needed service described below with return value that will surely be worthy of the initial investment. Hello Masayoshi Son. How do you do, Y Combinator?

What follows is the frustrating…

I’ve begun building a rudimentary fake dating app. For practice purposes.

(Coding practice, I mean.)

Two aspects about a dating app provide especially valuable learning opportunities for the developer:

  1. Working with data;
  2. Unique design features;

To briefly elaborate:

A dating app requires users. Our users, of course, will be notional. But each user will nevertheless have associated data: name, age, location, biography, etc. Working with that data will allow us practice with fundamental JavaScript tools, especially in regards to iterables: Tools to helps us splice and push to arrays, query arrays for objects by id, map through arrays, etc.


Today, let’s explore some thoughts about the unit tests we’re adding to the ReactJS / .NET Core feature we’ve been building throughout this series.

(If you need to catch up, please click HERE.)

In coming updates, we’ll dive deeper into the actual implementation of unit tests, such as arranging tests, performing test actions, writing assertion statements, using test runners, etc.

Today, I just want to discuss briefly some of the “big picture” issues we will have to address when adding unit tests to the .NET Core Web API portion of our project.

So, consider today’s post the introduction to the…

We interrupt your previously scheduled broadcast…

My most recent posts have shared progress building a new ReactJS / .NET Core feature for my personal site (, and deploying it to the cloud via Microsoft Azure. That series is continuing.

But this post is not that. Though, related.

After the conclusion of Part 5 of that series (as in “now”, the time of the present writing), our lingering objective is to implement unit testing. Which, in fact, I’m doing.

(Sneak preview: It involves lots of xUnit and Moq.)

But here’s the thing about writing unit tests (for me, anyway): Whereas developing…

Steve Bogucki

Agile development team manager and process truster.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store