Coding Blocks - The Twelve-Factor App: Port Binding, Concurrency, and Disposability

Episode Date: November 23, 2015

It's time for more DevOps fun as we continue learning about the Twelve-Factor app. This week we dive into the next three chapters: port binding, concurrency, and disposability.

Real quick, what's the biggest problem in developing for Internet Explorer? Internet Explorer? Only one? People use it. You're listening to Coding Blocks, episode 35. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at codingblocks.net where you can find show notes, examples, discussion, and more. And send your feedback, questions, and rants to comments at codingblocks.net where you can find show notes, examples, discussion, and more. And send your feedback, questions, and rants to comments at codingblocks.net,

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, welcome to Coding Blocks. I'm Alan Underwood. I'm Joe Zach. And I'm Mike Woutlaw. But first, this episode is sponsored by DigitalOcean. Over 550,000 developers have already deployed to their cloud. You too could deploy your own droplet in 55 seconds. Their options start at $5 per month and you only pay for the time used when your droplet is live. Use the offer coding blocks and get a $10 credit towards your new DigitalOcean account. All right. And so with that, let's get into the podcast news.

What? All right, we're done. Yeah. Yeah. I guess, what was his name, Pano? He'll be happy. We're done. Sorry, I was watching a Fallout trailer.

We really only have a couple things this week or this episode um first is jeff bellina wrote us wrote us about our or i guess my tip that i had on episode 33 where i discussed sp who too and he actually wrote in and said hey there's something even cooler and it is called sp who sp underscore who is active and he says it's everything that you love about sp who too and dbcc input buffer combined with being able to to show plan for the running sequel spids so that's pretty cool he did leave a couple of links that we'll put down here in the show notes and he also mentions as well that there is a free tool from, oh man, I've even used this company before sequel century and it's called plan explore.

And it allows you to see like the IO and, and the CPU for each of those statements as well. So very much appreciate the feedback. We're going to leave it in the show notes and people can go check that out. And I feel though, like since he didn't comment at all on the kill tip then he didn't he must have like stopped as soon as you said your thing he was like oh that's it i've heard i've heard the entire show and he stopped listening because

otherwise he would have definitely had some tips on the kill spid yeah there's i mean without that there's nothing so yeah very much appreciated that that's nothing. So, yeah, very much appreciated. That's a very cool tip. And I haven't gotten to play with it yet. I got this email today, so I'm going to, I'll definitely be trying that out here pretty soon. And then the other one was, we got asked a question on Twitter from Rebecca. And she basically asked, you know, hey, I've been spending time trying to learn this one language, and now I'm wondering, should I stay learning this one language, or should I switch over to Java or C Sharp?

Like, how do I know what to do? This seems like a song. Should I stay, or should I go? Hey, you want to break out? Oh, sorry. So I did write her back a fairly lengthy reply, and I'd love to hear what you guys think too so I told her I was like look my first thing would be is I'm not going and learning any kind of random language

just for fun like if I'm doing it I'm trying to apply it towards you know either work that I can do for a company or work that I can do for myself that can make some money or, you know, like there's usually a goal behind it. And so I told her, I was like, look, you know, if you can go and look at the jobs in your area and find out, hey, is there a lot of jobs for what you're spending your time learning, then I think you just stick with that, learn it well, get familiar with it. And then later on, if you need to transition to something else, once you know the fundamentals of any particular programming language, the specifics change a little bit from language to language, but overall, just knowing how the pieces come together, how they operate, you know, the methods that you use, the patterns,

those transfer pretty easily from one language to another. So my recommendation was, hey, if there are jobs in your market for what you're already learning, then stick with that. What are your thoughts? Yeah, I always thought it'd be cool to know one static, one scripting and one functional language really well, just because you know, you're pretty well rounded. And at that point, you've got your bases pretty well covered. But that was a couple years ago that i thought of that so now i have to add and javascript because everyone needs to know javascript now for some reason i actually think what she was learning that can't cover your scripting uh or did you mean like a shell scripting shell scripting oh okay okay. I mean, what, what are you, what are your thoughts outlaw?

Um, yeah, you know, I don't know. I mean, we, I felt like we, we kind of talked about this. We have an episode back about like talking about like,

you know, I think it was like, what do you want to be when you grow up? Something like that. That was the episode name. Yeah. Um, yeah.

You know, I mean, you can't, you can't avoid JavaScript. So like Joe said, that's definitely got to be on the list. I liked the added, you know, contextual bit that you put in there about like, well, you know, see what's going on in your area, right, and what your demand is. But then I also thought, well, that could really like, maybe really sway, you know, I don't know. I guess depending on, like, the workforce that's around you, it may heavily gear towards the language that maybe you honestly don't want to be a part of.

And that's fair, too, right? Yeah. But that could just be the demand in your area. So, yeah. There's a lot of ADA around here. Really? just be the demand in your area so yeah there's a lot of ada around here really yeah i guess maybe the defense contractors like lockheed and whatnot i think he meant abba i mean abba's more popular it's kind of weird though like i mean even even thinking about that like if your area is let's say like i don't know i would never suggest somebody go to some just really small language.

I mean, people will pick those up in their jobs if they have to. But, like, I don't know. I guess I would never try and stick yourself into a corner to where, you know, the only place you're ever going to be able to work is this one little spot in downtown area that's going to be a two-hour commute for you or something like that. So, I don't know. It's a really tough – That's the one danger about staying towards any kind of technology that's specific to your job.

Yeah, you'll be able to use it in your day-to-day, but there's that risk that you take to where the company may not be moving with the times. Right. And therefore, you fall behind. So yeah, you may be really up on whatever technology stack they're using, but that's not necessarily in your best interest. Yeah, in her case, she was actually, I think she said that she was going and taking classes on learning this one particular one,

and she wanted to know, hey, is this what I should be doing? I think it was Node and Python. Yeah, it was Node and Python. Let's see. Sorry, I moved away from the mic there james so i don't know i mean um but you know i i had like i guess my thing is try not to be add like most of us developers are to where you start something you're like you know you know, five minutes in and you're like, well, there's something shiny over there. Let me try that. Right. Like spend some time and get more intimately familiar with whatever you're diving into. And then that way you actually really start to understand how things work. And then when you move into something else, like I said, those patterns typically transfer

from language to language. So I don't know that that's my take on it hopefully you know that'll help some of you others out there who are in the same situation i mean we've got we got a buddy who loves uh erlang and haskell right and it is funny because i'm like okay yeah that's kind of cool but you're not gonna get me to touch it you know like why that you're gonna mention another friend of ours who's crazy about Go. Oh, yeah. He's a big fan of Go. Although I will mention,

