Coding Blocks - Javascript Promises and Beyond

Episode Date: August 22, 2015

In this episode we dive into Javascript Promises.  If you’re used to the olden way of doing an async call with a callback, you’ll definitely want to give this episode a listen as you could improve your mental sanity 10 fold by learning how to use promises in your application! Survey – What is Your Favorite Language? […]

you're listening to coding blocks episode 31 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app visit us at codingblocks.net where you can find show notes examples discussion and more send your feedback questions and rants to comments at codingblocks.net follow us on twitter at codingblocks or on, or head to www.codingblocks.net and you can find all our social links 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. And with that, let's get into it. So it's been an interesting few weeks since the last one. Went to some interesting meetups alan actually went with me on one of them went to uh the meteor in gaming what'd you think of that actually that one was really cool i mean if you haven't seen meteor js in action uh they they kind of took it to the next level by having like uh uh what would you call it like uh uh what were those old diamond games i can't i can't where you flip the oh like a bejeweled game yeah candy crush yeah so they took like a bejeweled type game and created one and what i think he said two weeks it was two weeks but you know here was the thing

that for me though that that was the bigger takeaway was just meteor yeah if you're not already playing around with Meteor.js, this totally got me. I wish I had more time to focus on it because there's some other libraries I've been spending some time on, but Meteor is definitely on my list of things to do. This is the reason why when you ask me,

hey, Outlaw, how are you doing on your resolutions there? How's that Ruby coming along, right? This is why I still haven't got it because there's so many other frameworks and libraries out there that are more interesting to me. Yeah, he's got ADD. We all do. We're developers. It happens, right? Yeah.

But Meteor is on my list. If you haven't seen this thing yet, it's like, how would you describe it? I would describe it as maybe an N npm for a javascript framework like is that fair well that's quite it's compared people have compared it to what rails is for ruby it is what uh job or what yeah it's like the rails for ruby it's that to node and so here's the cool part like probably what blew outlaw away and what blew me away when i first started playing with it is what's called ddp their distributed data protocol and basically if you've heard of um i can never remember the name of this thing signal r if you've ever heard of signal r and

all the real-time collaboration type stuff this is the same type thing like you can do pub sub type things and you know your app updates and everybody connected to it gets an update so and it's so easy to do i mean that wasn't even the exciting part i know that was like the most thing no it was just the fact that like like i said that you know having all the modules out there i don't know i there's still i i'm by no means a meteor expert but there's still a lot that i want to dig into but it it was that part that like uh when we were talking later about like the login modules and like automatically you know be able to use your social uh you know plugins for oauth and things like that it was that kind of thing that I thought was just awesome. Yeah, you could prototype an entire app in an incredibly short period of time.

So it was definitely a cool meetup. They covered a lot of neat stuff there. So that was a lot of fun. Yeah, and then there was the intro to Flux meetup too, which was really interesting too. So React has definitely been one of the things that I've been focusing more time on here lately in my infinite free time. And, uh, you know, flux is the, what would you say? Architecture that they're

using that, that Facebook is using to handle the, um, the M and the C portion of MVC maybe. Although they really say that flux is not an mvc pattern so that's kind of confusing i don't know what are your opinions on that i actually have not looked into flux at all to this point i did uh but along those lines well you've blinked and there's already like 24 derivatives of it so that well you said that the guy said that at the end of it right it was ridiculous like i mean it's not it's not an old framework by any stretch, you know, but I mean, it's not, it also didn't just come out last month either in all fairness. But yeah, he, uh, the, the guy that was giving the presentation at the end of the presentation

mentioned that there was already, you know, uh, he, he listed at least a dozen different, um, derivatives of it. And those were just the ones that he's actually taken the time to look at. There was more that he didn't bother. Well, along that note, so I say that I haven't looked into it. Unfortunately, I kind of have, but it was confusing. So I just recently bought WebStorm, and in there they have a template starter thing for React,

but it comes bundled with Flux. And I was looking through the code, and I couldn't figure out how any of it wired up. So I'm actually going to have to go out and do some tutorials to kind of pick up the pieces there. But I am on the WebStorm bandwagon because for 50 bucks it's pretty good this is kind of funny i was going to bring this up as a joke because uh yeah like what he's not telling you is i totally convinced him on that purchase though because he was kind of like on the fence about like

which way you go and you know i've mentioned i'm such a huge fan of jet brains products before right uh you know there might have been one or two times that I've mentioned ReSharper. So if you would like to have that, but in a lighter weight client where you could, you know, use some of that functionality on your JavaScript, then WebStorm can do awesome things for you. Well, but you want to know what actually sold me on it besides just you?

I mean, because you were a strong contributor to that. There was, so i was also looking at intellij which is you know i think 200 250 bucks for a personal license and i was almost willing to do that simply because it had a database plug-in because i really want to have something to be able to play with postgres well and if you've ever used pg admin 3 it's i mean i hate being the person who just says something stinks, especially when it's free. But I cannot stand that piece of software. But WebStorm does have a database plugin.

And I haven't tried it yet. But I was like, you know what, I'll give this a shot. If it's even halfway decent, it'll be as good as pg admin and so for 50 bucks i have a great javascript slash you know framework uh editor type thing and i i can get some additional functionality so that's i mean for 50 bucks i mean i paid more for sublime you know yeah well i also feel like it's important to note too because the one thing that that you know, your mileage may vary, but for my personal taste, the one thing that does bug me about both IntelliJ and WebStorm is the color palette. To me, it's just not visually pleasing to the eye.

And I'm such a huge fan of the dark theme in Visual Studio. So I've mentioned this before. If you like the JetBrains IDEs, you should go to ideacolorthemes.org. And they have several themes that other people have created that you can view. And these themes work for WebStorm and IntelliJ. And there's some awesome themes out there that you can change uh you can play around the colors because uh you both intellij and webstorm have the darkula theme i believe that's what they call it but that doesn't quite compare you know

isn't quite as nice as visual studios but uh i found some in there that after playing around with some some of the ones that were in there i found one that was close really close enough for me and then with some uh of my own customizations on top of it then it got better you know so yeah i also wanted to mention um navicat is really nice they have a postgres product i've used their um my sql um product before and i think for iOS it starts at $19.99, but you kind of have to buy features, so it ends up being kind of costly if you want to get everything.

Wait, you said iOS? Yep. It might be iOS. I meant to say Mac. The Windows is like $1.49, so it's pricey. I think you mean OS X. So that's kind of what did it to me. There is no OS X. It's OS10.

Okay, OS10. Oh, pardon me. Yeah, whatever. Anyways, so that was the one reason why I didn't grab NaviCat because they don't even give you a trial, if I remember right. Maybe they do. But I was like, $150, man. I can get a full-blown version of SQL Server Developer Edition for $50, right?

