HN user

joohwan

133 karma
Posts15
Comments10
View on HN

What stood out to me more than this particular project is the visible acceleration of a phenomenon many of us could foresee, especially over the last year or so: people can build a version of the same idea faster than ever.

After like 10 minutes of searching I found multiple similar swift projects (most of them are just a couple of weeks or months old):

https://github.com/tdeverx/contained-app https://github.com/nico81/iContainer https://github.com/wouterdebie/davit https://github.com/Augani/dory https://github.com/tofa84/berth https://github.com/erdaltoprak/ContainerUtility https://github.com/andrew-waters/orchard

There were more if you include ones with fewer GitHub stars, CLI-only, non-Swift etc. but you get the idea.

People will increasingly be able to build their own version of the software they want. As that happens the value of someone else's decreases. The era of hyper-personal software is coming.

LLMs can find issues that traditional SAST misses, but today they are slow, expensive, and nondeterministic. SAST is fast and cheap, but requires heavy manual rule maintenance. Our approach combines the strengths of both. The scanning engine is fully rule based and deterministic, with a rule language expressive enough to model code at compiler level accuracy. AI is used only to generate broad rule coverage across thousands of patterns, without sacrificing scan performance or reliability.

I've been working on a 2D game which involves pixel art. I wanted a way to quickly look up a color by hex code or RGB values on the terminal, but could not find a tool for it. So I created Colorpedia. It displays colors, shades and palettes along with details on multiple models (HSV, HSL, CMYK etc). It also outputs JSON for programmatic access.

Very true. I indeed found the lack of visibility into per-message information very painful when I was building this. One way I tried to alleviate the issue was providing a consumer "callback" to make it easier for users to plug their own code in to handle job failures (like your example of using SQS).

I've also thought about reserving a topic + consumer group specifically for failed jobs and bake the retry logic into KQ itself. But that's an area I must explore more.

I'm not sure if I understand what you are saying about batching consumers. What do you mean by batching in this context? Thanks for your input.