Coding Blocks - Thunder Talks

Episode Date: August 13, 2018

Joe's voice sounds funny, Allen has a theme, and Michael pours one out for Media Play as Michael's and Allen's impersonation of Joe is on point (#NailedIt).

You're listening to Coding Blocks, episode 87. 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. Check us out. Check us out at Coding Blocks. That's right. Send your feedback, questions, and comments to comments at codingblocks.net. Follow us on Twitter at codingblocks or head to www.codingblocks.net and find all our social

links there at the top of the page. And Joe has a cold today. I'm fine. I'm fine. Check us out. I'm Joe Zach. Oh, man. Yeah, so Joe's out.

I'm Alan Underwood. I'm Joe Zach. Oh, man. Yeah, so Joe's out. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. This episode is sponsored by Datadog. Datadog is a software-as-a-service monitoring platform that provides developer and operation teams with a unified view of their infrastructure, apps, and logs. Thousands of organizations rely on Datadog to collect, visualize, and alert on out-of-the-box and custom metrics to gain full-stack observability with a unified view of all their infrastructure, apps, and logs at cloud scale. They've got 200-plus turnkey integrations, including AWS, Postgres, SQL, Kubernetes, Slack,

Java. Check out the full list of integrations at www.datadoghq.com slash product slash integrations. Key features include real-time visibility from built-in customizable dashboards, algorithmic alerts like anomaly detection, outlier detection, or forecasting alerts, end-to-end request tracing and visualize app performance, and real-time collaboration. DataDog is offering our listeners a free 14-day trial, no credit card required, and as an added bonus for signing up and creating a dashboard, they will send you a Datadog t-shirt. Head to www.datadog.com slash coding blocks to sign up today.

That's www.datadog.com slash coding blocks. As always, we want to get into a little bit of news and thank those that have taken the time to actually leave us some iTunes reviews and Stitcher. So go ahead, Mike. What you got? Yeah. So from iTunes, we have Detroit++, Joel F., and Artie Chris. Very nice. And Stitcher, we have ARHelogens, This Would Not Fit With Spaces, BMO, Nikora, Wesh, and Jay Carty.

So thank you all that took the time to do that. There were some, there's some truly awesome ones in there. The, the bidet comment. Oh yeah. If you have not heard the episode with the bidet conversation towards the end, then you're missing out on some gold there.

Yeah. I got to agree with BMO on there. He says it's the funniest moment in the history of podcasts, and I think he's right. It's pretty up there. Oh, man. We were talking about it tonight and started laughing. So, oh, man. All right.

So this past weekend, we did get out and do a Coding Blocks community talk with an awesome panel of people, and the topic was Docker and Kubernetes. And so if you go and watch that episode, you'll be able to see, you know, Joe Zach do his Joe Zach impersonation and me do my Joe Zach impersonation. And you can tell us who did it better. That's right. Yeah, that's right. And so we don't have a link for it yet. It's going to be released probably by the time this episode makes it live this coming weekend. So just head to youtube.com slash coding blocks, or if you prefer, you can go to coding blocks.net slash YouTube. Either one will take you to our page and you should see the community talk up there. It was a quite excellent one with Docker and Kubernetes. So if you're interested at all in that, I would say check it

out. And the last little bit of news I have here is I somehow got accepted to speak on a topic at Microsoft Ignite in September. I think it's September 24th through 28th or something like that. 23rd through 28th. The date's not set yet. It's supposed to be a podcast type thing. So I don't really know how this thing's going to go down. But if you happen to be at ignite you know come come hunt me out don't kick me in the shin i'm not that guy that's that's joe well unless you're doing a

joe's act impersonation in which case yeah i don't want to i think i'm angrier than joe's act so please don't kick me in the shin um and so that's that's it for our news and with that we're we're i don't know that we want to call this a lightning round, but we're going to be talking about just several things that we found, right? Yeah, since Joe couldn't join us tonight, he had a lot going on. And so rather than doing our normal tech-heavy deep dives, we thought we would keep it a little bit lighter. Kind of similar to the last one, but since the last one was called Lightning Talks, we were like, well, crap. Thunder Talks. Thunder Talks.

There you go. Thunder Talks. The Garth Brooks other song. Oh, man. I was thinking more along the lines. What was it? It was ACDC? Thunder?

Oh, yeah. Yeah, yeah. Thunderstruck. Okay. You've got the country. I've got the old rock. So I guess kicking it off, one thing that's always been really interesting to me, and I think I've even mentioned this YouTube video before, is the JavaScript event loop that happens. And a lot of people just really do not understand how asynchronous and synchronous

code in JavaScript works. And if you do anything JavaScript related, whether you're programming in Node.js or you're doing things in a browser for a UI or whatever, it is almost hyper important that you eventually take the time to learn this stuff. So I at least want to scratch the surface of it here. And, you know, hopefully Michael has some questions or some things that he wants to throw in to, to at least sort of fill this in. So if you're talking about Node.js, they have the V8 engine that they built, and they have these notions of queues and stacks and all that. And your browser also does the same thing. So there is what is called a call stack in JavaScript. And then there's the callback queue. And then if you're talking about a browser, you have this also web

API stack. And it's interesting because when you write a function in JavaScript and you just do like a bunch of console dot logss in there. What happens is those console.logs will get added to the call stack in the order that they were run. And then basically on every tick, every time that that event loop comes back around, it'll take what's next in the call stack, try and run it. And if it's good, then it gets rid of it. And then it goes back to the next ticket. It gets the next thing in that call stack and gets rid of it. Right. And so in JavaScript, I mean, Mike, you ever see any code where you did something and the UI just completely hangs up and you eventually get that weight.

That's every application. You say it like I should be surprised. I mean, if you guys have ever seen that, like in Chrome, Chrome is like really good about it, right? Like if something sits there and waits for 15 or 20 seconds, it'll be like, it'll send you some ugly picture and be like, something's not working here. You want to just kill the page or you want to wait, right? It's like, it looks like a broken folder or something. Yeah. Dotted out eyes or something. And if you're seeing that, then basically what's happening is something is actually running like that call stack.

It hit something that is taking a lot of time to finish. And it might be processor intensive or it might just be a blocking call. It's really hard to say exactly what it is without talking about some implementation, but that's what's going on. And so really, when you're talking about a Web page, it really has the one thread that basically everything operates on unless you try to push it off to a background thread. And the way that you typically do that in JavaScript is with a set timeout. And there's new ways to do it now with like the later versions of ES6, ES2017 now and all that kind of stuff. There's fetch calls and all that. So anytime you're doing like an async call like to get data, usually that automatically gets kicked off to a separate thread that's not a UI blocking thread. But what happens is, let's say that you do a set timeout, whatever function got passed into that set timeout gets added to a callback queue. So basically

you have this set timeout. Let's say that you do set timeout, my function and 1000. So 1000 is a thousand milliseconds, right? So basically that says, all right, take this thing. And, and I believe the implementation of this was it sees that set timeout. It's going to take the function, which I just called it my function. And it's going to put that back in the callback queue. And now in the web API stack over there that your browser manages, it's actually another separate thing. It has a timer over there that it's going to listen for for 1000 milliseconds to elapse. Once that 1000 milliseconds elapses, then when the event loop picks back up it's going to go back to that callback queue and say all right take this my function call out of the callback queue

move it over to the call stack because this thing's now ready to be operated on and then what it will do as it goes through that any code that was in that my function call those will get added to the call stack and and hit in the order. So if I had five console.logs in my callback function, then it would put them in the order that they need to be called. And on each one of those event takes, it's going to run them and then kick them out of the call stack, right? So hopefully what you see now is there's really,

there's kind of two stacks that are working. There's the callback queue that is things that are running, that are sort of sitting in a background thread right now. There's your call stack, which are things that are going to be operated on, on the next tick, right? As soon as the next tick comes around, then it's going to run the next thing in that stack and then it's going to kick it off the stack, right? And then there's this web API thing that handles other things like timers or asynchronous calls, things like that. Now. So basically you're describing like, you can almost think of it as three threads. Sort of. Is what you're describing?

Sort of, yeah. Or three queues? They're three queues basically. And the thread thing is your callback stack is always going to tie up the UI thread, the main thread of your web app or your Node.js app or whatever that is. That'll always tie it up. When you do something like a set timeout zero, if you've ever seen that, basically what you're saying is, okay, I have this function that I want to happen as soon as I have some availability, right? So let's say that you had some method that added 20 different calls into the call stack. And now you call this set timeout zero. Basically what's going to happen is it's going to put that set timeout zero over into your callback queue. The timer is going to be set at zero, which means that it's really not going to do anything. And then it's going to take that thing out of the callback queue and then put it at the top of the callback stack or at the end

of the stack. So, so basically it's saying don't interrupt everything that needs to happen. If there were 20 items that were about to run, don't try and shove it in there. Wait until those 20 items are done and then do what I need it to do. So that's kind of a, that's kind of the way that people have, have made things happen in a way that won't interrupt the UI thread. Now, here's the thing that's interesting about it. If you've ever seen, like if you just search on Stack Overflow or something on how to do like a timer in JavaScript, typically the answer that you'll see is, you know, just have like, say that we have a ticker that we use for the show. Right. And I've never looked at the implementation of this and I don't want to dog on Joe Zach if he did it this way.

But the way that this timer works is, you know, it refreshes or shows on the page the new time, the amount of time that it's been running. If you have a page that does a set timeout and then says, hey, go update this screen, right? Basically, what happens is after a second, then it's going to go in and try and run this function that tries to update that text on the page. Now, here's the kicker. Just because you say set timeout 1000 does not mean that that is going to happen exactly one second later. So think about the situation where you have a long running thread in your call stack. It's going to take 20 seconds to complete, right? But then you did a set timeout of 1000 milliseconds to update your timer. What's going to happen is that thing will, at the end of that one second, it'll be pulled out of

that callback queue and it'll be pushed onto the callback stack. But if there's something over there running that takes 20 seconds to, to handle its thing, guess what? It's going to be 21 or it's going to be 20 seconds before your callback is, is executed. So if you're relying on the set timeout to do like an incremental counter or something, then you could easily get out of sync. Like if you have a bunch of things going on a webpage, in this case, our timer, there's nothing on the page except for that. So chances are if it's getting out of sync, it's a tick in the CPU cycles, which is nothing, right? But it's worth knowing about that because, you know, a lot of people just take it for granted that, hey, 1,000 milliseconds, this is going to run in a second. No, it's going to run after everything else in that call stack finished, and then it gets to that one.

