lirbank

4 ms·

1.
by lirbank 2mo ago
This has been needed long before agents were a thing - and now with agents, even more so! Excited to try it out. But I would like to understand more about the security posture. What documentation do you have for how Capy keeps secrets safe?
2.
by lirbank 3mo ago
Author here. Would love feedback and pushback. Is expand-and-contract how you'd approach migrations? And how do you handle the long tail of clients in the wild?
3.
Neon Testing now supports Bun Test(github.com)
1 points by lirbank 4mo ago|0 comments
4.
Agents are not compute – agents are data(electric.ax)
4 points by lirbank 5mo ago|1 comments
5.
Liberate yourself from infrastructure over-planning(lirbank.com)
1 points by lirbank 7mo ago|0 comments
6.
by lirbank 8mo ago
Right, that's a real concern with naive concurrent tests - you're at the mercy of timing and the test becomes flaky. That's exactly what the synchronization barrier solves: it forces both transactions to reach the critical po
7.
by lirbank 8mo ago
Fair concern about reaching inside systems - it's not something to do lightly. The hooks are designed to be minimal: production code never calls them, they only activate in tests. But the core point is narrower than the thread might su
8.
by lirbank 8mo ago
You're right, Postgres wraps every statement in an implicit transaction. The point of that first example is that the SELECT and UPDATE are in separate auto-committed transactions - there's no explicit transaction block wrapping bo
9.
by lirbank 8mo ago
Hey, thanks for sharing this - these bugs are so easy to miss because everything works fine until you get real concurrent traffic. And yeah, the moment you have multiple instances, app-level mutexes can't save you.
10.
by lirbank 8mo ago
Oh that is super cool. Great prior art to study in combo with Loom. Very excited to dig in - imagine if there was an easy-to-use data race tester where you didn't have to figure out the interleaving points up front? Just point it at yo
11.
by lirbank 8mo ago
Yeah, the more I think about it, the more exciting this idea gets. The walkthrough in the article shows exactly why - I intentionally (to later show why that is wrong) place the barrier between the SELECT and UPDATE, which deadlocks instead
12.
by lirbank 8mo ago
Good call, SERIALIZABLE is a strong option - it eliminates a whole class of bugs at the isolation level. The trade-off is your app needs to handle serialization failures with retry logic, which introduces its own complexity. That retry logi
13.
by lirbank 8mo ago
Absolutely - if you can express the whole operation as a single atomic statement, that's the best outcome. No locks needed, no race to test for. The article is about what comes next: when the logic can't collapse into one query, h
14.
by lirbank 8mo ago
Nice - that's a good case for barriers too. When there's no row to SELECT FOR UPDATE against, you'd inject the barrier after acquiring the advisory lock and verify the second transaction blocks until the first commits.
15.
by lirbank 8mo ago
Interesting! The barrier approach is more targeted: you specify the exact interleaving you want to test rather than exploring all of them. Trade-off is you need to know which interleavings matter, but you get deterministic tests that run ag
16.
by lirbank 8mo ago
Good point. The barrier pattern from the article applies to both approaches - whether you're using pessimistic locks or optimistic version checks, it's good to verify that the concurrency handling actually works. Barriers let you
17.
by lirbank 8mo ago
Here's a real-world example where atomic updates aren't an option - an order status transition that reads the current status from one table, validates the transition, and inserts into another: await db().transaction(async (tx) =&g
18.
by lirbank 8mo ago
Fair point - atomic updates like SET salary = salary + 500 sidestep the race condition entirely for simple cases. The examples are intentionally simplified to isolate the concurrency behavior. The barrier pattern is more relevant when you h
19.
Testing Postgres race conditions with synchronization barriers(lirbank.com)
102 points by lirbank 8mo ago|54 comments
20.
How many years do you give this?(cnbc.com)
3 points by lirbank 2y ago|3 comments
21.
by lirbank 3y ago
Agree. This is great though. Don't need a separate service to email to quickly email a bunch of ppl. Avoid building products around a closed platform.
22.
by lirbank 3y ago
How is this interesting for a coder community?
23.
Simple, Lovable and Complete(longform.asmartbear.com)
1 points by lirbank 3y ago|1 comments
24.
by lirbank 3y ago
Worth reposting. A thread with the author https://twitter.com/MikaelLirbank/status/1761557470395449375
25.
by lirbank 3y ago
I am taking a stab on bookkeeping software for devs running a business. But I am thinking "Hacker Worthy" could be it's own category of software. What other types of products needs to be redone hacker worthy?
26.
Hacker worthy accounting software?(starmode.app)
2 points by lirbank 3y ago|2 comments
27.
by lirbank 3y ago
Every time I do bookkeeping for our family business, I wish the bookkeeping software was more like VSCode, so I started building that. A bookkeeping app for small businesses that looks and feels like a code editor. And then I kept building.
28.
by lirbank 4y ago
I really don't like boilerplates. They're always outdated and usually include more than what I want. I also find it interesting to set up the same tools every few months so I can see what they new defaults are etc. But lately I&#x
29.
Show HN: My Favorite Next.js Boilerplate(github.com)
1 points by lirbank 4y ago|1 comments
30.
by lirbank 4y ago
He is a co-founder so I would believe he had more than a fraction of (unvested) stonks. A co-founder that left within a year, and prolly dropped all his shares (cliff, again my assumption).

More ›