I think the main thing I'm waiting for in the atproto space, for _most_ applications, is private data solutions. And the recent RFC on private data spaces (I forget the terminology) is a start, but has a ways to go.
I've yet to be convinced all of this effort is worth it, compared to the ease of using a repository pattern and just using a fake for tests.
And, like, I don't think we shouldn't be doing these efforts, I guess, as they may still pay technical advancement dividends down the road or help with cheaper, faster QA envs, all-in-one e2e envs, etc... but for the unit test and service test layers, those bottom several layers of your testing pyramid, fakes for your repository interfaces is so much easier and orders of magnitude cheaper.
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.
* You're just describing arranging the test setup, which is independent of storage medium.
* Is your repository interface untyped?
* Depends on the fidelity of your fake, but generally I find FKs to be an antipattern these days.
* What are you checking primary keys FOR? Uniqueness is easy and I avoid more complex constraints and triggers.
* ... I'm beginning to suspect we have a difference in terminology. I'm not saying a mock. A typical DB fake would be array or hash table backed in memory. So an insert is "real" and an update or delete would be too.
* Well, sure, but I can get 95% fidelity for 1% of the resources.
Even if the fake is super-fast compared to postgres (1%) in CPU resources: Why spend extra engineering effort to build something that has less fidelity?
CPU for test runs is cheap... and if you use any AI agent at all, tests runs faster than the agent does work. Why does it matter how much faster they run?
The goal of a regression test suite is to catch issues before you deploy to prod. That 95% is a nagging source of doubt. CAN you just release the code straight to prod? Or not?
Many times integration tests including the real postgres and real migration catches bugs for me before they go to prod.
Personally I would just never go with 95% fidelity in tests. Testing with the real postgres is just so good.
And just to get test coverage for the migrations themselves?
(In my case I also use stored procedures, RLS etc that needs those; with your setup that is just not on the table I think or you loose coverage of critical code.)
Once you've done it a time or two, setting up the "clone the db"/"erase the db for each test" pattern isn't that much work (plenty of libraries to help too).
And of course once its set up for a project, adding more tests to it is pretty straightforward. It is slower for each test run, but I had hundreds of tests running serially erasing a MySQL DB before each one and it only took a minute or so, which was well within my tolerance.
So overall I'm a fan; I think there's more benefits than drawbacks. Especially if it's SQLite, where setup is even easier.
If you are unit testing something then sure mock out everything you are not concerned with.
But for service layer tests I don't agree with you, including the actual production repository implementation and the DB is very useful.
It is like e2e tests, just leaving the frontend out. I really like having a lot of such tests to be productive with backend development.
To have a 100 such e2e tests complete quickly, spinning up SQL DBs cheaply is essential.
Also for actual e2e tests with frontend I prefer cheap DB clones rather than reusing DB between tests and having to worry about state between tests.
I think perfect layering was more relevant in the 2000-2010 with less powerful machines. Just making pseudo-integration tests and including more than may be strictly needed is fine. It completes quickly enough. When it breaks it is usually obvious what broke without limiting was code is included in the test.
How do you ensure your SQL queries (either raw or ORM generated) retrieve the correct data?
A lot of business apps are mostly SQL with a thin layer of glue to integrate everything.
I think it depends on what the app does--is it data manipulation heavy (lots of complex relations) or is it compute/algorithm heavy (simpler relations, lots of logic).
Alright, we're halfway through the Pantheon scene where David hacks the data center with the satellite phone.
Though, the phone moving with the vibration was always the more believable half. The ultrasonic pressing of the keyboard is mostly sound science but questionable from an engineering standpoint.
Hmm if a particle is a quantized packet of a field, then if multiple quantizations are possible in a field, then it's possible for more particles than fields?
People reach for the things you mentioned wayyyyyy before they should.
Just because you want something queue shaped or search, doesn't mean you should reach for the big, specialized, expensive technology, when Postgres can already support it in your existing infrastructure up until some significant scale you often won't surpass.
>People reach for the things you mentioned wayyyyyy before they should.
Most orgs are probably due for a technical reassessment. Scale that I believe would have melted postgres in the past now just runs fine. CPUs got a ton faster and memory got cheaper.
Projects that would have required a complex distributed setup 10 years ago can now be handled by a single machine. For a lot of use cases, CPUs got faster than population growth.
The amount of redis-as-database, or X really, that I see deployed that practically make no sense is insane. I haven't run the numbers to make my following claim based on anything but my feelings, but just incompetent dev alone is probably what keeps cloud computing alive.
Ticketmaster does something very similar to this with their "demand weighted pricing" and it is just so sad that their solution to "scalping" is "let's bring that profit into our platform."
You can get away from supply/demand laws. By pretending that something is not giverned by them and putting fixed price lower than real price (i.e. that price at which suppl equals demand) one leaves space for scalpers to exist and collect money that people are willing to spend over set price.
Given that people are going to spend money anyway it seems more honest and reasonable to direct this money to the party that makes the thing by letting it to run auction.
Society has found out money is a good way to encourage/discourage certain behavior in a predictable, deterministic, and quantifiable way. It really sucks that it has to be money, and maybe this can be solved with some other universal token that cannot be bought with wealth but equitably distributed some other way.
For example the dynamic fees in express lanes in California aren't really for the purposes of paying for the roads. They dynamically adjust it such that the traffic in the lane is operating at peak efficiency. Too few people using it obviously reduces throughput, so the price cheapens to have people using it, and too many people using it causes a collapse in efficiency so the price increases. Having some kind of adjustable cost on it lets the control system appropriately change the demand to keep it efficient.
It seems to me like a social score system is a direct upgrade to this in certain ways: participating in undesired behaviour will cause you headaches you cannot really solve with money.
Too bad it "naturally" slips into mass surveillance, but restricting privileges would be a great alternative to reducing the ability to take care of necessities for you and yours.
It doesn't have to only be money. In person waiting time is another mechanism to allocate a scarce resource. Back in the day when # of tickets exceeded demand at a fixed price, the tickets went to he/she who was willing to arrive early and wait in line longer (ie, die hard fans). Camping out for tickets was a thing and I somewhat miss it relative to scalpers and price being the only mechanism to drive demand/supply to equilibrium.
I don't see it really as profit maximising, just allocating it first to the people who want it the most. Like they are willing to pay scalpers.
You can get it at the lower price, you just have to wait. The same happens with loads of digital devices. On release day the price is higher.
If it helps you can separate it and have the first a 'ticket' in line to buy the product for the regular price. You just reserve your spot with the auction. The queue price just drops over time.
Profit and premium models can be great if it's allocated to useful things. For example if it went as bonuses to the rank and file employees, or was as steam store credit, or went to a charity.
I get your cynicism it would just go to billionaire shareholders, but profit itself isnt the enemy, greed is.
2. Regarding the title... you can definitely prompt them to be dumber, clearly. We know performance can be improved via prompts, from "baseline" performance. So this is a weird title.
It's not a routing issue, it's a firewall issue. Make sure you have a proper firewall on your network and don't rely on fake firewalls like ufw if you're concerned about this.
Again, if your router or perimeter devices are appropriately managing your network then it's a non-issue. By default most home routers have IPv6 disabled, and if you're setting up an enterprise environment with a VLAN you're probably subnetting IPv4 instead of using IPv6 at all.
All that means that if you're using IPv6 then you're proactively enabling it on whatever is handling your perimeter, which means you hopefully know what you're doing along with all the gotchas that come with that setup.