So one thing, though, that I'm trying to, like, follow along here is it almost sounds like what you're saying. Because when I think of a stack, right, I think of something something like uh you know whatever's on the top of the stack gets popped first yep right and so when you're saying that the callback queue is going to get added to the top of the stack the callback queue is almost like a way to like get something to pop to the top quick uh so the callback queue if you think about it like this, if you had a bunch of, let's say that you had a bunch of set timeout one thousands and you just added them all, it would be a FIFO type, uh, queue first in first out. Yep. So, so basically the same thing that you're thinking about, the first one would go on there. Then the second one will go on top of third, whatever. And then after that event loop comes around and it finds it, it's going to be like, okay, well, this is the next one that goes over to the call stack. And it'll start taking them out first in, first out. But a stack would be LIFO though, right? Well, that's so.

Like the queue would be first in, first out, but stack would be. It's a first in, first out. It's a first in, first out. So. For the call stack. For all of them. Oh. So I say for all of them, all things being equal, if you had a set timeout of 1,000 and then a set timeout of 2,000, remember what happens. There's a timer that goes in that will then move things into the queue when it's ready and then move them link to this session stack, which I don't think I'd ever even seen that one before.

But they had a really great write-up of how all this stuff works. And then I've got a link to the YouTube video as well where this guy goes through all of it. And he actually has animation showing, which they do on this other blog post as well. But it's just worth knowing that when you call these set timeouts and all these kind of things, it does put it on a background thread. So it's non-blocking, but at some point it's going to have to do the work, right? And that's where it's going to hit the call stack. And if you're not handling things in a manner there that doesn't block the thread, then you could also end up with other things. So set timeout was the way to make things happen asynchronously. There are other things like if you're doing an AJAX call or an async call, those also

happen on another thread. What else do I have in here? Although it seemed like there was a comment that I saw in one of these pages where it was like, you could technically run them synchronously. You can. Never do that. Yeah, don't. Because so basically what they said is when you call like a fetch, you can actually tell it async false.

And the problem is, is that that straight up blocks your UI thread. Right. So if you have something that takes five seconds to run, you can't do anything on that page at all. And it's probably not doing anything helpful. Yeah, I mean, that's good information because it's certainly in the JavaScript world something I've totally taken for granted, I'm sure. I've never bothered to care about how the event loop works in JavaScript. And that's the thing. I guess that's what, if I'd never seen that video a while back, then it probably wouldn't have stuck in my head. But

when you start Googling for answers, when you're trying to do something, like you have something hanging UI thread, everybody's like, I'll just do a set timeout. And they treat it like it's a magic bullet. But here's the thing, right? If you do that, there are, if you have a long running thing that happens, you could still potentially block the thread. You're just kind of postponing when it's going to happen by doing set timeouts. It reminds me of, did you ever do any Win32 programming? Not much. So, I mean, basically some of the stuff that you were describing kind of reminded me of that world, right? Where like in the win 32 world, there was this main loop that would run and every time there would be an event,

like you could say like, Oh, that's an event that I want to care about. Otherwise, you know, you would just skip it. Right. And that's what it kind of sounds like to me. And so like by default, you were single threaded and so you could lock up that thread. But in that win 32 world, you know, you were, the onus was more on you if you wanted to spin up a new thread. Whereas in, you know, a lot of the language, not just JavaScript, but a lot of the languages that we're in now, it's far easier to spin something off in a separate thread without really putting a lot of thought into it. Right. So like, you know,

the whole idea that set timeout is going to go into this callback queue that's on its own clock, you know, versus versus the call stack. You know, you're not really going to think about just like with the thread pool. I think we've talked about the thread pool before in like a C sharp, for example. Right. Like, you know, you didn't really have to like put a lot of work into it to get the advantage of those threads. Right. Yep. And that actually reminds me of what you just said. So one of the key parts to understand here is if you do something that your system's waiting on. So for instance, I make a call to my backend, right, to get some data and I do an async call to that. Typically what you do in JavaScript is you pass in a callback, right? Or if you're using promises, save type principle, but whatever, what happens is that gets thrown over to the web API stack or thread.

And then that thing is going to do its work. And as soon as it gets data back, then it's going to stick the callback and the callback here, then it'll get moved over to the stack. So it's just interesting how it kind of moves along the thing so that you're not blocking when, when you're waiting for things. And there was something else that I found in here that I'd never even heard of. And it's a new ES6 feature and it's called Jobs. And what they said is, and I was trying to read this, I haven't seen any examples of it, but it sounds like it's similar to calling a set timeout zero. Basically meaning, Hey,

run this thing, you know, as soon as you can type deal, um, except that it gives you more control over when the jobs run. And I didn't see any details or examples of it, but something that I'll probably dig into at some point and, and maybe come back with some information on. Yeah. Or that, or maybe it's just something that they named after Steve. Possibly. Steve Jobs Q. Yes. Does that mean he's coming back? It only does one thing, but it does it really well. There you go. There you go. So yeah, that was, that was my first semi deep dive. I think hopefully that gives a little bit of insight into how it's actually doing things in your JavaScript engine and your browser and server environment, whatever's running the JavaScript. Yeah, so... Oh man, I lost my article now.

Dang it. Let me see if I can find it again. I had this article that actually, uh, Mike RG from our Slack channel shared with us. Is it Mike RG? I always call him Mike RG. I don't know what it is. Well, now I'm on the spot.

I mean, one, you're asking the guy who mispronounces every name. So of course I would mispronounce Mike, right? Uh, you ain't right. You've only owned it for a couple years.

Yeah, you know. Thanks for driving the bus over me. Sorry about that. Okay. So we were talking about complexity in several algorithm episodes. We had talked about several algorithms, and we talked about their complexity in regards to time and space complexity. And, uh, he, he sent me this article actually, well, he sent it to all of us. It was in the Slack channel. Um, this article that Jeff Atwood wrote, it was really good. It

kind of puts things into perspective. And, you know, at some point I'd like us to do a deeper dive on big O, but just to quantify some of this, I thought it was really interesting. So Jeff Atwood put together this table where he summarized, there was another guy, Tom Neiman, who put together this table of what these things would be. So depending on the size of your N, what it means to have log N or N log N or N log squared or N factorial. And then Jeff Atwood took it a step further where he adds time to it. Nice. So I thought this could be a fun little game to play.

So the choices that both of these tables go from for the size of N, they are basically powers of two, but they skip a lot. So it's going to go 1, 16, 256, 40, 96. And then I'm going to like truncate the, I'm going to abbreviate the rest of the numbers. So 65,000, 1 million and 16 million. So just know that those are all powers of two. So when I, when I say 1 million, you know know that those are all powers of two. So when I say one million, you know what that is. Okay. So the point that Jeff Atwood was making with this article and why Mike sent it to us is that when we were talking about complexity regarding some of

those algorithms is that everything is fast for a small n, okay? So if your n is one, well, then log of n is zero, and n log n is zero, and n squared is one, n factorial is one, like, who cares, right? So in regards to seconds, those would all be less than a second, right? So who cares? So let's see where,

let's see where we get interesting here. Let's say if something is, if, if N is 16, let's do, let's do quantity first, right? So N is 16. N squared off the top of your head. Not fair. Trick question. 10 times 16 would be 160. So man, I don't know. 256. 256. All right. Okay. So I skipped over log N. I skipped over in log in. We went straight to in squared. In factorial. Oh, man, that's huge.

16 factorial? I have no idea. That's massive. 20.9 trillion. So for in factorial, all right? Now, we're not talking about like, that's just, you know, whatever the steps is now. So in this table, Jeff says, okay, let's say that each, uh, you know, for sample execution

times, assume that each one unit of execution time is one millisecond of time. Okay. Okay. Okay. For N16 again, okay, N squared, we said was 256. What do you think that is in terms of time? That's a quarter of a second. Okay.

Well, less than a second, so yes. Yeah. Okay. N factorial. I don't, two trillion? I have no idea. That's going to be 2 trillion. So I have no idea that's going to be 2 trillion. You take off three zeros and that gets you in the millions. Oh, that's like 2 million seconds. No, 2 billion seconds. I'm sorry.

2 billion seconds, which I have no idea what that would be in terms of actual minutes. I'm going to see if you're close. I'm checking your math here. which I have no idea what that would be in terms of actual minutes. I'm going to see if you're close. I'm checking your math here. Well, I hate it when it's written in exponents because I never think like that, but I think you're pretty close. 663 years. So if we said that something executed in infactorial time, and let's say that your array that you're passing into that function only had 16 elements in it, it would take 663 years to finish that small array, right?

Not too good. Okay. So let's skip around to what if it was, what would be a good one? 65,000. No. Yeah, let's do 65,000 in login. Okay. So, that's going to be, how many times is that? To the 12th power, 12 so if we're if we're talking about

in terms of the like what the math would be for that number then we're at 1 million okay now this is where the power of of the logarithms come in because remember we said we talked the logarithms come in. Because remember we said, we talked about logarithms before and we defined them as like a magnitude. Right? So n log n where n is 65,000 if each one of those units was a millisecond

of work. Do you have an idea? At a million, that's a thousand. n is 65,000. N is 65,000. And we said N log N? N log N.

If N log N, N is going to be to like the, I think that's 12 times 12. Maybe a couple minutes. 17 minutes. Okay. So look at how drastic that is, right? For n factorial, where n was 16, we were 663 years. Years. But as soon as we went to a logarithm, we went n log n for 65,000.

We dropped it down to 17 minutes for it. That's significant. So when we talk about, you know, the, the complexity of something being in login versus in factorial, that's huge. And when we talk, describe like that big old cheat sheet, for example, a big old cheat sheet.com where you can see the graph of these things. And we talk about in factorial being a hockey stick that just shoots almost straight up right away, right? That's what we're talking about. It doesn't take much for it to go infinite, right? If you go up to...

Well, let's put that in perspective, right? So let's say, so you said 17 minutes if you did n log n. If you just did n time, so this is in milliseconds, so let's divide it by 1,000, and then that's how many seconds? Well, if it's 65,000 milliseconds, it'd be 6 1⁄2 seconds. Yeah, that can't be right. Why wouldn't it? No, no, no, but n log n would have been way less than just n. Yeah, but it's n times n log n. n times n log n.

Yeah. I mean, n times log n. Yeah. That's what I meant to say. But I guess what I'm getting at, though, is that would be way faster than n time, I would think, right? No, n would just be constant. Yeah, so 65,000 milliseconds. So 65 seconds.

No, 65. Yeah, so 65,000 milliseconds. Six and a half seconds, right? Am I wrong? 65,000. Maybe I'm wrong. Yeah, no, I'm wrong. You're right.

