Coding Blocks - Design Patterns Part 4 – Adapter, Facade, and Memento

Episode Date: July 26, 2015

Part 4 of our design patterns series, this time up it's Adapters, Facades, and Mementos. Oh, an which tech luminary would make the best head of state!

Thank you. CodingBlocks or Facebook at facebook.com slash CodingBlocks or head to www.codingblocks.net and you can find all our social links there at the top of the page. And with that, welcome to CodingBlocks. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. All right, and so first let's start off with a little bit of news. We'll try to keep it short.

We've gotten some feedback about that. So Alan, you want to talk to us about algorithms? Yeah, apparently I can't. Wait, to us about algorithms yeah apparently i can't wait what what do you mean you're taking a whole class for this look man so i i did the first week week and a half of videos like all in one night and and i got wrapped up in meteor react js and literally just did not get back to the algorithm thing. Maybe at some point I'll get back to it, but apparently I'm going to fail this class.

Well, I quit intentionally. After telling the internet that I was going to do it, I watched the first couple videos and decided that I didn't want to do it. Oh, it was all theory and math. But you didn't even get through the first week. Who, me? I didn't. Oh, yeah. No, and math. But you didn't even get through the first week.

Who, me? I didn't. Oh, yeah, no, Joe quit. Because it wasn't code-centric. It was literally more... What? F of g of x up to n equal to f over n equal times g of x. It was straight up math.

And he even said he did not want to do any implementation code-wise. He wanted abstract thought and being able to put these ideas into pseudocode that could be translated into any language. So it was not coding. Yeah, man, it's not fun. But I wanted to keep up with it and you know fortunately our buddy uh i am will mattis or i am i can't will he's doing it like he's following through like a champ oh really yeah so hopefully he'll give us some feedback here at the end he is a champ man he is yeah he sticks with it but like i said i i found a shiny new toy and i and ietracked. Yeah, man. You saw a squirrel and you went for it. I did.

You're like a dog. All right. So what you got outlaw? Are you going to make it through this recording or like midway through it you're going to see something? Oh, I can't guarantee anything. Well, so you guys left me in Atlanta all by myself. So, you know, I've actually like wandered out around, you know, and gone to a couple meetups. So there have been some really good meetups here in the Atlanta area, both on React.js, or at least those are the ones that I've gone to. And one of them was a first, the premier meetup for specific to react.js and then another one was just uh the

javascript meetup where the topic was react.js and they were both really good you know the first one the premiere uh react.js meetup it was focusing on unit testing your react.js and uh the other one was just more of an introduction to react.js in general but it was both good information and in the testing one um we'll have the i'll include a link to that in the show notes but there was some um interesting verbiage around unit testing that i was actually kind of curious to see like if uh you know what you guys had had what you guys had heard of it or what you thought of it. Like there was unit versus functional testing, which is okay. That's not so new.

But white box versus black box testing. Never heard of it. Yeah, white box is like when you have the source code, right? No. No? black box is like when you have the source code, right? Um, no, no, no. Well, at least not the way that, that it was defined, uh, within, within the confines of that meetup, they were defining that, um, you know, think of black box testing as synonymous with functional testing. Whereas white block white box testing was testing more the internal structures of your entire system under test.

Okay, so white box has knowledge of the internal workings, and the black box is as if you were a third party almost. Yeah, I guess that'd be a good way to put it. Okay. Yeah, I've never heard those terms for it. Yeah, I hadn't heard of it described that way either. But yeah, it was really good. Like I said, I'll include a link to the slide presentation in the show notes.

It was some good stuff. Cool. Oh, and there's another one that's coming up that ought to be really – you should be excited about this one, Alan, because coming up at the 29th of this month, there's another JavaScript one on Meteor specific to gaming. Yeah, I saw that in the show notes. I'm kind of curious about it because it doesn't seem to really fit the pattern that Meteor is. But, yeah, I mean, I'm not going to, I don't think I'll be there.

Well, that's what happens when you leave me in Atlanta. Like, I got to go find things. Yeah, I understand. You know, you guys are both down in Florida now, so. So that's kind of interesting, though, because, like I said, what kind of pulled me away from the algorithm class was I've been messing around with Meteor, JS, and React. And really, kind of what did it is I don't even remember what I was searching for one night, but I came across this article that this guy wrote about, hey, why you should use Meteor for your next project.

And I ended up watching. Like, I read all his bullet points, and I was like, wow, that's kind of cool. And he's like, watch this video if you don't believe it. And I watched this video. It might have been seven minutes. But dude, like what they did in that seven minutes blew my mind. Just coming from having done so many apps over the years, I was like, wow, this is really impressive. And so I kind of dove into it.

And the interesting part is I ended up doing it with React. I have no idea why. I think maybe I saw another blog post and I was like, you know what? If I'm going to play with one, I'll play with them both. And I've actually had a lot of fun with it. Like I've literally been staying up every night past midnight messing around with Meteor.js and React.js. And I've got thoughts on it. I don't know if we want to go into them now.

Maybe we'll do it on the next episode or something. But there's some really cool stuff to be had there. Yeah, I was definitely thinking about maybe in a future episode we talk more about it. Because specific to React.js, right? Like one of the big to-dos about it is the virtual DOM, right? And it's kind of like, well, why should i care about the virtual dom like why is that a thing right right but um so i think maybe we could cover that in a future one yeah

there's a lot of good stuff there yeah we'll do it i mean i've actually had a lot of time to play around with both of them and and was this video that blew your mind away was this like a michael bay production or something no no no a lot of cgi no nothing nothing cool right it was it was literally just hey let me show you what Meteor can do. And just walk through quickly building an application that literally had all the core pieces that you would need. It was pretty impressive. Yeah, until I see it with my own eyes, it's CGI. Along those same lines, though, one other thing I wanted to mention was with that,

anytime you start making an app, you kind of want to start off with something that can bootstrap you. Right. And that's why, uh, bootstrap is so popular. And, and there's another one out there called foundation. Well, I've always kind of rooted for the underdog. Like I've always wanted to, you know, say, oh, okay, well half the planet's using bootstrap. Let me, let me try foundation. Right, man. I got in there messing with it and it's got some nice things, but i was so disappointed at some of the things that were missing that i ended up scrapping foundation and going back to bootstrap so i don't know a little frustrating and if you haven't played with either of those things we'll have links in the uh in the show notes for them but um at any rate just just some cursory thoughts on that.

I mean, I always go with the winner. That's why I program in C Sharp. Wait, wouldn't you be in Java? Isn't that what like 90% of the world's using? I got no time for losers. Second place is the first loser. Yeah, no fear. Sorry, Java.

Just kidding. Wow. Not. All right. Anyway, reviews. So we got a couple of reviews. Sorry, Java. Just kidding. Wow. Not. All right. Anyway, reviews. So we got a couple of reviews. I'm sorry. I'm going to butcher your name probably.

