brandur

It's astounding how bad faith you people are.

The question wasn't "does every billionaire pay the top marginal tax rate", it was: could you elaborate how France is "giving all the money to billionaires"? which was the OP's claim.

If this was true, it'd be simple for your ilk to answer it directly. Since it's not, you lie, misdirect, and shift the goalposts around in defense of the original lie, viciously attacking straw men that you erected.

France gives no money to billionaires. Even if you think their tax rate should be higher, those billionaires pay billions into a system that's managed to bankrupt itself through massive spending on general entitlements. You could take every billionaire in France to the guillotine, steal 100% of their wealth, and it'd fund the French government for less than two years. Spending must go down.

Quite terrifying that this appears to be a sincere comment. The top marginal tax rate on French nationals including CEHR is over 55%. The country spends ~60% of its GDP, almost 10% higher than the European average, let alone the average worldwide.

Could you elaborate how France is "giving all the money to billionaires"?

Article does a great job of conveying the stress involved for a non-actor to play even a tiny part in a big movie like this, but yeesh, it'd be a dream come true to get even the tiniest part in one of the greatest movies of all time (IMO obviously), let alone to luck into it this way by pure happenstance.

I remembered the scene vaguely, but was curious to go back and see it. It happens at roughly 7 minutes 19 seconds into the movie, intercut into the initial awards scene, and right before Willem Dafoe's nephew gives Steve a seahorse in a bag.

This is a distinction without a difference. Arko proposed to receive a copy of all RubyGems access logs containing full user PII.

He'd accept this PII en lieu of dollars for secondary on call coverage, so a safe assumption is that he intended to monetize the extracted user PII in some way. I am sure he would deny this, but there's a point where you have to let the evidence we do have combined with common sense guide us to the most likely conclusion.

Thanks for that — I didn't know about `clone` (and important to note it's non-default) and now intend to try it out.

As long as you're using Postgres, I would definitely try out an approach based on template databases in your situation. It should check all the boxes that a run with `db/seed.rb` would, except an order of magnitude or two compared to what Rails would be doing (i.e. parsing a big Ruby file and loading schema in table by table).

One of the best things about LLMs is they make these sorts of refactors entirely plausible even if you're not a subject area expert. You could probably prototype this and have a patch ready in an hour or two.

Ah yep, good point. I was confusing "ramdisk" versus just "ephemeral in-memory".

It doesn't look like MySQL has any concept like a template database. You could still migrate up a pristine database, use mysqldump to produce a schema, then load that into a series of test databases. It of course won't be as quick as the low level copies that Postgres is doing with a template database, but it'd be faster than re-running all your migrations.

OOC — I've been trying to gather real world anecdotes on who is using MySQL these days given that even some of its biggest traditional champions like PlanetScale are talking a lot more about Postgres recently. Are you using MySQL as part of an existing project that was started years ago, or do you still intend to use it for new things going forward?

No worries Peter. And thanks for putting together pgtestdb — such a great project! This conversion sprint was a fun little experiment.

Some very significant disadvantages to that approach:

* It's common these days for a single operation to manipulate dozens or even hundreds of database records. Often these records are interrelated because they reference each other. So with fakes, you're faking initial inserts and then faking inserts based on other fake inserts, creating a fragile tree structure of fakes, which models reality very poorly.

* No data type validation on data inserts or updates. Put a string in the integer field? Find out in production.

* No foreign key validation (or just general capacity for checking referential integrity) so you don't find out that you're rows aren't referencing each other correctly until production.

* Similarly, no checks on primary keys, check constraints, triggers do not run, etc.

* Since you're not doing real inserts, you're not doing real updates or deletes on inserted rows. So if those latter operations are referencing the wrong ID, you don't find out until ... you guessed it, production.

* You can try to build up the fidelity of your repository/fake framework, but the more effort you put into it, the closer you are to just rebuilding a database and the slower it'll get. You'll also never achieve actual parity with what your database is doing.

* Building out these big fake frameworks is a lot of work relatively speaking (you didn't need to build out anything for your DB because your non-test code is already using it), and gets you negative gain.

There was a time a long time ago when disk I/O was a lot slower than it is now and maybe there was some argument for a repository/stub system, but that was at least a decade ago, and even then the rationale was thin. These days we have NVMes, and if you're a real speed demon and think those are too slow, you can just put an in-memory SQLite or Postgres in place for your testing and get all the performance advantages with none of the downside.

Interesting. How many database copies do you bring up when the test suite starts running, and how is parallelism handled?