fabian2k

Journalism is allowed to have an opinion, that doesn't make it propaganda.

Assume you fetch a single customer entity with their 100 order entities as includes. With single query this will join both tables and produce 100 rows that contain the order data but also each one contains the customer data redundantly. Now Imagine you had two includes there, that will multiply the number of rows again.

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.

I'd consider keeping the other personal data to be still easily justifiable, as you might want to support various account recovery options. And the odds that a user forgot their password only increases for old accounts.

Those articles don't require deletion in this case, in my non-lawyer opinion. There is still a purpose to keeping the user's personal information here. Sony needs that information to be able to grant the user access to the content they bought.

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.

Scientists tend to understand that part, that's more of a political/cultural thing (I'm ignoring the language part here entirely about which terms to use for which concepts here).

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.

One part that people from the software side tend to underestimate is how fuzzy and analog everything in biology is. Genomics look more predictable and organized at first, but even these parts are quite fuzzy and subject to all kinds of physical effects.

I'd strongly recommend in reading up on the parts of cell biology that come after this. Otherwise you'll get the wrong impression of how messy biology actually is.

These rules are all stuff that you probably should think about at some time. But they're often taught as strict rules, which I don't think is a good idea.

In the end many of them are still quite subjective. It is useful to try to avoid mixing unrelated stuff into the same class. But trying to religiously find the boundary to what a single responsibility means in each specific case is a waste of time.

I had the same experience with the platforms when I first played Space Age. But this depends entirely on how you scale your Nauvis factory before you start launching rockets. You don't want to start too small, if you rush to rockets too quickly the beginning of your space exploration will be tedious.

You never want to burn fruit itself since that wastes the seeds. So you always want to process fruit the first step.

I limit fruit production based on the number of fruit on the belt, to avoid creating a huge buffer. But after that the factory just runs continuously at the same speed. And if I have too much of a final product, it gets destroyed or burned for heat and electricity.

One benefit, especially in the beginning, is that by processing more fruit you get more seeds. And you need the seeds to expand your fruit production later.

The enemies are probably one of the not ideally designed parts of Gleba. It's trivial to handle them if you know how, and can be very frustrating if you try to approach it the "wrong" way. If you have been to Vulcanus and Fulgora you can trivialize their threat.

Limiting production is probably the most difficult way to play Gleba. The easier way is to minimize buffers and have a path to extract spoilage at every position where it could accumulate. And to never, ever have the factory stop at any point in time.

The big changes are presented in the Factorio blog, read FFF #421 to #423 here to get an overview:

https://factorio.com/blog/

https://factorio.com/blog/post/fff-441

https://factorio.com/blog/post/fff-442

https://factorio.com/blog/post/fff-443

It's already faster even without that because it now uses mixed content rockets to build ships and platforms. But space-to-space logistics do mean that you can make rocket launches less bursty and continually ship stuff into space to then use it.

I don't think the developers promised more here, but the community might have overhyped itself as it is common. It's still a very solid .1 release, the improvements to space logistics and platform building are very nice. There's also a whole bunch of really nice circuit additions.

Gleba is different, but I think that is good in a game that is as long as Factorio. There's a bit of a bumpy difficulty curve here if you approach Gleba in certain ways. But it is very different mechanically than the base game or the other planets in a way that is interesting, at least to me.

It took me two or three iterations when I first landed on Gleba. But afterwards my factories there were more robust than on the other planets and almost never stalled or broke down. And solving that was quite satisfying.

it's really a bit of a different concept in scientific publishing, not actually plagiarism. The problematic part is publishing the same results twice, because it increases the burden on reviewers and inflates your publication count. It's also just messier if the results are in multiple places since it makes it harder to follow where those results were used and cited.

The COVID19 vaccines were the most-discussed vaccines ever. And there was an enormous amount of coverage for the potential side effects. Recommendations were adjusted based on new data.

There was also bad communication on the topic, often when politicians got involved or due to outdated information continued to be repeated. But there certainly was a lot of public discussion about the risks of the vaccines, they were simply vastly outnumbered by the benefits of the vaccines.

What happens right now is vastly different than before. Of course there are different priorities in funding for each administration, but those are usually more gradual shifts and especially don't cancel running grants arbitrarily.

