The Big TDD Misunderstanding https://linkedrecords.com/the-big-tdd-misunderstanding-8e22c...
Ask HN: Share your favorite software blog posts of 2023
41–50 of 86 posts
Re: Ask HN: Share your favorite software blog posts of 2023
#42"How Levels.fyi scaled to millions of users with Google Sheets as a backend"
https://www.levels.fyi/blog/scaling-to-millions-with-google-...
Re: Ask HN: Share your favorite software blog posts of 2023
#43The 'eu' in eucatastrophe – Why SciPy builds for Python 3.12 on Windows are a minor miracle https://labs.quansight.org/blog/building-scipy-with-flang
Re: Ask HN: Share your favorite software blog posts of 2023
#44Earlier quoted context omitted.
The biggest missing element, in my mind, of the pro-"classicist" and anti-"mockist" view is that the practice of writing unit tests with mocking leads to refactoring your code until it works with that approach, which in turn leads to better-designed code. I don't like the emphasis of "yeah but refactoring code leads to needing to rewrite mocked tests", because if you've designed your code well, then the need to adjus…
You can only get away with poorly designed code if that's not caught in the code review. I'd argue that while that might be a nice side benefit of some testing practices, forcing you to rewrite your code isn't relevant to the test - in fact the opposite! Your tests should work irrespective of your code's internals! (Also, you can easily run integration tests in parallel with a little planning and attention to detail.…
Re: Ask HN: Share your favorite software blog posts of 2023
#45Another shameless plug. I'm pretty proud of my Learning Zig series (1). It's been translated into Chinese, Russian and Korean. Some may know my other writings (e.g. Little Go/Redis/MongoDB Book). I don't feel like I captured Zig quite as well, but it's hopefully a useful resources especially if you're coming from a garbage collected language. (1) https://www.openmymind.net/learning_zig/
Re: Ask HN: Share your favorite software blog posts of 2023
#46Earlier quoted context omitted.
do you have a specific post? I think entire blog would be too big to check out, just to be in line with this post
These are some of my favourites: - https://danluu.com/culture/ - https://danluu.com/p95-skill/ - https://danluu.com/wat/ - https://danluu.com/look-stupid/
Re: Ask HN: Share your favorite software blog posts of 2023
#47Earlier quoted context omitted.
The biggest missing element, in my mind, of the pro-"classicist" and anti-"mockist" view is that the practice of writing unit tests with mocking leads to refactoring your code until it works with that approach, which in turn leads to better-designed code. I don't like the emphasis of "yeah but refactoring code leads to needing to rewrite mocked tests", because if you've designed your code well, then the need to adjus…
You can only get away with poorly designed code if that's not caught in the code review. I'd argue that while that might be a nice side benefit of some testing practices, forcing you to rewrite your code isn't relevant to the test - in fact the opposite! Your tests should work irrespective of your code's internals! (Also, you can easily run integration tests in parallel with a little planning and attention to detail.…
Are you avoiding rewriting your code so you can write integration tests, or are you writing integration tests so you can avoid rewriting your code?
Those that have been around the block of refactoring code so you can write good unit tests, tend to realize that the better-designed code isn't a side benefit. It's the entire point. The test is the side benefit.
Integration tests should be avoided if the same coverage can be reached with a refactor and some unit tests. For instance, it's very common for components to rely on complicated combinations of state. For instance, imagine a nightmare component that has nine boolean state parameters. To integration-test every combination, that's 512 cases. But in cases like those, you might discover through refactoring that some of those state combinations can compressed. For instance, you might be able to refactor into three sub-components, each of which take three boolean parameters and return one boolean result, and where the parent component only depends on those three booleans, which can be mocked. So then in that case, you've reduced the amount of tests you need to write to 32 total... that's 1/16th the effort.
I mean, I know that in common practice, neither are done, and people just leave the component largely untested, and then get bug reports that they close as "Can't reproduce".
Re: Ask HN: Share your favorite software blog posts of 2023
#48This post on embeddings by simonw https://simonwillison.net/2023/Oct/23/embeddings/
How Many Lines of C it Takes to Execute a + b in Python?
https://codeconfessions.substack.com/p/a-war-story-involving...
Re: Ask HN: Share your favorite software blog posts of 2023
#49Earlier quoted context omitted.
do you have a specific post? I think entire blog would be too big to check out, just to be in line with this post
These are some of my favourites: - https://danluu.com/culture/ - https://danluu.com/p95-skill/ - https://danluu.com/wat/ - https://danluu.com/look-stupid/
Re: Ask HN: Share your favorite software blog posts of 2023
#50Smashing the state machine: the true potential of web race conditions
https://portswigger.net/research/smashing-the-state-machine
The talk (on YouTube) is also absolutely brilliantly done.
James finds new vulnerabilities classes where others don’t even see potential for problems. Absolutely amazing!