Coding Blocks - Clean Architecture – Are Microservices Truly Decoupled?

Episode Date: March 19, 2018

We're back with our last deep dive into Robert C. Martin's latest book, Clean Architecture, while Allen suffers from sleep deprivation, Joe shows us his dance moves, and Michael's mind is blown on how to unit test.

You're listening to Coding Blocks, episode 77. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. This is CodingBlocks.net, where you can find show notes, examples, discussion, and a whole lot more. 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. Freelancers and small business owners, I feel for you.

Tax season is here and there's a good chance that many of you are trying to dig your way out from underneath a pile of receipts and spreadsheets. Do yourself a huge favor and stop digging. Before you completely disappear under that abys of paperwork, go and check out FreshBooks cloud accounting software. Not only is it going to save you a ton of time and stress, it might actually change the way you feel about dealing with your taxes. Need to send your accountant a quick summary on the amount of texts you collected last year? How about pulling together a profit and loss summary? FreshBooks can generate these reports in seconds instead of the hours it would take you to do them manually. You can even set up FreshBooks to import expenses directly from your bank accounts, which means next time you use your debit card for that meal,

tank of gas, or new computer, boom, the purchase is recorded instantly in FreshBooks. All this and FreshBooks is ridiculously easy to use. It's made especially for people who don't like dealing with numbers and their taxes. Right now, FreshBooks is offering a 30-day unrestricted free trial to our listeners. To claim it, just go to freshbooks.com slash coding and enter coding space blocks in the how did you hear about us section. All right. With that, it's time for our podcast news, and we always like to start off with reviews.

And with that, Jay-Z, you want to take iTunes? I do. So, iTunes, thank you big time to Frodo McNuggets, 007 Benny. I'm already packing up. Likely Suspect, Marcus Raspich, Alex13CP, The Clink Family, packing up likely suspect marcus raspich alex 13 cp uh the clink family especially big thank you to the clink family that was awesome uh chris sean hayes uh deleted grim for two and zach reeves Yep. And on Stitcher, we have Roka88. These trucks. The code itself.

Joe is dev for life. Huge thank you, guys. Great names, too. Some awesome ones in there. I really appreciate it. So it's that time of year again where Stack Overflow announces their 2018 survey results or their survey results for 2018. Did either of you guys see this yet? I have not looked at it.

There are some really interesting things that came out of it. What do you think the most popular framework, library, or tool is? Well, hold on. Let me go ahead and open this up and I'll tell you. Oh, geez. I'm going to guess Node.js. Go ahead. Node.js, I'd probably go with that as well.

Yep, yep. Yeah. But here was the one that I didn't expect to come out on top for second place. Angular beat out React. We saw that in the survey we did for JetBrains licenses not too long back. Yeah.

I guess it doesn't surprise me because Google's had quite the fight. And remember, React just recently went to a more accessible license. So a lot of companies probably wouldn't even touch them for that reason. So, yeah. Maybe.

It was a pretty big one though but um man i'm trying to think what were some other things in here like uh you know most most popular database i thought that one kind of went you know i was more i expected number one yep my sequel was number one okay i was actually kind of surprised to see SQL Server was the second most popular. And Oracle was like way down the list. Postgres was number three, I take it. Yep. Yep.

I have not cheated. I've got three. You've got three what? I've got three things I was going to call out on the survey. Okay. Okay, go ahead. So if you were still scrolling through, I was going to go ahead and go. How much time do developers spend on a computer?

You guys want to guess an hour? Is this per week or what? Oh, gosh. You know, it doesn't say. I assume it was per day. No, it was per day. I remember that one. Per day?

I'm going to say 11 hours. Outlaw? I remember looking at that one, but I i don't remember i think it was in like the it was a range given it was given as a range if i remember right so it was like 9 to 12 or something like that yep okay yeah that makes so yeah 9 to 12 uh 52 percent of developers spend 9 to 12 hours a day at a computer yeah that's crazy but i i mean i totally do so yeah and and along that one too i thought this was interesting that um kind of we'll get to the survey results from the last one but uh you know healthy habits how often do you exercise right like we asked the same type of

question not worded the same way but i thought like oh that's that's uh interesting timing yeah i mean i'm sure we influenced their their course we did right right i mean surely they they're like stack overflow is not that big all right i mean how that one end up um i will save that conversation for uh later but um yeah there was another one here i was trying to get in here too like most dreaded framework or language most dreaded objective c there's a basic visual basic six really what about kobol number two okay yeah um i don't know what number one might be. JavaScript, it hit number one in all the categories. Wouldn't that be amazing? Well, here's one, though, because most dreaded framework,

we said that Angular was number two. Angular was number four for the most dreaded framework. But they're probably referring to version 1.x. Oh, that's funny. Yeah, man. Well, I mean, Stack Overflow didn't specify because also on that list was Node.js. Really?

Which Node.js was number one before. Yeah. Wow. I mean, it's fair. So JavaScript kind of is sprinkled in there. Most dreaded database? Mongo. Mongo and what did you say, Joe?

DB2. Yep, DB2. Really? Wow. And number two was Oracle. Oracle, really? Yeah. Awesome.

Yeah. What do you think the most popular IDE is? Stack Overflow. Know your audience. I know the answer. It's going to be Visual Studio. Visual Studio? Yeah. You're wrong to be Visual Studio. Visual Studio? Yeah.

You're wrong. Really? It was Visual Studio Code. Code. Yeah. But not by much. Visual Studio was number two, and it was close. Now, here's where it gets.

We've had this conversation before. Let's round out the top five. What do you think number three, number four, and number five were? These are going to be hard, right? Jet Brains, Jet Brains, Jet jet brains jet brains okay there's his answer sublime okay uh what's the is it adam the okay adam yeah sublime adam and vim okay well you did really good man you got two out of those three and i did not expect that. I did not see that coming. Sublime was number four. Okay. And Vim is number five. And we've had

this conversation about like, hey, is it just a text editor? Are these things just text editors or are they IDEs? They're in this IDE conversation. Notepad plus plus is the one you forgot at number three. That makes sense. I mean, it's a great little tool. I wouldn't call it an IDE, but, you know.

Wow. Where are the Java developers that aren't answering the survey? Like, what are they using? Well, IntelliJ was number six. It was on the list. And Android Studio was next. And Eclipse was. So your next three, so six, seven, and eight,

were all Java development platforms. Awesome. Okay. So they were there Java development platforms. Awesome. Okay. So they were there. All right. How about we've asked a question about multiple monitors? Oh, yeah. What do you think the stack overflow respondents?

60% yes. No, no, no. Do they have one, two, three, four, five monitors? I'm going to say two is the predominant. The norm? Yeah. 51% two. Yeah. Okay. Yeah. have one two three four or five monitors i'm going to say two's the the predominant the norm yeah 51 two yeah okay yeah what's the next one uh that's what i would think that yes one monitor was was definitely the uh the next one yeah there there were a bunch of interesting things on here though i don't what were the other ones that you were going to bring up joe uh most popular technologies uh what do you think the top three were for most popular on

stack overflow survey c sharp this could be language this could be javascript is definitely going to be a javascript javascript number one at 70 and there's there's overlap 70 yes but 70 i mean 70 of people said yes the javascript was multi-select. C Sharp. HTML and CSS were number two and three. Oh, really? Wow. So it's literally all web. It's almost predominantly web. Yeah, and it's funny to think.

If you're on Stack Overflow, you're probably a web developer, and you probably work with Microsoft and JavaScript. Yep. It's kind of interesting. Okay, I'm sorry. Go ahead. Oh, I just have one more all right what is it uh what do developers use to stay comfortable while working and this is another multi-select but i thought the numbers were were really uh interesting so 52 percent of respondents

said they had an ergonomic keyboard or mouse so okay higher than was 10 years ago five years ago i would say yeah 50 with sandy desk really that's a lot dude yeah because that's not a cheap investment right places yeah man yeah so i thought that was crazy like wow like where where's everybody working i need to go there no i am standing right now at my standing desk. That's awesome. Wrist hand support is 22% and fatigue relieving mat, which I also have 12%. Those are important. Those really are.

I even wear shoes on my mat. Yeah. What do you think the most popular way developers learn on their own is video video okay like getting started guides getting started the official documentation and or standards for the technology was number one wow Two was questions and answers on Stack Overflow. And then three were books from O'Reilly or other public... So video wasn't even in the top three. That's interesting. Yeah, no. I was actually kind of surprised by that one too.

So yeah. What about why do people participate? What do you think the number one answer people participate, why they participate in a hackathon? Networking. Nope. You're way down the list. That would actually be the fifth answer.

So it's actually to learn skills. Nope. That would be the number two answer. Come on. Number one answer. Prizes. No, that was actually the last place answer. Come on. You guys are all over the map here.

This is great. The seventh answer was actually the last place to answer. Come on. You guys are like all over the map here. This is great. That would have been like what, the seventh answer was for the prizes. I think Joe and I have said the same thing for every slot. I think he's just watching your mouth and he's like, what was he going to say? Number of prizes. Yeah, I don't know, man. No, the number one answer was because I find it enjoyable. Okay.

Yeah. Do things because you love it. That's fine. Yeah, yeah. it enjoyable okay yeah do things because you love it that's fine yeah yeah what do you think about like um how many developers are students is this a number of students right now percentage this is a percentage percentage of the respondents to the survey 12 12 are students 35 35 are students well um you're closer but you're still off dog on it uh developer students 74 were no so 26 yeah the remaining 26 ish percent were in the yes either full-time or part-time categories that's that's cool stuff

i'm gonna go check out that thing uh well uh if you guys have anything interesting that you find on there drop us a comment on the show notes because i mean it is fun stuff and and actually so all right i know jay-z's got something up next but mine flows well into this one so i'm going to steal this particular slot so So this kind of goes hand in hand with what we had talked about on the previous episode where like languages that are dying, you know, those types of things. And we got several comments on that particular thing that we spoke about on, on episode 76, like Joseph Keegan, Nicholas. So I think one thing to note, and we've mentioned this before, right? Like at no point are we

actually meaning any kind of dogging on any particular language. And to a certain degree, I do also believe that predicting which languages are going to die is sort of silly, right? Like I think it was Nicholas who actually said that this is silly. And I agree. It is interesting, though, to take a look at what the trends are in the market so that if you go to learn something, you know, what are the hottest ones? Right. Like, do you want to invest your time in something that may not be as marketable? Now that I think that's not silly, but predicting whether or not something's going to be around in a year or whatever, like it's hard to say. Right. I mean, it's almost like predicting whether or not your Bitcoin's going up or down today. So, you know, I wanted to say that just kind of to put it out there, like, you know, we talk about these things because we find these articles and it's just interesting stuff to talk

about. But by no means take that as a hit to, you know, if you're working in a company, you're doing great things with Haskell or whatever, right? Does that mean you should stop doing it if some survey out there said, hey, this is no longer relevant? No, man. That doesn't make sense. Just wanted to put it out there because I know people have gotten upset about us playing around with PHP or something like that in the past. And that's by no means what we intend to do. We're going to joke about it. We joke about C Sharp, right?

Well, not as much because we love it. Do we? I do. I mean, you got to diversify, right? It just makes sense. You think of it like an investment. So, it makes sense, no matter what language you're in,

to at least have some JavaScript on your resume. Apparently, 70% of developers are working with it. Man, that's amazing. So, that would be a good one. Yeah. But, I mean, especially if you're on this list, like, it doesn't mean it's a bad language. It doesn't mean it's right, whatever.

But it's something to consider, you know, for managing your career that, you know, you do want to make sure that you've got, like, something that you could pivot if you need to. Yeah. All right. So now back to yours, seeing as I leapfrogged you. Yeah, all good. This past weekend, I had the, the honor of hosting a productivity and tech roundtable. We got a couple of people on Zoom, which is what we're using right now. And we talked about differences between programmers and management and

what it meant for programmers who want to move to management or maybe why programmers don't want to go into management. So it was a really interesting talk. We had Will from Complete Developer, also Darren, we talked about several times, of course, hosts the show. So if you're

interested in that topic then you should go check out this youtube video we'll have a link in the show notes awesome man i wish i made that it was just kind of at an inconvenient time on saturday because i would have loved to have been a part of that topic what were you what were you doing uh the week before man come on i was a little bit busy right uh out at the uh microsoft mvp summit which basically just drained you of, it's an amazing time. You meet some awesome people. By the way, if anybody knows Brandon Sargent,