Yeah, 65 seconds. So it would be a minute and five seconds, basically. Okay, so the n log of n was actually longer in this case. Well, yeah, because it's n times the log of n. Yeah. But if it went way up, like if you did a million, then chances are at some point n log n will probably beat n, right? Is I guess what I was getting at.

Well, how could it ever do that? I don't know. n would always have to be faster because it's not a multiple. In log in is a multiple, right? Like you're taking in and you're multiplying it by the log of in, but the log of in is usually really small. I guess is what I'm getting.

Oh, I see. I see where you're thinking. You're thinking like if it went less than zero or I'm not less than zero, less than one, if it was a fraction, then it would become like a divisor. Yeah.

So basically that's what I was saying is like the 65,000 didn't work, but maybe if you got into the millions or whatever, at some point, the log of N is only going to be 20. Whereas the, the N, the constant is a million, right?

If you're going after a million. So that's, that's what I was getting at is at some point, the whole point of the log of N, which we talked about before was it's base two, right? So it's how many times it's two to what power gave you 65,000, right? Well, if you're doing base two, yeah. If you're doing base two, which is I think what the big O notation uses. And so at some point, as your N scales up, your logarithm will actually beat N time, even within log N. Yeah.

I just don't know what that inflection point is. I mean, I see where you're going with that. It's not going to work out for you like that on this chart. All right. So there's your hint. I'm going to give you one last one. All right. Let's skip down to the 16 million and I'll give you your choice. We've talked about in login, do we want to do N squared or do we want to keep it back on in login just to stay on the same scale as what we've already talked about? Well, N squared, let's put this into perspective on what that means.

That's usually a loop and another loop, right? It's usually a loop within a loop, right? It's two loops, which is very common in your everyday to day programming type stuff you see. Yeah. Let's go with N squared versus N log in or whatever. So, so N squared is going to be in the middle between our n log in and well not exactly in the middle it's going to be somewhere in between i should say n log in and

n factorial in terms of performance of course yeah okay but but i'm just letting everybody know like that right you know n squared is still going to be a hockey stick. It's not as much of a hockey stick as N factorial. Okay, so if you have N is, let's say, an array, and N represents the size of that array, and it's 16 million to the power of two, so it's actually more than that, but it's 16 million items in that array, then...

I don't even know how many numbers that's going to be. That's exponent. So squared, because I don't expect you to know this number off the top of your head, $281.4 trillion. That's it? That's $16 million squared. Okay. Well, it's like 16.7 blah, blah, blah.

Okay. Okay. Now. Oh, but factorial is what I was thinking about yeah yeah sorry that's gonna be greater than a google at some point i should clarify too that when you see this chart there are parts of it that are just like marked as dash because they're basically like infinite like infinite space infinite time. It's not popular. Never happened. So like 16 million for N factorial? Forget it. It's not happening. All right.

So 16 million N squared where each one unit of execution time is one millisecond. How long do you think it would take to process that in N squared? Just guess. That was 25 trillion. Let's go. No, it was 281.4. 281.4 trillion. And we did two, that's 6,000 years.

That's not a bad guess. 8,923 years. So when the next coming of the dinosaurs are here. Pretty much. So the point is, though, is that really what Jeff Atwell was getting at in this article, though, is that you can look at some piece of code and some algorithm or whatever, and yeah, if all you're testing with is small amounts of data, you can look at some piece of code and some algorithm or whatever. And yeah, if you, if all you're testing with is small amounts of data, then it's always going to be fast,

right? Because no matter, no matter how bad you write that code, right? It's going to perform well with under a small load under, you know, with a small amount of small amount of data. So it's important to test things at the scale that you think is realistic

to your application. Yep. Right. Like you don't, the last thing you want to do is to develop something and then wait until you get into a production environment with real customer loads on it and real customer data and the size of real customer data before you realize like, Oh, that thing doesn't perform well at all. Like, you know, for whatever the reason is, right. I mean, there could be a bunch of reasons behind it, but yeah, but you don't want to do it that at that time. So yeah, it was kind of like making me think like, um, I had this way of summarizing it

where it's like, don't, don't confuse load testing with unit testing. Oh, that's a really good point. Right? Like those should be treated as two separate parts of your process. What you expect to get out is different than what the performance should be. Yes. Yeah. Yes.

Yeah. I like that. So, yep. So that was a big thank you to Mike. Mike RG. Man. And you know what? He's actually getting another shout out later in this episode.

But we've mentioned it before. If you're not in our Slack channel, like he's in there. He's always dropping awesome nuggets like this everywhere. Like he sprinkles them out throughout all the channels. It's not just general. It's in tips. He puts this everywhere. Like he sprinkles them out throughout all the channels. It's not just general, it's in tips. It's he puts it everywhere and he's got some good bourbon choices as well. So,

you know, uh, definitely come join us at coding blocks.net slash slack if you haven't done it. All right. So I had a theme for this episode, at least for the first two topics. Was I supposed to have a theme?

No, I went wrong. So you know what actually started all this is I've been getting back into parallel programming or threaded asynchronous type stuff in my C sharp world. And that's way more complicated than JavaScript in terms of just having to wrap your mind around what all is going on. And then I was like, you know what? I haven't looked at the JavaScript stuff in a while. So that interest kind of trickled back over here. So did you even know that ECMAScript 2017 is a thing yet? Did you know? I mean, I think I heard about it on, I think we

mentioned something about it on the last episode, didn't we? Maybe I heard someone say something about it. I don't know, man. So here's the thing. So we've talked about ES 2015, and it was just surprising to me that we've jumped ahead so far already because for years, JavaScript didn't change. It was like, what, over a decade, wasn't it? Yeah, for like a decade,

it was stuck at four or whatever it was. And so now it just seems to just be bolting ahead because people, one of the articles I read said that, uh, JavaScript, I believe is one of the most, uh, committed code languages on GitHub right now. So, I mean, yeah, it's just taken off like crazy. So going back to the async stuff that we were talking about earlier and running things on separate threads, I came across this async await in ES 2017, which I was like, well, that looks eerily familiar to some C sharp that I like. And there's a couple of really good write-ups. There's one on javascript.info slash async dash await that is really good. And I think they summarize it extremely well. So here's basically

in a nutshell, some of the pieces of this. If you see the word async before the word function, then that means that the function will return a promise. This is using ES 2017. Now I will say before I get into this a little bit further that I was surprised at how many browsers already support ES 2017. The only one that didn't was IE, which is not surprising. IE hasn't been released in years, right? Edge is the new stuff. So yeah, I was surprised. Now, granted, you have to have certain versions of the browsers for them to support ES 2017, but yeah, they, all the major ones do. Now if the function is returning a value rather than a promise. So let's say you have async my function and then inside there you have return

one, the JavaScript engine itself will actually wrap that thing in a promise and then do a promise dot resolve. So it's kind of interesting. It forces it into a promise. then do a promise.resolve. So it's kind of interesting. It forces it into a promise if you return just a regular value instead of returning a promise from that method or that function. Wait, say that again. Normally, it would prefer you to return the promise, but if you don't, if you return back an integer or a Boolean, it'll put it in a promise. It'll wrap it for you. Yes, it'll put the promise around it. So basically, if you think about the way that you do promises,

you'd have like a, you know, you call something and you say.then, it makes it thenable. So if instead of returning the promise that you should have in your method because you had an async function, it will actually wrap it in a promise for you so that you should have in your method because you had an async function, it will actually wrap it in a promise for you so that you can then do a dot then on it. So pretty interesting. Now, very similar to C sharp, the await keyword can only be used inside an async function. So if you try and use a wait in something that didn't have async prepending the function name, it's not going to work. And basically this is very similar to C sharp again,

in that it tells the JavaScript engine to wait until the promise has been resolved for that method that was called. So if I, if I say a wait, you know, my async function, then it's going to sit there. And if it takes five seconds for that thing to finish, it's not going to continue to the next line of code until that's done. However, it's not blocking. It's still running it on a separate thread, but it's not blocking anything. So once the promise is resolved, then JavaScript will pick back up at the next statement.

It reminds me of the yield return in C sharp. So that's kind of cool. Actually, it's very similar to C Sharp in the await there as well. Yeah, it doesn't block. It literally just lets the thing run, and then it won't go to the next statement until it finishes. And I think it might even use yield. I don't know. Behind the scenes.

So now here's one thing that's interesting. And this kind of makes sense. If you think about it, it says that the await cannot be called directly from the main body of a script. So, you know, if you were trying to do it in the global space of your script,

you can't do it because you can only use a weight inside a function that has been decorated with async. So you can't do that. That kind of makes sense. Yeah. It makes sense after, after you hear it and you look at it. It's like, okay, that's cool.

So here's the really cool part. The await works with the existing then and rejects on promises. So it's kind of cool. What does that mean? So in – I would await.then. So if you – I would dot then. So if I would await method dot then. It's the same as throwing an error.

So it's interesting. If you remember, like in a promise, you'd have a promise dot then. And then if you did a comma after your first method in the dot, then your second one was, hey, if it got rejected for some reason, right? You can actually write a little bit bit in my opinion, prettier code. If you do the await, but you do the await inside of try catch. If, if it gets rejected, it goes into the catch block. So it's, yeah, it's basically then the same as a throw. It throws an error, basically.

So the rejection is an error, which if you think about it, if I remember right in the promises, there's dot then success, comma error or failure. Right. So it's the same type thing. So your await would be you do a try await. If everything succeeds, fine. Otherwise, go into the catch block if it was rejected. Still trying to catch up with you there. So if you think about it, if you had a promise, you might have promise.then and in parentheses you'd have on success, that'd be your method call for success,

comma on failure would be your method to handle the failure, right? The equivalent using await would be try, open curly, await, some method, and then in curly, catch, open curly, handle the error, close curly. So it's almost like you're not doing the resolve response type of promise syntax or however you want to call it. Well, you don't do that second error one. It's handled in your catch statement as opposed to the second method. So it's a little bit cleaner. You're saying that you think that's cleaner because it's separating the concerns. It separates the concerns. It separates the concerns, and it's also, when you start looking at the promises and all those kind of things,

you just have a bunch of anonymous methods all in one place, right? This, to me, is a little bit more terse and easy to see that, oh, okay, I'm going to try and await this thing, and if it fails, then just go into the catch block, like most of your other code. So it's not like a special one-off case, I guess. Okay. So that's kind of cool.

And then the... Basically allowing you to have like one catch handler for multiple, like, quote, promises. Because you could wait multiple times inside of that try. You could. And you could have one... Catch. But you could do that

with a promise of two there right you can't it has a fall through yeah there's like a dot any i think yeah down at the end you can actually have it fall through the promises we we covered that extensively in an episode a while back but but yeah now dot all i think is the one i was thinking of right dot all so dot all is when everything resolves. Yeah, everything has to resolve. And if any one of them failed, then it would go into that. So, you can actually do that as well. You can use an await with a promise.all, and it will continue when all the promises have resolved. So, that's pretty cool.

Like, you can use it interchangeably with the things that you've been working with with promises for a while. But am I wrong, though? It sounds like the point of this, though, is to try to move away from... Promise.then. Promise.syntax. Yes. You know, like you're trying to make it a little... It's using promises behind the scenes without you needing to worry about that implementation.

So while you could do a promise.all, await promise.all, maybe you need to. Maybe, maybe not. But here's where things got interesting, that this article didn't point out that I found on Mozilla, which, by the way, their JavaScript documentation on Mozilla.org is always awesome. That's the place you go. It's fantastic. It's either that or Stack Overflow. That's just the truth. I'm speaking truth.

For the documentation. That's awesome. So, so when I was reading through this, I was like, well, let me take a look at this. And they actually had like a big red box on the page.

And I was like, danger, Will Robinson. No. So here's what's awesome here is they say, do not confuse a wait for promise dot then. And here's why. And this is they say, do not confuse await for promise.then. And here's why. And this is where it gets really excellent.

So, in a nutshell, await tells JavaScript to actually pause until it's done, right? So, if you have three await calls in a row that each take three seconds to complete, it'll be nine seconds before you reach after that code, right? So a wait three second call, a wait three second call, a wait three second call. It's going to wait three seconds for that first one before it goes to the next one, three seconds from there to the next one and three seconds and then on, right? So would you call a wait? It's actually pausing and not going to the next statement in that method or whatever that is until it finishes that first await. Right.

So if you were to take those three calls and you made them a promise, then they would actually run in parallel. for instance, where you had await my three-second method, instead you said my three-second method dot then, and then you had another, my other three-second method dot then, and then my third three-second method dot then. Okay, so just to be clear, inside of the then, the argument being passed in is the my second method? No, no, no. Let's just say there are three different methods. Oh, there's three separate lines of code.

Three separate lines of code. I'm just calling them three different method names to keep it clear so that it's not mixing that up. Method one, method two, method three. Right. Method one, two, and three. Each one will take three seconds. If you did await method one, await method two, and await method three, it's going to wait three seconds for the first one finished, then three seconds for the second, etc. If you do a method one dot then await method two, and await method three. It's going to wait three seconds for the first one to finish, then three seconds for the

second, et cetera. If you do a method one dot then, method two dot then, method three dot then, it fires them off in parallel. It doesn't wait for them. It adds them all to something to start operating immediately. Okay. And then when those things finish, then you'll get the callback in the dot thens. Well, that was something I was wanting to go back to when you were talking about the await versus the promise.all, right?

Because it almost sounded like you could accomplish the same thing in your try-catch, just doing an await for each one of the things. And then with your single catch method, or I don't want to call it a method, but your single catch block. Your catch block, right. Right? or not, I don't want to call it a method, but your single catch block. Catch block, right. Right. But the disadvantage there, it was what you were saying, because then you're waiting for each one of those sincerely to execute. So depending on how long they're going to take, whereas the advantage of the promise.all is that they would run in like, you know, quasi parallel time.

So it's interesting. Yeah. The part is if you didn't await on a promise.all, that's almost like doing the promise.all.then, right? That's not really going to change. But when you do await, await, await, even though each one of those await calls is running asynchronously, it's going to wait until that finishes before it

moves on to the next asynchronous task, right? Whereas if you just do the promise.all, promise.all, promise.all, then it's going to run those things all as fast as they can, right? And it's going to do the callbacks as soon as they're available. Now, if you have something that relies, like, let's say that, you know, something at the top of your method relies on something further down or something further down relies on something at the top of the method. That might be a good, good opportunity to use a weight up at the top. Right. So you say, hey, my user equal a weight. Go get user.

And then further down, you're going to use that user variable to do something. That's a perfectly good reason to do it that way. If you need that user though, further down, and you just do a promise.then, then you're going to have to start nesting things right inside that.then because that user is not going to be available until that promise finishes. So it really, it's one of those things that you don't want to wholesale just replace your promises, right? If you have things that you need to run in parallel because they just need to be fast and you don't need the output of them, promise them, right? And just go fire them off. If you need the output of one of those async calls further down in your method signature

somewhere, then that's probably a really good point to use await. So there's good uses for it. Don't just, I, my point here is don't go blanket replace everything with, uh, with async await. It's a very nice thing and it allows you not to get into, you remember the callback hell that we called it when you call async things, you can the callback hell that we called it when you call async things. You can sort of get into that with promises too. If you just keep saying dot then, dot then, dot then, and you know, 20 down, you're there. This allows you to do that cleanly, but you have to know about the trade-offs. So, Hmm. All right. Well, how about this one for a JavaScript one? There was another article that I found on Dev2, and I thought it wasn't kind of fair, but I've seen this question before asked, and this is going to be in parentheses. So picture like one parentheses block can a equal,

equal one and, and a equal, equal two and, and a equal, equal three equal true. A equal, equal one. Oh,

are we saying ampersand ampersand? I'm sorry. Yes. Maybe I should have made a picture. This is JavaScript and you have a statement that says something like if, and then in parentheses, I'm not going to say the parentheses again. If a equal,

equal one ampersand ampersand a equal, equal to ampersand ampersand a equal, equal three. I know this is a trick question, and I can't think of how that could be true. Okay. So I've actually seen this before. Now, in the spirit of the article,

I kind of, in fairness, didn't like the take that he gave on it because basically he was saying like, oh, hey, well, depending on what your font is, there are these like non-printable characters in like this other, you know, language. I don't remember what the dialect was, but you know, some weird Korean symbol that is basically unseen, but it would be technically before. So what he was saying, his trick to it was that you have this Korean symbol in front of the A and then you have the, you know, front of the A, and then you have one of the A's doesn't have the symbol at all, and then the third one has the symbol after the

A. So you have symbol A and A and a symbol. Does that make sense? Yep, it does. And I didn't like it, because I was like, that's not in the spirit. I've actually seen this once before, and there's a much cooler part of this where you could do it right so um there were there were two the two top responses to this article where one of one of them was you could have uh a value of function on a so you define a as a constant with the value of function on a, so you define a as a constant with the value of function. And anytime you are returning it, you're incrementing some value. Nice.

Right? So, so it would read like const a equals value of function. And then you're going to define a function where you say, let X equal one and return a Lambda X plus plus. And then you're going to close out of that. Um, cause that value of it's an iffy and then you're a, so every time you're calling a, and it's getting in the underpinnings of JavaScript or get getting the value of it,

it's going to be incrementing that thing each time. So the first time a is going to be one, then the next time it's going to be two is next time it's going to be two. It's the next time it's going to be three. And the other one was you define a property on the window for a, where the get function of it, you set a global variable, you set a global variable, right? And then the get function you'd say, you define a property on the window called a,

and the get function of that property would increment the same thing. So both are the same kind of spirit, right? But the first one I thought was a little bit cleaner because you weren't polluting the global namespace with that variable. But both of them I thought were pretty cool. So since you were so JavaScript heavy, I thought I would throw that one out there.

That works out, yeah. So was that your second article? No, that was just a bonus since your first two were so... Very much JavaScript. Yeah, I thought, well, we would continue having fun with JavaScript and throw that one out there. I like it. So what's your number two then? Well, I'll tell you what.

Why don't we come back to that? Let's say... Wait, am I wrong? Yeah. No. Oh, did you break it up? I didn't even notice it. That is, no. Yeah. I don't see your other one. No, no, no. Because what we're going to do instead is we're going to say, hey, if you haven't already taken the time to leave us a review, if you wouldn't mind, we greatly appreciate it. And if you have, we super appreciate you. Hopefully you know by now how much we appreciate that you took the time.

But yeah, so if you haven't, please do. And by the way, share us with a friend. Spread the word. Tell a friend about the show. Definitely. So with that said and out of the way, let's take a moment here. We, our last episode survey, we said, what is your favorite book type? So you don't have any competition here. So there's a good chance that you might win this one, Alan. No, I'm here. Oh, right. Oh, yeah. You're right. Joe is here. Great. So the question was, what is your favorite book type?

And your choices were hardcover. I want to protect my investment. Or paperback. I like to curl the cover back with one hand while I read it or ebook. It's the only chance I won't lose it or books. Ain't nobody got time for books. All right. So, so as Joe,

uh, hardcover 31%. And then Alan, I'm going to go. Joe doesn't want to give any reasons today. Go ahead. 31%. Joe says 31%.

And then Alan, let's go with. Wait, you didn't say which one was. Oh, it was hardcover. Yeah, hardcover. He said hardcover. I'm going to go with books. I ain't reading no books. And I'm going to go 30%.

30%. Okay. The funny part about that, though, was that when you did your impersonation of Joe, then you immediately went into Alan. There was no difference in the sound. No, no. This is Joe and I say 31. And this is Alan and I say 30.

This is Alan? All right. Well, somehow you lost to yourself. I don't know how you did that. I knew it was going to be hardcover. I knew that's what people were going to choose. No, it was books, but it wasn't 30%. Oh, really?

No, it was 28%. On the hardcover? Okay. No, 28, no books. Oh, no books. I ain't reading no books. I figured, man. Yeah, that was 28%.

That was the winning. You know why I thought that? And honestly, I think nowadays people in the day that we have now, think 10 or 15 years ago when we were developing. The way that you improved is you went and got a book, right? Unless you had super expensive subscriptions to MSDN. Nowadays, man, stack overflow, YouTube blogs. Like there's so many free resources.

Yeah. Do you remember media play? I do. Yeah. They used to, they're gone. They used to be a good source for like, uh,

programming books, man. I remember going to Barnes and Noble and like looking through 20 books, like which one of these $50 behemoths am I buying? Now you go look in Barnes and Noble on the programming section and it's depressing. Yeah. They don't,

I mean, why would you stock it? People, people don't buy them as much anymore. So yeah, man, that was my gut was I, I venture to say most people are just Googling stuff nowadays.

