It really would be nice to have a convenient renderer for it though. It's genuinely surprising something like firefox doesn't have a markdown reader builtin already.
I wrote one for my own use (on Linux): https://github.com/mvz/mdv
Readit Newsmatijsvzuijlen commented on How Markdown took over the world anildash.com/2026/01/09/h... · Posted by u/zdw
matijsvzuijlen commented on Archiving Git branches as tags etc.octavore.com/2025/12/... · Posted by u/octavore
I sometimes leave merged branches around for quite a while, because I squash them when I merge to master and sometimes when tracking down a bug the ability to bisect very handy.
What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?
imho the vaunted readability of custom elements has long been available with haml, with added readability by virtue of the indentation rules replacing closing tags. Not sure why it didn't really gain much traction, maybe the pre-processing is problematic when there's no server-side framework like Rails?
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.
matijsvzuijlen commented on Uncloud - Tool for deploying containerised apps across servers without k8s uncloud.run/... · Posted by u/rgun
"I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines"
Since k8s is very effective at running a bunch of containers across a few machines, it would appear to be exactly the correct thing to reach for. At this point, running a small k8s operation, with k3s or similar, has become so easy that I can't find a rational reason to look elsewhere for container "orchestration".
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.
matijsvzuijlen commented on Cognitive load is what matters github.com/zakirullin/cog... · Posted by u/nromiun
I don't think it's as cut and dry as that. In my team we require 100% test coverage. Every file requires an accompanying test file, and every test file is set up with a bunch of mocks.
Sure, we could take the Foo, Bar, and Baz tables that share 80-90% of common logic and have them inherit from a common, shared, abstract component. We've discussed it in the past. Maybe it's the better solution, maybe not. But it would mean that instead of maintaining 3 component files and 3 test file, which are very similar, and when we need to change something it is often a copy-paste job, instead we'd have to maintain 2 additional files for the shared component, and when that has to change, it would require more work as we then have to add more to the other 3 files.
Such setups can often cause a cascade of tests that need updated and PRs with dozens of files changed.
Also, there are many parts of our project where things could be done much better if we were making them from scratch. But, 6 years of changing requirements and new features and this is what we have - and at this point, I'm not sure that having a shared component would actually make things easier unless we rewrite a huge amount of the codebase, for which there is no business reason.
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?
matijsvzuijlen commented on Turning Claude Code into my best design partner betweentheprompts.com/des... · Posted by u/scastiel
No, TDD failed because it assumed you could design a perfect systems before implementation.
It’s a totally waste of time to do TDD to only find out you made a bad design choice or discovered a conflicting problem.
What makes you think TDD assumes that? It sounds like the complete opposite of what TDD is about.
For people who, like me, prefer to read the abstract first: https://www.arxiv.org/abs/2508.06471
I haven't tried this yet (though I plan to).
One thing I would love is if I could give it a hint and have it extract out certain types of changes into its own branch that could split into a new PR.
I often find myself adding a new, re-usable component or doing a small refactor in the middle of a project. When you're a few commits into a project and start doing side-quests, it's super annoying to untangle that work.
The options are one of:
1. A mega PR (which everybody hates) 2. Methodologically untangling the side quest post-hoc 3. Not doing it
In principle, the "right" thing to do would be to go checkout main, do the side quest, get it merged and then continue.
But that's annoying and I'd rather just jam through, have AI untangle it, and then stack the commits (ala Graphite).
It's easy to verbally explain what stuff is side-quest vs. main quest but it's super annoying to actually do the untangling.
Maybe this tool magically can do that... but I do wonder if some context hints from the dev would help / make it more effective.
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.
matijsvzuijlen commented on Git as a debugging tool lucasoshiro.github.io/pos... · Posted by u/lucasoshiro
As a reviewer, —amend means I need to reread the whole commit to see what changed. A tiny commit means it takes me seconds.
My opinion is that a PR should be small enough that it’s desirable to have it squashed into a single commit at the end anyway.
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.
Linking to the abstract instead would have been nice.