And if you think this administration is prioritizing science with actual applications, I have a bridge to sell to you. The cuts they made are not sensible policy, they are inherently destructive and wasteful. They aborted studies that were still running, so a lot of money was spent and we'll never get any results from that because they were not finished.

This administration is both fundamentally anti-science and wants to enforce political control over all government institutions. Science was never a particularly stable work environment, but the sheer insanity you have now makes it a deeply unattractive place. You have no idea if your grant might be denied, or even canceled at any point later by some political commissar that doesn't understand science.

And it's not just particular topics they hate, they hate the entire system and institutions. And they try to either break them and force them to adopt their political views, or they attack their funding or use any other powers to dismantle them.

> 30-50% of engineers on core teams have been forcefully reassigned to data labeling and RLHF, upsetting folks even more.

This really doesn't sound believable to me, but who knows with all the craziness going on. Software developers in the US are seriously expensive, using them for data labeling would be a waste of resources. And the percentage sounds very high, unless "core teams" is only a small subset of the total developer count.

If I read it correctly, they did espresso and filter taste tests at room temperature (thought they don't state the exact temperature, and how they managed to brew filter coffee with the described setup). Overall the press release is somewhat misleading in what the goal is until the part you mention. If the focus is industrial production of cold, mixed coffee drinks I'd have expected more quantitative measurements instead of taste tests. Testing how well your coffee is extracted is pretty trivial with the right equipment.

But people want to drink coffee/espresso hot, not room-temperature. So you have to heat the water afterward anyway. I'm not seeing that much potential for energy savings here, unless you're comparing setups with large boilers inefficiently used for small amounts of coffee.

It's up to the employer, they can ask for a doctor's note from day 1. Many employers have more lenient rules, though.

Some kind of versioning is extremely important for certain use cases. And having it a core DB feature makes it easier to show that you implement that checkbox.

One thing I'm wondering about is the performance of temporal tables for the common case, when you only query current rows. When you manually version tables, one strategy is to have a second table that contains archived versions. So your main table only has the current rows, avoiding a performance hit for having many versions per entry. Is there a way to do this with temporal tables? For example partitioning between active and old rows?

Should the Cubans that will inevitably be killed along the way be thankful as well? Or the Cubans currently suffering due to the blockade?

Even for clearly despotic regimes, overthrowing them is not the obviously right thing.

Appears a bit too superficial to me to be useful. It groups topics very weirdly (bool and timestamp, uuid and JSONB) and there is almost no detail in each topic.

Explaining text column types without mentioning limiting length with constraints instead of using varchar also seems a bit questionable to me.

You can manually add more advanced statistics in PostgreSQL. That includes statistics over multiple columns.

https://www.postgresql.org/docs/current/planner-stats.html#P...

yeah, there's plenty of ways to do that. I like having the attribute there so that there is a strong hint that some magic is happening somewhere with that class.

The only case I've used them was to mark classes that I need to find via reflection and do something with them. For example a migration system where you want to load all migrations that are defined and check if you need to run them. Of course you don't really need an attribute for that, but I find it helpful to leaven a marker on the class that there's something else going on there.

They didn't mention anything about SLAs. This is about all the time, effort, paperwork and risk it takes to add yet another vendor. Having fewer vendors does actually reduce risk, as long as your chosen vendors are reasonably good. Though the bigger reason is certainly avoiding the additional bureaucracy, which is partly self-inflicted in larger companies but also not without merit.

If the main job is putting out a report, starting with AI is wrong in any case. What's the value of an AI-generated report, even if experts fix the biggest issues with it? Maybe this kind of report didn't have all that much value before, I don't know. But starting with AI just makes sure it's generic drivel.

I'm always a bit skeptical about benchmarks like this. There's quite a few knobs you want to adjust for a production PostgreSQL on bigger hardware. And the article doesn't provide any configuration details (like shared buffers, is huge pages enabled).

The effect is visible at 500 connections, not at 250. The CPU is a Threadripper with 64 cores and 128 GB memory, which seems like a bit of a mismatch to me. So I wonder how transferable these benchmarks are to different setups.