Coding Blocks - The Twelve-Factor App: Backing Services, Building and Releasing, Stateless Processes

Episode Date: October 22, 2015

We’re headed back to the Twelve-Factor app territory and this time we’re picking up with the next three chapters – backing services, building and releasing and processes.  Jump in to get the shownotes and listen to the next three pieces of building a manageable and scalable twelve-factor app. Survey News Mark Tinsley – PHP Composer […]

You're listening to Coding Blocks, episode 33. 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 and 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. And with that, welcome to Coding Blocks. I'm Alan Underwood.

I'm Joe Zach. And I'm Michael Outlaw. 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 code coding box and get a ten dollar credit towards

your new digital ocean account all right so let's go ahead and get rolling with some podcast news first there was a big oops in the last one that I got to call out and people who listened to the episode probably were like, what in the world, man? Like outlaw and Joe are like the most rude people on the planet because there was a section there for like two and a half minutes where they were talking and I'd start to say something and then they would talk over me and then they'd say something else.

And it seemed like there was a pause and I'd start talking and it sounded like they just railroaded me. One of the cables came unplugged. We were all remote. We were recording remote on that episode. And a cable came unplugged on mine. So I was talking and they just talked over me. I'm like, man, why are these guys being jerks tonight, right?

I thought that got edited out then. So that's the thing. Joe did go back and edit it out. But anybody who was already subscribed to the podcast got the initial one that came oh so there was an initial version that went out that yeah and have that correction yeah so okay so there's a good two and a half minutes well you know i'm just gonna talk all over the whole time right here so you know go ahead and try to say something now let's see how this works out joe you want to you want to chime in right now i'm gonna mute outlaw but yeah i'm not even chewing gum why dude it was it was actually

pretty funny because i'm listening to it at once i was like man this is oh that's right that's when the cable came unplugged so uh if you did hear that they weren't being jerks i totally had come unplugged and that just happened so or were we being jerks maybe that should be the survey that's possible too right yeah we keep talking about again we forgot to come up with a survey beforehand i even tried oh i have a good one though i have a good one oh okay let's do it right now what is it is the surface book real like is it something that people want or not the new surface book the microsoft surface book okay this is something that people want or not that versus the ipad pro

but even though they're not really the same type thing but i don't know i don't know maybe maybe that's your survey already fell apart apparently yeah never mind all right that worked out well hey we should stick with our joe and and Michael jerks for talking over Alan. Yeah, there we go. Well, we did have a survey last episode. We did. Yeah, but we didn't remember. What I'm getting at, though, is we didn't talk about it beforehand,

so we didn't know what to say as we were recording. So it was something that we threw together afterwards. But I like it better if we have something to talk about actually as we record yeah we'll we'll have to go over the previous numbers in our next one because we totally maybe by maybe by we're only 33 episodes in so maybe give it another 33 and maybe by then we'll have like something worked out to where we're familiar with like what we need to prepare for the show yeah don't we go through 15 minutes of setup every time? Like, man, why is our audio not working every single time? That's because you've got too many knobs on this thing, man.

Right. We'll get this working one day. Sponsored by Yamaha over here. Hey, it works. Kind of. Don't make me ever rewire it. Speaking of last episode, we did get a nice comment from Mark Tinsley referring to PHP's Composer.

We pick on PHP a lot, but Composer looks really nice and looks like a really good dependency management tool. Yeah, very cool. I forgot about that. It's been a while since we recorded, man. We've been insanely busy. Yeah. I thought this was episode one. Right? It feels good to get back in here. Yeah. So it actually was episode one, right? It feels good to get back in here. So hopefully you guys missed us as much as we missed you.

So, Oh man. One last thing about last episode, no one commented on my thunder, which I worked so hard on. So I spent 45 minutes. I think it was more like the shock The shock and awe that Alan and I had

That we experienced when we heard it That was not real thunder correct? No it was It took a long time for me to isolate And get it all set up I was not going to use a cheesy thunder sound I wanted the real scary thunder Very nice I like that

It was like the sound of a thousand alligators being dropped on his roof i know i know i know the right uh survey we can do the poll do people like the music behind the uh behind the ad spots or would they rather it without because outlaw hates it me and joe are like let's get our groove on we like this so that that might be the poll man you guys will just have to visit this episode to find out how about how about this this should be the survey our surveys on the fly survey is a good thing or a bad thing right so far this is going horribly right right and we're like 10 minutes in and we haven't talked about anything

code related so that's awesome uh yeah anyways all right So, Jay-Z, you want to hit us with some review info? Yep. We got some really great reviews this time. Rum and Rum, awesome name. More Cowbell 8008. Tenorant and Dick Dingus, all really great reviews. So we really appreciate that. Yeah.

One of them even said, hey, evenp developers listen to you guys which was kind of cool right like i mean we've never i don't think really dogged on them but i don't think we've ever called it out either so um yeah i mean that's really awesome thanks for that and we got a killer one over on stitcher um so i i mean you guys thank you for taking the time to do that it really makes our day. I just wonder though, like if he was kind of having some fun at our expense with, uh, that, that name, because his review name, the name, his Twitter handle name was like Eddie something.

I can't remember. Uh, help me out here. I can't remember on Stitcher. He used a completely different name. And I wonder if he did that cause he knew we were going to read it. Let me go back. Because, Joe, do you want to say it again? No, we're good.

But you know what? One thing that I do want to say about his particular review that he did over on Stitcher, and it was Dick Dingus, the thing that was awesome about it though was the fact that he said that he typically just does standard crud type stuff at his job. And I think a lot of us have fallen into this to where you kind of, I don't know, you fall into a bit of a rut because you're used to doing the same thing over and over. And he said this kind of reignited his passion for, for doing things the right way and, and, and learning and building those skills. So that, that was really cool. That, that was exciting to read that we've kind of ignited that flame again. So, um, here at Eddie Peters. So I'm not, I'm not convinced that he used his real name.

One of those places he didn't use his real name. So I, you know, at this point I'm, I'm going to have to assume that Twitter is the right one. I could be wrong. Yeah. It's entertaining either way. One of those, he was having some fun with us. So, Joe also has other news, which is kind of cool and insane. Yeah, I was a little embarrassed the last episode when I was referring to, like, Bower and other things as dependency management tools. And they, you know, whatever. But I wanted to try and make a modern JavaScript application.

And so I made a little game using a bunch of different libraries. And I won't get too much into it, but we'll have a link in the show notes where you can go check it out. And it's not a very good game, and I kind of stole the idea from one of the first Game Boy games. And it's even worse than the Game Boy game. But you guys should go check it out and tell me all the stuff that I did wrong.

I didn't play it. You did, right? Yeah. Notice how, though, he said a bunch of different libraries, right? Because you can't... JavaScript is like Ruffles potato chips. You can't just have one, right? Yep. Yeah, and I'll add one, and I know be trying to figure out how to do something with it and everyone's like oh don't

use that one and like sometimes i remember to remove it sometimes i don't so there's all sorts of crap in there that you know and it's like only a 200 line application i don't know i don't know what half of it does it's just all like bringing another crap but hold on a second isn't that where dot net's going to like you're just going to start bringing in 5 000 different dependencies so yeah so you're complaining about javascript but it looks like microsoft took a little node out of nodes book and said hey let's just make everything some sort of package so yeah maybe yeah it's nice like i would bring in libraries for a single function.

