The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
11–20 of 21 posts
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#12We have effect.ts, also this was here on HN with not real improvements just with changed marketing I think.
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#13The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
You may have been lucky or privileged in working in high competency environments where the essence of containerization is truly captured in the dev practices. The vast majority of mediocre eng shops do "dockerize everything" but would still end up with leaks everywhere, artifacts in s3, endpoint dependencies, mounts that depend on the helm chart etc.
IMO containerization as a principle has failed the test of making mediocre teams productive. Such teams cargo cult ape on this term and think because they've done it theyre now webscale.
I personally like to still start with "this code should run anywhere" principle. On python especially with uv now this seems like a safer bet. At the least this forces the engineers to explicitly list out stupid dependencies in the reader.
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#14The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
You may have been lucky or privileged in working in high competency environments where the essence of containerization is truly captured in the dev practices. The vast majority of mediocre eng shops do "dockerize everything" but would still end up with leaks everywhere, artifacts in s3, endpoint dependencies, mounts that depend on the helm chart etc. IMO containerization as a principle has failed the test of making m…
I mean, to be honest, I'm the one who sets the precedent for most of the teams that I work with; that's one of my roles.
And personally, I don't necessarily follow a hard line with this. My Python API services run foregrounded in a terminal with uv run, but that doesn't mean that I'm using SQLite instead of Postgres. Any of the backend services I need that don't make sense to be foregrounded still run the same versions as prod containerized. And front end teams will tend to run a containerized API service since they're not modifying it as often.
Point being there is some conscious leeway here, but it's bounded and well-defined.
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#15[dead]
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#16The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
I agree that this isn't communicated well, but I think the idea he's going for has nothing to do with virtualization or containerization. It's reducing all application level actions to a sequence of events, complete with the data that would get passed in. That way, you can replay production events, complete with production data, locally for debugging purposes.
Unfortunately, that also makes this a PII security nightmare.
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#17Things like this have existed for awhile. The challenge is always rolling it out to peers. It's confusing to them, and kills their velocity. Just like functional programming paradigms themselves - objectively better, but also objectively more difficult to hire for.
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#18So many promises and claims in both the post and the README, yet I have no seen any evidence. I don't want to nitpick things out because it doesn't add much to the conversation, but it's assuming a lot of things about me "the majority of developers don't give a second thought to writing code with I/O tangled in business logic" This is a very fuzzy intro - "the majority of developers dont do X", is something that need…
[flagged]
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#19The problem with these libraries is that you need a strict sdlc including linters, ci, reviews and codong standards and still the language itself is not playing in your favour.
The idea is nobel and I like that from time to time somebody tries to solve it but imo its never going to go mainstream if the language itself allows for shortcuts.
Take Go as an example, its syntax is very simple on purpose and there is usually only one way to do things.
Unless we get a new language not much is really going to change in the broader landscape Im afraid.
Anyway kudos for the project, I like to see such innovations
Re: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
#20The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
I agree that this isn't communicated well, but I think the idea he's going for has nothing to do with virtualization or containerization. It's reducing all application level actions to a sequence of events, complete with the data that would get passed in. That way, you can replay production events, complete with production data, locally for debugging purposes. Unfortunately, that also makes this a PII security nightm…
The onBeforeCommand hook can be used to filter PII from inputs.