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 fakecloud"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.
For reasons my machine with a beefy GPU is stuck on an older set of Nvidia drivers. I've got them pinned with apt. The ollama installer fucked everything up by updating stuff that apparently wasn't pinned. After I had fun cleaning up that fucking mess I found it overwrote my custom systemd service file so I had to go in and fix that.
Curl-to-shell is a bullshit antipattern. I have no interest in going back to the dark days of expanding tarballs to / and hoping for the best.
I’m not sure how your machine is configured but mine has permission boundaries and security policies that make sure programs are behaving properly. I don’t run everything with my personal user context.
But really, there is no reason not to use prebuilt packages for distribution. Curlpiping needs to die.
If someone wants to be reckless they can be. If someone doesn't, they also have that ability.
As if the MiniStack website wasn't also obviously vibe-coded lol.
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”.
In total my conformance suite found 583 failures out of 1279 tests.
When I see that, it always reminds me of Steve Jobs’s quote: ”It’s not a product, it’s a feature”.
Aren’t cloud companies like AWS, Azure, GCP the first to be interested in providing their users a meaningful way to do test integrations of their products? Shouldn’t they provide them in the first place?
Depending on what your size and other things, sometimes it's just easier to have dev instances you test against. Like S3 emulator, you could download one of many and test it but unless your test suite is extensive, the costs against S3 test bucket would probably cost you .03 cents for assurances that everything will work against AWS. If that's breaking the bank at the company, you probably have bigger problems.
Not sure if your serious.
You picked the simplest service that isn't expensive at all to run. Have you tried with an RDS cluster for example, how does that work?
Does your integration test create a new cluster to use? That's slow to set up.
Does it use an existing one? Now you might have failures due to noisy neighbors and your cost will not be small.
And that's just RDS, as soon as it's not serverless, costs aren't trivial anymore.
Again, while local cloud emulator is great for cost sensitive customers, at some point, you should test Dev against almost exact environment you will be running Prod on. If not, you are asking for eventual outage in Prod when some slightly different AWS thing bites you.
My $0.02: just use the AWS SDK to spin up real infrastructure on demand. You can provision SQS in < 10ms. Buckets in <100ms. DDB can take upwards of 30 seconds to a minute if you're adding GSIs, but it's a very small tax in exchange for the confidence it brings. (People often balk at this idea when they first hear it, but give it a shot! I have stamped out many a bug thanks to being able to bounce ideas off real infra.)
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.)