Like I think at one point I had like a, a function that would just shuffle an array, like just randomize an array. Like I brought in a, you know, essentially a library for it and it was just a real small thing. It's, it's nice to do that with those modules.

That's kind of cool. I mean, it makes things a little bit more painful when you're trying to gather it all together. But I mean, the fact that it's there, I feel like, uh, i feel like uh i feel like steve gibson would hate you for doing that oh absolutely steve gibson would hate me for a lot

of reasons he brought in an entire library so that you could make one function call yeah but gibson also wrote stuff in assembly right like yeah yeah that's no fun nobody wants to do that and in fairness the library was just for shuffling an array. It's done. All it does is just randomize arrays using a well-known algorithm. That's awesome. Alright. So what was your takeaway from the experience, though? Were you like, oh my god, I get it, this is awesome.

Or were you like, oh, JavaScript. What I thought was interesting was like, oh wow, there's all these really nice libraries oh my god i get it this is awesome or were you like oh javascript well it's like um what i thought was interesting it's like oh wow there's all this really nice these nice libraries and nice tooling but the thing is i need those nice libraries and the toolings to just to make it bearable so it kind of uh evens things out for me so i feel good about it you know i had a good experience it's fun i plan on doing more but uh i you know i can't really sing the praises because i feel like you know it it wasn't so much helping me out as it was just kind of getting me normal getting me straight that's cool all right so so the server side guy

becomes the ui guy that's basically the takeaway from that yeah that's kind of interesting he said he was going to do more of it yeah yeah yep we'll follow this closely oh one other thing all right so the past few weeks i've been incredibly busy i think all of us have and one of the things i wanted to bring up that that harkens back to episode 23 is encapsulation it's crazy that we got that many oh my dear god if you if you write software please write it in a way to where you encapsulate things properly i i literally spent ridiculous amounts of hours trying to make heads or tails of something that was intended to be a reusable component, but it had like little tentacles that reached out to everything else. And so trying to figure out what this thing actually did was nearly impossible. Like, I mean, it was, it's one of those things to where when you're making it, if you're the person making it, you understand everything you did, right? As soon as somebody else has to pick that up, you now have this logic spread out all over the place that reaches into these things that

are seemingly completely unrelated. And so you have no idea what the side effects are if you try and pull those things back out. Like encapsulation can save you in so many ways. One, you can actually test it properly. Two, you can understand if something changes in there, you know where it changed, you know, do your best. I know we kind of laughed about, I think in one of the previous recent episodes, you know, Joe's like, Hey, just make it a global variable. And I agree to a certain extent. If you were just trying to get something out the door, proof of concept, you want to get something out the door proof of concept you want to get something out it's a minimal minimal viable product do it but know that there is a cost to it

and if you start writing all your software like that that cost will come back to bite you and it will be very difficult to maintain so um you know if you haven't listened to episode 23 please do go give it a listen and realize that encapsulation is really a huge key in writing maintainable software. Yep. It sounds like, though, am I misunderstanding? Because part of what you were complaining about in your statement just now, though, is you were saying it was reaching out into other things. That's beyond encapsulation, though.

Oh, it's way past encapsulation. Okay. But if they had encapsulated. I was like, well, wait a minute, because encapsulation is just like hiding implementation. Well, it's not just hiding implementation, right? It's setting something up so that it's aware of itself, right? Well, hiding the behavior and the data.

Right. It's both. But this thing literally would go out and and pull data from places that you assumed were there that weren't necessarily right like this was supposed to be a reusable component and it was not in any sense of of the words because you couldn't plug it in anywhere else because there were so many dependencies on these other things that would never have existed unless you recreated exactly what they had in the other environment. And I don't know.

So encapsulation does have to do with how you store your variables and how you access them and all that. But it also is this whole idea of a closed area, right? That's, that's the reason why you hide implementation and all that is because you have this, this black box of

functionality and that this thing did not right like it was just an open book and it felt like a choose your own adventure type thing like you went here and it was like go to page 83 and it's like oh my god what's on page 83 and it was just i have so i'm so frustrated well it sounds like it sounds like uh for anyone that hasn't caught up on the back catalog, then it sounds like it's more than just the episode 23 that you'd want to catch up on. We have another one for that? Well, I mean, because I'm just like listening to some of what your complaints are, but some of it just sounds more like solid.

I'm kind of thinking like solid is one of them. Some of the patterns come to mind mind design patterns come to mind it wasn't so much patterns i think solid the whole open close principle that kind of thing that solid would definitely apply solid would um it's a little over the top maybe even in some cases which we discussed back then i don't remember what episode that was but but definitely between the two like there should be like set defined inputs and outputs and the implementation inside should be basically hidden from everybody which is your encapsulation but it's uh it's worth noting that if you just start writing things that i just didn't want anyone to think to hear that

and think like you know based off the things that you were saying it was encapsulation only though no no that's what i was wanting to get it's it's both yeah um so i wonder should we ask joe if if the game that he made was uh solid did he adhere to solid no not at all a lot of stuff i tried to get it testable i wanted it to be solid but like man it was just so murderous just trying to get libraries like some that written had been written for with node in mind and some that had been written like kind of counting on there being a browser and getting all that crap working together was man it wasn't fun yeah interesting yeah i mean i front end testing i actually listened to an episode of javascript jabber recently where they were talking about testing front-end ui type stuff man that is a whole ball of wax when it comes to like browsers

like it's maybe it's something we'll try and dedicate an episode to in the future but it's not something that you can take lightly yeah it's it's a major undertaking what's terrible is um with the game it's like if i want to test you know what happens when you finish a level like that means i gotta play a level you know it takes a long time to test everything out i was joking with you about this. Remember I was like, we need to go back to the days of Mike Tyson's punch out where you have a code that'll put you back at like level five with whatever.

Yeah. And I actually, I actually joked and brought up a episode 30 with the memento pattern. Oh, that's right. Yeah. Yeah. I'm surprised you didn't implement that,

man. Yeah. If you want to be able to save the game, it's a great way of doing it. Yeah. So a lot of fun. Definitely go check out his thing i mean it's it's fully functional i didn't have time to play with it but i will um probably this week now so yeah and be sure to let him know about the bugs he loves that part yeah yeah i might have bothered him once or twice i think i fixed everything you found so yeah yep all right so are we ready to get into tonight's topic let's do it yeah i wanted to catch this up real quick um

so we're doing a a second pass here at the 12 factor app talking about uh the uh four five and six here um but i just wanted to let you know, if you aren't familiar with the 12 Factor app that you might want to check out the episode, um, before this one. There's not a whole lot of catching up you really need to do. You know, it's not going to kill you if you listen out of order, uh, with this topic. But, uh, you might want to listen anyhow. And, uh, last week we talked about specifically steps 1, 2, 3, which were code bases, dependencies, and configs. And, uh, now we're going to be talking about backing services build release run and processes oh man when you said episodes four five and six i got all excited i thought we were talking about star wars i'm all prepared for

the wrong thing the beta looks great start over all right all. So number four today, kicking things off is backing services. And what is a backing service? It's any resource that is consumed over the network. And these are things like databases, cloud services, mail servers. I mean, the list goes on and on. If you've done any programming, you're familiar with these things. It's services that you use. One of the key or interesting things that they say about this is they say network, but they really mean anything that's external to your app that you can hook into.

