Coding Blocks - Clean Code – Integrating with Third Party Libraries the Right Way

Episode Date: January 8, 2017

In this episode we talk about how to insulate your application at it’s boundaries?  What in the world does that even mean?!  We’re not talking about those boundaries where others aren’t allowed to touch your keyboard (although that’s a real thing).  No, we’re talking about making sure you make your code easier to maintain over […]

So a guy is standing on the corner of the street smoking one cigarette after another. A lady walking by notices him and says, Hey, don't you know those things can kill you? I mean, didn't you see the giant warning on the box? Guy replies, that's okay. Puffing casually, I'm a computer programmer. So what's that got to do with anything? We don't care about warnings.

We only care about errors. So true. I was wondering where you were going with that. You're listening to Coding Blocks, episode 53. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at codingblocks.net where you can find show notes, example discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. And with that, welcome. I'm Alan

Underwood. I'm Joe Zach. And I'm Michael Outlaw. All right. And starting us off with a little news here. We got some fantastic reviews thank you so much I'm going to go ahead with iTunes so big thank you to Deverell Dar Chickay Cody Monreal, Lou Ashby and Angelos M and you going to do these

I can I think Tim writes code Rainmaker52 I4 Tallat that's probably wrong uh tony tone tone why are you laughing like i mispronounced one of those tony tony tony should be that's yeah tony tony tony yeah man that's back in the day that was you don't remember them wait no tony tony Tony Tony has done it again. Yeah, you did say it right.

I was wrong. It's Tony Tone Tone. Tony Tone Tone. Oh, man. We all wanted it to be something else. I read one correct. Take that, Rainmaker52, with your easy name. Rainmaker's like, what do you got to bring me into this?

That's awesome. Thank you very much. I really appreciate it. And you can find the full show notes for this episode at www.codingblocks.net slash episode 53. And speaking of threes, we wanted to give a big thank you to everyone who voted for us in the 2016 podcast awards.

I think we ended up in third place in a category. I'm not really sure. They don't announce the the you know the losers i guess but i feel like a winner so what are you saying about this man that's we were the best of the worst yeah we really appreciate it and it was really cool i think that a lot of people were exposed to the name um there were a couple emails that went out as things got tighter and tighter the race got closer to finishing so um i think you guys helped us uh out a lot and we really appreciate it yep thank you and and joe did something pretty crazy here what was this yep and actually uh i

can't really take the credit for this um this kind of grew out of uh hashtag i made something the channel and our slack um and we created a Reddit. So if you go to www.reddit.com slash r slash codingblocks, we have a Reddit where you can submit links to stuff that you made or maybe articles that you think people might be interested in. And ideally, it's going to be a little friendlier community than slash r slash programming. It's going to be a lot smaller.

And we're still figuring out. Hey, what are you trying to say? Is our programming not friendly? It's a kind of a cesspool. Have you heard some of the conversations? There's a lot of really great articles. It's brutal. Yeah. And we've got some great moderators helping us out, including Zach Browdy. He's one of the moderators, also known as Reactionary. We've mentioned him a few times and we actually just wrote a little community spotlight, the first of

a series that we're starting here. Just saying thank you and kind of highlighting the awesome work that he's doing to teach other people how to code specifically React. Awesome stuff. And as always, if you would like some stickers, do send us a self-addressed

stamped envelope. You can go to www.cuttingblocks.net slash swag, and we have stickers and some other things there that are really cool. So if you're interested in getting stickers, send us that. If you don't have the address, definitely just send us a direct message on Twitter, hit us up on Slack, email us, whatever, and we'll get those out to you. And actually, can someone describe what a self-addressed stamp envelope is? That's kind of a common term here in America, but we've gotten some feedback from international people not knowing what that is. Oh, interesting. Okay. So yeah, if you mail us your own envelope, so basically take an envelope, address it to yourself, stuff it in another envelope that you'll send to us. Wait, you forgot to put whatever necessary postage. Oh yeah. You

want to put your postage on there, um, stuff it into the envelope that you send to us. And then we take that envelope out of the one you sent us, cram our stickers in there that you'll love. And we'll make your computers faster and we send it back to you. So yeah, I think I explained that. All right. It's like a very small nesting doll of envelopes. Yeah. The Russian doll envelope thing.

Yeah. Yes. There we go. All right. And, and we have our winner for clean code for episode 51 and that is Philip Thompson. So we'll be reaching out to you to try and get some information

so that we can send you your very own copy of Clean Code. So congratulations. All right, well, let's get into... Well, you know what? So tonight's topic is Chapter 8, Boundaries. But there was one thing I wanted to call out that was from the previous episode. We had talked about,

there was this conversation about return codes versus exceptions. And we had questioned like, hey, what about in a command line application, you know, where maybe the calling application is expecting a one or zero, like what then, right? So I actually got kind of curious and wanted to see what happened so turns out uh both can be returned in that scenario so you could have the exception thrown

and um at least in a dot net world uh it would return back an error code of 255 so i thought that was pretty neat awesome Awesome. Yeah, that's nice. Well, thanks for doing that. I totally forgot about it after the episode. Excellent. So let's go ahead and get rolling on this one, Boundaries. Yep. And this chapter was actually written by James Grenning,

who I did a little bit of Googling. He's done a couple of things. He's done a lot of things. But notably, he's written a book on test driven development for embedded c so you know that he is a badass you made it look like you're oh i forgot i did forget i wanted to mention one other thing about that that uh that topic was that in the case of the exception on windows for example it would bring up a an error dialogue saying like oh hey this application is crashed do you want to debug it or cancel it like you ever seen one of those annoying things yeah right that was in the case of the exception

being thrown but it also depended on how you called that though um so yeah whatever let's move on boundaries cool um so chapter written by james grading and when we talk about boundaries here in the book they focus really on third party and open source packages and uh and also um they mentioned later in the chapter code that doesn't actually exist yet so things that you think you're going to be working with that you want to kind of abstract but i did think it's really interesting that they didn't mention services which is now kind of my primary thought when I start thinking about boundaries and third parties, you know, I think about things like, I don't know, Splunk or, um, you know,

other services like payment gateways or whatever that I interact with over web services. And I think of those as being, uh, boundaries, but they're not so much third party libraries anymore. That's a, that's actually a really good point. And I think what we're going to talk about in here would greatly apply to those as well. And you'll find out why when we get into this a little bit. Yep. And this chapter basically just focuses on practices and techniques to keep those boundaries clean. And right away, there was an awesome quote that I loved in this one because it's so true, is that we seldom control all the software in our systems.

And I think really it should be like we never control all of the software in our systems because really I think in the times that we have controlled all of the software in our systems, I mean, like, what did you really write there? Fizzbuzz. Did you write? Did you? Did you really write there? Yeah. Fizzbuzz. Did you write? Exactly. Did you really?

I mean, honestly, because, you know, I mean, again, I'm not trying to take it to a stream, but I kind of felt like part of this kind of took it to a stream in this chapter because he's talking about some like built-in libraries of the language, right? Like the map. So in your Fizzbuzz example, I'm assuming you might have called some kind of console.write line or printf or whatever. So therefore, yeah, you used something that somebody else wrote, buddy. Yeah, that's true. Yeah, we'll get to that part about the built-in that he talked about working around, which was interesting. And I know situations where you've actually done something similar.

