The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It sure is pretty. I particularly like the hourly forecast breakdown which, for today, for each hour, says there's 0% of chance of rain. Literally, 0%, 0%, 0%, [...] %0, as far as it'll go (7am tomorrow morning).
This is neatly summarized with a single "Precipitation" graph, just under the hourly breakdown. This one says 30%.
If there's 0% chance of rain every hour until nearly 24 hours from now...how does this add up to "30% chance of rain"?
This is not a new thing. This app's been showing this sort of thing forever, as far as I can tell. Would love to see the source for that.
I understand your point. I've learned to live with it I guess.
If you zoom out and look at it, there's a 30% chance of rain throughout the day at some point (based on historical records and current conditions) but when zoomed in to specific hours there isn't enough.
Or perhaps they round down. Maybe the actual computer model is 4% every hour or something.
I don't necessarily disagree with you; however, I do understand the complexity of it, I think.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
I wrote a simple test in the Startup because I was to lazy to write a unit test. Part of writing the test is that I added the first non-generic constructor in the DB context definition:
public CatalogContext(DbContextOptions options) : base(options)
public CatalogContext(DbContextOptions<CatalogContext> options) : base(options)
Did my test, figured out how to work around the stupid EF issue, then removed my test code. And discovered that all my endpoints return "Unauthorized." WTF? Comment out that first non-generic constructor and lo-and-behold, API's work again.
WTF??? I set a breakpoint on the constructor and it doesn't even get called?
And then there's the whole IServiceCollection debacle. Whowever wrote a a service manager where you can't get the service? So you write:
and you'd think there might be a
call, right? Nope! Because they rely 100% on dependency injection. Oh for F*** sake.
And then there's db.YourContextObject.FromSql, because there isn't any SqlQuery because of Linq compatability issues. And FromSql has such absurd constraints that it basically is useless.
We had a mismatch during development where a new column existed in DEV but not yet in TEST. No matter, we weren't using it in this test so our filter didn't use it, no problem. Except EF generated SQL to ignore it by referencing it! Boom!
Straight SQL worked fine, of course.
- I would love to change the world, but they won’t give me the source code.
If your solution uses DI and you create ambiguous constructors then the only possibly outcome is failure. That's not a failure of DI, it is you using it in ways it is not intended to work. You can't throw a bike off a cliff and complain it didn't float to the ground.
As for getting services you've added to the service collection you use IServiceProvider to do that, the service collection is exactly what it says, a collection of services. If you want a given service you get it from the service provider.
As for EF and direct\raw SQL etc, EF is an ORM, if need to use raw sql, stored procs etc then it is the wrong tool for the job.
So use the right tool for the right job, and use those tools as they are intended to be used and you'll be fine.