Well, what was number two? Hard book. Really? Yeah. My people. It was, it was like just under it, like just barely under it. I prefer eBooks. Although I hate the formatting of some of those things. Yes. They drive it. And some of them you'll click a diagram and it'll just jump you out of your spot in the book. And it's like, what? Or some of them, you'll click a diagram and it'll just jump you out of your spot in the book. And it's like, what? Or some of them, the diagrams are just like JPEGs that don't render well, depending on like, you know, the Kindle app, for example.

Yeah, I'm with you on that. It totally depends. If I'm, it greatly depends on the type of book I'm reading. Yeah. Which we didn't really cover. We didn't, we didn't qualify that. If it's a technical book, let me let me rephrase that if it's not a technical book if it if it's any other book that's not technical then i don't

i would say i would prefer an ebook same here right but like you like what you were getting at when it's a technical book where you're going to have code listings and you might have diagrams and whatnot. They just tend to not work out so well on, you know, the readers. It's frustrating. Although, you know, it's funny.

I am not a lover of iPads or, or any just consumption based device. But one place where I love them is for like eBooks. I have, I have a plumbing book that I bought that was, that I did, you know, but the eBook is awesome because it's color photos and they're high quality

and you can zoom in on them and all that kind of, and it's great on an iPad. It's great on anything like that on a Kindle on like a paper white, man, I don't even know what I'm looking at here. Right. So, you know, it kind of depends on the type, you know, but I do love, you'd have to pry my paperwhite out of my cold dead hands.

I love that thing. Yeah. I mean, for reading like, you know, something fiction. Yeah. Fiction. And it's got the backlight that, that is why I never owned a nook or or any of those things back in the day it was because it was like wait i got a clip of light to this thing

right it's a digital thing put a light on it right as soon as i did that i was like i'm in so but that's why i'm more of the opinion that it's like well you might as well just get the ipad because it's it's a better kindle than most kindles so and it does more than just be a Kindle. So there's truth. There's truth, but that thing's tiny and it's, it's just, I don't know, man,

it's tiny. And the battery life lasts for, for months. Right? Yeah. The paper white is like ridiculously light. I love that thing. But that's really the only thing it's going to do.

It is. It is. Yeah. Yeah. All right. So how about for this survey, we change directions here and we say, does having multiple monitors improve your productivity and your choices are absolutely. And on the bright side, get it.

I get more work. I get to work on my tan from all the extra UV light. The more nits, the better. Or, no, but it can be a nice luxury. And lastly, it depends on the code base. The smellier the code, the more monitors I need. That and air fresheners. I love that.

This episode is sponsored by tech meme.com. Tech meme has a week day podcast where they release like quick 20 minute episodes that you can listen to on your ride home on your commute. They're quick hit news topics that basically are all the type of things that at least I look through when I'm going through my Google feed, looking at all the tech news of the day. It's a great way to stay up on the content without actually spending time looking at your phone or taking time out of your night once you get home to look this stuff up. You can either head to codingblocks.net slash episode 87 and find the

links to go to the podcast or head up to iTunes or Google Play Music and in the search type in tech meme ride home. That's T-E-C-H-M-E-M-E ride home and listen and subscribe. We get a lot of questions about like, hey, how do I, I'm starting out in my career. How do I get better at it? What's some advice you can help me on getting started? What are things like that? Right? So the tech, tech Republic had this article, 10 tips for becoming a better programmer. Right. And, uh, there's actually, I've actually got like two articles that are going to kind of go hand in hand with this. But, um, first is I'm going to try to go kind of quick through these 10, but the first is hone your soft skills.

And I knew that as soon as I saw that one, I was like, Oh, Alan's going to love that because you're always talking about like, like the networking aspect of going to meetups and things like that. Like, you know, it's more than just about what you know. Sometimes it's, it's, you know, the technical thing. It's more than about the technical things that you know. Number two, code the real world and code frequently. Meaning just practice and write things.

Don't just write like fizz buzz, right? But like write something real. Number three, be language agnostic. You don't like that one? I don't. That's hard. I don't love that one, but I get it. I get it. What if we reworded it to say, be a polyglot?

Yeah, that's fair. No multiple languages, because that's really kind of what they were getting at. It's like, learn more than one. I like not falling in love with one and being only tied to it, right? Like if a problem comes up and it requires Java, do Java. If it's Go, do Go, right? Like don't be in love with it, but yeah. Don't just write Perl.

Right. Don't. Poor Perl. Number four. I know we've talked about this one contribute to the open source community. Number five, join a local user group or mentorship program, which again, going back to our networking thing with, uh, you know, meetups, right? Like kind of in that same vein, right? The local user groups, right? Number six, work on a side project. Now, to me, this one got kind of confusing because I was like, couldn't that really be the same as the open source, like contributing to open source? Maybe, maybe not. A side project,

you don't necessarily want everybody in the world to see it, right? It might be something that you're building that you might want to sell. I guess where I'm going at it is like it could be the same.

It could be, totally. It could be the same. Yeah. It doesn't have to be because you could also like put your own stuff out there in the open source world and now are you contributing

to open source even if you're the only one that's reaping the benefits of that contribution? You are. Yep. All right. So here's where you're going to feel better about the being language agnostic. Develop a specialty. Yeah.

So, you know, pick something and, and try to specialize on it. It doesn't, it could be a language maybe. Right. But it could be something more than that. It might be, it might be something that could span languages like, you know, machine learning, for example, like just knowing the, how that works as an example,

right? Number eight is one that I feel like is not exercised enough. Take code review seriously, right? Like be, be receptive towards constructive criticism and, and take advantage of your reviewers experience and time. And they're trying to share with you so that you can create something better on your own. I fully agree with that. And,

and I also think on the flip side of that too, being the review, being the person reviewed, accept that feedback and all that, but also as the reviewer, you can learn things, right? You can see new patterns. You can find out about things that you didn't know existed, right? A new feature in the language that you hadn't looked at, whatever. It's important both ways. Here comes your favorite one, number nine. Learn more about the business side. All day long. Yeah. So whatever the software is that you're creating for that organization,

be it a profit organization or a nonprofit organization, the software that you're writing is empowering a business objective. Maybe not the ultimate business objective that is mostly responsible for the company. Maybe you're writing the logging framework for apple.com instead of the next version of iOS or the hardware for iPhone, right? But it's still empowering a business objective. I agree. You'll never be outside the owner of your company, be invaluable at your job because everybody's replaceable to a certain degree. But if you show that you care about what you're trying to solve, the about what you're trying to solve, the problem that you're trying to solve, it goes a long way, right? Because then it makes you easier

to communicate with and you'll do a better job because you'll be thinking about what pain am I solving? It's huge. I agree. And it'll be, you know, going back to our domain-driven design conversations, it'll make it easier for you to have conversations with the business owners, and it'll make it easier for other people to read your code because your code can reflect that same language. Yep. Right? Huge.

So it'll make conversations easier. Lastly, read voraciously. So, yeah, don't just stop your learning at school. I've mentioned before that college or university is just more about, in my opinion, a big part of what you're getting out of that is learning how to learn. When you're young and you're in those early school years, you're just learning how to learn. I mean, you're learning stuff.

Don't get me wrong. But I think the more valuable lesson is learning how to learn. And you need to continue that and continue practicing that and exercising that throughout your career. I agree. And if you're listening to this podcast or any podcast like this, you've already chosen that, right? Like this is, you've picked a profession to where that's what, that's kind of what your life is, right? And this ain't flipping burgers. No. Like this is good. You know, burgers are going to, flipping burgers are going to stay the same for the next 30 years. But well, if that, I say that and then watch, they'll come out with something fancy. The roo Flipper. Yeah, 2020.

Yeah, no, it's so true. I mean, this profession is literally, would you say that you learn probably about as much every year? You learn more every year than you did your entire time in college. I venture to say. I'm constantly picking up books and yeah, I've been in love with Coursera lately.

Um, and so I've been taking Coursera courses, uh, you know, Pluralsight. We talk about Pluralsight all the time. You know, that's a great opportunity to learn and,

and they're not relatively, they're like, you know, kind of call, I would kind of call those like small courses. I forget what Pluralsight actually calls them. They don't call them courses though, do they? I don't know. They call calls them. They don't call them courses though, do they?

I don't know. They call them lessons. I don't remember. But yeah, there's so many great ways to learn out there. And I'm constantly trying to find something because it's more like for me, just a fear of like getting behind because it's so easy. And this industry is always changing so fast, right? So, you know, I feel like, you know, the medical field, you have to stay on top of your game. Legal field, you have to stay on top

of your game. Technology field, you have to stay on top of your game. There's some fields where it's probably going to stay about the same for the next, you know, 20 years. You know, you might not have to worry about it so much. But man, those three fields are definitely not – those are constantly evolving. Learning is huge. I will say on the soft skills, and I don't think to belabor it or harp on it, but, you know, be careful of what you're posting on social media because it can totally change what your opportunities will be. You know, you just have to be careful about that stuff. You know, if you want to write blogs and that stuff about tech, you know, be careful about what, what you're putting

out there because now more than ever, it's who you are and it's how people will look at you and find you and judge you before they even really even talk to you. So, you know, be careful about that stuff. Yeah. I mean, there was kind of like a addendum to this that I wanted to add that was more in regards to it's – it's all kind of the same about becoming a better developer, but from a JavaScript point of view, right? Like, how do you keep up in the JavaScript world? Like, we've joked about, you know, the framework du jour, right? Like, how it seems like it's constantly changing. It's definitely, you know, in the past few few years seemed like it's been more stable right

i agree you know you you have your your big ones you know react and angular and you know i guess maybe those are those who might be vying for one and two and then view maybe as a third distant third between them yeah that sounds about fair not that i'm trying to dog on view but really a far further back, right? Like there's still some other ones out there. Yeah. Meteors, somewhere in that equation. But, you know, it's just, we've joked about how it can be difficult to stay on top of the JavaScript world, right?

And so there was another article that had some similar points to this other one. That's why I bring it up at the same time is that, you know, it's like, well, um, you know, the other one was talking about like reading and everything. Well, this one was saying like, Hey, consume curated content, like let someone else do that for you. So, you know, in the JavaScript world, you know, there are newsletters out there for like, uh, JavaScript weekly front end front, uh, front end newsletter, things like that, a drip of JavaScript, uh, or there. Or there are podcasts out there like JavaScript Jabber is a well-known one. Syntax.fm is coming up in the JavaScript rank. So then there's like, they mentioned different learning styles or different sites where you

might get your news. So we mentioned Pluralsight, for example, as one place. Udemy is another place that we've mentioned in the past for getting courses. So you're using those places that are already kind of like curated, you know, lessons that you could use for like whatever it is that you want to stay on top of. But, you know, there's a lot of great content on Dev2 or Medium, for example. You know, a lot of great articles that get put out there. What do you think about Reddit and Hacker News? I mean...