So your database might reside on an app server. It's still a backing service. It could be running on your laptop. It's still a backing service. It's not your code. It's something that you are utilizing. So what about logs? service. It's not your code. It's something that you are utilizing. So... What about logs?

A logging service might be considered that, but I don't think logs... As soon as you said that, I'm like, wait, are you talking about the actual file? What are we talking about? It's like logging. Normally you would write stuff to disk, right? But I was just kind of thinking like, you know,

if you would consider the, you know, writing of the log to be a backing service. I know, you know just kind of thinking like, you know, if you would consider the, you know, writing of the log to be a backing service. I know, you know, with Splunk and, you know, all the different ways of getting logs off of individual boxes, you know, that things are a little bit different nowadays. But I don't know, I was just trying to think if that was something that we could really consider a backend service, because it is a form of persistence, right? Well, I think so if you're writing it to a database that's a service that you're utilizing as that database um but i don't think logging itself is if you're using something like a queue that would be a service that you're hooking into i really

think joe's trying to like skip ahead here like he's saying you know like i'm already done with talking about chapter four the backing services and let's skip to Chapter 11, logs, which really seems unfair and disingenuous of you. Yeah, logging in and of itself wouldn't be. But if you're hooking into a service like a queue or a database or something like that, that could be a service that you're doing. Like you could mail logs. I mean, I'm sure some people do crazy things like that.

So that would be utilizing the mail service, but I think logging in and of itself wouldn't be a backing service. Yeah. I mean the difference here though, like your question about the logs though, is this like, are you assuming that the log and the data in that log that you've written to it is there for a future process or a future run of the application. In which case, typically in logs, that's not the case.

Like you don't care. You write it to the log and then you let something else do some aggregation of those logs. So logs wouldn't apply in this scenario. And I think it's more specific to this is oh yeah sorry your code is hooking into the service right like splunk wouldn't be it because that's something that runs completely independent of of what your application is right well it could be something like if you were writing directly to a splunk api or reading from a Splunk API, then that could be a backing service that, you know,

basically in a 12-factor app, all of these backing services as they're titled should be treated as, you know, attached resources that should be accessed by some kind of, they refer to it as accessed via by via url or other locator credentials and you know this is information that's stored in the config right so we talked you know configuration was one of the things that we talked about last time and um you know this is one of those things that can go in in the config are these type of uh yep identifiers so connection strings you know per this count yep and that's exactly

what they said it was kind of ironic though because uh in one of the previous ones that we were talking about with the configs they said if you open source this today would you be safe right but then in this particular one they mentioned having credentials stored in a config and i thought that was a little bit ironic oh well that wasn't one that they said in the 12 factor app that was one that we said oh there was and i forget why because it was based off of like some other oh there was another uh story that came out and i can't remember it it was hidden it was going around linkedin for a while and basically uh someone wrote up a story that was something along the lines of how i lost you know thousands of dollars uh because of a bug in visual studio so basically something was getting committed

and pushed into a public repository that he didn't intend to or something i don't remember the exact story but that that's what that was and so you know we were saying like well hey you know as part of what you're putting in your config, if your boss came to you right now and said, okay, we're pushing everything to a public GitHub repository, how fired are you? And so you're right. I do find it strange that the very next chapter is talking about putting some things,

and specifically they mentioned credentials stored in a config. And we had actually talked about other ways to do that using their ideas by the way for things like environment variables or something like that or machine configs machine level configs that would store those uh credentials that in a safer way something that could not accidentally get checked into a source control. Basically, the idea here, though, while Alan tries to catch his breath, is that should you have to replace

any one of these resources, though, it should just be a matter of a configuration change. And I think that's, in essence, what they're really trying to get to. Because they list examples of using various SMTP services or if you're using you know various database uh processes you know the ability to just

swap that out now swap it out within the same architecture though right yeah they're not saying go from sql server to oracle right they're saying you know if you're changing a connection from a local host database to a remote database you should just be able to change the IP or whatever it's pointing to. One other interesting thing, though, that is key to this is it should not require a code change. So anything that you do here, you can change a config file, but you should not have to redeploy code. So if you have to redeploy your code simply to change a connection, then you've violated this number four backing service. Yeah, they actually list an example of where in this scenario they say, you know, there's a database misbehaving due to a hardware issue,

and the app administrator might want to spin up a new database server based off of some backup, and you just point the app to might want to spin up a new database server based off of some backup. And you just point the app to that new one. Now, for some applications, that might require an app restart. And they don't really cover that as being necessary. But I don't take that as a bad thing, though. No. I mean, in most of your applications, they're not just going to pick up a config file on the fly.

In most of them. You're going to have to restart an app pool or something like that. It's not a deploy. IIS can be pretty good about picking up web config changes if you know if you're if we're talking specifically about that and and but it does kind of get into the question of um you know um well i don't know how much further we want to get but you know later on they talk about um session related kind of things right so if you were to not have anything session based and so every connection that came in was checking to see like, Oh,

what database do I use? Then, you know, a restart may not be required. Right. And pick it up on the fly. Right. Yeah.

I mean, you mentioned an app pool, which is definitely like, uh, you know, it's going to have that kind of connection, but. Well,

even with Apache, I think if you modify one of the configs, a lot of times you have to do an apache restart um you know depending on what the config file is and that kind of thing so but that's different though because you're describing you're describing configuring apache versus configuring iis and what we're talking about is configuring the application application which could be hosted by apache or iis that's a good point yeah yeah so yeah so yeah i think we've beat up uh backing services uh pretty well um there there was one other thing

though was the uh if you remember right continuing from the last one we gave these things importance ratings and i believe joe's the one who found the site so i'm gonna let him go with this yeah and i actually uh i lost the link so i'm gonna have to look that up while we're talking here i got it for you right here awesome what was the name tech.com awesome boom and uh they gave this one an importance rating of high what do you guys think about that i agree with that oh yeah yeah that seems fair like if you got it If you have to recompile and redeploy your app just because you wanted to change the connection to a mail server or a database, that's insane. Yeah, I agree with that. But it is kind of weird that there's so much carryover between this and the configs.

So really, I feel like this number four is really kind of number three. Which I said was high. This number four is really kind of number three. Hmm. Which I said was high. What did they say? What did they say three was? I don't remember on Clearly Tech. Do you remember? Let me check the show notes from last episode.

You were saying that you said it was high or that they said it was high? I'm hoping both. If I remember right, they said their configs were only medium or something though and we were like no that should be one that we disagreed with but yeah yeah either which way um but even in the even in the config one that they the 12 factor out does strongly um recommend you know environment variables yeah for that configuration but i would agree on this one. I think backing services is a high, and they should be decoupled.

I mean, as much as possible. Yeah. Let me see. Let's see what... Yeah, they have as a medium. Clearly Tech had FIG as a medium. They have which one as a medium? The configs?

Yeah, that's the one that we thought was a little bit low. Yeah, they say lots of companies get away without this but you're sloppy if you do so yeah it is a little strange that these chapters three and four do really go hand in hand so to say that config is not as important but backing services is of their confidence all right no they're both high yeah well that's interesting all right all right so moving right along let's uh skip right ahead to episode five i mean chapter five build release run strikes back gonna catch the star wars thanks wow fell on deaf ears we thought it was just late. Oh, oh. No, it's not that late.

So build, release, run. So this is talking about strictly separating the build and run stages of your application. Right? So we have the build stage is a transform which converts the code in a repository into an executable bundle known as a build. Right? I don't like them calling it a build. Build is a verb. I think they should call them buildings.