I got really into Ruby a long time ago now. One thing about it is whenever you do pick up a language, especially if it's really different from the ones that you've worked with, you almost always end up bringing something back. So Ruby is so heavy into the blocks, procs, and lambdas that just kind of, you know, it's really helped me understand the link stuff in like C sharp a lot better. That's cool.

But, you know, so the language you mentioned though is one of the most popular ones out there. Like I would almost say for anybody that's trying to learn something, go Google, hey, what are the top 10 programming languages or the top 10 paying programming languages or something like that and then that way you can at least see what the popularity index is right and then you know that if you're getting one of those top five top 10 you're in pretty good shape like yep well yeah you may be covered you're going

to be in a in a competitive market right so you're to have to deal with that if you're in those top ones. Yeah, and then you can't even say that you'd be in good shape because it's so competitive, then financially it's going to be affected too. I don't know. Those obscure ones might actually pay more. Well, the obscure ones will, but you'll be stuck in one place. But like Ruby was one of the top paying ones right and so here's the thing stack overflow i think we talked about this once before didn't stack overflow have a poll on this yeah somebody

did but here's the thing like and i'm not trying to be uh i've interviewed a lot of people over time and it's amazing the amount of people who say they know everything and don't know much so even if it's a competitive market as long as you are somebody that is going to take an interview or something like that really seriously and you study up and you polish up I don't really see that being a problem and especially if you're somebody trying to get in at a junior level or even an entry level type thing it's a great way to get in the door and get a ton of experience. But I mean, personally, I would stick with one more popular languages just, just for the reason that, you know, there's going to be positions around. Yeah. So this is a stack overflows, 2015 developer survey, and we can have a link in the show notes for this as well but uh javascript anyone care to take give me a number on javascript because we've all said it so we know what's in

there like what kind of number like salary a percentage number like no in terms of popularity give me a percentage of where you think javascript ranks i'm going to say number two that's your percentage oh You said where it ranks. It's one of the most popular languages. I'm asking you to give me a percentage. What percent of popularity do you think JavaScript is? On Stack Overflow?

I'm going to say 40. Okay, Joe says 40% popularity according to the Stack Overflow or developer survey and alan says 80 so it was 54.4 percent was the popularity wow uh for that and that's actually down from 2014 where it was 58.9 and then let's see let's see if you guys can guess that the highest one oh man are you already looking at it you cheater yeah of course i'm not gonna play this game there's no game anymore oh

my god all right the number two one surprises me though joe are you looking at it don't look at it you're looking at it number two for questions i am going to say SQL. Yes, sir. Oh, my God. Number three? You're cheating. All right. Number three, I'll say C Sharp. SQL, then Java, then C Sharp, and then PHP. So, yeah, I mean, like I said, pretty much anything in this list right here, you can't go wrong with. So, we will definitely have a link in the show notes. And, you know, if you stick with any one of these you're in pretty good shape and javascript because it's now client side server side and any

other side that exists it's probably not a bad one to pick up so yeah um you know they go on to talk about like the most loved the most dreaded the most wanted if you've never seen the stack overflow uh developer survey there's definitely uh you know there's definitely some interesting little nuggets of information in there like favorite favorite text editor just don't even look just guess them them bad or no bad okay is it gonna be i'm gonna have to give joe as being the closest but it's really notepad plus plus oh i love the winner plus plus yeah vim vim was actually a uh uh number four well it was number three in terms of popularity but there was this other category that actually had more percentage but you know that's not one particular thing. So we'll give you Vim for number three.

Yeah. No one likes Vim, though. No one enjoys it. But hey, you're about to get blasted. The majority of people are on my side with their IDE. They like the dark theme. So I feel like I've been redeemed a little bit there. All right. This poll is total crap.

Although tabs won out over spaces yes sir i feel like wait what i do not like what were we talking about okay i think we were i think we were trying to answer rebecca's question and then i sidetracked us yep so man news section so long now all right so that's actually it that was all of our news so yeah we'll uh get into the topic then this is going to be part three in our discussion on the 12 factor app and just kind of a little refresher the 12 factor methodology is uh basically for writing applications where the end goal is software as a service but it also applies to other types of applications that you might be working on. And it grew out of lessons learned

among people that have built a bunch of applications, but basically from Heroku. And this time we're going to be talking about port binding, concurrency, and disposability. Alright, we're done. Yep. First one up. Wow, so we're already talked about all that?

I'm still on the Stack Overflow developer survey. You guys are already talking about the whole show. Well, we've gotten into the weird ones now, so it's a little bit harder to explain some of these items. So we hope you'll bear with us. The first one is port binding. You want to take a stab, Alan? I mean, I will. This

one of the three, this one ends up being about the shortest after you kind of understand what they're talking about. So when they say port binding, essentially what it boils down to is you don't, in your app, you don't basically rely on the fact that you're going to have anything on your server that's going to exist for you if you want something that your app relies on be it an http server or something like that you're gonna you're going to bundle that in your app and then you're going to bind to a particular port that you're going to listen on so it almost sounds counterintuitive to some of the other ones that you know when we talked about like dependencies right like this like this one specifically says that the 12 factor app is completely self-contained and they specifically call out bringing in like an

apache or a tomcat or something like yeah jenny wait a minute like wouldn't you ingest like and you wouldn't that be injected if it was one of the services right like because they had talked about email and that kind of thing previously so yeah this one kind of straddles the line a little bit um you know it makes sense though i mean it really does make sense if you want to be able to scale up servers quickly, bundling in whatever you absolutely need and being able to make it listen on a port means that you can scale this thing out anywhere. You don't have to rely on an OS version or anything like that.

It brings with it what it needs. So it makes a lot of sense. To me, the most interesting thing here is what it's not doing. And that's kind of like the old school. When I started web programming, you would have Apache set up. And rather than you worrying about scalability, it was more about adding a new website. So you would go in there, you'd add a new virtual host, or you'd go into IIS, you'd right-click and create a new website. And that was more of the focus was kind of how to run more stuff off of one server and vertically scaling.

And now this is really the total opposite of that where they're wanting to break out everything. And they're actually dissuading people from using things like Apache and IIS, which were, I mean, those were the mainstays for what feels like hundreds of years. Yeah, well, I don't necessarily feel like it's going away from a pat that they're talking about necessarily going away from apache but it definitely feels like like some of this i'm assuming that some of this they're they're implying that you know you would okay so like in the last episode we talked about the build-release-run process, right? And so I would assume that they're suggesting that some of that bundling for bringing in Apache or a Tomcat or something like that might happen during that release stage or the build stage, rather. Not necessarily...

