Coding Blocks - Clean Code – How to Build Maintainable Systems

Episode Date: March 6, 2017

We’re back with another deep dive into the infamous book Clean Code by Uncle Bob as Joe alters columns, Michael misreads things, and Allen has a positive customer service experience. Care to join in on the conversation? Become a member of our Slack community by signing up at http://www.codingblocks.net/slack. Viewing these show notes through your podcast […]

you're listening to coding blocks episode 56 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app this is us at codingbox.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 coding blocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. And it is time for...

No. No. A little bit of news? No? No news? Yes. We kind of like this. Go ahead. All right. So first off, we got some great iTunes reviews. Thank you. We really appreciate it. So first off, we got some great iTunes reviews. Thank you. We really appreciate it.

So thank you to Chuck O. Halloran, Haddock67, Mhender24, Jeremy Underwood, RunAtRoulette, KSKL, Miller, TupleSteve, JoeR8975, CompNinja, Thomas Cooper, SwiftMac, YvisMitch, and Diana. Nicely done. I didn't see the Jeremy Underwood. I have some brethren on here. Apparently. This is good.

I didn't pay for this review. All right. Yeah, and from Stitcher, we have RyanMonsterMHinder24. That's right. We said his name again. Captain Coathanger, OOP Michael, JKBob11, Brandon Hartman, Taryn Zima, Matthew Lazaro,

yet another creative nickname, Sky Crenn, and Neutron. Yet another clever nickname. What did I say? Creative. Oh. Dang.

So with that, you can find all the show notes that we are going to be covering here if you head to www.cuttingblocks.net slash episode 56. And so I had to put this in the show notes because one of my friends today said something that is so amazing. He said he sees some people as code technicians and other ones as engineers. And what he meant by this was beautiful. A technician comes in and troubleshoots a problem, a specific problem, fixes that specific problem,

and usually doesn't care about anything else going on around it. An engineer is going to look at it and evaluate it and figure out what are the touch points, what they're more thorough, right? And I was like, man, that is beautiful. So in that, I want to say, strive to be an engineer, strive to be somebody who's thorough, who thinks through a problem, who, who, who doesn't just say, I checked that box, right. Be that person that really does your best to make sure that the system's in good shape after you've touched it. Right. So I thought that was really cool. And then reminds me of an article, actually, I just posted a link in the show notes for an article on wired.com or the

magazine too, for basically talking about programming, becoming a blue collar job in the future as things move more and more as the, the tools get better and better. And the, basically the need for technicians over engineers kind of grows. So it's food for thought. I don't, I don't know how much I agree with it or not, but it's interesting. Very cool. And I had to share this. I know that, so this is a little bit of technology that I was super, so we've had a discussion in the past. We had talked about Ergotron and Outlaw had said how incredibly happy he was because he contacted Ergotron support

and it was the most amazing support ever, right? Like they brainstormed some things with him and sent him out some stuff. So I was recently looking to replace the thermostats in my house with some, you know, better, smarter ones that could, you know, kind of do things in a better and more efficient way. Well, it was basically down to the Nest or the Ecobee. And I don't know why I decided to go the Ecobee route, but I did. And I literally had a problem where every time the heat would try to kick on, it would turn the thing off. Like it would recycle every single time.

And I got super frustrated, right? So my wife calls up Ecobee support. Dude, we were on the phone for three hours. Nobody does that nowadays like literally they'll be like here let me escalate you to level two oh i'm sorry we can't do anything when i say we were on the phone for three hours it was it was part me willing to do what they needed me to do to be able to troubleshoot the thing i literally was up underneath my house taking the panels off the furnaces and the ac things taking pictures of

wires sending pictures of wires from the thermostats to the two units dude after it was all done they sent me back a picture with the wires because i'd split them out real nice so you could see the separate paired up wires right and they labeled them abcdef and they said i want you to take that black wire from this one over here and put it into e and i was like really like three hours man nobody does that i'm not lying as soon as i got done with that everything worked perfectly three hours and check this out i'm testing the system and the phone hangs up. And I'm like, oh no. Like, I can't, this is horrible. She calls me back and she's like, I couldn't stand it.

She said, I had to know, did this fix it? And I was like, it totally did. The next day I went and I bought another one. Because I was like, you know what? If I'm going to get customer support like that, like you can't, you don't get that anywhere nowadays. So, you know, plus one, if anybody's looking at getting a smart thermostat, super happy with it so far. Um, it's really cool.

And it comes with, that's why I got it over the nest. It came with, uh, additional room sensors. So you could literally, you put it up and usually the, the sensor is on the thermostat itself, right? So if you have another room that's a little bit hotter or one that's colder, typically you're only getting what's at the thermostat. Well, you can take these sensors. You can buy up to, God, I forget. It was like 100 and something sensors that you can hook up to one thermostat. A little bit overkill.

But I put it in another room and it'll balance it out. It'll even say, hey, do you want me to only balance it between rooms that have activity in them or do you want to just always balance it between rooms that have activity in them or do you want to just always balance it out so that's actually why I went with that because I was like okay well that's a cool feature I'll try that so anyways a huge plus one for that so I had to share that because that that was just killer and it's technically you know kind of sort of geek stuff so yeah I was surprised that you went with that over the nest, but the sensors, that is definitely one difference, uh, between them. But I will say in support of nest, I've had almost an identical, uh, experience is what you described. Yeah. We're literally you're they're like, uh,

cause even in the app, they're like, um, you know, send us a photo of the wiring and then, uh, they'll come back and be like, no, no, plug this wire into that and see what happens. And yeah, you know, the crazy part was it wasn't bad wiring at my thermostat. It's just like anybody who has a house set up. The electrician, the electricians who set this system up, they use different color wires. So they'd splice a black into a blue over here. And so tracing it was a nightmare so the wires that i ended up switching were in one of the thermostats that were that not not the thermostat in one of the ac units that was buried in there

so i was like man this is ridiculous so yeah i think the other part was i didn't want to give any more google any more data to google well that's why i was surprised that you went with the ecobee over the nest considering how uh Considering how involved you are in the Google ecosystem, they have all my life. It would seem like that would already make sense, right? They don't need to know that I need my thermostat on 70 degrees at night. I'll give that to somebody else. You found your Google tipping point.

I did, I think. I don't know. So at any rate, yeah, I mean, fantastic little device. I'm happy with it, but the customer support was off the charts. Very cool. Cool. Oh, and then the next one. So Joe, Zach, and myself were in the Slack channel.

And if you're not there, you should be there. You go to www.codingblocks.net slash Slack, and you can auto-invite yourself into our Slack channel. But one of our friends on there, Ryan Monster, his name's actually Ryan, he wrote a plug-in that is probably one of the most popular in the Visual Studio store. Isn't it?

It's up there. Funny story, I installed 2017 recently and I started a new ASP project and it gives you a little pop-up and says hey, there's a couple of plugins we suggest. And this was one of them. Oh, that's killer, man.

So I guess we should probably explain what it is. It's a thing called Glyphrend. And basically what he's done is add support to Visual Studio for several different glyph or icon libraries. So he's got one for Bootstrap. He's got one for Font Awesome. There were a couple of other ones that I can't remember. Well, I told him how I normally work because I do a lot of work with Font Awesome. I normally go to

the website. I'm like, oh, I think it's like a suitcase or maybe it's like a flying saucer. And I'm like control effing around the page trying to find out. But with this plugin, I basically type class equals and I start typing in the name of the classes and it functions just like a search. So it's saving me like multiple trips to the internet and doing the same thing. And it shows you the icon right there. So you can type like circle and it shows you all the ones that have circles in it or whatever. It's just really great to use and it's seamless. Yeah, it is. It is beautifully done and we helped them troubleshoot it. Like we installed like 20 different versions of it. Maybe not that many, but we were helping him through it. And so he's made us, he's made us immortal.

He put us links on his page. So thank you for that. And if you haven't checked it out, we'll have a link for it here because it really is excellent. It's enough to make you want to use visual studio. If you're not a visual studio person, it's that good. So, uh, and then, uh, you got this one out low. Yeah. So we would like to send you some stickers. So head to www.codingblocks.net slash swag and send us a self-addressed stamped envelope. You can find the address to send it to at that URL and we will send you back some stickers.

Excellente. And then, and by the way you back some stickers. Excellent. And then, and by the way, I'm sorry. I hate to interrupt. You're good. Go ahead. I just looked it up.

I'm placed a link in the show. It's 340,000 downloads and there's a chance it might just be the version I'm looking at. So that's pretty crazy. That's a good percentage of all installs. It's a killer tool. It really is. Um, so I've not

been as busy as Joe and he'll tell you here in a second, but there was a conversation that we had in episode 55 that I'm sure probably a lot of people got lost on when we were talking about C-sharp specifically a public variable versus a public property. And I kind of wanted to, to flesh that out so that people could actually see what we were talking about. Cause we were talking about behind the scenes, it creates getters, setters, and without actually seeing that it's kind of hard to follow. So I did create a video for that, uh, the links up here and you know, if nothing else, it'll also give you an idea of some tools that you can use to really kind of dig into the stuff that you're doing because.NET, you know, C sharp or even Java, that all gets compiled down to code that runs inside of VM. And so you can actually look and see what did it do to your code?

What is it doing behind the scenes when you write your code? So definitely go check that out. I think it'll be helpful. And you know, I did get a feedback on the video saying that maybe I should zoom in on the code. So I'll make sure I do that next time. Yeah, and I actually got the same feedback on some of the videos I've been doing. I've got a little series going call I've been calling mini code adventures. And I just did the game of life and amaze. I don't remember if I talked about amaze on the last episode. But so there's a couple more videos like that. I also working on a little game and I started talked about it on the last episode. So there's a couple more videos like that. I'm also working on a little game, and I started a new channel on Slack called Game Dev Wannabe,

which is mainly just me talking about how I want to be a game developer and the things I'm trying. I feel like a lot of programmers want to make games. So anyway, I've just been having some fun with that and making some videos using Ndepend and also looking at just different kind of patterns and stuff. And you should check that out. Yeah. Great way to learn. Honestly, I watched all of them and, and like the one where he talked about what was the interface segregation principle.

Like he walks through how he can make his code easier to maintain by going through that and then using a static analysis piece of software to show that it's actually improving so good stuff yeah it's funny um i got mixed up on it on the last episode i think i tried to do ioc or something for the uh the ion solid and so i was like i obviously i need to go refresh my memory on this pattern i read about it and i was like hey wait a second if i followed this pattern it would totally help me with some of of the data I've been looking at and depend. So that's how that came to be. So that was pretty cool. Very cool.

And I also wanted to mention I was on the Productivity in Tech podcast. Luckily, he allows people who want to be productive to be guests. So that's how I got on there. So if you want to hear me be talking about my struggles with being productive or trying to be productive, as well as my dog eating my Fitbit and aliens and a dream i had where i was playing board games with the obamas um you should check out that podcast i may have come off a little scatterbrained but i had fun so i hope you like it oh okay so there was uh another thing i had in here there was a conversation that came up i think in gear on the slack channel about a week ago. And it was one that I think a lot of people kind of question, like what specs are good specs for