What? I'm sorry. I think I'm drunk on Coke Zero. I thought that was hilarious by the way let's just get through what the three stages are first right before we get into the commentary

buildings it's too late buildings what are you talking about man so the get stage you can tell where I'm thinking the build stage I said is a transformer which converts a code repository into an executable bundle known as a build. There's the release stage

that takes the build produced by the build stage and combines it with the deploy's current config and then there's the run stage known as the run time which is the running execution environment right? Yeah I like that

the release is a combination of the build with the config. I thought that was pretty cool. And it kind of implies that you can kind of mix and match those things. You can take different builds with different configs. And yeah, it's kind of cool. Yeah, I mean, the key is you can set it up to point to

multiple different deploy areas and that's how you've got to mix them in differently for those. Right. So, I mean, well, I mean, it kind of goes back to, uh, which one was it from, uh, the last episode? Um, I guess maybe it was code base. No, there was one where we were talking about like having, having a deploy on, um, maybe

it was under the config that we were talking about it where like you could have multiple deploys of the same uh code right but using different environment variables it would be essentially according to this definition uh it could be a different release right yeah um one thing i like here too is um because it takes the build that's done in the first stage and combines it with configs it um implies that you're using the same, you know, basically generating the same build, the same binaries, if you will. And MS Dev Show just had a recent interview with Donovan Brown. It was really good. And they were talking about Azure's release management.

And one thing that I thought was really cool there is they talked about with this new product, it kind of changed things a little bit with TFS so that you could actually take the same, you know know build output and move it to like qa environment and then take those same binaries and move them to staging and then take the same binaries and move it to production so there's no never any question over what's been tested and what hasn't it's not like you're like okay this looks good let's build another package for production and you know introducing any variability there yeah i like that and that is you know that's possible as a side effect of having the config done properly right which was chapter three yep right of having like what what's truly important because we you know as a refresher right some of the things that we talked about that go into that can fit into your

config file were things that would, that were important to the application that you, that aren't going to change per environment, but those things that were going to change per environment, those were the environment variables, right? Right. One of the additional things here is, and we've actually had discussion about this before as well, is when you do have a release

you're supposed to tag that with something whether it's an incrementing number version 101 or whether it's a time stamp and some people this is actually a topic that's kind of comical to me because i'm fairly indifferent to it i i kind of prefer the time stamp just because you know when it happens but i've heard people like passionately debate whether or not it should be a version number right or this is definitely in one of those var wars yeah yeah tabs versus spaces and var or not to var what's your preference joe i know you do quite a few builds they don't call it mic Windows 2015 October 11th. They do in the builds.

That's true. Man, I don't care what you market it as. The build, I like the date. I do like having the date in there because it gives you a point in reference that is human. Yeah, man. Sensical, right? Some random number, like that's meaningless. You have to go look it up.

And that's what sucks, right? Like eventually what you're going to do is go look up the tag somewhere just to find the date that you look at the tag annotation to see when it was made right and that way you get a date like who cares like really i care numbers don't take this away from me no no no so you like that you like the um minimum or not the what is it the minor and the revision numbers? Yeah, I like to know how big of a change this is. If it's just a minor change or a major, the date doesn't tell me anything about that. Okay, so what if we do 1.0.1.2015?

I'm going to start adding 10 to every major version just to mess with Joe so they don't think big things happened. And all I'm going to do is change a little string here and there. Oh, no. That version number, that's only for marketing people. They're the only ones that are going to care about the version. But from a developer perspective, a timestamp of the build is far more beneficial,

far more informational. I think I have the answer. There should be like a tag feature that gives you both. What? Are you trying to make a joke to me? Something. Like why can't the tag keep track of the time it was tagged? Since we're talking about version numbers

and then you just reminded me of a joke because one of our friends gave us a joke that he's been asking like hey are you gonna say this joke so i might as well say it you know like why did they uh why did microsoft name it windows 10 oh anyone 789 because windows 789 yes there you go that's awesome very nice oh hey one more

one more thing on this that I think is key and cannot be it cannot be overvalued like it needs to happen this basically this whole flow

that they're talking about here basically requires that you have a build server in place. So that when you are committing code, releases happen. I beg to differ. Builds are initiated by the app's developers whenever new code is deployed. Runtime execution, by contrast, can happen automatically in such cases as a server reboot, blah, blah, blah. So it implies it. It doesn't say it has to be there

but if you want to ease your life and not have to be doing manual builds all the time okay definitely you know if you can automate your builds that is definitely going to make life easier on you definitely no arguments there but what i'm saying though is that this this isn't really necessarily saying that that's part of it or a requirement of it. Not required. This is saying that the stage itself is taking the binary produced from the build and combining it with that deploy's current config, which could be just as simple as copying over a binary onto a particular Linux instance under its particular user directory that it's going to run as. And then, boom, that's your release stage. Right.

Because that user that it's going to run as might already have the environment variable set up for that configuration. And there you go. that's that's the release stage yeah it's not a requirement but it if if you ever have worked in an environment where you have a lot of moving pieces and and you're constantly having to produce builds like it can become almost a second full-time job to be constantly updating these things all over the place so if you can and you have the time setting up a build server to help automate some of this stuff can be like just a huge boon to productivity right i mean i could like even put these these three stages into different words so like the build stage is simply the compilation yep the

release stage is simply the transferring the files right and the run stage is the actual execution of it yep right like that that's in as simple as what this is and that's why i'm trying to say that like you know make the point that as much as you know uh continuous deployment is an amazing thing. It's not required. It's not, you know. But they also talk about a rollback. So you do have to have a rollback in place, which can simply mean backing up the folder that was there and then being able to, you know,

quickly, you know, switch back over to it if something goes wrong. Yeah, I mean, again, you know, this being Heroku and, you know, definitely Ruby-ish, you know this being heroku and you know definitely uh uh ruby-ish you know they're talking about environments where you could just uh you have have um one of the examples they give is is you know each release is a different version numbered subdirectory right not a timestamp to subdirectory but but in and you just have a releaseamped subdirectory. But you just have a release subdirectory that is a symlink to whatever version you want to be the current running version. Right.

Rollbacks are scary. Sometimes there are side effects if you change data or you add columns to the database or some other service. Then there can be real implications to rolling back. Oh, yeah. Especially in a production system. In a staging or a development environment, maybe not so big, but... Not in a 12-factor app.

Oh, sorry. Right. You start making data changes in the real world, and there are some implications to what you got to do. Yeah, I got a buddy who says, if you're talking about rolling back, then your continuous delivery is broken. And you need to speed up your pipeline so you can roll forward and fix stuff quickly.

And I agree with that. I actually do agree with that. I've worked with people that, like, their knee-jerk reaction is to roll back. I mean, just fix the problem. Yeah, fix the problem. I mean, unless this is something that's going to lose your company, you know, millions of dollars and time to try and get it done. But for the most part, if you've been on top of the situation and some anomaly comes up, you should have a pretty good idea of what it is and what it's going to take to get that thing resolved. And a lot of times rolling back will take just as much time as fixing the problem in the first place.

Sometimes more. Sometimes more. Like what Joe said a second ago, you know, if there were were major underlying architectural changes it may not even be feasible to do i mean i don't mean to you know make joe relive uh bad memories but i i definitely recall one weekend that he spent uh several hours after a rollback uh manually having to fix some data, if he recalls that, one January. Oh, yes. So many times. So many dirty, dirty things I've done.

