Coding Blocks - Clean Architecture – Components and Component Cohesion

Episode Date: December 11, 2017

Joe is down with OCP, Michael argues DRY, and Allen deletes our show notes as we dig into Components and Component Cohesion from Robert C. Martin's (aka Uncle Bob) Clean Architecture.

You're listening to Coding Blocks, episode 71. 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. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. Alright, so last time we talked about

clean architecture, we talked about how to kind of apply the solid principles at an architectural level in order to organize our code a little bit better. So this time we're kind of moving things up a level, talking about components and the three cohesion principles. Sweet. Sorry, I forgot that I put that section there. Sorry, listeners. All good.

So we're going to get into something that we love is thanking everybody for the reviews that you guys send in. So I've got iTunes this time time and apparently I need to increase my font. I have Sir Knee Games. Old Man Eyes. Apparently that's what you have. I think I actually shrank it down so that I could see stuff. Alright, so here we go. Sir Knee Games,

Killane99, TheRationalReptilian, ADNDYFC, Aaron Malikin, ADN DYFC, Aaron Milliken, Lean Webstart, Swap Futures, Fat64, Antoine New York, and Ace4410. And so thank you for all of you guys that did that. I do have a random thought here. And this came from ADN DYFC. So he gave us a one-star review. And I'm not calling him out for that.

But his reason was is because he heard us bashing on PHP. Right? And I do want to point out, like, I mean, I think we take it for granted because we're 70 episodes in. And we sort of, I think we kind of expect everybody to sort of get our humor at this point and kind of get where we're coming from because let's be honest, right? Like anything you can do, you can do in any language you want to do. Right. So I hope that nobody out there actually feels like we're always bashing on, on their particular language. We have lots of people on our Slack channel that do PHP. We have lots of people that do all kinds of random languages, right? So, you know, I hate

it that that was his introduction to us because I could see why that would, you know, potentially put somebody off, especially when that's how you bring home your bread, right? Yeah. And specifically the thing that caught him off was actually a reference to a previous episode where we had talked about a Reddit post in the programming humor where that was just one of all the languages that was, you know, quote, picked on. Right. So I hate that. I mean, hopefully if you're listening, you know,

you kind of see that we're sort of fun-loving guys and we joke about this stuff. We even self-deprecate our own stuff. So, you know, whatever. I just wanted to say that. I mean, hopefully everybody out there kind of knows that, you know, we're doing this so that everybody can get better, but we do like to laugh,

and we're going to continue to laugh about certain things. So, anyways. Especially PHP. Especially PHP. I mean, I made a lot of money using PHP. It's great for the internet, and Libby Limes is one of my heroes. So, I'm just a lot of money using PHP. It's great for the internet and living lines is one of my heroes. So yeah, I'm just kidding. Yeah, totally.

So anyway, that just want to drop that random thought. All right, moving on. Yep. And so from Stitcher, we have the mad Viking God, Aaron M, Twin Bits, Comet and Christopher Olson. And big thanks to God ProrogMan on Podchaser. And if you're not familiar with GodProgMan, he is one of the hosts of the Waffling Tailors podcast, which is the only gaming podcast I know of

that's got a perfect five-star record on iTunes. So good job, Jamie. Very nice. I mean, GodProgMan. Yeah. Whoever you are. Yeah, I just doxed you. Sorry.

Yeah. And we've got lots of people in here that left reviews that are on our Slack channel. So, you know, thank you to all you guys that took the time to do this and gals. Really awesome people out there. So thank you. Yeah.

Arlene wrote a really nice review for us over on Podchaser, which might have helped in us getting mentioned earlier today on a great post. They put us in the top five for tech podcasts. Thank you very much. Yep. Right behind Reply All. I mean, seriously. Yeah.

Which is my favorite show. Yeah, it's my two. I enjoy it. Besides ours, of course. Yeah, of course. Of course. Man, that's crazy. Hey, can I ask you a question, Joe?

Yep. Does this cup make my face look big? That cup is so giant. So giant, so beautiful. We did a swag trade with MS Dev Show, and so I've got a beautiful, beautiful cup. We've all got beautiful cups and hats. I cleaned my office, so I can't find it anymore,

but I've got a hat, too. It's a really nice trucker hat. So if you're interested in coding blocks, swag-like hats and mugs, I cleaned my office so I can't find it anymore, but I've got a hat too. It's a really nice trucker hat. So if you're interested in coding blocks, swag, like hats and mugs, you should let us know because we're working on it. Yes, we are definitely. Oh, and by the way, I don't think it's big enough though. This is for my friend, Ryan Williams. We've got a big matchup tomorrow night between the Saints and Tenor Mike

between the Falcons and the Saints. So this is for you, man. And hopefully I'm not eating these words come Sunday or Friday or whenever this game is over. Anyways. Or better yet, whenever this episode gets released. Right, exactly. I've got my hat on now.

There it is. Nice. All right. So we're going to get into the show. But first, I want to tell you something that we're really excited about uh did a little bit of math this year and you know we we try to do a lot of giveaways we try to um come up with really cool stuff to give you guys and we do a lot of this on the mailing list just because it's easier to kind of manage for us um we've done a few things on twitter and a few things um and like slack and a couple other different ways but uh the majority

of our contest giveaways have been on the mailing list and i did a little bit of math i added this stuff up and i figured out what all we gave away this year so check this out this year we gave away 550 in amazon gift cards 27 jet brains licenses 21 books that's's Clean Code, Imposter Syndrome, Domain Driven Design, Clean Architecture. Those are actually in the comment sections for the most part. Imposter Syndrome was in the mailing list. Two tickets to

Swanzacon, an awesome convention out in Wales. Three React in Motion courses from our buddy Zach Browdy. Three PostShar sharp ultimate licenses. And we also sent out a lot of stickers and mugs and a couple other things, some shirts.

But, um, I, I totaled this up and we are at almost $11,000 worth of giveaways. Wow. That's amazing. That's awesome. Yeah.

I mean, being like a listener show, it's like, it's almost, it's like, if you average it Yeah, I mean, being like a listener of the show, it's almost like if you average it out, it's like $10 a person. I'm just kidding. Well, if you consider how many episodes we release in a year, that's like... That's pretty good. Yeah, it's like $1,000 an episode. Yeah, that's pretty good.

We're working for you. So if you appreciate that work, well love those reviews, but we also just set up a page at codingblocks.net slash resources. And we'll have a link there on the website too. You can find it up at the top. But codingblocks.net slash resources. And there we've got links to different affiliate programs we've got set up. So if you're thinking about signing up for Pluralsight or you've got some ginormous purchase uh that you want to to do on amazon and uh consider going through us to do it it'll you

know leave us a small percentage it won't cost you anything extra but help support the show i'm probably violating some terms of service but we try to be up front with you guys about everything so don't tell amazon be our little secret. Yep. But we definitely give back and, and we love it because we know that all our community also gives back, right? Like our Slack community is amazing. The people leave comments on all our episodes. It's killer stuff.

So, you know, I guess this is the time of the year to say thank you to everybody for all the great stuff that you've done. And, you know, it's awesome to be able to give back. It really is.

All right. so we're going to hop into the meat here. Let's do it. Ew. Alright. We've got an interesting visual there. It's all this food talk. I guess I'm hungry when I'm podcasting.

Last time it was cheese, dust, and now... Anyway. Getting a little meta. We want to talk about components tonight. Let's first talk a little bit about what components are. The book defines... We're talking about clean architecture again.

The book defines components as the smallest entity that can be deployed. It's not a line of code. It's not a class. It could be an EXE. It could be a DLL, a JAR, a GIM, something that may be some compiled JavaScript code. But it's one deployable unit.

And the book starts out with an interesting history of components. We're not going to go too deep into it here. But it kind of builds up to the way we kind of got to where we are, the way things are today and why it kind of builds up to the way we kind of got to where we want the way things are today and why it kind of makes sense and why things are so awesome now but basically we started out with talking about programs that used to load common functionality into known memory locations that way programs could like reuse the same functions and whatnot without having to compile those things all together and I

just kind of saved time and this event eventually led to shared libraries between different program or programs and relocatable binaries that could be loaded into different memory locations and we got external references eventually which let you reference things by names rather than you know memory location 2000 which was really nice. And at the same time, hardware was getting better and better. So we were able to do more and more Kodi type stuff. And that brings us to linking loaders.

Unless you're working in a language like C, C++, you know, I don't know if anyone even really talks about these anymore i i really i mean it's been a while since i've been in that world so i don't know i mean i remember one of the things that he said in the book was even this wasn't great at the time because hardware was so slow right it was loading things up off tapes and so even trying to get a program to load could take like an hour depending depending on how complex the program was. Yep. And it's kind of back in the day too. And like everyone had their like little tool belt of things. Like you might have like a little date utils kind of collection of functions

that you would bring with you from project to project to make your life easier. That kind of thing, you know, went away over time and went over way uh went over uh because these smart linking loaders let us divide programs up into separately compilable and loadable segments and then we dynamically load them as needed so when we talk about dlls it's kind of a popular one um a dynamically linked library is it yeah dynamic link library yep okay so if you've got a program you know maybe you've

got an if statement in there and you know if one thing then it'll go out this library otherwise it may go out to another one those libraries aren't loaded in memory until you actually use them and even then i think it's really smart about like what it grabs out of those libraries in order to use so things have gotten a lot better and if you've ever worked on a really large project that took a long time to build and you're very familiar with the notion of like building the project you're in because a full rebuild could take an obscenely long time so this isn't anything new and if you work in compiled language you've probably seen this text go flying by and you've seen the you know talking about linking whatever and this used to be a really slow process. But all of this is just kind of leading up to the point that things have gotten a lot better.

And things have also gotten a lot more complicated because we didn't actually, you know, we don't use that extra time at the end of the day now to play foosball. We just have bigger and more requirements. So like back in the day, you would work on say an authentication page or something. You would start by typing HTML and then maybe doctype if you're doing things the right way. Then you get into the head and all that stuff's gone. You're probably going to bring in a couple of packages,

but then you're going to spend the rest of the day wrestling with trying to get your CSS library to look right with your authentication package to work right with your um you know orm whatever so the work just changes and ultimately the end result is going to look a lot nicer and work a lot better than it used to when you started out by mistyping that doc type but we just have bigger expectations. So what is this? Sorry, go ahead. There was a quote in here, though, that was kind of like going along your statement about the programs also got bigger and more complex.

There was a quote in here that it reminded me of something I've always heard referred to as the fishbowl principle. That could apply to a lot of different scenarios. But basically, the fishbowl principle is the fish is going to grow to a lot of different scenarios but um you know basically the fishbowl principle is the fish is going to grow to the size of his bowl right and and the spin on it that he had in here was that that the uh the programs grew to fill the available compile and link time so you know going back to your point about things got bigger and more complex you know as our as our hardware got faster and better we just filled that time up you're like why does it you ever wondered like why does it still take x amount of time to compile this right whatever that might be like you know if you if you think back to like uh recompiling the linux kernel and you're like oh man i can i can compile this kernel in

this amount of time you're like why does it still take that amount of time and that's why we just just keep scrolling just keep adding on that's right yeah but uh linking loaders are now the norm um even things like javascript you bring in my modules and whatnot dynamically and bundle them up dynamically and do all sorts of crazy stuff and because of that plug-in architectures are common in this case i don't think plug-in necessarily means like you know an eclipse or uh in the windows world like mef you know these places where they kind of like you start up an application it goes out looking for libraries to load and tell what to do i think they're talking about more like literally in the sense that like you've got a bunch of modules

that you're kind of plugging in and making work together. So rather than you doing all the typing, you're leveraging like all this work that's already done. And that's just kind of the world we live in now. We are in the age of software reuse. And so we need to figure out how to work effectively in that world and take advantage of it. Do you think that a big part of that age of software reuse has been the proliferation of open source projects and libraries?

Yeah, totally. I mean, I used to always hear about Perl because of CPAN. CPAN was the one that I kind of had first always heard about being amazing. And then next thing you know, everyone's got package managers springing up. I can't imagine working in.NET without Nougat now. It just seems crazy. Yeah, I agree. I mean, and you look at everything now. They've all got

multiple package managers, right? You got NPM for Node. You've got I mean, geez, everything now. And what did it really kind of started with what SourceForge back in the day, probably. Or maybe not. Or was that more just downloadable stuff? But I mean, GitHub's definitely made it ridiculous now to where it's just so easy and so many people do it.

Yeah, we're in a discourse site now, and you can add plugins by pasting in the Git URL. And it'll go and check it out and compile. It's just crazy. That's cool. So yeah, I mean, this is where we start getting into the three principles that he talks about in, in this particular section and they're the component principles. So the first one is REP. It's the reuse or release equivalence principle.

And it doesn't sound like much on the surface. But basically what they're saying is the releases of shareable software components or modules must produce the proper notifications and release documentation. That was like the one key takeaway for me in this. And I mean, we'll cover more details, but basically in order for people to be able to trust and use your components, they need to know what's in them and what's going to break as new changes come out. Except for the documentation part. That's the part that bugged me because I'm also like, well, wait a minute. In the other Uncle Bob book we read, didn't we talk about just have like self-documenting code?

Well, difference, difference though. This is more like release notes, right? Like because we're talking about release components. So I think at this point, it's almost like if you go to get a new NuGet package, like log for net or whatever, right? If you're getting that thing and they're jumping from 2.4.2 to 2.4.3, why do you need that? Yeah, well, I guess that's kind of where I was thinking about. I was like, how are we defining release documentation as this?

Because I don't want to spend my time. Please don't ask me to write a book about what I just put in. Yeah, I think it's more along the lines of if you've got a ticketing system or something, right? And there are various different things that are fixed in that particular release version hey what's the bullet list of of the items that were changed right for this i think that's really what we're talking about here imagine if you've got like kind of you know off the shelf software or software that you sell to a company and you go and you say okay we want to upgrade you to the latest versions like okay well

why and you're like well you know Tom over there updated the NuGet packages and Janet, she did some cool stuff with CSS. And what else do we do? You know, no one wants to hear that, right? That's about what happened. So it's both got professional reasons for checking that stuff and people using your code. But it's also really um, really important for,

uh, versioning tools like, you know, to know if you can say, for example, upgrade your packages, you know, to know whether like,

you know, a lot of times you see in package configurations. Now you'll see like, um, greater than less than type science. So you'll see like, yeah, um,

go ahead and just grab any, uh, log for net version. That's, you know, in the 2.2 ish range. And so it doesn't care if it's 2.2.141 or you know 163 both of those should be compatible so might as well grab the latest in that set yep

it just opens up automation so yeah and that's really part of it too you've so one of the things that they talk about here is the classes the modules within the release should be releasable together. And I know that sounds obvious, but there's many times that you've seen to where, you know, you go and you get the latest of something and it's not compatible with the other thing that was there. Right. And so like upgrading these things, it really needs to be a cohesive thing. It needs to be something that you don't really have to think about. It can be automated and it should work together. Somebody put in here, thou shalt have release numbers. I'm assuming that's you, Joe.

Yep. Yeah, I was trying to do something funny with like the three component commandments or something, but I don't know. Principles was in every one of these. Every one of these acronyms that we're going over right now, there's three of them, but everyone ends in P. Hey, maybe... I thought there were four. No, there are three here. No, the other one was the triangle. Yeah.

So, maybe this is worth talking about, just the versioning thing've, we've all kind of gone through different iterations of things, right? Um, like semantic versioning is the one that I think we sort of all agree on here. Yeah. No. Simver.

So that are dates. Those are kind of two popular ones. Uh, I don't like the date thing. I don't, it's not really meaningful. I think to the end user. Yeah.

I tried it at one point. It didn't work out well yeah and um there's really good reasons for everybody john knows them very well like it's kind of like if you're trying to do like semantic versioning for determining whether things are compatible then you want to go with the numbers the dates are meaningless there right but if you are trying to communicate it, I, you know, I guess this is the most recent version or how old it is. And maybe the dates make sense. But I mean, to me,

like, I don't want to see like Firefox, November, 2017, you know, it doesn't, I think it depends on who, who,

who or what is the end user of that? Uh, version is the point. If it's going to be machines, then you want it to be, you know, semantic versioning. If it's going to be human readable, then to your point, then maybe they want to be able to have some kind of relationship about like, okay, I see this version and I can assume that this is x amount old but that also kind of means like the only where places where i've seen where that kind of works is if it's always rolling forward right right like if it's if it's if there's ever the

possibility that you're going to like want to use something from the past then it's like why why would that why was why would you use that version then? That seems weird. It almost seems like there should be the product version that's like the human readable version versus the actual release version. There's the marketing version and then there's the technical version. And for those who aren't familiar with SimVerge, I think it's worth at least talking about it. Like the first digit is your major release number, right? Your second digit is a, what is that? That's a minor update, but it could have backward breaking compatibility with the previous one. So like 1.0 is your first release, right? 1.1 is, okay, this is an iteration on version one, but it has some breaking changes from 1.0.

If you have 1.0.1 though that's like usually bug fixes and improvements to the overall software that's not backward changing breaking and then correct me if i'm wrong i think the fourth digit so 1.0.1. you know one two three four that should be dictated by a build server somewhere right like that's not supposed to be anything that any human did unless you were just going to put.1,.2,.3, whatever. So I pulled up simver.org. Mm-hmm. But I think I wasn't sure the way you said the second one. They say the first one is the major, it's incompatible API changes.

So anytime that one changes, it's incompatible. The second one is the minor. Oh, it is backwards compatible. That one is backwards compatible. That's what I thought. You said it one changes, it's incompatible. The second one is the minor. Oh, it is backwards compatible. That one is backwards compatible. That's what I thought. You said it wasn't, right? It wasn't. Yeah, I was wrong. Yeah. Okay. And then there's the patch, which is the third one, which is also backwards compatible bug fixes. Okay. So the third one's bug fixes, the second one's additional functionality,

but still backwards compatible. Yeah. Yeah. So I think that's worth knowing about because it's really important when you're talking about versions that are compatible with other modules, seeing as how we're talking about all this stuff. If you use something like semantic versioning, it's very easy to reason about just looking at the numbers, assuming that people aren't lying and fudging about their numbers. But if they're truly using semantic versioning properly, you know, that it should work with

your software. So if we had to put other words to those like dot dot dots, then you could say it's a major release dot new feature dot bug fix dot build number. Yep. And it should be an automated build number. Yeah. Yep. So that's a,

for anybody who isn't familiar with that, hopefully that'll help out. And we'll have a link to Simver.org on here because I think it's really helpful to see this stuff and see the breakdown. So. All right. Tangent one, but I think it was a useful one

uh all right so what we got here oh um so releases should have a theme that's just something that i saw mentioned in the book that i just thought was kind of cool and it kind of goes back to like the marketing speak um but just the idea of not having like a, just a random collection of stuff. So if you've got some sort of release or something and you're writing your, you know, I would say show notes,

your, your release notes, then you want to kind of organize those a little bit. Like no one wants to see a bunch of like, you know, little tiny kind of meaningless changes. We want to know what the overall overall um sense is like are these performance enhancements are these security fixes are these you know new features like just make it easy give

it um you know make it something that's meaningful to humans in addition to computers yep and that pretty much wraps this one up right like? Like the, uh, the REP version. Now, one thing he did say on this one was, if I remember correctly is he said, this one isn't all that it's more of an idea, right? This one's more of, you know, you should release these things together that, that, you know, belong together. And he said, the problem is it's easy to say, Hey, this is what it should be. But you know, that doesn't mean that you can enforce it in any particular meaningful way.

But he said that the next two principles we get into help drive that a little bit better. So does anyone else hate that there's two R's before that EP, but then every time it's referenced there on out, it's the REP. Yes. Yeah. It kind of bugged me.

Yeah. And I like, I kind of bugged me. Yeah. And I don't even like the reuse in there. I wish it was just the release equivalence principle because I don't know. There's something about the word release that helps me remember, and I definitely got scrambled when I kept seeing these acronyms showing up. Go ahead. I was just going to say the reuse, I mean, that's almost unnecessary

because the whole point is to build components that other people use. Right? Like, so I think the, the release one is really, again, to,

to your point, it's what drives it home in my mind. And reuse is part of one of the other principles. Yeah. But this was, this also started though with like the very first quote that he has in here. Like it kind of built off of that. The granule of reuse is the granule of release.

Okay. Right. So yeah, trying to figure out how a better way to, another way to say that though, was that like, uh, yeah,

I can't, if you're going to be able to reuse it, if you can reuse it independently, then you can release it independently maybe yeah i mean that's true i don't know if that won't belong to this one so much but yeah i don't know let's cover the next i thought it did though because it was saying it like um if it all belonged together and you can release it, then maybe, maybe I'm wrong. That wasn't this one. I don't know.

They all kind of bleed together me a little bit, but I'm trying to keep a, like a firm grasp on them because there's some interesting stuff in the book that comes up later. And these three principles are definitely mentioned quite a bit by acronym. Yeah. So if you could just remember release equivalence principle or make an effort to say the full

principle name as we go along here because it gets really confusing. At least I think it gets confusing. It did when it started referencing them. I actually had to start looking back at my notes to see what it was. So yeah, the next one we have up is the CCP.

The common closure principle and joe you want to kick us off or mike you want to kick us off with this one uh not really i don't like this one okay no i really i think i i think i liked the last one if we're skipping ahead better but no we're not skipping ahead i don't know what no we're not so this was the common closure principle uh where it was components should consist of classes that change for the same reason and at the same time so this was similar to the to srp to the single uh responsibility principle um and that uh how i'm trying to remember how this how the single responsibility was something that

uh the class should change for only one reason yep you know so so you want your component to only have one reason to change as well and that if you're going to define a well, if you're going to create a well-defined component, as soon as you find that there's a second reason for that thing to change, then it should be in a second component. Yep. And to add on to that, they say classes that change for different reasons, which is what you said, or at different times should be broken out into separate components right so yeah and this is the srp the single responsibility principle that came from solid right which we've covered and talked about a few times a couple times yep so yeah it keeps coming up um you know like one uh one

example here i really i think this might be my favorite principle but like if you've got like say some some I don't know some email code that's kind of in like a core part of your your library then anytime you add support for say a different kind of email server or maybe sending through you know one of these cloudy kind of email services or something you're going to be changing that code but that's not really relevant to the rest of your code that's usually in like a core type library, right? That's normally your business logic. And so now you've got this like really functional area of code that's bundled with this other

code. And now whenever anyone makes a change to business logic, they're also deploying and rebuilding the email stuff and vice versa. And so what I really liked about this is that a lot of times um a lot like pretty much everywhere i've always worked has always been the question of like well should this stuff be its own project or should this be part of the bigger project the idea is that a bigger project is kind of easier to manage in some ways because it's just less stuff um but i think this is a pretty compelling argument and a pretty good way to kind of help you

decide on when to break things up into separate projects or separate packages. You know, it's funny you mentioned that because we've actually tried doing this to where you break things out into separate projects and create like NuGet packages and all that. And it's funny because I think where that falls flat is if you don't have a good build pipeline in place to manage a lot of that stuff for you, then people are just very against having to deal with that kind of stuff. Right. Yeah. Um, and we'll be talking later in, in the next chapter or next episode, more in depth about some of that stuff. But I do think it's important to, to think about breaking

those things out because what you said is probably the most important part you build your core logic and you're also now getting something else that's coming along for the ride that really you know you have no idea if it has any other impact on it right um and what's more important though reusability or maintainability for For most applications, maintainability, right? And this is, we had a conversation the other day and this is what's funny. And I don't even know if it really comes into play here, but we've talked about how you split up teams and components and how different people work in things, right? Like if everybody's working in an entire app all at once, you kind of step on each other's toes. Right. And, and I said, well, if you, if you draw the lines and you, and you say that, you know, you know, Joe, you're going to work over here in the accounting section, Mike,

you're going to work over here in customer service, Alan, I'm going to work over here on the, on the front end. Like we're all probably going to create code that's going to duplicate each other. But this is almost saying right here, this one line is saying that, you know, the ability to maintain that code is more important than the ability to reuse some of that code. Right? So. I mean, you can look at it like this. Look at it. Take it from this point of view. Let's say that all three of

us are working in some code base and we all have our own separate areas. And coincidentally, we all create, like, let's say something simple, a string extension that all does the same thing. Yeah, okay, fine. So now there's duplicate code. And if we find a bug in one of them, then we got to find it and we got to fix the others. I'm not going to say that that's not bad. But from the maintainability point of view, if I needed to change my specific version to be maybe a little different than yours, I'm not going to impact you. And I don't have to worry about, oh, well, I got to put in a special switch statement depending on, you know, with a default parameter and, you know, go through all on, you know, with a default parameter, and, you know, go through

all this, you know, logic to see like, okay, well, which particular case are we talking about here? Like, I don't have to worry about that, right? So from the maintainability point of view, it allows each of us to maintain our stuff independently. And if over time, we find that duplicate code, and we determine like, okay, this is really bad. We should consolidate this stuff. We can always refactor that into one thing, but it shouldn't be from the start. Like, oh, we can't have this duplicated code. We got to, we got to reduce all duplicated code down to just the single instance.

Right. Yep. Like that, I feel like is an impossible ask yeah and that gets into it again in the next section that's almost that's almost verbatim um oh did i say something no no i mean in in our next episode that we're going to talk about it he kind of goes down that is software is an evolving thing right like it's not right? You're never going to know exactly what you're writing up front because you can't, right? There was actually, actually no in something in this section. And I'm going to skip ahead a little bit of what I wrote down here in the notes,

but, um, cause keep in mind this, this is the, you know, clean architecture book. So of course he's coming from the architect point of view, which is kind of similar to what you just said that a good architect finds a position in the tension triangle that meets the current concerns of the development team but is also aware that those concerns will change over time yep right yep and i know i'm skipping ahead a little bit you're like tension triangle what are you talking about we'll get to that yes um so i gotta say i'm a little bit more uh a fan of dry up front because i feel like a lot of times we don't go back and and refactor things once there's two and the thing is like two becomes three sometimes and then becomes four then it gets to be a problem when you say like okay we need to systematically change this stuff so i kind of feel like it's easier to split it off when you

start needing the special case you know later than it is to kind of go back and consolidate stuff well i wasn't i wasn't trying to be like pro duplicate duplication by the way i wasn't saying like you know duplicate all the things but i was yeah i wouldn't let it like impede you from splitting things apart right oh yeah totally yeah i get it it's totally it's a prag it's pragmatism i don't know how to say it's pragmatist decision and like a lot of times you know we make it sound like oh why don't you just use that code but a lot of times it's you can't the choice is should i spend three hours refactoring somebody else's code so that i can reuse it? And then the next change comes down the pipeline. I have to toss the whole thing or make it even uglier.

And so that's the kind of decision you're faced with. And it could totally make sense to kind of copy pieces out of it or at least mimic it. Hey, but heads up. I think that's a different part of this whole what we're talking about here. I agree with what you just said. I think don't repeat yourself is something that you should practice as much as possible, right? So for instance, you're coding something like, none of us code, well, I mean, maybe Michael does, but none of us code the perfect thing up front, right? But as you're going, I mean, we've even talked about it sometimes seriously,

though, like you'll code the entire thing in one file, let's just say, right. And then you'll look at it and be like, okay, maybe you won't, but let's say that you did, let's, let's say that you coded everything in one file. Then you looked at it and you said, okay, I can break these pieces out. Right. Cause you're going to refactor it down to a better spot. And what I'm getting at is this, you can't start up front saying, Hey, so imagine you have, you have 10 teams of 10 developers each, right? You can't start and say, we're going to do this entire thing. And you know, everybody's going to have to know about these central things because how do you even communicate that? Right. But within your own teams and even within your own code, you can take that dry thing to heart, right?

So when you start writing something, you see that there's pieces duplicated, you start breaking those things out. So within your own team and within your own components, you sort of mitigated that problem, right? Now, the problem is what you said, where you have this string utility that now it's probably 10 teams have 10 different versions of it because they didn't know it all existed. But at some point when your application reaches a certain maturity level, I think is what we could call it, you can take a look at it and say, okay, what does our application do now? What are the common pieces here? And now you can start looking at it from a more, you know, overall overarching view and say, all right, let's pull some of these things out. So I guess what I'm saying is you can't say dry all the things up front, but you can do it within certain components

and within certain pieces of it. And then start as, as you become more mature, you can start doing that at a higher level, I think anyways. Yeah, I mean, definitely the things that you own are going to be easier for you to know and keep dry. It becomes a communication challenge once you get beyond yourself. Because, you know, we've each written enough code that we have trouble just remembering the things that we wrote, you know, a month ago, right?

Like, and in fact, that's actually like the age-old problem, right, with any kind of development. And that's why like a the age-old problem right with any kind of development that's why uh you know the clean code book was talked so much of that book was harping on like writing code that was expressive and self-documenting because otherwise when you come back to that code uh you know a year from now you're not going to understand it right so we forget what we write, much less now I got to keep in track. I got to keep track in my head what you wrote and what Joe wrote. So my only point on the whole repeating thing was, you know, it's okay if like,

if you're working in the department that's responsible for serving ads to your customer uh you know i'm not i'm not gonna beat you up if you created a customer object that has a same method as a customer object that the customer service team created you know like yeah i mean okay technically it's duplication but it's totally different projects. Like, who cares? Like, I don't. And you got to move the business forward too, right? Like, you can't stop everything to try and make the most minutiae type decisions possible.

Yeah, be pragmatic about it. Yeah. I had another thought on this. I know we don't want to beat it up too much more. No, let's do it. What was it? Beat it up. Beat it up. Well, let's do it. What was it? Beat it up. Beat it up.

Well, remember we talked about stovepipe architectures? The anti-patterns. We talked about silos. Oh, right. And this is one of the ones that they kind of talked about like, yeah, it's an anti-pattern, but it's also pretty good for some things. Oh, that's – This is kind of a controversial one.

That's actually what – that leads me into the thought. So, the big problem, honestly, I think the major problem with trying to make everything not duplicate is communication. How do you communicate to 10 different teams that I have this library that you should use? The only way that I can see that that becomes effective is if your team, if you say, okay, our team is responsible for X functionality. And if you ever need to do anything like that, you use the modules, packages, whatever projects, NuGet packages, whatever that we're publishing out. Here's where we're going to make these things available to you. And if you need things from us, you can submit, you know, issues, you can fork the repo, submit your own pull request, whatever. But you know, like, like,

for example, hypothetically, like if you had, you know, a group of people like, okay, hey, we're handling all of the logging within within company. It's going to be standardized on this one thing, right? Like you're Apache and you're writing log for net. Then yeah, you could see where like, why would you write your own logging at that point? Why would you? But how do you communicate that effectively to where it doesn't get lost in translation, right? Like how many times have you guys gotten emails

that are like, Hey, security just changed and you have to be aware of X, Y, Z. And then you know what I'm saying though? But like two days later, you look at it, you're like, my thing's broken. Why is it? You didn't read the email. I think at that point though, you have to look at like the large overarching cross-cutting concerns. And those are going to be your, your, your touch points, right?

Where you would do something like that. And then it a little bit easier to to have that communication and be like okay look this is the people we're not you know alan you don't need to worry about writing your own logger because joe is going to be responsible for that and this is where joe's publishing it and everything and making it available right and then and then it becomes a little bit easier but when we talk about like the string extension right now we're getting into the minutiae of it and it's like ah okay hold on yeah i understand dry i'm all i'm all for like staying dry but let's let's be realistic about it it's not the end of the world and it's not but let's say that you want to start building it up how do you communicate it is it a

wiki article that nobody knows about is it an email how i think it happens is um team a starts a project and they need a logger so they build it then eventually team b starts up and they need a logger so they just go ahead and do it because you know they don't have time to stop the whole train to you know build a logging framework and some point, somebody goes in there like, what the heck? I want the dates from logging A and I want the rolling options from logging B. Why aren't you guys using the same thing? You're all a bunch of idiots.

And at that point, they extract it out. And so I think this stuff has to kind of evolve organically. And so I do think that there is going to be a kind of this period of expanding and contracting, expanding, contracting, just like Atlas said, like a lot of times you, it's,

you have to start not, you know, you can't be dry right from the beginning. So yeah, a hundred percent dry. Yeah. And I think to be clear, these problems really rear themselves when you start getting more people

involved in a project, right? Like if it's just one person working on, on a particular project or a component or two people, or even three, it's probably not a big deal, right? Like if it's just one person working on a particular project or a component or two people or even three, it's probably not a big deal, right? When you start getting to 10 people, 20 people, now communication becomes a problem because it's hard to portray all those changes and things that are happening across. You can't know what everybody's working on. So a lot of these things come up as your application gets bigger and

as more people get involved i think wasn't it this book where they had like some kind of numbers as to like the number of people in a particular project but it yeah i seem to recall like for some reason i have this number five stuck in my head that was like that's the maximum amount of developers you want in the same same set of code and i don't recall where that came from i don't know if that was here if it was i don't remember where it was but you know what kind of stinks um just the the way that software tends to kind of grow organically in the way you kind of do stuff and maybe not you know keeping stuff dry and the way it just kind of starts out the new people at a company are always at an advantage they always get to look at the code and say,

hey, you guys are a bunch of idiots. This needs to be refactored out to something. But they weren't there for those pragmatic decisions that got the company to the point where they could even hire that new person. Right? Yeah. It's totally not fair. And I should remember this next time I start a new job and go there

and start railing on the source code, but I won't. Because that's not the way of things. And it's kind of not fair. If I did start a new job, I'd get to complain about the source code because I've had to hear about it for years myself. So, you know, we've got to pay it forward. Yeah, it's a tough situation. Actually, I think it was towards the beginning of this study. Once you got past five, it doubled. You got to five and like it the time to complete a task you know as the engineering staff grew then it just yeah the curve got really tall quick yeah that was the

beginning of this book that was those couple chapters were amazing I don't think he specifically called out the number five. It was just the way the particular... That chart looked. Yeah, example chart. Cool. So the next one we have on here is... So what we said last was for most applications, maintainability is more important than reusability. And the ability to change and deploy a single component

is typically safer than having to redeploy an entire app, which is what Joe said a minute ago. Right. That's what I lost kind of said. It's like, you know, if I've got my own stuff and then, you know,

I can change it as needed without worrying about breaking other stuff. So it's just kind of safer. Yep. So, uh, they then go on to say that if classes are tightly bound and they should be in a single component, right?

Like if there's just crazy amounts of dependencies they belong together yeah this is back to where you know the the ccp is tied to the srp there'll be a test on this alphabet soup later i'm down with ocp but this kind of made me think about like if you've ever had that argument well i'm somewhere you're working where you're like okay we've got these kind of, we've got these classes, and these things kind of need to know about each other. We've got three libraries at least in play. Maybe we should have like a definitions project that just has all the interfaces. And like, you know, there's some pros to that. But one con could be like, well, anytime I go add something to the interface in its own project by definition

i've got at least one of the place to change so this is at least one argument that says like if you're changing these two things two or more things together all the time they probably shouldn't be separated yeah but again in the next section we get into this pretty deep um in the next episode so we'll hold off on that. What just happened? Disappear. Way to go, Alan.

Delete the show notes. Why don't you? I don't think I did that. All right. Show's over. Yeah, we're done. Thanks for listening.

There's at least another hour left. So, oh, don't go anywhere. So, so there was another, you know, because there was this relationship between the single responsibility principle and the common closure principle, he was able to give a new definition that summarized both. So I wanted to share that because I thought it was pretty neat.

Gather together those things that change at the same times and for the same reason. Separate those things that change at different times or for different reasons. Yep. And that's a email example. That's a great example of something that should be separated because just because you either do SMTP or, um, you know,

Amazon SES or whatever Azure calls it shouldn't be changing and compiling and redeploying your main business logic, right? At the same time, if you've got two business units that change together often, maybe even all the time, then maybe those should be in their own logical component. Which kind of ties back into the 12-factor app to where you should use just a port and a URL to go back to whatever your external dependency is. So don't write your email service into your application you just access some service on some port which makes

you know we spent a lot of time uh like more recently kind of talking about bigger architectural stuff like the 12 factor app and cleaning architecture and domain driven design and um and i think it's been really healthy for me because there's a lot of times i wouldn't have had these arguments we've all had those arguments you know the same stuff we're talking about now but these are actually like well thought out kind of opinions on some of those things that we were just kind of you know spitballing so if i was on one side of an argument i was drawing from experience and um you know maybe like my own kind of tainted views of things but now i've got something that's actually been like thought out and,

you know, had an editor look at it. And a lot of people have really agreed on. So it's nice to have compelling arguments. Next time I think like, should this be its own project or not? I can kind of reference back to the book and take another look at it and kind of view it from a more objective angle. Because I don't know about you, but every boss I've ever had, that works great for them.

Like I could just pick up the book and be like, but the book says, and they're going to be like, yeah, I don't care. Yeah, exactly. I might have done that once or twice. Well, they say for a negotiation tactic is to basically have some sort of reference point. So if you're talking about salary or something, you'd be like, well, this guy makes that or this person makes that. And so say for the book, it's like, hey, you and I disagree on something. Let's see what the book says that I just happen to know agrees with me right i mean here's the thing though in complete honesty and not even being facetious at all the the beginning

of this book kind of ties it all out for you right like if you take to heart some of these things you can improve you can improve the amount of time it takes for you to do your software. You can improve the, the, the stability of your software, the maintainability, all of it, right? Like they proved it out. It wasn't, it wasn't just, Hey, I have these good ideas and let's put it down. It was, Hey, we have metrics to back this stuff up, right? We have numbers that show that when you do things in particular way your costs go way down your stability your bugs go way down like

there's just there's a lot of tangible man you talk about metrics and there i'm so i can't wait to get there's a part that i can't wait to get to it's a yeah the next chapter is really good so this episode sucks guys the next episode's to be where it's all at. That's because Alan deleted the show notes midway through. So we're going to wing it from here. I just got tired of typing. But I do want to say that a lot of the stuff that we read about, especially with the architecture stuff,

these are decisions that I was kind of making and I kind of had feelings or thoughts or whatever based on experience. But I wasn't deliberately making the decisions a lot of times I was just kind of doing what felt naturally like including stuff in the same project or broking out you know just because it kind of felt right but now that I've kind of got this language and I've kind of thought about these things a little bit I've got um at least I'm making decisions I mean I might totally ignore the advice but at least I've kind of considered it and read a little bit about it. So I've been really happy with the book.

I mean, it's hard because clean code was so influential and like had so many kind of new concepts and so many like kind of core beliefs that I've adopted that in a lot of ways, as I read clean architecture, I kind of keep comparing it to that. I'm like looking for those like groundbreaking insights. And I haven't been having that so much as i have been kind of having like the uh the kind of thoughts were like you know the next day i'm just kind of still chewing on it and trying to kind of see my way through it and understand it so it's been really good but it's been really different i think i think i know why though

is because i think and correct me you tell me if you agree or disagree, but with clean code, that's something like, that's your day to day, your, your coding day to day. You don't necessarily architect day to day. Right. I mean, some architecture happens and we, you might do it, but it's not like it's, it's not the same thing. So that's why you, that's why when you read clean code, you're like, Oh, well I can immediately put this to work right now, right now,

today you read clean architecture. And while it's great, you're like, well, I don't have any new components that I need to create or break out. I still have this other component that I got to like, uh, create,

you know, fix this thing or add this new feature to, but they're already split the way they are right now. Like you're not going to be splitting components out and creating components as often as you're going to be writing code. Well, and because also let's, let's be honest, like a lot of times when you do this, there's additional things you have to take into consideration, right? Like build orders and, and all kinds of things.

Like it's not as simple as, Hey, I'm going to implement this code change that I learned about in clean code. Now, all of a sudden you're going to start breaking projects out and versioning those things. Like there's other things that have to happen in order to make that work. Um, I will say one of the funny things that you were talking about, you know, like you're, you're constantly thinking about, should I break this out into its own project or whatever? Like I've literally not done that because i'm afraid that if you don't get enough into that project somebody else is going to latch onto it and dirty it up i i've i've seriously had those those internal things where it's like man i i know the road that i want it to go down and if i create this thing and somebody else takes it and and

slings it slings mud on it i I'm going to be really mad about it. And I struggle with that piece of it. And I don't even really know a good answer. I don't even know that that's the right thing to do. I think it depends. If you know going into it that it's going to be a pretty sizable amount of work already, then in the past, I've been like, okay, well, I can probably go ahead and just assume that I'm going to be safe in a separate package. And if, if I find out later that it's, it's not, then I can always just refactor it into something else. But, um, yeah, I'm with you more often than not. I think, oh, this probably isn't going to be that big a thing. So I'm just going to add it into something else and then i end up with these like gigantic libraries that i feel ultra guilty about that

i'm like man i should really break out some of those namespaces or should i yeah well one thing that um this book has got me doing is drawing a few more pictures like i've kind of noticed recently like i would go to kind of like write a say like a write a you know email or something write something to explain how a process works. And I realized like, man, this is like seven sentences. It's like really complicated. Like, why can't I express this, you know, more clearly? Like, you know, nobody who's reading this email has the time to really study this paragraph.

Like I need to express this information and all of this information in a more concise way. And so next thing you know i'm drawing pictures and as i'm drawing the pictures i start to realize like you know let's say i've got two or three systems in place i'm drawing little boxes and arrows and as i'm drawing i'm like oh wait but it actually goes back at this point and then it goes over here and my picture starts looking messy too so i'm like you know what the words are messy my diagram is messy maybe my code is messy right maybe i should take a look at this and so by with the pictures you start what you start doing is kind of like erasing some of those back lines and saying okay you know that's either not an

important detail or why don't i move the lines that were happening over here like why do i need to go back and so just by kind of drawing it out it kind of helped me make a little better decisions about where things should be in the kind of flow diagram it's like maybe this thing shouldn't be back in this class or back in this module maybe it should kind of stick together because more of the say the formatting logic stuff happens over here so maybe i could move this stuff to later in the process and then rather than me having three blue cubes that say like format headers, format body, format output, I have a format stage. So by just kind of drawing these pictures and trying to describe stuff in words, it's informing and making my code better to an outside observer. Because you can visualize it at that point, right?

Hey, what tool do you use just out of curiosity? Gliffy. Gliffy? Okay. Yeah, they have a free tier. It's an LSM product. It integrates with Jira and stuff really nicely. Cool. All right.

Well, that's the common closure principle. Yes. We never talk long about anything. Just a few more of these to go. I got my tip of the week. Hope you're sitting in traffic right now, maybe. of your mind yes all right so let's get into the common reuse principle the curb or the curb uh yeah just to restate that previous one that was a common closure principle and it dealt with keeping classes that change together together yes so we've got the re the release equivalence principle which is

basically good version numbers the common closure principle which is for keeping classes together that change together and now the common reuse principle so So in a single statement, the common reuse principle is don't force users of a component to depend on things that they don't need. We're all so guilty of this. So guilty. Everybody's guilty of this. So guilty. Yeah. Yeah, absolutely.

So Joe writes a great email client, and I want to use it, but Joe's email client has a dependency on Alan's logging client. So in order to get Joe's email client, I have to also use Alan's logging client, but it's amazing. So you're happy about that, which I didn't want because I wrote my own because I didn't adhere to dry. And you know, you would be so lucky if it was just a logging framework.

More likely if that email code is in, is touching anything else, is in any other package, it is got database code in there. It's got maybe website code in there, right? It's got all this stuff that if you just want to send an email from a simple executable, like all that stuff's coming along for the ride. And it makes it easy for somebody, say, who's working on the website to say, add a little call that logs an email via the database.

But if this little executable doesn't have access to that database, now all of a sudden it can't send emails? What sense does that make? And it's hard to see what's going on when you've got these sort of lines going on. So you would think my executable didn't need database access.

Why? It's not doing anything. It's not getting any data it doesn't need a session id from a cookie why is that in my email code but this stuff gets kind of dirty together and even if there weren't mistakes made and those are those clearly are mistakes and it's not really addressed by the you know that principle there should be a don't make mistakes principle but it's still just the idea of this like this email code it's like got a very specific functionality and it's now it's being tied with this other stuff and so anytime you need one the other comes along well here's here's a a great way to think about it okay so there was this uh the idea here is that if your component has a dependency on another component and then that

uh dependent upon component is changed. You need to reevaluate your component or possibly even recompile it. And you might think like, okay. And the example that I gave about like, Hey, I want to use Joe's email client, which uses Alan's logging client. You might think like, that doesn't sound so bad. What if, uh, you were trying to meet some kind of um government type compliance okay and you know that could be extremely stringent to meet uh and and to get a certain um uh certification right that your application is compliant with whatever their requirements are, right? Now, Alan's logging client changes, right? And that ends up coming along for the ride, but it could introduce new security flaws that now break my certification

or put my certification at risk. Yep. Yeah, and unnecessarily. It doesn't have to happen you know you can imagine the logging framework changes output so now it uses uh you know react instead of jquery react has got something that uh you know hippocompliance or whatever doesn't like and all of a sudden you can't release your software to your customers because your logging framework you know uses react which is totally sideways from React.

It has nothing to do with your product. Right. And again, like the other one was tied to another principle in Solid, this one also was. This was related to the interface segregation principle in Solid. So, I mean, he's drawing correlations. We talked about this earlier in the book. He's drawing correlations from your day-to-day stuff where you're working in classes and all that kind of stuff, and now we're just bringing it out

at a bigger level, right? Like parts of a system as opposed to classes within a part. And I'm a big fan of the ISP. And so this is the age-old question here, should the code be in its own project? Does it change together? It's really the answer, right? Yep. And I should mention, I just said ISP, we just talked about trying to not use acronyms, but if you're going to read this book, you should, I mean, it's going to go over solid, but you

definitely want to be at least familiar with the solid principles, and otherwise you're going to be doing a lot of backsliding, backpaging, figure out what's going on same with these three principles here they come up a lot in the book like it is not for people who don't like backpaging i couldn't imagine reading it on a kindle actually because of that like you know maybe you could kind of hover over or something like kind of look up definitions maybe would actually be easier but i definitely found myself flipping back especially when looking at diagrams yeah i actually find that to be true for a lot of technical books it's harder on kindle or or even any kind of tablet but yeah yeah it can be frustrating hey by the way solid we did talk an entire episode about solid and that was episode seven yep so but didn't we also just like rehash it in like 69

uh as it related to yeah in the architecture to this book yeah 68 69 was spending your money no that was 70 70 you're right that's my we're in 71 right now all right i'm i'm caught up welcome to the show yes hi uh so so joe is saying that we won't use any more acronyms so we said that during the ccp section and now we're saying that again during the crp section when we brought up the isp correct we got it we're all on board all right yeah so we want we want the idea here with the common reuse principle is that we want the classes in our component to be inseparable. You can't... Wait, you were going to say, did that spark a thought?

Yeah. Yeah, I just wanted to give an example, though. I didn't mean to cut you off. I just got excited about my example. Oh, because you looked like super excited. So I was like, oh, man. I got so excited. Yeah.

So... Forget it. We're done. We're done. we're done we're done i'm so excited about this right now apparently all right so i want to talk to you about system.drawing.point okay so in dot net um it's basically just a real simple it might even be a struct not a class like it's just got an x and a y coordinate and if you're doing a lot of graphing and stuff if you're doing some sort of like you know charting or some base basic uh you know linear kind of algebra type stuff like it makes sense to kind of have a simple class that has like an x and y that you can pass in you know as a the different functions and

stuff and i always thought it was funny that this point class that like would end up getting used in all sorts of other people's like you would see this all time in the other people's source code it was in system.drawing.point and so you would see these libraries that were like really math heavy would have a reference to system.drawing which is a namespace in.net land typically reserved for like drawing stuff so it's kind of funny where you've got a point which is often used for graphical and 2d 3d type stuff but also you've got this kind of funny where you've got a point which is often used for graphical and 2d 3d type stuff but also you've got this kind of notion of an x and y or an x y z that can be used for mathematical stuff that can be very far away from graphical so i mean it's maybe not that

really an example where not adhering to dry would have been okay so that you don't bring in all those other dependencies yeah i mean i could have just anyone could just as easily create one but even like there's some math functions that kind of rely on it and stuff so it's just kind of a weird case where you've got something that's like uh you've got a dependency that you might be bringing in that like seems totally unrelated and it's so easy to slip in there and not realize that you're bringing in this whole big dll and that's the kind of deal that probably has all sorts of security problems with it too so it's kind of funny yeah so the other principles that we've talked about so far were more

let's say positive about like what how you should put things together what you should do what you know this one the common reuse principle is more about what classes, what a, what a component shouldn't, uh, what classes shouldn't be together rather than what should. Right. So if, if you're, if you're putting classes inside of your component that aren't tightly bound together, that, that are separable, then why is it in that same component? Yep. Yep. Oh,

I think I had that written a different way there. Therefore classes that are not tightly bound should not be in the same component. Yeah. Whatever. Yep. And then wrapping it up, it says don't depend on things you don't need.

Right? Like that's, that's what it started with and that's what it ends with yeah oh this was yeah this that was another example where he like redefined the interface segregation principle to go along with the common reuse principle don't depend on things you don't need yep so i wanted to your system dot drawing dot point i would argue that maybe they're doing it wrong if they're going to bring in all those additional dependencies. Right.

Yeah, it's not a great example. Like most of my examples, it's not really adequate to the discussion. No, I thought that was a good one. I mean, you're bringing in an entire drawing namespace for a single thing. That should have been done differently somehow, some way. Yeah, but in this case, I i mean you're at least using a class like you can imagine like there's probably been all sorts of times when you people bring along dlls that aren't needed at all um but uh just to kind of recap yeah i just wanted to mention those

three because it's going to come up again and we're still talking about these three and now we're going to start mixing them all together. So we talked about the release equivalence principle, which is all about releasing shared software components with good version numbers and notifications and documentation. We've got the common closure principle, which is all about keeping things that change together. And we've got the common reuse principle, which is all about keeping unnecessary dependencies out. There, we got it?

Yeah. All right. So a couple of questions for you. If you're constantly releasing more than one component at a time, should that be a single component? If I've got, say, a web library and a core library that's got my business logic and whenever I make a change to the website, it generally needs a change to the core library and vice versa.

Hmm. No. Should not. I don't think. Okay, and I would say that the reason is you probably got other stuff that depends on that core right that's what i was going to say that core it that that's more of a dependency chain there i think that core should be compilable on its own right it should if it does have dependencies it should be on other pieces that it needs but it should be

compilable on its own but yet that, the website itself or whatever is using that business library, when that thing's being built, sure, it needs to go build the other one and then bring it in because it depends on it. But no, they should not be a single component. Yeah, so that was really interesting that neither of the three principles we talked about really kind of address that use case. And that's the kind of case where something is a broken out module because it's reused. And we've got the release reuse principle, but it didn't really talk so much about breaking stuff out in such a way as to make that easier. At least that's not what I got out of it. But I just thought it was kind of interesting to kind of hear these three principles

and then kind of think of a, you you know at least a somewhat common use case that kind of slipped through the cracks or at least kind of flew in the face of one of those guys so I thought it was interesting the reuse release equivalence principle well that was all about having those

good release numbers and notifications having a theme but it didn't really talk about where you should draw those lines between good release numbers and notifications, having a theme. But it didn't really talk about where you should draw those lines between releases and what should have separate release numbers. Well, wouldn't you have a separate release number for each of your components? Again, let's not talk about the marketing version

of all of the aggregate of the components, but for each individual component so your i think you gave a example of the core uh what'd you call it the core project is the core library that would have its own version number that could you know um depending on how it's released let's say say if it was a NuGet package, it could be published out as a NuGet package and then the web component in your example could use that latest NuGet package as needed.

There's a case where you add a new column or something and so you've got to go add it to your DTOs or your beans or whatever you want to call them, your POCOs. And then you go update some JavaScript and HTML to consume that data and actually display it. And so you've got a case where those two things change together all the time. But there's a really compelling reason for keeping them separate. Because other stuff needs to be able to raise that core. And it doesn't want to, you don't want to carry along those unnecessary dependencies from the

website. Well, I guess maybe that's, maybe that's it. Maybe it's the common reuse principle applies there because we say we want to break these two out because we don't want to carry along that website baggage. They shouldn't depend on each other.

Hey, just a, we, we've said new get several times just for anybody else out there that is the package manager for dot net and so like if you're talking about a java there's a gradle there's maven there's other ones right for javascript there's npm and all that so um i just didn't want anybody to get hung up on what's this new get thing right like if that's not your language du jour for c sharp or whatever you know or refer to C pan from now on or C pan.

There you go. Um, it's, it's a MPM for.net. That's basically what it is. But probably everybody knows MPM at this point. I would think just about, um,

yep. So, uh, I don't know if there was anything else I had a thought on there. I don't think I did. I'm pretty happy. I'm pretty happy with that justification. So I feel good about it.

I did have one question. So just out of curiosity, you guys, so you had this core thing and you had this, um, the website, we'll call it. Do you version these things the same?

So what do you, what do you call it? So, so, so for instance, your core is on two dot. Oh, do you make your website to dot? Oh, no core is on 2.0. Do you make your website 2.0?

No. You don't? No. I see no reason why the components need to have the same version number. Okay. Those version numbers should be able to increment independently of one another it's the aggregate it's the aggregation of all of those things that make a product that's going to fall under one specific you know version label that the you know your marketing group is going to define right but you know windows 95 you know for example

you open up any one program in there and go to a help about right like each one had a different version right right and so those were each of the different components you know notepad versus calculator and then if you fast forward to windows 10 and bring up those same versions it's still windows 10 and there's a build number associated to it like 1703 or whatever it is now uh but when you go to open up calculator or notepad and go to help about right those are different version numbers and and inside of that version number for like calculator for example or notepad there's a whole set of components that that version is aggregating together that that notepad version is aggregating together to represent what it takes to make that notepad right but so the key, I think I wanted to point it out for that purpose, right? Like if

you version them all together, it'd be really easy to figure out, right? But the key part here is when you have these things in separate versions, that means you have to be able to maintain what goes with what, right that's where yeah maintaining dependencies maintaining your dependencies right so anytime you introduce dependencies it's always that you're introducing maintenance nightmares for yourself always if you don't have some sort of automation in place to handle it all for you right even if you do it's still a hassle it is a hassle but like if you look at things like npm for for instance, right. When you do a, um, like NPM install, you know, whatever package and then save dev or something, you can actually tell it. I want anything like you said earlier, or you said greater or equal to this version or with this main version or whatever. Right. So it, it's, it's a whole nother thing this is where devops and all that kind of stuff comes in right but i did want to point that out that you know the

version should be independent and you know just what you said but there is some overhead to that to to be aware of because let's flip to the extreme for a moment let's say that you did take the approach to where my core library is 1.0, and it's extremely stable, right? Well-written, tested, whatever. But we're iterating constantly on our website, and so our website's about to become 2.0. Now I've got to go make an arbitrary version number change and republish out the library for no reason but just

because i want the version numbers to match right like that's seems crazy right so right away we can reason about that that doesn't that doesn't even seem like a logical idea that anyone should you should do cool and think about this example too like if i've got a c-sharp uh seven project what uh version.net is that right like it'd be kind of nice if those were in lockstep but i understand why they're not right and what version of visual studio does that require and what versions of windows can i deploy that on like it would be nice if those things were in sync but you can imagine if like they tried to release all that stuff all at the same time you know it'd be a major pain in the butt and would really slow things down and so i'm on board with keeping things separate but i also recognize that it's a huge pain in the

butt and i'm sure there's big lookup tables on microsoft.com where you can figure that stuff out and it stinks that we need that but i don't you know i still think it's the right answer yeah i mean basically what this does is i and the reason why I wanted to ask the question is I wanted everybody to be aware that there's a non-human readable or non-human followable part of this, right? Like it's a big matrices at some point of, you know, this depends on this version and then this thing depends on that version. And it's not something you're going to chain together mentally, right?

Like it needs to be something that's automated. And so the version numbers really shouldn't care to you as a person looking at it. And this is why the semantic versioning is so important. Yes. Because when those machines are reading, you need to have a consistent order to the chaos. Yep. Definitely. All right.

We have one more question there, Joe. I don't know if we uh did we hit this one yeah i've seen this on twitter recently um uh there's a lot of um i think the tide has kind of turned on microservices a lot of people kind of give them a lot of grief nowadays um at least you know the circles i'm hanging in um but uh one thing that's kind of um funny is i i guess a lot of people have kind of adopted them and not done them so greatly and so and so like I saw this come on

Twitter the other day it said if you're redeploying all of your microservices at the same time then you're doing it wrong it's totally defeating the point of microservices right so I thought that was a funny example. Yeah, the group's Joe's hanging out slash r slash I hate microservices. They don't like them.

I was actually thinking like at his board game conventions, they're sitting around, you know, while they're rolling the dice talking about microservices. Yeah. Awesome. So microservice, what gives? Oh, I got a 20. Yeah. That's awesome. So, microservice, what gives? Oh, I got a 20.

Wow. Is that how they talk? I don't know. I had to do some other voice. Are you guys not seeing the hate for microservices? You know what? I mean, it's one of those things that I've always seen hate for it because it makes total sense from a scalable perspective, right? But man, does that scalability come at a cost, right? Like it is not simple anymore. It's just not. I mean, now you got to

worry about end points going down. You have to worry about, Hey, how many are alive? Hey, Hey, did this already hit one like there's so many everything i've read about microservices and everything i've even tried to do personally with microservices is you have to code so much um uh failure type stuff into it that it's i mean it's a lot of work it's a lot of work for unless you need that scalability, it really doesn't make sense in a lot of cases. And that's where I've seen backlash, where it's like, hey, let's go ahead and code this thing up as a microservice up front.

And it's like, wait, why? Do we even know that that's necessary yet? Like, why don't we wait till we find out that we need it? Yeah, I mean, Amazon, yeah, Okay. They need microservices, right? Like they need to scale out to, you know, millions of hits a second, right? Maybe they do. I'm sure that there are projects within Amazon though, that don't fall into that realm. Totally. Totally. Yeah. I mean their website, their shopping website. Yes. But yeah, I mean, many things, a lot of times, I mean, there's even even so you've seen the backlash on it i've seen things where people are like monolith is the way to go right like it's simpler to maintain the hardware

so much faster nowadays that it doesn't make sense to deal with this kind of stuff so yeah i mean it's interesting yep although yeah the places i'm hanging on reddit like it's definitely uh there's a lot of negative tidying i negativity. Somebody posted an article about cloud something or other, like cloud innovations coming out of reInvent in November from AWS. It's like one of the top comments was still like, it's just computers. Anyway. So you're excited about this next piece, right? They what they wanted it to be right they didn't want it to be computers uh yeah so am i excited or my law i think outlaw was because this is where we

start getting into some diagrams so we talked i already gave a hint about the tension triangle and this is what we're leading into now, the tension diagram for component cohesion. So we talked about these three principles, the reuse-release equivalence principle, the common closure principle, and the common reuse principle. So picture each one of those as a, as a point on an equilateral triangle, right? And, um, what you're going to end up with is, man, how am I going to describe this visually or not visually, but voc verbally, um, you're going to try to swing that triangle to where at times it's not going to be an equilateral triangle, right? So in the beginning of your development, it might be positioned in more towards one way versus the other, right? One of those legs of the triangle

might be shorter. But you're ultimately going to want to try to get to a triangle that makes sense for your given project, right? But there's this relationship between them. So, uh, if, uh, opposite from the reuse equivalency principle is going to be the line across from that point is going to be the hard to reuse right does that sound easy enough to understand what i'm trying to yeah i think i've got that written out below i kind of like wrote out like what the three problems were and if you know if you have that problem like which kind of principle was at play here yeah it's hard to like try to describe this triangle but so let me just finish this then so across from the common reuse principle the line across from that on the triangle is going to be that it's you're going to have too many unneeded releases right and then the line across from the common closure principle is going to be that you're going to have too many components that change.

So if I put my finger on the common reuse principle, it's at the bottom of the triangle, the triangle is pointing down, I drag it down. So it's getting further and further from those other two points. What is that doing to my code? It's now going to be too many components to change, and it's going to be hard to reuse, right? I don't think so. If you drag that bottom point down? If I drag that bottom point down,

the edges of the diagram describe the cost of abandoning the principle on the opposite vertex no no cost it's the things between it so no as as you drag that common reuse principle further down, right, then that means that you're focusing on the reuse release equivalency principle and the common closure principle, which means you're going to have too many unneeded releases. Okay. That's how I interpret it. But now that I'm looking at it, it says the edges represent the cost of abandoning

the principle of the opposite vertex so the edges are the cost so if my if i'm having too many unneeded releases that focus that goes along with what i said if you focused on the top two points which would be okay you said that the common reuse principle was on the bottom so your release equivalency principle is on the top two points, which would be, okay, you said that the common reuse principle was on the bottom. So your release equivalency principles on the top left and the common closure principles on the top right. So if you focused on those top two points, then the line between them is that there's too many unneeded releases, right? So if you were to focus on those top two points, that would mean that that common reuse principle is further away. So the cost of abandoning the common reuse principle is the line between the release equivalency principle and the common closure principle, which is that it's too many unneeded releases.

Okay, which one was the reuse principle again? Okay, that was unnecessary dependencies. So if I've got too many unnecessary dependencies, then I'm going to have too many unneeded releases. Yes. Boy, who would have thought that talking about a triangle would be so difficult? So I think the problem is you can't talk about dragging these really you have to talk about if you focus on

one or two of these things at a time right like what what happens you kind of have to talk about them in pairs yeah that's the reality you're not there's no equation to like how you're going to draw this triangle it's just like hey these are the three points which one are you going to focus your effort on and you know anything that you're not focusing effort on, then the cost is directly opposite that point. The line directly opposite that point is your cost. Okay. So I'm happy with how I wrote things in.

So if I say we have too many unneeded releases, what's the problem? Then the answer is that I've got unnecessary dependencies because of the common reuse principle. If I say, hey, our code is too hard to reuse then the problem is that our release slash reuse uh equivalence principle is out of whack so we're not notifying of our releases we're not documenting well enough and if if we are saying that we have too many components changing

every time we do a release, that means we've got a problem with our common closure principle. So we've got components with mixed functionality. So too many components are changing because things are spread out too much. Yes.

That sounds like a good summary of it to me yes yeah so that's pretty cool so you can say you can kind of look at this triangle say like you know what my business has a bigger problem we probably have all three of these problems but i have a bigger problem right now with my code being too hard to reuse so the problem there is probably lack of documentation probably um lack of cohesive themes around releases. Yeah, I like that. I feel good about that. And I mean, to sum it all up,

they say really the key is trying to find a balance between these things because there's no perfect scenario, right? Like there never is. Yeah, and even talk about how the beginning of a project is going to be skewed. Like you don't want an equilateral triangle. You're probably going to be skewed to one of the other sides actually i think they even said you want to skew towards the um release right well so the the specifically the quote that he was that joe's referring to is um this is building on to the other quote that i mentioned about the good architect finds the tension uh finds a position in the tension triangle that meets the current concerns of the

team but is aware that those concerns will change over time and he says for example early in the development of a project the common closure principle is much more important than the reuse release equivalency principle because develop developability is more important than reuse right so that triangle is going to constantly be shifting and evolving it's going to look you know wiggly yep yeah, I'm not seeing this picture anywhere on the internet, so I don't think we'll be able to share it. We don't want to take a screenshot of the book.

It's a good book. You should buy it anyway. Are we doing a giveaway for this episode? I guess we are. I probably think we should pick a winner for the last episode too. Did we not? I forgot. $50 gift card we gave away uh last episode oh man oh i thought that we have to because i factored into my calculations all right all right we'll we'll figure that out before um yeah so the winner of the $50 gift card is Michael Outlaw.

Wow. That's how did that work out? Yep. So we'll figure that out before this goes out. So nice of you guys. So check your emails. We'll be sending something out. Just check your emails,

but we'll do, we'll do a book giveaway on this one. So if you'll leave a comment on this episode, coding blocks.net slash episode 71, we will give away another copy of this very excellent book so what does this all mean yes we've gotten through we've gotten through these three principles and a very difficult to explain triangle i don't know if you know how triangles work but who knew that they could be so complicated yeah and uh that's about it it's a it's a big tug of war and uh i i kind of like that there

are no clean answers it makes me feel like less of a dunce that i struggle with this stuff all the time so uh usually let us know what you think in the comments and win the book it definitely helps with our uh our imposter syndrome uh absolutely yep yep um so uh that's it for the uh, absolutely. Yep. Yep. Um, so, uh, that's it for the episode. We are going to try and keep it short tonight.

So hopefully you enjoyed, uh, and if you did, please leave us a review. If you go to coding blocks.net slash review, we tried to make it really easy for you. We've got all the links there. And so you don't have to install iTunes.

Um, pod chaser is an excellent place. You can actually leave a review per episode. Um, and, uh, you know, there's stitcher and there's other ways too so if you just go to codingbox.net slash review um then we'll make that easy for you and uh we also have really excellent show notes today which you can find at uh slash episode 70 all right and now it's time for my favorite part of the show survey says oh man

i feel like i just like knocked the ice cream cone out of your hand i'm sorry you can you can do it freaking florida boys wow all right so i thought i had uh more choices in here Hold on Oh no I only had three choices I threw your flip flop into the lake So Our In our survey says section

From our last episode we asked Do you trust Your family members To buy the tech that you want Because Christmas is coming up the holiday season is coming up, and this is the season to give, right? So your choices were, of course I trust my family to get the things that I want. Why wouldn't I trust them, right? Or, well, I'm hoping for the best, but please include gift receipts just in case.

And then lastly, no way. Even with a very specific list, things will go sideways. I could give them the link. Click the link. All right. So, Alan, you're going first What do you think was the most popular Option With Percent of the vote

I'm going to go with I'm hoping for the best but please include Gift receipts I like how you put a question mark on the end Of your answer You're so confident in it And I'll go with 30 30 all right remember price is right rules yes all right joe what say you

i'm gonna say no way even if the specific list things will go sideways But really, it's because I already have everything I want, and I buy it as soon as it comes out. So what's the percentage there? It's 34%. All right. 34%. Bollocks. And by the way, we know he's lying about he buys it as soon as he wants it.

No. That's such a lie. No. It's because I don't want very many things. How many times have we talked about like seeing him drool over like a specific guitar or a mountain bike and then like, you know, six months later, he still doesn't have it. Right, right. Yeah.

But six months later, I don't want it anymore. That's why you don't have it. You wait your want out basically. Yeah. It's the benefit of being flippant about my desires. Like you just wait long enough, you just don't care anymore. It's a defense mechanism, really. That's how you've survived all these years.

That's right. That's how I cope. All right. So Alan says he's hoping for the best with 30% of the vote. Joe says no way At 34% Of the vote And Joe wins Man people were really honest

Joe wins big time Was it 70 some odd percent No way Was 60% of the vote Holy cow Now Alan you were really close Because hoping for the best was definitely the second choice Just under 33% of the vote Now, Alan, you were really close because hoping for the best was definitely the second choice.

Just under 33% of the vote. Oh, nice. So there was nobody that was like, hey, just give it to me. Yeah. That's the real takeaway here. It's like less than 7% of the audience is like, trust their family to buy their tech gifts for them. Any devices, they're like you know no way i want an apple oh they get this like thing from an orchard yeah like hey hey mom i want the the latest uh

series 3 apple watch with lte and then you know they're just going to get a bag of apples a random watch you know a ten dollar watch or something you calculator watch there it is that's what it's going to be. Oh, because that'll be the latest smartwatch. Those are actually, that's becoming like the latest hipster thing is the calculator watches are coming back. So, yeah, that's what you would get. That's amazing. Well, this one doesn't have LT and E, just those letters.

This one had the whole calculator, had the whole alphabet on it. It's better. Well, see, i feel like you know like the phones and stuff like the stuff that i really want like i either buy or don't buy myself and so the stuff that i might want for christmas would be like you know i don't know a cell phone case that looks like a tank tread or something like i'm not trusting that to anybody i you know i need to see that you know i need to spend some serious research time i can't just you know tell anybody just pick me up a cool looking phone case

oh dude you know what if i what if i get the tank tread he's gonna spend all the time on it's like a 20 item like yeah a case for the phone but i gotta spend some research time on that wait what does that look like yeah it looks like it looks like a transformer it's badass oh it does yeah man my phone case has a kickstand now. You know, I wouldn't even have known if I didn't go browsing for myself. This is why Joe has to refer to our list when it comes to buying the more expensive things. Because he spends all of his time researching the little things. Could you imagine the hole he would crawl in?

I don't know what video card to get. In my research research i think you mean like holding my phone up to the screen like is this gonna look good i don't know i don't know why you just said video card and this like thought popped in my head because based off of the last conversation or the last episode but there was actually an article now where it was we were talking about how like the cost of video cards we're not we shouldn't expect to see any kind of decline in those because of the Bitcoin rise in mining. Now that it's gotten up to $13,000,

something insane like that. Because it's created another surge. So now all of the video cards are being consumed with mining capabilities. So it's like, thanks. Some of us wanted the game i don't know i don't know about you but some of us wanted to be able to like relax play a little game every now and then man continuing that tangent i shared with you

guys the other day there was a dude who mined 7500 bitcoins back in the infancy and he threw his hard drive right away and it's in a it's in a landfill somewhere his bitcoin fortune is worth over 80 million dollars and the dude like how do you sleep at night how oh man i like i'm a little vomity right now just even thinking about being in that position oh oh it's awful anyways i mean yeah i don't really have a good answer for that yeah no dude that's that's horrible yeah yeah that's awful all right so what we got for today's survey well before i do today's survey actually i uh we we we sent out one of the things we did on the mailing list was a course for React and Motion. And we asked people

to send in their favorite JavaScript front-end framework. I think you guys have both seen the graph. So you're going to have to pretend they didn't. And give me a guesstimate on what you think people said their favorite JavaScript front-end framework was and a percentage.

Well, I can't see the graph that you're looking at. I vaguely remember. I found it. I'm not going to paste it in until after you guess. I'm going to omit myself because I actually remember roughly what these numbers were. Do you remember the percentage? I don't remember the percentages.

I do remember Angular was the top angular was the top and it was like 34 or something like that like it was it was a pretty decent chunk it was like angular and then react and nobody was gonna be surprised well that was also joe combined all of the angular responses he didn't like break it up into versions fair enough yeah um but it was it was angular first uh and then react second and then third place i think it was view i think yeah wow she has a better memory than i do and then down from that i'm trying to remember what was after view it seems like it was like Knockout or something. One of the old random ones. It was jQuery. Yeah, it was jQuery.

Okay. Yeah. You want to take one more guess? After jQuery? Yeah. Like what was number five? Vanilla. It was Other.

Other. Ah. Other included things. We definitely got some funny answers in there. Well, Other tied with Meteor, didn't it? No, Meteor was only 3% oh dang but what I thought was really interesting is just how low

ember was like it was down in the others like hard like ember you know like if I if we had asked this a year ago I feel like ember would have been up there I don't remember hearing seeing any responses for ember it was yeah I mean you know the thing about ember is is it was always that niche thing but i mean it's it's like one of those things because we've been asked in the past you

know hey what framework would you go grab and i my answer has always been what's hot in the market right i mean ember's not i mean don't get me wrong there's companies out there that use it but i mean if you're looking for something that's not going to be what pops up on any linkedin or resume or anything like that yeah i don't know so um we'll have that we'll have the pie chart in the show notes um and i'll post on facebook and twitter and a couple other places too they're just kind of interesting to see and aurelia was another one that you see here all kind of a lot about uh in the dot net space and just kind of it's lumped into the others along with fart scroll a lot about in the.NET space and it's just kind of lumped into the others. Along with FartScroll. Nice.

We got more FartScrolls than Aurelias. I'm sad to say. So if you're working in Aurelia, then I know a great React course you could watch. Oh, man. Vue wasn't even around a year ago, right? I mean, I'm sure it was, but was it popular a year ago? Not as popular.

I think it's really been getting steam of late. Am I remembering it wrong? Vue predated Angular and React, right? Didn't some of the concepts? I don't know about that. I know that it just recently hit version 2.0, so I don't know. I'm curious. recently hit version 2.0 so i i don't know because it seems very it seems very much a mixture of react and angular in terms of how its syntax is but i don't know anyways okay all right today so

on to today's survey our third survey that we're discussing today we want to know how many developers are at your company and this is a really interesting question for us um so i know we definitely have our own biases based on the places that we've worked and i always hear such astronomical numbers like say they say like am a microsoft has 50,000 programmers on their staff and amazon has 20,000 so you almost think like our you know like that if we took a of listeners, you would think that so many of them would work for those large companies, but I kind of don't think that's the case.

So what we want to do here is we'll have a couple options. So if you're a solo developer, let us know, just me. About five, so give or take a couple, like Captain Planet. That's one of the options uh closer to

the 20 mark this is the point where you really want headphones and you have to you know get into the politics of uh where and when who you're going to launch with when you're closer to the 100 mark now things that's definitely gets changed there's going to be people that you don't know there and so let's know about that and then i'm just going to call anything over 10 000 like you know you're in the you're in those those big players you're at the facebooks or you know semantics or amazons or whatever 10 000 i think a thousand developers is pretty major right yeah we want to break that out to a thousand and one thousand let's just cap it at one thousand plus yeah one thousand plus because i mean that's when you start getting into like big big software because you're talking about like total developers in the company not

developers on the same team right right yeah i think which is really funny like i worked at semantic and they had well well over you know 18 000 employees but it didn't feel that way because the group i worked with was like 200 i I mean, I worked at the Amazon's up too, and Amazon's got 21,000 developers, I think. So it certainly didn't feel that way to me, right? Yeah,

I would say that I would guess that any company that has a thousand or more developers, that's an enterprise company. That's big time, yeah. Depending on what the enterprise might be, but that's an enterprise company that's big time yeah whether you know depending on what the enterprise might be but it's an enterprise company so i i got curious so i went to my favorite uh resource wikipedia uh the most accurate yeah wiki leaks or wikipedia well both um no so uh i remembered it incorrectly um view started after angular okay like uh one of the guys who was working for google using angular

uh created evan u that makes sense because it's definitely influenced by Angular syntax. But also React. Yeah. Both. I mean, it's a mixture of both. Yeah, definitely. We should talk about print and JavaScript sometime soon. We should. Man, we have all kinds of things.

I would love to do a machine learning series. I'd like to do some front-end stuff. Man, we have so many topics. Maybe after we get out of this book, we'll revisit some of these things that we'll do some deep dives on. Yeah, when you're leaving that comment, trying to win that book, why don't you let us know what you like to hear? Yeah, I like that. Cool.

Yeah, it's a good idea. All right. So, we're wrapping up this episode. Obviously, we're going to include a link for the resources we like section, a link to the clean architecture book by Uncle Bob. And with that, we head into Alan's favorite portion of the show. It's the tip of the week. Yeah, baby. All right.

So I'm going to start with my tip of the week. And, um, so Alan mentioned that, you know, he'd like to get interested in machine learning and start, uh, dipping his toe into that. You can too. So last episode, I believe it was last episode, my tip, or maybe it was episode back was the using the, uh, studio.azureml or, uh, what was that? I forgot the URL now. Studio, yeah, studio.azureml to start building out your, well, let me finish the URL, studio.azureml.net to experiment with machine learning and use some of the algorithms that have already been created, a little nice drag and drop interface, whatever, that's all within Azure and you could do that for free. Well, this is similar to that.

There's the notebooks.azure.com, where you can spin up a Jupyter notebook to play with Python or R or F sharp. And you can use that, uh, environment to go ahead and start playing around with some various machine learning, uh, exercises of your own. And they've got examples right there on the main page where you can, uh, discover sentiments in tweets or, um, they give you an introduction to the cognitive toolkit um and uh yeah so it's a really great tool you can go out there and play with it you can use um you know uh multiple versions of python like i said you could use r and f sharp as well so yeah just really cool environment for free um Um, yeah,

I don't know what else I could say about that, but it's awesome. That's killer. Oh, and those libraries, there's a whole bunch of libraries already there, uh, with our notebooks already available and you can clone those much like you

might clone a get repo and, uh, you know, start editing that. So if for a notebook, for anyone who hasn't used it, is this kind of concept where you could combine markup style documentation along with code. And you could break up the code and then insert like markup and then have code again.

And each individual piece of code, you could run independently. So what I mean by that is like, let's say I have a block of code where I would might put in all my import statements to reference other packages that I want. And so I could go ahead and execute that. So the inside of my running kernel, I have those. And then I could go ahead and execute that. So the inside of my running kernel, I have those. And then I could put in a block of like, okay, hey, here's the requirements of what I'm trying to do. And then I could write my third block would be another piece of code block where, maybe I write some entry level kind of just trying to ramp up the overall application or whatever. And I could run that second block independently of the other block. I don't have to rerun the first block of code. I only need to

rerun, I only need to run that second block. And I could run that second block as many times as I go. And I could keep writing blocks of code like that inside of this notebook. And I only need to run, I only have to run that one block as I'm going over the other blocks, their state is going to be maintained as I, as I carry on. That's really cool stuff. I mean, they've got all like, it's almost like the, uh, um, code Academy type courses where it's, it like walks you through while you're playing with the code. Like it's really cool stuff. Yeah. It's so amazing's so amazing it it the amount of stuff that you can get for free is crazy and i and here's one downside that i want to point out that

is like super unfortunate the way they microsoft positioned this uh in terms of like the placement but on that main page there's one called the Fundamentals of Data Science with Python, which, okay, that sounds super amazing, right? But like the first handful of notebooks are all the basics of Python, which I really wish they had moved that out into just the basic Pythons because it goes over like if you're not, so if you wanted to learn python for example then those those you know first handful of notebooks go over everything that you might want to know about working with python you you know what what the semantics of that language are like right um and

so i say that because my son who's interested in Python, I wanted to, you know, him to point it to him to use it. And, you know, he was going through the introduction of Python notebooks, and he's like, Wait a minute, I'm not seeing these things that you were talking about basic data structures, and, you know, things like for loops and while loops and things like that. And I'm and I'm looking through that introduction to Python notebook and i'm like yeah i don't see it either i don't remember what i was looking at before and i had to go back and find it like oh yeah there it is interesting so maybe misorganized a little bit but a lot of cool free stuff that particular one is so i only and i only call that out not as a not as a jab at Microsoft, but more like for those who

don't already play with Python that might have an interest in Python, that's a very easy set of notebooks that you could go through, but go looking for it in the data science, the introduction to data science area. Excellent. Alright, mine

is a Visual Studio 2017 tip that I stumbled upon and is just awesome to me. So anybody that's ever used Sublime or I think even Visual Studio Code has this. There's this whole map of your code on the scroll bar. Right. And so as you get familiar with your code, you sort of can see the pattern, right? Like you sort of see the indents and the fatter sections of code.

And so it's like a really quick visual way to be able to go in and scroll to a section of your code that you're aware of. And there is a way to enable that feature in Visual Studio 2017, probably even 2015, I think. Um, so in a nutshell, you go to tools, options, text editor, and, um, you go to all options and

you, or you can search in the, in the little search thing and type in scroll bar. And then you'll see there is a way, um, I think it says select show annotations over vertical scroll bar. But basically, right now you get those little dots down your scroll bar where you can enable this map view of it and you get those as well as highlights and you go to sections. So, I mean, I love it. I turned it on online. I use it all the time.

So if you didn't know it was there which likely you didn't because i mean unless you just somebody goes in digs around and options in visual studio you probably didn't you probably didn't know so now i would just encourage you to uh play with the white space on your your code so that you can make pretty art in that map you can man you'll easily be able to see methods all kinds of stuff i i mean it's a cool feature i mean there's a reason why things like sublime and visual studio and all these other or visual studio code do either of you guys remember that from like the 90s i think it was do you do you recall what i'm talking about joe there was like a i'm trying to remember who it

was i want to say it was like a printer company like Epson or somebody where it was, I don't know, like an Easter egg. If you happened to go look at their HTML, right? Because you remember like that was the 90s, right? Like, you know, everyone, you wrote your HTML or your JavaScript, you're like, oh man, it's amazing. How'd they do that? And then you go and like, you'd look at it and it was easily to, you know, easily human readable easily human readable right that wasn't minified or anything like it is today yep and they had organized their code to where if you flipped if you if you were to print the whole thing out the whole page out and then flipped it out on you know um portrait mode right then it was a mountain it was a mountain scene and i forget which one it was then it was a mountain scene.

I forget which one it was, but it was some Mount Fuji or something like that. It was a famous... That's awesome. You know what? Maybe that was it. It was a Fuji.com. Isn't that like a film company? That's what it was. I think it was the Fuji mountain chain.

If I remember right. I've never heard of this. I'm going to see if I can find it. I missed all days. All right. So that's it for me. Um, what you guys, what you got,

Joe? All right. Well, I remember that I'd done gliffy as a tip before, so I had to scramble. And, uh, once again,

I haven't actually, uh, used my tip. So I still thought it was pretty cool, though. Did you know that there are, in particular, actually, there's one really popular open source CPAP analyzer that will take the data from your CPAP. You can, you know, if you have a little SD card,

if you have, if you're not familiar with CPAP, then, you know, good for you. But for the people that do have a problem with sleep apnea like some are larger neck uh listeners like myself um it uh the data is oftentimes like encrypted or um just unaccessible or isn't it really easy to read but there's an open source uh software package called sleepyhead that will take that data will decrypt it load it in and give you all sorts of really interesting info and biometrics about your own sleeping habits habits and it looks really cool the graphs are all really cool i've heard a lot of good stuff about it i've been meaning to try it so i want to to take a look at it maybe you can do something with uh with outlaws tip

there and do some machine learning and i don't know disrupt the whole industry that's really cool yeah i mean why not i mean you gotta like that any open source project called sleepyhead is already a winner that's awesome it's pretty cool uh so i can't find that that any art or uh any images of that fuji thing that i was thinking of and when i found pictures of food mount fuji i'm like oh that's a little boring maybe that wasn't it because it definitely wasn't just like one peak. So I say that because if any listeners recall what I'm referring to. I actually found it. Oh, you did? Yeah. Oh, share the link.

Let's put the link in the show notes. Yeah. Yeah, because I definitely want to see it again. Fujinonbinos? Never. You're going to have to spell that one f u j i n o n b i n o s dot com slash bp dot php and apparently like this wait you can't just put that in the show i could i could i could all right anyways yes i I will send it. So there was somebody, yeah, I found a link to somebody.

I need to verify this. This might be an attack. I don't know. What are all these pop-ups, Alan? All right. Sorry about that. Oh, my gosh. Yeah, at any rate.

All right. you're right okay all right so with that uh we discussed the components and component cohesion of the clean architecture and i hope you enjoyed it as we continue to make our way through this uh this book subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app be sure to leave us a review by visiting www.codingblocks.net slash review. And while you're up there, go ahead and check out all our show notes, our examples, discussions, and more. And if you guys know anything about CryptoLocker,

let me know. I'm getting this weird pop-up. Man, get off me. Send your feedback questions, rants, to the Slack codingbox.slack.com you can actually send yourself an invite by going to the website codingbox.net and going to slash slack and we've got some links there too and come in hang out and swag flag if you guys want stickers send us a self-addressed stamped envelope just go to codingblocks.net slash swag and yeah i think that was it yep and we've got all sorts of stuff on the website if you've Send us a self-addressed stamped envelope. Just go to codingblocks.net slash swag.

And, yeah, I think that was it. Yep. And we've got all sorts of stuff on the website. If you've never been to the website, I definitely recommend checking it out because if you like the show, the show notes, there's just a ton of them. There's some additional articles and lots of resources. There's videos up there. I mean, there's all sorts of stuff. So you should check it out.

Yep, totally. This was a short episode. Thanks, guys.