hardware when you're a programmer? And, and obviously this is, this is a fairly open-ended question for one that may need to be tailored to a user's specific needs. Like if you're doing a lot of programming that deals with graphics and that kind of stuff, you're probably going to need something that's got a beefy GPU and that kind of thing. But I thought it would be kind of nice just for us to throw out what our ideas on what our ideal, if you're not going over the top

and let's say you got a budget of about maybe a thousand bucks, like what what would you think your key components would be hands down ssd would be one of the first factors i would go after i agree well now that computers are getting so much slimmer especially if you get the the top tier models it's really hard to upgrade hard drives sometimes which is something alan and i have both been running into so i think that you should spring for the larger hard drive as well. And it's just as much RAM as you can get. And actually a big factor for me for laptops is actually the keyboard and the monitor because those, you know, it's those peripherals are built into your

computer. So you really want to make sure you like them, which is why I usually think of Macs as being my primary choice, but now that they got rid of the F keys, I don't know anymore. So that's interesting. You went straight to laptop. I don't know. Personally, I would also go for a laptop, but going to the hardware specs, I think I would prioritize SSD first.

And then probably 16 gig of RAM is basically what I think is, as the low end of what I want in case I need to do any VMs or anything like that. And a lot of IDs chew up one to two gigs of Ram right off the bat nowadays. And then the other thing is the processor. Like I'm one of those guys that always wants to look at an I seven and be like, I need a nice seven,

but realistically, like we all remember vlad vlad made a really strong point of dude give me an i3 give me some ssds and give me some memory and i'm good to go now i'm not crazy about the i3 i'd probably jump up to the i5 bare minimum but for me those specs are key and then the one other thing, if it's a laptop, it better not have a funky keyboard layout, like that shift key and that left control key and that right shift key and that right control key better be in the right place. Otherwise I'm not having it. So those, those are probably my, my order of precedence. So, uh, when I do my, my video recordings, um,

the ones I do on windows, I record to the Mac because I've got an ultra wide monitor and i don't want to record a super wide resolution but man i tell you like using the mac on its own fine using a windows keyboard awesome no problem i got the shortcuts no problem but man when i rdp from the mac into windows i cannot get those keys right and so you'll see if you're watching my videos like a lot of times like i'll be trying to you know open up a console or something and i'll freaking the the mac email application will pop up a console or something and I'll fricking the, the Mac email application will pop up. Like what is going on? I don't,

I don't even know how to get back to my window. I'm trying to alt tab and like things are just going haywire, you know, like you're seeing my, you know, like movie time is your calendar or whatever. I was like, I'm trying to close stuff.

I don't know what's going on. My number one, when switching between, uh, OS 10 and windows 10, uh, when I between OS 10 and Windows 10, when I, with using the same keyboard, will be, it never, it'll never fail. I'll go to like Chrome and Command L. I just locked my house.

Because it's Windows L now. Right. Yeah. Yeah. Yeah. There's, so yeah, there yeah, there's fun things there. But, yeah, so I think we're all in agreement. Hard drive, it's weird because back in the day, like,

everybody would say get the most RAM you can, right? But now it's literally go for an SSD. If you're on a spinning drive. Yeah. Yeah. So I think the SSD is huge. And then from there, get a decent processor, but max out your Ram, right? Like it, or get at least 16 gigs and then go from there. And you'll have something that'll last you

several years with, with good, you know, results. Unless again, if you're doing anything that's like graphical, then you'll probably need something with a higher end GPU. I mean, you'll have to tailor it, but I think those are good baselines. So, all right. Yeah, we actually, in a previous conversation about hardware specific to laptops, we would be remiss if we didn't bring this up because we actually got some constructive criticism,

let's call it, in that, I don't remember how long ago, it was an episode a long time ago, but at the time, we had reasons for suggesting Max because it was, you know, well, it had the F keys for one. Never did we realize how much we would want those. But, you know, one of the arguments was, well, you could develop on any platform, you know, because you could run any operating system on it. So you had that kind of versatility.

But we got feedback that one thing that we didn't take into consideration that wasn't mentioned in there was support. And that if you went to something like a Lenovo or a Dell, then you could potentially, depending on what level you got, you might get like a 24 hour onsite support where they would come to your house and do the repair. And if this was for business needs, that could be huge, especially if it's like personal business needs, that could be huge, right? Especially if it's like personal business needs. Whereas, you know, if you have a Mac, you're, you know, going to schedule an appointment at the genius bar, go down to the Apple store. That's probably two hours away from your house. Yeah, that's a good point. So if you're going to go the Mac route by two of them, I think that was the takeaway here. I was going to say, if you,

if you buy a mac you obviously don't care about your money so i just buy another one oh that's not fair you don't care i'm running on one right now yeah uh yeah a 2015 mac yeah dude the the 2016 really hurt me and i'm about to build a hackintosh i'm about to do it so i'll let you know how bad it goes so one of the guys that did the audio template for us that's what his daily driver is is a Hackintosh yeah he runs on a Hackintosh so he's been doing that

for quite a while and you know he's kind of talked me into it so I think I'm going to do it so anyways I think we burnt that up so who wants to do the next piece? Me, uh,

Ben, you won, um, you won the book for a clean code from episode 54. So, uh, we'll hit you up about how to get that to you. Um,

right now. And so congratulations. Yeah. Awesome. And along those lines, we also ran a jet brains contest where, yep, you heard us right. We gave away a one year subscription to a jet brains product. And it those lines, we also ran a JetBrains contest where, yep, you heard us right.

We gave away a one-year subscription to a JetBrains product, and it had all of their subscriptions of the fallback license. So you always have that item. So, yeah, that's like many hundred dollars worth of value. And we did too. We sent it out over the mailing list. So if you're interested in contests like that, and we plan on doing a lot more of them, then you should join our mailing list. Hey, as a matter of fact,

speaking of go to www.codingblocks.net and sign up for our mailing list because we're going to have another little thing that we're going to do later on in this show. We're going to talk about another giveaway that we're going to do. So if you want to be a part of that, head over there and sign up. All we need is your name and your email, and it is a double opt-in.

So once you send the email or send that information, you'll need to check your email and then say, yeah, I got it. This is valid. You know, I didn't go to mailinator and sign up. So do that. I'll say we don't send a lot of junk. I don't think we send any junk on the mailing list. You know, a lot of people, a lot of places you'll sign up for a mailing list and they'll send you something to buy every week. We actually don't have anything to sell, which is kind of unfortunate, but pretty much the only things that we use the mailing list for are contests and a few minor little things of news. We are not going to be inundating you with crap emails, So you should join it if you want to enter in contests and communicate with us. We won't send junk email

until he has all the emails. Yeah, now once we have something to sell, you know, get ready. I'm going to turn that faucet on. It looks like Outlaw just ate a lemon. As soon as I said that, he was like, man, really? Yeah, we're going to take your email.

We'll send you these emails like, hey, this is USPS. We have a problem with your package. Click the zip file. Right. Man, I'm so tired of getting those. Yeah, we don't do that. All right, well, let's get into the main meat of tonight's show, which is going to chapter 11 of Clean Code, systems.

Isn't that so generic? Yeah. Totally. Yeah. Systems. I saw that and I was like, oh, this is going to be a great chapter. Yeah, right away. Cool illustration.

You're so bored. Like before you even get to the year. Wait, no, I probably can skip this chapter right exactly you know what it's funny it's funny that you say that because like the first 10 chapters are like the about the most like little minutia about like how you write like each line and it builds up the functions and builds up the classes and for the most part i think that's not the stuff that drags you down so much as the bigger picture stuff now a lot of times you can say that those little things add up think that's not the stuff that drags you down so much as the bigger picture stuff. Now, a lot of times you can say that those little things add up and that's what kind of makes the bigger messes.

And so those little things add up. But I think a lot of at least the things that I struggle with are actually more at the system level and kind of keeping things organized and clean so that I can make big sweeping changes, not just little, you know, private internal struggles. Yep. So who's got this first one here? Well, right away, every chapter starts off with an image and maybe a quote or some message, right? But there was this one quote from Ray Ozzie that I just loved the first part of it,

which was complexity kills. And it's so true. And when it comes to software development, no matter what you're doing, as soon as you have to work in anything that's overly complex, more so than it needs to be, like it'll be a huge time suck every time.

You don't write in your book? We're holding up pictures of our books to the camera. Do you write in your book, really? That's blasphemy. Not very many. I was in the doctor's office today reading this book and making notes.

There you go. And the people in there were looking at me like I was the Antichrist. Looking at me like I was the devil. You can't deface those pages. It's my book. I paid for it about 10 times now. All right.

That's true. So yeah, complexity kills us. So true. So one of the things that they start off this chapter with is saying separate constructing a system from using it. And that seems like a very simple thing, but really what they're talking about is they go into this analogy of a building, right? Like when you look at a building that's going up, there's a bunch of people out there working on the building. They've got the frame up, there's an elevator shaft and all kinds of stuff, people working, but that's not how it's going to be used. When that building's done, it's going to be used in a different manner. If it's a, if it's a

supermarket or something, there's going to be groceries in there. There's going to be that kind of stuff. People are going to go in and shop. So, you know, you, you need to separate the two because they are different. Yeah. And I thought that was really interesting too, that they go on from there even, and talk about building a city out of your code. And they talk about the reasons why you don't necessarily put in interstates before you need them. It reminded me of actually playing SimCity back in the day when you had a limited budget. And you wouldn't start by building the high-level industrial, all the big stuff. You wouldn't put a rail system in your city first thing, right?

You need to crawl before you can walk before you can run or crawl before you can walk, before you can run. Is that why? So you got to kind of scaffold yourself up. I think that's why I always failed at that. Like, seriously. I blew my $10,000 budget in, like, two blocks. Yeah, since 2000, you could build a freeway. So you just build a freeway from one end of the map to the other.

You're like, oh, I ran out of money. I'm done. It's time to start again. Yeah. Great game. Oh, man. you're like oh i ran out of money i'm done it's time to start starting again yeah great game so oh man yeah i so that was one of the things i said though and and we've talked about this this is my biggest problem with writing software on the side is if i do a little side project i'm like i'm gonna make this thing to where it scales to a million servers and yeah you know and seriously it's not needed unless you're just trying to figure out how it

would be done. It's not needed. Start with your use case with the story and build up from there. And they'll talk about this more, but, but that is a very key thing is hit what needs to be done. Just make something that works first. Totally. And that's hard to do. What? Yeah. So what were you going to say? I was going to say, like, a big part of this chapter really advocates for having at least kind of two classes for everything. You know, we're talking about having factories create instances and, you know, doing configuration and bringing in frameworks and stuff. So it's kind of funny to talk about keeping things as small and simple as possible and then talk about spring in the same sentence. Right. Those are very different things man when we get to that i'm sure i'm going to rail on that for a second but um but yeah i so what they're saying though is just because the code is so what they were talking about in some systems is like if you have startup code