Like our programming. Yeah. There's a lot of great stuff that comes up there. The problem that I have with both of those those though is that like um if you're not logged in and you don't save something or if you don't save it then you can quickly lose it and you'll never find that again you're like god what was the name of that article it was something it sounded so good or like or maybe you read like you know some of the comments in it and then you forgot like it can be that's the only problem i have is that those filters buy so

fast but they do have good stuff i'm not trying to try and take any weight and i'm not also it's not jab at the other ones that they don't operate fast either right um it's just more those are like a stream of thought almost like it happens so fast well those are like drinking from a fountain from a from a fire hose right it feels like sometimes you know um but yeah you know uh experiment with was listening there seek mentorship which goes back to you know uh the networking whatnot learn other languages expose yourself to others which you know maybe in this day and time that's the wrong way he shouldn't have phrased it that way um but, but you know, basically what he was going, yeah,

I'm going to reword that for him. Uh, you know, put your content out there, put your, your code out there and let others see your code. Yeah. He'll thank me later.

Uh, you know, basically the idea was like, you know, putting stuff out on stack overflow, for example, or, um,

going to conferences, speaking at conferences or whatnot, you know, putting articles up on Reddit, things like that, right? And, you know, the idea of building stuff and teaching, right? Like teaching is a great opportunity. Like if you think you know something well, try to explain it to someone who doesn't know it. And then that'll only increase your knowledge of it. I mean, yes, you're helping them out, but you're also helping yourself out. So there's a greedy reason for you to try it. Oh, man, the best way to learn is to try and teach. Yep.

Let's see, what were the last ones they had here? I'm going to go through these kind of quick. But contribute to open source, we already covered. Asking questions, you know. And then, yeah. Very nice. All right, so on my last one that I picked up, this one's kind of interesting. This one's more open.

I didn't put a ton of notes here because this is something that we've probably all faced at some point. So it's fake data. And why is it important, right? The way you wrote that, I assumed that it was a joke the way you wrote that in the show notes. Oh, no. No, no. So this is something that we've actually faced at our last two gigs and honestly more and more companies are going to be dealing with this stuff because i mean it seems like every time you turn around there's a data leak somewhere right and how much of that is because somebody had cloned the production database and stuck it in a development environment or or they had a copy of their data laying around somewhere

because they needed to do a backup before they ran something. There's just so many reasons that fake data is important, and it sounds really stupid until you start thinking about, okay, well, we need to protect our customers, and we need to protect ourselves from breaches and that kind of stuff. So a lot of times you do need to generate fake data so that your application is usable in a state that makes sense. Right. So so some of the some of the key points I put down here are why is fake data important? OK, well, yeah, you need to see if your system does work right.

Like if there's you know, if you're going to go use your production version of the application, well, there's certain amounts and types of data in there. Well, you probably need to be able to do the same type thing in your development in your QA environments, but it shouldn't be the real data, especially if it's sensitive data, PII or anything like that, then you need to create something that's kind of representative of what the population of data in your production environment should be. The other thing is, what if you need to sell your product? You need to demo it. You're going to go demo it with a bunch of real customer data in there and show it in front of a room full of people? Probably not the best move that you could make. So you'll probably need it for there.

Well, I mean, that gets you into all kinds of trouble too, because if it is real data that you're using to demo this product, like who's real data, is it right? Is it, is it data within your own company? Cause then you could still have like personally identifiable information that maybe you don't want shown, but Oh man, please don't use some other customer's data to sell to the next customer. That would be even worse. It'd be bad. I mean, there's just so many bad things that can happen if you're using real data. And the funny part is I was like, well, how hard can it really be? Oh. Right? No. That ain't fair. I mean, the funny thing is-

To create fake data that looks real that's right that that is i mean i don't want to i don't want to take away from you you need it you definitely need to do that exercise but that is not an easy challenge either no it's not you actually if you go about this and you take it seriously, it's a, it's, it's a big project to take on to try, because here's the thing. And we've seen it, right? It's not just, does the data in each individual component look right? It's does all the data together look right? Right.

Does do the patterns fit? Does the pattern of this data in your development environment and your QA environment match the pattern of data in your production environment? Right. Like it is so much harder than it sounds. And it is such a pain in the butt. That said, this article that I that I was reading, it was on Medium, which, like Mike said, is is a fantastic place to read articles on on people that are thinking and working in real world problems. Uh, but these guys,

there is an application that was created called, I think called fairy. Uh, let me scroll down and find it here. Basically what happened is this company had a same, a similar type problem, right? They needed some fake data,

but it needed to look pretty good. Uh, here it is, JFerry. And what they did is they created a fake user data generator, which is fantastic. Let me put it in show notes here because I'm sure that you're probably looking for it. And they actually have a place where you can go up there, you can click around on this thing. And if you go to the GitHub page where they have it, they have a try J fairy online and it's really cool. It generates user information. It generates like con like identity information, like your personal national identification number, uh, contact information, a credit card and company information.

Obviously, this stuff is all fake and it's generated, but it all looks very real. Okay, so the schema behind this is to create a person. Yeah, kind of a person with their company, their personal contact information, like a credit card or something. Yes, that's what it is. But I guess where I'm going is it's just that one. Just that one type of entity with its relationships, right? So if you want to see how hard it might be,

they have the source code up on GitHub, and you can come in here and you can take a look. And some of the cool things that they went through with this is, like, what's a real credit card look like, right? Like, what's the number. And then we need to validate that kind of stuff. But yeah, I mean, it's a, it's pretty neat stuff, man. Yeah. I mean, cause part of the challenge that can come in with that is that like, if you try to create, okay, it's one thing to create a fake entity or like a thousand fake entities, right? But where it can get more challenging is you then want to create fake data for each of those entities. So let's say you create a thousand

of these persons from using Jferry, right? And you want each of those persons to have a history of credit card transactions, right? And so you want history of credit card transactions, right? Right. And so you want some thousand credit card transactions, but you want them to look real. And if you were to chart them, you want them to look like they might in the real world, right? So sporadic and random and whatnot, not, you know, not a consistent sine wave or something like that, right? Or sales clumping up near Christmas or holidays or whatever.

Yeah, exactly. It's a lot of thought process. Seasonality. Right. So that's where it becomes a challenge. That's where it becomes hard, right? Not just creating the thousand persons that look real. Yep. the thousand persons that look real.

You can go out and get the top 1,000 common first names and top 1,000 last names and do a mix of those and there's your first name, last name. Now you just got to come up with some addresses. You know what I'm saying? The interesting thing is in this article

they even talk about that not taking it a step further in how that data might exist saying like yep the interesting thing is in this article they even talk about that like uh not taking it a step further and like how that data might exist in your system like you're talking about like transactions and stuff but they even talked about how just even the the social security number type thing that they have this this personal number like you can't just make that up because if your birth date was here, then your personal number is going to be here and they need to be able to validate that kind of stuff. They're going to be in a range. Yeah. There's going to be a range there. So there's

all these things that you have to think about that. Yeah. If you were just trying to do first name, last name is probably not that bad. But as soon as you start looking at these further details, like this stuff gets really complicated, just trying to come up with realistic looking fake data so yeah i thought it was a pretty a pretty cool article yeah i mean i definitely have had similar conversations where like for example um trying to be nice about this. So there's a, so Redgate is a tool we've talked about in the past, right?

Right. And I've definitely had conversations with DBA, DBA like folks where they're like, Oh, well, you know, we can just use the Redgate tools and cause Redgate has a tool where it'll generate a bunch of fake data for the table. Right.

And, and it is a really cool feature right and it can there's i'm not saying it doesn't have its place because it does if you're trying to do queries and whatnot you just want to be able to test like hey how fast this thing returned back one of the limitations that it has is that you do have to have a uh what would be the word for it you know your schema needs to be well-defined with keys and foreign keys in order for it to know that, hey, any data that I create in this table, I expect to link over here too, right? Like, you know, those keys have to exist.

Are you saying that people create databases without all those foreign keys? Well, I'm just saying, like, if you had a table that had a dependency on, you know, from one to the next, like, yeah, you would have to have that key defined in there. Otherwise, I wouldn't know. Yeah. Otherwise, it's not going to know. And so the data isn't going to necessarily be good. So you're saying for it basically to spider out and fill in these tables and create the relationships properly, you'd have to have a proper foreign key to find and all that. But where that tool is going to fail you, though, is A, it's going to look more garbage.

Names versus streets versus products versus things like that. Those are going to start to become like just gibberish. And, you know, again, if all you care about is you're just trying to check the performance of a join or, you know, some kind of query and index or whatever you're trying to, you're going after that, like, hey, how well does this index perform? If there's 8 billion records in this table, then that could be good enough and it has its place. But the other place where it's going to fail is like I mentioned a moment ago is, you know,

if you want to then be able to do any kind of statistical analysis on that data where you're looking for patterns in it, right. Like, you know, or you want a pattern in some of the data, like, um, you know, you mentioned about like the seasonality of, of credit card transactions and things like that. That's where that's going to – it's not going to have that type of logic built in, right? And how could it? How could it know that you wanted that, right? So you can't expect that.

It's a hard problem to solve, really. There's definitely a science to being able to create fake data, data that is fake but looks real, right? And it can be very useful to your application right finding bugs so not useful and and on top of it is something that can be reproducible depending on how you do it right which is which is also a nice thing for developers and testing integration tests all that so yeah yeah we'll have we'll have a link to the article there it's pretty cool and like i said you can go check out the gith the GitHub page and see exactly how they generated this fake user data.

And they said it was funny, too, when they were going through some of this. It does such a good job that on occasion they hooked it up to Gravatar to see if anything would come in. And on occasion they'd get a hit. Like it would generate somebody that had like a Gravatar email address or something. And they'd come in and they're like, whoa. Right. Yeah, you're right. No, that actually is another one of the challenges, right?

Like creating fake data that is always fake. Hard to do. Yeah. Yeah. All right. So here's going to be a fun one. So the title of this is, now,

you know, I love get right. So you knew that there was going to be a get one in there. And if you didn't shame on you, shame on you, you should have known better. 11 painful get interview questions. You will cry on.

You ready? Probably not. Okay. So we'll try to go through these kind of fast because there's 11 of them. But what is GitFork? What is the difference between GitFork, branch, and clone? GitFork actually creates another copy of the repo that you could merge back in at some point. Git clone is the copy of the same repo.

