Coding Blocks - Code Confidence using NASA’s Ten Simple Rules

Episode Date: October 2, 2023

We’ve mentioned in the past that the code we write isn’t maintaining heartbeats or being used in life-critical settings, but what if your code is? NASA happens to be a company who has code that is life and mission critical and it’s very possible it won’t even be accessible once it leaves earth. In this […]

all right i think we're ready to do this thing are we because if we are then this is episode 219 uh that's one more than the last time so i guess we're recording now in the show's life and alan loves it when we start this way take a deep breath yeah that's true alan and out breathe out is that what they said on Bad Boys? Gruesfaba? Gruesfaba? Something. Something faba. And we are recording. This is Coding Blocks. Visit us at

codingblocks.net where you can find our show notes. We'll start chopping up onions in the background or something. I was trying to like channel my best NPR kind of voice, you know. Very relaxing. Thank you. Yeah. Very nice. Well, I'm Joe Zach.

I'm Michael Outlaw. I'm Alan Underwood. And for this episode, I thought a fun topic might be learn how to space proof your code. Have you ever wanted to do that? Have you ever even thought about that? You mean on the moon type space or like Mars? Or what are we talking about? What kind of space do you think I meant?

Did you think I meant like, you know, space between like, hey man, I need some space. We need some space. Step back. I don't know. Step off. That's the kind of space-proofing code I'm writing. Step off.

See? Okay. Well, that's if kind of space proofing code i'm writing is step off see see okay well that's if you believe in space yeah i started getting uh facebook ads that like kind of make fun of like things like the earth being around and like the space shuttle being real and i live in central florida right so i've seen many space shuttles my entire life going up and i saw little uh comments on facebook of people questioning whether uh anyone's ever actually seen the shuttle go up because they didn't quite believe that they were fast enough because look at them don't they look dumb and and where did it actually go did you actually see where it went i mean i went out of my range of vision i've seen them explode too you know i've

seen them like you know I've seen them disappear. How do you know it wasn't just an RC shuttle? That's right. Just saying. Did they let you up next to it? This is all suspect. It's true. This has definitely

taken a tangent that I didn't account for. Hey, we're off. We're off to a great start already then. Hey, you're the one that brought up fake moon, so whatever. All right. Did I bring it up though? Okay.

We'll go have to rewind it. Fake moon. Oh, I did. There it was. Nice. So this all starts from my son sent me this video a while back. I've been holding on to this topic now for a while, but he sent me this video that was pretty neat. It's on YouTube. There'll be a link to it in the notes, the show notes, which by the way,

if you don't already know, you can go to codingblocks.net slash episode 219 and you'll be able to find the show notes for this episode, which will include this link. But there's a video on YouTube called How NASA Writes Spaceproof Code. And the idea here was that this, the video is based around this set of rules that NASA has called the power of 10. And the idea behind these rule, this set of rules is to help ease static analysis, but also like just more generally, you know, uh, right. Cleaner code, you know, easier to debug and things like

that. But they heavily rely on static analysis for doing things. And, you know, really like the end goal being like, you're going to write code that's going to run on some robot that is, you know, some obscene number of light years or, you know, whatever, something not light years, I guess, but, you know, some nine months away from you. Right. And you know, you're going to have extremely limited communication. So, you know, those robots need to work on their own, right. That is until like Megatron comes and gets them. Cause I did see a documentary where that happened, but whatever. I digress. So documentary.

So, so, uh, well, yeah, cause the Mars rover stopped communicating, but yeah, whatever. So we're going to discuss the simple, the 10 rules that they have. And some of these are going to be like, well, that seems kind of obvious, you know, but then some of them got a little bit more interesting as we go. So I'm going to throw them out there and then we'll discuss. So rule number one in NASA's power of 10. And, and, oh, by the way, I should add, you can easily Google NASA's power of 10 and you will find

8 billion Google results. And so I'm going to say these rules like rule number one, blah, blah, blah, blah. And some of the results that I found, like the rules were in different orders. So, uh, you know, I tried to find a more official NASA link for it and I, I can't came up empty. So whatever rule number one, simple control flow. So this is meaning you're not allowed to use statements like go to or set jump, long jump, which, OK, those those all sound fine. But here, you know, because you're going to think with those like, oh, well, that's going to be like super language dependent. But the big one here is recursion. No recursion. Right. Good riddance. Yeah. Some of these are going to be like that,

right? Some, some of these are going to be like, yeah, I love that idea. Like no recursion, but you know, you think about like all the trouble that you can get into with recursion. And we've talked about it in the past with like, um, you know, stack overflows and things like that, right. That you can get the troubles that you can get into with recursion. But like, so the point that I'm trying to call out here is that some of these are going to seem very specific to a given language. And some of these are going to, are going to apply to all and like the recursion one applies to all, but a go-to, you're not really doing a lot of go-to in Java. Feedback, comments, thoughts, rants? The recursion one's funny because I was almost writing something that was going to be recursive the other day. And I was like, you know what? No.

No, I'll find another way yeah no the deal is that most things that are recursive at least there's an iterative way to to run it that's going to be much safer and is less likely to kind of explode on you at least in terms of like memory and frames because just calling functions is expensive because the way the whole you know stack works like each one is a frame each one allocates memory like it's generally bad news if you can replace that with a variable and so like all those kind of like um you know uh what's it not fibonacci what's the one where it's like the it is fibonacci where like you can add the numbers up recursively like it's a beautiful algorithm recursively it's a terrible idea you're much better off just doing

a loop but it always feels so like you feel like you're in control of the matrix when you do it right like you feel like super cool and that's the matrix when you do it, right? You feel super cool. And that's the problem is that there are some of these things that you can feel super cool about doing it. You're really taking advantage of the power of whatever that framework is. And yet, they're still like, well, yeah, I mean, you can. Right. Should you? Well, you know, on that topic, the reason why I ended up stepping away from it was because I think I was doing something in JavaScript. I don't even remember exactly.

But I was like, you know what? Let me just find out what's the max depth of a stack here. I don't think that it's going to be that large for my needs. But I started reading and they're like, well, some of them do 10,000, some of them do less. So, and when I say some of them, we're talking about the engine. So it's like, you're not even guaranteed a certain number across that particular, you know, stack or whatever. I was like, you know what? All right, I'm done. I will go the iterative way. Just like Joe said, you know, there's, there's other ways to do the same thing and usually way easier. It just seems like, Oh, it'd be real cool if I could do this. And then you're like, no, it's not. So rule number two, limit all loops to a fixed upper bound. So think about like anytime you've ever done like, you know, while this variable is true,

do something, right? But in their rules here, not, you wouldn't just do that. You'd say like, while that is true and my iteration count hasn't exceeded whatever my maximum is. And so the example that was given was like, think of a linked list traversal, right? You could easily say like, Hey, while the next node is not null, continue reading, right? But to prevent it from going out of control, right? Then you also add in this boundary check on it as well. And they specifically say that like, hey, if a tool can't prove that the loop bound statically, then the rule is considered violated, right? Okay, I get that.

Could you back up a second? I don't know if I missed it or where it was. This power of 10 is I see that you have to ease static analysis. Like what, what do we mean there? We're going to, we're, this is going to be like a common theme through all of these, but like using a static code analysis tool against this, right? These are all efforts so that those types of tools, right, can more easily review your code. Okay. So in the past, we've talked about like, oh man, just slipped my mind.

The.NET one starts with an N. N depend. N depend, thank you. And then I think SonarQube might be another one. Yeah. Or maybe I'm wrong. No, it's not. QSonar.

No, SonarQube. One is the music software, the other one. Yeah. SonarQube with a Q is the software one. Yeah. There you go. But, yeah, so the idea is that anything that you can do to better analyze your code with these tools, then it's going to help to improve your code, right? Okay, okay. But some of these operations that you might do, like recursion, make it dramatically more difficult or drastically more difficult for those those static analysis tools to analyze your code.

OK, and so we're saying by also limiting, you know, the length of whatever kind of loop that's running at that point, you can also dramatically or drastically reduce the possibility that you're going to get into an infinite loop don't even have to check for it because it's going to be done bingo you're not going to get into an infinite loop because you have a boundary on it yep okay so some of these yeah go ahead well they're doing these things i guess because you're writing software like you said for things they're going to be thousands of miles away. And you may not be able to control it at that point. So it needs to be able to do simple things to recover is, I guess, the whole point of this, right? And predictable.

Predictable. Maybe there's some sort of problem with the linked list or something, but we still need other systems to function. And we don't want to starve, like, the, I don't know, the Oxygen software because the Fuel software has a linked list with, you know, something. So, like, we need to keep things moving. It's interesting that you chose the word predict because that's a great segue into rule number three, which is do not use heap memory. So, you know, their examples, a lot of the code here was, you know,

and NASA's rules are largely based around the C language. So, you know, there's no need for the use of malloc or free in this case. But instead, only rely on the stack memory right and the reason why i called out uh your use of the word uh predict was that it makes it easier to predict how much memory your application is going to need if you're not dynamically allocating memory on the heap. But also what they called out was that, you know, there, I think they use the phrase, the video use the word notable, but there's quite a few memory bugs that exist due to the use of the heap and garbage collection, right? So various memory leaks, use after free is a special type of error,

heap overflows, heap exhaustion. All of those problems go away if you say, nope, you can't use the heap. You can only use the stack. And if you're only looking at the stack, that's really easy to analyze to find out exactly how much RAM you need. Exactly, because you're only looking at the stack, that's really easy to analyze to find out exactly how much RAM you need. Exactly, because you're only using it in static analysis.

Applications that make use of the heap cannot be proven by a static analyzer. But to your point, the flip side then exists. They can easily analyze stack use. So yeah, we're tiptoeing towards formal software proofs. We're reducing the problem set to where we can get, just focus on predictability. So the heap, that could cause problems in the function I'm running now just because I'm out of heap space,

which has nothing to do with the thing I'm trying to run right now. But if I eliminate the heap, then things should run consistently. And so as long as there's enough memory for me to allocate this on the stack, then it should run the same way every time. Yeah. So by only using stack memory, including the upper boundaries where necessary that I mentioned before, you can compute exactly the amount of memory your application will need. Right. You're removing the guesswork out of this sort of thing. Right.

You're saying like, hey, you go into this function. This is the amount of memory it needs. Right. And it can now be proven by a static analysis, you know, and bonus by only using the stack, you eliminate the possibility of the previously mentioned memory bugs. And for those who don't know, quick refresher, right? The heap is where objects go and the stack is where any variables within a method call are put, right? Like, so if you have,

if you define a variable or something inside or is passed into your method, I wouldn't, I wouldn't phrase it that way because you could have objects that are definitely in the stack, right? It's, it's going to be a matter of like, if you had, if you had a string,

like if you had a, I'm thinking in like terms of C plus plus, right. And you had a class that had all primitive data types like integers, right. That could easily sit in the stack. But if it had a string pointer, then that pointer is going to be off into the heap,

but the pointer itself would be in the stack, right? Right. So yeah, the 32-bit or 64-bit pointer is going to be reliably allocated on the stack, whatever that function is called. And what's nice about it is when the function exits, all the memory is automatically reclaimed. You don't have to worry about anything dangling or whatever.

Yeah. So, so, but, but that example of like that class where the pointer is pointed to the heap, though, is the example of what you wouldn't want to do per NASA's power of 10

rules, right? You would, you would want to shy away from, uh, you know, things like that. So, um,

and, and some of this, like, you know, to be fair, cause it's been a minute since I've done any C and C plus plus type programming. Right. It's like, Hmm. Okay. Like I actually like looked up some of the stuff I was like, wait, how's that? Wait, it's been a while. How does that work? So some of this, I'm like, man, I don't know how you get around some of these things. Like, like the, the, the string example, you know, like, I'm like, how do they get around that? You know, I mean, I guess you could like, you know, a fixed, a fixed size, you know, but yeah. Um, again, it's, it's been too long for me to, to, to know on some of that. Right. It's a file. I don't know that they're going to want that either to do what was that right to a file. Yeah, sure. They'd love that. No. Um, yeah. And, and like I ran out of time cause i was like putting these notes together before

we record so like i said i did you know have to go back and look at some of them but some of them i didn't have time so that was an example of one i didn't have to go i didn't have time to go back and find but um okay so so far pretty interesting right like you know i mean the heap one was my favorite uh of them and uh you know but the next one I was like, OK, well, this one's this one's going to sound familiar. Right. Rule number four, limit your function sizes. So going back to the old school classic, you know, function should only do one thing, but it might require multiple steps. Now, this is very consistent with like the Uncle Bob series of books and other best practices and

principles that we've talked about over the years, right? And Uncle Bob takes it to a more extreme, like, you know, I think he had like three lines, like, you know, you shouldn't have a method any more than three lines. And, you know, NASA doesn't restrict it to that. Their recommendation is that functions should be limited to 60 lines or whatever can fit on a single printed page. And the reason for this limitation is that, well, there's a couple of reasons. One is that it makes it easier for someone reviewing your code to be able to read that entire function and understand it in its entirety without having to like flip back and forth, right? They can just look at it on the screen and be like, okay, I see what you're

doing there. Right? So that that's number one. Number two though, and this is kind of going back to the old school classic, you know, principles that we've talked about over the years, because you've had to make it smaller, that also, uh, maybe inadvertently made it easier to make that method testable. Right. So, you know, you had, you got this like side effect that you might not have intended, but in like, I kind of wrote this wrote this joke about it's not just some meandering 2,000 line long function with 18 levels of nesting, right? Because at some point in every one of our careers, we've all seen those types of files where you open up some class or some file and you're like, why is this thing 12,000 lines long?

Wait, it's all one method you know like so so and those are like really hard to read right so rule number four is to limit all that but also a very you know like we've talked about that one before. Uncle Bob, uh, this was another one of the ones up there in terms of like my favorites. So, um, rule number five is hide your data. So there was a quote in the video. Um, and I wasn't sure if like this quote, if the, if the video author was,

you know, attributing it somewhere else, but so I wanted to be careful to call it out like this quote, if the, if the video author was, you know, attributing it somewhere else, but so I wanted to be careful to call it out. Like, Hey, you know, um, I'm quoting the video and the video might be quoting something else, but data hiding is a technique of hiding internal object details. Data hiding restricts the data access to class members and it maintains data integrity. The idea here is to declare your variables as close as possible to where they are used at the lowest possible scope. So think of an example where you have a function and maybe inside of that function you have a loop and maybe inside of that loop you could even have like another conditional, like an if statement or something right there.

Wherever you need, if the lowest point that you need that variable, if it was inside that if rather than just declaring it up above at the top level of the function, instead declare it at the lowest level inside of that if statement, for example, and that way you're reducing that variable scope. Now that's also going to be language dependent, right, because JavaScript did the hoisting for you. So let's ignore that example from them because, again, we're living in NASA's sea world here.

So in this case, we get into like, what was it like ECMAScript 2015, where you could do the lets and, you know, so that you, so that JavaScript would honor those, those lowest scopes. So by doing this, you get a couple of benefits of it, right? Um, first it reduces the amount of code that can access that access those variables. Right. But maybe more importantly, is that by reducing those number of touch points and the number of places that could possibly change that variable value when when it comes time for you to debug it, because you like hey how did it get that crazy value by limiting that it aids your ability to debug it right because you're like oh well this is that it that that variable is only defined inside of this if statement which is inside of this for loop you know so you know that's slick yeah yeah so i think so far in terms of like these rules

the not using the heap was probably my favorite the hiding data was second and then um you know the recursion not you know simple control flow is probably third so far. You know, it's funny. Like I would say that mine, one of my favorite was the limit all loops to a fixed upper bound, because it's amazing how easy you can get in a runaway situation and not even realize it, you know? But this last one, the hydro data, that's something that I've always kind of done over the years, right? Like if there's something that I need set, like I guess just internally, and it makes sense. And I think the whole reason I ended up doing it was for debugging, right? Like how many times in your early career did you have things getting set all over the place?

So you're like, how did that get that value? And you realize that you had sort of leaked its implementation all over the place, you know? Yeah. Another way to interpret that one, though, is if we get into like an object-oriented world, right, it kind of makes you want to shy away from using member variables because then their scope is like every method can potentially touch and alter them. Right. Yeah, totally. So, you know, again, there, this was more from a C perspective, so that's not really a problem for them, but, um, you know, just, just trying to like, okay,

how can I take some of these principles and apply it to my day job, which is not writing for a robot in C in space. Space robots. I like these so far. They make sense. Yeah. I thought they would be interesting to review. And, you know, I say review because a lot of these like are things that we've probably talked about in various topics related to like an uncle bob or something or maybe we haven't thought about or ever like really formally like described but you know like to your point about the data hiding you know like it's just something that a practice

you put together you know like you fell into by mistake right without like really formally defining it so um okay so you know uh speaker reviews i just googled to see uh you know what the deal is with reviews because it's been a while uh since i've seen you know since just saying it's been a while since we got one uh it turns out uh that five star reviews are the best they're really good actually they're really good for podcasts that really help us out a lot and uh you can only give yourself so many of them so i was hoping uh if you're out there uh listening right now you could hook us up with a review too because it really helps us with the show and uh yeah i I've hit the limit. And so that would be really great. We've got a URL set up, codingbox.net slash reviews,

where you can go and click a link and drop it. Let me, five star review would be great if you could hook us up with that. And we've got a couple of links there to try and make it easy for you. And yeah, five stars would be great. Wait a minute. No, no, no.

Alan likes the three stars. No, that's yeah, five stars would be great. Wait a minute. No, no, no. Alan likes the three stars. No, that's never, that's never come out of this man's mouth. Three stars, right? Yeah. I'm looking at it right now. It says, I thought hat tricks were good things. I thought that's what I'm confused now. Hey, I will say, so we didn't actually have a review on the episode, but, um, ironically

enough, man, this is so bad i'm i am terrible at this so i got a proper name a noun well now no no it's more just dealing with social media stuff so i apparently got a message on linkedin in july of 2022, thank you to us for doing the podcast. It was like sort of a mini review. And, uh, I replied the other day, a year, a year and some months later, you know, what's funny is when I saw this message the other day, I was like, Oh man, I'm like a couple months late. I didn't realize I was like a couple of years late, but you know, Hey, if you want to reach out to us that way too, that's really awesome. You know, um, thank you. Anybody who takes the time to, to send us in some, some love for the, uh, 10 years. Hey,

have you guys been getting a bunch of, uh, LinkedIn happy anniversaries, um, for, for the podcast? No, but I am glad that you called that out because I was meaning to mention that the 10th year anniversary of Coding Blocks went by and we didn't even mention it. And it depends on how you decide to count it, right? Because I went back looking and I was like, okay, there's when we actually formed,

you know, the, the, the LLC behind it or versus when we released the first episode versus when we first set up the website and the first post versus when we first got together and recorded, because we recorded before anything was, was,

you know, ready. Right. We started recording. We still ended up doing it. Right. Like we recorded and we was ready. We started recording then. We still ended up doing it, right? We recorded and we were like, hey, this is still a decent idea. Let's go ahead and do it. So my point is no matter what metric you choose to use as the birthday for it, we passed it.

We totally 16 candles that thing, forgot all about it. Nobody paid us any attention. And yeah, there's a John Hughes reference for you. Well, we know outlaw knows what day the first episode was published on the website. Jay Z, do you know?

No. See, I was wrong too. I would have thought it would have been like September 20th. I thought it was August something. No. Oh, you were wrong. Look at that. September 20th. I thought it was August something. No. Oh, you were wrong.

Look at that. September 9th, 2013. The very first episode is published by Joe Zach. No, no, no, no, no. I thought it was you published, published the very first. Oh, you said episode episode. I, okay. I was thinking the first article on the website.

Oh no, I don't even know what that is that one predates that one and that's the it was like a interface guardrails thing yeah IAS for interface was number one that's the episode I'm talking about the article though

I don't even know how many pages I'd have to go deep here but alright so yes at any rate we all missed it but thank the article though i don't even know how many pages i'd have to go deep here but all right so yes at any rate we all missed it but thank you to everybody who's reached out and been like hey you know congrats um i think we're one of the few granddaddy uh podcasts still around so back in my day right seriously it's uh it's pretty awesome said so do we get like bumper stickers like my podcast can beat up your podcast or something like that yeah is that what we're talking about i never said i ever say that i have uh it's a crap let's say that says uh my podcast

is smarter than your honor student august 15th interfaces as guardrails. Dang it. Isn't that crazy? August 15th. Michael for the win. How about that? That's crazy, man. Told you. August.

Yeah, actually, I have that sticker on my car, but it's hard to see because of all the other anti-moon stuff and whatever else I got on there. And all the tinfoil kind of covers it up but i do get a couple comments sometimes the tinfoil covers okay amazing all right so yeah that must work well in that florida heat too all the tinfoil on your car yeah it's got to be good you know i'm saying i get a lot of looks you I'm saying? You're causing the global warming with that tinfoil, sir. That's what's up down there in Florida. I get a lot of second looks. That's all I'm saying.

They see me rolling. Okay. So let's see. This is episode 219. According to TechHose, trademark rules of engagement. Alan, you are first. You are on a losing streak. I don't mean to you know shame

anyone but you know technically yeah yeah so your choices are this is uh oh yeah we still haven't come up with a name for this but um you know we got a bunch of good ones i always got a bunch of good suggestions okay let's hear it let's hear it all, uh, it's gonna take me a second to find it. Um, okay. Episode discussion. Slack has a ton of great names. You, you, you look that up and, I'm going to give the topics out here.

All right. See what I did there or multi lovely. Oh, that's one of the, that was a topic. Okay. That book you've been meaning to read or at the store or going through some cycles or the Edwardian era.

Why am I saying that? Right. And Edwardian. I think I said it right. Yeah. Or the a list where the a is the first letter of each response so those are your topics well i don't like any of these um let's do at the store okay and we'll go we'll go middle of the road three three well you guys level three keep going to three let's go four oh here bump it

up one that's four here at the store this convenience store took its name in 1946 from the extended hours between which its stores were open 7-eleven what bingo what is 7-eleven he didn't even hesitate on that one. Well, kind of, but not for long. Yeah, I would have probably struggled on that one. It's like, wait a minute, Walmart? Took its name from the hours it took. Yeah, I was like, how is that possible? I thought it was named after the guy. It was like Walton or something.

That's amazing. All right, Joe, you got the names ready? Yeah, I got a couple of them. So Scott Harden mentioned mental blocks. Ooh, I like that. Yeah, sometimes it's hard to remember. That's pretty accurate. Graham asked to chat GPT, and here's a couple of suggestions.

I'll just blast them real quick. Code Challenge Clash, Coding Blocks Conundrum, Algorithm Arena, Binary Brain Teasers, Debugging Duel, Codecraft Quiz, Stack Overflow Showdown, Dev Duel, Jeopardy Edition, Codemasters Challenge, and Byte Battle, Coding Edition. Some of those weren't bad. Yeah.

I got to say that the mental blocks, like kind of keeping with the theme of coding blocks and, you know, the listeners being blockheads. And a human one again. Yeah. I'll take it. Yeah, I love it. I love it.

And also I suffer from mental blocks. Yeah. Like right now, even. Well, you're going to have to get over it because you need to think of which category you want to choose from next. Historic ships. Oh, okay. Go want to choose from next. Historic ships. Go ahead. Historic ships. Historic ships. The Bible.

A trip to the museum. Body part phrases. Musical theater. Or driving in LA. And since you said the Bible. No, just kidding.

That was category two. That was for the last one. So let's go with body part phrases. Okay. One, two, three, four, five. What kind of level you want to go with it? I mean, seven or eleven. So I'm going to go with two.

Two? Okay. I mean, Alan stepped his game up. But yeah, sure. We'll go to yeah no shame there body part phrases to fall in love in a surprisingly complete manner is to do so this way mentioning body parts on two extremes what is head over heels so lame that is correct that is correct man got it high game this is interesting now here we go here we go this is i wonder yeah you would have gotten you would have gotten number four by the way had you had you decided to like man up and

go for the fourth oh i didn't mean to shame you when I said that. Yeah, I feel the same. Well, what's number five then? Because I'm going to get that one too. Oh. Well, we're moving on. He said no. Yeah, you'll never know.

Okay, all right. For the spirit of it, I'll read it real quick. The fourth one, and this is why I was saying you would have gotten this one. From World War II came a reminder to be careful what you say around others, because these sink ships, loose lips. There you go.

And the fifth one was when you need to concentrate on your ultimate goal, remember to keep this a rhyming phrase involving visual organs. Um, visual organs, eyes. organs of the eyes. What was the... Eyes on the prize. There you go. Eyes on the prize.

All right. So for round three, back to you, Alan. You get to pick the category. Yeah. Your choices are brush up your Hebrew. Don't laugh at me.

Historic events, a trip on the Gulf stream. Oh God. He's going to pick this one. Sports stars. Oh, there it is. American folklore and legends or computer science with Matt.

Amadio. We got to do computer science, don't we? I'm saying that one wrong. For the first mental blocks winner. Even though I feel like sports is better. You're allowed to pick whatever you want to pick, but Matt, and man, you know how I am with proper nouns. Matt Amadio is a Je jeopardy super champ and yale phd focusing on

artificial intelligence and machine learning and uh yeah so these are these are questions from him so let's do computer science let's go middle of the road because i'm not a ml guy okay here we go in this code that's the basis for digital computing my beloved cleveland guardians would have retired bob feller's number one zero zero one one and jim thorns one one zero zero one what is binary that is the correct answer. I get it. I can't believe that was a level three. What was level four? These are all, this isn't, how deep do you think they're going to get on Celebrity Jeopardy?

Did you really think that they were going to be like, okay, given this linked list, find the bug. I mean, anything. I don't know. I feel like cheated and number four a statistician who annoyed some computer scientists by butting into our field john turkey turn yeah turkey came up with this eight letter word for the programs that tell a computer what to do algorithm uh algorithm uh assembly no no no no i don't know what is it software so oh come on we lose all right you want to just go down this the computer science one just for kicks yeah yeah why not let's do it before the hard disk era the storage of data or programs known as this word took more cumbersome forms like huge circular drums and

reels bearing hundreds of feet of tape i was gonna say tape yeah uh i don't know what is real to real? No. What was that? I forgot the first part of the question. Mental blocks. I mean. Memory.

Yeah. Memory. Memory. Oh, man. Able to recognize patterns and help solve problems. Neural networks are designed in imitation of this roughly three pound item. Your brain. That's pound item, your brain. That's right.

The human brain. Uh, let's see. We did that one. We did that one. Last one. This word means a procedure for solving a computational problem. It can be simple,

like the steps of long division or complicated, like the ones search engines use to deliver results. And now I got it. Jay-Z got it on question number two or three or something. Yeah, I forgot to count the letters. I got so excited about saying it wrong. Yep. So, all right.

So back to NASA's power of 10. So think of like, what was uh um oh shoot the looney tunes character uh dag blasted blah blah what was his name uh yosemite sam yosemite sam so i thought i had like yosemite sam in mind when i wrote this, like check the blam, blam, blam return values, right? NASA didn't quite put it that way. They had a more elegant way of saying it, but how many times,

okay. Think about this. How many times have you ever been bitten by code that makes some call, even a shell script, right? Or, or a command on the command line, you know,

in a shell where the call failed, but the return value that would have saved you wasn't checked. Many, many times. It happens to everyone throughout their career. It's just a thing, right? So the rule here is check the return values of everything that returns something. So in other words, if the method returns void, fine, you're excused this time, but always check them,

all of them. And they go so far as to say that if you explicitly want to ignore a return value, such as like if you did call it a printf in the example that was given, right, that would return back, you know, a result, you have to explicitly cast the return to void so that a reviewer of your code knows that you do not care about that particular return value. That's pretty interesting. And if you fail to either check a return value or cast it to void, it'll be brought up during the code review. That's pretty good. I mean, it's pretty awesome.

I think is what you meant to say, but also like as a code reviewer, think about like, now you have to have this like, you know, like memory map of like, okay you have to have this, like, you know, like memory map of like, okay, here are the functions that return back something.

And what that return type is versus here are the ones that don't return back anything. You know, it's very explicit now, you know, exactly. Yeah. But this is why I was saying like the,

the mental map thing though is like, well, what if it returns back like an int 64 and you're going to put it in like an int 16 space, you know what I'm saying? Like, you know, those types of issues that could come up,

come about, um, I don't know. I don't know how far they take it, but that was at least their their example was you had to check it and it might be okay if you're not like trying to store that into another that result into another variable but if you are putting it into another variable then that's where like you know type coercion could become an issue maybe i actually like this quite a bit i mean we

ran into something like this not terribly long ago from a bash script, right? There was a bash command that did something that was returning something that you didn't know about. And then it failed. You're like, why is it failing? Then you go look and you're like,

Oh, it has a return code. I wasn't checking it. Well, that's why, that's why I called out specifically. Like I was like, Oh,

like we could even apply this to shell scripts and things like that. Again, their examples and talk of this was more in regards to C, but I don't know. I'm sure they make use of some scripts on their, you know, it's probably all Linux underneath. It's probably got some crime job like restart, you know, whatever on Sundays reboot, you know, somebody reboot.

You have to remember to trap errors or else it's very easy to think something succeeded and it actually failed online. One, everything else just kept running. Yeah. So, uh, rule number seven,

the use of prerocessors, the use of the preprocessor is very limited. So this one is definitely going to be, you know, depending on like what your, your type of language is, right? So like in a JavaScript world, you're probably not going to come across this one. Although I don't know if node, if you're doing like server side node kind of stuff, if you can make use of any kind of preprocessor declarations, but I'm going to assume not since JavaScript isn't, uh, you know, compiled. All right. It's just interpreted, but NASA limits the use of C preprocessors to only file inclusions in very simple macros, right? And they have this quote in here to justify why. And the quote is,

the C preprocessor is a powerful obfuscation tool that can destroy code clarity and befuddle many text-based checkers, which was, you know, they, they were, their use of text-based checkers here is another way of them saying static code analysis.

But basically the idea here is that I don't know how advanced you guys are, how far you guys have ever taken pre-processor definitions, but you can, you can get pretty crazy with them, right? In terms of really muddling up the code, like what's actually happening here, right? So specifically, they call out conditionals that can change the code at compile time are called out as a no-no, right?

So they gave this example in the video that if you had 10 different flags that can be changed at compile time, then you have two to the 10 build targets that need to be tested. Makes sense. So in other words, those preprocessor conditionals can exponentially increase your testing requirements. So where I can think of this outside of C++ is you remember when we were like heavily talking about aspects and things like that? That's the same type thing, right? It's going through your, I can't even think of what it's called, your interpreted language, your IL code. And it would do what was called IL interweaving.

And that's changing your compiled code a little bit, but it's after the fact. That would be different. So I guess that's a little bit different, yeah. Aspects, I would imagine that it's not called out in the Power of 10, but I would imagine that that type of idea would be against what NASA is going after here. Because of the common argument against aspect-oriented programming is the obfuscation that happens. And you're like, well, I didn't even know that this other thing was happening before or after my code. So I would imagine that that would be a

frowned upon within nasa but here we're talking about like the the example that came to mind was in uh previous episodes i remember we talked about um i don't remember which episode off top my head but it was a feature flag reference and if def stuff is what you're talking about the pre-compiler stuff yes yes that's exactly what we're talking about here and we talked about like one of the ideas i forget which bookers or topic we were talking about at the time but it had it had called out the idea of using um these types of pre-processor flags as a way to turn off, you know, code that you didn't want live in production yet.

