89
points
mehagar
Joined 83 karma
- If a tool makes it easy to shoot yourself in the foot, then it's not a good tool. See C++.
- We tested this against WebRTC data channels (which also uses UDP) and found that the congestion control algorithm used for WebTransport limits its use for videoconferencing. We'll probably look into it again if browsers start allowing this to be configured.
- For Zoom Team Chat you can set up notifications to only notify for replies to your messages, direct messages, and explicit mentions. I agree that it would be useful to additionally batch notifications for specific channels though.
- We're using conventional commits on my team, and it's extremely annoying. I've never had a reason to go deeper into the history of a repo outside of the PR merge commit history. I think it makes more sense to have conventions on PR descriptions.
- This article explicitly mentions your first point.
- How could you possibly plan out "everything" in advance? Code itself would be the only way to explicitly specify the "everything".
- Yes, the original set of web technologies was simply not designed with the kinds of interactive UIs people expect today.
Perhaps in the future UIs can be rendered with WASM, with the common rendering libraries being distributed as a separate WASM module (so users would not have to repeatedly download large files)?
- More likely they don't even need to use useMemo if it's not an expensive calculation. They can just calculate the dependent values during rendering, which is explained in the docs: https://react.dev/learn/you-might-not-need-an-effect#updatin...
If `getLinkedCats` calls an external API, then the calculation can instead be all in the same useEffect.
The number one mistake I see people inexperienced with React doing is using too many useEffect's in their code, which is both hard to read and hurts performance, since it results in more renders than necessary.
- More broadly it includes moving activities that are normally performed at a later stage so that they are earlier in the process. The idea is that defects found later in the process are more costly.
- Unit tests should be independent of the environment they are run in, and pass or fail consistently. Otherwise, it is not a unit test.
- Unit testing proves correctness in regard to the test written (not necessarily the correctness of the application itself). They're similar in that they are both typically fast to run, and that they check an aspect of the program for correctness.
- I like the testing pyramid specifically because it captures the tradeoffs between the different kinds of tests. Mocks can come in handy, but like anything else can be abused. We need a "Mock this, not that" kind of guide.
- On that topic, static type checking can effectively be seen as a "unit test" that tests as well as documents the expected types for an interface.
- That reminds me that Stripe actually maintains (or used to) their own mock for their Ruby package. This puts the burden on maintaining the mock on the library owner, where it is more likely that they would implement the mock correctly, edge cases and all.
- I agree that if you need to write mocks, it's likely that your interfaces are poorly defined. This is one of the claimed benefits of test driven development - writing the tests first forces you to design the code in a way that cleanly separates modules so they can be tested.
- The catch-22 with refactoring to be able to write unit tests is that refactoring introduces risk as you are changing code, and you need tests to help reduce that risk. But you can't easily write tests without refactoring. This has been a very difficult problem for the team I'm currently on.
The only strategy I'm aware of is described in `Working Effectively With Legacy Code`, where you start by writing throwaway unit or E2E tests that give you "cover" for being able to refactor. These tests depend on the implementation or may use mocking just to get started. Then you refactor, and write better unit tests. Then get rid of the throwaway tests.
- Clean Architecture and Fundamentals of Software Architecture: An Engineering Approach.
- WebSocketStream is about to ship in Chrome, which adds backpressure: https://chromestatus.com/feature/5189728691290112
"Oh, that must have been frustrating."