It doesn't break it off. And what was the other Git branch? Yeah, that's just creating another work, a branch in the tree that you could merge back into the main repo. Okay. So the only clarification let's make is that fork is remote clone is local okay right and then that way it's but yeah you you're you're like really good uh i expect you to know the difference between a pull request and a branch oh yeah yeah do those a little bit.

This one, this one felt more like for those who were just getting started with get, but maybe still a helpful one to cover the difference between get, pull and get fetch. Oh yeah. Get fetch will bring down the latest stuff. Get pull, we'll bring it down and merge it into the branch. Right.

Get pulled does a get fetch and a git merge. Yep. Right. Git fetch only retrieves it but doesn't bring it in. Now we're going to start getting fun. Oh, no. How to revert the previous commit. Man, I hate this stuff.

So I don't know how to revert it. I always just check out the previous commit and then act like the other one didn't happen. Oh, really? Yeah. Oh. Well, there's an easier way. Oh, okay.

Okay. One, you go to Stack Overflow. So you Google how to revert commit. Okay. Okay. So typically the way I would do it is I would do a get reset dash dash soft hard tilde one. Okay. Go back one commit.

That goes back. That undoes the previous commit and leaves the changes still there for you and your index to change, right? You could do the hard one where it would just reset it, right? Like now they're undone. Yeah. And he has another one here for just get reset head tilde one. I believe that's the same as soft though, right? Sounds right.

Because if you don't do dash dash hard, it should make it the soft one, right? Yeah, that would be the same. Those are the same. Dash dash soft, you could leave it off or add it bi-typically and more explicit so um what is get cherry pick that's bringing in changes usually from a commit hash from one branch into the current branch right so basically if you're listening to this and you're like oh man i don't know don't know. This is a good list of things to be aware of. And CherryPick's useful. You know what I think we should do in the future, not to derail this?

We should talk about the Git workflow that we're using that Microsoft recommends that has actually helped us out tremendously. We should probably do an episode on that. I'm so glad you brought up workflow. Can you explain the advantages of forking workflow? No. Okay. So the main

advantage, uh, I'm going to paraphrase what he says here is, you know, or try to keep brief, but the main advantage of the forking workflow

is that contributions can be integrated without the need for everyone to push into a single auditory. And then once you're done with that, then the developer of that forked repository

can make the pull request into the main when they're ready. All right. Can you tell me the difference between head, working tree, and index? No. I mean, head is your current saved commit. Working tree, I probably can't give you anything good on that one. And index? Index is where you're pointing in the commit line.

And I can't really describe it well. Okay. So you were in the ballparks for those three head is the last commit that was current this currently checked out in the, in the branch you're in, uh, is it, well, I should say it's a reference to the last commit in the current check currently checked out branch. The workspace is just the directory that you're, you're in that that's the current, uh, is just the directory that you're in. Okay.

That's the current, you know. That's your work entry. Yeah. Wherever, not including your.git directory. I'm not including that one, but that's where all your source is that you can see and edit. Okay.

All right. Okay. The index and staging area, that's just a large, a single large binary file underneath your.git directory called index. And it lists all of the files in that branch in their SHA-1 checksums. Oh, nice.

The timestamps and the file name of them. Didn't know that. So it is not a copy of them. That's one of the reasons why Git was preferred over things like SVN. It's faster. Because there aren't multiple copies. It was just the SHA-1s that you're comparing. Very nice.

Okay, Git workflow. Can you explain Git workflow? You have to be able to explain it. It's been a while yeah git workflow was uh creating branching strategies where you'd name the branches and then you would you didn't cherry pick you would merge those things up like if you had a change to an earlier branch then you would merge it up to the next branch to the next branch whatever if i remember correctly it was something like that yeah you're pretty much i mean the main the main point of the git workflow is that you'd pretty much have like two long-lived

branches a develop and a master and you know you would you would your master branch is always available to be pushed to production or is always production ready and um whatever that might mean for you. Right. And your develop branch is where all your newest stuff is. And you don't merge that branch in to master until everything has been, you know, theoretically everything has been tested and signed off on as being ready for production. And then you would merge that in.

So it uses a merge kind of strategy is what you were getting at. We've tried that one. That one didn't work out so well for us. We have successfully used that in the past. As long as you don't have multiple concurrent releases that you have to support. It depends on the product that you're working on. You and I were at a previous um environment where

it worked out well we were in a uh constantly a continuously deployed environment where uh you know if there was a failure you moved forward right like you you didn't roll we we tended extremely rarely did we roll back we we would always roll forward. So if there was a bug, you just fix it and, you know, roll forward. And in that kind of scenario, the get workflow can, can work quite well, where you what you're referring to, where we had problems with it is, if picture Microsoft supporting Windows and, you know, Microsoft doesn't just support one version of Windows. There are multiple versions of Windows that they support concurrently. And so if they needed to release a bug to that,

like how would you do that? That's where the Git workflow kind of fell apart because if you have these multiple versions that you're still supporting and now you have a bug fix that you need to make in one of those in the middle and now you got to like roll it back and roll it forward or something weird like that like super hard you know that that's where you get into like merge hell yeah right and we spent a lot of time there yeah that's a good point yeah all right when should i use get stash? Oh, if you want, if you don't want to commit a change,

but you need to go work on a different branch or different set of code or something, you get stash it to kind of tuck it away and then you can come back to it later. Yep. Uh, blah, blah,

blah. How to remove a file from get without removing it from your file system. Get RM file name. Uh, file from git without removing it from your file system? git rm filename. Without. That doesn't remove it from the file system, right? I think it just takes it out of the cache. git rm will remove it. From the file system? Will remove it.

Then it's like git rm no no or dash dash no cache or something like that. I can't remember. Okay, this one isn't that hard. You're overthinking it. Git reset file name. That's it?

That will unstage the file. Oh, unstage the file. Oh, oh, oh, oh. I thought you said take it out of the cache. Well, it's weird how they worded their question here. They say, how do you want to remove a file from git without removing it from your file system? Yeah, that's GitRM. If you are not, no, if you are not careful during a Git add, you end up adding files you didn't want to commit. So at that point, Git add is going to take unstaged files and stage them. And he says,

if you then do a GitRM, it will remove it from the staging area and from the file system. But it doesn't remove it from the file system. Git rm takes it out of git so it doesn't track the file, right? That's what I was getting at. So git reset will take it out of the staged area, but git rm just removes it so git doesn't care about that file anymore. The official documentation, the name of it, removes files from the working tree and from the index. So it will remove the file.

GitRM will remove the file. From the working tree. Remember, the working tree is just the directory you're in. No, no, no. GitRM will not remove a file from just your working directory. There's no option to remove a file only from the working tree and yet keep it in the index. No, no, no. Git RM will not remove a file from just your working directory. There's no option to remove a file only from the working tree and yet keep it in the index. No, no, no. Yeah.

Okay. Okay. I'm sorry. I'm saying like if you do a Git RM, it will remove it from both. Interesting. If you only want to remove it from the index, what they're saying here is that like you could do that, use Git reset. But I think to be more specific, the way I would really phrase that is if you wanted to unstage the file, then you could do a git reset. So what I was thinking of was

git rm cached, dash dash cache. So if you don't want, so for instance, you added a file to your directory that you didn't want to be in git, that's what I was thinking of. Remove it from Git. That'd be git rm dash dash cached and then the file name. And then that would say, hey, don't track this file. I don't want this to go into source control, right? So think of if you were crazy enough to leave passwords and plain text on your system, you wouldn't want it there. So going back to what your original intent was, right? The stage thing, if you did a git add dot and it put everything in there and you wanted to get it out, git reset, and then the file name will bring it back out of the

stage. Yeah, I feel like in your example, though, I still probably wouldn't do the dash dash cached. You know, you could do a git ignore in that file. Put it in the git ignore, right? In that particular example. I've done the git rm cached whenever something got added

to the repo that I wanted to make sure it got out of it. Right. Yeah. Because otherwise, even if you put it in the get ignore after it's been added, it'll stay in there. Right. Yeah. That's a good point.

All right. So last one, uh, when do you do a rebase versus a merge? Oh man, I, I rebase all the time. So that's probably not the right answer. If, if you have not pushed your branch remote, then I say do a rebase. So for instance, if I check out, if I check out from master and I'm going to do some work, right. And I have five commits and I pull master into mine, then any commits that anybody else has done over time is going to be intermixed with mine. And so the rebase will basically say, okay, take all the previous commits that were brought in from the poll

and reorder them so that my commits show up in one chunk, right? All together. That's more the answer that I would be looking for. Okay. Like if this was my 11 painful interview questions, like that's the answer I would be more looking for is that the rebase is going to put your commits at the end of the head. Yeah. Right. In order.

Yeah. Whereas if you didn't, if you just merged it in, then it's going to be merged in intermixed with you know everything else it's impossible whatever branch you're merging into yeah it does become and it becomes really painful to bisect it or you know yeah go back and look at the history but like you you alluded to it does you do have to use it sparingly and with caution like you have to know when to use it, because if it has, if it's something that has been already shared, then that might not be an option. So it does require some thought on your part before using it. Right. That, you know, I wouldn't advise any, I would never advise any team to just automatically make it a part of their workflow if not everyone on the team understood it. Yeah, I agree with that. And honestly, if you've ever pushed your branch remote and it's been sitting out there for any amount of time, chances are you no longer want to rebase that locally. Because if anybody used that branch for any reason, then you're going to screw it up.

Yeah, especially if you're doing shared development on it, that would be... When you do the rebase, does it create new commit hashes on those? It probably does, right? It does create new commit hashes. Okay. And so that's why it screws it up. That's where it's rewriting history. Yeah.

So the rebase rewrites the history to put it in the order, like we said, nice and neat at the end. The problem is, if you had pushed that branch up previously what was hash one two three might now be hash five six seven and so if you were to go try that person if you merged your code in that person who used that remote branch they get merge conflicts like crazy when they tried to go merge their code in which is just nasty. It's wrong to do to people. It's nasty.

It is nasty. Anybody that's ever spent any time dealing with merge conflicts, they, they hate life. Okay. So I want to, I'm not sure this one is definitely going to be a visual. So we're not going to do this one long.

Okay. But if you are watching on YouTube, you can follow along with this. But I want to figure out like how we could do this. So this is going to be a little test for you here, Alan. Hey, wait. Did I pass the interview? Did I get the job? Oh, yes.

I'm sorry. Yes, you're hired. All right. What's minimum wage these days? That plus one. That's what I got. There you go. Um, okay.