I don't know. Am I saying that right? Because then... then yeah i understand what you're saying but i feel like um the way things are going now like even with asp.net you know five that like they're trying to get down to like smaller and smaller web services so rather than having this big battleship that's like you know httpd or apache which uh you know can support multiple hosts and you know can do all sorts of stuff. And that's all social security. And I mean, just tons of the config files are crazy for Apache. It's, it's getting down to where you're running these little things like, you know, Twisted or a Node web server or, you know, whatever ASP calls it. But things are just,

it's just a tide change, I guess. It's just different. Yeah. Yeah. I'm with you. Yeah. but I guess one of the things that kind of tripped me up, though, is you had mentioned the vertical scaling and whatnot. And I kind of, maybe because I was taking into consideration the previous chapters here, that I was kind of thinking, well, you could still have multiple instances of it and then the port be decided based on an environment variable or a configuration or something like that, right? So you could still have multiple versions of it running side by side. Right?

Right, yeah, it's definitely possible something like Apache, just kind of interesting to me that they're kind of pushing these smaller libraries. I forget the Ruby ones, but I remember when I first started looking at Ruby on Rails, they were using mongrel and fast HTTP at the time and I was blown away it's like why wouldn't you just use Apache but uh it just uh things are changing and that was like 10 years ago now but still feels new to me it definitely feels like it plays along with the idea of the microservice too yep yeah there's no question That's part of it.

But this is where too like maybe I'm trying to remember back to the first six. I think this is where like the 12-factor app starts to specifically deviate away where like some of these chapters are very specific to web deployment or web applications. Yeah. are very specific to web deployments or web applications. Because we talked about in the previous chapters that they weren't really specific to web. Like one of them was configuration-based that we talked about, right? Or dependency. I mean, there were just good things in there

that really applied to any kind of development that you were doing, whether it be like an iOS app or an Android app or even like a simple Hello World app. You know, there were code-based things that we discussed about that had nothing to do necessarily with a web-based app. But now we're starting to get into the chapters where it's getting really specific to network applications.

Network, but not necessarily web, because you could create some sort of app that you listen on a port, and maybe it's taking in EDI information or something like that, right? Well, they specifically, in this chapter, in this section here, they specifically call out HTTP is not the only service

that can be exported by port binding. Yeah, so basically anything that you're doing, even if you wrote a database engine, that's going to listen on a port if you have something. I mean, there's tons of things. The important thing here, though, is that, like, the main takeaway that I got from this chapter was that what they're striving for is that you should, your application should just be listening in on some port that could be configured. You know, you don't care what the actual port number is.

Right. port that could be configured you know you don't care what the actual port number is right it may be configured on on you know the client side um but or you know client being like whoever does the installation um but you're going to listen in on some port and you're going to respond on some port and so that's the service that your application is going to provide and you bundled it and and your yeah your things are bundled together to make that happen. And you're not expecting that your code is going to be statically, use static binding, for example, to be included into another project, right? Or I guess even dynamic binding. Instead, you're providing a service, which is consistent with the previous chapters that we've talked about so far. Yep.

And then one of the other cool things that they talk about here is the fact that when you follow this particular approach here, that means your app can also become a backing service for another app because your app could basically then be something that can be bound to a port that the other thing is talking to. So this is kind of a way to be able to chain additional things together. Yep. And, you know, actually one thing I used to shell out for all the time was ImageMagick. So it was basically like a little Linux utility for resizing images. So that was something I used to always have to shell out on. And now, you know, reading this,

it makes sense that I would write some sort of wrapper that would run, you know, basically a service under a port that would handle that. And then, you know, I could end up breaking that off into a separate box or something. And it doesn't make sense that my web application would be running this, you know, potentially CPU intensive operation.

You know, it should be able to break that off to another server if I need to. We've mentioned the Clearly Tech article many times here. I'd play a game with you guys, but you've probably already read ahead to figure out which one it's going to be. That's all right. Well, I guess we can still answer what we think it should be. Yeah, I'm not hurt a little bit by that last one

when I wanted to play with the Stack Overflow report. It did take me a while to find it on the page, though. If that's any consolation. It's not. It's really not. I would rate this one as being kind of low on importance. You know, I would go more medium

only from the scalability factor. Yeah, reading specifically from that Clearly Tech article, they have it rated as a medium, and they say that most runtime frameworks are going to give this to you for free. So again, if we were to take this out of the Heroku environment and put it into something else, right, like a IIS app, as an example, you're going to set up the port that your app is going to listen to when you configure your IIS application, right? But the one thing that you're not doing in that example is bundling IIS.

And this is where, like, some of these, like, starting with this chapter two, it's also going to get kind of specific to certain types of developed applications, right? Like, because you don't bundle iis and with your dot net application or you know web application then it kind of breaks this port binding chapter because you're not including it although with the later versions of dot net you might be doing this pretty soon right yep um but you're not going to be including iis though no not is but the actual core runtime that you could but what i'm saying though is that like they specifically talk about bundling in your apache httpd right right and that's what i'm saying like it starts to get

kind of this these this chapter and the next two start to get specific like you can kind of see where their mindset was but you know taking you know abstracting some of that away there's still good fundamentals here even though it might not you know be applicable to everything and that's the point i'm trying to make with i the iis example right so the next one up is oh wait wait wait what did they say the uh medium rating was for at like what reason they give behind it oh i said that because uh most runtime frameworks will give this to you for free oh okay got it yeah and that's where i brought up the is example right like you're going to do that configuration there yep right okay so step it into the next one chapter what is this eight yeah uh or part eight is concurrency and i

actually like this one it it's it feels it will get into it here in a second but but this one kind of makes sense so the whole point is to be able to scale out via a process model and horizontally yeah and it's kind of interesting so i mean we've all got some thoughts on this because this is where it all started feel very linuxy to me um but you know we'll talk about it here in a minute so what they say is processes are first class citizens in the 12 factor app and by that what they mean is the app has control over the various process types that exist and then assigning work to those process types. And some of the examples they gave is you might have a web process that you would, you know, handle any kind of HTTP traffic or anything with. And then you might have a worker process that would handle any kind of long running task.

Like Joe brought up like an image processing thing before like so you would assign these tasks out to these different process types I yep go ahead Joe oh sorry uh yeah I was just uh gonna say um it was starting to read on this you're gonna see a lot of stuff about like pid files and stuff like that and I've been working in Windows environments for a while so it was kind of a trip down memory lane um but yeah i definitely think scaling horizontally uh is you know definitely a kind of a web notion or a cloud notion but it's just good good practice and i think like it's kind of rare to work on apps now that don't have some sort of web component to them but was it just me though?

And I don't know when you guys read this, if you have what your interpretation was on it, but it almost felt like, well, now we're so much of this is talking about, you can see this direction that they're going. And I just mentioned, mentioned about the microservices,

