Thanks! The backend and chrome extension is not yet open source, but we have to do some work to make that possible expected in the next week. It performs best with Gemini Pro 1.5, so the backend is important for now, but long term we can switch to a local model as soon as possible.
The chrome extension is required to target off-screen elements, using a websocket server locally. This allows a 100% replacement for previous selector strategies.
If you are interested in contributing email me at rohan@cheatlayer.com and I can help get you set up.
not sure how. But when I asked GPT with this line and the issue was found exactly.
The issue is tiny and slipery for a very big table. But I am still curious of
why test can not find it.
>During the work day, this was fine. We probably committed 10-20 times a day (directly to main of course) which would cause new backend deployments to occur, giving us 40 new IDs for customers to potentially use.
They just use the test env for prod?
When to push code, the CICD should be run and some examples should be run too here. And every time, the env should be clean.
Here the database does not change from test to production.
I came accross a lot of such info from redhat. And I tried podman which is not bad because my scenario was not complicated. But days before, I tried podman-compose which behaved so poor. That's a pitty. After years, podman's ecosystem is so poor. I don't want to be trapped by sorts of small/hidden pitfalls. I have to switch back docker then. The quality prevails, not the advertisement. PS: I did not read the passage. The title is enough.
I read the blog twice and have some thoughts:
The root cause seems is as: "While deploying a change to our prefix advertisement policies, a re-ordering of terms caused us to withdraw a critical subset of prefixes."
And a dry-run: "a Change Request ticket was created, which includes a dry-run of the change, as well as a stepped rollout procedure."
And a Peer review: "Before it was allowed to go out, it was also peer reviewed by multiple engineers. "
I would doubt the expertise of tech guys of cloudflare, reviewing the change. And there was a dry-run.
But is it really OK to apply the change to a spine network which would affect 50% network traffic? Just out of peer review and a dry run? No green/blue, no gray release, maybe these are not proper for a small change here. But this "small" change really got big affect. I thougt it was worth it.
And from my shallow experience, the dry-run would always have do nothing to the env. It is dry-run anyway.
And at last the three lines are found out. So I wonder how did this re-order happen? And why?
With these tiny changes, there should be some mechanism to verify their correctness, not just review and dry-run.
We use a phased rollout process for all routine changes (like this one). Once a change has passed peer review and the "dry-run", changes are rolled out to progressively larger slices of our production environment, with monitoring systems and engineers watching for adverse effects.
The specific network locations that were impacted by this change were amongst the last to see the change rolled out. One deficiency in our deployment strategy (which we will correct) is that no network locations in the affected "MCP" configuration received the change early in our rollout process. If that had been the case, we would have found the problem much earlier and the incident's impact would have been much reduced.
It was a story about my last manager. 2 years ago, I transferred to Cloud team internally from blockchain. Yeah, both of them were so hot and even today. I had to make this transfer because I have to relocated to another city where my family resides. And my mom was so sick, I had to consider to take care of her. This is the background.
At the first few weeks, I tried to learn the new knowgede of cloud native and it was so depressed. I was so new and I was not an open man. Because my mother's health condition always makes me so gloomy. I could not be open. So it was not efficient. Well, I love opensource and I have some experiences. So I was assigned to do some open source projects for our products. Now here we have the them:
1. My manager called me to out of the opensource team for something else that I did not listened and not interested at that time.
2. He said this was his team and he was the only man can decide that no one could change.
I was a little shocked at first. And hated this then. But I could not change this. I knew the only way I changed this that I argued with him or leave. I knew at that time every body in our team had quarrelled with him. But I felt down at that time I could spare the energy to fight.
I made my mistakes. Not sure this was a mistake. I have no idea who things would went if I had a different choice. I chose to accept it even though I felt so bad. I could have choosen another blockchan startups.
So I had a bad 1.5 years work experience in my career.
One interesting story:
My manager wants us to show our minds about team. Guys had their voices out and the summary sent to him, which were all agaist him. Can you image what he looked like?
He denied all the comments from guys. And continued to do as his will. Then 8 months later, our team was laid off, all but me. I had a health condition at that time.
It was a bad experience. I should not have hesitated. I should have called out my thoughts. Or just leave.
Life is short. Please stay happy and focus on the lovable things.
The first time I programed in mainframe, I suffered a lot. I am young. We young people at least myself is people programming from top to down, but you guys, old programmer programed from down to top. I mean from low level to high level of computer. Early days, people would have to learn hardware a lot to program. This is my impression.