So, you know, just simply the point being is that, like, you know, it's often far more time-consuming to roll back. So, I mean, you know, any managers that might be listening to this or whatever, you know, definitely listen to the developer and find out, you know, try and get a real judge of what the situation may be and then move forward with it.

Now, in fairness though, the times where those rollbacks were so nightmarish, were they 12- apps oh man nothing we've worked on has ever been a 12 factor come on well but my point being though is like if it truly was a 12 factor app right if it truly was a 12 factor app would rolling back be such a bad thing uh no but still there's still going to be changes that will be complicated, right? Like if it's a database, if you're upgrading a schema on a database, are you going to really want to roll that schema back to a point before it? So, I mean, even in a 12-factor app, these kind of things can come up. I mean, there's definitely situations where it's not going to be so easy.

Yeah, I mean, I don't mean to insult, but it definitely feels like they were living in a bubble for some of these yeah there's no doubt i mean or that or i've just like really not had the pleasure i mean in all in all honesty right like most apps aren't all that clean they just aren't because they grow organically over time we've talked about this before and you know in in all fairness if you could write everything perfectly from the beginning, nothing would probably ever get done. Well, I mean, you know, not to harp on the data issue, but I keep thinking about like scenarios where, you know, especially in like live environments where, you know, where you get a lot of traffic. Right. Once you make that schema change you're done yeah i mean you can't what are you doing to do like so yeah i don't know yeah highly transactional

systems is not in half the time a rollback takes twice as long like in data if you try and update something and it starts going sideways and you try and roll back that rollback may take twice as long as the initial update you tried to do so as we were talking about this i was trying to think of scenarios like well what if what about you know if you took a snapshot of the database so that you could like have that as a backup but then you might have like for example you mentioned transactional makes me think of like orders you know if you had a live e-commerce site and you have orders coming in well you don't want to lose those orders so you can't just roll back to the other version of the database and right you

know if this is all live yeah so yeah i don't i i like what joe said best roll forward yeah just keep rolling forward like if you have to roll back, then that should be a code smell that something is wrong with your deployment process. Yeah. Alright. The importance that they assigned to this one was the

word conceptual. That's a little bit hard to interpret, but I've got the page up here. And basically they say from a practical perspective, the tools and framework that you use will define best practices for building, deploying, and running your app. So just kind of follow it, and it's going to take care of it, you know, for better or for worse. And I agree with that. And for the most part, like, I don't know how you would do it another way, you know? No, this seems pretty status quo.

Like, yeah. I mean, this is almost just a part of anything that you do anyway, so. Yeah. I just thought it was interesting to have these three well-defined steps. And there are definitely things, you know, you could do in, say, like, a.NET world. You know, you could kind of build debug for one thing and then build release for another. You could use web transforms and things that kind of blur the lines between these three steps.

So it's just kind of interesting and a nice guideline to try and keep those separate. Cool. Well, I think if you're doing the web transform, so that would break this, you'd be breaking this part of the 12 factor app. But yeah, the web config is already kind of breaking it, right? Because you've got a bunch of config type stuff

that's now no longer associated with the environment. It's associated with the code. Well, no, the transform only happens when you deploy. It doesn't happen on a build. No, it happens on a build. The web transform happens on a build because it puts a copy of the web config in each of the folders.

Yeah, it's build time. Yeah, it actually modifies the XML of the web config. Of the web config you don't you could still adhere to the config chapter of the 12 factor app with a dot net app i mean it's you know that that is more dependent upon like what do you put in that web config right so they don't want you to put things that are going to change environment to environment like you know database credentials that's where they want things in some other configuration. And, you know, I think we talked about the machine config or the user configs for something like that. But they want the things that are code specific

that need to be in there in order for the application to run that, you know, can go in that web config. Right. And that would adhere to 12-factor apt is fine. I concede that point i don't know about the conceptual stuff there for the importance that seems like kind of odd it seems like a necessary thing like you have to build you have to release you have to run how can you call it conceptual well conceptually you have to do that okay well because if in reality you don't right well you know it just won't work you got a zero factor app right that's right all right

well let's uh let's move along here i think we beat that that one uh a little much so you know we've said this before and i don't mind asking again, but if you haven't already, we greatly appreciate it. Every time we read a new review, it makes each of us a little giddy inside. We really do appreciate it and it really does mean a lot to us and it helps us a lot with, you know, other people when they run across the podcast uh, the podcast and whatever, you know, source they're looking at and they're like, Hey, I wonder if this won't be any good. And they, and they read your review. It really does help. So we really do appreciate that. So if you haven't already left us a review, please do. You can go to iTunes or Stitcher. Uh, you can quickly go to, uh, coding box.net slash review. And, uh, there's quick links there to help you, you know, get to your source. And,

and if those aren't one of the places that you want to leave a review, you know, pick your podcast aggregator of choice and let us know. We'd be interested to know, you know, some of the sources that people are using to find us out there. This episode is sponsored by Infragistics. Design before you build with Indigo Studio.

Share and collaborate on designs with indigodesign.com and build high performance enterprise ready desktop and web line of business apps and mobile apps in your platform of choice. Be that WPF, Windows Forms, ASP.NET, HTML5 and JavaScript, iOS ios android or xamarin head over to infragistics.com to view sample apps and see those tools in action and get started with your free trial today all right this brings us to part six processes so this has to do not so much with your application but with the various kind of executables that run around it. Things like scheduled tasks, cron jobs, stuff like that. And the goal here, or at least the guideline, is to execute that app as one or more stateless processes. And I actually apologize. This does

refer to the application as well, just to kind of encompasses those other things as well. And the goal here is to stay stateless and share nothing, including not sharing memory or disk storage. Yeah, so this is kind of like, you know, when I was hinting at before, when I was talking about sessions, you know, because this specifically does get into things. It specifically calls out, you know, if you're using sticky sessions, you know, because this specifically does get into thing. It specifically calls out, you know, if you're using sticky sessions, for example, which if you're not familiar with sticky

sessions, let's say that you have a multiple, uh, app servers that are serving up your website and randomly as new users come in, uh, you know, some load balancer decides which one of those servers should, uh, take that request. Right. And there's different, uh, you know, some load balancer decides which one of those servers should, uh, take that request, right? And there's different, uh, algorithms that are used to decide how that gets balanced. But, you know, what you want is then in the second request that that user makes, you might have a need for them to come back to the same server. And that's where, that's what's called a sticky session. And so in that case, what's called a sticky session. And so in that case, what happens is the load balancer says, Oh, well, this guy has already visited once

before, I'm going to send him back to the same one that he went to the first time. And I'm gonna keep routing his traffic to that same box until he's done, right until until his sticky session expires. And, you know, in the 12 factor app here in the, in chapter six of processes, they specifically call out sticky sessions as a bad thing, right? Like if you're, if your box needs, uh, sticky sessions, then, you know, you're doing it wrong. And they specifically call it, you know, you should use, uh, you know, something like a, a memcached or Redis in order to save that data. Yeah, absolutely. And there's a lot of really good reasons for doing this.

And one is scalability. If you've got sticky sessions turned on and you add a new box, then only new people are going to ever get to it. And it's going to take a long time to actually balance that load. And same thing with killing boxes. You're introducing points of failure. If you're in a checkout process or something and you're storing that in session,