It just killed me that I was paying that much for a free quote-unquote database and actually i was right it was ios there is a mac version as well which starts at 149 but yeah ios is only 1999 so wait a second mind doing on your phone then go for it well i guess if you hooked up a bluetooth keyboard to your ipad that wouldn't be absolutely terrible i don't know only mostly terrible yeah i agree well maybe with the ipad pro coming out where it's going to be a bigger screen it wouldn't be so horrible they're rumored it's going to happen man i don't know it's going to happen yeah whatever all right so yeah uh i guess moving on from there what we got next yeah so uh and i finally remembered to go ahead and sign up for connect JS. I don't know if you have or have not,

but if you are in the Atlanta area or are looking for an excuse to come to the Atlanta area, connect JS is happening October 16th and 17th. You can find out more information at connect dash JS.com. I'm looking forward to that one. There's going to be a lot of good speeches there. I'm meant to sign up and I completely forgot, which means

I'd have to pay more if I do it now. We'll see. It's probably not that much more. I wanted to mention something else. Probably most everybody who listens to this podcast, because it has.NET in the title, probably also listens to this other

one dot net rocks what yeah i've heard of that i i thought you were gonna say i thought you were talking about the other podcast when you were saying that they listen to it because it has dot net and i was like wait a minute they probably listen to it because they like rocks it's the other other podcast if you if you get that reference all right so um well i was listening to the latest episode and they had julie lerman on and she is absolutely amazing if you are on or if you've ever been on plural site she does almost all the top rated entity framework uh learning videos and she is absolutely phenomenal like just go check her out now here's the crazy part for whatever reason she decided she wanted to jump in and start messing with Aurelia and so she's talking about it on there and it it was interesting hearing

somebody who is so well known for producing like super quality content and basically feels like she knows everything. Right. And so kind of reason I want to bring this up. She's like the entity framework goddess. She is. She is. Absolutely. She was like a fish out of water doing this stuff.

And it was kind of cool to hear somebody because, I mean, we all deal with things daily that you're an expert at or, or if you're getting into things, I just wanted to bring this up because people say, how do you learn things? She actually goes off and has a long blurb where she's talking about how, you know, the very first thing she did is she would go and download these things and then start listening to the two or going through the tutorials to build the things because, you know, that's how you got the basis of what was going on. And then the next thing she'd do is she would run the debugger as she was stepping through this stuff so that she could see how it bounced around in the framework and how it hit all the things i feel like you're trying to skip ahead to my episode 30 survey results oh really oh i forgot about that oh yeah so so anyways i just go cheating joe i did want to say though i mean the the episode

is about you know her messing with aurelia but there are so many gems in there that she drops and so it's okay for people that aren't comfortable with a particular technology to go pick it up like i mean she she like he said she's the goddess of entity framework and it, you know, it's really cool to hear somebody who is respected as well as she is to say, you know, I hit so many walls trying to do this, but you know, it was her approach to doing it that I thought was really important. So I wanted to bring that up. It was a great episode.

I would definitely go give that a listen and we'll have a link in the show notes. Speaking of links, do you know of any new places where you might be able to find out or listen to us? Oh, yeah. So we had a request. I don't even remember who did it at this point,

but we had somebody complain that we weren't on SoundCloud. So because we want to make this as easy as possible for you guys to share to people and make it available everywhere, we have basically got us a SoundCloud account now. So you can head to www.soundcloud.com slash codingblocks. You can go to our site at www.codingblocks.net and just go to the top of the page and click the link, whatever you want to do. The point is we are now on SoundCloud.

You can download on ios android you can listen directly on the web um and please do you know subscribe to us there now if if that's your thing and uh you know share so i am slowly catching up the backlog because it takes a lot of time to port everything over from you know one host another, but we are now on SoundCloud. Are you sneaker netting it to them? Man, it is manual labor. The app looks really pretty too. It kind of shows the artwork in a cool way,

so if you're listening to the episodes, it just looks nice. Yeah, I've been impressed with it. Not everybody's on it, but it's one of those things. Like, somebody asked for it, and because we can, we're like, you know what, we'll go ahead and make that happen. So, you know, we're excited about it. Hopefully, you guys are as well. So, the next thing I want to bring up, and only Joe has responded to this email. Uh, and so I guess we're just going to respond to it publicly here

was we got an email from Steven Lopes asking about global, uh, variables and when they're appropriate to use. And he actually, in his own email, he went into it to an extent that I thought he did a pretty good job explaining how he would avoid doing a truly global variable. So, um, I, I'll chime in all my thoughts here. So what he was talking about doing was, I know that it's not a good idea to have a global variable and people who don't know why the really the simple answer is you can't control it, right? If you have a global variable that everything can touch then you have no idea what actually touched it right like unless you put in just crazy amounts of logging and that's just a really bad way of going about doing things so typically what you

want to do is if you do have global you know type variables that you need to maintain or whatever he brought up singleton and of course outlaws over there just waiting waiting to scream out at the top of his lungs to the world that yes this is how you do it that is a great way to do it um if you know it's a one way let's say it's one way it's a great way so you can either have that or you can have some sort of object that persists in memory elsewhere that you know things have access to but essentially you do want to control it you don't want to have just a variable out there you want to control how it gets set how it gets you know did you already say the example that he gave uh no i didn't so so just so for everyone

else's edification he says that you know let's assume that we have some sensor that reads the ambient temperature of the room right so there's only the one sensor right so that's where you know my giddiness about the singleton kind of came up but you know jokingly because i know that that's become a thing now but uh but we have images to back it up yeah so so uh you know that that's where it was coming from was that, you know, there's this one thing, right? So how do I share that thing without it being global, right? Yeah. And Joe, what was it? You did respond to them.

And what was your take? Yeah, I did. And what I was kind of thinking along the lines is basically, you know, globals are bad. Okay, if this is an interview, that's your answer. But, you know, they're bad because they break encapsulations not as future proof and you can get around some of the problems of having all this plumbing code with um dependency injection which is like its whole own its whole another big nightmare but what i finally ended up responding with that was actually uh just go ahead and do it as a global.

Because if this is something small and you have things to get done, code's worst enemy is more code. So if you've got this nice little project that's doing its thing and it's working and it's using a global, then so what? You're done. It's wonderful. And if you need to make changes in the future, you can address it then. Joe is cray-cray.

He's off his rocker. This is not the right answer, but it totally is. I don't like that advice, Joe. Did you cringe a little bit when you heard that answer coming from Joe, of all people? I know, right? If I did this, it'd be like five interfaces. It'd be like two months later, I'd stop talking about it,

and three months later, I'd officially tell you that I stopped. So I guess here's my take. I completely agree overcomplicating code from the Git will stop you from coding anything useful, right? Like your 300 interfaces, and you haven't even gotten your hello world thing working yet. There is something to be said about getting the minimal viable product out there. But I feel like even if you decided at worst case scenario to go singleton, at least then you have controlled the ins and outs.

Whoa, whoa. Why are you calling it the worst case? Okay, sorry. Global was the worst case. Global was the worst case the worst singleton singleton actually wasn't the worst case because then you could add some thread safety around the usage of it it's it's fairly actually i don't i i like the implementation of singleton there any anything that's going to have a global counter or or monitor or something but i do not like the global. Just make it global. I can't stand that. That hurts a little.

