Coding Blocks - Is Kubernetes Programming?

Episode Date: September 14, 2020

We gather around the water cooler to discuss some random topics, while Joe sends too many calendar invites, Allen interferes with science, and Michael was totally duped.

You're listening to Coding Blocks, episode 141. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And if you've been to the website, you know how amazing it is. And if not, come on. Episode 141 here. Go to codingblocks.net and you can find show notes, examples, discussion, and a whole lot more.

Oh, and feedback, questions, and rants can be can be sent to comments at codingblocks.net. We'll get these kinks ironed out at some point in the life of this. That'll be our seven-year stretch goal. Right, that's what we're doing. So you can follow us on Twitter at CodingBlocks or head to www.codingblocks.net

and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Jezek. And I'm Alan Underwood. I'm Jezek. And I'm Mike Woutlaw. This episode is sponsored by Datadog, the cloud scale monitoring and analytics platform for end-to-end visibility into modern applications.

And SecureCodeWarrior, build your security posture and defend your organization from cybersecurity threats by empowering your developers with the skills and expertise they need to write secure code from the start. Okay, so let's get the show on the road. We are going to be talking about, well, I feel like Alan should have to say this because he's the one that says it so well. Gorsh. There you go. Gorsh.h gorsh i don't know yeah so uh yeah

you know uh we've done these water cooler type episodes in the past and so that's what this one is it's a little light-hearted uh you know water cooler type episode uh but you know before we get into that though let's uh you know as we like to do say thanks to those that left us a new review oh you know what we forgot to put some names on that so uh i'll take the easy one so from itunes uh we have i buy not play and then on stitcher we've got comrade, the nickname field is Too Sure, and Hopker. I love that one. I didn't.

I just got it as you're reading it. I was like, because before I saw it, and I'm just like, huh. And now when you read it, I'm like, oh. That's awesome. So, yes, thank you very much for taking the time to leave those. Yeah, very cool. Also, one last thing, bit of news here, very here very important factorio is version 1.0 right now maybe i mean at least 1.0 right now and uh it's super awesome i've talked about that game

before but it's super exciting and it really hasn't changed that much from uh beta in my opinion user-invasive but anyway uh it's super awesome if you can't leave your house for months at a time i highly recommend it the game that will never, ever go on sale. It will always be $30. Yep. He said, I got it at $20. Really? How?

Yep. Because it's never gone on sale, but it has gotten more expensive. Right. Okay. When it first came out and it was in very, very early days, it was $20. And then they let everyone know, they're like, hey, in the next couple months, we're going up to $30 so it may get

more expensive so you should probably buy it now anything major in V1 it's just like a little quality of life stuff the user interface got a little bit easier you actually if you do free play it starts you off standing by like a wreckage of a rocket so it's kind of like there's a little

bit more of a narrative there in that experience but overall it seems it's totally still the same game so they're unpolished i can get behind that yeah for years they've probably been focusing on their their devops behind it i'm sure you know trying to get metrics and telemetry and you know see what matters well you know uh critner was running a game server in Docker there for a while. A Vectoreo game server? Mm-hmm. And he was running it in Docker? Yeah.

That's great. That's pretty awesome. Yeah. So we didn't know what to do today, so we just decided to kind of bring a couple topics to the table and just talk about it. So welcome. Hope you're enjoying the show so far. Let's get going.

And if you're not, you're probably already gone, so it's all good. Wow. Okay, so I guess I'm taking the first one here. So I have noticed over the years people talk about unit testing. It's kind of gone up and down. And the way people talk about it kind of comes in waves. And right now it seems like we're in a pessimist wave on it. And so I just read an article the other day just kind of talking about the downfalls of unit testing, kind of questioning whether it's been kind of like comparing it to a cult or a fad or something that ended up kind of washing over and not really being practiced anymore

and not being considered best practice anymore. Anyway, that was kind of the tone of the article that I read, and there were a lot of comments, of course, on Hacker News and whatnot about it. So I wanted to ask, are your unit tests bringing you down who's going first can we just say like how could somebody honestly write an article and take the stance that unit tests are like an anti-pattern what i could look i could get it we've talked about this in the past we have talked about this to where if you were just trying to get a thousand percent coverage on everything because now i'm the mathemachicken um if you're trying to do that and you're testing things that don't matter like if you're testing things that are like you're just testing to make sure that, you know, pie is pie.

Like, just that's a waste of that's code that you got to maintain and you got to keep and you got to bring with you all the time. That's not what you should be testing. You should be testing what you're contractually saying that other people can use. Right. And I think that's really what it boils down to. So I can see it. I could totally see it. If somebody's goal isn't to make sure the application is solid, but instead to make sure that they got tests to cover every single method in the app.

I get it. I totally get it. I mean, you shouldn't be testing, trying to test like, okay, well, this could be controversial. In my opinion, I don't like to write tests or waste time with tests that are like testing the framework or something or like math. Like I'm going to expect that two plus two is always going to equal three no matter what i do um i was a no one really never mind i mean jay-z actually thought that was what it was i mean i believe you i you know anything can get past both the math and the chicken.

So, you know. Yeah, approved. At any rate, but I do recall, like, even with libraries, I tend to, like, not focus in on their stuff. I try to focus on testing my stuff. But I do recall there was, you know, one of the Uncle Bob books that we had talked about i don't remember if it was clean code or architecture um it was one of those where where he did talk about like writing test for the framework so that you could protect yourself when or if you upgrade that that library right so i was like oh i mean i get it. But, you know, those are tests that should be like in a very specific place in my mind

for that, you know, I don't know. But I can't take the approach, though, that it's overrated. So which is which is what this whole thing was about, right? It was saying that unit testing is overrated. And I'm just like, I can't get behind you there. I can't. That's not a position I could take. No, it's not.

I can't. I can't get behind you there. I can't, that's not a position I could take. No, it's not. I can't, I can't agree to that. Like it's your, it's your, your first wave of defense in making sure that your stuff still works. And so that, you know, and as you make changes to it, to know that you didn't introduce something new, what's the alternative if you're not going to have no testing at all? I mean, I would assume that's not going to be the approach. So then what's the other thing to say, like, we're only going to focus on integration tests because those can be slow. So, I mean, you want that fast feedback loop, which is what unit tests are all about. And it's not just slow.

Integration tests can also be really brittle, right? So they are way harder to keep up and maintain over time as opposed to a unit test. But in fairness, like if you, so Jay-Z did include the link to this thing, basically what this person's saying, and I sort of get it, I don't agree with it completely, is he's basically saying there's really just two types of code. There's your plumbing, and then there's their computational thing. And I think when he talks about computational, he's basically saying, Hey, your business type code, your, your business logic. And then there's the other stuff, um, your database access, your,

your file system access, all that kind of stuff. And he's saying that your business access or your business layer is usually way smaller than your other stuff. And that's all you should care about testing. And I wanted to bring it up because, you know, I mostly just look at the comments, but I actually just clicked through the article and then realized I didn't actually look at the initial reference when I kind of ran through all these comments and all the links from the comments and kind of was checking on the debate. This was from 2014. And we might even talked about this at the time.

There was like a series of discussions between three different people, including Martin Fowler, who we've referenced many times, Kent Beck, who kind of was a big influence on starting with automated testing and unit testing specifically, and also DHH, Ruby on Rails, influential kind of figure. And they had a series of discussions kind of talking about whether TDD was dead and kind of what their thoughts were after several years of unit testing. And yeah, I was just,

the comments I saw were very surprising to me. I saw a lot of negativity around unit testing, which I wasn't too surprised about because it is a pain in the butt. And what people were saying was like, they kind of got the impression from the comments that there's a lot of people out there that are just drowning in unit tests.

And they're constantly fixing unit tests. And they're just – they can't get any work done because unit tests. And I don't know where these people are working. Everyone I talk to is almost like a myth. It's like, no, I heard about unit tests. I think it would help a lot. But there's no way we're getting it through on this brownfield project. Or there's no way I'm doing that because I don't know what I'm doing.

I'm still kind of exploring. i'm still figuring things out or i've got too many dependencies to make this work with it and so i was just surprised to see so many people kind of talking about it as if they just had these horrible experiences with it so i was just curious what people out there have they tried it did everyone like did a lot of people go out there and try to do unit testing and just get burned by it somehow or you know was a bad test or what happened here but i was just kind of curious to see why it flared up and i noticed that i just searched this article it managed to somehow this article from five years ago six years ago managed to make it to the top of reddit and the top of hacker news twice uh this

week so okay i feel like there's some weird stuff going on. I don't know what REO you're looking at because this thing is from July of 2020. Well, that's when it was resubmitted to Hacker News. No, no, no. I'm saying... Oh, yeah. I posted multiple links. So the one that got me started is TD Dead. It's actually the second and third links.

Oh, I haven't seen that one. I'm doing unit testing. It's overrated. Yeah, that one was from 2020. So let's, let's not go past this one yet, because in my mind, my mind went to sort of like the domain driven design series that we talked about a couple of years ago now, maybe three, but one of the things that I really liked from domain driven design, even if you don't buy into the rest of sort of their structure and their framework or everything. But this whole notion that there should be value types that are