then if that box dies, you might get kicked out to the beginning of checkout again or even worse, you might lose your card or whatever. And that's all really bad. You're actually introducing points of failure. Yeah, and I mean, when it comes down to it, there's a lot of options for not having to do that, which is, you know, in ASP.net, you have your session state service, and they mentioned a lot of times you back it with a database or something like that. But I mean,

just about everything has something available to do this. And when you do something like sticky sessions, nevermind the fact that you can't't even it takes new people to start balancing out these new servers the other thing that stinks about it is nothing takes into um consideration the load on those servers at that point in time so if you actually had a real load balancing type solution in place it's not going to be leveraged right you could have one server that's at 90 cpu utilization another one that's at zero but because you know those people are stuck on that other box there's nowhere to go so there's a lot of reasons not to do this and there's a lot of options for not having to do it so i mean this one's actually fairly easy to do you just you just have to architect

your architect your application in a way that takes advantage of it. Yeah, well, okay, so you mentioned architecture, right? So there's one statement in here in Chapter 6 where they say that the 12-factor processes because we're talking about like, well, you don't want any saved session data on a particular app server. Instead, you want that to be done by some other backing server service like a memcache, right, that all of these processes would then, you know, these app server processes could then share, right? Which seems like, well, wait a minute. It's supposed to be stateless and share nothing right so i almost want to rephrase that statement to say the 12 factor processes are stateless and know nothing right i like that but but the reason why they call it shared nothing is based off of or at least i'm assuming, based off of the architecture, the shared nothing architecture.

Yeah, which is old, by the way. I had just, this is the first time tonight that I had heard this term before, and I looked it up, and it was actually developed by this guy, Michael Stonebraker, awesome name, in 1986, when I was six. Yeah, so it's kind of funny.

It only, at least as far as I know, became really popular with the kind of rise of Google and Facebook and that sort of commodity hardware type of hosting. And so it was just kind of funny to see it coming back from so long ago. So it's using a shared nothing architecture, but really you need to think about this

as stateless and no nothing. Because I really interpret that as like, that's the way they want. If we go back to the shared, if we go back to the session data as an, as the example, right? So in the, in the scenario that you each described, you know, if you were to pop in a new app server into your load balancer, you want it to be able to pick up right along with wherever they are in the shopping experience.

You know, customers could randomly go each request that they make each click that they make to the next page could take them to any one server. They're not going to keep going to the same app server over and over and over. Right. So that, and that's because each one is stateless and knows nothing about the session. All of that is coming from some other shared backing service. It's kind of funny though, Right. So that and that's because each one is stateless and knows nothing about the session.

All of that is coming from some other shared backing service. It's kind of funny, though, because it says it has to be stateless. And it's weird because it is in the term that there is not a session, but you're still relying on a database or you're relying on a memcache. It's not that you're not going to have that, that shared data. It's just that it's not relying on one piece of hardware to do it because then it kills your scalability. Right. I think in stateless as in like,

you don't have to initiate, you know, one of those run apps. You don't have to use like a memento pattern. You're not, you're not like bringing in some kind of state in order for the app to even start up right right it can start up and in it and you know exist like you're making a database connection i don't really consider that's not that's not part of it no but i mean i guess one of the things here

is like the whole thing with session like if it goes away it shouldn't kill you you should be able to bounce to another server and do it right right but the whole idea is though there's still something backing that now if it's a if it's a database there's a single point of failure there so it's it's just kind of curious that they're saying they move it so that you can basically scale out horizontally right well okay but that doesn't have to be that database doesn't have to be a single point of failure that's all in how you date how you architect a database layer yeah good point and and specifically not you know we keep beating up on session as the example here but you know they actually specifically call out other uh

caching you know session-based services to to uh cache that that uh session data okay yeah oh i got a good one um one example of that of kind of a bad thing to do in this situation is uh file uploads if you've ever uploaded a file stashed somewhere on disk temporarily and then dealt with it again in like uh you know later requests like say you crop the photo or whatever um that's the kind of thing that you need to put that in some sort of shared location because you never know who's going to get that next request yeah that's a really good example yep and the same goes for um for processes uh kind of mentioned that earlier but uh sometimes because you never know who's going to get that next request. Yeah, that's a really good example. Yep. And the same goes for processes.

I kind of mentioned that earlier, but sometimes I've seen processes that will like, phase one will kind of create a file, and then phase two will go read that file and do something else and put it somewhere else. And it just makes for a flow that's very heavily dependent on knowing what the last state was of, you know, some other process,

which is just not a great practice. Yeah. It makes scaling pretty much impossible. Yep. Yeah. So that, that's actually a, that,

that example hits on two of those scenarios, Joe one, one is being the state of it, knowing like where you are in the processing of that file. But then the other one is if a second request were to come in, it might not have access to that file. Right. So that pretty much wrapped that one up. That one was pretty short and sweet yeah i mean there was like specifically you know i do want to like

make one little caveat though to the file because you know if if that see if if operating on that file is in one you know transaction right then that's okay right yeah they even say that because using disk space or memory space you know locally at the time of processing some request that can be considered just you know a local cache and that can be okay in that scenario it's it's the subsequent use of it so in joe's example that he gave where you know some other step or process needed to be able to know what you what step you were at in processing the file right that's where it becomes a problem well yeah i mean a file uploads a perfect example of that because when it first uploads if it's a web page right it goes to a temporary spot on the server

and then if you're going to move that into a more accessible location there is another step there that has to happen so that's a perfect example of yeah temporarily just until you get it into a better place that can be used by other pieces you know that's fine that's really unavoidable in most cases so you know and then yeah what's the uh what'd you find on the importance on that one, Joe? They said high, and I wish there was something higher than high, because I really like this one. Higher than high. Yeah.

You can make it critical. I can't feel my face when I'm, you know, God, that song. By the way, come on, man. It's the weekend. Let's get into pop culture for just a moment. Oh, my God. I can't feel my face when I'm with you?

What does that even mean? I guess you'll know it when you know it. Man. Have you never had tequila? Wait, that stuff that you could smell on yourself like three days later? You eat the worm, man, and you'll know what the song's about so the next time you're with with your significant other and you'd be like i can't feel my face when i'm with you like they're supposed to really think that's something special right you say oh you're so sweet yeah and there's coding blocks on pop culture sorry about that man they're just so

like this song is so catchy But it is seriously some of the worst lyrics I think I've ever heard And I love it Say what Oh man we came off the rails That's awesome Nice

Alright so yeah they say it's high And Joe says it's higher than high Yeah I don't know That one's pretty important All right, so yeah, they say it's high. And Joe says it's higher than high. Yeah, that one's pretty important. Yeah, they specifically have a blurb here that says that not only is a stateless app more robust, but it's easier to manage, generally incur, easy for me to say, incurs fewer bugs and scales better.

So higher than high according to joe like willie nelson high how's that like your whole lifetime of high more pop culture all right so uh there's some resources that we like that we will include in the show notes. Clearly, tech is obviously going to be one again, and obviously the 12 Factor app. And again, if you didn't listen to the first one, certainly go back and listen to episode 32 for the first three chapters. But know that if you were to try to go find the 12 Factor site on your own, it's 12 as in the number factor.net. All right. So let's get into Alan's favorite portion of the show. Our tip of the year.

The tip of the week. What you got, Alan? So my tip of the quarter is... Tip of the quarter. Oh my God. It feels like it anyways. You know, it is a weekday that we are recording this. I feel like tip of the week is inappropriate for this segment.