Crazy Joe. I was like what? You said global? Well while you guys are trying to figure out what to name your silly little singleton I'm done and partying at the beach. Dude no that's simple. I just call it the global singleton. And then all of a sudden

and then all of a sudden you have two things like changing the temperature of this, and you can't figure out why it's 10 degrees off. Or better yet, I might just call it that. You just scroll down a little bit. Maybe I should just call it the Global Helper Util Singleton Library. Maybe that's a good rule of thumb. If your code is small enough to exist sanely in one file,

then it can be a global. Okay. But once you start doing multiple files, then it's too big. How long is that file? 500 lines. We have these stipulations. So yeah,

at any rate, hopefully that helps out a little bit. It was a great question and it sounded like he had already thought about it quite a bit, but you know, we wanted to address it here cause I think it's a little bit. It was a great question and it sounded like he had already thought about it quite a bit, but we wanted to address it here because I think it's a good one. Yep. Also, another email we got, Wesley

Backer sent us a really nice link to some design patterns that he had written up and had some really good examples of. Some ones that we talked about and he had some really nice examples, but the link is broken for me right now, but but i'm gonna go ahead and mention it just in case it's working by the time uh we post the show notes but uh you guys should go check it out if you're interested in design patterns and also uh he mentioned uh view state as an example of a

memento pattern which is a good example we hadn't thought of and i actually got a lot of flack for hating on the memento pattern so uh since the airing of the episode i've gotten uh quite a few people mentioning to me um good uses of memento patterns so i'm sorry if i was down on them please stop yelling at me are you back up now so yeah mementos are cool i give up so alan are you sure because it sounds like he's just doing it reluctantly yeah he's suddenly on board with the memento pattern but you know not because he chose to be yeah i don't know that we can believe this yeah no i'm gonna say i'm cool with it and then make little remarks about it for the rest of my

life kind of like you do with javascript right exactly like javascript that's gonna be great for this particular show ouch that's crazy oh and by the way guys like i see your tweets you know so so when you tweet these crazy tweets about you know when i don't like that we're gonna tweet what we're gonna do before we do it uh and you're not gonna tell me like i see those so in case you don't know what we're talking about like alan last week was tweeting an email like yeah no we're totally going to email meanwhile he could barely talk at all it was like alan are you crazy like why do you think we're going to record so yeah i was planning on recording last wednesday but outlaw so you know nicely pointed out that I was swallowing a gallon of snot about every five seconds.

Wow, thanks for... I wasn't going to bother to mention that part. That was unnecessary. While I technically could speak, it was going to be a rather... It was brutal for me to listen to. It was going to be a tasty sounding episode, so we decided to skip it. Whoa, that's a crazy adjective to throw in there. So, yeah, while I may not sound 100% now, at least I'm not constantly swallowing phlegm. Oh, this is so much better than last week.

This is sexy Alan voice. Good, good. Yeah, I want to mention the reviews, but first I just realized we never actually mentioned what the topic was, but I promise we're getting to one. Okay. Maybe. Get it?

Ha ha. All right. Nice. I promise at some point we will discuss what it's about. Yes. Yep. But not yet. So first, big thanks to all the reviews we got.

We got a ton of reviews this time, so we really appreciate it. You guys have been awesome. Yeah. Both on iTunes and Stitcher. Fantastic. Yep. So I'm going to blast through these because they're awesome. this time so we really appreciate it you guys have been awesome yeah both on itunes and stitchers yeah so i'm gonna blast through these um because they're awesome uh jmm zen oj hawkins j canaro beach and bites gbd 77rc sparkster 314 159 holla mike love very uh we've got 714 Threadsleep and Adidias Rikamar so I apologize

for butchering all of this you guys are awesome that was awesome to see that we got that many new reviews that came in between the last episode and this one but hey for all you people on Reddit, we see you too. All right. So I happen to notice that, uh, you know, we haven't discussed this

before, but there are some, uh, we've been getting some love on Reddit. So I wanted to give, you know, shout out to death row, uh, Tom five, one, seven, one James XV seven and special one out to Coder Hawk and Jesse 2014, uh, for some of the, the, the love we've gotten on Reddit. Big thanks to that. We really appreciate it guys. Uh, and then also we haven't forgotten about you stack overflow specifically you, Andy Joyner. Yeah, you, we got some love there too, we greatly appreciate it so thanks for uh spreading the word we really do appreciate it yeah and he's been with us since near the beginning which is just awesome so yeah huge thanks so for that so that that uh takes me to what i mentioned uh you know kind of hinted at a little bit before which was you know we had the survey in episode 30

and uh you guys haven't cheated, right? I mean, I got to see Joe's face, make sure that guy hasn't been cheating here. I have not cheated on the survey today. I have noticed how he's like hiding behind the pop filter there. Like, I'm not so sure that counts. Okay. So the question was, are you better off spending more time learning specific frameworks or the underlying technologies? I think Outlaw lost.

The first answer was, well, frameworks, I'll dive into the underlying as needed. Or the second answer, underlying technologies. technologies you gotta walk before you can run now i feel like last last episode last episode i think i was the only one that was saying no you gotta you gotta start with the underlying technology right i think like both of you guys were in the framework camp but let's just play the game anyways who wants to give me a guess as to what they think the percentage was let's start with you alan which one do you think won and what you know give me a number i i feel like you're all over there all giddy to to to kill this one so i'm going to say that you won with the language 60 4040. 60% underlying and 40% on the framework side.

Although I think that's crazy talk. Okay. What about you, Joe? Well, since this is a coding podcast, I'm going to say that we cater to and have more voters that are kind of engineering-minded. So I will say that only 60% got it correct and the other 40 chose to run before you can walk.

Yeah, but what's your 60% then? Oh, it's the framework one, of course. Oh, okay. So you guys, just to make sure we're on the same page, Joe is saying 60% voted for frameworks, and Alan is saying 60% voted for underlying technologies. Yes. All right. Well well here's the answer 64.2 percent voted for frameworks i'll dive into the underlying as yeah baby that means that only just under 36 percent of our audience is correct. And that it's the underlying technologies.

Well, see, here's the thing. People that go learn languages just want to learn things. People that go use frameworks want to get things done. So I thought that when you were mentioning Julie Lerman earlier, I thought that this was like a segue that you were going to use to mention this because you were talking about her diving into new new technologies and you know stepping through the

debugger and whatnot but i still like that's just i'm glad that i was wrong about what the percentages were because i feel like now i i have i have a great respect for our audience that we're starting to learn about through our surveys. So I will say this. I still say I was right. So maybe I'll say two things. And the second one being that a friend had mentioned, well, because he kind of put some context around it. Like if you're doing this for, like if this is on-the-job training, right? Like you got to get something accomplished, right?

Then diving into the frameworks is what you're going to do. And it's kind of like, okay, fine. I'll take that answer you know given that context because i was thinking of it more like you know hey i would like to learn you know whatever right like angular you're not going to jump into angular if you don't already have some javascript experience right like you're going to need to know some javascript before you jump i disagree you gotta look at a tutorial oh my god i'm telling you my frame of mind you can't disagree with what my frame of mind was at the time i'm telling you where i was coming from the place that i was in and i still say that i was right in 36 of our audience i'm rounding that up which is with me