right? And there's so many of these chapters that are kind of going towards that route. And that's the way this concurrency part feels. But yet at the same time, this one almost sounds like they're talking about like all of these individual processes are all bundled in as one thing. And then it's like, well, then you just points that they made on it was not only do you need to be able to task out your processes to different or task out your work to different process types, but you need to be able to not just do it on the same machine. You need to be able to do it across multiple machines. So that goes back with the micros factor thing is they say that you need to leverage the OS's ability to do the processes or some sort of package that's already on the OS.

And I think they called out Foreman was one and what was the upstart? Upstart was the other. So they say leverage those. Don't try and handle the processes yourself and the foreman was also a great example too because like i was reading up on some of that documentation too and that's where it made me it even brought this this thought that okay well you're describing a monolithic application at this point it feels like right even reading the form and stuff because you know they were talking about like well i'll have a i'll have a worker process to do that they'll handle processes off of this queue my

web process will handle this stuff and it's like as i was reading i'm like well why would those why shouldn't those each be independent pieces that are that are you know one's a backing service to the other right like shouldn't a worker process be a backing service to the web process and the web process doesn't care like you know as a developer why why should i have to care how many of these things i'm going to spin up right like you know i i don't i just trust that they're there and then the actual spinning up of that should be handled by the server or whatever yeah like a runtime decision yeah and then um the examples that they gave with Foreman, it definitely spins up processes per application instance.

So if you had 10 applications running on the server, then you're going to have 10 of these other processes that are associated with it, which is totally the opposite of scalability. You should be able to scale those independently. So I totally get where you're going out, Lon. I agree. And yeah, it's kind of strange,

but I don't think there's so much hammering on Foreman. I think that was just kind of an example of a tool. Oh, I don't mean to hammer on it by any means. Oh, no, I didn't mean you. I just meant they weren't laser focusing in on Foreman specifically. It's just kind of a strange tangent and doesn't really line up with the rest

of their kind of methodology, I think. Yeah, well, even in there's a diagram there where they talk about the scale going up and the workload diversity going across, right? And so on your, I always get the X and Y, X is going to the right. Yes. So, okay, sorry.

So your X is your workload diversity, right? And so in that frame, you have web, worker, and clock in their diagram. And then on your Y axis, you have web, worker, and clock in their diagram. And then on your Y axis, you have scaling. So for each web, you might have, maybe you have two web processes running and you have four worker processes running. So you're scaling up like that. And they're talking about doing this on the same box. But again, that's where it was like, well, why do I care?

Why do I have to manage that like it feels like if if i have to have one application that is configuring how many of each one of these things then i think i've done something wrong if if they're that tightly coupled that i got to do that in a configuration yeah it's weird if you think about almost from a web architecture standpoint, like if you talked about like Elastic Beanstalk or something in AWS, you typically set up things to say, okay, I need to scale at this point,

like when CPU utilization hits this or so. And so it seems like there should be something else sitting there other than you writing code to say push these. Well, that's why this one confused me so much and and you know i really i'm not a harp on this one but this one really was kind of confusing to me and reading it because it really did seem like it contradicted itself and other chapters because they talk about like okay so they give this example of the worker process but it's

supposed to be working off of a queue and they specifically mention that you know if it's you know any any items that it can't work on at the time then it'll put the items back to the queue like and when i think of queuing i definitely think of you know horizontally uh distributed you know or scaled applications right right i'm not thinking about like i have multiples of these workers processing on the queue that I've manually configured how many of them and they're all in the same box. But then at the same time,

one of the examples they mentioned was a clock process, much like a cron scheduler where that process's job is to schedule tasks to run on a certain, you know, schedule. And I'm like, why, why, why would I do that? Right. Why wouldn't you let the server or whatever handle that instead of you be trying to coordinate all that? Right. Yeah. So, so I say that because if anyone's listening and they're, they're more familiar with this 12 factor app and this chapter really you

know made sense to them i would love to get some feedback on and maybe better understand what they're getting at here because it really seemed you know even reading like some of the deeper links that they had in there it seemed like it contradicted itself and the other chapters. Yeah, it was a little bizarre. There's no doubt. And like I said, even if you take, let's get out of the Heroku context here, like this feels very Linux-y to me because you don't really talk about creating processes in Windows, right? Like a lot of that stuff is managed for you to a certain degree. I guess if you're talking about a schedule or something, you'd set it up in the window scheduler, but, but that kind

of goes back to what you were talking about before. Like you just let the pieces kind of handle what they're supposed to. This, this feels more like, okay, well I need to, I need to tell Foreman to create this process type and then I'm going to start assigning some work to it, which is not really something that you do in a lot of Windows type programming. At least not in stuff I've done anyways. One good point I thought they did make was that you should try to avoid your process of spinning up and managing threads. And that's because it's kind of an example of vertically scaling, you know, an example of the ImageMagick resizing. If I opened up a thread to do the resizing every time I got a resize request,

then I'm going to be maxing out that box when I should be looking at trying to do that either on a service on that box to start and then maybe moving that off to a dedicated box just for doing that. And so by kind of spinning off these own threads, I'm creating headaches for myself and kind of scaling in the wrong direction.

But then again, they also specifically say this does not exclude individual processes on threads i'm creating headaches for myself and kind of scaling in the wrong direction but then again they also specifically say this does not exclude individual processes from handling their own internal multiplexing right but it's discouraged i i think i don't know if they said that if i read that yeah so yeah they did say it was discouraged it yeah i i wish this one was more clear because i've loved every other part of it so far until i got to this one and i was like well because i really like the whole idea of the micro architecture like you know you know just building small little pieces of the puzzle and then getting them to all work together but this one felt like it didn't exactly mesh with that and maybe maybe it was

my interpretation or maybe it's their wording or maybe it's both and you know what's kind of funny too is the name just like what we've talked about what we've described in the graph that we've looked at and the reading that we've done i wouldn't really classify that as being related to concurrency you know to me concurrency is kind of running things you know like independently of each other. Not quite at the same time, like parallel, but you know, well,

the only part that is, is where they talk about scaling out to other machines on processes on those. Right. But yeah, I'm with you. So in terms of importance, you've already cheated. Why do I even ask?

It's already there. Yeah. All right. What am I supposed to do? I can't close my eyes. You were supposed to close your eyes. All right. So this one was rated low and I totally agreed with their reasoning on it.

Same. And according to Clearly Tech, their reasoning for giving it a low rating was they said, don't worry about this factor until you get pretty deep into scaling considerations trust your chief architect or cta to raise the red flag if this is going to become an issue for you and i totally agree with what you're saying like that's good advice because you know going back to you know we've mentioned the mvp as well right in the past in past episodes and and you know just get the product out well, right. In the past, in past episodes and, and you know, just get the product out there.