If we ever do the tip of the weekend. One of these days we're actually going to send out a newsletter too. It's going to be interesting when it happens. We still have a couple written. People are going to be like, what's this coding blocks thing that came to me? Anyways, all right, so my tip is I was just helping somebody recently. I was watching them do some things, and they had a problem where their application was locking up. And it was clearly something to do with the database, which was backed by SQL Server.

And if you've done this much, you know, a lot of people go into query profiler and they start searching for things that look for long running execution times. Profiler can be a little bit, um, daunting for people who don't have, haven't used it initially. Um, and there's a lot of settings you can set. So that's a lot is an understatement. It's like in the New York city of state of settings. It crazy yeah there's there's a lot that you can do in there and if you don't check the right things and you actually won't get back data that will help you so you also must i mean must create your own templates that you just reuse yeah you should in order to make query profiler work for you yeah i would agree and it's funny

because the ones that come out of the box are really just not very good. So anyways, long story, still long, but I will try to get to the point here. One thing you can do if it's SQL Server, and I've taught several people this trick, you can do an SP underscore who to. And number two. Yeah, number two. And this is basically a store proc that comes bundled with SQL server. It's kind of a hidden proc. And if you do SP who to, and then in single quotes to active, it will show you all the active running processes. And if you leave off active, it'll actually show you all the processes that have been running at

some point in time. But here's the cool part. So you do SPHOO2 active, you can see a list of everything that's running. Then you can look for things that have a high CPU utilization, maybe a high disk IO and haven't finished. And maybe they're even blocking. Now in one of those columns, there's going to be an SPID. That's your SPID as they call it. It's basically your process ID. If you take that thing, this doesn't help you. You'll see that it'll say maybe there's a select running or an update running or a delete running. And that doesn't help you because you really don't know what the statement is, is bombing at that point in time. You just know that it's hanging up the machine. If you take that SPID

that's associated with that row, and then now you have to have rights to do this a lot of times you might have to have sysadmin rights or at least elevated rights on the server to do this you can run a dbcc space input buffer and then in parens put that spid it will actually give you the query statement that is running that is causing all that CPU locking or the disk IO so instead of just seeing select you'll actually see your crazy query statement that might be breaking things and it might not even be a nasty statement it's just that maybe an index was bad or fragmented or or you know statistics are out of date whatever the

case may be this will actually get you to the answer quicker than going into profiler. Now the only caveat here is if the process finished, you're not going to see it in your SPHOO2. So it's got to be something that is running and is blocking things for you to actually see it. But it is a nice quick way to be able to troubleshoot things on SQL Server if you're having some performance issues. Now, here's a bonus to that.

Let's say you do your SP who to you do your dbcc input buffer right you see what your friends are doing out there and let's assume that you have privilege kill spit now do kill space and put that spit in there just to like randomly mess with him that's where you were going. Their query stops and they have no idea what just happened. This is only if you don't like the people you work with. Because they've been working on this query all day. There they are debugging their app, stepping through it.

They're like, wait, what just happened? Now, I will say, though, there have been more than a time or two where somebody will have opened a transaction and forgot to commit it or roll it back, and it will hang everybody attached to that server. Like, you can't do anything. Right. And then they went to lunch because they had plans, right? And so then you can freely kill whatever they did, right? That's awesome. But, yeah, this is actually a very nice troubleshooting tool.

A lot of people don't even know about it, and it is super helpful. And you'd be surprised. You start killing processes, and things run fast. They do. That database backup that was running, who needed that? Yeah, that's just... I hate seeing that word. It's a factor app.

We don't need backups. You should have stopped listening to our advice about a minute ago. I hate seeing that word. We're a 12-factor app. We don't need backups. You should have stopped listening to our advice about a minute ago. I hate seeing that word. Sorry for that derailment. When you see select in that SPHOOT2, every time I see the word select, I'm like, come on. That means you know what it is. You're just not telling me. Because it won't give you the whole statement?

Yeah, it obviously knows. That's awesome. Oh, by the way, here's another quick little tip for you. If it is a select and there's a ton of CPU and really the disk IO is really low, typically that's a bad index. Almost always. Or a missing index. Say that again? So if you see really high CPU utilization and very low disk IO and it's a select, that's almost always guaranteed to be either a fragmented or missing index

because basically SQL is having to join everything in its memory to get things done. Yeah, if you also find those bits that are waiting or runnable, I'm sorry, they'll be runnable, those can often be your friend uh sql server uh management studio sessions because every window if you notice every window you open up it'll have in parentheses what the is of that window yep right so if you wanted to like disconnect your friends yeah you can kill all their open connections there you go yeah. You know, I had a connection killed on me

the other day. It wasn't me. I've never actually done this. I've only recommended this to other people. I read about it somewhere. I've never done this. Oh, that's convenient. Yeah. I totally believe you guys. You should.

Would I lie? I found some great oceanfront property in Arizona. Right. All right. So, Joe, what you got for the tip of the week? All right. So this tip is from Andy Joyner, our buddy at Techies UK. And he tipped me off to Tortoise Git, which I know Outlaw is already gritting his teeth

because it's not, you know, I'll reserve my comment. But what it's really nice for, and Alan kind of sold me on this inadvertently, but it's nice for partial commits when you're doing something like a rebase and you want to, you know, kind of clean up your commits

and get things in there in a nicer, cleaner way, then this is really nice. And it's also nice, like, sometimes I just don't want to type anymore. I get tired. So laziness is the key here. All the best programmers are lazy. Just know that that's a good point.

I hate you a little bit inside for mentioning a Git GUI tool as a tip of the week. Take it. As long as the Git GUI tool is not Visual Studio, I'm somewhat okay with it. Visual Studio is probably the most hamstrung Git interface I've ever seen. It's horrible. It's beyond terrible. I've had to help so many people that have decided they were going to use that to where it's like come on dude it's purposely it's i don't know how else to

put this so i hope this is uh like you know a good pc way to put it but it's like purposely crippled like they don't have all the functionality there they don't even have a handful of functionality like there's so many features you can't you. You won't hear me typically bash on Visual Studio, but in this case, dude, just leave it out of there. Let somebody build a plugin that works. Man, no. No, the plugins are just as bad. Oh, really? I haven't never seen a good plugin for it.

Forget it. It's over. Just do command line. That's because Git's crazy. Git is schizophrenic. What? It really is. I agree. I agree. command line that's because git's crazy git is schizophrenic it really is i i agree i agree like if you go through the rtfm which if anybody ever sends that to me i may actually just sign off of

social media forever but if you go through it it's incredibly complicated but if you learn the basics and you learn them very well git by command line is actually fairly elegant and easy to follow. Like there are the edge cases where you have to do something crazy for the most part. That's never the case. Yeah. Sometimes it's like, how do I revert a commit?

And it's like, well, pull up a chair. No dude, I did it the other day, get revert. And then you just put in the hash, right?

Like it's so easy. Uh, anyways, um, all right, done rant. Yeah, I can't support this tip of the week. I did not mean to hijack your tip. I think it's fantastic, I guess. I mean, I guess Andy helped you with this one,

come up with that one, but I still... And we like Andy. Just know I can't support that. Yeah, we like Andy, so we're going to let this one fly for right now. Alright, so here's my tip of the week. And I need to backtrack a little bit for a moment here. By the way, his tip says

