 I'm not sure we can actually use them all back to work on Thursday. So I'm going to put in two ways that I think the radar will be immediately applicable to some of you going back to work. I have two blips here. One is legacy in a box, which is something that we think you should do. We have been doing it in quite a few places. The other one is enterprise-wide integration test environments. That is a whole blip. I'm sure many of you are familiar with an SIT environment where different teams come together after several weeks of writing code together. Typically that is the first time when teams put their code together and do some testing. That is the first time you actually test. What we typically find is that people do it on a Friday night. It lasts all the way to Monday morning. Sometimes they don't even finish. So these two techniques really are saying that if you have some kind of legacy big box on a network, which I call the piece of art, because there's only one in the whole world, you can't recreate that. That shouldn't stop you from doing it. If it is just a piece of vendor product, you can very easily use a VM to containerize it and have developers pull it down, set up some base data for testing. If there's actually deferment work in that box, one technique that we are using quite frequently is to build a CI pipeline, a continuous integration pipeline, and make sure that we generate the VM as an artifact at the end of the build process so that teams can self-service and get this VM for more frequent contract testing. So I don't have all the blips here, but there are various libraries that we have open sourced and used quite frequently in the past, things like PACT or PACT-JVM, which allows you to specify the contract between the consumer and the producer of a service. So I think this is something that we can immediately use after all the happy tech. And finally, to close this, if you open the ThoughtWorks.com-slash-radar link at the bottom, you will see a sidebar here that allows you to build your own tech radar. So a lot of people think that the tech radar is really just all the weird things that the ThoughtWorks are hacking, but really a lot of enterprise teams have a need to limit experimentation. They also need to understand what are the best bright spot in their teams. So one of the exercises that we do quite a lot with clients and we encourage clients to do it themselves is to build their own tech radar. Bring your tech leads together in the organization, understand what are the anti-patterns, what has been holding the teams back, put them on the whole range so that you can tell people never to do these things. Conversely, if there are certain libraries that people should be using, people shouldn't reinvent the wheel, put them in the adopt ring. And you can now understand for your environment what are the experimentations, what are the new libraries that you guys are using by looking at the assess and the trial ring. So that is one way that we find quite surprising. We thought people should know the tech. But when you are in an environment with 100, 200 developers, you find that very quickly people are doing the same thing over and over again. So this is an exercise that I would encourage you to do using the build your own radar link at the bottom of the tech radar link. So that brings us to the end of the radar talk tonight. Some of us will be hanging around to answer questions. So thank you for coming.