Right. Like that, that should be your primary concern. Get it out there. So. Yeah. Also, before we leave this one,

I did want to mention, um, there were a couple of programs that we had mentioned that I wasn't familiar with before. So I kind of looked them up and I just wanted to give you guys a, like a kind of, you know, 10,000 foot overview of them. Um, one was upstart, which is, uh, you know, it's, it's only Ubuntu. It's on

other Linux distributions as well. But, um, if you've ever tried to write a process that would, and I think we've all probably done this at some point in our careers, but you've write a process to try and see if another process is running or not. And it either, um, you know, monitors and alerts and let somebody know process is running or not. And it either monitors and alerts and lets somebody know either via email or something, or it tries to restart the process. That can get hairy quickly and you quickly start reinventing the wheel.

Well, Upstart is basically a nice, really low level set of programs for event-based starting, stopping, and monitoring. So it can do really cool stuff like restarting application as soon as it crashes, because it's based on an event being thrown rather than polling every minute or so often to see if something is still alive. So I thought that was really cool. And the other one we've mentioned a few times was Foreman, Foreman, which is a Ruby gem for basically managing multiple processes. And it's also kind of heavy on the Linux side.

And it helps manage either your upstart scripts or your init scripts. So you can do stuff like restart my application, and it will actually restart all the processes that are associated with that in the form and file. So it's a nice way of kind of grouping the things that you need for your app, the local things for your app, into these logical units, and it kind of handles the OS side of things for keeping those running and starting, stopping, restarting, and making sure it all is done gracefully. So I thought those were both really cool, and I definitely will be keeping an eye out for those. Yeah, there was one other thing I wanted to mention too, just going back to that whole thing about the low importance for the concurrency one and the concept of the MVP and just getting it out there. coincidentally watching a TED talk today and they were talking about like the key factors for startups and why startups have succeeded why they hadn't or why some hadn't and

the number one reason at least according to this analysis was the timing you know just you know getting it out there what was the timing know, getting it out there, what was the timing right and, and, um, getting it out there at the right time. So, you know, when we talk about the MVP, like sometimes it's just more important to get your idea out in the wild. Um, you know, if the timing is right for it and, you know, that means that you're going to have to come back and refactor and iterate on things later on. So it doesn't have to be perfect the first time. Yeah, I definitely like that. And we'll have some resources we like that mention some nice resources for exactly that sort of thing.

Yeah. So with that, it's that time of the show again where you hear me beg as always and so i'll do it um if you haven't already we greatly appreciate it if you'd leave us a review and if you have already um you feel free to tell a friend and we would greatly appreciate that too. Or if you've already left a review on one site and you want to leave another on another app, that's okay too. We don't mind getting multiple reviews from the same people across different sites. So, uh, yeah, we would greatly appreciate it. Thank you. This episode is sponsored by Infragistics. Experts in data visualization, Infragistics developer tools drive custom app development for any data visualization scenario on any platform.

And ReportPlus is an enterprise-ready, self-service BI dashboard solution that opens up your enterprise big data for end-user consumption. Head over to Infragistics.com and get your free trial today. All right. So let's get into this last part here. Let's just dispose of it. Right? Disposability.

That is the last chapter we will be talking about tonight. What would that make it? Chapter nine, I believe. So, uh, disposability. We already threw it away. I already lost my notes on it. Was that too soon? We should wrap it.

Nah. So, who wants to kick this one off? Me. I'm definitely thinking graceful shutdowns based on the name, but the official sentence is maximize robustness with fast startup and graceful shutdown. So, I definitely have been in plenty, plenty, plenty, many, many, many thousands of hundreds of millions of situations where

people are terrified to either shut down a server or restart a process because they just don't know what the heck is going to happen. And I think this is aimed at that. We haven't restarted this box since 2003 yeah how many times have you been in the company and they're talking about testing their their disaster recovery plan and no one wants to do it because they just they have zero confidence that they're gonna be able to recover with you know the mail server going down or something yeah and that's a fair enough uh fear to have yeah i mean they

when they talk about disposability here they're talking about like it being disposable meaning that it could start up or shut down at a moment's notice so that if you wanted to spin up a brand new instance of your app server then it shouldn't be a big deal to do so right and and bringing down another one so that everything rolls to the new one shouldn't be a problem. Right. And I feel like we kind of talked about this or at least we hinted on it a little bit. And I don't remember which one which chapter that exactly was. But it definitely feels like we talked about kind of hinted about that. And a lot of these are kind of tied together. I'm looking at the list right now i definitely know they are absolutely positively

into the whole uh you know disposability aspect from like i should be able to shoot boxes in the head i should be able to deploy things i should be able to spin up spin down no problem and everything should be stateless too so everything should just kind of bounce to the next guy and i should never have any sort of downtime yeah and one thing i we've probably mentioned these terms before when you hear elastic scaling all that means is it's able to grow and and contract back down right like if you need to to scale out to 100 servers from your usual three and then you know that spike is down then you can go back to your three servers or whatever i think you forgot a key word there though right automatically yeah yeah you don't want to manually be pushing a button yeah so it automatically expands or contracts

as needed yeah and and this this portion this chapter doesn't really call that out well they kind of do when they talk about beanstalk but um but it's really uh but that's kind of where it's going though, right? Right. You can see there's this path that these chapters have been going so far, right? And each one has been kind of building on this central theme and leading to the next one, right? And so this idea of being able to spin a process up or down quick in order to bring more of them up or more or or to take uh some of them down right you know going back to your elasticity um you know you can see like that's where they're talking about right and you know who does this well i mean this is a side note netflix

oh yeah if you want if you really want to think about a company that has to scale you know they have their prime time viewing the and yeah they're only like 40 percent of prime time internet traffic right so so when you think about it think if if you were to consider your application it got as popular as say like a netflix or something it's not like you can have somebody sitting in the room saying oh no our 10 servers are 90%. We need to scale up five more. You can't do that. This has to be something that can grow organically and come back down to size. So that's what this is about.

And they did have some really cool tips in here. Like one of the ones was strive to minimize the startup time, which is not something that a lot of people really think about, right? It almost goes back to being funny about what Joe said, like, oh, man, I don't really want to hit this restart button because it's going to spin and spin and spin. Yeah, I mean, they actually go a little bit further with the crash-only design.

Yeah, that was cool. The final logical conclusion of where this should go. Right. And, and in that they, they linked to a report that seemed a little bit dated, um, based off of some of the versions that they were talking about. But, you know, in that report, it was specifically calling out, um, you know, versions of software that, you know, their startup time on a clean boot, and, you know, here was the average reported startup time, versus the startup time on a crash reboot, and yet it was the faster time was on the crash reboot than on the clean reboot.