and also correct in that you gotta you gotta walk before you run there with the underlying technologies so crazy people yep i i'm glad that everybody made the right decision or most uh speaking of polls uh we didn't come up with one for this episode so i guess you're just gonna have to uh head to slash episode 31 to find out what it is yeah this one's gonna be a surprise and i'm putting this one together so i have no idea what it's going to be well you know you mentioned uh i corrected you on the osx earlier because that's also been one that's come up before a few times like just recently too it was one of the microsoft presentations that they did maybe it was build related i don't forget when and and oh maybe it's for the os 10 or windows 10 announcement

and uh they kept referring to it as os x and i'm like it's os 10 os 10 it's even you could go to the wikipedia page it's os 10 apple doesn't call it os x why wouldn't they just write the number 10 then are they are they too cool are they a roaming company were they were they born in greece or rome or this is just good marketing right here that's that's what that is because Are they too cool? Are they a roaming company? Were they born in Greece or Rome? This is just good marketing right here. That's what that is. Because previously, hey, hey, previously they did write the numbers until it got to 10, and then they switched to the Roman numerals.

They said X looks cooler. And you've got to give them credit. It does. Yeah, whatever. It's OS X. Whatever. It's OS 10. Maybe that should be the survey how do you

pronounce it is it osx or os10 i don't know i might do that because wikipedia is on my side if i can't come up with anything relevant to do a survey about that i will do that one for sure wikipedia i'm just saying all right so now it's it is now time to jump into this particular episode's meat and potatoes. I promise. Yes, he promises. It's OS 10. So what we're talking about today is JavaScript promises. And before we get into a ton of it, I just, first, I want to say, like, this is a fairly big deal.

I think it's planned on being baked into ES or ECMA Script 6. And here's the deal. There are a ton of libraries out there that deal with this kind of stuff. There's Bluebird, ES6, Promise Polyfill, jQuery, which is not strictly to the standard Q. It's K-E-W. Oh, that one. Sorry. Which is suspiciously pronounced like the Q library. Sorry. And then there's suspiciously pronounced like the Q library.

Yeah. And then there's lie. Uh, there's the Q library, which is the letter Q and angular actually uses a, a smaller version of that. And then there's RSVP. Now of all these RSVP,

I think, uh, actually, no, no, it's the ES six promise polyfill one that is basically a subset of the rsvp that very closely resembles the xma6 specs so that's kind of what we took for this particular episode but here's the cool thing right like used to back in the day when you

talk about a javas go ahead also clear up to you keep calling xbox 6 but it's not they've changed the name now to 2015 okay whatever so just saying all right so um here's here's one of the things like you know maybe just even a couple years ago if we were talking about javascript promises or anything javascript typically you're thinking about front end type code right so just keep in mind when we're talking about this now we're thinking about front end type code, right? So just keep in mind when we're talking about this, now we're talking about, it could be server side, it could be client side. You know, if it's, if it's a node type thing, then that could be server side. If it was, you know, any one of these 5,000 JavaScript framework libraries out there, then it could be client side. But these things, a lot of these libraries can actually be included server side or client side. So just something to be aware of.

And so I guess first, what the heck is it, right? I'm trying to sum that up as isomorphic. It is isomorphic. You can have the same language both server and client side, right? Now, so what is a promise? Why does it matter, right? I have two one-word answers to those two questions. Okay. And they're not very good answers, but I want to say them anyway.

So what are promises dot then. That's pretty good. And oh, crap. And my second answer is not one word. But why do they matter? My answer is one inch because that's about how much screen share it saves you. Interesting take on it. That's not true.

I had a different answer, and that was that it tries to solve the callback hell problem by introducing callback hell. Yeah. and that was that it tries to solve the callback hell problem by introducing callback hell yeah so i've actually heard of other people i've heard other people refer to it um as the uh pyramid of of uh the the pyramid of callback doom or something right i like that yeah yeah because as you get your callbacks your code just literally starts like to what joe said starts incrementing like an inch so what he said was an inch could turn into 30 fairly quick but so so to to get back to the serious thing is promises have a venable approach so that if you have an async request, basically instead of having a callback that has a bunch of logic in it,

you just say.then. Hey, when this async request is finished, then run this. Otherwise, if there was an error, do this. So the really interesting part about this is if you've worked with any asynchronous JavaScript before, the way that you would typically do things is, let's say that you had three async calls, and each one of them depended on the previous one, you basically have async call one with a callback. And then inside

that, you would basically have an async call to then with a callback that's now indented over some more and then an async 3 with its own callback now there are some pitfalls to this we just mentioned one which is just your code becomes unwieldy right like there's so much nested code that to follow it is fairly disgusting i mean to answer your question as seriousness though about what they are why they matter you i would put that in is that they that they provide a usefulness for async programming. I mean, yes, that's what it's for. That would be a much better way to sum that up as to what they're doing.

Yeah, and actually. Or why you might want them. Yeah, and I also want to mention one of my favorite things about it is that it bubbles up exceptions really nicely. Yes. Which is something that callbacks have a real big problem with. A problem happens in one of them, and you've got to kind of funnel the scrap out. But with the.then,.then,.fail syntax, then if any one of those fail, it just kind of gets bubbled up like normal synchronous exception handling. Yeah, it's like wrapping a

huge try-catch around all your async calls calls as opposed to when you have the nested callbacks you have to handle it on each level that was another thing that actually wrote in my notes about like when i was describing promises to myself is that it's like try catch on crack that's what it is it's very yeah i mean but it's like it's like because okay so let's take let's take um an example right like if you were going to read some image off of a remote server, right, and you wanted to do it safely, right, you might do that inside of a try and then have a catch handler for it, right? And this is where Alan's.then.fail comes in,

because with a promise, right, you could have the.then. It's actually not.fail, though. Well, okay. It's. then, uh, it's actually not dot fail though. Well, okay. It's dot then comma and then the failure. Right. Right. Okay. But, but, um, right. If you were going to pass, could you pass in like a, uh, a success and a fulfill and a reject method, right? Or a callback. And, and one of them can handle the success portion of it which would be in your try and the other portion could handle if there's a failure which is your catch portion but then you start chaining these things together dot then dot then dot then dot then and that's when i was thinking like of this being on crack because you know the alternative would be nested

tries yes you know which could get going back to your pyramid scheme right of try catches would be crazy yeah it can get really ugly and one so one of the interesting things is and we have an article we're going to link to in the show notes because it's one of the best i saw when we were looking at this but like the approach they took was let's say that you have a book right um and then that book has chapters, and then those chapters have content. So as you're doing this, so you're going to load your book first because that's one async call.

Now you're going to load your chapter list. That's another async call. Then you're going to load the content of those chapters. That's another async call. Well, the problem is, like in the past, like I said, you would typically just start nesting these callbacks. After the first one finishes.

All right, now do a callback and run the next async request. Here's an event listener for this section. Yeah, and it just keeps growing. So like, let's say that at that point, let's say that if you wanted to take it even a step further, that'd be crazier. And instead of loading all the content for that chapter, say maybe you load three pages at a time so that you didn't get a huge chapter that blew everything out now you're going to have even more nested the promises allow you to say load chapter or load book dot then load chapter dot then load content dot then load uh pages you know whatever and then at the end of all that if you wanted to you could put off your catch and say dot catch and then put your error handling in there and if any one of those previous async calls failed it would all get handled in that catch and then it would all basically have

a fail right and then you can figure out what you want to do from there yep and you know what's funny to me is that looking at this, it's really discernible. Like when you see dot then dot then dot then, you know you're dealing with promises. But what's really funny to me is it really does make this asynchronous code look synchronous. It looks like you're blocking on a thread,

you know, like prompt the user. When that's done, run the web service. When that's done, populate the UI with the response. And so it's really masking over a lot of complexity. But what's funny is it really is kind of simplifying things and making it act like you're just dealing with a synchronous program. So let's ask the question then, why is it so hot now?

I think because JavaScript has gotten to the point where it's so pervasive in everything, right? Like back in the day, you know, before all these frameworks got really hot, you know, there were a handful of us out there using Ajax calls and all that. And you just dealt with, with what you did because single page applications weren't all the, all the norm back then, right? Like you might have one or two calls on a page nowadays, like everything on your page is asynchron back then, right? Like you might have one or two calls on a page. Nowadays, like everything on your page is asynchronously grabbed, right? Like you only get the data that you need.

And so now it's a big deal. And so I think that's probably what it is. That'd be my guess. And then also, now you're not just doing it client side. Now you're doing it server side. And when you have a bunch of server side code, like think about database inserts, right? Like, let's just take that for example.

If you are sending up a bunch of data that has to insert a person and then insert their favorite books and then insert, you know, different sections, you all have all these, you know, after this happens, then do this, then do this, then do this. And it becomes really a pain to read and track.

So yeah, I totally agree with you. I really think this is all Node's this, and it becomes really a pain to read and track. Yeah, I totally agree with you. I really think this is all Node's fault, why it's so popular, because the deal is, you know, we've got all this really cool non-blocking async stuff going on in the server, but that's not going to work for me. I need to get the stuff from the database, I need to do some stuff with it, and

then I need to return it. And so, I think, you know, people are working a lot more with Node, and they're doing this stuff with callbacks, which is a nightmare. I thought he said notes. No, no, no. And I was like, wait a minute, like Lotus notes, no JS. You're blaming, you're giving Lotus notes credit for JavaScript promises or anything. So I actually have a little chain here in my notes where basically why are promises in JS such a big deal? And it's because of callbacks. So why are, you know, why do we even have callbacks in JavaScript?

And basically I think it's because there's such a, you know, asynchronous heavy UI model. That's, you know, where the language came from. Yeah, and so I don't, I think we might have put this further down i can't even remember how we have this organized right now but what one of the things to note and i don't think we wrote this anywhere is when you do these promises it's deferreds that you're dealing with so it it so the thing is when you have a dot then,.then,.then,.then, it's returning something back. I don't want to get confused with, let's not call it deferreds,

if you don't mind. Because what I don't want to get confused with specifically is jQuery's implementation. Because jQuery is not the standard ECMA script 2015. But promises actually have deferred. It is deferred. It is deferred. It's called the same thing. But there's also like,

you know, a lot of the documentation you're going to read, just talk about it as an eventual result. And so that's the key is what I wanted to get at. So what you see, what Joe mentioned a minute ago, where it all looks like

it's truly synchronous, what's happening is you are returning back what is called literally a promise. A promise that it's truly synchronous what's happening is you are returning back what is called literally a promise a promise that it's going to either be fulfilled rejected is that that's pretty much it right no there's there's or it could be abandoned four states there's fulfilled rejected pending and settled okay right are the states so before we get into some of that you know the implementation gory details of it, though, let me let me just say with like, you know, we got a lot of love from you guys in reviews in the last after the last episode. And we really, really appreciate that. and you haven't already put up a review on either Stitcher or iTunes or Reddit or wherever,

we would greatly appreciate it if you would take the time and put that review out there. We really appreciate it. It goes a long way to help us out in new people finding us, and we really do appreciate it. And tell a friend. Share the show with a friend or 14. Pick your number of choice. I just threw out 14. I think that's a good recommendation.

And speaking of helping us out, this episode is sponsored 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. So head over to Infragistics.com and download your free trial. All right. So now we can get into the implementation details. Let's do it so so you know we mentioned the the four states of it but what we haven't really said

here that i think is like one very key thing that when we you know when i jokingly refer to it as callback hell or uh you know try catch on crack one huge difference like why you should care about promises is that they do have state, right? Because that's huge. So I mentioned that there's four states, fulfilled, rejected, pending, and settled, right? Now, if a promise has already been fulfilled or rejected, no matter how or when you call it again later, it's going to give back the same result. Right. Right.

It's not re executing that code. It's just returning back the same value that it returned back the first time. Right. Which is a huge difference. Yep. Okay. Yeah. That's,

I mean, that's, that's major. What were you waiting for me to, uh, uh, you, I was, I was, I took a screenshot of your face. Like you were looking at me like, you know, like, what do you think about that? Huh? I don't, I don't know. No, I mean, that's absolutely true because in a callback, you just, you'd basically re-execute it right with? With this, because of what he said right there,

if you try and execute it again, quote-unquote, it's not going to do anything. It's just going to give you back what you already had. So, yeah, that's a big differentiator right there. But you said there was another piece, right, as far as the state? Or was that pretty much where you're going with that one? Oh, no, I thought I pretty much... Oh, there was the four pieces,

the four states that it could be in. Is that what you mean? No, so I guess where I was going with this earlier to stack on top of that, because I wasn't even going to say that, was the fact that when you have these things that look all synchronous, they look synchronous,

but really what's happening is it blew through all that code. Now you basically have a bunch of things that are in some sort of probably pending state until it comes back and is either accepted or rejected. And here's the cool thing. So when you chain together these dot then dot then dot then what you're returning back is you're returning back a promise from each one of those things. So basically this is promise dot then that now is the promise that the next dot then is going to rely on. And those don't actually do anything until the state changes on it to resolve or settled where it was either rejected or what was it fulfilled or accepted?

I can't remember. Fulfilled, rejected, pinned, and settled. Okay, so fulfilled. So once that happens, then it says, all right, let me look at the next thenable function that's there and let me run that. Now, one thing that we kind of glossed over a little while ago that is kind of an interesting piece of this is when you have a.then, and let's just say you have a dot then,

then your function, a dot then, then a function, dot then function, and then dot catch. Basically, what's going to happen is any one of those three async calls that led up to that dot catch, any one of those fails, it's going to skip the rest of those dot thens and go straight to the catch. And then you're going to handle that error. Now, another way you can handle it is every thenable function. You can also pass in a function to handle the rejection. So you can have dot then your function, typically an anonymous function. I mean, you see that a lot. You could pass it anything. But if you have comma and then another function, that is an error handling function.

