Podcast Episode 144: Episode 117: Special Edition: Best Practices

Description

Learn why you shouldn't edit a core block, use workflows as data storage, or leave workflows you don't need running forever. Plus, Jon shares how to write a love letter to your future self by documenting everything.

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 this special edition of Rockcast, the podcast where we take you behind the scenes with Rock. Sometimes in our special editions, we have the opportunity to interview someone in the community who has some great insights to share. Sometimes we have a special topic, and today is one of those special topic days. It's something that we've been talking about internally for quite a while and just feel there's a lot of value and benefit in sharing with the community, especially on the heels of the conference where some of these conversations, I think, naturally occur and come up. So today, we're going to be talking about best practices inside the context of Rock. And it's a really exciting topic to help narrow down. Of course, there are a million and one ways to do anything in Rock. But are is there a best way? And in some cases, there are just options and they're equally valid. And in other cases, there are things that it would be helpful to know. These are things you should do or maybe some things you might not want to do. And here are the reasons why and some considerations. So we're gonna chat about some of those today. And let's start out with the very top of the list, some things you might want to be super careful about inside Rock. Okay. So the first one, don't edit core blocks. So Nick, why can't I edit core blocks? That's a really good one because when we create updates on patches and releases of Rock, we will often replace large parts of the blocks that are out there. So those are gonna get wiped out the next time you hit update. So never ever edit a core block. That's just kind of a cardinal sin of Rock. Don't edit a core block. It will get lost. So it's kinda throwing a boomerang and it's gonna come back and hit you. It will definitely bite you and it depends, , if you did it a long time ago and it just you got lucky because it hasn't gotten updated yet, that day is coming. Good point. Yep. It's a little bit of a landmine that it will eventually go off. So what about I wanna make some edits to a block, so I so I kinda fork the block. I can make a copy of a block, make some changes to it, and I don't put it in the same place, it's gonna get overwritten. Okay. what, why might not I not want to do that? Guilty as charged. I have done that in former role. For my own internal use, we just needed a little change. And what we did was we would give it a different name. And again, never release that to anybody else. That's kind of the main thing. the source is open source for you to True. But there's still a trip hazard there, right? Absolutely. I mean, a model changes, something else in the core logic changes, and you're out on very end of a very thin branch. So that's one of those things where if you do that, you're gonna regret it. And every time we went to update, we said, oh, look at how much that block changed. We had to keep our block in sync with it, and it's just not worth it. So we recommend don't do that. Yeah. And I think we've worked with a lot of churches who've come back to us and said, hey, our former employee did all this, and now we have a complete mess, and they're not here anymore. What do we do? And they didn't write down what they changed or where they put it. Yeah. And even if they did, they're still left with a mess. Yeah. they don't They can't upgrade anymore. Consult a partner if you're in that situation. Yeah. So I would say don't do that. , if there's something you don't , put it into the ideas area or reach out to Spark and say, Hey, I'd to fund a feature here. Can you add a block setting that does X? It's a little bit more work in the short term, but it's gonna save you a ton of work and headaches and nightmares. Maybe not for you because you may not You might be the person who actually didn't Who leaves and go someplace else, but for your organization. Your organization will be crying hard over a bunch of small little changes. So just reach out. Yeah. Get funded or also to, if it's not worth the funding to go do, maybe it's not worth doing. Right. First and foremost, we should you should always have in your mind the continuity plan. what happens if you go away? You should never do anything that is gonna jeopardize the continuity plan for your church. Right. Yeah. I mean, technical environments are very highly configured and they need to be very structured. And sometimes we're not always structured thinking, and everybody's on a continuum on how structured their thinking is. I'd mine to be a little bit more structured than it is, but you need to always be worrying about, even if that's not your natural tendency, you have to be thinking about it for your systems of your church, because they want it that way, even if they don't know that. Okay. So let's move on to the next one. So the first two were kind of about blocks. Don't change the core blocks and don't fork the blocks and make some small changes and have your own version. Just reach out, fund it, Or if you can't fund it, at least put the idea in the idea board. Sometimes we take some of those ideas. In fact, in the last two weeks, I've seen ideas come through that we just went ahead and did within days of the submission. And it's , that's a good idea. I totally see that. The third one, don't use HTML blocks or pre post functions on other blocks to put JavaScript or CSS to modify core functionality or hide things or do things. We have spent hours when we did this or somebody on our team at the church did this and we didn't know. And we spent hours , why is this column gone? It's just vanished. It shouldn't be happening. I'm pretty sure it's the code is still there. And it turned out that somebody snuck a JavaScript function or I can't remember JavaScript or CSS to hide a particular column. And we just wasted time of several of us. So it's a time waste. Yeah. I've been on that too, where I've been helping someone and say, hey, there's a bug, this button's not showing. And of course my first thought is, well, let's look in the code, let's see where this bug is. And after many much time, it was , oh, it's a CSS thing. Someone just hid it. Which is the last thing you'd think of Right. When you're a developer. Well, and I think we all, as human beings, give ourselves too much credit for what we'll remember or what we'll understand in the future. I'm shocked at how much I don't remember, and they don't understand of the work that I did. So I love adding little love notes to myself about how this works, why it's doing this way, and and most of all, doing things I'm gonna regret. It's basically saying, hey, the lights are on in my house right now, and I know I'm gonna have to cross this in a second, and turn the light switch on and cross this room. Why would I set all these trip hazards for myself? I know I'm about to turn off the lights and I know I have to cross this big room. Why would I do that to myself? Don't I respect and love myself more than that? And that's what this is because we don't understand that in two weeks, it's turning the light off, and we're going to trip on this. Or think more in terms of your spouse. Your spouse is going to to cross the room, and they don't know what's been done to the room, you're just going to turn the lights off. That's your coworker in six months coming back and doing this. So just don't do it. Again, go back to number two. What is it that needs to be changed? Put the idea in, fund it, or don't do it. It's in your best interest. Yep. Okay. Don't hook into an element on a page unless it has a dot JS prefix or it will break on an update. So this is giving even a little bit more technical. So sometimes we do place hooks in certain places that allow you to do some JavaScript. And those hooks are usually around a CSS class. Right. And so we will decorate that particular element with, I think it's JS dash. And so if you see a JS dash as a CSS element, JS dash, whatever the element is, we will typically use that as well in our JavaScript in core code to do and hide or move that thing. So those are the kind of sanctioned interface points where you can do things with. But just be aware, the previous rules still apply. Don't mess with the core code. Yeah. I would say those an internally sanctioned hook points depending on what you're doing. Maybe it's okay, but that's a big maybe. And it's going to depend on the specifics. Yeah, probably best to consult the developed channel and ask around. Yeah. But the best version of Rock you're gonna have is the is the out of the box kinda clean version. , you don't wanna be putting trip hazards in. Yeah. Okay. So let's do decide about something that you should do. Everything should be documented. People don't love that, but. Yeah, that's a discipline you have to build over time. And it'll come in several forms, whether you're working with a partner, they should be providing you with documentation on what they did to your Rock system or what the code is and how it works. Just the basics. We also at Central Christian Church, we created run books, we called them. So for any part of the system that was fairly custom, there's a page in Rock with all the run books and you can click on one of those and then read all about the details of that. But you say custom, I mean, run book could be anything how should you set up camp check-in? I mean, may not even be custom, but it's , this how we do it. Yep, for sure. So that's a perfect example of another runbook. I think we had one called creating events. And another good example of documentation is use the description field, right? A data view a report or a workflow, write what that thing is for. What's its purpose? Where is it used and referenced? Because finding where something is referenced from can be tricky later on, but when you're creating it where it's referenced. So add that in the description, put a link in there. Yeah. Within our team, we'd say it, the description field is a required field. Even though there's no red dot, even though there's no validation for us, description is a required field. And we haven't always done that, so that's something we're working on, but that is a new thing. So now if we go into a workflow and it's been made since that statement was made and there's no description, that's a little bit of a ding. No, that was a required field. I'm not the best with that too. You end up becoming better as you gotten burned by it. So I've gotten to the point where when I create one of those workflows, I just document the whole thing right there in the in the description because I've gotten burned. I burned myself. Well, with experience too. I know sometimes I'm working on a workflow, I'm , who the heck made this thing? Who thought this? And I know, , I'm , in my head, I'm , it was probably you. You're beating you. I always go check who did it. I'm , yep, that was me. That was it. Just that it recently happened too. I was , who who made this workflow? It was for RX. And I knew who did it because it was just happened. , why didn't I put a description in all this stuff? And so I went back and added the descriptions because I felt that's needed for the next person, but I was running and gunning, gonna need those workflows. Needed them. I was working on it in late at night, I had to have them for the morning. So in my mind, was , well, I was just having to work quickly and no excuse. Another example is logging changes. So I know we added the notes block to the workflow type details. So when you make a change to a particular workflow type, definitely go in there and say what you did and why and who did it. That's really helped a lot at a couple churches that I know of where they've realized somebody was making a change that they didn't know, but it was because they logged it. Yeah. And I highly recommend that every church creates a content channel. That's a change management log. Oh. And it might , you said, the workflow, there's a thing there. Okay. Go use that. But there's so many places in Rock that there's not a thing to log, and it probably doesn't make sense to add. But in a lot of systems that we work with, we have a change log, we keep a change log for that. In the corporate space, it's called configuration management. And it's a very healthy thing. It's often the thing that makes you want to quit your job. Because it goes too far. You can't change anything on these big servers without going through a change management that takes weeks and you have to go in front of a board of people. Oh, boy. So we don't want to go that far, but having a change log , hey, you changed the network interface or you changed this or that. You changed the site domain name on this particular date from this to that. Yeah, trust me too, you a bug or a problem, the two things you're gonna look for, we have video coming on this is what changed and what's different. If you have a change log, you can go right to the change log and say, oh, so and so changed this two days ago. I wonder if that might have been the change that did it. Yep. And it's usually more , I don't know, this problem started and it looks it started three months ago. What did we change back then? Well, go look. So from a psychology perspective, what I would say is you're probably having one of two reactions to this idea of the changelog. You're either probably very excited and can't wait to go do it. I would say tamp it down a bit. , you're you're probably gonna go a little too far than you want. Right. More commonly though, you're probably , no, come on. , it's not that big of a deal. I would say, woah, woah. , you really need to do this. Just start simple and light. , it should be lightweight and fairly friction free. Yeah. And I would turn it into a bit of a game. if you do well, keep metrics on it. Whoever does the most change logs per month, with with not without weird ones. I typed into the notepad window, then they get a prize. If you didn't do one that you should have, maybe there's a swear jar, you have a didn't do the config jar and you have to put a dollar in or something. So turn it into a game that it can be fun and very helpful. But that to me is probably the biggest thing you could do to make your life easier and respect the people who work with you. And I think too, we all want to think of ourselves as IT professionals and take pride in the fact that that's what IT professionals do. They document their changes. Okay, here's another one. Don't use workflows as data storage or tables. So in that one, you're saying somebody's , set up a workflow and and the records, the instances of the workflows coming in are the permanent record of whatever that thing was doing. It's a persistence mechanism, yeah. I mean, it's too abstract. How do you get the data out of it? There's risk that someday somebody is going to turn the setting on to say delete old completed workflows. I would say in those cases, you should be doing is writing the result of the workflow should write data to the appropriate place, whatever it is, whether it's an attribute on a person or a change to an entity, the workflows should be thought of as kind of transient. They're going to go away. Right. And there's actually a video I did on this topics, because we've seen this a lot, is that workflows are inside the body. The workflows would be the muscle and things connection statuses or or person attributes would be the bones, the structure. And so if you have a body with no bones and all muscle, you might be Arnold Schwarzenegger, but you're still a blob on the ground and you can't move because you don't have anything to have resistance and to have structure to pull on. And so you really need to have both. And what we've seen is people who've created these huge workflows, 90 some activities, and they become many applications and they're impossible to support. In fact, the ones that I've seen that are epic have never actually seen production use because even in the development process, they've become so unmanageable that they can't even get it done. And so instead of that, use things connections and use multiple workflows as little muscles to pull things in different directions. So you might have 10 workflows instead of one big one. Yeah. So if you ever found yourself saying in a data view another workflow saying, Oh, I need to go check a workflow to see if there's an instance of it, that's a red flag. Yeah, workflow should kind of come alive, do their thing and hopefully go In some cases they might pause and wait for the human to come back within a given period of time. That's acceptable. And we'll talk about those in a few items down Okay, so let's keep going. Right That was the next one. Don't leave workflows running forever if not needed. Yeah, so this is sort of the maintenance check topic. You should have kind of your finger on the pulse of workflows. You should have a report that shows you for each workflow type, how many are still non completed, how many are still running. If you have never looked at that, you will be surprised at how many workflows you may have written that are still running. And you are, it's just one of those things that you want to stay on top of. You want to figure out why, why did it not complete? You shouldn't have to go back three years into your list and see that there's workflows still running. They take up horsepower. Every time Rock's workflow processor runs, it has to look at all those and see if it needs to do something. Yeah, and that's what just happened to me after the conferences, the workflows I created real quickly, they didn't complete and there's thousands of them still running. And luckily I found it. I went back and checked, I did what you're saying is that the checkup, but I've run some checkup scripts that I have, and I've made a little bar chart of active workflows that were started back four years ago. And there's thousands of them on some of these systems and it's , woah, that's such big tax on Rock. And we've all done that. So it's again, no judgment, but take action and get your finger on the pulse of that. We'll talk about maintenance checkups a little bit more later. Thing we just did on this though, it's a feature that's gonna be coming up. I believe it's not coming in '13, but there's a feature we're adding to workflows that as you create the type, it's gonna say what's the longest that a workflow should be out there running? And I kinda call it the Reaper feature. It's gonna come kill that workflow if it gets to be too long. Yeah, it's sort of the safety net. if if if it's a year old, it's total garbage, so just delete it even if it's still running. Yeah. And so a good example is if I was doing these these workflows for the conference, I would go, oh, yeah. Well, yeah, make sure that these things are all dead within a few days of the conference. Dead not mean you delete them, dead mean it just don't make them run anymore. Right. And that would have been a complete easy safety net. Right, that feature can also help. I know some people have written into their workflows this loop where it kind of checks how old it is and then it auto completes itself. So this will kind of build that feature in. Yeah. Okay. So don't have hundreds or thousands of values in a defined type. And so why is that? Yeah, people may not realize that the data you put in those defined types, they're little dictionaries or books that get stored into memory. And , we want those to be super, super fast, But if you start putting volumes of data in there, you're going to potentially affect your system negatively. Yeah. And so that comes up sometimes when you talk about a new feature and someone might say, oh, we don't need a new table for that. We'll just use defined values. And sometimes that's appropriate if you're gonna have ten, twenty, 30, maybe a hundred, maybe 200 values, you're okay. But if you start putting a thousand, a hundred thousand Oh no. You're misusing that feature in that a lot of people don't realize it's stored in memory. Yeah. And when they are told that they, oh yeah, that doesn't make sense then. But there could be an edge case, if you're writing a huge feature, maybe, but- I would probably find a partner to turn it into a real entity. Yeah. Find someone else in the community to run that idea by and make sure you have a lot of memory in your server. Don't test in production with tests that creates lots of new person records. Person records can't be deleted. Yeah, they're very difficult. And even if you try to collapse them into an existing record, the remnants that it creates behind the scenes is going to live forever. So that's a perfect example why you should have a test system. If you're gonna be doing any kind of load testing or tests, you should use a test system, not your production system. Yep. Don't host your development and production instances on the same server. Sometimes it's easier, but it doesn't mean it's a good idea. There can be situations that happen where one system can interfere with the other and that would just put you at greater risk. So it's kind of one of those, you're at a higher risk level if you're trying to blend a test system and a production system together. It's definitely not a corporate 500 best practice. Yeah. And so why do you have a dev system? It's so that you don't impact your production system, but when it's on the same hardware, it's impacting the production system. Yeah, you could have something that starts a bad process and just takes over and destroys IIS. And now all of a sudden you've affected your production system. There's several situations that could haunt you if you did that. Yeah, it also leads to a very, well, it leads to a more complex configuration to where that's tripped us up a few times where the configuration's a little bit more complex. And a lot of times you don't assume that when you're working with the system and you're , oh, why why is this? Oh, oh, because it's the the dev systems running on this too. The and the the complexity of that was tricky. Be sure to install security updates quickly. I mean, that seems it goes without saying, but we try to take this super seriously. So when there's a security patch, if you see us patching three different versions of Rock 10.4, 11 point four and 12 point something, you should jump on that. You should go out and get that and apply it as soon as possible. Yeah, this realizes in technical environments, there's a lot of responsibilities and security is always one of the top priorities and we're treating it as top priority. We just, it doesn't do any good if we treat it that way and people don't put the security updates in play. And so on the release notes page, if you didn't know this already, there's now a little sidebar at the top that says, which are the secured versions of Rock? There's three at the moment. And right now, one of the things I'm working on is getting that next year's pen test all research configured, who's gonna do it, get the quotes. And let me tell you, it is a lot of money to have these tests done. And it's money well spent, but only if it actually gets installed quickly. Regarding the last note I just mentioned, let me clarify that. It's the it's the most secure version for that particular major release of Rock. So for example, I think it says 12.2. It doesn't mean 12.3, 12 point four, 12 point five are not secure. It means you've got to be at least 12.2. Obviously, the future patches of that same major version are just as secure. Correct. Okay, next one, share lessons learned. I mean, you should always be sharing. Sharing is kind of my philosophy for life. I think it's my life first. He who refreshes others will himself be refreshed. I take that to mean teaching and training as well and sharing. So some of the ways that we've done that are we've held lunch and learns. Everybody has to eat and it's a perfect time to talk. Why not talk about something that is very valuable? So get some food, get your staff together and teach them about something in Rock, whether it's a best practice you're trying to enforce in them or something new that they need to be aware of. I think we already mentioned the run books. That's another way to share, but blogging. I think sharing amongst the community too. I mean, a big situation happened recently with a church that ran into a pretty big issue that their own activity had caused, but honestly, don't know if I would have thought that that would have been a cause the problem too. So I learned a lot from it. And so I just to go around and share because, hey, if someone trips on a route, then the polite thing to do is to point down at it and say, hey, watch out for that route. So that as you're hiking as a team, that everybody trips over the same route. And again, a lot of these things in hindsight, they're , Oh, well, of course, but it's only in hindsight that they seem so obvious. So as you have run into those lessons learned, open up a permanent notebook and put a section in there called RX and write down for next year's RX, the topic that you wanna share, especially if it's a big one and everybody needs to know. Those are good examples of things that need to be shared at the conference. Yeah. Put it in the conference book, throw it in the rocket chat. I saw there's a guy who does a lot of technical training for a specific product, in the industry. And he does a lot of q and a. And he has a thing, a rule that if you ask a question, you have to ask the question on behalf of a friend, even if it's your question. And he does it kind of tongue in cheek, it kind of reduces people's , they don't want to look stupid by asking a question that you might already know. So everybody, I didn't pick up on it because I was at one of his online seminars until after I saw everybody doing it. I'm , this must be our thing. But they would say, have a friend who wants to know. And so you might put it in, Hey, I have a friend who tripped on this route and did this. You don't have to necessarily say it's you because some of the things are kind of embarrassing in hindsight, I've done it. And I'm , I don't want to tell people not to do that because I just did that. So just say, Hey, I was working with someone the other day, or I was working with a friend and they did this. Or I know someone, yourself, so. Yeah, so don't be embarrassed. Use a mnemonic that to help you if it makes you feel better. Okay. And the last one that we have for today at least is to really do a health check on your system, know your system. Yeah, as time goes on, you're going to find things that you should check regularly. And if you don't have that documented yet, you should document it. here's my little checklist of things that I check weekly or monthly. And a few of the things that I think are important are how many workflows are running successfully or still running rather. That was the item we talked about earlier. How long are jobs taking to run? Is it abnormal for a job that normally takes five minutes to now be running, taking thirty minutes? Are there errors in the jobs, the job history that you should be aware of? , would go look at that stuff. Yeah, there's a long list of things you probably should do and you should build that list up over time and share it. It used to be that cars weren't always as reliable as they are today. I know that some people maybe didn't live through that, but my mom, when I was a kid, taught me to check the oil every time I filled the tank. You have to wait anyways, you might as check the oil. I don't do that today because cars are much more reliable, but it kind of harkens back to that. You have to go around and check. And I feel what I talk about with some of the people on the team is you have to feel the system. There's a science to this too, but there's just a feeling you get, and you should know how your system runs. , think of a captain of a ship. A lot times he'll know something's wrong. Just say something, I'm feeling a vibration, or there's something not quite right. You have to know your ship, and you have to know, oh, yeah, that job, it takes long, but it's because of X, Y, Z. And that's within normal for you. It may not be normal for the next church, but it's normal for you, but you have to know that. I love to look into IIS logs. Definitely be checking, making sure your IIS logs are running. Go into those IIS logs. Every time you go into those logs, you'll see something that is interesting. You'll see a bot maybe attacking you, or you'll see I was in a church's IS logs a couple months ago. They're asking for some help on something. And I noticed that their keep alive wasn't being called. And I was , Oh, you must have a DNS configuration. The keep alive isn't calling itself it should. Not a big deal. it's not something that is gonna cause harm, but it was of interest and pointed out a misconfiguration. But every time I go into someone's iOS logs, you can see stuff in there , There's another one. Oh, I saw a ton of four zero four messages to a endpoint. And I'm , you have a system out somewhere. And it wasn't a Rock end point, was a PHP end point, but you could tell it was not a bot. It was , it had some kind of ministry name in it. I'm , I think you have some old software somewhere that's calling the new www, which is now Rock, but it was formerly probably something else. you need to go find that because it's a small little tax on the That reminds me of talking about logs. , when I was in my email days, we would periodically go and look and we would see an email message that was literally looping through multiple systems forever. if we hadn't got in there, saw it and removed it, it would just slowly build up and you'd, over time, you'd get hundreds or thousands. Now this was back in the crazy days of email, both with multiple different protocols. Yeah. But what the sad thing is at a big company that? That email might've been put in there by somebody that was their health check. Oh, it was. And it was We And by taking it out, production systems, , the the the the manufacturing system could now go down. I don't wanna name his name, but, yeah, there was a guy who who did that. He was monitoring the speed of our email backbone. He was cut from another sector. Yeah. I that's a That's a scary step in When you see stuff that, you're , you're you're so afraid to remove or do something about it because you don't know what somebody is bail bailing wired and duct taped together a I think the main point though is get to know and put your finger on the pulse of your Rock server, and you should understand and know how it behaves and which things are, should be of certain sizes. Now that's another one, the size of tables. I had a script or a report that would just show you list out the size of all the tables, because if it got out of hand, it grew too much, you might have a problem that you didn't know. We would then set up metrics on certain things. So we'd write a metric so we could see a graph to see it changing over time. There's just so many things you can do inside of Rock. So that would be maybe another item. Check your metrics that you set up weekly or monthly. Yeah. And as you start this, you're gonna feel very, it's a waste of time. Because you look in the IS logs, you're gonna , I don't know what to look for. Well, that's, yeah, the first few times you go through that, you don't know what to look for, but after you start seeing the pattern in the future, you'll go, wait, I had never saw this stuff in here before, this is new. And sometimes I would just, in the IS log specifically, I just kind of run, I'll go through them in detail, and then I just kind of scroll up and down real fast, and I'm looking for You'll see patterns of , oh, here's a whole bunch of the same requests, Cause your eye gets pretty good at seeing patterns. And you're , oh wait, what's that? And you'll stop and look at it. Oh, that's a big bot attack. Maybe I should put something on the firewall to stop that. It's interesting because in physical health, the healthy human temperature has a range. Right? And so you can, if you take your temperature regularly, get to know what your range is, what your healthy typical normal temperature is. And it might be different from someone else in your family or a friend or, , an average across a population, but that's your normal temperature. And so you're better able to determine when you have something else that's going on because you can you can see that change or that movement. It might still be considered slightly normal on an average, but it may not be normal for you. And it's an indicator of something else that you should look into. And, , I don't think anything gets simpler over time. it from people to systems to to anything that complexity grows. And so the regularity and consistency of understanding your system, not just once, don't just look at it and go, oh, looks good. Okay. We're good forever. But just getting in there and regularly understanding what's going on is the key to helping prevent or curtail some of the the chaos and complexity. Yeah. And just know that your server does have the body, it has symptoms and you have to just look for the symptoms. a lot of these log files and such, and some of the stuff that Nick brought up, it's basically literally puking in the corner and you're just not paying attention. And if you just go, you're , Oh yeah, that's not good. You don't have to have a PhD to know, Oh my gosh, there's 10,000 workflows running every, yeah, that's bad. That's it puking in the corner. You're not even looking. Just saying, open the door, look, take a whiff. Okay, we're good. Oh my gosh. The word pictures never stop in case someone hasn't picked up on that yet. So, and it's just trying to pick up, and then there's always going to be a lots of little things that are going to pass through. Those are fine. It's the big things that can make a huge difference. I'm working on a video concept, and it talks about aerodynamics and efficiency within a system. So , imagine you buy a brand new Tesla. I say Tesla because it actually has a very, very good efficiency in terms of going through wind. You wouldn't know it by looking at it, but it's actually one of the most aerodynamic cars you can buy. If you look at a Lamborghini Countach, from the eighties, nineties, it was actually one of the most inefficient aerodynamic cars available. You look at it, it looks a wedge, you'd think, oh, this must be super aerodynamic. No, actually a semi truck. A modern day semi truck has better aero Aerodynamic efficiency. Aerodynamic efficiency than a Lamborghini Wow. So let's say you're okay, you got Rock. It comes out of the box, it's Tesla. It's it's pretty air efficient. We're always trying to do better. But then let's just say, well, you decided it'd be cool, , to drive with the doors wide open. And and that's kinda what maybe you've done with with some of your workflows. You've put a you put a stick in your door and and you're you're driving it with a wide open. You're , this is this is terrible. , my efficiency has gone way down. , this car is inefficient. No. It's the way we use the car or the add on that we bolted on. , you might bolt on some crazy aftermarket spoiler that's looks really cool, but is not air efficient, aerodynamic at all. Yeah. You can't blame the say the car. It's it's the bolt ons. It's the plug in that you maybe have or the custom code that you had written or the fact that you're driving with both doors open and maybe a shovel out the window. The front trunk is open. Big air. Could you embarrass So those are the things that we just need to spot and look for. Just know that as much as the product has to be efficient, your usage of the product is probably gonna be the biggest contributor. You can have an inefficient product if run efficiently will still be okay. But if you have an efficient product run inefficiently, it's terrible. It's horrible. And that's what we're trying to point out. So this is, I'm sure not a complete list of all things that could ever be shared, but it is our list for today. And it is something that we're going to put out on the Rock site, so it's accessible in the future. And we're going to work to continue to compile and share best practices as we trip over those roots ourselves, or as we become aware of something that, oh gosh, I'm not sure we've shared that before. That's a great tip. So we'll look for other ways to continue sharing that information so we can all increase our efficiency and and learn dynamically from each other instead of having to trip on the route individually every time. So keep an eye out for that. This was great to be able to share some of this information and and we hope that it helps you. Thanks for tuning in for this special edition of Rockcast, and we will catch you on the next one. 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.