Well, I thought it was so coincidental that in the last episode like i completely forgot i'd actually already read this chapter before but it'd been a while and so when we were talking last time and i made the you know kind of extreme case about like well hey would you wrap system for example like referring to built-in yep uh namespaces or types and then when i went back and reread this chapter and he was calling out something that was built into the framework of his particular language of choice i was like oh wow i'm not the only one that went kind of extreme on that uh yeah yeah he totally did so there's a there's a quote that we have here. There's a natural tension between the provider of an interface and the user of an interface. Yeah, I really like this quote.

I'm the one that's in there. It's true, right? I mean, you, I don't know. You always feel like when you're working with something that's not yours that you're somewhat wary of it. I don't know. There is a tension there. Well, I mean, specifically what he was talking about in this chapter, though, or in this part of the book, was talking about how the provider wants it to do one thing, wants to solve one problem for as many cases as he can.

But yet we as the user, we have our very special need and that's the one thing that we want it to excel at and we don't care about all that other stuff we just care about ourselves because we're greedy oh wait he probably that last part i may have i may have ad-libbed on that well i know when i'm writing code i try to write things in a way so that it's flexible for the things that i think are most likely to change. Because as we all know, requirements always change all the time immediately. And that's why, you know, it's good for us job security, but it's definitely something to watch out for. And so it's something I think it was like, when I make something that's really more general, and this carries over, unfortunately, a lot of times into the UI, I'm thinking more about my set of things and not about the experience that the user is dealing with.

But, you know, you said a word or phrase there, though, that kind of hit a nerve. Because you said you threw in job security as part of your description there. Yeah. Have you ever noticed though that when, at least in real world situations, at least that I've had, whenever job security is used as a reference to some piece of code, it's never the pretty piece of code. It's always the code that's like, here's this 20,000 line file that nobody ever wants to have to edit. And anytime they ever have to fix or add or do anything to it, it's just a week-long endeavor to add five lines or to figure out where to put it.

It's the worst part of the application at all. So I don't want, if that's what job security is, I don't want it. Right. I think we've actually talked about that before in the past in that's not something you should strive to be there, right? Like you should write code because it's almost like, as you do things better and better and better, people will appreciate that. And it makes them want you to be there more, right? As opposed to being the only guy who understands that, that one file. And I know people joke about it, but there is something to be said for being that guy that helps build those standards or builds that clean code so that other people that come behind can get things done quicker. So I don't even know if it's that so much as it's just,

you'll spend all your time in that file because it's such a, it's so monstrous that yeah, you'll own it. You'll have job security because it takes forever to do anything in it. Yeah. So on this thing with the broad applicability and the specific need, this is actually where they started talking about wrapping the built-in feature, which was a hash map in Java. Just map. Which was a hash map in java just map which was a map in java and what they said is it

when you look at a map it has a ton of features right like you can add to it you can clear it you can you know you do all kinds of things with it right and it's because people who use maps might need to use them for various different things but if you have a very specific need and you don't want anybody to be able to modify that collection, then using the map may not make sense. And so it makes sense for you to wrap that map and kind of hide it through implementation purposes so that when you give that object to somebody, that collection of whatever it is that you were putting in that map, they can't clear it. they can't edit it, they can't delete from it, they can't add to it, right?

So that's where they were talking about wrapping it, and it's about your usage of it. So it was interesting, and I know you've done this in the past with like a cache type thing, where you'd wrap a class and the internal implementation of yours did something slightly different, right? Well, I mean, it's actually interesting that you brought that example up because I kind of, as I was rereading this section, I did kind of

think about that one in the back of my mind as I was reading it. And I don't really think that it would kind of apply because in my case, I was providing a class that internally I had a dictionary that I was using, but I was also, and the dictionary was never being exposed, but externally I was providing a dictionary interface. So I was still providing all the same functionality of a dictionary. Okay. And so I feel like that's where it kind of broke what James was saying here in that maybe you don't want to implement delete or clear kind of functionality, right? And if you're just going to do a one-for-one of the interface, then I feel like that didn't apply.

So it is interesting that you thought of that same example, though. Yeah, and they recommend basically avoiding passing around that third party, which we talked about a little bit in the last episode with the example of Log4Net, like how often are you going to swap Log4Net out? And so I do think you've got to take this with a pragmatic grain of salt. You know, there's third-party libraries that are more important important to wrap things that are more likely to change or things that are more likely to be finicky or need flexibility but if it's something that really common really basic then you can maybe be a little lax with that well so there's a couple points here that that i found

in this that was interesting one is that he was talking about this whole thing about wrapping map, which, one, okay, so going back to the previous statement about my extreme take on, hey, what if we were to wrap system, right? Or console or something basic like that. And his reason for it was that from one version of Java to the next version of java once they introduced generics then uh you know that's when that's when it hit the fan right right and uh and had they wrapped map then they wouldn't have been in painful situations and that the code bases that didn't wrap it, um, were, were, didn't get updated as quickly to support generics as the ones that had protected themselves against exposing implementation details like that. So then it kind of made me think like, okay, well, that's interesting. Is that because, is this a, cause there's some of these chapters

where we've talked about, um, things that were like, well, that's because, okay. Like checked exceptions. For example, we talked about checked exceptions in the last episode and we're like, well, okay. That's because that's a Java thing that it was like, you know, other languages don't really have, that's not really a problem in other languages. And it kind of made me think like huh what's another example of something that was kind of a core uh type in a in a framework or language that then changed from one version into the next and i i don't know if you guys have one off the top of your head but i i couldn't think of one right away nope but uh in this example um i think it's important to point out that they weren't using all the functionality of this map. They were only doing one thing with it. So it's a really contrived example where all they were ever doing is getting an item out of it. And so they were able to wrap that functionality because it didn't matter that it was a map or a hashback. All that mattered is that they could get an item. Correct. Yeah, in that example. Now, going back, though, I kind of take a little bit of issue with wrapping.

For what their purpose was of getting just that one thing out, sure, wrap it. That makes sense. But the whole idea of... Does it, though? Well, it kind of does. I mean, because if we're taking this to an extreme, then we're basically saying that your public API should never expose a type that isn't yours. No, right. You always said, no, no, I think it has to do with the use case, right? So if you

know that you only want people to ever use this product or this object and read from it, then totally build your own type to make sure that that only happens. And if map happens to be the easiest way to get data in there, then that makes sense, right? Like I can get behind that. I can see the value in it. What I don't like though, is where they said, well, if you just wrap map in the past, then you would have been set up for using generics in the future. Come on, man. Like that's, I don't feel like that's a fair statement because who's going to know that all of a sudden your types are going to, they're going to know that all of a sudden your types are going to, they're going to introduce this thing called generics, right? Like, I don't feel like that's a

good argument for it because the only thing I will say is, and we used to see it in.NET, .NET 2.0, I believe, before that, from before the next version of.NET, there were no generics, right? So you would constantly see these casting of data types. You know that you put something into a particular object. That hasn't gone away, by the way. And you'd always have to cast it coming out, right? Well, generics kind of solves that problem, which is what they're saying. Yeah, that's what I'm saying.

That hasn't actually gone away. That'll never go away. It depends on what part of the framework you're using. Right. But I guess what I'm saying is you could have totally done the same thing and made the same argument.net. But I feel like, like wrapping some sort of system thing saying,

