Comments URL: https://news.ycombinator.com/item?id=49367914

Points: 4

# Comments: 2

It’s aptly called GeoLint and I hope it might be useful to folks working with GeoJSON, especially people who have workflows/pipelines setup to generate it automatically and want more rigorous checks on the output beyond formatting. You can define budgets for things like file size, feature count, and vertex count, add consistency checks, and keep a baseline so CI can flag unexpected regressions in generated output. Based on my benchmarking, it’s pretty quick!

Would love feedback from folks who work with GeoJSON on a regular basis on if this is useful to them, and if not, what kind of features they’d like to see in a tool like this. Thanks!

Comments URL: https://news.ycombinator.com/item?id=49311145

Points: 1

# Comments: 2

Interlock is my attempt to make that transition a single explicit unit and commit all of its durable effects together in PostgreSQL.

PostgreSQL is the only supported backend right now. I was torn about some of the packaging stuff, especially the separate core and Postgres packages.

The guarantees, reference app, concurrency tests, failure cases, and implementation details are all in the repo. There are plenty of powerful tools for modeling state and running workflows; Interlock is aimed at the narrower case where you want something lightweight for atomic, database-backed transitions.

I’d be interested to hear whether the abstraction feels useful, where the boundaries seem wrong, or stuff I’ve overlooked.

Thank you!

Comments URL: https://news.ycombinator.com/item?id=49195943

Points: 3

# Comments: 0

Respectfully disagree here. People have always hired code monkeys and arguably they will hire more of them as engineers become increasingly able to defer their judgment to LLMs. It might be true that the top level companies expect strong mental models of the code but in my experience many companies (especially startups) really just want the 0->1 ability and don’t care how you get there.