Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month,
Speaker 1: we'll get you that and a special dot NetRocks patron mug.
Speaker 1: Sign up now at Patreon dot dot NetRocks dot com. Hey,
Speaker 1: welcome back to dot net Rocks episode number nineteen forty three.
Speaker 1: I'm Carl Franklin at amergri Gabel. How you doing, Richard?
Speaker 1: What's up? I'm all right. This is weird to be
Speaker 1: in the twentieth century of shows, but you know, yeah,
Speaker 1: and so much happened during these years. Yeah, so we'll
Speaker 1: talk about that in a minute. But uh, how's the
Speaker 1: weather up there in otter Town? Yea, we gotta break today,
Speaker 1: little suddy. You know it's it's definitely springtime. So yeah,
Speaker 1: here too, things are changing.
Speaker 2: We had one snowfall, which is kind of normal for
Speaker 2: the coast, and now it's things are warming.
Speaker 1: Up here too, and it's kind of nice. Yeah. I
Speaker 1: install the camera right outside the studio nice and brought
Speaker 1: the big screen TV and from the living room, which
Speaker 1: we don't really use anymore and sort of mounted it
Speaker 1: right in back of where the camera is, so I
Speaker 1: have like a digital window out on my outside.
Speaker 2: But you can control the amount of light, and so
Speaker 2: you got control over your space till right, Yeah, exactly.
Speaker 1: So it's fun. All right, it's good. Let's talk about
Speaker 1: nineteen forty three before we do better. No framework going
Speaker 1: to do that first, sure, all right, Well, from what
Speaker 1: I know and what I read, nineteen forty three, the
Speaker 1: tide of World War two began to turn against the
Speaker 1: Axis powers, with significant events including the Soviet victory at
Speaker 1: the Battle of Stalingrad, the Allied invasion of Sicily, and
Speaker 1: the beginning of the Warsaw Ghetto uprising. The word ghetto
Speaker 1: comes from Poland. Not a lot of people know that
Speaker 1: in America anyway. And what's crazy when you go to
Speaker 1: Warsaw is the chunks of it that are still there. Yeah,
Speaker 1: the Polish are taken very seriously the ownership of those buildings,
Speaker 1: and well, it's entirely likely there's no one left alive
Speaker 1: that owned some of those buildings. They just won't do
Speaker 1: anything about it. Yeah, they're holding off on the chance
Speaker 1: that they could find some relations to the point now
Speaker 1: where they've built these protective screens up one floor over
Speaker 1: the sidewalk because there's Yeah, it's the building falling off.
Speaker 1: They don't want to hurt anybody. Wow, there's still billet
Speaker 1: holes in buildings in Warsaw from that. At that time,
Speaker 1: Zootsuit riots happened in Los Angeles. White servicemen and police
Speaker 1: officers attacked Mexican American youth, which turned that into the
Speaker 1: Zootsuit riots. The Harlem race Riot occurred in Harlem, New
Speaker 1: York after a white police officer shot in African American soldier.
Speaker 1: In the good News section of nineteen forty three, the
Speaker 1: Pentagon is completed, the Chinese exclusion acts are repealed. Actually
Speaker 1: is that good news? Does sound like it? I'm not
Speaker 1: so sure. But also two things were invented in nineteen
Speaker 1: forty three that we need to thank the people for
Speaker 1: duct tape, nice and LSD.
Speaker 2: It's funny also when the Colossus computer, which arguably is
Speaker 2: the first electronic programmable computing device, of course, built Blenchley
Speaker 2: Park for cryptanalysis. Wow, although that's also the same. Forty
Speaker 2: three is a year where the contract for ANIAC starts,
Speaker 2: but they won't get finished until forty five.
Speaker 1: Yeah, and I don't know.
Speaker 2: This is also forty three was the era of the
Speaker 2: first generation of antibiotics.
Speaker 1: That's right.
Speaker 2: Yeah, yeah, so, and there's some funny stories around that,
Speaker 2: like they found the perfect bacterium for growing penicillin on
Speaker 2: a cantalope.
Speaker 1: I thought it was on an orange randomly. There were
Speaker 1: are versions there, but the thing they call the golden mold,
Speaker 1: it was actually on a canalope in Illinois. That's so cool,
Speaker 1: and that maybe they already knew how to make penicill
Speaker 1: at that point. But it became the master mechanism destructimyas
Speaker 1: and was developed in forty three. I think that it
Speaker 1: was really released in forty four, wasn't it.
Speaker 2: Yeah, but that's when it was first developed and it
Speaker 2: was the first treatment for tuberculosis.
Speaker 1: Wow, take a lot of that stuff for granted, now,
Speaker 1: don't we We share doom to the point where people forget. Yeah,
Speaker 1: we used to have friends that died. He stepped on
Speaker 1: a nail. You were going to die? Yeah, and you
Speaker 1: everybody had somebody who died in tuberculosis. Many people oculosis.
Speaker 1: It was untreatable, tetanus too. Yeah. Okay, so let's get
Speaker 1: to better know a framework, roll the music. Awesome, A man,
Speaker 1: what you got? This one comes from our friend Damian Edwards.
Speaker 1: You know him. He's overdue for a show, isn't name?
Speaker 1: We should totally is. Yeah, we need a little signal,
Speaker 1: our reminiscence and all that good stuff. So he wrote
Speaker 1: this tool. It's on GitHub called dot net purge. It's
Speaker 1: a dot Net tool that runs dot net clean for
Speaker 1: each target, framework and configuration and then deletes the output directories. Okay.
Speaker 1: Can be run in a directory containing a solution or
Speaker 1: project file because you know what disk space is low. No,
Speaker 1: I'm kidding. I'm kidding, of course, Damien. That's not the point.
Speaker 1: The point is you have all these dangling frameworks and
Speaker 1: tools that you don't need anymore. Yeah, why confuse the issue?
Speaker 1: Just clean them up, Just tidy stuff up. Yeah, so
Speaker 1: that's cool. As you can see, it's a it's a
Speaker 1: dot net tool. It's a command line thing. You can
Speaker 1: add it to Windows Explore. There's a little registry hack
Speaker 1: that you can add dot net purge to Explore a
Speaker 1: context menu. Turn it into a shortcut. Yeah, very cool.
Speaker 1: You know, at least it'll it'll it'll help with your
Speaker 1: large lene you're programming large language model lature is not
Speaker 1: navigating old files. Ooh, there you go. Yeah. And also
Speaker 1: Simon Crop was a contributor to that. There's Damien and
Speaker 1: Simon basically another guy you should probably be back on
Speaker 1: the show. Yeah, so there you go. Clearly they both
Speaker 1: had the problem and decided to fix it. Yeah. Maybe
Speaker 1: it only happens in Australia, though I don't know. I
Speaker 1: don't know the answer. Okay, he's talking to us today.
Speaker 1: Richard grabbed a comment on a show eighteen eighty five,
Speaker 1: the one we did with Martine back in February of
Speaker 1: twenty four. We were talking about improving your CSS skills. Yeah,
Speaker 1: and Vladimir Jirgov commented this about a year ago. Hees hi, guys,
Speaker 1: long term listening to the show, writing in reference to
Speaker 1: using chat GPT for creating CSS code. I found this
Speaker 1: comment hilarious because it was a year ago when we
Speaker 1: just didn't know. I've recently used the free version of
Speaker 1: chat gpt for a small CSS h schmael and JavaScript project. Well,
Speaker 1: I could say it's pretty good perspectives matter.
Speaker 2: I'm an infrastructure engineer recently turned web developer, so my
Speaker 2: appraisal of quote good CSS code is limited. Nevertheless, chat
Speaker 2: GPD was able to produce clear, readable, almost eighty percent
Speaker 2: accurate code. The other twenty percent I compensated by pointing
Speaker 2: me to the right direction to fix it or just
Speaker 2: it when I couldn't do it itself.
Speaker 1: All this is good. It really blew me away a positively.
Speaker 1: When I asked to refactor the code, it gave me
Speaker 1: clear and concise, simplified Yeah, and ask it to comment
Speaker 1: it as well, that's another trick. Yeah. Well, and again,
Speaker 1: imagine this is a year ago, like so much has
Speaker 1: happened in this space in a year. That's the problem
Speaker 1: I find with chatchipt and things like CSS, because there's
Speaker 1: so many posts like on stack overflow of people who
Speaker 1: are posting bad CSS right and saying why is in
Speaker 1: this work? And then their discussions and by the time
Speaker 1: you get to the to the good one, you know,
Speaker 1: to the solution, it might be three years old. And
Speaker 1: so there's just a lot of confused CSS on the internet.
Speaker 1: So I'm probably true for all code. But in general,
Speaker 1: these tools have moved so quickly, and being aware that
Speaker 1: we're coming up on a bills and there's some interesting
Speaker 1: announcements coming, like you know, Microsoft's a tooling company first
Speaker 1: and foremost, so expect amazing things in this space.
Speaker 2: Yep, that's for sure, Vladimir, Thank you so much for
Speaker 2: your comment, and a copy of music Cobey is on
Speaker 2: its way to you. And if you'd like copy music Cobey,
Speaker 2: I write a comment on the website at dot at
Speaker 2: rocks dot com or on the facebooks. We publish every
Speaker 2: show there and if I comment there or if you
Speaker 2: comment there and I read it on the show, we'll
Speaker 2: send you copy of music go bay.
Speaker 1: And of course music to Code by born of a
Speaker 1: conversation that we had on dot net rocks and it
Speaker 1: turns out that music at a certain with certain attributes
Speaker 1: really help you focus, and it's based on science. Was
Speaker 1: that Dan North or was it Mark Semen? Mark Semen?
Speaker 1: Was Mark Semen? Yeah? Yeah, So you know, we just
Speaker 1: did track twenty two. So you can get that track
Speaker 1: by itself, or you can get MP three flak or
Speaker 1: wave collections. Go to music to Code by dot net. Okay, awesome,
Speaker 1: Let's bring back Martine Dowdin, an award winning CTO ux
Speaker 1: UI designer and developer, International speaker and author. Martin focuses
Speaker 1: on web interfaces. That are beautiful, functional, accessible, and usable.
Speaker 1: She approaches user experience from both art and science, drawing
Speaker 1: from her degrees in psychology and visual communications. Martin has
Speaker 1: worked as a developer, artist, educator, and consultants since two
Speaker 1: thousand and five. Currently, she's the CTO at Andromeda Galactic
Speaker 1: Solutions good name where she that's a great name as
Speaker 1: opposed to like Minutia Incorporated right where she continues to
Speaker 1: learn work on. Sorry, I didn't mean to make you laugh,
Speaker 1: continues to learn work on and share her passion for
Speaker 1: front end development. Welcome back, Martin.
Speaker 3: Well glad to be back. Thank you for having me.
Speaker 1: Sure.
Speaker 2: Yeah, it's great to have you back, and I'm happy
Speaker 2: to not be talking about CSS this time around. Not
Speaker 2: that your conversation CSS aren't brilliant. Yeah, but admittedly I
Speaker 2: think I pinged you saying it's been about a year
Speaker 2: and I had been poking through your sessionized and saw
Speaker 2: you doing a talk on promises and I'm like, you know,
Speaker 2: those things have driven me crazy since they were first
Speaker 2: talked about in the W three C.
Speaker 1: I should talk to Martina.
Speaker 2: It's like, as soon as I get that urge, like
Speaker 2: I want to call you and talk about it we
Speaker 2: should probably make a show.
Speaker 1: So, Martine, what is on your mind these days?
Speaker 3: Well, the I've been writing blog posts and one of
Speaker 3: them that you mentioned was about promises and also made
Speaker 3: it as a talk, and so I realized when I
Speaker 3: was I was, I've been working with some junior devs
Speaker 3: and some dot devs recently, and uh, we were arguing about,
Speaker 3: you know, better ways to write code and how something
Speaker 3: should be architected, because you know, de've never disagree on
Speaker 3: such things.
Speaker 1: Never, never, never, never.
Speaker 3: And I realized that one one of the one of
Speaker 3: the guys I was talking to, didn't actually understand what
Speaker 3: promises did or how they worked. And so that's kind
Speaker 3: of what prompted me to write that article because as
Speaker 3: I did some digging, I realized that not only do
Speaker 3: it's not as common knowledge as I originally thought it
Speaker 3: was on how they work, but also that there's so
Speaker 3: much with them that can be done that like, sure
Speaker 3: people can remember how to do a dot then or
Speaker 3: dot catch or maybe even in a sink away, but
Speaker 3: there's so much more to them than those three things,
Speaker 3: which is kind of what a lot of people think
Speaker 3: of when they think promises, Right, you get your fetch
Speaker 3: you get your then and go on and go forth
Speaker 3: and conquer. But there's a lot more to it that
Speaker 3: you can do in terms of parallelization or how you
Speaker 3: want things to happen, or if you want, you know,
Speaker 3: just give me the first response or things like that.
Speaker 3: And so that's kind of what prompted me to write it.
Speaker 1: And just to back up, we're talking about JavaScript here,
Speaker 1: yes we are. You know, we didn't really introduce the
Speaker 1: topic unless you read the title of the show, but
Speaker 1: so we're talking JavaScript promises, and you know this is
Speaker 1: the way to do one way to do things asynchronously.
Speaker 1: Right you mentioned a sink a weight, which we do
Speaker 1: and c sharp all the time, but turned into JavaScript as.
Speaker 3: Well, yep, which is it's kind of cool. I just
Speaker 3: I mean, the thing with them is the I found
Speaker 3: that the ear handling becomes a little different if you're
Speaker 3: doing the a a sek away where you have to
Speaker 3: wrap the trycatch and so on, and then depending if
Speaker 3: you want to where you want to catch your things
Speaker 3: and how ends up being a little bit different. But oh,
Speaker 3: in all, I find they I personally like it because
Speaker 3: I find it more readable to just be able to go,
Speaker 3: you know, especially if you have multiple private promises you're
Speaker 3: doing in sequence to just be able to do a
Speaker 3: weight one A wait two, a wait three, And it's
Speaker 3: really instead of having to do the whole that then
Speaker 3: that then that then that then I find it less worthy,
Speaker 3: but it's a personal preference really.
Speaker 1: So the whole dot then that that is that the
Speaker 1: promise syntax like fluent. Is that how it works.
Speaker 3: Yeah, So in JavaScript, fetch is a promise. I'm just
Speaker 3: going to use that as the example because it's the
Speaker 3: same one I have in the in the article. But
Speaker 3: you would do like fetch whatever the U R L, right,
Speaker 3: and then you would do after that you do dot
Speaker 3: then and then you're going to get the results and
Speaker 3: that that's that's going to be a function. So you
Speaker 3: get your result and you can do whatever you want
Speaker 3: with that result at that point, right, And you can
Speaker 3: chain those dot dens, so if you get what you
Speaker 3: sometimes see is like where it starts, people try to
Speaker 3: nest the dot dens instead of chaining them, so you
Speaker 3: get kind of that that Christmas tree pattern like that,
Speaker 3: but you can just know and the fun thing with
Speaker 3: that then and it doesn't actually require you to return
Speaker 3: a promise. You can put promise one that then promise
Speaker 3: you know, take my results and then put it in
Speaker 3: for promise too and so on. But you can very easily,
Speaker 3: very easily just do some kind of transformation on the
Speaker 3: data and return that site. Once you're in that that
Speaker 3: then sequence. It does not have to be a promise.
Speaker 3: You can do then whatever you want to after that.
Speaker 1: At that point it kind of sounds like a task
Speaker 1: and see sharp the concept anyway, where you know, when
Speaker 1: you have a promise, what do you do with it? Right?
Speaker 1: That's yeah.
Speaker 3: For JavaScript, the most common use would be for like
Speaker 3: fetching data, like whether whether it's whether you're doing using
Speaker 3: a framework or something or you're just doing raw JavaScript.
Speaker 3: Most of the time it's because you're fetching data that's
Speaker 3: ninety nine percent of the timeline, it's going to be
Speaker 3: four and.
Speaker 1: You're trying not to hang the UI.
Speaker 2: Why you do it right that I send off the
Speaker 2: fetch you can.
Speaker 3: It doesn't matter that more depends on how you're calling
Speaker 3: the function more than more and where more than the
Speaker 3: fact that it's a promise. The other one would be
Speaker 3: to turn that I use it a lot for is
Speaker 3: to turn callbacks into a promise because they're easier to
Speaker 3: chain and handle and deal with. I find so like
Speaker 3: when you're doing an image upload or a file upload
Speaker 3: and you want to do a preview for it, there's
Speaker 3: the whole file reader thing, and that's always a that's
Speaker 3: one of the common ones, or even the set time
Speaker 3: out technically speaking, you know, is callback. So like those
Speaker 3: sorts of things so that I can chain them easily
Speaker 3: with other things. I'll tend to turn them into promises
Speaker 3: because it makes my life a whole lot easier than
Speaker 3: living in and trying to figure out which callback is
Speaker 3: doing what and going where. And I find them gross personally,
Speaker 3: But just.
Speaker 1: A just a for full disclosure, It's been a long
Speaker 1: time since I've looked at that kind of complexity in JavaScript.
Speaker 1: I mean, ever since I found Blazer, I've been as
Speaker 1: much c Sharp as possible and as little JavaScript as possible,
Speaker 1: And usually the JavaScript that I'm calling is just something
Speaker 1: to get something from the dom that I can't get
Speaker 1: with sea Sharp.
Speaker 3: Yeah, dumb manipulation doesn't have too much in terms of
Speaker 3: callbacks or anything else. They have a couple, I guess,
Speaker 3: especially when you're getting to events like.
Speaker 1: Yeah, window do resize all that stuff.
Speaker 3: Or even what a fun one. That's always a h
Speaker 3: Be careful how you type that in your Google searches
Speaker 3: everything related to drag and drop because dom drag events
Speaker 3: can can make some fun fun Oh yeah, fun search
Speaker 3: results if you're not careful.
Speaker 1: Oh boy, yep, Tom drag pictures of Dom Delawi's. So
Speaker 1: does the fetch approach have an advantage when you want
Speaker 1: to call off like multiple data sets you want to
Speaker 1: fetch and you don't really care what order they come
Speaker 1: back in you're populating different divs kind of thing. Yes,
Speaker 1: if that word shines.
Speaker 3: So fetch literally just goes and gets the data. So
Speaker 3: if you wanted to call multiples, what you might do
Speaker 3: is do it in a You could do a promise
Speaker 3: that all which you would put a series of fetches
Speaker 3: in it, and it would only return the data once
Speaker 3: all of them have returned.
Speaker 1: That's convenient.
Speaker 3: So if you had to get if you needed all
Speaker 3: three sets of data in order to populate or do
Speaker 3: whatever you were going to do, that wouldn't return until
Speaker 3: all of them have returned. Now, the downside is if
Speaker 3: one of it fails, it fails everything. So that can
Speaker 3: be good or bad, right, It depends on your use case,
Speaker 3: but it.
Speaker 2: Is nice if you do need three sets and you
Speaker 2: don't want to wait for each one to come back,
Speaker 2: to do it that way and they run in parallel
Speaker 2: and once they're all back, then you act. If you
Speaker 2: got three different sets that just render in three different
Speaker 2: dips and you don't care whatever that comes in, can
Speaker 2: you still use it?
Speaker 3: Then you would probably do three. You would do either
Speaker 3: three functions or three fetches, and then in the response
Speaker 3: from the that fetch. But what I wouldn't do is
Speaker 3: try to go a sink a wait for a second
Speaker 3: and third because then you're literally waiting for a second
Speaker 3: and third. Right, So at that point I would probably
Speaker 3: do either separated into three functions that I would call
Speaker 3: and not wait on right, or if I wanted everything
Speaker 3: in the same function, I would do, uh, fetch a dot,
Speaker 3: then do whatever I'm gonna do, fetch b dot, then
Speaker 3: do what I'm going to do and do it as
Speaker 3: a dot. Then structure, because then they're not waiting on
Speaker 3: each other because JavaScript is going to fire the first one,
Speaker 3: the second one, the third one because it has the dot.
Speaker 3: Then it's not waiting for that to be finished. It's
Speaker 3: just going to fire and go and move on to
Speaker 3: the next but it will wait. Where it will wait
Speaker 3: is to do what's in that dot then then I'll
Speaker 3: wait for that data to come in. So if I
Speaker 3: wanted them in peril, well, i'd probably use and in
Speaker 3: the same function, I'd use dot then and definitely not
Speaker 3: a sync away because then you're forcing for the way.
Speaker 1: How is one doesn't help that there's multiple JavaScript async
Speaker 1: methods like call there's callbacks, there's promises, there's a sync away.
Speaker 1: Is that all of them?
Speaker 3: Well, if you get into some of the frameworks like
Speaker 3: our XGS, and you have the entire observable game as well.
Speaker 2: React right, yeah, yeah, then is what the other frames
Speaker 2: will provide you on top of everything else.
Speaker 3: And then there's a handful of listeners too, which I
Speaker 3: think are just callbacks if I remember, well.
Speaker 1: How does one do a resilient strategy like we do
Speaker 1: with poly in c sharp, Like you know, if if
Speaker 1: a service is down and you call it, how can
Speaker 1: you do like easing, you know, back off multiple retries
Speaker 1: that kind of thing. Is there such a thing like
Speaker 1: that built into JavaScript?
Speaker 3: So our XGS does have a if you're dealing with observables,
Speaker 3: does have a retry function. But you can fairly easily
Speaker 3: do or retribe, because what you're gonna you're gonna utilize
Speaker 3: your catch for that, right, So we're either going to
Speaker 3: do in a trycatch block or as a dot catch
Speaker 3: you're gonna say, you're going to have a variable outside
Speaker 3: of that how many times have I retried? And then
Speaker 3: you can call itself again and increment your retry.
Speaker 4: Right.
Speaker 3: The other thing you can do in your catch is say, okay,
Speaker 3: this one's down, give me a different one. There's promise
Speaker 3: not all settled that you can use. So if you
Speaker 3: have like say, three three different APIs that you want
Speaker 3: to hit, but you know that one of them is
Speaker 3: likely to fail. But if you can get the data, great,
Speaker 3: If not, we'll move on, it's okay, situation. Or if
Speaker 3: you want to handle depending on let's say you've got
Speaker 3: your three calls, but you want to handle your failures
Speaker 3: a little bit differently, you can do and all settled.
Speaker 3: So what happens with the all settled is like, let's
Speaker 3: say one of your three of them dies in the middle, right,
Speaker 3: Unlike the promise at all, which goes ahead and and
Speaker 3: will throw an error if any of them fail. What
Speaker 3: they all settled does is it will return for all
Speaker 3: three a status of either okay or there's been an error,
Speaker 3: and then if there's an error reason so you can
Speaker 3: get you can still get your data for say like
Speaker 3: one in two and then you'll get your error for three.
Speaker 3: But then you have to make sure in your once
Speaker 3: you get the data that you realize that it's not
Speaker 3: just the raw data. It's got like the value and
Speaker 3: the status or the value or the status in error
Speaker 3: depending on So you've got to remap that to whatever
Speaker 3: you need. But that one's convenient if you have a
Speaker 3: service that you know is maybe a little flaky, that
Speaker 3: might but you still want to do whatever you're going
Speaker 3: to do with the rest of the data, or if
Speaker 3: you're okay with only partial information. That's one that's that's
Speaker 3: pretty useful for that.
Speaker 1: Yeah, yeah, you were talking about this.
Speaker 2: Some of these more advanced features in jabscript promises like
Speaker 2: all settled that this is where you get some power.
Speaker 3: Yeah. The other one if you know you've got that's
Speaker 3: that's part that I find particularly powerful. The only use
Speaker 3: case I've ever really seen it used for networking type
Speaker 3: of stuff, but is the race and where it's like
Speaker 3: you just want the first one that can get me
Speaker 3: an answer, get me that one nice. So you can
Speaker 3: put like, let's say one, two, and three in there,
Speaker 3: and once one of them fires, you're good. You've got
Speaker 3: an answer. You run with it, right, and it's going
Speaker 3: to give up on the other two, right, So from
Speaker 3: a speed perspective, that's super nice.
Speaker 2: Whether they come back or not, you're just going to
Speaker 2: ignore the results, right. So, yeah, you've got multiple services
Speaker 2: that can bring you the result. You just want the
Speaker 2: fastest one.
Speaker 3: Yeah, Now, raise will if one of them fails, it
Speaker 3: will fail out the same way as promised at all.
Speaker 3: If you do promise that any it will try until
Speaker 3: it gets an answer, it will give you the fastest
Speaker 3: answer that hasn't failed, and it won't fail until all
Speaker 3: of them has failed. So if you really want, just
Speaker 3: give me whatever as fast as humanly possible, ignore all
Speaker 3: failures unless everything fails, obviously, but it's promised that any
Speaker 3: which is kind of really powerful. I have not found
Speaker 3: a use case for that one yet, but one day,
Speaker 3: one day, I.
Speaker 2: Will literally are you know, calling three different services from
Speaker 2: three different places that are going to provide the same result,
Speaker 2: and any of them will do.
Speaker 1: And I don't care if any of them fail as
Speaker 1: long as one of them doesn't, right, sure exactly. Yeah,
Speaker 1: it's nice. Yeah, that is powerful. It's powerful and a
Speaker 1: bit weird, but you know, well strange. I mean, I'm
Speaker 1: thinking about the alternatives. The alternative is using sort of
Speaker 1: round robin dns. You know, if you've got like three
Speaker 1: services that are all trying to share the load or whatever.
Speaker 1: But what you're doing is you're hitting all three of
Speaker 1: them all at the same time rather than a round robin,
Speaker 1: So may put a little more load on the network,
Speaker 1: but you at least get the result that you want.
Speaker 4: You know.
Speaker 1: Yeah, first, first person to give me a chicken sandwich,
Speaker 1: I'll eat it.
Speaker 3: The other actually, the one of the US because I
Speaker 3: could think for that would be if you're calling something
Speaker 3: like from a CDN, so you could call multiple CDMs
Speaker 3: so that if one of them is down right.
Speaker 2: Yeah, yeah, sure you do want that any sense, because
Speaker 2: I don't care if there's a failure as long as
Speaker 2: there's one that.
Speaker 3: Doesn't fail, right exactly.
Speaker 1: Yeah, that's what's important. But you do have to throw
Speaker 1: the other two chicken sandwiches away, I mean, there isn't
Speaker 1: if they if you're.
Speaker 3: Goin of like, well it would I'd have to double
Speaker 3: check the network. But the network calls from the browser,
Speaker 3: but I think it actually abandons the network call, like
Speaker 3: it terminates.
Speaker 1: If it always drops the connection. Well, that's good.
Speaker 3: I think I'd have to double check that, and it
Speaker 3: might that might even be browser specific, so that that
Speaker 3: would be don't quote me on that one, because I'd
Speaker 3: have to actually.
Speaker 1: Look at that, But that would be smart. That would be,
Speaker 1: you know, in a perfect world.
Speaker 3: In a perfect world. Yeah, because the Internet is perfect,
Speaker 3: it has yeah never never, and JavaScript is perfect, it
Speaker 3: has no flaws.
Speaker 1: It's the best language ever.
Speaker 3: It was totally thought through when it was created, right.
Speaker 1: Oh, definitely. I think it took a weekend, right, So
Speaker 1: let's yeah, Well, let's talk about some challenges when approaching
Speaker 1: acink JavaScript programming for the first time. What are people
Speaker 1: getting hung up on?
Speaker 3: One of the common one of the common things I've
Speaker 3: seen when I'm teaching people how to use promises is
Speaker 3: they'll learn a pattern and they'll try to use it everywhere,
Speaker 3: no matter what. And I don't think this is specific
Speaker 3: to promises.
Speaker 1: Here's your hammer, find the nails exactly.
Speaker 4: They'll learn I go.
Speaker 3: Let's say they'll learn a sink await right, and they
Speaker 3: will regardless of whether it needs to be parallel or not.
Speaker 3: They'll just like await everything right. And so I mean,
Speaker 3: in the end it works, and this is the piece. Right,
Speaker 3: in the end, it works if even if you need
Speaker 3: it technically to have them in parallel, you await everything
Speaker 3: you you're gonna you're gonna take a performance hit, but
Speaker 3: it'll work. Right. So I think those are the most
Speaker 3: probably nefarious things because it's.
Speaker 1: Not like it's broken, and we have the same problems
Speaker 1: sea sharp Right. Once you learn a sync awight, you
Speaker 1: want to do everything a sink and don't necessarily need
Speaker 1: to a perfect example of this is data access right.
Speaker 1: Data access can be completely done with adeo dot net,
Speaker 1: which is sort of the lingua franca of dot net,
Speaker 1: sql access or whatever, and it can all be done synchronously,
Speaker 1: and it should be done synchronously because there isn't any
Speaker 1: reason not to. When you add a sync to it,
Speaker 1: even though you're not using it now, you're requiring the
Speaker 1: method that calls it to be a sync. So property
Speaker 1: getters and setters become more difficult, you know, just standard
Speaker 1: events that aren't marked a sync that you don't want
Speaker 1: to mark a sync that kind of stuff. So, yeah,
Speaker 1: we have the same problem over here.
Speaker 3: The other one I see, which is again is a
Speaker 3: little bit more advanced, but it's the trying to mix
Speaker 3: and match two things and make them work well together.
Speaker 3: So like not realizing that you can fairly easily transform
Speaker 3: a call back into a promise and then trying to
Speaker 3: mix your callbacks and your promises and ending up in
Speaker 3: some weird, kind of weird Christmas tree jumbold mess because
Speaker 3: you're trying to mix the two or same with So
Speaker 3: if you're using RXGS and you're using observables in an
Speaker 3: RXGS chain, so let's say you have your first you know,
Speaker 3: you get your your calling, your observable you get, and
Speaker 3: then you're going to do a pipe with your maps
Speaker 3: and your switch maps and your all of those things.
Speaker 3: You can actually return as part of a switch map
Speaker 3: a promise instead of an observable, and it'll take it
Speaker 3: like a champion on the output return and observable. So
Speaker 3: that's kind of but what I see is people not
Speaker 3: realizing that they can do that and that that promise
Speaker 3: as long as you're starting with an observable in RXGS,
Speaker 3: you can stick and promise in the middle or call
Speaker 3: that's actually to a promise in the middle, and it's fine,
Speaker 3: and it'll take it. I mean, you're going to get
Speaker 3: a one time value. It's not going to be a stream,
Speaker 3: but it'll it'll work. And so I see some weirdnesses
Speaker 3: in trying to like shoehorn in various often very creative
Speaker 3: ways the pieces together with not not quite understanding where
Speaker 3: they line up and how you can either turn one
Speaker 3: into the other or where chaining can just work and
Speaker 3: doesn't have to. And the other big one is like
Speaker 3: the Christmas train I talked about before, or instead of
Speaker 3: dot venning as a chain, they just kind of start
Speaker 3: nesting the dot bens forever and ever amen, which again
Speaker 3: works but not ideal and hard to read.
Speaker 1: Right right, did you say forever and ever amen? Yes,
Speaker 1: Hodding Randy Travis, there, I saw what you did there.
Speaker 1: All right, let's take a break and when we get back,
Speaker 1: we got some more questions from our tin doubt and
Speaker 1: we'll be right back. Don't go away. Did you know
Speaker 1: you can easily migrate asp net web apps to Windows
Speaker 1: containers on aws. Use the app to container tool to
Speaker 1: containerize your iis websites and deploy to aws Managed Container
Speaker 1: services with or without Kubernetes. Find out more about app
Speaker 1: to container at aws dot Amazon dot com, Slash dot net,
Speaker 1: slash modernize, and we're back. It's dot net rock some
Speaker 1: Carl Franklin. That's my friend Richard Campbell. Hey there, Martin
Speaker 1: dubtny is here. We're talking javascripts and let's see if
Speaker 1: you don't want ads. By the way, if you don't
Speaker 1: want to hear these breakads, you can become a patron
Speaker 1: at Patreon dot dot Nerocks dot com five bucks a
Speaker 1: month and we'll give you an ad free feed. Uh okay, Richard,
Speaker 1: you had a question, then I want to I have
Speaker 1: a question to change course. Yeah, well, just before the
Speaker 1: break Martine should have just dropped RxJS in our laps.
Speaker 1: I'm like, wait what yeah?
Speaker 2: Uh, Because I always thought that the reactive extensions were
Speaker 2: important before promises had been standardizing the browsers, like reactive
Speaker 2: js came along like twenty fifteen, twenty sixteen, and we
Speaker 2: didn't get uniformity on promises to like twenty twenty one,
Speaker 2: so it seemed like rxchas's a safe way to go.
Speaker 3: Right, it's fairly recently. Yeah, well they have very different purposes,
Speaker 3: So okay, like, can you do similar that you? So,
Speaker 3: let me back up with rxs and the concept of observables,
Speaker 3: assuming it's not an and and I think observable, which
Speaker 3: is a whole different ballgame. Let's let's muddel the two
Speaker 3: while we're at it, because of course we can't but
Speaker 3: an observable, whether it's just a dumb subject, a behavior subject,
Speaker 3: or a replace subject, is going to be a stream, right.
Speaker 3: Promises are one and done. So the fact that you
Speaker 3: can mix and match the two and the fact that
Speaker 3: you can kind of make both of them work together
Speaker 3: is a nice city. But they have a very different
Speaker 3: purposes in the grand scheme of things, Like if I
Speaker 3: want to continue listening to something, I can't use it.
Speaker 3: I mean, I can do things with promises, but like
Speaker 3: I still have to have my listener versus the observable
Speaker 3: with Once you subscribe to the observable, you're going to
Speaker 3: get that stream until you unsubscribe. Of course, because everything
Speaker 3: JavaScript has to be complicated, We're going to add the
Speaker 3: async subject in the mix, which is a one and done,
Speaker 3: which is an observable you subscribe to as if it
Speaker 3: was any other of the observable types, which but it's
Speaker 3: not going to fire off the result until it's completed,
Speaker 3: so it'll only ever have that one value.
Speaker 1: The way I think of reactive extensions is a way
Speaker 1: to turn event handling in the classic sense, where you
Speaker 1: have event listeners and you do something in the event
Speaker 1: handler and just turn that into like you said, a
Speaker 1: stream or something that you can query, hey, how many
Speaker 1: times did this event occur? And quantify that and give
Speaker 1: me the data that was passed in. And that came
Speaker 1: really into sharp focus when we interviewed remember Bjorn and
Speaker 1: the guys that did the helicopter whatever the drone programs
Speaker 1: at NDC, and they wrote a little tool to handle
Speaker 1: those because there's a lot of events that come right
Speaker 1: when they when they're flying around and they're moving, and
Speaker 1: they use the reactive extensions to to manage that, which
Speaker 1: would be absolutely impossible trying to do it with event handlers,
Speaker 1: timers and things. So anyway, that's that's my understanding of
Speaker 1: the reactive kind of observable model.
Speaker 3: The I think the most the most. There's kind of
Speaker 3: two places I use it a lot. I'm from going
Speaker 3: to use observables. I would say one of them is
Speaker 3: I do tend to work a lot with Firebase and
Speaker 3: Firebase as a real time database and the fire store.
Speaker 3: But either way it's it's a real time situation, right,
Speaker 3: So I can subscribe to my data, and as data
Speaker 3: changes in the database, I'm just going to get the
Speaker 3: latest and greatest directly so to me using this, you know,
Speaker 3: using the their system. So that's one of the ways
Speaker 3: where it's legitimately a stream that I'm you know, connected
Speaker 3: to my database directly and I want to get that
Speaker 3: stream now. Where that gets interesting, and then you have
Speaker 3: to worry about, Okay, I'm piping this to a form
Speaker 3: I maybe don't want my form values to go ahead
Speaker 3: and update just because somebody else updated the data day.
Speaker 3: So there's use cases where you have to start thinking, okay,
Speaker 3: where do I want it feeding me the stream or
Speaker 3: where do I want it to get the stream? Call
Speaker 3: it a one and done, and you know there's there's
Speaker 3: months is there. And the other piece is let's say
Speaker 3: I have a piece of data in a service, right
Speaker 3: that I'm keeping up to date so that I can
Speaker 3: potentially send to multiple components or multiple places in might UI, right,
Speaker 3: and it might be something local too. I don't know,
Speaker 3: let's say it's a let's do the number of visitor
Speaker 3: tickers something dumb, right, it doesn't matter what it is.
Speaker 3: And so that would be something where I can feed
Speaker 3: whatever the latest value is and any component Okay, I
Speaker 3: usually use Angular a lot, so any component would go
Speaker 3: ahead and you know, get that value an automatically update
Speaker 3: and automatically do what it needs to do in the
Speaker 3: UI and update the UI according or do some math
Speaker 3: or whatever. But those are kind of the two places.
Speaker 3: Is either for uy stay in terms of or maybe
Speaker 3: turning something off and on and being able to listen
Speaker 3: to an action happening anywhere and turn something off and on,
Speaker 3: or like dark mode is a good example that way
Speaker 3: doesn't matter where the button is and then or because
Speaker 3: then I can have the button trigger the update and
Speaker 3: then whatever's list switching over the theme is listening to
Speaker 3: that to that observable or connected to the database. But
Speaker 3: that's a little bit different. Then let's say your your
Speaker 3: promises where it's like a one and done. Once it's done,
Speaker 3: it's done. It's not there's no continual listening. But it
Speaker 3: also means that when you're dealing with the observables, you
Speaker 3: have to make sure to stop listening to them at
Speaker 3: some point, because otherwise you end up with them. Yeah,
Speaker 3: there's a cleanup step that now needs to happen, which
Speaker 3: doesn't happen in promises because obviously there were when I'm done.
Speaker 2: Okay, so I'm preeting pretty clear on our xas is
Speaker 2: for observers connecting to streams and being able to react
Speaker 2: to them accordingly. Yeah, maybe I'm not a clear on
Speaker 2: where i'd use promises versus async a weight and JavaScript,
Speaker 2: because you know, when I look at the rafts to
Speaker 2: async a weight, they basically say, hey, this is making
Speaker 2: promises nicer.
Speaker 1: Yeah.
Speaker 3: So yeah, so acync await is just is just a
Speaker 3: uh a way to do promises. It's not changing anything.
Speaker 3: It's just a how do you want to think of it?
Speaker 3: Maybe grammar like how do you want to structure your promise?
Speaker 3: That's all that's all it is to It doesn't change
Speaker 3: anything about the functionality. It's not do I want to
Speaker 3: use asink or promises? It's like I'm using promises and
Speaker 3: do I want to write do I wanted to you know,
Speaker 3: write it this way or that way? Essentially, that's all.
Speaker 3: It's just a syntactic sugar at that point.
Speaker 1: And you mentioned that you prefer using asnk a weight
Speaker 1: because you can do everything line by line rather than
Speaker 1: having dot the n's all over the place.
Speaker 3: Yeah, I just it's but it's not going to be.
Speaker 3: It's not I'm not going to be able to write
Speaker 3: it that way for everything because of the wholeation we
Speaker 3: were talking about earlier. Right, it depends on. But if
Speaker 3: I'm doing very much A, then B, then C very
Speaker 3: programmatically one two, three, four five, then I find it
Speaker 3: a lot easier to to handle, especially if I really
Speaker 3: don't care about error handling outside of it worked or
Speaker 3: it failed like my function worker failed, in which case
Speaker 3: I track at the block and I'm done, right.
Speaker 1: And you still have access to the ane and all
Speaker 1: settled and all that stuff, whether you're using the ACN
Speaker 1: syntax or just the promise intex Yeah.
Speaker 3: Oh yeah, yeah, because instead of doing promise dot all,
Speaker 3: you know, my array of promises dot done, I would
Speaker 3: do my results equals away promised dot all, my array
Speaker 3: of promises essentially.
Speaker 1: Right. Okay, a while ago before the break, you brought
Speaker 1: up map, and I'm not so sure many of our
Speaker 1: listeners know what that is in another one map switch
Speaker 1: or maple switch up.
Speaker 3: So those are all various RXGS functions that do various things.
Speaker 3: So in our which is okay, so map, there's your
Speaker 3: XGS map and then there's map in terms of mapping
Speaker 3: in arrays in JavaScript, so of course reduce the same name.
Speaker 3: So it's great, and they do different things. It's great.
Speaker 1: We'll be confusing at all, not at all, no.
Speaker 3: Not at all, but no, those are just ways to
Speaker 3: chain in ox in our XGS in order to do
Speaker 3: things with the data once you subscribe, you know, once
Speaker 3: you're doing something with your observable, right, So map would
Speaker 3: allow you to just transform the data and return switch
Speaker 3: map allows you to call another observable or promise and
Speaker 3: then return that. It's just with various ways of chaining.
Speaker 3: And there's I don't know how many, there's at least
Speaker 3: twenty or so, if not more. Various ones won't bore
Speaker 3: you with the details, really, people can read the dogs.
Speaker 1: But yeah, yeah, no, I think the main thing to
Speaker 1: know is there's a way to do this. Just go
Speaker 1: look at the docks. Yeah, very good. Any other gotchas
Speaker 1: that people find when they're starting the ACENC got down
Speaker 1: the ACENC path.
Speaker 3: I'd say where to put your catches, like where where,
Speaker 3: and how to catch your errors, like because you can
Speaker 3: say await my promise, dot catch and then return a
Speaker 3: different value if it fails in a series of your
Speaker 3: asinka weights and then still put it in a try
Speaker 3: catch block, which so means that if anything else in
Speaker 3: your function fails, then it would just go ahead and catch.
Speaker 3: So I would say, think through where your catches are
Speaker 3: and what they affect, so that you can know how
Speaker 3: and where you're handling your errors, because you can't actually
Speaker 3: do put a dot catch something dot catch inside of
Speaker 3: a try catch block and then figure out where your
Speaker 3: is being caught and by what and how right and
Speaker 3: the fact that a trycatch block the catch doesn't return
Speaker 3: a value. However, a dot if you do my promise
Speaker 3: doc you know, fetch my url whatever, dot catch, so
Speaker 3: my promise dot catch, you can actually take the air
Speaker 3: or swallow the air and return it if a value
Speaker 3: should at sale. So you could potentially have something where
Speaker 3: if you can't get a value, you're going to return
Speaker 3: some defult object. Right, you could totally do that or no, yeah,
Speaker 3: but then what do you do with that air? Or
Speaker 3: do you just swallow it and never know what happened?
Speaker 3: Do you send it somewhere for air handling? What do
Speaker 3: you like if you're going to swallow it, what are
Speaker 3: you going to how do you want to handle that
Speaker 3: in terms of you knowing it happened or do you
Speaker 3: even care?
Speaker 1: Right? So it's like, as long as something got returned, right, if.
Speaker 3: My dude entered his wrong password, I don't really care
Speaker 3: to send that to my server.
Speaker 1: You know, right, Like yeah, and c sharp reez that
Speaker 1: catch handlers for logging primarily and transforming whatever data is
Speaker 1: going to be returned if it's in a method. Right,
Speaker 1: If you have a method, you put the whole thing
Speaker 1: in a try, but you put the return value up
Speaker 1: the top before the try, and then modify it if
Speaker 1: everything is fine and it's not all I fits if
Speaker 1: you get an exception and return it at the bottom
Speaker 1: no matter what, or in a finally. But you know,
Speaker 1: that's just a pattern that I use a lot. I've
Speaker 1: seen it abused. I've seen try catches nested within catches
Speaker 1: for example.
Speaker 3: Yep, I've seen those two not good. I've seen those
Speaker 3: good or.
Speaker 1: Hidden dependencies where every time you tested it, it loaded in
Speaker 1: a particular order, so you never realize that actually it
Speaker 1: had an order dependency that you weren't protecting yourself from.
Speaker 1: Oh no, yeah, it's terrible. Yeah.
Speaker 3: Race conditions are fun too, when you've forgotten away somewhere,
Speaker 3: oh right, or.
Speaker 1: You forgot yeah, oh yeah, that's right.
Speaker 3: We do have finally as well. On javascripts we do
Speaker 3: have finally as well. But finally in an observable one,
Speaker 3: finally and I promise don't work the same, because of
Speaker 3: course they don't. Course not, what do you want they
Speaker 3: do when they they do when they don't. So finally
Speaker 3: in a promise does exactly what you think it's going
Speaker 3: to trigger, whether you've succeeded or failed.
Speaker 1: Right.
Speaker 3: Finally, in a stream will only hit when the stream completes,
Speaker 3: so it's not after every successful value. Once the stream completes,
Speaker 3: that means you've closed off, or you've said dot complete
Speaker 3: or you've shut that down. Well that's once the stream complete. So,
Speaker 3: but it's worth noting the difference that it's not going
Speaker 3: to be every time you get a value.
Speaker 2: Right, this is back to that stream versus one and
Speaker 2: done mindset right, correct, It actually is the same. It
Speaker 2: is actually I responded the same event it's the closing
Speaker 2: of the socket that raises the event. It's just that
Speaker 2: in an observable, it doesn't close to you complete exactly.
Speaker 1: Can I just make an observation? What's really amazing to me?
Speaker 1: We've been doing this show for how in years? Twenty
Speaker 1: three something like that, all right, and you've been there
Speaker 1: for most of them, Richard, So don't say you're the
Speaker 1: new kid. But when I started it, I said, we
Speaker 1: are never going to read code on this show, right, right,
Speaker 1: But we're getting very close with this. We are well,
Speaker 1: and I think we've been close before. I'm following it,
Speaker 1: and I'm thinking that a lot of people are following
Speaker 1: it too. Yeah, I know.
Speaker 2: I appreciate that. I've never had this clearer in my
Speaker 2: head than right now.
Speaker 1: Yeah, right that. This is why I wanted to call
Speaker 1: Martine in the first place. It's like, oh good, if
Speaker 1: she's explaining it, I'll probably understand it.
Speaker 2: So yes, now, now you see all the roles for
Speaker 2: each of these pieces, So that's good. It just makes
Speaker 2: sense to where and why you would use this but
Speaker 2: don't use it everywhere all the time. Why is that
Speaker 2: just complex?
Speaker 3: Well, I don't know. You know, if you have a
Speaker 3: hammer might as well.
Speaker 1: No, here's a hammer.
Speaker 3: Yeah, I can CSS important everything. It'll be fine.
Speaker 1: No, I can't believe you said that. That's something i'd say.
Speaker 3: I have to make fun of it. I have to
Speaker 3: make fun of my own world a little bit.
Speaker 2: Sure, I appreciate that, and we all do that, but
Speaker 2: I do feel like it introduces complexity, and it's only
Speaker 2: if you need it you should be asynchronous. That this
Speaker 2: does delay the rendering of a page. This isn't essential
Speaker 2: for people being able to do their work. Oh yeah,
Speaker 2: I really like a web page.
Speaker 1: I've that's crafted in a way where I'm still able
Speaker 1: to click on what I need because I knew where
Speaker 1: it was before the page was even finished loading. And
Speaker 1: it'll continue. It's fine. And an ACYNC tolerates that.
Speaker 3: Yeah, And that actually has more to do with how
Speaker 3: the JavaScript is loaded into the I mean there's two
Speaker 3: aspects to that. There's one, how are you loading that
Speaker 3: JavaScript while into the browser? Right, because you you might
Speaker 3: have browser you might have JavaScript that's needed immediately on
Speaker 3: the page load, versus you can get there when it
Speaker 3: gets there and then you can the actual the If
Speaker 3: you're doing dumb HTML, you've got the source on the
Speaker 3: source attribute. You can go ahead and put an acinc
Speaker 3: decorator and go ahead and make that, I think. But
Speaker 3: so that's part number one, and then part number two
Speaker 3: is how did you structure your HTML and what not
Speaker 3: to render based on when? When things load right? And
Speaker 3: what data do you need to load? Wet But there's
Speaker 3: two there's two aspects to that, which is also how
Speaker 3: is this JavaScript itself being loaded into the browser that
Speaker 3: may or may not block the rendering of the browser.
Speaker 3: And now you're getting into the whole core web vitals
Speaker 3: thing and all that fun stuff.
Speaker 1: But yeah, just because I'm too impatient away for a
Speaker 1: whole patient render. You know, a lot of these rules
Speaker 1: that Martine is talking about also apply in Blazer programming. Yeah,
Speaker 1: I mean it's basically web programming, you know, in web
Speaker 1: is web. So that's a good if any of the
Speaker 1: Blazer programmers listening too. It's a good rule to only
Speaker 1: use a sink when you need a sinc. Very good rule. Yeah,
Speaker 1: your environment's still the same, it's just the coding language chain,
Speaker 1: that's right, because it presumably the user's needs are the same,
Speaker 1: like users.
Speaker 3: Are impatient presumably Yeah, yeah, yeah, one the faster you
Speaker 3: get it up there too. I mean there's from a
Speaker 3: pure marketing and se O. Your SEU has good. If
Speaker 3: you've got a quicker to click time, your SEO is
Speaker 3: going to go up. Your marketing people are going to
Speaker 3: be happier, Like, there's all the reasons right right.
Speaker 1: People are never happy happy? Did I say that out loud?
Speaker 1: I feel bad. You want some fun when you're working
Speaker 1: in a development shop, go talk to the sales guys.
Speaker 1: Oh yeah, oh yeah, they don't like us. You know,
Speaker 1: they do not like us in the end, and we
Speaker 1: don't like them because they promise features you know that
Speaker 1: you don't even know about. You don't even know about
Speaker 1: much less know when you're delivered. Good idea to have
Speaker 1: lunch with a sales guy once a week. What have
Speaker 1: you promised this year? A good idea for the manager?
Speaker 3: Where did you get your estimates?
Speaker 1: Yeah? What lines have you told?
Speaker 5: Oh?
Speaker 3: You just rolled a handful of dies?
Speaker 1: Got it? I remember working for a software company and
Speaker 1: he basically used the word on all the time as
Speaker 1: a verb. Something of part of his job description was
Speaker 1: constantly unaff ing the things that need that were screwed up.
Speaker 1: He was an angry man.
Speaker 3: I've never used I've never used the F word in relationships,
Speaker 3: my job, or anything I was doing.
Speaker 1: Never, no, no, never never never. Okay, you heard it
Speaker 1: here first, folks. It's actually not a bad job title,
Speaker 1: you know, Carl Franklin. It's like, oh, you're the as man.
Speaker 3: We had a q I person we called the Harborder
Speaker 3: of Doom for a long time.
Speaker 1: I like that the Arbor of Doom approaches.
Speaker 3: In terms of fun titles.
Speaker 1: Yeah, definitely.
Speaker 2: When I was in my INFOSEC roles, it was like, oh,
Speaker 2: here comes the business impediment off.
Speaker 3: Now which role was that? Because I can think of
Speaker 3: multiple roles for that.
Speaker 1: Yeah. Yeah, there's a bunch of folks like that. You
Speaker 1: could argue the QA guys that, but INFOSEC especially, Yeah. Yeah,
Speaker 1: you will authenticate this person before anything proceeds. Sellers to that.
Speaker 1: You know what though, I mean, you know, if you
Speaker 1: have special roles in your database for users that they're
Speaker 1: never going to see what they are, you can make
Speaker 1: them whatever you want, right, So get creative. Some day
Speaker 1: that person realizes you tag their role as Harborder of Doom.
Speaker 1: Some day Harboringer of Doom.
Speaker 4: I did have a client once. One of the first
Speaker 4: things I had to do for them is they asked me.
Speaker 4: They're like, okay, we've been laxed, but unfortunately now we're
Speaker 4: shipping you know, this bundle to our clients, and so
Speaker 4: they can see our code. You need to go through
Speaker 4: and find all the profanity and.
Speaker 1: Remove and also just like comments like wtf what was
Speaker 1: I thinking? My family clearly wrote this because nobody else
Speaker 1: could have No.
Speaker 3: My favorite was the number of times I all because
Speaker 3: I E. And I've written this in code basiness before.
Speaker 3: So it made me double laugh because I was like,
Speaker 3: I haven't touched this before. How is my comments in here?
Speaker 3: Because I E. Is being a little sleep.
Speaker 1: Yes, that's legit. They shouldn't even be removed. That's just
Speaker 1: being honest, right right, I E. I E. Defect resistance requirements. Yep,
Speaker 1: Like wtf I see that in code all the time?
Speaker 1: Who wrote this crap? Well?
Speaker 2: I had a standard tag, you know, like a paragraph
Speaker 2: at the top of each of the perform misdoing things.
Speaker 2: Just like if this doesn't make sense to you, do
Speaker 2: not touch it. Yeah, ask someone else.
Speaker 3: Yeah, yeah, I do have a I do have a
Speaker 3: phone on a project. If you think about touching this file,
Speaker 3: I will haunt you.
Speaker 1: Yeah. The curse the curse, curse on your head comes
Speaker 1: your Liam Neeson. I will find you and I will
Speaker 1: kill you.
Speaker 3: Yes.
Speaker 1: Oh what the heck? Were we talking about JavaScript?
Speaker 3: Of JavaScript and where we love it?
Speaker 1: Yeah, the wonders. That's why we got to profanity. It
Speaker 1: was inevitable. I mean, oh man, oh man. Well I'm
Speaker 1: really grateful. This is a great explanation. It seems it
Speaker 1: seems like you shouldn't be afraid of this stuff. It's
Speaker 1: been and it's been true for a few years now.
Speaker 1: Like I just double checked, and like since roughly twenty
Speaker 1: twenty one, every browser responded more or less the same
Speaker 1: to this, so you can count on it.
Speaker 3: That's good and available in Node as well, so if
Speaker 3: you're in you know, if you're in that side of
Speaker 3: the universe, it does totally work there too, which is
Speaker 3: super cool.
Speaker 2: If you weren't frustrated enough with no JS, try ASNC
Speaker 2: and no j as.
Speaker 1: Yeah.
Speaker 3: Well that's the thing though for a node for a
Speaker 3: long time you had to have a package for doing
Speaker 3: a sync and so now it's actually legitimately available in node.
Speaker 1: They're using the engine. Yeah, because it's part of the language.
Speaker 1: Yeah right, yeah, that's good. Uh well, Martine Is there
Speaker 1: anything that we missed that you want to anything? You
Speaker 1: want to plug or talk about your book? You said
Speaker 1: you wrote a paper.
Speaker 3: Oh, I'm I mean I have my blog articles up
Speaker 3: on the blog for Andromeda Galactic dot com. I also twitch.
Speaker 3: I'm working on moving my Twitch to Monday nights. So
Speaker 3: definitely come look food, look for me there. Don't hesitate
Speaker 3: to come say hi. It's kind of hip random what
Speaker 3: will hit but it'll be front and dev something and you.
Speaker 1: Have Martine dot dev. Can you code and chat at
Speaker 1: the same time like that? I can't really challenge that's crazy.
Speaker 3: As long as it's something like there's so much in
Speaker 3: UI that's memorization, that's the same stuff no matter what.
Speaker 3: Like yeah, I might do my column with's through my robe.
Speaker 3: Height's a little bit different depending on the layout. But realistically,
Speaker 3: writing a writing the CSS to write a great is
Speaker 3: going to be more or less the same every time,
Speaker 3: or a flex or whatever. Yeah, as long as I
Speaker 3: figured out what I'm going to write most of the
Speaker 3: actual typing it out, I can do well. Chatting nice,
Speaker 3: not too difficultly.
Speaker 1: And your your personal website is Martin dot dev right correct?
Speaker 3: Yes, And all the links are all there.
Speaker 1: Yeah, stream links there, the blog links there, like everything
Speaker 1: you need is there. You told us the story, but
Speaker 1: tell the users how you got that.
Speaker 3: So when the dot dev extension came out for being
Speaker 3: able to get domains, the first thing I did, and
Speaker 3: like right came out. I want to look, I wanted
Speaker 3: to get Martin dot dev and it was Bob, and
Speaker 3: I cussed up because I never used the F word,
Speaker 3: so it was definitely not used in this use case.
Speaker 3: Cursing of whoever might have bought it, et cetera, et cetera,
Speaker 3: et cetera. It turned out that my partner Michael had
Speaker 3: bought it for me, so so nice.
Speaker 2: A story from rage to delight exactly.
Speaker 1: I mean, that's that's like if I had Carl dot com.
Speaker 1: You know, that's really good Martin dot dev fantastic, really good.
Speaker 3: Yeah well, I mean it has the advantage of not
Speaker 3: being too common of a name, so got lucky.
Speaker 1: I'm not well, this has been great, Thank you very much, Martine.
Speaker 1: And uh, well we'll talk to you probably in a
Speaker 1: year or so, because we seem to be talking to
Speaker 1: you once a year. Yeah.
Speaker 3: Yeah, well, I'll be delighted to come back anytime you
Speaker 3: want me.
Speaker 1: Great, Thanks all right, and we'll talk to you next
Speaker 1: time on dot net rocks. Dot net rocks is brought
Speaker 1: to you by Franklin's Net and produced by Pop Studios,
Speaker 1: a full service audio, video and post production facility located
Speaker 1: physically in New London, Connecticut, and of course in the
Speaker 1: cloud online at pwop dot com.
Speaker 5: Visit our website at d O T N E t
Speaker 5: R O c k S dot com for RSS feeds, downloads,
Speaker 5: mobile apps, comments, and access to the full archives going
Speaker 5: back to show number one, recorded.
Speaker 1: In September two thousand and two. And make sure you
Speaker 1: check out our sponsors. They keep us in business. Now,
Speaker 1: go write some code, see you next time.
Speaker 5: You got you
Speaker 3: D that Bess home and my taxes a line d