The API for FlightNode is essentially structured along the lines of the onion architecture concept. Follow that link for a full description of the concept. Because my graphics toolkit is currently limited, my diagram for FlightNode has boxes instead of concentric onion-looking circles…

This release candidate nearly wraps up the user management and volunteer work tracking functionality. There are a small few “should have” features that will be added in a future release. So what’s new?

Back in the ’90s, I remember my parents saying that it was less expensive to inspect their cars in Plano, in Collin County, than a few miles further south in Dallas County - because of the additional emissions inspections required in the latter. I never would have imagined that 20 years later, ten DFW counties are now in non-attainment for smog-producing ozone pollution - and we still have no plan to solve the problem.

The .NET projects for FlightNode were created in several different Git repositories, thus giving us several small, well-contained, and re-usable projects. These small projects would be installed into the Service project as NuGet packages, which also makes for a faster compile in each discrete solution:

The first beta release of FlightNode is now alive and in the hands of testers. So what’s been delivered?

Wow, you’d think nothing had been happening for the past two months. But that’s not the case at all. There are now 6 different GitHub repositories (perhaps a few too many). November and December were heads-down coding months. But now the product is almost ready for an MVP launch… and that has me thinking about error handling. Specifically, logging.

Twenty-something years ago, not long after the Exxon Valdez disaster, I wrote a research paper on solar power for my middle school Earth science class. I’ve been trying to lower my consumption, and looking forward to rooftop solar, ever since. The wait is finally over.

In order to run FlightNode locally: