Coding Blocks - Minimum Viable Continuous Delivery

Episode Date: February 28, 2022

We dive into what it takes to adhere to minimum viable continuous delivery while Michael isn't going to quit his day job, Allen catches the earworm, and Joe is experiencing full-on Stockholm syndrome.

You're listening to Coding Blocks, episode 179. Subscribe to us on iTunes, Spotify, Stitcher, you know, all those wonderful places where you can find podcasts. I hope we're there. And if we're not, let Alan know. I don't even know where to go with that. Do you like how I threw you under the bus? Yeah, I gave you work to do already.

That's right. I'm done. Visit us at codingblocks.net where you can find all our show notes, examples, discussions, and much more. And send your feedback, questions, and rants to comments at codingblocks.net. And we got all the tweets you're ever going to need over on Twitter at codingblocks. We also have a bunch of links at the top of our page on codingblocks.net. With that, I'm Joe Zack. Oh, and I'm late.

I'm Michael Outlaw. And I am under the bus, Alan Underwood. Alan under the bus? Alan under the bus would, yes. There we go. This episode is sponsored by Shortcut, formerly known as Clubhouse. You shouldn't have to project manage

your project management all right and today we're gonna be talking about a minimum viable continuous delivery platform but first a little bit of news all right so uh outlaw you typically read off reviews you want to do that yep um this one is uh you know how I am with proper nouns. It's always a problem. So NADA. That's how I would say that. Did I not get it right?

Yeah, yeah. We got nada. We got nada. Mami's. We already shared that out. So if you don't know what we're talking about uh so yeah we didn't get any reviews sad faces um hopefully hopefully we'll get one this next go around one yeah you know more than one would be fantastic but it won't be great i feel like we need a truckload

that's right make up for it all right, so I actually hit these guys up earlier today because I was frustrated. And so I wanted to bring this up because we all three had different takes on this and I thought it was great. So here's what happened. And I think we might've talked about this in the past, but whatever, we'll talk about it again. So I had a class that, that I was working in and more or less what I wanted to do was have like an internal cache in this class, which means that I had a method that was creating these keys for the cache, but that's a private method, right? Like it was, it was doing something internal to the class that nothing else knows about, right? Like you're going to call something that says, Hey, get me this object from,

from that class. And it might pull it from the cache or it might pull it from a service. It might pull it from a database. It doesn't matter. But the thing is this whole thing that was creating these keys was private. And I was like, how do I test the, the, the key generation on this thing without making this member function public? And, and this is where i'll turn it over to you guys to share your thoughts on it um and then and then i'll i'll share what what i think my thought was that i don't know that i'm gonna do but but whatever so josiah yours was more comical i think so you want to share what your thought was yeah so my argument is that uh privacy is dead it's been dead for a long time i just can't care that much anymore about uh access and the reason i say that is

because if i'm publishing uh you know like uh my api is basically a you know third-party jar library or something then i'm not giving you my class anyway i've got some sort of interface that defines the contract and i'm not relying on this protected internal package, whatever. I'm not relying on that to protect anything. So all you're really doing is sending a message to your coworkers, which is important, but not important enough to not test it. And so I would say either break it out to its own class and test it there, in which case it's going to be public. Basically, you could do that whole internal trick. So like some, you know, like C sharp can let you mark things as like internally testable.

I don't think it's worth it because as one of your coworkers and a hypothetical situation, if I find a private method, it does exactly what I need. And I need to use that somewhere else, guess what? I'm instantly going to turn that thing public and do what I need to do because now it's a shared behavior. And so what's the problem? So my idea here is basically just set the thing to public and, code terms, because what you just said is essentially anytime you're going to use that class, instead of providing the user of that class, the actual class, you're going to provide it the interface, right? So let's say it's a car, right? You're going to have an I car interface, and then you're going to have your Mustang class. Nowhere is anybody going to be using that Mustang class directly.

You're saying they're going to be using it through that I car interface. And so it doesn't matter if anything's public in that Mustang class at all, because the only thing people are going to know about are the public members that were defined in that interface, right? Yeah. I'm going to use those as gates. And I think those serve as better gates.

Like it, it makes more sense to return an interface anyway. And it's this nice way of like very explicitly saying, this is what you get back from my library. And I don't have to worry about you tripping on some methods that I, you know, coincidentally made public or private. And also, I'd argue, too, like, what is privacy for? Like, you know, I feel like you could make things, you know, we've talked about like code being coincidentally the same. And so it can be wrong sometimes to abstract something and share code between two different features that are coincidentally doing the same thing because eventually they diverge. And then you're like trying to kind of make this abstraction work. I think things can be

coincidentally public or coincidentally private as well, where you just kind of either do it by default or you make something private because you don't have a use for it yet and i i'd argue that that's not a great use of something being private because just because you don't use it today doesn't mean that it shouldn't ever be used and so you know well i mean don't get me wrong i still like make my methods private by default it's just that i don't really put a lot of stock in seeing that so if i see another developer's code and they've got a private method that to me isn't a promise or a warning that I shouldn't ever use that method. It's saying no one else is using it right now. I prevented the leakage, but it doesn't mean that I can't change that code to take advantage of it.

That's an interesting take. Like my, my gut reaction to that is that it seems crazy talk, but, but I think the only reason is, is typically when I make things private, they're doing like grunge work for the other stuff, right? Like, and so they're, they're supposed to be doing the things that nobody should care about.

And that's why I typically make them private. So it's weird. Like I, I see your point to a certain degree, right? Like, Hey, who cares?

Um, well, who cares? Um, well, one more, one last argument. If you're, if your argument is that you shouldn't have to change your code to make it more testable, then good luck testing anything because that's totally,

that's the problem. All you do. Yeah. I mean, what you said makes sense, right? Like, let's say that,

um, you know, you had a Mustang class, like we said, and so maybe you want to create a, um, uh, a method call, you know, let me hear the beautiful exhaust note, right? That interface isn't going to have that thing, but you could totally test it in a unit test if you made that thing public. And so you did completely get around the problem. So it makes sense. And maybe,

maybe, maybe that's fine. I don't know. I've never thought about it from that perspective. When you said it, I was like, wow, that's okay.

And I can't think of any great arguments for it or against it. What about, all right. So outlaw, you had, you had another take on this. Yeah. Um,

so first of all, I want to say that like when alan posed this question to us like the the background of the caching and all that was not at all told to us it was like i have a private method that i want to test how i tested it because like as you were describing the use case i was like whoa wait a minute like why are we whoa like that should be in something else that would be testable and not inside of this thing that, and then like, who cares? Cause it's inside of this other thing that you would test. And like, you know, maybe it's doing too much or whatever, like a whole slew of other questions like popped into my head. But, uh, then as, as Jay-Z was saying his,

his take on this, it made me think of, um,worker had told me about this architectural pattern I'd never heard of until he mentioned it. But it's, I guess, popular in video game development. And it's called the entity component system. And it's basically a principle that – well, it's basically a type of pattern that, you know, largely just favors composition over inheritance. And so you're passing around interfaces. So like, you know, if all you needed to know about the car in, in Alan's example was that, does it have doors? Then you get a door interface that like describes like, Hey, here's how you unlock this door. Uh, does the door, you know, fold up and down, like, you know, or like scissor, like a Lamborghini, or does it, uh, you know, open like normal, or is it a suicide doors,

like on a Lincoln, uh, Lincoln continental, you know, like, um, or, you know, that same car, you know, that same data structure that is the car might also have another interface that's like the engine. And, you know, the engine interface might return back like, oh, here's how you can like listen to what this thing sounds like. So there's your car note thing. So like basically the idea being behind that, though, is that like one data structure, but it's like a slew of interfaces behind it.

And depending on the need, you know, something else is going to slew of interfaces behind it. And, you know, depending on the need, you know, something else is going to see that in a different way. So that's kind of what Jay-Z's response kind of reminded me of, although technically it's more about, you know, I believe that system is more about the data than it is like methods on the data, but same idea of like, you know, favoring composition over inheritance type of thing. So when Alan first hit us up though, with this, this question and there was no like, you know, context of, of the specific use case, it was just like, Hey, I have a private method. How do I test it? My go-to was like, well, if you truly,

and I'm positive we've talked about this before. I think we have. But if you truly wanted to test it, well, A, there's a strong argument to be made that like, you know, why do you want to test private methods, right? Because like you shouldn't care how your thing got there. Like you test the public stuff and the mechanics of how it got there, you shouldn't have to care about. And if you do, maybe the class is doing too much and that's something that should be broken apart.

And then you could test that thing in another class that is open. Right. But if you do find yourself in this situation, then where, you know, you wanted to, then that it was a hack, total hacky way of doing it. And, you know, you know, you wanted to, then the, I, that, that it was a hack, total hacky way of doing it. And, uh, you know, you know, total gross. So don't judge me for, for what I'm about to say. But the idea was you could make a, you could make the method, uh, protected instead of private so that only it, and like anything that you inherit from it can, can use it. And then you could create a mock class that is internal to the test library. So like in a C sharp language, you know, the, the class signature would be

internal. And then inside of that mock, you can have a public method that calls the, uh, protected one for you. And so I showed Alan an example that I don't know who authored it, but whoever came up with this idea, uh, I, I showed Alan an example where, um, you know, the, the actual method name was like call protected method and then underscore and then, and then whatever the real name was, because like in, uh, you know, test code, I tend to be verbose, you know, with not, Oh shoot. Did I give it away? I didn't write, I, I wasn't the author of this example. Uh, but yeah, so I tend to be verbose in my method name. So like, I don't mind spelling out like, Hey, I'm specifically calling a protected method. Um, and here's that method name.

And then that way I can test the kind of mechanics of it, but it's super dirty. And I, and more often than not, like, uh, it's only in a situation where like, I find that I really super duper, duper, duper want to test that mechanic internally because there might be a whole chain of events happening, uh, you know, in, inside of that class that I'm like, okay, I just want to know, like, I just want to verify that this one thing is doing what I think it should be doing. Maybe I ran into a bug and that's why I wanted to like write that test, you know? Um, cause like I said, I, I definitely try to start out without doing that. And, and definitely, you know, it's not a habit to, to write those tests.

It's super loose. So I'll give a little bit more insight into what I was doing just to help people follow along here. So really what I wanted to do was create an integration test more than a unit test, because I needed to find out how to get a version of something from an object I was getting back from a cloud call. And I was like, man, I, so I need to create a cache key. And so let me back up a little bit here too. So what outlaw described the first go around where you break out multiple interfaces. I think that's ultimately where I would land if I wanted to do this quote unquote, right. Is so I have my thing interface, right? Like that's, that's what my thing is get thing and, you know, create thing and delete thing. That's my main interface. But then I was thinking, well, maybe I create like a thing,

a thing cache interface, right? And that thing will have methods like create key, get key from thing, whatever, right. Something along those lines. And if you did have methods like create key, get key from thing, whatever. Right. Something along those lines. And if you did that, then maybe you only ever use it once. But at least then you'd have that contract that says, hey, there's this thing that creates a thing key. And so you'd know how to get it. And then I could test it that way. But again, this was very much an internal thing that's like,, Hey, if, if I just, if I had my own object that I was just creating, I'd know how to get the cash key, but because I'm getting something from a cloud service, I didn't know how to get the version off of it properly. And I wanted to

guarantee that I created those keys properly. So it really needed to be an integration test. So at any rate, I think, I think the way that I would go about doing it, even though I'm sort of buying into Jay-Z's mode of like, I just make it public, who cares? Um, you know, I have a contract, nothing else is going to know about it unless it walks, walks it with reflection, right? Like that's really the only way you could get around it. Um, unless somebody can use it up directly or if somebody news it up directly, directly. Um, but I, I kind of like the idea of going, it's almost like the Microsoft way in my mind. Like it, you know, you've seen like a list in Microsoft. If you look at it, that thing's like I iterable, I blah, blah, I blah, blah, blah. Like there's so many things that hang off of that

and it's purposeful right like each one of them defines a little bit of what that thing can do so i don't know i thought it was interesting that we all had three different perspectives on this and so i kind of wanted to share it and let you know like we've all been doing this a long time and we all still came up with different ways that we would probably go to on this so um oh i will say, knowing more about the problem now, I think assuming you're using something like Spring or something with dependency injection, I would have a service that generates the key.

And then for unit tests or whatever, you can plug in your own basically, but you don't care about that. You're doing integration tests. So integration tests, you would give it to the key provider, have it do the actual work. And then those integration tests aren't going to work a month from now but you know who cares it got you past the hump and if you ever need to work on it

again you can kind of you know meddle with them again and get them working and do your thing so it's funny you mentioned spring because one of the reasons i wanted to do an integration test and you've seen this right like when you have a spring app like getting the thing running like if you're doing a bunch of work you're creating a bunch of new classes services factories whatever right like that thing's not going to run when you go to run it because yeah there's so much stuff that you've added that there's no way you've hooked it all up properly and i couldn't see the information that i needed to see to finish writing the class that i needed to do i was like okay i'm going to do an integration

test right like i'm going to hook this thing up to the real service, get the stuff. And then that way I can get it back, finish writing my class so that when I do go to hook it all up in spring magically creates 5 million classes for me behind the scenes or, or, um, instances, I'll be good to go. So yeah, it's a, it's an interesting problem when you're working on on um a lot of dependency injection stuff so well i got another question for you before we get into the main topic here um that was asked in the came up in our slack community all right um ben ben craig asked um why can't you give Elsa a balloon? These are the questions that matter.

She'll let it go. Because she'll only let it go. I win. Thank you, Ben. That's good. That's real good. Wonderful. So we do a show here?

I think so. I mean, that was so i think so i mean that was good content yeah but that was good content right there i mean we could probably call it quits you guys just want to wrap up and do the next one later all right well we head into alan's favorite portion of the show that's right all right so jay-z you want to lead us off here uh yeah sure so uh i mean actually this was uh outlaw's topic um this is your idea so this is all your fault so why don't you tell us what got you interested in this well i mean this was like along the ideas of we've talked about like the 12 factor app and the 11 factor app and the twin factor app and then the seven factor app no i'm just kidding seven seven

factor but but there is this uh this new thing that like a common friend of ours shared about the minimum viable cd and i thought oh that sounds like a you know neat kind of topic along that same kind of like line of the the 12 factor app like let's you know discuss that briefly so that that's what this is hey and for what it's worth this is sort of near and dear to my heart only because over time, like I remember back in the day when, you know, CD and CI and none of that didn't exist. Right. Like for, for me as a developer, like we just built stuff and throw it out in production and, and, you know, hope it worked right. Package that up, you know, put it out there. And after you get a taste of it, like you realize what you're missing.

But then what's frustrating is if you get thrown into one, that's not great. Now you're frustrated because it's sort of doing things for you, but it's also holding you back. And so like this, this whole topic is, is really, it's near and dear to my heart. And having been through all the stages of with, without, with not great and all that, you know. Yeah. So that kind of idea behind it is it's basically this is kind of a stripped down minimal version of a continuous deployment pipeline. So that if you were starting a new product today and you want to know, OK, what should I do to kind of get started? If I don't really have any strong opinions or strong reasons to kind of

deviate from a standard plan. Like what's vanilla here? And that's what we're talking about today. Yeah. I want to make it clear too that like CD in this case, you know, for those new to it, we're referring to continuous delivery. Which is deployments, right? If you wanted to make it. I don't want to call it deployment necessarily, but there is. Okay. Delivery. Well, no, I guess the reason why he's saying that is because it's creating things that can be deployed, right? Like artifacts and whatnot.

I assume that's where you're going with that. Well, I mean, there's definitely a slant to this, but I wanted to hold that for later. Okay. We'll hold it. All right. There's definitely a slant to this that I, but I wanted to hold that for later. Okay. We'll hold it. All right. So I guess to sort of hit at what they're going for and what they were talking about for this minimal minimum viable is the outcome they're looking for is improved speed, quality and safety of the deployment pipeline.

And, and they had a nice little quote here that for what their continuous delivery definition is really, and it's the engineering discipline of delivering all changes in a standard way safely. And I really like that personally. Like I don't know that I've ever seen it put so well. Who is this we anyway? Oh, yeah. They have a whole bunch of people up on their site did you guys click that you mean the signatories of it yeah yeah yeah well you can

you can become a signatory all you gotta do is submit a pull request and they'll consider it okay yeah so the deal is uh it's kind of like the agile manifesto where a bunch of people got together and said like hey you know what is this thing that we're all talking about like how should we do this and let's come up with a you, what is this thing that we're all talking about? How should we do this? Let's come up with a couple of basic things that we think are going to make this thing work. And so a couple of people got together and basically signed their names, and here we are.

And so it's not like a company. This isn't minimumbuyablecd.com. Oh, actually it is. But it's not a company. Dot org, okay. This isn't Microsoft. This is just a bunch of people that got together and it's a consortium that got this stuff started.

And so when they say they, it's whoever wrote that page. And these people all kind of agreed to it and signed their name to it. So that's who they is. This started at a conference, a DevOps conference, where they broke off into a room and started trying to solve the problem. I wanted to be clear, too, that the website where you can find this is minimumcd.org.

And we're going to have links in the show notes to all of this. But for those listening along that don't want to go to the show notes just now, but you're like, what are they talking about? That's what we're talking about. Yep. And so they had a list of, and we'll, we'll sort of quickly go through these because we'll talk about a little bit more in depth, but what they consider their minimum requirements for their minimum, minimum viable CD, right? And so the first one is the application pipeline is the

only way to deploy to an environment. And, and instead of putting a long definition of what the application pipeline is there, they actually had a link to an article and I've shared that here, but more or less, it's the thing that sort of automatically does what you would do if people were manually doing it, which is building, um, building the application, merging stuff, building the artifacts, publishing them somewhere, making sure they're running there, like all that stuff. Right. And that's what they called the application pipeline. So now there's a, there's a whole article around it, but definitely can go check it out. It'll be in our links. Um, so that's number one. So, and I thought that was

interesting. I I'm assuming you guys did too, right? Like you can't build this thing except through this. I do have one thing that bugs me about that. We all like to deploy or to develop locally. And I know when you're dealing with things like secrets, it is hyper frustrating if you can't run things locally that have access to environments like what a deployed thing would do. What's the answer there? Have automated tests on an integration environment, I think is the right answer here. So you want to have some sort of staging environment.

And, you know, the application pipeline doesn't have to not have a staging. You just want to make sure it's all automated. So you would run some integration tests there. Yeah, but weren't you asking about like how would you develop locally? Yeah, local development. You start up your application and it needs access to Azure storage, blob storage or whatever, and your deployed app will have that because it picks up the secrets

and deploys, bundles it with the thing when it launches it because it's an environmental thing. How do you get that locally? Okay. This is where somebody is going to come back with the textbook answer of, well, you would have a different interface for your local development versus your integration development and, you know, or your integrated, you know, your deployed environment. And you're not – that code, you'll get tested when it's deployed, but you have this other set of code that's tested when you're writing code locally and blah, blah, blah. I call hot garbage on that.

Yeah. I mean, that's why I worded it the way I did. Like somebody's going to come out with that answer, but – That's what I was going to do. Oh, go ahead. That's what you were gonna do i was literally gonna say that because i am so tired of like say well i want to change the color of a div on an html page oh but i need the database and i need my middle tier and now i need some you know

some cloud storage stuff and now i need some other thing it's like oh my gosh i just wanted to make some simple ui change and now it's taking me an hour just to get my environment set up. Why the heck Angular, React, all these things have – these frameworks have really easy ways to kind of mock data and be able to work locally. Why don't I take advantage of that? Here's the thing. Hold up, though. I think – so I agree with you, but I think we're talking about two different things. Yes. So right there, what you're saying is, why do I have to spin up the world just to work on my UI?

Completely agree with that. You should have a mock API that you can use so that you can work on your API. What I'm talking about is when you're actually working on that backend piece that is talking and writing objects to Azure blob storage or Google storage or, or AWS S3, whatever. How do you, how do you do that locally? When the only thing that has the rights to these environments in the way that you're going to deploy it, by the way, because there's a difference between running with your local credentials, talking to a cloud service versus using some service accounts credentials that they don't want people to have. Like, and that's, that's where I'm talking about. I totally agree with what you're saying.

API is a mock API should be used there. But when you actually need something to work the same way locally, that it's going to work in a deployed environment, how do you do that? If the only thing that can get it to you is the application pipeline based off what they're saying. Here's a hard truth is Working on the cloud sucks. It's going to cost you a lot of money. You're going to constantly be doing

these weird hacky things in order to try and make your local prod sometimes and make it very much not like prod other times. I don't know any other way to deal with it other than just changing your crap around all the time. Well, if we're, if we're talking about,

if we're talking about a cloud development then, and, and we're talking about specifically like maybe Kubernetes specific development, the Kubernetes best practices book would tell you that each developer should be able to have their own environment. And they, they go into deep,

they go that, that book, um, I'll, I'll provide a into deep, they go that, that book, um, and I'll, I'll provide a link to it, but the, that book, they go into detail about different patterns and ways that you can, uh, each developer could have their own environment to where, you know, if you know, it wouldn't be a problem because you would have your own, uh, deployed secret server or whatever it is that you're trying to deal with it. You know,

even locally, if you wanted to change a, a URL or IP address or port to point to something that is in your deployed Kubernetes environment that you could, because they, in that book, they didn't even talk about using something like a scaffold to do it locally. Yeah.

That's interesting what you said, because I was not speaking about Kubernetes specifically, but that too is also something that a company has got to be on what Joe said, right? That stuff gets expensive quick. You got a bunch of projects spun up for each developer and they're all, you know, running resources or whatever,

you know, but maybe it saves you a lot of money in developer time, right? Possibly. Yeah. And trying to run stuff locally to get, it gets big, you know, you're trying to work on a website and now you're installing, you know, two different data.

We did a survey, right? Like two different databases, at least one middle tier, you know, some services and yeah, it just, it's the unwieldy. It's hard to work on and have your ids open too it's a tough problem it's frustrating and the the other thing that we've talked about too that that can get really frustrating is a lot of times you end up with with some sort of hacky thing to so that you can work locally right like so instead of using s3 storage or, or, um, you know, Azure blob storage or whatever, there are some tools for, for faking that locally, but let's assume that there's not,

then people might do something like go to a men IO, uh, men.io type of blob storage, but now you're not actually using the same thing that you're going to be using in another environment. And that's, so it's like you're testing and your stuff's working here, but maybe your calls aren't exactly the same when they get deployed out. So it's a frustrating thing. So while I agree that this application pipeline is the only thing that should be able to deploy to an environment,

I hate it that local development environments are really not included in, in a lot of these things. Like it is sometimes it's really hard to set up that stuff in a way that makes sense anyways. Yeah. I wanted to call it to that, that they're linked to the definition for that application pipeline. And it's actually comes from a book called a continuous delivery,

reliable software releases through build test deployment and automation. So, and automation. So. All right. I'll include a link to, I just pulled up the book because this was the book I was talking about, by the way. It's an O'Reilly book, Kubernetes Best Practices. So we'll have a link to it. But if you have the ACM subscription, because this is a O'Reilly book. You can read it that way.

Excellent. Nice. So like we mentioned, the application pipeline needs to be the authority. So if the, here's a direct quote, if the pipeline says everything looks good and that should be enough, it forces the focus to stay on what reasonable means.

And that's from Dave Farley. Yeah. So that is, but it's a good quote. Yeah, the bullet point that you skipped over there, though, is the pipeline decides if the work is releasable, which is interesting. Not a manager, not the QA team, the pipeline. And if your pipeline can't make the decision because it's not good enough, well, it your pipeline is not good enough yeah isn't that crazy yeah it makes sense that's hard though i mean this to say that's a minimum viable is like oh okay that's uh that's the that's the biggest stumbling block that i saw here that's that's a tough order take some time well i mean it goes back to like just having uh you know you know, automated tests at every level.

And then that way the system can decide like, okay, you've passed all the tests, uh, the test gates where like, and at every level, what I mean is if you go back to our DevOps handbook and, the Phoenix project,

unicorn project, like that, that series of books, right. There's, um, you know, tests get slower and slower over time, uh,

depending on like what level it was. Right. So your unit tests are like super fast. And then you would get into like integration tests and, uh, end to end tests and user acceptance tests and whatnot. And so like, you know, if you've thought of it as a pyramid where like the bottom of that pyramid are all the unit tests, they're like lightweight. They have no external dependencies, um, highly reproducible, you know, results. And then, you know, integration tests that might depend on something like, so now you had to slow down because you had to like deploy an environment before you could even use it. You had to have a database up and running and things like that, or a web server or something that could respond to, uh, to a call. Um, you know, like each level would get a little bit slower as it would go through it. But, uh, you know, if you live in this utopia where you have

that and you could rely on that as your, your, your gates, then, you know, you get to a point where you're like, okay, it passed, everything passed. And like now let's kick off an automated deployment. Yeah, just, you know, it's literally I just don't like the idea that and I mean, I get it, but just we're saying like this is the minimum viable CD. If you are starting on a continuous delivery project at work, the first thing you got to do is set up an application pipeline that you can absolutely trust to do production deployments. It's like, well, that's going to take a few years well it's something that i mean and that's why i refer to it as the utopia because in my mind like so to your point this does not happen overnight this is no this is a long slow process that you and the team have to be committed to evolving towards and it starts with okay how about if we agree on like this is how we're going to do our our continuous integration so let's agree on like what the what the merge strategy and like what

that's going to look like in terms of like get, you know, how we're going to branch and things like that. Then you build on top of that to say like, okay, let's have some, let's figure out like how can we script a, make a repeatable build process. Okay, now we've done that. Hey, I wonder if I can like make that part of a PR gate, you know, so that now I can like verify that the thing even builds before you're allowed to merge in. Okay. I got that. What if I like write some tests too? And like, okay, I got some tests now. Can I like automate the, the execution of those tests as part of another PR gate? And you just keep going and going and going until like, you know, uh, you, I haven't been in this environment that, that I speak of, but I, I totally want to be in this yike utopia where you do have like, you know, new environments that are spun up automatically as part of a test. And like,

you know, it runs through a series of integration tests. It runs through a series of end to end tests, you know, and then decides, okay, all of that's done. Let's deploy to production automatically because I just like that.

Everything passed because no humans doesn't, they're not there. Yeah. Cause cause smaller, the smaller you can make the change that makes us wait to production, the easier it is to debug that, that issue. So like, that sounds like an amazing dream. I want to live there. I'm not going to let Jay-Z take me down.

Well, here's the thing, though. This project is framed literally as the minimum viable CD. And the first argument, the very, like, thesis of this whole thing is the belief that you must put a certain core set of principles in order to reap the benefits of continuous delivery. So, we're saying these are the things that you need to reap the benefits. And one of the first ones is utopia. Yeah.

Right. Like that's, it's a tough sell. So I don't know. I just kind of, but in fairness though, if you set those things up ahead of time, like,

you know, it's like outlaw just said, he just rattled off three or four things that, that you'd want in place already. If you knew that when you're setting this thing up, then it's like outlaw just said, he just rattled off three or four things that, that you'd want in place already. If you knew that when you're setting this thing up, then it's not as terrible. We don't have a bunch of things already there to break it. Right.

So, you know, it's not, it's not fair. It's like in order to get to, uh, reap the benefits of continuous delivery. First,

you have to start a new project. Otherwise you're never going to get there. It's like, well, wait a second. Well, I mean, we, we've definitely been in these in like, okay, so you, you joke, right. project because otherwise you're never going to get there it's like well wait a second well i mean we we've definitely been in these in like okay so you you joke right and talk about small projects

but we've absolutely been in those environments where like netlify we've talked about countless times right that is an example that is that meets this objective like you can extremely easily set up you know netlify to like point to your git repo and it'll automatically deploy it and then you and so you could come at it backwards like you have the automatic deployment to netlify but you might not have any tests just like as soon as it commits made to your your GitHub repo, Netlify is like, oh, new code, I guess. I assume it works. And then you could start putting some gates onto whatever the branch is that you're serving from. In this case, they advocate for it being called trunk.

You could then put in a gate that says, okay, hey, you can't, you can't just manually, uh, commit or merge to this. It has to go through a PR. Okay. Now that I have that one on there, Oh, the PR also has to perform a build that succeeds. That's important. And then you add on like, Oh yeah, now we do some tests, but, but we can all agree what Jay-Z said. There was a lot of truth in it, right? Oh, absolutely. If you file new project, it's a totally different ball game than if you're but but we can all agree what jay-z said there was a lot of truth in it right oh absolutely if you file new project it's a totally different ball game than if you're trying to wrap this thing around some existing monstrosity that's been there it's got 20 heads right so um legacy code is impossible and it's hard it really it really does like there was another argument i

forget where um where dang where did I see this? Where they were talking about it's almost, you're going to rewrite it soon anyways. They were kind of making the argument, why put a lot of effort into it? You're going to rewrite it anyways eventually. So just focus on the other parts of the good stuff, and eventually that old legacy thing is going to die, which I don't know that I agree with, but now that I can't even remember, uh, where I read it, you're like, who's the, they in that Michael, is that you, are you the, they, yeah, it doesn't even matter. All right. So, so the next one up that we have here is the artifacts created by the pipeline

must meet the organization's requirement for being deployable. And, and really all that meant was the organization has to have a list of what are the non-negotiable things that have to be there, right? It might be security. Like you might have to have had our back stuff in everywhere, right? Or it might be that, you know, hopefully there's no errors in it, but for whatever the thing is, they have a list of requirements and that determines whether or not this thing is releasable. Yep. I mean,

this goes back to Jay-Z's like list of hard things. Oh, totally. Because one of the ones that they gave would be like responsiveness. So now it's like, Oh, okay. So you actually have a mature enough automated deployment system to where

you're measuring the responsiveness of the page and that you can automatically tell like, oh, okay, so you actually have a mature enough automated deployment system to where you're measuring the responsiveness of the page and that you can automatically tell like, oh, hey, Michael's new commit has decreased the responsiveness of the page. So we're going to fail that deployment or fail that build. It can't make its way out into production. That's a pretty mature pipeline. Yeah. I mean, I don't think this stuff happens overnight, right? Like people build on this as time goes on. But it's all great guidance, too.

It's all good stuff. It's just the name minimum viable CD kind of missells it, in my opinion. Yeah, it kind of does a little bit. That Dave Farley guy, by the way. So this particular one that on that last bullet point about the definition, there was a link to a YouTube video for a financial tech company that actually has a deployment pipeline that they stepped through all the things. And so I want to say it's like an 18 minute video, something like that. So it's probably worth checking out just to see. And in my opinion, this is one of the ones that are done

pretty well where they draw on boards in front of them. So it's not super boring opinion this is one of the ones that are done pretty well where they draw on boards in front of them so it's not super boring this is one of those few times where like if your boss caught you watching youtube you'd be like no this is for work stuff promise good totally good yeah yeah yeah yeah yeah now jim uh jim hummel's on design painter evangelist on uh on uh psychosynos the sky a few times so i've watched a few videos it's good stuff yeah he's good um all right so the next one we have oh i like this one too this one i actually really love and it's not that hard uh the artifacts they should be considered immutable meaning after the pipeline built them nobody can touch them doesn't matter what for you just if anything touches it, it's invalid. Throw it away. Yeah, and that's not hard to accomplish necessarily. If you have an Artifactory or something like that.

But there is a thing about, well, I guess even with Artifactory, though, you could fake it. Because if you didn't up the version number and you just like constantly rewrote to the same destination same path is like here's my application dll dot you know version 1.0.0 right or whatever if you had the creds to push them out there yeah you could totally fake it but but you shouldn't have access to it doesn't have to be you though is my point like even if you had a a notmature build pipeline, and only your build pipeline could push to Artifactory, for example, and you weren't including any kind of build version number,

or the version number was never getting incremented, and you were just constantly writing to the same spot, that would not meet this requirement. Good call. So this next one's interesting to me because this is a cultural thing, right? And this is where you're going to have to get buy-in from the entire company from the top down in order to make this happen.

All feature work stops. If the pipeline status is red, this is the end on court at Toyota. You guys seen this in practice? Uh, so I, uh, I've been to places where like if the build was broken,

nobody could merge. And so like nobody could, you couldn't like, you literally couldn't merge because the build was broken and it was miserable. But that's different than stop all feature work, right? Like this is basically like all hands on deck.

And even then like it made sense like it was frustrating when you're like you go to check something in like especially if you're working late or something you're like oh wait someone broke the build an hour ago and they left for the day and now i can't check my stuff in and i told my boss i'd be there tomorrow i need to get it to qa tomorrow so it means i'd get in tonight blah blah blah um so it's frustrating all yeah so it's kind of weird like the build's broken so everyone puts the keyboard down it's like a strange notion to me but i've heard it several times now to me the problem here is like well how did i mean the thing i didn't like about this one is it seems like then the pipeline is kind of immature if it lets something get into the pipeline that impacted

everybody else like that yeah i mean i'm sure there's a million edge cases that we can't think of off the top of our head, right? DB migrations. And think about how hard it is to test database migrations. Sure, it worked on the local machine because I didn't have an age-old database. Maybe it worked on an integration environment,

the PR gate, because that's a new environment spun up from scratch, but it didn't work on the staging environment because I actually tried to apply a migration on another environment and it didn't work. And so now the pipeline is down. Or what if your Jenkins server went full on space? Like there's so many different things that can happen here that are kind of hard to think about, but it is interesting because this implies that your continuous delivery pipeline is one of the most important things that you have going. And that might be true. Like if you've actually done this the way that they're saying here, it's what allows you to move quickly in your development world.

So I don't know. I kind of get it. But I also see a lot of managers being like, what are you doing not over there banging on the keyboard? I really think that the way it should be worded and this isn't going to be the wording for it, but something to this effect would be that it's not that everybody stops

their work. It's that everyone is available and will stop their work should I tap them to say, hey, because you brought up a Jenkins. That's a good example. If the build server, that might be a reason why the pipeline would go red, right? Because the build server itself is out. And so you might not have credentials to even get to the build server

at that level of detail or whatnot, or might not even know to diagnose that is the problem. But you can see, hey, there's something wrong with the build server. And then you could tap the person who is responsible for the build server or might have the the keys to the castle and know a bit more about it and say like hey can you help there's something problem and that person should be willing to say okay let me you know drop rather than like giving you like really come on you know kind of attitude about it. So, yeah, I think outlaw just became a signatory.

Let's put that PR in and, uh, you'll be up on the page here pretty soon. Yeah. I thought it was worded really well. That's, that's actually a good way to do it. Um, the next one is,

and this, this is kind of a no brainer. You must have a production like test environment. Everybody should have that. If you don't get one, those are real easy to do. It's super simple, right? It's easy.

Next one's easy. This is an example. That's an example of one that we're going to come back to. Put a pin in that one. Oh, man. The next one we have is must have rollback on demand capability. That's fun. It codes, no problem no problem right it's the persistent storage which is yes how do you that look on outlaw's face was absolutely amazing yeah this rollback thing right like if we're talking application code sure we're talking

about databases oh what man yeah data migration is so tough like it's such a tricky thing to get right and no one ever like problems happen it doesn't and rolling back is tough it doesn't even necessarily have to be like data any kind of persistent storage like it could be keys yeah totally like rolling back keys could be could be an issue you know which means to do these rollbacks that really means you have to have really good backup plans in place for everything and be able to push a button and flip all the way back on all of it.

That means stopping the whole system, right? Stopping everything. Hey, it could also mean losing data, which may not even be possible if you're talking, like we mentioned the financial tech industry earlier. If you're in a fintech, there's transactions that came through you ain't touching that stuff so i mean rollback is you know there might be some

transactions you're okay with tim like losing you're like okay i know it's fine i didn't mean to spend a million dollars yeah so yeah that one that one's hard like rollback is not an easy thing um i like this one application configuration is deployed with the artifacts. Now, what I liked about this one is they called out in an article or on their page or whatever, that they said that people use the word config so loosely across the industry. And I completely agree with this. It's actually really irritating. The config they're talking about is environmental configurations, right? Like if you have a connection set up for your database, then that config is going to be different in dev is going to be different in QA and in prod, right? That's what they're talking

about. Application config stuff that actually ships with the code is not included in this. It is only environmental stuff. And I actually liked that distinction. Well, can I, can I read the way they worded it? Because you may, I think it's summed it up pretty good because this is actually taken from wait for it, the 12 factor app. So they were saying that the word, the term was overused and under defined across the industry and that they embrace the 12 factor app definition where config is environment specific, i.e. it varies by deployment and application config is internal to the app and does

not vary by environment. Yeah. And I love that distinction because it's, it makes it clear. Yeah. So here they're talking about application config. Application config is deployed with the artifacts. Oh yes.

So that's the configuration does that does not, does not change, change from one environment to the next. Yes. If, if you're going to support, I don't know, let's say like,

uh, it won't be a good example. You're going to limit, you know, like, Hey, I can support, like, hey, I can support 500 requests per

app server before I need to create a new one. That's not going to change per environment. That's probably a horrible example. That was a bad example? Yeah, sorry. That's fine. I'm not going to quit my day job. Let's put it that way.

Creating examples is not a good thing. I have a node with one gig of memory in dev, but in prod, I got 50 gigs. So we kind of started with the end a little bit. This web play starts at the end a little bit talking about continuous delivery. So we're actually going to kind of make it a little bit more personal now and talk about continuous integration, which is kind of a smaller topic. It's a little bit easier to get your head around. And the first piece of advice I give is to use trunk-based development, which we're going to talk about.

That's kind of the last leg of this thing here. So just for now, we're going to just quickly say that it basically means all developers releasing, pull requesting and deploying, not deploying, integrating into a single branch, like a master or main kind of thing. And there is one other thing here that they advocate for. And I've read, we talked about DevOps Handbook and we've seen this a few times. So basically saying to integrate daily at a minimum in order to keep your integrations really small.

Yeah, this one, you can go back. I want to say it was like episode 90, maybe something like that. I'll find their exact episode. But we talked about the various Git workflows. And, you know, this trunk-based development, the minimum viable CD actually advocated for using trunk, if I remember right. Um, as the, the branch name.

Um, but, but basically this workflow is you have that one branch and you're always merging into that only ever merging into that branch. Um, so that's another one that I wanted to put a pin in. Yeah. I was going to say,

and we're going to come back to things. But the other thing that I will say is they say daily at a minimum. If you go back to our DevOps episodes that we did, like as frequently as possible is the best. Right. But if you can only do it once a day, fine. But but you do want to do it frequently. Oh, man, I'm so good. I nailed it.

Episode 90. That's ridiculous, dude. That man, I'm so good. I nailed it. Episode 90. That's ridiculous, dude. That's been 80 somewhat episodes ago. That's ridiculous. 160. Yeah. I'm a professional and,

uh, I would like you to respect that. That's insane, man. All right. It's impressive, but insane. All right. You got the next one, Jay-z what we have fun yeah uh so uh idea is that we're gonna have some sort of automated testing that runs before you

can merge to work and so this is kind of like a well what i say like a pr gate like a pull request gate where something has to run but you can do this uh also just for actual commits. Sometimes you'll see that in a few places. But GitHub has become such an authority here and just a common workflow. So I don't even know the last time I've seen something that forced a build integration test before you could actually just merge it or push your commits up to a branch. Wait, you're saying just because it was in github i mean github definitely has support for actions to where you could enforce that so how does that work then so like i'm working on trunk i commit locally and before i push what happens wait uh no you have to pr it yeah i was gonna say you have to push to your own

branch more or less up and get right yeah you push your branch and then you pr your branch into and you've got the pr gates yeah so that's the only way that i've ever like worked with this but uh later on in the next section uh on this website uh they actually advocate for having small teams working directly in trunk and committing directly to trunk. And so I was saying that it is possible for you to have like pre or post commit hooks in order to kind of block actions. But it's just weird. Yeah, I don't like that. Yeah, and it's up to, you know, it's client side at that point. Maybe I missed that part because I remember them talking about like small branches and you wouldn't delete, you wouldn't merge into a release branch.

You know what? It wasn't on this website. It's on the actual, there's a link off to trunkbaseddevelopment.com. Yeah, that's what I'm looking at. Yeah. And so down here. best done with short-lived feature branches one person over a couple of days maximum flow and flowing through pull request style code review and build automation before integrating and merging into trunk so uh very small teams may commit direct to the trunk where did i just see that

and there's uh they got a section here. Small teams will choose to commit straight to the trunk. Most likely it's because blah, blah goes on and relies on the build being fast and really exhaustive. And so, yeah, I mean, that's pretty nasty. I don't know if that's disregard that.

That's not true. Yeah. I think, I think the difference here though, is that like that would, that would, uh, go against minimum viable CDd and now you're like

off on some other website so i mean they link to it as their definition for trunk based development yeah but here's the thing right like this whole notion that small teams may do this there's no real overhead in creating a branch and pring into it. So don't ignore that. Don't be committing directly into trial. It doesn't make sense. Well, I mean, also there's supposed to be an argument.

Like what, what's a small team is a small team, like three to five people, because isn't that supposed to be like the average team size team, right? Yeah. Like anything larger than that's supposed to be too big, you know,

depending on like you get into different Scrum or Agile type organization, team organizations, and they'll tell you that you're getting too big if you were to go beyond that. Look, the real answer to this for anybody out there managing repos, don't allow people to commit directly to that branch. They should be...

Would you pull requests as a solo developer? Sure. And review it yourself and approve it and merge it? Okay. I mean, okay. Maybe not. Maybe not. But still, even as a solo dev, it's not that hard to create a branch and push the branch up and BR it in, right?

I mean, I get it. You're skipping maybe two steps, but you're saving yourself two minutes. It just doesn't – I don't know. I, I, at least once a day, here's the answer. Here's the answer to Jay-Z's question. If I'm going to solo dev, then no, I'm not going to create a branch and PR and all that kind of, well, I might create a branch just because it'd be, might be easy if I'm doing like a bunch of multi-development and I might want to like tap a context switch.

So maybe I would create a branch, but I'm probably not. I'm probably going to work directly off of whatever the trunk is and I'm not going to bother to PR in it. But that's because I hope, or at least the way I've done things is that I already have my tests where I'm running my tests. So any tests that I would have done in a bill as a build gate i'm doing manually myself so it's definitely not perfect and definitely goes against what they're advocating here yeah everybody does that yeah that's the way everybody does in solo death but once you get into like the end and teams you can trust everyone to always run the test that's right yeah no once you get into duo

dev though you should be doing these branches. I don't get this. Can we call it that? Does that mean you sing while you do your PRs? That might be good. Well, okay. I mean, you had to make it weird. I didn't call it a duet. Islands in the stream.

Okay, wait. That is what you want. Yes! The earworm worked. Oh my gosh. So as part of the these tests that run, the work

is also tested with any other work that's automatically brought in as part of that merge. So just make sure it's always up to date. And like we mentioned before, all feature work stops when the build is read and new work does not break already delivered work. Otherwise, it's not allowed, right? It's not allowed in the pipeline. So basically, this utopia is that there's never a regression. That's right. And if there is, everybody stops.

So, I mean, no, but going back to your thing from the beginning where you were saying like, hey, this is unattainable because you start with the C-topia definition, then this one is there, right? Like there can never be a regression or you are not a minimum viable CD environment, which we know there's never been code. never been a minimum. How are you going to get anywhere else? So, so here's the problem, right? There's never any code that's delivered. That's always been a hundred percent perfect on every delivery. So this, this is where I think this, this is where language is dangerous and incomplete, right? When they say does not all, does not break already delivered work what does that mean does that mean it failed in a build because of a unit test does that mean that it failed um launching in a deployment environment right like break is such a ambiguous term and in regards to what we're

talking about if the thing builds if it passes integrations passes the unit test and all that stuff sure you're going to deliver it but maybe you find a bug out later and you go, oh, we need to do a hot fix for that. Right. So I think that's the key. Right. If there's any automatic detection of a failure in this process, then you shut it down. Right. But there are going to be problems unless you are just the most amazing developer that's ever seen the face of this planet how you doing so right so so yeah i mean they need to you know i feel sorry i mean i

guess we could put in a pull request but yes break needs to be defined in terms of what can be detected automatically so then if i don't have any detection automatically then nothing is ever determined to be broken and i mean you just release it all and as a solo dev that's what you do all right yeah gotcha this episode is sponsored by shortcut have you ever really been happy with your project management tool most are either too simple for a growing engineering team to manage everything or too complex for anyone to want to use them without constant prodding. Shortcut is different though, because it's better. Shortcut is project management built specifically for software teams

and they're fast, intuitive, flexible, and powerful. Let's take a look at their highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them flexible, and powerful. Let's take a look at their highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them to match the way they work. Organization-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. It takes one click to move from a roadmap to a team's work to individual updates and vice versa.

Tight VCS integration. Whether you use GitHub, GitLab, or Bitbucket, Shortcut ties directly to them so you can update progress from the command line. Keyboard-friendly interface. The rest of Shortcut is just as keyboard-friendly with their power bar, allowing you to do virtually anything without touching your mouse. Iterations planning. Set weekly priorities and then let Shortcut run the schedule for you with accompanying burned down charts and other reporting.

So give it a try today at shortcut.com slash coding blocks. Again, that's shortcut.com slash coding blocks. Shortcut, because you shouldn't have to project manage your project management. All right. Hey there. This is my Joe Zach radio voice here. This is the voice that I use on the podcast, which I assume you're familiar with by right now.

Normally, when I'm just at home by myself, I just mostly just mumble. So tonight, you're getting podcast Joe asking for podcast reviews because we love them. We need them. We eat off of them. I don't know. They put the bread in my belly. I don't know what I'm saying. This is why Outlaw is just over there saying, why?

Stop. Stop. Just say that. Just ask for a review. And I'm just here. I'm just not doing it. I'm sorry. We need a review with mayonnaise on it is what he just said.

Yeah. I don't know. I don't know if we're going to cut. not doing it i'm sorry we need a review with mayonnaise on it is what he just said yeah i don't know i don't know if we're gonna cut we may have cut the whole 30 minute discussion about mayonnaise off uh off of the show and so you may not know what's going on here i'm sorry for that but anyway if you want more of this nonsense then leave some reviews and we'll know that this kind of bag uh works so what what happened to like the reviews? I thought, what happened to late night DJ or NPR voice or auctioneer voice? You just come at it with normal voice? We're going backwards.

No, because this is my dream come true. Because we were doing those late night voices and I hated it. I was like, Oh God, that's so creepy. I can't, I can't take it. My ears were bleeding when they,

when I would hear it, but now we're going back. I'm like, I'm going to do cartwheels. You started getting used to it. So I had to find something new that you wouldn't like. That's right. I love this.

This is awesome. Oh crap. All right. Well, if you go to cooking box.net slash review, we try to make it easy for you. You got all that? Yeah. I mean, it's definitely a lot better for my mental health now, knowing that we're not

doing the late night voices anymore because that was... Oh, no. That's not going. That's great. It's on a hiatus. Oh, okay. Well, now we're going there. You know what else is bad for your mental health is like social media, like Instagram.

They say Instagram is bad for your mental health. Really? But what about JIRA? Nobody talks about JIRA. I would concur. Yeah. Thank you, Tim. All right. I would concur. Yeah. Thank you, Tim.

All right. So we now head into my favorite portion of the show. Survey says. All right. So a few episodes back, we asked, what's your container management of choice? And your choices were good old reliable Docker desktop or rancher desktop. I like my container management free and open like the wild west or pod man because the little otters logo is so cute. All right. So episode 179 to tuck those trademark rules of engagement.

Alan, you are first. I'm going to have to go with number one here. Good old reliable Docker desktop because I'm going to venture to say that most people didn't even know those other two existed before this survey. So we'll go with number one. I'm going to go with a strong 50%.

Okay, well, I'm just going to lose this one. I'm going to let you win because Podman just released version 4.0 the day that we're recording this. Okay, well, I'm just going to lose this one. I'm going to let you win. Because Podman just released version 4.0 the day that we're recording this. And they do say that support for Podman on Windows and OSX has been the top priority for this release. And I didn't have a problem with it before, so I assume it's only better now. And so I'm going to say that 71% of people are going to say that they use pot man. He's going to lose a little logo.

If you're going to lose, lose big. That's right. 71. That's 71%. That's my final answer. Final answer. Okay.

Now, before I give you these results, do you want to phone a friend? This is going to be the first survey that ever had 100 percent. I was going to say,

or maybe do you want to eliminate two choices? Okay. Well, okay. So Jay-Z with the risk goes out on a limb at 71% pod man. Yep. And Alan takes the conservative approach of good old reliable Docker desktop. I mean, it's in the name, Joe. Good old reliable Docker desktop.

And Alan says 50% of the vote. I feel like I undershot it at this point. I'm not going to lie. Wait for it. Now, don't be surprised when I tell you that alan won oh docker desktop clearly 90 i don't think i think that we did i think that some people were messing with us honestly because it only got 75 and And I'm thinking like, okay, I think the other 25% were pulling our leg there.

I'm not saying that the others don't get usage, but I just think that if you were to throw this survey out to a much larger audience, I think that we would see a sway even more stronger for Docker desktop, you know? Yeah. That's, that's interesting.

Yeah. But 25% not in Docker is interesting. I think, I think they didn't have their glasses on, I think is what happened. Yeah. They, they accidentally tapped the wrong button and then you're like,

Oh man, I can't. Ranch is huge. It's over. K three S is the future. Oh man. All right. So I am curious, like anybody that, that, man, I can't. Rancher's huge. And K3S is over. K3S is the future. Oh, man. All right. So I am curious.

Like anybody that chose one of the other ones, leave a comment on this episode, episode 179. So codingblocks.net slash episode 179. And let us know what you're using and why it's better. Like that's interesting. And it might be that people have moved over now because Docker is charging. Right. That's possible. Well,

that's when we, when we brought this topic up, that's why we were talking about it. Right. Because maybe that's it. Licensing. I mean, it is very likely that that's what's going on.

So maybe this would even be higher in the future. I don't know. So, yeah. Yeah. We'll run the survey again in like 10 years and see we're we're outlaws gonna be like hey we talked back in episode 179 about this and we'll be like episode 400 now i was gonna say we'll be on episode 236 there we go there we go. Oh, man. All right. So, yeah.

So, and Podman was second in case if you were curious. Yeah. All right. I'm fine with rainbows. I like all of them. So, yeah. Where do bad rainbows go? I mean, pot of gold? I don't know.

They go to prism. Oh, geez. That's good. But don't worry. It's a light sentence. Thank you, Jesse. All right. So for this episode, since we're talking about minimum viable CD, how mature is your CI CD pipeline?

And your choices are extremely mature. Something like commits are made. Bits are built. Things are tested. PRs are merged. Builds are deployed automatically every time. Or somewhat as in we build and test prs regularly but deployments still require a person to initiate or not even close it's more like leroy leaves his laptop

running in a closet and when we need to build somebody walks over and performs the 18 necessary build steps leroy jenkins yeah so you're somewhere on that you're somewhere on that spectrum is is what we're getting at all right outlaw you bring us back in this time. What do we got? Well, we're going to get into details of trunk-based development. And, you know, I think I'm going to hold off on like what my take is on this. But we already kind of gave a description of this. This is basically like you have one main branch that all the developers collaborate on that single branch. Now that's not to say that you as a developer couldn't have a small feature branch. And, you know, like I said earlier, according to the trunk based development site,

they actually advocate for working in small feature branches. It's just that you're regularly merging back into the trunk branch. And, you know, they even on that, on the trunk based development website mentioned that like the name doesn't have to necessarily be trunk. So. Yeah. And the trick here is to resist any pressure to try and create other long lived development branches.

And sometimes there can be a lot of pressure for that because people think that integrating loses time, basically. And so the argument there is that it's just easier to kind of go off with a smaller team and build on their own for a little while. And then later, they're mulch-brecken and be fine. And trunk-based development says, heck no. Yeah. Okay, go ahead.

Nope. Well, I was going to say that the argument is that the simplicity of the structure is more worth anything gain you might get from some other type of structure, right? That like by having everybody constantly merging into that branch, then everybody's getting those new bits more often. Uh, and therefore, you know, a variety of different people are testing it in ways that they might not even realize that they were testing it, like, you know, in order to access the website or something like that. Uh, so it's like little things like that,

because everybody's like working in the same, um, trunk, then you reap more benefits than you would from having teams work in long-lived branches. And anybody who's ever worked in long-lived branches knows exactly what we're talking about. And they're probably screaming at their 8-track right now

because that's how they get their podcasts. Just kidding. But yeah, they're screaming at this like, you know, yes, this long-lived branches are difficult because the code gets out. I guess I should go on like, why? Why is it difficult, Michael? But, you know, the code gets out of sync quicker in those long branches, and then the merges become awful or can be awful when you do try to get caught up. And then it has this self-fulfilling kind of prophecy type of thing.

Because the merge was so painful, you're like, I don't want to do that again anytime soon. And so you don't. And then it goes off on this long-lived branch again that you didn't mean to do. And then you're like weeks later, you're like, oh, man, I got to do that again. Now I realize why this is so hard. I never want to do this again. And so you like, you know, slug your way through it. And then you're like, oh, I'm never doing that again.

Not for a few more weeks. And then like rinse and repeat. Yep. Yes. It stinks. Yeah. And even on relatively, uh,

small teams, man, it can really eat up a day. Like once, once you start getting down that, that Hill where those things are rolling down, those mergers are coming down, man,

it just clobbers everybody that comes after the first one. right? So the first tough one goes in the next one might've been simple, but it becomes tough. And then the third one's even worse. Like it just seems to keep rolling downhill and gathering speed and it just destroys time. So yeah, the, the long live branches that you're merging into a single trunk or something is a terrible, terrible approach. Terrible. Terrible. In the great words of Charles Barkley, it's terrible. Terrible.

You sound just like him, Joe. You didn't even try, Joe. Come on. You got to post there. What? You don't know Charles Barkley? I know Charles Barkley. I was a kid in the 90s.

Let's see. So, like we mentioned, you know, for small teams, they recommend committing straight to trunk. And I'm getting this from the trunkbaseddevelopment.com where they mentioned having a kind of a build test gate, which is awkward without pull requests. But good news, pull requests are everywhere. And over larger teams, they do say for larger teams that you can use short-lived feature branches that might live for a couple days max

and end with a good PR review and build test gate. Now, we already mentioned that there's a split in the websites here. And so minimum viable CD recommends committing every day. And so they're not going to like this short in the feature branch. But sometimes you got people collaborating on stuff. And so these are kind of two concepts at odds. So you take that with a grain of salt here. And just understand that the goal here of minimum viable CD is to have more frequent, smaller chunks committed directly into trunk.

But why? Idea is that our code base, our trunk, is always releasable. It's always in a working, functional state. We don't have tags. We don't have, maybe you have that stuff too, but you're not doing any funky stuff. There's nothing special about certain commits or certain branches or environments. It's just always deployable.

And Google, Facebook, the authors of Continuous Delivery, and the DevOps Handbook all advocate for this. This seems to fly in the face of get flow because that particular workflow, you would have a branch like a release and a dev and a hot fix type of branch where like those are, are, you know, always around branches. And it's a good thing I read ahead here,

by the way, because all the things that you've got listed down there were all the things that I remember that we talked about in episode 90 about why following this one piece of advice is the greatest thing on earth when it may not be for you for a lot of good reasons. Yep. So let's get into that. So in the series of questions, but how do we, what about a big feature? How do you do a big feature in this particular workflow? Feature flag it and commit small little chunks, all of which is turned off until you're ready for it.

Which, by the way, I don't hate that. I like that actually i don't hate it but it does require like feature flag can mean different things to different people depending on who you're talking to yep and you really need some infrastructure for it it's not something that you can just easily do a lot of times especially across distributed systems right well that's why i say it depends on who you're talking to because you know you might talk to one developer might just say, oh, I'll just if def this out or, you know, I'll like conditional it to where it's hard coded in the code. Right. To not run, you know, unless it's a debug build or something like that or, you know, it's just hard coded to not run. And, you know, unless it's like

on my machine or something. Whereas someone else, another developer might say, oh, well, it's always available. And, you know, unless we like change a flag in the database, you know, if we set some value in the database then it will execute that branch and someone else might say well let's use something like um uh what was it launch darkly i think was the example uh an example where uh you know of a feature flag system that you could you might be uh it might integrate into it yeah lots of different things and like services like launch darkly are kind of famous for being a feature flag company but when they say feature flag they mean oh well you can turn on just the east coast or 10 of your users or oh yeah only users in this

time zone are you they're hooked up into all sorts of different stuff so they have like a lot of flexibility on when and how things are kind of rolled out and the idea is that it's easy to have like one flag across multiple systems because they've got this kind of third-party service that handles it that's a big level of maturity that's required if you're going to build that on your own it's going to take some time i'm so glad you you brought that up because i totally forgot about that with the ability to like uh uh, target, like maybe I only want to target like 1% of my user base just to see like, Hey, let's get, let's start testing this thing out in the wild. Does it work? Does this feature work? Or it, and not only does it work, but am I seeing a return

on that effort that makes it worth pushing out to others? Like maybe, maybe it actually detracts from sales, for example, if this was an e-commerce website. So yeah, I'm glad that you brought up that services like LaunchDarkly provide much more capability than just is the feature on or off. Yeah, but what you were hitting at here too is what feature flags don't buy you is when there's infrastructure and things that need to be in place or different versions of infrastructure or whatever, right? Like you can't just feature flag that thing away, right? Like, Oh, this, this particular thing runs on version one of Kafka. This one works on version 1.1, right? Like it's using some new whatever, like that's the kind of

stuff that you can't easily feature flag. And so that's where the answer is not put that into a feature flag. That's probably going to need to be a separate branch where you're testing things out independently. Right. Yeah, it's definitely complicated. We're starting to get into like, remember where I was telling you like, Hey, put a pin on it. Right. So one of the other ones is like,

well, but how do we hot fix? Right. And, and the answer here is like, Oh, fix forward. You're always just rolling forward.

So while I mean nothing against, uh, Dave Farley or anyone else that's involved with this or the signatories and all that, I think what they've done here is fantastic. But this whole thing is very strongly slanted towards a website or something that can always be just, there's only a single version that we need to be concerned about. And we can always just, uh, if there's a bug we can, you know, put out a new one, even though they do talk about like, you know, uh, the ability to roll backwards. It's still the same thing though. It's my point. Like this, even with the answer of like, hey, how do you deal with a hot fix? You know, just fix forward. What I mean by this, that I take issue with this, is that if you have to support multiple concurrent versions,

and I'm technically getting ahead here because I see that that was another one, but like how do we support concurrent releases and, you know, any work around here related to this minimum viable CD? You can't do some of what they're talking about here. So let's imagine that, you know, take, let's go back to that Git workflow episode 90. And one of the examples that we talked about there was a strategy that Microsoft authored that at the beginning, they didn't really have a title for it. They didn't have anything clever. Like the article was just like Git branching strategies. And they described what was being done within Microsoft, right? And I know that we have since been big fans of that strategy. And amongst the three of us, we've referred to it as or a hot fix or whatever, like you were the best

person to know, like, Hey, I need to cherry pick it to all these different places. And that works out great when you have to support multiple versions and those other versions might be different branches. And just, just to add some color to that too, when we're talking about multiple versions, you can think of multiple things, right? So Outlaw said that this thing here is very slanted towards like a website or even like software as a service, right? Like you're providing some sort of service API that people hit and they're always doing that. What if you, even if you are doing software as a service, what if you've had something out there that's running for two or three years and you need to