basically immutable, and then there are other stateful type objects, that's the kind of stuff to me that deserves real unit tests, right? Like if you are mutating state and the state is mutated based off any kind of business rules, right? Any kind of logic, like, I don't know, you set a calendar date for an appointment, right? If that appointment can only happen between eight and five and if the person's not booked up already, there's business logic there. That's testable, right? That should be tested and it should be a pretty simple unit test because there should be logic that's applied to whatever that state was to identify whether or not it could be mutated into that other one. However, if all you're doing is dealing with DTOs and you're writing to a database, you're just trying to make sure the database got that changed. And if you get that DTO back that you got the same thing, this is where I tend to agree with what people are saying in this article and that that's not a unit test, right? If that is

truly an integration test, did what I persisted to the database, do I get that same thing back, right? That should be an integration test. And I do agree with that. But yeah, I definitely, I think that unit tests play a super vital role in making sure that if you're changing business logic, you don't jack up what's there. So in, in full disclosure, so like, you know, these links that Jay-Z just presented to us, I hadn't seen these before, so I hadn't read this before, but I'm like, you know, trying to zoom through this, this first one, that unit testing is overrated. And like, I'm just like, no, I can't, I don't know that I could read this thing and like really, you know, take it, take it serious. Like there, at one point he's like saying, hey, let's expand on the observations we've made about this process. And, and he says, unit tests have a limited purpose. I'm like, right.

I mean, if that purpose is to protect your code, then okay, and make sure that it works, right? Okay, yeah. I mean, I don't know. I mean, what do you want it to do? It's a unit test. It's not the main function. So, okay. I guess all code has a limited purpose at

some point in some regard, but this one I disagreed with, like just on its face value, unit tests lead to a more complicated design. I'm like, no, it shouldn't. No, I mean, not if you have the right levels of abstraction, right? Like, it should make it better, right? Like, that's the whole point is, like, your dependencies are supposed to be lessened because of that. And if that's what you mean by a more complicated design, like, oh, I'm not going to let all these dependencies seep in, then okay, I guess. But that's a weird stance to take. And then the third one, unit tests are expensive. And I'm like, hey, we touched on that in clean architecture at the very beginning of the book, where they said

that the whole point of a unit test or even an integration test, any kind of testing like that is to give you confidence that you can make a change. And when you don't have that stuff in place over time, it gets increasingly difficult to make changes because you don't have confidence that you're not breaking something. Well, I mean, here, here's his,

his thing that he's saying is that unit tests by design are very tightly coupled to the code they're testing, which means that any effort to make a change is effectively doubled as the test suite needs to be updated as well. And I'm like, well, that seems crazy logic to me. Like the whole, yeah, I mean, sure, fine. If you're going to like fundamentally make some changes to the thing, then yeah, you have to change the unit test to go along with it.

But is it necessarily double? I can't get behind that anyways, because you're still going to have to test it one way or another, whether or not you have a QA person going in regression tests, or are you saying that their time is less valuable than taking the time to automate testing that thing? Like, that doesn't make sense. Now, here's two, the last two though, that get interesting is that unit, cause, cause the first one was like,

I think are just like way too confrontational to start with. Those first three were just confrontation, but then it's like, okay, unit tests rely on implementation details. Well, okay. Yeah. I mean, you got to know something about what you're testing. So, okay. I, I guess I can't argue with that. Right. I mean, you got to know something about what you're testing. So, okay, I guess I can't argue with that, right? I mean, otherwise, how else do you want to test it? Like, again, go back to what you just said a minute ago. Okay, yeah, it's either the code knows it or a person knows it, but somebody has to know what they're testing.

So, you know, some detail needs to be known there. And then unit tests don't exercise user behavior. Well, that's different. That's I mean, when we start talking about user behavior, you start talking about interacting through another layer, right? Another UI or something that has other things going on. That's that's again, that's more of an integration type test. That's not the same thing. And again, he has a tweet in here that's kind of funny.

Yeah, I saw that. Where it says, unit testing is a great way to ensure your mocks work. And I'm like, that's hilarious. You know, on that one, i i gotta argue like i think there is something wrong like i think if you've got a ton of mocks then that's kind of a sign that something bad is happening because i kind of like the idea that you should have your branching business logic your decisions separated from your third-party dependencies i want those third-party dependencies and those like external services to be really dumb, almost like REST-level dumb.

They should crud, and then I want my logic separate. Have it do the deciding and have these other humble objects do the doing. And so I kind of feel like by doing that, if you can truly spit out your decisions from your actions, then you don't really need mocks because the actions, who cares? They're basically – you're relying on the integration type stuff for that. And, you know, if you can just kind of keep your decisions separately, then that's the places that change 800 times. Well, hold on, hold on.

In fairness, the mocks do serve a decent space, right? And the reason I say is, if we're talking about OO specifically, if you're mutating state, how do you verify that state? And that's where a mock can come into play. Now, if you go crazy and you have all kinds of complicated objects that are nested and all, sure, right? Like now you're creating a very complex unit testing framework that is almost like maintaining a whole other app on the side. I don't even know.

1988 called and went through state back. It's all about the function on that. Oh, come on. Oh, come on. I don't even know if you've seen it, though, because there are some disgusting, absolutely disgusting things that you could do with unit tests and mods. Totally. like there there's actually like there are frameworks that allow you to say like hey i know that this other object should have this internal you know method and you tell me if that thing actually got ever got called i want to verify that it got called that the method got called right and it's like that's the kind of thing in my mind like no i don't i don't want to be in the

internals of that other thing. Like that feels wrong. I want to test that method. If that method returns what I think it should do and does what it should do in certain situations, you know, test the behavior. Sure, fine. You know, I can get on board with that, but I don't know. Like he goes on in this article and makes this point. We're picking on only this one that you pointed out, Jay-Z.

But, you know, where he's saying is saying, he's talking about partitioning your test based on threads of behavior rather than the code's internal structure. But in the examples that he's given, he has external dependencies on standard out or a file system and things like that. And I'm like, I'm thinking in my head, like, okay, depending on where you decide to run that unit test, that could be problematic. If it's, you know, it might not run the same way in a Docker container on a build server that it ran on your laptop when you coded it, you know, for example, maybe, you know,

I mean, your, your mileage can vary. So I don't know. I can't. It seems like it's pretty controversial. The other one is TDD dead. So this is one of those ones where I think somebody got annoyed by the fact that everybody's preaching TDD, right? And they basically say, hey, the thought leaders are the ones out there that are preaching this stuff, but they don't ever actually have to implement it. Right. Well, it's the that's the title of what they link to. And then there's a whole bunch of discussions that you kind of have to like you basically listen to.

It's not even really like a laid out article. It's discussions about it, but definitely the way it's framed by the title and then the comments that you see, you can definitely see a certain kind of leaning in the comments. Well, what I was going to say is our buddy, Will, who was on, it's been several episodes back now, but he did TDD and he loved it. Like he said that it made you very, you were way more thoughtful about your approach to problems when you did that, where you basically set up a failing test at the beginning. You figured out what the business rules were that you needed to implement, and then you coded that stuff. And then when that was all good, then your unit test would pass, right? And so it was a very structured way of ensuring that you were meeting the business logic that needed to happen. It sounds great in theory. I just can't do it.

I've never been forced to do it. So I can't, I can't speak to whether or not it, yeah, I can't speak to whether it will work for me or not, but I know for him, he was forced to do it and he ended up liking it because I had even asked him about it. I was like, what do you think? He's like, oh dude, I like it. Because I hadn't even asked him about it. I was like, what do you think? He's like, oh, dude, I like it. At least that's what he said at the time. I mean, we'll definitely shout out at us and let us know if that's changed. But, you know.

You see a lot of this kind of with trends. Like I saw an article asking if server-side rendering is dead recently. And that's something that I've actually got my own. I kind of think it is maybe. But just this whole notion that things are... Because my business flow or my workflow doesn't jive well with these things, it must be dead for everybody. It's just ridiculous. I think if you're working on huge, large code bases that are difficult to test and feature

a lot of integrations then uh it's pretty rough to not have unit testing i had to make a change in another developer's code they were out for a little while and so i had to hop in there and make a change they added a bunch of tests and so it was nice that when i added my little thing and ran the test i could see one that failed and go check it out and figure it out and it would have been miserable to even figure out how to test it and hook it up. And this developer had an integration test too, but the database had moved on since then. I didn't know where it was. It didn't have good ways for me to hook it up from this thing that had been written maybe

even years ago. And so I've just had so much more problems with integration tests and end tests just being fragile or getting out to date than i have unit tests i've just never in my life have said gosh darn it there's too many unit tests here right and even um the times i've written them at worst i feel like they're extraneous and annoying and then you just delete them if they're not useful and you know i feel like you're talking about maybe single digits worth of hours of wasted work if that's the case but uh one bug in production you know one problem can easily eat those hours in you know a single single day or so i don't know i just don't i don't get i don't understand the hate here well i do want

in relation to this in regards to this article about the unit test operating fairness to the author i do want to to close out with his summary and see where we all land on it. Or I can tell you where I land on some of these. Because his main takeaways were, number one, in true developer form, though, he numbers these

from zero. So, number zero, think critically and challenge best practices. Okay, fine. I can get on board with that. I don't think that, I still think that unit testing is a best practice and we should continue doing it though. So I'm not swayed there yet.

