Podcast Episode 197: Episode 170: RockTech: Next Gen Insights

Description

Tune in to this week's RockCast with Jon Edmiston, Emily Forman, and Nick Airdo as they dive into the Next Generation of Rock and Obsidian, exploring front and back-end changes, block completion rates, rollout updates, and the impact on plugins. Get your questions answered!Show Notes:Details about Rock's newest version releases here: https://www.rockrms.com/releasenoteSpecialized Rock ClassesSQL for Rock Class: https://www.rockrms.com/sqlVirtual Master Class: https://www.rockrms.com/masterclassRX24 Conference Information RX Registration: https://rx.rockrms.com/Group Discounts: https://admin.sparkdevnetwork.org/page/3068RX Hotel Information: https://www.marriott.com/event-reservations/reservation-link.mi?id=1694551025506&key=GRP&app=resvlinkRock SponsorsWe are thankful for our Rock Sponsors and their support of the Rock Community. Visit their websites through the link above to learn how they can help your ministry and confirm that those you work with are as invested in the success of Rock as you are!

Transcribed Content

This episode of Rockcast is brought to you by Rock partner Triumph Tech, a full service specialist partner. Rock partners provide crucial support for Spark Development Network and important services for the Rock community. Connect with Triumph Tech today at rockrms.com/partners. Welcome to Rockcast, the podcast dedicated to the Rock community. Join us as we delve into behind the scenes happenings, offer insights into our community, and explore leadership dynamics. I'm Emily Forman, and I have with me today, Jon Edmiston and Nick Airdo. Welcome to Rockcast. Okay. We have many exciting things swirling around over here. It seems we never get bored. Nick, start us out with our favorite first topic, which is where are we on our Rock versions? Well, to me, it felt it's been many weeks, but John just reminded me, no, Nick, it was just the beginning of last week that we released 16.3, partially because, , I am not involved at that end stage and I'm already thinking about 16.4. So 16.4 is going to be next. It's got some more bug fixes and we're going to probably start alpha testing that soon. And let's see, can we talk about V17? There's a kind of a big thing going on behind the scenes. It really doesn't affect normal Rock admins at all, but it's a version numbering issue. So unbeknownst to many people, what we call Rock V17 or Rock V16 for that matter, really starts with a one. So it's one dot 16 dot three dot and then another number, which we use during our, when we build packages. It's kind of the actual release number. But what we're doing is we're gonna become slightly more, I don't know, compliant with some other practices and some other systems that we wanna use to store Rock libraries. And we're dropping the number one. So at the very beginning of that version number, the one dot. Well, yeah, you will not see the one anymore. It'll just all of a sudden say 16.3.5 or whatever. Most people won't care about the last number, the five, but for version, starting with version 17, you will no longer see that one. We used to put in place of the number one, the word McKinley. And I think we'll probably not see that anymore either. I don't know. Maybe. We'll still probably use that. Okay. It's just a real minor ticky tacky thing that we probably don't even need to talk about, but we thought we would mention it just in case anybody ever wondered. Case anyone thought the one witnessed it. What happened with the one. Just since we're on the topic, , what was the one? Well, the one represented Rock, this major release that is compatible with itself. And if we ever had to have a new version that was not compatible with itself, you couldn't use them in, going from one version to the next wasn't gonna be a pleasant experience, then it was gonna be called the two. We were gonna bump that up to a two, but that was ten years ago. Yeah, but I think you say that the next gen platform is two. And when the next gen platform is completely dot net core compatible, which means, you can run it on Linux or, , whatever platform you want. That would be considered too. I mean, that's what I would consider in my mind. Yeah. But I think we would have thought maybe we would have already had a two in some cases, but we've been so laser focused on not breaking anything that it never And even when we go to full on next gen, we hope that it doesn't really break anything. We're so crazy about not breaking things. And that's the key. That's really it. When you and the team of architects were looking at how do we get to version two without breaking anything, we kind of came across this, how do we, we figured out how to do it together so that it wouldn't be a major breaking change. And we've already started. In fact, can I start talking about the Obsidian conversion? Well, can I jump in for just a quick minute? I just wanted to remind people that as 16.3 is out now, and that's what you need for your Google email requirements for bulk email. If you find yourself behind that level and you need to get there before June, when Google has said they will start either blocking or spamming every message from bulk senders, start making those upgrade plans now. And if your path is blocked by early access, please reach out and let us know and we will help you get set up so you can have early access to move into that latest version in time for June. That's something you should probably be planning for right about now. Yeah, just to be clear, that's only large senders. If you're not a large sender, don't have to worry about that. But if you are, , and we're not backporting it because, I mean, first of all, that's crazy. no product backports major new features backwards into old versions. we're literally, they're probably the only software vendor I know that does that. And it just takes a lot of time. There's a lot of technical debt to that. And you can't even imagine how hard it is to keep that going because it's not just a one time thing. When you move something backwards, now you basically have two versions of it that you have to keep going on those separate sub paths. So 15.6, 15 point seven, 15 point eight, they all have their own version of this other thing. So we do that occasionally if it's easy and security, but for other features, it's just forget how well we're resourced. It doesn't matter. It's crazy. No one does that. Yep. One of the other big topics we want to talk about is the next gen. We've kind of already hinted at it. This next gen, we call it, in some ways we call it Obsidian. So let's clarify that first. What's the difference between NextGen and Obsidian? I would say NextGen is this overarching move to a new, more relevant framework. Obsidian is one component of that, and that is the front end component of that. So, , there's a lot of things that need to change, but probably the biggest hardest, most time consuming for sure is the front end framework. So a little backstory. The current framework is called Webforms. That was a Microsoft created framework. It was created probably twenty years ago, maybe a little bit more. It's in use by, , tens of thousands of companies, pretty much every huge company used web forms and to date still do. It's an interesting take. Back in the early days, I would kind of describe it as it was a way to get client server programmers to be web programmers very easily. So it kind of recreated a lot of the event structure that traditional client server programming had. Things , , Visual Basic, Power Builder, Delphi. So those developers, as they're coming into the web space, , in a sense, they didn't really wanna learn the web. So Microsoft kinda made it kinda feel that. So as someone who kind of more grew up on the web, at first I thought it was an abomination. I'm , this is crazy. just do it the way. , , we've been doing it in, , Pearl, LiveWire, ColdFusion, and quit trying to baby these folks. But it was kind of brilliant in some ways, and sometime it took me a little while to kinda see some of that. And I think some of it, maybe it was accidental. I don't think Microsoft had planned for some of these kinda cool concepts that you could do. So Rock's block system, the the the thought that a page is not a page, a page is just a container of blocks, is perfect for this web forms type of thing. So they create this thing called a user control. Well, the user control really are blocks. And just the way that whole structure works is really kind of a brilliant thing. And so it's one of those things you you can love it and you can hate it at the same time, and for both for good valid reasons. However, as things go forward, Microsoft's decided that they're just not gonna support that anymore. Why? It's because they they're trying to delink themselves from a development perspective to Windows. And unfortunately, when they wrote Webforms, , the API is just a spaghetti of linking to things and hooks that only exist in Windows. And they could undo it easily. I mean, wouldn't be that hard for their engineering team. But they've just decided, nah, let's just not. It's it's not the cool thing anymore, and let's just forget about it. And that's the right, no problem. Most big companies have yet to really recognize that. Maybe a few people on their teams are , hey, this isn't gonna be supported. But big companies typically don't move until they absolutely have to, and there's a critical reason to do it. So in a sense, we're trying to get ahead of that. Webforms, in my mind, will probably still be supported by Microsoft for another ten years. That's not where you want to be. You're not going be able to hire new developers who are fascinated by But that said, I mean, if you're a COBOL developer today, you're making a ton of money right now. So it'll be around supported and safe, but we don't want to wait for that. So we've been working over the last four years just to find a plan forward and then have been executing on that plan. And I said, the biggest part is Obsidian. Obsidian is the front end framework. It's many frameworks right now, it's JavaScript based. And I think that's can be you can think of it too in terms of web forms. There's a lot of things to love about that and a lot of things to hate about that, and they're both valid. Obsidian is our term that we use for the technologies that we're kind of wrappering to build that. Underneath it, a lot of it is a JavaScript framework called Vue. We didn't say Vue because we don't really wanna talk about Vue. We wanna talk about Obsidian because it's our flavor of Vue. And that's not to say we're going inside of Vue's code and changing it. that would be unwise, but we don't want people to latch onto a specific version of Vue or a specific type of you, because that's gonna be a fragmented space. you're always gonna have opinions that you should do this part of you or that part of you. So our Obsidian is kind of a wrapper and saying, this is view, but it's configured in this way, done this way. And we've had our own kind of secret sauces to make things as easy as possible. But any change, it's difficult. What are the benefits? I think some people are asked, , what do you see as a benefit? And there's a lot. I think, first of all, it's modern, it's new, it's much easier to find developers who want to work on this technology. pretty much every person coming out of college right now wants to work on these types of frameworks, whether it's Vue or React. It's great to see a lot of the people coming out of college don't even really care. It's , well, they taught me React, but Vue's really cool too. I just wanna work on that kind of stuff. I think there's a performance benefit too. The screens feel much more quicker because they're more, what we would call reactive. And that's why, that's what we're talking about is making things reactive. So in web forms, your page is kind of there and every time it really needs to do something, it's gotta go back to the server to kind of say, Hey, I'd say a lot of the control of the UI is happening on the server. A lot of that control of the UI can now happen on the client. And so that's really cool, I think. And that feels modern. That's what a lot of our applications do. So it gives us that capability. So for instance, someone asked the other day, hey. On the group placement block, I want to have little counts that are automatically as I drag people into certain groups, I want those counts to update. You can do that in Webforms, but that is not pretty and it's not performing and it's not really what it was meant to do. That is right up the alley of these modern JavaScript frameworks. They're meant to be reactive. They're meant to automatically count and it's all happening on the client in JavaScript. And for the most part, pretty easy to do that type of thing. So our UIs will become much more reactive. I think another good example of that is the grid filtering. Our new grid is really, really cool. the filtering that can happen on the client is so awesome. Now one of the challenges that we've talked about is to get that to happen, you have to bring down all the data so that the client can now do the filtering before that was happening on the server. And so in some cases, it could be seen as a little faster because the server's only having to send down that of which you filtered. And every time you change your filter, it has to go do that again. So that's kind of a pain. But in doing that, we put a ton of work into the back end in the C sharp to make the loading of that data insanely fast. And so it sometimes can be a thousand times faster. So it's not just, this next generation is not just all about the front end. There's a lot of backend going on. Another good example is right now we're in the middle of rewriting check-in. A lot of the speed problems there are actually backend speed problems. And we're addressing all that. It's already crazy fast compared to what it was and we're not done yet. Now those are some of the benefits. What are some of the challenges? I think the first that I would identify is this transition. as we transition the code over, it's difficult because it's not one of those things that you just kind of start on a path and you're on the perfect path the whole way. These are very deep technical hard things. So sometimes we have to shift and change and we can't go down a perfect path. we'll have to make some adjustments and those adjustments will have to be seen by those people using Rock. Now, of those transitions will get polished out. Some of those transitions are just change and change can be difficult for certain personalities. And I would just say, hey, if recognize the things that your personality is really great at and recognize the things your personality maybe isn't so great at. So if change doesn't come natural to you, just go realize, Oh, I'm about to have to go through some change here. And that's not a defect in us, right? But God has uniquely wired each of us. Some people are change and addicts. They want everything changed every day. There's good things to that and there's bad things to that. And some people are really resistant to change and there's good things to that and bad things to that. But I would just say if you're one of those people who doesn't love change, just realize, well, things have to change. Otherwise we'll just keep on web forms and let it ride this thing into the ground. But I don't think anybody really wants that. But it also brings up another thing, which is bugs. Now you could say, well, you have the block today, why it should be pretty easy just to rewrite it. Not really. I mean, there's enough changes here and you can't just copy and paste. You can copy and paste a little bit of the code, but not a lot. Now I would say that you're right in the fact that the current block is probably the most perfect set of requirements you could ever be given because it works today and it's had years of refactoring, but that's not to say that it's easy to get it to be a perfect match. So just give us a little grace on that. I do think there's some price, some low hanging fruit that the first few blocks we could have done much better. And so we're learning from that and we appreciate it when people share, hey, that piece was missed. Recently someone shared some of that and some of those changes are broken pieces. We didn't realize were actually even broken. So them identifying it was a huge favor to us. We've since edited some of our tooling to prevent that in the future. But as we release these blocks, we sometimes kind of say shift happens. And as you shift this stuff, things can break. That was a careful pronunciation. I had to be very careful. Excellent job. Yeah. So just realize that happens. And as we release these blocks in the first place, trust me, took many versions to get things all lined up. Then as we shift this, we'll have to take, we've upset the apple cart, so we'll have to get back into some parody there. And again, some of the changes that are seen as bugs aren't really bugs because we weren't planning for it to be used that way, but oh, now you were using it that way? Okay. That's fine. Let's get that fixed. Also the plugin ecosystem will definitely be changing. For today, keep doing what you're doing. But there'll be a time when you will want to get all these plugins converted over to the new Obsidian framework. Because eventually, and this is a couple years from now, everything will be on a new platform that's running non Windows. So everything that was cannot be there. We have to rewrite everything. But if you're a plugin writer, hold on, hold your horses, we're not quite ready We're getting close. We're doing some plugins ourselves to see where the trip hazards are, and we are finding those, and we are correcting those, and we are polishing those, and creating good documentation for that. So that is happening. Progress is being made. So those are are the challenge. I guess one one other one I just wanna throw out there too, because we just wanna call the file. We say that a lot around here. We wanna call the file. So as a new page loads and it has an Obsidian block on it, , one of the interesting things with Obsidian is, and these JavaScript frameworks in general, is a lot of things happen on the server, bring it to the client, the client paints the screen, but then the client has to go back and get some more information. And so that can cause, , a UX to kind of change in size. And that can feel kind of, at first when it's only one page and it's only one block on a page, most people don't even notice it. But as you start to see more and more of these Obsidian blocks, it can start to feel a little bit the screen's kind of shifting a lot and changing a lot. And so we know about that, we're working on that. We're still trying to kind of polish that out. And we have some ideas, which a couple paths to go down, so we're going down that. So just recognize that we understand that, we see that, but those are part some of the growth pains. So I opened it up quickly to get some questions from some of the Rock stars about what they had in terms of obsidian. And so maybe one of the first questions, Nick, maybe you can help with this is, how many blocks do we have converted now? Okay, that's a tricky question, let me unpack the answer. So although we've completed behind the scenes 130, almost none of those have been rolled out yet. We've only rolled out, I think we rolled out two in version fifteen, one, two, , V15, zero, one or two. And then we've rolled out about 10 in the V16 series. So that's only 10% of that 130 that we've completed. Now there's 600 and plus blocks to go a total of 600 blocks. So we're only 20% and we've done a lot of the easiest ones so that we could. Well, I would say we've done some of the easiest and some of the hardest. Yeah, we've done a handful of hard ones just so we can make sure that- Group scheduling. Yeah, group scheduling, forum builder, event registration. Probably the hardest. But a lot of those 30 that we did, those are , okay, let's knock this bunch out and see how fast we can do these small ones. So there's still a lot of work to go. Yeah. But I would say that percentage hides the fact that when it's , , the famous president Lincoln quote, if you're gonna chop down a tree, , he would spend and he had an hour to do it, he'd spend fifteen minutes sharpening his axe. And that's what we've been doing. So all the field types had to be rewritten. , that's pretty much done. There's a few couple that are just straggling that we just had to put some finishing touches on, but a majority of those are done. We also have a really cool internal tool for auto gensing these blocks for us. So, so much of it is written for us. And unfortunately, know some plugin people are , Oh, can I get access to that tool? It doesn't work for plugins. Even our own plugins, we can't use it. It's meant for just core entities. So there's a lot of stuff that makes it easy. In fact, the grid blocks are insanely easy to convert over. There's really not much to it. The grid is so powerful that you just basically have to give it a set of data and say, okay, there you go. Run with it. Yeah. And and then the the hard part comes in with all the little bells and whistles we might add into that list block. Special filtering, options, weird features and buttons at the bottom, those are the harder parts of those blocks. Yeah. But we're gonna spin I mean, we've already spun through a lot of those grids. So Mhmm. And so a 30 blocks completed. We're basically now internally doing some more formal testing of those. And then we will select a bunch and roll them out with patches B16.5 or six. For sure a whole bunch will come in version 17. Anything that we think is slightly more risky. Yeah. I think there's some special rockstars and beta tester, alpha testers that we'll be going to very shortly and telling them how they can actually test more of these blocks right now. They might actually be on their system, but they can't see them. And that they can get ahead. Because there has been some rockstars who are amazing proof that they are rockstars who are saying, Hey, I'd love to start testing some of these ahead of time for you. That's awesome. Wow, thank you. Yeah, , so we don't even have to wait for an official alpha beta. Can tell you, , what little switch to flip, and you'll be able to play with some more of them. And we'll probably need to create a separate page that lists with each release of Rock which blocks we've converted. Because if we try to put that in the release notes, it's gonna just muddy it up and nobody's gonna care except, , our Rock stars. Yeah. Now that brings up another point, how do you guys roll out Obsidian blocks? And so there's a few different patterns that we can do. The pattern that we the best is what we call CHOP, which means it just says, take the old block out of Rock, put the new block every place it was. But keep all the settings. Right. When possible, 99% of time, can keep the settings. You shouldn't notice anything. We that because it's as clean. It's a rip and fix. You don't have to ever do that. The other one is a swap where we'll put the new block in on the page. We'll change all the pages out to use it, but we'll keep the old one there just in case something didn't go quite right. You could always flip it back in if you had to. And so we do that with blocks that we're kind of we feel comfortable about it, but , well, just in case it's a very important block and if something was to go wrong, a giving block might be an example of something that. We would keep the old one there for a while. We prefer you not swap it back in, but we would understand in a certain use case you might have to. And then sometimes we just put the block, the Obsidian block on the system and we just say, well, if you wanna swap it in yourself, you can do that. And then you can kind of pre prototype it. And we would do that for stuff that we're , we think it's done, but we're not quite sure yet. Or maybe it's a radically different shift in how the block works. the group scheduler block was a good example. It's , dude, that, we think it's the right thing. We think it's great. We think this is the way, but, , we also worked with, , a couple of clients who wanted that and we wanted to get it to them, but we also didn't wanna necessarily pull the rug out real quick on everybody else. So we moved very cautiously with that. So a lot of this stuff is , trust us is highly considered. It's not to say it's perfect, but we've put a lot of time and effort into those thoughts. I'd also say that there are some new features built into some of the patterns that are gonna be really pretty cool. For instance, every detail block that we ship has the ability to go right to as a block loads, to load it in edit mode. So most blocks have a view mode and an edit mode. We've built into all these Obsidian detail blocks the ability to go straight to edit mode. So you might go, well, that's interesting, but , why is that such a good idea? Well, as Lava, you can create the view mode a lot of times yourself. And maybe you wanna really customize what your view mode looks . Well, you can create a page that has your own group detail, screen painted in Lava. That's a really piece of cake. Anybody who knows Lava can pretty much do that. But what you can't do is you can't edit it. So what you can do though is you can put your own little edit button that takes you to a page to the current group detail block, and you just pass it in the query string, Hey, I wanna be in edit mode. And it's in edit mode. And you also pass it in a return path. So when you hit save, the block doesn't go, Well, I'm gonna show you the view mode. It's , No, you came here from someplace else. I'm sending you back. So you'll be able to kind of wire up some really interesting extensible kind of pages that you can provide some customized kind of views to, but you don't have to worry about the edit mode. So we've really thought through how to make Rock even more extensible. And that's another cool little feature that we've added that we really haven't talked about because it's all too early, we're starting to talk about it now. There are some questions too about, I think people are very familiar with the way the blocks work today. How do I figure out, how do I read the code? So to say, , if I can read the code, I can figure out a lot of things about how these blocks work, but now with these new blocks, I'm a little confused. Yeah. Welcome to the club. Welcome to our lives. As we change things, we realize we have to change too. And so we feel your pain, we get it. Here's what I'd say at a high level, and we don't wanna get into a lot of code in this. Just realize there is still a code behind file to the block, a C file that has a lot of business logic, a lot of code that you're used to today in the code line, that still exists. Now there are these other files that are the front end. And in the old days, there was usually just one of those. Now you have a few more. In most detail blocks, kind of have typically at least three. You have a master file, then you have a view, for viewing the data, and then you have an edit to edit the data. So now they it can get more much more complex than that too. But for the most part, the high level, that's what it is. Here's what I would say though. , for the most part, the stuff that you're really looking for, it's gonna still be in that C sharp. The front end typically doesn't have a lot of business logic. It's just presenting the data and doing reactivity type stuff. Now again, there's there's exceptions to that rule, but just trying to keep it super, super basic. Typically, find I'm still looking most of the time for the stuff that I'm looking for is still in the in the c sharp behind file. So that's not always the case, but, , at a high level, that's that's kind of what it is. This is a whole new platform. So you more code on the front end that's running on the client than you used to. So if there's a problem, if there's an exception or a code issue, you're still in my, , in our current knowledge base, a lot of that's still gonna be on the back end side. Any kind of problem that you have in the front end side more often than not is probably gonna be a UI kind of itch issue glitch. It's not gonna be something that you almost need to know about. your client's gonna be a little frustrated, Ugh, GRRRR, this little thing is broken, but it's not causing a data quality issue. It's not causing , those are more on the backend side and those will still be in the exception log. UI glitches will not be in the exception log. That's not where they belong. They show up inside the client's JavaScript console. So, but those are typically not business, what I would consider business exceptions. Those are UI stumbles and glitches. And there's not too much we could do about that. I'm not sure we'd even wanna bring them back to the back end. So that's a little bit deeper about Obsidian. Hopefully that helps. I would say if you're a developer or a plugin developer, yeah, prepare to eat your cheese moove. And we all are there with you. But it's what you do. Technology moves, you got to move with it. It doesn't mean you move with every new technology, but these generational moves and shifts have to happen. And it's just you got to kind of dust off, get familiar with it. And it reminds me a lot of the early days of Rock because we used to do things back then and you're , why is it gotta be this hard? And so we create a new way of making it easier. So I think the best developers is in a sense a little bit lazy in a way, because they just , this seems a lot of work. Let's go do a lot more work to make that easier. But then once we do it once, , it's easier forever. So I'm very much somebody who thinks about the future and I'm always trying to invest now so I can make the future better. But we don't know what those are until we get in there and do it. And I think we're in that process now where we've done a lot of that, but we still have a little bit more to do. In a sense, we'll always have stuff to do because even now we still polish up some of the web form stuff to make it easier for ourselves. So hopefully that's helpful and gives you a little bit of insight into Obsidian. There is a documentation that, , we've obviously been working on. It's not quite ready for public viewing, , so I would just be careful, even if you do find it or see it, don't trust We keep it up to date, but it changes all the time. So don't go writing stuff. If you write something today in Obsidian, you try to get ahead of the curve, just that's okay. But just expect it not to work on the next release because that's the state we're in right now. And we have to do that to ourselves. If you wanna get ahead, you can join us in our frustrations. Anything else you would add Nick on? The only thing that occurs to me is if you are somehow in the position, maybe you're even a developer listening to this at your church, the worst thing you can do is to internally start thinking, I don't this stuff. That's the worst thing you could do. What you need to do is say, oh, this is so interesting. I'm gonna learn it. I'm gonna learn it because it is hard. And if you let that little poison get in your well, it will ruin you. So I would just say, and that's kind of advice for life. That's true of anything with change, right? Exactly. Just do not let yourself start hating it. You just need to say it's different. I will learn it. And that's life. And the growth mindset approaches, I can't do it yet. Yep. One of the brilliant things God gave our human bodies is the ability. Well, it's not even the ability. It's that our bodies cannot remember pain. You can remember a time when you were in pain, but you cannot remember the feeling, the actual, you can't recall the feeling of So I would just say you went through that pain once, the first time you looked at what, , web form block or some new Rock thing, you were , what the heck is this? And you felt lost, you felt kind of dumb. Just realize you did it before. It's unnatural to think that when everything changes, you're just gonna get it. I would say it doesn't feel as bad because there's a lot of ties. we tried to do everything in a Rock ish way, but yeah, you're just forgetting the pain that you already did once. Another quick topic we wanted to, , discuss also starts with the letter o, observability. Observability is probably one of the coolest features, , in my mind. The one that most , one of the most exciting features for me. Now it doesn't have a front end component. It doesn't have a business component, but it basically gives us a clear paint plane that pane of glass to look into the performance of Rock. Until now, we've not had a good way of measuring Rock. There's, Oh, I'm on a page, this page took this long, but that's not helpful from a developer perspective. Because A, when we're developing it ourselves, the data looks much different and it's shaped differently, which we have a different project to kind of help us with that. But we wanna see it in aggregate, a huge amounts of it. And we now have the ability to see into Rock instances and see what's a bit slow. every project though, it's not a straight path. we have to we're learning as we go and we're making adjustments. We're making a lot of adjustments to the observability and we'll continue to do that. But we're really excited about the data that we're seeing and the telemetry that we now have. And so now it's time to, now that we've built the tool, it's time to switch gears and start to use the tool and to start to build in processes into our team to do that. I just wanted to, hey, mention that. There's some of you who might be getting an advanced start with the OpenTelemetry and the observability feature in Rock. And we would say, thank you. That's awesome. keep it up. Reminder, you can get a free account at New Relic and you can wire it up. It really takes just a few minutes to wire it up. It's really easy. And now you'll have the data. And so now we're working to create some scripts to harvest that data. And so we're working with some people who've already been on the cutting edge of rolling out observability to get that data. But those people are gonna start to see some areas of inefficiency. And so, I just want to let everybody know, we see it too. And we're actively not waiting for an issue to come up and then use the data. We're proactively using the data right now to find some of the slowest areas in the hottest zones of Rock that we can then go do some efficiency changes on. So that's something that we're working on that, , typically we wouldn't talk about because it's not very fun, no one really cares. But they care about the result and that's what we wanted to just call that out in case you're ahead and you're looking at some of that stuff. So are we if you if you do have OpenTelemetry turned on in New Relic, , let us know. We might wanna jump on your system and run some of the queries that we have to find some of that data. And then the last little feature thing I just wanted to mention is the upcoming change coming in version 17. In version I believe it was 16. These versions get hard to remember. We added a way that you can so as interaction data is being written from page views, there's a job that will go start appending location based on the IP address. And so that that is happening after the fact, and it's using a service, a paid service that you have to buy, and you just paste in the key and then it'll start appending in the the locations for all those IP addresses. So that's really cool because you can now see kind of where your traffic's coming from. However, doing a lot more research into, some of these technologies, some of it was spurred on by that bot issue from a few weeks ago. We found another way that we could do this that would be free. So in '17, we're basically ripping out that logic that we put in and that need for that service, all that we're just literally just ripping it out. And we found a different way of doing it that we can do it in real time. So as those requests are coming in, before that gets to Rock, we can actually append on the location and send that through. And we'll write it directly as we're writing the interaction. We'll write the location right onto the interaction, making it a lot less resource intensive. But I think the really cool thing is you'll actually have the location on page load. So your lava can now do stuff that says, Oh, this traffic is from this country. So maybe temporarily I need to block that. And I think that's gonna be a huge thing. It's super performant too, which is really nice. It's not gonna add that much to your page loads. Hopefully it's way less than milliseconds, a thousandth of a millisecond or maybe a couple thousandths of a millisecond. And so we'll eventually continue to build off of that to perhaps build that into the rate limiter. I'm not saying when that's gonna be done, I'm not saying that's gonna be done 17. But then we can basically do some rate limiting and say, hey, , here's the default rate limit, but for these specific countries, we might rate limit it differently. Because we take a country, , I'm just randomly , Mongolia, you're probably not getting a lot of traffic from them. So if you started getting a lot of traffic from them, that would probably be, , something you wanted to be curious. So I think it'll allow us to kind of treat traffic differently based on the patterns instead of treating every IP address as the same. Initially, you'll get a lot, get that data, everybody will have that data for free. You'll have it at page, right at the runtime on page. And eventually it'll give us a bit more capabilities of what we can do. So I wanted to mention that because we are ripping out that. If you're considering getting that service, I'd probably say hold, . That said, you can turn off the service. It's a monthly service. So, , if you really want the data and you need it for a project, , don't go to your leadership and say, we can't do it. Just know that you probably wanna get rid of it. And if you're gonna pre buy, I think one of the options is to pre buy a whole bunch of things don't pre buy too much. So just wanted to mention that, put that out there. That is a lot of incredible information. I know those are a couple of topics that we've had a lot of questions on and people anxious to hear more about. So I think this is gonna be something they're excited to hear. Thanks for sharing, John. Yeah. A few community updates. We have limited opportunities every year for just a couple of Sequel to Rock classes, and the next one is coming up next month. So April, we do have a few seats still available if you are ready for your next step, and that includes SQL for Rock so that you can access new ways to do custom reporting and understand the tables structure behind Rock. If this is a class for you, make sure to sign up soon while we still have a few seats available. Additionally, we have typically about one virtual masterclass option a year. And so I wanna mention that early, that's coming up in May through the seventeenth. So if virtual masterclass makes the most sense for you as far as budget or time goes, make sure that you sign up for that. It's always a well attended and an in demand class. So there are still seats available. Make sure that that's on your agenda to sign up for soon and not delay if you need a seat at that class. And then let's talk about RX twenty four. So we're getting really excited for the event, and it is coming up sooner and sooner. It's it's exciting that the hotel is actually at about 78% booked already. So we're way ahead of last year's schedule in terms of how early this hotel is going to sell out. So if the experience you're looking for is stay in the same place that the conference is happening, don't wait until when you purchase those hotel rooms last year because that will not be the experience that you'll have. You'll be walking across the parking lot. So we do wanna mention that. Go ahead and get your Rock Conference tickets and your hotel tickets and get that spot locked in. We know there are a lot of regular attenders that haven't had a chance yet to do that, so make sure you don't forget that. Also, we're gonna be helping you help us. We're adding a couple new experiences to the conference this year for people who may not have attended the event before. And our goal here is to really help facilitate some of the networking connections and just the learning and best practices sharing that some of your teams don't have access to in their roles. And while everything about Rock may not be 100% relevant to them, there are many things that are. So we're providing unique track experiences for our digital strategies and communications is one track. We're also going to provide a unique track for discipleship and engagement and a track for those who are new to Rock, as well as a track for finance and generosity. So that's a lot that we're talking about. And this is an opportunity for people to have some great Rock insights because Rock is definitely valuable in their roles, but also some other best practices that are unrelated to Rock itself, but will help with learning and growth. So we encourage you to invite the members of your team who might fit into some of those tracks, and to invite the community of churches in your area who aren't on Rock to come attend the New to Rock track and learn more about what makes Rock great. So we will be sending out some packages of postcards that make the invite really easy for you. So expect to see that coming through. You'll be able to just hand things out to your finance team, to some pastors that you think might be interested in the discipleship track and to your communications team. And they will understand a little bit more about how Rock can empower their goals and their departments, and also how they can connect with others in churches in the same role. We're really excited about it. Look for those postcards and help us get the word out because we think these experiences will be really powerful. Alright. That's quite a bit of information for this podcast today. I think we're gonna have to wrap it up. We might be on information overload. We'll save the rest for next time. Thank you so much for joining us, and we appreciate the support of the Rock community. Do a church that loves the idea of using Rock but hasn't taken that leap yet? With managed hosting, churches of any size can get access to Rock's amazing technology, hassle free. With just one click, Rock's managed hosting removes the roadblocks that might stop a church from switching to Rock by making the process simple. Churches get the ease of a SaaS church management system without losing any of Rock's powerful features. Are you ready to take the next step or share with another local church? Visit rockrms.com/hosting today.