Readit Newsthats why we are starting to see a programming of ai, almost like programming building blocks
if there is a pathway for models to get smart enough to know when to trigger these hooks by themselves from system prompt or by default itself, then it wouldn't make sense to have these hooks
so many of the eventually consistent stores reflect so late that its a pain to work with their SDKs
out of curiosity, what kind of metrics or observability do we get for events that got dropped due to some issue
always liked the v0 feature where they notify to top up when the balance runs low
when do apps invoke the credit balance api? before sending events or they poll asynchronously and keep a local cache about the credit balance?
i guess caching would be a bad pattern too as the app may not function immediately after the top up of credits
while I agree to some degree, but when performance comes into picture, what really matters more is normal path vs surprise path rather than happy path vs error path
it's hard to argue what is a happy path in the code, but it's not wrong to say that io.EOF check is a normal path of the code i.e. not a surprise in production. the bad performance of errors.Is is something to be improved upon but it's not a surprise in production when there are a large number of `errors.Is` checks during normal path of the code
now coming to the surprise path of the code, here's where performance gets really important, no one wants their code to suddenly hog 100% CPU because of some special error case - https://blog.cloudflare.com/cloudflare-outage . but such surprise paths often contain a large amount of business logic that weigh much more than how slow errors.Is function is compared to a boolean check
it would be interesting to see where this line of reasoning is valid but IMO performance isn't a good argument against why errors are not normal outcomes of operations in production
but thumbs up for the article, now I know what to reference for backing the below pattern that I often use, when I first saw the errors.Is it was pretty obvious that its going to be slow but just didn't have time to prove it and use below pattern
```
if err != nil && errors.Is(err, x) {
} else if err != nil && errors.Is(err, y) {
} else if err != nil {
// handling unknown error
```
how are you thinking about capturing such dynamic decisions to choose focus area, happening outside the communication tool - like zoom or meetings etc,... algorithm can be real-time but even with data points from meetings etc,... can it be made in such a real-time?
instagram feed algo is pretty real-time but the number of unique behaviours or behaviours to people ratio is quite low. but I'm guessing in a work environment that ratio or the unique behaviours would be too high for the algo to react quickly, right?
problem is that the most common backpressure techniques like exponential back-off and sending a retry-after time in the response header have constraints on maximum backoff time they can do, in some scenarios that is much much less than the normal.
for example, imagine a scenario where a customer explores 10 items on Amazon, and then finally places an order, so 10rps for the product page and 1 rps for the order page. if order services goes down, slowly the customers get stuck on the order page and even with backpressure, your RPS keeps on growing on the order page. exponential backoff doesn't help as well
while dropping requests is a good idea, but that action is not designed by default every time, systems go into metastable state and you need the ability to control the throughput on producer side
you could solve it by keeping a different layer in between like load balancer or some gateway layer that is resilient against such throughput spikes and will let you control throughput on your service and slowly scale up the throughput as per your requirements (by user or by random)
for frontend devices, it gets exponentially harder to control the throughput. having an independent config API that can control the throughput is the best solution that I came across
This isn't a clear-cut conflict of interest because he doesn't work there anymore, but when the article started claiming that AWS gets full credit for Redis's mainstream adoption I went to look at his bio and found this.
for any open source project, the initial adoption during its initial stages would have been that project itself, later on it will be someone with financial incentive to drive adoption but that would still be a niche market and as soon as it starts to show potential aws simply copies and gives it as an offering
all 3 help with the adoption, whether we like it or not, aws has much larger distribution channel and people would rather just use one of the existing vendor than buy a new Nth vendor
It would have been so much more comfortable if we flipped this around a little - the website would present a QR code, you would open the phone and scan the code, the phone would make a request signed with your key to a URL, and the website would authenticate you because by making this signed request you proved that "something you have" part is done.
It feels like when the 2FA thing started no one considered that sooner or later all services will require it, and the UX will be terrible.
exactly :(
I wish passkeys get rolled out quickly across all sites, most people use just 2 or 3 trusted devices 99% of the time.
for those edge cases where you are working on an untrusted device, the passkey on your trusted mobile can help with authentication via Bluetooth or some QR code etc,...
Tech: Golang • Python • AI Agents
At Zenact AI, we are building AI agents that test apps like real users. I personally faced this problem at Zomato for over 6 years while handling many bugs and incidents.
We launched recently and already got 35+ signups from leading unicorns & soonicorns in India.
Backed by the Zomato mafia.
Team comes with deep expertise from Zomato’s scale journey.
Roles:
Founding Engineers.
Interns (6 months). Must’ve built serious projects or freelanced early in college.
You’ll work on:
* Building the platform from the active feedback from the customers, with heavy focus on improving the end to end latency of testing.
* Fine-tuned vision & reasoning models (currently 92% accuracy vs SOTA ~60%)
* AI agents for mobile testing, reasoning flows.
Apply: shoot a mail to sri@zenact.ai or fill form here: https://forms.gle/yWproMowhA4ZF4gv6