I'm learning about fuzzing too, and I just wrote a tutorial about what I learned so far.[0]
The issue I found with a lot of fuzzing tutorials is that they're difficult to reproduce because there's a lot of work in setting up the environment and toolchain. In my tutorial, you can kick off fuzzing with one command, but I also walk through how I created the workflow step by step.
Garbage collection always needs to be paid for -- in working set size and CPU time. That's why you never see production kernels, databases, video codecs, or high performance games written in GC languages.
>Almost always the data is the most important thing, so I like being able to expand/replace/trash the app infra at will with no worries.
Have you used SQLite with Litestream? That's the beauty of it. You can blow away the app and deploy it somewhere else, and Litestream will just pull down your data and continue along as if nothing happened.
At the top of this post, I show a demo of attaching Litestream to my app, and then blowing away my Heroku instance and redeploying a clean instance on Fly.io, and Litestream ports all the data along with the new deployment:
I'm currently using SQLite + Litestream with one app, though it's strictly Litestream as a backup/safety net and I'd be manually standing the thing back up if it came to building the server anew, as that's not automated.
If anything, I'd probably end up looking at a dedicated PG VPS. I've started to get used to a few Postgres conveniences over SQLite, especially around datetimes, various extensions, and more sophisticated table alterations (without that infamous SQLite 12-step process), etc. So that's been an evolution, too, compared to my always-SQLite days.
Can you share a bit more about why you feel it's deceptive?
The point I was trying to make is that database servers are relatively complex and expensive. S3 is still a server, but it's static storage, which is about as simple and cheap as it gets for a remote service.
Was it that I could have been clearer about the distinction? Or was the distinction clear but feels like not a big difference?
Suggestion if you want people to look at your code (which I'm assuming you do since you linked to the PR): make whitespace changes in a separate commit from functional changes.[0]
This PR is a 50-line diff, but only about 8 lines are real changes. The rest are just whitespace changes that seem to have nothing to do with the feature you added.
IsoCity's neat. My suggestion for the functionality would be to make it easier for the user to join roads together. I drew roads at a 90-degree angle expecting the game to auto-join them, but it turns out I have to go find the right 90-degree tile to do it manually.
I've started a new city builder in 3D [1], I don't have that much free time as I used to have, but I feel like investing time on that would be better than on isocity. On a
full fledged city builder it would be worthed to implement a road algorithm
A UI that might be relatively easy for the road problem: when you right click on an empty tile, in the left hand tile selector show all the tiles that would be "valid" in that position. You'd have to add metadata about how tiles hook up, but you wouldn't need to get all fancy about constraints and stuff, or picking from several valid options.
I think that's pretty funny and not particularly malevolent. It's a fake alt rock band called Zendesk. It's obviously tongue-in-cheek and not going to deceive anyone.
Also, anytime I search for "X alternative" the results are all AI-generated garbage anyway, so I'd welcome something quirky and original like this in my results.
It seems like you're being sarcastic, but I think that's really what happened. I think it's much more about getting press for doing something funny than it is about having a meaningful impact on cluttering search results.
It's the same reason why Google paid its marketing team to make a promo for Gmail Blue (back in 2013 when Google was still doing legitimately funny fake promos):
This is off topic for Show HN, as it's just a sign up page and nothing the HN community can play with:
>Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.
>On topic: things people can run on their computers or hold in their hands. For hardware, you can post a video or detailed article. For books, a sample chapter is ok.
>Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. Make a regular submission instead.
The issue I found with a lot of fuzzing tutorials is that they're difficult to reproduce because there's a lot of work in setting up the environment and toolchain. In my tutorial, you can kick off fuzzing with one command, but I also walk through how I created the workflow step by step.
[0] https://mtlynch.io/nix-fuzz-testing-1/
reply