Coding Blocks - Back to Basics – Encapsulation for Object Oriented Programming

Episode Date: February 10, 2015

It's time to get back to basics. It's easy as a software developer to be working on the latest and greatest frameworks, using the best methodologies, trying out new things. Sometimes it's a good idea to get a refresher on the very basic fundamentals. In this episode we go over the access modifiers that are common in C# and Java as well as ways to emulate these types of behaviors in Javascript. And let's be honest - encapsulation is only effective if you're providing programmers that come after you with a roadmap of how things should work. For that reason we also discuss Command Query Separation and some other ideas and practices that are a part of good programming practices. Be sure to head over to www.CodingBlocks.net/review and leave us a review on your favorite podcasting platform!

You're listening to Coding Blocks, episode 23. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And check us out at CodingBlocks.net where you can find show notes, examples, discussion, and other stuff. Send your feedback, questions, and rants to comments at CodingBlocks.net 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 Coding Blocks. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. And today we're talking about encapsulation.

So a little bit of back to basics. Back to school. Back to school. Before we get to that though, I wanted to mention briefly some podcast news. First off, big thanks. We got three reviews in since the last episode, so we really appreciate that. Wanted to give a shout out to Ferngi001, Matt Shea, and Balzac D. Really

appreciate it. You guys are awesome. Also, really exciting news this week. The.NET Core CLR is now open source and on GitHub. So, this is a big step. We knew it was coming, but it's still exciting to see, and I think it's interesting that it's on GitHub. But my favorite

part of this, actually, someone pointed out on Reddit, is there's an actual single class for the garbage compiler, and there's actually a lot of classes for it, but there's one big one that's kind of hard to miss called gc.cpp. And if you look at this file, it's thousands of lines long. Actually, if you browse to it

in GitHub, it's got a message there saying this file has been truncated. Click here to get the full view. So if you ever want to know how a garbage compiler works, you can just go take a look at gc.cpp. Nice. Another thing that happened is in the past couple weeks, we ended up going

to, actually, myself and Outlaw went to an ECMA 6 meetup. Where they call me out. Well, you were supposed to go, but you had important things to do, apparently. But yeah, they were talking about all the new features that will be coming out in ECMA 6, God knows when. But it was pretty interesting stuff. What was your favorite feature? I like Promises a lot, but, I mean, a lot of the things that I already like are available in a number of other libraries already.

This just kind of boils or bakes it into browsers so that you don't have to have all these additional libraries. I'm a big fan of Promises, but there were some other cool things. We've got classes. We've got some new operators, things like that. Yeah, I was really looking forward to in 15 years from now, all the browsers will support it, so I'll be able to use these features in 15 years.

15, dream on. Yeah, exactly. Oh, and it's worth noting, didn't they skip five? No, they skipped one of them. Was it four? Yeah, it was four. They skipped four. Version four. Yeah, so, I mean, they're having a hard time getting all these together. But, yeah, it was a really interesting meetup.

And there was also, while he doesn't want us to reveal him yet, there was a guy there that did a presentation on some UI testing framework that he put together that's pretty outstanding. So hopefully he'll have it. I can't wait until we can talk about it. I know. It was actually one of the better, one of the coolest things I've seen in a presentation in a long, long time. It was pretty amazing stuff. So hopefully here in the near future, he will give us his blessings

so that we can speak about it on the podcast. Way to tease it. Yeah, are you guys just messing with me or what? No, it was quite awesome. I wish he didn't mind us talking about it because I really wanted to. I was really looking forward to it. Yeah, maybe the next episode,

I'll get in touch with him and see what we can do. Maybe he's changed his mind. Yeah, maybe. Have you changed your mind yet? Isn't there a preprocessor for JavaScript 6 so you can kind of do some of this stuff today and it just compiles it down to JavaScript 5? Yeah, there was a Google project, right?

Well, there was the transpiler that you can use for that. Like 6 to 5 or something like that. We'll have a link to it. Yeah, the one thing that they did say about that, though, was it doesn't make pretty code by any stretch of the imagination. He said it's one of those things that you don't really want to have to support what's been transpiled, but it is there. Yeah, and so we also tried an AngularJS meetup, and I don't know why.

I'm giving up on the Angular meetups. If only someone would do a good Angular presentation. Maybe it's just me. I'm done. No, I don't know. I mean, it seems like the ones that we've gone to, the people that have done the presentations, they've been really keen on it, right?

You can tell that they're really passionate about it, yes it just doesn't come across well for some reason i don't they are super excited about it they love the topic you could tell that they know it inside and out but the presentation trying to explain it to somebody else is just not there for me. Yeah. So. That's unfortunate. Yeah. Next thing, though. What about resolutions?

On that note, yeah. How are you guys' New Year's resolutions going? All right. So I'll start seeing how we just kind of led with that. I actually started putting together like a little presentation that I'm going to potentially try and do at a meetup here in the near future. That is AngularJS. Great. Now I'm going to have to go to this one.

Yeah. We'll see. And I'm going to have to go to this one. Yeah, we'll see. And I'm going to have to bash him. You guys will be my test omies. I'll say it right there to his face. Yeah, fair enough. Yep. So I'm working on that right now. Hopefully, I mean, so I have been working towards one of my New Year's resolutions,

and that's the only one I remember. So, yeah, that's mine. Nice. The only one you remember. so yeah that's mine nice remember so i was doing really good uh exploring functional programming until someone stole my book i left it in uh like a doctor's waiting room and i came back and it was gone i kept i kept bashing on the angular meetup hoping that i could get you to bash on javascript and apparently it failed yeah i'm doing good on all my resolutions uh i'll also try to get in touch with my ui side um and that doesn't necessarily mean html um so i've actually

been working on a little game that maybe someday possibly i can publish um i don't know i doubt it but i'm working on it very cool what about you ella where you at um yeah nowhere social's been terrible you don't seem too broken up about this um yeah no i mean like deep inside there's a lot of uh you know upset but you know what's your rank on call of duty you know it's up there but that's different that's different social right that's family time no not really because uh the way like i see so so actually actually i'm glad you mentioned it because this is a great a great way to sum up how i feel about like all the social platforms because like you take your gaming consoles like xbox for example right and on xbox live you could plug in use a microphone

headphones and listen to other people and chat chat with other people. Oh, no. I don't care to hear what you have to say, so I just don't even bother to plug it in. Because random people on the internet that I'm going to play Call of Duty with, I don't care. Like, what am I going to say? Like, oh, he's behind the air conditioning unit. Oh, no. The things that people say on there are terrible. Yeah, no.

