 OK, next up is Timo with cellular. Welcome Timo. Hi. OK, I'm Timo. Let's talk about Timo today. I'm assuming he wants me to be here. I do some kind of programming library. I support all the employees in the new role. I encourage like that, some kind of formatting thing, like really some kind of extension, sort of printed formatting, a printed template degree. And you probably ended up with this choice. Both of takes my job in sub-log file, somewhere he doesn't serve up. And that's really fine. I mean, the human eye can teach us what happens in there. Until some days or later, he just shows up and we ask him, I am doing just, doing a list of all the customers for which we have this login tree with this volume, with this type of encoding and stuff like that. And you're like, I mean, I do regular expressions, but you know. And you are trying to extract your data from your log files when you really just had it in the first place pretty well separated from your log statements. So that's kind of the idea to go beyond takes place login where you're really writing just log messages, just big blocks of strings all over the place. It's good to watch structured login while not writing the messages, but log events. So it's really just kind of keeping the collections of information at more inches than the kind of stuff. So the idea with that is you will just start logging kind of the same way. You have your login statements. Except instead of throwing away straight away the data you're formatting, you kind of keep it around. You keep it around to capture it. So instead of doing string f formatting, you're actually storing the structure of the data all along with the message template. You can see it properly, but you're waiting until the last minute to actually format it into a log message. And once you have that in place, actually it's pretty cool because you defer rendering until the end. So you can still, if you want, somehow this way to format it at the last minute into some kind of log file. But you can actually use this structure of data you've been storing in a store that supports more powerful things. Like for instance, a document store where you just store that thing and be able to pre-read it later on. Or you can store that in actually some kind of hybrid storage, like originally the database has support for this in pre-reading or semi-pre-reading of structured data, I think. Or to store it in LSD search, store it in re-uname it. Or on some sort of specific log server. So the idea is that once you have actually this information stored with your events, you can actually use tools to query it. And what's really interesting later on is your big walls, lots, lots, lots of events. You can start doing really useful stuff with all these properties you've been storing appending to your events. You can do lots of query or change stuff like just give me all the events with the same HTTP which should be requested and then correlate and track the moves of your users in the system. That's really pretty cool. So it's just really a quick introduction to structured data logging. I'm here to promote a bit like I've done in several logins. It's a .NET library. It works for a platform with a bit more than 6.5 million downloads. Oh yeah, that's done in the open source community. I don't know if you heard about that. Sorry, this is one more. Go to our website where you get a report and the industry has its questions. Thank you for explaining that. Thank you very much.