right like things that are supposed to fire off as soon as your application starts just because it's in your startup code doesn't mean that it doesn't need abstraction. Like if you're starting, if you start baking in dependencies and all that, you can't test it. And they started talking about that. Like if you're doing a new instance of a particular class, you can't build any tests around that. So you don't know if it's actually going to work the way that you think it should. Well, I interpreted the startup code part a little different though, because there is this whole concept that he talks about, about, he gives an example of a lazy instantiation, right? Where he's like, okay, if this thing is null, then new up a new version of that object and later we'll return it. And that way you're never returning back null. You're always protecting against that.

But, um, and you, and from a plus side, you're only creating this thing at the time that it's needed, but you've now coupled the creation of the thing and the getting of the thing in the same method. And you've locked yourself into that object type yep so if you ever needed to change that now

it becomes you know you can't just inject it so it wasn't necessarily startup as in like what your application does the first you know few lines of code that it starts up, it was startup as in however an object gets started, however its life is started, that's the startup code. In this case, it was this lazy instantiation example. Yeah, that makes sense. One example I like to think of

is if settings, a lot of times you'll see code where it goes out and fetches settings as needed, one by one. So as soon as it needs it, it just goes to the database and grabs it. It's compared to doing something like grabbing all the settings from like a database or a file or anywhere and then loading them into some sort of data structure

that can be referenced later. And so they're kind of advocating for doing the kind of input gathering and config gathering and everything you need to run your process or run your thing and kind of having that specified outside of your thing that actually does it. Yeah. Oh, speaking of, you just brought up something that I don't believe are in the show notes here,

but they mentioned in the chapter and I wanted to bring up is if you, if your application typically goes and gets stuff from the database, try and keep that consistent, right? Don't spread out a lot of different configurations, some in an XML file, some in JSON files, some in the database, some somewhere else. So that was an interesting take on it. I don't know that that's always necessarily the best case depending on what your system scales to and all that. But it was, you know,

consistency can be a very big help when you're writing software. Yeah, absolutely. What'd you guys think about talking about using factories to create instances? I liked it. I don't know that I practice it as much as what they were intending for it. Like they basically say,

you don't ever new up something from a class period right like it always essentially uses a factory yeah i don't do that like i only use factories when there's like a specific use case i want a factory for by default i like i just do the new thing and i've gotten away from using constructors because i'm kind of leaning towards more this idea that the object shouldn't know what it needs because it doesn't necessarily know what it's how it's going to be used right it's supposed to be like this dumb little thing that does one thing so i've gotten away from that even though it's awkward for me to make code that relies on say a property being there um and you know counting on the value not being null and then not enforcing that in a way that's easy to enforce like via a constructor so

i'm still i'm not real happy with that pattern but it's something i've kind of accepted well i can back you up on that though because what i like kind of where you're going is you just have a default constructor you know parameterless constructor but you're speaking specifically in like c sharp uh terminology i like the object initializer uh way of uh creating the object and initializing it, where I don't have to create a specific constructor for that specific variety of parameters that I want to include in that order, right? I can just let the object initializer take care of it. Yeah, so what you're talking about essentially, though, is behind what you're really doing is calling an empty constructor and then

passing in the values that you want to be filled in into the property. So that's the object initializer. Right. Yeah. I'm a big fan of that. Yeah. And it's so nice for testing. It really is. It really is. Cause there's no state to set up. You pass in the state that you want basically. And I am curious though. So if you have an object that let's say like an order object that's supposed to calculate the total of all the order line items. So like you can't really get away from that terribly much. Can you, I mean,

you still, you're still going to need to use maybe either a constructor or, I don't guess you do. I guess at that point you could use methods within the class to actually do the calculations for you. So I don't know. I didn't really think anything ahead of time for that. But anyways. Yeah, it just kind of makes me uncomfortable to have a ready solution. If I just force this constructor to take this parameter that I know that I need

that I can rely on having it later, and I can even check to make sure it's not null in the constructor. I never have to worry about going away because I'm managing that at this point. And I just hate to have such a nice tool and then to not use it because I want to be able to do dependency injection or make testing easier. On the other end, like I know exactly why I'm doing that. Like if I see a class and there's even a parameterless constructor, and the first thing it does in that constructor is go and get a database connection or grab a file or do something. When I go to unit test that,

the first thing I do is pull those guys out to properties, and it's just a pain in the butt. So I like the idea that whatever code is calling that gets to make those decisions about those properties. And then you can use a factory to kind of get around the problems, but I don't like the idea of having factories for everything. Yeah.

I am a fan of factories when there's going to be more than one, but if I only have the one thing of what, you know, I'm trying to not say type, but yeah, like whatever that one thing is, I don't necessarily need a, I don't, or at least I don't feel like I need a factory for that. So maybe I'm wrong.

Maybe as it relates to this chapter, maybe I'm setting myself up for failure because now I'm saying like, oh, well, as soon as I have a need for a second or a third thing that's similar to that first one, then I'm saying at that time, oh yeah, I'm going to have to create a factory then. I think part of it might also come down to what it goes into in a little bit that we'll get into is the dependency injection and hooking that kind of stuff up to where it knows how to instantiate those things through a factory. So maybe that's what it is. But again, if there's only one type of a particular or one, one implementation of a type, then yeah, it kind of doesn't make a whole lot of sense. So I don't know. But that brings us into dependency injection. So I think it's interesting because honestly, I've seen tons of conversations around dependency injection. And a lot of people don't

just if they haven't used it, they don't understand it, right? Because the way of writing code that you start out is, okay, well I'm in here and I need a new instance of this. So I'm going to new up that class. And then, you know, whatever it needs is going to new up those classes. So the whole idea of dependency injection, and they said it really well in here is a class takes no steps to resolve.

It's just, it's dependencies. It's completely passive. So if a class needs, if a man, I don't know if, if a car class needs an engine and a drive type, those get wired up for you behind the scenes. Like you're not actually going in there and say, Hey, give me a new V8 engine. Give me a new rear wheel drive system that all happens for you you know what um working in unity i'm a little game i've been working on like man patterns abound everywhere it's it kind of makes me feel like more of a programmer doing some of this stuff because i am running so many things like a dependency injection in unity is a very it's very much a first class concept and it's because I'm going to write, say an

enemy class, right? And I'm going to have a sprite that represents that enemy, I might have different attacks that that enemy can do, yada, yada, yada, I can have the sound that they make when they, you know, attack or get hurt. All that stuff, stuff that I would typically if I was doing this outside, you know, I would probably, you know, do it, set it up in constructor, I'd have some sort of data files, I have it in database, I would select it, yada, yada. No, in Unity, it's got really great mechanisms for exposing that stuff in the UI if you make them public fields. So I say, here's my enemy class, which is a component. And it has a public sprite, it has a public attack sound, public attack set. And then in Unity, I can go and compose those and I could do it dynamically in script too. But it's just got this really nice support for the

application at runtime, filling in those values from other places. And so that's been really cool to kind of see that. And so I've been really feeling the benefits of dependency injection. So now everything I write, the first thing I do is rather than saying go to sprite sheet, get, you know, square 11 comma 2, whatever. I just expose a sprite sheet or a sprite class. And then in the UI, I'm able to drag a drop or assign that dynamically. And it's been great. You know, it's interesting. When you said Unity, I was like, is he talking about the Unity dependency injection framework in C Sharp?

No, you were talking about Unity 3D. Yeah, Unity 3D, even though I'm doing a 2D project. Okay. So that's, yeah's confusing. Injection framework in C Sharp? No, you were talking about Unity 3D. Yeah, Unity 3D, even though I'm doing a 2D project. Okay. So that's, yeah. Okay. There was a quote in here that I really liked, though, that I had never thought of it this way, but it summarized it quite nice.

Dependency injection, the application of inversion of control to dependency management. It is. Yeah. I'd never considered it like that, but I was like, yeah,

okay, I'll buy that for a dollar. That makes sense. Yeah. I do get confused on those terms. Like they, it seems like you can't say DI without talking about IOC and, but it's,

I kind of think of them in the same way. Like maybe they're, I don't know. I don't know where the line is. Well, I think so. I may not be 100% on here, but dependency injection you can do through constructors, right? Dependency injection. You could say, uh, if, if you had a particular class and it took in an I person and it took in an I

account, then your dependency injection would be you pass it the person and the account so that that class that's going to use those things doesn't new them up. Right. So that's a form of dependency injection. You can also do it with setters within a class. So if you say, you know, set something, it will create that dependency for you. Now, when you talk about the IOC, instead of that class doing things, it actually inverts the control, gives it away and says, create this dependency and give it back to me. So I, they kind of go hand in hand, but, but usually IOC uses dependency injection. Dependency injection doesn't mean you're using IOC. Is that? Backwards.

Did I say it backwards? IOC is, okay, I'm going to, this is from the top answer from Stack Overflow for this question of inversion of control versus dependency injection, right? And inversion of control is a generic term, meaning rather than having the application call the methods in a framework, the framework calls implementations provided by the application. Okay. Dependency injection is a form of inversion of control where implementations are passed into an object through constructors, setters, or service lookups, which the object will depend on in order

to behave correctly. So the author of this answer gives an example of inversion of control without using dependency injection, for example, would be the template pattern, because the implementation can only be changed through subclassing. So it's the application that is providing the implementations that will be called in that example. Cool. Now I'm putting this link in the show notes right under this. So if you want to follow along with this, and actually this ties really back to the last section uh that's how we got there is um if if if i'm a class and i get my stuff passed to me from another class who got its stuff passed to them who got it from another class like where does it all start from and basically the answer is that main that's where

we talk to that's the starting point or if we're talking about using a dependency injection framework and there's some sort of binding config you know xml file or some code somewhere that's responsible for tying that stuff together but the idea is to have that stuff come from one point and there's some sort of binding config, you know, XML file or some code somewhere that's responsible for tying that stuff together. But the idea is to have that stuff come from one point. And so that one point can change if you want to use the app for something different or configure it differently or run it with different stuff.

Yep, totally. And the one that this whole chapter is, it basically revolves around Java, right? So they bring up spring which it's objects wired together in xml configurations and if you've never seen it you don't ever want to see it i've heard it's gotten a lot better right like it's not well this is definitely an old version where this book was like from what 2005 so i think the last time i saw spring was a little over two years ago and they were still using all the XML configurations and it just hurt my head.

Right? Like it was so many config files, but apparently I think, uh, what's the name of it? Spring boot or spring. There's like a new version of it that apparently is a lot easier and a lot nicer to set up and use.

But well, he, he references in this chapter though, the later versions, I thought I in this chapter the later versions. I thought I remembered him referencing the later versions used the annotations. That was in EJB3, Enterprise. Okay, maybe I remembered that wrong.

Yeah, that was slightly different. But the key is the way that DI is handled in something like Spring is you basically set up all the relationships beforehand so that if there's an interface, an IPerson somewhere, it knows how to instantiate that. So if it's somewhere in your code, you're going to use an instance of IPerson. The dependency injection framework will handle creating that thing for you, and then it's just available. You're not newing up that class. It just becomes available to you, which is kind of magic and kind of cool. Yeah. I did a little bit of, Oh, sorry. No, I was just gonna say, I've seen the code that you

were referring to, you know, a few years back with spring. I've seen that as well, but I'm trying to think of like, well, those were in small little, you little, isolated apps. They didn't have a ton of functionality about them, which is probably the way it should be anyways. But in some monster applications that I know that the three of us have worked on collectively over the years, it's like, could you imagine having one monster XML file that defined everything, every one of those relationships. I'm like,

yeah, no way. Wouldn't want to do it. It would hurt you. I mean, it's, it's basically like an internal schema of how objects relate. And that's man,

which is probably a good pain though, because then it would force you to not create these large behemoth applications. Can't argue with that. Can't argue with that for sure. But yo, I'm, I'm here to write four loops and two bubble gum,

but not at the same time. That's dangerous. I'm all out of four loops. I think I got that wrong. Yeah. I did a little bit of spray. It was just a tiny bit of spring a couple of years ago. So I don't have a lot of experience with it,

but I remember being like, okay, I've got a simple problem. Like I think I was something like I didn't want to allow or we had a problem with like negative inventories or something it's like okay so i just need to check if the inventory is negative and throw an error it's like okay cool so i don't have to do that where's the code it's like okay well first we create a class that uh takes an integer and if it's negative one it throws an error i'm like okay so that's one line it's like all right and now we're going to

spend the next 30 minutes trying to configure it via XML to add it as a filter onto the whatever filter, handler, filter, factory. And it's like, what? And I was like, okay. So there were like three lines of Java, which is amazing in itself, right?

Like three lines of Java to do anything. It's like, you know, that's amazing. But I just felt like there's no way I can understand this from just looking at this, what I think of as code, because it's like you know that's amazing but uh i just felt like there's no way i can understand this from just looking at this what i think of as code because it's really not it's that you really have to have the whole picture of mind that's hilarious so there are some dot net di frameworks and i put a link to them on new get why does new get not allow you to sort by most downloaded like i don't know but what is that yeah so you have that link there, but what I thought

was kind of comical in it is like the top two dependency injection frameworks that I know of weren't at the top of that list, and that's Unity and Ninjek. Unity's number one on that list. I thought it was further down. No, that's the first one. 5,300,000

ish downloads. Castle Windsor is up there. Structure map. But NINJEC is like right up there in the same count. Yeah, I don't know why NINJEC wasn't further up. I mean, that's... I didn't see structure map in there. Structure map's like the fourth or fifth down,

wait, fifth, sixth. Yeah. I saw Castle though. Oh, there's structure. That's right. But Castle and Structure were like way down in terms of numbers though. It was really like the main contenders are Unity and NINJECT

according to downloads, and they weren't there. Yeah, so go ahead. It's because NINJECT is a dependency injector. They need to update the keywords. Oh, right. Yeah, actually, the keyword, it's got 4 million downloads, but the keywords aren't so great, so that's probably what the search runs off.

Interesting. Yeah, that probably is Nougat. I don't like it. Anyways. You don't like Nougat? Nougat causes me pain. If you've ever created a package, it's not trivial.

Even creating the package is like, here's the 11 page 11 page pdf that tells you how to create the package and then here's another one for uploading it it's not that bad it's pretty bad well if it's public though oh yeah good point because you got to sign it and everything yeah so there's a thing all right so when i first got into dependency injection a while back, one of the things that bothered me was like, I don't want this thing newing up objects for me, just because I have a reference to I something, right. Um, it turns out the better dependency injection frameworks out there won't, they'll only create them when they're needed, which is good. Right. So you don't want this huge object graph of a bunch of stuff

that's never going to be used just eating up your heap space. So that's pretty cool. So they actually say most DI frameworks won't construct an object until you need it. It's called lazy initialization. So that's really cool. I think Ninja is lazy by default. I could be wrong on that, but I think that's like one of their dealies. That's nice. And then this goes back to the factory thing that we were talking about earlier is,

I guess the reason why you use a factory is they say that they allow for plugging in the factories to help with this idea of lazy evaluation. I don't know exactly how that differs from the initialization, but I don't know. I guess if you get super deep into dependency injection, maybe those come into play a little bit more there. So when I did some exploring with NINJECT originally, what I would end up doing is creating like a bindings file, which is not a great name, and it would create a container for you, which is also not a great name. But essentially, what you do is you could configure stuff. And you could basically say like, hey, when they ask for an I cart service, then you give them this and you can define this and it could be, you know, creating a new object, like they have

some default stuff set up for you, it could be using a factory, which is pointed to somewhere else in your code. It could be grabbing a factory, which is pointed to somewhere else in your code. Um, it could be, um, grabbing other services and constructing stuff and it would like look stuff up recursively. And so it was really good about how you did that. Uh, it was just kind of awkward to me how you would actually get those items. And so you'd be in your, like, say your order service or something. And you'd be like, well, let me get this container from, I guess the singleton. And then I asked for my cart service and then it would know. And by the way, in the bindings, you could also say like, hey, this is scoped to my session. And so you could just say, hey, get iCartService and it would get whatever cart service you configured. So it would actually, you could get the one for that request or that

session or for that application or whatever. You could do all sorts of cool stuff, and the code where you used it was just really dumb. Like, hey, get me a cart. I don't care. Yeah, I mean, I've not messed with Ninjake. I've messed with Unity a little bit. And there weren't XML configurations. You actually configured it through code, which I kind of liked because it was very easy to reason about, but, but I just felt that that defeated the point though. But you're doing it in a different place. You're doing it in a more, um,

global place, right? Like what's, what's the difference, I guess, between writing code to set it up versus writing a bunch of XML files, right? Like cause the XML doesn't have to be compiled. Okay. That's a decent enough point. So I actually like structure map because structure map can just scan the assemblies. Oh really?

Yeah. So you could just like swap out your DLL and all of a sudden you got a whole new set of, uh, the types that are going to, that are going to get thrown in as soon as it it scans it well i guess that kind of assumes that the same assembly uh same dll name right yeah but yeah you know i always thought that was kind of this the simplicity of structure map was that you know it just scans it for you so so i get the whole not needing to be compiled but really what

you're going after more than anything, I mean, I guess if you screw up one of your mappings, it'd be nice to be able to just change a config file and it'd just start working, right? But on the flip side, like, I don't know. I guess I could see that. That's definitely a point for it. So, yeah.

Anyways, there are a ton of them out there, and there's probably even more for Java. But I think spring has pretty much won that battle over the years. Right. So, oh, this is one thing that I really liked. This is after it went past this was there is a myth about getting it right. The first time it doesn't happen. Don't ever try and code the perfect application. The first time it says the guy who can't get started because he's always over-architecting it right from the start. No, no, dude. For a billion concurrent users that could scale infinitely wide.

I get started. I get started. I never get finished. But, you know, I mean, I'm teasing you here, but yeah, you're totally right. He says this in the book that there's this myth about trying to get it right the first time. And really this chapter, there was this, uh, like overarching theme among it, which was, you know, just to keep, you know, do a little and then iterate and make some change to improve upon it. But don't, don't try to do everything right now. Right. And in fact, it was, it was, um, I forget exactly how he worded it,

but it was something along the lines of, you know, focus today on today's needs, right? Worry about tomorrow's needs tomorrow. And when it comes time for tomorrow to get here and worry about tomorrow's needs, then you can refactor it and expand for tomorrow's needs at that time. Yep. And, and probably something you'll really enjoy here is they even say you should iterate on the stories today, the user stories that need to be done, do those today and do more in the future as they come along. Don't be afraid to be agile and make those changes. And what enables us TDD and clean code, because if you have test driven, if you have tests in place,

then you're going to be more confident about making those changes. And if your code's clean, then it's not going to be painful to make those changes. So this is where it's all starting to come full circle. And so when we said at the beginning, the name of this chapter kind of stunk, there was a lot of good meat here, but it was just funny.

Systems. All right. Yeah, well, was just thinking about that um when i was doing my video about the isp like you can't just do the s in solid right you can't just do the o you can't just do the l like all these things work together and same with this stuff too you can't really you know separate your concerns into the main it's just not practical without something like dependency injection and um it's just a lot of this stuff it really requires the others like you can't really be agile and make changes like the changes they make you can't manage that kind of complexity that

we're talking about creating so many classes without good clean abstractions and so all this stuff is really uh really difficult to bring to brownfield applications, in my opinion, but it's still good to think about. It is true. One can dream. It is. Yeah. All right. So with that, let's take a moment to say that if you have taken a moment already out of your busy, hectic day to stop by and leave us a review.

First, know that we greatly appreciate that you took the time. And if you haven't, we would be super appreciative if you would. You could head to www.codingblocks.net slash review and find easy links there for your favorite podcast aggregators and know that we would be super in your debt. Awesome. And, let me just interrupt real quick.

I remembered the thing there. I don't remember if we talked about this on the show or not, but there was a thing I had to remember that I really wanted to mention this show that I promised somebody that I would. And I just remembered it. Do we want to talk about it now? Do it now. All right. And I just remembered it. Do we want to talk about it now? Do it now. Alright, I have to Google it.

So now you're not going to talk about it. No, wait, you're going to Google it? So, yeah. I probably shouldn't have interrupted until I figured out what we were going to do. Oh, man. We've got off the rails. So what it is,'ll tell you i'll just i'll do we'll just keep it rolling so there is a github game going around uh which is a project that isn't really

scoped out um so it's as agile as you can get and i'm looking it up right now so we can figure out who started it and how to contribute to it but it's basically a game and um the the one that i was the i contributed to uh zach brady started he did a little application that was kind of it was like um like a mock translation app where you would kind of translate some words and i am i added emoji support that was my contribution so it's kind of like a chain letter a little bit like each person makes a little contribution and it moves on. So yeah, GitHub game, we're going to have a link in the show notes as soon as I find it. Well, while you're looking for that, let me take this opportunity to remind you again that if you would like some stickers, you can send us a self-addressed stamped

envelope. You can head to www.codingblocks.net slash swag and find the address to send that to. And we will gladly send you one or more of these amazing stickers that I'm pretty sure if you saw these, you would realize that you must have these in your life and that they would look super awesome on your laptop. Hey man, one of the reviews we got, the guy even said, man, I don't put stickers on anything, but I might actually have to put this on my prime real estate. I was like, yeah, baby.

Yeah, that was awesome. And even if you go to Slice Swag, you'll find there's a setup for some shirts that we've been trying out here. So you'll find links to that there as well. I think you're sporting one right now, aren't you? You want to give a little view here? Yeah, you know. Push that down.

Look, look. Bam. Bam. The bam. The bam is what did it. The bam. It wasn't enough for me to lean back so that you could see the shirt until you heard the bam. Yes, it. The bam. It wasn't enough for me to lean back so that you could see the shirt until you heard the bam.

Yes, you needed the bam. All right, so while Joe's finding the link, what's our next thing here? I got it now. Oh, you found it? Yes, it was G105B who mentioned the GitHub game to me. It's his own GitHub account, so you can go to github.com slash github game slash one and it's up to 62 commits now um i i'm looking at the commits now and there's a lot of names that

we've talked about like uh daniel ponzabon um zach brady's in there um just all over the place and so it's really cool to see and you should check this out and make something it's got some simple rules in there basically if there are less than 10 collaborators it will just merge. If there's more than there's like a little voting system, and it's just like a little fun thing. It's like, you know, three paragraphs on the readme. So you should check it out, make a change. And, uh, you know, they've got some general rules like avoid violence and keep everything legal. We got it, got it. But yeah, it's just kind of like a little fun thing to see how far we can take this. And it's really cool. And you should check it out. You know what? And along those lines, we get emails and comments all the time about, you know,

how can I get started in programming? If you are new and you're in school or you're not in school and you're trying to break into programming, this would be a great way to somewhat get familiar with GitHub, make some changes, work in a collaborative way and try it out. Like this could be awesome. And this one was started by G105B and it's a little bit different than the one I contributed to. So I will have to add emoji support to this one. Awesome. All right.

So what's our next section here? Well, it's time for one of my favorite portions of the show. Survey Says. So in our last episode, we asked the question, what type of overall development floats your boat? And your choices were gaming. I want to make something people play with. Business apps. I want to create apps that solve real business problems.

Machine learning. Data science gets my brain moving. DevOps. I want to make software delivery smooth as silk. Big data. I want to pour through all the bits. Hacking. Rever reverse engineering is how i butter my bread or frameworks i want to build the next great tool for developers all right so let's see who went first last time do you remember joe did joe okay so we'll let alan go first this time given those choices gaming business apps machine learning devops big data hacking or frameworks i'm gonna, business apps, machine learning, DevOps, big data, hacking,

or frameworks. I'm going to say business apps. That's what most people choose. That's what floats most people's boat. I'm going to say business apps because we've got so many. I'm going to go at 27%. 27%. All right.

Me? Yep. Sure. BizApps 28. Oh, come on, man. 27%. All right. Me? Yep. Sure. BizApps28. Oh, come on, man. Well played, sir. Well played. Prize is right.

Rules. What's up? All right. Well, Showcase Showdown sucks nowadays. That is so amazing that he did that. So the answer is Joe won. Oh, come on, man. I was right.

Yeah, but you both underestimated it by a lot. Oh, really? It had like 54% of the vote. I was shocked when I saw that result. What's the next closest? Hold on, hold on. I think the next closest is going to be gaming. Joe, you want to weigh in on this?

How about we do second place since first place was a runaway? $1. $1? Just for fun, I'm going to say frameworks at 7. I'm going to say gaming at $7. I'm going to say gaming at $12. It was gaming, 16%. Wow, all right. But I still question that.

I'm like, really? Business apps were like, what makes you excited about development? Well, I mean, isn't it cool when you come up with a solution that makes the company a million dollars or you come up with a solution that makes things easier for people to do their jobs? There's a bit of reward in building something that people really find useful.

Don't get me wrong. It'd be cool to make the anger your Flappy Bird game, right? And know that every person on the planet hates themselves because they can't get this thing past the first board but but there is a real at least for me there's a real internal this is awesome like these people like you build something and maybe people have been using a garbage system for a long time and all of a sudden they see it they're like oh my, you just made my life so much easier. And that's rewarding. Like at least for me. Wow. 53%.

Yeah. That's crazy. I'm surprised that I'm sorry. Oh, I was just surprised that machine learning was so low. I would definitely think business apps if it was my business. Not somebody else's. Yeah, totally. Well, cause I'm, I mean,

I understand what you're saying though, with like, you know, if you create some little change, you're like, Oh my gosh, look, I did this one thing and it increased our SEO performance so much that, you know, we brought in an, you know, another million dollars this week. We've all experienced it though. Right. You know, I mean, yeah, that is kind of neat, but like, I was really kind of surprised that that was going to be the one that the audience picked as like, you know, what, you know,

quote floats their boat for development. But yeah. What, what, so what was yours? What would you have picked? Yeah. I, yeah, I don't know. What would I have picked? I mean, here lately it's definitely been machine learning has been like, that's I mean, here lately, it's definitely been machine learning. That's been my free time has been focused on machine learning. Interesting. What about you, Joe? Gaming, I think, right?

Gaming, yeah. Mine would have been big data. Yeah, well, that sounds about right for you. Yeah. I could see that. Yeah. So, yeah, interesting. I was actually talking to Dave Studdart earlier today,

and he might have thought I was joking, but I was talking about my retirement plan for retiring once I can afford it, and then trying to make the kinds of crappy Nintendo and Cubicator games that I wanted to play when I was playing games. That's excellent, man. That's my goal. Hey, man.

Everybody's got to have their dream. Yeah. For this episode survey, we ask, why did you start programming? And your choices are needed to fulfill a business need, wanted to personalize my MySpace theme, took a class in school and thought it was awesome, or to make games. took a class in school and thought it was awesome. Or to make games.

And lastly, I like getting paid to sit. Can I pick two? That's awesome. That is excellent. I don't know how I'll vote on this one Do you guys vote on these? No I leave it to the audience I do if I'm passionate about it I just like to see the results

Before the recording So you can stop there That's like Outlaw's worst fear Click Oh I see all the bars Yeah Oh that's killer up there. That's the outlaws worst fear. Click. Oh, I see all the bars. Yeah.

Oh, that's killing. Wow. Well, I guess I'll know for next time. Uh, and with that, let's jump back into chapter 11 as we dive into AOP. Yes,

I actually, this, this was kind of exciting. So the analogies of cities growing and the pains involved, they, they parallel that to software. Like, you know, as a city grows, you need to improve the highway system. Like you were talking about in SimCity earlier, right? Like you bust down the old roads, you put up the new ones. The same type thing happens in software, right? Like if you need to, to make something scale or you need to improve or add additional features, it can be painful. Um, but going back to the whole thing is you're not going to build the perfect, you know, end product at the very beginning.

You wouldn't build a six lane highway through a little tiny town. You're not going to build a app that will scale to a million servers before you even have a user, right? I mean, apparently I would, but most people shouldn't, but it's, it's a great analogy and it's so true, man. And we've said it probably at least on half our episodes, focus on the MVP, the minimum viable product, right? Get it out there and get going with it. It's a way to do it. Yeah. And I do like the idea of what we're going to be talking about here in the next section was basically aspect oriented programming. And there was a quote here I particularly liked. The real value of an AOP system is the ability to specify systemic behaviors in a concise and modular way. And that

I think to me is a big deal. When you think about things like logging or, you know, doing database type stuff, like I love the idea of consolidating that logic in one area of the code, like one namespace, one, one library, one, whatever, and then having everything else be as dumb as possible. But most of the time when I end up writing code, you'll see a function and I'll have like a, you know, a logging statement saying, Hey, I'm here, whatever. I do some stuff. And then I end up like running, you know, running a query, maybe two, maybe three, maybe some logs in the middle. And that's exactly the kind of code that we're advocating against right now, which is a bad habit of mine. But if you do stuff like that, if you're able to accomplish that,

then not only can you swap stuff out, which is kind of like the primary example that people give that it's kind of impractical, you know, like changing up big databases or something, but just the idea of being able to swap or make upgrades to that as a system, rather than as, you know, like changing up big databases or something. But just the idea of being able to swap or make upgrades to that as a system rather than as, you know, a thousand little five liners sprinkled throughout your code. Yeah, so I think the big statement here is, so you said AOP, did we say,

did we actually say that it's aspect oriented? I don't remember if we did. I didn't. So it's called aspect oriented programming. And what he's just saying is when you sprinkle all these logs throughout, that's not necessarily the absolute worst thing ever. It's not great, but it's almost the, it's the idea that almost every class that you'll see in something like if you're using a log for net or probably even log for J, a lot of

times you have to new up an instance of it in the class and all that kind of stuff, right? So you've got in all your classes, you've got this underscore logger equal new, you know, instance of this logger framework. Well, what AOP does is it says, hey, wait a second, you're going to use logging everywhere in your application. Don't be knowing that thing up all over the place and doing the same thing, just inject an aspect. And, and what that means is, okay, you put an aspect on this thing and it can do your logging for you. Or if you have database connections or retries, right? And this gets into the whole idea of cross-cutting concerns, which is stuff that's needed everywhere. So why would you really want to keep one-offing it everywhere? Aspect-oriented programming is amazing. I mean, Joe brought up the ability to just do the S in solid earlier, right?

AOP lets you do that. It does. It really lets you focus on your class doing that one thing that is supposed to do. Right. And then you can just annotate it or, you know, put an attribute on it or whatever, depending on your language and the framework that you're using to get this other functionality without having to, you know, have that boilerplate stuff in your way. Yeah. So like the retry thing, right? Like a lot of times what you'd see is if somebody was going to try connecting to a database three times, you'd typically see like a for loop, right? Like, all right, I've got my counter. I've set it at

zero. I'm going to try and connect. If it fails and try it again until I get to my counter. Right. And that kind of sucks. If you end up doing that in 20 different places, you've literally copied and pasted that same code. And if you ever decide to change it to something else, then you're going to have 20 places to change. If you have an aspect, you have one place where you put that logic for how that's going to work. And then you basically tell it, Hey, I want to use this aspect on this particular section right here. And when he says annotate it, you might mark it above the method, or in in some situations you might put it in a config file,

but aspect oriented programming is it. Do you like it more than unit tests? Like I've, I've wondered, I, you know, that's a tough one because I will say that if you've never done it, you should try it because I promise you when you're done,

you're going to look at that and be like, that is the cleanest code I've ever written. It's killer, right? It is. And it's so amazing that it works. Like it's just, I,

yeah, I'm, I'm a huge fan. So let's like say, do you like iced or tea better exactly you can't answer this question which part of computers

do you like the best the ones or the zeros pick one you only get one so we said at the beginning go join our mailing list and this is the reason why so if you're a.NET person and you use Visual Studio You only get one. Hey, so we said at the beginning, go join our mailing list. And this is the reason why. So if you're a.NET person and you use Visual Studio, pretty much the de facto AOP framework for.NET is PostSharp.

Like it's the one that comes up the most. And we've got a PostSharp ultimate license to give away. And that, my friends, is close to a $700 value. So if you are interested in getting AOP and put it into your own application, go sign up for our mailing list. We're going to be sending out something here probably within the next week or two, and you'll have the opportunity to win a license for PostSharp Ultimate, which is one of the cool things that it does. And I think we talked about previously is it will even help you fix bad patterns in your code, which is amazing. Like if you think about it, there's lots of patterns that you use and I forget, what was it? The

something no. Oh, the one that was specifically mentioned in the, in the class was the weak event pattern, the weak event pattern, and it will actually help identify and fix those things. And so one of the interesting things, I guess, go in a little bit deeper on AOP in general is there's different ways to do it. But the gist of it is a lot of the ones that are worried about performance a lot, what they do is they go in and rewrite the IL underneath the scene. So you've got your C sharp stuff and you wrote your method, your functions, everything. And then you decide you want to annotate it and put a particular aspect or maybe two or three aspects around that, that method. What it's going to do is when you compile it, it's actually going

to go in and rewrite your, your interpreted language code so that it puts it, it's actually going to go in and rewrite your, your interpreted language code so that it puts it, it's called aisle weaving. And then that way it's not messing with the performance because the other way you have to do that is you have to do some inversion and control and, you know, say, all right, we'll flip this and then take control of it and give it back. So it doesn't do all that. It basically like injects its pieces where it needs to be in the aisle. So it's super fast. So, um, pretty cool stuff. Yeah. And this is important to note. This is a perpetual license. So similar to the, like how we mentioned the jet brains license earlier was perpetual. So is this, this is post-sharp

ultimate perpetual license with a year of support and updates. Yep. So definitely go sign up for it. I mean, we get excited when we talk about it because when you look at code where you see all the same boilerplate stuff, every, maybe that's the way to describe it, right? If you see a bunch of boilerplate code, that is probably a good case for an aspect, right? Just about anywhere. So anyways, all right. So the next part that they talked about in Java, did you have something else you want to say? Well, I was just thinking of like a date. Like what should we set as the date for?

Today's the first, right? For this. Oh, we don't reveal that date. What's going on here? You're giving a little preview behind the curtain. Nothing to see here. Pay no attention. What did he say, the 21st?

Well, I was thinking maybe if we said X number of days after the episode drops, that's how long you have to get on the mailing list before we send that blast out. And that way we give you a chance to go sign up and we're not limiting you. Give everyone a decent chance. I know not everybody listens when it first drops. What's fair? Two weeks? Three weeks?

What do you want to do? Currently we do about a month on the book giveaways because that's every two episodes. Oh, so you want to just give it for the month of March then? Yeah, let's do that. I like that. That's good. Yeah, you have March 2017 to sign up for the mailing list. Yes. Okay. Awesome.

And whoever's on that mailing list at that time will have an opportunity to win. Yep, we'll send out an email that says hey, tell us a joke or something and you win. So just follow the instructions in the email and you will win. And it's $700 value and it's super awesome. Yep, excellent.

Alright, so back to the regularly scheduled program so one of the things that was interesting that they were talking about were proxies that that they were talking about for that that you would typically do in like a java application and it's not just java you do it anywhere but it's it's nothing more than a wrapper around the code and what they said one of the biggest problems of proxies is there it's complicated code, right? Like it's not easy to read. It's not easy to implement. And it doesn't give you what they called system wide execution points, which means you just can't use it anywhere. Right? So to quote myself, quoting Ray Ozzie complexity kills. It does.

It does. Now, they did say in fairness, though, a lot of times proxies are created by tooling, right? So templated code type stuff. But AOP is still a better approach to that because then you can basically use it anywhere. I've never had a good proxy experience. Every time in my life, the word proxy has come up. It's always been like, well, we deployed it, but there

is a proxy. Or, there's a proxy, so you're going to have to do some weird port stuff that you don't want to do. I've never had a good experience with a proxy. I don't think there's a different kind of proxy, but yeah, fair enough. It doesn't matter. Anytime I've ever heard the word bad taste in the mouth, it's always been something I don't want to do. Vote by proxy?

Yes. Yes, none of that. Complexity kills. It does. So one of the next things they bring up is after they got out of the so Spring has its own AOP framework. There were some other ones, and they go into detail on several of the different Java ones. I don't think we're going to really jump into that so much. But I did want to hit a few of the concepts, like a POJO, plain old Java object. In C Sharp, you call it a POCO, plain old C Sharp object.

The cool thing about these are is they're supposed to focus on their domain. If you have a person object, it'll have methods and it can do things within its own object, but it's not supposed to have dependencies on external domains. And that's interesting, right? That's all self-contained. And what that means is it's highly testable and it's highly abstracted. And you know what this reminded me of? Have either of you guys ever looked into the onion architecture? A little bit. It reminds me of that.

So like at the very center of everything are your domain objects because anything can reference them. So the whole idea of the onion architecture really is you got all these different layers of abstraction, right? These peels, everything can point into the center, but nothing can reach out. So basically when you're creating your dependencies, you can always reference something further in, but you're never allowed to like from your domain objects, which are in the very center, they can't reach out and touch anything else. So it's, it's really kind of an interesting way of thinking about your abstraction to make sure that you can literally just, you know, you can depend on certain things working so yeah i really like that is if you think about like in just a contrived example like if you've got a website being an outer layer

of the onion it should be able to reach into some sort of core library to do some sort of you know business logic stuff that business logic should not be reaching out and grabbing like the user id from the http request, right? That's going the wrong direction. Right. Do you know, here's the funny part is I actually started trying to do an onion architecture with TypeScript and it's up on our GitHub. And what is it? GitHub.com slash coding blocks.

Is that what we are? Yeah. So I started something there. I think there's like three class files. So, you know, I got stuck So I started something there. I think there's like three class files. So, you know, I got stuck when I started trying to scale it out. But there is code up there. And the reason I thought it would be cool to do it with TypeScript is people have been doing this in strongly typed languages for a while. And now that you have this notion of interfaces and, and being able to plug things using TypeScript,

I was like, well, this would be interesting, right? What if we take this paradigm and put it to the strongly typed JavaScript? So I don't know, maybe I'll get back to it at some point. So this next one,

right? Yeah. So looking XML sucks. We all agree on that. There's a long sentence there. It equals that. Was that ever XML? Stop reading.

Uh, TL, TLDR. Uh, that's awesome. So the next one, the quote, I actually really do like this one.

The power of separating concerns through aspect-oriented approaches can't be overstated. If you can write your application's domain logic using POJOs decoupled from any architecture concerns at the code level, then it is possible to truly test drive your architecture. So if you are centralizing your stuff so that other things are using it, then it's easy to abstract those things away. And if you are using something like an AOP, then you can literally set up your test fairly easy because you don't have these dependencies on databases. Like you said earlier, right? You have some sort of constructor that's reaching out to some dependency that you can't test because you're not guaranteed that it's going to be there on

every system. So really powerful statement. And it is really big. Like the thing I kind of went about earlier, writing the little handler that would return or throw an error on a negative number, something like, imagine in a perfect world, an application where that was configured, and the business owners can tell you to do that. You write your three little lines, test those three little lines,

very easy to do, right? So now you're like, you know, including the test code, you're at 10 lines, say, you get that deployed production and then they come running back into your office an hour later and saying, oh crap, we can't do any returns

because negative numbers aren't working. Like, oh crap, we didn't think about that. Let me make this change in my XML file, which is maybe even administered by like a website or something. You know, you're allowing the business to pull the levers and make the decisions about the code and you're not slowing them down, which is maybe even administered by a website or something. You're allowing the business to pull the levers and make the decisions about the code, and you're not slowing them down, which is really cool.

So it's a nice pie-in-the-sky kind of dream thing. I'm not a fan of my experiences, but there's also a very good possibility I'm just doing it wrong and not knowing what I'm doing, especially in a framework I'm not familiar with. Your thoughts? I'm just doing it wrong and not knowing what I'm doing, especially in a framework I'm not familiar with. Your thoughts? Oh, well, I was thinking of the next part here that caught my attention here was the don't do BDUF. Yep. Stay away from BDUF.

And when I saw that, I was like, wait a minute, BDUF. You say you're looking at the BDUF lines, but when I looked into your face on the Skype camera, I clearly saw in your eyes, you were like, iced or tea? Iced or tea? So what was this BDUF we speak of? Well, sadly, it's the way that we used to do software development. Totally.

BDUF is their acronym for Big Design Upfront. So you would spend all your time up front designing out, gathering all your requirements for the application, designing out how this thing's supposed to look, how it's supposed to interact. You do all of that before you would start writing any code. And it was awful. It was painful. And, you know, they, he made a good point about saying that, like, if you do adhere, if you do a beat off approach to this, then you're going to be reluctant to make any changes because it took so much effort to even get those requirements and to get everything drawn out

that you're just mentally, you're already going to have blocks, whether you're aware of them or not, that you're not going to want to introduce anything new, any new changes to the system. You're just going to want to get the system done. And you know, we've all worked on applications where that stuff happened. And honestly, because the BDUF takes so long by the time you've actually started flushing out and building the application, the needs have changed, right? Because the business, like businesses can't just look at Blockbuster, right? They didn't change their business model. They're gone, right? Companies have to, just like software has to change because of various needs, whether it's scaling or whatever

the business needs for that software also change. And that's one thing a lot of programmers have a hard time dealing with. And that's not fair, right? It's when we're writing software, whether it's for a business or for somebody or whatever, you're doing it to fulfill a need. The needs of the business change just as much as the needs of the software itself change, right? If all of a sudden you have a million users and you only plan for 10,000, guess what? You might have to change your architecture. If your business all of a sudden needs to start selling into a new market, guess what? Your business needs for your software now change too. So you got to be willing to work with that.

And that's always one thing that's bothered me about that big design upfront or huge, you know, meetings upon meetings for months and months and months. And the software doesn't get built for two years. And by then they're like, yeah, we don't really need that. You know? Yeah. I mean, you're definitely talking about, uh, you know, six months to a year being spent just in all your requirements, gathering and design and, you know, meetings going back and forth with the customer and be like, okay, you know, trying to understand what you think they

want and then having me as, okay, am I, am I on the right track? Do I have what you want? And it was just an awful, painful experience. I, I'm so glad that as an industry, we've moved away from that. I agree. I mean, that was the old waterfall approach, we've moved away from that. I agree. I mean, that was the old waterfall approach, right? I mean, that's basically when you hear that,

that thing, that's kind of what that, that was. And everybody's agile now, 100%. So nice. Stop it. It'd be nice. Maybe.

Yeah. Yeah. We're getting there. We're now we're now we're we're doing lduf now little design up front and often no duff and duff no design up front that's all about redesign all the time is there yeah i can remember that that's pretty much it oh man, man. Nice quote in here. A good API should largely disappear from view most of the time, allowing you to focus on your core competencies, which I like that idea, and it kind of speaks to that composability of logic

and these little Lego blocks and modularity, which is like the dream for software, a bunch of little tools that do their job, and you can kind of compose them. And actually, this got me thinking about kind of more modern architectures and specifically web services with REST. So if I'm thinking about, say, if I'm working on some REST web services

for a company, if I were to try and take these lessons from the services chapter and apply that, then I would probably have some really kind of dumb web services that would do REST kind of dumb web services that would do rest kind of the proper old school way you know i'd have a create that inserts and update that updates delete that deletes you know read the gets and i would do that for all of my persistence layer right and then i would maybe have a client or some some minor higher level items that would do some of the logic stuff. But ultimately, I would want to be able to compose these little pieces of my system.

And I wouldn't be writing opinionated web service methods that do things like get me this whatever that runs a stored procedure and intersects a bunch of other stuff and turns it all upside down and returns it. I'd be doing a bunch of little units and then composing them somewhere else. That's interesting. I don't know if it always works, but that's interesting. The quote that this came from that is somewhat in line with what you're saying is the whole use of frameworks. So like rest is a convention, right? Rest is your crud or making sure that you're using the, the HTTP verbs properly with, you know, different types of requests. But there was something that was really interesting that came right around that section where they were talking about, don't be one of those people

that loves to fall in love with a standard, right? Like get so don't get so hung up in doing something just because it's a standard because one of the things in this entire chapter and again we didn't go into the java like the too much of just very language specific type stuff but they were talking about ejb1 and ejb2 and how they were super tightly coupled and so making any kind of changes were really difficult because they were so nested together. And there were people at the times that those were out because those were the enterprise Java standards that everybody's like, well, we're going with the standard. This is what we're doing.

This is what we're doing. And it turns out that ended up being a really bad thing because of the way it tightly coupled all the code. And it made systems a little bit fragile when you're trying to change them. And so they said, don't be that person, right? If you could have written it in something else that would have been simpler and easier to maintain over time, then maybe that's what you should do. You know, so that's when they said, allow you to focus on your core. If you're spending all your time trying to figure out how to perfectly implement standards in a framework, then you may be putting your time and effort into the wrong

thing, right? Because you're not focusing on your user stories. Yeah, I was just kind of imagining like with the Rust scenario, I wouldn't necessarily want, if I'm doing a website, I wouldn't want my JavaScript composing my logic, you know, 100%. But I'm just imagining like, you've got a persistence, like some sort of database, we've got this web service layer that all it does is these like, you know, dumb crud operations. And then there's a layer on top of that, which could be a whole another service runs on a whole nother computer, you know, whatever. And that's like my business layer, right? We're getting back to this onion architecture idea. And at some point, you know, I've got a view that just does its um does its job as dumbly

as possible too but just i was just kind of thinking about it um you know he doesn't like i don't i don't think this that rest and web services were even really a thing when this book was first being written i'm sure soap was around but it wasn't as prominent as it is today like the word spa is not in this book anywhere. Thankfully. You need a day at the spa after coding. Is that what you're talking about? I like web pages. Save it for another day though.

Nothing wrong with web pages. I'm mad. What else do we have here? Well, there was another quote that I really liked, which was that in large systems, no one person can make all of the decisions. And this going back to that whole BDUF kind of approach, right, is that it was often a very limited number of people, one, two, three, whatever, but it was a small number and, you know, they're being asked to architect like big things for that customer, right? It's, that's an impossible task, right? Like that's a huge burden that you're

trying to do. It's not realistic. So yeah, move on. Like, and, and furthermore, going back to that whole concept of like, you know, let's jump on the anti BDUF approach, right? Don't try to decide everything up front, postpone those decisions for as long as you possibly can, for as long as you can get away with it. Because by the, if you do that, then when it's time to finally make that decision at that last possible moment, then you have much more information at that point than if you had made it at some point earlier. Right?

No, let me tell you, I've tried explaining this to my wife. I'm not procrastinating. I'm trying to make the most responsible decision that I can, which means letting you know

five minutes before we need to leave where we're going to dinner. Are we in the car? I don't know. Terribly. It's not good. Especially when I forget. You have her write the author of this book. Right. It's his fault. I's amazing. Especially when I forget. You have her write the author of this book. Right.

It's his fault. I will say, though, I actually like that as one of my favorite quotes in this entire chapter. It was the postponement to the last possible. Because it is true. If you, and I'm not saying, like, there's the point of procrastination, but as a business, if you wait until you have as much knowledge as you possibly can get before you go to implement a certain feature, it's like you said, you have a lot more of the information to help you make a good decision when you're putting that piece together. Delay commitment as long as possible. I feel like there's another there's another theme

you should take all the lessons that you learned from clean code and apply them to your marriage oh wow what could go wrong no i was just looking at the the phrase i've heard before is last responsible moment so i was looking at some articles and where that term came from it's basically the same idea there but um the verbiage specifically used from the the originating book lean software development and agile toolkit referred to delaying commitment to the last responsible moment that is the moment at which failing to make a decision eliminates an important alternative i was thinking like man yeah i try not to do that most of the time hey what was so the domain specific language that was like the way for business people to kind of communicate uh you know needs in a way

that they can understand and i always forget about this we went to that meetup. It was spec flow. Spec flow, yeah. Yeah, so this is what this reminded me of. I feel like they talked about that a lot, especially when Ruby was first kind of coming about really popular because it was kind of easy to create DSLs, sort of. And I think I've mentioned this before. I'm just not crazy about it. Maybe I don't really understand. I get writing tests like that

and being able to explain business use cases and trying to speak in the language of the, of the, the business owners. But I, this idea of creating a separate language is just, I feel like it's kind of gone out of popularity since this book's come out. And I agree with that. I don't see much of it, right? I mean, SpecFlow was the one that I remember, vaguely remember every time it comes up, but I haven't seen a lot of domain-specific language stuff anywhere. But, you know, when reading this chapter, I didn't even really equate those two together, that he was necessarily referring to something like that.

So, I mean, maybe that's something he meant, but for those not familiar with spec flow, I think we've talked about it before, but it's a, there's this cucumber.js. Maybe you know that one better. And spec flow is the. uh, dot net port of cucumber for dot net and allows you to write your, um, business requirements and then take that and treat it as code. And it's a really, it's a neat concept and a novel idea, but like you were saying, like I haven't really seen this in practice a lot and I'm not entirely sure that necessarily that's what he was getting at in here, that you would coders and other stakeholders communicating in the same language is basically what it boiled down to right well they talk about small scripting languages and apis which to me means stuff like you know specflow where i say the customer and then i map the customer to go get a customer

record and create an object and you know then you kind of marry that stuff together, which is, let's see, this is where it threw me off. Cause like it doesn't even hit. It's okay. So there's a, the final quote in here in that, in that portion of the book where he says that a domain specific languages allow for all levels of abstraction and all domains in the application to be expressed as POJOs, from high-level policy to low-level details. And I'm like, well, you know, you're not going to expect someone from marketing

to talk to you about, like, the class names that you're going to use, right? Your POJO, right? Yeah, they're not going to talk to you in that. So that's where I wasn't equating those two things together. Right. I think the scripting language is what grabbed me the same thing. Like when I saw that, I was like, yeah, I mean, yeah, I guess it's funny. Like ever since when I went and saw that, I thought that was a really novel idea. Right. Like when we sat in on that thing, it was like, okay, that's cool. You have business people that can kind of define your

test cases up front in a pseudo language that the coders can implement but as we've gone on i've kind of been like yeah i don't that seems like that might just be i don't know it seems like another layer of things to deal with it that may not be all that effective i don't know. It seems like another layer of things to deal with that may not be all that effective. I don't know. I feel like someone in marketing or someone in the business wants to say, I want to cancel an order. And that should ideally map back to objects and things in your system. Like you want to have something that says like order dot cancel or something

like that. So I get trying to bring the language closer to the code. Like you don't want someone to say customer service, say, Hey, I need you to cancel that, that order. And you say,

well, see an order doesn't really exist. There's a table that has order header. And then there's a table that has order line items. And then there's several statuses there and I can remove it. And you don't want to go into all of that. Like they want you to cancel an order. Right.

So I get trying to, to limit that gap. Yeah. And you forgot, like you don't even you haven't even mentioned which payment method this is that's a totally different type of object now we gotta go down a whole different path you're like let me show you the whiteboard and you like start drawing like 11 objects that represent what an order means you know because you don't actually

have an order class you've got all these little you know widgets. They're like, no, man, you lie. I got the email. This is what my order said. Yeah. Like there better be $11 going back to that customer. That's right. Today. Yeah. Oh, man.

So this is where it kind of wraps up the chapter. And they say systems should be clean too. Failing to make a system clean can impact the agility and tie you directly to your architecture. Oh, yeah. One of you guys made a statement earlier about, yeah, you probably don't change out your databases that often. I used to make that argument, by the way. Anytime somebody was like, you know, don't do T-SQL or don't do this

or, you know, don't do something that ties you in, I was always like, it's not like you're going to pick up and move to Oracle, right? Like that's, that's typically not going to happen. And I'd say probably 99% of the time it doesn't. But what might happen is if you've got your things abstracted properly, you might introduce another technology that will augment your existing technology, right? So maybe it's a search system. Maybe it is some sort of event queuing system. Maybe it's, you know, who knows? But the point is, if you write your software in a way

to where you've created these abstractions properly, it's not going to be painful that if all of a sudden, you know, you need to get searches from somewhere, you're not going to have to rewrite your entire code base because it was all tied strictly to sql right so i thought that was an interesting thing to think about and i've seen crazy things happen like i've worked in systems where you know we had a users table and users had a username and a password and then someone comes along and says yeah we need users to be able to masquerade as other users. And we need to be able to limit those permissions.

And so now it's like, okay, well, now we have this weird kind of split in the user table between, like, who am I and who could I be? And who could I place orders on behalf of? And all this other kind of weird stuff. And so that's the example where you might say, like, we're never, I mean, we're always going to have a user, right? It's like, no, maybe, maybe not. Right, right. Yeah. But you should start with that user table.

You should. Don't try to go too crazy right in the beginning, right? Don't build that interstate across the map unless you're cheating. Yep, totally. And you want to wrap it up with this last quote here? Yeah, this was a great one. It was literally not just the last quote

that we're going to say for this episode of this chapter but it was the last of the chapter yes never forget to use the smallest thing that can possibly work simplest ah dang it

did I write it down oh I did dang I just blew out my mic just ruined the normalization sorry guys so it was sort of the last well congratulations guys you made it to the end of another episode thanks for listening um well we're not quite sorry i'm a little goofy man why are you doing that that's wrong

i feel that's wrong oh and we got uh first we got to mention the resources we like right of course clean code um and if you buy the the book via the link on our website then you can win a copy or wait no you can what i mean i've been drinking this diet cream soda man it is not doing me good is it the ice or the tea no joke how much bourbon is it right if you buy if you buy the book using the link on the website, you will throw us probably like 30 to 70 cents somewhere in that ballpark, and we would use that to probably buy more stuff to give away. Yes, totally.

We should do that. Because that's what we do is we give away the monies that we earn here. Yes, clean code. There we are. So now it is Alan's favorite portion of the show it's the tip of the week yeah baby so what you got jay-z all right first of all i don't think i've been i'm sorry i've been goofy on that i don't think we ever mentioned uh exactly what sebastian greenholds did to win dead brains but what we did is we sent an email out and said,

hey, send us a recommendation for the tip of the week. And if you win, we'll read your tip online, we'll mention you, and we'll send you a free JetBrains subscription. So Sebastian did that. He sent us a great tip and he won. And I'm using his tip for the tip of the week, which is fantastic for me.

And it's a win-win, I'll say. So his tip involved using snippets. And he specifically mentioned using it in a Java environment. But I've actually done it using ColdFusion, a little bit of Java, and a few other areas. And actually just about any IDE or even editors like Sublime or Visual Studio Code support this sort of thing. So the idea is you build up a bank of snippets, which are commonly used blocks of text, right? And you can actually kind of parameterize them sometimes depending on the plugin you're using or the support for it. And so sometimes you even get a little pop-up window so you can do a little key binding and say control kp and now i um created an insert statement for a person that gave me nice little text boxes where i can pop in the name or

