Problem​

I had just upgraded NuGet packages - a seemingly innocent thing to do. Everything compiles fine and I tried to run my ASP.NET WebAPI service. Testing in Postman works fine, but when I try to let the browser call an endpoint (any endpoint), I get a mysterious 500 server error with a rather unhelpful payload message of {"message":"An error has occurred."}. However, even with Chrome accessing the service, a breakpoint in the endpoint showed me that the code was executing fine. The problem is clearly occurring inside the ASP.NET engine when trying to send the response back to the browser.

The Yellow-rumped Warblers and Dark-eyed Juncos have been back and enjoying our back yard for several weeks now. This year, the warblers have decided to trust our bird bath - we've frequently seen them drinking and bathing over the past several weeks. While the Blue Jays have still been coming round, and we've had several sightings of Orange-crowned Warbler and Ruby-Crowned Kinglet this fall, I hadn't seen a Bewick's Wren in quite some time. Thus I was delighted to see this guy a few days ago. The light isn't very good, and the window is a bit dirty, but the ID is clear.

On Friday, the flood waters were fully receded on the Elm Fork of the Trinity River. With only a trace of rain on Saturday, I noticed on Sunday afternoon that the Elm Fork had returned to a flood warning. The Army Corps must have released water from one of the upstream lakes again. Quickly airing-up my tires, I raced down to Sam Houston Park in the hope of crossing the recently revealed causeway and seeing whom I could find on the levee-side of the lake. Alas, I was already too late. But the hour spent at the tantalizingly-small open (to bikers & peds) part of Sam Houston was well worth it the ride.

Great stories moves us. They do not only move us: indeed, they instill the desire to move. But it is we, the reader or audience, who choose where to go, and what to do.

Moving stories comes in so many packages, though one man's great may be another woman's banal. Tonight I watched an episode of Star Trek: Deep Space Nine that fulfilled all of the promise of social commentary through science fiction. This was in your face; the banal was banished; my comfort and ease were disturbed; and yet I was left with hope by the end.

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.

Just looking at the smog, we all know it can't be good for any of us. The American Lung Association has a good article on the health effects of ozone pollution. Moreover, studies have shown that air pollution in general has a disproportionate impact on Latino and African-American communities.

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:

1. FlightNode.Common
2. FlightNode.DataCollection
3. FlightNode.Identity

But… this has approach has caused problems.

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.

Originally I decided to look into NLog for .NET logging, a product I've never used before. I have experience with the Enterprise Library logging block and with Log4Net, and find them both to be useful but not as... pleasant... as I would like. They don't have the interface I would prefer. But they work. It turns out NLog has basically the same interface, and the same tedious configuration.