Andrew Stone of Oxide Engineering joined Bryan, Adam, and the Oxide Friends to talk about his purpose-built, replay debugger for the Oxide setup textual UI. Andrew borrowed a technique from his extensive work with distributed systems to built a UI that was well-structured... and highly amenable to debuggability. He built a custom debugger "in a weekend"!

Some of the topics we hit on, in the order that we hit them:

The (lightly) edited live chat from the show:

MattCampbell: I'm gathering that this is more like the fancy pseudo-GUI style of TUI, which is possibly bad for accessibility
ahl: we are also building with accessibility in mind, stripping away some of the non-textual elements optionally
MattCampbell: oh, cool
ahl: Episode about the "Sidecar" switch: https://github.com/oxidecomputer/oxide-and-friends/blob/master/2021_11_29.md
MattCampbell: ooh! That kind of recording is definitely better for accessibility than a video.
uwaces: Were you inspired by Elm? (The programming language for web browsers?)
bcantrill: Here's Andrew's PR for this, FWIW: oxidecomputer/omicron#2682
uwaces: Elm has a very similar model. They have even had a debugger that let you run events in reverse: https://elm-lang.org/news/time-travel-made-easy
bch: I’m joining late - 1) does this state-machine replay model have a name 2) expand on (describe ) the I/o logic separation distinction?
ahl: http://dtrace.org/blogs/ahl/2015/06/22/first-rust-program-pain/
zk: RE: logic separation in consensus protocols: the benefit of seperating out the state machine into a side-effect free function allows you to write a formally verified implementation in a pure FP lang or theorem prover, and then extract a reference program from the proof.
we're going to the zoo: lol i’m a web dev && we do UI tests via StorybookJS + snapshots of each story + snapshots of the end state of an interaction
ig: At that point you could turn the recording into an “expect test”. https://blog.janestreet.com/the-joy-of-expect-tests/
we're going to the zoo: TOFU but for tests 🥰
uwaces: Are you at all worried that you are replicating the horror that is the IBM 3270 terminal? — I have personal history programming on z/OS where the only interface is a graphical EBCDIC 3027 interface — the horror is that people write programs to interact with graphical window (assuming a certain size).
ahl: https://docs.rs/serde/latest/serde/#data-formats
ahl: SHOW NOTES Bryan as "semi-elderly" engineer
MattCampbell: didn't Bryan write a blog post on this?
MattCampbell: http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/
uwaces: https://www.replay.io
ahl: https://devtools.fm/episode/9
ahl: e.g. https://altsysrq.github.io/proptest-book/intro.html
we're going to the zoo: https://github.com/AFLplusplus/LibAFL
ig: Are you using proptest, quickcheck, or something else?
nickik: This really started with Haskell https://hackage.haskell.org/package/QuickCheck Its also cool that it does 'narrowing' meaning it will try to find an error, and then try to generate a simpler error case.
endigma: how different is something like this from what go calls "fuzzing"
Riking: Fuzzing does also have a minimization step
we're going to the zoo: https://github.com/dubzzz/fast-check
Riking: Property-based testing tends to be structured differently in philosophy, while fuzzers are more aligned to "give you a bag of bytes"
nickik: http://www.quviq.com/products/erlang-quickcheck/
endigma: yeah I can tell its a different structure, but the overall goal seems similar
we're going to the zoo: they are nonexclusive approaches to testing
papertigers: I think Kelly was doing a bunch of tests at Joyent based on quick check and prop test. First time I encountered it
we're going to the zoo: libafl provides a #[derive(Arbitrary)] macro that will provide the correct values for a struct
uwaces: Lots of stuff in Rust existed first in Haskell (build.rs, quote!, Derive macros, Traits, ect….)…
nixinator: https://tenor.com/view/%C3%B3culos-escuro-exterminador-terminator-arnold-schwarzenegger-gif-14440790
we're going to the zoo: “what do these means” depends on who you ask lol
we're going to the zoo: fast-check is 🔥 for TypeScript
endigma: if the tested function is deterministic and the test is testing arbitrary input and testing against the result to be derivative in some way of the input function by some f(x), don't you end up re-implementing the tested function to provide the expected result? how does the author choose what properties of a system to test without falling into a "testing the test" pit?
we're going to the zoo: Rust: “Here comes the Haskell plane!”
nixinator: Isn’t rust == oxidation
endigma: yes
endigma: in a scientific sense
nixinator: Iron oxide 🙂 lol
nixinator: Very good!
GeneralShaw: Is prop test a way of formal verification? Is it same/different?
ahl: https://dl.acm.org/conference/aadebug
ig: I mean, Haskell is an academic rese...

Get You a State Machine for Great Good

Oxide and Friends

Get You a State Machine for Great Good