I know. That's what I'm saying. You can't have your kids in the room, basically. I'm so horrible when it comes to any kind of digital social environment. I'm just like, whatever. Okay, so you failed on all yours. Yeah, pretty much. But don't give up on me.

Right. It's a work in progress. So, encapsulation. Let's talk about it like what is it and why does it matter it sounds like uh the process that the medicine manufacturers go through i was gonna say a pharmacy yeah you get that little stuff in those little cool pills right it's the process of making the medicine i wonder i mean there's probably people out there that don't even really know what it is, right? I mean, it's basically bundling your stuff up so that it only affects its own little scope and so that people don't have access to everything that you do, right?

I mean, simply, that's mostly what it is. Well, I make everything public anyway, so. Well, here's my question question i didn't put this in the notes because i wanted to kind of surprise you guys but why do you wear clothes because i get cold sometimes i'll tell you why i usually wear clothes so i like how he said usually when i'm interacting like wait what you know and they want to know like let's say he's getting around lunch time they want to know if i'm if i want to go to lunch they could ask me if they want to know, like, let's say it's getting around lunchtime. They want to know if I'm, if I want to go to lunch, they could ask me if I want to go to lunch or if I weren't wearing any clothes,

they could look at my stomach and figure out if it's distended or not and make some sort of judgment on a based off upon that. But I don't want that. Right. I don't want people looking at my, my bare stomach to make decisions about it without actually, you know, going through the proper channels that I prefer.

And so you guys just look still, I thought you'd be laughing. I'm so sorry. We're both just staring at it right now. Funny. You guys are imagining me naked. So, so we got a review from ball sack

uh yeah actually the analogy is pretty good i mean really what it is is what do you want people to see that they can actually interact with yeah these are the things i want you guys to interact with so keep it up here you know i'm saying eyes up top that's right um yeah it's funny because i mean there is the question couldn't you just make everything public yeah you could but that doesn't necessarily protect you and it will really just confuse people who come behind you so what does public even mean okay so so can we like maybe boil it down down into a simple definition of it's the internal representation of an object? So encapsulation is the process of hiding internal implementation of your behavior. And data.

Yeah, and data. And only exposing the behaviors and properties that you want other people to interact with. I.e. the abstraction. Sorry, my dog's barking. is that another euphemism no no entendres so when we say something is public we're talking about the things that are exposed these are the things i'm letting people who use my library know like these are the things that you're supposed to do. This is how you use my functionality. Okay. Yep. Do you disagree?

I said okay. Alan's the one that's looking at us like, Nah, I'm in full grace. I think we're all a little taken aback by the dog. We're like, are we about to get mugged? What's going on up there? Sorry, guys. So the opposite of public is private then these are things that can only be seen by the members of the class that i'm in so whereas

public is available to anyone that links by my um library private is only available to the things that can see it in that particular class yep well. Well, there goes your Adam and Eve analogy. Yeah, none of that. So what would an example be of a method that you guys would usually have a private for? An example method that I would have a private for? That's an awkward question. What's an example of a private method?

So the constructor. All right, so moving on to the next bring my boy singleton into it yeah no it's so i mean anytime you want to you don't want people to be concerned about the details of what's happening right or you have variables that that need to be set so like if you have getters and setters and all that on your class usually you back that with a private variable because you don't want people outside well auto properties in c-sharp but you want you don't want people who may be using your your library your assembly to have access to that underlying variable you want them to use your getter and setter so that if there's any special logic that's

going on behind the scenes, they don't see that. They don't need to know about it. You know, they don't need to know what your storage mechanism is. So that's why you use your private variables there. And then you've got your in-betweeners too, right? So you have protected. Okay. So what is protected?

So protected is basically Anything that is in that particular class Or is a inherited It's a subclass of it Can use and access that same variable So my children can access my protected members Correct It's like protected to the family It's like, you know, the godfather access that same variable so my children can access my protected my protected members correct it's like protected to the family it's like you know the godfather yeah only my direct siblings

no cousins okay fair enough fair enough and so in dot net that's basically anything in your assembly that is you know or not actually let me take that back that That's wrong. Anything that inherits from that, so even if it's outside that assembly, if you extend that particular class, it will have access to the protected members or struct. So that's the same in both C Sharp and Java. That's a really important point. It's kind of funny in that way in that it can talk to things outside of your assembly, whereas some of the other ones we're about to talk to can't. So even though you normally think of them as being more open,

you actually can't directly interact with them. Yeah, so going from the top down, let's just circle back. Public is the most open. Anything can do anything with it, basically, right? Then your next level down is you're protected anything that inherits from a class that has protected members those can all interact with those protected variables and then going down to the next one what we got from there well it depends on what language you're talking about so let's go with c-sharp first all right

c-sharp first and then we're talking about internal. So internal means that people, or people, you can tell how I think about code, classes inside of my assembly, so like my DLL or my EXE, those can talk to my class, but nothing outside. And there's a star on that nothing, but we'll get to that in a second. I know it's getting a little confusing, but C Sharp has this notion of internal, and Java does not. Well, kind of. And that's what is a little hairy there.

You call it out explicitly in C sharp, but in Java, you just don't put a modifier on whatever the variable or the method is. If you leave it blank, then it's assumed to be internal yeah well yeah it's not quite internal the package is a little bit different so package is basically the namespace so for c sharp we say something is internal that means anyone in the dll can access it regardless of namespace and the namespace could be totally different if you're a jerk who doesn't follow the file structure naming convention but not so with j Java. And I actually much prefer Java's package implementation here. Okay. Whoa.

Interesting take on that. Yeah. There's not many things, but that's one of them. And so now we've gone. Breaking news. So we've gone from public to protected to internal or not. Yeah, and this is the weird case we were talking about where internal, I would normally think of being much more open than protected, right?

Because anyone, you know, tons of classes can interact with my internal class as long as it's in my assembly. However, protected items actually can leak out inside of other assemblies because of this notion, you know, if you can inherit from your class, you can access those protecteds. So it's kind of interesting. Yep. And then the step down from that was the private, which we started off with earlier, which hides your implementation from anything outside your direct class. So even things that inherit from it cannot touch that private variable. That's the best one. That is the one that hides the most implementation.

So we talked about a little while ago, briefly with your analogy of wearing clothes, the whole purpose behind this entire thing is, and it's really, I mean, people who program APIs that they expose to other users through a DLL or through some sort of package for Java, those people have to be really concerned about it because you don't necessarily want to expose your implementation of code. So you're going to be a little bit more careful about whether you make something public or whether you make something protected or private, because

that's probably also how a lot of security leaks can happen as well, is letting people leak in and be able to get hold of how you do things like whether it's file storage or you know i don't know but that's the whole reason encapsulation really the the main purpose of it but then also we didn't even mention it in the show notes let's talk about global variables because that's like the entire do we have to that's like the anti-encapsulation right oh this is a javascript discussion you can do it in.net too yeah because we all probably started out that way right like when you first start writing a program you're like man i have this counter and i need everything to be able to see this counter

and and of course your easiest way is well i'm just gonna make this parent object have this property that is easy yeah yeah and so so what's bad about that anybody come on like everything like well i'm where do i start yeah i'm i mean having having like you shouldn't just have some piece of data out there that everything under the sun could access and modify well why not right right let's let's i mean i know one reason is it's completely not reusable. So you can't take this thing outside of the context of its entire application and use it with any other application. But besides that, you can't even reuse it a lot of times within your application because it's not properly scoped. And so this works great if you're doing a dead simple app. And as soon as you start trying to do anything, um, or any sort of maintenance on

the application afterwards, then you're going to quickly be eating it. Well, that's where the big problem is, is when you have a global variable, something goes wrong. Where did it go wrong from? Like everything has, has, you know, God writes to it. What messed it up? And, and how are you going to find it now? Like tracing back through this thing, you have all these methods out there that are modifying this one counter, and all of a sudden the counter gets zeroed out and you have no idea why. Yeah, you don't know where it happened. Yeah, it's really difficult. So encapsulation is not only so that you can protect the application

so that you can guarantee certain entries and exit points to it. I like that better than the security analogy you made. Well, security can be. A lot of things can happen with security. Protecting your data, but not necessarily from the security point. But guaranteeing certain entries and exits. But then also, I think probably more importantly, and I saw this on one of the Pluralsight videos that I was going through, I really like the idea that when you program and you keep encapsulation in mind you help pave a way so that the person that comes after you they have they have a really good map of what they have available to them a pit of success so it's i it's like a, right? Like this is stuff that you shouldn't worry about

over here, but these are the things that you can do. If you want to use my class, you can call, you know, read this, get this, do this, but all these like underlying implementation details, you don't need to know about that. Yeah. And for the most part, I'm, I'm working on something. I'm delivering a system, not a big collection of tools. So, you know, if I go and buy a house, I don't want a big pile of wood and screws and bolts and doorknobs. You know, I want a house with a door and windows and, you know, other things like that. And this stuff only makes sense when it's put together.

Yep. And that's actually a really good analogy. And it's much more usable. Yeah, it is. So we're still walking down this tree of uh access modifiers i didn't hear anyone talk about protected internal oh yeah i always forget about that one yeah it's like the little bastard stepchild yeah that's you can explain that one nope i don't want to

that one should be just what it sounds like right anything that inherits from it but is in the same assembly right so it kind of solves the problem of the uh the protect or from a derived class in another assembly from a derived class in another so it almost begs the question like okay well how is it different than protected so so i think i'm not a i'm i don't care to understand protected internal i think what it is is it's like internal for everything that's in that dll but if you're if something inherits from it then it's protected for that i think right if it's internal i thought yeah it's like we said it originally so the type remember can be accessed by any code in the assembly and which is like we said it originally. So the type, remember, can be accessed by any code in the assembly,

which is declared, or from a derived class in another assembly. That's what I just said. Which is what protected is. Oh, I see. So it's internal to mine or protected to yours. Right. That's what I said. So they should name it internal protected, not protected internal. Within the assembly, it's internal.

But for anything that derives from it, it's protected. I hate that. Yeah. Well, that's internal. But for anything that derives from it, it's protected. I hate that. Yeah. Well, that's what I'm saying. Going back to, I guess it was Alan's point, if you're actually taking the time to create an API, then this might be important to you. But I look at that and I'm like, yeah.

Generally, more often than not, I'm not writing classes where I need where that is where I need to worry about that. Thank you. So I like to keep it, I like to stay to the kiss principle, right? You know, just keep it simple, stupid and protected internal to me is like, you know, more complication than, than I feel is necessary sometimes. But if you think that that's bad enough, we talked about this one once before in the, uh, pour some sugar on me episode, uh, with one of the new features coming out in the C sharp six,

which is private protected. What? I don't even remember what it was anymore. I looked this up like 10 minutes ago. I don't remember. So, uh, it's only the derived types within the current assembly

i've you know i that that's another one that i feel like like if you go and google that they're like one of the top results was uh it's an abomination yeah this is the one i kind of feel like that that's true because going back to my kiss principle of like keeping it simple this is another one of the scenarios where it's like okay here's here's some additional complication that maybe if you're like you know if you're writing the dot net you know uh framework then maybe this is an important one to you but i'm going to venture to say that for like 99 of the applications out there you're not going to care right and and this is actually the one that i thought we were talking about earlier but the name is so confusing where it's basically it's only protected for things that are in your assembly, which is weird because it doesn't even have the internal word in there.

So it's just a weird one. Don't use this, guys. All right. So what about... It's private elsewhere. So if you inherit from it, but you're not in the assembly, then it's private to you. But if you're inside of that assembly and you inherit from that class, then it's protected and you have access to it. So both of these are like just...

And even internal protected is more, it's less restrictive than internal. Right. It's very strange. Don't use any of these. Yeah. I mean, really, the main ones that you want to be concerned with are your public, your protected, your internal or blank for Java, and your private. So blank? Man, I can't write... Just type or blank for Java, and you're private. So blank? Man, I can't write.

I'm going to write some blank Java. Fill in the blank. Hey, but we have one more modifier keyword. Actually, two if we want to count. Are we filling the blank now? Is this what we're doing? Can you fill in the blank? The modifier keywords? Yes. Sealed. I know Joe is a big fan of this

because he's bitten me with this a few times in the past. Yeah, so I'm a fan of sealed only because some smart people told me that I should be. So I'm going to have a hard time explaining why you should do this. But basically it boils down to, got a great quote from Josh Block here who said, you should design for inheritance or prohibit it. And what I think he meant there is basically, if you are intending for your object to be a parent class and for it to have many children that do interesting things,

then awesome. And document it and do it that way. Set up some template methods and awesome. However, if you're not planning on doing that, then why aren't you sailing it? And the idea there is that you may want to change this class. You might want to do things different internally. And if you're not locking this stuff down, then people might come to rely on it when they shouldn't.

And it's basically just an example of encapsulation. So is it another way of saying that this class can't be trusted because I might not be done with it? Well, not necessarily trusted, but it's like... Not even that I may not be done with it. It's just like... You just can't inherit from it. Yeah, you guys can deal with my public interface, but I don't want you overriding and doing weird things with it because it's not really intended for that.

I got a better example for the use of sealed. I'm going to bring it back to my boy Singleton. Oh... It doesn't really make sense to inherit a Singleton right no there can only be the one so singletons should be sealed yeah basically if it's a leaf note of some sort it should be sealed that i mean if you don't ever plan on anything ever being a child of yours seal it be done with it sounds like a guns and roses song it might be oh yeah so this is another one of those things that were that like aside from the the singleton uh you know use for it though like more often than not like maybe i'm just i kind of view it as like being egotistical because i'm not like yeah no one will ever need this class is perfect

the way it is i'm sealing it you can't touch it well i just imagine like it feels very egotistical i've got a class and it's got a like a we'll say a protected method uh protected array right and i've got a couple children that interact with it and maybe why would you make anything protected if you're going to seal it well no because i have children right so i've got children that i want to be able to use and um so you know i can't seal it but i can seal those children and what this does is it prevents people from outside the assembly from inheriting from this public class or you know i'm saying but they can they can inherit from that base that the children all inherit from uh if it's if it's public i'm saying you can make the children public but the the parent internal. Oh, I see.

So what it does is it prevents people from extending that and then doing something based on this protected array, and the next version comes out and I've switched to a list, not really thinking about it because my code compiles and it should be fine, and now it's going to be breaking these third-party DLLs and interacting with it.

And just to be clear, in Java, the equivalent is final so if if you're in that realm then these same type rules apply so um that's that's all the the nuts and bolts basically did one want to mention that star that we mentioned so there is one big caveat to that internal and that is friendly assemblies so dot net gives you the ability to say you know internal only people from this assembly can talk to my internals but i also like that guy but yeah i'm friends with this guy we're cool so it can also access my internals it's kind of like okay only people that live in my house can watch my tv and change my tv but you know My neighbor over there, we're really good friends.

So if he wants to walk on over here and change my channel, he's more than welcome to do it. So this is a little weird, but my favorite example of this is basically testing. And there's a whole big argument there about whether or not you should be testing, you know, unit testing internals because it doesn't really make sense. But sometimes it's really easy to test internals. So what you do is basically like, if you've got some sort of method that talks to a database or something, you might

write a function that takes extra arguments that kind of allow you to kind of skip that database step in order to test something. And you keep it internal so that no one else outside sees it. And you're friendly with your test framework. So it lets you get around some of those dependencies. And at that point, you're basically cheating. And so there's this whole big argument around that. But it's useful. And I don't recommend it, but I do it. So that's that. There was another interesting scenario that came up with friendly.

But I can't remember what it is now. Maybe it'll come to me in a minute. So moving along those lines with encapsulation, and maybe I'll remember what he was thinking about, there was a thing called the command query separation that was in that same Pluralsight video, which I found really interesting. So going back to the point that I made about encapsulation

is also so that programmers that come later or people that are going to use the code that you've written, whether it's in an API or they're going to be in your code base later, they should be able to look at your method signatures and know roughly what it does without having to read through the code. Because we've all done it, right? Like you get into somebody else's code, you see this method signature, and you're like, okay, what in the world is it doing? Like it'll say that it's returning out a string and you're like, well, what string am I getting back from this thing? And then you end up reading out through the code. Well, if it's only 30 lines of code, maybe you figure it out pretty quick.

If it's 200 lines of code, you're going through all these if else's, you have no idea what's coming out of that. So the whole idea behind this command query separation is commands have a void return type and they're mutators. They're modifying your application in some way. So your class are setting some variables or changing something. They're mutators. If it's a query, then it has a return type and your method signature should tell you enough about what you're going to get back from this thing. So if it's something like get file name, you know, then you know that you're getting a file name, right? Like your, your naming of that method should give it to you. And

because it has a return type of a string, you know that you're getting the name of a file back so it was a really interesting concept in that the way that this guy put it is you know for programmers that suck they'll be able to work with it well and that's and then it's harsh he did he was harsh but then he said but hold on let's let's just let's take it he said not necessarily that they suck but that they're ignorant to what was really going on there. You want to make this easy for people. When they come in, you want to be able to look at it and see what happens. So the interesting thing about that, and I guess having worked in JavaScript for a long time and dealing with a lot of these things, typically when you call something, you get something back almost every single time, right?

Whether it's a DOM element or whether it's some object or whatever you could be calling set something and you're still in yeah you'll get something back right even if it seems like it's completely garbage but there's something really elegant about if you follow this and and it's definitely a a design choice that you have to make up front and people have to follow it. Otherwise it doesn't mean anything, right? Like if half the time they use this where they're using void and then the other half of the time they don't, well then nobody will be able to look at it and figure it out either because they're going to be like, did they do it this time or did they not?

Right. So it seems more like just a good practice more than anything to do specifically with encapsulation. No, but that's the whole thing. It seems like a good, a good, like a good pattern to follow. It is a good pattern, but it embraces encapsulation, like the whole idea behind it,

because you're only exposing methods that people can work with. You're hiding all the internal implementation, but when you do this now, you name your things, and you have return types that are consistent. But we're talking about the abstraction. It is the abstraction, but otherwise it wouldn't even matter because everything would be public and then you'd have no idea either, right? So this is a good practice on top of encapsulation because if you made everything public, you would have no idea what you needed to do, right? So let's say that to read something from the file system, you know that you need to get a handle

on a file, you know that you need to open a handle on a file you know that you need to open a stream you need to do all this kind of stuff right well let's say that in your one main call that you do you pass in a file name and it knows to go get the the handle on the file and go do all this stuff right well the way that you might do that through encapsulation is you might have some private methods out there that would go go get the file stream for you and they would do these other things well if you made all those public you wouldn't necessarily know in what order you needed to go do that stuff. Oh, yeah, you'd type the period and it'd be like a list of 50 things. You're like, oh, my God, I just want to open a file. Right.

So that's the whole point. What he was getting at is, so encapsulation is the technical pieces we talked about previously with the privates, the publics, all that. But that's not even all that important if you don't make your your programming easily readable from other programmers who follow yeah i get it and i like it i'm not arguing with that and it is a good practice what percentage of code do you think is null checking like why aren't there good studies on this stuff like i really wonder like there was because we talked about the six billion dollar problem i thought they'd already like oh yeah know... Oh, yeah, but I haven't seen like...

You know, quantified it. I would like to see a percentage by language of how much, you know, how many lines are wasted. How many, you know, how much time is my eyeball spinning looking at null checks? Well, if you're doing aspect-oriented programming, it could be a lot less.

It's true. There are ways around this, I guess. You have your aspects do the null checking for you. Man, that seems like a... Well, I guess if it's aspects to the null checking for you man that seems like it well I guess if you're if it's like doing aisle weaving yeah but that's yeah that's kind of weird yeah anything that reduces code I guess would do that right yeah but so going into that one of the things with this command query separation that that kind of came out of there was one of the problems is like if you get a string back is it null or is it not like you have to do

all this null checking because that was another thing like a lot of people would look at a method they see that hey it returns a string string dot is null or empty oh god all over the place yeah everywhere string dot is null or white space why didn't they make it the same command why is this why are they separate man it's so crazy and we've all done this right like we see a method we're like okay i need that method it's returning back a string you start using it all of a sudden it blows up on you because it got a null and you're like oh come on man i didn't i didn't know this and so one of the things that he that he ran through that i thought was brilliant and i'd never really even spent that much time thinking about before was

the way that you typically about before was the way that you typically do it is the way that we just said you started using a method it broke on you and then the next what do you do next if this is null do this if it's not null do this right bug fixed yeah exactly and then you move on and then now you have that everywhere in all your classes in all your files like I wonder why that was null oh well yep so moving on um sweep it under the rug so then it looks like you know microsoft and i don't know maybe java they did something like this they did what was called the try read or the try parse type thing and you've seen it right like int dot try parse and basically you have an out variable that

will try and set that variable and that way it avoids this null stuff. You know, if it was null or if it can't be converted, then it's just going to give you some sort of default value. If it's integer, it might be zero, you know. And so that's kind of an ugly way of doing it. You have to set up your variables beforehand. It's not really pretty. In C Sharp 5, you have to set them up ahead of time.

C Sharp 6 got that nice syntax for declaring the variable inside that method so we're just hiding more yeah yeah oh yeah still doing all the same work just gets it down from two lines to one so there was this thing that this guy brought up that I thought was just brilliant and whether or not

I don't know I might actually start using this because it was really sweet so instead of doing this he said let's go about this the object-oriented way. And let's do a maybe of T. And for those of you who don't know what of T is, that's basically type. Well, we're talking about generics. Generics in.NET. And I know Java has generics as well.

I don't know how their syntax is. Well, generics is old. I mean know how their um their syntax is well generics is old i mean it's predates c sharp but i don't know what their syntax is is what i'm saying okay so like in in dot net you'd have you know maybe um less than capital t greater than that's just kind of the standard way of going about it but then what they were saying is if you do a maybe of t then you could say hey the return type is going to be maybe of string we'll say and then what they were saying is if you do a maybe of T, then you could say, hey, the return type is going to be maybe of string, we'll say. And then what you have is an implementation that when you call this method, instead of it returning a null, if it doesn't have the string to give you back, it will return you an empty list of string. And so when you say maybe of T, you'll either get back an empty list of string or you'll get back a list that has one string in it

and then what you can do in dot net which i just thought was gorgeous is you could basically say all right call that method dot default if empty and then you can pass in what you want that default to be if it didn't have a value and thensingle. And then that way it returns you one result every time. It's guaranteed to be not null. You can default it to what you want it to be. And now you have a nice OO approach to not having to deal with nulls anymore. Yeah, it sounds like the null object pattern that we talked about a couple episodes back. Well, why not just do single or default?

You might be able to. Doesn't single to default return the default for that type, not necessarily the default that you specify? That's a good question. Everybody gets to check the manuals. But it was a really cool way of thinking about it instead of fighting all these

nulls that happen. If everybody decided to take that pattern and use when they're creating their own methods instead of having you know uh you know uh string my file name and then method you'd have maybe of string you know get file method and then that way you're always guaranteed that you get back something that won't be broken, which is just gorgeous. And you can always make a method that basically does that, you know, a single or default that takes an additional parameter. Do the extension method and add usings all over your code.

And there you go. So really cool stuff. We'll have a link in the references to that as well in the show notes. But it was a really neat take on it. Sorry, I got caught on there. I think it's the same deal where it returns the default for that type, which is null for reference types, and it could be a zero or a false or whatever.

You're right. So a really cool thing. We might even put a little snippet up on the show notes so you see what we're talking about. It was pretty cool. Where did you find that? Was that the Pluralsight video? It was on the show notes so you see what we're talking about. It was pretty cool. Where did you find that? Was that the Pluralsight video? It was on the Pluralsight video.

It was actually in – I'm surprised we didn't hit this before. It was in Solid and Encapsulation, I believe was the name of the course. So, again, we'll have the link down there. It was pretty excellent. I was playing Call of Duty while I was watching that video. You missed a little bit. Speaking of calling. So if you are a fan of the show, we would totally appreciate if you haven't already. Go on iTunes or Stitcher or wherever you prefer to download your podcast.

Leave us a review, a rating. We greatly appreciate it. And tell a friend or three. Share the show with them. Let them know. Maybe they might get something from it too and find some value in it too so or you know it gives you guys something to discuss like you know how much we don't know uh you know when you're at lunch and to make it easy on you we've actually created a link that you could go to instead of having to go into itunes and search for us or wherever just go to www.codingblocks.net slash review and that will give you the option to be able to click something if you want to go to itunes fine if you want to go to stitcher hey if there's another uh podcast

directory that comes up in the future it'll go there too so um just go to www.codingblocks.net slash review that's a great idea. So, all right, moving on. So, the most important thing is encapsulation in JavaScript because we're all

JavaScript monkeys now. Oh, wait, what? So, let's talk about this. So, anybody want to start?

No, because it's JavaScript. So, I wanted to recap real quick. So C Sharp, Java, most kind of sane languages have this notion of things like public, protected. Compiling. Internal.

Private. And so these really fine-grained controls. But JavaScript doesn't have that, right? In fact, everything is global by default. So it's very, very public. And there's some ways you can get around that. I'm not going to say hacks because it's... For all the singleton haters, there's a lot of JavaScript singletons.

There are. And so, yeah, I lost my place because I scrolled the notes. But basically the idea is that there are ways to work around it, and we're going to talk about some of those ways right now. Okay, but first, I've got to call you out. Didn't you say you were getting ready to pick up a Ruby? You just said something about compilers you know i don't believe that's a part of that universe there's a there's a good time for a scripty language every now and then you know and ruby does have uh you know a pearl my my my bash scripts you know what's wrong with ruby why

i got dog on ruby i was just saying, you compile. So anyways. Ruby does have accessibility types. So it doesn't have semicolons though. Optional semicolons. Right, yeah. Digress. All right, so.

The greatest hide and go seek player ever. The semicolon. So let's talk about JavaScript encapsulation. And probably the most important keyword in JavaScript is var. If you don't use var in front of your variable, no matter where you put it, it is basically global at that point in time. That's terrible for JavaScript because, first of all, no one's ever using a single JavaScript library.

There's always like 10 in any single website. And so if none of these guys use VAR, they'd all be clobbering each other. Yeah, and it's... That's why I always prefix my variables with JZ. The JZ library. But it sounds like an awesome moron to talk about encapsulation in JavaScript because

when you talk about encapsulation, you think like classes. Right? I mean, at least I do. Or you think about hiding. It's not necessarily classes. Yeah, I was going to say, you got namespaces, you got variables, you got all kinds of stuff. JavaScript doesn't have namespaces. Even Objective-C doesn't have proper namespaces, right? That's why everything's like

NSString and crap. Emphasis on the crap. so the way that you do this i'm pretty sure that somebody should make a type caught in a stringing crap so the way you do this in javascript there's actually a few different ways and and obviously it's a pretty vast language as far as how they do things to get around certain things so we're going to talk about a few of these. First, it uses prototypical inheritance. So if you want to create some sort of like class instantiator, like you can in a true OO language like Java or C sharp, you can basically create a function and let's call it person, right? Function person, you pass in first name and last name. Inside that function, you can have this dot first name equal whatever you passed in and this

dot last name equal whatever you passed in. At that point, you actually have encapsulation. You have member variables if you knew it up. So after you define that, you can basically say var outlaw equal new person pass in in Michael, and then outlaw. And now you have this person object that has its own member variables. So it has encapsulation. Kind of. It's kind of an accident, though. It's not a private variable.

Well, I mean, the fact that you just started off with the same prototypical inheritance. It's accidentally unreachable. Well, no, it is reachable. And that's actually where I was going to say it's kind of encapsulation because... Yeah, because it's fully reachable. Everything is. No, it's not,

and that's where things get a little bit different. You know, watch me. I'm going to pop over the developer tools. I'll take the object. I'm just going to overwrite it in my console. Yeah. No, so you can in some of that. I'll just change the prototype.

But that's where you can do some crazy stuff using closures in JavaScript. So when you new up that object, instead of doing what I just said, where you set this.firstname equal whatever you pass in this.lastname, you can have a var in there, right? Or you could just use those. Now what you do is you create these internal methods inside that. So inside your person thing, you're going to say get first

name, right? This dot get first name equal function and then you're going to return a variable that was pointing to first name up there. And because it's a closure Now we're dealing with function pointers all the time. I mean, this is... This is what you got to do to get privacy in JavaScript.

And that's my point. It feels like JavaScript like there's so many ways it feels like javascript like there's so many ways in which we went we took a step backwards in order to go forwards but it's different right it's prototypical inheritance as opposed to classical inheritance in in a regular language so you get the good with the bad it is until ecma 6 and then they're bringing in classes so yeah that's that's gonna be and then they're bringing in classes. So, yeah, that's going to be interesting. And then you have both prototypical inheritance and classical inheritance, and that'll be a lot of fun.

Then you'll just go to TypeScript, right, and say, screw it all. Or CoffeeScript. But that doesn't have types, right? Not static, not static types. All right, so anyways, so you can get around that by doing closures inside of objects or methods or whatever. And all a closure really says is if you define a variable, so let's say inside that person thing, you define a variable using var, right? Then you have a method that's defined down below it, like get name, right? Inside there, you can reference that first name var, even though it

was never defined inside that other method. And that's what a closure does. An internal method has access to variables that were defined at the same scope level that it is, or maybe even further up the chain. I'd have to check on that, but that's how you can hide variables so instead of setting a this dot property you now have you know access to these variables that you can never look at in chrome like you can't go to the chrome inspector tools and see these variables anymore they don't exist so here's here's here's what you want to do if you want to learn a program right so you pick a language like maybe you pick c or c plus plus or java or c or C Sharp. All right, fair enough. And then you learn a lot of good practices.

You learn a lot of good techniques, right? There's a lot of good in all of those languages that you will learn, right? And I say those languages just because those are kind of the big four, right? Then you move over to JavaScript, and you're going to throw all of that out the window because everything is messed up when it comes to JavaScript. Right? Like it's like, oh, no, no, no. It's totally different. Yeah. No. Just because you didn't declare it and you're in here in this scope. Yeah. But you could totally get to it. And, you know,

I know that, like, I don't want you to access this, but technically you can. Yep. And so it's really hard for JavaScript programmers to wear clothes. We've come full circle. Hey, we laughed.

So, yeah, it was good. But here's the, here's the thing though, right? Well, you're,

you're playing the long play there. There's a reason why people, why JavaScript is blowing up though you have node you have all these things out there now it's easy right yeah it's actually surprising i like okay i find it surprising that it's as popular as it is considering how different but yeah like you said i mean you you can you can break the rules and go against the norms you know just because yeah i can't it's fairly easy and not necessarily, you're going to do it in a great way, but you can make things work.

That's why you have to have a book called JavaScript, the good parts, because there's like all these bad things that you could do. Uh, when's the last time you did equal, equal, equal null in JavaScript? It's if objects, whatever. Yeah. You do iffy oh my truthy all right oh okay so so moving on to the next part i think actually the last part on javascript with with what we're talking about as far as encapsulation is you should avoid global variables and there's plenty of reasons out there just just major reasons because anything that you want to name that global variable, there's already a JavaScript framework that's using that name

that's going to overwrite what you wanted to pick. Precisely. So let's take jQuery, for example. They decided they were going to take the dollar sign, right? Well, so has every other framework on the planet. So if you mix the two, then basically you've got all kinds of collisions. Things are overriding each other