Wow. Which was unexpected. Yeah. Right? Do that on SQL Server and see which one goes faster yeah yeah and so so in here they reference like you know um again these are all dated but uh windows xp red hot red hat 8 and jboss 3 so you know different types of software across the spectrum right App servers and OSs and OSs. And then, but yet, you know,

the startup times. So like XP on a clean reboot, according to these results was 61 seconds, right? And on a crash reboot was 48 seconds, right? Now you hear me say that and you know, instantly like,

Oh my God, that's dated because right yeah this world of ssds like we were talking about in the last eight seconds and you know 60 seconds i want to kill myself if it takes that long yeah but and just the fact that they're talking about xp tells you a lot right but it was still some good information in it though uh you know uh about that the crash-only approach. Yeah, they also talked about their shutting down should be graceful. And by graceful, and we've all kind of worked with situations like this before,

if you shut down something, you can't just kill somebody in the middle of a process, right? The processes that are running need to finish, and then you close out the connections and you exit. And that's how you want it to happen and that's how it should happen and you should do whatever is in your power to make that happen but that means that you have to enforce some things like your request can't be the super long running request right they need to be fairly short-lived request a couple seconds long something like that um so no more uh kill 9? I think that's the one that just absolutely shuts it down right now. Well, if you do that, you should be able to handle that too, right?

Well, and that's kind of like, you know, I kind of teased it when I said there were some good things in this crash-only software design. Because that's kind of where that was going was that, you know, if you look at these systems that, why are they slower on a clean start versus a reboot? And the idea was like, well, then why not just write your app to always be able to, to, um,

to only do a crash start or a crash shutdown, right? Because if you're able to handle that and that's faster, then why have the other code and then have to maintain that code if it's just slower anyways, right? So just write your application to where it always handles that scenario, you know, and then you get the benefit of it, right? It was interesting, too, how they handled that in some cases. So one was setting up queues, right? Because the way like I've done some reading on RabbitMQ and done some listening, but you can set these things up to where if it can't talk to one of the boxes or one of the processes that's supposed to be doing something in the queue,

it'll just pop it back to the queue. And then that way something else can pick it up. And that's one of the ways that they talk about handling those kind of situations. Now, that also means, though, that you're going to have to have some sort of way of clean rolling back whatever was happening, right? If something was in the middle of a process and then it died, if it was database transactions, you need to be able to roll that back. So these are all things that you kind of have to build in and yeah i think they even mentioned a few queuing systems where they were talking about uh you know the the queue should be able to there there's some process that should be able to handle like if the if the worker process hasn't replied back in a certain amount of time or timed out that the job just goes back to the queue for the next worker to get it the nice thing is, now I do want to say like a lot of this stuff that we're talking about right

here is not necessarily easy code to write because you have to handle a lot of different situations, right? But if you do implement something like a queue, because a lot of queues do have that stuff built in, you can, you can almost offset some of your own programming into functionality that's already built in other stacks. So it's something to consider.

I mean, a lot of people don't use queues, but there's some benefits to be had by leveraging that kind of functionality. Yeah, one example I think of here is, I've done this a million times incorrectly, is if I have some sort of process that needs to do a bunch of work, I will query all the things that need to happen in one query, and then I'll loop over and do each one. And the problem is, if that's, you know, quits in the middle or something, or if that process gets run, say twice, then you potentially start doing some of these things twice. And a better approach is to basically, you know, back to the DB example, is you basically, you know, query for one row, do that work for one row, then query another one.

Now I can spin two processes off at the same time and it's not a problem. And if it, you know, gets killed in the middle, I can start it back up without worrying about what's going to happen. And basically what I've done there is just reinvented a queue in, you know, a database. Right.

I mean, not to harp on the crash handling design because I don't want people to think that they should just go and in you know a database right i mean not to harp on the the crash only design because i don't want people to think that they should just go and uh you know hit the power button on their computer to shut it off instead of doing a graceful shutdown um but uh you know in this chapter though they do say that the the 12 factor app is architected to handle unexpected non-graceful terminations so basically what they're they're trying to get at is that your application should be robust enough that if i just come and yank the power cord out of the machine it's not going to destroy anything right like you know things will be able to continue on right some other job some other process will be able to pick

up where your that machine left off and that machine, when it comes back up or that process, when it comes back up, isn't going to be in a corrupt state. Like that's ultimately where we're going at with this. Yep. And like I said, that's not exactly easy to do depending on,

depending on what kind of technologies you leverage. If you are leveraging cues that can greatly simplify what you've got to do. But if you've got some sort of process flow and it all has to happen, you know, A, B, C, D, E, F, G, let's say that you got 30 steps in that and something dies on step 26, you have to have built something that knows how to, you know,

fix kind of where you were in that process but if each one of those steps was another job that was added to the queue then that solves your problem so that that's where the architecture comes back in right yep so and it doesn't necessarily have to be the queuing like like joe mentioned right like so you know using the database could be you know how you it's a way to do it queuing mechanism and it's a way a lot of people do it right i mean well i don't know if i'd say a lot and you know if we're thinking about like in the cloud in the cloud environment that we live in today right yeah you know there's definitely a lot of queuing cloud queuing options out there yep right yeah uh also i wanted to mention uh you know single uh data like transactions are easy to do in the most ACID compliant databases.

But when you start talking about external services where, you know, writing to this service, writing to that service, and, you know, something gets killed along the way, that's really tough. And, you know, like you mentioned, the queue is a great way of solving that. Yep. I mean, that's pretty much it for disposability. So I can't ask my question because Alan's already cheated. Well, I haven't read the reason. Ah, fine. I can only see the rating.

Okay. So, this one was rated as a medium. Right? You agree or disagree? Is there something between medium and high? No, because I've cheated and looked at all of them. But I wish that there were for this. Because, you know, it's really hard to get it perfect,

but that doesn't mean that you shouldn't pay any attention to it. So, yeah, I'm going to go with medium. I agree. This one's medium for me not because of how important i think it actually is like i i put this up there closer to high depending on what the system's doing but the reason why i put it at medium is going back to the mvp thing because i'm very much into get something that works out there. Right? Like, get your product out there. And the problem is you can spend a whole lot of time on this and never even come close to perfecting it.

If you're talking about trying to break things off into queueable work items. Bite-sized chunks. And then spinning off a bunch of different worker processes. And those worker processes are all code that you've got to write like i can totally understand where you're coming from with that i like this one a lot like if if you had unlimited resources unlimited amount of time this one would be high for me but because of the kind of resources and time you would have to put into this to make it perfect that it's it's definitely closer medium i feel like this is an iterate until you get there absolutely right but you know and the important parts too right like the the mission critical

