Okay, look, if there's one thing I'm tired of, it's half-baked example code that doesn't anticipate changes needed to push it into production.

Like the good ole WeatherForecastController from the .NET Core WebAPI template.

using Microsoft.AspNetCore.Mvc;

namespace MyApp .Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", 
            "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
        };

        private readonly ILogger<WeatherForecastController> _logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
        }

        [HttpGet(Name = "GetWeatherForecast")]
        public IEnumerable<WeatherForecast> Get()
        {
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = Summaries[Random.Shared.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

I mean, Visual Studio immediately complains:

Remove this unread private field '_logger' or refactor the code to use its value.

Well, duh. We have an endpoint with no logging. When would we need to log? Probably when we're doing something more complicated than creating random 8-ball style forecasts.

So let's pretend it's more difficult, throw in a try... catch, and actually log the exception.

[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()
{
    try
    {
        return new ActionResult<IEnumerable<WeatherForecast>>(Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        }));
    }
    catch (Exception e)
    {
        _logger.LogError(e, "Something failed");
        return BadRequest("that didn't work");
    }
}

Guess what? Now we got TWO errors! YAY!!

1. CS0029 Cannot implicitly convert type 'Microsoft.AspNetCore.Mvc.ActionResult<System.Collections.Generic.IEnumerable<MyApp.WeatherForecast>>' to 'System.Collections.Generic.IEnumerable<MyApp.WeatherForecast>'
2. CS0266 Cannot implicitly convert type 'Microsoft.AspNetCore.Mvc.BadRequestObjectResult' to 'System.Collections.Generic.IEnumerable<MyApp.WeatherForecast>'. An explicit conversion exists (are you missing a cast?)

Dare you to tell me what to do next. Heck, I don't know. I do know WebAPIs have been around so long there are tons of wrong answers on the net.

Let's just show one example that does work and call it a day.

[HttpGet(Name = "GetWeatherForecast")]
public ActionResult<IEnumerable<WeatherForecast>> Get()
{
    try
    {
        return new ActionResult<IEnumerable<WeatherForecast>>(Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        }));
    }
    catch (Exception e)
    {
        _logger.LogError(e, "Something failed");
        return BadRequest("that didn't work");
    }
}

Why do I need to wrap the return type with ActionResult to be able to return BadRequest REST code? I don't know man. It should implicitly cast imo into any hard type return value. I mean it's not like we're literally returning IEnumerable<WeatherForecast> in the original code. We are doing some magic behind the scenes to make that a JSON return value for our consumers. Why not do the same for any REST code convenience type too?

Anyhow, I just want to remember this trick for the next time it happens so to the blog it goes.

:sigh:

Labels: .NET, c#, noteToSelf, web API

Grubes on the economics of Android and Chrome:

Chrome makes no money at all on its own. It’s just a funnel for Google Search. Android maybe sort of kind of makes a little money for Google on its own, through the sale of Pixel devices, but it’s negligible. Like Chrome, Android really only exists as a funnel to keep users using Google search and within the broader Google digital ecosystem.

The best counterargument I could come up with was that both serve as first-party digital private investigators, which is likely worth something, though even that ultimately reduces to "broader Google ecosystem" which, itself, also seems to reduce down to search. Does Google sell its behavioral analytics data?

There's an interesting example of the power of this surveillence in The Trust Engineers podcast. Facebook had somewhat naively demonstrated that they had users [nearly everyone?] involved in several A/B style psychological tests at once, and were modifying feeds in ways that seemed to change those users' outlooks on life in general. Horrible ethical optics, and it sounds like potentially horrible ethical outcomes. Can you convince people to shop more? Spend more in specific categories? Give to charities less? Support fringe causes? Change political positions? Break family bonds? Etc.

I guess that's the power that Android and Chrome bring, though there is a bit of an underpants gnomes feel in here somewhere. Either this stuff is so effective I completely miss it or my inclination is accurate: They really don't know how to sell me music, books, goods that I actually like yet, even with all the extra information I've given them, intentionally or not. One day they might make a hard right into exploitation, but so far it doesn't really feel like they're even trying. I might have a profile they sell to companies who buy advertisements, but the advertisements aren't that much more effective than they were 20 years ago, and they should be waaaaay more effective by now!

Still, the point is a very interesting one: What's the long game for these culturally-central open source projects Google backs? Because it's certainly not as simple a profit-seeking setup as, say, selling lemonade on a hot day.

Labels: business, chrome, gruber, privacy