Now, the interesting part about this is when you have an async dot then and then comma else really for the error, only one of those two gets called. If that async function failed before the dot, then then only the error function is called. If the async function succeeded, then the dot then is called and the error function is never called. It skips it. If you, however, if you do this with the catch, the success function may still run before the dot catch hits. It's, it's really kind of weird how it all works out. And again, in the show notes,

we are going to put a link up to this other thing where the guy actually has a nice flow diagram that will probably take you 20 minutes to read through. Oh, there were several. I mean, there's going to be a bunch of links in the resources that we liked for this episode because when I was doing some research on this, there was one of the articles that I read. The author basically took the approach of, you know, what if we had to create, what if you had to create promises?

How would you create it? Nice. And he starts walking it down like, here's what will be required, right? And here's the next thing that'd be required and then there was another one that was just um uh one of the presentations that was given at uh the js conf in europe and um it he gave a great overview of the uh of promises going from like well why is this a thing so like there's going to be some awesome links, uh, that we'll include in that, but very cool. Um, so here's another thing about promises that I really like, and this is something that I've dealt with for years in callbacks. It's a little frustrating. So let's say that you have a page that you can't display anything on until three

requests finish, right? The way that you would typically handle this back in the days of callbacks is you'd have some sort of variable that a function would manage that was basically a counter to say, okay, how many of these succeeded? I have these three methods, right? When callback one hits and that's done, then I'm going to increment the counter. When the counter gets to three gets to three everything's good all right let me continue on my way right is that a global variable counter no it would be encapsulated singleton counter no no it could be a single i don't think i would use a global but you know why why you got to say the the old days i did this like last week actually you know you know what's funny about that you're

true depending on the type of library you're using if they're not using promises and all they have are callbacks you're pretty much stuck unless you bring in a third-party promise library where you can handle this kind of thing but but i digress um now what's really cool with Promises, though, they have this thing to where you can parallelize a number of calls so that, hey, my three calls, you can basically just say, hey, do this. And I think it's, what is it, promise.all? Where is it? Yeah,.all. I think it's just.all.

Yeah,.all. And that's absolutely amazing. So if you have 20 things that have to complete before you move on about your way, you say, you know, promises dot all. Once this is done,

then do this next thing. And you don't have to try and stitch these things together yourself. Right. That's, that's amazing. Like, I love that. You know,

one thing that I failed to mention that when I mentioned the different states of it and the fact that it's awesome that it's uh you know that because these promises have state and if you were to try to call that value later or multiple times uh and you're going to get the same thing what i didn't mention when i was describing that is that that's immutable uh yeah so so actually that state is that value and state aren't going to change which is uh good and bad um some of the cons actually for promises that i was reading about is that uh it's not so good for recurring type tasks like if you're doing some sort of polling or streaming then because it's imm, you have to be doing this kind of weird, you know, creating of promises and have a little promise factory

shooting these things off and collecting them. Huh, yeah, that's true. Because otherwise you get the same result back every time. Yeah, that's... Yep, and some other negatives I saw were that basically this new spec, even though some of the libraries have support for it, but the new spec, ES 2015 or 6, sorry, there's no way to cancel it.

There's no sort of progress indicator. So if you knew how long a task is going to take, there's this sort of support in the language spec to be able to say, hey, how far along am I? Interesting. Not the end of the world.

It's important when you're thinking about you know using these things to build your next application that's that's definitely something valid to think about yeah i mean yeah going back to that uh that that video from the jsconf in uh it was a it was the 2013 jsconf um europe presentation and it was, man, I hope I don't butcher this name, but Forbes Lindsey that gave the presentation. But he gave what I thought were four really awesome values of promises in that presentation that were why these are a thing, why you should care to try out promises if you haven't already. Right. And one is that it works with the, the primitive control flow, right. Or the control, control flow primitives, right. You don't have to do anything there to make that happen. You can

already work with it. Right. So you have some, you know, you want to use it in a four-inch loop and it can, it can do it on its own, right? And it can handle the errors or let them bubble up properly, right? That was one example that Joe already mentioned, one of the things that he liked about it. And then it doesn't conflate the input with the output, right, when you're dealing with your promises, right? Your code is really clean, and it's's keeping like one thing that I really, um, kind of thought about this was if we go back to solid, right. Or even if you have any, um, familiarity or experience with doing aspect oriented programming, it's kind of what promises

felt like to me too, was that it was keeping the business logic of your methods more clean, right? Yeah. You're not dealing with a lot of business logic of your methods more clean, right? Yeah. You're not dealing with a lot of try catch kind of boilerplate crap, right? You have a method that you're error handler, you have a method that your business logic and your promise allows you to keep those two clean, right? And then the fourth value that he pointed out in this presentation was that your code looks like async code. Yeah. For someone who has never seen this code, has no idea what the app does, and they just walk up to it,

they can immediately look at this code and say, oh, yeah, that looks like asynchronous code, just because of all the dot thens that might be chained together. And I think Joe mentioned that, too. It's like one of the things that he liked about it. So what about other languages uh did a little bit of research because usually when you hear the word promises the person's usually talking about javascript um that or maybe c++ because they're getting some support for that

soon but actually um most languages i looked at had something that took the place of it c sharp had tasks java had um they've got features and proposes kind of coming along in more recent versions um although you're able to do stuff like that in scala or just kind of build in yourself for a long time c plus plus python pretty much everyone's got support for it but a lot of times these other languages have things uh like built in or just slightly different from um javascript like i'm more familiar withNET, so I'm used to having things like cancellation built in. It's kind of cool. It actually returns what they call a task.

So you can start the task now. You can start it later. You can serialize, re-serialize, and then start it. You can do all sorts of weird stuff with it. That's kind of cool, and it works with generics, which I really like. What's also interesting about the task is that it's actually built into the library for

C Sharp or the .NET framework. Promise is more of a convention. Depending on the framework you're using, you're going to do some Googling to figure out exactly how they work. I like with tasks, it's literally a task object. You're using ES6 there, right?

Because then it's in this ES6 specification. Yeah, whenever that is supported by IE8, just let me know. Right. Well, that's why you use a polyfill or one of these other libraries, right? I'm not doing any of that. Yeah, it's not looking good for ES6, for IE8. Anybody that's heard the word polyfill and has no idea what they're talking about, there's basically tons of little libraries out there written to fill in the gaps of things like IE8

or these older browsers that keep hanging around for whatever reason. So that's what a polyfill is. When we were talking about other libraries, though, that this was included in, one that you left off there was uh extjs well that's in the newest version right version six it uh it is es6 it complies to the es6 spec so oh interesting um you know the thing that's kind of crazy about that and i'll never understand why the the powers that be only include certain things so like rsvp is one of the more popular uh yeah that and q are really popular yeah and they left off some of the functionality that