well, because I'm having to cast all the time, you know, I have this future vision that somebody is going to add some generics. Like, I feel like that was a bad argument, but it doesn't necessarily have to be just language constructs, right? This getById method could have gone out and fetched from a database.

It could have fetched from a cache. It could have been a map. It could have been a hash map. So there's other reasons there. This is definitely a contrived example. In an example, map has 21 functions associated with the object. And all we ever want to do is just have something that we're, that we can retrieve our item from. Right.

So, you know, it's, it's nice as clean. Would I do it in the real world? Probably not. It would depend. I think,

I think wouldn't that be true? Like probably not. If you knew it was only you consuming that thing, but if it was something you're going to expose the expose the other programming departments or other users of your API, you probably would, right? Because you'd want to guarantee that they weren't going to cause some problem that you weren't going to be able to anticipate. going with this though especially when i brought back up the checked exceptions as an example was this one it felt more like a case of trust like there was a lack of trust because of this bat this prior experience in the language that the framework authors or language authors did to their community right and so because there was this lack of trust then the community felt

like okay well we have to build up walls around them because we can't trust them to protect us and keep it easy for future upgrades right and as a result like i maybe maybe that's not a fair analogy but do you understand what I'm trying to say? Does that make sense? Yeah. I don't think wrapping system things for that reason makes much sense. But the map thing I get, I don't know. Well, only if you're reducing functionality.

I get it in that case. But again, there's a part of this context that was about protecting it for future upgradability, which is the part where it's kind of take an issue with it like yeah okay then you go to the extreme that i mentioned where you like you never return back any uh built-in type now i will give you something interesting along these lines before we move on though that's sort of what they've probably done with uh the windows subsystem for linux right? I mean, really, more than likely, they're wrapping their subsystem calls. Stuff you would never change, right? Right, right.

I'm assuming that that's just a facade around it. It is. I'm sure it is. But, I mean, it is interesting when you talk about, like, you'd probably never wrap it. I guarantee you that's mostly what they are doing to a certain degree, right? Which a lot of... No, I mean, I think that's, what they are doing to a certain degree, right? Which a lot of... No, I mean, I think that's like different things

because they're translating... And this is why I say it's a facade pattern because they're translating a call from... Like a Linux call might have, let's say, to read a file from the disk. Then a Linux API call might take a certain format. Well, that format might be different. That same operation might have a different format in the Windows call,

so there's this facade in between, or an adapter that translates the Linux API call into the format that the Windows API call takes and then returns it back in the appropriate format. So I'm not assuming that that's this. I'm not interpreting that as the same case as like wrapping map to be some type that only returns one method. Right. Um,

but then there was also this other thing too, and that I kind of did a bad job on. I've explained to myself in the last one where even if you wrap your, these third party libraries, right? You, you don't get away from DLL hell, right? That still exists because your project still carries that other DLL with it, right? So obviously since we're talking DLLs, we're not talking about Java, but you know, if we're talking about, uh, you bring not talking about Java. But, you know, if we're talking about you bring in log for net. Right. So you have some kind of a package that you've written as a wrapper around log for net.

So last time we were calling this the CodingBlocks logging library. CBLL for short. So the CodingBlocks logging library is wrapping log for net. And let's say it's log, it's wrapping log for net version eight, right? And so you put that thing out there as a NuGet package and it's version one of the coding box logging library. And you could have a solution right now. I'm not saying this would be an ideal world, but you could have a solution where different versions of that might have our different projects within the solution could use different versions of that NuGet package.

And then you still have multiple, like when you would go to build one final project that could happen, but that's less likely. I think that's the whole point of wrapping a third party library, like a logger, right? You know, that for the most part, if we're talking about something like a logging library, those are fairly standardized nowadays. So if you write your, but if you write your wrapper, let's say that you're going to have, you're going to have a logger.warn, a logger.error, and a logger.info, right? Chances of you really making that many changes to your interface are pretty slim over time. Whereas that log for net library is being updated constantly,

whether it's for performance purposes or. Yeah. Your DLL isn't going to go, isn't going, might not be updated. But what I'm saying is that like your DLL is going to bring with it, unless you do something like where you compile it to where that other binary is included in, is like literally written into your binary, right? So it's an internal reference to it.

But nine times out of 10, that's not what you do. You would have both DLLs, your library referencing the other library, right? And so you're still going to, so when it comes, if you had multiple projects that all reference your library referencing the other library, right? And so you're still going to, so when it comes, if you had multiple projects that all reference your library, but yours is changing, comes into build one final project,

then there's going to be a consistency. Like you're going to have two file names, two DLL file names that are the same DLL name, but different versions. And so that's where the Carp compiler is going to get into a linking problem at the end because it's gonna be like well hey you got these conflicting versions unless now log for net's a special case because there are things that you can do within the law in the dot net um like in your web config or your, um,

app config where you can say like, Hey, if you see this version of the live of a DLL, anything in this version range treat as acceptable in this, right? But what were you going to say, Joe? Uh,

I was just going to say that, um, we're getting kind of into implementation details here, but you're absolutely right. We do bring along the third-party dependencies, but I do like that it's hidden from our code. So the things that I'm typing are largely ignorant of those things.

So I still think it's cleaner, but it's something to consider. Yes, so great. So the only takeaway that I was trying to make last time was that it doesn't solve the DLL hell. And that's the real thing that I was getting at. That doesn't go away. It does make it cleaner. Hence the title

Clean Code. I don't know if you caught that reference. And speaking of cleaner, sort of, one thing that I thought was really interesting is the next section talking about exploring and learning boundaries. And the reason I thought it was so interesting is because a lot of times when we talk about unit testing, we kind of give a few things, kind of free passes, license to not be tested. One of those things that

I've always said is exploratory code. It's hard to test exploratory code because you don't know what you're doing yet. You don't know what the code does yet. And so it's kind of something where tests aren't common. And this section is kind of saying the opposite. so it's kind of something where tests aren't common and this this section it's kind of saying the opposite so it's saying why don't you do your exploration and test and that way you've got a nice reference example of how to do it and also you've got a repeatable test that you can use for helping you migrate and whatnot and so i thought this was really interesting section my favorite part actually i love the idea but i can say that i don't think i've done that though i mean i've done that for things that weren't exploring a

third party like where i'm exploring my own ideas like well hey what if does this work what if i made it do this did that still work but never for a third party so i need to start you know the the thing that caught me on this is it actually seems like it's more important to do it for a third party. So I need to start. You know, the thing that caught me on this is it actually seems like it's more important to do it for a third party than it would be your own code, right? Because you don't know what their implementation is. And if they do upgrade and you have to upgrade your dependency, all of a sudden, if you don't have tests around it, you don't know if it's still operating the same that you expected it to before the upgrade so i thought this was an absolutely fantastic point that i'd never even

really thought about yeah and that's it's funny like i've even wrote like written um like program dot cs like started up a new project just to you know see how something works and kind of figure out before i go drop it in my code. And now I'm thinking, why didn't I make that instantly repeatable? Oops. I'm so glad I'm not the only one that's done that. Yeah, the takeaway from this one was really good. And the other thing they said too that I really liked was the whole idea that when you integrate with a third party, it's a bunch of unknown, right? It really is exploratory programming. And the thing is, if you don't put tests around it so you don't know what your expectations are,

when it gets out into the field, you end up spending tons of time debugging stuff that you don't even really have any idea how it works, right? And you've got no fallback. You've got nothing that says, this is what I thought would happen here, and this is what actually happened. So it was huge even from a productivity point of view. And if you write your unit test names like I write my unit test names,

you're definitely documenting your expectation of that API. Yeah, and stay tuned for the next episode, at least the next one in the Clean Code session we've been doing here because it's all about unit testing, and I'm sure it's going to be a good one. Cool. Tease. Yeah, and one thing I thought was interesting here, too,

is they mentioned spending a day or two reading documentation, which I thought was kind of – it gave me a little shocker because back in the day when I got a new payment API or something like that, that would happen. I would do a lot of reading, and a lot of times it was like coding stuff out of tables from the PDF, you know, sometimes you couldn't even copy paste in order to do that. And it's gotten so much easier, but just thinking about spending two days with so much stuff going on, especially in JavaScript world where you require a package, you just Google real quick, like, uh, you know, how do I talk to no SQL?

Okay. Found the top package. Let's try it. You know, if you can't get that working in five minutes, you move to the next one. That you found the top package. Let's try it. If you can't get that working in five minutes, you move to the next one. That's right. It's a different world. We're so spoiled. It's so true, too, man. We definitely want instant gratification. So if we don't immediately see a result

based off of that Stack Overflow answer, we're moving on to the next one. There's got to be another good one. Like reading documentation, you mean the readme file? Readme.md? You mean the google results uh yep stack overflow that's beautiful it is ironic that our next topic here is is the part of the chapter that was talking about log4j because what they go through is the whole okay well here it is let me plop it in oh that should work right and it doesn't

work and then it's like oh well it says you need this oh Let me plop it in. Oh, that should work, right? And it doesn't work. And then it's like, oh, well, it says you need this. Oh, let me plop that in. It still doesn't work. Now it's complaining about this. Dude, I've had the same exact experience with Log4Net every single time I have to do it from scratch. Because you look at it, you're like, oh, this looks simple. You throw it in there and nothing happens. You're like, what? Why is that not working? I've got the console appender in there i know i'm doing this and it shows in their document and then like an hour later you finally have it working you're like i should totally snapshot this and put it somewhere but i'm not

going to do it because i love this pain yeah no no totally your snapshot is the git repo and then the next time you need a new Git repo with Log4Net, you're just like, hey, what did my config look like last time? Oh, yeah, copy and paste. But then you're like, it can't be that hard. I mean, it shows right here. I will say that config for Log4Net, it seems unnecessarily brutal

than what you might expect it should be. Feature parity with Java. That's what I blame it on. But if you set up a learning test and you had a nice simple example there and some sort of test project that you could reference, then that would be the ultimate because you don't have to go searching around

through Git history or anything. You've just got it. But going back to the whole idea of learning this library, doing your experimenting tests and trying to figure out like what you want out of their api there was this this really great uh quote in here that was learning the third party code is hard integrating the third party card code is hard too doing both at the same time is doubly hard yeah it really is

and by hard uh we mean hard and also very error prone. Oh yeah, yeah. That's the thing that's really bad. So going around this whole logging thing, we've been talking about creating our boundaries so that it's things that we've created that we know about. And in the logging one, we brought it up in the last episode,

should you wrap your logging library? And we're talking about it again here with, you know, what we were just talking about. It was interesting that we're not the only ones that think about this. Will was in Slack, and he's like, hey, have you ever seen the, I can't remember the name of it, the simple logging facade for Java? Yeah. So there's actually, which is ironic because you'd be introducing a third party and that's the point that i made a will was like okay well fine then you're still using a third party yeah so now do you wrap that thing because you don't trust that i mean that because that's

the point of this chapter it's still a third party dependency period yeah wrap the third party dependencies it was it was interesting though that this is such a big problem and and something that that you don't even realize is a problem until you get stuck in it right and as soon as you're stuck you're like oh man why didn't why didn't we do things differently but it is ironic that there's an entire library out there just as a facade for all the logging libraries out there for java so um we'll include that in the show notes and it was interesting but it's been a while since i've looked at that uh what was it again i forgot it was the simple logging library

yeah why is that not working simple log for j simple logging facade for J, but that was, um, I thought that when it gave you the ability to swap them out without, uh, like using spring for dependency injection or something. Yeah. It gave you the ability. I thought it gave you the ability to swap out your logging on the fly.

Yeah. Let's just kind of configure it if I remember correctly, but I don't, I don't really know a whole lot about it. So, uh, I'm kind of scared to say anything. Yeah.

Alright. So, am I the beggar? I thought you were begging today. Oh, I can. Yeah, sure. Alright, go ahead. So, dear listener, we would greatly, greatly appreciate you taking that moment to leave us a review.

And if you have already, and you're thinking, man, I've got to listen to this again, I'm sorry. Send us a self-addressed envelope and we'll send you a sticker or two or three to make it up to you. But if you have it, we would greatly appreciate it. It really does put a smile on our face when we read those reviews. And it really means a lot to us. So you can head to www.codingblocks.net slash review and find easy links to the major platforms to leave us a review there.

And with that, it's time for my favorite portion of the show. Survey says. All right. Why is Joe's screen bouncing? He's running down, man. It was action. That's right.

I got you. All right. So our last episode, the survey was, do you listen to anything while you code? So your choices were music because i got to get my jam on or podcast because how else do you think i'm listening to this audiobooks because the books are always better than the movie tv how else am i going to stay up to date on westworld oh what how can you watch westworld and do anything except for just continue to exist that show that show turns me into filthy sludge like i don't even want to be alive like humans

are wretched uh shows amazing okay maybe there should be another survey about how wretched are we? Or, and lastly, back to the previous survey, the office background, because I'm actually paying attention to my cubicle neighbors and all of their gossip. So, let's see, who went first last time? Let's go with Joe this time. I don't remember who went first, but we're going to go with Joe. So pick one of those, Joe. What do you think it is music podcast audiobooks tv or just a background noise going on around you i'm gonna say music because uh there's a lot of chatter in our programming music channels and slack and i've never seen uh you know or heard anyone really talk about the office drama

going around them. That would be my second, though. You got a number you want to throw to that? Yeah, I think music has it with 30.2%. That is rather specific. Okay, Alan? It's music for sure, and it's going to be 30.21. For two on. That for two well played sir uh it's it's going to be somewhere north of 60 i say okay so are we just i'm just going to call it at 60 then 60 yeah

okay and remember we're playing by price is Right rules. So the answer is, it's music. Bye. Yeah, you should have stayed with your original answer there, buddy. 30.21, come on, man. 59%. Are you kidding me? Oh, no. Dude.

So Joe wins it. That's so close. Well played. Man, I'll take some solace. I was close. Nope, we don't play solace. I was close. Nope, we don't play by absolute. It's Price is Right rules.

He went over. Wait, we actually had an awesome conversation in Slack. And this was interesting for anybody listening. And this was in.NET specifically, probably C Sharp. Don't know if it's for every language. But did you know that rounding up in dot net if you're rounding to a whole number it does it by odds and evens oh yeah there's actually it's called a banker's rounding yeah it's a financial thing yeah like this conversation went on forever and they're like what is going on like sometimes it's going up to this and sometimes

it's going down yeah and i forget what the case is like you would expect it like sometimes it's going up to this and sometimes it's going down yeah and i forget what the case is like you would expect it like if it was something 0.5 you would expect that it would round up to two but instead it round like if it was 1.5 and you round it you would expect 1.5 to be rounding to 2.0 and instead it would round to 1.0 and that's because by default it uses bankers rounding because basically if it does one way for odds and the other way for evens and it ends up canceling itself out. So you don't really lose any money. So, so it's interesting. Weird that the choice that was made to counter like what you would learn in math though, right? Because you're like, okay, yeah, okay, fine. It's going to encounter, it's going to,

it's going to contradict one another. So then why didn't you do it the way that we're taught in math? Yeah. It seems to me like the bankers is a very specific case and if you are worried about those numbers matching up you're probably much more aware of that problem whereas everyone else in the universe thinks round means round yeah that was a again join our slack channel we have awesome conversations like this all the time um but yeah i thought that was that was great considering that should have been rounded up to 60 yeah i should have won that so no yeah you totally didn't um joe won that and by the way like how many people you think get the price is right reference though is that even a thing anymore like that that uh

you know now that bob barker's going Do we need to describe what that means? Because especially considering, I mean, we have a rather large international audience, and I don't know how popular The Price is Right is over there. Once you get on the other side of the pond. We can do this right. We'll find an excellent clip from The Price is Right on YouTube, and it will be in the show notes here. Okay.

Oh, by the way, by the way, we're doing video again, right? Are we? And we did video on the last one, we added my face on well outlaw has a microphone the size of his head in front of his head we're gonna get that out of there actually i'm gonna sneak in with a small mic next time um but yeah so on me episode 52 we actually have the YouTube video on that episode and we'll have this video as well. Um, if you click the link there. So I just want to throw that out while I was thinking about it.

All right. I'm desperate to check out these show notes cause I want to see these prices right highlights. I guess we know who's editing this one. Oh man. Hey, true turn. Yeah.

I was going to say, you're excited, but I think this is awkward. I'll find a YouTube clip. All right. All righty. So let's get into our next survey. So when you are PC gaming, what is your preferred weapon of choice? Is it the Xbox controller?

Any version? PlayStation controller steam controller anything made by logitech or just a plain old mouse and keyboard wasdy for life we're not gonna do mad you can't have wasdy in there what is it wasazzy is the obvious answer. For hardcore PC gamers, totally. If it's PC and keyboard, what are you going to do? Remap it to JKL? You could. IJKL, I guess. I just want to make sure that we specify for games that are designed for controllers. Because if you're playing anything else, if you're playing Rocket League, you need a controller.

And that's what this question is designed for but if you're playing like you know doom or call of duty or something you're using a keyboard and mouse unless you hate yourself i mean why there's console versions of those games where you could use an xbox controller or a playstation controller somebody with a keyboard and a mouse will smoke you every single time playing a first person shooter okay so we're saying that mouse and keyboard can't be a legitimate uh option in this game so so we gotta i gotta reword the question then to say when you're pc gaming for a game that was really designed for a console and requires that you use a console controller which is your preferred console why don't i just say when you're console gaming why don't we just say then you don't have a choice hey when you're console gaming? Why don't we just say... Because then you don't have a choice. Hey, when you're playing Rocket League,

what is your preferred controller? I think we've gotten to the meat of the question there. There are a lot of games that I use a controller for, surprisingly. This is why your stats are what they are. I thought you were going to say... Hey! Shots fired!

Oh, man. I am terrible. Oh, man. I am terrible. Oh, wow. Just kidding. All right, he weeps. All right, that scar is going to take a while to heal. All right, so what do we got next? All right, we're back to talking about tests.

So we're continuing with the boundaries discussion. We talked about learning tests, and we didn't really talk about, or maybe we did, talk about why they're better than free. Because the idea there is that you're doing the work to discover this and debug and figure this third-party library out. So why not say what you did for future smoke tests and migrations? It makes so much sense. It's kind of hard to argue against that one.

Yeah, why don't we? I'm telling you, reading this chapter and that last chapter, I feel guilty about not wrapping everything I've ever used. Even if it was a system-related or framework-related, language-related call, I felt like i should have wrapped it and i was bad for not yep yep and by having this battery test too like say new you end up upgrading newton soft which somehow happens all the time uh if you're in dot net land then you'll know if something meaningful broke um

which is pretty nice and uh yeah it just makes it easier to upgrade. So it's kind of takes some of that pain away, which is a big benefit of unit testing in general, right? Is it kind of takes some of the fear out of refactoring and changing things? Well, it takes, yeah.

So another way to say that too, is that it takes away the friction. Yeah. Yep. So it's just smoother because you know, you have more confidence in it. I mean, how many times have you heard,

Oh, we don't want to update that library. Right. Yeah. And it's because you don't know what's going to it. I mean, how many times have you heard, Oh, we don't want to update that library. Right. Yeah. And it's because you don't know what's going to happen. I don't, we haven't updated that library in three years and now we've waited too long. So it's probably going to be really painful when we do it and we don't want

to experience that pain right now. So we're going to, we're going to push that technical debt out. We're going to put it on loan for another six months and maybe we'll revisit this conversation then. Yep. So the unit tests really do give you confidence.

That is huge. Yep. And the next section was using code that does not yet exist. I like this. It's a funny way of saying code that you know is coming, like say you're working with a partner and they're working on something, but they're not really sure what it's going to look like yet because they're still figuring out some business requirements, but you've got a general sense of what you need or how you need to interact with it. So you can write a little class,

program to that class or interface. And then once they, once they finished their part, you can kind of make those two match up. And theoretically you shouldn't have to change too much of your code. Well, what I really liked was not even just making it match up right so so you coded to your interface and they wrote their own implementation and then in order for you to make your stuff work you just write your adapter to go in between the two right so in other words alan doesn't have to be dependent on my crappy implementation he can just have his interface and then he doesn't have to worry about when i'm changing mine all the time. Exactly. And that's

excellent. Your crappy implementation wasn't going to work for me. Although I will say there are times when you think you've got a simple use case and then once you get that library, it's totally different. And the example I always think of is PayPal. If you take credit cards now and then

you want to add paypal you think like okay easy i'll just you know it's probably just another processor but it's really not because they've got to jump out to that website come back to yours um there's a couple steps processing that's just different there's there's different trigger points than if you're just doing a kind of traditional credit card type thing and so it's not just uh the author abstract around the authorizations are completely different. So it is different.

But if you think about it though, from a programmer's perspective, if you're coding to an interface, right, go, go authorize the card and then go, go get money from the card. Granted,

the implementation is night and day difference, but your interface really should still be about the same. The people who are using your payment interface instrument there, they shouldn't have to worry about that implementation. The poor fools who wrote that adapter are going to hate themselves in life. How you doing? Right? But you know what I'm saying though? it still stands true. Your boundary should be your interface. And if you're getting to that.

Sorry. No, go, go. Sorry, I'm an interrupter. Yeah, I was just saying, with PayPal specifically, you know, with a credit card, you take their information and you go and auth. PayPal, you send them to a link that goes and collects information, bounces back to like a redirect page that has some information for you. And so there's this back and forth that isn't there. And that happens with OAuth stuff all the time. Like if you're used to taking, say, username and password for a login, and now you want to bring in something like OAuth like you do in Google or something, now you're bouncing them out and you're adding steps. And you're adding things that need hooks that you don't have yet in just a traditional simple scenario.

And so it's not just a matter of saying, let me pop this provider in. You've got to really re-architect the whole solution for it. Well, I mean, while we're pouncing on PayPal, I'd like an opportunity to jump in. So, yeah, because when you do capture that auth with PayPal, though, that auth can expire. So if you have a product that's on backorder, right, with a credit card, you get like what, like 60 to 90 days, I believe, for the auth. It's a longer duration. I don't remember exactly what it is. But with PayPal, though, that auth expires after 30 days.

And after that time wasn't it it was a short time frame no like i'm thinking in the case of like back orders okay the the off can expire and by the time you want to go back and re-auth then because of the nature of paypal there might not be money in the account because it's not on credit right necessarily right it might not be backed by a account because it's not on credit necessarily. It might not be backed by a credit card. So you might go to ship that thing and, oh, nope, now you can't, because you have to go back through and re-auth it, and now you can't re-capture or re-auth the transaction.

It's a real pain. Let's back up to the heart of this, though. So what you said, though, Joe, was I feel is something different, right? So when you're talking about you bounce out and you go to PayPal, like literally you left where you were visually at. And then you went over to PayPal and you did some stuff over there. And now you bounce back to yours. I feel like that's a totally different flow. So with that, though, you could say the same thing about like

Amazon payments, right? Because you can do the same type thing. So I feel like if that's what you're talking about, that's not just a provider. That's not a payment provider. At that point, you actually have another payment flow that you have to go through. And, and so I just, I wanted to make sure that we were kind of comparing apples to apples. Because if you're using the PayPal payment authorization gateway, similar to a credit card gateway, you can code to an interface. If you're using a payment gateway type thing, right? If you're using something to where you have to break flow from whatever your page is and

then move on, then at that point, you've actually got a completely different process. And maybe you code those two interfaces as well. And that's not going to fit with your payment authorized type interface. It's a different instrument totally, right? So I guess my point is there's always going to be differences. And as long as they somewhat fit in the same thing, then you can code it to it. When you're talking about a completely different workflow, though, you can't cram that into the same box. Which I feel like is what Joe was originally trying to say, right? You think you start out with credit card and that all your payment processors are going to look like this and fit like this. So you have this interface that looks a particular way. And then you're like, Oh, I think I can fit

in an Amazon, a pay with Amazon or a PayPal or whatever, or a Google wallet into the same interface. But then because of the breakout situations that you're talking about, then it ends up falling apart. And so you can get into a bad situation where you tried to do what you felt was the right thing of having this one common interface, but these other, in this case, payment formats don't really lend themselves well to that. So at what point do you take a step back then? So you've started and then you find out that, oh, okay, well, I can use it this way, but maybe they don't want to use it this way, or maybe we don't want to integrate it this way. At what point do you find out that, oh, okay, well, I can use it this way, but maybe they don't want to use it this way or maybe we don't want to integrate it this way.

At what point do you say, okay, I'm not going to try and put it into this interface. I'm going to create this whole other flow, right? Like is there a great divide there that you know of? Well, I think the idea is that you don't know there's going to be a divide yet. Like you think it's going to be simple and it's not. And I think that there's no really way to protect against unknown unknowns right things that are totally not you're not prepared for but the example that they gave in the book dealt with dealing with a very specific transmitter

that would have certain frequencies and whatnot and so that makes a lot of sense to do just kind of like a little mod class so that you can continue working while they kind of fill in those details and it doesn't really matter what calls you have to make to configure that object. You know, once they get it done, you can kind of fit that in pretty easily and the rough parts fit in. And even with PayPal or something crazy like that, I think having that kind of mock object or that stub in there while you're working is still a good idea. I mean, you might get, you know, totally blindsided, but you're probably going to be better off if you code to that more generic interface anyway. And it presents an interface where you use or an adapter

for to use if you do go to the Amazon route or some other way. And then you can also, if you do create those adapters, you can create tests on those adapters so that you know that they work as expected whenever you're getting them into your apps. So that goes back to that whole, you know, you test at the boundaries and then that way you can feel comfortable when you're deploying these things or upgrading them in the future. Yeah, I'll never feel comfortable with PayPal. Yeah. I love to use it. And

one thing we didn't mention is that if you do that kind of ghost object or adapter, then it also provides a convenient scene for testing. So you can easily mock or stub that out because now you're programming to an interface rather than implementation, which is just great for you in testing.

Yep. Alright. So So that pretty much wraps up this chapter, right? So clean boundaries is what they should have named this book. Oh no, it was clean code. Yep. And a code of the boundaries needs clear separation and uh we have tests that can define that expectation we can use wrappers and adapters those are the two primary mechanisms they use for kind of protecting ourselves um and it kind of harkens back to something uh i like to say um which is basically pushing the weird stuff to the edges or i would even say boundaries like pushing the weird stuff to the boundaries so if you've got some code that touches even like a database or a third party or a service or a package or a dll the four

the farther you can get that away from your core competency i think the better off you you're going to be um sometimes that's not practical or pragmatic but just as a general rule i like to push the weird stuff to the edges yeah i agree with that it reminds me of the onion architecture i don't know if you guys have ever looked into it but basically where all your models are down in the middle you have interfaces that are out from that and then all your actual implementation where things happen is at the very outside so if anything needs to change it's only out there it doesn't affect any other piece. Like everything can only keep going in towards the center. Nothing can reach out from the center.

So all your dependencies are on the edge. So it makes it very easy to decouple those things. I actually started putting together a project on GitHub for that and I don't like most of my projects. I get about 10% in. Well, at first where you were going, I thought you were

talking about the onion router, and I was like, well, that's definitely... No, that's a little random. So, who posted the question here? I put the question there. So, we mentioned there were two primary mechanisms that we mentioned as

dealing with boundaries, and they were wrapping the code to basically encapsulate it. And then we talked about adapting. And so I was just curious what you guys thought about when do you wrap and when do you adapt? I think if you're trying to like what they did with the map object,

that made perfect sense for wrapping, right? That, that was, I need some of the features of this but I don't want to expose all the features I love that adapting is more I think of that almost like the the facade or something like that where you know I have this interface I'm programming to but I need it to pipe through to this other one over here I don't necessarily want to wrap all their features I just want to you know create these little plugs that will allow this to pass through

to it i don't know that there's a clean i i can't think of any time when i would choose one over the other necessarily i guess i don't understand the difference because um even in like if you were to look up adapter pattern in wikipedia it says also known as rapper yeah do they call it that really yeah when you when you're so i don't i don't think there's a difference is there like what so you asked the question what's your distinction between the two yeah when i guess i was anchored by the the examples in the book so when i was thinking about the wrapper i was thinking about um basically hiding the implementation so i can only expose the necessary bits but when i think about an adapter i think about slightly tweaking or rather um changing the interface to an object to better suit my needs and then kind of adapting my needs

to one or more scenarios. Kind of like a power adapter, right? You might have one for US or you might have one for international plugs. Either way, my device plugs into one side and I can adapt it to whatever situation I need. So the wrapping, like literally, he took in the map situation,