First is from Aswinr, who said this is the only podcast they listen to, which is cool. But there's some other good ones that we can suggest. No, no. But that's perfectly fine. We'll take that. That's incredible. Awesome. We're the only one he listens to that's amazing yeah uh also we got one from fleckism uh which is awesome so thank you very much and oh also uh on twitter i believe it was luke warren mentioned he got his whole team of co-workers listening to the podcast which is fantastic so what up team yeah thank you very much that's awesome welcome welcome to our

our podcast yeah somebody give that guy a medal yeah no doubt high five now i told him if he to take it to the next level he needs to get all those guys to leave us reviews that would be amazing so also yeah we sent out we sent out a thing on Twitter just kind of saying, hey, we're about to do a podcast on design patterns and other. And, you know, hey, what do you guys want to hear about? And Adam actually wrote us and said that he'd like to know about, like, parsing APIs using XML or JSON, why choose them, that kind of thing. So we'll add that to the stack of things that we want to talk about. And then Andre asked about ALM, which is alerting, logging, and monitoring. And that's something that we've all had quite a bit of experience with,

and that could definitely span an episode or two. So we'll get that in the queue because I think that's something that everybody should know a little bit about. And since we're on the topic of JavaScript frameworks, or have been talking about them so far, could one of you guys do me a favor and remind me to register for ConnectJS? Yeah, I was going to ask you to remind me. But that's coming up, so if you're in the Atlanta area, or you want an excuse to travel to the Atlanta area, October 16th through the 17th uh hint hint joe yeah uh

there's some there's some pretty good stuff i mean if you if you go and look at that conference you can find it at connect-js.com yeah and there's uh big names in that it sounds like it's going to be a very interesting conference so um yeah check it And then you'll, so we started doing these surveys and, uh, you know, we've gotten some interesting results and in our last episode, you know, just as soon as we start it and we get this good path going, we forget to mention a survey. And so like I had to make one up up so since we didn't remember to mention it in the episode i thought well obviously the survey for this one is should this episode have a survey now i'm assuming that you two haven't cheated i haven't you haven't looked at it i've not looked. Not looked. So, your choices are yes or no.

75% no. 75% no. 75% yes. Okay. Well, Joe would be the winner then. Really? People like surveys. It was 72% for yes.

Wow. All right, then. Well, I guess if you rounded that, it would be closer to 73%, but whatever. If the price is right, he would have won. Showcase showdown. Come on, people. I'm just amazed that more than four people voted. No, because he went over.

He went over there, right? No, but that's the thing. You always had to. No, you had to go under. Yeah, my bad. I was wrong. Yeah, you had to stay under. He went over there, right? No, but that's the thing. You always had to. No, you had to go under. Yeah, my bad. I was wrong. Yeah, you had to stay under. He lost.

But, yeah, so I thought that was interesting. So I guess the audience likes surveys because even the episode that we forgot to have a survey should have had a survey. Which is cool. Coincidentally, it did have a survey, so it's a good thing that I put a survey on it since everyone seemed to think that it should have one. That's like 12 monkeys or Pandora's box or something. This is good. This is for science. So I feel like we've done the scientific community well by including that survey.

We have stats now. now so uh you know in other news and i i debate on whether or not this one should be a survey but i decided not to uh you know their github has their atom editor i don't know if either of you used it and then microsoft forked that and uh used it as the base basis for the visual studio code product that was discussed i don't know how long ago a couple months back and um so i've been playing with both and like kind of comparing and contrast like you know just trying to get acclimated to both and uh i wasn't sure like you know have you guys used either what's your thoughts on one versus the other or do you have any opinions on it haven't touched them i've wanted to get into both of And I wasn't sure, like, you know, have you guys used either? What's your thoughts on one versus the other? Or do you have any opinions on it?

Haven't touched them. I've wanted to get into both of them, but I don't know. I guess I'm so used to Visual Studio and Sublime that those pretty much went out. Yeah, I'm still really figuring out Sublime, which is sad. So here's the thing then. So, like, for anyone who's listening in that is a you know a fan of either i'd love to hear some of your um your take on either or both of them because if you use both like for example um there's some little nuances between them right like visual studio code has a revert file option but that option is dangerously close to the save all so every time you click on save all you almost feel like

you want to say that was close yeah that's awesome i almost didn't make it, right? So, Atom doesn't have that feature, which is good. But then there's other little nuances, too. Atom has tabbed. So, every time you open a file, you get a new tab for it, which is really cool, right? And especially if you're already coming from something like a Visual Studio or an IntelliJ. Or Sublime. Yeah. You're used to from something like a Visual Studio or an IntelliJ. Or Sublime. Yeah. Like you're used to this, right?

And I don't know why, but they took it out in code. It doesn't do that. So you only have one file? No. You can split screen your environment like you can in a Visual Studio, for example, right? You can split screen it your environment like you can in like a visual studio for example right like you you can have uh you know to split screen it and see multiples but it's so annoying because in each one of those panes you can only have one file so as soon as you click on another file well you just blew away you know you just took away whatever one you were looking at so you

can't have one two files at a time. Yeah. So, well, no, you can. You can keep splitting them off just like you can in like a Visual Studio or an IntelliJ. But they're open. They're truly open at that point, right? Like you're seeing them all at the same time as opposed to, hey, this is my list of files open and let me switch between them. Well, yeah. my list of files open and let me switch between them well yeah so like if you're like me like i'll often have multiple files open that i'm working in and i'll know that like hey you know one maybe

one piece of something that i need is going to be in this file and another part's going to be another file like and i might not be actively looking at that it might not be one of the tabs that are actively open at the time but i can i know that it's there and I can easily go back to it, right? Whereas now, working in code, you don't have that option. But what you do get is this other little workspace scenario where if you double-click the file, then it comes up into your workspace area

so that you can have a quick access to it from there. Because I should mention, too, that when you navigate files, it's automatically moving the equivalent of the Solution Explorer. I like that. It's automatically navigating to that next file. You say that, but it can be annoying if you only have a couple files open, and all of a sudden you're like, well, where's that other file that I really needed? Oh, I forgot to double click it.

So it gets in the workspace. I'm going to have to download and install it. Yeah. I need to install it. One last one though, is that on the atom side of the house, it is inundated with choices in the menus, right?

Like if you start poking around in the menu systems, there's just all kinds of options there. Right. Whereas in Visual Studio Code. They've pared that down. And I actually kind of liked that better. I thought that was a better experience. Than like hey here's everything under the sun.

So they chose the eclipse route in Atom. Um. I don't know that I would quite word it that way. But I mean like. There's definitely, you know, if you start poking around the menus, you definitely get lost in the options quick. You know, you can, right? And code is cleaner in that respect.

So, like I said, I'd love to hear some feedback from, like, what others are doing with either or both editors. You know, if you have a pro and con why you chose one over the other i'd love to hear some feedback on that yeah and you'll be able to do that if you're in a podcast player like you're listening to your car or something just you know swipe over to the show notes thing and at the very top we're going to have a link to this episode so it'll be codingblocks.net slash episode 30 but you'll be able to click that and go up there and leave us a comment fairly quickly so um with that we did decide that we were going to do a survey this episode a real one and based off a linkedin question that i saw that i thought

was pretty interesting there seemed to be a lot of of comments on this one question about whether you should spend your time learning frameworks or learning the underlying languages. So, for instance, would you learn React.js or would you take the time learning just the core JavaScript language? Or would you take time learning Angular

versus the JavaScript language or whatever? Right? So, it's kind of... Definitely the survey isn't a survey. Like, this is a no-brainer you got to learn the underlying technology i see i disagree i i've known plenty i've known plenty of people that have picked up frameworks and been able to look at existing code in the framework because the framework is coded in a way that is usually better practices than somebody just coming off street and writing some code right right? Because there's a lot of people collaborating on it.

So you kind of get to pick up good practices that way. And I've actually known people that have picked up frameworks and, and been able to be productive and not be inundated with all the little nuances of the language. And they pick those up over time as they run. I've also known people though, that get in that situation and then all they know is the framework and they don't know anything outside of it and that's the argument right so the the actual linkedin question was hey my team is working with angular but they're about to switch

to react and i'm nervous because you know i don't even know if angular that well you know should i move over to this and then of course you know as is the case with everything on the Internet, people don't actually answer the immediate question. They, you know, go off, hey, you don't need to learn just that. You need to learn JavaScript. You need to learn CSS. You need to learn HTML. That's pretty overwhelming, right, all in itself. So it was kind of curious.

So, you know, I'm wondering where people stand on that. Do you get extremely proficient at the underlying language before you go jump into any frameworks or do you use the frameworks to help you learn as you go? I don't know, but I do agree because frameworks get eclipsed, right? Like they, they have a sunset on them, you know,

framework isn't going to tell you to use triple equal, but you'll see it a lot in the code. Yeah. In the examples. Yeah. That's what I understand it. Uh, I disagree, man. That's one of those things.

When you're reading through any kind of new language that you pick up, I mean, I don't know. A lot of times using somebody else's code as a guide is a lot of the way to learn something, right? I guess we'll see what everybody responds back with. What's your take, Joe? Then we'll have back with. What's your take, Joe? Then we'll have the science. What's your take, Joe?

Of course the answer is both, but I'm strangely on the side of learning the framework, actually. What? Yeah, I feel the same way. You've got to get stuff done, and I feel like learning through the lens of framework can be a good way to kind of dip your toe into the underlying technology while still getting stuff done.

And as you keep seeing patterns or things like triple equal signs, eventually you're going to get curious and Google them. So I feel like you'll learn the underlying soon enough. Okay, so let me put it to you like this, okay? You're not going to convince me. Yeah. So this one's specifically for Alan, but you know what, Joe? You're more than welcome to sign up for this too

because Coursera has a new class on React.js or there's one on JavaScript. Now, which one are you going to pick? React.js. Oh, man. You would do core JavaScript? Are you kidding me? Well, I mean, like if you hadn't already done it.

I was trying to make a joke. I don't know if Coursera actually has those classes. No, no, but I mean... They probably do. But seriously, throw that away. So here's my thing. If you were doing a resume, are people going to look at your resume if you just have JavaScript? Or are they going to look at it and say, oh, this dude's doing React.js and Angular.js, right?

But we're not talking about a resume, though. We're talking about learning. So my point is that if you had to start with something from scratch you haven't you haven't touched it day one are you going to start learning the core principles of it or are you going to dig into a framework framework start learning the core principles of it first i think you pick it up along the way though i mean that's that is honestly my opinion on it i i mean, a lot of people, they're more comfortable when they have the confines of something like a framework, and it gives them a little bit. Now, I would argue that Angular is probably not a good example of that because it's so deep,

but a lot of times a framework gives you those guardrails to where you can kind of start. So are you going to learn the good practices of C, or are you going to jump straight into the Unreal Engine? Straight into Unreal. Unreal. I mean, because you want to accomplish something, right? I guess that's the difference. People that want to learn a language, they're going to go learn that language. People that want to make something are going to say,

hey, how can I make something the quickest way possible? I think it's a recipe for disaster, though. I don't know, man. Like I said, it'll be interesting. I'm definitely looking forward to this particular survey results. The survey will decide. Yes, it will. Like I said, it's science, so you can't argue with science.

So definitely also check out the show notes for that. We'll have a link for the survey up there definitely go up there and fill it out we're really looking forward to this one everybody helped me prove alan and joe wrong yeah also um while we're talking about kind of voting uh i tweeted this out a while ago and i thought it was kind of funny uh don't want to take too much time but uh i was kind of thinking i always like uh the idea of having like a programmer for president you know and so it got me kind of thinking like well which kind of thinking, I always like the idea of having a programmer for president. And so I got me kind of thinking, well, which kind of, at least tech luminary, would I like to be president?

Steve Jobs, Bill Gates, Linus Torvalds. Which kind of famous programmer, Steve Wozniak, would you like to be president? They all scare me. They're kind of known for being tyrants, aren't they? Yeah. Well, if Steve Jobs was president, it would be the best-looking White House you've ever seen. But you could only open the door one way because he's not going to let you do it any other way. But coincidentally, you never realized it before, but that's the way you wanted to open the door anyways.

So it kind of works out. Right. Now, Bill Gates is president. Bill Gates is president. Then the White House will work with everything. All the way back to 300 years ago, it'll still work with all of that. And he's going to borrow from everything else. So you'll have the best of everything. Yeah, it'll be really heavy, though, because it's carrying a lot of baggage with it right and then if linus is president he's going

to rebuild the whole thing from the bottom up and it's going to work more efficient than anything you've ever seen and it'll be impossible to use and and the whole world will adopt it and it'll be black and white so i gotta vote linus all right i like it all right so i guess on to the uh the actual meat of the show today and that is going to be design patterns and so the one that i picked is the adapter pattern because i feel that it's fairly useful so i guess first is is just a bit of a question you know what is it and what does it actually try to solve? So think about it like this. If you have a laptop and your laptop has an SD card slot on it, but you bought a camera that now has a mini SD

and then you have another device that has a micro SD, well, you can't plug those things into it because you don't have a slot for it. So what do you do? You go out and buy an adapter so you can plug up to your computer through a USB port or something and then you can plug these various different cards into that adapter. Well, that's the same exact mentality

behind programming an adapter. So just walking through kind of a small example, I think it'll help clear it up as far as software terms. And I'm borrowing some of this from a tutorials example. I think this will, it'll help clear it up as far as software terms. And I'm borrowing some of this from a tutorials point. We'll have a link on the show, on the show notes to the particular article, but I'm loosely going with it. So the one interesting thing about this that I've seen in almost every one of the implementations is there's almost like a mini factory pattern within all the adapters. And you'll find out why in just a minute. So, and I don't remember one of the shows we did factory

patterns. So if you're not familiar with that, you can go back and listen to the episode, or we'll probably have another link on the show notes for that as well. But let's say that you have an audio player app. And let's say that this particular audio player has a class and it has one method in it called play. And that play takes in a file type and the file name because it needs to know what it is and where to go play it. And you, let's say that you now say, Hey, you know, my audio player is getting pretty popular. I want to bring in some other things right now. It can only play MP3s, but I want to be able to play flax and MP4s as well. Okay, well, in order to do that, you don't have to reinvent the wheel. So you pull in some third-party libraries, one that plays MP4s and one that plays FLACs. Well, those are going

to have their own methods or API calls to play files. And let's say that the MP4 one's play MP4. It's not play like yours. And then the flack one has a play flack method well what you could do is you could go into your play method and you could put a bunch of if else's in there so that every time that you add a new different type of file you could just have if file type equal this and do this if this and do this and so it really makes your core application a little bit cruddy like you have to go in and modify it every time. Then it's not easy to follow. It's no longer clean.

So the way that you do this is you create an adapter. And so in this case, you might create something called a media adapter. And that media adapter would take in a file type. Okay. When you call play, that is then going to have a private instance of a media adapter. We'll say that media adapter could take in any type of file type. And so now you've got these flax and these MP4s. When that MP,

when that media adapter gets instantiated, it's going to go through and do that switch type thing. So it's what kind of does its own internal factory. So it's going to say if file type equal MP3, then create me a new instance of the MP3 player. If file type equal flat, create me a new instance of the flat player. If it, if it equals MP4, create me a new instance of the MP4 player. And then it's going to know, Hey, you called play. You need to play, or you need to hit the method on each one of those different classes that actually plays that file. And so really in a simplified term, all you're doing is you're creating a

bridge from your existing code that your particular application knows that it works with, in this case play. And now you're creating an adapter so that it can hook into multiple different classes that maybe you don't know, maybe different classes that maybe you don't know maybe you do but you don't want to have to change everything to work with your existing interface so you create these adapters that will then kind of translate what that play means on all those other classes so essentially that's all it is it's very similar to to using an adapter that you plug into something to where you can put multiple different things into it through the same interface. And in a nutshell, that's, that's pretty much it. So as long as you can play, you can play. But one thing I think is kind of interesting about this

is that you do kind of have a dumbing down effect. Like, uh, you know, MP3 supports this notion of bookmarks, but flax don't. So you're probably not going to have bookmarks in your, you know, interface. And so you, if you do treat everything the same, then you have to stick to those commonalities. Yeah. And I mean, I guess one thing to point out too, though, it's usually on a method by method basis, right? Like when you're doing an adapter, it's typically for a specific piece of functionality. So what you just said, which was really interesting, is bookmarks, right? Like several of these file formats don't support it, but what you could do if you wanted at that point, you could create your own layer for bookmarking on top of these things and then handle it yourself. And again, that's the same type of thing using an adapter that you had the core FLAC library doesn't support bookmarks, but you could internally because you created this adapter,

and now you also set up this other layer of handling that behind the scenes. So, yeah, absolutely true. I mean, if you look at it purely from if you're trying to map everything one-to-one, then you're going to end up having to take the lowest common denominator. But really what the adapter pattern allows you to do is say, okay, my core interface or class supports these methods, and I need these to map to methods in these other classes out here. How do I do it?

You create an adapter, basically a bridge from yours to theirs. Well, I wouldn't talk about it as like one though, right? Like, I mean, you wouldn't necessarily talk about adapter patterns as like one to one, right? Like you would typically want, you know, you have these two things or more and you want them to all have a similar interface to them. And that's where you'd use the adapter. It's not trying to make this one. I forget exactly how you worded it a moment ago, but. Well, no, no. make this one uh i forget exactly how you worded it a moment ago but well no no when i said that

the one-to-one i mean you're going to map this one method over here like play to some method over in another class so when i say one-to-one you're basically trying to get that same type functionality out of this third party or this other this other class that you're trying to adapt to yours right i didn't necessarily mean you're only going to ever have one adapter. What I'm saying is you're trying to map one piece of functionality to another. And it might be that your adapter has to call multiple things in that other class in order to accomplish what your play is, right? Like, let's say that...

Now you're getting into a gray area. No, not really, because an adapter really is. You're trying to play that file. So a FLAC is a compressed. It's basically a zipped-up audio file. All right? So it may be that in that adapter to do play, you've got to call this unzip type function first and then play.

Convert to MP3 function? See, I feel like you're about to step on my toes here with my my boy facade okay well we won't we won't step on the toes but but you see what i'm saying i didn't mean one to one i meant that you're trying to map the functionality of one to the other through a common interface and by interface we usually mean like the programming term interface right like you're gonna have a play well it doesn't have to be i wouldn't phrase it as that doesn't have interface in this way could be much more of a generic term not necessarily programming interface fair enough but it's really cool when you think about um you know

the audio example if you've got a file and it can do all the basic audio stuff like fast forward play rewind and um once you get it you're going through that adapter then you can probably do all the kind of other cool stuff audio audio stuff you want to do like equalizers visualizations all that stuff's just work because it's dealing with that interface and you don't have to do a bunch of ifs all throughout that code yeah that's the thing and the reason why i was joking about the facade pattern though is it does kind of come up often about like you know adapter versus facade i think they're very similar and i mean you're going to get into it here in a minute but one's more about hiding ugliness and the other one's uh more about linking two things together right usually we won't say which is which yet i don't know why you got to

call it ugly it's just code yeah fair enough i've definitely written some ugly code in my time so yeah that's that's pretty much it in a nutshell i mean um it's got a pretty simple use and really behind the scenes it's not that difficult to do i've got a couple of links one for the tutorials point and then there was another one on code project that i thought did a really nice job of bringing it all into like one block of code so that you can like quickly look down and see oh this is what it's doing so it's pretty pretty simple straightforward and useful stuff cool all right so the next thing is yeah uh if you haven't already please go leave us a review we've had like just a couple in the, uh, in the past month

since we did our last episode. So please, if you've been on the fence about it and, and, you know, you just haven't taken the time to go up there and do it, please do it. It really does help us out. It helps us get us in front of more people and grow the audience. I mean, we, we want to, we want to make this a big thing so everybody can learn and, and have fun along the way. And if you have any friends or family that are programmers or aspiring to be programmers or just like somewhat off humor on occasion, you know, definitely send them over there and tell them to take a listen to the show. I think what Alan's trying to say is that you should aspire to be like Luke and get the entire team listening to the show.

And, you know, even better if you can get the entire team to leave a review. That would be awesome too because we greatly appreciate this. Yeah, most excellent. This episode is being brought to you by Infragistics. Great apps happen by design. Build your application right from the start with rapid prototyping, UI controls, and the support you need to develop the ultimate experience. Head over to Infragistics.com

and start your free trial now all right so quick recap uh we just talked about the adapter pattern uh which allows you to get two incompatible sets of code to talk together and uh had some uh some really cool examples there and uh now we're moving on to the facade pattern yeah so we kind of already hinted around about this one right and and talked about uh it it may be having some similarities with the adapter pattern so uh let's go over first like you know the the book definition for this thing right an object that provides a simplified interface to a larger body of code. So this is why, Alan, when you started to talk about your example of, you know, this thing might, your adapter might be making calls into several, making several calls into that object, you know, and kind

of trying to hide some of that, abstract, you know, extract some of that away from you. That's why I was like, oh, let's, let's know tread tread carefully there right because that's the whole point of the facade pattern is to take those complicated interfaces and to simplify them so if in your flack example you mentioned like an unzip uh you know feature that had to happen and joe mentioned that it has to do a call to to convert to mp3 before it can play right like all those complicated calls obviously we're making those up but those might be brought into a simpler for simpler interface that's just play right so you just have the one method play and and that's really the whole point the intent of the facade pattern right

or or if you were to think about it you could think about this way too is that it could provide a unified interface to a set of uh you know interfaces you know act as a wrapper to those and again in this term and in the way that i'm using interface here i'm not necessarily referring to the programming interface uh as in you know uh i is for interface you know the type of interface but maybe a more generic uh you know usage of the word right so i have a question for you all right i'm trying to think of an example where i've seen something like this and i'm thinking of um like basically ftp like if you were to ftp via command line you're gonna you know All right. I'm trying to think of an example where I've seen something like this. And I'm thinking of basically FTPing. If you were to FTP via command line, you're going to open connection, CD to directory, copy file, stuff like that.

But if I were to want to simplify that process, I might write a facade that's kind of catered towards or tailored towards copying a file somewhere. And then I might say facade.copy file and it's still going to do all the stuff in the background but to callers of that code i don't have to kind of copy and paste all those lines to do you know similar tasks um yeah i mean that that's one example so like let's say like when you would want to use this, right? Is you have some complex set of calls or maybe an API, a third party API, and you want to reduce that down to a much more simpler set of calls that, that has to happen. Right. So, you know,

I was trying to think back and, you know, originally when I was trying to put my notes together for the show on this, like I couldn't come up with like any concrete examples of like, I know I've done this, but God, it feels like it's been so long. Because I could certainly remember like, you know, taking old C APIs that, you know, third party C APIs that would be given. And I would want to have those in, you know, maybe a C++ kind of framework. So I would want to group those together logically into classes. And then that way it would just be these simple, easy objects that I could call. And those objects would do all the complicated, uh, you know, steps that might be necessary

to happen. But then as I was thinking about it later, I was like, well, there's definitely some examples where, um, maybe if you're working with a third-party vendor for payment systems, as an example, and you want to take their APIs and reduce that down into a much simpler format that you you can call so maybe you're not going to use every feature under the sun that that you know third party offers but the ones that you are going to use you want to have it in a reproducible format right and so you might reduce that down into uh you know one method that's you know pay and you know you pass an amount or something like that, right? Versus the 15 calls that you have to make ahead of that in order to set up the secure connection between you and that third-party payment system and keep that token and then tell it what you're about to send and all that.

Have all that hidden away in one simple method as an example, right? Yeah, you just said that reminds me a lot of dealing with the AWS API. You know, the first thing you do is you use a factory to create an object. You pass it your credentials. You use that object to create a request. You process the request, and you get an object back that represents the request, and you kind of check and see when that's done. And a lot of times if you're just putting a file up in, say, S3,

then you might write, like, say, just putting a file up and say S3, then you might write like, say like a singleton class put in S3 and you know, it just kind of does it returns true or false. Yeah. It's like a wrapper for everything. Right. I mean, we've even definitely is a wrapper.

I mean, that's a good way to consider it. I mean, we've even, I mean, we've all worked in, in order systems where I definitely remember seeing code where it'd be like, okay, here's the order placed. All right. then it would go and it would reduce the inventory and then it would go

and try and allocate payments then it would go and try and do other things and instead of having a single wrapper that was hey order placed that would then go do all these things there was an api it would literally step through and do that kind of code, right? And that's where a facade pattern is awesome. Hey, go do this, determine the taxes, do all this, and it does it all for you, and then it's done. And then anything that needs to leverage that same API, whether it be, I don't know,

some other system that you have on-site or off-site, can call into this one simple call as opposed to having to have this intimate knowledge about your, your, your internal structure of your app. Yeah. It keeps it nice and dry. Yeah. And I actually was thinking of specifically, you know, of the PayPal API. If anybody who's done any kind of e-commerce and you've worked with PayPal, you can know that that API can be really has some gross parts to it.

Yeah. It's a beast. You know, if you can, if you can take all of that complication and reduce it into one class that has just simpler, you know, easier to understand entry points for the rest of your application,

that's a facade. Right. So specifically, entry points for the rest of your application, that's a facade. Right? So specifically, you know, going back to the adapter conversation, it then brought up this interesting take about like, okay, well, let's talk about facade versus adapter, right? Like, what's the difference between these two? When would you use one versus the other, right? So an adapter pattern pattern you typically already have an existing interface that you're trying to get other uh inner systems to act like right

whereas with a facade pattern you don't have that this is something brand new that you're going to create from scratch right that's a really good distinction so so uh this facade you're defining a new pattern and an adapter and i think i might have said this before or or you did alan but you're trying to make you know two or more things look similar and and act similar to each other right so um you know whereas with the facade pattern you're not trying to necessarily make it look similar to anything you're just trying to make it easier to use right right they're both wrappers in in a sense right but the facade pattern is trying to wrap maybe multiple objects or multiple uh system calls API calls or multiple calls into a much more

simple and easy to use call. Whereas an adapter is trying to wrap, you know, each adapter is trying to wrap a single object, right? Maybe. I don't know if single object, but definitely just trying to do similar functionality, right? Well, there might be a flack wrapper there might be an mp3 wrapper right there might be a wave wrapper but the point is is that like each one of those i'm sorry uh i kept saying a wrapper but i'm an adapter so a flack adapter or you know an mp3 adapter so each one of those is is wrapping the specific type uh ultimately but they're providing a common interface to it. Right. And, and that's the whole point of the adapter is it's trying to solve the problem of, Hey, we have these, have these multiple interfaces, whether they be objects or,

you know, actual type interfaces or whether they be API calls, but I have these multiple things, these multiple interfaces, and they're all distinct, but I want to make them compatible amongst them. That's what the adapter is trying to do, right? But the facade pattern is simply trying to take all this complication and put it into easier bite-sized chunks. Yeah, to hide it,

to hide the implementation, basically. So I guess you were referring to facade as hiding the ugly earlier, right? Yeah, yeah. Who do you call an ugly, man? A lot of times that's what it's used for, right, is to hide the internals. It may or may not be ugly. It could be the most beautiful code in the world, but it was 20 different calls, and now you want to make it more. I mean, I'm sure if you've seen PayPal, it's got to be pretty. So then I went on this hunt because then I was curious.

I was like, well, where is this thing used? Like, is there an example already inside of.NET, right, where this thing is being used? And so I did some searching around, did some Googling. And one comment that came back that I thought, oh, that's probably an interesting case, was system.net.webclient. And going back to Joe's FTP example, I thought, oh, that's probably a pretty good example. If you think of the protocol there as the interface, then all that has been abstracted away from you now. All of that ugliness has been abstracted away from you now, all of that ugliness has been abstracted away from you. And instead you just have this one, you know,

pretty little interface to work with, you know, called the web client. So no sockets, no DNS, all that stuff is, you know, out of,

out of your hands. Right. Exactly. Exactly. And, and so then I got to thinking like, well, okay,

well, I wonder if, you know, maybe outside of.net, like maybe, well, but still if maybe outside of.NET, maybe, well, but still within.NET but not baked into it, maybe something like JSON.NET would count, right? Where you're kind of extracting away what does it take to make, to reconstitute

these JavaScript objects or to go from one to the other, right? Like, you just know of these simple J objects, for example, right? make to reconstitute these javascript objects or to go from one to the other right like you know you just know of these simple you know j objects for example right right or or but then but then i started going a little bit crazy when i was thinking about like okay well where does the facade pattern madness end right because if we're going back outside of dot net right then it's like well you know we were talking about react js earlier and i was like, well, you know, we were talking about React.js earlier. And I was like, well, huh, could you count that as a way to, as a facade? You know, because then you don't have to deal with the DOM, right? That's probably, yeah, that's probably exactly what it is.

It's doing things for you, right? Like it's extracting away things for you. But then I got into this question where I was like, okay, wait a minute. If the facade pattern aims to make complex systems or interface simpler, okay, by wrapping them in an easier interface, would that then make like all NuGet packages, all JavaScript frameworks, like every new package or framework that you've heard of, be it for whatever language, does that then make that a facade pattern? They most certainly contain them, right? But the point that I'm trying to make, though, is that every framework that comes out, like any JavaScript package, any NuGet package that you're going to use,

the whole point of that thing is to take something else and make it easier to use. So the facade is basically a good example of abstraction. And so all these frameworks, even a function, it's abstracting away what's done inside. And all you see are inputs and outputs. So I think specifically this pattern is talking about having a class to represent a system of actions. So I think it's a little bit smaller, but I think things like frameworks and stuff like that are definitely very similar. And you could argue that philosophically they're the same. Exactly. Well, they're similar in what they're trying to accomplish, except it's, I think even, I think Joe mentioned this previously, is when you look at a framework, it's a system of all these things put together of different patterns, right?

That compose the entire framework. Right. So I was just throwing that out there as a thought, because like everything, you know, most of what you're going to read, like you're not going to find anything that's going to say like, Hey, every package is a facade pattern. Right. But it definitely started to, you you know as you start reading into it you start like expanding like well wait a minute because you know if i take away the definition of

it just being the one object or you know the one entry point and then say well what if this uh you know json.net or React.js like you know if that counts then that's where it was like okay wait a minute I think I'm going too far here right like turtles all the way down yeah so

that's the facade pattern my mind's kind of blown right now I feel very small so one of those posters with the universe and the arrow and you're like you're here you're nothing you gotta make it bigger man you gotta you gotta build it up yeah uh so we just talked about um two of our favorite patterns now i wanted to talk about uh one uh that i'm sort of lukewarm on, which is the Memento pattern. And the reason I'm lukewarm is... I've seen that movie. Yeah, it's a much better movie than it is a pattern.

I actually thought that the Memento pattern was something else before I started looking into it and realized what I was really thinking was more like the command pattern, which we'll probably mention sometime in the future and go into depth. But the Memento pattern is aimed specifically at rollbacks. So like a real world example would be something like you're about to make some changes to a database and you take a full backup first, right?

Because you don't know what's going to happen if something goes sideways, you can restore that full backup. And it's very important to know that it's a full backup, because you're taking a snapshot of the entire internal state of this thing. And you're able to return and restore to this full internal state. And that doesn't work so well for something like say, you know, undo in Microsoft Word, where you know, you want to be able to kind of control Z and control shift Z or, you know, control Y Microsoft Word, where, you know, you want to be able to kind of control Z and control shift Z or, you know, control Y to go backwards and forwards in time, because you'd

be saving a full snapshot of this document at every turn. And it just doesn't work out very well. But the command pattern is designed specifically for that purpose. And so it's just, it's better for that. Yeah, I'm kind of curious curious i don't think i've ever seen this particular pattern so i'm curious as to what you say the implementation details of this are yeah sure so um just to give you kind of like a more cody example um one thing you might do is you would have uh an object well i will say car and you want a method called, got the name here, save to memento. So you would say car.saveToMemento, and it would give you, we'll say, just for the purpose of demonstration, a JSON object contains all the data,

like 100% of the internal structure of that object, all those internal, all those private, all those public variables. So a deep copy. Yeah, a deep copy, everything you need to know about that car. And what that means is I can say, hey, car, save to Memento. It gives me an object. I can start making some changes. I can take the tires off.

And if I run into some sort of problem, I can say, oh, crap, I don't have the right kind of tires or I'm not going to be able to finish this job. Let's just go ahead and undo. And so you roll back the complete state, you roll back to that memento. So when you say you roll back, does that mean that it's going to keep track of everything you do or do you just keep a copy of that car and another variable somewhere yes you keep a copy so like if you were doing something more along the lines of the command pattern you would keep track of what you do along the way and you would know how to undo each step and so you're only saving a minimum of information for each thing you do but the memento pattern is

very dumb it just takes like basically a dehydrated object takes a copy you know a picture of your object and if things go south it can restore it so like a good example of this another uh kind of real world examples like a database transaction you know you say start transaction you do some stuff if something goes badly you can roll back and you go back to the state before that transaction began well i was thinking of a different example yeah yeah like a get reset hard oh there you go that's that's actually probably right along the lines of it yep because its story it has the previous state and it goes straight back to it except i guess the difference would be it sounds like the way that this is implemented in code is this is like

a live memory type thing that's there right yep okay i don't think the get reset this is implemented in code is this is like a live memory type thing that's there, right? Yep. Okay. I don't think the get reset hard is like an actual example. I was just trying to like – You're slipping get back in there. We understand. Well, you know, there's a lot of reasons to do that.

But I was just trying to make like a – I was trying to make it more tangible, right? And it makes sense. There's another example like a tangible way to think about this thing too that i was thinking about was like system restore points oh yeah um on your on your you know for windows users right yep vm step shots are another great example interesting so it's it's like you said it's it's pretty heavy-handed yeah it's it's not all that efficient but it's a brute force way of just getting back to the previous state. Yep.