that those libraries add to the table and it's like well why didn't you just wait who's they uh the ECMA 6 board that decides what goes in there the standards body yeah the standards body like I don't understand why they're like yeah that one just doesn't really matter as much you know what I'm saying like why not take the ones that people have decided that they really like and need and just say hey this is it you know it's not like it's that more difficult for these browsers to keep up with them so I guess this is what happens when you're like you know it's not like it's that more difficult for these browsers to keep up with them so i guess this is what happens when you're like you know decision by committee yeah yeah that's a good point somebody's like you should start a committee for something yeah you know as you were talking about promises in other languages though like

you know you mentioned tasks in c sharp and i okay, that's kind of not really close. Totally kind of close. Absolutely. I mean, it really, there really is some awesomeness to it though that, uh, you know, like I said, it, you know, the fact that it does have that aspect type kind of feel to it, right. Where it's like really keeping the business logic of your methods clean. I really appreciate. Yeah, and that is something that you miss out with on C Sharp.

The syntax doesn't look as pretty as the promises do in JavaScript for a variety of reasons. But it's not terrible for static languages about what I expect, but promises in JavaScript is really beautiful. I think a lot of times that's why when people talk about promises, they talk about JavaScript. It just works really nicely with the first class functions and also closures. It just works really well in that environment.

Now, you heard it here, right? Yeah. Joe just referred to something about JavaScript as beautiful. I know. Right? I think he's sick. The weather down there must be getting to him. I think he's got like too much sun are you wearing

a hat or some sunscreen no i had a hair incident and now my head is really shiny and it's hurting my eyes and giving me a headache and making me think that i like javascript you want to know one of the frustrating things when i was doing this like i actually spent some time i was going to put together some cool examples and i was like you know what it would be cool to make something that's not just a contrived example right like what if i go pull from amazon or you know maybe get a list of things and then get some reviews and then i was like man this is really a pain in the butt because now i got to generate some keys i gotta you know i gotta set up a bunch of server-side garbage you want to do anything aws yeah aws is like and i i very much appreciate it that's why you should use jaws this is a real library the job the javascript for aws library oh man but but so here's the

thing right like so you start looking at some of their examples are like well here's a tool a utility to generate some keys but here's the problem people you can't at some of their examples. They're like, well, here's a tool, a utility to generate some keys. But here's the problem, people. You can't expose any of that stuff client side because then everybody's going to steal your information anyways. So you have to, like everything, everything I looked at that I was like, well, I could do this example. And then I'm like, well, I got to go set up some keys and some OAuth things and some private and some shared. And then it's like, oh, God, now I got to do a full blown implementation. And I, it, it just wears you down. So, you know, I really wanted to put together some nice, you know, real life type stuff,

but it is actually fairly involved. Like you start getting into writing an app when you just try to demonstrate this. And that's why almost every article you see out there is say hey imagine you have this book right and then imagine you have these chapters and that's why everything is like that because it's just it's frustrating just in case if anyone should be uh some curiosity should be sparked about that jaws uh comment that i made it's the jaws stack so if you were to go to github.com slash jaws dash stack slash jaws you can find it there yep the serverless stack it's so man everything requires a server and i was like you know what i can do it in node but then it's like man i want to set up a node and do all that because then i'm gonna have to decide whether i want to use express js or whether i want to try to do it in meteor or maybe this is the kind of stuff that runs through my head every time i go to do like a

little tiny project like that it's like and then by the end of it you're just worn out thinking about it and then you're like i can't code anything yep so keep things simple and use globals i think that was the answer that That right there is the answer. Well, I mean, he mentioned a global counter, so I feel like that's fair. Yeah. Boom. I think he needs to go back and change his answer from above.

All right, awesome. So that's about it for this topic. So to recap really quickly, Promises provide really nice quote-then, then unquote syntax that provides simple looking syntax for asynchronous code and it handles exceptions very nicely. And that's a big deal for JavaScript because async programming, I didn't say sucks. Uh, it just is. And, uh, because JavaScript is winning at everything.

But I gotta say though though this is completely off topic for promises async programming is a little bit hard to just talk about and wrap your head around it i guess from a an implementation standpoint because we've talked about doing an episode on it right and we probably will eventually but one of the things that I just really love about it is you can get so much more out of doing something asynchronously like I remember taking a problem that we had where something was taking hours to do and I reduced it to like two minutes using async programming right how right and there's there's very little in what we do yeah that is

as exciting as getting like you know 20 000 returns on your on your effort you know so it'll definitely make you giddy if you've never done it before and then all of a sudden you start paralyzing some stuff yeah and then you're like oh man and then you start trying to paralyze everything and that's a problem so so i mentioned earlier that earlier that there was going to be like a ton of resources that we like links in here. And just looking at our list here collectively between the three of us, there's maybe 11 or so different links. So here's the deal. In our show notes, we're going to include all of this, and it's going to be a lot of information. But you can also from within

your podcast app, you can view these show notes. I know within the iOS app, you just simply click on the quote album art for the episode within the iOS podcast player and then that'll flip over to the uh you know shows metadata and you can see all the show notes there other podcast players have similar um type functionality like on Android for example to get to all that so these links are going to be available for you whether you're at your computer visiting codingblocks.net or if you're just simply uh you know browsing around or listening on your phone and want to browse around while you listen that information will be available and if they're not clickable you need a different podcast app

wow just saying ouch all right uh so clickable on ios there are actually they're clickable in pocketcast as well which is what i use on android and i love that app um so now it's time for our tips of the week week yeah definitely week all right so man i i don't even i stumbled across this recently i just thought it was so cool so back in the day if you had a bunch of xml and you want to turn this into c-sharp classes what you would do is there was like this xsd.exe or something that you could download and it would you know turn through your xml and spit out these these c-sharp classes you no longer need a third part of utility if you are on visual studio 20 what are we 13 or probably above i know for certain this works in 2013 if you go to you didn't try this in older

versions no i didn't okay sorry it might be in 2012 as well i think it is i think that's where i first saw let's just say that you should try this regardless of what version you're in yeah let us know if it doesn't work in your version yeah so either xml or json take either one copy it go into visual studio go to your edit menu and go down to paste special and there will be two options there one for paste xml as classes or paste json as classes And what you will get is so beautiful. It will actually inspect either your JSON or your XML, and it will create a C sharp class with all the serializable tags and everything on it already so that you can quickly take some output from something and map it to an object.

And it is absolutely phenomenal. It works well. So, um, didn't know that existed. You know, I would definitely try that out. If nothing else, just for fun. Even if you don't need it. It's just so cool. I'm really surprised you didn't mention WebStorm

as your tip of the week. That's coming. I have too many tips. All right. All right. So, you know, I love Git, right right we've kind of gone over this one before it wasn't subversion uh you know surprisingly it wasn't so um so here's another get tip for you let's say the scenario is that you committed something okay and you you know what you want to search for, right, but you don't know how.

And when I say that you want to search for, I don't mean that you want to search your commit message, you know, the log for what the commit message was. You want to actually search the content of the commits. Right? So some file has some text in it, foobar, that you want to go searching for, right? So let's say that you want to search for foobar from this file. So you could say, get,p space minus e space and then in

