Coding Blocks - The Twelve-Factor App: Codebase, Dependencies, and Config

Episode Date: September 17, 2015

Dipping our toes into the DevOps waters with the Twelve-Factor App. How important is depedency management, and how fired would you be if you accidentally leaked your company’s source code? News We have a new logo! Allen was right… Soundcloud Thanks for the reviews! GunBlade77 What is the Twelve-Factor App? A methodology for writing applications […]

you're listening to coding blocks episode 32 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app and visit us at codingblocks.net where you can find show notes examples discussion and more 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 at the top of the page. And with that, welcome to Coding Blocks. I'm Alan Underwood. I'm Joe Zack. And I'm Michael Outlaw. This episode is sponsored by WeWet. Save time, money, and pain with responsive cross-browser retina-ready templates that fully integrate into Visual Studio 2012, 2013, and 2015. With templates starting at only $59 with source code,

start your next mobile-ready ASP.NET or MVC web application using C Sharp or VB.NET in less than a minute. Find yours today at WeWet. That's W-I-W-E-T.com. The first marketplace for ASP.NET templates. All right, so with that, let's go ahead and get some podcast news out of the way. The first is we had a logo design contest that totally was not stressful at all. It was awesome, but man, it took some energy and it almost broke up the band.

It was the most painful thing we've ever had to do. It really is. I mean, everybody has different tastes, and that is never more apparent than when you're all trying to decide on one thing. Here's a way. If you want to challenge your friendship with anyone, try to agree on art. Just try it. It is a frustrating thing. And you know what?

The one surprising thing about it, to me at least, was we hired it out so that we wouldn't have to try and come up with anything right man do you have to babysit these things it it was a lot of work yeah you really need to have a lot of time to dedicate to it we got so many good submissions though but it was really hard to find one that we could all agree on but we did and we're actually really happy with this logo. Oh, you know, and so for anyone that's curious that didn't know, so what we did is we used 99designs to host this contest. And, yeah, I mean, to Alan's point, like, there was every, like, one thing that I wasn't prepared for, and I don't know, maybe you guys were,

but every design we had to provide feedback on. Like, this is what I like, this is what I like, this is what I don't like. Or, you know, I think we should go in this direction or that direction. And it was, it was a full-time job. It felt like, yeah, you definitely spent a lot of time on it. And, and the thing is is people spend a lot of time putting this stuff together. So you want to respect what they've done, but at the same time,

some things you just don't like, one of us likes or you know it's it was a challenge to say the least but i i really do think we got something pretty sweet out of the deal so um oh man the end product is so awesome i mean it it was a painful journey for among the three of us getting there but where we ended up with i'm i'm extremely happy with it yeah yeah we'll be rolling that out to you know itunes and a few other places but uh you'll definitely be able to see it on the show notes for this episode as well slash episode 32 absolutely definitely check it out because we are excited about it um and and so the next piece of news is i was right outlaw do

you remember in the last episode i said something about an ipad pro with a bigger screen coming and guess what happened uh did i did i dog it in the last one you said that's never gonna happen it by the way not only is it an ipad pro it has a pencil yeah that whole you know oh man i've been accused many times over the years of being an Apple fanboy. And, you know, whatever. The difference, though, is that I think like a fanboy would just agree to everything. But as much as I love a lot of the stuff that company makes, that recent announcement was just disappointing for me. But, you know, hey, you win some, you lose some.

Yep. You know, but for other people, they might have loved that announcement. It might have been great. But that whole iPad Pro felt very... Surface Pro? Surface Pro. Yeah, exactly.

And the same price points, too. You know, it's bigger's bigger hey there's a the cover is a keyboard whoa and you know but it was funny too it was also comical because like you know well the surface has the the pen so the ipad has the pencil and it's like oh come on did they like somebody carefully thought it like we can't call it a pen right right and then it was kind of comical that microsoft was on stage with them during the keynote to talk about office on the ipad pro and i'm like well i guess at this point they're like whatever any device we can be on yeah i didn't i didn't watch the keynote it when you guys were kind of shooting me some messages about what was going on,

I was just happy. I didn't waste my time on it, but you know, yeah, this is where, this is where people, you know, get that ammo for the fuel boy or a fan boy stuff because like I watch them all,

everyone. Right. In their entirety. So the next piece is, again, we mentioned last episode that we are now on SoundCloud. So any of you guys who have a SoundCloud subscription and want to listen there, definitely check it out. Share with your friends or whoever else.

And I am slowly updating all the episodes up there. I need to get back to work because we only have the first 12 up, but I will be uploading more. Slacker. I know. Yeah, and the Facebook integration looks pretty cool. 12 up, but I will be uploading more. Slacker. I know. Yeah, and the Facebook integration looks pretty cool, so if you follow us on Facebook, you'll be able to see those episodes coming out there, which looks kind of neat once we

get that up to date. Also, you know it. Thank you for the reviews. This time we've got a review from Gunblade77. I don't know if that's a reference to Final Fantasy VIII, but I hope that it is. So anyway, thank you Gunblade77. I don't know if that's a reference to Final Fantasy VIII, but I hope that it is. So anyway, thank you, Gunblade77.

Yep, it was a fantastic review, too. My boy Singleton. Oh, yeah, this was that one. I love that that's become a thing in the show. Like, the whole Singleton meme is, like, you know, it's taken off. I'm just waiting. Someone's going to recognize one of us and be like,

oh, you're the Singleton guys. I'm like, no, no. Not at all. Some hipster developer out there is really upset because Singletons are coming back into the swing. It's an anti-batter. We're the utility library guys. The helper class?

Right, the helper class. All right, so the news was pretty short this this go around so let's go ahead and jump into the main topic here and that is 12 factor applications yep and we're not going to talk about all 12 factors because um you know we're kind of opinionated people and we like to talk so we'll be splitting this up into a couple episodes yeah there's a lot of meat here so yeah so first let's get into this uh you know a little bit of background on what this is right so it's the 12 factor app this was a a how would you describe an article uh published by some guys from Heroku, right? Actually, a co-founder. Okay. That they're documenting, like, you know, the ideal app, right?

Like, based off of their experiences, what they've seen works best for an app, and that's what they've documented here as the 12-factor app. So we're going to be going through some of these. They've got it broken down into chapters and each one of these chapters is, is short. You know, it's not like a, uh,

you know, Stephen King novel, but, um, we're going to be going through it for a few of them today and see what happens. Yeah. And just to clarify,

one of the things that they say on there is that the, the goal of this is for writing apps that are software as a service, which is kind of interesting. It definitely leans towards that as we get into it. But some of these or a lot of these are things that are probably pretty good practices for writing any type of application. So it was an interesting thing that they pointed out that they said the end goal is software as a service. But we'll see as we go that a lot of these things apply across the board. Yep. And I was actually kind of thinking about this.