parts you should do this on you know like if your business is maybe start out with some of the not so mission critical ones just to get your uh your pattern down your pattern down right work out some of the kinks in your in your queuing and worker process system there, right? Whatever platform that is that you're using. But, like, so I guess the reason I say this is let's say that your application is a bank wire transfer, right? And it's got to do several steps to get your money out of one account into another account. That thing should be perfect. Like if,

if you have software that does 5,000 other things, but that is one of them that needs to be perfect. But that's actually a great example of what we're talking about here though, right? Because if that job dies in between, you know, in the middle of that, then the job should just go back on the queue that's

what i'm saying that's where i'm saying this needs to be implemented perfectly okay yeah sorry so the rest of your app whatever right like don't even focus on that but this part is mission critical because you can't take money out of my account and have it sitting in limbo somewhere just because your server crashed so i wasn't too crazy about their reasoning though here and i mean i kind of get it but that so you know again clearly text description for why they said a medium as they say depending on how often you are releasing new code and how much you have to scale your app traffic up and down on demand you probably won't have to worry about the startup

and shutdown speed but be sure to understand the implications for your app so they're literally they only care about the scale problem as opposed to what the other implications would be yeah so definitely like in your transaction your banking transaction example like they're not addressing the criticality of that unit of work. It's either seen to completion or it's not. Almost like a database transaction, commit on a database transaction. They're definitely more concerned about the scalability of your application.

And again, if we're thinking cloud, that kind of makes sense. I think we disposed of that one. We did. It is gone. Yep. So on to resources we like. We talked about a few things in this episode that remind me of some books that I like. And I just found out that one of them,

The Phoenix Project, which is, I don't think I've mentioned it on this show before, but I'm a big fan of this book, so I wouldn't be that surprised, but it's basically, it's fiction, but it's kind of like a DevOps-y kind of romp through like an IT company, and it's a really light read, and it's really fun, and you're gonna hear stuff that you hear in the workplace,

like things like Kanban boards and change management and stuff. But it's actually an entertaining read, and it's easy to root for the main character. And I just found out that it's on Audible. So that's huge because I hate reading. Also, another book which is on Audible fantastic is the lean startup uh and that's actually a book that i think defined a lot of terms like mvp and a lot of stuff that and that's where it comes from it's got a lot of case studies it's also a surprisingly light read for uh such a such a a good book so i would definitely check those out we'll have links to those in the show

notes yeah i mean if you buy both of them you're at under 20 bucks if you do it on kindle so yep um yeah very nice yeah we'll have links to you know obviously we'll have uh links in there for the 12 factor uh 12 factor.net and clearly tech and i've said this before but you know just in case if this is the first of the 12 Factor episodes that you're listening to, the website for that is 12factor.net. But everywhere else, 12 is spelled out. So just be aware of that. And the previous episodes for the 12 Factor app that we've discussed are episodes 32 and 33. And we're almost done. So we'll probably have one more episode, right?

And we'll go over those last three and then we'll be experts in DevOps. Yeah. Yeah. It's going to be awesome. Looking forward to it. Yep. All right. So let's get into Alan's most favorite part of the show.

The tip of the week. Of the year. Of the week of the year of the week all right and this time it actually is a week how about that oh so is it so my tip actually came from something stupid that i did uh recently that you just you're coding you're in a groove and you do something, you get an error and you're like, what? Come on. And then you realize that you did something stupid and then you have to figure out a way around it. So essentially what I was doing is I needed to go through and I needed to replace some things in a list, like maybe some properties or some values.

And if you've ever done a loop over any kind of list and you try to change something in it, typically you're going to get barked at because it's going to be like, yo, you changed the list. We can't keep enumerating this list, right? And so one of the ways that you can handle that is, and this goes back to episode two, by the way, where we talk about boxing and unboxing and.NET. We talk about the stack, the heap talk about boxing and unboxing and.NET, we talk about the stack,

the heap and pointers and all kinds of stuff. There's a lot of people that probably skip that because it says and.NET, this works the same in Java as well. And anything that's running a virtual machine pretty much that manages a heap and all that. But essentially, what you can do is if you're looping over that thing, let's say that you want to replace something in that list, you can't change anything on the fly because then it's going to say it changed and it doesn't know how to enumerate it anymore. So you can keep track of the changes you want

by having like an external list. And then the way that I do it, or did in this case, is I kept a dictionary of the previous object and then the new object that's going to replace it. So I loop over the list, I find out what changes need to happen, I create a new object that basically is a copy of that other object and just change the property I need in it. And then when it's all done, I can just swap out those items.

Because everything that was in that previous list is pointing to some space in the heap, and so all you're doing is telling okay point to this new spot that i've got so you can basically swap out that object um yep i totally did this today by the way i was looping through a list and i was removing items from the list as i was looping through and then i ended up getting an error because my length didn't line up and so i ended up creating a list of items to remove and And after I ended up looping, then I went back and removed them. Yeah. It's, it's really a nice little pattern and it doesn't take up that much.

I mean, now granted, depending on how many objects you're trying to throw in here, it could be a problem, but, um, yeah, man, it's a nice little pattern and it'll keep you from doing anything that'll just crash you. And it's, it's a bit of a minor annoyance, but it happens, right? Like you're just thinking you're like okay i need to do this and then oh yeah that's right you can't do that so there ought to be a design pattern for this so make it make a a list of only the things you want to remove or modify mine was modify so basically what i did is i took the item that i needed to change i put

it in a dictionary as whatever that type was right and. And then I said, okay, we'll make a copy of that thing, but now change something and make that the value in this dictionary. And then that way, all I had to do at the very end was say, okay, replace this one with this one done. And it automatically just changes the pointers out behind the scenes and it'll get garbage collected. So it was beautiful. And I happen to be working with J objects because it was all dynamic objects that were created from json and all that and c sharp so it was pretty interesting it was fun maybe i'll uh maybe i'll try and get some sample code together who knows yeah i i'm i'm very familiar with that kind of pattern of doing things and it's not natural to me but it's

something i keep trying to do where basically i try not to modify any of my inputs. So I'm always trying to basically do what you're talking about where I have a new copy, I do my work there, and then I swap them at the last second. That's it. Yeah. And it works because – It's like faux functional. It is kind of, yeah, because it's all immutable.

It's not functional. Right. But yet you want it to be like functional programming by not changing the original source. I mean, the beauty is if you create a whole new programming paradigm called functional. I mean, the beauty is if you actually understand how the heap works and all that and they're all pointers, it makes perfect sense. Right. Because now it's just pointing to that new object instead of the other one. I'm going to register fo-functional. Wait, wouldn't it be f-e-a-u-x?

No, that'd be... I was trying to make a joke. No, f-a-u-x. Yeah, I was trying to make a joke, but your bad spelling ruined it. It might have enhanced it. Well, because I was going to leave it up to interpretation what the FO was I also think it makes things more refactorable because you can kind of copy and paste

