Coding Blocks - Your Questions Our Answers SYN-ACK with Packet Loss

Episode Date: May 8, 2015

In this, Episode 27 of the Coding Blocks Podcast, we are answering several questions from our listeners regarding:  more frequent episodes, naming of classes / assemblies, Test Driven Development, the differences between MVC and MVVM and a number of other side conversations such as aliasing tables in SQL.  As always we’d love to hear back […]

You're listening to Coding Blocks, episode 27. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And visit us at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks and follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, welcome to CodingBlocks. I'm Alan Underwood. I'm Joe Zak. And I'm Michael Outlaw. And first, we wanted to start with a little bit of news. We got a lot of feedback on our last episode. Thank you very much. That was

the one we were talking about puzzles and algorithms and design patterns. And one of the things we were trying to figure out was basically how to really express the difference between design patterns and algorithms. And we got a lot of really good feedback and tweets and emails about this in comments and i just want to mention my favorite was from andy joiner who said uh if an algorithm is a recipe then rue would be a pattern and i had to look this up because i hadn't heard of rue before but i think that's uh that's uh like tigger's fan friend to oh rue uh i don don't know, man. That's a little too old for me. You just aged me out there. What?

Who doesn't know about Winnie the Pooh? I remember Pooh. Anyone born in like 1990 and up? Like me? Tigger's still a thing? There was a whole movie. All right. But anyway, so I had to look up what R was and that's a r-o-u-x

and uh it's basically this kind of mixture that you can make a bunch of different ways and it doesn't really matter but the gist is that it's 50 fat and 50 flour which is amazing and that's kind of cool yeah i will be cooking with some rue in the near future yeah i have some more i want to add to this to this topic that uh we'll get to in a bit but just know that uh that's coming all right all right yeah who wants to mention it yeah somebody found my office yeah so uh sam wrote us directly to uh comments at coding blocks and uh And you could, too. And you absolutely can. But it was fantastic because he sent in a screenshot of...

Singleton's Architects. No, no. Singleton Architects. Ah, I screwed it up. Only the Architects was plural. Which, still, though, I think we need to open up a ticket for this thing. Bug Zillager, whatever your ticket platform choice is. You guys are missing the point.

It can't be plural. There's a bug in their name you know i'm looking forward to the day when you're gonna have to start talking about architects as building architects and it's just kind of implied that it's software it could happen maybe all things become virtual in this world i know a girl who would be very upset by me saying this, though. Yeah, that was actually really cool. He tweeted it. We'll put a link in the show notes, but it was excellent. We all got a good laugh out of that one, so we appreciate that. I still don't understand why they would name it that way, though,

because even if they were referring to the mathematical term for single nerd, it's still wrong. It should only be the one. It's like the Highlander. You guys wondered who the real nerd was here now you know and uh big thanks to ollie 724 for the review you're awesome it was a fantastic review thank you for taking the time to do that oh yeah we greatly appreciate those those are awesome uh i did have one that i wanted to comment. There have been some episodes before where I've made a joke here and there. Maybe.

And so my youngest, he came home from school today, and he had one for me that I thought I would share with you guys. So what did one developer say to the other developer? I don't know. Stop commenting out other developer? I don't know. Stop commenting out my stuff. I don't know. Want to get a bite to eat? Oh, nice.

Very good. I like it. Very good. Yeah, so I couldn't resist, like, throwing that in there. That was a good one. Nice and cheesy. I like it. Yeah, well, he's talking about pizza. All right.

So, and then, and then along the topic of, uh, well, me, uh, recently my mind was blown here. So last episode we were talking about the puzzles and everything and, uh, project Euler came up and then someone had to correct us and say that it's pronounced Euler. So it's project Euler came up and then someone had to correct us and say that it's pronounced Euler. So it's project Euler. Yes. And I know we all Googled this ourselves. It was,

uh, um, what was it? Who did, uh, Kikens five one one on Twitter. Yeah. I,

I, what? No, it's Euler. I've never, like, I can't even look at that and think Euler. Yeah. Well, what's funny to me is, uh, maybe it's like an American thing, but I saw the name I've never, like, I can't even look at that and think Euler.

Yeah, well, what's funny to me is maybe it's like an American thing, but I saw the name and it never crossed my mind, you know, to look up how it might be pronounced. I'm just like, oh, that looks like Euler. Well, I mean, how do you say Europe, right? E-U, it's you. Yo-yup. So, yeah, thanks for correcting us. From now on, it's Euler-up.

We were absolutely All of us were like really Yeah it makes me feel very dumb And very redneck All these years we're talking about Project Euler Guys it's awesome He even gave a link though to the Wikipedia Article that had

The pronunciation and everything But it's not just us I've had other people mention that site to me. I've never heard anyone once refer to it as Euler. Euler, yeah, Euler. And that's really it. If you search for E-U-L-E-R, actually Google will take you to a YouTube video that says Euler. Nice.

Euler. So, yeah. And next time you're talking about it with your programmer friends, you can actually pronounce it the right way, and they're all going to look at you like you're something special. Yep. And so here's something that came up. Also, our friend Sam, who sent the picture of Outlaw's hidden cave somewhere. It wasn't very hidden.

Yeah, it wasn't. I was trying to hide my cave. I was doing a poor job of it. But it's like you said before you listened to this podcast he said he'd probably walk by it a thousand times and never notice it but then when he saw that after listening he was like oh that's kind of funny right so he found the bat cave he did well he he actually asked you know hey could we go to doing a more frequent format like daily or or at least more frequent um and it's something that we would love to do but we've never really sat down and tried to because we do try we put a lot of time into

i'd like a content yeah i'd like ferrari i mean if we're talking about things i'd love so so really we kind of want to get you guys feedback find out you know if we went to something with like a shorter format uh you know maybe a quick question or something here and there and and we did maybe 10 or 15 minute episodes is that something that people would want or do you guys like the format it is i mean yeah we'd love to hear what you say like obviously you know some some larger topics need more time and um you know some things uh don't need a lot more time so we want to know is that good or bad would it be annoying if you heard a five minute episode episode or a ten-minute episode?

Or a twenty. Or do you love the hour-and-a-half episodes we've been doing? I don't know. Yeah, we definitely talked about some different ideas for it and thrown them around. Yeah, so do us a favor. I mean, when you listen to this, head to www.codingblocks.net slash poll, P-O-L-L, and let us know. Because we would truly love to get your feedback on that um and and it's some more about about me like yeah we're gonna have to rename this episode

to be about me so yeah i need to make a retraction so in last week's tip of the week i talked about using uh get bash in the tab completion and it totally works awesome for tab completion on the branch name which is where i originally started that but i swear i've used it on like file names as well. But then since that episode, and since you brought up the question about like, oh, I think it's a Git Bash integration thing. I've gone back and tried other scenarios and I'm like, I must've just gotten lucky on other times because like where I thought,

I thought I could, I swear I could remember doing this where if I wanted to do like a Git add in a file name or a git diff in a file name or a git reset in a file name or a git checkout in a file name, I could have sworn that if you started typing in parts of the file name, it would, and then you tab tab, that it would be smart enough to show you only the file that was relevant to the relevant to what you're trying to to the command you're trying to do to like one that has actually changed or been modified or something like that right but i wasn't able to re-simulate that this week so then it made me think like oh man every time i must have done that before on the file name maybe i was just getting lucky or it was the same i already typed in enough distinctiveness about the file name because like i remember the reason the reason why this seems so distinctively like in my mind is that there have been times where i could remember doing the tab tab and depending on

how many files i had either unstaged or in the directory or both there have been times where i could remember like it would take like there was a noticeable pause while it was trying to figure out like which file name to display right and that's why i was like i was sure it was doing this on on more than just the branch name but i couldn't reproduce it uh you know at least within the last few days i haven't been able to reproduce it so it just made me like feel like okay i just got to retract that like it's fine if you want to use the tab tab for the branch name but interesting i think my memory might have served me wrong there on the rest so outlaws going back to gooey forget all right

whoa whoa that was a stretch I actually have a correction To make over last episode And we actually had somebody Write in about it And It frustrated me When I realized it I kept saying

Topcode.com It's topcoder.com The R on the end Is apparently important When you type in a URL So It is www.topcoder.com So For I don't like the way you enunciate the der code der

well i mean it's missing so www.topcoder.com redneck with your accent i don't who's got an accent oh fighting words here it goes who's got an accent right here it's not me um so so yeah uh sorry for the mistake i did actually make it correct in the show notes so if you were looking at the show notes or the resources you would have had the right link but yes if you just listened and tried to go over there you were getting a 404 so i apologize for that um yeah at least it was a 404 could have been much worse Yeah it could have Oh god So we got some bad news I don't Do we have to talk about this?

Yeah I think we do So this is We're kind of breaking up The gang here So I don't think we're the ones Responsible for breaking up the band

That's a good point So Joe You want to go ahead and I am moving right now we are all basically in the northwest atlanta georgia area and uh i am leaving the area i'm moving uh back to where i basically got some family and uh some warm beaches and sunny air or something so i am moving to central florida region particularly brevard county so if you guys around there and i know that some of you do then give me a shout you'll be seeing me at some of those meetups now so basically this is our last episode oh no no no don't don't put that out there