In a way, it's kind of like a design pattern for your product. So if you're part of a company that's designing some sort of application that lives either on a you know server or you know maybe cloud whatever something like that then it's kind of like a guideline for how to kind of put those pieces together so there's not going to be anything about like ticketing systems or kanban boards or scrum or anything like that it's all based around like your product the code the application you know this the stuff that you write all day. Yeah, and one of the interesting things is we had put out a thing on Twitter a while back saying, hey, is there anything you guys really want to hear about?

And Andre actually replied and said he'd like to hear about ALM, so Application Lifecycle Management type stuff. And this is one of the things that kind of feeds into that. So this is – Oh, this is right up there with that. Yeah, this has been out for a little while. and like i said but it's it's a quick read and it's got a lot of good good things so let's go ahead and get into it um one of the guiding principles well hold on you say this was been out there for a while like uh actually on the site i didn't even

realize how old this is but it's actually been out there for a few years now. Yeah, I think I saw references to it back to 2010. Yeah, I heard very recently. Yeah, it seems like it's definitely been making its – I've definitely heard more about it here more recently than I did – I didn't hear anything about this three, four years ago. Right. So I thought that was kind of interesting. It seems like it's gaining popularity suddenly like it's popularity just sprung up it probably got mentioned on a podcast so um one of the guiding principles that they have one of the first things they say is you

should use declarative formats for setup automation to minimize the time and the cost for new developers joining the project. Well, before we go too far down this, like what is declarative? What is a declarative format? And this is something that I wanted to point out for anybody that is not familiar with this stuff. So when you talk about a declarative format, it's basically something that describes what the app is supposed to do as opposed to how to do it. So when you write code, you'll say, Hey, do this part first, do this part second, do this part third, a declarative format is, Hey, we want to do this. Right. And so it's a pretty simple thing. And so the, the opposite

side of that is imperative. And the imperative is actually what tells you the steps to accomplish the thing. And one of the interesting things I saw in this Wikipedia article is there's like this bit of gray area. Because procedural programming in and of itself could almost be considered close to declarative. Because you can look at the name of the subroutines or the methods or anything there and if it's named well and it's a consistent way you should be able to kind of tell what it's supposed to do but it's the actual implementation of those things all put together that becomes your empirical programming well there's two clarifications because because one the declarative formats was for setup automation

that they're referring to. And specifically these guidelines were what a 12-factor app is. What the methodology is. Right? So one of them is using declarative formats for setup automation. Right.

And a good way to explain it, I think, right? So one of them is using declarative formats for setup automation. Right. Yeah. And a good way to explain it, I think is, um, like a PowerShell script is imperative. It's do this, then do that, then do the other thing.

Yeah. I was kind of thinking like a, uh, like an NPM, uh, script, you know, where you're like,

uh, or, or, you know, a list of Bower commands, you know? Yes. That would be imperative.

And the opposite would be like an XML, XML file or, uh, you know. Yes, that would be imperative. And the opposite would be like an XML file or, you know, JSON, just a data. You're saying the data would be the declarative, right? Right. So I'm basically defining like this is my version. These are the things that I need. And, you know, you just define that format or define it in that format. And someone else is responsible for actually going out and fetching that and setting that format and define it in that format and some someone else is responsible for actually going out and fetching that and setting that all up right it's it's

basically a human readable approach to it like you can glance at it and kind of tell what's going on so it was interesting that they said to use that particular like that was one of their key things is you know that's the first part of it so the next thing is is you have to have a clean contract with the underlying operating system offering maximum portability between execution environments we'll get into that deeper as we go or they have to be suitable for deployment on modern cloud platforms obviating the need for servers and systems administration. Now, this kind of goes back to the whole software as a service type thing, right? That's probably one of the reasons why they state that.

It's not a bad idea to write any application that way anyways, because if you make it to where it's flexible enough to be moved on to, you know, different type of environments, then that kind of takes care of itself. Yeah, and if you're writing the next version of Paint, then a lot of this stuff, it doesn't really make sense for you. But if you're doing any sort of like kind of modern web app development, then this is right up your alley.

Yeah, absolutely. I don't know. I mean, I would agree that I would say that some of these factors still apply regardless of the type of application that you're going to build, though. I mean, we'll get into some of these, but some of these are just like how to structure the code necessarily. Right. That doesn't matter what the end app is. Right. But you're not going to try and put paint on a cloud platform, right?

To Joe's point, that's going to be very much specific to an OS, right? No, but here's one of the things that I guess where I'm going at with this though, is that like these 12 factors, like these guidelines, these introductory guidelines that you're, you're referencing, right? They mentioned the cloud platforms, but actually the 12 factors themselves, there's, there's no, no one part of the 12 factors that are dependent on cloud right like that and that's what i'm saying like these factors could apply to any type of app that doesn't it could be you know an ios app or you know the next ms paint app or whatever you know yeah and for your app you could probably go through this checklist and say yes yes no not applicable you know for the things

that maybe don't make sense to your specific product. Yeah. I guess like, um, to your point on that, the, the one thing that where that doesn't apply though, and I think this is why the whole cloud thing comes into play is when they start talking about scaling out and that, that gets further down into the actual, you know, if you're just creating an MS Paint app and that's scaling up, then

that's a point because it's like well every install can scale. So it's like, you understand what I'm saying? Yeah, that's what I'm saying. That's why like this whole thing being able to go on cloud. They mentioned cloud because it was Heroku, but it's not

the factors I I think, are more abstract than just cloud is my point. So I don't want to turn anyone off to it and say like, oh, I'm not doing cloud development, so none of this is going to apply because my point is actually the opposite. All of this still applies regardless of the type of app. Yep, and I think even if you're starting small and just living on one server, if you

follow these guidelines, you're going to be ready to take that to a multi-server environment because everything is going to be separated nicely and modular. Yeah, and that's really the key points of it and they do it all the way across the board. So the next one we have is minimize the

divergence between development and production, enabling continuous deployment for maximum agility. If you've ever been in a situation where that is not the case, then you know how crazy it is to try and make your applications work. When things have diverged too much, like you start troubleshooting things

that you should never be messing with. So that is a huge key point yep yeah and and many times now it seems like more often than not that divergence is data oh always and and that's the one that i hate the most when it comes to you know the differences between development and production yeah a few times when i worked with products that would work with like server farms or you know sharepoint farms and uh i didn't have a good way of mocking that and so it's just kind of like i think this is what's going to work and then you would kind of throw it up in some sort of lab environment to test it that feedback cycle is just killer so it is interesting though i mean if you think about it and we all agree,

it's very difficult when those things do diverge. So you have a development environment that's not set up similar to your production environment and it may be a data thing, but then it boils down to how do you get data, you know, that, that actually mimics that type of stuff, right?

Like you can't bring real customer order information or credit card information or any of that kind of stuff down to a development environment right so yeah you need the netflix chaos monkey yeah but for data yeah no but there was another thing though that this one reminded me on too and uh for any you know developers from like you, old school days of, you know, your pound defines, right? So, like, pound debug or pound release, you know, type environments. I don't know if, you know, either of you recall that. But, you know, you might have a statement in there to say, like, you know, there was a preprocessor declaration to say, like, you know, pound if debug. Then you'd have a block of code and pound end if.

And if you were running in debug mode, and the compiler would leave that part that code in, and you would see that code get executed. But if you were building the release version of it, then that code got removed from it and never even ended up and it let alone did it not run it was never even in the final binary and so right away you know this is an older practice but you know right away you had this divergence in your development binaries compared to your release binaries yeah and that could be a, a huge problem in and of itself. You have something that got left in that you didn't know was supposed to be there. So, yeah, this is probably one of the hardest things to actually tackle, especially in a development environment where you're making fast-moving changes.

But it's definitely a good point. The next one is, can scale up without significant changes to tooling architecture or developmental or development practices. And again, one of the cool things about this whole thing is this really applies to just about any programming language, any backing service, such as a database or anything like that. Really, these are, I think Joe said, or no, I think outlaw said, this is almost like a pattern

you know for development so as long as you follow the principles behind it then then it can ease some of your challenges as you move along well and just to clarify that when you say pattern for development more like pattern for the development team right because this isn't this isn't like a pattern for the code necessarily as well as like structuring everything like how the group works yeah you know back in the day it used to be enough to just be a front end or back end and now you know there's this whole full stack thing going on and now they're bringing in dev ops so developers are wearing more and more hats and it's kind of because you need to wear more hats because things are getting more and more hats, and it's kind of because you need to wear more hats

because things are getting more complicated and integrated. But I just thought it was kind of interesting. We're definitely dipping our toes into the DevOps waters here. Oh, yeah. Also, I wanted to mention while we're on this kind of introduction here, do you guys ever see Joel's 12 questions? No. Joel Smolsky? Yeah, he used to have 12 questions no joel supposed to be uh yeah he used to have um 12

questions that you could use to kind of um identify if uh this like a company you were interviewing for was a place you wanted to work and has questions like do you use source control can you make a build in one step do you make daily builds and so on um so i just thought it's kind of interesting that this is kind of an evolution of that. And the Joel questions, actually, there were 12 of them as well. Are you talking about the Joel test, 12 steps to better code? That's it. Okay. Huh.

I'll be reading this. Yeah, it's got other stuff in there, like do programmers have quiet working conditions and stuff. So it's a little bit more geared towards a different audience, but it's still interesting. Very cool. Yeah, it's an older bit more geared towards you know a different audience but it's still interesting very cool yeah it's uh it's an older article too yeah but it's still these questions i'm looking over these questions now and they still seem very relevant yeah joel is still my hero even though he quit blogging and i'm sad about it uh i have the books do you use source control no all right this interview is over in 2000 though that was you know that wasn't common yeah that's a good point it's come a long ways this episode is sponsored by digital ocean they are a simple cloud hosting platform built for developers you can deploy an instance in under a minute their lowest price plan starts

at under one cent per hour. You heard that right. For seven-tenths of a penny for just an hour's utilization, you can have your own instance or droplet, as they call it, up and running. You pay for the time your droplet is active. Head over to DigitalOcean.com and use the offer code CODINGBLOCKS, one word, and get started today. All right, so let's go ahead and dive deep into some of these 12 factors. Let's start with the first one, which is chapter one, code base. And this one's right up your alley.

So why don't you go ahead and take this one? Yeah, this one's literally like if you're not using Git, you're doing it wrong. I think that's what the takeaway was. No. Okay, fine. I joke. it goes a little bit deeper than that and um this is something that i've run into everywhere that i've ever used git is um at what point do you start splitting repos yeah yeah okay so fine i

was joking around about that but it was saying that you know it's defining the code base is tracked in revision control and that it can have many deploys right and that um you know, is defining the code base is tracked in revision control and that it can have many deploys, right? And that, um, you know, a code base is a single repository, right? And some, uh, centralized, you know, system, whether it be subversion, God, or get, which, you know, be the preferred way. And, uh, you know, any other set of repos can share a root commit in that repository, like in a Git environment, right? And what else to say there? That you could have multiple code bases. Help me out here, guys.

So what's a code base? code bases. Um, uh, help me out here guys. Well, so what's a code base? You know, if, if I've got a website and a mobile app, is that a code base? It's two code bases. So that,

that was really the, the key point is there is a one-to-one correlation between the code base and an app. A code base does not have multiple apps. That, that, that's what I was trying to get to. Thank you.

The, is that, yeah, Codebase does not have multiple apps. That's what I was trying to get to. Thank you. Yeah, because if you had multiple apps sharing same code from that codebase, then that is a violation of the 12-factor app. So we just put all in one codebase. So this is the point that Joe was making from the beginning there about when to split up the codebase into individual repos, right? And as soon as you have some code that's being shared, then that's when that code should be broken out into a separate repository, separate library, that could then be shared as, you know, through some kind of a dependency manager,

whether it be Nougat or, you know, a Bower or something like that. Part of a factory, something, whatever. Yeah. or a Bower or something like that. Part of a factory, something, whatever. Yeah, but a code base is a single app. It's not multiples. And that's a very important thing to identify because it gets into the next part that we'll get into here in a minute, but it has to be one. If you've gone

further, you violated it and it will actually cause you problems down the road. And that's why it's such an important takeaway on this. Yeah. And I think a big part of this 12 factor app is really just drawing clean lines to things. So if you had like one repo that had your website and your mobile app, then in that repo, there's going to be code that's shared between those two and so it's not really website it's not really mobile it's a shared library and you know what happens is this stuff starts getting out of sync and it just gets real messy but if you had like clean modules defined and we're bringing this stuff in yeah it's more pain to set up you know the the proper packaging but it does keep those things you modularized, and it doesn't let you cheat those rules of abstraction. It goes on, too, to talk about deploys as well, as that there's only one app per code base, but there could be many deploys of the app, right?

And the deploys are different than the code base, right? There's only the one code base, but you could have multiple deploys of that app, and each or we could even say since code base equals app, you say many deploys of that code base. But any of those deploys could be at a different commit level, right? Like you could have a staging environment, a development environment, a production environment, right? But it's still, you know, they're still running the one code base. They came from the same repo, essentially, is what it boils down to, right?

So your production one is probably on a stable release. Your staging one is on the next, you know, ready to be released thing, your development environments on your latest development code. So yeah, right. My,

my development has commits the head of staging and staging has commits ahead of production, but they're all coming from the same route, same repo, same app. So I think it's safe to say that if you're logging into a server and changing the files manually, that you are not, you are not participating in a 12 factor app you've completely violated at that point oh my god are you saying you do that any rules and back in the day php cold fusion ruled the land it was you know it was different times oh dude i've done things i'm not proud of

dude cold fusion was literally just hack away at the files until you got it to work. And then try to remember to bring it back down, right? Yeah, it's a different ballgame. Somebody also put here importance non-negotiable. Yeah, so I found an article. We'll have a link to it in Clearly Tech. It was kind of written to a slightly different audience than programmers. I'm not really sure what the audience is but i thought that was pretty cool that they put in

an actual uh importance on each step and uh so i thought we'd talk about that and for this one it was non-negotiable like this is a requirement for any sort of professional you know working development shop oh yeah that's pretty cool yeah okay so i think that's about right i can't imagine like that would be the first thing i did a new job or you know even starting a new project like that's like number one for me yeah i would agree with that that's i mean we've all been in projects where you have this one monolithic type app right that really has like 20 different apps rolled into it and it's really a pain to keep it all managed properly. So yeah,

that's a good one. Yeah, I agree with that. Yeah. So real quick, I just want to take a moment, you know, we've said this before and you know, I don't mind saying again that,

you know, if you've already left us the review, we really, really appreciate it. But if you haven't, we would be forever grateful if you would please take the time. You can head to codingblocks.net slash review to find quick links to Stitcher or iTunes. Or if you have some other preferred podcast aggregator that you'd like to leave a review at, we would greatly appreciate it. Leaving those reviews helps people to find us. We've all seen how the iTunes algorithm works, and there's definitely something to be said

about as people take the time to leave feedback on the episodes, what it can do to the shows as far as it bumping up in the, uh, in the, in the list there. Yeah. All right. So thank you. Uh, also, uh, let's get on to number two here, which is dependencies. So we talked about two chapter two, we talked about code base, which is everything that

we're kind of working on. We're generating this code base. We are actually making this. Well, dependencies are everything that you don't make. That could be your bootstrap files. That could be third-party libraries. That could be all sorts of stuff. And just for fun, how many package management solutions can you guys name in 10 seconds?

Oh, my God. NPM. NuGet. Gems. many package management solutions can you guys name in like 10 seconds oh my god npm um nougat gems uh i don't even remember i feel like there's like some trick that he's going at with this though i'm so i'm like waiting for the punchline yeah sorry i thought you guys were looking at the show notes where i've written a bunch of them so i was trying to set you guys up to sound like super on the ball oh okay yeah but yeah the point is that there's a lot of them and this has been a big problem but there are a lot you have like gulp and grunt in there right those don't count yeah those are task runners yeah but a lot of times those tasks are in the pearl like make sure you're gonna count pearl a c-pan but yeah c-pan fine bauer is not pearl yeah bauer's one yeah but i feel like a

lot of times those are doing those sort of things they're managing dependencies a lot of times maybe that's not a but you know one thing that's not mentioned here though that is very soon coming uh as a dependency is you could also you know it's we're getting to the point to where with with services like docker right where we can abstract away the uh you know the environment as well right and that's a dependency too yeah you specify the version of linux you need and uh it just kind of happens somehow yeah so one thing that you said a second ago that that is kind of interesting and somewhat misleading is it's all the stuff that you don't write it can be stuff you write as well we just talked about a second ago that that is kind of interesting and somewhat misleading is it's all the stuff that you don't write it can be stuff you write as well we just talked about a minute ago if it's something

if it's something that's shared between multiple apps then it should be a package that gets brought in as a dependency so it can be your internal stuff too that are various libraries that get pulled into multiple different applications. Good point. So, um, one of the things that was interesting about this one is it says it never relies on the existence of system wide packages. Um, I know we've been doing.net for a while.

Can you say goodbye GAC? I mean, and hello, ASP.net five. Yeah. Which is excellent. I mean, you actually, you declare your dependencies. I mean – And hello, ASP.NET 5. 5, yeah, which is excellent. I mean, you actually – you declare your dependencies. Like, I mean, we've all had issues with GAC, right?

Like, you go, you install something, and you're like, why is this not working? So, for those that aren't familiar with it, right, the GAC is a.NET specific thing, the Global Assembly Cache. assembly cache and and the goal of it was trying to get away from what was commonly referred to as dll hell right where it was like okay well what version of the dll do you have that this is trying to load in and where is it coming from and things like that and so the gac was trying to like centralize that as one repository and make it all nice and simple but then that became a real problem because then as multiple apps all dependent on this one version and you needed to maybe for security reasons you want to not have that version of dot net or any of its assemblies or any of those assemblies available you know now it became a big nightmare because you're like, well, I don't know which applications are using this thing.

Right. So you had this basically like a global parking lot of stuff that it became difficult to know who needed it, why it needed it, and managed it. Versus take applications on the flip side where everything is local to their directory tree, for example, right? So that's where ASP.NET 5 is going and is pretty much catching up with the way a lot of other platforms already are. Yeah, it is interesting. I mean, they went that route to simplify things, right? To make it easier.

And it really ended up causing more problems. Like, you have to bundle everything in order for which is the new way of doing things to isolate them properly right to sandbox those so that you don't have to worry about those external um variables that that occur and and they tried to make it better but ended up causing way more pains in the long run. Yeah, I think this is, the GAC was envisioned back when people were still on dial-up, and so we were concerned with downloading DLLs, and like, if we could just share them somehow. We could really cut down on those 20-minute downloads. Yeah, I mean, it completely...

Well, yeah, I mean, there is something to be said about, you know, only have, instead of having like 20 copies of the same library, if you'd only have it once, but from a maintenance perspective, it does make it a lot more difficult. So, and that's where, you know,

from the 12 factor app is coming from is that, you know, this is something you're going to have to maintain, right? So you want the, you want to know the dependencies and you want them, you don't want to just rely on things magically appearing right yeah and i mean a perfect example of this is you have some app that somebody wrote five years ago you need to put this on a new

server somewhere you can't get a copy of you know windows server 2000 or whatever so how are you going to make it happen right like and and with including these dependencies in line in the app, you don't run into those situations. Not as much anyways. So here's a trick question for you. All right. So at the, the beginning of this article,

right. It starts off, it starts off with saying that the, you know, this 12 factor methodology could be applied to apps written in any language. Right. But if we're saying though, that you must explicitly declare and isolate your dependencies, right?

Well, then does that exclude.NET apps? Yeah,.NET is getting better with the new stuff they're doing for ASP.NET 5, but it's been frustrating for me before to try and deploy an app somewhere and find out that they don't have.NET 4.5 installed or something like that. So that's definitely been a trouble spot. Yeah, it's interesting because that is a problem. I also included a link that we'll have in the show notes that is how to bundle things. And there's all kinds of like hints and stuff that you can do so that even if something

is in the GAC, you can tell it, hey, I want you to look at my bin directory. Well, okay. So that's where I was kind of going with this though, is that because while I've never tried this, maybe theoretically it's possible, but it sounds like it would be a nightmare to find all of your dependencies. But the way that works though is that it'll look first in its executing directory path before it starts reaching out into the global assembly cache for it. So technically, if you were looking for something like system.net and you had that DLL side-by-side your exe, then it should use that one first, right? Hopefully.

I've never tried that, but then this is where I was getting at, is like, well, any references that that system DLL wants to make to other parts of the.NET framework, like you're going to have to have all those interdependencies side by side with your app. It's not going to be big. Yeah, now it becomes a nightmare. Obviously, we're talking like pre-ASP.NET 5 type apps.

Which is brand new. Yeah, so everything pretty much. Yeah, pretty much everything before you heard this. But I've never tried that. I've never heard of anyone that's tried that. I mean, maybe with some third-party DLLs. That's done, and I've seen that done, and I've done it myself, but never with the core system.NET DLLs. And that's why I was bringing this up is like, well, you kind of can never do that then.

It would be difficult. It would be – Or it's not practically done. Let's put it that way. Right, right. I've never seen it practically done in a.NET environment that would meet Chapter 2 of the 12-factor app. Well, that kind of brings me to another question. So they say that you have to use dependency isolation tool to make sure no additional dependencies leak in.

Now, that was – so you just asked the question that I was kind of curious about except for this one. I don't know of a dependency isolation tool for.NET. So the only thing that comes close that I can think of is like MSBuild, where it does your build stuff for you. But are you guys aware? But that's not isolation, though. I know. That's the whole thing. That's really just...

That's just the build the build and yeah so that i don't even know what would be the what would be the tool that you would use for dot net i'm not aware of anything yeah i was thinking um there's that program depends which will tell you dependencies of dlls but that doesn't help you if you like shell out to something like image magic for resizing images or um you know in a lin Linux environment, if you, you know, try to, if you shell out a WGET and whatever install, you know, whatever you install next doesn't have that particular program installed on it, you know, that could be a real problem. And I don't know how to find those.

All right. So you've convinced me. I'm full-time Ruby and JavaScript from now on. There it is. I'm done. I'm done. You know what? I can't, you know, isolate my dependencies. We're done. Does know what? I can't isolate my dependencies.

We're done. Does this work for Swift? Can we change the name? Do we have to change? We're now codingblocks.js. And we're the 11 Factor app. Awesome. All right.

Oh, and one thing we didn't really hammer on, though, but a big part of this whole dependency part is actually explicitly declaring them. And there's that word again, declare. So they're talking about having some sort of manifest file, maybe JSON, maybe XML, maybe YML, whatever, that actually lists all the things that your app needs to run. Yeah. I mean, NuGet has their own file that manages that stuff. I mean, a lot of the package managers do, like Bower, NuGet, all those.

They kind of create that or they handle that manifest for you. So it's nothing that you actually have to do much with other than say, I want this package. So, I mean, that's usually fairly easy. But again, the isolation is kind of what tripped me up is I, I'm not aware of anything for.net anyways. Yeah. But how annoying is it that you have to have multiple manifest files, right? If you're doing a,

you know, an ASP site, you might have new get, you might have a Bauer, you may have NPM in there for some stuff. Yeah. Yeah. It's things are getting complicated.

Yeah. So instead of one manifest file, you've got 20. Yep. And that's realistic now, especially with web development. Now, one of the cool upticks or the really nice pieces about this is if it's done properly, it would make onboarding new developers pretty easy because in theory, they'd be able to check out the code base

run the build tools and all the dependencies would be pulled in everything would just be set up right like you mentioned docker like if it was something like that like it would set up your entire environment and you'd be up and running no time i mean and i know we've tried to help developers in the past try and set up something for for an application that's not well documented or scripted like that. And, you know, it could be a half day trying to get somebody set up. Well, and this kind of goes back to Chapter 1, right? Because, like, ultimately, deploying the 12-factor app should be simple, right? Right.

And so getting a new developer set up is just another deploy. Right. You know, if you think about it at its most basic level. That's a really good point. And that's almost a good test to know whether you have your dependencies under control. You know, how long does it take you to set somebody new up? And how many steps are in your, you know, deployment to a new environment document? If you're hitting, you know, dozens of steps, then you probably have a problem.

Yeah. But Alan does bring up a good point here. So maybe let's put this question out to the audience. If you are using a good isolation tool, dependency isolation, regardless of language, tweet us, email us, let us know. I'd love to hear what tools you're using out there. Yeah. It was like Googling it didn't bring up much.

So, uh, hopefully somebody knows you should bring it. So they just copy Google, right? Uh, that's good. Well,

now it's, it's reversing. Actually, Google has been taking on more and more features from being, I don't know if you guys have noticed. Oh no. Oh my God. I'd never go to being metals for all my searches.

I'm just making it up. All right. Oh, no. Oh, my God. I'm going to start getting medals for all my searches. I'm just making it up. All right. So where does this one rank in with the management then, dependencies? The article had it as a high. What do you guys think about that? I think dependencies is extremely important. Again, I don't know about the isolation, but I definitely agree that breaking your dependencies out to that uh you know without this you're gonna have this constant slow time suck of confusion and frustration right so you

know yeah okay fine don't make it mandatory but it's really in your best interest to make this mandatory right have your dependencies declared and isolated yep and. And I'm going to put this one, I, you know, I get why it's high and I think it's really important of course, but for me, this one's kind of like a medium and that's because depending on your particular setup, you know, if you have a complex setup, but with not a lot of environments in it, it may be worth it for you to take on some of that technical debt, at least in the beginning, I think. Um, well, it's harder to add in, I guess that technical debt, at least in the beginning, I think. But it's harder to add in, I guess.

Here's why I can support the high, right? And that's a weird statement. So my reasoning is, have you ever been in an environment where, especially if you're new to the environment and you're trying to get your environment set up and it's just not building and you can't figure out like why what am i missing and then like hours later after like digging through the code trying to figure it out someone's like oh yeah you got to install this other third-party thing and then that makes the magic happen and you're like wait what like you, whether that be, you know, a payment system, you know, development, you know, SDK or, you know, some other magical tool for, you know, I don't know, like the what's the the data tools for Visual Studio? Something like that.

We've been in those environments, and that sucks, because especially when you first get there, you're brand new to it, and you're like, okay, man, I can't even. You want me to work on this thing, and it's not even working from the start. I pulled the repository down, and it's already broken. So what am I supposed to do with this right yeah i worked uh somewhere once or it took me a week to get my the product um building and i was i was sweating bullets you know i was so nervous i i must be an idiot i can't get this working and by the time i got it finally working there were vms involved and all sorts

of weird stuff and i had my one-on-one with my manager it's like yeah you know i'm still iron you know getting the kinks worked out. And he's like, oh, yeah, it takes everyone at least a week. Yeah, you know, you're good. Like, oh, my God. It's like trial by fire. Yeah. Yeah, I feel like that should be one of Joel's 12 questions.

What was that? Florida Thunder, baby. I think Joe's house just fell on him. Hey, if it did, I got dibs on the ruby slippers. Hey. Well, the good news is the rain's going to be done in like five minutes. Yeah, because it's Florida, right? And then it'll start up again in about two hours.

Yeah. Yeah, like the wind is probably picking up alligators and throwing them against the house. Yep. Got to get aluminum screens to Keep those gauges out. Oh, that's awesome. And hey, this episode is sponsored by Infragistics. Great apps happen by design. Build your application right from the start with rapid prototyping, UI controls, and the

support you need to develop the ultimate experience. Head over to Infragistics.com and download your free trial today. All right. So let's get into chapter three, which is configs. Configuration. Storing your config in the environment. Okay. So what is a config exactly?

Is that like my version of.NET? What is that? Well, I would think that versions would be part of your dependencies, right? Like this is more like a – I'm thinking more things like connection strings. Yeah. Right? Like – Payment system passwords, you know.

Things that you'd be tempted to put into like a config file, whether that's some kind of text file, XML file, JSON file, whatever. It's some kind of – I'm thinking it's some kind of human readable file, right? Okay, yeah. And also a good way to differentiate between the dependencies is these are things that could vary by deployment environment. So a dependency, you know, I need SQL Server, period. That doesn't matter if that's stage, production, whatever. But a configuration, a password is something that, that you know should be different in those environments well yeah and to be more clear on your statement there though because according to the way the 12 factor act has is written is that that an app's config is

everything that is likely to vary between deploys okay right yep and so credentials, you mentioned specific resources like SQL Server, maybe for local environments. You know, if again, thinking in like a.NET world, you're using IIS Express and local DB. But in your production environment, you're using IIS or SQL Server. Yeah, and I think it's important to draw the distinction there too because if you're working in a Spring Java kind of environment, you're going to have a lot of XML files, but those aren't the kind of configs that we're talking about here because those don't change between deployments. Those are just kind of wiring your application together.

Right. Here we're talking about the kind of settings that need to talk to external services and things like that. Yeah, these are literally things like passwords or anything to make connections. And that is an important distinction. But I thought the cool part about it, and is something that probably just about every .NET application breaks, is you should almost always try to avoid putting them in config files, right?

Which is so easy to check them in that way. Yeah, and that's the key. It makes the point to say that storing these configs, this is often stored as constants, right, either in the code or in some kind of config, and it points this out as like, hey, this is a violation, right? You should have that configuration data. It should not be committed into the code base.

Right. You should never have to change the code. Your code should be able to run without those constants defined in the actual code. But they point out you should try and do it in environment variables in the particular OS that you're working in. So in Windows, you have your environment variables. Linux has places where you can place those things. And there were two reasons for it, right?

One is you can leverage the OS's ability to use those environment variables. And the other was the source code. Like if you don't have a config file, the chances of you checking it in are zero, right? But it does go on to point out, though, that this doesn't include, this does not include internal application configuration. So, like, I think Joe mentioned Spring. The code, right. You know, how the code modules are connected in Spring, that doesn't count. Similarly, like, you know, dependency injection,

like if you were using Unity, for example, that wouldn't count according to this definition. Right. It's, it's more so your, your passwords, your private and your, and your keys and stuff that you use to connect to web services, your database connections, like you mentioned a second ago, all those kinds of things that would change from environment to environment. As far as how you're going to connect your permissions, your credentials, all that kind of stuff. Maybe even, you know, how many rows you show on a page, something like that, right? That's the kind of thing that you could set in an environment variable somewhere, or what they recommend doing in an environment variable.

That is what you should be able to do that wouldn't break your application, right? If you took away a Spring config file, your whole app crashes, right? Same thing with Unity or maybe any other type of thing like that. So one thing I thought was really interesting about the environment variables is this notion of, they call it orthogonality, which is, I looked it up, it just means right angles.

But what it really means for us is that you can have different environments even on the same computer. So if you wanted to spin up different processes and say, have like a different port number or something like that for each one, then that's something that you can easily do in the environment and you don't have to worry about managing these files. You know, it can just kind of get that data from somewhere and save it for its particular session. And then the good test that somebody actually put in here that's so true is,

can your code be open sourced right now? Basically, could you take your code and upload it to Git and be perfectly safe and sound that you didn't have any passwords in there, that you didn't have anything like that, that you would basically just really shoot yourself in the foot. Yeah, I like this question. How fired would you be if your application was open sourced right now? Just a little fired or a lot fired?

Right. Yeah, if you've got credentials in there, then you're definitely fired. Yep, big time fired. And again, we've done something like this in the past right like so web.config is one of the key things that's used with.NET file or.NET web applications right and they kind of get abused and that's where you put a lot of your things like your connection strings and all the different types of settings but um a previous engagement we had actually worked on something where we took a lot of those variables and stuck them into IIS up on the actual server, right? Which would be like its environment variable.

So instead of having a web config that you check in, you put that on the server and you're good to go, right? Well, I guess where I was thinking about, or I thought you were going to go with that too, is that specific to.NET environment, right? Like there's the web config or an app config that are specific to that web application or the application. But there's also machine level configs too. And so you could have some configuration. Maybe you want to have some credentials that are available system wide. I don't know. I guess as I say that, it sounds bad.

But maybe you want to have those credentials system-wide, and you could put that stuff into the machine config, which is rarely going to be touched. Right. And the beautiful thing is now when you go to deploy your app, you don't have to worry about munging up your config files before they go into a particular environment, which is a lot of times what happens, right? Like you will transform a web config or probably even

in other languages, you'll, you'll have it overwrite keys here and there. If you have something like these environment variables set up, you don't have to worry about that. You just deploy the app and those environment variables are already there. You're not going to overwrite them. They're in a completely separate space. And so your deployments become much less painful. Yeah, another thing about the machine config, again, very.NET specific though, is that at the end of the day, that's just a file. It just happens to live in a system-specific directory space, but it's just a file.

So it makes it easy to move that around, is my point. So going back to the Docker kind of point or Puppet or Chef kind of scenarios, being that it's just a file makes it a little bit easy to move around. Yeah, but you do lose the orthogonality, which is also a problem of storing your stuff in a database. And also, I was kind of wondering, you know, why not the database? But then another reason is, where do you store your connection string for the database? Right.

Yeah, but I also see that as like, that seems like a very specific need, though, where you would have duplicates of the environment variables that don't clash with one another, but yet multiple instances of the same app would know which version of the environment variable to use. Like, that seems... Well, you can have your own environment. So, like, if you're running in your own kind of, you know, subshell or whatever, you can have your own environment settings that get overlaid in are specific to that process so like imagine if you start up a shell you start up a subshell

inside of that then you can apply environment variables inside that subshell and it's not going to leak outside yeah but is there's also there's still user configuration specific. I mean, again, we're harping on.NET, though. That's specific to that user, though, right? I guess I'm thinking, like, I guess based on what you said about it being specific to the user, it made me kind of think in, like, a Linux world, you know you know, where like your bash profile might load up, you know, environment variables, environment variables specific to you and mine might load up similar ones, but specific to me. Right.

And you could do similar things in a windows environment with a, with the user configs. Right. So would that not solve that? Yeah. I was just kind of thinking um sometimes with cluster environments like you have to have like a unique identifier and so if you had um you know a couple different processes running and they were clustered although they were all in the same machine which doesn't make a lot of sense then you might you know need to have a different guid

in each environment that that process is running. That's a totally contrived example, though. Hmm. Yeah, I guess the only thing that does make it a little disappointing, though, about this is that this configuration is a dependency on your app, but it's now separate from your app. It was the only thing that's like, we still have that part that's not quite solved yet does that make sense yep and you have to bring in another tool really to manage this because you know you're talking about things being different in multiple you know prod staging whatever so how do we keep those separate do we you know do we check those into source control

like how do we keep track of these things? Yeah, that's a little more difficult. The answer is not source control, by the way. Also, speaking of this, a really bad practice is naming variables. Wouldn't that depend, though, on what you're using? Yeah, I guess so. If you're doing some sort of puppet or chef,

then you would want to check that stuff in, right? But then you've got the problem of secrets and the GitHub problem again. Yeah. Okay, okay. Like if you're speaking specifically to credentials, then yeah, fine. You don't want to check in credentials. I'm with you on that one.

Yeah, but you can chase your tail all day long in the whole, you know, the key problem. Yeah. So one of the other things that they pointed out that is extremely true you should never name any kind of environment variables or config config variables dev underscore or staging underscore or prod underscore they should be consistent because once you start going down that road your app has to handle these things and so now it's looking at different types of variable names that may or may not exist in different places. So never prefix your environment variables

or your config variables with environment-level information. Yep. Oh, right, yeah. Just don't prepend it with any kind of... Yeah, okay, I got you. Don't prepend it with dev, test, or prod. Right. Yeah, okay.

So what do you guys think of the importance rating for this one? I kind of cheated. Yeah. Yeah? I'm reading it. I don't know. I think this one might could be a little bit higher because I'm definitely not a fan of accidentally checking in passwords to source control. Yeah, I'm a little bit higher on this one.

I would call myself like a high minus on this one. Because they listed it as medium. And I don't know. It feels a little short. Yeah. I mean, definitely. So from a security point of view, I don't like the credentials leaking in other things. I can, I can see why it becomes why they rated it as a medium though. Like if you take everything credential, you know, talk out of consideration and we're talking about other things, then you can kind of make the sounds like, eh, okay, fine, I see where you're coming at with Medium. Yeah, but I feel like how many times have you seen a problem

where something got deployed and a setting was lost or forgotten to be added, you know, a new setting was not added and it caused, you know, a big outage? Like, that happens all the time. Yeah, it really does. So I kind of think of this as being a part of that solution. Well, yeah, I guess that makes me question then, like, are we talking about a configuration

that's internal to the application, right? Because remember, those type of configuration things are part of the code base and are checked in. No, we're definitely talking about, you know, I don't know it throw away password you know something that says how many records are supposed to show on your page or or something like that right like that gets left out and all of a sudden your app needs it and it breaks right and it's because this stuff isn't checked into source control it's not automatically deployed right

so let's say you're adding a new caching, you're adding a memcache functionality to your website. I want to revise my answer because as I go back and I look at this again, because I had said taking out everything credential-wise, but really,

this is talking about everything that's likely to vary. So yeah, I'm going to vary. Right. Right. So, yeah, I'm going to support the high. Well, that came out wrong. Twice in one episode. You heard it here. I'm not even trying.

All right. So that's actually, we've gone through. I think I need to move to Colorado or something. Here I come, Washington. So we've made it through the first three chapters, or I guess you could call them chapters, of the 12-Factor app. Yeah, it's chapters. Factors. Yeah, 12 factors.

The 12-Factor chapters. We've gone through the first three factors of the 12-Factor app. All right, so, yeah, I mean, this could go on for quite a while, so we're going to cut it off here, and we're going to go ahead and talk about some of the resources we like. Yep, so first is the actual, there's a nice article on Heroku.com talking about this, but even more importantly than that,

they actually created a website called 12factor.net that actually goes through and has a nice write-up on each of the factors, chapters. And that's the number 12factor.net for the URL. It's important to note that the name that they actually use elsewhere, 12, is spelled out. But for the URL, it's the number. Yep. And that article that we mentioned that talked about each item and kind of assigned the rating, that's on clearlytech.com.

We'll have a link to that as well. Yep, and we've also got links to Wikipedia for the declarative and imperative and also to the Microsoft article about deploying with dependencies and all that kind of stuff. So we've got several in here. And then... So with that, let's get uh alan's favorite section of the show the tip of the week yes this week it's the week it is the week this is a week

that we are recording and it's the tip of that particular week yes Yes, I love this part. All right. So, we've talked about Pluralsight before, and lynda.com has come up as well. And there was one that I think is relatively new. I could be wrong on that, but it was new to me. Like, I found it, you know, a few months ago, and I've been meaning to bring it up and kept forgetting. And I finally remembered to bring it up and that is Codeschool.com, which has been acquired by Pluralsight. But one of the cool things that I liked about this, though, is that like Pluralsight, for you get there's some video to teach you whatever

the subject is that you're trying to teach but like Pluralsight for example we've joked about the you know if you pay for like one of the upper level subscriptions there are these tests that you can take after the fact right and you know it's like eh whatever

who cares right but with Codeschool.com there are these coding challenges that're like right after you finish a section and it's in line to the whole presentation, right? Like it's not, it doesn't feel disconnected. Um, like, uh, like, well, speaking specifically about plural sites, right? Like it's right? Like, it's part of the whole thing. Like, you have to do that before you move on to the next thing. And, yeah, you could skip it if you really wanted to. But, you know, the whole idea is it's trying to... Engage?

Yeah, you know, enhance or, you know, strengthen whatever, you know, they were trying to, whatever the subject is they were trying to teach you, right? So it was really nice, and it's a very well-done interface for those coding challenges too, you know, where it'll give you some, you know, hey, make this, like if it's an Angular thing, right? It's like, you know, hey, make this directive do this, and, you know, you'll go and do it, and if you start doing it wrong, there'll be little things that'll pop up. You'll be like, eh, that's not quite what we meant. Sometimes it can get a little crazy if you didn't do it exactly character for character,