release a new version of this, but it'll break the other stuff. Well, you might have a totally separate release of the same API out there. Or if you have software that's installed on a person's computer, right? It's very likely that, um, you know, windows XP wasn't completely thrown away when people were done with it. They had windows 10 and they had windows millennium, which was great. Um, but the whole notion is what he's saying is, okay, a fix comes out. You can't just put it in the latest, right? Like you might need it in XP because there was a big thing there and you still have a lot of customers you're supporting. And then you also need it in the latest, right? Like you might need it in XP because there was a big thing there and you still have a lot of customers you're supporting.

And then you also need it in Windows Millennium and maybe it didn't exist in Windows 10. So it's not something you bring forward. So that's where like you have to know your software and how it's delivered and how people use it and how it lives in the wild, right? If you only ever own one service API endpoint that anybody ever hits, sure, this whole thing of always going into that one branch is great.

But when you have something where you're supporting multiple releases, multiple versions out there, whether it's something that you own or whether it's something that's installed on somebody else's computer, that strategy is going to fall apart quickly. And, I mean, we went over it pretty in depth on episode 90 and the reasons why each one of them work in different environments. Um, I got one sidebar question though. Tangent alert.

You don't use windows often. Do you Alan? What did I say? Your windows references are really up to date XP. Well, you remember, that was a good one though it was a good one i'm just teasing i'm just teasing i was just but you remember gibson right like steve gibson was like i'm never leaving xp because you know he loved that one so at any rate like xp is like the the first great one that i can think of yeah it was like the worst like you didn't talk about like you know windows 7 or 8 or 10 or 11 i couldn't even think like you went all the way back to yeah right i mean why do you while while we're at it let's talk about windows 3o right yeah i mean

3.11 is where it was really at you know i'm on windows 11 right now and I kind of like it. So at any rate, I joke though. Um, but yeah, I mean that, that was a big thing that I, that, you know, I take with some of this because in the problem that I have with this is that a lot of what's being discussed here doesn't have to, uh, be only for like websites and services and things like that, or like mobile games or mobile apps where, you know, you're going to put out the latest version and that's the version you're supporting, you know, kind of situation. You can still do a lot of what is in here, even for like an application that will be installed on somebody else's computer or device. There's still a lot of this stuff that can be done, but there are parts of this where it's like immediately shut the doors. Like,

well, you know, you're, you're, you are forgetting about a large part of the development world that, you know, where you do need to support multiple versions, for example. And so in this trunk-based development, if you're not going to,

if everything has to be merged into this main trunk and you can't have these long-lived branches, which might be those releases, right, then, you know, I don't know what the workaround is. Directories. No. Version 1 directory or is it 2 directory? You joke,

but that was basically how TFS versioning worked, right? We've seen it in Unreal Codebases, too. Well, yeah. You could do it inside of Git, too, if you wanted to, I guess, which is where your joke is coming from but uh yeah they didn't even address it at all i looked at faqs and stuff trying to figure out like both trunk-based development.com minimum viable cd i couldn't find anything about it they did have a section on multiple consecutive releases

which i thought was really bizarre we can talk about that in a second but i could not find anything for multiple concurrent releases even though though we could come up with several examples. Anyway, I want to know about this. What's this multiple consecutive? Yeah, so there was an FAQ for multiple consecutive, and at first I misread it, and I was like, oh, okay, cool. Here's what I was looking for. But no, they were talking about when a company is working on multiple releases at the same time. For example, maybe half of our team is working on a release that's going to come out in March and the other half is working on a release that's going to come out in June. And when the March team gets done, they're going to maybe come over and work on the June team or maybe they'll become the September

team or something. So it's kind of like working on different steps. And there's people that are working on stuff that's going to be released a lot sooner than someone else. So, you know, you can imagine if there's like some big feature that's going to take your team two years to build, but there's stuff that you also need to get delivered next month, you're going to split that out. And what they argued here is basically that,

and this is a funny quote here, what you have got is the perfect setup for disaster born from the random bad news event. Which is the idea that you're going to have this one team that's off working. You're basically splitting up your code base at this point. You don't even have long-lived features. You've got long-lived teams in a weird way. And so when you try to bring these things back together, it's going to be just as problematic as having separate feature environments or separate long-lived branches.

So they said it's a disaster, and what you should try to do is basically get everyone working in the same trunk, and if you release stuff later, fine, but you should try to not have these big kind of milestone-esque releases. And use feature flags. So everybody working on the March release is working off trunk. Everybody working off the June release

is working off trunk also. Yeah. It's okay to have things delivered at separate times. You know, that's not a problem. It's just the idea that they were saying is like having these kinds of like multiple releases that were planned out, you know,

way ahead of time. It just, you know, in a way they're almost kind of pitching agile a little bit with this FAQ. I mean, I don't hate the idea of, of both of them working in trunk.

What I hate is if there is a release in March and that's going to live somewhere independent of the release in June at some point, not having that branch for March to be able to come back and do things to doesn't make sense, right? Right. Like, I don't know. I mean, in that example, I still like the idea of like, this is where, you know, write your code and just however you get, however you make it not executable, then fine, you know, make it to where it can't, if that's a feature flag or something else, as long as it, it isn't getting, uh, the, the later team could be developing and just crafting it in a way that it isn't executable at the moment or you can't. You have to know like an obscure path to get to that branch or whatever, you know, however that works.

That that part's fine with me. But, you know, I'm still stuck on the previous issue. Yeah. in my head. My head was exploding even as listening to you describe this one because I'm like, in a real world, you might have customers that... To rewind on that one, I was envisioning somebody arguing like, well, you just shouldn't be in that type of situation where you have that support those multiple concurrent versions. And I'm like,

in my mind, I'm like, well, there are definitely real world situations where depending on like how big your product is and what type of customers you are, like if you're serving like fortune 500 companies, those companies are slow to move. And so, you know, you, you're going to have a cousin, one of those customers who it's a significant amount of money, and they're going to say, I'm not willing to move off of version 1.0 yet, and you might be already on version 3. And it's not that they don't see that the versions are great. They just don't want to undertake the time and effort to do the upgrade for whatever reason. They don't view those improvements as worthwhile, and they're not going to do the upgrade for whatever reason. They don't view those improvements as

worthwhile and they're not going to do it. There's companies that have a variety of reasons for why they might only upgrade some particular system on a schedule like, hey, we'll do that every two years or whatever their reasons are that make it to where you have to support multiple concurrent versions. Yeah, it does make sense to me that now they're giving me business advice. You know, they're not telling me what to do with my code and how to deliver my code. They're telling me how to run my business. And, you know, a great example here is Kubernetes.

Kubernetes releases a version three times a year. And you can look and see what's coming out in those next couple versions for the year. And they are not releasing this stuff in point releases. And they're not releasing day-to-day because they really care about stability and reliability and getting the cloud vendors to support the features as they come online. So there's a whole lot of communication that needs to happen because we've got these big enterprise customers that all need to be on the same train and come out every three months on a schedule after being talked about so

that's a great example where kubernetes has multiple concurrent releases first of all because they're still putting bugs into multiple old versions go for long-term support and they're also they've got these big milestone releases so they've both got concurrent and consecutive releases and there's people you know it's not like they're just choosing to start working on the things that are coming out later this year. Later, they're talking about it now. They're working on it now. They've got this stuff off in seven branches.

It's not ideal, but it's working pretty well for them. Yeah. That pretty much sums up where when I was mentioning earlier, hey, put a pin in that topic. Let's come back to it. It was things that kind of, you know, flew in the face of like, well, okay, that works great for your business. It doesn't necessarily work great for every business. we're going to create something that is, you know, the minimum viable standard for, you know, the industry, then I think we should be more honest with, you know,

all development if that's going to be the minimum. Yeah. Right? Yeah. And then build on top of that. Like, here's the minimum for a website. Here's the minimum for API. Here's the minimum for a software as a service.

Here's the minimum for a website. Here's the minimum for API. Here's the minimum for a software as a service. Here's the minimum for a, a user installed application or whatever. Like let's build on top of it, but let's not start the minimum. It's something that isn't realistic for anybody. Well, yeah, there,

there were definitely parts that are, they're hard, but you know, yeah. So it's a really good, I'm definitely glad hard. But, you know, yeah. I'm with you. It's really good. I'm definitely glad I read about it and I agree with everything you said. It's just I would absolutely not call it minimum.

You know, I think minimum is the code should be built on every commit. I like that. And you should be able to deploy via an automation system. That to me is minimum viable CD and everything else is a matter of maturity. Yeah. And I don't mean any of that as a negative to any of the signatories on this project. Even though it might sound like I'm being harsh, I really don't mean it that way um you know yeah i do say i do think yeah so i yeah

i don't i don't mean to sound harsh just like you said but it is kind of off-putting to say like hey people this is what you need to do to be minimum viable cd like don't get stressed about about all the details this is all you have to do to get the ball rolling, and then you can take it and ball from there. Step one is a mountain. Right. Okay, so it's off-putting to beginners. So I guess the takeaway from this is that if you're listening to this and you were like, oh, my gosh, I can never get to there,

you're not alone, I guess is the takeaway from that. You're in good company. Yeah, it's not easy. Or at least you're in our company. I don't know if it from that. Like you're in good company. Yeah. It's not easy. Or at least you're in our company. I don't know if it's good, but you're in our company. How's that?

Well, we'll see. We got a survey, right? Yeah, we do. We do. We do. Yeah.

Uh, we're the only ones that are not doing everybody's be like, ours is perfect. Yeah. How about, how about I say this, like should any, should this get back

to any of the signatories and they're kind of like upset with me or anything i've said how about if i if i try to uh you know change their mind by asking or or letting them know that the and i don't know if you guys even knew this the t-shirts is actually short for tyrannosaurus shirt did you know that that that's what the t stands for in t-shirt is that true i know there's a punch line here we're waiting i think it's true it's absolutely true why would i make this up because of all the alarms, you know? See, I knew it. All right. So, so, uh, you can't be mad at me now. All right. So, uh, with that, you know, we will have a whole bunch of links, uh,

to the resources we like for this episode. Um, you know, definitely minimum cd.org is going to be there. Trunk based development.com is going to be in there. Uh, yeah. So there's, there's going to be a whole bunch of links in this episode. And with that, we head into Alan's favorite portion of the show.