we're lazy. I have no idea where this is going. Pulpiter. I'm pretty sure that's self-explanatory way to give it away so so okay uh went to a new meetup it was really good right there's a node js meetup here in the atlanta area and you know while the meetup itself was was good and entertaining. I'm not trying to take anything at all away from that experience. You know, one of the interesting things that happened, though, like afterwards, you know, everybody was kind of like getting to know each other, talk, you know, and, you know, share experiences and whatnot. And so, you know, I met the, I was talking with the guy who runs the meetup, that particular Node.js meetup.

And, you know, during our conversation, you know, he happens to mention that he has his own podcast. And I'm like, oh, that's kind of neat. Now, as soon as he told me the name of the podcast, I was immediately jealous. This is the most awesome name for, for a coding related podcast. This is the most awesome name. Like I, I was, I was disappointed in myself that I didn't think of it. You ever have those situations where like somebody thinks of something so simple, but yet its simplicity is exactly its elegance for

that particular thing, right? And this was one of those examples. I was like, oh man, that's an incredible name for it. That's awesome. Give it up! Quit teasing! So on top of that, but on top of that, and here's where our laziness kicks ininess you're still doing it

right i'm getting there hang with me so so on top of that this is this is where our laziness kicks in right because he and his co-hosts they have or at the time had seven episodes recorded and the way that he introduces this to me is he goes hey i don't know if you listen to podcasts but here's my card it hands me this business card and i'm like after all the flipping time we spent trying to come up with a new logo, and we still don't have any business cards. Oh, man. And there's seven in. Not only do they have this great name, but these business cards are beautiful.

Give it to me. Come on. So check that out. The show title is Pseudo Code. code and i thought that's an amazing name like s-u-d-o yeah s-u-s-p-s-e-u how else would you spell pseudo code yeah it's a pseudo s-u-d-o pseudo not that kind of okay fine that would be pretty good too. Sudoku, is that it? I'm thinking spinoff podcast. Check out that business card. It's like serious quality, right?

And I gave them a listen. And, you know, you can go to sudokode.fm or you can find them in iTunes. I don't know if they're on other platforms. But they're definitely available in iTunes. And they are like,, some of their content, so I met Joe, and I don't know how to pronounce his last name exactly, so I'm probably going to butcher this, but DeCarlo, Joseph DeCarlo. Yeah, that looked right. So him and his co-host, Emlyn Murphy, and both of these guys, I mean, I have been at various meetups around the Atlanta area over the years and have heard both of them present topics. Both guys that really know what they're, uh, what they're talking about. And this was a, um,

you know, a lot of the topics that they talked about, I was like, wow, that's kind of like in the same, uh, vein of what we do, except where a lot of times we give.net examples, they do objective C. Okay. So, uh, you know, I, I thought that that was was that was kind of like uh you know here here's our here's our uh bizarro world opposite right um i thought that was interesting when did you go to this meetup um it was uh last week last thursday because it was the.js meetup here in the Atlanta area. And, you know, I mean, it was really good. So my tip of the week, so definitely go listen to, go give them a listen at pseudocode.fm. And, yeah, but the tip of the week really, though, is don't be lazy like us.

Because we're 33 episodes in now. And we still like, anytime I meet somebody at a meetup, I have nothing to give them to say like, you go listen to my show. I will say I've been trying to get us business cards for a while, but, but here's one thing. Here's one thing I will say though.

Like, and we hadn't actually said anything to anybody, man, we had a whole slew of problems. Like what? A few weeks back oh god you're talking about like when we dropped out of the store by dropped out like the first thing that we noticed was i think jay-z noticed was that our latest episode wasn't showing in itunes and we're like what's going on and then like three days later we disappear and so like

all this stuff all our excitement about getting a little more than three yeah i mean it wasn't like six okay yeah but it was not very fun because here we are we were all stoked about getting our our logo done and everything and we had some momentum we were we were pushing forward and then like we just got we got slapped. We spent days trying to figure out what was going on, and it was not fun. And do you know what it was? It was a rest verb. If only they were using gets and posts like you should.

And none of those other six weirdo ones. Yeah, options, right? No, they were doing head. So first you're stepping out with other Joes. And now you're promoting these weirdo rest methods. Yeah, because

they're good. They're necessary. Alright, well I'm going to find another git tip for next week. Non-console. A git gooey tip. And here's the thing. I'm i i'm i'm not blaming any one of us we're we're all at fault my point though is that like you know i'm willing to give us the last month because you know we did run into some complications there but man you know we're 33

episodes in now we've been doing this since 2012 now, because we did our first recording in late 2012. Very late. We still, when this man came up to me and handed me this business card, and for those of you listening that can't see this business card, this thing's got some girth to it, man. It's fatter than my wallet. This business card is like what you would be handed at a bar to put your drink on it's that kind of thick like you know this this is like

this is like a burger with stripes you know yeah no but now in all fairness this this does make me feel a little bit better at this point in time, is they still only have seven episodes. And while we may be late to the game with coming with new episodes, they definitely have some time in between theirs, too. So they literally are the parallel universe to us with Objective-C. Yeah, I talked with him about that too. They do strive to be a weekly, but yeah, definitely have had real world kind of, like us, have had real world situations get into the way of being able to accomplish that goal. But give it a listen. There was some good stuff in there. Cool.

Yeah, I'll check it out. And don't be lazy. We will have some business cards and we will have some stickers and whatnot because we need the stickers that i want yes we need to adorn outlaw's macbook if he's got any room left on it yeah man with a with a new sticker and i'm sure joe's gonna put one on there too yep i think joe's gonna put a sticker on my laptop that's gonna be, I'm going to do it too. I'm going to get one for my car. I'll do that too. Yeah, so anyways, we are going to get some things.

But yeah, it literally was a rough month with having to troubleshoot problems. I mean, you learn a lot doing this kind of stuff. I think life just beat all of us up individually too. We all individually got put through the dryer oh it really has been a rough several weeks so yeah um but all right but we do love doing this like we were all stoked i mean even tonight was a challenge right we're all like man maybe we can make tonight i'm surprised joe's still awake yeah joe's not actually still awake we don't know actually still awake. I've been asleep for 30 minutes. Now that I look at the video,

that doesn't look like Joe at all. He's now called Left Eye. Because one of them's open, one of them's not. Squinty. We hope you've enjoyed listening to this episode of Coding Box and catching up on

chapters 4, 5, and 6 of the 12 Factor app, which were the catching up on chapters four, five, and six of the 12 Factor app, which were the backing services, the build, release, run, and processes. So check out episode 32 for chapters one, two, and three. And be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app.

And be sure to give us a us on iTunes, Stitcher, and more using your favorite podcast app. And be sure to give us a review on iTunes, Stitcher, or whatever podcast aggregator you prefer to use. We greatly appreciate it. Yep, and contact us with a question or a topic. Leave your name, preferred method of shout-out, and we'll mention you on the podcast. Also, visit us at www.codingblocks.net where you can find all our show notes, examples, discussions, and more. And send your feedback, questions, and rants to comments at codingblocks.net and follow us on Twitter at Coding Blocks.

And we've actually been keeping up our Facebook page a little bit more here lately, haven't we? Yeah, it's fun. There's this thing called Facebook that we found out about. Yeah, I actually post pictures there. I don't know why I don't do that on Twitter too, but's not enough characters it eats up half of them so that's true yeah