you know, seek him out or Brandon Padgett. I'm sorry, not Sargent. Brandon Padgett, seek him out and ask him to show you some yo-yo tricks. Like, it's amazing. We had great conversation, but dude, like I was like a little kid watching him. So, but yeah, I mean, just an awesome time and drinking through a fire hose of information,

but coming back and losing three hours from Seattle to the East coast and then getting kicked in the teeth with daylight savings time has been a little rough, but you know, it was, it was an awesome week and we might have a tip or two in the, in the tip section here that kind of came from some of that information so hang around all right and uh can you guys hear my mouse by the way i know it's been kind of loud lately is there anything i can do about that oh man so check the suggestions for me all right so check this out guys if this came up because outlaw was like man in the previous episode your mouse was just like a shotgun going off right i mean i didn't sound like that he might

have said that hey man your mouse is like really loud hey i don't have that much space in my voice all right so at my house like i i literally have my pc in front of me and then right next to me is my wife's gaming pc slash whatever. Right. And my kids will want to play arc. And if you know anything about arc or any game that a kid plays, it's literally, they just want to keep biting and shooting and hitting things. Right. And so they just click, click, click, click, click. And I literally almost lost my mind one day. And I was like, there's gotta be such a thing as a silent mouse. And sure enough, there is. So I ended up buying one. I'll have a link to the amazon

thing i think it's like 16 bucks or 17 bucks it's not 20 bucks all right so maybe it went up since um but man oh i can't even hear it it is blissful it's right next to me i know they're clicking into the thousand times per minute and i don't hear it And it is the most amazing feeling on the planet not to hear that thing. So it looks cool too. Yeah. The shape of it isn't great. I don't like anytime I've used it. It doesn't, I don't know. It doesn't feel substantial, but it serves its purpose. So, you know, if you want a silent mouse, I've got, I've got a link for you. Oh, the promotional pictures got like a guy and a laptop in bed next to his spouse and he's here clicking away. Yeah, I don't know if I'd do that.

Where are you looking at, honey? Oh, nothing. I thought this was quiet. Go to sleep. This is the last episode, for reals, about clean architecture. This is your last chance probably for a while to, uh, leave comment on the episode and when that particular book. So we'll probably be doing cool stuff in the future. I don't know.

Stay tuned. But if you want to win a picture of a picture, a copy of, um, clean architecture and that's international too. You guys are awesome. Yep. And,

uh, yeah, just leave a comment and we will pick one and we will email you a picture of the book yeah so be prepared so i mean i'm extra awkward tonight and by the way we've mentioned this before if you do have anything like if you're you know pining for that pro site subscription or you have any books that you're interested in go check out our coding blocks.net slash resources we put things up there that we personally really like and use. And if you are planning on buying any of that stuff, you know,

please click those links on that page. It won't cost you any more. In some cases, it might actually save you money, and you'll be helping support the show. So, you know, thank you for that. And with that, it's time to start. Yeah. Yep. So let's get started with services, great and small. So there's this little buzzword out there about, you know, well, there's a couple of them,

service-oriented architectures and microservices, right? And they're all the rave, right? Or I think we've talked about how like maybe there's the backlash now on the microservice architecture. Yeah, and you'll typically see this thing listed as like SOA for service-oriented architecture. And I don't know, is there an acronym for the microservices? I don't know that I've ever seen that thing abbreviated. Yeah, but it's really small, so you can't see it.

Great point. So, yeah, man, there's definitely a backlash, right? Like at one point it was, hey, microservice all the things. And it's like, wait a second, this's definitely a backlash, right? Like at one point it was, hey, microservice all the things. And it's like, wait a second, this makes everything really hard. So back off that. Let's go mono again. And, you know, there's probably a balance somewhere in between. In fact, I feel like there was a talk given along those times.

I'll have to find it now. Where like Uber, didn't they have a talk where they went completely microservice with everything this was a few years back oh i don't know spotify weren't they the one everyone always talks about okay well oh did they go microservice and then backed off of it oh no they didn't do the back off they just wrote a big article about kind of splitting their teams up and organizing organizing around services. Actually, I found it. The title was, and it is Uber, What I Wish I Had Known Before Scaling Uber to 1,000 Services.

Ouch. We'll include a link to that. That would be painful for anybody. In the show notes. So I definitely think that if your company or your organization or a programmer is telling me about their organization and they mention that they've got microservices i just naturally kind of assume that that means that there's been someone who's been kind of steering that and thinking about architecture at a high level and that to me or as well i'm reading

this chapter it made me kind of realize that I have this kind of bias of thinking like, oh, well, if you're microservicing, then you've put a lot of thought into your architecture and you're probably splitting stuff off. Well, you've done a really good job and you've handled the deployment issues and your DevOps and you've really got your stuff together. After reading that chapter, he kind of makes a distinction

and says, you know, basically services and particularly microservices don't mean that you have any sort of architecture right which i thought was awesome it was a great call out because you have a bunch of services they must be decoupled right right yes that's i guess that's one of the uh the fallacies of that kind of thinking is that you think of services and micro architecture or microservices and service-oriented architectures you think of these things as being strongly decoupled and that you can develop them and deploy them independently of one another or of their

you know quote users yep but then you actually take a step back and you say, are these things truly decoupled? Like if I, if I release my new, if I release an update to my microservice, does it have any impact downstream? Like I added a new field to mine or something like that. All of a sudden you start realizing these things are way more coupled than what you thought they were because now you can't independently deploy this thing because it's going to break everything downstream of it, right right like all these other services that were depending on that thing it now has a different set of data types that are coming in and it's like well i don't know what to do with this i mean the only thing i could think of is if you have like a if

you're a truly large service you know if you're a provider of some service and it's truly large like massively at scale like a google or a Facebook or something like that, and you might have versions of your service running concurrently, then I could see the argument where it's like, oh no, I can have multiple versions of my service running and everything, and it's not going to be a problem. But for the average company, because going back even to the Stack Overflow survey, when they talked about the size of the companies, right, like most people were in companies

larger, less than 100 people, right? That was the largest category, you know, that the respondents picked, highest percentage. So, you know, most of us aren't working in an organization where we're supporting thousands upon thousands upon thousands of users where we might be doing that. Realistically, are you going to have multiple versions of your service in use? Maybe not so much. So then you get into what you're saying where like, hey, I added a new field or we needed to deprecate the use of a field.

Yeah, I think that microservices are definitely a solution to certain problems but it's not the default answer for organization by by any means so yeah i think you need to justify that decision before you make it and we actually had some really good advice from uncle bob in an earlier chapter where he said don't start out with microservices start you Start out and build your stuff as if they've got nice boundaries and services and manage your dependencies and work towards the interface so that you can split things off if you need to. So don't shut that door, but you don't have to dive into it immediately. And actually, I got to start a really great talk from Facundo,

which I'm going to be checking out here at Orlando CodeCamp again. He's a developer here in Orlando who does some consulting and he's done a lot of moving companies to microservices or moving away from or helping them get them to the cloud, just working with microservices. He had a really great talk on some kind of QA around it and he definitely wasn't pushing it. You know, he was, he took a very practical approach and really liked it.

So I'm hoping to find a link and I'll throw that in the show notes if I can find one for that talk. But I thought it was really good. It kind of changed my thinking on microservices. And so I think if you can build your app, if you can, I don't want to say monolith, you know, because that kind of implies things I don't mean here. But if you can build your app, if you can, I don't want to say monolith, you know, because that kind of implies things I don't mean here.

But if you can build your applications such that they have these nice clean boundaries and layers, then you're leaving yourself open to future expansion. But you're not forcing that upon anyone. Yeah. Yeah. So basically, this is kind of goes back to I think we had this conversation before where he's like, services are not an architecture. There was a similar conversation from several chapters back where it was something along those same kind of lines. I can't recall it exactly,

but any services that separate these application behavior, that do nothing more than separate these application behaviors are just expensive function calls. Isn't that beautiful? You're just adding latency for the sake of it, but it, you know, you're not necessarily improving your architecture. Latency and complexity, right? Because now these things all have to be managed and deployed.

And did this thing die? Does it need to fail over to another version of it? Like there's, I mean, when you really start thinking through it and how you have to, to keep these things alive and all in good health, man, it's not a small problem to solve. Yeah, I think a lot of organizations put off the actual deployment of it until kind of near the end. They don't really think about it until things are getting ready to launch like a version 2 or a new project or something.

I definitely think that some of the problems that you encounter with microservices can be kind of solved, or at least you can recognize them early on by getting a nice CI pipeline going and deploying these things and make sure that it makes sense to deploy them independently. And you're not just always having to push all these things up at all at once because they're actually totally tightly bound to each other. You just got a really complicated monolith. Now, he does make the point though to call out that just because you might want to break these things up into services it doesn't mean that necessarily every service has to be architecturally significant and that you know it needs to be strongly decoupled or anything like that like you know sometimes you you could break those

things apart into services and that doesn't necessarily make it wrong or bad. Right, right. Just like if you have a function that's dependent on something else, it doesn't, again, he drew the parallel there, you know, not everything's going to be perfect and you do have to make trade-offs for, you know, time versus productivity versus, you know, whatever else you got to do for maintaining the thing. Yeah, I mean, he calls that like, you know, even if you're breaking the dependency rule here, sometimes there are benefits to this where having that functionality separated out might benefit your particular use. Maybe it's a scale problem. Maybe breaking that one piece out, you can now horizontally

scale that one service, which for whatever problem you're trying to solve might help even though you're still strongly coupled to it, right? Maybe you didn't do it in like the most, you know, quote, ideal way. Yeah. And if you remember the dependency rule, it was that source code dependencies can only point inwards. And it's really important, not only is inwards, inwards, and not outwards, but also means not to the side, right? So that means these services shouldn't be calling each other because then they're tightly bound to each other. They need to be going through a layer of indirection.

And an example to kind of bring this to the real world for what they just said was when they don't, the benefits might be horizontal scaling, right? So let's say that you have just, for instance, a database behind the scenes that can take, you know, thousands of transactions per second. That's not a problem. But let's say that you have a web server that sort of maxes out at a thousand transactions

per second, but you need more of these things coming in, right? It might make sense to break that service across multiple boxes that could then take in, you know, multiple thousands of those requests, right? So that's a case to where, you know, I mean, you could make multiple thousands of those requests, right? So that's a case to where, you know, I mean, you can make up all kinds of things, but like credit card processing, right? You don't want to be bottlenecked by a particular server if you have to handle a high amount of transactions. So it might make sense to break apart that one service from your application so they can take in as many of those things as possible, right? And then maybe queue it up and

add it to the database or something. So that's sort of an example of when that might matter, even though you don't care about drawing these specific boundaries, you just need something that will scale, right? Yep. And I really like on the next section here talking about the benefits of services, and there are plenty of benefits of services, but decoupling is not one of them. And I's that's one that we kind of like instantly go to but there are others you

know like being able to independently scale or deploy or whatever but if these services are calling each other and they're absolutely coupled just like your code can be coupled it is funny because like you said when you hear microservices or service oriented architectures you just automatically assume oh well they you know they architected this thing to be just amazing and all separate and independently runnable. And that's not the case, typically. Yeah, I almost think like I meet somebody and they're like, oh, yeah, we do use microservices. I'm like, oh my gosh, do you work at Google? Right? Or Amazon, AWS? Yeah, exactly. Let me ask you guys this. When you think of using microservices,

what is your thinking behind it? Why you would want that? Why that was needed? I'm curious if your go-to answer is the same as mine. Mine? Or thought. Go ahead, Joe. What's yours?

For me, it's being able to independently release and independently scale, but primarily just the ability to release one part without having to release the others. So if you've got these things tightly bound, then to me, you've lost the primary benefit, at least from my understanding. So mine would be reliability. Mine's so I know most people would think that I would think scale. But mine is more along the lines of you have two of these things standing up. So if one fails, it can, you can easily swap over to the other one.

Like I would think that reliability would be the primary benefit and scale would probably be next. So scale reliability in Joe's was what again? Independent deployability. Independent deployability. Yeah. Or being able to work at things in kind of parallel and like being able to release things and,