and you would say well how else would you do it i mean i gotta have it there somewhere well the way that you go jQuery dot that's how you should do it with jQuery like if you're going to have a framework too they have a compatibility mode but there's these things called ifs i i f e's and there's other names for them too and i can't remember what they are but all it is is an immediately invoked function expression. And essentially what you do is you wrap a function in parentheses, and then you immediately execute it at the very end. So it's like an anonymous function that you execute right now.

That's exactly what it is. And it has no scope. So it's inside of your parentheses you declare the function, and then outside of that closing parentheses, you then have an immediate opening and closing parentheses and a semicolon so that you execute what was in the first set of parentheses. That's correct. I don't even know that you need the parentheses.

I think you can do it right after the curly braces. I don't recommend it. I don't think you can. I don't think you can. But either which way, that basically sets it up to where now you can execute this JavaScript that has no particular scope. There's no variable existing around. Now, I don't know how you would do something like that with jQuery because you need to call that framework all the time to do things. But let's say that you have form validation on the page. The old school way of

doing it was you would say function validate form and then have your implementation. Well, if you have some other file that's including a JavaScript that has that same thing in there, you just blew away that validation thing. So instead of doing that, you would have this iffy function that would attach itself to the form and then maybe say on submit then run this particular function that would be inside of closure essentially and now you have no global conflict with a name so it's encapsulation in javascript is easier but at the same time it is so counterintuitive for people that are used to a traditional OO type background. And most people don't do it.

Yeah, I would agree with that. Like you see global variables everywhere. Or if you miss a variable, oh dear God. Work in a big framework, like I don't know, tons of them, and forget to var something, whether it's Angular or EXTJS or something like that. Forget to var something and see if it just doesn't jack up your entire day. Yeah. Man, I had something today where I copied a line from one place

and pasted it somewhere else, which is already a bad sign. But I didn't realize that I was missing a variable that it was expecting. And it still worked somehow. I'm like, what? What was it? But it turned out it was because the variable I named was called window, which is built into JavaScript. It's a global.

Yep. And so it was doing stuff to my window, and it kind of worked, so whatever. And that's the thing. I guess that's the one thing about JavaScript that really is frustrating is a lot of times it'll continue to do something. It's just not what you think it should be doing, right? And you don't usually find out about it until much later and you're like oh that's actually a really big problem so i feel like the c-sharp compiler is like hey can't do that can't do that can't do that

and javascript it's more of like the apologize later what's like hey what'd you expect yeah so i mean while we talk about javascript it can't help but make me want to bash on ie for a moment oh but then but then i'm trying i'm really trying not to so then i was like well okay so there is the new uh spartan new spartan version coming out so maybe maybe it'll be okay yeah just yesterday i, man, why aren't there more browsers? It's like Opera kind of died out a little bit, man. We need to spice it up. Man, Safari is right up there. Dude, I don't know, though.

I will say this. I used to have a real love relationship with Chrome. I get that off-snap display way i mean what i can deal with a total tangent and i'm sorry but when did chrome start sucking it is definitely like as soon as it started winning yeah maybe it's definitely gotten bad yeah i have a lot of problems with it myself you know you know there's something wrong when your browser has to have its own task manager that's not a good sign yeah yeah i mean i i see that all snap window i don't know how many times a day and it's like really come on but i still love it for for debugging though firefox with uh firebug doesn't hold outstanding compared, it depends on what you're doing.

There's some stuff that's nicer, but Firefox is so much slower. Man, try and open up your Gmail in Firefox. Firefox has a much smaller footprint. Try and open up Gmail in Firefox. In Firefox, speaking of ECMA 6 is ahead. It is. It's beating everybody, which was interesting. So in the standards compliance department, they're leading the pack. Yeah, if they would just do better with their speed.

Smaller memory footprint. Slower performance. And they're not backed by an advertising company. Which is nice, actually. That's one of the reasons why I use it. Yep. So we do have one more section I wanted to talk about. And this kind of refers back to an older episode that we had where we talked a little bit about dependency injection and inversion of control.

And we want to talk about how that conflicts with everything we just talked about, encapsulation. injection is that you have, um, you, you're kind of getting away from things like constructors and, um, you know, even, uh, like internal variables and, um, I may have said the right word anyway, you and you're, what you're doing is you're exposing properties for your dependencies and then something else comes along and kind of fills those dependencies. And what that means in practice is that you end up having classes that have properties for things that you require. And that means that when you initialize that object, you've got to know to set those properties or else things aren't going to work right. And so literally what I just defined there, I'm saying that someone else needs to know enough about your internal state to know what's required for you to function properly. Which is completely anti the whole point of encapsulation.

And so we've got some interesting links on about that, including one where it's a Stack Overflow question where the man, Eric Lipper himself, does a pretty big smack-dizzle in just a few sentences. And so I actually wanted to bring up the article here because he he starts out saying that basically di is a bad idea and it just goes on from there which is a pretty big smackdown for something that's kind of you know so hot right now so what do you guys think about that which part part of it? The DI smackdown?

Either one. I know when I'm doing stuff with dependency injection or if I'm even programming in a way where I'm kind of manually inserting those dependencies, that it feels a little dirty. I'm creating properties for things like file systems or databases or whatever, and my caller is responsible for filling those in. And it's totally the opposite of something like a singleton or something that knows how to kind of take care of itself. I'm basically putting this class's life and functionality in the hands of someone else. Yeah, that's pretty interesting. I mean, it's a good point. Yeah, so you ever knew up a class and you try to use it and it's like, oh, it blew up, didn't have something.

You're like, oh, I guess I need to set this property. And you try it again and it blows up and you're like, I guess I need to set this property and you try it again and it blows up like yes i need to set this property too you don't have any insight as to what's happening inside that method but it's relying on these things to be there that just aren't there yeah not going too far down the dependency injection hole the one thing that i do find that is somewhat for me because i like performance i've always been a fan of performance you have to have nude up objects of everything if you're doing dependency injection it news it up if it doesn't use it or not it's still creating it and so you have space on the on the heap already being used up even if it's never going to be touched that's a different argument from what we're talking about

with encapsulation but it's i think what you just said is it's definitely something that would give you pause to using it is now the user has full control as opposed to the person who developed the particular you know method or class or whatever yeah so usually it would take care of something like that so if i wasn't working with di i would basically have a constructor that took in the arguments that I needed to, to make sure everything is good. And so it's pretty obvious, you know, what I need to do my job. But if those things are just public properties, you know, they appear to be optional and, uh, yeah, that's a problem. It's, you know, pretty much the opposite of encapsulation. Looks like I'll be doing some reading. It's like you're having your organs on the outside of your

