 Thanks everyone for joining. Good afternoon. I hope you all had a nice lunch break to track B. We have Diego with us. Diego, thank you very much for joining us today with a much needed topic on Selenium Grid 4 and Appium together in Harmony. With no further delay, Diego, over to you. Thank you. Hi everyone. Good afternoon for most of you. Good morning for all the other ones who are here in the European time zone. And maybe good middle in the night for the ones who are attending from the American continent. Right, so I'm very happy to be here. Super glad to be in Appium Conference for the second time. And today I want to share what we have been doing with the Selenium Grid 4 and how it will work with Appium. So, first of all, for the ones who don't know me, I am Diego. I work with the Selenium project. I am a part of the team that is developing the upcoming Selenium 4 version. And if you're interested to join us to help us in the project to somehow make Selenium better for you and for everyone, please let us know. I will share some links at the end of the slides that you can just get the context for our Slack channel, our email group so you can join us and you can help us to make Selenium better. I am also part of the open source program office at Source Labs. I am a staff software engineer over there. Thanks to that I have plenty of time to contribute to open source and especially to Selenium. So thanks to both organizations, both teams to support me in my open source and contribution journey. So let's get started. What we're going to cover today is several topics. One is we're going to understand how the new grid works and we are going to go a bit into the detail of why Appium wasn't working with the Grid 4. Then we're going to jump like how are they going to work together, what's the process, what are the moving pieces of them, like having them working together. And in the end, I'm going to share a few tips on how you could migrate to Grid 4 if you haven't done that yet. And some final thoughts. Right, so let's start. Grid 4, pretty new. We wrote that from scratch and I would like to share why we did that. I'm going to share the architecture and I'm going to share a demo of its major features and different ways of use. Right, so the first question that many people have asked themselves and I was also asking myself when we started this, the grid is written from scratch, completely new, right. And to be honest, I must confess I was one of the ones saying like why do we need to do this, like things are already working and why do we need to break everything apart and do it again. And I have to say that Simon was right, he had very good reasons. And one of them is that as a team we agreed that it was hard to maintain. It was agreed that it was incredibly sophisticated. So if you took a look to the code, the structure of it was like really, really smart, but really hard to maintain and understand and read, because it was like extremely configurable, extremely extendable. So many things you could do with it, but at the same time, it was really hard to understand and to maintain. And only a couple of people were aware how to do that. And sadly, they were not at the project anymore. Also, when that grid came to be part of the Selenium project, we had different code bases. One of the things that the typical hub and node mode and the standalone mode were different set of codes. So if you were running standalone, and you were maybe having a successful test. But then you went bumping into a into a bug, some situation in standalone, and then you were running hub and node, and this was not what was not happening anymore. And then what was happening is that we had people running a test, working well in, for example, hub and node, and then they were using standalone and things were failing for them. And the explanation for that is that there were different code bases, there were different paths in the code being gone through to actually do what you wanted to achieve. And this goes together with the hard to maintain, like two different set of code doing the same thing. We fixed a block in one side, we don't fix it in the other side. So it was really, really complicated to to maintain this type of things. So with grid four, we took the approach of have a unified code base, right, it's much smarter. We have more people who understand the code, more people who have contributed and who can contribute in the future. But we also have like better things inside the code. For example, we have less traffic internally, which was one of the things that really was suffering from. And the grid had high load, and there was like internal traffic checking health checks and stuff like that. Therefore, in that case that the problem was that really, really, the grid was under high pressure. And now in grid four, we have taken that pain away by having different ways of having internal traffic and I will show an example of that in a moment. Obviously, as I said, we have more contributors to it. And together with that, we are going to take advantage of modern infrastructure, for example, this new grid has support for Docker containers built in so you could have something like a dynamic grid. You can have containers being created on the fly when you're running tests. So this is already built in and you don't have to plug different things around. We also have distributed tracing tools that bring you more observability and many more things that take advantage of the of the new type of infrastructure we have today, such like cloud and like different databases and different types of data storages to back the, the certain grid four. So it's a brand new grid right and we wrote it from scratch. And one of the plus things of doing that is that we know how it should work. And we have learned all that from the past. So we can are very well now to like put that into practice. And of course, still support the standalone mode, you can run it as if you were running with three, you can also do it with with four. So in that aspect, for example, you can just keep your original flow, just move to with for started as a standalone, the common changes a bit but in the end they're going to have the same environment you were having with with three. You can also support the habit mode mode. It works very similar to what it was working before internally there are differences but for the user for the person who wants to run tests against the grid. It's exactly the same thing. But now let's go a bit deeper into the details of what has changed it. You can also run the new grid in a fully distributed mode. And this means that you can take each one of the pieces that composes a grid and run it apart. And this is extremely good. If you want to scale up a grid, I don't know 200 300 nodes. This is very positive. For example, we have a router that is in charge of being the entry point of the grid. We have a queue. We have a session map and I will explain slowly what each of these components do. But one of the important things is that for example, the queue and decision map have been developed in a way that in the future, we can actually put different type of storage. So, for example, we can have a session map that is starting the relation between the sessions that are running and the node where the session is running, we can put something like readies on the back, so you can start scaling up this component. I will give you a few examples in a moment. So let's talk about the ways the new grid work. Let's talk about the node registration. Normally how it works today is that a node will talk to the event bus. The dotted line means that it's a message sent through the bus. So the node will send a message and the bus will facilitate its communication and it will say, hey, I am a node and I have these browsers ready for you. So what happens is that the distributor is the one listening to this type of registration message. The distributor will listen to it, will say, okay, there is a new node. I want to double check that this node actually exists. It makes an HTTP call, so the solid line is an HTTP call and it says, okay, there is a node there, it exists, so I will register it. This is a new session work. You in your laptop or your CI CD system start a new session. The request will come to the router, right? And then the router will say, oh, this is a new session. I need to send this to the queue. The queue will store it there and it will wait there for a while. And in intervals, the distributor is asking the queue. Give me the new sessions. Give me the new requests for a session. And it will take those, it will take a batch of sessions of pending to be served. And it will start checking around the different nodes, which node can serve the session. Then it will find one. It will create a session. And as a last step, it will tell the event bus, okay, there is a session which is being served by this node. Data is going to be stored in the session map, right? And why is this important? You will see it in the next slide. For example, you create a new session and you have a web driver command. For example, load a page. Then the router will see this is not a new session request. This is a command for the existing session. If I ask the session map, I have this ID, I have this session ID, could you please tell me in which node is this session running? And then the command will be forward right away. And with this, I want to remind you that this is like a smarter way of routing things. There are only a couple of components that involve it here. And for example, the heavy load that is being done by the distributor is not affected by this. So in this way, the grid is already much smarter than the previous one. But let's have a short demo. Well, actually, this one is not too short. Let me show you how the grid works. Let's talk about the standalone grid. And we're going to start a grid in the standalone mode in a very simple way. We can see that the grid detects how many processors are available so it recommends to have maximum of 12 tests on each type of browser. And then we're going to have a look. This is the new UI as well. We can see that we have the different browsers there. We can see that, for example, for Chrome on a Mac, it's going to have 12 available slots. And for example, in Safari, you can only run one session in Safari at the same time. So it's going to have only one available, right? But you could see that based on the 12 processors that were identified, we're going to have maximum concurrency of 12 sessions. So let's run a few tests, very simple tests. They're just going to go to a website, load it, and move to the next one. So actually, this is not really a test. This is just an automated script. We're not doing any checks, any verifications, nothing in that regard. So we run the script. And we see how dynamically the UI is going to show us that sessions are loading, that sessions are happening. And we can switch to the sessions tab and we can get tons of information from the UI. What the session has, the different capabilities that are being used during this session. And this is super practical for the vulnerability purposes. So let's come to Docker, for example. I will share the links showing you how you can do this on your own at the end of the slides. But here we're starting a typical hop note setup with Docker. So things are starting normally. And then when I load the UI, we're going to have three nodes, Edge, Chrome, and Firefox with their versions and maximum concurrency of one in this case. That's the default. Let's run the tests. The same ones I was running before. And we're going to see how the UI already shows that the sessions are coming there. And one of the cool things we have in the NeoGrid is that you can switch to a session. And actually you can see what is happening in there because we have VNC ready for you. So you can also debug and see what is going on in the different sessions and tests that are running. So you can interact with the browser, you can post your test, you can debug it, and everything from the UI of the NeoGrid. And one of the cool things is that you don't need any extra setup. You just need to start the Docker containers with the recommended configuration in the project. And that's pretty much it. I was talking that the NeoGrid has Docker support embedded. So you can have a dynamic grid. In this case, we start a grid and we have the possibility to run up to five sessions with Chrome, Firefox, or Edge. And that we can start containers in the background without the need to plan a huge grid in advance. One of the important things here is that if you want to record video, which is also included, you need to add a few capabilities. For example, you have to say record video through, you can set a time zone, you can set a screen resolution, and you can even add metadata for your test, like the name over there. Let's run those tests. And then what we're going to have here is a few tests running in the grid. We can see how the concurrence is getting used, but more interestingly, we're going to see how Docker containers are getting started and disposed in the background. We can see that there is a container for the browser. There is a container for the video recording. So you have to be very mindful about the resources you have in your machine because you cannot run 10 tests in parallel if you have only like four CPUs available. So this is very, very important to have stable tests. How does the configuration look? Right? You have a Docker image on the left side saying this is a Firefox container. And on the right you have the stereotype that says this is Firefox in the platform Linux, and you can enrich the stereotype as much as you want. The same thing for Chrome, the same thing for Edge. So here we're going to see what are the outputs of running these tests, because I already mentioned that you can record video, but how does this look? So you have to mount a directory, but you will get the output of these files. That ID is the session ID, right? So you're going to have all the session IDs that you were executing a moment ago. And then you can see the video that was produced. And you can also see the capabilities that were part of this session. So you can see, for example, what browser was being used, the metadata that you were adding to it. So you can easily parse this data and maybe build a dashboard for your tests if you wish. And the tests have their video. It looks pretty slick. And that's mostly what you have when you use a dynamic grid. Now let's talk about scaling up, right? One of the complaints that we got about 3 was that it was really hard to scale up. So I took the time to build a Terraform script that I can share with you if you want. And I started that grid with 100 nodes in AWS. So I'm going to run up to 100 tests in parallel. And you can see simply how the concurrency is going up as more tests are getting sent and started in the grid. So I did this last night, and it takes a while to bootstrap all the infrastructure, but when you have it there, it's actually pretty, pretty fast. So the trick here is to find ways how to bootstrap the infrastructure fast enough so your tests can run and you can also be saving costs in the cloud. Right. So you can also have all the nice things that I was showing you locally. You can have the live session. You can have everything. It doesn't matter if you run it in the cloud or locally or in an internal server. And all these features work whatever you deploy the grid. So we can see how the tests were running I think for a minute, and then it's like ramping down already. And this is mostly the core of the features of the new grid that you can use already, even though it's on release candidate, but we have no major changes to do. So I hope that you have the time to have a look at them and try it out. So that's about for the demo for the grid. Let's jump back to the core of this presentation. What is going on with Appian and Grid 4? Basically they don't work. Maybe you already saw why? Because then the way a node gets registered to the grid changes. In Grid 3, the way to register a node was pretty straightforward. There was a node and the node was sending a registration request via HTTP with all its characteristics. And the hub was saying, yeah, this is a node. It's registered and so on. Appian server was doing exactly the same thing, sending an HTTP request, registering the Appian server. And that was it. No more. And it was, I would say, pretty straightforward. But one of the issues that we had with this type of integration is that Selenium Grid and Appian were very coupled because the Appian server needed to know the structure of the payload that had to be sent to the server. And this meant that if we wanted to make changes to the grid, to the Grid 3, we had to coordinate releases. We had to tell people from this version to this version, you could use this and that. So there was kind of coupling between the two projects in that way. In Grid 4, obviously this has changed, right? Because a normal node would easily send a bus message and it will get registered as we saw before. But then what happens with an Appian server? And that server will say, hey, here is my HTTP request, registering myself to the Grid, but where can I register via HTTP, right? Like there is no point to register via HTTP. And here I would like to make a parenthesis because one of the questions might be, so why are you using a bus? Why did you stop using HTTP for requests? And one of the benefits of using a bus is that it allows and enables scaling up. In the future, I mean this is not possible yet, but our plans are to allow users to have, for example, two distributors at the same time, two sessions maps at the same time. And if we do everything via HTTP, the setup is more complicated. If we use a bus for messaging, it's much more simple because everyone can just listen and send messages without having a complex structure of HTTP calls. So, together in harmony, right? How do they work together? What's architecture? How do you can configure Grid 4 to use Appian and a quick demo? So, let's take the approach of using the typical hub and node mode. We're going to have a hub in Grid 4. And then, as I have said, I think already three times, you can register a node with a message through the event bus. I'm not having all the components explained here or detailed because they are all living in the hub right now. And then the hub will actually check, okay, you are a node, you are registered. Then we have our Appian server, which normally runs in local host 4723. And that's basically the endpoint where we create our tests, where we send our test requests to Appian. So how can we connect these two parts? So we have developed a relay server. And in this case, it's going to be a relay node that will act as a intermediary between the two parts. It will reduce it itself. It will be acknowledged by the grid because it's a node. And what will happen is that this node will be able to relay traffic to the Appian server. So when you create a session, you will send a request to the hub. The hub will say, who is able to match these capabilities? Who has these stereotypes? And then we'll find the relay node. The relay node will basically forward all the requests to that endpoint local host 4723 WD hub. So in this way, you can actually just forward things and whatever the Appian server replies, then it just gets forwarded back to you as a user. One of the interesting things of this approach is that, yeah, we have right now an Appian server that is able to talk WebDriver via that service endpoint. But you can have anything you want that talks WebDriver. For example, you can have a grid 3. If you're in the process of migrating from grid 3 to grid 4, you can connect your grid 3 to the relay node and migrate slowly in a way that the pace is good for you. You can move slowly the components around and that way you can also, yeah, step by step you can migrate. Another way, other thing that you can do is if you have an account with a cloud provider, you can also have a cloud provider acting as a node in your grid. Because for example, you have locally, I don't know, Docker containers, and you want to use Mac or other services that are in the cloud. Then you can configure that cloud service as an endpoint, and then all tests that cannot be fulfilled locally will be served in the cloud. But how does the configuration look for that? In grid 4, we are using extensively Tomo configuration files, which are much easier to read than JSON. So in this case, we're going to have a server that is running on the port 5555. And to avoid all the cluttering in the UI, we're going to tell the grid, so please don't detect any drivers because drivers are normally detected automatically. And the interesting part comes in the relay section. This is where you can specify the URL, which is where the service that is able to start with the conversation leaves. And optionally, you can have a status endpoint, you can say, you know, I want to be sure this endpoint is up before we start the node. So actually, the node will double check that this endpoint is up. And the interesting part comes in the configuration, which I will explain a bit more in detail in the demo. In the end, you can start the jar in the same way, you can say Java minus jar, etc, etc. And then you pass at the end the configuration file. Let's move to the demo so we can understand how this works. So here, I'm going to take a moment to explain the configuration first. As I said, you have an endpoint that is described by your URLs. And this could be anything that you want. I mean, you can have the app in server somewhere else. The important thing is that the relay server accesses to this has network access to this point. So let's talk about the configurations. In this case, I'm saying that I have maximum one session of this stereotype. I'm going to set the browser Chrome with the platform Android. And this is the Appian version, sorry, the platform version I'm going to use. Please note that platform version is not a standard W2C capability, so it has to be prefixed, but Grid 4 has proper matching for platform version now. Same study for iOS. So let's move to Appian. So we have to start our server, of course, so the status check works. And we can see how the capabilities are mapped. And if I refresh the UI, I can see already there is Android with Chrome, maximum one session, and the same thing for Safari. And if you hover over it, then you will see the whole description of the slot. Then let's run a couple of tests, a very silly small script checking an iOS app and also an Android browser test. So we're going to move back here and we can see how the UI is reflecting everything. The session is created. And on the right you can see how the Appian server is getting all the information. I'm just doing a job that it's done very well by Appian. I am missing the emulator, so it was actually prompt to a different workspace, but the test is running in a very straight forward way. Let's log into a website and just checking that things are there. So now I'm going to move the emulator where the simulator is, and I'm just going to run the test again so you can see both things working at the same time. And in a gist, that's almost all the demo, because it's pretty straightforward in the sense that you configure your Appian endpoint, but you are in charge of declaring what capabilities you have available locally. You have to say, right, I have Android 10, Android 9, Android 11 with this type of devices, and that's the configuration you need to provide to the Relay server, because without that you won't be able to actually match the tests requests you are sending to the grid. Right, so the test is just now finishing, or not really a test, a script that loads an app, and that's pretty much it. So you can see also the session information when the session starts, but obviously there is no live stream, since this only works in Docker containers. And yeah, that's the Appian demo. So let's go back to the slides. Let's talk a little bit about migration to Grid 4. The way we have implemented Grid 4, it should be a drop-in replacement for most of the cases. But if not, obviously there is always a case that this doesn't happen, please let us know. I will share a link where you can reach out to us and chat with us, be a Slack or IRC. If you're using the Docker images, many people use the Docker image with the TAC3 or Latest. Please note that when Serenium 4 is released, hopefully pretty soon, we're going to switch Latest to 4. So it's a good idea to start using the Docker Serenium images to get feedback about that. We have actually spent quite some time to write detailed instructions of how to use the Docker images, how they work, all their benefits like video recording, BNC, all this and that. So please have a look and if you need any help, we are there for you. And one of the cases that might be tricky for you to migrate is when you have developed some custom servlets or custom nodes in Grid 3. I believe most of the use cases are covered by other features. For example, we have GraphQL available for you to query the Grid. We have many things such as the video recording, the live view that were implemented in other projects before. So if you have a customization and maybe you'll find a way to migrate that, let us know when we can talk or we can find ways to help you migrate. But obviously, a first step to start migrating to Grid 4 is to use the relay configuration and you can put your existing Grid behind that type of node or type of standalone server and already start using Grid 3. Grid 4, sorry. Yeah, and if you have any questions, if you need anything from us, from the Selenium project or Grid or anything, or if you want to start contributing, please go to www.selenium.dev. We have our email list, our link for the Slack channel IRC, so please join the community and let us know how we can help and let us know how you want to help us as well. So a small recap. Before going through the detail of this slide, I just wanted to say that the background image means a lot in this case. We have implemented this as a first step to support Appian, and I believe it's a good approach so far. And it's something that is there that you can use already. Obviously, there are ways to make this much better to improve it, and that's why we need your feedback. So we can make it perfect together. And as I said, it's just a way to start. It's a way to find how we can support other use cases with Grid 4, but in the end, let us know how this works for you. There might be some comments that don't work properly because you're sending comments in JSON-wide protocol and maybe W3C is the preferred way, so please try it and let us know what use cases you have. It's much easier if sometimes you just join to this live channel and tell us about your use case because sometimes the issues that are getting created are very ambiguous and really hard to understand. So anyway, try both ways, but feel free to join us in our Slack or IRC channel. One of the main things here, the main takeaway is that, yeah, like the Grid and the Appian server are less coupled, they are more independent, but they're together again. So you can use them again, you can run your tests at scale, and hopefully you can share your learnings about that maybe in a future talk or to us in the Selenium project and the Appian project. And yeah, Selenium 4 is coming really soon. I hope this comes really, really in terms of weeks. So we'll see how this goes and please stay up to date, follow us in the Twitter and in the follow us on our blog that we will post updates for the upcoming news in Selenium. And with that, I really want to thank you. I tried to do this very timely so you have a lot of time for questions. But more than that, I just want to thank all of you for being here for taking the time to listen to me. And I hope you have a good experience trying out the new Grid. And again, thank you. Have a great day. Have a great weekend. Thank you Diego. That was a great session. We definitely have more time for questions. Let me go into the Q&A section. We have about 10 questions. That's great. And we are about 140 plus people. That's a great turnout for the session. One last question. I see there are some processes on this Grid 4 before going to web browser. We are currently using Selenoid GGR, like Selenium Grid, and often get a high latency due to too many hops. How about in Grid 4? Is there any data that we have for latency test? Yeah. Obviously latency is very relative, based on where you deploy the Grid, where you are having your system under test, because you could have your Grid deployed in AWS and your system under test could be on a server next to you. So there will be always latency. So it's a very contextual type of sentence. But in Grid 4, I didn't do a demo about that. I actually forgot. We have observability plugged in. So you can actually run your tests as normal with observability turned on and have your dagger server or whatever you want to use for that to collect the data. And you can see exactly how much each command is taking during the whole flow. For example, if you create a session, you can say, okay, the router took this time and the distributor took this time and the node took this time. So you can see exactly where the latency is going to be happening. So you could say, okay, maybe the Grid is taking half a second creating the session, but like loading the page is taking 30 seconds. So maybe I have to see what's the connection between my Grid and the system under test. Thank you, Diego for answering that patiently. The next question is from Muhammad Kaja. So he compliments about the nice UA. So I was trying to keep the chat room a little active. So definitely the new Grid UA is welcomed. People like it. But would there be any options to customize that in case if they want to put in the company logo or any such customization options? I mean, right now, no, I mean, the answer is no, that's the short answer. But this is something I have thought about and I haven't really commented with the team, but I think that would be a nice idea. For example, obviously have like a dark theme or allow you to supply some set of colors. Basically, if you check the UI, it's possible to, so it has like two major colors, like the purple one, and then like a lighter one. And then you have like some logos. So ideally, yeah, we could find a way to customize that. But we haven't really thought about it because it's not like something extremely important right now. But yeah, it's something that we have thought about. Awesome. That will be nice to have. Next question I'm going to pick is from Dasu Babu. We can run parallel testing by giving a different Appium port, but what is the advantage of using Grid 4 over it? I mean, usually it's just depending on your context because if you are able to handle things by load balance, your own solution between Appium servers, I don't see why you need a Grid, right? But if you want to have a single place and entry point where you can have your browsers and your mobile tests, then that's when it makes sense. It's mostly up to you. I think it's very practical. If you want to have a single entry point, if you have maybe in your company two or three teams that don't want to maintain the grid, but they want to run some mobile tests, then you can like gather all this behind the Grid entry point. Obviously, there are, I don't know how many, but there are cases where you say, I can have a simple way to balance my five, seven Appium servers. And that's it. Obviously, this is completely optional and it's a way to help people to scale up their tests together with browsers. Cool. Thanks, Diego. Next question. I'll just ask myself. Diego, have you tried Appium 2.0 yourself? To be honest, I saw demos and I didn't try it myself because I just didn't have to think. I'm very sorry about that. Right. I think I was, if you said yes, I was going towards, with this Grid 4, have you tried connecting with Appium 2. Honestly, there would be much of a difference, but I would like to know your experience and your observations on that. Yeah. I mean, I read a bit of the documentation and I saw the demos because I was worried that something in the endpoint was going to be different. I mean, something was going to be different. And based on that, I took the same approach because it's just an endpoint, right? To just forward traffic and get traffic back. So that's why I focused on something that I hadn't already installed and I wanted to show something working. But no, I haven't really tried it yet. All right. It's not a problem. The next question. Diego, you mentioned about the Observatory plugin that you forgot to demo, but do you think that can also be used with Appium? That's a good question. And right now it's not possible, but I mean, we have, it's a matter of conversation, right? We have to see if the Appium project is interested in that and we can check, we can work together. Actually, this approach is the result of the work of, I was talking with Nicola here in Solstax. We decided this could be a good approach. So this is the solution that I'm sharing here today. It's not my, I came out with me. I came out with it. I spoke with Nicola. I talked with different people. So we might find a way to do that as well with the Appium project. But yeah, right now it's not possible. Cool. Thank you. The next question is from Nikhil Grover. How are you able to run iOS simulator in a Docker container? It's technically possible, right? And there are now projects. So there has been a project for a long time in GitHub that shows you how to run a macOS operating system on KVM and also put it in Docker. So this is completely possible. You need a machine that facilitates nested virtualization, but it's completely possible. However, there are things that you need to take into account because one of the things that Apple is very tricky is that the macOS operating system is free, like different to Windows. That means you can download it and use it. But the license says that you can only use it on mac hardware. So then you would need to maybe buy a mac, format it and enable KVM and run those Docker containers in there. So it's possible, technically it's possible, but you bump into those situations. I was reading that project and it said that Apple was approving that usage if you were going to use it to report security bugs to Apple, security issues. I don't know. I mean, of course, you can do it in your company. You can run the containers, but if they catch you, I think you're on your own. All right, cool. I guess we are out of time. Diego, thank you very much for spending your time with us and showing us a shiny UI of Grid4. It's usually, when we talk about Grid4, I remember we usually pair on workshops, but this time it's quite different that I sit on the other side and get to the talking. It's quite a nice experience. I hope you enjoyed as well. Yeah, thank you very much. It was a bit like feeling at home again with someone who has like helped me work through the projects from the beginning. I think the first time we met was in 2017 or something like that. So yeah, thank you for hosting the session and thank you to everyone who was at the session for all your questions.