Also maybe, if this approach could yield stats on if some import was needed or not ?
I remember few buddies using similar pattern in ASM that just added n NOP's into code to allow patching and thus eliminating possible recompilation..
This is strongest in the "Sleepytime" episode which is based on the "Jupiter" movement of Holst's "The Planets" . . . honestly I have to skip this episode when it comes up because it makes me tear up so much, and most parents I know who also watch the show have similar reactions. "Sleepytime" is really art.
WebUSB should enable the same for more types of devices, but of course there should be appropriate permission mechanisms.
If you have general questions about axe-core, the best place to ask is our axe Community slack instance (https://accessibility.deque.com/axe-community). If you have a specific issue you'd like us to investigate, try https://github.com/dequelabs/axe-core/issues
We publish the engine (axe-core) and the "core" playwright integration library Slack is using (@axe-core/playwright) as open source, but if you're interested in what the Slack team has described in this blog, we also have a paid offering called axe Developer Hub (https://www.deque.com/axe/developer-hub) that offers a similar workflow to what the Slack folks describe here: It hooks into end-to-end tests you already have to add in accessibility testing without needing a ton of code changes to your test suite.
It's very enlightening to see which features the Slack folks prioritized for their setup and to see some of the stuff they were able to do by going deep on integration with Playwright specifically. It's not often you are lucky enough to get feedback as strong as "we cared about <feature> enough to invest a bunch of engineering time into it".
If you're interested in building these sort of accessibility tools, my team is hiring! https://www.deque.com/careers/senior-accessibility-tool-deve...
And if you are willing to answer some other questions regarding axe-core itself, I might have few.
I remarked that in the circumstances I'd need to know, that I'd google it and check the documentation to make sure I got it right.
The interviewer (who I later found out was the founder/CEO) absolutely laid into me for that answer, saying if he wanted people to google that a "thousand Indians graduating in computer science every day" could google it.
I tried to argue that I was looking to be employed for my problem solving skills and experience rather than rote knowledge, but he was really angry. He literally said to be verbatim, "Let me give you some interview advice, NEVER tell an interviewer you'd google something". He also made a mildly off-colour remark that if he "wanted someone just to google, [he] could hire one of thousands of fresh graduates coming out of India".
It was an experience so bad that it inspired me to create a glassdoor account just to leave negative feedback, something I've never done before or since. The recruiter was absolutely pissed, and still doesn't provide me leads, which is kind of annoying since he's the most active C#/.Net recruiter in my area.
But my point is that some people have absoultely atrocious interview manners. Interviews are a two-way street and I discovered that there was absoultely no way I'd want to work with them. (Even when I just thought they were a team lead rather than the CEO it was enough to put me off.)
Had somewhat similar scenario. Company's internal headhunters had reached out to me once already before and I did few interview rounds with them and said no. Year later they reached out to me again and had to go thru tech interview again.. during that I did help(sleep) on python repl and mentioned why; since I haven't used sleeps on my own code I wanted I make sure that if sleep will yield cpu time or not. Mood of the interview changed at that point and got rejected by not having enough skills in Python.
Another case; One of the interviewers was late to the meeting and started to shout profanities cuz my Audio Quality was poor. And it was - thanks Sony XM's but the way he acted on the call really gave lasting impression on their "company culture"
> We have 730+ days with 99.993% measured availability and we also escaped AWS region wide downtime that happened a week ago.
This is a very nice brag. Given they are using their ddos protection ingress via CloudFlare there is that dependancy, but in that case I can 100% agree than DNS and ingress can absolutely be a full time job. Running some microservices and a database absolutely is not. If your teams are constantly monitoring and adjusting them such as scaling, then the problem is the design. Not the hosting.
Unless you're a small company serving up billions of heavy requests an hour, I would put money on the bet AWS is overcharging you.
My opinion on this: docker sort of changed the game here. It sort of enabled a lot of people to get a "new and fresh" level of abstraction to not bother about bare metal.
As an example, I work in company where most consultants are doing DevOps and k8 is big part of that.
What made me consider that? I've been told multiple times that "you know your stuff" when I mention some kernel or userland feature that container approach provides.