Recent submissions

Comment · 1 month ago
In GitHub and vim at least you can dig past those commits to see earlier relevant commits. I'm sure there are more tools that allow this.
Comment · 3 months ago
This is a nice idea but a lot of the OSM tiles show as blocked due to lack of a Referer.
Comment · 4 months ago
Thanks, that makes sense. I actually just parsed aes as related to encryption without even considering how weird that was given the contect.
Comment · 4 months ago
Yes, I will do that!
Comment · 4 months ago
Why are all the parameters full words except 'labs'? I find it jarring because to me 'lab' is short for laboratory, not label.
Comment · 9 months ago
Comment · 10 months ago
What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?
Comment · 11 months ago
I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation.

I think it's worse than, e.g., typical yaml files because the nesting is deeper.

Comment · 11 months ago
If you already know k8s, this is probably true. If you don't it's hard to know what bits you need, and need to learn about, to get something simple set up.
Comment · 1 year ago
I can understand requiring 100% test coverage, but it seems to me that requiring a test file for every file is preventing your team from doing useful refactoring.

What made your team decide on that rule? Could your team decide to drop it since it hinders improving the design of your code?

Comment · 1 year ago
What makes you think TDD assumes that? It sounds like the complete opposite of what TDD is about.
Comment · 1 year ago
Comment · 1 year ago
In such cases, I generally checkout main, do the side quest, and rebase my original branch on top of it. Then, I can just continue without waiting for the side quest to be merged. Depending on the situation, I may make a separate PR for the side quest, but I don't have to wait for it to get merged.

Alternatively, if you don't like rebasing, you can merge the side quest branch into your project branch instead.

Either way, you don't have to wait for the side quest to get merged.

Comment · 2 years ago
The idea is that --amend would be used before pushing the commit that it amends, and so before a reviewer ever sees the original commit.
Comment · 2 years ago
Linking to the abstract instead would have been nice.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton