Coding Blocks - The Pragmatic Programmer – The Evils of Duplication

Episode Date: May 13, 2019

We take a deep dive into the various forms of duplication and jump aboard the complain train as Allen complains about Confluent's documentation, Michael complains about Docker's documentation, and Joe complains about curl.

You're listening to Coding Blocks, episode 106. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And check us out at codingblocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at codingblocks.net, follow us on Twitter at codingblocks, or head to www.codingblocks.net and find all our social links there at the top of the page.

And with that, I'm Alan Underwood. I'm Jay Zizzle. www.codingblocks.net and find all our social links there at the top of the page. And with that, I'm Alan Underwood. I'm Jay Zizzle. Well, how do I follow up that? You're M. Zizzle. No, that's not going to work. I'm Michael Outlaw. This episode is sponsored by the O'Reilly Software Architecture Conference.

What sets the O'Reilly Software Architecture Conference apart is that it is the only conference that focuses exclusively on software architecture and the evolution of that role. This conference is in the weeds with tech and cover complex topics from microservices to domain-driven design. It features different styles of learning from 50-minute sessions to two-day training courses. The O'Reilly Software Architecture Conference also focuses on soft skills. O'Reilly knows that architects are having to communicate complex technical topics and their merit compassionately to both upper management and technical teams. This conference can help you navigate different communication styles, like in the Architectural Elevator course. O'Reilly knows how siloed software architecture can feel. At the conference, you'll have countless networking opportunities so that you can meet people who are working on the same tech as you and offer personal experience and learnings that you can apply to your own work.

Many of the attendees are either aspiring software architects or doing the work of a software architect without the title. The conference offers a special networking experience called Architectural Katas, where you get to practice being software architects. Attorneys break up into small groups and then work together on a project that needs development. Visit O'ReillySACon.com slash blocks. That's O'Reilly S-A-Con slash blocks to sign up and listeners to this show can get 20% off most passes to the O'Reilly software architecture conference. When you use code blocks 20 during registration, that's B L O C K S two zero. And that's O'Reilly, the letters S-A-Con. All right. So in this particular episode,

we are going to continue with the Pragmatic Programmer. So we got another four-hour episode here for you, or actually, hopefully not. But we are going to continue on that. But before we do so, we like to give a shout out and thanks to those who took the time to leave us some reviews. Yep. So from iTunes, we have minimally viable pacemaker and dude, Scott and in stitcher, we have Brian P.

So thank you for all those who took the time to go up there and leave us a review. And if you haven't already, but would like to head to www.codingblocks.net slash review. And you'll have all kinds of links there to take you to Stitcher or iTunes or wherever your platform of choice is. And we greatly appreciate them and get a good giggle out of most of them. I was just thinking a minimally viable pacemaker mentioned that our attention span was similar to theirs. So I don't know if that's a compliment or not, but I'll take it. Oh, man, that's good stuff.

All right. So I want to mention quickly, I'm going to be talking about Jamstack in May at OneTug, which is our Orlando.net group. So if you're in the area, you should come by and attempt to kick me in the shins. Good luck. Very nice. And then it sounds like on June 24th, I'll be giving the Kafka presentation at the Intelligent Devices Meetup at the Microsoft campus there in Alpharetta. So if you would like to learn some more about Kafka, come on over. And I've also got potentially a talk happening at Connect Tech. I don't know. It's still in new status.

Nobody's reviewed it, so I have no idea what's going on. But there might be something going on there. I'll tell you, if you're around the Atlanta area, you've got to check this talk out because everyone who saw it at Orlando Code Camp was shook. That's what I do, man. Was that from the sugar high they got from it? I think so. I think that's what it was. I definitely had a method to try and get people interested in going.

What was the method? Give them all diabetes as part of that? That way they sit there with the shakes the whole time. Yeah, that's awesome. Awesome. So here we go. We are jumping into Chapter 2 of the pragmatic programmer. And the funny thing is, I didn't realize this until Outlaw said this just a little while ago is chapters one and two are like a third of the book. So, you know, there's a reason why the first episode was so long. We're actually splitting this one up a little bit better so that so that doesn't go as long but these chapters are pretty beefy so um this one's called a pragmatic approach and the first topic are evils of duplication oh yeah

real quick though i want to interject one nice thing about duplication uh sometimes uh it results in consistency so like if we give away a book on the second episode. Sorry, that was a terrible segue. I was trying to make it clever and cool. I see what you did there. If you leave a comment on this episode, you're likely to win a book maybe. Yeah, I like what you did there. It took a little sideways turn on me. Yeah, I dumped it on the ground.

Yep, great. Yep. So, leave a comment, potentially win a book. There you go. Now, on to the evils of the ground. Yep. Great. Yep. So leave a comment, potentially win a book. There you go. Now on to the evils of duplication. Yep. Before we jump into this, and this is why our episodes are so long because we just take these sideways. It's so long.

We haven't even said the first thing and we're going to go ahead and go sideways. Do we remember, I think it was in Clean Architecture, to where they said that duplication isn't always bad, right? Right. So we're about to completely contradict that in another context here. But, you know, if you're like – What was it? It was like accidental duplication or duplication that you think is duplication, but it changes for different reasons. Yes.

So incidentally duplicated. Yes. So, it wasn't the two things were actually the same. They just happen to have the same implementation right now. So, when you try to make these things do similar, when they need to diverge, you can start getting ugly. So, they really emphasize that you should try to break things down by purpose. Right. But I wanted to mention, too, number three before we get to the first item but the 20th

anniversary edition of Fragment has been released since recording or not released, it's going to be released, it's been announced. May 8th there's going to be a beta that starts and so I'll be interested to see what they have to say about this approach because I think especially with microservices people, the way people have

kind of thought about duplicated code has kind of changed in the last couple of years. And so we kind of picked a little fun last time with some of the things that they mentioned in other chapters that seemed a little old school. And I'm curious to see if this is one of the things that changes. So we'll be getting updated copies of the book and looking through the things that change. So stick around. Yeah, definitely.

But yeah, to the point of the duplication layers that you brought up, it was all about the layers, right? Like you could straight up have one layer that is responsible for talking to the database. The other layer is responsible for talking to the UI. Basically the same implementations, but at some point in time, one of those might change. You don't want them both to have to change. So yeah, at any rate, now we should probably jump into this book. So now we're going to talk about the programmatic programmer. Yes, there we go.

And the evils of duplication. That hurt my brain. The only constant is change. As we all know, we've heard that a thousand times. What they really emphasize is that we spend a large part of our time in maintenance mode. And I think unless you're very lucky, I think that's very much true. You definitely spend much more time reading code and maintaining code than you do originally writing that greenfield code.

Well, you're actually being nice about it by just saying it's a large part of time. They actually say we're constantly in maintenance mode. Yeah, they do. They say, yeah, right from the get-go. Even from the first line of code, you're kind of in maintenance. Cause how often do you like come out of the gate knowing exactly what you want everything to look like and exactly what's going to, you're going to do. And, uh, yeah, I mean, that never happens for me. Yeah. And that, that was a key point, right? Like the first day you start writing code and then

you talk to somebody and the requirements change. And so you're already going back and revisiting what you already did because assumptions were wrong or maybe the business requirements changed, right? Well, they summed that up great too because they just say that knowledge isn't stable. Right. Which I never thought of it in that kind of wording. You never think about knowledge as stable because when you talk about stability, it's like, okay, is this software stable? Is this server stable? Does it handle the load or whatever? Now you're like, oh, knowledge, it's as stable. Because when you talk about stability, it's like, okay, is this software stable? Is this server stable? Does it handle the load or whatever? Now you're like, oh, knowledge, it's not stable. And it's like, yeah, I guess it can fall on its face too. Yeah. I mean, when you think about the purpose of a business, typically it's to make money, right? And so the needs of that business is going to change a lot. Well, hopefully it's

to make money. Wait a minute, what business is in the business of not making money? Not for profits netflix amazon facebook and google well apparently tesla doesn't care about making money what they all make money uh man they lost what like don't be full 200 million dollars this last quarter anyways um but yet their stock price keeper i it how does how. I think we should start a business and sell some stocks and just lose money constantly. And the price of our stocks will just keep going up. I don't understand it. Anyways.

I think the trick is to make something while you lose the money. Yeah, fair enough. So you spend the money and then some to make something that doesn't recover your cost. I think we – let's make an electric car. And the trick is if you do it a billion times. Exactly. See, you get the rewards because it's economies of scale, right? Yeah.

Anybody wants to join in on this business plan, we've got it mapped out. Just go to ponzi.dev. Donation box right there. We need to set up a subscription service for it. Man, we have gone straight off the rails. Let's talk about how easy it is to duplicate knowledge. Yes.

So, in the documentation. Yes. Yeah. As soon as you write documentation, a lot of times you see like Javadocs or anything. So, in the documentation. Yes. Yeah. It's true. In the specification. As soon as you write documentation, like a lot of times you see like Java docs or anything, as soon as you write a line describing what that method or line does, then you've duplicated that item twice.

Now it's in the code and it's in the documentation. Yep. Let the diverging begin. Which is an interesting thing because I never considered, like when we talk about dry, like how many times have we talked about dry on this show, right? A few. Never once that I can recall have we ever referred to it as it relates to like comments or documentation. Yeah, right. And it's really weird, but if you think about it, it's true.

It's absolutely a form of duplication. But it's like how extreme do you get now? Right. I was going to say, in fairness, you typically have to have some form of documentation. If you're providing a product or an API or something that somebody is going to consume, you have to give that at least some level of documentation for the end user or developer, right? So that's not quite fair. We'll come back to it.

Yeah. But, yeah, they do stress dry here, which is we've talked about it and they say, don't repeat yourself, right? That's the dry principle. And they say, I actually like this, the way that they phrase this in the book was every piece of knowledge should have a single unambiguous representation within the system. And that's a really good way of putting that, in my opinion. Yeah, it fits nicely with the solid principles that the clean books really push.

It makes sense. They've got a notion here, too, that repeating knowledge in your code means that it's not a question of if you'll forget or if those things will drift. It's when. And I definitely agree with that. I tend to write a lot of wiki articles. Man, I hate when I spend a lot of time on a wiki and then some little thing changes and it's not updated and the whole thing is practically worthless. Even if it's 80%, 85%, 95% correct, across the whole wiki, as soon as one person hits that first stumbling block and like, this hasn't been updated, they immediately distrust the whole thing. Yeah. You're still too

nice though, Joe. Because you say it's like, it's a question of when. But, oh, I guess you did kind of say it like, it's not a question of if you'll forget, but when. But yeah, okay, fine. Because they're definitely making a point that like, hey, you're going to forget. You will. Yeah, and even if you don't

forget, somebody else will. Well, the next developer who comes behind you and has to maintain it you know when you move on to some other bigger project i mean we've got real life experiences with this and and this goes back to clean code like they said one of the code smells is if you see a bunch of case statements right if you see a case statement with a bunch of switches, a lot of times that will find itself into multiple files in your code, right? It's not the OO approach to something. You're no longer leveraging an object to do something, right? And so you have this switch statement everywhere. Well, guess what? That will get forgotten, right? There's no question. If you're switching on a type somewhere, oh, well, I didn't realize it was over here in that project as well, or in that, that CS file. So yeah, it, it, it just, it comes with a level of maintenance that you will forget

and it will cause bugs and you'll have no way of knowing that. I'm pretty sure it was one of the clean code books where, uh, I'm pretty sure it was uncle Bob that said that the only place that you should use a switch statement, the only place it should be allowed is in a factory. In a factory. Yep. Yep. That's exactly what he said. No other class or method should use it except for a factory class or method. Yep. And one of the things I did want to point out here is the authors felt so strongly about the dry principle is that they even called it out in this section and said,

Hey, this is one of the most important tools in a developer's toolkit. And one of the more, most important principles in this book, like they said, it's a big deal to them and they repeat it a lot, which is funny. They don't repeat themselves,

but they do. So anyway, yeah. Although I will say I was a little disappointed in this chapter because so many of the stories in the first section, they had cool little examples and stuff. And so the one on Dry just didn't have a cool little fox character or some parable or study about donuts. Boiling some wild animal. Yeah. So I kept waiting for it. I'm like, wait, where is it? I thought all these were really cool. Boiling some wild animal. Yeah, so I kept waiting for it.

I'm like, wait, where is it? I thought all these were really cool. I've got my spoon. Where's the soup? I think the world of pain from dealing with these kind of problems just kind of takes it out of your soul, and they just wanted to get through this piece. Well, I mean, they did talk about it in this part

where they were talking about even for the purposes of publishing the book, for making the book, they practiced the do not repeat principle as part of the book, the making of the book. I bet they spent a lot of time doing that, too. Quite honestly, it was probably not a challenge. And we'll get into some of the reasons. Well, now you understand when you go back through, what was it, the foreword or the preface where they mention all the different open source technologies that they used to make the book and you're like what would you need all that for just to write a book and then you're like oh i get it right right these are my people so yeah here it is this book was produced using latex pick pearl divips ghost view i spell gnu make cvs emax xemax egcs gcc java i GNU Make, CVS, Emacs, Xemacs, EGCS, GCC, Java, iContract, and SmallIFL using Bash and ZShell

under Linux. That's crazy. I don't know that I'd list the tools when I wrote a book. I don't know that I've ever read a list of tools when I've read a book. That was crazy. That's why it stood out in my mind. And I was like, why did you need all that? And now I'm like, oh, I get it.

So one of the important things to know is how does duplication happen? And they had four kind of key things that we'll dive into. One was called imposed, basically. And we've all been through this. Programmers feel like they don't have a choice, right? Like you've got to duplicate it because you don't have the time or whatever it is. But if you don't have the time, then that would just be like one of the other ones, right? Like we skip ahead to impatient. I don't know that impatient falls in there. I don't know.

We'll cover it. The inadvertent, you didn't realize you were doing it. The impatient, which was more lazy. I don't know. So lazy was, you just don't feel like refactoring something. I don't know that it was necessarily a time pressure type deal. So I don't know. That's where we can get into that one in a minute and enter developer. Like when you have teams of people working on something. And so you don't realize you're duplicating something because Outlaw's writing the same thing that Joe's writing that Alan's writing. Well, this is why I'm kind of harping specifically on the imposed one because

the other three, inadvertent, impatient, and inter-developer, all made sense to me. But imposed, it's not specifically a time crunch that you're under it's just that the developers feel they don't have a choice right and that the environment seems to require duplication and i was like okay i'm i'm still even now as we talk now i'm trying to like mentally map that to an example of like what do you mean like what imagine if you had like a a firm like a server team and a firm firm UI team and you knew that the UI did some logic that now you need down in the server. But you don't feel like you've got the authority to make them change their code to just pull their stuff from the server.

So they both happen on the server, which is the quote unquote right answer. So you just end up reduplicating the logic down in the server because you don't have the ability to make them change theirs and you don't feel like you have a choice okay i guess i just haven't worked in that kind of environment though but okay i see where you're coming at it where it's like where you have like specific teams that are split up and you know nobody's full stack that can make that call yeah and we'll even we'll even get into some of the things that they say is sort of imposed by choices that you really can't control at all either. But let's jump into it. So some of the possible causes of imposed duplication and some of the possible solutions.

So they kind of start off in like a random order. Like they start off with some of the solutions, then they go into some of the problems or what causes it, and then they go back into more solutions. So they kind of start off in like a random order. Like they start off with some of the solutions, then they go into some of the problems or what causes it. And then they go back into more solutions. So, so bear with us here. We didn't organize it. So, um, one of the ones that I thought was kind of interesting and I really liked this one and I wish it was done more is using code generators to build code from some common set of metadata. I like that. You know, I did the one-off script stuff, but I don't really set up like firm generators that often.

Like those times, like I'll have some data, I'll use like a SQL script or a quick PowerShell script to like generate classes or some basic stuff. Definitely like an entity framework kind of example. But then that's where it kind of dies. Like ORM type examples come to mind, like super easy, like done often. You know, for code generators. Outside of that, I'm trying to think of some examples. I mean, one of the points that they made about that was it's not a one-off type thing, right?

So something like an ORM is a good example, I think, to where, you know, if you make a change to a database, you're probably going to run your generator again to create your classes or whatever. That's a good example of constant code generation so that you're not duplicating your efforts, right? Like you didn't go create a table and now you're going to have to go write some boilerplate class on the side. You run your generator and it goes. And I agree. I think that's one. I mean, um, I know I've definitely done things where I'll write like things based off the database to try and create, you know, other things for me, but a lot of times people end up do writing a lot of

boilerplate code because they don't know better. They don't have the tooling to do it. I don't know. I don't know the right answer. I mean, I definitely, okay, let me put it to you. Let me put it like this. I definitely conceptually like this idea, right? Because you get consistency from your code, right? Like, for example, let's say that we lived in a world where maybe we treat our database as a source of truth. And so any changes to the database, we have a generator that'll go and write out new classes for the C-sharp layer. And it'll also write out maybe we have something similar in our JavaScript layer, right?

So our UI layer that might have to get these know, get these objects from the C sharp layer. So they're like, you know, consistent communication. Right. So I kind of like that because now you have consistency in what's happening. And maybe that buys you some compile time checking, too. It also feels like it kind of goes against some of the onion architecture or even uncle Bob's like clean architecture approach though. Like depending on how far you were to take that, like especially when I mentioned the JavaScript cause cause now you're, I mean maybe it's okay,

but intermixing your dependencies a little bit, but you could, you could abstract those. I think the part that jumped out to me that was a little bit more sideways on that was, I mean, if you think about a form, right? Let's say that you just have some simple form like our newsletter that you can sign up for, right? So you have a name field, you have an email field, and then it's pretty simple, right? So if you think about in terms of your data storage, you're going to have an email and a name field. And then in your C sharp layer, you're probably going to have some sort of DAO or, you know, data object that's going to be name, email, whatever. And then on your UI,

you're also, you're going to have the physical representation of those fields and then a submit button, right? So it makes sense to be able to generate that stuff. But this is where another set of podcasts that we did has me not liking that as much. And it's the domain-driven design thing. And this is the part that always bugs me. Of all the books that we've done, that one was probably the most painful to read, in my opinion. It was really hard. But the concepts in it were so good to me. You're writing code to address a business case, right?

You're not writing code to mimic a database. You're not writing code to mimic how you think about code. You're writing code to solve a business problem. And code generators can't do that for you. Right. They don't encapsulate that. Right. Like it's easy to say, okay, take the fields from database, generate a C sharp file, generated a JS file.

But all you're doing is passing along the data storage. You're not passing along business knowledge. And that kind of bugs me. So I love the generator. passing along the data storage. You're not passing along business knowledge. And that kind of bugs me. So I love the generator. And at the same time, I'm kind of like, eh. Except, can I put an asterisk on that? Please, please. Because, I mean, definitely skipping ahead here.

But later on in the book, and we'll dive deeper into this. You're cheating. No. Because I haven't gotten there yet. Well, that's not my fault. But later on, they do talk about creating your own

language. Okay. Which, if you remember back, Robert L. Reed, I believe was his name, we did the series on how to be a programmer. Oh, yeah. Do you remember that series? I do. And one of the things that he had said was you should, like when you become an advanced programmer, it's like Do you remember that series? I do. And one of the things that he had said was you should like when, like when you become an advanced programmer is like when you create your

own language. And so they, they talk about this idea of creating your own language that could be used that's in the domain. Right. And you could eventually make that into code. So if you combine the two ideas of the generator and this mini language, then maybe you could also generate code that is like that. It kind of reminds me of, do you remember? I mean, it's in a variety of different names, but like, I think it's spec flow cucumber. Yep. There was another one too.

I want to say pickle, but that's not it. Name your random vegetable. We'll get there. Well, yeah, pickle is something totally different in Python. But it was cucumber JS, if I remember right, spec flow in C sharp. And I feel like there was another name for it, but in another language, and I can't remember it. But basically where the idea was that you're writing your – it was mostly for test cases, but you could write them in more of like a pseudo-bus probably possible to do that, to create your own language to do it. But, I mean, you're talking about an extra layer of complexity there, you know, for doing it.

But it would probably be a killer thing. But I guess that was my point, though, is like the code generators just using it for something like EF just exposes your storage engine all the way through your stack. Well, again, if you keep it isolated, though, to just that one layer, right? Well, the EF code generator would create your C sharp, but if you have a generator that then just mimics a form on your JS, then you're kind of trickling it down through every part of your stack. That's where I was thinking it would be gross. Yeah, you're right.

Yeah, I want to mention a couple things. So DSLs, domain-specific languages, they don't have to be like English NLP type stuff. They can be like really simple basic commands. Like sometimes if you've got a couple of commands that users can kind of compose in a way, then you can kind of open up those tools and let them do those few basic commands. And as long as you support those, then that's a lot easier than trying to kind of, if else, for loop your way through solving some problems. So it can be really nice and it doesn't have to be complicated.

I also wanted to mention that language support has gotten a lot better for things like link is what I'm thinking of on generics and C sharp. So a lot of things we used to have to use co-generators for has gotten a lot easier because now we can just take angle brackets T and as long as that T meets the constraints to whatever we need to do in that function, then we can do that stuff without generating all these classes then we let the kind of compiler do its generation for us that was it very nice sorry i was so i had another tip that just hit me and i had to put it down in the notes oh no worries okay so so going back to the duplication then, I mean, we kind of already mentioned this one, but duplication in code, right? So, you know, you can break the drive principle.

The documentation. Oh, wait, what did I say? Duplication. Oh, yeah. It's still duplication, but yes, the duplication of the documentation in your code. Wow, that probably made a lot of sense. So, yeah, the documentation in code. So your comments and stuff, right? I picked a heck of a day to quit drinking.

No, just kidding. I like that they mentioned that bad code requires a lot of documentation and that's something I agree with. As I've mentioned before, usually when I'm doing comments it's because I'm either excusing bad behavior that I know is bad or else I'm, you know, I guess that's

my main reason for doing it. It's like, this is something bad I know, but it's not worth changing right now for whatever reason. Don't hate me. Yeah. I mean, we've shared this story before. Like I got a screenshot from my buddy, Will, after I'd left the company and he sent me a picture of my comment where I was like, I have no idea how you get here. Oh, yeah. That was still one of my favorites. I mean, this was interesting, though. And I brought this up to you guys. You might not have even realized it was in reference to this portion of the book, but in our day jobs.

Because there was some code that I was working in and I just kind of was following the, you ever, you ever noticed, like sometimes you'll work in a code base that maybe you didn't create, right? And whatever the established pattern is for doing things, it's like, well, now I need to add some code to it or modify some code to it. And you're like, well, right or wrong, I'm going to like follow suit. Right. And so in this particular set of code, uh, method like functions were, you know, had comments about like, uh, what the function did, what the returns, uh, the arguments, you know, regardless of didn't matter, you know, if it was obvious or not, or how big the function is. Every one of them were commented on. Then I was reading this after adding some new functions to it. I'm like, well, there was a statement in here that really hit home with me.

It was like, okay, the dry principle tells us to keep the low-level knowledge in the code. Yep. Right? Where it belongs and reserve comments for other high-level explanations. And so the way I interpreted that then was like, oh, so for privates, for example, or internal kind of functions that you don't intend to be used elsewhere, you shouldn't be commenting on those. Like you shouldn't have whatever your equivalent of, this happened to be in Python, but like if you're thinking C sharp and you have the summary documentation, like whatever that type of documentation is called in your language of choice, then you shouldn't have it if it's a private level function.

Like the function itself by its names, if you're following everything that Uncle Bob has ever taught you and what this book is teaching you, then it should be self-explanatory enough to not need a comment on it. Agreed. Fully agree. And the comments that you do put on your code, if you're going to put comments on the code, it should be those things that are going to be the public interfaces to the outside world.

Yep. I fully agree with all that. Okay, I got to go make a pull request then. I saw here they mentioned possibly generating code from your documentation. I remember when I went to school in the whenever 60s felt like it, they were talking a lot about

UML. I didn't know at the time that that ship had already kind of sailed, but they were talking about UML being the future and how people were going to draw diagrams and it was going to generate all your code for you and it was going to be wonderful. It didn't really pan out that way. I did think we've come a long way towards generating really good documentation from

the code. It just reminded me of one of my favorite recent query languages, or DSLs rather GraphQL that's a generated language based on whatever you're kind of feeding it it's type safe and it generates really nice documentation and it's strict so like you can't make a lot

of mistakes with it you know it'll catch you but at the same time it is actually generated code so it's a pretty good example of something that's a DSL that you kind of generate and help build and i just thought it was kind of cool you know you say that and i'm also wondering like too now i'm thinking and i'm like you know uh i wonder if swagger or swashbuckle for dot net would also count if you've ever used those where it like auto documents your api

have you ever you you for you do you recall what I'm talking about? I do. The package I'm talking about? Yeah, as long as you comment your public methods, then it'll create the documentation that people can see in the UI. Well, when I say auto-documenting, I don't mean necessarily the summary documentation being included, but I just mean it gives the user an interface to where you'll see like here's an api here's what it takes and you could test it and everything like right from another interface right because just like with the graphql example that joe's talking about right like it doesn't give you documentation per se right yeah you just generate your documentation and then the only stuff that you as human do is fill in lots of examples,

tons of examples in your documentation, man. You know what? I just tweeted about this the other day. Cause I, man, living in the Kafka world is so frustrating. Actually,

I'd say Java in general, and maybe this is just completely wrong to bash, but, but man, I feel like, I think honestly, what it is is I'm spoiled by Microsoft documentation because what I feel like they do a really good job of and my, and part of it might just be because they've open sourced it. And there's a lot of people like us that'll go do pull requests to it or Steve R Dallas. Like he's constantly in there updating their docs.

But if I go to a method, it's not because I want to see the signature of the method, right? I could see that in my IDE, show me how it's used. Like I get so mad when I go to some documentation that a company's written, Confluent, and there's no example. And the summary information on the page is so basic that it's like you added zero value. As a matter of fact, you added negative value because you've now wasted 10 minutes of my day. And now I'm angry about it because now I've got to go look up a stack overflow and hope that it's not out of date. Or closed. I'm so angry about this still.

Like I'm getting hot thinking about it. I've spent so many hours in this land of no examples now that I'm like, man. Oh, God. I can't wait for my turn. Okay, go ahead. I think I'm done. Like I'm still, man. Oh, God. I can't wait for my turn. Okay, go ahead. I think I'm done. Like, I'm still mad about it. When I tweeted it the other day,

I was ticked off. And there were a lot of people that were like heartening it. Yes, yes, this. We just talked about this maybe yesterday or the day before. So, okay, Confluent is your example. For me, it's Docker documentation.

Like, the Docker documentation, it's Docker documentation. Like the Docker documentation, it's so, there's a lot of it, okay? There's a lot of it. But you still read and you're like, what? Like if you just gave me like one, maybe two different examples, it would have explained a lot more

than all the other. You just used 10,000 words and I'm still like, what? Yeah. Yeah. There's like 800 flags that you can pass into it and they'll show you examples of two of them. Yeah. And never like, here's when to use this one versus when to use that one and why you need that one,

but not this other one. And oh, these other three, well, you're only going to need those on days that end or that start with a T. And you're like, but why? Why days that end or that start with a t and you're like but why why does that even import it like yeah don't you love this stuff it'll be like host name string and you're like does that include the protocol does it right let me like search around does it do i put the port there is there another okay i i look for the word port but it's actually um source prt or something stupid you're like oh okay that's why i didn't

find it and no there's a separate spot for it. Yeah. I swear to you. I, I think as have like, we're not new to this game, right? Like we've been doing this stuff a long time.

And to this day, like I would rather you give me a piece of code I can copy and paste and say, Oh, let me form this to what I need to do. Then give me all the documentation in the world that still gives me no clue of how it works. Because like, let's be honest, like the flag stuff that we're talking about. And this, this also drives me crazy with Linux.

And then I'll get off my soapbox is anytime you ask for Linux help anywhere on the internet, you get RTFM, right? And that makes me want to destroy their computer, my computer, and the internet completely. And the reason is is because when you say, you know, dash dash man or whatever to go to the freaking manual page, there's 5,000 flags on the page. Oh, but you can only use some of them in conjunction with others.

What combination of flags makes this thing work, right? Like, oh, man. I mean, this is all similar. Okay, sorry. But this is all similar to one of the comments that's made here, which isn't, it's not quite where you and I are talking about it, but it's kind of in the same similar vein

where it's like untrustworthy comments are worse than no comments at all, right? So like if you provide documentation, but it doesn't, you know, it's not, you know, no examples or whatever.

Right. Then it's in a similar kind of vein. Right. But yeah. Where are you? Oh, I'm sorry. No,

I was going to complain about curl. Oh, please do. Please do. Hey, we're not done complaining. Go ahead. You haven't gotten in on the complaint train here.

So I'll just tell you about the things I was going to complain about and then I won't have to do it. But inconsistent flag names, sometimes it's capital, sometimes it's lowercase, different commands using different flags for different things. Everything's strings, you know, anyway. Yes. Yes. All those things. But you guys mentioned generating your documentation from your code, but this whole point is about generating your code from the documentation. Yeah.

Which flips it on its head. Which goes back to the spec flow thing. And that's kind of an interesting thing, right? Like if you could truly generate code based off documentation, which, by the way, this book was written back when UML and Rational Rose and all that stuff was a big thing. So that's probably why they were driving here, because in theory, it's a great idea. Apparently, it never really worked out that well in practice, because here we are 20 years later. So here's my request, Andrew Hunt or David Thomas,

if you are listening and you can hook us up with the beta that was just released, email comments at coding blocks. There we go. So getting back to the thing that you said earlier, like, you know, I don't really understand the imposed. This one was interesting because this was a real world example of where you have no choice. So in languages like C, C++ and Pascal, they require that you have a separate header file and a separate implementation file, right? And so you have duplication that you absolutely cannot avoid because that's the construct of the languages. So, you know, that to me isn't as bad, right? Like, you know, that the language forces that, whatever, you just do it. Now they did say,

and I thought this was really important, don't put the same comment in both places, right? If you have a header declaration, don't put the same comment on there that you do in the implementation one, because what if you change what the implementation's doing or what if, you know, something and that comment's not going to get updated and now you have lies in your code again? Yeah. Well, they actually like took it even a step further there, right? It was like, put the public-facing documentation in the header file, but the nitty-gritty details that another developer coming behind you to maintain it might need to know in the implementation. So kind of have double comments for the same thing, but, you know, yeah. Yeah, totally. Yeah, it's frustrating.

All right, so page five. I'm just kidding. A couple of common causes of inadvertent duplication, possible solutions. Accidental denormalization of data. You have the same attribute in multiple layers that are related. We talked about the JavaScript server-side thing. That's what they're talking about there. And they mentioned this can happen in their things with

mutually dependent items. So they use a line object with two points and a length attribute. And this is kind of like the, have you ever heard of that square rectangle problem? Where you change two and the other... Anyway, that's a whole other segue. But we've talked about it before, so I'll skip it.

But the idea with the line example is like you have a start, a point, and an end point, and then the length. But if you change the start or the length, then it has an effect on the other. I said that all wrong. Oh, my gosh. You did say that all wrong. That's amazing. Oh, my gosh. Just someone save me.

Well, let's get back to the accidental denormalization of data because I thought this one was really good. They used a delivery truck and a delivery route as an example. And on the delivery truck, there's a driver. On the delivery route, there's also a driver. And they said, well, what if somebody calls in sick one day? Now you have this driver that's both in the truck and the route. And it was an unintentional denormalization of data. So maybe the truck never has a driver.

Why does it have to, right? Or maybe the route doesn't. You pick one. But that was the accidental denormalization because you look at it, and as things change, do you have to change it in both spots? What does it mean if you don't? So that one was interesting. Now, what he was saying about the points, this one was kind of, I thought this is impossible to explain basically. Actually,

I didn't think this one was that bad. You butchered it really well. So the point of this one was all about the data storage. And we've talked about this in the past with encapsulation, right? So in the first example, they had, you know, let's say a rectangle. You had two points or a line. I would do the line. There was a start and an end, right? There was two points, and then there was a length. Well, the problem was what they had for the length was it was just a variable that had, you know, a long.

Just another property on it, yeah. Right, and so what they're saying is what you've kind of done here is you've set this thing up to where the length is truly dependent on those two points. So that means that if you change a point, then that length should update. And by just making it a value that anybody can willy nilly update, then you've kind of screwed up here because now you've, you've created this disconnect between your attributes on your class. And what they said a better way to approach this is you have your two points, and then your length is nothing more than a calculation. So get length would actually say, hey, give me the difference in the X, Ys and all that kind of stuff.

And then that way it's a calculated member. I don't know if I count that as duplication as much as I just would consider it like bad design though. Well, maybe, but then they get into the fact that maybe it's not bad design. Maybe it's purposeful design. And that's if, let's say, let's say that it's something more expensive than a simple XY, you know, calculation. This is something that actually requires some compute power, then you might choose to cache that thing. So at that point, it makes sense to make it not a calculated member, but you build in some, some sort of caching layer behind

it, right? So you have a private variable that maybe is your long that you're storing, but then the actual get will say, Hey, has that thing been set or not? If it hasn't, then go ahead and run the calculation. If it has, then just retrieve that value. Well, it's a really interesting, cause there's three approaches that we do just ran over there like quickly, like first was the worst one where you've got to start in and align. They're all individually settable and then things get out of sync. The second one was like, Oh, just have the, the size be a derived property property and so whatever the changes in the start or end will automatically be reflected now we're saying well actually if you've got

performance issues you're concerned about a smarter way of doing this would be to move the brains to when the start or end changes and then have the only property that's ever actually or you know just dumbly stored is the actual length. So it's kind of funny to go through three totally different ways of saying it. And I think the last one was probably the best overall. It's just kind of funny to think about those things changing in implementation. They make the point though of saying that

when you choose to violate dry because of these performance reasons, the trick is to localize the impact, right? So like in your example that you gave, like you're trying to localize it by some accessory that would say in your example that you gave, like you're trying to localize it by some accessor that would say like, Hey, have I already made this calculation? If I haven't, then fine, I'll calculate it and return it. Or in Joe's example, he was saying like, Hey, did one of these things change? If they haven't changed, then I already know what it is.

Otherwise I need to recalculate it. Yep. And, and what they say is with the localizing or probably, as other people know, encapsulation is don't expose that length property itself, right? Right. So you have your get accessor, like he's saying, but nobody has direct access to that length property. Now, it's kind of weird in a language like C Sharp where we have the syntactic sugar to where, you know, you probably wouldn't even create like, Oh my God, that's another thing about Java for better or for worse. Like if you have a bunch of member variables, then you're going to have gets and sets for all of them basically. Right. Like that's just sort of the contract properties. Yes.

So we have auto properties in C sharp. So you might have length, but your get implementation would do this stuff for you. Right. So even though when you say, Hey, you know, my, my line dot length, but your get implementation would do this stuff for you, right? So even though when you say, hey, you know, my line dot length, you're not actually accessing the underlying thing. It's calling a get method for you. So, you know, there's some pretty things that happen for you in the C sharp world, but it's the same concept of encapsulating that. Yeah, they do call out that like where possible always use accessor functions to

read and write the attributes and that way you can make changes so if you decide later you want to make a caching change for example like in your example right you can easily introduce that change without it being a huge refactoring effort because now you know if before if everything was like let's say you're in java and everything was just directly calling a property on the object and now you change it to being a method that needs to be called. Well, now you got to go and find all of those places, change the signature to be a method call instead. Just becomes a big hassle. You know, you know, what's funny about that is I actually did a video on this. It was public variables versus public properties.

And and it's interesting. I'll leave a link in the show notes here. But the whole point of it was exposing a public variable. Like what they're saying is if you ever need to refactor that kind of stuff out, it's sort of a bit of a pain. Whereas if you always do it as a public property, instead of a public variable, you have these like basically interfaces that you can work with. Right. And you can abstract those things away. And,

and another thing too, is when you have a public variable, anybody can do what they want to. Right. If it's a public property, then you can actually, you can lock down the gets and the sets to private members or whatever. Like there's a lot of features that you can add to it. So the sets to private members or whatever. Like there's a lot of features you can add to it.

So anyways, I thought that was recent. Sorry. No, go ahead. Recently. I just found out that if you have a public property or any sort of property and to specify the get,

but you never specify the set. Have you ever seen that where it's property get and C sharp, no set. It just means you have to set in the constructor. Yep. But what I in C Sharp? It just means you have to set it in the constructor. What I really like about it is that if you forget to set it in the constructor, you'll actually get an error about it. It's like, this will never be set. It's not going to compile. I just thought that was a cool way

of saying, you can only set this for one place so it's immutable. And also, if you make a mistake, you're protected. So it just seemed like a really nice bit of C Sharp sugar. I don't know when they slipped that in, but it was nice. That is good. This episode is sponsored by Clubhouse. Clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters, creating products our customers love. While designed to be developer first, the UI is simple and intuitive enough for all teams to enjoy using. Clubhouse is truly built for developers by developers.

And you can tell because they've done things like sprinkling Git tips throughout the UI, and they make a point to highlight open source projects that integrate with them. And they're constantly adding new features. So just recently, they added new features to where search operators now auto-populate in the navigational search bar as you're trying to type along there. They've added Sentry integrations. Now you can automatically resolve linked Sentry issues all from within Clubhouse. With a simple API and a robust set of integrations, Clubhouse also seamlessly integrates with

the tools you already use every day, like Slack or GitHub, for example, getting out of your way so you can focus on delivering quality software on time. Sign up for two free months of Clubhouse by visiting clubhouse.io slash coding blocks. Again, that's clubhouse.io slash coding blocks to get your two free months and see why companies like Elastic, Full Story, and LaunchDarkly love Clubhouse. All right. So it's that time of the show where we do ask you if you haven't already and you would like to give back to us and put a smile on our face and you know, put a smile on your face. Please do leave us review head up to codingblocks.net slash review. And we have links to Stitcher, iTunes, and maybe some other things there.

But, you know, quick links to where if you want to just drop us a little note and say, hey, you guys made my day or you put a smile on our face or you helped me, that would be awesome and definitely appreciate it. So please do take the time to do that. And as always, we do appreciate it. And if you leave a creative name on there, we will read it on the show. So thank you to all who have done it also.

We may mispronounce it on purpose. Depending on what it is, we have definitely had to do that. We put pauses. This whole time I could have been saying I did it on purpose. That's what I definitely did. That's right. Strategic pauses might have happened.

If I ever got it wrong, that was on purpose. All right. So with that, we head into my favorite portion of the show. Survey says. All right. So back a few episodes ago in 103, we asked, what is your favorite cloud provider? And your choices were Amazon AWS, baby, the original gangsta of cloud providers. Or Microsoft Azure.

Remember when they called it Windows Azure? Awkward. Google Cloud, because I also need them to know how I cloud. Or IBM Cloud. I'm all about the business. Rackspace Cloud. Big enough to be a big deal, small enough to care. Or, I just love some of these, by the way.

Linode. You gotta love that pricing. Or Vulture. Bare metal for bare prices. Or Digital Ocean, a refreshing droplet. And lastly, Other. Because how did you not know about my dog's groomer's dad's side cloud business? All right. I think Alan went first last time.

So, Joe, I'm going to give it to you. You go first. Which one? Oh my gosh. So I'm still laughing over here. We need to edit like a laugh track in or something. Like this is just too good.

It's gold. These are, these are awesome. I don't want a laugh track. I want genuine laughter. Laugh tracks always sound fake. Man, you could like,

you could take these like seven or eight, nine bullet points and work them into a ten minute comedy routine and it would kill. I'm going to go AWS. AWS. What percentage?

With 30. 33. .26. .26. I'm not dealing with fractions. AWS 33. All right, Alan. All right.

So depending on what he chose here, I was going the other one, not because I have any strong feelings or opinions, but just because I want to win. So I'm going Microsoft Azure. Okay. And I will go 30. 30. 30.

All right. I like the way you did that. All right. So AWS 33 for Joe and Azure at 30 for Alan. Drum roll, please. Oh, God. Now there's the comedy routine. Boy, I could ask for that more often.

All right. Well, I'm actually surprised that no one, neither of you bothered to say Google. Like, that didn't come up. But, yeah. Joe, Alan won. Really? Yeah. Yep.

It's because of Cuddlebox.net. I don't know, man. I got to agree with Joe on this one. You think so? I think that has a large influence on it. What was the percentage? Were we up in the 50s? It was like 43%.

Okay, that's pretty high. Yeah. Oh, yeah. AWS was definitely number two then. What was it at? You'd also be wrong pretty high. Yeah. Oh, yeah. AWS was definitely number two then. What was it at? You'd also be wrong. Really? Yeah.

No. No. This one was super surprising. Rack Space? No. IBM? No. Digital Ocean.

It was Digital Ocean. Wow. All right. What was the percentage there? Rock on. Well, Digital Ocean and Amazon were like neck and neck. So it was like 16 and 15. That's really low.

Yeah. Like far and away, Azure was the clear winner. Everything else was, you know, not far apart from one another. Opinion based here, I will say Azure has the more pleasant experience through their portal. Oh, compared to the AWS console? Yeah, man. Yeah. My opinion here,

if AWS bought a TLD for AWS and offered us $2 million to change the domain name, I would change it to cutting blocks.aws. If you're listening. Jeff, if you're out there.aws. If you're listening. Jeff, if you're out there. Yes, if you're on the team, Route 66, and you want to provide us some money.

Yeah. That's awesome. Codingblocks.aws. Codingblocks.aws, baby. Yeah, hey. Well, I mean, they'll have to pry away codingblocks.js from our cold, dead hands though first, right? That's right. Yeah, codingblocks.js from our cold dead hands though first, right? That's right.

Yeah, codingblocks.js is like the pictures for each episode. Maybe we should just register. Should that be a thing? Should we register a codingblocks domain for every language so there'd be like a codingblocks.py, a codingblocks.java, a codingblocks.js? Some are expensive. I know, man. It's like 70 bucks. Yeah, that is pretty.

That's pricey, really. Dot radio or dot FM? Forget about it. Hundreds. Really? Yeah. All right. Now I got to.

Is radio still a thing? Radio killed the video store. What killed the radio store? I don't think they call it radio anymore. They just call it podcasting. That's true. Yeah. I heart radio.

All right. So for today's survey, or I should better say for this episode survey, we ask, why don't you go to conferences? And for the astute listener, you will recall that this is a follow-up from episode 102 where Alan was like, hey, we should ask, why don't you go to conferences? Guess what I wrote down? So we're asking, why don't you go to conferences? And your choices are too expensive. Got to think about that ROI. Or too far.

I could finish an entire Coding Blo blocks podcast just getting there that's a long drive uh that one kind of hurts for right i'm not gonna lie no one wins i'm gonna be upset or what about both of the above oh that that's this option lastly, but I do go to conferences. Why can't I participate in the survey? That's amazing. This episode is sponsored by Datadog, a monitoring platform for cloud-scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly. You can visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues

fast. You can try it yourself today by starting a free 14-day trial, and you can get a free Datadog t-shirt when you create your first dashboard. Head to www.datadog.com slash coding blocks to see how Datadog can provide real-time visibility into your application. Again, visit www.datadog.com slash coding blocks and sign up today. All right, so the next thing is the impatient, the potential causes and the solutions of impatient duplication. And I had to put this quote in here because, oh, man, I felt this so many times today. And the last time you highlighted it, that's so amazing. So the quote is, shortcuts make for long delays.

Can I get an amen? Amen. Amen. It's so true. I love it when we find something written in black and white that's like, oh, my God. Just so succinctly, they just summed up my life. Yeah, exactly. That's what I run into.

I feel like so often, right? And it's so hard, too. Trying to explain this to upper management is is what virtually impossible like seriously i mean everybody everybody is in has their own challenges right so so you know higher levels they're trying to just focus on like well hey we need to make money right like i that that's all great what you're saying that's nice but at the end of the day nobody cares all great. What you're saying. That's nice. But at the end of the day, nobody cares about that. But meanwhile, you're like, but I got to support it.

Right. I don't, I don't want to deal with this. You're like, I don't care, kid. Here's a quarter. Go away. You know, the worst part is it's not even just for delays. I mean, this statement, so it's true, but also the shortcuts come back to bite you in the long run. So you might not have delayed the release of the product, but you're going to introduce pains, you know, either for your customer or maintenance or whatever. Like, it's just, it's amazing how those little things that you didn't take the time to do come back to bite you somehow. Well, let me put that another way. The delay could be how long long how how long it's delayed until you get to do it the quote right way yeah that's true too right like how how long

before you get to fix it yep and and the more you keep delaying that the more you keep uh not paying that debt yep it incurs a higher penalty although Although, I'll tell you, man, if there isn't somebody saying no, I will never ship. So, I'm the one who's saying no to myself. That's the truth, too. No, it's not perfect, my precious. Yeah. My precious.

Somebody needs to make a Gollum meme of Joe. Kick me in the shins, my precious. Oh, that was creepy, man. That was really good. So this one's funny because we've all done this. We've seen it a million times. Using the same literal in multiple spots, right? Like you'll find yourself plugging in, I don't know, 3,600 for, you know, a minute.

Oh. Right? For 3,600 for a minute, right? For 3,600 seconds. What am I thinking? Yeah, 60 seconds. Oh, man, everyone hates when I do all the math. It's an hour. An hour.

Code. Yeah, an hour. And so, yeah, you'll be writing 3,600 all over the place, and you're like, wait a second. Come on, man. Let's create a string literal for this thing and just use it, right? Change it in one spot. Yeah, exactly.

It makes life a whole lot easier. but why make anyone do the math why don't you just put the equation there 60 times 60 that's that's a cpu that's a cpu cycle man you can't do that come on but you why does everyone hate that it's so nice but it's not any better though to to alan's point though right like you're still, what's this magic math formula? Why did you need this? Oh, I see. You're setting a timeout. If I see 3600 or 660, I'm like, oh, okay. But in fairness, this whole code duplication thing, I think we can all think of one place where modularizing your code does not help you that much.

Anybody? Wait, what? The database. Oh. Yes. It almost always bites you instead of helps you so i'm surprised that nobody was going to jump on my like one hour timeout yeah the 3600 like using that legit never i slipped that one in and you guys let it go so cool there are times

so but oh yeah i think um you ever like you know the five why's you're here though you keep asking why so if you ever like type in 3600 like well why didn't you use the variable why i don't have a variable why don't you make a variable because there's no good spot for me to put a variable why don't you make a good spot for you to put a variable well we don't really have a good place for that like okay that's the problem to solve you don't have a good solid place for settings that are accessible that's a worthy problem of solving. Figure that out now. Otherwise, you're going to be putting literals all over the place.

Oh, that's actually a really good point. Like, I don't know that I'd ever thought about it. It's funny because I'm the one who brought up the example of 3600. But why not just have a constants file like they did in the good old VB days where you've got, you know, one hour and seconds, um, you know, well, what assemblies are going? So what? Assembly wars,

man, the assembly was really anytime you have to ask like, well, where should we put it? What assembly? As soon as you get like two or three people on that question, man, you don't ask anybody.

You just do it. I immediately thought of like dumping grounds when, as soon as you said it, because I was like, Oh my God, now you're going to have like a constants assembly. That's going to be a dumping ground for all global constants that's going to be in the utilities of utilities assembly it would have to be like very uh rigid

you know like hey it needs to be truly global global like i don't want to have to calculate 60 times 60 to get an hour right and i don't want to have a hard code. I want to have a string representation for it. Right. Yeah. What do you do? The next one, the copying and pasting source code from a standard implementation and tweaking it. We've all seen this, right? Stack Overflow would be out of business if you didn't do this.

That's Stack Overflow's business model right there. Well, that's fine if you're doing it from Stack Overflow to your code. It's the problem when you're in one method in your code and you do it to the second method, right? Okay. Yeah. It rolls so easily off the fingers, though. You're like, oh, I did this something like this over here. Let me just go see.

Yeah, I just got to change the connection string or whatever it is. I got to tweak this one line, right? And to their point, and this is uh is this it's further down so i shouldn't say this yet i'm gonna say it anyways this is where something like the strategy pattern or the template method pattern or or anything like that can come into play right because oh okay well most of the block is the same so let me have a starting point a middle point and an exit point. Right. And then that way you can tweak that thing however you want. And just the little bit of the algorithm

changes for you. Or not even that, like just refactor and have like, you know, the common parts, you know, as as reusable methods. Yeah. That it shares. I mean, you don't have to take it to like a template pattern if that's a good point. It doesn't need it. Yeah. But I'll tell you some of the stuff when if you start like going down this rabbit hole sometimes it can get really gnarly so like the example i just said where the connection strings were like you can take an example and just change where you get the connection string from i'm sure we've all seen code where someone like had two places they were getting connection strings and they said i'm gonna make a factory and so now whenever you need to do a query you have to use this weirdo class that

somebody created for the connection string and then we gotta oh you need to do a query, you have to use this weirdo class that somebody created for the connection string. And then when you want to log something, oh, well, I don't want to just directly access my logger because that's code duplication. So we do that. But next thing you know, it's like you can't type a stupid line of code without going to look and see how everyone else is doing it because everything is some custom little factory rather than using the language built in stuff that everyone is kind of just standard. And so you've kind of built this whole little fragile architecture where every little thing you want to do, it's like, oh, I'm going to add two numbers together. Well, better use the add whatever function because we built one of those. I don't want to do that twice. And so you get to this monster of tangled code that gets actually worse just because you keep adding lines of code for things that really aren't conceptually significant.

You know, I think though, I think though, and this might be getting into another part of this whole situation though, is that where it comes to, you have too many people working in the same code base? Well, I don't know, because this one, this one kind of hits close to home for me and I'm kind of a little hurt. Like I gotta say. Your ad function because, because just today I did write some code for dealing with the connection string where I was like,

you know, I have the use for a connection string in multiple places. And sometimes I needed a little bit different than others, but most of the time I want it to be mostly the same. And so I'm going to write something to deal with this for me to make it easier for me. And now just picking on me. So he was watching over your shoulder. You didn't really, same and so i'm going to write something to deal with this for me to make it easier for me and now just picking on me so he was watching over your shoulder you didn't apparently like you know it's

like i'm sure you've i know we've seen code bases where you're like oh all i gotta do is change a label and you go in there to change the label on a website and you're like oh wait all the labels come from xml files but there's like a three-tier xml system with like these like translation layers and like language stuff in between so like when it gets down to it's like oh actually this changing one thing from like note to warning uh is now taking me 17 modified files and you know four hours six hours eight hours of time because it was all it was too uh overly architected okay so now we're going backwards though because like if it was used if it was based off of the XML, right, then that's like a meta-language to describe it

that you could then build your code on, generate your code from, right? So now it's almost making the question of, the example that you just gave, well, is that previous section that we just talked about, generating your code from metadata like that, maybe is that an outdated thing? Because remember, like you pointed out, Alan,

this book was originally written in 2000, I think. Yeah. Right? And so, yeah, sure, at that time, XML was much more popular than it is today. Do you think that that is now an outdated? No, I think code generation still makes sense. But there are things like what he's saying, though, where some things are just overly complex, right? They shouldn't be that way.

And I think there's a difference, right? The code generation thing, like I said, I don't think it ever came to fruition in terms of writing like UML to write your code. However, that doesn't mean that I think that code generation is not a thing, right? Like T4 templates I think are fantastic. Yeah, but those are very specific and very isolated use cases though. So now we're talking about just, I mean, a T4 isn't going to generate the code for your entire application. It's just going to generate a part as it interacts with the database. And what they're talking about here is generation for the code, period.

They're not making such a narrow specification. I mean, you guys remember back in the days they were all called 4GL languages, right? That you could basically generate an entire application based off something. Man, everybody that I ever knew that worked with those things hated them, right? Because they did some things super well, but then anything outside of that, you were basically trying to hack apart whatever it generated to inject what you needed it to do. All right. Well, you've convinced me then that generating your code then from the metadata now is now an outdated concept and so sometimes it's really nice so there's definitely been times when i've looked at xml files and project we're like oh okay all i have

to do is change here and i don't have to change any code that's awesome it's like data that's informing that my architecture that's great and there's other times that i saw an xml project and wanted to jump out of windows like oh no this is not right yeah it depends on how it was implemented right how it was implemented, right? How it was all wired up is really what it boils down to. Okay, so here's the request, dear listener. If you feel like I feel that this is now become an outdated recommendation, then on this episode's show notes, discuss comment, uh, you know, uh, discuss comment, leave a comment, letting me know that you agree. And if you don't agree, then, uh, don't bother leaving a comment.

No, I'm just kidding. No, either way, either way, leave a comment either way. Uh, but definitely like, I want to hear, I want to hear examples, like current examples, where generating your code, not just a part of the application either. I mean the application from some other documentation or some other mini language that you're using, be it like a UML or something, to generate the entire application. I don't know that we'll get very much where people say they're doing it. I'm curious to hear that, hear that example. Like where does that, you know, in modern day, where does that fall? And by the way, that'll be coding blocks.net slash episode one Oh six. And, and we actually got a question in email the other day about commenting on

our stuff. You don't have to have a Disqus login. You can log in with Twitter, Disqus, Facebook, I think even Google. I think those are the ones that you can log in with. So any of those accounts, you can log in and do something. So you don't have to go set up anything. It's one of the reasons why I use the platform. They just made it really easy to leave comments.

So, you know, heads up anything. It's one of the reasons why I use the platform. They just made it really easy to leave comments. So, you know, heads up there. Hey, one last thing though, before we move on off of a inpatient duplication though, they do make the point to saying like, this is an easy form to detect and handle. And if you just think about like everything that we just described, right? Like, Oh, I've already got a method that's like this and I only need to change one thing. Like, like immediately in your mind, you can think like, oh, I'm duplicating it. Right? Like you can detect it immediately in real time. You might still do it, but. But it's not a hard one to see is the point. Take a little bit of time.

The Boy Scout rule, I think, is how outlaws always talked about it is leave it better than what you came. Right? Or at least as nice as it was when you came. So we've gone from the easiest and now let's go to one that they say is possibly the hardest type of duplication to detect and handle which is inter-developer duplication yeah man yeah and it doesn't necessarily mean that like duplication doesn't mean line by line, semicolon by semicolon duplication. It could also be logical duplication.

So we're doing the same thing in two different ways. And that's even worse than copy pasting because it's harder to find. With copy paste, when you know it's happening, you can search for it. You can find those patterns. If everyone does things a little bit differently and inconsistently, then that's a real problem. And I see that a lot in SQL sometimes because if you were doing a lot of stuff stuff it's like store procedures or in views or whatever then for performance reasons you've got to move stuff around so you can't just search for one easy clause because someone's using the alias over here because aliases are terrible someone else is using a different alias so you can't

search that way sometimes it's in the join sometimes it's in the where sometimes it's uh you know alias the column names, for God's sake. I mean, I just had this exact same, this exact example happen. And to me, working in a rather large database schema, and I needed to, like millions, millions of rows, and I needed to go ahead and pre-compute some columns. So I thought, okay, you know what? The easy thing for me to do here will be I can just take the one-time hit, do a big generation. I'll create another table that can store these pre-computed values,

create that table, take the one-time hit to populate it, and amazing things can then follow on, right? And then weeks go by, many, you know, weeks go by, several, many, many, several weeks go by and someone else happens to notice. They're like, Hey, wait a minute. I created this other table that's extremely similar to the problem that you have. Did you know that mine was there?

Cause I didn't know that yours was there. And I'm like, well, no, how? No, I didn't know. You know? And it was, it's exactly this kind of thing. And, you know, because they, they're similar problems, but, you know, to your point, they're not the name, the same thing. They don't have the same exact structure, but they solve similar problems. And that's why it's so difficult to detect. Yep. The, the example they gave in the book that I just had to share on this one was, so when the year 2K, the Y2K audits went around in the government applications, they found 10,000 applications that needed to be looked at. And each of them had their own social security validation. So this was a thing where, hey, there weren't

any shared libraries. There were 10,000 individual apps written and a bunch of duplication. And that's really hard to manage. And it's hard to know about because it's not like all these developers were sitting in one room writing these 10,000 apps. So can we solve this? So can we solve this? How can we solve it? Is it solvable? Can you imagine if those people work on those 10,000 apps across years, times, locations?

They're like, hey, wait, you know what? I need to validate SSN here. Can we get everybody on the call here real quick and figure out if someone's done this already? Oh, man. That's awesome. Yeah. So the how to solve thing, this one's one's man this one's so hard and and i agree with and disagree with some of these but like one is a clear overall vision so yes you

should have that does it solve the problem uh you know this is where uncle bob's version of of duplication comes in though because this because this also falls into the realm of accidental duplication, right? Where, yeah, you might've generated the same functionality, but it might need to change for different reasons at different times. So, I mean, you might on the surface think that it's duplication only to find out it really wasn't. Right. I mean, this one's hard too, though, because so they say the clear overall vision. Yeah, of course you want somebody that has the big picture in mind and they need to be able to share that in a way that people can absorb it. Right. But then the next thing they say is you have a strong project leader. Okay. I agree with that too. But you still have issues to where, are we talking about a project leader that's leading

everybody? You know what I mean? Like if you have a team of 50 developers, that project leader overall 50 unlikely. Yeah. You know what I mean? So it's, we've all read the documentation about how, uh, it was Spotify does a lot of their, their work, right? And they sort of have silos where they work in little like task forces. And my guess is they probably duplicate things, but they're cross-functional teams. They work on one component. And I'm sure that they do communicate across those teams, but the chances of not duplicating anything is going to be really tough.

But as long as you encapsulate and isolate those particular modules pretty well, then you sort of save yourself from a little bit of this. Yeah, I'll include a link to the Spotify article because it was quite interesting. I heard they kind of got away from doing that. I knew that they used to take it to an extreme level where like even like different parts of like the page or web page would be owned by different groups yep and i think that they got away from that in recent years interesting i haven't i haven't seen an official source on that but i'd love to see one if you drop it in the comment uh comments then you could win a book for it i mean this is also

from like five years ago so yeah but yeah i'll include a link to it so the next big one and in in our personal lives we struggle with this one the division of responsibilities and this one's a hard one right like this is basically you know slicing up your teams to where people are working on very specific things or or whatever and and figuring out where to draw those lines wait this is a problem in your personal life? Well, in our personal working lives. Oh, professional life. Professional life, yeah. Our personal professional lives.

You're at home and you're like, okay, honey, there's going to be a division of like who takes out the trash on Tuesdays? I'm doing the dishes. That's right. But yeah, I mean, this is – so the clear overall vision, the project lead, and the division of responsibilities, I think all of those things together will definitely help. But I don't know that they solve the problem. You know what I mean?

Yeah. It's a hard – because – Well, this goes back to the example that Joe gave, or I think it was Joe, with the – what was that first one? The imposed duplication, right? Oh, yeah. You know, you have this division of responsibility. So you might be thinking like, oh, well, I can't change the SQL, you know, now that he's given me this awesome example that I can like relate to, like, you know, I can't, I don't have the, I don't have the, you know, the approval to change it on the SQL layer, but I can do this change in C sharp.

So I'm going to do what I need to do in C sharp, even though it's very similar to what's being done there. Well, I think, I think one of the things that was really cool here too is like that social security thing, right? My guess is all those applications that were written to 10,000, their core feature had nothing to do with social security numbers. You know what I'm saying?

But every person in the system and the government do with social security numbers. Probably. Yeah. You know what I'm saying? So, but every person in the system and the government has a social security number. It was not core to the application. And so it was an afterthought. And that's one of the things that they bring up here is that's one of the problems is when you have something that's tertiary to the, to the actual core of an application,

those are the things that a lot of times get duplicated because it's like, oh, well, we need to do something for this. Here, let's hook that up, right, and move on. Yeah, like was that validation just 10,000 regular expressions that were all very similar that just validated, hey, this thing is a social security number? Because they were like, oh, well, we have these SSNs. We need to do something.

Or maybe one of them was a regular expression and another one was a method or a function. Right. Well, here's another view on it, though. The opposite thing, a different way to approach it, but like, well, wouldn't it be great if back then when they're working on these 10,000 apps, there was a nice package manager and they could just say like NPM install ssn verification but then this is the kind of thing that people complain about all the times where like people talk about the left pad library or the center library or whatever like these little libraries that do like one little tiny thing and people are always saying oh man like why did you install a dependency for this it's a potential security vulnerability when you

could have just done it with a one-liner well that's what we just described with the social security number and so we didn't want that because now we've got this duplicated logic all over this place in this tertiary function. That is super frustrating, what you just said. And that one definitely hits home for me is just, man, when people – Can't win. Yeah, you really can't because if you write that regex yourself, then you're potentially missing something, right? Oh, yeah. If you use the third-party dependency or even if it's an internal dependency, you'll get complaints that why is there only one class in this assembly?

And it's like, man, that's not the view to take. The view to take is, does this thing do one thing? And is it testable? And does it do it well? And I can validate it and I can verify it. And it's the same everywhere. If that's the case, then that's all you need. You don't have to have 50 files to make an assembly. It doesn't matter. What is the purpose of that assembly? I mean, here's an example that we've talked about in the past, which is that you don't want to write which is a an email validator right oh yeah like because if you were to try to write that in whatever your language is right like there's uh i mean it's it's to write it to where it's like 99 of the time right it's several lines long. Like I'm looking at it right now on the Pearl and Ruby version of that regular expression

is 82 lines long. God, that's insane. And, and that, that's the, you know, yeah. I mean, it's not like it's better in other languages either. Right. Yeah. I just don't care 82 lines much if your email is correct or not. So,

but the point is, the point is, is like, uh, you know, when you said like, Hey, now you might,

if you take the time to write that regular expression, you might miss something. Well, it's quite possible that you might miss something. So you're better off, you know, using SS, SSN dot JS, you know, and you're better off you know using ss ssn.js you know and up until like you know moment ssn comes out and then you're better to pick that one instead or yeah but in in

all seriousness and honesty like assuming that you have something that bundles your things properly then you shouldn't be worried about the size of the assembly, right? You should be worrying about the functionality it provides and the, well, and the level of confidence. Wait, no,

hold on. Now, hold on. It depends on the type of development you're doing. If you're doing like IOT development, for example, you care about the size of the assembly. No,

no, no. When I said size, I meant how many lines are in it. I didn't mean how big it gets. I mean, if there's a single file in it, you shouldn't care. Is it providing you the functionality you need? So, yes, in fairness, yeah, I wasn't talking about megabytes.

I'm sorry. I misunderstood. Yeah. So, to me, at least personally, professionally, what I have seen is typically when you have smaller assemblies, they're usually written well or at least better. And they are usually more testable because it's got a small surface area. And we just talked about this, too. They typically change less often. Almost never, right?

Like the thing works. Why touch it? Yeah. You know, unless the Social Security number is now just got expanded to an extra digit. Okay. Somebody's got to go change that one that, you know, 5 million people in the world are using. And guess what? All 5 million of those people now get the benefits of the additional social security verification.

So, yeah, I'm going to let that rest, but it does drive me crazy. So the next part that they say on how to solve the problem. And this one, this one's hard is open and frequent communication between developers. And, and our buddy, John, who was on episodes 100 and one Oh one,

he always said this the best. And, and I love this communication doesn't scale. Right. How do you, how do you propagate that stuff to where it soaks in? Tell me this. If you've written a long letter or a wiki, how many people out of 100 do you think read it?

One. None. And it was probably you because you authored it. If you write something that's a two-liner, people will read it. But can they get enough context out of it? That's the problem. How do you communicate properly? If you have a meeting with 100 people in it, how many people are looking at their phones versus actually paying attention to what you're saying?

Probably not that many. This is the hardest part. I think it's the most important. I guess the key here is it has to be, if you're going to say open and frequent communication between the developers, then it has to be small or otherwise, unless you're assuming like online things like forums or Slack or wikis. But to your point, you have to assume that a lot of information is going to be missed, right? If things that are written into forums, for example, or wikis, Slack, Slack especially, is going to be gone. But yeah, not everybody's going to catch every little thing that was written there. I mean, how many times has somebody sent Joe an email like hey how do we do the login and he's

like hey here's this wiki page like I know you've probably replied like seriously 50 times with a link to a wiki page and and it's the same thing that everybody's gotten an email before don't don't even look it up yeah yeah let me tell you about where the deployment destinations go. Exactly. I meant to ask you about that earlier. Jesus. I do like the idea of having a project librarian or a steward or even a subcommittee. No, really? Really?

Really? Guess what job I'm just giving you. Yeah, no doubt. Yeah, I know. Well, at least you only have one person that has to bear the misery of the whole community. Who wants to take that, though? Like, this appointed project librarian? Like, I even put after it. Who's taking that job willingly?

Like, that's crazy. So, I mean, like, not just the librarian, but, like, who's the person that, you know, you ask? Or maybe a subcommittee where you say, like, hey, I've got to do a thing. Have we done something similar? Wouldn't it be nice if you had, like, an email district where one person asks asking you kind of funnel you to the right person it's like hey why don't you go talk to betty she did something like this last week yeah i mean i get it i just don't know who wants to be that like i know all three of us have at one point or another have been the people that got prs pushed to them all the time and it's like eventually you're like dude don't send me another pr i don't want to see

this yeah but i mean like going along with this point though the the next one that they had here was to have have a central place for in your source for utility routines and scripts and i'm like what no like this goes against everything that we've ever talked about before. Like, because when I read this, and I don't know, like, you guys tell me if this was your thought, too. But, like, having a helper's library or a utilities library, like, that was immediately what I thought of. Like, oh, well, what would you name this central place? Like, you know, it's going to be like a dumping ground. All the scripts.

And so then I was like, man, I really don't like this idea. And yet they're like, I actually, I circled this part in the book and wrote gross by it. I agree. Fair enough. Yeah, I agree. I don't like it. I can't argue that it's not somewhat I agree. I don't like it. I can't argue that it's not somewhat useful,

but I don't like it. Is there a way to make people go to the wiki? It's like whenever you're fired up, Visual Studio, you have one of those tips things. It's like, hey, did you know? And here's a snippet from the wiki. That's kind of a nice idea. That just made me think of an

amazing idea. I wonder if you could control the start page to go to your own oh i'm sure you can uh-oh now to the google oh oh man yeah how nice would be visual studio every time you pop it up and it like just opens the tab of the wiki area it's like you can close it if you want but but we're gonna crash visual studio yeah by karma so the next one too and and I kind of like this one. I don't know how reasonable it is, but the continually explore other people's source code and be a part of PRs, right, and code reviews. Oh, man. So. I don't want to see my own garbage.

Well, that's the thing, right? Like, the problem is, depending on the size of the team, how realistic is this? So, so one way you could do it, if you're using something like, uh, Azure DevOps or probably even get hub is you can just go look at the latest commits to a repo, right? And they just look through them and see what's happening. But I have two problems with that. One is first, just, I mean, it's, it's amount of time that you got to do it, but two is, and I'm sure you guys have seen this,

it's really hard to get the context out of what's been done just by looking at PR. Because usually it's the one or two lines that are highlighted that changed and a bunch of other stuff just not shown on the page. Now, granted, it'll give you an idea of what's going on. So you'll probably see quickly if there was any duplication, but it is an effort on the developer's part. Yeah, yeah, for sure. Hey, so just a quick backup here for a moment. You can create a custom start page for your Visual Studio environment, and there's a couple extensions for it, a couple plugins for it, But Microsoft also has a document on how you can create your own custom.

Can you force it using source control? Yeah. That's the real question, right? Well, that's different. I don't know that it would be source control because it's not going to be part of, like, you're not necessarily opening a repo. Right. You would probably want, like, something through Active Directory that would like push that setting down. We got to trick your coworkers to do this.

It's like set up a lunch and learn. You tell them you're going to work through a code kata. Step one, open your Visual Studio settings. I'll include a couple links here. I like that. Step two, paste a wiki in and hit save. I'm watching all of you. That's awesome.

You will read what I write. So the next one, we're back to the tips. So we made it through tip 11 on last episode. This tip, number 12, is make it easy to reuse. And this is so true. If you don't make it easy, people won't reuse it. It's that simple. And it's that true.

Yeah, and that is one nice thing about having the dumping ground is like at least people know where to look until it gets too big and then it gets lost in there i mean i don't agree with that yeah exactly what alan just said man that dumping ground will become like literally the dump right like That's saying that, hey, it's easy to find the bumper you need for your 1970 Chevrolet in the junkyard because they're all in the junkyard. But it's still going to be like, well, find the right one. Yeah, man. It's just going to become a mess. It's the humble package pattern. Put all your crap in one package and it keeps it out of the other places.

Man, I hate that. I don't love it, but I just don't know a better way. I don't want to be like, oh, wait, which assembly had the one thing that I need? Now you're adding references to random assemblies because that's where some little bit of functionality is that you need. That stinks unless you have tons of assemblies, in which case every little one has some little thing in it which is also a pain to find how is that any different than using npm or nougat i think as long as you have a package manager that or a package management system that is halfway useful then you're fine if you send me a pr with a single package and dot net project with a social security number foundation in it,

I'm going to be tempted to hit no. Come on. I'm not sending it to you. The key is he's only going to be tempted to hit no. He's going to hit yes. I probably will. I probably will because I'm so tired of fighting. But no, the reality is, though, is that if you have –

okay, I mean, that's an extreme example, right? Let's admit that the Social Security thing that you're talking about, that's an extreme example. There are things like that, like LeftPad, like what he was talking about in NPM, the one that broke all the interwebs. But the point is, is that if you have a package or a library, whatever your language of choice happens to refer to them as, that is single purpose, right? Even if you have two of them that are single purpose, it's going to be easier to deal with that than if you have functions that are spread all over the place that might be doing the same thing.

I would rather have... I'm just saying I would rather have that problem. I would too. I'd rather have the, I chose my assembly versus, I have this utility package that has 9 billion things in it that I don't care about and I'll never use, but they're forced on me because they're all in this dumping ground. Now I want an amen.

Amen, brother. Just do the regex. Let's do the regex. Man, somebody cut his mic. I don't know how we can do this. I'll prove that PR. And on this make it easy to reuse, basically what they said is if you duplicate something, you're likely going to have problems further down the line, which is true.

Very true. very true. All right. So with that, we will have some links to resources we like. Obviously, we're going to have a link to the Programmatic Programmer. Oh, wait, did I say that wrong? That hurts my head. Oh, the Pragmatic Programmer. Ever since Joe said it that way, now I can't not say it that way.

It's my favorite way to say this book if you haven't caught on. And with that, we head into Alan's favorite portion of the show. It's the tip of the week. Yeah, come on. You know, recently I was told that I have the worst tips of the week. I was curious if you saw that the slack and yeah it's funny that the person's name it just happens to be tippet as well oh michael that's nice yeah oh that was so hilarious so i thought i was gonna like come up with like the super best tip and like blow you guys away

and uh no it's not gonna happen i came out here you guys have like seven freaking tips written in here i've got nothing again so yeah i've been called out man it was it was so amazing i wish i could remember exactly how the call out went but yeah go ahead on. It was dead on. So, yeah, I have the worst tips. That should be my tip. But I did come up with another bad one. Sorry.

Tip it. Sorry, Michael. This time, I do want to talk about it, though. I do think this is actually not a terrible idea. But if you really want to know something, if you really want to learn something, then I want to encourage you to look at multiple medium learning. So what I mean by that is just multiple different sources. So if you're wanting to know Kafka, we mentioned Kafka earlier, go to QIT, listen to every Kafka podcast. There's quite a lot of them, actually.

Go on YouTube, watch all the Kafka videos. Check out the courses. Check out the books. Try writing about it. try doing a side project. I think by attacking it by the multiple angles and like every different angle that you can think about

really does a lot to kind of fill out the whole spectrum. So if it's something that you really want to care about, you really care about, like you say, you really wanted to react,

then don't just sit down there with a good, like a guide and editor. I mean, that's good too, but round out everything you'll you'll learn different things from different mediums and the ways that people express things on those mediums and so if you really truly want to know something deeply and i think that a multimedia approach is the way to do it i like that take that i had to go back and find it so

like the one thing that he said that called out was like when you brought up Moment.js as a tip. Yeah, that's a tip for nobody. So, hey, that should be your tip is that if you want to join in on this comedy gold, you should join our Slack if you haven't already. So you can find all the information you need to join our Slack at www.codingblocks.net slash Slack. Yes. And so I have two tips and one of them I actually had to use last night because I accidentally blew away our previous show notes. So in Google Drive, there's a feature that is really sweet. If you have a file on there and you do something like what I did, where you thought that you were editing the new show notes,

but you actually were blowing away the old ones, you can exit out of that file, right-click it, and you'll have the option in there to say, look at the versions. So you right-click and you say, where is it? Why is it not there? You don't exit the file. You do it from the file menu in the file. Maybe. Yeah. Okay. Yeah. You do it from the file menu in the file. I think you can also do it on the other one. I'm pretty sure I did it that way. Hold on. Let me see. 105. Right click. Whatever. Oh, no, no, no. That's what it is. Right click, say view details. Where is it?

Something like that. And over on the right hand side, you'll actually have an activity bar and you can click on the one that you want to open it to. So yes, you can do it there. And then also in the file menu, when you are inside the thing, you can tell it to go back to a previous version. So you can go to version history and you can choose the, you say, see version history and you can choose it and you can actually restore that file back to what it is. And it'll blow away the changes that you had. So like what I did last night is before I did that, I duplicated the thing. And then I, then I went back into it and I said, all right, now restore this one back to it so we didn't lose the old stuff. So yeah, that's really

nice being able to use multiple versions of the file so you have a running history there. But that's also something to keep in mind. Like if you ever put something important in the document and you didn't really want it there, then you probably want to delete that file because it's going to have the version history information there. And then the next one I thought was really cool. So the other day I had asked Outlaw, I was like, hey man, what's the name of that tool that we had mentioned to where you can actually create flow charts from code? And he told me the website and I don't remember what it was, but... PlantUML.

What was it? PlantUML. That was one of my tips the week a while back. Oh, it was a good one. One of your few. Oh, man. It's getting ugly now. I did get the tip from somebody else.

Gloves are off. Thanks, Bozzoli, for the best tip apparently I ever gave. Oh, thanks. Possibly from the best tip. Apparently I ever gave, but so while I was asking him, I was also Googling, you know, create a flow chart from code. And I came across this really cool JavaScript library. It's called flow chart. Dot J S.

And if you, there's, I'll have a link in the show notes, but it's flow chart. Dot J S. Dot org. And they've, they've got a JavaScript library that you can use in your

own applications. So let's say that you wanted people to be able to write flow charts and you wanted to create an application and allowed them to do so you can embed this library and it will generate flow charts for you. So really cool. If you don't want to just use a tool, but you would like to leverage that functionality, you can do that yourself. It offers things like regular flowcharts, colored objects, lines, all kinds of decision trees and whatnot. So really cool little thing. It's free. Go play with it. Have fun. Wait a second here. Here's the real tip. What is JS.org? That's a good question, right? Yeah. Hit it. Check it out. Here's the real tip. What is JS.org? That's a good question, right?

Yeah, hit it. Check it out. It's awesome. Did Joe just come up with an awesome tip? Yeah, this is mine, retroactively. So, JS.org offers free web spaces for

JavaScript developers to host their projects. So, you can go toblocks.js.org. You got to hook it up. You got to sign up on your GitHub page. I haven't done this yet, but you can bet I'm going to be doing it. So we can have codingblocks.js.org. This fork.js, or no, it's fork.js, flowchart.js that you are mentioning here reminds me of gitGraph.js.

So with GitGraph.js, you can, like you've ever seen those drawings of like Git subway lanes, the Git subway lanes for like a Git graph, right? And like I've actually used this multiple times. Have you ever seen like, hey, how did Outlaw create that cool Git graph where he was like showing some example, right? That I'll use as like an image and documentation or something, or in like a wiki article or something like that. Uh, you know, get, get graph JS was what I used to do it. It's the downside to doing those though, that I found is like, it can be like looking at the, the comment that not the comments, the, the examples that they give for flowchart js is it is very tedious you're like oh i want to inject something in here you're like okay let me go find the one

specific place where i want to do it and it's not that bad it's not that bad like i actually messed with it because i thought the same thing but you basically define your variables that are each block and you can just do an arrow to it and just put it in the middle of something else. Yeah, I get it. Yeah. I mean, don't get me wrong.

It's very terse, but, but it's super cool. Like I'll put it this way. If you ever do many diagrams or, or create flow charts and stuff, man, it takes so much time dragging those connectors between things and getting the

text in there. And it all look at like, it takes so much time and i could do this in seriously a tenth of the time is dragging things out and typing it in and all that kind of garbage so it's easier to keep keep it all together so and you could source this thing you could commit your flowchart js code stuff and you could have versions of your flow charts as you watch it change over time. Right.

That's kind of cool. I would say the same thing for get graph JS, but then that'd be weird. Cause then you'd have a get graft of your get graft. Yeah. That was, that, that would be a little bit rough.

Yeah. That'd be interesting. Things went like inception there. did all right so uh this was an interesting one that you know how we've joked about like apple hiding all kinds of functionality if you're like oh like just press the option button as you like open up that menu or right click on that thing you get a whole bunch of extra functionality. I never knew this, but apparently Microsoft does it too. So I heard this one on SecurityNow and I thought like, oh, you know what? I'll save this.

So from SecurityNow 709, they mentioned that if you are in File Explorer and you shift right click on a file, you get an additional option as well as some others. But the one that was like really of interest here was copy as path. So if you ever needed the path to that file as a string on your clipboard that you could just easily use, this is how you can do it. That just saved me a few minutes a day. Honestly, I'm not even lying. I know, right? That's why I was like, oh my God, I never knew that was there. Because in Windows, I would have never thought to like, that's an Apple thing. Apple has taught us, hey, we're going to hide functionality from you. There's a modifier key for everything.

Yes. You better press around some random keys to see what might be showing up. But Microsoft has never taught us that. We're not trained for that, right? We're used to really verbose menus that have a billion different options, and what you see is what you get. But apparently, this thing has been around since at least Windows 7, right? So it's been around for a little bit. That's really nice. I don't know if you've heard, Windows 7 is being sunset. So it's been around for a bit. This all feels kind of new to me. Windows 7.

Can we be honest? Windows 7 was the first time that I was like, man, they're making an effort to be pretty and make things look nice, right? It was good. And then there was Vista? It was good. Yeah. And then there was Vista, and it was just a pile.

No, no, no. Vista was before 7. Oh, Vista. That's right. It was the very unstable version of what 7 would end up being. Yeah. 8 was the next one, which was like, hey, let's just have one giant start screen. Yeah.

Let's be creative and see how that works yeah yeah all right well with that we hope you've uh enjoyed this additional deep dive into the pragmatic approach and the evils of duplication. With that, subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcast app. Be sure to leave us a review. You can find some helpful links by visiting www.codingblocks.net slash review. And while you're up there at codingblocks.net,

check out our show notes, examples, discussions, and more. And hit us up on Twitter. We're very funny. Facebook, too. And of course, the Slack is where it's at. Joe gets all kind of friendly comments on there. Join the Slack just so you can tell Joe how much you like

his tips. I think he's going to need some pick-me-ups after this.