Well, yeah, because this thing is all in memory, though, too, like Joe said, these are deep copies. So depending on your usage of this thing, this could be some heavy memory usage. Yeah, it could be. Yeah, it absolutely needs to be everything that's needed to restore that object to 100% of its original state. So it's not necessarily that you need to save, you know, you don't need to necessarily serialize all of the internal data as long as it's, you know, derived or you kind of put those pieces back together when you restore to that memento. So I think this pattern is interesting for a couple other reasons though. The way it works, I thought it was pretty interesting. This is kind of the way i thought about it and then um after i read about it it was

kind of um a little bit different and so um there's really three objects involved um and they're poorly named so sorry uh but the first is the originator and that's your that's your real object that's the object that you want to be able to create a memento of. And I just said the second object, the memento, is actually an object that represents the state. So really, the JSON example I gave above wasn't so great because the JSON, you know, it's not really an object. It's serialized. It's a little bit different. The object should actually be something that's completely immutable you almost want to think of it like uh you know like where

i thought you were going to go with this was like inception though where like the the saved copy is a is another uh originator object oh yeah so that would be that would get into like kind of prototype uh territory right which is something we kind of talked about where you could kind of clone things and change them a little bit you know and uh that's why i think it's kind of interesting about this so it's got really firm rules around how to do this and basically the originers got originators got two methods and that's save to memento and restore to memento and um actually i should say two additional methods because um in a clear violation of the single responsibility pattern um we do want our object that actually you know does the work and does the stuff to be able to save its own internal state and restore

from its own internal state which i thought thought was interesting. Initially, when I was reading about this, I thought that there was going to be another class around that was in charge of knowing how to serialize and deserialize these objects. But that's not the case, and they specifically wanted these objects to know how to put themselves back together. Well, yeah, I'm trying to figure out why you think that would be a violation because how would something else know the internal state?

So if it's just a DOM like Poco or data transfer object like DTO, then it's only really going to have public properties and it doesn't even matter. There's no real reason to do a deep copy of that because it's all right there at face value. But if you did do this on some sort of you know real class that had uh you know methods for doing things then not only is

your class responsible for doing those things it now also knows how to export and import itself so i guess the example i'm thinking of like if I'm thinking of a complicated object type, I'm thinking of a data table. Where it might not expose, but it'll know where it is in the reading process. It might know a total count. Well, it'll exposed to total count. I guess that was the class, though, that I was thinking of. There's going to be a lot of internal state there that it's not going to necessarily expose publicly. Yeah, so one example might be... But would be necessary in order to reconstitute itself.

Right. So, I mean, you know, in like real simple examples, you could actually just kind of, you know, base64, you know, encode your data or literally just, you know, take the binary for that object and write a disk or something. But another example that was kind of fun is, you guys remember Mega Man? Oh, yeah. Yeah, when you would save your game, you know,

they would give you a little code, which was like a grid with little pictures in it. Yep. Yeah, I mean, that right there, that's an example of the memento pattern, where they give you something that represents the state of the game, and you type it back in at some later date, and it's able to recreate the state of that game perfectly. That was an incredibly hard game, by the way. It's got to play for thousands of hours.

You really did, man. You couldn't beat that game. It was impossible. You had to memorize. Oh, actually, Call of Duty was, speaking of gaming, one of the things that we got some feedback on. Like, we should definitely include an episode on Call of Duty. Ain't nobody got time for that.

Nice. And so I did want to mention the third object, which is involved with this pattern. So the first was the originator. It's the real thing. Memento is the internal state. The third is called the, another terrible name, the caretaker.

And the caretakers is the person who's, or the class who's actually in charge of doing that rolling back and doing that stuff. And what I thought was kind of interesting there is that there's pretty much no example of this, at least no abstract example. It's all pretty much you kind of save the memento and then you do some stuff. And if you need to, you can roll back the memento.

So the caretaker is not used? Actually, if you were to pull up the Wikipedia article for this pattern, it doesn't mention a caretaker. Yep. So that's a strictly by the book. I wouldn't be surprised if most people just leave that out of their examples. Huh. But just for fun,

I wanted to kind of think of some weirdo tips because I was trying to think of examples that were like.NET or just well-known examples where this might exist. And so I kind of thought of some weird scenarios that aren't quite right. But, you know, like one was the undo and redo history.

You know, that's not a great example here because we've got such a, you know, heavy export. You don't want to save a copy of your – a full copy of your Word document every time you, you know, bold something. Also, we mentioned a little bit if instead of having that restore to and meant to function return void if we actually returned an object then you'd almost have a factory so you'd be able to kind of like pump in this internal state and get out objects which is interesting but that does mean that that factor or you know what's acting as a factory has to know how to create internal states of the objects it's producing so it's a little gross and what I like about thinking through that is I feel like I'm kind of learning from the masters in a way.

You know, I'm looking at this pattern, and even though I don't like it much, I'm starting to understand why I think they made some of these decisions. And so I thought that was pretty cool. There's also an example of sending between different systems which is kind of interesting if you're doing some sort of you know if you can export a blob or something and send it to some other system that knows how to put it together even if you're using a shared library then that's pretty cool and uh kind of along the same lines of cloning um c-sharp you know it's got the cool generics so you can do some pretty cool stuff with generics to kind of generify this but when you do

that you're kind of losing some of the benefit because you're you know you either have to know about the internal privates of these objects or they their internal state doesn't matter very much so then why are you really doing this so and i wanted to mention also why you don't really see this pattern very much which is kind of the main use case of the software is transactions and that kind of stuff is usually held or already taken care of for you by wherever you're

doing those transactions so and command pattern is just better for most things I'd never even heard of memento before you said you were going to do it yeah huh it kind of reminds me of

like thinking of just another like real world use of it is if you've ever used the protocol buffers google protocol buffers it's like think of json except if it were better. JSON is awesome. I don't know what you're talking about.

Well, okay. So, you know, I say that jokingly, though. But, like, JSON is all human readable, right? And so by very definition, then that means that there's waste there, right? Yeah. Whereas Protocol Buffers solves the problem. It's solving a similar problem, but it's doing it in binary form. And it would compress things too, wouldn't it? But what I don't remember is, oh, it's definitely a compressed version of what you get.

Yeah, which is hard to do for streaming type stuff. So that's interesting because it doesn't know where the end is so but but what i don't recall it's been a while since i've used the protocol buffers is does it uh save the the state for like private you know did it have access i can't remember if you were setting up access to the things that needed to be saved in the protocol buffer. I'm pretty sure that you did. Yeah, I don't know. I'll have to go back and look at that.

But that's one example I was thinking about. I've never seen the protocol buffers before. That's pretty awesome. Yeah, they are amazing. Yeah, we're going to have to leave this in the show notes. It's definitely a much smaller way. So like if you wanted to serialize your objects and you wanted to serialize a lot of them and you wanted to do it in as little space as possible,

then that's where JSON starts to break down, right? Because it's such, because it is human readable, you're going to have a lot of waste there, right? Whereas with protocol buffers, you know, it's just garbage, you know, is what it's going to have a lot of waste there, right? Whereas with protocol buffers, it's just garbage is what it's going to look like. That's really cool. We'll definitely leave a link in the show notes for this. Yeah, definitely. Also, just to recap, I guess it's not really an also, to recap, we talked about adapters, facades, and mementos.