And this whole testing thing, he referred to it as the testing pyramid. So he says, don't rely on the testing pyramid pyramid on the test pyramid, which, you know, more specifically the test pyramid, the base of the, the pyramid was a unit tests. And then the, um, I'm trying to find it. The second layer of the, was it was integration tests. And then the top layer of the pyramid was end-to-end test. And he was saying, like, don't rely on that. So I don't know. I can't get on board with that. But there's this other one, though, that is kind of interesting. It says, separate test by functionality rather than by classes, modules, or scope.

And I kind of like, okay, that's an interesting, cause like, I know that I've written unit tests where it's kind of like, um, where our structured is like, Hey, here's the class under test. And then here's the method under test within the class. I mean, we've talked about like that, that structure, like how I like to lay out my, my classes. Right. And he's, he's advocating for like, don't structure your test like that. I don't know. I mean, maybe. It's interesting. Well, where I think that that particular point ties in more specifically is, I'm pretty sure it was also, again, from one of the Clean code series of books where he talked about creating your own

test language that you would use, you know, and it's like all your tests will be written in that language so that it, so that you're, you're, you know, it was closer to your domain. You know, do you, do you recall that part? Nope. Um, so like maybe you would have like a, you know, a, a, a create customer method and, and you know, that, that, that test method could then you would be like create customer dot order item dot, you know, is in stock dot, you know, and so you could like change, you could have this like descriptive kind of language about your test, right? And so maybe that would be more in line with what the author here is describing about like testing the functionality.

Like if you were to go, if you were to take your testing to that extra level where you, where you did that kind of testing language. I'll say, I do want to read this article. It's long. It's super long. But in the summary, it almost goes back to kind of what we were talking about or maybe what I was mentioning there at the beginning is this sounds more like the domain-driven approach, right?

Like what you just said, right? Create customer, create order, something like that. Test what you're trying to actually accomplish with something, right? So your public calls, test to make sure they functionally work the way that they're supposed to instead of testing every single method in a class. And that's what he says kind of in his summary here is test for functionality rather than by classes or modules or any of that kind of stuff. And I think I can get behind that.

And if he's just saying that I can get behind that. And, and if he's just saying that, treat your tests like that as a, but that's still to me, Ken, a unit test, right? But I think he's,

he's trying to draw a line between trying to test every single method you got here. Here's where we're going to start to derail again. Right. Because remember that, that other, that other example that I told you about, like where he was showing like a unit test or i won't call him unit test he was showing tests that like relied on the file system or standard

out standard and things like that so he says aim for the highest level of integration while maintaining reasonable speed and cost so you know the point being like hey it's okay to use a file off the file system or or standard standard inner standard out for your test. If you know that level of integration is still going to be acceptable amount of speed and cost. Like, uh, okay.

I mean, you know, again, that's going to be problem. That can be problematic. What happens if now, uh, your build server is,

well, well, let, let's just say it's cross platform code. Let's say, you know, and, and you're running it on Windows, and now the build server is going to run it under some version of Linux inside of a Docker container. That path might be problematic now. I don't know. I don't want that to muddy,

you know, the, the, does my code work? And, you know, um, but then he says, he says, avoid sacrificing software design for testability. So this is going back to that other idea about like, you know, the, the level of abstraction and whatnot, like in the, we mentioned about like, Hey, if you have your, uh, um, your dependencies are, you know, are they separated or not? Right. And are they baked in or not? And then the, this last one though is interesting where he says, consider mocking only as a last resort. But again, I kind of go back to Joe's point earlier, you know, like, well,

I mean, depending on, you know, if depending on – if you need the mocks, if you need mocks and you need a lot of them, then maybe there's something else wrong there. Right, right. Maybe there's a bigger problem. Yeah, and, you know, we don't have to – I guess we've been stuck on it for – we've been beating this one for a while. Well, it was an interesting one. Oh, yeah, yeah yeah for sure i like it just i was surprised by so many comments uh kind of speaking to the idea that you know they're they're people getting crushed by trying to get to 100 uh code coverage and from what i hear from talking to people i got in the field like i would be so surprised if most code bases even had 25 coverage based on what i hear from like real people but then I see the comments on the

on you know these articles and it just sounds like you know people are having radically different experiences than me I guess yeah that's the thing like I want to see some of these code bases yeah I don't know but yeah so that was number one

we got 17 more questions here to go all right sweet one down all right my next one's really just kind of a rant so I don't know. But yeah, so that was number one. We've got 17 more questions here to go. All right. Sweet. One down. All right. My next one is really just kind of a rant. So I can just skip that and just. No, let's hear it.

Okay, fine. I was going to say, do you really have to read emails? Do you, if someone sends you an email, are you obligated to read it and respond? Wait, now respond is different. Hold on. Which question are you going to ask me here i'm so i'm skipping past do you have an obligation to respond i'm saying do you have an obligation to read emails and i i say this because i'm a big jerk and i've already i've always been bad

about responding emails and now i've gotten to the point where i'm bad about reading them and like i'll check my every once in a while scan through my email and i'll like i get so much junk and a lot of it's really nasty where the person, I'm sure it's a robot, but they're like, I've tried contacting you six times, and you've never responded to my email. Don't you want to have a call tomorrow to talk about my product? No, I don't have to respond to you. I get so much of that every week. Listen, if you don't want to talk to me, just respond back with either one, two, or three, depending on the definitions I gave you for one, two, and three.

Yeah. We get some nasty ones. It's crazy how much nasty. And the thing is, because of all that nasty stuff, I don't even like checking my email anymore. I miss so much good stuff. So, my mom calls me and is like, I sent you an email last week with your cousin Jennifer's baby or something. You didn't say anything. I'm like, well, that's because I kind of stopped checking my email.

Well, I'm sorry. You should text me. But that's where I've gotten with email. I've pretty much just declared – I've not even declared bankruptcy. I'm just choosing not to believe it exists, I guess. It's a wasteland to you. Well, those bad ones, just know that those bad ones are definitely robots. Oh, yeah.

I'm sure. It doesn't even make sense. But, yeah. I'm sure. Yeah. It doesn't even make sense. But yeah, it's just crazy to be like, you haven't responded. This is the last time I'm going to contact you. And you're like, look. And you're like, that's like number seven. Like, okay.

Listen, your phishing scam hasn't caught on yet. It's still not going to catch on. Yeah. I don't know. Maybe I'm a jerk for not reading emails. And I'm sorry if I haven't responded to you. It's because I haven't even looked. Dude, and you know the thing is, I'll pile on to it, is it's not just any one particular email service out there. Like, they all are just.

Google does a fantastic job of trying to weed out the garbage. But there's still just so much that it's. I don't know, man, it's like deflating. I know, I know you guys keep like zero inboxes. I don't believe in that.

Like I couldn't live my life. I would, I would be debilitated every day right now. I'm looking in, in mine and it says I have 12,180 on red. That's debilitating right there. Yeah. Well,

what I do now is like basically what I've started doing, because I love inbox zero. I like to kind of use it as to do, what I do now is basically what I've started doing because I love Inbox Zero. I like to kind of use it as to-do. But for my personal email accounts, the only one I check anymore is my home. And the thing is, I mean, sorry, my work email. When I go look at my personal emails, I look and there's so many and they're so old. So I kind of think like, well, I guess if I haven't responded to you in two months, it's probably irrelevant now. So I'll just do kind of like in inbox is it on red and

just you know i look maybe for the last day or two to see if there's anything important that's still relevant and then i just nuke all of them and then i feel like a huge jerk but also it's kind of nice just to not have an email anymore yeah that's why i don't worry about the zero thing like i'm not trying to keep up with that did you like auto respond it just is like hey i'm sorry you should tweet at me if you're a human but if you're like wayfair trying to sell me a couch or something like that you know or you want to have a meeting to talk about something tomorrow then no yeah i guess um i can't relate to either of you then because like maybe here's probably what it is. Maybe you guys get like 10 times the amount of email I get. Maybe that's what it is.

But I'm always like there's some emails that I can just tell right away from the subject. Like that's junk. I don't even care. Oh, yeah, totally. You know, except, except when maybe I do care. Right. And by that,

what I mean is like, let's say, let's say I get email from meetup.com right now. Uh, we're in a pandemic. I'm deleting all of it. If I, every time I see an email from,

from meetup, done, done, done, done, trash, trash, trash.

I don't even bother with it. Right. But you could be missing some killer virtual meetups. You know that, right? Just saying. And that's the thing. That's why I say, except when I don't. So when I'm in a mood for meetups and I see that meetup email come in,

I'll be like, all right, let me check it out. Which is it? Oh, yeah, no. Like the Amazon. We get tons of Amazon email, right? Like, hey, Joe, I see that you like this. Or Alan, I see you like that. And I'm like, yeah.

So there's so much of that email that right away, I might not even have to open it to be able to see, that's junk, junk, junk. I don't care. I'm not in the mood for this. Not in the mood, not in the mood, not in the mood. And then that way, I can, when it does get to the few that it's like, oh, okay, here's the five that I really want to take the time to actually read.

Then it's like, okay, fine. And then, you know, when I'm done with reading those five, guess what? I have zero unread emails. You know what's so funny about this is you guys remember years ago, like when probably Newegg was probably one of the first that started doing it. And Amazon was really good. Like you'd be on Amazon looking for something. And I'm talking years ago, 10, 15 years ago when they were still kind of the, the new kids in town. Right. And you'd be searching for something and then like you get distracted and you'd walk away from it.

And then later on, you'd have an email saying, Hey, I saw you were looking at this. You're like, I was, and you'd be excited about it. Like, Oh, you you you were kind enough to remind me right and nowadays you're like yo get off me like i don't want you to tell me that i was looking at this monitor and there's these 50 other ones that i might be interested in i was already in a rabbit hole and you just ruined me because now that's going to be another 20 hours of research so yeah i don't get excited about it anymore not not to hijack Jay-Z's question here about the email, but specific to Amazon, since you brought it up, the thing that has annoyed me lately that I've noticed,

and I don't know if they're doing it intentionally, just thinking most people probably aren't going to like bother to pay attention, but there'll be things that you'll see something on Amazon. You're like, Oh yeah, that's something I would want to buy, but it's more expensive on Amazon than what it costs anywhere else. And it used to be the case that when you would see that it was because if you

looked at the, like who it's bought or who it's sold and shipped from it wasn't amazon but here lately i've had cases where it was sold and shipped by amazon but yet it would be like there was one where it was 25 more expensive from amazon than it was to just go directly to the manufacturer and buy it directly from them. And I'm like, why? There was no good reason. It was not like I was going to get it any faster. Like literally, I wasn't going to get it any faster. So why was it going to cost me 25% more? And the only thing I can think of is just that you didn't think I would look.

Right. People are there. Did you ever know those people that used to love to go to flea markets? I know we all knew people that it was like, oh, they were hitting the flea market on the weekend. They would go there and buy stuff. And it was like, dude, do you realize you could have bought that in Walmart for, you know, I don't know, 10 bucks less. Right. But they thought because they were there, they were getting a deal. And I think people are just trained now that, hey, they're on Amazon. They got their Amazon store card. It's so easy to push that buy it now button

that's it right they're done so for some reason i don't know why but the mtx blue thunders were the ones that came to mind when you said that because for some reason, that was like the flea market brand. That's so funny, man. Good times. All right, Jay-Z, you got another one for us. Yeah, by the way, I just set up, on two of my email accounts, I just set up autoresponders.

This email is no longer supported. Sorry, I'm a jerk. So it's just going to automatically respond to every email like I might reply I might read this no it just says I'm not going to read it how's that going to work against spam though isn't that going to make your spam problem worse

yeah I guess I don't know I'm not going to know he's never going to look at it it's never going to hit his inbox oh I guess. I don't know. I'm not going to know. He's never going to look at it. It's never going to hit his inbox. Oh, I guess it might. I don't know. I'm going to sign out and never sign back in again. Okay.

We'll see. We'll see how it goes. If it's a real human that gets that, or if you're a real human and you send me an email to that address for some reason, and you get autosponded, just contact me on Twitter or something. At the Joe Zach. I'm still supporting that at this time. Until he turns on that autoresponder, that'll be

good. Yeah, right. Alright, I did have one more question. I think I just know the answer is my question was, are you ruining everything by working late? Yes. Yeah, I think that is the answer. I think it's a bad game for you and everyone around you and everyone in the industry.

So you should just do your 40 and do it good and that's it. I wouldn't even say 40. But if you were constantly the person that's like, yeah, I'm going to work from 7 in the morning until 7 at night because I got to help everybody out. And then I got to get my own work done. You're not doing yourself a favor, right? That's it. Yeah, if you're making mistakes and making trouble to begin with, even if it's worth more than you lose, everyone just hates you for it. Trust me, I know.

So just don't do it. Yeah, that was it. I'm so conflicted on that one i mean yes there's definitely a limit like if you're putting in 80 hours then yeah that's a problem yeah no no i didn't say i was gonna stop doing it i just said i'm ruining everything oh okay well maybe i mean here's the thing i think we've talked about this at some point in the past. Here's my biggest problem with this entire thing, right? When somebody goes in and they do project planning, let's say, right? A project manager, they're looking at the burndown rate because that's what they do because they need to be able to forecast how much work they can do in the future.

And if you are saying that you're only working 40 hours, which a lot of people tend to do, they won't put on there that they actually work 12 hours in a day on a single problem. And at the end of that, it's going to look like you only spent 40 hours, but you were really on the computer for 80. Then you are messing things up for yourself. You're not being honest with anybody. And all it does is perpetuate the cycle to where they're going to be like, well, I mean, dude, Jay-Z is just a beast. He can get, he can get three times the work done that anybody else does not knowing that he's working twice as much. Right. And that's, you're setting yourself up for, for constant pain.

If you are allowing that to happen. Now, the three of us, we always, we kind of, I don't know if it's our nature. We put in extra work, even if it's not just at the keyboard,

like we'll be researching and we'll be doing other things, right? Like we spent seven years doing this. Yeah, exactly. And so there's, that's different. But if you are truly dedicating your entire day, like you're 12 to 14 to 16 waking hours in front of the keyboard. Yeah, man, you're ruining it for, for yourself.

And you're making the rest of us look bad. Oh, right. There's that too, because then it's like, well, he's getting his work done. How come you're not getting your work done? Well, dude, he just spent 14 hours in a day. See, I wasn't even thinking about like you're coming at it from the approach of like, Hey,

you're, you're working 80 hours, but you're only claiming to work 40. That happens a lot. And yeah, well, it depends on your industry though. Right?

Like if you're in a services industry, all right, you're billing then industry and you have billable hours, then you want to bill those 80 hours. But guess what? You're only getting paid for the 40. And so you are incentivized to track those hours because especially in that type of environment, you're going to care about your billable hours, like your overall utilization at the end of the year, right? It's going to matter. So, you know, you might be tempted to like bank up some of those extra hours like that so that you can have some time to relax later on, especially like, you know, if you have like high utilization targets i mean i've seen some organizations where like you know the utilization target was 97 percent of the year which means you can hardly take you can't take vacation let alone holidays all right um you know so so that's where the rub is but like when you do go to those extremes, like the 80 hours, where I was kind of more thinking of is just the mental fatigue that you're going to have to work on anything.

If you put in an all-nighter, the next day, you're pretty much trash. You're not operating 100%. Yeah, you're pretty much trash. Like, right. You might, you're not operating a hundred percent. Yeah. You might be physically there, but yeah, to your point, you're probably operating at like 40%. So what is it? It doesn't do anyone any good that you, you put in those extra hours. So stop doing it, Jay-Z.

Yeah. That's the answer. I guess that means we should go play some overwatch. That's right. It's high noon somewhere. Call of Duty, man. Call of Duty. You know, I mean, it's still Overwatch for me.

I still love that game. That's still one of my favorites. I would much rather play Call of Duty any day of the week. Overwatch is too much team. I want to be Rambo. Yeah, I can't get behind that. it's overwatch definitely overwatch uh all right so how about this then for a question um also from Jay-Z is because if you don't like this question I want to make sure like let's make this clear that that's who you should take your comments to.

Is Kubernetes programming? So I guess if you're actually writing the code for Kubernetes, then yes, absolutely. That is programming. But kind of assume we mean the YAML. Well, you know, even aside from the YAML,l to me my argument is that it kind of feels like coding all right like there's no i mean if you of course like the helm is never far away hold up hold up we don't have feelings on this show yeah so but go ahead go ahead all right so yeah i mean there's the act of running yAML, which is terrible and is just a terrible idea. And we should stop that in Kubernetes, too.

But I do think I'm not creating classes, no interfaces. Very rarely do I have any sort of looping. There's lots of variables, tons of variables, because, like, you can't do Kubernetes for very long without tripping on Helm. Wait, you can do looping and then templating? Yeah, yeah okay sorry sorry yeah and so you know there is that but overall i kind of feel like you know even with the yamlification there's still a lot of creativity involved in how you set things up and how you test and how you read things and how you debug because whether or not kubernetes is coding i think everyone who is working with it will agree that you sure do a lot of debugging wait so that's why the coding that's what i'm saying wait wait well i've just proved this point

well i was going to argue that like if you can't write a unit test in your language, then is it really a programming language? Helm has hooks for tests. It does have tests. But that's Helm, not Kubernetes. So that's not the same, right? Okay, but let's be fair. Let's be fair here.

Kubernetes isn't Kubernetes without Helm. No, no, no. No, it totally fair here. Kubernetes isn't Kubernetes without Helm. No, no, no, no. No, it totally is. You could totally have Kubernetes without Helm. You can, and you'd be insane, but you can't. Technically, yes. I mean, you can have Docker without Kubernetes. You can have Docker without Docker Compose.

Right. But you wouldn't because that's insanity. So, again, you can't write a YAML file that is a unit test. I'm just going full circle back to the previous conversation. So, oh, man, this was hard. So I would say that Kubernetes is not a programming language, right? Or it's not a programming. It's not programming.

However, I completely agree with the fact that if you're getting into Kubernetes, you were learning all kinds of things about networking. All those fun sysadmin things you never wanted to know. Right, right. Like basically every Linux command that you've never understood that you've seen on Stack Overflow that you copy and pasted, you will become a magician at that kind of stuff. I'll never need to know this stuff. Right, right.

I said, what's this? Just copy and paste it. All right, cool. It worked, right? I honestly think that, man man i've mentioned this before i'm curious what you guys take is on this because i love this it's not programming in my opinion it's totally not programming but it is a really good way to understand how things interoperate and how the underpinnings of everything works but But this is where I was going.

Have you ever had that friend that was just like a Windows developer, right? Like they spent their entire life on Windows. And so they just lived in Visual Studio. And so everything they ever did was F5 to run. And if they made changes to a class, it was all in the IDE. Everything was in the IDE. And then you start, like, not even going into Linux and Vim, right? Like, we've all seen Vim magicians, and you're like, oh, my word. Like, what does that say? Casey and I got schooled by one. Right, right. But if you've ever taken one of your Windows friends and they've seen you operate, like, doing Docker or Kubernetes commands, they just kind of stare at you slack-jawed like, dude, what are you doing?

And you almost feel like a magician. Kubernetes forces you to work those muscles that you've never had to deal with before. And you will actually be a better developer for doing it, is what my argument is. Even though it's not programming, it gets you in the mindset of how to troubleshoot and resolve things and figure out how things work because of all the tools that you have to use, all the command line type tools that you have to use to make it happen. So that's where I am. I don't think it's programming, but it can make you a better programmer.

Oh man, I can't find the, um, the, the tech. I thought we did like a community talk where, uh, Jay Z and I got the lesson on, uh,

VI and Vim. That was awesome. It wasn't a community talk. It was, um, Zach. But I thought we recorded it, but okay. Oh, we did. It's on his YouTube channel.

Oh, it's on his YouTube channel, not on ours? Yes. Oh, okay. We'll have a link for that. I'll look that up here. I just can't pronounce your last name. Sorry. No, it's I-N-G. So, Jay-Z, you posed the question. Well, no, Outlaw, you posed the question.

Is Kubernetes programming? In my opinion, I would say no. It's configuration is what it is. Configuration debugging. Well, no, no, it's no different. Okay. It's no different than if

you set up like a silent install script for a bunch of installers and you're like, okay, let me, I want to automate the provisioning of a server, right? So I'm going to spin up the server and it's going to run and it's going to install everything. Okay. Did it install everything the way I wanted to? Okay. It looks like it did. It looks like it did. Okay. Now can I actually make the connections to and from that server? Like I expected, let me test

that. Let me test it. Let me test it. Oh shoot. I messed one up. Let me go back and change something else. Okay. Now I'm going to like retest that whole configuration again. Did it work again? Right. It's configuration. It's not, it's not, again. Did it work again? It's configuration. It's not programming. It's necessary, and it's awesome, and I'm not trying to belittle it at all. Totally. But it's not programming. I agree with that.

You, Jay-Z? Nope. Nope, what? No, I don't agree. You think it's programming? It looks like programming. It feels like programming, and I do a lot of debugging. So I'm going to say it's basically coding, just like HTML. I mean, Go templates, or Go though, if you're doing Helm specifically, there is programming type functionality that goes into that templating type stuff that you can leverage.

But it's not full on. It's mostly conditional type things, right? And chaining of commands together. So I don't know. I mean, it's pretty much, it's like, it reminds me of the days of like creating an image of a hard drive. You would sit down, you would take the time to install everything on one box, then you would take a snapshot of that hard drive, an image of that hard drive, and then you would lay it out on another hard drive.

And that second one, you might make sure, oh, let me make sure that everything that was specific to a, you know, like, like a DNS name or something like that, like that I needed to have variable and make sure like I remove those bits from the image. And, and then when I like try to reuse that image the second time, like make sure that those things took, you know, that, that it prompts me for a new activation key or something like that. Right. Right. That's the way I view it. Is it like, that's the type of testing you're doing. Yeah, I agree. I will say what Kubernetes kind of forces on you is back, I don't even know, I don't want to say back in the day, but in the world before Kubernetes was really a thing, like all of this stuff happened on hardware, right? Like if you had a switch or

a firewall you had to open ports to, and you had routers that were doing things and you had all this other stuff, right? Like these were all devices that you sort of managed independently, right? And it was all configuration type stuff, like what you just said outlaw, right? Like you're going to go

and you're going to open up a firewall port. You're going to go in and you're going to set up some routing information in these tables and all that kind of stuff. This is all stuff that is now virtualized that you do in Kubernetes. So if you ever wanted to learn about all the nitty gritty crazy stuff that has had to happen to make your applications actually work in the real world, it's all baked into this virtual ecosystem that is called Kubernetesubernetes and it is nuts what you can do with all this stuff well and going back to the devops handbook right like if you recall there was a one one of the earlier chapters that we talked about in the devops handbook where they were talking

about how uh you should commit things like your firewall rules right like that that would be something that you would commit. And, you know, with a configuration like Kubernetes, you actually can. You do. Yeah. Like it's more in your face the, you know, the capability and, you know, to be able to do that. So.

Yep. I don't know. I feel like we ended at yes, yes, no. Or was it no, no, yes? I think it was no, no, yes. No, no, no, yes. Wrong, yes, no. Or was it no, no, yes? I think it was no, no, yes. No, no, no, yes. Wrong, wrong, right. I don't see that one.

So we're at least 50% is what you're saying. Well, I'll leave it to the math gurus to tell me. Today's episode of Coding Blocks is sponsored by Datadog, the unified monitoring platform for real-time observability and detailed insights into Docker performance. Enhance your visibility into Docker orchestration with a live container view and easily detect clusters that are consuming excess resources using an auto-generated container map. And have you seen, it's actually pretty cool if you've never seen it.

There was a new one that they had for the blog post. They just introduced a similar one for Kubernetes where you can see like everything is happening. Same, similar kind of concept. I'll include a link to it in the share notes. But the container maps, it's really cool to be able to just see what's happening automatically. Yeah, I just Googled container map Datadog and I was able to instantly see the cool beehive kind of visualization there it just looks really neat yeah and uh it's really well designed for uh for like small or large uh large numbers of containers so that's really cool it's uh it's really smart

so i recommend you checking that out and uh while you're there notice that out of the box data dog collects critical metrics for each each Docker container and you get immediate visibility and aggregated and disaggregated service level traffic. Yeah, and if you've captured anything that we've said from the DevOps handbook, collecting those metrics is critical. So we can't stress that enough. I mean, Datadog is really right up there with all your DevOps needs. It's pretty much like they took the DevOps handbook and just said, hey, let's make a company based on the concepts in this book. Try it today. Find out for yourself why they're awesome. Go start at your 14-day free trial and receive a Datadog t-shirt after creating just one dashboard.

Visit datadoghq.com slash codingblocks to get started. All right. So you guys know that we love it when you take the time to go and leave us a review, guys, gals. It truly does brighten our day and it's something that we look forward to. So if we're keeping you company in any way, shape or form, while we're all stuck at home here for the past five,

six months, you know, and you find yourself with a few minutes in between washing dishes, taking care of kids, taking your dogs out, feeding your cats, all that kind of stuff, you know,

definitely go up to coding blocks.net slash review and just, you know, drop us a line and tell us you appreciate it. And, and that re we read it and it puts a smile on her face and we truly do appreciate it. So yeah. Thank you in advance. If you go ahead and do that. And with that, we head into dad jokes. You didn't see that coming, did i didn't all right so i got a couple here from uh i think it

was from mike rg let me double check that oh make sure i got that right no it's just mike what we got a new mike there's too many of us we've replicated oh no it threw me off because he changed his profile picture. All right. So the boss walks in and says, where have you been? I've been trying to find you all morning. And I said, good employees are hard to find. That was pretty good. So with that, we head into my favorite portion of the show, Survey Says.

All right. A few episodes back, we asked, what is your meeting limit? And your choices were, one is too many. There is a reason I work with computers. Or less than five hours per week is okay, so still have plenty of me time. Or I can handle 10 hours a week, but ain't nobody happy about it. Or lastly, bring it on. The trick is to mute when you go to the bathroom. All right. I always forget who went first last. Bring it on. The trick is to mute when you go to the bathroom.

All right. I always forget who went first last. I think Jay-Z did last. Okay. So, Alan, you go first. Which one do you think and percentage? I'm going to say this is what people's limits are. I'm going to say less than five hours a week is okay. And let's go with, let's see, 40%.

40%. That's confidence. I think so. Yeah, I think so. Okay. Okay. I'm going to say one is too many with 30%. One with the

top vote. No. Okay. One. One meeting is too many. Okay. Just want to make sure we're one. You know he added three meetings to my calendar for today.

Yeah, right? That's why I'm double checking. I wasn't? That's why I'm double-checking. I wasn't happy about it. I'm overdrawn on my meetings. You're going with one. I just want to have this on the record so that the next meeting invite I get from Joe Zach, I'm going to be like, one, sir. I can just reply back.

I can't help it if y'all need my guidance. That's so great. What a great answer. I can't argue with that answer either. Right? Okay. All right. I know what my autoresponder is going to say.

If email from Joe Zach and Calendar invite, respond back with one, sir. All right. So Alan is going to go with less than five hours per week at 40%. And Joe, you are going with one is too many with, I think you said 30%. Yep. Okay, 30%. And the winner is... Well, now it feels awkward.

Like, for those watching it... You know I was flexing. And you see the gun show come out here. That's right. You know, you're blinded by the swoller eclipse over there. That's right. Yeah, this is awkward, but yeah, it was Alan. Alan won.

Of course. It had to have been 60% or 70%, I got to guess. Yeah, it was 54%. Yeah. Was one even in the top three? Well, I mean, there were only four choices here. That's what I'm saying. I don't think it was.

So you had a really good chance of it being in the top three. That's what I'm saying. I still don't think it was. Oh, it was in the top three. Yeah. Come on. One of them was bring it on. Of course, one is too many had a had a good chance yeah yeah so uh yeah i don't know are we really

surprised by that though i mean i'm like your meeting limit like that seems about spot on as to what you'd be willing to take now yeah are of us, do we go into more meetings than that? Like, oh, yeah, sure. Yeah. I mean, we don't like it. We're not happy about it. But, okay. Well, let's see.

I'm tempted here. Like, do I go with another joke or do I go with a survey? So how about if I say what the survey is for this episode first? And the survey is, do you eat at your desk? And your choices are, yeah, you don't eat at home too? Or, no, never. My keyboard is a shrine to purity. Or, no, wait no wait why you have something

which i mean you know could be worse we probably should have like put out like an option there about like uh you know yes but only with like you know if i like dexter proof my keyboard you know so that i could so i don't get crumbs in it or something like that. Maybe I should have added that one as an option. No, well, too late. There's no way we could possibly add a fourth option. That's right. That's right.

It's too far gone. It's locked down, man. Yeah. Clearly, you don't understand how these surveys work. I mean, this is science. We can't go messing around with science. That's right. All right.

So one last joke, also from Mike Harjee. And he says, my son kept chewing on electrical cords, so I had to ground him. That's amazing. But wait, there's more he's doing better currently oh no and conducting himself properly

oh that's excellent oh my gosh thank you Mike RG very good it doesn't hurt that we record super late at night because these things are always funnier than what they probably are. Mike or G, do not listen to him. These were great jokes.

It had nothing to do with time of day. These would be funny at, you know, a good, what's a reasonable time? 11 a.m.? Maybe. Yeah. This episode is sponsored by secure code warrior secure code warriors gamification lets you learn how to write secure code from the start and identify the bad code already present in your application and i know you're like wait how could there be bad code right there's no bad code in my stuff you know you're going to find stuff that you didn't think was bad,

but if you take some of these assessments, you're going to realize like, oh, oh, whoa. Yeah, for sure. And for me, it was very eye-opening to see just how hard it can be to find an issue if you don't know that there's one there or if you've got a lot of code that you need to look at in a short amount of time. And so what I really like about Secure Code Warriors, the way they've got their challenges

organized are very much like real world situations where you've got a project to look at for problems. And so, for example, now my latest side project, I didn't take security seriously enough. I didn't start left. And now I've got, let's see here, adversary profile. Daniel Pytho is attacking me um because he's well known for targeting world leader companies that sell user information and the threat file profile in this case for my go api is sql injection so i'm able to go and enter this game mode and complete

a couple tasks where i basically find and uh you know find the the places in this code that are open to vulnerabilities and then select the appropriate actions in order to remediate. And I'm looking at this project now. There's like, I don't know, maybe 20 Go files here that I've got to kind of look through. And I can get some hints, which reduce my score. But anyway, the point is it's all just really cool. And I'm learning a lot about Go API right now, which is also really cool. Yeah, and I'm kind of torn because, you know, I mean, we had that whole conversation about, like, if Kubernetes is a programming language, but they have Kubernetes as, like, one of the challenges.

So it's kind of like, I don't know. I mean, you're not helping me out here by saying that Kubernetes isn't programming when there's, like, a whole section of challenges on it, just kubernetes so i don't know but here's the thing though like it is pretty cool because like you could set up your organization uh to use a code secure code warrior so that they could learn and you can actually like set up assessments for the members of your team and you can like set up uh tournaments to like make it more fun right right? Because, you know, I mean, we've kind of enjoyed, we kind of enjoyed teasing Alan like when we beat him, right? I mean, just a little bit. Oh, yeah. Yeah.

I mean, you know, we might have a couple more points than him right now. So, you know, that's always kind of fun. But, hey, just as like the, you know, how we've talked about how it's important to like have metrics and everything. There's like literally you can go see your statistics as like how well you're doing and track your own metrics. And they've got like little dashboards to show you like, hey, here's your average strengths and weaknesses. Like, you know, as if I wasn't feeling bad enough about myself, now I have a chart to

show me where I'm messing up. But, you know, that's me though, right? Because you're going to do awesome on this thing. So yeah, listen, uh, head over to discover.securecodewarrior.com slash coding blocks to start your next game and score 5,000 points. And you get a cool t-shirt that's discover.securecodewarrior.com slash coding blocks. All right. So, yeah, I guess now it's up to the one that I was curious about for you guys. All right. So let me set the scene here just a little bit. Okay.

So let's say that you're going to create a project from scratch. And I'm not talking about just a library or a component or something, right? Like you're not trying to make the next grid for React or anything. I'm talking about you have this great idea. You're going to make a gazillion dollars. And so you now need to create this thing that you're going to deploy out to the world somehow, whether it's the web or whether it's a desktop application. But so of all the stuff we've talked about on this show, over 141 episodes now. Well, this is the 141st, right Well, this is the 141st, right?

So this is the 141st. So we're here. We're here. So what let's, let's say pick maybe the top three things out of this list. And if I'm missing anything, let's add it to it because while we can't modify the survey, we can totally modify this. Oh, this isn't science. I get it. I get it. This isn't science. This is just an experiment

without any kind of science backing it. What are the top three things that would be the most important to you when creating the said application that's going to make you, um, babillions? So is it features, right? Okay. okay i thought i was gonna get to say so features features is a good one automation so your ci cd pipeline your automated testing your deployments all that kind of stuff right unit tests dependency injection, ALM for those that aren't in the know, alerting, logging, monitoring, or security first.

What would be your top three here? I mean, clearly, anytime I start with an application, the first thing I do is I work on my authentication and make sure that it can tie into Twitter and Facebook and all that, and that it can scale to a billion concurrent users. Because if I can't do that, then it's already a loss. I failed already. I agree with that.

Okay. I knew you would appreciate it. I almost put scaling in here, but I was like, you know what? No. No, seriously. In all seriousness, I would say feature first. Okay, feature first. MVP.

MVP. And then everything else, like the ability to scale. We don't know what areas of the thing are going to be a problem yet, so don't try to focus on scaling first. You don't even know if your thing is going to be liked by anyone. So, you know, if you only get like one person a day, I'm sure it can scale to one person a day. So we got you, your number one is features. Features, definitely.

Because you got to even see if like, you know, get some feedback, see if this thing is even liked first. I mean, nobody, I don't think anybody's going to focus on unit tests as like the thing that they're going to like you know let me start with unit tests but how you're supposed to i i don't know well if it's tdd yeah um but i mean given the choices that you gave here well okay now if you're going to like see okay this is where you're messing up science because you're going back and re- have some unit tests alongside that development but i don't know if it's something that i would call like you know i i don't know the way it's called out three years uh you only pick three of these all the other stuff is just going to be terrible so you get you get to pick three of these that's it yeah okay uh. Okay. Uh, I mean, I, I, given, given that choice and everything that

you said, I would probably focus on features first. Um, I don't know about the alerting and the monitoring portion, but logging, I would have some kind of logging, right? Even if it, even if it was just like a log for J or a log for net, like, you know, it wouldn't have to be anything fancy. Or, you know, I can't remember the other one. What's the other current one now? Oh, man, I can't even remember. And yeah, I guess, you know, if it's something public,

then, I mean, security first seems like too aggressive because i'm assuming you mean like hyper secure no no just right like security you're gonna care about encrypting things you're gonna care about not storing plain text passwords you're gonna care about that kind of like i'm talking i mean i'm not talking about that's gonna vary by app though too though right because like not every app is going to need that. No, you are. You're going to need this. This is scaling to billions of users, and you're going to make billions of dollars. You have to care about it.

Well, I'm saying if your thing is like a Pac-Man, if your mission is, I want to create a CSS-based version of Pac-Man, you don't need security. But you're going to have to put credit cards so that people can play Pac-Man. So, yeah, then then in that case then i guess i'm gonna i'm given the choices i would have to say security all right so outlaw feature a l capital l m and then security all right jz you so i i have to be in the butt and draw a line this is fluid this is fluid fluid line so if i

think this project is going to be less than three days 24 hours worth of work features features features i don't even care about the rest just you know i'm trying to poc something i don't even know about the three-day limit it could be a week long and like features are the primary i would agree with you there well so i'm gonna say three days because i feel like there's two things that we mentioned here

that just make it so much easier to add features and uh at least for me i just find motivational uh maybe maybe that's a bit of a stretch for one of these. So I'm going to go ahead and say my first is CI. And this is something new this year. I've kind of tried a few things. Maybe that's the reason I haven't published anything in the last seven months or so. But my idea here is basically getting CI set up really early in the process so that if I'm doing a website it starts publishing before i even start doing the content and you know i i recognize that's probably backwards but uh i just like the idea of always publishing and like if i'm not publishing from

day one then there's such a good chance i'm just never going to publish because if it's not easy it's probably not going to happen so i want i want to be able to show people my features as soon as possible at this point i kind of feel like being able to show and share my features is just as important as having them because if i can't share them then i'm just describing them you know but um i don't think you mean ci uh sorry yeah cd ci c i would just be like it's all part of it well no ci is literally just like integrating your code integration that's just right like a get repo is c i only work in one branch yeah i don't i don't go to multiple branches until we're at the six month mark yeah i gotcha okay, so CD. You're absolutely right.

Yeah, so delivery. So that's kind of where my head's at now. Maybe I'm just skewed. But apparently, according to you guys, I'm not even coding lately. So, you know, whatever. You're in meetings. It doesn't matter. Yeah.

