Speaker 1: Hello, and welcome to another episode of Adventures in Dutnet.
Speaker 1: I'm Sean Klaper. You're hosted with me today. Your two
Speaker 1: co hosts Wylou Hey, why good? The snow is finally
Speaker 1: melting so I can almost see my grass, all right?
Speaker 1: Or are the co hosts Caleb Wells, Hey, Caleb.
Speaker 2: Hey, guys, how's it going good? Good? Yeah, we got
Speaker 2: down into the thirties today, like thirty three, I think,
Speaker 2: right right above freezing with with rain, which is always beautiful.
Speaker 2: But I guess that's what you get in Normans, right,
Speaker 2: you're not going to all that often.
Speaker 1: Has it ever snowed there while you live there?
Speaker 2: Yes, yes, yes, that's okay, once or twice, but it
Speaker 2: doesn't stick, right, it's just yeah, yeah, you see it
Speaker 2: coming down, but yeah, it's it is rare. But if
Speaker 2: you go to the North Shore, it's right. We're in
Speaker 2: the Bowl of New Orleans and you have light contra
Speaker 2: trains to the north of US in the North Shores suburbs. Yeah,
Speaker 2: they get snow every three or four years or so.
Speaker 2: It's just far enough north, I guess. But yeah.
Speaker 1: Anyway, all right, so you're you're doing a double duty today, Caleb,
Speaker 1: So you're You're right, you're also a guest. I think, well,
Speaker 1: you know last a couple of times, so you're probably
Speaker 1: good at it.
Speaker 2: Well, I think last time you guys said I had
Speaker 2: some work to do and you weren't sure if you
Speaker 2: were invite me back. Well, I figured, right why I
Speaker 2: did the last episode on the whole power platform, so
Speaker 2: I figured I could I could take a stab at
Speaker 2: some Blazer stuff, which right there, there always seems to
Speaker 2: be something new in Blazer Land because it just keeps
Speaker 2: picking up steaming momentum and new features and functionality and
Speaker 2: ways of using it. And so today I actually thought
Speaker 2: we could talk a little bit about Blazer and job
Speaker 2: script interrupt, right, and one of the big go ahead.
Speaker 1: Yeah, all these states that we really haven't covered that.
Speaker 1: You know, we've covered the basics and new features and
Speaker 1: things like that and previous shows, but we really haven't
Speaker 1: gone into the interrupt part of it and maybe working
Speaker 1: with other frameworks and things like that. So, yeah, it
Speaker 1: sounds interesting. Where should we start.
Speaker 2: So I think probably one of the reasons why we
Speaker 2: haven't talked about job scripin or op and maybe it
Speaker 2: doesn't get as much fanfarees R at the whole point
Speaker 2: of Blazers and I have to do JavaScript right, or
Speaker 2: at least that that was one of its big selling points.
Speaker 1: But yeah, so we should start off with when should
Speaker 1: you use interrupt.
Speaker 2: Well, you're going to have to use it in certain instances. So, right,
Speaker 2: the web assembly standard doesn't currently have full access to
Speaker 2: the DOM and so that means you're going to have
Speaker 2: limitations when it comes around things like geolocation or local
Speaker 2: storage that kind of stuff, right, And so what you
Speaker 2: end up have to do is you have to go
Speaker 2: through jobscript through those What I think most people don't
Speaker 2: realize is that in order for your page to load
Speaker 2: and for the Blazer to get the web assembly and
Speaker 2: the WASM and all that up and running, it actually
Speaker 2: talks through JavaScript to talk to the don to get
Speaker 2: all this stuff set up in the UI updated. So
Speaker 2: you use the jobscript, whether you realize it or not.
Speaker 2: Down the road, as they evolve web assembly, which they're
Speaker 2: planning on doing and giving it more access and bringing
Speaker 2: in a line with jobscript, some of this will go away,
Speaker 2: but there are instances where where it's needed and you're
Speaker 2: going to have some form of jobscript layer to get
Speaker 2: some of this functionality. So the next thing when it
Speaker 2: comes to this stuff is Blazer has interface for a
Speaker 2: GAS runtime which allows you to invoke functions, make asynchronous
Speaker 2: calls back and forth. It allows you to send and
Speaker 2: retrieve data, right, which which is doing behind the scenesy way.
Speaker 2: But you're going to need for this functionality, and that
Speaker 2: led us to try a proof of concept which has
Speaker 2: been done before, and that is taking web components and
Speaker 2: getting those to work inside of Blazer. And when I
Speaker 2: say web components actually mean the HTML definition which I
Speaker 2: can actually read it.
Speaker 1: Right.
Speaker 2: It's a set of features that provide a standard component
Speaker 2: model for the web, allowing for encapsulation and interoperability of
Speaker 2: individual HTML elements. And so the idea is you end
Speaker 2: up creating your own custom tags, very similar to how
Speaker 2: you do it at Angular or React or view, and
Speaker 2: you inject those into the page the same way that
Speaker 2: Blazer does. Kind of the component model a setup, right.
Speaker 3: So is it basically The advantage of that is that
Speaker 3: it is framed with Yes it is. It's like you know, yeah, yeah,
Speaker 3: so that's how you can angle it.
Speaker 2: Yeah, it's right. It's basically HTML and jobscript and if necessary,
Speaker 2: if you want it, you can bundle CSS in there too,
Speaker 2: and it's portable. All the current browsers will recognize this
Speaker 2: content as long as you provide it the actual files
Speaker 2: to load that content, and it'll work out of the
Speaker 2: box in any application pretty much. It's actually an interesting
Speaker 2: side note is that Angular io their website where they
Speaker 2: do all their documentation and workflows, the majority of that
Speaker 2: is Angular Web components. And the reason being is you
Speaker 2: can manage this website and you can be a doc
Speaker 2: writer or do tutorials and not have to know necessarily
Speaker 2: how to build your own Angular app or all the
Speaker 2: intricacies that go into a web component. You just know
Speaker 2: the inputs and outputs and you can build stuff that way.
Speaker 2: And Angular calls this Angular elements. What it ends up
Speaker 2: being is a web component. So what we did was
Speaker 2: we already have several Angular applications running because we have
Speaker 2: a couple of teams inside the company. We have a
Speaker 2: couple of teams that are contract and the contract teams
Speaker 2: have been doing mostly Angular stuff. And so and I
Speaker 2: think I've told you guys, we've got like between services
Speaker 2: and apps, we've got like one hundred it's a ridiculous number.
Speaker 2: They're wanting to consolidate that down and when I was hired,
Speaker 2: we decided that we wanted to move forward using Blazer
Speaker 2: right because the majority of our internal team is dot
Speaker 2: Net Framework or dot Net and c sharp focus, and
Speaker 2: Blazer gives us that ability to be able to learn
Speaker 2: its version of Razor and then be able to use
Speaker 2: our Sea sharp knowledge and kind of right go to town.
Speaker 2: But we had to figure out a bridge between Angular
Speaker 2: and Blazer and or they wanted a bridge. Right. For instance,
Speaker 2: if we have this Angular application that has a bunch
Speaker 2: of components and we want to be able to reuse
Speaker 2: those until we can rebuild them in Laser, how are
Speaker 2: we going to do that? And we actually got a
Speaker 2: working model which is which is really interesting because you
Speaker 2: end up doing a deep dive into a job inter
Speaker 2: ops inside of Blazer. And so what you do is
Speaker 2: you have your your normal Angular components. They're doing their
Speaker 2: their stuff inputs, outputs, the ventomitters, and there are certain
Speaker 2: steps you have to take inside of Angular to be
Speaker 2: able to export these, but you can export them as
Speaker 2: custom components web components, and then you reference the javascripts,
Speaker 2: the polypills and the Angular code as well as your
Speaker 2: elements and at the bottom of your index and then
Speaker 2: you can reference those tags in any of your Blazer components, right,
Speaker 2: And they can be as simple as an Angular component
Speaker 2: that takes an input, and when when the website loads,
Speaker 2: the Angler component is themeless. Right. You have an Angular
Speaker 2: input and you pass in a variable like your name
Speaker 2: into that the property on that tag, and when the
Speaker 2: the browser loads up, the angler is transparent. You really
Speaker 2: can't tell just by looking at it what's Angular and
Speaker 2: what's not. And it's going to show you your name
Speaker 2: that came from Blazer into the Angular component, right, and
Speaker 2: that's I guess, yeah, it's a it's a web component
Speaker 2: at that point, yes, yep, yeah, and that's all finally good, right,
Speaker 2: But that's that's kind of got limited use, right. Most
Speaker 2: of your Angular components are going to be more complex
Speaker 2: and so right, we had to actually do some tests
Speaker 2: where we're passing in like Jason data, right, or you
Speaker 2: get a call you call an API from Blazer, and
Speaker 2: you need to be able to pass those objects into
Speaker 2: this web component. And it's really interesting how how they've
Speaker 2: done this, because what you end up doing is you
Speaker 2: have your own custom JavaScript where you can write, you
Speaker 2: can build your own functions that hang off the dom
Speaker 2: and if you need to talk back and forth, you
Speaker 2: not only pass in this object this data, but you
Speaker 2: pass in a dot net reference and it's actually called
Speaker 2: dot net reference, and it's a reference to this component
Speaker 2: or the contents of that Blazer component. And so if
Speaker 2: you say you have a chart widget, right, that's an
Speaker 2: Angular and you like the way it looks and likes
Speaker 2: the functionality, but there's functionality built into it. Right, you
Speaker 2: click events or filtering or whatever, right, you can actually
Speaker 2: have that loaded on the screen, and when you do
Speaker 2: button events, it's going to admit those events. You're going
Speaker 2: to have an event listener. It's just going to trigger
Speaker 2: those events and actually return the data to Blazer through
Speaker 2: that dot net reference. And the Blazer can manipulate code
Speaker 2: outside of the web component to do whatever you want
Speaker 2: to do. So there's there's a lot of power that's
Speaker 2: built into it. One thing that we're going to have
Speaker 2: to figure out as we go, right, is our existing
Speaker 2: Angular components. They're not dumb components, right. They typically have
Speaker 2: a good deal of functionality, and they may be calling
Speaker 2: their own Angular services right using RxJS or whatever. And
Speaker 2: we're going to have to look at how how we're
Speaker 2: going to manage that because the Angular services we're not
Speaker 2: going to bring over, right, They're not going to be
Speaker 2: compiled into the component. And there's no way, at least
Speaker 2: that I found this point to be able to manage
Speaker 2: them separately. So we're gonna end up having to do
Speaker 2: those API calls in that state management in Blazer or
Speaker 2: in c sharp classes versus doing them in Angular services.
Speaker 3: What about the payload, Like, is each Angular element that
Speaker 3: you can added to a webpone have basically the entire
Speaker 3: Angular framework on that you could?
Speaker 2: I wouldn't, I would advise against it. Yes, yeah, Payler
Speaker 2: is something you have to factor in. And that's actually
Speaker 2: where when you build out the Angular elements, right, and
Speaker 2: you get your disk folder, you can determine how the
Speaker 2: job script is broken up. And what I've done is
Speaker 2: I have two jobscript files that are strictly Angular based, right,
Speaker 2: the polypills that it needs for certain browsers, and then
Speaker 2: the Angular code which is just main gs between the
Speaker 2: two of those, right, it's you know, maybe a little
Speaker 2: over a meg. And then I have a separate jobscript
Speaker 2: file that actually houses all of the web components. And
Speaker 2: of course that file can get fairly large. Depending on
Speaker 2: how many you have or you're pulling in and there's
Speaker 2: really no tree shaking for that. But that job script
Speaker 2: can then reference the separate polyphyl and main and not
Speaker 2: have that load every single time. Now, freach Blazer component,
Speaker 2: you go into that job script, those web components script
Speaker 2: had to be initialized. But in my testing it's really
Speaker 2: there's really no performance difference between it and Blazer. Of
Speaker 2: course we haven't done you know, extreme edge cases or anything,
Speaker 2: but it performs well at this point.
Speaker 1: So it's really the main use of it is just
Speaker 1: for bringing over components that you don't have in Blazer.
Speaker 1: Could it be you know, like third party components that
Speaker 1: they read it wrote it for some for some jobscript framework,
Speaker 1: like maybe some Bootstrap components or things like that, and
Speaker 1: you can interrupt with those with Blazer.
Speaker 2: Yeah, yeah, if you if you needed to, you definitely could.
Speaker 2: Like like I said earlier, right, Blazer is growing elites
Speaker 2: and bounds and the dishes they're adding to it in
Speaker 2: the features, so there there are a ton of components
Speaker 2: that will do anything you could do or almost anything
Speaker 2: you can do in an Angular or React, boot Strap
Speaker 2: or whatnot. But I do see this as a is
Speaker 2: for people who have a lot of SPA frameworks, a
Speaker 2: lot of job script apps and they want to transition.
Speaker 2: This is kind of a bridge, or it could be
Speaker 2: the One of the interesting things about doing that SITS
Speaker 2: is some of the additions they've added a Blazer is
Speaker 2: you can now actually export Blazer components as web components
Speaker 2: and then we use them in Angular or React apps
Speaker 2: if you want to, or any app. Right, so it
Speaker 2: goes both ways, but I see right, they're trying to
Speaker 2: make it as easy a transition as possible if you
Speaker 2: want to transition and you and the majority of your
Speaker 2: developer knowledge is in c sharp. One of the other
Speaker 2: interesting things that we ran across, at least I find
Speaker 2: the interesting, but I'm also a designer UI guy, is
Speaker 2: you can have an Angular app that, for instance, say
Speaker 2: is using material design right in the material INPM packages
Speaker 2: and all that stuff, and you can actually change the
Speaker 2: styling in those components to use Bootstrap styling, but never
Speaker 2: install Bootstrap and Angular. And when you create the web components,
Speaker 2: you have Bootstrap running a Blazer and you add that
Speaker 2: Angular component the web component, it's going to pick up
Speaker 2: the Bootstrap CSS because it has the right styles. Install
Speaker 2: itself appropriately for Bootstrap, without Bootstrap ever being inside of
Speaker 2: the Angler application, and vice versa. You can not have
Speaker 2: material inside a Blazer at all, right, because especially with
Speaker 2: material for Angular, you can get beyond just the CSS, right,
Speaker 2: they have their own web components that have job script
Speaker 2: and all that extra stuff and on where when you
Speaker 2: click on an input, the title or the field goes
Speaker 2: up above the input. All that functionality. You can get
Speaker 2: that in Blazer through Angular without ever having to install
Speaker 2: any material stuff inside of Blazer application, which is is
Speaker 2: an interesting workaround. I guess if you again, if you're
Speaker 2: trying to transition, you're trying to match up styles between
Speaker 2: two disparate apps.
Speaker 3: So do you see the use case of this as
Speaker 3: more like like like what you're doing basically converting legacy
Speaker 3: apps into run on like new Blazer apps, or do
Speaker 3: you kind of foresee maybe like maybe you have two
Speaker 3: teams or one one team working on a Blazer and
Speaker 3: then one team developing like new Anglar like Angler components
Speaker 3: and all that stuff into and tnvert into web components
Speaker 3: in that second.
Speaker 2: Yeah, I think I think both are perfectly valid use
Speaker 2: cases because right in a lot of cases, you may
Speaker 2: have a React app that you have new intention of
Speaker 2: converting the Blazer, Right, but then you have a whole
Speaker 2: separate team that's creating a new app and they're like, hey,
Speaker 2: we want to do this in Blazer, but we want
Speaker 2: to be able to use some of our existing components
Speaker 2: and manage the look and feel. Right, you could cherry
Speaker 2: pick and I'm not sure how we are actually builds
Speaker 2: their web component, sure if they have that functionality, But
Speaker 2: an angular you can cherry pick the components you want
Speaker 2: impullment a Blazer and vice versa. Right, if you end
Speaker 2: up building this awesome grid and Blazer with all the
Speaker 2: functional that you want, filtering, sorting, whatever, and you want
Speaker 2: to be able to reuse it, you can reuse it
Speaker 2: inside a reactor angular app. I do see this more
Speaker 2: as it's your code, use it the way you want
Speaker 2: to use it kind of thing, right, And so the
Speaker 2: I guess the possibilities really are end list just depends
Speaker 2: on how your like you said, how your teams are
Speaker 2: set up, what's your area of expertise, and where what
Speaker 2: your roadmap roadmap is where you're looking to go. And
Speaker 2: there's a few other things in Blazer and Dot and
Speaker 2: at six that I think people are going to begin
Speaker 2: to use more and more become more common as people
Speaker 2: get used to all the additions, because honestly, there's a
Speaker 2: ton of changes from five that that exists. I mean,
Speaker 2: if you're if you're migrating, it's pretty straightforward. But the
Speaker 2: but the functionality that you can do and in how
Speaker 2: you can segment out your jovascript has changed, Right, you
Speaker 2: can isolate jobscript to a specific Blazer component. You can
Speaker 2: also now with that six initialize some job script before
Speaker 2: the Blazer app is even loaded, and Blazer knows how
Speaker 2: to take that job script that content and initialize it
Speaker 2: properly so you don't have to wait to get access
Speaker 2: to the dom. So there's all kinds of cool stuff.
Speaker 2: I appreciate the effort they put in to making Blazer
Speaker 2: work with job script as well as they have, so I.
Speaker 3: Think that's the only way for it to succeed, to
Speaker 3: be honest, Like Lazowski's been around for so long, there's
Speaker 3: that such a big ecosystem of developers and andsting components
Speaker 3: and all that stuff, you really can't get away with
Speaker 3: having a front way that doesn't interrupt with it. But
Speaker 3: it's seed, so it's actually really good to see it.
Speaker 3: This is happening. You see what you're doing? Is it
Speaker 3: like it sounds like it's pretty totton edge like Is
Speaker 3: this like based on like some sort of Microsoft kind
Speaker 3: of pattern that they're published or have you kind of
Speaker 3: dislike experimented and just done your own thing?
Speaker 2: And so it's I don't think it's something they've officially published.
Speaker 2: But like I said, I'm not the first one that
Speaker 2: came up with this. There's actually Dan Roth actually has
Speaker 2: a GitHub rebolt out there that he dubbed a blangular,
Speaker 2: which is blazer and Angular. It's three years old. It's
Speaker 2: it's it's fairly ancient when it comes to development, but
Speaker 2: but it gives you the idea of how you get
Speaker 2: things to work. And I also found I found a
Speaker 2: resource on think texture where they did something similar. I mean,
Speaker 2: I can add these links to the show notes for
Speaker 2: those who are interested, but right so, so it was
Speaker 2: one of the things I took a couple of odds
Speaker 2: and ends pieces here and there, saw how they did it,
Speaker 2: and was able to build on it to kind of
Speaker 2: meet our initial needs. I'm sure that's going to grow,
Speaker 2: right as we figure out the Angular service stuff in
Speaker 2: our XJS but it's been it's been an interesting project.
Speaker 2: It's been a lot of fun. And I actually have
Speaker 2: a proof of concept that I need to get up
Speaker 2: on GitHub. I just haven't done it yet because I
Speaker 2: got to clean it up and you know, remove all
Speaker 2: the company related stuff.
Speaker 1: So so, what kind of lessons have you learned doing this?
Speaker 1: You know, are the things that you can't do or
Speaker 1: things you have to watch out for.
Speaker 2: Well, yeah, it's I guess technically there are very well there.
Speaker 2: I was gonna say, there's very few limitations when it
Speaker 2: comes to this, but it's it's more of being smart
Speaker 2: about how you use it right. I mean, you could
Speaker 2: jam five angular components into one page and me passing
Speaker 2: all this data and stuff in and maybe the performance
Speaker 2: tanks because there's just too much going on and there's
Speaker 2: just too much talking back and forth. I also, I
Speaker 2: would recommend if you're doing this right and you had
Speaker 2: you had, one thing you have to do with this
Speaker 2: is you're gonna have to write your own custom job
Speaker 2: script to allow Blazer and your web components to talk.
Speaker 2: So you're gonna have to know jobscript if you if
Speaker 2: you really want to get into this, and a suggestion
Speaker 2: there is right don't. Don't hang a bunch of functions
Speaker 2: right off the dom. Right, don't use global variables, don't.
Speaker 2: I mean, all this is common jobscript stuff. How you
Speaker 2: keep things clean and perform it. Right, create a create
Speaker 2: your own module hanging off the dom and put all
Speaker 2: your functions inside of that. And right, you're gonna have
Speaker 2: to keep in mind the not so much as the
Speaker 2: security implications, but right, job Script and Blazer right have
Speaker 2: their own access to the dom, to the browsers. And
Speaker 2: so you know, you might come across an issue where
Speaker 2: you know there's a mismatch there and you're not getting
Speaker 2: the results or the look and fill you won't and
Speaker 2: and if that happens, then yeah, you're gonna have some
Speaker 2: interesting deep and digging into your angular app and making
Speaker 2: sure that there's no issues there, and then how Blazer
Speaker 2: interrupts with that. I do think maybe this is a
Speaker 2: little a little bit of the wild wild West. You know,
Speaker 2: it's you're kind of you're rolling your own But I
Speaker 2: do see the possibilities and the functionality that you can
Speaker 2: get out of this, especially between multiple teams, to be
Speaker 2: worth the investment.
Speaker 1: So yeah, you probably don't want to put your angular
Speaker 1: elements into every row of a grid that's got a
Speaker 1: hundred thousand elements or something like that in there. So
Speaker 1: that's agree always something not smart to do.
Speaker 2: Right, So I think again, like you just said, a
Speaker 2: lot of it comes down to common sense and knowing
Speaker 2: your limitations, because right the whole point is getting a
Speaker 2: quality application out to your clients or your users that
Speaker 2: has good performance with as little development time on you
Speaker 2: as is reasonable. And again, I long term, I wouldn't
Speaker 2: take an Angular app, export all these components Angular elements
Speaker 2: and then plug them into their own separate Blazer components
Speaker 2: and just call them the day and you know, and hey,
Speaker 2: here's here's your new app. Here, you've got Blazer running,
Speaker 2: but it's really still just Angular. I would take that
Speaker 2: next step and then convert those web components to actual
Speaker 2: sea sharp Blazer components. But for us, I think it's
Speaker 2: going to be a good bridge going forward. And it's
Speaker 2: interesting because our contract teams actually did a demo last
Speaker 2: week or two weeks ago going over this proof of concept,
Speaker 2: and even though most of them are very familiar with Angular,
Speaker 2: they also have dot net c sharp background and seven
Speaker 2: of them were like, man, I've been I've been looking
Speaker 2: forward to this, like when do we get started? So
Speaker 2: it's going to be good and I'll keep out updated
Speaker 2: on the on the status. We'll see, we'll see how
Speaker 2: it goes.
Speaker 3: And it sounds be exciting, sounds like it's really cutting edge.
Speaker 2: It's fun stuff, right this. I guess this is one
Speaker 2: of the perks of my job is I get to
Speaker 2: go off on these adventures and see what actually what
Speaker 2: actually works. And there were enough resources out there to
Speaker 2: get me started that actually you know worked well. For instance,
Speaker 2: Dan's which Sean added to the show notes, so you
Speaker 2: guys will have it to get it to where we
Speaker 2: could actually use it in a production environment and be
Speaker 2: comfortable with it.
Speaker 1: All right, cool? Well, yeah, definitely keep us updated. You know,
Speaker 1: we will only see you like every week. So sounds good. Yeah,
Speaker 1: you guys ready for picks? Sure, I just got to
Speaker 1: figure out what the heck my pick is preparedness, preparedness,
Speaker 1: So I'll go first. I guess my pick is going
Speaker 1: to be the new merger of Microsoft and Acting, So
Speaker 1: it's going to be interesting to see, you know, how
Speaker 1: that goes. You know, I'm a big Blizzard fan, like
Speaker 1: Diablo and things like that, so be interested to see
Speaker 1: what happens with with those projects and where Microsoft takes it.
Speaker 1: But it's nice to see Microsoft kind of gun in
Speaker 1: there first with the game stuff.
Speaker 2: Now, well, you know, they've.
Speaker 3: Fifty billion dollars are on so probably the worth that much.
Speaker 2: Well, no, I think they probably overpaid, but they can
Speaker 2: afford to do that, right, And they they bought Bethesda
Speaker 2: the year before or the beginning of last year, so
Speaker 2: either there's there's a bunch of questions. Now are they
Speaker 2: going to add Border Warcraft to the Xbox Game Pass
Speaker 2: and are they going to a port it to to
Speaker 2: console and all kinds of stuff? So time will tell, right,
Speaker 2: But yeah, I think it's cool. All right, Why would
Speaker 2: you pick?
Speaker 3: So? This week? My pick is actually the Amazon fire Stick,
Speaker 3: which I kind of just picked up because it was
Speaker 3: like really cheap on my Amazon Prime thing. And it's like,
Speaker 3: I don't know, I even know why I bought it
Speaker 3: because I've already got but it's just like so much
Speaker 3: the Android one, Like it's so smoother and yeah, so
Speaker 3: I think my Android one was actually pretty old and
Speaker 3: it's a little bit like flaky or something like that.
Speaker 3: But yeah, I'm really enjoying the being I've never actually
Speaker 3: been the Amazon kind of ecosystem kind of thing. And yes,
Speaker 3: it feels like the look and feel of it's a
Speaker 3: lot more mature than the Android one.
Speaker 1: So yeah, all right, kil we came up with a
Speaker 1: pickh this is actually a food a foody pick and
Speaker 1: it may be a Southern foody pick.
Speaker 2: I don't know if you guys have ever had French
Speaker 2: onion dip, like with potato chips, right, My family were
Speaker 2: big snackers and so right, we like potato chips or
Speaker 2: free doos in French onion dip rain, it's it's like
Speaker 2: sour cream, but it's a it's a dip that's got
Speaker 2: it some taste and not our brands are equal, right,
Speaker 2: they're not all the same. And the best French onion
Speaker 2: dip I've ever had, and sometimes it could be hard
Speaker 2: to find. It's called hell of a good dip. So
Speaker 2: my pick is hell of a good dip. So if
Speaker 2: you haven't tried it, you should try it. If you
Speaker 2: can get it in Australia, why let me know. Okay,
Speaker 2: does good? Does it go good with veggmine? I don't
Speaker 2: know about vegamin but you know, hey, if you want
Speaker 2: to use salary instead of chips, if you want to
Speaker 2: try to be a little healthy. Salary works too.
Speaker 1: Very cool, all right, keleb. If you people have questions
Speaker 1: and they want to ask you questions, like I said, yeah,
Speaker 1: ask your questions about questions.
Speaker 2: I I think I have a Twitter account out there somewhere.
Speaker 2: It's Caleb Wells Codes, and you know, if you can
Speaker 2: get on GitHub and ping me on one of my repos.
Speaker 2: I'm also on LinkedIn. I think all my stuff gets
Speaker 2: thrown into bombs of the show notes, but I'm all
Speaker 2: over the place. So yeah, Hey, if you have any
Speaker 2: questions and I can, I can help. I would love
Speaker 2: to chat.
Speaker 1: If our listeners have feedback for the show, they can
Speaker 1: reach out and get in touch with me. I am
Speaker 1: on Twitter, I am at dot net superhero. Uh all right,
Speaker 1: thanks Caleb, Thanks?
Speaker 2: Why yeah?
Speaker 1: That show? All right. We'll catch everybody else in the
Speaker 1: next episode of Ventures in dot Net. Bye all