- 2 Posts
- 4 Comments
1·20 days agoA somewhat forgotten option for dependency injection in Ruby is closures. Personally I find this technique much more practical than declaring classes. But this does go with a more functional approach in general.
score 1 · canonical
Something that struck me reading the article is in fact how similar the different examples of query builders are to plain SQL. Which begs the question, why use them in the first place? I mean, on the one hand those DSLs actually require us to be knowledgeable in SQL. On the other hand they prevent using more advanced features of SQL such as CTEs, window functions, RETURNING clauses, etc. Those abstractions are quite leaky. The way those WHERE clauses are put together in some of the examples. Sure, SQL has some warts, but finally what is the value of all those DSLs, apart from letting you put the SELECT clause at the end?
I wrote more of my thoughts on the subject here: https://noteflakes.com/articles/2026-09-05-beyond-orms
score 1 · canonical
The other day I reviewed a PR for one of my projects that was vibe-coded. The PR comprised a single commit with a small fix and lots of additional tests. The single commit means there’s no (easy) way to really make sure all those new tests would fail without the fix.
I think it would have been better to have the agent first write failing tests, commit that, then work on the fix and commit it separately. While I don’t vibe-code myself, I think following a strict TDD methodology can make a big difference in this respect.
score 1 · canonical