|
Smacks of a demo that was done to show what could be done and then shipped, I have written code like that...
|
|
|
|
|
I wouldn't know. Living in Wales means it just predicts rain all the time, and is generally spot on.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
+1
I suppose sometimes you can get away with guessing.
|
|
|
|
|
dandy72 wrote: Would love to see the source for that.
More than likely it is just pulling data from some other site/location, rather than trying to do all of the "calculations" itself.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Written by the same helpful chaps who brought you the ever-accurate progress bar estimates throughout Windows.
|
|
|
|
|
It's not just the Win10 app that that happens on. I've seen it in Accuweather as well.
As someone else said, it's probably from a different dataset.
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.
|
|
|
|
|
ZurdoDev wrote: As someone else said, it's probably from a different dataset.
Dumb thing to do when your datasets contradict one another.
It's like having two watches that aren't synchronized. You start questioning the accuracy for both.
|
|
|
|
|
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.
|
|
|
|
|
Probability of precipitation clickety[^] apparently refers to the chance of rain falling at any point in the area.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I upset them when I informed them that winds come from a compass bearing, not go to it, so their vanes were out by 180 degrees.
In typical ms fashion, rather than fix it (which would probably take ten minutes), they removed the vanes (which probably took an hour).
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: I upset them when I informed them that winds come from a compass bearing, not go to it, so their vanes were out by 180 degrees.
Reminds me of the KB article from a decade+ ago that mentioned that in Encarta (?), the animated Earth was spinning in the wrong direction...
|
|
|
|
|
WTF?
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:
services.AddDbContext...
and you'd think there might be a
services.GetDbContext... 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.
Read more:
Database.SqlQuery<TElement> Missing · Issue #10365 · aspnet/EntityFrameworkCore · GitHub[^]
and:
Leveraging Raw SQL in Entity Framework Core -- Visual Studio Magazine[^]
So instead I found GitHub - devel0/netcore-ef-util: net core entity framework util[^]
I despise:
* dependency injection
* EF
* Behind the scenes magic is breaks everything if you don't wave the wand just exactly right
While I like .NET Core, I just refuse to use the ASP.NET/EF pieces.
And don't even get me started on the BS on how to get CORS working properly and the whole pipeline-middlewear crapola. More perfect wand waving and incantations required.
|
|
|
|
|
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.
|
|
|
|
|
Quote: throw a bike off a cliff
Why do you think his name is Clifton 
|
|
|
|
|
F-ES Sitecore wrote: If your solution uses DI and you create ambiguous constructors then the only possibly outcome is failure.
Pardon me for taking exception to this, but that's BS. I've written DI's and you go for the most specific instantiator you can with the information you have in the service manager. You don't go from general to specific, or simply barf in the bowels of your injector with no intelligible message.
F-ES Sitecore wrote: As for getting services you've added to the service collection you use IServiceProvider to do that
Right. So you have one thing for adding services, but another thing for getting them? BS.
F-ES Sitecore wrote: 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.
And exactly why can't the tool do both gracefully? It's not the wrong tool. The tool is broken.
We have very different views, I see!
|
|
|
|
|
Marc Clifton wrote: you go for the most specific instantiator you can with the information you have in the service
Unless I misunderstood your original post you had two constructors with a single param, so how does the DI know which is "more specific"?
Marc Clifton wrote: So you have one thing for adding services, but another thing for getting them?
Yes, it's called the single responsibility principal. By separating the two if you want to use your own resolver, you can.
Marc Clifton wrote: why can't the tool do both gracefully?
Why can't my bike float me to the ground like a parachute? The more things a tool does, the worse it tends to be at them. EF can use SPs and raw SQL, but you're not going to have as much flexibility or control, so if you want to do anything advanced you're probably going to have a bad time.
|
|
|
|
|
F-ES Sitecore wrote: so how does the DI know which is "more specific"?
Well, one is of the form Foo<Bar> and the other is just Foo. That seems sufficient to distinguish which to use.
Oops, hit Post Message.
Quote: Yes, it's called the single responsibility principal. By separating the two if you want to use your own resolver, you can.
OK, point taken, though personally I find that to be a bit too much separation.
F-ES Sitecore wrote: EF can use SPs and raw SQL, but you're not going to have as much flexibility or control, so if you want to do anything advanced you're probably going to have a bad time.
Agreed, but in my case, I want to do something very specific and simple involving several table joins and I don't want to write the class models for each table so EF can make the query. For me, it's a case of the tool which as a method that looks like it should work but has severe limitations. Tools (we're talking software tools, not specious analogies) should not be designed so they get in the way when I want to take control, and shouldn't require me to write additional otherwise useless layers of code.
|
|
|
|
|
Marc Clifton wrote: Well, one is of the form Foo<Bar> and the other is just Foo. That seems sufficient to distinguish which to use.
What if it has both Foo and Foo<Bar> registered as services? How does it know which one you want? You should have added Foo to the param list of the existing constructor rather than create a new constructor with one param also. That's just how DI works.
|
|
|
|
|
Not really possible given it's a derived class:
public class CatalogContext : DbContext
{
public CatalogContext(DbContextOptions<CatalogContext> options) : base(options)
{
}
}
|
|
|
|
|
So given what you said, I tried something:
public CatalogContext(DbContextOptions opts2, DbContextOptions<CatalogContext> options) : base(opts2 ?? options)
That actually worked. Sort of gross though
Actually, the whole issue could be avoided if I'd done:
var dbBuilder = new DbContextOptionsBuilder<CatalogContext>();
instead of:
var dbBuilder = new DbContextOptionsBuilder();
|
|
|
|
|
Into the future, or the past, and, be present as an invisible observer: when/where would you go ?
I'll add my choice, later.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Well, hard to choose the future as we don't know what events will occur...
So I will go back in time and watch the dinosaurs get wiped out.
|
|
|
|
|
I would go back and just watch the dinosaurs live. People have speculated that the T-Rex was about as intelligent as a cat. Did it play with its prey as a cat does? Did it train it young to hunt? Inquiring minds want to know.
|
|
|
|
|
I'd use it to skip advert breaks on TV.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