what they wanted to see. But yeah, it's quite a nice resource. So if you've never tried it, you can go on there, and there's courses that you can see for free. But of course, there are subscription based pricing too. But I thought I'd throw that one out there since we have talked about other learning resources. So that's another one that you can put in

the toolbox. Central Florida represent. I actually have a shirt that they did a thing a while back called Rails for Zombies, where you would kind of like fight and escape the zombies by programming stuff with Ruby. It was just a nice, really unique course that they did. Okay.

So I did not realize that they are from Orlando, Florida. So I'm going to take my tip of the week back. Oh. Okay? That's all that we have. You have Disney come on man you know it's funny

everyone that I've met around here like what do you do like a programmer work from home they're like oh have you heard of CodeSkull and Envy Labs I'm like yes

yes I have it's all we have then you should say have you heard of coding blocks that's right if only we had some shirts or hats or something right

yeah alright so I I asked for help That's right. If only we had some shirts or hats or something. Right? Yeah. All right. So I asked for help coming up with the tip this week, and I did get one. I kind of messed up the tweet. But anyway, break up with IEA. We kind of mentioned it last time, so I'm not going to use that tip.

But Carl, you're right. IEA is terrible. It needs to go. The tip I was going to use is Programming Your Hands. It's an old article from another one of my idols, Jeff Atwood, for little exercises that you can do to kind of help with carpal tunnel type syndrome or symptoms. And that's something that affects a lot of people that I know, including myself. So check it out.

This is interesting. So basically these are hand exercises is what he's trying to say. This thing's almost 10 years old. This can't be true anymore. Yeah, everything I know, unfortunately, is like 10 years old. Yeah, it definitely says something about you. Every time you read an article, it's something like, hey, that reminds me of something I read 10 years ago. You know that it's a sign of how old the article is.

As you scroll down to the bottom and there's links for the previous article or the next article, and the title of the article is something like, did IE6 make Web 2.0 possible? Oh, no. Wow. It is. Yeah, that's scary. Wait. So does this mean that I'm old or that everything is coming around again?

Hmm. Or, or maybe you're just discovering the internet. So like you're going through, uh, our starting at Oregon. Yeah. You're,

you're starting from the beginning. So you've made your way through the nineties and now you're in the mid two thousands. Very nice. You'll catch up soon. All right. I'm surprised last week you weren't telling us about Y2K. I was thinking about it. All right.

So my tip of the week. This one's kind of interesting. It's called Packery, and it's packery.metaphysy.co. And really all it is, it's pretty nifty. If you go to the page and you resize the page you'll actually see what it's doing so if you have a bunch of containers or divs or something and this is for the web by the way this is a javascript library that will lay out items that you have in a way that that takes up space in an appropriate way oh it'll pinterest your stuff yeah kind of

except in all kinds of layouts like you know pinterest has its own you know two column type deal or whatever this you can actually tell it to be really meticulous or give it a building blog type thing or kind of lay it out sort of randomly but it's pretty amazing that it will just literally lay out your content in all these nifty little formats and format it properly for you. And I think it's relatively cheap. Where's the price? I can't remember. Is there a price for it?

It's on GitHub. It's on GitHub. If you want to use it commercially. Okay, so a developer license is $25. It's dirt cheap if you want to use it commercially. Okay, so a developer license is $25. It's dirt cheap if you want to use it for commercial purposes. For one developer. Yeah, for one developer. If you're wanting to put it in some sort of blog or something,

you can probably get the free version and play with it. But it's pretty nifty. I definitely recommend going up there and just resizing your browser and seeing what it does with those blocks at the top. It's pretty cool. Hold on. Wait a minute top. It's pretty cool. Hold on. Wait a minute. It was – now that's old news.

That JavaScript framework has been deprecated. There's now packet.js. No, I'm just kidding. There's no such thing. Stop it. Well, there might be such a thing. Actually, another cool thing is if you're up there, click on some of those blocks, and you'll see them resizing and kind of reshaping everything as you go.

It's pretty, pretty neat stuff, man. So, you know, it seems like the most annoying layout there. Like everything is like, you know, as you're clicking on it's like, oh, my God, I was just reading this other article and I was looking at the next article I want to click on and it just moved. Where did it go? Yeah, I'm going to make a copy of Flipboard and I'm going to call it Block board and i'm going to use this yeah how can you close source javascript yeah right i mean seriously well they did um the the closest best thing which is a gplv3 so uh yeah if you're gonna use their stuff without paying them then you are also gonna be publishing your stuff open source yeah so good luck to everybody who decides to do that. So how fired would you be

if you didn't pay for this license and you included it in your code base? Yeah, go ahead and pony up, what was it, for eight developers? It was like $110 or $115. Yeah, go ahead and do that so you don't give away your code. So that is pretty much it. That's the first three parts of the 12 Factor

app. Yeah, and we definitely want to hear about that dependency isolation tool. So let us know. Oh, yeah. We totally forgot about another. This is the second time we've forgotten about a survey. Dang. Oh, we didn't even talk about the survey results from last time.

No, we didn't. Oh, fail. Yeah. I guess we'll results from last time. No, we didn't. Oh, fail. Yeah. I guess we'll be picking it back up on the next one. Yeah, I guess Alan said that he was right, so maybe we should say, well, maybe the question should be, well, was he? Right. We'll have some sort of poll, so go to the website,

and we'll have something there that's super awesome for you to see. Was Alan right or was Michael right? I feel like all your polls have that kind of angle. And don't, if you haven't already watched the Apple keynote, don't. Don't listen to any Apple news. And then, you know, just go and like blindly decide like, is Michael right? Or is Alan right?

I think that should be it. Don't even put the question of what we were right about in there. Right. Just yeah. No, no, no, no.

Who was right? Yeah. Uh, all right. Yeah. That sounds awesome. Uh, so like we said,

uh, you know, if you're hearing this on a friend's device, be sure to find us on iTunes, Stitcher, or more. Use your favorite podcast app and subscribe to us there. And like I already said before, if you haven't already left a review, we would greatly appreciate it and be forever grateful. If you would go to either iTunes or Stitcher, again, you can go to codingblocks.net slash review to find quick links to those resources. Or if you have a preferred podcast aggregator where you'd like to leave a review, please do. And hey, let us know what that is

so that we can be aware of it too. Yep, and contact us with any question, topic, leave your name, preferred method of shout out, and we'll mention you on the podcast. And visit us at www.codingblocks.net where you can find all our show notes examples discussions and more and this particular episode will be codingblocks.net episode 32 yep and if you don't want to tweet us you can send us an email to comments at codingblocks.net and let us know about that isolation tool or how wrong we are about any of this. Oh, and that Twitter address, at CodingBlocks.

Yep. All right. © BF-WATCH TV 2021