but but the one which one of us is the coding blocks someone must carry on oh uh well it's not a singleton it's a good point right i guess we're just gonna have to keep doing them these are delegates apparently we're going on so so one reason why i wanted to bring this up though uh you know or at least why i put it in the show notes i don't really like talking about it though is that you know a little bit of behind the scenes though though, for you, dear listener, is that I know that amongst the three of us, we've actually discussed this, the extreme luck, you might call it, or dumb luck, you might call it, that we stumbled upon with, if you only saw just how little we've invested into what we use to record this these episodes but yet the quality of which they come out with we're always you know we're pretty impressed with it so even audio technician might correct us but but you know we we think that considering how little we have invested into the equipment the audio quality comes out pretty nice and a part of that is that we are

fortunate in that we are all sitting across from one another so uh we don't have to worry about you know any kind of networking the audio quality is the water's running well okay so there's some little background things here and there it adds some color to it but but you know one of the one of the concerns though is that like uh now that we're going to be forced to do remote uh you know uh recording sessions you know what impact is this going to have on the overall quality of the show so hopefully hopefully we'll be able to sort that out we've got some ideas and things that we're going to do so hopefully we're going to be able to sort that out and you won't be able to tell any difference however i do ask that you have some patience with us in the next few episodes just in case if there

are some kinks that we're working out uh during that time yeah but i mean one of our top goals we we all agreed when we first started this thing that we we all listen to podcasts and we can't stand listening to podcasts with bad audio like it's it's incredibly frustrating so we're going to do our very best to make sure that we bring you high quality sound and all that um so that you know it continues to be the same quality um i don't know nobody's ever really asked do we even want to talk about the equipment we use for this no save that for something else there's other shows that talk about how to podcast nobody does it like us right um uh it's gonna be good though we're not gonna do anything crappy so

we'll be all right yeah yeah we aim for somewhat high standards. Somewhat high. I like how you put it. All right. Somewhat high. Somewhat. All right. So status report. Outlaw, what you got?

What's my status report on? New Year's resolutions of 2015. So we were talking, you know, three, four months ago. Yeah. So, yeah, not really a whole lot to report. I did actually, like, decide, okay, fine. I mentioned before, like, I would just pull up some Pluralsight stuff and go from there with it. And I actually did start one.

But then I realized, oh, you know what? I got other stuff to do that's more important to my day-to-day. So, I still, I don't know. You're talking about a Ruby course or what? Yes, a Ruby course. Sorry. Yeah, at this point, I don't know if I'm ever going to get to day. So I still, I don't know. You're talking about a Ruby course or what? Yes. A Ruby course. Sorry. Yeah. At this point, I don't know if I'm ever going to get to it because there's so many other topics that are far more interesting to me. Call of duty. Uh, yeah, that's definitely one. You want to talk about some call of duty? Let's bring it. Come on, man. He's prestiged 80 times. Favorite weapon. Come on, let's talk. Call of duty. I'm going to the SMGs right now.

Personal favorites, KF5, which is always, you know, like that's a default. How about you, Joe? That's a little. Any status report? Man, I've been so busy with this move. I've actually given myself shingles maybe, which is contagious, by the way. So don't touch anything in my house. Awesome.

He tells us this now. Yeah, yeah. This is literally the first time we're hearing about this. As we record out of his basement. Excellent. That's right. Sorry. So, yeah, I've done Jack this time we're as we record out of his basement excellent that's right sorry so uh yeah i haven't i've done jack uh this time so uh we'll see all right so me going back to all right so i've only got like 30 views on that youtube video i put together it's kind of

hurt my feelings so if you would just i don't think closures are that popular i think that's the takeaway i don't think i named it well um but yeah, if you guys haven't checked it out, please do. Because I'd even like to get some feedback on, you know, what you would like to see done better or worse or whatever. You know, I mean, I can always make it worse. And then going to the Angular thing. So it's frustrating when you're trying to put together a course because you start looking like, well, Angular 2 is on the horizon, right? And you know what i was like you know hey let me go ahead and move towards angular 2 because that's where it's going to be here in the near future the problem is i went and looked

at it it is like it's not even near beta or anything like that you can't find any information on it unless you're going to dig through source code and figure out how to write the code yourself there's literally nothing out there but the source code is the best documentation you can find okay yeah yeah so so i'm not that's you don't agree ain't nobody got time for that so actually what that meme gets overplayed so i don't know if we can put that on this one too because it's gonna end up in every one of our episodes right i think we use it a lot um but so here's the interesting thing the the angle that i the angle that i'm taking on this is i am what you did there uh yeah i'm trying to create like what you would do in a business an enterprise type thing so you're going to have a login

and you're going to have assets that are locked down and all that kind of stuff so i am going with the angular 1.3 approach right now, but I'm trying to keep this thing open so that I could basically plug and play another UI. So maybe I'll do something like react in the future or, you know, I don't know, but,

um, that is the direction that I'm heading with that. And I, I have put a little bit of time into it, although with the NBA playoffs on right now, um, wow, it's hard to focus.

Hey, my Atlanta Hawks are two and O in the playoffs. That hasn't happened. I think ever. um wow it's hard for sports for sports it's hard to focus hey my atlanta hawks are two and oh in the playoffs that hasn't happened i think ever so it feels good yeah i think um i don't know if we've mentioned this before um because i'm definitely not trying to steal any thunder but there's a there's a book uh i think it's called The Java Framework Guide, and it compares Angular, Backbone, and Ember. And what it does, I think, is kind of similar to what you were talking about, maybe? Eventually.

It takes one, let's say, problem domain or application, right? And then it creates that same app in each of the different frameworks. That way you can focus on what are the actual differences between each of these. The different UI frameworks, yeah. Yeah, I think that's kind of how I'm doing it. And it's also a nice proof of concept from what we used to have with web forms and that kind of thing where your code was so intermingled with your UI and everything, that if you do this the proper way nowadays,

you can just about lift and replace if you want. So are you saying that Hello World isn't a valid starting point? Oh, it's a great starting point. Actually, one of our good buddies is doing something along this lines, right? Like he's taking a bunch of different server backends and then a bunch of client frontends and trying to do just different pieces on them. And so it's going to be kind of interesting to hear how his turns out. So it's definitely a challenge.

It takes a lot of time to sit down and put something like that together. Well, good. All right. a lot of time to to sit down and put something like that together so well good all right so now i guess uh we're getting into it's it's kind of a mixture of questions and feedback type things that we've got in this episode so the first thing we want to talk about this is in case we haven't already said this is our synac episode you know you you send us a syn packet to synchronize and we act it with that answer. Yeah, we're basically reducing our, I don't want to call it technical debt, but we've been kind of bad about responding to things that you guys have sent us and this is us of, kind of paying down some of that debt.

And we are completely taking the TCP route of it, where if packets get dropped, we can't really be responsible for actually the UDP, right? We're just going to blast them out. You asked the question? Yeah. So we're just going to throw a random package your way. So we'll see how this goes. So the first one we got is one that was sent to us a while back,

and we're just now getting to it. No, actually, this one was recent. This is from Matthew Dougal, and he basically had a question on on naming things and he's not necessarily talking about naming conventions like variables and and methods and that kind of stuff not like upper or camel casing or any of that he's basically saying he finds himself in the situation to where you know he'll spend a lot of time sitting there going do i call this a log manager do i call it a log agent do i call it a log service what do i call this a log manager? Do I call it a log agent? Do I call it a log service? What do I call this?

Like, what's the difference? Logger. Logger. Do, uh, or he had another one that was a great one was, I'm going to take the Ren and Stimpy approach and just call it log.

Interesting. I actually want to talk about these because we've all got some probably almost embarrassing times where you sit there and you think about something for 45 minutes and you're like, oh, dear God, just name it. Yeah. And there's so many times when I'll name something a manager, which is usually a bad sign. It's a sign that I'm doing something incorrectly and kind of doing too much in one class. But it gets really hard to name things. Yeah, it does.

And he had another one that's a great example of do i call this thing a helper or do i call it a utility class and really i mean they're essentially the same type thing for the most part so you're not alone dude you know what's worse i hate i do this uh too often it's like i'll name a class something like a you know we'll call it a log validator and uh you know i started writing some validation code and then uh the time moves on i kind of maintain it a little bit and kind of add some abilities next you know my validator class is creating files and moving things around and and i've never changed the class name in the meantime so not only have i bundled this crap together but the name is also misleading. Yeah. And honestly, like now one thing I will say, he said that.

Well, okay. So your helper versus utility though, didn't, wasn't there something about the, about. Yes. Utility wouldn't, doesn't have state. Yeah. A utility. So we found this link and we'll include it in the show notes on stack overflow where a guy actually had a nice breakdown and he basically said like if you have a utility class there is no state you can't instantiate it every method

is static and so the utility class is something that you just you know you call and use um what's the example function that you would have a utility class uh trim right like it would say that there wasn't such a thing as a string dot trim or whatever you could have a string utility class and it would have a trim function and you pass string into it and return it, right? Like pretty format date or something like that. Um, granted a lot of these things exist. That's just a stupid, simple example. Now, um, in that stack overflow article, uh, the guy, not really article, but answer the guy said that, you know, a helper class is essentially the same type thing, except it can state um now i don't know where these definitions are coming from i've never actually seen this laid out anywhere before but just know that they're very close to the same type thing

and naming these generally speaking i would probably just kind of follow suit with what's already in your application elsewhere. Right. Like if people have utils class, then maybe follow the utils naming. Yeah. Consistency is important. Yeah. And it might be more important than actually naming it completely properly.

Right. But that's if you're talking about specific about utils. many times for like new classes or even namespaces where like i've started down one path with you know where i thought that i might you know what i might want this thing to look like and then uh along the way during the development process you know um i ended up deciding you know what i really feel like this other name would better suit it what what it's actually become now once that's been committed though once that's out there in the wild then i'm not so much on the changing but yeah it's pretty much leave it at that point that's kind of hard i mean i'll change it i'll refactor stuff if i think that it belongs like what he just said about having like some log validator like oh i mean if it's something like if

it's a like a really uh horrible name like anymore yeah like an example that he gave where it's no longer validating stuff where it's doing a lot more than just validating then yeah sure refactor it but i was thinking of like much less extreme examples where it's like you know yeah so i another one that um i will say he mentioned something about a framework i just about never name anything framework because that usually is something when can i call something a framework because that is so much larger like when you look at what a i don't think he meant the name of it though um well when you when you call something a framework it's usually like you just you're not writing much of your own code for it.

You're using stuff that other people have provided, right? When I think of a framework, that's kind of what I'm thinking about. Yeah, but I'm pretty sure he wasn't talking about naming his thing a framework. Because he says, and when can I call something a framework? I'm so used to hearing that word describe web frameworks that it's made me second guess my usage of it. Right, so i don't i don't really know what he's saying well i feel like there he's kind of almost like implying the difference between like a toolkit and a framework and to me like a framework is like when you have

framework you have like a prescribed way of doing these like you these are the types of problems you're solving with my framework and here's basically how you uh how you solve them with my framework yeah like when when does my namespace or when does my DLL become a framework? Yeah. Right? Is the way I kind of interpreted his question. Right. Yeah, that's a really tough one.

Usually frameworks... My answer would be when someone else calls it a framework. Yeah. Not when you self-declare it one. Yeah. I kind of like the explanation too. Like if you're building on it, it's a if your project is you know heavily based upon this thing but if you're building with it and you could replace it you could do something else and that's probably

something different but yeah really i just stay away from those words because it's confusing but the words i use instead are just as bad so i tend to do things like lib or core an engine which is really embarrassing. No, but lib and core make sense, right? Core? No. It's the same thing. It doesn't mean anything.

It just means this isn't my website project. Well, it's a bundle of stuff. Well, lib sounds completely redundant. If it's going to be compiled into a DLL, then it's a DLL. It's a library dynamic link library. Well, as soon as I start a website, I name it Visual Studio, create a new solution, whatever, and then a new project.

And the first thing I do is I create a lib for the logic. Now you're going to start naming them all logic. Well, what sucks is the first thing I create is usually the web project, so that's got the real name I wanted it. So if I wanted to make a

roguelike game website, I would call the project roguelike game and then the first thing i would add was a big roguelike game library yeah oh this is gross and that's where most of my code is this is unfortunate yeah i will say i know i've sat there before and i mean i think you and i sat next to each other at one point and we were going back and forth for like 20 minutes on what we should name just a class. And it's like, oh, come on. Let's just put something down. Right. Like if it sticks, it sticks.

If it doesn't, whatever. We'll change it later. I'll change it later, except I'm not going to change it later. Right. That's that's really the key. Well, that's the thing. Like once you commit it, it's set. But yeah, you're not alone, man.

People are going to change it. That's the sad. committed it it's set but yeah you're not alone man people aren't going to change it that that's the sad that and that's why that's why like this is true of just like any kind of uh like oh let me just quick hack this in right like you know like why it's so important to to take this proper times because like it's so often that is going to become technical debt that will just hang around so if you give something a really bad name, like in Joe's validator case, there's a good chance that it's just going to remain that name even though that name really doesn't signify what it actually does. Unless you're Angular,

and then you just come out with a completely different. Are you guys familiar with the joke about the only two hard things in computer science? No. It's cache and validation and naming things and off-by-one errors. But naming things is definitely in there yeah so again you are absolutely not alone it is hard to do this kind of stuff and i mean all of us have been doing it for a long time and we still run into this right you know what no

that's not true there's a random baby name generators and you just go to one of those and that's the name of your new class because you think about it every class that you're working on at the time that you're working on it that's your new baby so aloe aloe becomes one right uh okay all right so uh hopefully that's why i gotta instantiate a little uh Dean. Little Bobby Dean here. You hungry? That's Jimmy Dean. That's Jimmy Dean.

I was thinking Bobby Table, Little Bobby Tables, but I don't know that reference. Well, XACD. We'll have a link in the show notes. We got to show you the internet. Apparently. Yes. Also, Matthew didn't really ask this, but I kind of went off researching in the wrong direction but just wanted to kind of mention uh the code complete book which we've mentioned before but it's got a whole chapter on naming things and in ibooks it's like 94 pages so it's it's a lot of information which on print that's probably like three oh no it's much more than

that it's a chapter it's it's terrible i think that's when i stopped reading this book actually oh great so you guys should go read it that's a strong's when I stopped reading this book actually Oh great So you guys should go read it That's a strong reference You should go read this book that I put down This was my waterloo Yes Matthew the question you asked made me stop reading the book But it's actually got

Like really great sections on like Optimum name length and language specific Naming conventions and Different kinds of prefixes and all sorts of stuff. So if, uh, if you really want to punish yourself, then,

uh, that's a good way to do it. All right. So optimum name length is like however many characters can fit on your screen. I agree with that. And, and, Oh,

that's a great way to bring this up. I ended up, I got the 34 inch ultra wide. Oh my God. So that, that variable name is going to be insane wow by the way if you're a programmer and you love yourself you should get this it is oh man it is so good it really is this going to be like one of your new uh christmas

tips you know are you that oh it'll be on the list yeah mean, it's better than I thought it could have been Right? And it's the LG 34 No, LG Well, this one isn't like It's not 4K 34 UM95-P It's not 4K

It's 3560 by 2440 No, by 1440 So it's not So it's not quite Yeah so it's not quite yeah it's not it's not 4k resolution but it's i think i forget what this is stupid big what is it it's a 20 by 10 i can't no i can't it can't be 20 by 10 i was like 34 to 1 i don't know i can't remember what the actual uh i can't remember the ratio is ratio is. But, man, it is absolute. If only there was a network of computers around the world that we could look up information.

Yeah, this thing called the interwebs. But, yeah. You never use it. So, apparently not. Hey, man, I got things to do. So, yeah. Anyways, variable names. Honestly, though, the 9 to 16 or whatever, what year did that start?

If you make a variable name long enough that goes across your 34 inch monitor it's too long i will stab you you heard it here on the show he threatened me yeah i will stab you with a blunt mouse that's how much i'm gonna mean it yeah i think that's too big for the symbol table i don't think it's gonna work oh that's awesome no but i symbol table. I don't think it's going to work. That's awesome. No, but I mean, seriously, my thought on that is as long as it needs to be to make sense, right? Like it doesn't necessarily have to be a sentence, but I mean, it has to make sense, right? Like don't give me some, don't try and cram it down to 10 characters just because you have this arbitrary 10 character rule.

Yep. The quote I grabbed from the book basically says, an effective technique for coming up with a good name is to state in words what the variable represents and often that statement is the best variable name. Yeah, but I don't want a variable name that's a sentence. Right, but you know, it just means something like rather than having a variable named

count, call it... This variable is the input. Well, lines in file or something like that. So, so you know it's something that's usually a phrase there might be some you know some helper words in there yeah i like that i mean i'm still gonna do count but that's what the book recommends i thought you were supposed to just use like letters of the alphabet oh you wrap around yeah you know especially in sequel man i cannot stand those acronym aliases Oh come on man Look we had this conversation The other day

I'm glad this came up Who does not Alias their tables Apparently this guy Yeah he actually Complained about it He would rather type out A table name

That's 80 characters long And do it 500 times in a row That's insane That's because that query Is read a thousand more times Than it is written Man Look

Not by humans Look if you're- Not by humans. Look, if you're aliasing your tables A, B, C, D, okay, I get it, right? That's a problem. But if your table name is People Jobs, it should be PJ. Well, what if your table name is Alphabet? Then ABC might be a good name for it. That's a great one.

Hey, I'm good with that. No, no cute acronyms. Or maybe you just do A, number two, Z, right? Like, I'm good with that. No cute acronyms. Or maybe you just do A number two Z, right? Like, I'm good with that. Make it represent it. But if you are not. I think he just threw up a little bit in his mouth. Absolutely.

Hey, look, if you're not using table aliases, you need to step back from the keyboard and reevaluate what you're doing. Oh, I'm totally with you on the table alias, though. Yeah, that PC is great when you write it, but then, you know, 10 lines later when it's off screen or not in Alan's case. Well, then your query, like you're doing something wrong here. Oh, no, man. I've seen some big queries and they are just right.

I'm not saying that they weren't doing it wrong either. But let me give you two things here. All right. One, if you have a self-joining table, you have to alias it. You have to. There's no way around it. on it and two if you don't like it just just select the the text in it in in management studio right click and put it in design view and it'll give you all the it'll give you everything you need right there oh and you can alias uh columns too so you can join your pc on your pd dot ffvv

whatever and i'm not gonna read it so so is your problem the aliasing, or is it just really bad naming for the aliases? Well, the aliases are usually something sensical, but I just hate the readability. When I'm in a big query, and I don't like to look at the line when I'm trying to figure out what's going on, and then I have to go scroll up to see what GDV is, you know little tft8 or whatever okay i'm going to give you another tip of the week then or of the episode as it were because we never do a weekly episode i don't even know why i call it tip of the week anyways you can split your view right like you can drag down that little corner up in the right hand corner and split your view and then that way you can have all your froms showing in one spot

So you don't have to Scroll up and down And then on your Bottom portion You can see your aliases And life is dandy Or we can just not alias Oh see that's ridiculous

You can actually do The same thing in the studio too Yes you can So They're all based Off the same Underline So if you want to see

The same file If you want to see The Different sections Of the same file You can do that. Joe, I'm trying to help you, man. He's shaking a little bit.

He is. He's quivering. What if you were to alias the table as Jennifer Garner? No. No? That kind of reference doesn't work for you? I'm going to find someone on the internet who agrees with me. He's shaking because of the shingles.

It's got nothing to do with the alias. Don't make me shake these things at you. I even made a bad alias joke and you still didn't like it that's oh is that the show i don't i've never watched it yeah yeah she was she okay well never mind yeah you did fail apparently wow tough crowd all right okay so we beat that one up um where are we at number two uh tdd you guys with me oh yeah yeah here we go okay go ahead kick it off uh no i don't want to okay so yeah go ahead all right so i i read this um john hansen just recently well i mean of course i read it um john hansen just recently wrote us and he kind of took a little uh exception

to what we had said about tdd in episode 20 i don't think he liked my jokes yeah and so here's the deal i'm sure we joked about it because we did talk about test-driven development in that episode quite a bit and we said you know nobody does it um and we say that because in a lot of situations like if you were to try and sell it to anybody that we've ever done work for, they're like, oh no, we need code. We need it now. Right. And, and his arguments are, and they're very valid. And it's the whole reason TDD exists is he said, when you actually use TDD, you were forced to really understand the problem upfront before you ever Type in a line of code and that And that is the whole reason it exists

Is you build your test cases up front Around the actual problem You're trying to solve before you ever get into The implementation and there's a lot of Value to it and he goes on to say that There's been studies done that say When you approach it like this There are usually less lines of

Code and the code is actually better And it takes less time to complete. We actually referenced that in that episode. So, um, it is specifically in that episode there. We also talked about the book, the art of unit testing.

And, uh, one of the things that was talked about in that book was, was such a study where they, they took two teams, one that was doing traditional, uh, development where you would do your

implementation first and then come back. And if there's time you'd unit test and the other team that did test driven development where they wrote their unit test first and then started writing the minimal amount to you. So at first all their tests failed, then they would write the minimum amount to make the test pass and then expand on it from there. And initially, if I remember the book correctly, initially the results were that in the first few weeks, the team that was doing the implementation was far exceeding the team doing the test-driven development pattern. But very quickly, within like, maybe third week or less, I forget exact numbers. But very quickly, the test driven development team started to they caught up, and then they started to pass the other team. And then where they really started to excel and really gain momentum past the other team was once the other team had finished what they thought was their initial implementation and they got into their testing phase,

then they were discovering a lot more bugs and some of those bugs were really costly to, you know, to the overall, you know, architecture and things like that, that they really ate up a lot of time. And the team doing the test driven development, their testing cycle was a whole lot smaller because they found far fewer bugs because they had taken so much, um, time up front to, to put the testing in place. So, I mean, some of this we did, we did cover, but yeah, we, we have definitely made some jokes at the expense of TDD advocates.

Yeah, we even did in the last episode. Nobody does that. I'm sure we'll continue. Yeah, I mean, that's what we do. It was a really good email. It was very thought-provoking. He had some really good examples that he gave us, and so we really appreciate that email. Yeah, and to go in before we wrap up with it, though, another thing that he did touch on that I liked, because we did pretty much say that, you know, you pretty much don't do TDD and Brownfield.

So existing applications. But he said that they actually, he does anyways. And he finds that it's useful because before they go try to solve a problem, they build their test cases just like they would if you were starting from scratch. You build those before you actually go in and try and solve the problem. And again, he said the big piece was truly understanding what the requirement was. So it's almost like what we talked about in episode 26 to where you're given a problem in an interview or something, you need to fully understand what it is. And TDD actually facilitates that, right? Well, I know I've done this and I think we've actually talked about this before.

Um, I think maybe we talked about it in that episode, uh, episode 20. Um, but I know where like there've been times before, like for certain bugs in a system, especially in a system where we already have a lot of these test cases in place, it's easier to do this where, you know, there'll be some bug come up and i'll go ahead and write a a um test case specific to that ticket right and and there have been times going back to our naming conventions where uh for right or wrong i've actually put the ticket number in the name of the method just for my own tracking purposes probably wrong. I don't remember if I committed it that way. But I know I do recall I have done that before.

But yeah, I mean, I've definitely created methods that tested. And that way, that test was already failing. Right. And then you're trying to turn it green. And then I would try to fix the bug to where it would pass. But the problem with TDD and Brownfield is a lot of times you can't really write a test because you know if you haven't started out writing testable code then it can be really hard to kind of just get in there and verify what you need to without touching database and session and files i mean this is

where like it gets such a it it gets such a bad uh name because because if you're talking about like, it depends on like how deep into this application are you talking about you need to fix a bug or write some test case. Because then, yes, there could be a lot of dependencies that are interwoven in because it wasn't really thought about in a TDD modular kind of way where everything is broken apart nice and cleanly. But there are some times where even in these brownfield applications where smaller pieces are easy enough to go ahead and test where you could do the example that I gave where you go ahead and create that test case for the bug. When you can. It's not touching the database and the file system.

If it's in a code behind in a web form type thing that's nesting in database calls and 20 other things, it may be a little bit more difficult to do that because it was never broken apart in a way that you can actually write a test case without having to go through 30 steps to even get there right so i i think that's what we meant when we were talking about this with brownfield last time is we just made the assumption that it was just not architected or or i shouldn't say architected because there's a lot of ambiguity it wasn't

designed in a way that actually makes that achievable right just interwoven dependencies like you know like what joe mentioned like if you have session scattered around throughout your code right or you know a database or file system references just scattered around throughout the code where it's not easy to be able to mock those in your you know method or class under, then it can be more difficult. Yeah, but I really do appreciate him writing in because it is nice to know that there are companies out there that are actually allowing their teams to start off from a good starting point, right? That's excellent. I mean, it seems like most places I've worked, it's moving so fast

that they don't want to slow down to take the time to do stuff like that. So yeah, he, he definitely put a lot of thought into this and, uh, I think we may have struck a chord. Yeah. I mean, we did, but it, and, and again, like, please do anybody that ever has any kind of comment like this, like I loved getting it because the guy put a lot of thought into it and obviously is very passionate about the way that they approach it. And his software is probably very bug free compared to a lot of other software out there so um yeah definitely like if you ever have uh yeah he didn't have some interesting statements in here though where like uh he said that you know i i view test driven development really as requirement first coding yeah you know yeah and that's a really good way of putting it, and that makes a lot of sense.

We went to some meetup that was a business. That narrows it down. It was a business tool for writing test-driven. Oh, SpecFlow. We talked about that one time before. And that was really interesting because you can build those things up front, and that's kind of a nice way to let the business interact

with your application to a certain degree. SpecFlow solved a different problem, different problem though it's for business and that was also there's also like what was it cucumber um i don't remember and that it was cucumber was the javascript version spec flow no if i have that ruby cucumber was for ruby yeah that was for j JavaScript. What was the JavaScript one? Pickle? No. No. Did you add vinegar?

That's real. I'm not making that up. I'm not making that up. I have no idea. Somebody Google that. Cucumber is JS. Let me see what it is. Ah.

Then it was pickle. That is ridiculous. Really? I must know. There was a pickle framework. So pickle for Ruby? How do you know when it's a framework? I don't know what that was about to pull up. It There was a pickle framework. So pickle for Ruby? How do you know when it's a framework? I don't know what that was about to pull up.

This kind of scares me. Pickle for Ruby. Whatever. One of you guys can find it. Our spec is Ruby. There's also Cucumber, though. So I don't know. There's Pickle My Cucumber, Ruby Flare.

I have no idea. All right. So now we're just rambling. All right. Yeah. Anyways, yeah, so it is definitely. Pickle is a JavaScript implementation of the Python pickle format. Oh, yeah.

That does nothing for me. Pickle is containing cross-language subsets of the primitive types. All right. Awesome. All right, so moving on. I knew it was a real framework. Thank you for the email. See, that's the problem.

There's so many JavaScript frameworks out there, and they've got to come up with weird names that don't describe them. Well right. So moving on. I knew it was a real framework. Thank you for the email. See, that's the problem. There's so many JavaScript frameworks out there. They've got to come up with weird names that don't describe them. Well, they have to follow. They need to listen to this naming convention. They have to follow Java. I mean, for every framework that Java does, we need at least one more for JavaScript, right? I don't know if they're related, but my point, though, is valid that their names are horrible. All right.

So now we're coming back around to design pattern versus algorithm oh we're onto that yes so is a design pattern algorithm yeah there there was some awesome feedback we got um on on this question and it came from a variety of of sources to twitter or email uh it seems that the consensus was that uh no they're not the same right yeah yeah and we got some really cool examples from people um you know like we mentioned the rue one earlier uh kind of explaining uh how they understood the difference and that was really good for helping us kind of but wrap our head around it but here here here was so i i wanted to add a little bit to this though because if you were to

go and do a a google search uh for uh you know just simply go into google is a design pattern an algorithm right the top two results are going to be from stack exchange or you know stack overflow sex exchange same thing. Both on this topic. What's the difference between an algorithm and a design pattern? Or the other one is, what's the difference between a design pattern and an algorithm? So just flip-flopped. But those are the top two Google results. And I found it, even based off of some of the feedback that uh you know the listeners were giving back even going back and looking at like formal definitions of these things it's so vague yeah it's right like like let me just say read this off from wikipedia right so a design pattern in architecture and

computer science is a formal way of documenting a solution to a design problem in a particular field of expertise right all right now huh yeah oh we're back now here here's algorithm in mathematics and computer science an algorithm is a self-contained step-by-step set of operations to be performed oh self-contained that might have done it right there. Well, it was more, what was really more, as I was trying to like dig into this, what I was really hoping to find was like something more,

a little more definitive and I never really did. Looking for a smoking gun. Yeah, but I think it was more the step-by-step part of the algorithm definition and the design pattern one was more a design problem in a particular field of expertise like as taking aside the examples of like the like if you were to

go and look at design pattern information on like the singleton was the example we gave right where there's plenty of implementation there's plenty of like here's the steps that you need to do. Right. Then aside from that one, the other ones were like, okay, this makes a little bit more sense where they, you know, where you could make the strong argument that these are not the same. Right. Um, but my favorite answer that I did find that was on a stack overflow from actually, or the stack exchange link that was actually the accepted answer, although not by many. And I don't necessarily agree with his answer, but I just thought it was kind of humorous was that the guy says, a binary search is a design pattern. It's a problem that pops up all the time and the same pattern, i.e. binary search, solves it.

There's no difference between design patterns and algorithms from a mathematical level. Now, if you're talking to another human, you should probably not say this because they are not capable of reducing ideas to their base components. Just like you shouldn't tell a math guy that all math is just basic addition, even though it's true. I was surprised that this was the accepted answer but people like people who but it was interesting accepted by the asker uh okay fine but but it actually had some votes on it too though or at least an extra vote. Interesting. So we still don't know.

Well, no, I mean, the consensus, definitely the consensus is that they're not. They're not, right. You know, but like I said, like, you know, you go back and you, you know, dear listener, do your, do your own reading on this. You'll see like the definitions of both are so vague and it you could make you could really make an argument in either direction if you wanted to and the only reason why that guy's answer that i read off that i thought was kind of interesting was the fact that you know if he did break it down to where he mentioned you know it being from a mathematical level and how legally there have

been arguments that you know everything that we as developers do is just math formulas. So who cares? Right. You know, there, you've heard those arguments before when it comes to like the, uh, patentability, for example, of certain, um, uh, you know, algorithms or code or whatever, that when he mentioned that, I was like, okay, now it definitely kind of muddies it a little bit more. But I agree, they're not. Yeah, and we really appreciate the feedback, and we got some really good conversations out of it.

So thank you. All right, so our next one came from probably Outlaw's favorite person on the planet, Jeremy Singleton. So he asked a question about- I think that name's a lie. I don't think that's his real name. It's pretty awesome. He's just buttering you up.

Yeah. His real name is Jeremy Factory. So he had a question about the various different types of frameworks, such as MVC versus MVVM. What's the difference? What, what, what, right?

So, um, and it is kind of vague because you look at certain things and they're just labeled that way. And so it's easy to just take them at face value, right? Like you have the MVC framework in.net and then you have mvvm for you know um it was silver light xaml that kind of stuff so there's there's tons of things so at any rate

we dug into this a little bit and and i believe joe did you put together these notes on it yeah i did and actually this question reminds me a little bit of the one uh we were talking about just a second ago with algorithms versus design patterns where we can define either one but when it's when you try to compare them that things get a little weird and so we thought we'd start just kind of by saying what model view controller is and basically um we found a real simple uh version of this where we say the m and mvc stands for model, which is what your item is. Data. Data. V is for view, which is what that data looks like. True UI. And C for controller is what it does.

Yep. But that's really simple. So if we're talking about, say, a website, and you go to the homepage, in the, there might in the code, there might be, you know, a controller for the homepage. I'm not really sure what this looks like, but I can tell you that there's going to be a lot of models and at least one controller involved in the making of this thing. Yeah. So usually your controller is shaping the data or providing the data to your view, right? So you have, in an MVC application, your model's your data, your view's your, let's say it's a web page,

right? Then that's going to be your HTML and whatever templates have been defined over there. And then your controller is what's taking that data and providing it to the view. And it also does things like if you click add to cart, then your controller should be handling that action, right? The logic. Yeah yeah it's what's your pages doing yep and then so when you get into the mvvm and there's even mvcvm um i mean there's a ton of variations on these things but really what it boils down to is mvvm was created by microsoft essentially based off uh martinowler's, uh, one of his designs, but essentially it's, it's binding. So your view model is kind of like a bridge for the data to go from in, in, because there's no controller there, it's kind of, it's kind of hard to say it, but

your view model is, is what takes your data from the model and then provides it to the view itself. So it's kind of just like a transport layer. It's not supposed to have any knowledge of anything going on. And I think the reason why they did it, and it really all boiled down to this, it was data binding. So essentially you could have your UI guys working on the view. You could have your, your, um, programmers working on, on the logic part of it. And then this view model would just be what says, hey, take the data from these guys that programmed it and give it to the view and let it use it. Yeah.

And what I think is important to mention here is that the M and the V are kind of the same. But what is kind of different or at least implied different here is when you're dealing with an MVVM situation, you're often dealing with more than one model. And that view model takes those different models. And it kind of brings those together into a way that the view can deal with. So it takes, you know, the products, it takes the account information, it takes the, you know, search data. And it kind of brings those together in such a way that the view can make sense of it. And so the view knows how to get its products and it knows how to get to your name for the, you know, hello Joe kind of

stuff. And so the, the, the VM really simplifies what the presentation layer has to know about. Right. The basically what it boils down to is your view should not be doing any kind of logical type stuff. The, the data that is coming across should just basically be spit out onto the screen, whether it's on a web thing or on your desktop app, something like that. And I'll take it to Angular for those who are used to that kind of thing. Like they have this whole it's an MVVM type thing, or it's actually kind of MVCVM because they do have these notions of controllers, but essentially your controller should be what's changing things. It's doing the logical pieces of

the code. Then that gets bound to your view. Anything that you change in the view automatically gets transferred back to the model and vice versa. So it's a two-way data binding, at least in 1.3, apparently they're doing away with that in 2.0, but it has a lot to do with the binding and not having your, you should have all your logic in the controller and then your view should just be able to, it knows the shape of the data that's supposed to come over and it should just be able to use it. That's it. Yep. And MVVM doesn't mean that there is no controller. You know, there's still something that needs to kind of manage these behaviors and events. It's just that there's this kind of this VM there.

And there's actually a really good example or explanation someone gave on Stack Overflow. True Blue Aussie will have a link to this. But they say that the view model holds a certain shape of data and commands. And they don't know or the view doesn't know where the data comes from. And it doesn't really care how that gets saved or kind of reflected back to the persistence layer but the view is able to communicate with this view model and that keeps that view really dumb and focused on it's just just this job of looking good yep and and i will also say also with this mvvm is typically done all at your view layer which is kind of odd right so if you have an mvc

so in dot net if you're talking about uh your your web mvc that's usually talking about server side technologies so your models like your database storage and all that kind of stuff your view is your html page and then your um controller is the actions like your button click you might be we're going to put this all in we're going to put mvvm inside of my mvc that's yes so actually the mvvm actually replaces your v typically so that's generally speaking what you have so i mean if you're really going to break it down it'd be m mvvm c right and that's that's really what you're getting usually when you see these frameworks that is your ui level um yeah the v and the vm are very tightly coupled you're not frequently going to see those used apart but you are going to see models statement

though so what that's a bold statement that's pretty accurate i mean because that's what it usually boils down i like your confidence sir confidence, sir. You like that? I'm about to get all kinds of flame mail on this. This is going to be great. Well, I do think of the view model as being closer to view than model. At least that's how I kind of think of it. You know, it's just kind of a presentation layer that that view knows how to interact with. A view model closer to view than model? Yeah.

Yes. You wouldn't consider it closer to controller than either? Not really, because I think of the view model as data only so this is you know when i yes when i change my name on the account page then it knows how to um you know reflect that change back it's your glue and the model is in charge of writing it to a database or log or you know whatever else yeah well i only i only pose that but just because like uh in in this very stack overflow article that you're um pointing out like there was one of the high rated ones was where the guy was saying that the it the view model replaced the controller

yeah i don't agree with that i don't either i've never seen it happen that way i think in a simple example it can be like if i'm making like a simple account page where I kind of, you know, sign up and I say save that I can get how that VM replace the controller there because the VM should know how to kind of write itself back to those various models. And that makes sense to me that you wouldn't need a controller. But I don't see a lot of behaviors happening in that view model. I don't want to see button click events in the view model. And I think you need those things. Right right okay i i'll give you that one i agree with you there that's my opinion but yeah so i mean i did want to say that um this is sometimes also referred to as the model view binder yeah we saw that so depending on uh you on your language. They said non-Microsoft usually refers to it that way, right? Well, knock out JS, for example.

It's model viewfinder there. It's kind of interesting. I think because we program in a Microsoft realm. Oh, my God. This is a Microsoft show? It's JavaScript, isn't it um i mean usually when i hear like uh angular or a lot of these other ones uh ember they're usually referred to as mvvm i i haven't actually heard that other one ever referred to in the model key binder yeah i'd never heard of it it like even even when i'd heard

just to be complete nice try guys it's mvvm yeah. I mean, I'm with you there. I've always heard it as MVVM. Yep. Oh, I had one example I wanted to give. Maybe I should have done earlier. But I did want to say that you can have MVVM without binding, strictly speaking. And I wanted to give an example where I had this project. It was a website, and it had one of of these 17 step wizards where you kind of, you know, you enter your first name, the next page has your payment details, the next one has, you know, your job history, whatever. And what was kind of interesting about that is the database structure was very flat, like there was one big table that had a ton of rows, everything was one

to one. And this wizard would fill in different parts of this table based on what step you were on. And in this case, you know, there was really only one model. And I had a bunch of different view models, though, that lined up with each step of the wizard. And so the view model was in charge of, you know, knowing how to set those fields and unset if you, you know, chose different actions. But the views didn't know anything about how this was, you know, only one model in the background. So I thought it was kind of an interesting, interesting use case of a MVVV MVVM pattern. Say that 10 times fast. I can't without binding.

Yeah, that is. Yeah. So, uh, hopefully that helps a little bit. I mean, uh,

before MVC got popular, I mean, what was it? Just willy nilly style. You just do whatever you wanted. PHP, baby. I mean, really, the only reason these patterns exist is to separate concerns.

We've talked about it a number of times, but a lot of times it's separation of concerns so that there's code maintainability, but there's also testability, right? Like if you have your model and your controller and everything nested in one, like we talked about earlier, it's really hard to put together tests. View code in general is hard to test.

Yeah, it is. But the whole purpose of something like MVVM is you should never have to test your view because it doesn't matter. That's really the whole idea behind it is because it's kind of a dummy container that just spits stuff out. It shouldn't matter that much. Really what you care about is what happens when data is moving back and forth. So, and I know that's a really general thing. Of course you want to test your UI, but as far as writing like unit tests and that kind of stuff, you know, this allows you to do that. Oh yeah. And did want to mention, if you guys have a better explanation, then we would love to hear it. So tweet us or email or

something and we'll throw it out there. Yep, absolutely. We're not afraid to address our past mistakes. Indiscretions. Indiscretions, yes. Yeah, I'd like to actually hear some cool examples of where others are using MVVM. Yeah, I'm sure somebody out there has like a one-sentence example

that just sums it all up perfectly. Maybe. They would have the key to the internet. Yes, they would. All key to the internet yes they would all right so we also um sam uh the guy who found outlaws hidden layer again or not so hidden layer uh he he did write in and said something about you know hey some of the things that i'd like to hear more about it would be like learning things that are hard to learn at your job uh agile scrum,

uh, making enterprise architecture choices. Um, and then potentially we might even have a future episode cause he asked about mocking libraries and he also asked about unit testing, which is episode 20. So if he hasn't heard it yet, please do go back and listen to that one. And then,

and then ask us any questions that we might've glossed over. But so it's kind of hard to teach yourself agile by yourself. Right? So here, here was my take on the agile thing and Swansea con Swansea, might have glossed over but so it's kind of hard to teach yourself agile by yourself right so here here was my take on the agile thing and swansea con swansea con is actually a good way to do something like that it's it's a whole conference dedicated to learn for agile people or so the way that i look at something like this is if it's not in your current job and it's something that you are passionate about and you

want to go learn going to a conference or maybe even a class is an excellent way to get filled in on this kind of stuff meetups are awesome there's probably an agile meetup near you yeah more than likely there is because it's incredibly popular now so that's according to linkedin i'm like an agile master yeah did you see that I endorsed you for it the other day just for fun? I'm going to do it right now, actually. Jeez. So that's definitely one way, especially with something like that, because really that's more of a methodology of doing things, right?

So that's a great way to learn that. Another way, dude, Pluralsight actually has videos on this kind of stuff. Also, you can pick up books on Agile and Scrum. Granted, you can't put it into practice because maybe your company doesn't want to. But if you learn it enough, potentially you can get it in there. And then there's always this. Your company doesn't want to do it, you just go to another one. That's harsh.

Yeah, that's a little rough. But I mean, I'm not telling you to leave your job. Where is he you know now this one i know we're all somewhat passionate about making architecture choices so again that's kind of vague but let's talk about just picking your your tech stack for one oh we already did this though that was the hot stacks episode well that was just me rambling on about not being able to make it i mean we talked about that we went into that in detail about like picking which technology stack well let's talk about it within a company as opposed to just a side project which is what i was talking about initially but i think our

answer is there applied to either i mean basically We talked about different ways Of prototyping it And there's something to be said About getting it to Getting to market fast Right Whether that's a market for yourself Or for your company So if you wanted to prototype it

In something that you know And you know well Then there's no harm in that But if you Unless you just really want to take the time To learn some other framework Or there's something else out there That you've heard a lot you know, unless you just really want to take the time to learn some other framework or there's something else out there that you, you've heard a lot of great things about and you really want to take the time to

invest and learn in that, then sure. But you know, that, because you're going to be less knowledgeable about that, you might be setting yourself up. All right. So let's talk about it from the perspective of, you have a team of 20 people and you introduce a new stack. And now you've got, let's say, let's say that in,

in a situation you already had three tech stacks and you only had a couple people that were dedicated to each. And now you introduce a new one. Um, would you, I mean, they can, they can set you up.

Which one costs the least? Yeah. I would say think long and hard before you do that. Cause there going to be some attrition it's really yeah it's that the answer is always going to be like which which one costs the least but is that immediate cost or is that future because the thing is your boss and the bean counters won't matt won't care that's that's true now if you're out you're used to kibble maybe it's time to upgrade but there has to be some serious business reasons for changing yeah i think i mean that's that's one of the the key things that i want to take away from just saying this right here is just because something's free like let's say my sequel right maybe they don't want

to do it for for reasons that you know i don't know what they might have but you know they they have licenses for sequel server they're spending a ton of money on it they want to stay with that right yeah i mean yeah so i guess i guess like this question this question could be taken in a couple different ways like you know enterprise architecture choices is it your enterprise and these are your people right or is this a customer and it's their enterprise i'm so lost right now but but you know regardless the the cost is definitely going to be a factor when you start talking about uh enterprise you know when you start talking about the big large companies like that because it's going to matter you know what i was talking about with the quality yeah we have some water running you're probably not going going to hear it. Actually, it's very faint when it comes out. So, yeah.

So, unfortunately, you might want to use the new hotness, like you'd mentioned the next version of Angular. That's going to be more difficult to find those resources. Those resources that are good are going to be more expensive. And it could change. Documentation is going to be harder to come by for it because it's still so new. Therefore your development cycle is going to be longer. I mean,

those are all serious costs that you're going to have to weigh in and you know, whether it's your company or, uh, you know, your, your client's company that you have to think about. Plus you have to think about, like you mentioned,

like, and I think, I think these are all things that we addressed in that episode. I don't remember that, that it was, uh, it was called hot stacks. I don't remember that. It was called Hot Stacks. I don't remember. I can find it. But do you already have licenses for Oracle?

Well, then if you already have a site license for Oracle, then switching over to SQL Server, there's going to have to be a good reason for it. Or maybe you already have a lot of in-house expertise on SQL Server. Therefore, moving to DB2 is, you know, you're going to have to, there's training and tooling that's going to have to happen there. So, you know. Yeah, that was episode 17. Unfortunately, money is going to be, you know,

a big part of that decision when it comes to. But I also think you need to look at your team. If you've got a bunch of experts in one technology and you're wanting to go another direction because it is the new hotness or because it's something you're interested in, you have to take that into consideration when something goes wrong, you know, who's going to be able to work on it. Right. Um, and I will say though, there, there is something to be said too, like, and, and I joked about like leaving your job, but I mean, honestly, if, if I was stuck working on a VB six application today, I would be looking for something else.

Well, that's different, though. That's an outdated technology, though. Like when Joe brought up the COBOL example. But let's bring up another example. Let's say like if you are in a shop, let's say, okay, you're in a C-sharp shop. And you have a strong passion to write go, right? You know, in that case, then maybe it would be advantageous to go ahead and start shopping around if that's something that, you know, you truly wanted to pursue. But if you were to create some new app and you wrote it in

go and you're the only one that knows it and you're the only one that can support it, then, you know, as that company becomes dependent, then, you know, as that company becomes dependent on it, you know, that that's going to become their technical debt that, you know, you have to consider when you choose that. And I will say this too, and this is probably, I don't know, maybe going a little bit too long on it, but one other thing is consider how easy it is to find resources out there. I actually hate my answers though, because it just makes it sound like, you know, just stay with the with the norm yeah and and that's that's always a tough thing right like that's often the answer it really is often the answer and that's why there are still companies

working in vb6 but it's it's it's one of those things too though like anytime that i'm working on a project six i can't take i can't i can't accept that argument and here's the reason why here's the reason why i can't accept that argument because that here's the reason why. Here's the reason why I can't accept that argument because that is a case of a company not upgrading as things progress. So to make an analogy to that argument would be like saying a company who's still on like C Sharp or.NET 2.0.

That would be the equivalent of tier V Sharp 6. Okay, I'll give you a different one. But using a different architecture or different framework you know like things like that like you know uh hey we're on uh uh you know i can't even i'm trying to think of an old javascript library but you know and you want to move to prototype.js okay and you want to move to angular 2 or you want to move to knockout or you know ember whatever you know whatever it is Knockout or Ember, whatever it is that, you know, whatever your new hotness is that you think this is going to solve all of our problems. I've done some research in it, but that's different because it's not necessarily just an upgrade. Whereas your VB6

example is the company didn't take the time at the times that they should have to upgrade their application as changes were happening to visual basic and so now going from vb6 to dot net four or five or five oh is coming now it's going to become a bigger effort than it should have been had they maintained it all along so i'll say like there's i used to do cold fusion programming and a lot of those companies that had it had, you know, hundreds of thousands of lines of code written in that, and so they never wanted to change away from it, right? Like, it's like trying to steer the Titanic away from that. It just wasn't going to happen.

And so they end up staying with it. And so if you find yourself in a position to where you can't work on new architecture because you're stuck on some old stuff, then maybe you need to need to look at what you want to do um well i agree with that if you're in a company that's just dead set in their old ways and they don't want to move with technology then that might not be the place for you and you can and you have to be careful because you can easily if if this if this ends up being two or three years down the road you're stuck in an old technology you haven't touched any new stuff and it's going to be hard for you to shift gears and nobody else is using it you're basically like putting yourself out of

market yeah you are and that's what i'm saying on that old technology like those years if you were doing visual basic six development right now and and i'm sorry there's a lot of visuals basic six but that does nothing for your resume right now. Right, and that's the thing too. Like let's say this company has a layoff and you are no longer there. What are you going to do now? So hopefully you've been at home programming on your own,

trying to figure stuff out. I mean, it's just a really tough thing. So I wanted to say that, but then the other thing also, I've led projects where you're looking at what technology stack to use at the time. And again, it's different than when you're just doing something for yourself. You can pick up whatever you want, right? Cause you're just trying to do it for fun or whatever the case may be.

If you're in a company, you need to look at what kind of resources available. Can I find angular programmers? Can I find.net programmers? Can I find COBOL programmers, right? You need to, and like Ember, Ember is one of the hot new javascript frameworks and a lot of companies use it um especially startup companies but companies that are looking to make big teams go quickly it's hard to find those resources it's scary to be on ember 10 years from now when there's you know radiant and emerald and whatever else is on time you know you don't want to still be supporting by that but you have to be thinking about that sort of thing when you make decisions like scott hanselman actually had a really nice quote about um basically asking yourself you know have i had 10 years of experience or have i had one year of experience 10 times interesting yeah so yeah i mean you i was thinking

about this the other day um not necessarily the architecture question, but just like as a software developer in general and making sure that you stay current and marketable. It's kind of like with doctors or anyone in the medical field, they have to stay current, take continuing education classes with latest findings and whatnot as it relates to medicine. And in a lot of ways, software development is similar in that if you want to stay current, you have to find a way and get into a good pattern of continuing to learn new technologies as they come out. And that can be-

I know that's off topic of that question, but- No, but it's a very good point. And it can be either you move to jobs where they have that to where there's constant growth in it, right, where they're changing technologies and they're staying up all the times. Or it can be you're just spending your nights, you know, going through and watching Pluralsight videos or writing sample code. So it's really up to you. But it is something that, you know, if you're still programming in one of these older languages, you're doing yourself no favors. Yeah, and it's a dangerous situation to be in. Speaking of older technologies, I just endorsed Michael for Subversion.

Awesome. Hey, I actually think I did the other day too. Oh, my God. Me and three others have. I'm going to un-endorse him for all the new stuff just for fun. Oh, come on now. That's not nice. Okay, I won't do that.

Yeah, and while we're on top of you guys, you should go link us in and we'll endorse you. Yeah, check us out on LinkedIn. Scratch my back, I scratch yours. Yeah, www.codingblocks.net slash about, and you'll find all our profiles and LinkedIn links and all that kind of stuff. Oh, Jesus. Anyways, all right, so on to the resources we like this week. So Joe, kick us off. Yeah.

I wanted to mention Code Complete. That's the book we heard. That you put down? Yeah, it is. I'm sorry, man. That is the book that I stopped reading at when talking about naming things, but it is a really good book actually. And also there's the book Clean Code, which also talked a lot about naming. And so that's, I didn't actually mention it when we talked about it, but it's is a really good book actually. And also this is the book clean code, which also talked a lot about naming.

And so that's, I didn't actually mention it when we talked about it, but it's also a really good book for that sort of thing. All right. And this isn't actually our resource, but Mike Barlow wrote us quite a while back and I dug up his email and he had a fantastic thing going back to one of the episodes where we kind of went on about plural site versus Linda versus books,

whatever. And he had a, he had a resource I didn't even know existed. This is kind of cool. Cause we had talked about, you know, it's frustrating trying to pick up a book, get it home and then find out that it's not what you wanted. It's, it's not that good. There is a safaribooksonline.com and they was, uh, yeah, safaribooksonline.com. And they have a whole library of books that you can check out kind of like a plural site or something

and just go look at it. And it's $39 a month so it's kind of up there. A little bit costlier than the plural site lower end thing but they have a whole slew of books from different publishers. You're talking about this like you've never heard about Safari Books Online though.

I haven't. I just said. I've never heard of it. Oh really? I missed that part when you said that. Merry Christmas. So then like you've never heard about safari books online now i haven't i just said i'd never heard of it oh really i missed that part when you said merry christmas so then really you've never heard of this ever wow yeah yeah so um if you haven't heard of it like me because i've never been on the internet then um you know you should go check yet another example of things i have not seen on the interwebs. But, yeah, I thought that was pretty cool. So you can basically spend $39 a month or $400 a year, and you basically have access to a whole slew of technical books, which is pretty awesome.

Yeah, and what – man, we should find that email. Because the one thing that I didn't realize – because I have heard about this before. But the one thing that he called out in that that i wasn't aware of was that i always assumed that it was um locked down to just the o'reilly books but he actually referenced in his uh a press o'reilly pax sam's manning addison wesley yeah, and Manning especially is one where I really like a lot of the Manning publications. Yeah. That's one of my favorites.

Yeah, these are major, major publishers. It's not just one. Hate the covers, though. Yeah? The Manning covers are terrible. O'Reilly covers are awesome. I just wish you could get them. I wish you didn't have to buy the physical version to get the soft copy.

Oh, and also a thing he mentioned that uh i didn't realize either is they have videos so like he said he would do a search and and then sort on the publish date so that you could get the freshest one and like angular js and the title of a book there were 30 books and 10 videos um asp.net nvc 31 books, 3 videos, JavaScript, 224. It sounded like they had completely expanded on this thing since they originally launched it. So while I had heard of it, if you, like me, recalled this thing when it originally started out

as an O'Reilly thing, know now that they've expanded on the offering. So it might be something of interest to you. Yep. So thank you, Mike, for sending that tip in. That's a, that's excellent.

All right. So let's get into the tip of the week. Is this really the week or the tip of the episode? Whatever. I have a tip every week. It's just, you guys don't get to hear it. Oh,

all right. So, so mine, but you know where you could is if you signed up for our newsletter, that's, that's weekly that's the tip of the year now we may tweet weekly yeah we do that so so for my tip of the week the question is oh where oh where is mike's tip of the week and i say that because my tip of the week my tip of the week and alan will attest to this is to use a wear clause oh i'll

burn so all your sequel if you're going to do an update statement you should be careful and use a wear clause i don't know what he's talking about write the wear clause first i don't know what he's talking about i i always write like update table set and then i don't say what he's talking about. Write the where clause first. I don't know what he's talking about. I always write like update table set, and then I don't say anything else, and then I say where, and then that way it's already a syntactic error so that I'm safe that it won't run. So frustrating, man. It's such a newbie mistake, man.