Right. But that way you could be shipping it. And if you wanted to test with it, then you could turn that thing on by the simple use of a, of a preprocessor definition, right? That's an example of what NASA doesn't want you to do. Yeah, that makes sense. A lot of sense. So rule number eight. Now think back to the pointer,

the heap one that we talked about before. Pointer use is restricted. So there was a quote here and they said, no more than one level of dereferencing should be used. Dereference operations may not be hidden in macro definitions or inside type def declarations. And this was an example of one that I was like, okay, wait a minute. Uh, you know, I had to think back to like, okay, what does it mean to dereference a pointer in, uh, in, in C for example. Right. And, you know, depending on like some of the answers are basically talking about like the, um, where was it? There was one, let me see. I want to quote this correctly. This one, uh, answer on stack overflow. Oh, I can't find it now. Um, you want to access the data value in your memory. Then that's the, that's the D reference to it, right? To access the value or to set the value of it. But what they're saying here

is you're, think about like the code, the, the, the, the syntax that you would write to access, to dereference that pointer, to, to set or read that value, Right. So in like a C sharp, I'm sorry, in a C language, you might use like the, uh, the arrow operator to get to that, uh, that value. Right. In here, the example that they gave is that you would, you would only do that dereference one time and set it to a variable, and then everywhere else you're using that variable inside to read it. Does that make more sense? And so that's what they meant by, like,

you're only allowed to dereference it the one time. Yeah, it gets tricky. I remember C++ and C being nasty in that regard. Like you could really shoot yourself in the foot if you didn't know what you were doing. Well, and that's, they specifically caught out. This is because pointers, you know, albeit powerful, they're easy to misuse. And so if you limit yourself to only dereferencing that pointer one time, right? Sure, you can use or change its value, but like you only get to do it that one time, then you like severely, you know, limit the times that you could mess up, right? And they also called out that the pointer restrictions aren't just to variables. They also include not using function pointers. And the reason here was because that can severely obfuscate the control flow of

your application, right? As well as make it more difficult for static code analysis of your application. So go ahead, Tracy. I was just going to agree with that. Like it seems like just having that one level of indirection is all it takes to like really screw with things in order to kind of point, you know, point them at things other than what you intended. Does it sound to you guys like they basically only allow functional programming at this point?

Like, yeah, that's what it sounds like. Okay. So it's funny you say that because I definitely heavily thought of that too. Like it's definitely, you know, if you're limiting the ends and the inputs and outputs,

like, you know what you can and can't do in it, then you do kind of get more into functional programming. And then by extension, that makes it easier to write test code around. Yeah. Right. Um, there's no state being stored anywhere. I mean, usually your state is stored in your heap, right? That's, that's kind of what you do with OO level applications and you can't use the heap. You're only using the stack, which means things

are getting added and pulled off every time, which means the only place where it sounds like there would be any memory for state would be the main control loop, right? So it sounds very, very functional to me just in terms of what they're describing here. Yeah, and this is how our robot overlords are going to work. They're going to be very fun. Math, all math. So think about this, though. How many times, how much code have you ever written or taken advantage of that allowed you to pass in a callback function?

Oh, lots. Yeah. Well, you were passing in a function pointer and you're not going to be able to do that here. Yeah, totally. Yeah. No JavaScript at NASA. Yeah.

So, like, that's why I'm saying, like, some of these ideas were, like, restricted to, you know, the language. Like I said, the preprocessor is an example. Like, you're not going to run into that in a JavaScript world, right? But some of these are like applicable to everywhere. And I thought that was a pretty cool one, you know, about like, you know, not doing function pointers. Cause even though in like a lot of modern languages, like

the Java based languages or C sharp, for example, like you don't really get access to the pointers. So you don't really think about them. Right. But function pointers, I mean, those happen. Right. So,

uh, here's number nine compile in. Let me see if I can pronounce this right. Pandemic mode there. I got it. Nailed it. First try. So the idea here is that you want to compile with all warnings.

And basically, this is the idea of treating your warnings as errors too, right? Wait, hold up. Hold up. You didn't seriously say the word the way that it was said, right? Podantic. Isn't that what I said? Yeah, I'm not sure which one's right. They're both wrong.

That's what I said. Say it again. Pedantic. That's what I said. What do you think I said? What do you think I said? Pedemic? No, I wouldn't have said that. That sounds silly. Pedantic is that's what I said.

My brain shut down like straight up. Like I was like, wait, you just, he kept going. Yeah. So compiling pandemic mode, this way you get the compiler.

We'll let you know all warnings, right? Cause all of the warnings are going to be enabled. So every time that anytime that the compiler sees anything that could possibly alert on, it's going to, it's going to issue that alert to you. Right. And treating your warnings as errors and address them before you release the code. Right. So, you know, I'm trying to think it was a good example, but like, you know i'm trying to think it was a good example but like um you know there's there's

times where like you've seen those compiler type warnings where it's like oh warning this could potentially overflow or something like that or you know i'm trying to think of like something that a visual studio or intellij might warn you of that like it lets you get away with some stuff is the point like when you have a line that runs too long like when you say when you say uh pandemic mode and your friend doesn't like say oh did you mean this you're like no that's not what i said that's not what i said a dantic that said it right the first time oh it hurts so uh but yeah i mean i know that like okay do you remember years ago we were working on a project where there was like an obscene number of of warnings just warning thousand no it was it was

a you know it was a strong five digit number my friend was it really? At some point we're like, okay, I think we're finally at a point. And it was years in the making. We're finally at the point to where we can turn on the capability, the pandemic mode where we could, we could treat these as errors and then make fun of our friends when they mispronounce a word live on the radio. I'm not, you know, not pointing any fingers, but if I was, I think you said it right the first time. I don't know who would do that. I'm sure I would have heard about it from somebody.

What did I really say? How did I say it? I swear. Aluminium. Aluminium. See, that sounds right to me i hear it and i'm like yeah yeah it sounds cooler for sure um you know what was interesting there was an example on stack overflow on this pedantic thing and and somebody was asking about that flag with antsy with the C++ type thing. And they said that like it'll complain about anything that goes over 509 characters because everything needs to accept that. And if you go over that, then not everything out there that compiles in that can do it. So