single quotes whatever text you want to search for space dollar sign and then in parentheses get space rev dash list space dash dash all and then space dash dash max count dash, I'm sorry, mint max dash count and then it'll say equal 500, right? So that's the end of your parentheses there. And you have to memorize this. There'll be a test. Right, there's gonna be a test. Yeah, this will not be in the

show notes. You are screwed. Why would you do that? That's so wrong. So again, what this is doing here, right? The first portion of this is doing a grep, and then you're specifying some text here. And you're using the dash E is going to be necessary for strings that might begin with a dash, right? So, you know, it's just safe. It's not going to hurt anything if you added it for other strings, but, you know, it's

definitely going to help you for strings that do begin with a dash. You're going to need that in there. And then the quoting the string isn't technically necessary, but it's definitely a good practice to go ahead and do. And especially these are, you know, going to be handy if you're going to bake this into a script that you might use for some other purpose. Right. And then, you know, inside of, then the next thing we did was inside of that, there was another command that we did, which was the get rev list, uh, dash dash dash

all dash dash max count. And technically the dash dash max count isn't necessary. However, if you have, uh, if your rev list is too long, right? If that, if that's going to return back too many, then what's going to happen is you'll get back an error that'll say argument list too long. And so, or you might get an error that says bad file number. It'll be one of those two. And that's why if you go ahead and just specify your max count, uh, it'll, you know, help you out if to limit that rev that, uh, list of, uh, commits that you're going to go back and search content through. Right. But it'll return back every commit that has that text in it where that pattern is found. Right. And that might be depending on whatever, you know, how, uh, if you're not specific enough, it might return back a lot. But, um, if you're using like,

uh, from command line, uh, within like, let's say the get command line within OS 10, right. You know, it'll go ahead and, um and highlight in a different color, like mine's doing it in red, the pattern, you know, showing you like, this is the pattern that I found in this in this commit. So it'll give you back the commit ID, where it found it, and then the file that it found it, and then the actual string of text that was matched. So I thought that was a really helpful commit or command that I've used in the past when I I thought that was a really helpful, um, commit, uh, command that I've used in the past when I was like looking for a very

specific, like, I know that this used to have this particular class name or string or whatever it was that I was searching for. Where is that? So you're actually searching the changed code. Yes. You're actually searching the contents of the commit,

not the message. The messages are basically worthless right well no i wouldn't say commit messages were worthless and oh by the way that's actually a pretty good one too making your commit messages good because uh oh who was it that sent us uh the the sound the the tag cloud forget uh oh yeah techies yeah that's and's Andy. Yeah. Yeah. Yeah. It sent us the, um, and we already tweeted it,

but we can include that again in the show notes. Uh, I'll link to that, um, where he was making his commit messages. Um, he was basically, how would you say that?

He, he was, he was structuring his commit messages into a particular format, right. To where, uh, one portion of the format was specifying you know how risky this change was one was specifying like what particular ticket or

storyline is this working is this part of and i forget what the other part of the structure was but basically then he could he had a tag cloud plugin that he was using that would visualize, and you could see, like, here's all the commits that might be for a particular story or ticket. Here's all the commits that we deem risky, right? It was a very interesting use of your commit messages. But what I was talking about was not searching your commit messages. It's actually searching the contents of the commit. The code. The code. Yeah, I was talking about was not searching your commit messages. It's actually searching the contents of the commit. The code.

The code. Yeah, I was just kidding. I was just imagining trying to look for something and looking through all these messages like Friday 5 o'clock or whatever. All right, that brings us to you, Joe. Yes, all right. So I heard from Brett at WeWet.com, and he's got a really cool business where you can buy website themes,

but they're specific to.NET, right? So rather than buying a theme off, say, like ThemeForest or something, and then taking it and trying to kind of get that into a MVC project or whatever, you buy these, and they're already set up for you. So you just download and double double click the solution and go. So, uh, I am all about lowering the bar to innovation and getting stuff done.

So that's really nice. So we wet.com, W I W E T.com. Yeah. And they integrate so nicely into visual studio. I don't know if you've already seen this. If you, if you played around with it,

you basically, uh, install it like a, it was a, a nougat package. But then from within, if you've already seen this, if you, if you played around with it, you basically, uh, install it like a, it was a, a nougat package, but then from within, if you go to within visual studio, do file new project,

right? It would show up as one of the available, um, uh, you know, canned kind of, of, of packages that you create and it would go ahead and stub everything out for

you. Hey, Joe, I think you meant lowering, lowering the the barrier to innovation not lower the bar oh man it's getting late when you said that i was like well that's interesting let's make all our apps suck more i'm all for it how did i miss that lowering the innovation bar yeah dude i love that that's actually what our tagline should be no god no yeah we don't have t-shirts that say that that's what i need oh that was awesome oh man yeah so i we also wanted to throw in one uh from matthew walkins who sent us an email

and this one's kind of cool it's uh there is an open source pro uh open source uh program called auto hotkey that that you can basically map hotkeys on your keyboard and i i don't know if he was clear whether or not it was windows or or mac or what but so basically he's got something crazy like you know he does he does something in visual studio and he wants to commit that change. You know, the way that outlaw and I operate is we would then switch over to a command window. We would do a get status.

We would, you know, there's this whole string of things to get that commit. Well, you know, he got tired of doing that. So he mapped this hotkey to where basically he hits this thing. It automatically switches over to his bash terminal.

It automatically runs the commands to actually do this commit. So it's literally almost like a macro runner for your hotkeys. You know what this reminded me of when we read this was, I forget who mentioned it. Maybe Joe will remember it because this came up before where someone was using a gaming mouse that had all the programmable buttons on it and they were programming the functions of the gaming mouse so that they could just click that one button and it would do you know whatever they actually was so like you know builds in in visual studio or you know i don't know whatever yeah it's very much like that and i mean it's pretty

cool right so this was a this was a different version of that except without the hardware requirement yep this is just software that you can download and use just map it to whatever oh he he is using windows so he said currently he's using windows key plus g so um yeah i mean pretty cool stuff i've not used it yet but it's something I will probably check out. And it is open source and it's out there, so you can go grab it. We'll have a link in the show notes for that as well. So yeah. Yeah, so just wrapping up the show, I promise we discussed promises.

And we did. And subscribe to us on iTunes, Stitcher and more using your favorite podcast app. Be sure to give us a review on iTunes, Stitcher. We really appreciate it. Throw some love out on Reddit too. Stack Overflow. We really do

enjoy finding that and really appreciate it when we see it. Or heart us on SoundCloud. i think that's what it is so yeah yeah we have all these places of all the ones you picked right so i think it was a heart so uh also contact us with a question or topic leave your name preferred method of shout out whether that's website twitter whatever we'll mention you on the podcast definitely go visit us at www.cuddyblocks.net where you can find show notes, examples, discussions, and more. And you can send us your feedback, questions, and rants

to comments at codingblocks.net. And make sure to visit us on Twitter at Coding Blocks or check out Facebook slash Coding Blocks. It's blowing up on Facebook lately. It's crazy. It's wild. Check it out. It's like. It's wild. Check it out. Yeah. It's like 100 followers.

We've gone global. 100 followers. That's awesome. I'm going to go post that right now.