 Thank you very much for stopping by. So I'm going to be talking about generative testing. It's a little bit different from a lot of the testing that we do today. It has some interesting properties, as well as some interesting caveats and challenges. So first off, just real quick. Basically, I'm just some guy, engineer at PayGarden, get me normal places. I work a lot on functional programming stuff. So we're actually a closure shop. I do a lot of work in OCaml as well. So I'm approaching this from a very functional programming mindset. And this talk has some pretty strong caveats. So first of all, this is mainly meant to be a thought experiment. So we use a lot of these techniques ourselves, but they're not necessarily things that you're going to be able to graft on to your existing code base right away. They take a fundamental rethink of the entire architecture in order to be able to pull off a lot of this stuff. Therefore, it's very well suited for greenfield projects, stuff where you can kind of come in and lay a very strong foundation at the beginning. I assume things like a functional stack, and I mean functional in a functional programming kind of way. So Scala, maybe, Clojure, OCaml Haskell, stuff that lends itself to very strong, immutable, persistent data structures, even immutable databases, in this case. That'll come back to help us a little bit later. And then this is not a basic talk. I assume that if we're doing this kind of thing, we all understand how we're going to have a fully parallelized setup. So we're not running a million tests sequentially in an hour. There's a lot of parallelism that needs to happen here. And that needs to happen at the browser level. That needs to be able to happen at the server level, even for your testing infrastructure. And then your runners and your reporters need to be able to run in parallel as well. With the Greenfield project and thought experiments, a lot of times I think there's value in saying, rather than figuring out what can we incrementally do better about our existing code base here? What if we were starting from scratch and we wanted to kind of create a perfect setup? And we'll never get a perfect setup, but we want to try something totally new. And you kind of see what you can achieve given no restraints. And then based off of what you can do there, you figure out how you can slowly start to graph that back and backcourt that onto existing code bases. So with that, kind of start off with what is testing for? I think you guys will all agree that testing is for exploring state transition space for invalid states. Is that right? I mean, it's a terrible definition, but actually it will help us kind of think about this a little bit later. So to give an example of what I mean, let's just imagine we have a simple cart on a PsyTorrent app. We just have a couple of steps, right?