that's why it throws warnings, right? Or, or errors in that regard is because it may work right here, but it may not work on the next thing that you try and port this code to or this compiled compiled stuff too so it's pretty cool so uh last but not least at least according to the video and like i said uh some of these i didn't see um actually i'm taking a quick check oh so this is where it gets different so according to the video the last one was to just analyze and test your code and that at nasa they use multiple static code analyzer tools to do it because, you know, they don't all work the same.

Some of them will have different rules that they will use. And I think that we even ran into that as a recommendation before there was talked about. Oh shoot. Maybe when we were going through the DevOps handbook, maybe there, there was talking, there was talk of that before though, because, um, of this very reason, like depending on like how you would configure some of them and they, they would highlight different things. But obviously the big one here though, is to test, test, test, test, test. So preferably you're

using some kind of automated testing of your code, like unit tests or integration tests, but test it, test it, test it, test it, test it. Because literally lives could be on the line here, right? According to another one that I found, that one wasn't specifically mentioned, but one that was mentioned that we hadn't talked about was the codes asserted this. I'm going to read it specifically. The codes assertion density should average to minimally two assertions per function. Right. So again, like, you know, making it to where there's not like no more than two reasons why that,

that function could be like, Nope, we're out of here. Right. Only two reasons could at most could cause it to, you know, for there to be a, a reason to error out or to sort out.

But yeah. So, uh, like I said, there'll be a link to this, um, this video and yeah, I thought they were interesting. I like it quite a bit. We've, we've often said on this show, you know, Hey, we're not doing open heart surgery but what if you were right like this is the kind of stuff that that you would probably want to to take into you know consideration like yeah we probably don't want an infinite loop while this thing's doing something you know um yeah this this is pretty neat i don't know if a robot's operating on me. I might want an infinite loop while not done. Keep working. Oh man. So I don't know.

Open the other thread though. Yeah. Maybe your use case depends. I don't know. Right. Um, all right. So with that,

we head into Alan's favorite portion of the show. It's the tip. I had to throw you off there just to see. I was like, I've been doing it at the beginning of the show. What if I do it in the middle? Like what happens then? Yeah, I'm catching on. I've stopped the cold sweats and all that i think i think i'm growing nice uh so for my tip a couple years ago i mentioned uh an instrumental album that i really liked for a band called night versus called copper wasp and it was great i think it was 2019 maybe 2020 and i was really you know i was really excited about it i liked it i listened to a lot and it was great working music kept things moving and bumping and all instrumental, metal, whatever.

And now they've gone and released a new album like last week. So I just started listening to that. And I love it. It's great. You should check it out. It's all instrumental. It's great working music. And if you're a fan of Tool, the band Tool, then the bass player guest starred on one of the tracks, which was pretty cool.

Awesome. You should listen. Night version. It features Justin Timberlake. So that's, that's excellent. Yep. Yep. That's him playing bass.

It's great. Wait, what? It doesn't. You know what? I love how you just moved my letters around to make them line up with the line. He's a Justin Chancellor is the Justin Tim timberlake of the uh new metal world yeah i was just teasing but yeah of course i had to align okay so in what what what alan's

referring to for those that didn't that don't know in the background like we have our show notes you know in like this rundown format of what we're going to talk about and like there'll be somebody's initials next to a particular topic that we're going to discuss, you know, and it's not like we're reading necessarily verbatim. It's just like, you know,

here's the idea of what we're going to do. Right. And then that, that will become the input to the show notes that you eventually will see all pretty fine. And Alan, again, here put his initials on an empty line, this time in the wrong column.

I think this is payback for me not saying things the way we had been since year one. He's like, Mike's messing with my OCD. I'm going to mess up his CDO. Oh, man. Dude, my wife. So this is funny. There's not many things that get me like the show has gotten me because we're like 200 episodes and now we're gonna change it uh i walked into my bathroom the other night every drawer was open every door was open

and it's like everything i got to turn around and walk out of the bathroom like in me i want to go close all the drawers close all the doors like put everything i just but she actually looked at me she's like you're not gonna do it i was like no i'm going to bed wait did she leave them open on purpose to mess with you not not left them open open them all pulled them all out everywhere like all of them were open and i looked at it and i was like that's grounds for divorce right there that's i can't do this monster would do that i know man it was wrong it was wrong yeah i do the same stuff to my wife as uh she's much more organized me so nothing makes me happier than like misspelling something in a really dumb way on like the grocery list or whatever because i know like no matter how small it is like what you know whatever it is she's

gonna see it and it's going to drive her crazy. I'll frequently go to Publix and I'll see that she's scratched out and expelled it correctly. She just couldn't resist. If it had been me, I would have taken a picture of all of it. And then when she asked, why are you taking a picture? I'm like, well, this is exhibit A. This is exhibit B. Yeah, I need these, Your Honor.

That's amazing. That's all right. I'll go into her spice drawer and just move things around. She can't do it, right? Like, it's all alphabetized and all that, which is insane. So, yeah, all right. So, mine, I have a few. One of them popped up while we were doing the show because I went and searched,

and I don't guess I've shared this on the show. You mentioned the methods that are like 20 gazillion lines long, right? And, and there, you can't do a pull request on it because there's no context. You can't possibly squeeze all that into your brain. One of the things that I've found that I absolutely love, and IntelliJ specifically, and it's probably, my guess is, things like Visual Studio Code, probably all the other JetBrains tools, is you can actually view pull requests directly in the IDE. Now, the reason this is so good to me is if you go look at a pull request on GitHub, you know it shows you, I don't know, 20 lines on top and then 20 lines down below or whatever. And there's not enough context. And worse than that, unless you have one of the plugins set up in GitHub, it's right there with your project files and you can actually navigate to the other files by command clicking or control clicking, whatever your own windows,

Mac, whatever it is absolutely fantastic. And I find for me anyways, if I have not a tiny pull request to review with people, I can bring that down and I can more easily and more contextually show people, this is what I changed, right? And these are the files in the file system. And this is how it goes. Love it. Have a link to their, their page up there. And if I remember right off the top of my head, you can go up to get, go down to view and it'll have pull requests. And as long as you have it hooked up to, you know, that get area, then it'll show you all the pull requests and you can look at open ones you can look at them by author you can look at them by all kinds of tags so it's pretty excellent so only because uh you know of our our one true love here

get visual studio code can do the similar thing yeah i figured it could i haven't done it in there but that's awesome and also i wanted to point out like you were talking about the context in your pull request but you know or maybe you haven't like paid attention to it there's little up down arrows in the pull request so you can expand the context you can just keep clicking and eventually see the file yeah so so context here being limited to like that that file not necessarily like the project necessarily but even that file gets annoying right like i mean look if we all had files that were only 50 lines long that'd be amazing but usually they're not and and you keep hitting those arrows up and down and you're like man