you know, like updating the version number but not necessarily affecting any existing behavior. You're basically treating your services like third parties. Right. That is not, like neither of you were thinking, it's interesting how the three of us each

had a different takeaway. Mine is just that if I think that there's a need for microservices because you have some idea that you might want to reuse that by other applications. So you're thinking like an external API? I'm thinking of it as like it's part of an external API, yeah. Okay.

So I was just curious, you know, a little, little side tangent topic there. Yeah, that's cool. Yeah. That's really interesting. Yeah. I'm looking at a list here and like all our stuff is in there in the top,

whatever this, this article has like 30 different pros for it though. So I'm not going to get into that. Yeah. There's a few, but yeah, we hit the high points. Yeah.

And we talked about just a minute ago, like they are tightly bound because of the data they share, right? If you typically, you don't have just some central app that calls out to a service and then it gets something back and calls out to another service. Typically, it's almost like a waterfall effect, right? Like you call service A and then it's going to call service B and then it's going to call service C.

And that's how you end up. That's how they all become tightly bound because they are all aware of each other to some certain degree and the data inputs and outputs that they have to publish. So an example might be, and I'm thinking off the top of my head, so maybe this would be a messed up example. But if you wanted to do some kind of an authentication, right, then maybe your first iteration, you're like, you know what, I only need you to pass in a username and a password, and I will verify from there.

But then on a subsequent one, you might think, you know what? We've changed the way we handle our encryption, and so we don't want the salt necessarily right next to the encrypted version, so you're going to pass me in your salt as well. That's probably a really messed up... Anybody who knows encryption is probably like, what? You don't pass your salt around, but whatever. Yeah, I'm thinking the point is you would pass in

now suddenly you need to pass in a third thing. You're like, hey, we have to deprecate the use of that other one because we've changed the way we're handling the encryption or something like that. What if you went two-factor? Okay, two-factor. I like that one better. Multi-factor.

You have to pass in the multi-factor authentication code as part of the authentication at the time, right? Because you've changed that strategy, now any applications that were using the old authentication service now have to know, they have to be updated at the same time

and released at the same time as this new authentication service. So the deployability and the developability are both impacted by that service. Yeah, you can't just release that thing, assuming that you don't just release that thing, assuming that you don't just create a V2 of it, right? Or something like that. But you can't just say, all right, well, I'm updating the authentication service because that will now bust everything else.

Well, you're saying the V2 though, that means that now assumes that you have concurrently two versions of the service running. Right, that's what I'm saying. Let's not assume that. Yeah, and maybe that might not be an option for your particular organization, right? currently two versions of the service running. Right. That's what I'm saying. Let's not assume that. Yeah. And maybe that might not be an option for your particular organization, right? You might not have the option of running two versions of the service because maybe in the

background, there might be like schema changes that are forced on the first version of the service that's like, I can't allow this version anymore. That database doesn't exist that way or whatever. Maybe the way you were storing the passwords, for example, maybe you didn't have them encrypted good enough. And so you've had to force, maybe because of some government regulation, like a HIPAA regulation or something like that, you have to absolutely do away with the old way that you were doing the

password so you've like gone and deleted from that and you know you force all your users to change their password they have to go through the new version of the service so it's not an option to run the new both and i do like the having the ability with microservices to be able to spin those up those two different versions of other times i definitely think it's a benefit to be able to do that and then it buys you flexibility on like how to upgrade stuff but yeah it may not be an option which and that's another point like if you've only got three servers or one server you know microservicing it's just another you know it's it's a premature optimization yep and we touched on some of these other things but one of the things that they say here is service interfaces

are not any more formal rigorous rigorous, or defined than functions. And that's interesting, right? Like when you think about that, still, if it changes, everything else has to change, right? Yeah, and I've definitely been on the receiving end and also the giving end of making changes to services. Oh, I forgot to tell you. It's not a string anymore. Oops. Yeah, I've definitely been on the receiving end of some bad documentation related to services too.

Oh, man. So I would have much rather have had a function that I could go reading rather than bad documentation that leads me down the wrong road. Right. They start talking about here the independent, what Joe's thought of a service was, was the independent development and deployment.

And they say that it's been proven that large enterprise systems can exist in the form of a monolith. Services-based or component-based doesn't really matter. It can all be one, right? As a matter of fact, there was a, I want to say it might have been a Software Engineering Daily or Software Engineering Radio podcast episode a while back where they had on the the the guy who created uh base camp i think is the name of it it's a it's a

ruby on rails thing and david hansel hireman and and he was like yeah man ours runs as a monolith and we have you know i forget how many users ridiculous i remember you talking about this yeah it was amazing like the dude's like look man we have a monolith, I forget how many users ridiculous. And Marie talking about this. Yeah. It was amazing. Like the dude's like, look, man, we have a monolith and he's like, hardware is cheap. Add more of it. Right. Trying to scale this thing out in software is going to be a super

expensive engineering problem. And he's like, and ours runs fine. Right. Like we've, we've never really had a problem. So it is interesting. It's not saying that everybody should go monolith, but it does make you at least step back and say, do we need this? Need is a very important word. Yeah. I mean, I have been in some places where microservices were employed and it does kind of

make you question, is this a micro optimization that we're making before we know that we need it? Yeah. I mean, we said architecture is all about deferring those sort of implementation details and this is definitely an implementation detail so why start there yeah okay and i did find the link i'll share this in the in the show notes it was software engineering radio episode 261 and his name is david heinemeier and yeah he talks yeah and he talks about the state of Rails monoliths and all that stuff. So it was a really interesting episode. He's a great person to follow on Twitter too. He is not afraid of saying controversial things.

Awesome. Uncle Bob says that because these services are tightly bound to the data that they ingest or output, they are still tightly coupled to their dependencies and their deployments must still be coordinated with those external systems. Here's a downside that wasn't mentioned, though, is that if it was just a function, have compile time checking you know error compile

time errors versus runtime errors and we've talked about the benefits of you know prefer compile time error over runtime error they're a whole lot easier to handle because you know about them yeah what's wrong with your kitty tell me about your kitty problem what you gotta do all right so i don't know if you guys remember way back, you know, a couple months ago, we talked about a taxi service as an example of an application. And you've got a user who could basically say, hey, I need a taxi. And your app would be in charge of dealing with the various companies and making sure that your qualifications as a rider are met. Like, you know, it's maybe a certain certain price or certain quality of cab or some such and it would go out find the cab and get it to you and we had like a little sample app that

we worked on well in the meantime in those last couple months marketing came back to those those programmers and said hey you know what in addition to all that other stuff we also want to start delivering kitties around the city and because of that we need to be aware of other people's allergies particularly the drivers also anyone any cab that has delivered a kitty needs to take a couple days off before letting one ride in it just in case and so they basically uh they do what pm does right they um they took things in a direction that would have been difficult to predict ahead of time. And what did that do to our functional decomposition? Somebody else. So, yeah, I mean, that was the thing is all of a sudden you had this simple, you know,

pick up somebody and deliver them from one place to another as a taxi service. And now you have all these additional rules, like, you know, can the cat go with this person? Can the cat be taken to this location? All this kind of stuff. If all that was in some sort of microservice architecture, how much of that stuff would have to change? Probably all of it, right? Like every bit of it. So that architecture that you used, quote unquote, at the time that you created that thing originally, it doesn't support these new use cases. And so you got to redo it all anyways. Right. This is a cross-cutting concern of, you know, fundamentally to how this service is going to work. What was once just a taxi service is now a, also a

kitten delivery service, right? That's a cross-cutting concern that impacts the entire application. So everything is going to be affected. And you know the funny part is, I think the last time we mentioned this, we're going to call it a vocabulary term, which by the way, Joe Zach, didn't you create a GitHub vocabulary thing for cutting blocks? Like we need to start updating this thing. Yeah, Joe, of course, Joe had a great idea and said, hey, why don't you put up some of the vocab?

Yeah, he really does. Joe, you're awesome. And anyway, I made a little GitHub page. It's really scant right now, but hey, you could totally fork it and add stuff to it. So I'm going to take a little note here to add cross-cutting concerns. Because I always think of logging or something else.

It was interesting to see a functional requirement considered cross-cutting because because i always think of like logging or something else it was interesting to see like a functional requirement considered cross cross-cutting because it really does have effects on ui i mean every single layer of the diagram we won't go over the diagram but every single component was like oh yep that needs to change because this and that needs to change because of that yeah so cross-cutting concerns for anybody that's not aware that's basically something that that that touches like all different parts of your application, right? It could be, it's easy to say logging because typically you want to log things if there's errors or warnings or whatever.

So that's an easy one that you kind of want everywhere. A lot of times there's retries and that kind of stuff. So yeah, cross-cutting concerns is a good vocabulary for anybody who's not heard of it. And functional decompositions. Yep. And so he says know care needs to be taken so that these new features don't cut across all of your services yeah so how the heck do you do that and i feel like that that's kind of been what the whole book has been about it's like well how do you do that what you do is you create a bunch of

interfaces to interact between these different parts of our application and then we can side load this jar or dll or library or service whatever and then we can inject this logic into various other places by basically configuring our current application our current services to go through that and to incorporate the pieces as needed. So it's writing our own logic for this specific problem and then kind of configuring it into the flow and utilizing tools like dependency injection and configuration management to make it all work. And by the way, this is something that is going like we're not even going to try and describe how he broke it down and change it in the book because like he's got pages of diagrams to where he's re architecting, reconfiguring these boundaries and

all that kind of stuff. So like, this is literally one of those things that if you want to be able to follow along with this one, you'll need the book. So again, if you want your chance to win it, you know, leave a comment here, but this, this is where having the book can add some value to, to some of these conversations and before reading this i was like as soon as i heard the problem was like well you know yeah you had to change everything and then kind of reading the explanation of how they kind of broke it about and how they kind of made it happen it's like oh crap that's pretty good but i still kind of i'm like my mind is boggling because if say you know the next day like hey we're now we're

a parrot delivery service too i think like okay now we're going to need to sideload the parrot stuff and then we're going to have to configure this stuff and kind of pile it on top of the kit like how do you do that without having the bird stuff aware of the kitty stuff aware of the driver you know it's my mind is still kind of melting over that um but i'm gonna take his word for it and that's not an easy problem right and that's one of those things, like, I think he said, it might have been our last episode where he was talking about, don't try and guess everything up front, right? Like, if something like this comes along, yes, take a step back and look at all of it because architecture is an iterative approach. So don't try and figure out all this stuff to make it the most flexible system on the planet when you started out delivering people, right? When this next requirement comes up that kind of blows up your whole world, at that point, say, all right, well, where can I draw these boundaries?

Where are the things that are in common? Where are the things that aren't? And then go from there. So like, you know, your next step, you'd probably do the same thing. You back up, you try and draw it out like on a sheet of paper of all things and say hey where can i draw these lines well i think it was also mentioned too in like the last episode that those pain points those those those points of friction uh are going to be the ones that you're going to re-evaluate right you know um because you're not going to like take a look at it you

know all up front you're not going to like break it apart into all of its individual granules you'll you'll do a little here a little there and you know each time you you iterate on it again it's going to be on like what's the next pain point and i will say like going to a real life use case of this thing if you find yourself start writing a bunch of if else statements we've used this in in in payment processing before because it's a pain that we've all felt. If you start seeing yourself doing if PayPal than this, if credit card, if this, if other payment instrument than this, then you really, really need to take a step back and think about how do I abstract this better? Yeah, same with switch statements and same kind of thing. Yep. Switch, if else, any of that kind of stuff where you start really complicating your code

and really introducing a lot of potential maintenance problems and just bugs because you have all these if-else statements, that's when you need to think about how do I break this down to where it's just something that can be plugged in, right? If you can train your mind to think of how can I plug this in and it work, then you've taken a step in the right direction. Well, here's something that some might consider controversial. If I remember clean code correctly, Uncle Bob said that your switch statements should only be used in factories.

Yes, he did. That's the only time you're allowed to use a switch statement. Yep. switch statement. So getting back onto the topic here about the cross-cutting concerns, he says that these architectural boundaries don't run between the services, but rather through them. So this is kind of, you know, at first like that statement, I'm like, wait, what? What does that mean? But this is kind of building on what Joe was talking about with, you know, using solid principles and interfaces between these things to, you know, as to like, well, how do you fix this problem? Right. And that's what he's trying to get at here is that, you know, the, these interfaces are what's going to run through the different, you know, from the service and the user of the service.

Yep. And we got the dependency rule coming up again which is saying that the dependencies need to point inward to uh higher or lower layers depending on the diagram you're looking at the easiest way to remember it is your applications business logic is the innermost circle right so that's everything should be pointing towards that the top of the ziggurat or the cone yes awesome diagram yes see the architecture is defined by the boundaries within the system and the dependencies that cross those boundaries yeah it's not defined by the physical mechanisms of how the code communicates and runs. That's so important.

Don't think about the underlying storage. Don't think about the communication channels. Don't think about that stuff. It's literally how they interact. Yeah. Your architecture, here's another one too. Like if you were to go to like a conference, you know, and you were to ask somebody like, hey, what's your architecture?

You know, you might often hear people refer to the tech stack. Yeah, definitely. Not the architecture. Definitely. I definitely feel like microservices was a common answer for the organizations that are using microservices. Like, hey, which architecture? Like, microservices, everything. Right.

But how do you... Next is the language. Okay, so backing up then, if somebody asks you about the architecture of your system, what do you say? Because that's typically your go-to. It's microservices or I have three tiers or whatever. Like everything we've talked about in this book over the past, what, three months,

it is not, it's not got anything to do with the technical nitty-gritty hardware, none of that. It's literally drawing lines between between functional components i keep in my wallet a folded up diagram of of all the functionality and objects within uh you know and so i can physically show like here are the lines between my apple this is what my architecture looks like these little bubbles over here they communicate through here so so when somebody asks you like you hold like, hold, hold please. Right. You pull that wallet out.

You unfold that thing. You uncrinkle it, lay it on the floor, and you're like, bam. It takes me a little bit. It takes me a minute. There it is. Yeah. You can see how a database-focused person might generate a schema diagram when asked about the architecture. I think what he's getting at is the answer should be,

like in the taxi kitty example, it should be, well, we've got a user interface that takes input from a user and it goes out to a taxi dispatcher. And we've got a couple of rules there and it goes out and it figures out based on those rules, which taxi services are eligible to send a car. We go ahead and get that scheduled for the user who pays us somehow and we have abstractions here and you know just it's definitely more of a technical software talk than it is a

oh we have three tiers it's pretty interesting i almost just described the business not the right the app actual application it's because those things have gotten to be really close. And if we go way back, the whole purpose of software is to enable the business to automate and do things. Make money. Yeah, in a computing way. It's about the business. The only value you really have is what you're adding to the business through your application. So then your short answer is, if somebody asks you what the architecture is at your job, then you should either describe your business or say something short like, our architecture is designed to support the business.

Or after reading this book, you just say, oh, we have a clean architecture. Don't lie. Okay. Well, I mean, I'm assuming our listeners probably have clean architecture. And that's what I'm assuming. That's why they're all listening right now. I mean, you want to sound good, so clean architecture. And that's what I'm assuming. That's why they're all listening right now. Yeah, I mean, you want to sound good. So don't tell them the truth.

That's right. But, you know, like an e-commerce site, you might say something like, well, we've got a website front end where users can place orders through a queue that gets picked up and processed by processing. And then accounting does this. And I mean, you really are describing the business and just like we said when we first started out on this journey with this book we want the scope to max to match the structure and what we meant by that was the actual business need and what the code looks should be like a reflection and the closer that reflection is to being accurate to like both sides you know match like looking in a mirror then the less strife there's going to be between the two and the easier it's going to be to

change things because remember that was the big problem business said we want a checkbox that a checkbox that you know undoes your entire world like well we can't do that because that's actually a big change for us because even though it seems like something little for you are the way we've written these rules doesn't line up with the way you think about these rules. And that's what we're trying to fix with clean architecture. Hey, before we go into the resources,

there was a really good, and I want to find who did it. There was a really good comment from, oh man, it was an episode discussion on this podcast. And it was from, I cannot find it. Doggone it. Man, I hate that.

At any rate, it was brought up. We had mentioned in the last episode this whole thing about, what was it? Partial decoupling or partial boundaries. Partial decoupling or partial boundaries, partial boundaries. So what we said is, you know, in a fully implemented boundary, you might have your interfaces in a separate project, separate jar, separate whatever, right. Or assembly that both sides that are going to use that thing will implement. Right. And the discussion was, well, if you go the partial boundary route, then you might skip breaking that thing out into its own assembly or jar or whatever.

And then that way, you don't have as many things to manage when you're deploying, right? So you might bundle it in with a particular layer, we'll say, or a particular component, I think is how it was put. And man, it drives me crazy that I can't find them because it won't scroll back far enough right now. But the thing that was said was, well, why not just put it in the application layer? Because that's your most central, so things can use it. And I wanted to reply to that because it's a really good statement. If you don't have that many layers outside of that, then maybe that's fine, right?

Maybe, maybe you make things depend on that interface in there. The only problem I see with that is, and I tried to reply in the thing and I, and it's hard to describe this stuff, just, you know, writing back about thoughts, right? But what I was saying is, if that application tier doesn't actually implement that interface, then it doesn't make sense to put it there. You know what I'm saying? So, so for instance, if you put the interface in there, because you want everything

to be looking in, and basically anything can look in there and say, implement the interfaces in this particular application component. Well, if that application component isn't using that interface in any way, shape, or form, then you're probably putting it in the wrong place because now it's just sort of a dumping ground. There's no cohesion there. There's nothing that says this application tier belongs to this interface. So I want to redefine how you described partial versus fully. Okay. Because I think it might help clear this up a little bit. Okay. Is that from what I recall, and you tell me if I can be way off base,

but a fully implemented boundary was where everything was in its own separate component, separately deployed component, right? A partially one is you, it's all deployed together, but maybe in the source code code it's broken out into separate projects so that later it could be broken out and independent so what you're describing is like you might still have that other project for that interface right and other projects that want it might reference that interface either for implementing a version of that interface or just, hey, I want a instance of this interface.

But it would still be in its own thing and not in some other project that has nothing to do with it. Right. And that's really the key, right? So whatever abstraction, and we say interface because it it's easy to just, you know, think about things that polymorph to that. It could be an abstract class, whatever. But what I'm saying is that thing should at least be where it's being used, right? Or where it's being implemented, because it doesn't make sense to say, hey, put everything in the application tier, just because you know, everything's going to be pointed in that way, right? If there's no implementation at that level of that particular interface or that abstract class or whatever it is, then that's probably not the right place to put it.

Bring it out to where it is being used by whatever's on both sides of it. So, Joe, I see you sort of looking. Does that make sense yeah i was just thinking like by putting in the core then you're kind of applying that this is kind of like a core feature a core part of the system but if it's you know you've got the interface there but the functionality is really not it's really one of these lower layers and you're kind of lying to your users or you're right slating and that's what i was getting at. This isn't a part of your core logic. Yeah, and again, I mean, it's easy to talk about these things in hypotheticals, but you'd probably see it. Like if you ever saw some sort of class that's buried in your application

and nothing's really using it there, then you probably need to figure out where that thing should actually live. Because you don't want to just say, hey, what's the innermost here? Put everything here because I know everything can use it right that just doesn't make sense so yeah yeah that makes sense to me i'm on board all right so with that um if you haven't already left us a review we would greatly greatly appreciate it if you would puts a huge smile on our face uh you can head to www.codingblocks.net slash review and you can find some helpful links there to some of the main uh aggregators but uh i think we've said it before like i don't care how

many reviews we have every new one that i read is a smile. I enjoy reading every one of them. So don't think that you're too late to leave yours. It'll still mean just as much to us as the first one. Definitely. And by the way, I want to give credit where credit was due. It was not in the episode discussion channel. It was in the podcast chat and it was henry cogan who left that message it was reached aloft and a great great point so thanks for for sharing those thoughts in there which is also a great segue into like if you haven't joined this slack wait wait wait oh what were you saying i had another segue all right but i was just saying don't forget that we're sending out free stickers if you send a review. So you don't need to go back and screenshot anything.

Like we're doing honor system here. But if you have left a review in the past, and we really appreciate it, we want to send you stickers. So go ahead and shoot us a message or an email or something, and we'll hook you up, especially if you're international. Yeah. you up even if you're uh especially if you're international yeah and uh you know if you haven't already um joined the slack community you really should um so you can hit us up there at uh codingblocks.net slash slack if if you haven't already joined i was actually telling arlene earlier today that believe it or not slag is actually the best way to contact me because i get the whole notification number like email definitely not twitter like not you know not so much like we all kind of

check it sometimes so that those notifications kind of get lost but uh slack i will eventually see it and i'm still not very good at that though but But you do get a little ding on your phone, on your computer, all three of them. Yeah, but email works too. So whatever you're comfortable with, we're there. Go ahead and contact us about those stickers. We'll hook you up. I know email too gets a lot of spam and notifications and stuff. So Slack is preferred, but we'll hook it up.

Definitely. All right. So let's get into my favorite portion of the episode. Survey says... Outlaw family, step on up. Right? I would try to sing the music right now, but it would come out horribly wrong. Dun-dun-dun. Dun-dun-dun-dun-dun. Yes. right i would try to sing the music right now but it would come out horribly wrong okay there i did it for you we haven't sang in a while so we have you did that with the creepy host although now it's steve harvey so that's not so much creepy it's just hilarious

yeah right he's kind of mean isn't he man don't be the person that's... Have you seen some of the people on there, though? Yeah, true. Mommy. Yeah, that was different than mommy. Okay, so I mentioned earlier that there was some similarity between our recent survey and some other site's recent survey. In the last episode, we asked, when you're not coding for work or school in your free time, do you eat, sleep, code, repeat coding is all that matters. Or you gotta be well-rounded, get outside, ride a bike, climb a mountain, hike a trail or netflix gotta binge watch everything or rocket league or insert favorite

video game title here i feel like that should have been call of duty seeing as how that's what we used to talk about all the time used to be man times have changed haven't they no man i love some call of duty no really man on xbox one i used to love it man i don't even know what happened like somehow it just it was literally like a light switch like years of call of duty and just finally i was like i'm done well that was me last year last year i didn't play it and then this year i just i had the itch and i was like i i need this in my life i don't know how much came out and i was like oh this is different and new and also good like what else is out there? I did see that they already have announced the pre-order for Black Ops 4, and I did get a little excited when I saw that.

I can't lie. I was like, oh, yes. So, I don't know, man. All right, sorry for derailing us. All right, so let's go Joe first. Which one do you think is the most popular? Coding is all that matters. Get outside Netflix or Rocket League.

This is tough. Um, if it was, it was a multi-select, it would definitely be Netflix. Cause like everybody has Netflix, right? I would say, Oh, you know, a large percentage of people. And, uh, Oh, geez, this is tough. I'm going to say, I'm going to say Netflix with, netflix with uh 37 wow you went high nice i did i think i'm going low on this one i'm going to go man this one is hard because honestly i could see every one of these being like 25 of the vote i'm gonna go rocket league because i think we got some

gamers yeah i want to say rocket league and we're not talking about the percentage of time they do doing this we're just talking about the percentage of people you have free time and this is your go to way to spend that free time i'm going to give this 20 20 rocket league okay well done all right 20 rocket league and 37 netflix and survey says you're both wrong. Oh man. Don't tell me people are lying. They said they get outside. I don't believe it. Yep.

Get outside is the number one answer with 43% of the vote. Man, that's awesome. I get for you. That's, I would have never guessed that high. And I think that's awesome. That's what I'd hoped everybody would say.

Yep. Now you, you had number two, Alan. Okay. Rocket league or, or any kind of gaming was definitely uh you know 20 that was number two how far was it though was it truly 20 uh no it was like almost 21 oh i was really close how about that all right yeah had that been the most popular answer you

would have definitely won by prices right nice um and then yeah netflix was actually last last place yeah i would have said rocket league but my subs keep getting destroyed in subnautica so i gotta get back to it glanks uh hooked me up he threw out a little time capsule so i gotta go find it but yeah i'm always puttering out with something yeah i mean it was kind of interesting comparing our results with the Stack Overflow results because they worded theirs as like, well, how often do you exercise, right? They didn't give it a choice of like, hey, do you exercise or do you just Netflix or Rocket League? Right. Because basically, like, Eat Sleep Code Repeat, Netflix and Rocket League, for example, could all be done in front of your computer.

Yep. In fact, you could do those maybe even somewhat concurrently. I don't know about all three of them. There's definitely two of them you could definitely do. Yeah. So theirs was just how often do you exercise, period. The choices were I don't typically exercise one to two times a week, three to four times a week, three to four times a week or daily or almost daily care to take a stab at what you think those were two to three,

two to three. Wait, no, that wasn't a choice. It was one to two or three to four. Hmm. One to two, one to two is the number one.

Yeah. Care to put a percent on it. 27, 27. Joe, one to two, 60 60 one to two no way no i don't typically exercise was 37.4 ouch percent one to two was the number two choice at 29 man i'm really close yeah yeah so i will say for me like this these answers here it's cyclic like i'll literally find myself for weeks at a time all i do is code all day right yeah and then i'll be like i gotta get out and i gotta get some exercise i need some physical

exertion right yeah so i mean and then there's times where i need some call of duty in my life right it's just yeah yeah i would say that exercise's times where i need some call of duty in my life right it's just yeah yeah i would say that exercise is probably a little extra hot this time of year yeah all right we're still coming off that january 1st yeah so if you take a look at like you know we had uh 43 we're saying they get outside when they have their free time if you take all of the ones from stack overflow all the all of the exercise ones and combine them in to one choice of like, you know, do you exercise or not? Then it was like 60% of the respondents exercise at least weekly.

Interesting. Right. That's cool. I mean, it's good to hear because it's, I mean, honestly, in this profession, if you don't get some physical exercise in your life, you will eventually just get to a point where you feel and and i mean sitting is the news is the smoking of our generation right yep so you know if i finally had my first full standing day oh i had meetings all day so that wasn't so nice but it

was nice that i stood all day and i wasn't uncomfortable so i first started standing standing, even after like two hours, I remember being like, oh my gosh, I'm standing two hours a day. My feet hurt. Yeah. So now like I can do a whole day and it's no big deal. Awesome. Man, I got to get me a standing desk. How often do you use yours?

Not as much as I should. Probably a few times a month. I mean, I'm not good about it. Yeah. Only a few times a month. Yeah. I'm not, I should be. The thing is I'll get coding and I'll just forget that I even have it.

Right. I can see that. Yeah. The meeting is great because I don't like typing a lot while I'm standing. But in the meeting, no problem standing. I don't like to be dancing and stuff to kind of keep awake. Yeah. It's good.

Nobody even knows I'm dancing right now. I can see you. All right. So this episode, we're going to ask, while we watch Joe dance and raise the roof. That's right. We, oh, man. We got to have a sprinkler next.

If you're not watching this also on video, you should, because the dance moves that I'm seeing right now are just amazing. And you owe it to yourself to check it out. I've seen Joe sprout into a flower or something before. Head to codingblocks.net slash YouTube to get to our YouTube channel. And you'll be able to find this in all of its video glory. I do a lot of dancing. So we talked about licenses before earlier and I forget the exact context of

it. Something, one of the things that you brought up earlier, I think in the beginning of the show, Alan, but so this episode we're going to ask, do you pay attention to third-party licenses and your answer, your choices are your answers. I was going to answer it for you, but instead I digress and I'll just give you your choices.

Your first, your first choice is yes, because my company forces me to, Or yes, because it's a good habit. Or no, wait, you actually read those things? Or lastly, no, wait, am I supposed to? Yeah, this will be interesting. I bet there will be things in here that will be scary. Yeah, I think it depends a lot on where you work, what kind of software. Yeah, we'll see. A quick question for all of you trailblazing freelancers.

If you could reclaim up to 192 hours a year of your precious time, would you? Our friends at FreshBooks who make ridiculously easy to use cloud accounting software for freelancers are the architects behind this question, and for good reason. By simplifying tasks like invoicing, tracking expenses, and getting paid online, FreshBooks has drastically reduced the time it takes for over 5 million people to deal with their paperwork. If that's not enough incentive, the FreshBooks platform has been rebuilt from the ground up. They've taken simplicity and speed to an entirely new level and added powerful new features. Oh, and if you're doing the math,

192 hours works out to two working days per month. When tax time does roll around, you'll find tidy summaries of your expense reports, your invoice details, your sales tax summaries, and a lot more. If you're a freelancer listening to this and not using FreshBooks yet, now would be a good time to try it. FreshBooks is offering a 30-day unrestricted free trial to our listeners. To claim it, just go to freshbooks.com slash coding, that's C-O-D-I-N-G, and enter coding space blocks in the how did you hear about us section. Hey, and check this out. One of our buddies just signed up for it and they even have little interesting tools to start the clock when you start working and stop the clock so there's there's a ton of other little features to make it really nice for you as you're keeping up with your expenses very nice all right so coming back

in here the next thing that we're going to talk about are test boundaries and yes they are a part of your architecture that's the test right the tests are part of your architecture. That's the test, right? The tests are part of your architecture. The tests are, yes. They should not be an afterthought, basically, right? We talked about it in clean code and other things. They need to be there. And here's the interesting thing, right? Like we've talked about all these abstractions and everything.

That's not the case with tests. They need to be very detailed and very concrete. They are following the same dependency rule that everything else is, and they're pointing inwards. there was yeah oops dang it all right okay there was probably gonna say the same thing that tests are not immune to all the rules we've been talking about they're not some like sort of side thing where you get to do whatever you want it's really important to write those well or else they end up being fragile and discarded yeah except i did want to come back and explore on that though but um he said one part here that i hadn't really thought about it like he said like think of your your test as your outermost circle right and i'd never really

thought of them like that but it makes sense when you when you do and if i remember right when they fall into the zone of uselessness or something, it's something ridiculous. It might not have been uselessness, but basically... Zone of pain, maybe? Zone of pain. They are very concrete and very not abstract,

and that's what it was, zone of pain. So, yeah. I mean, but that's the way they're supposed to be, right? They're supposed to be there to test what you have, not be used by... Yeah, they're consumers of your code. Right. Not be used by consumers of your code right not be used by

anything else right i'll remember the dependency rule means the dependencies go inward so the test still shouldn't be dependent on say a database of you know of course if you do an integration test or something then you're you're going to end up testing some sort of database or some sort of mock of one but yeah just the idea the tests are part of that boundary and they're part of that layer that are outside and past all of that because they can kind of reach in and that made me kind of think about a discussion that we had way way back maybe like episode nine way in the beginning we were talking about unit testing when we talked about testing internal classes and methods or package or private or basically you know some sort of non-public entity with unit tests and we both

said i think outlaw and i both said i don't remember where you were at alan but we both liked that idea and we kind of struggled with the notion that maybe you shouldn't test you know anything but the public layer i was wondering uh like how you thought about that now outlaw that we've kind of like read this chapter well i mean this chapter was like you might think that okay you might think that hearing us talk about test boundaries you're like oh god not this again i've seen so many take talks on unit unit testing and tdd and bdd blah blah blah you're like okay i'm done i don't need this but this chapter was actually like seriously eyeopening. It made me like reconsider everything that I've ever done about, uh, unit testing was probably

wrong. And it actually like flies in the face of a lot of the, like how you should structure your unit test kind of topics and conversations that are out there. Um, so, you know, I would say that uncle Bob would definitely argue that you shouldn't be going after, you know, anything that's not public, that you should only be testing the public layer. Um, and that makes sense. But the reason why I say that it, it was so mind blowing for me was that, you know, you mentioned earlier a moment ago, Alan, about them being in the zone of pain because they are so concrete and fragile, right? He refers to it as like, you need to create a testing, a test API, right?

And I think we've talked about this in the content in some other context before where it was like a test language, right? And I think we've talked about this in the content in some other context before, where it was like a test language, right? If I remember, right. But he basically says like, you're you're testing architecture needs to have its own API. That's a that's a super set of these interfaces so that you can decouple your tests from the application themselves so that testing, you know, refactoring the application doesn't mean necessarily mean that the tests themselves have to be rewritten. Yeah. That was a really cool takeaway. And I've never thought of it like that. Like, you know, even, um, I think when we've talked about, testing before, and in fact, I think there was a previous episode where I had posted like, hey, here's how I like this.

There was this article that Phil Hack put out about how he likes to structure his unit tests and so that it shows up nice inside of that IDE. And then Roy Oshirov, I think is how you pronounce his name, that wrote The Art of Unit Testing. He had a particular format on how to structure your unit tests and even, you know, as far as from the naming perspective, so that, you know, regardless of what test runner you used, you could immediately see what class was being tested, what method was being tested and what use case was being tested. Right.

And, you know, I, and in that episode, uh, where I, you know, merged those two concepts into one, it was like, Hey, here's how I like to do it. Right. Would totally go against everything that Uncle Bob is telling us here. Because having those class names and those method names in the unit test names and the unit test method names, he would probably want to slap me with this book if he saw that. Because they call this the fragile test problem.

Basically, as those those um concrete classes change you could have like depending on how complex your project is you could have a thousand unit test fail right it's like whoa yeah it's it's really funny like reading this chapter i felt like i kind of had like uncle bob on one shoulder and like roy osher over the other and you know as soon as i would start like leaning one way, the other would kind of smack me. And so I, you know, my initial first thoughts coming in were, well, of course my test files should match, you know, match up like one for one for the test or the files that are under test. Right. And, um, same with the assemblies and everything. It should all just line up because I'm testing classes, right. I'm testing these smallest units. And then,

you know, reading this chapter i've got uh you know it feels like a little bob slapped me on the back of the head saying hey wait no this is the outermost consumer like why would you cheat and suddenly start having all these concrete dependencies and uh you know like why would why would you do that that's totally anti-everything are you trying to make this stuff really fragile like why would you have it totally this mirror image of everything that's under test so that you you know like kind of by definition every time you change one you have to go change the other like are you crazy so every time i would kind of start leaning towards one i would

get smacked together so i still i don't i don't know where i ended up still figuring that out yeah honestly i'm with you on that yeah i i still got to try to sort this out in my mind now because it was a little bit of a mind-blown moment. I've had so many years of extremely smart, well-respected people in the developer community. We named a couple already that are saying, hey, here some like really good ways to structure your tests and everything like good patterns and then this comes along and i'm like oh man and it's not how do i incorporate that right it's not that it just comes along and you're like oh it makes sense right like yeah

that made sense exactly it's like how. Exactly as how Joe put it. Why would you cheat? This is the outermost circle. So why would you suddenly decide that it's okay to cheat the system here? Yep. And if you go back to what we talked about, I think, on the last episode when we thought we were going to have both of them in one, we talked about the main program, the main method, right? Being the thing that scaffolds it or puts all the things together,

right? That's basically what your unit test should do, right? There should be some things that new up everything and inject all your dependencies at the first place and use the abstractions. And now you're in a spot to where if you want to test it slightly different, if you have another pluggable feature, guess what? You just test that way too. And it was funny just the other day on Twitter, I saw someone talking about how they gave some advice for somebody on, on unit testing and they pasted like the, what they typed to the person in Twitter.

And I read it and I was like, Oh, this person is going to get a beat down. Like they, they don't know the rules and what you're supposed to say about unit testing because they were advocating for outside in unit testing. And I thought maybe they had just come up with this this or this was just kind of like a novel idea that they had and i was like oh boy you're gonna get it right got the popcorn and i hit the replies and man reply after reply after reply was like man i finally get it this actually makes so much more sense to me i'm actually testing this stuff how i use it it's not so fragile it's really great

and i started kind of Googling this whole outside in and saw that there's a little bit of talk. I don't know if I'm maybe not getting the right terminology or what it is. So I'm not finding people recently talking about it. But I do see this term of outside in testing sprinkled throughout blog posts over the last five years or so.

But now I'm kind of wondering, it's like, well, crap, maybe I need to reevaluate and look at some of the newer thinking on unit tests. And, you know, maybe I've been kind of stuck in my ways. I don't know. It's easy to do. We've talked about it. We did the same thing with databases for years, right?

Like it was your source of truth. It was the core. It was what everything depended on, only to look back and go, oh, wait a second. That really shouldn't have mattered, right? Yeah. So and we kind of skipped over it. These should be independently deployable, right? And the most isolated system component,

meaning that it really only relies on everything else. Nothing should be touching that. So you can push it out there and run it at any time. And they already are deployed like that. They already are independently deployed. If you think about it, you don't deploy the test version of your code to a production environment. Typically, that's a debug version that's just deployed to whatever you're going to run the tests are, even if that, quote, deployment is just locally on your own file system.

But that's it. Well, let's talk about that real quick. It depends on what language you're talking about, right? Because if you talk about something like C Sharp, that'll be in a separate project that you don't deploy, right? If you're talking about things like, for instance, in the JavaScript world,

it is typically a best practice to have your test spec in the same folder as the files that it's using. But you'll have something in the bundling or the building of your application that will say, hey, skip all the spec files or whatever. So it depends on which world you're talking about, right? Like it still doesn't get deployed.

Well, that's what I meant by deployed even like on your local file system, right? It would be like, you know, if you're skipping the spec files versus if you're building a separate dll or jar file it is interesting because like in the c-sharp world it does kind of frustrate me that you can't put the test next to it like you have to put it in another project and now it's not really clear to see hey did i test these things right like it is are there tests for this are there tests like

there might not be and and that's the one thing i really do like about at least the JavaScript ecosystem and how that stuff evolves is it's nothing to put it right next to it. It's just another statement in whatever your build setup is to say, hey, skip these things. So, yeah. Yeah, and I always thought it'd be neat to have the tests in the files too. I don't do that. I know that's against the rules or whatever but uh just imagine the idea of like you know going into your class and you see you know you're one of two methods there and then you scroll down a little bit and then there's like 10 tests that kind of show you like what the you know the rules are what it means i bet you could

do directive things it's especially a hassle in like large yeah projects yeah where there's a lot of individual um components or projects within the overall solution you know how frustrating is like when you would have like two files open they're you know the same file name basically are very similar except for maybe the word test in them and they're even arranged kind of similarly and like one's way over here one's way over there so you're like okay let me open the next file and let me go up down over left turn around three times open the other file uh turn turn the other way three times go right go down go up you know and then find the same file that's kind of mapped there and then open that up and now like every time you open a file you've got two files opening up with very similar names you know it's just

annoying i felt like he was trying to hunt the wumpa says he was trying to open his files Like every time you open a file, you've got two files opening up with very similar names. You know, it's just annoying. I felt like he was trying to hunt the wumpa since he was trying to open his files. I mean, the interesting thing with that is the fact that they get very disorganized unless you are super, you know, hyper aware of what the file structure is. But then it sucks, right? Like if you move your class from one place to another, you're going to go unit test from one location to another and so it's just it's a mess but anyways yeah wasn't that a benefit of unit testing like isn't it supposed to free me up to refactor more freely right and now we're saying like well actually it's a big pain in the butt if you move anything so you know refactor but just don't rename anything but unlike unlike the other parts

of your of the code, though, in your application, your tests support development, and that's it. Right. Everything else is about operation, but your unit tests are not. They have nothing to do with operation. They're purely about supporting the development

and giving you the confidence to do any kind of refactoring or to know that this works the way i intended it to work this next now i'm wondering like me you know maybe all this time like i thought unit testing was just really hard to do maybe i've just been doing it wrong so i'm gonna have to do some experimenting i'm gonna have to try um kind of creating my own test boundary keeping it as part of the the architecture and just kind of see how that works on a project and see how i feel about it yeah i mean it doesn't sound like a bad thing no if anything it'll make it easier and better going forward right although it's going to be painful it's a it's a mind bender right but um yeah so he has a statement here where you know

if you think about what we said so far about you know these are the most detailed and concrete they're the outermost circle uh nothing depends on them nothing depends on them that's a key and that you know they support the development he says all code should be modeled like the tests isn't that crazy you know layers upon layers i mean i i have to see what this looks like i've never seen anything like this so um if there's an open source project or something that's got like this kind of test layer, then I'd love to see it. And you're coming up the next chapter. I think we've got a nice example of what layers like this could look like, though not specific to testing. Yep. Yeah, I want to see a test layer.

Yeah, so ultimately, this kind of goes back to like a TDD conversation where, you know, the solution to this test boundary is to design for testability from the start. Right. Which is very TDD in thought. Right. Like if you can't write a test for it, then you can't be writing the code for it either. And their next statement is something that we hit on several chapters back, which is don't depend on the volatile things. So your databases, your file storage, that kind of stuff, like that's not is don't depend on the volatile things. So your databases, your file storage,

that kind of stuff, like that's not things you should depend on the clock, right? You should, you should mock those things as much as possible. And then that way, you know, you don't have these things that are so brittle.

And yeah, go ahead. Yeah. So rather than writing, okay. So going back to like my mind being blown here you know typically the way i would have thought about like writing unit tests would be like okay i have this set of classes i need to write you know as joe put it like there's this one-to-one mapping you know for the the classes and then the unit test to make sure that all the functionality in that class is tested right and basically what Uncle Bob was saying here is rather than writing these unit tests against all

of the production classes, instead write your tests against the API, allowing this primary application to change without worrying about breaking that many unit tests because you're not necessarily going after any individual one class necessarily but but more the overall function of some purpose and this whole api thing is basically coding to the contract is really all he's saying right code against the abstraction whatever whatever public interface was made it not to the class. Because then the class can change and you don't care about it. As long as that class is fulfilling whatever that contract said it had to, you don't care what the implementation was.

Well, kind of going backwards to our conversation at the start where we were talking about the authentication microservice, right? So you might have some code within that service that handles the decryption or encryption. Well, I guess you would be doing Well, I think where you're going with this Let's say if this authentication was to create, if this microservice was to save these credentials, then you might want to do the initial encryption

insulting right and you wanted to make sure that like you were producing the same you know given the same uh you know inputs that you were always producing a consistent output right so you might be tempted to just test that one thing right isolation and say, hey, does this encryption layer work the way I think it does? And what he's saying here is that rather than even bothering with that low-level detail, instead you would just focus on writing a test that's about the API of, hey, if I try to save a credential, does it get saved? Right. Period. Did it work? Right? a credential, does it get saved? Right. Period. Did it work? Right.

Does the overall intent of the thing work? And not focus on the minutia of it. Which is interesting because you hear a lot about people saying code coverage, right? And it's a thing even in tools that will measure how much code coverage you've got with your tests. And this flies

in the face of that too. This is, no, just test against what your interface is, your contract, so that you need to. Well, I don't know that I would necessarily word it that way because you could still have code coverage that goes across all of the intent of it without necessarily writing classes that focus in on a particular thing, right? So you could still focus in on like,

you still have a test that's like, hey, I called my authentication service to create these credentials, right? And to save those credentials. And did that work? Okay, fine. And part of that path may still include encrypting the password with some salt, right?

And making sure that that works rather than having a class, a test class specifically for, hey, encrypt this and make sure that the output is right. So, I mean, it's still the same coverage. But isn't code coverage, doesn't that usually count how many methods have not been tested against? And that's what I'm getting at. Yeah, but you could still be calling all of those methods,

but not specifically. You're getting them implicit rather than explicitly calling them. Well, you could also configure the coverage tool. So you say, here are my unit tests, and only calculate the coverage for this public API layer because we've got a separate layer for it. So now we tell it to kind of ignore the other stuff because we say, well, it doesn't really matter that's just how the sauce

implementation details right yeah nobody cares about how the sauce is made yeah okay yeah i mean this still i'm still chewing on this chapter yeah honestly that's a good way to put it you know he says that this testing api should have superpowers outside the normal powers of a regular system user therefore it's probably best if it's deployed separately and never ships with your product. I love this one, by the way, because what they're saying is in your test, you're bypassing everything. You can assume that you've got super user rights. You can assume that you don't have any rights. You can assume whatever you mock all that stuff out, right? So you definitely don't want to ship this code because now you could be potentially giving away the keys to the castle with some sort of hole, right?

And it's interesting. It makes a lot of sense. You shouldn't be, if you run on a Windows network, you shouldn't be relying on AD in your unit test, right? You should be able to mock that user out to say that, yeah, you're a member of X, Y, and Z group and you've got God rights to everything. So I really liked this one. It was an interesting take on it that I don't know I've seen embraced anywhere. Yeah. Basically what I want is after having read this book, I want Roy Oshirov to write the art of Unit Testing 2.0 as it relates to the testing API that Uncle Bob is suggesting

here, and then maybe I'll be able to wrap my head around it more easily. I think you can write that book. You just call it The Art of Unit Testing with Good Architecture. I think that's a good title. With good, not clean, but good. With good architecture. Yeah, we don't want to see anybody's title. Right, right. Just the first one.

This chapter sort of came with a disclaimer, like, we'll rock your world. Yes. We'll hurt your brain. All right. So now we get into something that I don't think any of us have a ton of experience in. I may be wrong. I think Outlaw, you're probably the closest. I don't know.

Well, I would have said no until I kind of read some of the generating SQL type stuff. Oh, yeah. Oh, yeah, totally. That's a good point. Yeah. So the name of this one was Clean Embedded Systems. So, man, it's funny. When I first read the title to this particular chapter, I was like, eh.

And then I started reading it. I was like, okay, well, this is way more applicable than I thought it was going to be. Yeah. So like the first one, I love this statement that he makes. Software doesn't wear out, but it can be destroyed by unmanaged dependencies on firmware or hardware. And you're about to, and I'll let one of these guys get into it, you're about to get your head twisted around a little bit on what he means by firmware. I had to look it up.

I feel like I've used the word firmware for routers and all sorts of stuff but like when he kept like talking about the differences between the hardware and firmware i had to go look it up and what he means by firmware is um i lost i lost this is the very next line here you okay so uh no that's not what i was looking for someone else has to say it okay well i well, I'll say this part then. He says that firmware isn't firm because of where it is stored. Rather, what it depends on and how hard it is to change as the hardware changes. Okay, and actually, I found the line I was looking for.

I was like, well, what the heck is firmware to begin with? And what I ended up finding in Wikipedia is that they call it the low level control for the device's specific hardware. So an example here might be some sort of call to blink the power light. Right. So it's the things like that that can be controlled via, I don't want to say software, because it's kind of in between software and hardware, right? So it was on read only memory generally, not necessarily, but for the most part, this is software that isn't going to change so much.

All right. So here's the part that kind of drove it all home. And this is, this is where if you hear this and it doesn't make you twitch a little bit, then maybe you've been doing things great all these years. But this is where I was like, okay, we're not just talking about embedded systems on a chip. Non-embedded developers also create firmware when they embed SQL statements in your code. That's so true.

Same type thing if you're embedding HTML in your SQL when you're returning stuff. Same type thing. You are making hard, fast decisions on what your architecture, not your architecture, on what your hardware, what your application is using and what it's doing. You've now basically created firmware because it is extremely hard to pivot off that. Maybe you're entrenching yourself, depending on the software itself, you could be limiting yourself to particular hardware, as you mentioned, like ARM or, you know, whatever other kinds of hardware there is. But also your operating system, your tech stack,

all sorts of stuff. You're cementing your position. Yep. Yeah, I was going to embellish this a little bit, because it doesn't just have to be like embedding your SQL statements. We've talked about this as, you know, if you aren't careful and don't abstract away some of those dependencies, then you further tie yourself or marry yourself to them. So for example, if in your code, it's, you know, like a quote known thing by some kind of dependency there

that you're using SQL server, for example. Well, you've now, you know, it's become firmware because it's now hardened to SQL server, right? Yep. And we've talked about entity framework. If you use entity framework with link to SQL, guess what? You've now, and we are not picking on any framework. We all know and have loved and used Entity Framework. But if you don't draw those boundaries properly, then you have created firmware because you have tightly coupled your application to SQL Server via the Entity Framework, you know, bus, we'll call it. So it's really interesting when you think about it like this. That statement of software doesn't wear out. I mean, think about it. It can't. It this. That statement of software doesn't wear out. I mean, think about it.

It can't. It's ones and zeros. It doesn't wear out, but it can completely be destroyed. And that's, man, that's powerful. And Kent Beck, famous for a lot of unit testing, writing, and a lot of other stuff, had some really nice rules here that I think a lot of developers follow to some extent. And the first one was first, get it working. I've definitely been there where like the first thing you're just trying to do is get something to show on screen that looks roughly like, you know, some approximation of what you're supposed to do. Then you try to make it right.