But since you just tweeted that out i was like oh that's uh where where's my tip you know what your tip could have been i was wondering like i was like when when i put that in the show notes i was just waiting on one of you to like catch on to what i was gonna say yeah i got it now i'm not happy you know what might help you Alan Is something like T-SQLT Which is a unit test framework For SQL I'm not unit testing my SQL My SQL's right it just didn't have a word clause

There was no error when I ran that It just had a higher row count For some definitions of correct But you guys all know that moment Where you run it you're like Wait why is it still running why is it why didn't it say one where's the undo yeah and there's like 10 vendors that will sell you some sort of unit testing solution for uh sql and none of them will show you the syntax so you know what that means man and you know what hurts so bad was his previous

tip of the week was if you put that begin transaction right before the update then you can run both of them and if it's not the right row count then you just roll it back i was like man i so so aggravated anyways all right joe what's yours so that's an awesome tip of the week that alan can take home with him yeah whatever i think alan should go first because mine's sad yours is sad yeah all right all right then so i will go first because mine's sad. Yours is sad. All right. So I will go first or I will go second. This one's actually kind of cool. I found this on a LinkedIn thread that people were arguing about things,

which is what they do up there. If you want to write a – you want to create an application, but you basically don't have an API or a backend, there's a site called apiary.io where you can build these server-side APIs without actually writing any code. And if you were just a person doing this, it's free. You can set it up and you can go create these server backends and it gives you all kinds of stuff you have uh http like proxies that you can look at how data is coming in and what should be going out and all this kind of stuff so it's rather interesting i'd never heard of it um but and i haven't actually played with it much yet uh other than just reading through what it does but you can basically mock out and build these apis that are functional and test your applications against it without actually writing any code. So you can

focus on, on creating these APIs that you want. And then after you finally narrow whittle everything down to what you think it should be, then you start actually coding it. So, uh, pretty cool. Very nice. All right. Now for my bummer tip. So a couple of weeks, maybe even months ago at Atlanta B-Sides, I saw a really good talk, which is titled basically, When You're Online, No One Knows You're Dead. And it basically had to do with, you know, a really tech savvy person who died and their surviving spouse had to kind of figure out how to manage the leftovers of their kind of digital life. So it was things like trying to figure out how to access family pics that were

on his computer, Facebook status, Facebook, and even how to get Facebook and Gmail and Outlook and everyone to kind of, you know, turn over the rights to those accounts to kind of shut some of the stuff down. Because you think about, you know, banking statements, you know, turn over the rights to those accounts to kind of shut some of the stuff down. Because you think about, you know, banking statements, you know, services, hosting, this person had a side business, a lot of the bills for the family were, you know, basically in digital only form. And so they had to kind of try to crack into those emails. And it was really tough. And it was a really good talk. And even just the home network, how to kind of figure that out was all, you know, really tough and where the backups were, et cetera. What was their answer to LastPass?

They had a lot of answers. It was very complicated. And one of the actual things, I think it was called the Iron Key. It's basically something that you can do. It's almost like a USB drive that has kind of ways into and information about all your various different services and something that you can kind of put in a safe once a month or something like that. And when you die, you can get turned over to someone and they can kind of take over that stuff that is kind of sad thanks yeah but it was a really good talk and so it's actually about one of the guys from the defense there's something you need to tell us yeah just in case is this why you're moving but you know what that is kind of valid

because my wife has actually said to me before she's's like, oh my God, if you weren't here, I wouldn't know how to do any of this stuff. I wouldn't know how to get my Wi-Fi working. She literally kind of freaks out on occasion about it. Teaching her how to set up a Wi-Fi is one thing, but giving her the credentials, though. Yeah, yeah. That's why I asked, is LastPass the answer to a part of a lot of these because you could just you know family share that stuff but but you have to admit like as techies we we don't and i've said this before and we've come across this before where like you know this happened with uh the get logging credentials right you were like hey man i found this great thing to where you don't have to type in your Git credentials every time you do something. I was like, oh, yeah, I already did that, right?

You don't think about it because this is just what we do. You find a problem, you get past it, and you move on, right? We don't think about how difficult some of this stuff is. So I need a wiki for my life is what you're saying. That's actually what it sounds like, right? Yeah, this guy had some kind of helpful tips for how to kind of manage that sort of thing but um in particular this guy he was kind of security guy so his hard drives were all encrypted you know full disk encryption um you know things like network passwords or just computer passwords for his devices weren't in

things like last pass and so there were things that were difficult to get into including a lot of you know he's a family photographer so there are all sorts of pictures and stuff that are kind of locked away on disc and there's not a great way of getting that data so just things to think about yeah yeah so excellent tip real sad thanks and even phone numbers and stuff like you know it was a car accident and so you know the the devices were lost and so it was really hard to even like brought the tone down enough on this show. Yeah, you really. Way to take all of the fun out.

Yeah, see you guys next week. Wait, wait. They're not just IP addresses now? They're still phone numbers? Some areas of the country. Okay. All right. So we hope you've enjoyed the show.

We've talked about naming conventions and TDD and NVC versus MVVM and stumbled on how to say that 10 times fast. And let us know what you think about in regards to some shorter episodes. We'd like to get some feedback on that. Which was www.coatingblocks.net. That's your fault..net poll p-o-l-l all right so subscribe to us on itunes stitcher and more using your favorite podcast app and be sure to leave us a review on on those platforms as well i guess we've said before we greatly appreciate that it goes a long way to help us and to help uh new listeners find us so

we really appreciate it. Yep. And contact us with any question or topic. As you can tell with this episode, we really do like to get them in and we take them to heart. Leave your name and preferred method of shout out if you want one, website, Twitter, whatever, and we'll mention you on the podcast. And visit us at codingblocks.net where you can find show notes, examples, discussion, and more. Yeah, yeah. Send us your feedback,

questions, and rants to comments at codingblocks.net. It's like 10 o'clock at night, guys. I don't know. I'm shutting down.

One of these days we'll actually get good at this. We've only done it 27 times. Yeah, yeah. 28. Definitely follow us

on Twitter at codingblocks. We've gotten some great... No, 27. Huh? There was the one episode we threw away The secret episode that nobody knows about We did We got a shh They're listening

Anyways Follow us on CodingBlocks Follow us somewhere Go to Twitter at CodingBlocks We've actually had some great It's hard to call a thing on Twitter a discussion, isn't it? That's what it is. That's a discussion.

Is it? It's hard to do a discussion in 140 characters. That's why it says you discussion. Right. Or you conversation. Okay, yeah. Maybe it's a conversation. We've had some great back and forth on Twitter,

so definitely come join us over there. We enjoy that. It's a lot of fun. So that's it. Episode 27 is a wrap it's my nose whistling or is that your nose is that your nose what am i doing it's probably me do i have boogers that's why i wanted the napkin thing so i could like just gotta eat them you really don't like toilet paper

you don't blow your nose to toilet paper that's my preferred it's right it's right there but but then i need a lot of it whereas like you know one napkin has the strength to be able to last it's got strength no we we buy the good toilet paper man i need it yeah the two ply yeah two ply doesn't doesn't flake off yeah that's important yeah oh yeah man what is google wait which one do you use which one i don't know starman something ultra soft i get the ultra ultra strong oh yeah nice yes yeah man uh no toilet paper left behind i need like ultra sensitive you got like the aloe going on i need it man we're not recording i would love

oh my god i have a bidet yeah they, my God. I have a bidet. Yeah? They're fantastic. Oh, man. You have a bidet in your house? Dude, I bought one at Costco. Of course, I had it at Costco. It was like $200.

The only thing that sucked is I had to run an electrical outlet with a GFCI over by the toilet to make it work because this is the kind that you hit a button and it's like... Oh. It's fantastic. Oh, man. I thought that, it's fantastic. Oh man. I thought that was a water fountain. Little late. No, dude, they're great, but they do not eliminate the need for toilet paper.

Yeah. I've heard Leo say that it does. This is the most disturbing conversation because we're talking about how he wipes. Dude, Leo's gone off on it. He's got a $4,000 toilet. Yeah, but I mean, you got to do it with water in your hand at the same time, and then you wash your hand good. What?

You can't just do water. You can't just do water. When you take a shower, you don't just do water. You know what I'm saying? You don't do it at the same time. I don't want to know where you guys put your hands. No, man. They go together.

No, you don't do it at the same time You squirt and then you wipe Come on Oh my god This is the most disturbing thing that we've ever recorded Hey mine's got a hair dryer Not a hair dryer I suppose it is Where's that picture I suppose it is.

Where's that picture? Talk about your Freudian slip. Okay, so I suppose it is. That's awesome. Hey, you're editing, so you got it all. Okay, so wait a minute. Let me make sure I understand this thing. This thing is like an add-on to your toilet Is what you were describing

It's like a fancy seat You take off the lid Yeah you take off the seat And the closed lid thing And it's basically a replacement seat And lid It's a fancy seat It's fantastic

We've had it for like maybe two or three years Sounds like it'd be a mess Oh no no Not at all It will shoot you off the toilet The first time You do it Oh my god

You won't be You won't be ready for it Alright Whoa whoa whoa I put the counter in the In the episode Are we In the

The show notes thing Are we starting thing comments there it's got a hair dryer that might be the best comment accidental comment uh