really so but but it is good to have them there. So at any rate, love that, that if you haven't used it, it's one of the reasons why I do like get integration into some of the IDEs. I don't really use it to do much else with it, but it is nice to see those changes. All right. So one of our friends, John, he was on the show a long time ago. Was it 101? 100 and 101.

Okay. Yeah. So it's been a little while. He wrote us the other night and he's like, oh man, this is so cool. I downloaded the Lama AI model and did the same thing that you can do with chat GPT in the cloud. And I was like, I hadn't even considered it. Right? So if you didn't know, you can actually go download one of these large language models and run it locally, which is insane on even on a not so powerful computer. You can download these things and run them because they've already been pre-processed, right? So you can ask these things natural language questions and they'll work. So if you haven't heard of this, you can go to ai.meta.com slash Lama. And Lama 2 is their latest one. And one of the things that was interesting that John also pointed out was this is free for everybody to use.

You can use it personally. If you have a business you want to use it in, you can use it commercially. Like there are no limits. You can use it personally if you have a business you want to use it in you can use it commercially like there are no limits you can use it which is awesome it really kicks the llamas oh wait a minute i'll stop um so that was pretty cool well when i went to download this thing because i was like well now i need this because you know why wouldn't you want to be able to ask any question on the planet to this thing locally that led me to this thing that I'd never heard of. And I, and I'm going to feel silly cause I have a feeling that outlaws heard of

this. Have you ever heard of Anaconda guys? I have. Yes. Python. Yeah. Have you heard of it though? Yeah.

Well, I don't, I don't remember the deal though. Okay. It's been a long time so i used it but this was like the intro thing that you would use to get your data science environment up and running or your machine learning like tool base yeah running yeah i remember that with like the notebooks and stuff like anaconda seemed to be what they recommended yep okay so that is it and that'll

get your jupiter notebooks and all that stuff easy, but it's crazy the amount of stuff in this thing. So essentially they, they tout themselves as the way to get started with data science, ML or AI type stuff. And the reason is like, if you click on the download link that I'll have there, this is what they say. it has a free distribution install so it has installers for windows linux and mac which is that doesn't happen on anything which is pretty cool they have thousands of the most fundamental data science ai and ml packages um they manage environment so we've talked about sort of made fun of, Python virtual environments of the past. You know, I take it back. I take it back.

Make fun of it. Tell me about that again. This thing actually has its own virtual environment. So if you wanted to set up something that was running Python 3.8, you could have one environment over there. If you wanted to do something else that was totally dedicated to AI and whatever, you could have it set up another virtual environment over there. So this does it all for you. And when you download the thing, if you install it, it's tons and tons of tools. And it's got a really nice UI to be able to get you set up and running pretty quick. So very cool. But to take it even a step further, you don't want to install it on local, you got a Chromebook or something, you don't have that much room. You can also run this thing in the cloud which is super cool because when you do it in

the cloud they also give you five gigs of personal storage for free you're not paying for this you get a thousand daily seconds of compute i hate it that they said seconds because then i was like what does that mean it's about 16 minutes of high speed compute is what they say. And then you also have access to data science or yeah, data science courses, not, not, I don't know if they're all tons of free ones or what, but you have access to it. So if you're trying to learn, this is a great way to get your feet wet doing this kind of stuff. So, um, you know, go check all that stuff out. It's really fun. Yep. Okay. So for mine, um, this one is going to come from the world of, well, yeah, of course, Michael. Uh, so with that in mind, so for the rest of us that might not have been doing Java for the last 18 billion years, and especially if you come from a Visual Studio environment. So here's the thing.

In a Visual Studio kind of world, be it, I don't care if it goes way back to Visual C, C++ rather, or C sharp, I don't care, whatever. The point is, is that since the beginning of time, there's been this concept of when you do a build, it would only build the things that changed, right? And it's always bugged me that my Maven project in IntelliJ, and I'll go over there to lifecycle and double-click compile, and it's like, oh, well, let me start over from the earlier this week and one of the presenters there from gradle talked about uh cash build cash extensions and he specifically mentioned one for for gradle and maven but um sadly i only remember the one from Maven. But point is, is that both of them have this thing that you could super easily add to your palm file and then boom, you immediately got this build cache to where now your Maven builds act like Visual Studio does out of the box and only recompile the things that have changed or whatever tree you know causes

changes and not necessarily the entire thing over and over and over every time and so i know that like for those java developers are like come on michael that's stupid this one isn't for you just you know this is this is for the person who's just starting out in their Java development. And they're like, God, why does it take so long every time? Here you go. And add this. See, we're in the Java world. I have a feeling it's not going to be like, you know, you're stupid.

Why didn't you already know about this? It's going to be like, why aren't you using Gradle? That's the attack you're going to get. Yeah, yeah, you're not wrong there. And I really, if I remembered the Gradle cradle one i would include the link to it but um i didn't so i didn't want to like go in my haste trying to find it um because i was really trying to think back to like the the talk itself to see if i could find it but i came up short so i didn't i didn't want to like give one that I didn't know

to be correct. And then somebody say, you mispronounced it. Not that that would ever happen live. Not here, for sure. We don't do that. So yeah, that's the show. I was going to say,

if you're really talking with a group of job developers, they'll be like, why aren't you using Gradle? And you say, well, I tried Gradle. And they're like, oh, no, you've got to use Zable. It's like Gradle, but they fixed that problem. And someone else says, yeah, but no, really, there's actually two tools that replace that one. There's OpenZadal, and then there's Zadal 2,

which is just a fork of OpenZadal because the guy left. Anyway, it doesn't matter. You should use that. And you say, well, I looked at that but there were some problems. Some things couldn't get to work. Someone says, wait, why aren't you just using Maven? No, you go to

Zadal Enterprise. It actually has additional capabilities. And then the next version will be Zadal Boot. So yeah, it's all going to happen. And the cycle continues. Yeah. So, that's the show.

Be in. Bye. Go to our Slack channel. Just go to CodyBlox.net slash Slack. Do it. Do it now. Yeah, I don't know. What else?

That's fine. That's fine. That's good. We got links on top of the page for other stuff. We it. Do it now. Yeah, I don't know. What else? It's fine. It's fine. We got links on top of the page for other stuff. We do. Yeah. Yeah. Alright.