This would be deployed separately but in close proximity to your sandboxes. You'd want to add network restrictions around sandboxes to only allow outbound requests to AV.
You'd add HTTPS_PROXY to your sandbox environment and pre-configure it to trust the AV CA.
The authors praised Rust debugging capabilities (also) in VScode, can somebody point to some references on this? From what I’ve seen around and what I’m able to debug in my VScode environment I might be missing something…
For Linux, I haven't used VSCode for debugging myself, just `gdb --tui`. Since VSCode supports driving gdb I would think everything would work fine.
For Windows, I used to debug Rust using Visual Studio (not Code) without problems, because Windows binaries built for the windows-msvc target generate regular .pdb files that VS can work with regardless of the source language.
Both VS and gdb have a problem where the representation of Rust values when printed / watched is funky, especially with enums, because the Rust type gets translated into C terms. But it's not unworkable.
This is something I’d love to try on my personal projects.
I recently used act[0] to locally test my GitHub actions pipelines and worked okay, the fact that I could interact with the Dagger API via a Python SDK could be even more convenient, will definitely try!
He's probably referring to the trading desk or similar teams.
Stock traders forced a lot of advances onto software. Random examples of high-perf stuff from that space include the new garbage collector in the JVM with a minimal pause time and LMAX Disruptor. Multi-threaded GUIs are relatively common in that space as well, to ensure that one hung control or window won't stop anything else.
I've known a handful of software engineers who have stopped through The Trade Desk for a year or less. It doesn't sound like a great place to work to me, despite the high throughput their software demands.
reply