lines around a bit more without worrying about the state of individual variables that's cool man I'm actually glad somebody else had this problem where they were coding and they were like oh yeah that's right I can't do that literally today and it never comes up, but it did today.

Awesome. Speaking of things that never comes up, I guess we're up to my tip. And I feel like there should be a name for this too. And this is the kind of thing that nobody really does anymore because every language has nice ways of iterating through collections now. But if you're messing around with any sort of game programming

or just multi-dimensional rays for some reason reason one kind of trick that is kind of neat that if you're let's say we're iterating through a two-dimensional array for a maze like a pac-man maze or something and you know your first inclination is usually to go x then y probably a byproduct of you know using english and cartesian coordinates we always say x and y we list the x first and then the y but it's actually more efficient to loop based on the y's first and uh so what i'm talking about is we're doing two four loops uh four you know x equals zero x less than length x plus plus and then inside that you would do a four x equals or y equals zero y less than length

y plus plus that's kind of the natural way to do it but if you actually swap those then it's much faster on the like the computational level and that's because at that point you're actually iterating through the inner array first and so rather than your pointer slopping back and forth between these two arrays to get the next value it stays in the same array and it just increments the actual index by one until it gets to the end so it looks a little funky but it's

you know and it's definitely a micro optimization but you'll look like you know what you're doing in an interview maybe interested I need to see a code sample well there's one right you'll look like you know what you're doing in an interview maybe. Interesting. I need to see a code sample. Well, there's one right there in the show notes.

And we'll have it on the website. It's not doing it for me. Yeah, if you're looping through. It's basically like this. It's backwards. So, you know, hipster programmers do it backwards. I know it's backwards, but how are you referencing that inner item first? Because you're going through the Y loop, inner item first? Because you're going through the Y loop, and then inside

of that, you're going through the X loop. How's that different than reversing Y and X as variables? I guess that's what I'm missing. Because we're talking about multidimensional arrays or arrays of arrays. So if you did the X first, you're saying, go to array number zero, then go index

number one. Okay, so you're going through the last segment of that multi-dimensional array going through all pieces of it before you go to the next item at the top level array right otherwise you're swapping an array each time so it's just kind of a bigger hop okay i got you no that makes perfect sense definitely micro but it's uh it's kind of cool cool yeah i'd really be curious based on like current memory speeds how much how much matters that is i feel a js perf coming on yeah oh okay well i'm not doing it you can do it oh i just say i feel like this is joe's tip like why am i getting the work here well i always say I'm going to do things and then forget about them conveniently. All right.

Well, then this next tip is for you then, Alan. This is your tip right here. You want to pay attention to this one. So actually, it was Alan that brought this up. Or that I mentioned it to Alan and Alan said, oh, that's a good tip. And I was like, oh, yeah, I'll use that for the show. So this was my pro tip to Alan was to set a calendar task

to remind yourself to change your password. So if you are in a corporate environment where there's a password policy in place where you have to change your password every so often and specifically, this is more specific to the actual commands are going to be specific to a Windows domain controller environment. Then you can open up your choice of PowerShell or command prompt. We won't talk about it.

And issue the command net space user and And then your username, your domain username space forward slash domain. And that will generate a report that'll show you about your user ID and included in that output will be a little line that says password expires and it'll have the exact date and timestamp of when your password expires and it'll have the exact date and timestamp of when your password expires. Now you take that little gem right there and you go over to whatever your calendaring application of choice is and create yourself a task or reminder for that date and time to change your password and add an alert to that or, or a reminder to that task to, uh, for a day or however your choice, however many hours or days ahead of that time that your password is going to expire. That way

you have like a little countdown of like, if you're an outlook, for example, and you create a task with a reminder alert, you know, a week ahead of time, for example, then you have an exact to the minute, seven day advanced notice. Hey, your password is going to expire. And then you can just choose to like keep hitting the snooze button until the last minute or choose to do it right then or there, whatever your choice is. You keep getting that reminder until you do it. Yeah, it actually is pretty cool. I mean, like you said, you just type in that cool i mean like you said you just type in that command and it gives you the second that your password will expire yeah and and that's your

um you know when i say your username i'm just talking about the short portion of your username so you don't have to include the at and your company name or whatever so um just you know whatever your short username is. So like if your, you know, username that you usually log in with might be John space dough, right. At example, company.com. Uh, instead we're talking about just, you know, if the short name for that was just J dough, then it would be net user JDoe slash domain. Yep, and not the domain you're on.

The actual word slash domain. Right, yes, sorry. Yes, the actual word domain. Yep, works perfect. Yep, and you'll learn all kinds of little interesting things about your credentials. Nothing crazy. No no it's not

that juicy all right doesn't change your password every day good that would definitely be a serious password policy right there there's actually some philosophies out there that like that having policies to then enforce their employees to change their passwords often isn't necessarily the best way to go. It's not even not necessarily the best. It's usually the worst because then it ends up being, you know, my name, 2015, my name, zero one, zero two, zero three. Some of the reports out there were suggesting that,

or some of that philosophy was based off of reports that suggested that it encourages people to write down their password, you know, or save their password underneath their keyboard. Like, really bad habits like that. Instead, it would be a far better environment if you just encouraged high entropy passwords, super long passwords or passphrases, really, and maybe be more event-driven with your policy rather than forcing people to remember something new every 90 days because then that's where your username, 123, comes in. Yep.

Or whatever you said. I don't remember the exact example. It's all based off numbers. But yeah, so that's episode 35. I hope you've enjoyed listening to chapters 7, 8, and 9 of the 12 Factor app, port binding, concurrency, and disposability. And as I mentioned before,

be sure to check out episodes 32 and 33 if you haven't already listened to our takes on the first half of the 12 Factor app. And as always, be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. We really do appreciate those reviews. So, you know, you can go to www.codingblocks.net slash review and find links to quickly get you over to iTunes or Stitcher to leave a review there.

Yep. Contact us with any questions or topics. Like, we seriously love getting those. We love answering them and hopefully it helps you and anybody else out who's listening. And visit us at CodingBlocks.net You can find all our show notes, our examples,

discussions, and more. This particular episode will be www.CodingBlocks.net slash episode 35. That's right. And send your feedback, questions, and rants to comments at codingblocks.net. And make sure to follow us on Twitter at Coding Blocks. And we're also on Facebook and Google Plus and Pinterest.

And LinkedIn and, yeah. And we will totally endorse you if you friend us on LinkedIn. Oh, my God. You're still doing that? Here we go again. Yep. Joe will endorse you. That's my little LinkedIn Ponzi

scheme. That's awesome. Alright, so we will be back and talk to you soon.