Now, number two, this is a bit of a stretch. I just like it. I like dependency injection. Working with things like Spring and things like React, injection working with uh things like spring and uh things like react where i've got like things like context uh where i can just pass my stuff in or grab my stuff in from where i need it and so i don't have to do so much plumbing so i'm just tired of typing i'm tired of plumbing i just want to be able to grab stuff that i want i don't want to do singletons i want to be able to get my i just want to have my stuff just shoved to me. So if I need something from session or if I've got some service, I just

want to reach out and grab it. I don't want to pass stuff down the chain anymore. I'm hashtag over it. And so I think that if I get that started from day one and most frameworks that I work with nowadays, like they just kind of have that built in. So just a matter of kind of not screwing that up. Then the third, of course, is features. So I feel just a matter of kind of not screwing that up. Then the third, of course, is features. So I feel like if I set up a good pipeline, get a publishing, and second, make it easy for me to not have to worry about plumbing, the features will just flow.

Man, you know what's so crazy is? Yours is super close to what mine is. So I also am buying into the automation, the CI slash CD pipeline. And part of this is the series we've been doing. So I think it's fundamentally changed my life. That's one. But the other thing, too, is I think I mentioned to you guys about one of the MS Dev Show episodes where a guy was creating like the stock thing where he was checking and he was like, it's because he set it up at the very beginning. He never had to think about it from that point on. Right.

Like every time they committed code, it would build. And if everything was fine, then it could get released out. Right. And just having that automation takes take so much off of you in terms of just repetitive crap work that you just keep moving. Right. And that to me is huge. So I've bought into that. The next thing for me, I think features has got to be number two, because to what Outlaw and you even said, right? Like if you're not getting the thing out there for people to use, then it doesn't matter how perfect your code is.

None of it matters, right? It's never going to save the light of day. So features is my number two. And three, man, I'm super close to the dependency injection. Like for me, it's a toss up. I'm in between DI because I truly think it makes you write better code. Because to leverage it, you have to think about things a little bit better. At least that's kind of how I see things.

But I'm also big on this whole alerting, logging, monitoring thing, because without it, man, like we've been talking about in this past series here, you're blind. You're blind to everything that's going on.

Are people using your features? Are your features working? Are they failing? Is there stuff happening that you have no clue about? So I am straight up torn on these two, but I think I'm leaning towards the ALM side of the world here. Just getting that stuff baked in early so that you have your automation, this stuff goes out as soon as you plug a feature in. And now when that thing's out there running, you know whether or not it's performing how you want it to.

And if you go that route, you can even start doing A-B testing whenever you want because you can sort of monitor, well, you know, 20% of the people are using this feature, 80% of the people are using this other version of it, right? Like, I don't know. So that whole – go ahead. it, right? Like, I don't know. So that whole. Okay. Go ahead.

No, no, no. Sorry. I was just going to say that whole ability to be able to measure things and to be able to respond to things when they happen or they don't happen or whatever is super appealing to me. So, so yeah, I think the automation, the features in the ALM. I mean, I like where you got some of the reasons that you gave, but part of the thing here that you gave was that you had to collect credit cards. Neither of you picked security? I'm doing that through Stripe now.

Come on. Right, yeah. I was going to say I'm offloading that to a third-party service. That wasn't an option. I was trying to sell you, man. You said that we had to pick secure. You said that we had to collect credit cards. Your credit card number has been stolen like five times since we started this podcast.

It's fine. Yeah, look, man, every health insurance company you've been with to this point has now leaked you. So we're fine. I'm disappointed. Hey, look, look, I'm going to be honest with you. So we're fine. I'm disappointed. Hey, look, look, I'm going to be honest with you. Security actually bothered me in this list because I know that it should be first.

But if I make, if I'm making something, make a billion dollars, I'm going to get it in there at some point, but I need to get my features. Well, I mean, I really loved the way Jay-Z broke it down. Like by the number of the number of, hey, if it's this many days, then do this.

If it's this many days, do that. Although I would argue that your three-day thing I think is way too aggressive because I think personally it's going to be like, if it's going to be something that you're going to work on for a few weeks, feature, feature, feature. That's the only thing that matters is feature, feature, feature. That's the only thing that matters is feature, feature, feature. But if it's going to be like, you know, beyond six months, then, you know, these other things start to matter more. Well, before launch, before a real launch. Yes. Right. Like, and I think that's the key, like what you're talking about, feature, feature, feature, cram it in there, cram it in there, cram it in there. And then when you really plan on putting it out so that people could consume it, then you'd to start really being concerned about security

and all that stuff. But we've talked about this in the past. It's a heck of a lot easier to bake security in at the very beginning than to try and bolt it on later and go, oh, I really screwed that up. For me, the way I think about

security is so tightly entwined with CICD that I kind of feel like CI, CD is like a prerequisite if you're doing any sort of thing with keys and deployments. And so, you know, I do think starting left or starting as left as possible is really important. So, you know, obviously security, the sooner you do it, the better it just I kind of feel like, you know, like aside from like storing, you know, storing your password in a password safe, like if you're actually deploying, you need to have that CD pipeline before you can really consider yourself to be in best practice. I mean, listen, if you think that just because you have a CICD pipeline in place that you automatically have security done solved for you, then there's some tests that you need to go back through on Secure Code because you're missing they they have a whole section of kubernetes and docker like right right you could have cicd in place and still have all kinds of security holes oh yeah i just mean without the cd cd then you're probably ftping somewhere from maybe from a coffee shop you've got some keys that are on that disc if that that disk fails, then maybe you lose your keys.

And I can see denial of service or something gets knocked over or destroyed or whatever. So there's a lot of bad things that can happen if you don't have the security kind of baked in. And when I say baked in, I mean baked into a pipeline, not hard-coded into your code. Right. I'm just sorry because I feel like I got duped into picking security because you said that we had to collect credit cards and then the two of you don't pick security as one of your three. Well, yeah. I mean, come on. That ain't right. I don't trust myself to do anything secure, so I just don't. I will say on the CICD thing that I think the big one for me is one, you get rid of the minutiae of just tasks to get something deployed.

That's huge. But for me, I think the more important thing is the repeatability, right? We've talked about this in the past, is you push a button, and it does it all exactly the same every single time. I didn't have to remember to go load up a file or bake in the secrets or any of that stuff. It's there or it doesn't work. And that is huge to me. Without having CI and CD

on other projects, it's definitely been a pain. I remember having a NuGet library and every time I would make a change, I would have to manually run a script and then publish the thing. But then I had a private key that I used to sign it and that private key was on my desktop but it wasn't on my laptop. So depending

on where I worked, I had to go do it. And so it just made, I would have some little change like, Oh, but I don't want to do it now. Cause I don't want to deal with the hassle versioning and putting this stuff up there and publishing and then updating the website, which was like a web deploy kind of thing.

It just been, there was like seven manual steps for every little, you know, text change or minor bug fix. And I just don't want to deal with that. I forgot to bump the Simver. Great. Yeah. Just stupid little stuff that is so easy to miss as a person. So, yeah. I want to embrace the joy of programming

through CIACD. Same here. It truly, man, we've said it before. If you ever get it and you never had it before, you're like, how did I ever do this without it? So, cool. Do we have any resources? I guess we do. We have the links that you had to the Reddit stuff. Yeah, we'll have some links in here.

There's also the video where, you know, the Vim tutorial that Zach gave to Joe and I, that would be interesting. If you want to learn a thing or two about them and I guarantee you'll walk out of there with like 15 things you learned about it. It was really good. All right. Well, with that,

we head into Alan's favorite portion of the show. It's the tip of the week only without Alan. Uh, Alan just had to step away. So we will continue on. So you want to go first, Joe? Yeah, the show must go on. Okay. Oh, that's right.

That's the saying that I should have said. Next time. Next time. Well, I didn't know we were allowed to just step out, man. I don't know. Maybe we'll be seeing some changes right here i'll be right back oh no backfired all right so here's my tip and i know it's going to be controversial with controversial with the outlaw oh yes especially based on what we talked about in this episode. Okay. So there is a UI in almost like a – I can't really call it IDE, but there's a UI for Kubernetes called Lens.

And it's open source. And somehow it also just got acquired by Mirantis, which is the same company that acquired Docker Enterprise, basically the consulting arm of docker from docker corporation earlier which is kind of weird but they also snapped up this open source ide and as much as i know we love the cli we love to type stuff and to know what's really going on and what exactly is happening when we do things, it is so gosh darn convenient to be able to click through and see and filter. It remembers things that you filter by. You can easily have multiple contexts and you don't have to switch your local context. So if you're doing something in CLI in one environment, you can just kind of keep it

running and easily pop over to another context, you know, or another cluster and go check on something without disrupting anything that you've got going on in your kind of local configuration. I mean, yeah, so I have used this. It is very cool to be able to like see and manage your Kubernetes environment. It is interesting, though, that you made that distinction earlier about UI versus IDE, because it's actually called Lens v. Kubernetes IDE, which I'm like, but there's no such thing. Yeah, we said it was a development, right?

Right, it's not programming, right? So how can you have an ide i don't know the ie for kubernetes i mean you know because the because the d is specifically for uh development environment right so uh yeah uh yeah i don't know it's just a integrated environment yeah uh maybe a integrated doer environment for for doers that need to do stuff. Yeah, it's great if you just need to do stuff. The best thing, in my opinion, aside from being able to pop over to another cluster to do something quickly without disrupting your local context, I mean, that's kind of number one for me. Number two is just the links.