Also, I don't think we really called it out, but we've got three other shows spotlighting other design patterns. So if you're just listening now, go back and check those out. I know the first one is at 11, but there are two more in there somewhere. Yep. And we'll leave links in the show notes for those as well. And then, yeah, resources we like. The first and foremost for probably every episode is the internet.

If you haven't been there, you should check it out. You know, we were putting the show together, the show notes together. I felt like that was relevant. I don't know. It's definitely one of my favorite resources. So if you haven't used it yet, well, A, it's interesting that you're listening. So you can probably thank a friend for letting you listen to the show. Yes.

And you should check it out. Yep. And there's also the Gang of Four book, which we've mentioned many times, but that's kind of where a lot of this stuff comes from originally, including some of the stuff that's kind of outdated. And I actually just threw another link in here. You guys familiar with the Codeless Code? No.

I'm sure you've seen it before on, like, Reddit or Hackanoo's, whatever, but it's not really design pattern specific, but it'll have these kind of, like, fake scenarios with, like, Buddhist monk temples, and they'll illustrate some sort of like programming principle using some sort of like funny story about the, you know, monk cracking the egg or something. I've never seen nor heard of this. Oh, you are in for a treat then. You're welcome.

Yeah, thanks. I probably just lost hours. Yeah, I think they have some sort of rating. So definitely start with the the higher ranked ones all right cool um so j is so joe what's your uh what's your tip of the week well uh i was talking about um other editors that i won't name um i uh i've finally gotten back into reinstalling some of the packages that I used to use for Sublime. I've been lazy when setting up other computers.

But one that I finally reinstalled the other day was CodeFormatter, which actually, I guess it provides a nice facade, probably using some adapters for other plugins. You said facade. It's got to be a facade pattern. Yeah. I heard you say the words. So there's actually a bunch of different formatters. So you can go and you can get the package for JSON formatting or PHP formatting or HTML, or you can get the code formatter package, which bundles all those up.

And you can just say kind of, you know, I think I did like control F for my hotkey. I can open a file, do control F, and it's going to format my SQL for me or my XML or whatever it is. So I don't have to go use an online formatter. Oh, dude, that's beautiful. I'm downloading that. Yep. Because I did exactly what you said. I've got like three or four different formatters installed.

This is excellent. Yep. Awesome. Wait, this is going to format. Wait, did you say it was specific to the language? No, it can handle many. It can handle many is what he said. Yeah, yeah, but what I mean though is that like did you say it was specific to the language? No, it can handle many. It can handle many is what he said. Yeah, yeah, but what I mean, though, is that, like,

did you say that it's going to format your C Sharp specific to Microsoft's coding standards and JavaScript to its standard? I believe so. It's up to the individual formatters that it uses to decide that. But for me, most of the time, if I'm doing that, it's just because I want to see, you know, I got some sort of like, you know, something from like

a stack trace or something, and I just want to like dump it in. That's probably a bad example. Or, you know, I get some sort of mangled XML and I just want to see it properly tabbed so I could read it. That's awesome. Alright, so my tip of the week, simply because I couldn't think of anything else.

Oh, I need to start writing these things down because they come up all throughout programming and I always forget them. So mine is Slack. If you've got a team of people that you... Hey, I'm already Slack. I'm already winning. He is a Slacker. So no, seriously, if you haven't used Slack and you do any kind of communication, like a lot of us were using Google Hangouts, and while they can be awesome, there are some things that are frustrating. Like, you can't boot somebody out of a Hangout.

So, if somebody needs to be gone from your Hangout, if they don't choose to leave, then... Why are you looking at me? Then you can't get rid of them. But with Slack, not only is it an excellent chat platform, but it's got a ton of plug-ins to it that make it both useful and fun for working with a group of people. You don't want to be getting on the phone all day with them. You just want to shoot over a quick message. I would definitely recommend checking it out.

It's a very nice platform. There's a reason why they are growing like crazy. Yep, slash Jiffy. That's why. Giffy, come on. So the deal is you type in slash Giffy and then some sort of phrase, and then they will try to find an appropriate GIF that matches that. So you can say, like, slash Giffyhy lol and it'll get a picture of somebody laughing really

loud, a little animated GIF. Sometimes it comes up with some really interesting and odd photos or GIFs. And they're usually animated GIFs. There's some pretty entertaining stuff. I mean, we've definitely blown out our bandwidth. Yeah. And it sounds like that's more about a tip of the week for the company and, and instead of the individual. Yeah.

I mean, if you don't already have a good chat platform, this is an excellent one. Yeah. We need to get a coding blocks, a slack going, maybe a little sponsor us and we can just kind of keep it running. Ooh,

that would be fun. Maybe we can even invite others yeah so uh i did write down my tip of the week thanks uh i'll get the knife out later um so we were talking about Atom and Code earlier, and so I found this, the keyboard shortcut cheat sheet for the two editors. And so we'll throw a link up to that in the show notes, but it's a pretty good list of all the different keyboard shortcuts, assuming that you're a keyboard junkie, which I would imagine most every developer I've met, the majority of them are. Except when it comes to Git, which is weird.

Because Git is weird. It is. It's like you're making fun of his girlfriend, man. That's just wrong. Wow. Why do we have to make it weird? Your girlfriend is his girlfriend, man. This is wrong. Wow. Why do we have to make it weird? Your girlfriend is nonsensical. I'm sorry.

Oh, man. She has weird flags. All right. Before we go any further with that joke, let's just go ahead and wrap this show up and say that, in summary, we've discussed the adapter, the facade, and the memento pattern. And what else do you want to add to that? Go to the internet. Yeah, use the internet. It's good for you.

And we know who Outlaw is voting for for president. Yes, yes. This has been a very fruitful show. All right, so with that, be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And if you haven't already, we've said it before and we'll say it again, please go on iTunes or Stitcher and leave us a review. We greatly appreciate it.

Yep, and contact us with any questions or topics, head over to www.codingblocks.net. And there's a contact link up there at the top of the page and leave your name. And if you want to be mentioned on the show, we'll be happy to do it. And also visit us at www.codingblocks.net where you'll find the show notes, examples,

discussions, and more. And send your feedback, questions, and rants to comments at codingblocks.net and make sure to follow us on Twitter and Facebook. I think he was just using Slack. Was he being Slack? Is that what you were talking about? I think he was asleep, actually.

I'm not real sure. I'm singing about pizza. Oh, you're just now eating? Oh, man, you've got to be hungry. And that pizza's cold. No, man, this is like the other side of things when you're like, Whoa, why did I eat that pizza? Pizza.

Oh, man, I'm old now, man. I think about pizza very differently. We have a very different relationship now. That's excellent. Alright guys, that's episode 30. It's a wrap. Peace.