The Context Podcast: TopCallStats
Featuring:
- Ernest Koe, CEO of Proof+Geist
- Kyle Duval, Software Engineer
- Brian Ouimette, Senior Software Engineer
Description:
Join Ernest, Brian, and Kyle in this episode of The Context Podcast! This episode is a demo of TopCallStats, our newest tool in the Ottomatic Cloud Console. Upload your data, or pull directly from your Ottomatic server to get a visual graph of your performance data. Instead of parsing through an indecipherable log, you can get a clear understanding of your data and pinpoint issues with ease. In the last half of the conversation, they discuss how they used agentic coding to flesh out the tool quickly.
Find this episode on YouTube.
Ernest Koe (00:02.735)
Cool, great.
Ernest Koe (00:07.321)
Ready?
Kyle (00:10.99)
minimizing all the various things on my computer.
Ernest Koe (00:17.042)
hey guys.
Kyle (00:19.694)
Hello!
Brian Ouimette (00:20.664)
Hello?
Ernest Koe (00:21.295)
So welcome to another episode of the Context Podcast. And I think today I've called in Brian here with me because we've got some pretty interesting things that we want to talk about, about the current and maybe some future releases for Automatic, the most amazing file maker developer and hosting platform by us, Proof. So.
Kyle Bryant, what's new and what's shaking? What cool things do we have to talk about today?
Kyle (00:54.486)
Yeah, so the automatic console has been focusing a lot on monitoring and giving developers tools to figure out what's going on in their server, what might be going wrong, and to pinpoint issues both on the server and in your solution for how to make things work faster and work better. So the big one is the top call stats tool. So it is a tool that lets you...
grab the top call stats from your server or upload one if you don't want to connect your server to the console and do a bunch of manipulation of the log, figuring out what things take the longest and it lets you upload XMLs so you can map those unreadable table and field IDs to things that actually make sense to you and let you hunt down problems.
Ernest Koe (01:44.409)
Wait, wait, so let me get this right. I've seen this demo before, but I just want to make sure that I understand what we're saying here. right now, is it out? I think it's out, right? I think we've shipped it. So the idea here is that if you have a filemega database hosted on automatic, like today, you can see, is it in real time? The performance of that solution.
Kyle (01:55.436)
Yeah, yeah, it's live.
Ernest Koe (02:13.153)
using top call stats lock that's being generated by the server. Did I get it right?
Kyle (02:17.494)
Yeah, I mean it's not quite real time, but it's pretty close. Yeah. Right, you can pull the log up to current time, yeah.
Brian Ouimette (02:17.656)
Correct.
Ernest Koe (02:20.471)
Near real time is what I would say because it's doing some magic in the background to kind of grab that stuff,
That's freaking cool. Can we take a look? Do you have it?
Kyle (02:32.046)
Sure. Let me share my screen.
Ernest Koe (02:37.667)
So as you were doing that, so Brian, maybe help me frame this here because before the old way of doing this was kind of painful, right? Because you had to export, you have to turn it on first and foremost, right? Top call stats on your server if it's not already on. And then what? You have to export that top call stats log and then go find it in the folder where it's exported. Then you got to grab it and then what? I think.
Maybe run it through.
Brian Ouimette (03:06.85)
Then you have to pull it through, like FM perception to try to map IDs and figure out what's going on.
Ernest Koe (03:13.761)
Right. It was very cool that you could do it with FM perception, that you could pull it in and if you map it to your DDR, you can kind of see how those IDs and objects actually translate. But there's a lot of different steps, right, to even get that done.
Brian Ouimette (03:30.51)
do that. Yeah, and most of the time you just try to look at the logs and maybe do a quick analysis to figure out. But the logs themselves are just unreadable for the most part. You know, something's happening in a file in a table that has an ID of 123, but you don't know what table that is or what fields it's referencing.
Ernest Koe (03:43.695)
Right.
Ernest Koe (03:53.081)
Yeah, yeah, Kyle is showing that now. So yeah, this is the output that we get from the logs.
Kyle (03:56.045)
Yeah.
Kyle (03:59.471)
So you'll see I have big file, table 148, containers 35. Very useful.
Ernest Koe (04:01.326)
Right. Right. And you have no idea what table 148 is. It could be like, yeah, customers. could be underscore or something. It could be whatever.
Kyle (04:07.766)
no idea what that is. So.
Kyle (04:13.454)
Yeah.
Ernest Koe (04:14.498)
Okay, cool. yeah, it wasn't a great experience before just because of like the disconnection between the server logs and ingestion process you got to go through to get to that. And I think we've gotten this down to where it's basically one click or no clicks. Let's see.
Kyle (04:33.282)
Yeah, so if you're in the log here, can click this in the top call stats log or in the top call stats, any of the rotated ones. You can just click analyze and that will take you over to the top call stats viewer with the log preloaded for you.
Ernest Koe (04:36.654)
Ahem.
Ernest Koe (04:41.41)
Maha.
Ernest Koe (04:45.954)
Holy cow.
Kyle (04:50.082)
So yeah, this is the viewer. You can view it by like the operation type, which is the operation listed in the top call stats log, or you can view a timestamp based one, which is over time, what things are happening and how long are they taking. So you see all that bucketed. They're bucketed by like the length of the query. And then you can filter and sort and say, show me everything that happens over a second, which I have nothing that is over a second long, which is good, but.
If I say 10 to 100 milliseconds, then that'll show me this graph, and I can go back to the operation, and then that'll show me only things in that bucket. You'll also see down here we have the full log, so you can sort and filter and say, for the total elapsed, me things that are greater than one second, or whatever. So you can...
Ernest Koe (05:34.382)
Hmm.
Ernest Koe (05:38.927)
So we're going to be able to pinpoint, like say that if you go back to, there was a list of slow operations under the 10 to 100 millisecond range. And I can go up to the top and say, hey, the perform scripts part, let's go back to the very top there for a second. like perform script on several operations are maybe a thing I want to pay attention to because that seems to be the most costly. Right. Yeah. Then I can.
Kyle (05:45.654)
Yeah.
Kyle (05:56.827)
yeah.
Kyle (06:00.75)
Yeah, they're generally taking a while. Yeah, and you can also, if you don't want to filter it by this, you can just come down here and sort it by the elapsed time and say, oh, this big file, I have a find that's taking 200 milliseconds.
Ernest Koe (06:10.219)
Right.
Right.
Great, great. This is freaking cool. I think it's going to save a lot of time. So what was the inspiration for doing this? I know it was kind of a bit of a skunkworks before, right Brian? What's...
Brian Ouimette (06:29.102)
Yeah, so Angela had brought up top call stats and how it was just unreadable. And it's like, it'd be nice just to see a graph and, you know, the table below with the logs to see, you know, what's going on and kind of get a visual of everything. then from there, it kind of morphed where it was like, well, it'd be nice to see a translation of what
these table and field IDs are, which then turned into, it'd be nice to see more data about what's going on in the file, which is where that inspect button comes into play, which will give you more.
Ernest Koe (06:57.016)
Hmm.
Ernest Koe (07:10.936)
All right.
Kyle (07:11.884)
Yeah, I guess speaking of that, we showed off the log parsing, we can show off the XML a little bit too. you can upload your own XMLs and upload your own log, but if your server is connected to the cloud console, you can also just pull them. So I'm going to pull only this better auth test one. This one.
So using autoFMS, this can grab an XML from the server and download it to your browser and then parse it out. So you'll see now where earlier it had unreadable table IDs, now it has actual values. This one probably got deleted or something, so it doesn't exist anymore. But so now you can say, this commit records that takes longer than all the other ones is on the user table.
Ernest Koe (07:49.518)
you
Kyle (08:02.796)
And then you can say, I wonder what's going on on that table. Let's inspect it. And you can get a basic functionality for this table, what fields are in it, what table occurrences are using it, what layouts are using it. You can navigate through your whole file and see a full list of tables and layouts and scripts and see the themes that are used. Apex Blue.
Ernest Koe (08:11.214)
It's awesome. Right.
Ernest Koe (08:21.976)
That's It packs blue. my goodness. That's the problem? Yeah.
Kyle (08:28.526)
And you can jump up and down in here and see which layouts use which themes.
Ernest Koe (08:31.329)
Right, right.
That's amazing. So do we have to load up the XML each time you do this or does it keep the cache in? I kind of know.
Kyle (08:41.678)
yeah, so if you're, if you're pulling it from the server, it makes a new XML every time you can, when you pull from the server, choose to download it. So you can just say, grab me the XML and also put it on my computer. So this will load it into the top cost as viewer and also download it. So the next time you come in, you can just drag and drop it right in there. but there is no cash just in case you're changing stuff.
Ernest Koe (08:51.043)
Hmm.
Ernest Koe (09:05.486)
So when you come back, will basically start as if the XML doesn't exist. And then you just got to pull and reset. Well, that's cool. So maybe in some future, that will be automated too. And you can say, hey, get XML from an automatic server or an autofm server and be done.
Kyle (09:08.556)
Yeah, it'll start fresh. I press, yeah, if I reset, I'll pull and it'll do it all again.
Ernest Koe (09:30.488)
future version. But this is already...
Kyle (09:32.824)
Well, mean, can, yeah, so you can already pull it from the, but it doesn't, it doesn't include ones that are.
So you can also do the same thing with the log. So I can pull the log and download it, which you can see downloaded it to my computer. And then can pull from the server and download it.
Kyle (09:58.969)
that will generate an XML, pull it and really wants me to know I should change my password for that file. And then if I reset here, right, I'll be able to grab these two files from my computer and you can just drag and drop all of the files onto this first.
Kyle (10:20.719)
can just drag and drop all the files onto this first entry. Sorry, my files got named something weird because I already had these files downloaded from a different demo. So you can just drag and drop everything and then it just does it all at once.
Ernest Koe (10:35.453)
Mm-mm.
This is very cool. I recall as we were talking about this that one of the things that really motivated us to do this was, you know, hosting customers with sort of performance questions on databases, And so we were seeing a lot of my files are slow or something's going on, something's happening with my scripts and it was hard to support. how has this helped, if anything?
Kyle (11:01.667)
Yeah.
Ernest Koe (11:09.845)
something you can speak to Brian or Kyle.
Brian Ouimette (11:17.113)
I know we're working on additional features that tie into other logs as well. So we can see server performance at the time and then pulling in eventually additional logs that will tell us events that were happening through the event log, access logs, additional data that will help give a bigger picture of what's going on during that.
Ernest Koe (11:42.135)
Right.
Brian Ouimette (11:45.708)
that time period where we're seeing the performance that's.
Ernest Koe (11:49.794)
But we are actively using this even for ourselves, for support. It sounds like that's already been making a big difference.
Brian Ouimette (11:54.734)
Correct, yes.
Kyle (11:56.208)
Yeah, and I can also, let me share my screen again. These features aren't quite released, but they're gonna be released probably before this podcast even goes live. So.
Ernest Koe (12:05.058)
good.
Kyle (12:12.557)
This is in our staging branch right now. You'll see these two new sections where you can do server monitoring and server log viewer. So if I select the timestamp and I, the monitoring will only work for stuff in the last 48 hours. not quite that much. So if I select like this time period, if I select this time period, where are we at? that went really far.
Ernest Koe (12:18.207)
Yeah, yeah, yeah.
Sweet.
Kyle (12:43.009)
Let me get there. No. Let me get there. Aha! No. Okay. We're almost there. my goodness. Okay. Well, that's a bug.
Ernest Koe (12:46.445)
There we go.
Ernest Koe (12:56.641)
cut it up.
Kyle (12:59.509)
Hold on, let do this manually.
Filter from.
Today's the fifth from yesterday until today.
Kyle (13:14.413)
And then I say, I didn't select a server to pull the logs from, so it's not showing one. But I can select a server here, and this will.
This will not quite work because...
My range is not... This is the problem, is this server has almost no data on it. So nothing has happened on it in the last day. You know what I should do? I should try Acme Prod instead. Hold on.
Kyle (13:51.119)
If I grab, act me prod.
Kyle (13:55.908)
doesn't have it. If I grab back me win, which does have it, I'm pretty sure. I pull this log.
Kyle (14:07.625)
I grab an XML from the server, which I don't need an XML from the server. And then you'll see here this should have to f in the last couple days, but only one little section, apparently. That's okay though, except it's only giving me a tiny little bit of the monitoring, but...
Ernest Koe (14:22.102)
That's okay.
Kyle (14:28.591)
So yeah, you can, for a server that has more stuff going on, you'll be able to see a lot more information as monitoring. This is only for automatic servers that this monitoring of it is available. And then you can see the CPU or the disk IO or disk utilization or whatever you want from the stats that we have available in the monitoring tab back in the server dashboard, which is another new thing in the cloud console we could also talk about. But then you can also select a different event, a different log. So if I select a larger time range than this.
Ernest Koe (14:46.892)
Mm-hmm. Mm-hmm.
Kyle (14:57.827)
like this time range right here, then this log you'll be able to pull for that period of time.
Apparently nothing happens in the event long for that period of time. That seems unlikely.
Kyle (15:29.369)
Doesn't want to show anything. Okay, well, this is why it's a pre-release feature.
Ernest Koe (15:34.412)
We don't have to include this in the podcast. Do you have something here that we can show? We can kind of reset the segment and talk.
Kyle (15:41.133)
Yeah.
Kyle (15:45.487)
I can show off the log thing on Acme Dev probably. So we grab this stuff from Acme Dev.
Kyle (15:56.815)
Pull this.
Kyle (16:07.211)
She doesn't want to point logs. That's so strange.
Kyle (16:13.291)
Okay, well, I guess not.
Ernest Koe (16:16.876)
Okay, well, let's skip this. can re-record this section later. note to Thanh here, we're just going to 1628 timestamp here, and we're going to skip to other topics. So, so topical stats looks like it's, we dropped it. It's going to be pretty awesome feature, and I think we've got a couple more new things that are on the way, right, Cal?
Kyle (16:19.96)
Yeah.
Kyle (16:45.399)
Yeah. Yeah. So the top call stats is useful for seeing what's taking a long time. And you can kind of pinpoint what parts of your solution might be taking a while, but it's a little more difficult to figure out why that's happening.
Ernest Koe (16:45.964)
You wanna talk a little bit about that?
Ernest Koe (17:02.796)
Mm.
Kyle (17:03.151)
So oftentimes a true analysis at the top call stats requires looking at how many connected clients there might be and what's going on on the server and if there's some schedule running that's got a high server load going on. So we're currently working on getting you able to see, for automatic servers, being able to see monitoring stats. So being able to see what the CPU load is and see how many connected clients there are and all those kinds of things. And then for every server connected to the cloud console, being able to pull other logs
in and filters them to the same time range. So if you're looking at a top call stats and you look at a top call stats for a full day, right, you can at the same time see the event log for that day or, you know, the stats log from FileMaker and kind of map periods of time in the top call stats to other logs and see what's going on. So maybe you haven't.
Ernest Koe (17:50.701)
Yeah, I'm looking forward to that. That seems like a pretty cool thing. When are we thinking that's going to ship? I know we're working through some final things on that.
Kyle (18:00.568)
Yeah, hopefully next week. Soon is the goal.
Ernest Koe (18:03.372)
Cool. Awesome. I want to go back to Top Close Sats a little bit and kind of zoom out. We've got a few minutes here. I'm actually kind of curious and maybe it's worth sharing with listeners. Like, what was the process in developing this? I know, Brian, you were involved and then it escalated and whatnot. And maybe it's worth just like coming, talking a little bit about that process.
Brian Ouimette (18:30.594)
Yeah, so I checked Angelo's kind of thoughts and decided to run with it. So I ended up using cursor and one of the sonnet LLMs to start working through the issue and generating, you know, the repository and the initial code base and
slowly work through building out the chart and the table below and then slowly kind of added on additional features like the inspect button and then the modals for that. And once I got it to a point where we needed some more performance, know, enhancements and tying it into the console, that's when I...
to step back and hand it over to Kyle to review and start integrating with the console.
Ernest Koe (19:35.264)
Yeah, think two things jump out on that.
Ernest Koe (19:41.578)
I think at Proof, we've been using AI for both research R &D and really across our entire workflows and work, especially on the product and development side of things. think that's AI and HNTEC engineering has been deeply embedded now in the way we do things, Kyle, think you live in Cursor probably most of the days and...
Kyle (20:09.328)
Claude all day every day.
Ernest Koe (20:10.219)
cloud all day every day, I live in cloud all day every day. And I think what's interesting about the story is that, you know, there was a design idea, there was a problem that we need to solve and even the prototyping and sort of investigation, exploratory aspect, we've spun up as a gigantic process, right? So you did a couple of spikes, Brian, on this process, you kind of fleshed out what the UI was supposed to be, you work with AI to develop it and then...
At some point we developed a spec, it's like this is the idea, this is the working prototype, and now how does it fit into automatic, and then I think that's when unquote product was brought in, you were brought in, Kyle, to really start engaging in that and then taking that forward, Does that, was that my narrative here, like does that align with what actually happened? I don't wanna tell a happy past story, I just wanna share with listeners how we do things at Proof.
Brian Ouimette (21:04.813)
It's in that's pretty accurate.
Ernest Koe (21:08.191)
Whether, yeah, so, yeah, I mean, I'm curious, like, so.
Kyle (21:08.548)
Yeah.
Ernest Koe (21:15.615)
you know, moving from a non-agentic AI development posture to something that's so fully deeply ingrained in what we do. I what would you say is different, like, now, in how we build and how we do things?
Kyle (21:32.645)
I think generally we can... I mean, we're faster. I think there's a much higher... there's a much larger need for good, solid testing and good, solid harnesses for these things. Whereas before it was... we were relatively... we weren't slow slow, but we were relatively slow compared to where we are now. But...
Ernest Koe (21:45.503)
Mmm.
Kyle (21:57.337)
A lot of the stuff was being handwritten and hand tested and things are still being hand tested but less handwritten and therefore the testing like automated testing was important but like less crucial. Whereas now it's everything has to be tested because
if something touches a piece of code that it shouldn't have and we don't catch it in the development process, it's much more important. So there's the testing part and that part's much more important now. I'll also say that the feedback loop is much faster. instead of it being...
somebody has a feature request in the community, I put it into a list, and a month and a half later I look at it, I can say, someone has a feature request in the community. I can grab that URL, I can plug it in and say, hey, this feature request came in, let's make a plan to do it, you know? And it can go read that feature request.
Ernest Koe (22:40.011)
All
Kyle (22:53.808)
pull it down, figure out what in the code base needs to change, ask some clarifying questions about, does it mean this feature over here or this feature over here? All that kind of thing. And you can direct it and get it going where you need to and add some sort of some taste on top of it into like a, they requested this, but I think the helpful thing would be really doing what they requested with a little extra or a little less. So there's definitely still that human in the loop element where it's.
Sometimes features just don't really make sense for what we're building or sometimes features make sense, but would make sense slightly different. So the human part is still very important. It's not just like a direct feedback.
Ernest Koe (23:37.152)
Yeah, it seems to me that I think this this lines up really well with my experience, which is that we're sort of moving up a level of abstraction. It doesn't. We can't abdicate the business of actually understanding what we're trying to do, right? I mean, I don't think you can write good tests without knowing why you're writing good tests and what you're trying to guard against. And so it's it's a little bit weird. Like, it's like, you know,
before a lot of things were just felt like, know, this is expensive to do and maybe we have to corners because of time and budget and whatnot. And now it's like, okay, well, that stuff is not so expensive anymore because we can get to it first. And the actual spitting out the code part is not the thing that's the most consuming. So you're spending all your times on harnesses and scaffolding and...
making sure the loops actually run and you got feedback loops and that's the agentic part of this that I think really interesting, right? And obviously it doesn't, that's not even talking about figuring out which problem to solve and how we want to solve it, right? Like, do we export XML? Do we just pull it directly from the server? How do we connect these pieces?
Kyle (24:52.474)
Right.
Ernest Koe (25:01.087)
So I think there's a lot more design involved, I'm really excited about. I think it's a move us into a much more user-driven, user-centric product organization.
Kyle (25:14.874)
Yeah, I do find it a lot of the time the design is the thing that takes the longest now. Whereas before it was like, wanna add a feature, you'd like in the process of researching what you would need to add where you'd just start developing it because you're already there, you know what you need to do there. But there was no, there was no.
Ernest Koe (25:20.937)
cox and
Ernest Koe (25:32.009)
Right, right.
Kyle (25:38.659)
full research at the beginning to see what all the different pieces were and how they were going to interact and all that kind of thing. And with a full stack application like the Cloud and Solo or like AutoFMS, which I also develop, those things, having the full stack in one repo lets you kind of manage the full feature at once and figure out what everything needs and kind of handle it on an all-fail swoop. So.
Ernest Koe (26:03.37)
I don't know if this jives with your experience, but I'm finding that design is also a lot less precious, and so I can take a lot more wax at things,
Kyle (26:12.281)
Yeah. Yeah.
Ernest Koe (26:16.415)
Before it be like, invested all this time. I don't know. I don't want to change that.
Brian Ouimette (26:20.494)
You
Kyle (26:22.819)
Yeah. It's not even, I also find the designs are less precious. The actual generated code is less precious. Like if you generated a thing and you try it out and you're like, nah, I don't like this. You just throw it out. It took you, you know, it didn't take you that long. It took you about as long as it would have taken to, you know, sit down and think through it and develop half the feature in the first place. But now you've got a full working feature and you're like, man, this doesn't really make sense. Nevermind. And there's no like, I worked on this for two weeks. We have to use it kind of situation.
Brian Ouimette (26:23.83)
you
Ernest Koe (26:27.274)
Right. Right, right,
Ernest Koe (26:32.666)
Meh, right.
Ernest Koe (26:51.807)
Yeah.
Yeah, sometimes it's like, it's not even that we are moving faster net-net. Like, you know, we may have gotten to the same quote unquote product in the same time span, but certainly we're covering a lot more territory and we're much more rigorous in the things that go into the final product.
Kyle (27:20.079)
Yeah, and I think it makes it easier to add the things that would have been justifiable not to add before. So for example, like with the new monitoring tab in the Cloud Console.
in like probably next week when these features get released, we're adding the same log viewer thing we're adding to the top call stats where it lets you like you say, show me the monitoring for the last hour. You can pull in whatever log you want for the last hour, right? And that before would have taken probably a few hours to build. And now it's like, hey, grab me this stuff from over here and plug it all into this screen and make it work like this. And it goes and does it right. And
Ernest Koe (28:00.947)
Yeah.
Kyle (28:03.247)
That's a feature that wouldn't have been hard for me to make before using AI, but now it makes it almost trivial to make, because I've already written all of the code to do all of those things. I just haven't plugged them all in in the right place.
Ernest Koe (28:13.994)
Yeah, it seems to me that, and maybe Brian you can speak to this too, that I'm certainly more more lately that judgment about what not to do is becoming really valuable because it's so easy to just throw stuff in and say, I've shipped something of value and it's not really necessarily true.
Brian Ouimette (28:41.176)
Yeah, absolutely. I found a lot of times too, just with the design phase, like I'm more of a logical thinker than an actual like designing either UI or big, huge planning of things. So I found that I can use, you know, the LLMs to help me work through that process and guide those questions.
Ernest Koe (29:10.206)
the
Brian Ouimette (29:10.862)
that then helps to just build up the thing that I'm trying to get to. And I've had a lot of fun doing it, working on personal projects too that started from nothing and just said, I want to build this, build an app and go walk me through the design phase first. And it asked me questions like,
What's your elevator pitch? What's the app for? What problem are you solving? And, and then it just works you through. And I did that on a project and the UI came out horrible. Like, I mean, I haven't seen a, like I, I can actually design a UI that's better than that, which just says a lot. so then I was like, okay, well let's do a UI design phase and we're going to talk through.
Ernest Koe (29:53.821)
You
Brian Ouimette (30:06.552)
how I want this to look and maybe some of the things I like and dislike. I'll upload some screenshots of those and you can then go ahead and figure out what this actually needs to be. And it went and did it and then I'm like, hey, you got the UI right. Now let's start working on the next chunk that we got to work on. So.
Ernest Koe (30:27.486)
This is the way. This is the way. Well, I'm really excited to see both the features we're dropping, think top call SATs and...
the ability to get that directly in the console. I think that's really huge. And I know we've got many more cool things that we're lining up here. Deciding what not to do, I think is the trick. So I think we've got to pay attention to it. But also, just as a cap here, this is a really exciting time for us at Proof. I think we're fully engaged in and...
embracing this agentic process of engineering and product development. It is a skill though. think, Brian, I think you touch on a lot of things that make it work well, which is the of joke internally, the proof way, which is to understand design first. then we had the manual way of doing that before, which was like, we've got to do that from design, then do the ship and iterate and do all that. And it just worked out that.
agents like that, know, and it's really helpful with the way we do things. So that part, I think, is an awesome thing to see. All right. Well, thank you both for joining me here, and we look forward to the next time we talk about this. We've got more coming, and we'll be sharing it as soon as we can. Cheers, everybody.