I'll go click on a pod. Oh, let me go check out that config map. Oh, okay, let me go see something else. map oh okay let me go see you know something else just click click click boom boom boom and typing that stuff can be pretty arduous even with uh you know autocomplete or whatever you might have uh in in uh bash it's still uh nice to just be able to click and you don't have to worry about like oh let me change my context go do some stuff yeah and then you want to run that next command but you forgot which context you're in and oops you ran it in the wrong one and you're port forwarding over in this context and you pop over to the other one you go do something oh the ports you try to port forward

but that one's already balanced and i just okay let me increment and then that was the database let me go it just goes on and on and on so just anything to make that easier i think is great and plus if you're in a screen share or something i think it's much easier to be able to just kind of click through that than try to expect the person to kind of keep up with the things that you're typing. Well, very cool. Yeah, I'd be curious to see, like, you know, get some feedback on this because I know, like we said, we've used it and we both like it. But, you know, be curious to know, like, what others think of it, too. Interesting that it got bought too, though. I didn't know that.

Is that brand new information? Did that just happen this week? No. Probably within the last month or so. Oh, okay. All right. Well, here's my tip for you. Have you ever wanted to, within a running Docker container, have you ever wanted to within a running docker container have you ever wanted to use docker

yes have you ever tried yes i could i immediately like lost myself to the inception and my brain exploded for the rest of the day yeah i had to go homesick it's kind of weird, right? Yep. It's not technically recommended, but there are ways to do it. And the easiest way that I found to do it is you can, within inside of your running Docker container, you can bind its Docker instance to the host hosts Docker instance. So what I mean by that is that when you're in your, your, let's say you're on your Docker host and you do a Docker stats, Docker space stats, or you do a Docker space image, uh, space LS, right? Whatever the output you see there, if you were inside of your Docker container,

you're running Docker container and you bind it to the host and you do those same commands, you're going to see the same output, right? Because it's literally just showing you whatever the host is doing. So the situation that I found myself in was we, uh, we use Docker for all of our builds for our build pipeline. So that, that way, like, you know, the actual building of something can be consistent no matter who you build, who builds it, where they build it, uh, whether you're, you're building it for local purposes to like run and test something or, you know, because it's going to actually get deployed out as an artifact somewhere else, right? That way all the actual construction of the artifact is consistent. However, I found myself in a need where our Jenkins build agents weren't available.

And I thought, you know, as a temporary workaround for this, it'd be pretty cool if I could spin these agents up as Docker containers on like my laptop here. And then that way our build pipeline could still flow, right? But that's where this problem came in, where it's like, oh, hey, wait a minute, those Docker images need to run, would need to be able to like run Docker to build images with inside of the image. So they are very inception ish, right? Yep.

So, so here's the way that you do that. Uh, you know how you could do like a dash V to pass in a volume, right? So, so the syntax for this thing is the, the,

what I'm going to tell you, the syntax I'm going to tell you was for me to bind a Windows, a running Ubuntu instance of a Docker container version of Docker to the host Windows 10 Docker desktop environment. But it's all in a Unix kind of format, but it was, you know, you'd use the dash V like you were going to like mount a volume, but it's slash var slash run slash Docker dot sock, like, like socket or, you know, like the sock that you would wear with shoes well not for you because you're in florida florida man doesn't wear shoes but so so var var slash var slash run slash docker dot sock colon and then basically the same thing slash var slash run slash docker dot sock and what

that'll do is that bind that'll that'll uh bind the container's Docker socket to the host Docker socket. And then that way you can use Docker inside of your container. That's freaky. I didn't know you could bind anything except volumes. It didn't make sense. I mean, it's a dash V.

Yeah. Isn't that crazy? Yeah. And what's even more bizarre to me is that at least in my, your mileage may vary, but for me, I used what I would call like a Unix type syntax for that volume mount. And yeah, that worked. I can't remember what I was trying to do with that. I think I was trying to basically get an artifact out. So I wanted to do the Docker build and then take the thing that got out of – that was the result of that build and get it out somewhere else.

And so I was basically trying to do kind of a build within a build. Yeah. I gave up very quickly. Well, and that's what I was doing. That's pretty much what I was doing here was like within this running Docker container, which again, you know, it was basically at that point a Jenkins build agent, and I would want it to do, perform Jenkins builds. And so it would then, you know, publish those out to like an artifactory, for example. So it was creating artifacts and publishing the artifacts and everything. And, you know, there's things that like you can easily

take for granted with Docker, you know, depending on your use case. But there were some things where like to run like SnapD, for example, because Snap bit me because I wanted to run, um, Helm and, and specifically for Helm, like one of the easy ways of, uh, of installing Helm is, you know, with Snapd, you could just be like snap install Helm dash dash classic. Right. But, uh, Snap, you, you know, there, there's no supported way of running it inside of Docker. right so i couldn't use that trick so i had to like go through this manual process of like okay fine i'll download the the helm tarball i'll extract it and then move the files into the right places and so that i could have helm which i mean you know wasn't the end of the world but it was like little things

like that that is you know and and you know running docker within docker was just like a one of those other things because another one of the things like i never really thought about but um did you kind of take for granted is you know like there's the different init levels for uh like in like a unix kind of system like a posix type operating system you know that you could be running in. So there's like, you know, normal,

the normal multi-user mode, but then there's also like single user modes and things like that. So I never really took for, I never really thought about it, but I always took it for granted. The init level that you're running in when that Docker container is running. Right. So you're going to have things that aren't going to like operate like normal.

Like if you wanted to build up a, a container and run cron and have cron jobs run inside of it, right? Like, like maybe if you were going to like thinking, Oh, I'll have like a long running instance or, you know, and, and periodically I want it to run some kind of thing, right? Like, yeah, yeah. We'll go and install cron and then watch it not work. Watch it not get fired because you're not in that type of a knit level for it to run. Wow. Yeah, it's just things I never thought about before. I just completely take it for granted. Yeah.

I ran into something similar where I was trying to check a service account or something in Kubernetes. So I ended up installing kubectl inside a pod and doing some weird stuff. And I tried to do it in Helm too. And I ended up giving up on that too. So every pod has access to the Kubernetes was the kubelet or whatever that's on that instance. So you can talk out to

Kubernetes API just from any pod just built in. You can literally do REST calls unless you've got some stuff turned off, depending on your permissions, yada, yada. But what is awful about that is the REST API takes JSON

and it does not take YAML. So everything else, everything that everybody in the world is doing with Kubernetes is YAML, YAML, YAML. Everyone complains about YAML, YAML, YAML. so everything else everything that everybody in the world is doing with kubernetes is yaml yaml yaml everyone complains about yaml yaml yaml then you go to use the kubernetes api from inside a pod and they're like nope gotta be json i wonder what the decision was behind that yeah it looks like kubectl itself uh when whenever you interact with it it's basically responsible for taking your yaml converting it to the json and then sending up. I haven't verified that yet, but that's what it appears to

be doing. So like the brains and smarts for doing that sort of thing happens at, you know, basically the interface layer rather than kind of deeper in the API. And so it's a pretty big pain in the butt. But you said it's because you're, you're passing it into like a rest API, you said. Yeah. So maybe the reason why is just because they're there. The thinking was like, Oh, Hey,

there's, there's truckloads of libraries out there for Jason. You know, the kid like, uh, D serialize the Jason back into an object versus what's there out there. What's out there for YAML, right?

Yeah. Is there, is there a, it's like the for yaml right yeah is there it's like why bother with yaml on the outside and why don't we just do everything jason yeah yeah i don't know if you know the answer you should leave a comment because i don't know what the answer is didn't we already decide though that yaml

was another one of those um the the redundant acronyms. Oh, recursive. Yeah. Was it Yet Another Markup Language? Yet Another Markup Language. No.

Was that it? Or YAML? YAML is Another Markup Language. Is that what it's called? Sounds right. I don't know. This is why we need Alan. Yeah.

We're falling apart. YAML ain't markup language is what YAML stands for. We were close and yet so far away. It's another one of those recursive definitions that they made recursive after the fact, which is cheating. Yeah, like PHP. Because it used to be, yeah, another personal homepages, yeah. Yeah. All right.

Well, so I hope you've enjoyed our water cooler episode. With that, we ask that, as mentioned earlier, if you haven't already left us a review, we would appreciate it if you did. You can find some helpful links at www.codingblocks.net slash review. And if you haven't already subscribed to us, wherever you happen to find your podcasts, Spotify, Stitcher, whatever, iTunes, we're there. We would appreciate it in case if a friend happened to point you in the direction of us. When you're at CodingBlocks.net, finding those helpful links for the reviews, be sure to check out the show notes, examples, and discussion there. You, you know,

jump in on discuss and join in on the conversation on any one of the episodes. And if you go to slash slack and there's probably a link up there somewhere too, you can join the slack. It's very easy. Like how you said, probably there.

Definitely. Yeah. I've been there before. I remember seeing something like that. It's actually more specifically to join slack yes join the slack right um because you could auto join slack you don't have to send an email you don't have to send a twitter you could just join it uh and hey there is yeah the the link is join our slack so yeah just at the top of the page there it's awesome okay and so alan thinks he bails on the last five minutes of the show and

we go on for another two hours that's fine it's fine and make sure to follow us on twitter at coding blocks you can find all our social links at the top of the page of the website