12,556 karma · joined March 18, 2011
The latter seems inefficient, so my first assumption would be that they would avoid that. But while I suspect they'd check if they know the book before scanning, I could imagine them not caring that much before buying them and just focus on volume.
An additional complication is that more aggressive pooling methods have side effects that you must know and prevent in your application. They're not safe to use out of the box.
The need for a connection pool is a side effect of the heavy process-based PostgreSQL connections. And I would suspect that this will change at some point in the not so near future, so that users don't have to think about this part this much.
They are likely prone to more biases than written exams, and the variability among examiners is likely high. My experience is both in taking these exams myself, and also sitting in on them as the note taker many times. Though that was only with one specific professor, and almost always on the same course. But that was in my experience a very fair exam, even for those students that were very noticeably nervous.
I was the PhD student in the room in dozens of these exams, and I toke some of them myself. But that was for classes with a bit less than 40 to maybe 60-80 students. The load for the larger ones was shared among professors, if I remember correctly. But it was certainly the case that a single professor spent 1-2 days doing nothing else but these exams.
And it was 1 professor and 1 PhD students, and those don't count. They essentially grow on trees and are always available, if you need some.
Of course it didn't save any money, and it was obvious from the start that the numbers they put out were entirely fictional.
That is an example of ignoring laws and regulations. So that is certainly relevant as context to the current case where the company is ignoring laws and regulations.
And of course devs read the content of functions they call. Unless it's a well written library used by many different people, odds are the function isn't documented well enough and has quirks that force you to understand in more detail how it works. This is not external library code, it's still part of your application.
In most situations I'd try to avoid using stored procedures. Unless you're all in on them, the effect will be that it hides some logic from the developers since it is not in the main part of the codebase.
Now, once the AI can carry all the compute it might need, I'd really worry when it doesn't only carry compute but also more explosive ordinance.
> In a podcast segment about immigration and deportations Allard stated his opinion and said that "They will also be forced to leave, even if they are born in Sweden, because they have no natural connection to Sweden. They are not Swedish."
I have also seen bad duplicate closures that weren't actually exact duplicates. But people talk like this is the only kind of duplicate closure that actually happens. I've no idea if the rate of bad duplicates is so much higher than I observed, or if people are missing that their question is actually answered in the duplicate.
.NET AOT right now is a very specialized solution that isn't widely applicable. Self-contained and single-file binaries do work pretty much out of the box already.
See the documention here for the PublishSingleFile and SelfContained options:
https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
AOT is not all that useful yet for many applications as important libraries still don't support it. So more something for things like CLI tools with a small scope.
It's not quite the same as with Go, the binaries get large if you can't trim them. But creating single-file self-contained executables is very much usable and works well otherwise.
AsSingleQuery is as dangerous as this makes it sound. This works surprisingly well if you know that the number of included entities is low, but only then.
You can get much better queries here if you write a Select() and let EF Core translate that into SQL. That will probably do roughly want you are imagining here, usually with subqueries fetching the data from related entities.
There's a difference here between an account that hasn't been used and doesn't hold anything of value and an account like this that holds items that were bought.
There's the X and Y chromosomes, those produce a binary result (unless you have a genetic anomaly). And after that comes the messy and fuzzy parts I mentioned, where those genes trigger changes in hormone levels and development. And those parts are analog, very complex and contain a lot of different parts. So the outcome is not binary anymore.