78 comments
Both fakecloud and its website look sloppily vibe-coded, and its “authors” are anonymous. It’s going to take a while for it to earn trust. I’d treat it with suspicion. (Curl-to-shell pipe to install? Ugh.)
The blog posts are all attributed to "Lucas Vieira" and the dev group https://faisca.dev that is attributed as the author has 2 other projects. Lucas comes up in LinkedIn and looks like an actual person working in San Francisco.
Re: curl; this seems to work:
cargo install fakecloudDisclaimer: I work for LocalStack
"curl-to-shell pipe to install" - what's the problem here? that's pretty common on linux systems and something the AWS CLI uses.
Or is the problem the fact that this dev is untrusted and is executing a possibly malicious script on your machine?
I've run Linux without meaningful package management, as that was kind of the style of the time 30 years ago with Slackware. It can quickly become untenable.
There's no real difference between an uninspected script that gets piped straight from the URL into the shell, or a similarly-uninspected make&&sudo make install routine from a tarball. They can both execute code that does bad things (whether unintentionally or deliberately), and they can both leave a mess that is hard to cleaned up.
I've found that it is better to just avoid going down that road to begin with. Whether distro-specific packages, Docker containers, flatpaks, or whatever: All of these make housekeeping easier.
As if the MiniStack website wasn't also obviously vibe-coded lol.
You can check who’s using Ministack on public GitHub repos, NVIDIA, Block, NASA, the U.S. gov, the UK gov, and many others. There are plenty of examples demonstrating that we’re doing something good
If you still want to use COBOL because it makes you feel better or smarter, good for you. That doesn’t mean Ministack lacks quality
Otherwise your test implicitly make assumptions like “User A is always off-line” (or bucket A is always empty), add a reader of the test would have to go find where that assumption is hardcoded in the simulator and verify it separately from the test itself.
To someone reading that test it is not intuitive that user A is always off-line or bucket A is empty.
If you mock out in line, you can have tests that mock user a / bucket a — to simulate any state for any user or bucket. Perhaps multiple states in one test.
Also think about scenarios like the bucket is initially populated, but then on a subsequent request, it’s empty.
With the simulator approach, you’d have an endless number of permutations of scenarios to add — each of these scenarios would be highly coupled to the test it belongs to, so why not just put it in line in the test itself?
Any reader of the test that uses inline mocking would clearly see which scenario is being tested instead of having to dive into a separate simulator to see what special treatment is hardcoded for User a / bucket a (or maintaining potentially hundreds or thousands of simulated buckets with ad hoc names like “empty-on-second-request” or “bucket–that-responds-slow-and-times-out-but-succeeds-on-retry”.
That's where the difficulty is, where the round trip to testing this stuff on live services is painfully slow and error feedback is mixed at best.
In total my conformance suite found 583 failures out of 1279 tests.
Read the full thread on Hacker News →
Related stories
- Hacker News · 1 points · 2 days ago
- Hacker News · 3 points · 9 days ago
- Hacker News · 1 points · 5 days ago
- Hacker News · 2 points · 7 days ago
- DEV Community · 7 points · 10 days ago
- Hacker News · 2 points · 6 days ago