That's step two. And then after that, you try to make it fast. And a lot of developers will just kind of stop after number two or sometimes number three but there's no keep it clean step here right and that's true the make it right doesn't mean make it make it clean doesn't mean make those boundaries it just means okay it's not as crapified as it was initially right right and yeah i guess you could define right to be different things right you could say right to be different things, right? You could say a right does mean clean, I suppose. I just kind of interpreted it as actually correct, but maybe I'm wrong there. Well, and nowhere in here does it say to make it perfect. Like,

we're not talking about perfection. No, no. And you should, I mean, this is probably a bad thing to say. You should never strive for perfection in your code. And the only reason I say that is chances are it's going to change tomorrow or the next day or the next day. Like, I mean, we've all done it. We've created code that we're super proud of. And then it's like, oh man, I didn't think about this edge case. And then, and then you go in and, and it's not as pretty as it was before. So don't strive for perfection. Strive for really good. Like don't ever walk away from a steaming pile and be like, that's it. I'm done. But, you know, perfection is a tough one in programming.

Yeah, no one would win to call win. Yeah, exactly. Yeah. Remember we talked about the gold playing anti-pattern? Oh, yeah. But I do want to go ahead and make a retraction on a statement made two minutes ago. So, first, make it work. Second, make it right.

I think to make it right does imply getting it clean and making sure that the things are maintainable. And then the third, making it fast. Like, you know, I made the statement that uh there was no fourth step but i think that was implicit there in step two all right then yeah he says that if you're only going to focus on making it work then you're doing everyone a disservice totally agree because you're going to have to maintain that thing and there is more to software development than just making it work that's actually where it you can draw the line between a good developer and somebody who's just getting paid to get the job done, honestly.

So going back to a conversation we've had in the past about what's the difference between a junior and senior? That's a big one. That's a big one. The junior would just make it work? Yep. I got it done. Whoa, what is that?

Did you? Yeah. All right. would just make it work yep i got it done whoa what is that did you yeah uh all right so uh where were we at here so so there's much more getting it to just work okay so intermingling your software and your firmware is an anti-pattern so what does that mean and by the way i pretty much hate the term anti-pattern so what does that mean and by the way i pretty much hate the term anti-pattern but it has relevance because i i feel like some people just use the words to to make it sound cool right oh that's an anti-pattern well i don't okay i think it was bad habits it's a bad habit right yes so so the where i got kind of confused on this, though, was that, like, well, if you intermingle the software and the firmware, then it's no longer intermingling. The firmware is a virus. If your software intermingles with the firmware firmware then the software has become firm

yep the firmware has infected it and it's become firmware that's a good point it's no longer soft so there is no such thing as intermingling software and firmware that's so awesome what we need to do here is create a humble layer that will do all the talking to the uh the firmware and then we can sit on top of that humble layer and now we're protected from that virus and we'll be able to use this code more you know more well yeah potentially other places and be able to test it and do all sorts of other good stuff with it nice way to bring back in the uh humble layer that was good job never forget humble objects oh never forget so yeah intermingled let's say, infected code resists changes.

I actually like the infection because that's really, if you picture that, that's beautiful. And the worst are these make the entire system almost impossible to test, right? Or the changes are dangerous and require full regression tests. Which is going to make it even more difficult. If you start embedding your dependencies, now you've got integration tests instead of unit tests, which we've talked about in the past are really hard to do. So, yeah.

It also makes it really slow to work on too. Like, you know, I've talked to people who work at New Cash Register, NCR. And, you know, obviously it's not like this because it would be too slow to work on. But I, you know, I've talked to people who work at New Cash Register or NCR. And, you know, obviously, it's not like this, because it would be too slow to work on. But I've kind of joked about like, every time you make a code change, you got to publish to the ATM machine that you've got sitting next to your desk. And you've got to get out your debit card and work on. And obviously, that's a silly way to work because it's just too slow. But, you know, a lot of us do kind of put up with that sort of stuff in other situations where we're relying on that hardware that website that whatever really bring up the

website click click click click click wait wait wait wait click click didn't work start over again so we're introducing these cycles that are dependent on the bottleneck and that's because we don't have these kind of good abstractions, good boundaries, good layers that we can kind of mock and play with in order to test more granularly. Yep. It's funny you bring them up as an example. I've actually been in their labs before. Oh, really? They really do have a room of all the various ATMs.

Wow. At some point, you kind of got to, right? You can't just say, like, works on my machine machine, and then roll it out to Bank of America. Now, in fairness, for what he's saying, you want to write your software in a way that it's abstracted away from the hardware so that you can write your software independently of the hardware, but it's not a bad idea to test it on the hardware afterwards, right? So we're not saying that you shouldn't have it.

We're just saying that it should be done in a way that you don't you don't have that bottleneck yeah you don't want to publish to that atm because you're trying to get the uh logging you know the pin screen to be pixel perfect so the grant is too slow right so this is where the how comes in i don't remember this boundary between the software and the firmware and so immediately you should think space odyssey 2001 uh you know the how 2000 the how is the hardware abstraction layer and this is where you abstract that hardware so that your firmware can be tested off hardware all right so you're making a firmware a little less firm that's the that's the objective here It provides the service without revealing how. Yeah.

An example here I really liked is that you might have methods like indicate low battery or indicate error rather than LED blink 5 or LED blink 3, which I'm sure you've at one point had some sort of hardware device where, you know, the different blinkings or maybe the different lights meant different things. Like why have that kind of blinking light code, you know, invade your code and poison your code? That is a perfect example. You can have a layer here that you can use to interact between. And then if you need to move this code, give it a life outside of this device, maybe the device is upgraded or, you know, something else changes, then it's really easy to see exactly what needs to change in order to support that new hardware.

So if you're on board with the concept then of the hardware abstraction layer, then this is where things get like rinse and repeat type of patterns. Again, every time the goal is to make the firmware a little less firm. And so you'll bring in a processor abstraction layer where you're trying to further decouple that, that firmware and the hardware from, uh, so that, you know, you want to, you don't, you don't want anything to know about the hardware registers, for example. Um, and again, you're just trying to, your goal here is to be able to test off hardware as much as possible. And take that a step further to an operating system abstraction layer so that the OS can just be treated as a detail to protect yourself against for many dependencies that you have on it, right? So you keep putting these abstraction layers

between your firmware and ultimately the hardware. I mean, if you think about it, that's kind of what they probably did with the Windows subsystem for Linux, right? They just stuck an abstraction in there and said, hey, treat this just like you would a Linux system. We don't care about the underlying architecture. Just make it fit, right?

Here's the interface. Let's make this work like it. Well, just the window. Yeah, now PowerShell. Say again? Oh, PowerShell now, it can be run on multiple different platforms as well, cross-platform.

So same type of thing. I forget where they have it, but they basically have an abstraction layer now that sits on top of the operating system and everything runs through that and it just works magically. Awesome. So that was PAL and the same thing for operating system, OSAL, but either way, access layer.

Yep. And yeah, we've said layers many, many times tonight and many times throughout the book. Layer architecture is premised on the idea of programming to interfaces. It lets you do cool stuff like work vertically or horizontally or test your APIs or kind of slice stuff off and support multiple devices for embedded architecture. So it just seems like a really good idea. I mean, you can even use the layers for the testing, which still, you know, wrapping my mind around. But it definitely seems like the layers for the testing which still you know wrapping my my mind around but it definitely

seems like the layers have been really core layers and dependency injection have been core to the whole concept of clean architecture yeah he he wrapped this up in a different way instead of saying dependency injection but substitutability right right by programming to the interfaces that you allow for substitutability. Which is the same thing as the whole plug-in notion and all that, right? Literally being able to swap things in and out. Yep, so a clean embedded architectures software is testable off of the target hardware,

off of the target operating system, and within layers because the modules interface through interfaces. Interface inception. Someone had to say it. I'm sorry. And this is funny right here. They even say that if def, so your, what are they called? Pound of fines. Yeah, your directives.

Yeah. Like your processor directives and that kind of stuff. They violate the dry principle when you have this wrinkled all over your code. We've never seen that. So, yeah, keep those isolated to a single file. And now that only, it's like the switch statement or the if statement. That is only going to work if you've got that dependency injection or, you know, some sort of substitutability set up. So you can actually swap classes in and out because if you just do an if

statement in each of those functions and you're repeating yourself you know the same thing right you're you're spreading that poison so whether it's a if def there and if either way you're doing the wrong thing according to clean architecture ideally you're going to be able to swap those things in and you're still going to have those if def somewhere but you're going to keep in one spot and it's going to control which set of classes or which set of components gets used yeah and this whole if def thing just so for people who have no idea what we're talking about those are things like uh compiler directive so that if you're in debug mode then do this if you're in production mode do this yeah i was going to give

like a really good uh or actually i guess really bad example that i was guilty of a long time ago where like in my c code or even c++ code i might do something like if def debug uh and then log out some kind of message or print out some kind of message either to the console or to the law to a log right and you know i'd have this stuff just sprinkled all throughout the code and it was like really easy for me for a debugging purpose you know if def debug if def debug like just sprinkled all throughout it but it did you know it goes against what he's saying here because i probably you know thinking back to it now i would look at it and be like oh you know what i should just have the one method that's going to print out whatever I wanted to print out.

And inside of that one thing, then maybe it should be making the decision about like, hey, you know, if def, you know, debug, then do this. Maybe that's the answer. But, you know, another downside of that kind of thing, having those if def statements in your code, whether it be for this debug scenario that I'm describing or if def uh you know core i7 if def core i5 it breaks up the readability of your code which isn't one of the topics necessarily mentioned in here but definitely uh you know going back to clean code right you know the whole point is to make your functions readable immediately right then uh that totally interrupts the flow of

the reading and there's a complexity score in things like independent or any kind of static analysis things that will show you the the number of like uh uh what are they called decision paths or whatever that they can shoot up the complexity and that would probably do it as well right i don't know if the if defs do though because they get compiled and the static analysis you're talking about is going to go on the compiled version that's a good point so your code is hard to read yeah all right yeah that's a fair point all right so yeah the next thing we got here is we say letting all code become firmware is bad for the obvious reasons that we just stated before it's a virus yeah so going back to the example that alan started with about like um you know if you start embedding your sql into your

code well we know that that's a bad thing right uh for one you're doing like string construction of your sql statements like we know that's a bad thing right but now we can phrase that in a different way because we can say it as, oh, you've infected it. It's now become firmware. It's no longer soft. You can't change this thing. You've gone down this path. Only being able to target or test on the target hardware is bad, right?

That makes a lot of sense. If you've got to have the ATM sitting next to you everywhere you go, how are you going to do that at home? What if you've got a late night that you've got to do something atm sitting next to you everywhere you go how are you going to do that at home what if you got a late night that you got to do something you know away from the office right and hooked up to the bank too right oh yeah every time i need to test it costs me 20 bucks yeah and another way to think about that though is that it that also implies that you don't have unit test at all right and we we know from past experience that like not having unit test is a bad thing so if you can only test on the, then that means that you don't have it. And because you don't have those unit tests,

now you've got to remember all of the use cases that have to be tested on the hardware. Yes, a little bit. So you've got to have a running punch list of, here are the things I need to make sure I do. That you know, or that Joe knows, or whoever worked on the system for the past 10 years knows. Right.

That some person has to manually go through and do. And not only that, but they got to be diligent that they do the exact input or, you know, and make sure that they get the exact output.

And don't get lazy or don't mess up. way to do it because humans, we are definitely fallible. You know, we're going to make mistakes. So if you're relying on a person to do it because humans we are definitely fallible you know we're going to make mistakes so if you're relying on a person to do that it's going to fail yeah and the thing is is typically when you're working on a mundane task like that your mind has a tendency not to focus as much i mean there's even there's a netflix we've talked about this there's a program on netflix called

like uh uh brain oh brain games is it brain games i think it is i don't know where you're going and so there's a show on netflix that i highly recommend it's called brain games and it just shows you how your mind fills in the blanks when your mind's bored it literally just i'll make this up and and it's a real thing. Like it will blow your mind, you know, pun. But if you, if you watch it and you see some of this stuff, you're like, wow, I never realized that because my mind disengaged, you just start making mistakes. Well, here's a, here's taking this from a different angle. I believe it was an MIT study that said that as long as you had all of the consonants in order, that you could remove any or all of the vowels out of the words and still

write the sentence and it would still be readable and you wouldn't even trip over trying to read it. You would immediately know what that sentence is trying to say and so that's an example of what you're describing where in our minds will automatically fill in the gaps right but it might be critical to our application that we actually print out you know something exact and you know we need the software we need that unit test to make sure that the exact thing was printed without some human's brain just going oh well i can easily fill in the gaps and move on yep so and actually that's a nice teaser for the we talked about doing a practice episode next i'm not sure it'll be the next one but we're going to be uh i'm gonna be talking about that exact thing in my presentation talking about how your brain takes shortcuts for for good and for bad and that's why it's really important to build up good habits because

when your brain is it's so desperate to take those shortcuts and it desperately wants to be on autopilot that if you don't kind of have that good muscle memory built, but if you haven't codified good habits, then it's really easy to slip into really bad habits. And if you're in Orlando, this coming, well, this probably won't be out by the time you do it.

Ah, doggone it. Well, hopefully you did an awesome job by the time this is released, but yes. I'm going to make some videos eventually. So if you're listening to this and you want to hear or see the video, you should like come kick me

and make sure I get it done. That's right. And then, so wrapping this all up, what have we learned in this book? So there are more chapters, just as a heads up. But I think we've fairly thoroughly covered, I think what are the most important and, and just really main points that this book tries to drive home. And so following

the principles outlined in this will help make your architecture and your code clean and maintainable for the, you know, foreseeable future. Yeah. The only section we didn't get to is the, the detail section. And there's a few things section we didn't get to is the details section. There's a few things we skipped along the way, but the details just kind of dives into more specific examples of how to handle some weird situations that come up.

And it probably covers a lot of the weird things that we brought up too. So I'm going to keep on reading. And if, you know, again, I highly recommend picking up the book. If you're not one of the winners, by leaving a comment on one of these, you know, pick it up, check out our resources page. It's there. It's excellent. I mean, it'll make you think about

code in a different way, not just something that you write in your codes clean, but thinking about maintainable systems overall. So, uh, you know, obviously it's one of the resources we really like clean architecture, surprising. And then brain games. I found the link to it on Netflix. I've put that link in the resources as well. Super fun show to watch, man. It will absolutely blow your mind. And yeah. And I found the story about that. I had it wrong. It wasn't that their vowels were removed. It was just that you could replace, you could move them in any order and it was a cambridge university not an mit study that did it so we'll include some links to that as well the link is fun yeah

well yeah i i'm trying to find the original story but that was like a fox news story where it's all everything is misspelled and it is hilarious it's beautiful well you will include that link in your mind really does just pick it up like it's nothing yep all right so now it's my time for the favorite part of the show joe never did pick one by the way still it's the tip of the week yeah i sure did i remember would you you picked this one too didn't you uh no it's the dankest memes oh is that is that still a thing all right someone erased the rules we need to get those back in there sorry slack inside joke all right i know some people hate those all right what you got all right my tip of the week is uh this is a suggestion from arlene because i've been talking

about it non-stop forever in the Slack. Why not hackathon? I know being a card carrying introvert that I've been kind of scared of in the past. But after seeing some of our friends over at Wales this past weekend, done really, really awesome, cool, fun, neat things. I figure I need to do it, too. So I'm going to be signing up for one in Orlando and I'm going to be giving a shot. It's kind of like this weird health app slash game jam. So if you got an idea, let me know. And I'm just going to, I guess I'm going to show up stag

and just kind of see what happens. So it may turn out terrible. But I have really good resources to read on what to bring. Both cynical developer, James from Wales and Jamie, made videos and slash podcasts about what they kind of brought. And it's really kind of interesting

just to see what kind of things and tools and prep they did for these hackathons. And just watching that YouTube video or listening to that episode, it's like, oh man, I really want to do this now. It's almost like a camping trip, but way nerdier. Awesome. I i'm gonna watch that video too all right so for my tip of the week i encourage you to sign up for a new feature that is right now uh you can sign up for early access for visual

studio live share now you might say, wait a minute, but I like Visual Studio Code. Well, guess what? This works for that too. What this allows for is real-time remote pair programming within Visual Studio or Visual Studio Code. So, you know, Alan could have his environment already set up and running.

You know, maybe he's got the connection to a database or whatnot, and he can send me the link. I can connect to his system. And in my instance of Visual Studio, I can edit his code. He can see me editing his code and I can run it against his system. But we can both work on it together. Yeah. I mean, it is incredibly cool. And there's, there's a couple of things to point out on this because I love this tip. One is it's your environment. If I send you a link, a share for mine, you load up your visual Studio or your Visual Studio code, either one, doesn't matter, with your theme, with your font size, with your layout,

your solution explorer could be in a different spot. It doesn't matter. It's yours, right? And then the other really cool part of this that I don't want to gloss over is he has to have no dependencies. Like if my app depends on no JS and it's got to have Bower and it's got to have Grunt and Gulp and 5 million other dependencies, he doesn't have to have any of them. Like you are literally running off my system with whatever code changes you want to make. Yep. So we're going to include that link in there and encourage you. We should all flood Microsoft with signup requests to this so that this thing can come out as soon as possible,

because this might be like one of the most exciting technologies that have come out. I'm not joking. Like I'm super stoked about the idea of remote pair programming becoming super easy and plausible. Oh, it's so cool. And now one thing to note, you can download the extension. If you go into Visual Studio Code, you can actually look for the extension and you'll be able to download it, but you will not be able to use it

because it'll want you to log in and it'll say, hey, you're not a part of the beta program or the preview. So make sure that you do hit one of these links and go and try and get your signup approved for the preview. That's a killer tip.

I agree. Like when I saw this, I was like, whoa. It's amazing. All right. So mine, there was another thing that was just sort of mind blowing. So if you haven't heard about WebAssembly, it's basically compiled code that will run in a browser in a nutshell, right? Like I don't think,

and it's, and it runs way faster than anything else that loads in because it's literally system level type calls that are, that are working. So small, really efficient subset of JavaScript. Right, man.

It is, it is crazy fast And again, it's compiled like it runs off if you're using dot net code It's it's dlls if it's you know, something else who knows what comes down, but Let's say let's back up just a moment. Let's give a Maybe a super brief overview on web assembly. Okay It's a like joe said it's a subset of javascript But if you take a look at like how

your JavaScript works today, you go to amazon.com, you download some JavaScript. The first thing that your browser has to do is compile that so that it can run. So when Alan says that it's compiled, compiled binary that you're pulling down, what he's referring to is the JavaScript compilation has now been moved from the client back to the server so that the compilation is only happening the one time and getting shipped as in that binary form so that's where it makes up its speed because you get to skip the compilation step yep and here's the really cool part so microsoft has been putting in some effort called blazer b- B-L-A-Z-O-R. And what this is,

is basically being able to write your entire web application with C Sharp and doing your templates, like your view templates within Visual Studio. Like basically, bye-bye React, bye-bye Angular, bye-bye all these other front-end client frameworks or GUIs or views or whatever, literally you can have, if you want to boil it down to kind of

what it is, it's basically ASP.NET MVC that gets compiled into WebAssembly and it just runs on the web. So you still have your CSHTML files that are like, I don't know if they're using Razor syntax. I think they are.

I think that's why it says they are. Yeah. So you've basically got those templates and then you've got your C sharp that you write that works with the data and pushes it in and out of the views. But then everything else is handled for you. If the browser supports WebAssembly, it'll publish it in a web assembly app if it doesn't it supposedly falls back so for older browsers like ie8 or 9 or whatever supposedly it'll fall back and use the regular java script route like you're talking about being

able to write full-blown applications and nothing but c-sharp and some html templates with some razor syntax that's cool you know i was originally kind of pessimistic about it i was like you know i've seen stuff that generates javascript before i've seen stuff that generates uh you know html and it's never been real great because it's separating me from the stuff that i want control over but then i remember well what about you know how unity generates web assembly and i'm able to do like to generate a full on JavaScript game from anything I do in Unity that's like 3D, 2D

that's really cool and it's been really great and so I'm still kind of like wrapping my mind around what this can mean for the future but it's really cool to think that like I can write something in C Sharp that runs you know over here maybe it's even a website and now all of a sudden I'm maybe running my website all in the browser.

I mean, I'm still trying to kind of understand it. Obviously, I think that the main thing that they're after there is replacing those or enabling those other frameworks to do kind of cool HTML stuff. But it can also mean really big, other interesting things, just kind of like the opening up the 3D capabilities

or translating 3D capabilities or whatever other capabilities of.NET into the browser so it's gonna be cool yeah I think WebAssembly is like one of the most exciting things happening in the in web development right now the fact that you can you know we will that there's this roadmap to where we're going to be able to do, use strongly typed languages to write this code. If you want, you don't have to, but, you know, because there's other languages that'll support it. I just think, I just find that exciting. Yeah, it's cool.

And on top of it, again, the speed, like I've seen full on 3D apps running in the browser. That's just like if it was running in an application an exe that you fired off on your computer which is cool um go ahead well i was going to say that you know you can see that they they came up with the name blazer because it was kind of like a a play on the razor part of this which anyone that's not familiar with.NET development, Razor is the engine for using in.NET to create your MVC app.

But because it's like C Sharp and Razor, they could have gone like Crazer or just Crazy crazy but i guess they didn't i guess the from a marketing point of view they were like that's probably not so good yeah so but but i'm sure the blaze was on the speed though thinking about it right oh i'm sure so a couple of things to note here this is this is open source you can go to go to GitHub and go to the page. You could put in a pull request. You can take a look at all this stuff, which is amazing, right?

Like the fact that companies are doing more and more of this, especially Microsoft being more open is awesome. If you want to play with this, what I would suggest, because this requires ASP.NET Core 2.0.4, or no, 2.1.4, which is bleeding edge stuff. What I'd recommend is probably go get a Docker image that has Ubuntu, like the latest version of Ubuntu on it. And then that way you can install.NET Core or get one of the images. Microsoft actually has Docker images that you can download with this already in it and run it that way, right?

Don't pollute your system with, you know, something that might not be ready for prime time, but definitely go play with it, man. Like, it's really cool. You can go spend this thing up and download the Git repo and then run the thing. They've even got a demo up on the site and they've got a YouTube video.

So I highly recommend checking it out. It's exciting where this stuff's headed. Definitely. All right. Who's doing the summary? Well, I guess me, this episode,

we talked about services, test layers, embedded architecture, and some tips of the week. And that's it for the clean architecture. It's the pen ultimate episode here there's still a lot of stuff in the book a lot more to it so we heartily recommend wait no this isn't the pen ultimate isn't that what pen ultimate means no i think that's like the best of the best

no pen ultimate would be the second to last is it second to the last last but one in a series of things i was wrong too. Wow, you're totally right. Yeah, I guess I should have just said the ultimate. This is the last. The last episode was the penultimate. By the way, we're done. Well, I mean, the way we worded it last time

is we might come back to some of these topics in the future because there's still a lot of book left with a lot of great topics, but we do want to move on to other topics so um you know hey if you want to read the rest of this then you should definitely leave a comment on this episode you'll be able to find it at www.codingblocks.net slash episode 77 and you can leave a comment there on that episode for your chance to win a copy of this book. And with that, if you haven't already, subscribe to us on iTunes, Stitcher, or more

using your favorite podcast app. Be sure to leave us a review by heading to www.codingblocks.net slash review. Yep, while you're up there, go ahead and check out all our show notes, examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel, we have channels like books and episode discussion and podcast chat, where we talk about all the sorts of stuff that we talk about on the show and architecture and this and that.

So if that's interesting to you, then you can send yourself an invite to that Slack and hop on in. Hey, make sure to hey no keep going just gonna say follow us on twitter at coding blocks they're heading over to cutting blocks that never can find all our social links at the top of the page sorry i had a i had a uh a moment of of i need to say this before i forget it yeah if you guys are going to be in any of our areas orlando or the atlanta area or something and you want to hook up you know holler at us let us know we you know we'll get out of the house area or something and you want to hook up, holler at us. Let us know. We'll get out of the house. We'll come meet you.

We're not totally socially awkward, so it might be alright. I'm so ready to get out of this house. You look like you have something to say. I was very tired. I was just kind of thinking when you said about the socially awkward,

I was like, okay, I'm probably going to be socially awkward, but, you know, that's just me. Yeah, it's all good. So, yep, that's it. Thanks.