It's the tip of the week. We're tips. I have a few today. Oh, all right, here we go again. We'll shut it down. It's going to be like 18 hours later.

That's right. Coming back strong. All right. So first this is for anybody else that may ever have to do this. I'm going to save you some time. You cannot set environment variables in a Java application. I don't know why I naively just assume that, hey, this should be a thing, right? It's not.

And it's really frustrating when you need it. So just as some background, if you're trying to authenticate into the Google Cloud project or Google Cloud platform, the way that they suggest you do it is set an environment variable with a path to your key. Well, you can't do it in the Java app itself. You got to do it in environment variables being either passed to the Java application on the command line or it actually needs to be an environment variable. So just be aware of that. I wasted way too much time on that. And it's really frustrating.

But it makes sense, though, right? It makes sense when you think about it, right? Because what does the Java app run in? Yeah, it's a virtual machine, right? Oh, there you go. I don't care. I'm still upset about it. I want that virtual machine to be able to manipulate the real machine.

Right. And let me save you some more time because the way that I am is I'm like, I can make this happen. So I tried to make it happen. And I even found some hacks out there that apparently did work at one point in time. But Java has since closed a lot of those loopholes. So it just doesn't work. So just don't waste your time. We might call those bugs then.

Yeah, bugs maybe. I don't know. It's also weird. Like environment variables are usually read like when the application starts and they kind of forget about it. So it's kind of a weird thing to set it and read it. But I understand why you want to do it. You got like a secret server or something and you go out and get the credentials

and then you want to pass it somewhere else. How do they recommend it? Set environment variable. Okay, let me just, what? Yeah, can't do it. Yeah, yeah. And you know the worst part is it'll even allow you to get

the environment variable collection and it even has the put function on that collection, but it blows up and says, you can't put something into an immutable collect, whatever, man, just don't do it. So all you people out there dealing with Java, I hopefully just saved you some hours of frustration. Um, so I came up with that after I actually found this one from Lars on silliest. I hope I said your name, right? I don't know that I said it terribly wrong, but this was way better than I would have said it. Okay. That's good. That's good. Um, so this was over in our Slack channel in the tips, uh, in our Slack community and the tips channel. Um, this was actually pretty cool.

And I, I highly recommend that everybody do this, including the other two guys sitting on this call, it's terms and conditions dot game. And it's just a funny little game about all the way that websites are trying to trick you into stealing your private information. Cause we know since the GDPR stuff, that's all popped up here in the past year and a half to no, Oh man, three years now, I think i think um like every site you go to now there's a pop-up that comes up like hey you want to accept these cookies or you just want to accept everything it's like well if i don't click the customize thing they're going to take more than what i want it's just annoying right so this is actually a pretty fun little game that i spent a little bit too much time on and And then one more.

That one I forgot to mention, though, because that one was from Lars, and he is the one who told me where the name T-shirt actually came from. So thank you, Lars. Oh, very nice. He gets two mentions on this one. And then this last one, while Ryan didn't actually give this to me for this episode or as a tip. He has sold this hardcore to at least two of us on this call. And, and he loves these things.

So Ryan monster, if you want to hit him up on Twitter or whatever, or even if you want to see him over in Slack, there's this thing called test containers. And I thought this was apropos to this particular episode because we were talking about unit testing and, and integration testing and all that. Test containers are pretty interesting because what they allow you to do is in a Docker type of an environment, instead of having to spin up full-blown Postgres or SQL

Server or Kafka or any of these kinds of things, you can have these test containers that hook up and work as an integration test that you do. So you don't actually have to have a full blown other server environment set up. It'll launch with your tests. And then that way, let's say, let's say for instance, you want to test a procedure out in Postgres, right? It could create the database, create the procedure. You could insert some data, do some stuff like that, and then run your integration test on the procedure, make sure everything's good, and it'll shut down the container afterwards. So these test containers are a way to be able to do integration tests when you need infrastructure spawn up just for that

specific test. And they work pretty well. I know there's been a few little hiccups here and there, but for the most part, they're awesome for doing the types of things like what I just mentioned. So that's it. All right. Well, hey, I was doing a little bit of work on a game and I had to read in some data

and I knew that I was able to serialize Jason with just the game engine. I had it built in. But here's the thing. I didn't want to write Jason. I mean, there's no comments, first of all. Second, you know, there's a lot

of commas. There's a lot of quotes. There's a lot of brackets. No comments is just terrible. Well, what I wanted, friends, is I wanted the YAML. Said no one ever. A year or two ago, I was like griping about YAML. And I was like, why don't you just use Jason? I think we even had a survey.

And I was like, you know, very formerly the camp of Jason. And now it seems so foreign to me because I don't remember what I didn't like about YAML because I'm fully Stockholm on this thing. The white space is a little weird, right? Sometimes you can be real confusing. But no, it's just nice. And so I went and I found a third party plug in, not plugl.net, and I imported it, and it was great. And I was able to just very easily read in my yaml and serialize it just like you would JSON, except it's like half the lines and it can have comments, and I don't have to have quotes all over the place.

And so, yeah, really what I was just saying there is that yaml is a superior format and i was wrong i i if you go to yaml.org though you almost want to like barf a little bit when you see this website if you haven't seen it already you're like that's oh yeah i mean but you know there's a reason why jason.org is not does not look like that because no just couldn't read it. Hey, look. You know there's already a problem with YAML. When you go to yaml.org and Chrome says, hey, do you want to install a Google Translate extension? That's true.

Fancy YAML has some pretty cool support for like variables and loops and all sorts of weird stuff it's really powerful the the one problem i wouldn't say it's fancy nothing supports it but you know it's fancy look look the problem with yaml is the fact that everything that seems to parse it doesn't know how to tell you where the problem is in it and that is why yaml sucks whereas json's like hey this property right here i don't know what you want to do with it it's like okay all right cool i'll fix that yeah i was like documents bad okay thanks now if you're if you miss a space you're gonna get wrecked god and true and false is weird too like what they allow for bullions you know it's just kind of funky but

i mean overall jason's weird too i mean you can allow for bullions, you know, it's just kind of funky. But, uh, I mean, overall Jason's weird too. I mean, you can't have comments. You've gone to the dark side. Hey, the comments is a big one for sure. Yep. Uh,

one more, uh, Scott Harden, uh, mentioned this a couple of weeks ago and I said, no, we already did that on the show. We didn't.

Uh, have you heard of power toys? Is this like power tools from back in the day? Uh, pretty much. Uh, so here's a list of power toys you can install if you're working on windows this is window things from microsoft they're utilities to customize windows not windows xp though alan this will be a later version it's it's dead to me yep but you know i don't see the minimum so you you need to have uh x64 support so not xp then i guess

it's not uh you have to have xp64 uh but anyway um so always on top is an app that enables you to pin windows on top of all others with a shortcut uh power tools awake is just a simple utility that is designed to keep your uh computer awake without having to mess with your settings in order to keep it from going to sleep. If it's like a laptop or whatever, a color pickers, color picker is really nice. Uh, so you can like basically copy stuff to clipboard with just a quick shortcut.

Uh, and there's way too many for me to read here, but it's, it's all little stuff like that. Um, mouse utility, um, renaming tool. how are you going

to skip fancy zones that was like the very next one that's the one that i think everybody would want uh windows manager that makes it easy to create complex windows layouts and position oh that's what i should do oh i didn't see that one so that's great for when i'm doing like streaming stuff like sometimes i have to like perfectly align my windows. So here's OBS. Here's my Unity. Here's my IDE. And I have to line them up perfectly so it looks good on the camera. Yeah.

You just push a button. Oh, that is amazing. Yeah. Image Resizer. I mean, there's just a bunch. There's probably 20. There's Video Conference Mute. A global way to mute between your microphone and camera

that's killer yeah windows shift q will do it boom shortcut so yeah uh we'll have a link to that thanks scott harden uh that's excellent share what was the meet oh i see it now video conference mute yeah and hey uh you know the the PM for that was Clint Ruckus. We did an episode a long time back on I forget what it's called now. Templates for Found You. No, it was the Visual Studio

templating. It had like a built-in thing for... It was the Found You experience. Oh, yeah, it was. I just couldn't remember the name of uwp for those kind of apps oh yeah wait where did you see his name on here though uh down the bottom uh power toys video walkthrough there's a video of i recognize that i was like hey it's huh well very good all right so uh for my tip of the week um how did you know that you can now include diagrams in your markdown well you can with mermaid which is a javascript package uh javascript based diagramming and charting tool that takes the Markdown inspired definitions and creates diagrams in the browser when you're viewing it.

So I'll have a link to this project. It's a GitHub project. But yeah, it's super cool. we've talked similar about this, like not this specific one, but there was a tool that we had talked about doing diagramming that would be rendered in visual studio code. Do you remember that? I do remember that. So it kind of reminded me of that, the idea of just,

you know, creating your, your charts or diagrams or whatever in, in code and it being rendered. So, yeah, so I'll have a link to that and I'll close you out with this.

You ready for a question? Did you hear about the mathematician who was terrified of negative numbers? No, I have not. No. But I get it. You do? I understand it. I get it. You do? I understand it.

I empathize. Well, he would stop at nothing to avoid them. Oh. That's good. All right. Well, that's for Mike RG, who reminds you to always give 100% in everything you do, unless you're donating blood. So with that, subscribe to us on iTunes, Spotify, Stitcher. give 100% in everything you do unless you're donating blood. So with that, subscribe to us on iTunes,

Spotify, Stitcher. Thanks again for that one too, Mike. iTunes, Spotify, Stitcher, wherever you like to find your podcast apps, or your podcast, rather. And you know, as Joe said in his normal Joe voice, you know, if you haven't left us

a review, we would greatly appreciate it if you have, if you would. So you can find some helpful links at www.codingblocks.net slash review. And while you're up there at codingblocks.net, check out our show notes, examples, discussions, and much more, and send your feedback, questions, and rants

to the Slack channel at codingblocks.net slash slack. I'm Joe Zack and make sure to follow us on Twitter at codingblocks or head over to codingblocks.net where you can find all our social links at the top of the page.