body. Huh? Yeah. Every yeah every time you know whenever it gets into the differences between dependency injection and inversion of control though there's a bit of a mind melt there because there there's some similarities in like principle but they serve different tasks and they they do different things and in some ways you could think of the inversion of control as uh uh maybe kind of is do you think it'd be considered similar to like the template pattern that we talked about like with the uh the hollywood principle it's kind of like that yeah i mean yeah there's there's definitely uh yeah like i said every time whenever we get into those topics, I always have to go back and read another book on it.

And somebody's dissertation out of college on the values of it. And how Fowler and Martin came up with it. What was that conversation like where they're like, hey, listen, man. I got this idea I've been working on. What was that conversation like where they're like, hey, listen, man. I got this idea I've been working on. What was that conversation like? The guy is way over my head. Anyway, so I just wanted to bring that up. Yeah, thanks.

I feel like an idiot now. More reading to do. One more thing I've got to study. All right, so now it is actually time to get into the tips of the week wait we're gonna skip over the resources oh wait oh yeah that's that's totally wrong let's go to the other one so the resource so the first one i mentioned was the uh the plural site it's a encapsulation with solid by mark c man we'll have links to all these in the show notes yep also i want to mention the book CLR via C Sharp Edition,

which is where I first read about internal seals. And it's got a great section on encapsulation and all the different flavors. Yep. And then there was one other one on Mozilla, which they've got a really good developer section, and this is on inheritance for JavaScript. That's what you get for dogging on Firefox. Now you're going to have to.

I use Firefox. It's just slow compared to Chrome firefox now you're gonna have to i use firefox this is slow compared to chrome now you're gonna have to give up some love for mozilla with a firefox link hey man i use firefox too let's just go rust i mean rust rocks yeah i wonder how many people out there even know what you're talking about if you hang out on hackanoo's long enough you're gonna get a complex and think that everyone's working with this sort of stuff when they're not and then i think uh jay-z yeah i meant to put this in the notes so are in the news i want to say thanks for the linkedin invites we mentioned that on the last show and we actually got some uh invites so it's really cool so uh yeah hit us up

and we will totally endorse you yeah if you go wow. We get a little Ponzi scheme going on here, you know what I'm saying? Like, you friend me, I friend you, we endorse. You know, everyone wins. Yeah, actually, if you go to www.codingblocks.net slash about, though, you'll have links to all our LinkedIn's there. Oh, Jesus. If you do want to friend us, there's the way. And you can force Outlaw to be social.

I'm pretty sure that's a bad idea i don't think that's what i feel like i just broke the law or something i think you did the linkedin police are coming for you i'm feeling kind of dirty right now yeah all right so let's get into the tips of the week so here's a neat little uh site that i found that i happened to stumble upon called can i use dot com now i don't know what you're thinking but this is related to code okay so let's say we didn't find out lost on the side of the street with the needle hanging out of his heart. I guess he can use. So let's say it's a great site,

great resource to put in your toolbox there. So if you want to, it could be a JavaScript function and you want to say like, hey, which browsers support this function, right? Or this API. So like maybe like a file API. And you can see, well, not in IE eight or nine, but everything else is pretty much green except for opera mini, right? And Android kind of gets a little fuzzy, right? Like maybe it's partially supported. So, um, you know, that's

an example. There's HTML five, there's CSS, there's SVG. There's a whole slew of different things that you could use this for to find out, like, hey, does this whatever feature work across all the browsers? Can I use dot com? Very nice. You have to provide your own needles, though. Awesome. So I wanted to call out a library. I mentioned that I was making a little game for fun. And the library I'm using that totally got me past all the crap I was wrestling with forever is RogueSharp. It's an MIT-licensed C-sharp library. And there's a really awesome tutorial that will basically get you up and running with a little game that is very similar to the old ASCII game Rogue. So you should check it out.

Yeah, we actually saw it running. It's for real. Yeah. All right, so tip and this this oh so i got another tip here so no i'm kidding go ahead hey wait is that because i did that last time no i'm not gonna steal your tip i was just joking whatever all right so uh this is all because my mac really hated me recently. I tried to run boot camp. If you ever go into your add, remove programs in Windows and you click on a program to remove it and there is no uninstall button, all you have is change or repair

and you really want to uninstall it, you can do it. But you have to go into your registry because apparently that's where all this is controlled. So you can go to a particular key and then go down into the registry. High key local user? It's H key local machine, but I'll actually have a link to it. But you can literally, if there is something that you want to get off your machine because you need it off your machine, there's a way to do it.

And it's through a registry update. And it's very simple fairly safe and i will just imagine you're like oh god my boss is gonna see this dude i i had to get boot camp the boot camp drivers that were on there were old and wrong and not working and it would not let me uninstall them and so i was able to get in there change the registry key uninstall it put the new ones on life was dandy so anytime the tip of the week involves reg edit i'm pretty sure it felt so good you're doing it wrong it felt so good so that's show summary. So, uh...

Reading off the notes here. It's late. I was thinking about something awesome I'm not going to tell you about. Take that. So, this week we talked... What kind of tease is that? We talked about encapsulation, different types in different languages, C-Sharp, Java, JavaScript. And we also talked about different issues between some static between

encapsulation and DI. Dependency injection. So I hope you got something out of it. And let us know what you think. Yeah, and so with that, like we've said before, subscribe to us on iTunes and Stitcher. Be sure to leave us a review. You could use

your favorite podcast app, iTunes or Stitcher or wherever you prefer to get your content. And as Alan mentioned before, he's made a friendly little place for you to go to codingblocks.net slash review. However, I do have a question about that, though, because that 404'd for me. Are you sure that's the right URL? You're not supposed to do that.

I'm going to have it ready by the time this podcast comes out. Yeah, because thatl is the most awesome url it'll return back the best 200 you've ever had and we all know the 200s saying you're going to do something on the podcast is the best way to ensure that it gets done this is totally like he's up off me so so i've actually dot net slash link alan's way hey i've already created the page i just haven't created the uh the pretty link or whatever to it so so yeah slash review thanks codingbox.net slash review that's the it's the most beautiful 200 you'll ever get absolutely all right so contact us with any

questions topics comments whatever um and you can hit us up at wow i just totally jacked that up comments at codingblocks.net comments at codingblocks.net yes all right and yeah so send us your feedback and questions and make sure to follow us on twitter at codingblocks why are you looking at me i don't know