right? Like you took a class and you wrapped it around this map class and you only gave it access to what you needed in there. An adapter is more, okay, I have my class over here. There's this third party over here and I'm going to create this adapter in the middle that I'm going to call that would just kind of proxy stuff back and forth. Right. least in my mind that's that's what I was thinking and it sounds like that's kind of where you were going so an adapter is kind of like a proxy yeah I think it's really similar just um kind of different flavors based on the context here but uh I think like I said um there's not a real hard distinction there just kind of food for thought cool all right do we like this resource uh a little bit a little bit yeah i think a lot

of people like this resource it is popular yeah i don't know if you've heard of it before. Maybe, probably. But we will definitely include a link to this in our show notes. This book called Clean Code. And by the way, my wife asked me, she's like, hey, are you guys going to get in trouble for going through the book and doing this? And I don't know the answer to that. But here's what I will tell you. Way to bring it up now. Well, I mean, this is...

I feel like we should have had this conversation off air. Yeah. Maybe, you know, a few chapters ago. So here's the thing, and this is what I will give you is like, you're getting our thoughts on this, but you're not seeing the code implementations that they have in the book. You're not seeing all the solid examples that they've got. So there's a lot that you don't get when you don't have the book. So I feel like if anything, we anything, it's like we do with most of our podcasts, right? Like we introduce the ideas, we give you our thoughts on it, but hopefully it triggers you to either want to go read the book or look into it or go find other

information, right? To try and fill in those voids here and there. So that's my take on it. I'd hope that the authors would see that as well and see that we're adding value. And if nothing else, you know, people that had never heard of the book before will now hear of it. So yeah. If not just send us a DMCA to comments at coding blocks.net. Oh man, it went straight to spam. That's weird. How's that happen? I messed up the filter. The filter looked for DMCA and threw it at the trash. I'm sorry. Speaking of possible copyright infringement,

just on Hacker News today, I saw a great link to someone who is adapting clean code specifically for JavaScript. So they kind of take some of the paradigms in the book and just kind of update it and tweak it and drop some of the things that are less applicable. So, for example uh use searchable names is a lot more important in javascript than it is in java so let's highlight it a little bit more but it's actually a really nice concise uh github account that uh is just really easy to read and it's got great examples of all the stuff we've been talking about so you should definitely go check it out

but wait a second java is already so pretty javascript javascript it's already so pretty like how are you gonna write bad code with it um i can do it trust me yeah notice how there's no uh topic on wrapping third-party libraries i need to require my require. Yeah. Trust me. No one can write bad JavaScript. Like I can write bad JavaScript. All right.

So it's that time of this episode for the tip of the Allen's favorite every other week is the tip of the week. And it looks like I'm up first. There you go. Explains the silence there. So I'm totally stealing this one. So earlier today, I was creeping on MSDevShow's Twitter account. I like to see what they're doing, doing a little spying, whatever, a little recon mission.

I think they call that stalking. Yes. I have a little crush on MSDevShow. I have a little crush on MS, I have a podcast crush on MS Dev Show. And I noticed that someone named at go fight and win, or I'm sorry about the name. My pronunciation is terrible. Anyway, they tweeted MS Dev Show

with a really cool shortcut in Visual Studio, which I thought looked really good. And then I noticed that this person actually has started a whole blog series dedicated to Visual Studio shortcuts. So I'll definitely be checking it out. And we'll have links in the show notes. But this one is pretty interesting. If you select some text

in your file and do Ctrl-M, Ctrl-H, it removes that text and replaces it with a dot, dot, dot. Ellipse? Yeah, ellipses. And so I thought this was really interesting because sometimes when i'm reading a really hairy function which you know shouldn't exist but it happens all

the time right a big hairy function a lot of times i used to like put regions around code and just kind of type in some notes as i was going along just to try and figure out what the heck is going on before i start making changes and so i like that i can do this control mh thing just get the stuff i don't care about out of my face while i'm trying to just understand. And so I like that I can do that now without being destructive and trying to remember to back everything out and accidentally leaving a space here or there and then that's sneaking into my pull request and outlaw calling me on it. So I thought that was a really cool shortcut control M control H. And to be fair for those things like, well, Hey, I think I could already do that if it's like already in, say, some block scope level, like a for loop or if statement or write.

And you're like, but I can already collapse that. But what he's describing is, let's say maybe you have a portion of code that isn't, that's in the same scope, but yet there's that portion that you want to collapse, right? So you can collapse just that one portion that you've selected. It doesn't have to be its own scope level. That's, yep. That's really cool. I didn't know about that one. I'll be trying it tomorrow. Although I'm sure, I'm sure uncle Bob's like, Oh my God, you have that many lines of code that you have to hide it in order to read the method? I feel like you missed a chapter.

Slack has been going nuts all week talking about how many lines are appropriate in a function. It's been amazing. I think we've answered that. The answer is one. I think it came to blows at some point. I'm fairly certain. It's reignited just tonight, actually. Oh, did it really?

Yeah, it's entertaining. And I believe it's all in good fun. I hope no one's getting offended, but it's been a really fun read. And taking it to both extremes, there have been examples like, how would you condense this back and forth? And arguments over whether it's actively

making the code worse or whatever. It's just been a really good and lively debate. We've enjoyed watching it. Yeah, we have a fantastic community of people. Which is a great segue because if you haven't already joined the CodingBlock Slack channel, you are truly missing out.

This is one of the greatest Slack channels in the world. No lie, you gotta join. And we're biased. I mean, we'll freely admit we're biased, but even if you weren't, they're seriously. We were literally, it was actually listed in like the top podcast or Slack channels. No, it is the top Slack channel.

So www.codingblocks.com slash Slack. You did it this time. Really? Oh, really? It's because you set a bad habit. No, I didn't do it. It wasn't my fault. Dang it.

It ain't my fault. Somebody buy that URL. www.codingblocks.net slash slack. I was so focused on getting the slash slack part correct that I messed up the URL. You did great on the slack part. Yeah, thanks. Did you notice? I'll mention that I'm actually actively trying to schedule a Rocket League game for after this podcast recording.

Oh, really? In Slack. Oh, you want some? Bring it on. Yeah, computer. Oh, man, it's too easy there because he's going to use his little controller. All right. So my tip of the week is this little thing called power bi if you haven't heard of it it's like

microsoft's little visualization type thing where you can bring in data and you can you can visualize it basically 9 000 different ways and the part that's amazing to me is you can download their desktop client for free and they also have this thing where you can do so much for free using their platform. So if you have some things that you want to visualize, and you have data coming from like disparate sources, you can suck that data in to the desktop client, you can even then massage the data in there, you can reformat the entire data stream that's coming in, you can then relate the data, and you can create graphs and visualizations all based off this.

It's absolutely killer. So if you've ever had anything, you have a little side project, maybe you want to look at your web logs and see how many people are coming or you've got different places where you want to get stats from and you want to be able to see it.

It is a killer tool. I've only messed with it for about four or five hours and I've already created some really cool stuff in there. So I highly recommend going and checking it out. We've got the link there. It's powerbi.microsoft.com. Go check it out, play with it. And again, it's free. Like it's crazy that it's free because the amount of power this tool has is unreal. And they have ways where you can publish to the web. You can publish to, like, mobile platforms. You can publish to all kinds of places.

Now, I don't know what the costs run into when you start doing some of that. But, you know, maybe you don't need to. Maybe it's something to look at. But even the free tier, though, isn't that priced based on a certain number of calls? No? Am I wrong? No, no. And it's confusing. So part of it is part of Azure.

If you publish it to the web and you can embed it some places, yes. There is, like, you like you get like 30 sessions or x number of sessions a day for free and then after that it starts costing like 10 cents per session in a session is it can time out after a certain period of time i don't remember the exact numbers but that can be it can get pricey yeah i i found what i was looking for it was based on the on there's a charge based on like the number of rows per hour that you – because I know that there was some other API calls that Azure has that are like that, too, where it's like, oh, hey, the first – you know, here's the free tier,

and you could do, like, you know, I don't know, 50,000 calls for free. Right. But that 50,001 call is going to cost you. Yeah. Right. Some of it's not that expensive, but, again, the1 call is going to cost you yeah right some of it's not that expensive but again the cool part is the desktop app as far as i can tell it's completely free and you can do tons of visualizations in there and if you want to publish it somewhere you can i mean let's keep this in perspective when we talk about signing up because if you want to sign up for the power bi

pro level it's ten dollars per user per month. Yeah, it's not expensive. Depends on how many users you have. Yeah, good point. It's not as expensive as Slack. Slack is expensive. Slack is a little cray. They cray cray. Wow.

So, yeah, really cool tool. Definitely check it out. I'm probably going to be doing a video on it here in the near future because I was able to do some pretty neat stuff with some stats. So yeah, that's it. So my tip of the week is going to fall into the category of outlaws a moron. So let's say you do a Git pull merge, you know, in some other branch into yours and you know, you have the merge conflicts and you take the time and let's say that you use a tool to do like a K diff three, for example. So you do a Git merge tool and you know, resolve all your conflicts, right? And then afterwards, you're left with all these.org files or however you would pronounce that spread throughout your directory tree, right?

Mm-hmm. And if you're like me, I hate those things, right? I forever now have been in the habit of, I will just type in, it's like secondhand, I would just type in find.name, and then in parentheses,

splat.orig, minus minus exec, rm, curly brace, curly brace, backslash, semicolon, boom, they're gone. Right? I don't know why. I don't even remember why. But a few weeks ago, I found myself reading the documentation for find and realized that there was a dash dash delete option. I'm sorry, not even a dash.

I'm sorry. I think I said dash dash delete. I just mean dash delete. There's a dash delete option. I'm like, are you kidding me this whole time? I've been typing in exact rim, curly brace, curly brace, and I could have just, so yeah, don't be stupid. Read the documentation. So curious why you don't reset or...

I guess reset wouldn't do it because they're new files, but clean FD deletes too much? Oh, I've never done that. No, you mean like a get clean FD? Yep. And now I just... I don't know. I'm weird.

I don't know. I don't have a good answer. Clean FD gets rid of other stuff too, so you have to do like a full rebuild. I'm weird. I don't know. I don't have a good answer. Clean FD gets rid of other stuff too, so you have to do a full rebuild. That's what I usually do and it's a pain in the butt. I guess, yeah, I don't really have a good answer because I do so many builds that I don't really care about

getting rid of the builds, but yeah. Find.name or find. minus name. And then in parentheses, splat dot O R I G minus delete. Man, I got,

I got a tip for you cause that's, that's a little too verbose. If you're in command line, no man slash S come on. You do all your development on windows. No, you don't. I do.

No, you don't. Let me see you do that dell command on that mac you're sitting on right now i'm gonna alias that bad boy that ain't gonna work that ain't gonna work it's so much cleaner no man nobody got time for that no i like to i like to keep my commands you know cross platform and at least with the git bash, then I can do that find on any platform. I've got a dumb question for you, Ella. Oh, God. Here we go. I'm a big fan of git alias.

I've got a bunch of aliases doing common tasks. Is it possible to git alias something like, say, git cleanup? Cleanup's probably better. Git remove or orange and have it actually execute something that's not even git at all just totally i think you're wanting a git hook but wait why wouldn't you just create an alias in bash yeah i could do the bash thing but i actually want to say like you know it just makes sense to me to have it in my alias file so i can just say forget okay clean or something and it just kind of you know maybe i just makes sense to me to have it in my alias file. So I can just say, forget,

okay, clean or something. And it just kind of, you know, maybe I could do get clean and it does the clean FD. It does a couple of different things. I don't, I don't remember. I haven't thought too much about it,

but I was just wondering if there was a way to actually kind of shell out through get, maybe he piped them together. I honestly, I can't say cause I don't like it because to me, get alias is just an opportunity to forget. Like, because that's really all I'm telling myself is,

Oh, I'm going to forget the real thing and I'm going to have this shortcut for it. And now when I go to this brand new system, then, Oh man, what was that command again? Oh yeah. Let me go and relook at my alias.

So I would rather just be in the habit of knowing what the real thing is no well it looks like you can there's a git config dash dash global and then then you do your alias dot whatever it's going to be so it looks like you totally can i because you asked that question i'm going to paste this into our show notes um yeah i'm just kind of curious because i know i i alias git commands all the time, so I'll say I have one called git ignore, and I think it was a tip once where it basically does the commands to temporarily ignore files, and so it won't see them as

changed, so I'll do it for some setting files and some stuff that I'll mess with sometimes that I don't want to accidentally check in. But yeah, I have no clue what it's doing underneath anymore. I totally forgot, which is the whole point of aliasing. I wanted to forget that weird dash dash slash slash stuff. Yeah. It looks like you can, you can even do things because the, one of the things that they're

showing here is they've got this, they aliased an unstage and it's got reset head dash dash. And then down below where they show using it, you can do git unstage file A or git reset head dash dash file A. No, but I think what he's talking about, though, isn't that. He's talking about aliasing multiple commands chained together. Where you do this command and do this command and do that command. Oh, they're not git commands, though. No, it doesn't look like you can do that. Well, someone let us know if there's something else I should be doing instead. Oh, they're not Git commands, though. No, it doesn't look like you can do that. No.

Well, someone let us know if there's something else I should be doing instead. I think that's where Git hooks are going to come in. Interesting. All right, well, I'm still going to put the link there. I don't know. I don't know. Like I said, I would rather just know the command. That way I can go on any system and just know what I need to know

rather than, oh, yeah, let me go look at my cheat sheet. Right. Coolness. All right. Well, that was it. We just covered chapter eight on clean code boundaries. Yep.

Keeping things clean, separated. So with that, be sure to subscribe to us on iTunes and stitcher or more using your favorite podcast app. Be sure to subscribe to us on iTunes and Stitcher or more using your favorite podcast app. Be sure to leave us a review. You can visit us at www.codingblocks.net slash review. And while you're up there, you can check out all our show notes, examples, discussions, and more.

And send your questions, feedback, and rants to codingblocks.slack.com. And follow us under it. Every time I say that, I get a little chuckle. I'm just waiting for you to specifically call out someone else on the Slack channel. Direct all your comments and rants to

James. Wow. Way to throw him under the bus. Nah nah he wants it and follow us on twitter at codingblocks or head over to codingblocks.net and we've got all sorts of other stuff we've got a mailing list we've got facebook we have reddit so

there's a whole lot of stuff going on so you can follow us in the channel of your choice totally till next time. Peace. Ignore warnings. I just got it. What? No, I'm just kidding.

That's awesome.