Where's the, let's see if this will work. And you tell me when you can see my screen. Oh, and, uh, let's do that and share that screen. Who did that work? All right. I got some, I got some screen sharing going on. What do you see? I see three boxes with an arrow in the middle.

Okay. So there was this hilarious, and I'm going to include the links to it, but there was this hilarious thread on our programming subreddit where it was a quiz. And basically the title is AWS has terrible icons and they're going to send the results to the AWS team. So the quiz is you're given all of these, you're presenting with all these icons and you have to say what the icon represents. So you describe it as best you can and then tell me what you think this icon is

okay so what i see is what appears to be three boxes with holes in the middle of them stacked on top of each other with like a play icon in the middle i have no idea what this represents okay that would be lambda as best as i can find man there's a lambda symbol for that like that doesn't make sense okay i didn't say these were going to make sense that that never came into it i'm sorry if i misled you oh man okay... I'm going to give you a hint. This is not a Shake Weight. That's awesome. Okay, so it looks kind of like a Shake Weight. If you don't know what that is, congratulations, you win. This is basically like a rectangular 3D rectangle on the top,

3D rectangle on the bottom, and then like a cube in the middle. I have no idea. This one is Elastocash. Man, okay. I don't even know. Yeah. Okay, well, it's about to get so much better. I don't know how many of these you're going to do before you get tired of it, but try to describe that one.

That's the same thing. That's like the more realistic representation of the Shake-A-Way, except these are rounded. Well, this is like Minecraft rounded. You know what? This looks like Toadstool from Mario Brothers. I don't know, man. I got nothing. Database Migration Service.

Man. They have coders for designers, I think. I know, right? You tell me if you want to do a couple more? Yeah, we'll do a couple more. Oh, no. I win. I i win you can't see that uh it has the answer key uh trying to describe that one okay so there's a big block of Minecraft land on the bottom, and then a bunch of weird-looking M's on top. I don't have any clue what that could be.

None. Now, I realize that every time I give you one of these, I've got to go and then look it up and be like, oh, God, what was that one? I have no idea. None of these seem to represent anything other than polygons. Directory service. I mean, that's kind of the point that they're making here, idea like none of these seem to represent anything other than polygons directory service i mean that's kind of the point that that they're making here is that like all these random shapes

that you know for these icons and none of them have meaning none to anyone yeah why would you ever pick these like i can't even figure out why this would be a directory service like this. This maybe it looks sort of like a Rolodex. Maybe if you're really stretching here. Oh my God. Maybe. Wow. I, until you said it now,

I can't unsee it, but you know, that's the thing is that like, I remember, uh, years back, you know, one of the things that,

uh, Apple had paid, uh, I can't remember. It was a woman who she made the icons or something for it. She was a well-known artist, if I remember the story correct. She made these things to be meaningful, these icons to be meaningful. You kind of understood what it does to like be meaningful, right? These icons to be meaningful. And, you know,

you kind of understood like what it does, right? Just by looking at the thing, right? Like even the street signs. I remember there was another article. Maybe I'm confused. Maybe they weren't because the other one was definitely a woman

that did the street signs that came up with the symbols for like what would be a yield versus a stop and everything. You know, that we kind of now understand is like, you know, that, that's what that means. Right. But like,

where do they come up with some of these things? I, I don't know, man. I mean, hopefully you're, you're watching the YouTube version of this because these are awful. Like they're, they're pretty bad. Let's do one more. We'll do one more. All right. I do like how you can change the width of it up there. Let's see. What do we got here? Let's say this is some sort of statistics thing.

That's the only thing I could come up with. It looks like two flat pieces of land topped by what looks like some 3D bar charts. Okay. Is it stat related? Oh man, I can't find it. Analytics of some sort? Oh man, it fails me. You can't lose the thing.

I can't. I feel like I got one out of five. Oh no, I found it. Okay. You would actually like this one i think it's kinesis i vaguely remember what that is i don't what is kinesis it seems like a big data thing right aws kinesis let me Google it real quick. You want...

Yeah, streaming data. Okay, yeah. You want... How many more do you want? Let's do one more. One more. Because none of these make sense. Like, they're all awful.

Okay. I think this is where I'm just going to have to, like, show you this thing. Can I just drag this over here? Here we go. Oh, you got the entire thing. Which icon does CloudFront have? Really?

Is this multiple choice really? This one is. Let's do the tower with the L-shaped thingy. Wait, describe it better. It says the tower with the L-shaped thingy. Oh, you want me to describe it? Yeah, yeah, yeah. Describe it so that people are listening.

Okay, so what this thing looks like is a column out in the middle of a room and looking at the corner of the room. Is that it? Now I've got to look at my cheat sheet and my cheat sheet is failing me. Dang it. I wasn't prepared for that. I really don't know. I feel like

literally people just had random polygon drawings and then just dropped them with one of their names you know what though this seems wrong i could have sworn the aws lambda actually had the lambda picture nope really okay so you picked you picked the top left. I did. Okay. And basically you described that as like a wall, a corner of a wall with a column in front of that. Yeah. Okay. No, it's, it's the middle left.

It's the six cubes floating in space. So picture you're playing Minecraft and you have six disconnected cubes that are just like all hovering in space. That's that one. That's, this is ridiculous. Yeah. It's going to get difficult for like, uh, you know, people to follow along, but yeah, we'll. Yeah.

You should check out the YouTube video of this one just to see sort of this. It's pretty awful. I mean, I'm almost to the opinion that if you can't come up with something, like if you're ever designing something and you can't come up with anything that makes any sense, then just use the words, you know? Yeah.

Something, something will be better than some of those icons. That's for sure. So yeah, I'll include, I'll include that. Where did I put that link? That'll be in the one resource we like. Actually, we have tons of links in this one, but they'll all be kind of interspersed without the notes. That reminds me of that too. in the Reddit about it, though, was that whoever in the company decided that it would be wise for

the company to have a Route 53 product and an S3 product should be shot. They look a little bit the same. You look at 53 and S3 and you can't tell the difference. Oh, man. That's awesome. So now it's time for my favorite part of the show and it's the tip of the week and in this case i have two so we've talked about design patterns in the past and i actually thought about bringing some of these up on the articles that we're going to discuss but i mean there's just so many of them somebody did a really nice job where they went in to ES6 and JavaScript. So I was very JavaScript heavy in this episode. And they went over many

of the design patterns that we've talked about over the episodes and showed the JavaScript implementations of those things. And I think if I remember correctly, a lot of those were using ES6 syntax. So you'd use like the class keyword and that kind of stuff. So if you want to see what, you know, the abstract factory looks like in JavaScript, here you go. They have it, the builder, builder, factory method, singletons, etc. So they have a whole bunch bunch of them in here and it's pretty cool stuff. And it's weird seeing JavaScript that looks like C sharp code or Java code or whatever, but pretty cool stuff. And then the other one that I wanted to share, I said that, uh, Micro G or Mike RG was going to get another shout out in this show. So he shared this in the tips and tricks Slack channel, and it's called layout it.com.

And it's really cool. If you do any kind of work in bootstrap, or if you're using CSS grids, like the, uh, uh, the responsive grids, they, if you come up to layout it.com and click on one of those things you can actually drag components into into like a drag and drop thing so that if you want to design a layout without having to actually code all the divs and everything you could literally go over here for like a bootstrap you can choose something like okay i want a badge drag it out into the middle there and it'll drop it in. And then you can actually get the HTML for that. That is killer. It's pretty sweet. Right. And it looks great. Like when you do it, it's, let me say this a different way. It's a whizzy wig for using bootstrap. Yeah, man. It's really good. So if, if you're somebody like me that typically just codes your divs and all this, this is actually faster.

And you can see it happen. Like you drag it out there and it'll pop it in place really nice. And you can do your grid layouts, all kinds of stuff, right? And it's even got the ability to change the styles there. You can remove them. Oh, dude, this is so beautiful. Yeah, it's pretty sick so uh very nice very nice tip for a mic up there on slack the other mic so thank you much for that and hopefully

you guys get something cool out of that oh i still can't believe this thing is so awesome yeah somebody did a really good job putting that one together. Yeah, they did. Jeez. People got too much time on their hands. You ever feel like that? I do. I feel like I got no, I don't have enough time on my hands. Yeah. But other people though, I'm talking about other people got too much time on their hands. Wow.

Okay. So I'm going to need some help with this one. So my tip of the week, remember I said, you know, I was going to mention some good stuff in there. So keeping along with that one, my tip of the week is, oh, shh, it get.com. So it's hilarious. But basically, uh, the author had, you know, gotten into some bad situations himself and there were certain situations where he was like, oh, God, how do I get out of this situation? And here was an easy cheat sheet of some of the commands

that he used to help him out with that. So I thought I would share with that because, one, it's just hilarious. So just for comedic relief, you know, comedy relief, you know, I wanted to share it. Um, please tell me get has a magic time machine. Yes. Yeah. I mean, let me just read like the first paragraph of this. Uh, I'm going to have to, you know, some words I'll skip, but, uh, he says, get as hard. Screwing up as easy and figuring out how to fix your mistakes is explicit of impossible. Get documentation has the chicken and egg problem where you can't search for how to get yourself out of a mess unless you already know the name

of the thing you need to know about in order to fix your problem. So here's some bad situations I've gotten myself into and how I eventually got myself out of them in somewhat plain English. And the thing is, like you said, it's really funny, but honest to God, there are some just gems in here. Like this, if you really want to get better at get like, this is a good way to be entertained and actually learn how to do it. Yeah. And so then, inspired by oh, shh, it, get.com,

someone else authored oh, shh, it, them.com. Now, this one is more of just a cheat sheet, so I felt like I should include it because one, well, just for the comedy of them going along with the other one. But since I had the other cheat sheets last week, I thought, okay, fine, I'll include this one, too. I like this cheat sheet. This one's better than most of them. Well, now, don't forget the Rico's cheat sheet that I shared last time.

His was ridiculous, yeah. Yeah. So, very nice, man. So oh, shh, get.com and oh, shh, them.com. And now we keep our clean lyrics. There we go. Don't hate on us. We're trying to make this work.

All right. So we hope you have enjoyed this episode. Subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And if you haven't already, be sure to leave us a review. You can find some helpful links at www.codingblocks.net slash review. Yep. While you're up there, check out our show notes, examples, discussions, and more. And we always forget, if you want some stickers, hit us up at codingblocks.net slash swag.

There's instructions there on what to do. Send your feedbacks, questions, and rants to the Slyke channel, codingblocks.slyke.com. Be sure to follow us on Twitter at CodingBlocks or head over to codingblocks.net, and you will find all of our social links there at the top of the page.