exactly this, verification should always been on the code
if someone fresh wants to contribute, now they will have to network before they can write code
honestly i don't see my self networking just so that i can push my code
I think there are valid ways to increase the outcome, like open source projects codifying the focus areas during each month, or verifying the PRs, or making PRs show proof of working etc,... many ways to deter folks who don't want to meaningfully contribute and simply ai generate and push the effort down the real contributors
Zenact AI | Founding Engineers & Interns | Full-Time + 6-Month Internships | Onsite Bangalore | Location flexible for internships (India)
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.
## Tech Stack:
Golang, Python, Java(5%), Appium, AWS, Docker
## 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%)
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%)
one thing that is getting clear is that the gains from model enhancement is getting saturated
thats 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
most of the current systems that need a reliable managed service for distributed locking use dynamodb, are there any scenarios where s3 is preferrable than dynamodb for implementing such distributed locking?
> The problem is that sentinel errors, as typically and idiomatically used, in fact are special, and are more expensive to deal with than other values. My suggestion to use boolean values outperforms them by a lot, 30x in fairly common idiomatic usage.
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
people who need to monitor a lot of channels are usually in senior/leadership layer, but one technique usually they follow is focus on a specific problem and consequently some set of specific channels for few weeks or a month and shift focus as the project/task changes
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?
controlling the producer is such a hard problem, even with exponential back off and backoff times in the response headers, you still get at minimum 2x throughput increase from the producers during a retry storm
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
I think of it as different companies helping at different stages of mainstream adoption
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
> Nowadays I open Aegis and I have > 20 services there, and trying to look for my code between all the running numbers is a pain.
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,...
I took a high enough number to showcase the problem, for a fresher it doesn't change much even if that number is as low as 15 or 20, or even if 5 people that they don't know or at higher levels
also I feel like, the number of people that hop on the incident call are almost always related to the category of the incident, sure you can always break out to a separate room, but often the person would have already realised the impact and the weight of the incident
> “Oscar, do you mind sharing your screen so Deepak and Deanna can see the weird log messages too?”
it seems so obvious from an Incident Commander perspective but so much goes into this workflow during an incident
* what if the person is a fresher, you are asking him to share screen, debug and perform actions in front of 100 people in the incident call and the anxiety that comes with it
* While IC has much more practice with handling fires continuously, for instance, if there is a fire every week in a 50-team organisation, a specific team would only be seeing their first incident once a year
* Self-consciousness/awareness instantly triggers a flight or fight response from even the most experienced folks
I don't know how other industries handle such a thing, I'm pretty sure even in non-tech there would be a hierarchy for the anomaly response and sometimes leaf level teams might be called to answer questions at top level of the incident response (like a forest fire response, might have a state wide response team and they pulling local response team and making them answer questions) probably they get much more time to prepare than in tech where its a matter of minutes
websockets and sse are a big headache to manage at scale, especially backend, requires special observability, if not implemented really carefully on mobile devices its a nightmare to debug on frontend side
devices switch off network or slow down etc,... for battery conservation, or when you don't explicitly do the I/O using a dedicated API for it.
new connection setup is a costly operation, the server has to store the state somewhere and when this stateful layer faces any issue, clients keep retrying and timing out. forever stuck on performing this costly operation. it's not like there is an easy way to control the throughput and slowly put the load on database
reliability wise long polling is the best one IME, if event based flow is really important, even then its better to have a 2 layer backend, where frontend does long polling on the 1st layer which then subscribes to websockets to the 2nd layer backend. much better control in terms of reliability
I never focussed much on sleeping postures, but one day I read this article about how acid reflux goes away if you side-sleep on your left hand side i.e stomach is at a lower height than when you sleep on your right hand side
that really changed my life, it was like, how did I waste 28 years of my life without finding this trick :D
if someone fresh wants to contribute, now they will have to network before they can write code
honestly i don't see my self networking just so that i can push my code
I think there are valid ways to increase the outcome, like open source projects codifying the focus areas during each month, or verifying the PRs, or making PRs show proof of working etc,... many ways to deter folks who don't want to meaningfully contribute and simply ai generate and push the effort down the real contributors