FoundationDB is awesome testing wise as they have deterministic simulation testing [1] that can simulate distributed and operating system failures.
> We wanted FoundationDB to survive failures of machines, networks, disks, clocks, racks, data centers, file systems, etc., so we created a simulation framework closely tied to Flow. By replacing physical interfaces with shims, replacing the main epoll-based run loop with a time-based simulation, and running multiple logical processes as concurrent Flow Actors, Simulation is able to conduct a deterministic simulation of an entire FoundationDB cluster within a single-thread! Even better, we are able to execute this simulation in a deterministic way, enabling us to reproduce problems and add instrumentation ex post facto. This incredible capability enabled us to build FoundationDB exclusively in simulation for the first 18 months and ensure exceptional fault tolerance long before it sent its first real network packet. For a database with as strong a contract as the FoundationDB, testing is crucial, and over the years we have run the equivalent of a trillion CPU-hours of simulated stress testing.
Pretty cool. For it to scale they are building their own deterministic hypervisor too [0], but also a new distributed database to support their workloads more efficiently [1].
> What most sticks out to me is the "Managers" directory. I've seen similar patterns before, even at my current place of work, but they seem to correlate with less experienced implementations
What is wrong with such structure? How would you structure this code? Genuinely asking
There are no peer-reviewed studies yet for me to corroborate this with, but I've seen this pattern primarily from a specific type of autistic, and it's similar to an actor pattern: a Manager is expected to entirely "manage" whatever feature it's concerned with. This is usually different from a simple module by not collecting related functionality regarding the feature, but rather trying to contain the entire feature itself.
This typically creates artifacts like each "Manager" owning too much of its implementation (not benefiting from or contributing to shared structures, such as a proper domain suffix list), inconsistency between different parts of the app (since different "Managers" don't necessarily share common patterns between them), and tons of hooks into random "Managers" all over the code.
To me, it feels a bit like an "emotionally driven" architecture, where the organization of the code is based on the list of features of the app, and not based on the implementation of those features. So rather than having, for example, a drag and drop component for the tabs to use, you would have, for example, a ReorderingTabsManager, and the implementation may behave differently than drag and drop in other places. So rather than factoring out code into modules for deduplication, you're making modules ("Managers") based on where they are in the product, and duplicating functionality across each module, to varying standards of completeness and/or quality.
Now I don't know if this project is quite that egregious, but it hopefully illustrates why I raise an eyebrow when I see a project architected this way.
While traveling I was so pissed with the Apple TV player's performance on less-than-lightspeed internet connections, I ragecancelled my subscription and just yo ho ho'ed the last couple episodes of Severance
I have a server that runs a bunch of containers (bittorrent client on a VPN, Home Assistant, etc.) and hosts SMB shares. I acquire content that goes on the shares which then get consumed by various devices.
- Kodi on a TV that has been stripped of as much of Google as I could find, streams from the shares
- VLC on my PC, streams from the shares
- VLC on my phone which is always VPN'd to my local network and streams from the shares
- VLC on iPads on which I usually drag and drop some shows/movies ahead of time so I am not wifi-dependent
GitHub frontend is mostly still their own [1] Web Components based library. They use Turbo to do client side reloading.
They have small islands of React based views like Projects view or reworked Pull Request review.
The thing is, even if you disable JavaScript, sites still load sloow. Try it yourself. Frontend code doesn’t seem to be the bottleneck.
How?
reply