you know whatever else fields like just common things that i might do in my code base like i'm working in ext js right now and one anti-pattern i partake in right now is if I need to create a new grid or new page, I'll control F in the code base to find an example of something that I will, similar to what I want to do. And instead of me doing that, I should just create a snippet and then I can do control K P grid or, you know, something like that in order to kind of pop that out. So I don't have to keep searching my code base. Although you could, you know, smack me down for repeating myself on, uh, you know, copying, basing code, but we all know that there's boilerplate no matter what you're doing. So, um, snippets are a great way to do that. So you should go out and check out your snippet plugin for your favorite

IDE today. And thank you, Sebastian Greenhalgh, and enjoy the JetBrains. Awesome. Congratulations. All right. So mine is something that is funny that I mean, I've been working in SQL Server for a long, long time. And I guess I was stuck in my old school ways because like when I would go and do something like, I don't know, I had a proc and it wasn't returning what I thought it should be returning. Or, or if I had a query that wasn't doing exactly what I thought it should be, like, I would always just kind of put print statements all over the place, right? Like the old school JavaScript type stuff that you do on the web. Like if there was something that you were trying to check, you throw an alert to see what the value of it was. You can actually debug inside SQL Server Management Studio. You could actually hit play and debug. So if you're calling a proc, you can step through line by line,

watch all the variables in the proc and see what's going on or in some sort of batch SQL statement that you have. So if you've never done this, just look up there next to your execute. There's probably a little play button. And if you'll highlight a line of code, like if you've never done this, just look up there next to your execute. There's probably a little play button. And if you'll highlight a line of code, like if you're wanting to call a stored procedure, you could highlight an exec line and hit play. And then you could literally F11 through that thing and see exactly what, what conditional branches it's hitting in there, what all the values are of everything. Like it's pretty killer. It will definitely speed up your ability to diagnose and fix

problems in some SQL code. That is my tip. I'm curious. Did you guys even use this or know about it? No. Really? I've never debugged the query like that. I've seen it before.

That doesn't make any sense. I knew that it had the capabilities in there and I was just like what's the situation where I would use this? A store proc. If you've got some dynamic SQL and you need to see why is it hitting this particular

if statement, right? Like why is it not setting these variables the way it's supposed to be? You can see, oh, that value was null or wait, no, that value didn't have in it what I thought it did. Like the one that I just used recently to troubleshoot is SQL is really annoying. And here's another tip for you. If you are trying to auto convert a SQL date to a VAR car, if you just basically cast it directly to a VAR car,

it'll drop off the seconds. So it'll basically give you the hours, the minutes and the date, and it'll drop the seconds off. Well, if you want to get the seconds and the milliseconds as well, you need to do a convert to, I think convert one 23. And then it'll give you the entire timestamp.

But I kept going, I was looking at this thing going, man, I know this code's right. And sure enough, there were a few things where it was missing the conditionals. And so stepping through it, I was able to see it. So at any rate, yeah, man, you can do it just like you would in Visual Studio. It's beautiful.

So for my tip of the week, have you ever had a chance where you wanted to copy something from a, from, you know, maybe a site or one application and you want to paste it into something else and the formatting comes along with it, Right? So you just want to paste the contents, but without the formatting, right? So this is a Mac OS trick, but according to the official keystroke for this, if you were to copy it, and then when you go to paste it, do command shift option V. Right. Then you can paste it without the formatting. Now, I know I haven't I wasn't able to find any documentation to support this. But for me, just command shift V worked in my case.

So I don't know why. But. Yeah, you could format you could paste without the formatting and it is so awesome. Uh, especially like if you're putting the show notes together, for example, you know, as we're compiling this episode, right. Uh, you know, we use Google, uh, docs for our rundown here and you know, there's formatting in there and we might want to like copy and paste that into, uh, you know, the, the blog article to create that post. And sometimes the, uh, spreadsheet formatting gets in there that you didn't want, but, and that's just one example, right? Like maybe you're, you're, you know,

you copy and it's in a table format and you didn't want the table, whatever, right? That's nice. But command shift V or according to the official documentation, command shift option V. That's interesting. So we're going to introduce something different, at least for this episode. I don't know if we'll do this every time, but there's this thing going around about programmers confessing their coding sins, right? And how the whiteboard interview is awful, right? And it's just not a great way to do it. And so there's this, a bunch of tweets going around about it that, um, and I don't even know who, oh, actually here it is. Uh, the Ruby on rails, uh, the, the creator of Ruby on rails is the one who started this. And he says, hello, my name is David. I would fail to write bubble sort on a whiteboard.

I look code up on the internet all the time. I don't do riddles, right? So that's the premise of the developer confession, right? So I thought, oh, this is kind of neat. So this was one that I'll I'll throw my, my, my two cents in here is that, you know, you guys know I love get right. I mean, I love get every time I need to undo the last commit and then redo it.

I always look up the command every time just to be sure. Oh yeah. Yeah. I yeah. Yeah. I look up, there's given if Google ever changes the link colors from purple back to blue, like if they lose whatever history they're doing there, I am so screwed on get,

because there's so many things I search for in Google all the time. I'm like, Oh, it's the fourth one right here. I, there you are. My old friend. Uh,

so you guys got, you guys have a confession ready? what's yours? I do? first of all I'm going to steal the format from Jamie from something

in our slack channel developer confessions which we've had around for a while before it was cool so mine is forgive me SQL for I have sinned. I once updated a credit card number from a string to an integer field because I care about code quality. And it broke all sorts of stuff. It's really bad.

And the double joke there is that we were storing credit card numbers in the clear. Oh, no. So you got a double whammy there. Yeah, I didn't check the data type. I was just like, hey, wait, why is this character? That's dumb. Should we start this section off with never have I ever? Oh, no.

So let's see. Oh, no. So, let's see. No, no, let's not start that. How would I summarize Jay-Z's confession? One, stored CCs as unclear. Hey, this was like,

this might have even been in the 90s, so you know, like, we all did some stuff in the nineties, you know, it was a different time. I definitely remember writing some logins system. Wait, is this confession?

I don't want to give that one. Um, uh, so, so, so now change your cookie to his admin. Oh man. Uh,

never have I ever written, even recently, updates or deletes without where clauses accidentally. Unfortunately, it's usually on my own box, but man, that always sucks when it happens. Yeah. Actually, the format I stole the forgive me SQL 5 send was because Jimmy, he pasted a little link or, uh, he was doing a cursor and then, uh, didn't do the fetch inside.

You do the fetch outside to get the first one. And then infidel loop. Oh man. Oh, by the way, on this link that you shared, that's going to be in the show notes. I was reading this the other day, as a matter of fact, and my favorite one on here. Did you guys know this? I didn't know this. This guy, Max Howell, he wrote a homebrew.

Might have heard of it. It's a pretty big deal. So he put in his tweet, Google colon, 90% of our engineers use the software you wrote homebrew, but you can't invert a binary tree on a whiteboard so f off how about that like seriously you interviewed the dude who wrote that and you're like no you you're not good enough that's uh well you gotta be careful with those binary trees man that not being able to balance a tree could get you rejected at the airport you can't see that story no it's reporting on political,

but yeah, they, uh, they asked the guy to prove he was a programmer. Uh, Oh, wow. That's an imbalance of binary tree.

Wow. Like, Oh man. Yeah. I mean, it's, it really is amazing when you think about it and we've talked about interviews before,

but there are times that it's just kind of garbage, right? Like, I mean, don't get me wrong. Look, if you're going to interview at Google, Amazon, Microsoft, you better be prepared. You better go by, and we'll put this in the resources because we're talking about it. Go by Cracking the Coding Interview.

Go buy it. Read the entire book. Do the entire thing. I think it's right in front of you there. By Gail... Yeah, yeah. Gail... Something.

Lackman McDowell. So, if you're going to go interview at one of those big companies and it's your dream to work for one of these major software corporations, guess what? You're going to be doing whiteboard problems for the better part of four hours. Right? It's going to be a grueling interview process and you can't go into it thinking that you know it all because you really need to practice. It's just like taking a final exam in college. But there are times that it's like, man, really? What? You know, we've talked about it. You're hiring me to do website stuff,

but yet you want me to be able to write a bubble sort. Right. Right. Okay. And then you get in there and you're, and you're modifying CSS files. It's like, what just happened there?

So we decided we want our font to be Helvetica. Can you handle it? No area. No Helvetica. Can you handle it? No, Helvetica. Yes, dude. We can't really decide, sans serif or serif. Man, it's funny. I'll say, man, and we've talked about this. I'll take a scrappy person, a scrappy programmer,

somebody that's just a bulldog and won't give up over somebody that has all the best technical knowledge in the world. Just about every time. I want that person that just can't give up, that they just cannot lose, right? Like it's in their soul that they cannot let it beat them. And that's the kind of person I want. Kind of have grit, grit, grit. Really, grit. Really? Totally.

So, well, yeah, that was fun. So we'll have the links to the story that we're talking about, the stories that we're talking about in the developer confessions. And yeah, we'll go from there.

So we hope you've enjoyed this chapter, chapter 11 on systems, separating the construction and the running with dependency injection, modularizing cross-cutting concerns with AOP and keeping things ship shape and ready for change. So subscribe to us on iTunes, Stitcher and more using your favorite podcast app. Be sure to leave us a review by visiting www.codingblocks.net slash review. Oh,

it wasn't my turn. Yeah. If you go to codingblocks.net, find all our show notes, examples, discussions, and more. It's too late. Lay off that cream soda, man. Dude, what time is it? It is March 1st at 10.45 p.m.

Now you gave away the secret. You broke the fourth wall. I did, man. Well, let us know in the feedback, questions, and rants on the slack channel codingbox.slap.com and follow us on twitter at coding blocks or head over to youtube and check out coding blocks or go to codingbox.net and find the rest of our social links up there yep totally hey hey by the way like i noticed this the other day i don't know why but like we have coding blocks, that net slash YouTube. And we have youtube.com slash coding blocks. We have,

you know, twitter.com slash coding blocks. And we have coding blocks.com or.net slash Twitter. I think we've inverted all of them pretty well. So as long as you can remember one of the two and put a slash of the other one, then you should be good. So just thought just Google us.

Yeah. In case if you are having trouble remembering YouTube. Yes. Go to codingblocks.net. Codingblocks.net slash YouTube. Oh, man. Did you see that there were like, what did they say? There was like a billion some odd.

I forget. It was some insane number for YouTube. Like the number of petabits or something that are streamed every... Oh yeah, those statistics are crazy. Oh man. It doesn't even make sense

anymore. You might as well not even talk about it. It's like they're inventing new numbers just to describe it. It's insane. And I understand it. It's like a black hole. If you just to describe it it's insane and i understand it it's like a black hole if you start watching something you're done right anyways all right so yeah that's it