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 net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Hey, welcome back to dot need rocks. I'm
Speaker 1: Carl Franklin, an amateur count And although dev Intersection has
Speaker 1: hopefully come and gone, if the world hasn't ended, uh,
Speaker 1: we haven't been there yet. We're recording this on September thirty.
Speaker 2: Time shifting is a wonder, but yeah, we're we're headed
Speaker 2: there in a few days and then yeah, by the
Speaker 2: time this is published, it'll have happened. Actually, I think
Speaker 2: I'll be in Lizbeon on the week this is published
Speaker 2: for the Azure dev.
Speaker 1: So that's also appropriate because we're talking about Aspire and
Speaker 1: by this time, hopefully you'll have done the crazy gotten
Speaker 1: at rocks dot com should have been a spirified.
Speaker 2: A spirified because that's a word.
Speaker 1: But we don't know as.
Speaker 2: We can't just because you're going to build it on
Speaker 2: stage doesn't mean you're going to deploy it. That's right,
Speaker 2: that's right.
Speaker 1: Anyway, Chris Klug is here, we're going to talk to
Speaker 1: him about Aspire, and let's start with nineteen seventy two,
Speaker 1: which is our show number.
Speaker 2: Yeah, there's a.
Speaker 1: Bunch of stuff happened. The Watergate scandal.
Speaker 2: Yes, I think that's the single biggest piece of news,
Speaker 2: although you can always look at everything. Vietnam during seventy two.
Speaker 1: Oh yeah, yeah, significant stuff, the Easter offensive by North Vietnam,
Speaker 1: the US response with Operation Linebacker. Nixon went to China.
Speaker 2: Yeah, that's big news.
Speaker 1: Probably probably to take his mind off of water Well,
Speaker 1: it was a big breakthrough and it had been worked
Speaker 1: on for really a few years. Your Kissinger had been
Speaker 1: involved and so forth, like that's the beginning of the
Speaker 1: opening of China. That kind of helped lead us to
Speaker 1: where we are right now. And we got some beautiful
Speaker 1: cherry trees out of it, and they're still there.
Speaker 2: It's pandace. Don't forget the pandits.
Speaker 1: And the pandas, right, the Munich massacre during the Summer
Speaker 1: Olympics terrorist attack not good, and the troubles in Northern Ireland.
Speaker 2: Yeah, bloody Sunday.
Speaker 1: The troubles such a whitewashed version. Yeah, description of that troubles.
Speaker 1: A bunch of stuff. Like I said before the nineteen
Speaker 1: seventy two Winter Olympics, a lot of entertainment things happening.
Speaker 1: But I'm gonna let you take it from here with
Speaker 1: science and tech.
Speaker 2: Let's do space first, Okay, Big Year. Of course, Mariner
Speaker 2: nine arrives at Mars. We always think the Mariners are
Speaker 2: all the same, and they weren't. They were a class
Speaker 2: of planetary explorer. Some failed, some succeed and so forth.
Speaker 2: But Marina nine was a very large mariner was twice
Speaker 2: the size of the predecessors. Mariner eight didn't launch especially,
Speaker 2: but six and seven did. And this one's literally a
Speaker 2: thousand kilos where six and seven were about five hundred.
Speaker 2: Why because it carried enough fuel and power plant to
Speaker 2: go into orbit around Mars, the first time humans ever
Speaker 2: put something in orbit around another planet. Wow, And then
Speaker 2: spent about It's spent three hundred and forty nine days
Speaker 2: in orbit around Mars operational, taking pictures of the majority
Speaker 2: of Mars. Those photos used to plan the Viking landings,
Speaker 2: as well as giving us our first detailed photographs it.
Speaker 1: Looks like Gene Roddenberry's you know, Scape of External Planets
Speaker 1: was pretty spot on in terms of what of what
Speaker 1: Mars actually looks like.
Speaker 2: Yeah, Mars had you know, the problem we had with
Speaker 2: Mars was there was a year long dust storm in
Speaker 2: the earlier marindim missiones of the good and getting good
Speaker 2: pictures and like, what's going on? I just have no
Speaker 2: idea that it was this crazy dust him. But Mariner
Speaker 2: nine stuck around, was able to orbit rather than just
Speaker 2: to a flyby. It's difficult to get into orbit of
Speaker 2: on the planet. You think about the threading of the
Speaker 2: needle to pull that up. Exceptional achievement, good stuff. How
Speaker 2: about in computers? The last two Apollo missions, Okay, Paulo
Speaker 2: sixteen Young Duke Mattalie, which is the second rover mission
Speaker 2: secually called the J class missions the real science missions,
Speaker 2: and the final one of Paulo seventeen with Sernaan, Evans
Speaker 2: and Schmidt Harrison Schmidt being the only scientist to set
Speaker 2: foot on the Moon. He was a geologist. He had
Speaker 2: helped train the other test pilots. There are eleven test
Speaker 2: pilots that had walked on the Moon to try and
Speaker 2: find good rocks, and needless to say, he was better
Speaker 2: at than everybody else. He's the only human face ever
Speaker 2: photographed on the moon because he broke all the rules.
Speaker 2: He kept flipping up the visor to see the rocks
Speaker 2: better because he's a geologist. And it is actually a
Speaker 2: photograph of him with the visor flipped because that goldvisor
Speaker 2: stopped their eyes from burned out of their heads. But
Speaker 2: that didn't matter to rish Schmid. He really wanted to
Speaker 2: look at rocks, and he found easily the most important rock.
Speaker 2: He found this unshocked chocolatedite, which is a synthesis of
Speaker 2: olivine that showed that they rock formations were partially volcanic,
Speaker 2: and it spoke to the actual formation of the moon.
Speaker 2: Wow Incerning ended that mission with the we leave as
Speaker 2: we came, and God willing we shall return with peace
Speaker 2: and hope for all men.
Speaker 1: There is one thing we haven't talked about that happened
Speaker 1: in nineteen seventy two, and that's Richard Campbell and Carl
Speaker 1: Franklin started kindergarten because we were five. We were five
Speaker 1: thru and isn't that the year that you went from
Speaker 1: New Zealand to Canada?
Speaker 2: No, I just a couple of years before.
Speaker 1: And then oh okay, I thought you said, Oh no,
Speaker 1: you were five when you went to your uncle's house
Speaker 1: and had prairie dog target.
Speaker 2: Practice five, five or six. Yeah, it's you know, that's
Speaker 2: hard to when you're young, The Great Prairie Dog story.
Speaker 2: The microcomputer has been invented, or the CPU has been
Speaker 2: invented a couple years before, but the first scientific calculator,
Speaker 2: the HP thirty five, comes out in nineteen seventy two,
Speaker 2: although it does not use a four thousand and four. Now,
Speaker 2: this is the time when trigonometry and exponents were done
Speaker 2: with slide rulers, so the idea we had an electronic
Speaker 2: device that could do Trigg and exponents was a big deal.
Speaker 2: It also use the first implementation of a thing called
Speaker 2: a reverse polish notation or called postfix notation, where you're
Speaker 2: loading registers, so you go one enter to enter and
Speaker 2: then plus to add them together. And so if you
Speaker 2: were into those old calculators, that's where it began. Nineteen
Speaker 2: seventy two. Wow, as another from the previous show or
Speaker 2: another reference to Alan Shoeguard, he has now left IBM,
Speaker 2: gone to MEMORYX where he makes the shoe guard floppy
Speaker 2: drive or read write drive for MEMORYX called the six fifty,
Speaker 2: with one hundred and seventy five kilobits a storage on
Speaker 2: an eight inch piece of plastic.
Speaker 1: They weren't asking the question about is it live yet?
Speaker 2: No, I think that's an ad A little later on
Speaker 2: for cassette daves, well, that's.
Speaker 1: When they got into audio. It's probably later, but we'll
Speaker 1: probably get there in a couple of weeks.
Speaker 2: And I'd be remiss not to mention the C programming
Speaker 2: language Dennis Richie being released in nineteen.
Speaker 1: Seventy two currently get in Richie.
Speaker 2: And finally in video game history, the Magnavox Odyssey is
Speaker 2: released in nineteen seventy two in the US for one
Speaker 2: hundred US dollars that'd be about seven hundred bucks to day.
Speaker 2: And it was you know, basic screen Pong and you
Speaker 2: had two little knobs. It was Pong. Yeah, they had
Speaker 2: a few variations on the game, but essentially it was
Speaker 2: just Pong. They sold three hundred and fifty thousand units
Speaker 2: by nineteen seventy five. This is also the same year
Speaker 2: that one Nolan Bushnell makes a video game console called
Speaker 2: Pong and forms the company Atari, and is promptly sued
Speaker 2: by Magnavox and Settles.
Speaker 1: We would encourage our listeners to search the archives, the
Speaker 1: dot Rocks archives for Nolan Bushnell because we talked to him,
Speaker 1: yeah a few years ago.
Speaker 2: Yeah, one of one of Yeah, one of my heroes
Speaker 2: from back in the day. And it was interesting to
Speaker 2: actually meet the man, yeah, in his seventies and drink
Speaker 2: whiskey with him.
Speaker 1: Yep. And I just remember him saying at the end
Speaker 1: of it was an NBC, No, it was at dev
Speaker 1: it was it was or DEEV. Yeah, he was addressing
Speaker 1: the group and he said, you know, there's some very
Speaker 1: very smart people in this audience, arguably the biggest collection
Speaker 1: of smart people in Sweden right now in one room.
Speaker 1: And I have some advice. Go have babies.
Speaker 3: Because the stupid people are over popularly and you need
Speaker 3: to go home, talk to you significant other and say, honey,
Speaker 3: we're going to take one for the team.
Speaker 2: Yeah. He was a grandpa. No two ways about that.
Speaker 2: Absolutely funny. That's what I got seventy two crazy year.
Speaker 1: All right, so I guess we should get going with
Speaker 1: better no framework.
Speaker 2: Awesome, all right, what do you got?
Speaker 1: Our good old friend Simon Crop is working on this
Speaker 1: tool called Excelsior and it's an Excel spreadsheet generation library
Speaker 1: with a distinctive data driven approach.
Speaker 2: Oh okay, so is he using l MS.
Speaker 1: I don't think so. And it's pretty pretty much just
Speaker 1: you know, driven by Jason data and classes and you
Speaker 1: can save it to a stream and you can do
Speaker 1: custom headers and ordering and do some styling with with code.
Speaker 1: You know, it's all it's all code and Jason data.
Speaker 2: So just a tooling library to dump data into Excel
Speaker 2: with some formatting and exactabilities.
Speaker 1: Cool exactly. And there's lots of third party libraries that
Speaker 1: do this, you know, the big ones do.
Speaker 2: You can cut your paste, your Brain's out or CSV
Speaker 2: all the way, but it's nice to have a code
Speaker 2: driven way.
Speaker 1: Well, like I'm saying, there are third party libraries, you know,
Speaker 1: from dev Express and Telerating, those guys that have you
Speaker 1: know in Grape City, the original spread they have libraries
Speaker 1: that you can do this too as well. But this
Speaker 1: is an open source, free library from Simon Beautiful. Yeah,
Speaker 1: thanks Simon, Yeah, thanks Simon. No I learned it.
Speaker 4: LOVI it.
Speaker 2: Who's talking to us today? Richard grabbed Commentaler Show eighteen
Speaker 2: eighty one. The moment we did with when David Fowler
Speaker 2: talking a little bit about dot Net Aspire back in
Speaker 2: those very early days where I think they were just
Speaker 2: trying to figure out what the heck they were making,
Speaker 2: and Noel Anderton had this comment. He says, I would
Speaker 2: really like to hear them talk about Dapper. That's DAPR
Speaker 2: and Aspire. There seems to be a major overlap between
Speaker 2: these two projects that look to be mutually exclusive. Aspire
Speaker 2: seems to be a dot net centric view, where Dapper
Speaker 2: is more technologically agnostic. Less importantly, I'd also like to
Speaker 2: know where you see this in relation to intern Ol
Speaker 2: Developer Portal's IDP. You have to start an IDP dashboard
Speaker 2: and you have the creation of a new component. Scaffolding
Speaker 2: uses tooling being used by I DPS. Do you see
Speaker 2: Microsoft building and IDP and considering we've really not heard
Speaker 2: about IDPs again, so I don't know that it really
Speaker 2: took off right. Everybody's got their own approach to doing
Speaker 2: these things. But I do appreciate the term scaffolding, which
Speaker 2: is certainly the way I've looked at Aspire as code
Speaker 2: you use to generate other code that doesn't actually continue.
Speaker 2: Can you on from there of certainly will Luke Crisen
Speaker 2: on the whole Dapper versus Spire side, I do think
Speaker 2: they overlap to some degree, because in the end, it's
Speaker 2: trying to make cloud native code in whatever language you want.
Speaker 2: In this case we're talking specifically dot Net. I do
Speaker 2: think that Thespire goes deeper into the dot Net stack
Speaker 2: the Dapper's capable doing it. But I've been interested to
Speaker 2: do a Dapper show at some point in the future.
Speaker 2: Show we'll pay attention to that. So Noel, thank you
Speaker 2: so much for your comment, and a copy of music
Speaker 2: Coba is on it even if you'd like copyes to code.
Speaker 2: But I read a comment on the website at dot
Speaker 2: netroocks dot com or on the facebooks we publish every show.
Speaker 2: There a new comment there, and I read in the show.
Speaker 2: We'll send you copymies to go by.
Speaker 1: I was just using music to code by yesterday while
Speaker 1: I was working on a difficult problem. And uh yeah,
Speaker 1: it's still going strong. Twenty two tracks, MP three, flak
Speaker 1: and wave formats at musicdocode by dot net. All right,
Speaker 1: Chris Klug, let's bring you in here. I'm reading a bio.
Speaker 1: I'm reading a bio from the last show and stop
Speaker 1: me if I get anything wrong. Chris Klug works as
Speaker 1: a developer architect at Active Solution in Stockholm. That's right,
Speaker 1: working mostly with cloud based solutions for clients in a
Speaker 1: wide range of domains. Lately, his contracts have pulled him
Speaker 1: towards the DevOps area, working almost entirely with build and
Speaker 1: release automation as well as infrastructure as code. Both were
Speaker 1: somewhat uncharted areas to him, which suited him fine, as
Speaker 1: he loves learning new things and figuring out how to
Speaker 1: make them do what he wants them to do. Obviously,
Speaker 1: these days he's working with that that aspire. So welcome back, Chris,
Speaker 1: thank you, thanks for having me, thanks for being here.
Speaker 4: I can say that the intro is not really correct anymore.
Speaker 4: I haven't done devils for quite a while now, but
Speaker 4: I'm not actually touching cloud at this point either, because
Speaker 4: I'm at a bank that has everything in house. But yeah,
Speaker 4: it's I'm still a developer at least, so that part
Speaker 4: was correct.
Speaker 1: You were a full stack guy, right, I mean touch everything.
Speaker 4: I don't defront them anymore, so I don't call myself
Speaker 4: a full stack developer anymore. I I personally dislike the
Speaker 4: idea of full stack developer because I think there's too
Speaker 4: much in front end and back into note to actually
Speaker 4: know both of them really well. But that's me at least.
Speaker 4: I've decided to focus more on the back end side
Speaker 4: of things in the last few years.
Speaker 2: Right, Do you have any thoughts on on no One's
Speaker 2: comment about the relationship between Dapper and Aspire.
Speaker 4: I see them as very different things. So Dapper work
Speaker 4: as far as I understand, Dapper works pretty well with Aspire.
Speaker 4: I'm just I'm not a Dapper person. I've only used
Speaker 4: that on one project, and personally in that scenario it
Speaker 4: didn't give us very much. But I think Dapper is
Speaker 4: more of a way of abstracting away your environment, right,
Speaker 4: being able to plug and play different parts and replacing
Speaker 4: things in your environment by giving you pre defined interfaces
Speaker 4: that people can implement and then provide, whereas I think
Speaker 4: Aspire is more of a we will host your services
Speaker 4: for you. We're not going to give you any abstractions,
Speaker 4: but we will give you a bunch of hosting stuff
Speaker 4: for you instead. So they actually work pretty well together
Speaker 4: because you can use Aspire to spin up the different
Speaker 4: services you need, like reddish and seql and all the
Speaker 4: things that you would do and service buses and stuff
Speaker 4: like that, and then you use Dapper in your application
Speaker 4: to configure how they fit together. So yes, there's a
Speaker 4: bit of an overlap with the how it fits together
Speaker 4: kind of thing, but they are very.
Speaker 2: I don't know if this is true yet, but I
Speaker 2: could see Aspire being able to deploy Dapper as APIs
Speaker 2: in front of the services it just configured.
Speaker 4: For in theory. Yes, yeah, I think that would work.
Speaker 2: Yeah, I buy that. And of course there is the
Speaker 2: overlap on like the workflow side and things, and they
Speaker 2: both generately a dashboard, but yeah, I see there's difference.
Speaker 2: The main thing I see with Dapper is it's a
Speaker 2: set of building block APIs that Aspire seems to avoid.
Speaker 4: Doing, which I personally kind of like. But that's made
Speaker 4: because unless you have a very specific reason where you
Speaker 4: actually do switch out your services, then I personally am
Speaker 4: not a big fan of the least common denominator thing
Speaker 4: for all of the services you want to use. I
Speaker 4: don't mind pulling in an SDK for a specific service
Speaker 4: that I use, And I also feel like in ninety
Speaker 4: nine percent of my cases, the services I use are
Speaker 4: the same during development and during production. Because we use
Speaker 4: Sequel server, we use Cosmos, we use a bunch of
Speaker 4: services that you can run locally using emulators and things instead.
Speaker 4: So I haven't run into that porb currently for anything
Speaker 4: that we need, but maybe sometime in the future.
Speaker 1: So, in your opinion, what is the most essential service
Speaker 1: that dot net Aspire gives you. I mean, there's a
Speaker 1: whole bunch of things in there, but what's the most
Speaker 1: essential one.
Speaker 4: Oh, the most essential one for me is the ability
Speaker 4: to actually it's not a service as such, but it's
Speaker 4: running your own projects because you don't necessarily need any
Speaker 4: external services to make Aspire really useful. For me, the
Speaker 4: biggest thing that makes Aspire something that I really love
Speaker 4: having is the fact that I can take multiple of
Speaker 4: my services locally and just spin them up and debug
Speaker 4: them all at the same time in an easy to
Speaker 4: do way. And then on top of that, yes, you
Speaker 4: have all of the other services that they can help you
Speaker 4: out with, and those are just getting so many it's
Speaker 4: ridiculous by now.
Speaker 1: Right Well, in that family of services, when you say
Speaker 1: start a project and Aspire, what's the first thing that
Speaker 1: you turn on?
Speaker 4: The first thing I probably put put into everything I've
Speaker 4: built so far as a sequel, So for instance, yeah,
Speaker 4: because I use sequel server.
Speaker 2: How old school of you, right.
Speaker 4: Yeah, I know everybody's moving to postgrists and document databases
Speaker 4: and things, but the sequel has always been the foundation
Speaker 4: and background of what I've been building. It's very natural
Speaker 4: for me to go there. And the fact that is
Speaker 4: that easy just spin up, that's what I'm putting in
Speaker 4: there is my first thing in most cases.
Speaker 1: Yeah, about the red as cash, I know that that's
Speaker 1: something that a lot of maybe a lot of developers
Speaker 1: do know about it, but I think there's a huge
Speaker 1: sloth of the development community of dot net development community
Speaker 1: that is neither either never needed it or didn't know
Speaker 1: they needed it. But that can make a huge difference
Speaker 1: in performance and scalability.
Speaker 4: It can, and I think it's useful for a lot
Speaker 4: of scenarios. We're currently looking at it for my current project,
Speaker 4: but we're for we're doing a hybrid cash solution at
Speaker 4: the moment with in memory while actually using the met
Speaker 4: core hybrid cash with in memory and a sort of
Speaker 4: a semi permanent store as well. And we looked at readies,
Speaker 4: but we ended up going old school sequel again. Mostly
Speaker 4: because we're hosting on prem at a bank that's using Kubernetes, right,
Speaker 4: and we can't touch too much of the stuff there,
Speaker 4: and trying to get them convinced that hey, we want
Speaker 4: to run read this as well was not really an option.
Speaker 2: But you got to talk to it about standing up
Speaker 2: a new service. That's an interesting battle to have at
Speaker 2: a bank.
Speaker 4: That is a very interesting conversation to be had.
Speaker 2: I promise you, dude, I've done the mineral right. It's okay.
Speaker 2: It's one thing to stand it up. It's another thing
Speaker 2: to back it up, monitor it and like I know
Speaker 2: all of that stuff.
Speaker 4: He's equal they had so that was aacy, But yeah,
Speaker 4: I do. I agree with your carlab. I think reddis
Speaker 4: is the simplest and by far fastest way to gain
Speaker 4: performance out of your APIs and your services if you
Speaker 4: know not how to use it.
Speaker 1: I'm doing a manual cash of the dot net rocks data.
Speaker 1: So basically, we have a database to keep all this
Speaker 1: stuff in, and then we generate JSON files and put
Speaker 1: them in a storage account, and then we pull them out,
Speaker 1: but only on a timer, you know, like a couple
Speaker 1: of times a day or on an hour time or whatever.
Speaker 1: So everything's cashed in memory pretty much all the time,
Speaker 1: but it is a roll your own cash kind of thing.
Speaker 1: And I think that's probably the first thing that Maddie's
Speaker 1: going to want to tear out of there, and the
Speaker 1: place with redd is when I get on stage with her.
Speaker 2: And again with time shifting, Maddy has already torn out
Speaker 2: of there. Well she may or she may not have,
Speaker 2: but it will. See it's I got to feel in
Speaker 2: that's the first thing to go. I'm kind of excited
Speaker 2: to see Chris talking about cloud related stuff on an
Speaker 2: on prem implementation, like this is cloud as architecture versus
Speaker 2: cloud as a deployment location.
Speaker 4: Yep, yeah, so it's yeah, I don't know why. Well,
Speaker 4: it's funny because cloud native or cloud based development always
Speaker 4: indicates Kubernatist. For most people, that's fine, there's a and
Speaker 4: in this case it happens to be that we are
Speaker 4: actually running Kubernatis, but we're doing it on prem. But
Speaker 4: for me, the cloud native stuff is slightly different and
Speaker 4: it doesn't need to be Kubernetes. But that's where we're
Speaker 4: at the moment. But Aspire then has this interesting concept
Speaker 4: of deployment where it doesn't need to go to Kubernates
Speaker 4: even though you're doing a cloud ish solution.
Speaker 2: Although it certainly can. We did a whole show just
Speaker 2: talking about Aspire being a way to get to containers.
Speaker 2: If you're not already comfortable with it.
Speaker 1: Ye, is there Docker without Kubernetes in your opinion, not.
Speaker 4: Really too perfect? Honest. If I was going to run
Speaker 4: something for local, yes, but for production, no, I wouldn't
Speaker 4: run docer, Well, no, I wouldn't depending on how it well, okay,
Speaker 4: that's now you got it depends on how you look
Speaker 4: at it, right. If I was going to use Ashure,
Speaker 4: which is my native home for most of them stuff
Speaker 4: I do normally do. I believe in the idea of
Speaker 4: having container images in my web apps, for example, to
Speaker 4: do web aps for containers and hosting containers instead of
Speaker 4: running my applications natively on web apps for example, That
Speaker 4: makes sense. But using docer in a way where I
Speaker 4: touch docer and do docer run and everything like that,
Speaker 4: that's not.
Speaker 2: No.
Speaker 4: I would never do that.
Speaker 1: You're not.
Speaker 4: I'm not going to say it never because there will
Speaker 4: be a scenario, right, but right now I haven't seen
Speaker 4: that need as such. And if if I was going
Speaker 4: to go in that direction. Yeah, kubernet Is an akas
Speaker 4: would probably be better at choice.
Speaker 1: So imagine I'm a psychiatrist and you're on my couch,
Speaker 1: tell me about Yamo.
Speaker 4: About Yamo.
Speaker 1: What is your relationship to Yamo.
Speaker 4: It's the it's the shitty replacement for Jason because it's, oh,
Speaker 4: it doesn't have curly braces, but instead we make it white, white, white,
Speaker 4: space sensitive. So a minor little change causes everything to
Speaker 4: break down and it's really hard to debug. I don't
Speaker 4: like Yamo whatsoever.
Speaker 1: God, I feel so vindicated, Richard Nice. You know here
Speaker 1: I was thinking, I was like the you know, the
Speaker 1: odd man out saying I don't like Yamo, but apparently
Speaker 1: really smart people like Chris don't like it either.
Speaker 4: I wouldn't call myself very sad.
Speaker 2: Listen, anybody who says it like Yamo has Stockholm syndrome.
Speaker 2: Let's be clear, right, Like, I get.
Speaker 4: The point, I really do. And if you pull up
Speaker 4: a Yamo file that somebody has written that's already there,
Speaker 4: it's definitely a lot easier to read than than Jason
Speaker 4: because you don't have all of the curly bras and everything.
Speaker 4: But authoring them is a different story because offering them,
Speaker 4: all of a sudden you do a tab in the
Speaker 4: wrong place or a space in the wrong place, and
Speaker 4: all of a sudden, oh, you have now modified the
Speaker 4: entire thing. I'm not a huge fan.
Speaker 2: Well, ps code helps you by letting you know everything
Speaker 2: is read now and it's your fault.
Speaker 4: Yeah.
Speaker 2: True, Yeah, but I appreciate your thinking. YAML should be generated,
Speaker 2: should and then should be read only when you look
Speaker 2: at it.
Speaker 1: Yeah, it's kind of like assembly language, do not edit,
Speaker 1: you are not quality, should be treated as such. When
Speaker 1: you said Stockholm syndrome, it's funny because Chris is from Stockholm.
Speaker 2: Yep.
Speaker 1: The jokes just keep coming, just keep coming. Oh man,
Speaker 1: all right, So we talked about Reddish. Where are some
Speaker 1: of the other hidden gems in Aspire?
Speaker 4: Well, actually, I think there's there are hidden gems in
Speaker 4: Aspire that's not really about services like that. There are
Speaker 4: features I think that people are missing out on potentially
Speaker 4: an Aspire that I find to be really little gems.
Speaker 4: It's like being able to add customer commands to the
Speaker 4: dashboard is one of those things that just on the
Speaker 4: surface is like why would you need that? And then
Speaker 4: we're doing it in the current project where we have
Speaker 4: a little receive the database. So if somebody pulls it
Speaker 4: up and they need to restore the database back to
Speaker 4: a database that we can work with. It's not a
Speaker 4: manual task. It's not a script that needs to be run.
Speaker 4: You go into dashboard, you click the button and you say, hey,
Speaker 4: reseve the database, and it sets the database for us.
Speaker 4: It's nice, a nice way of doing it. We also
Speaker 4: have an export from SQL to Neo for j for
Speaker 4: some graph stuff, and we can redo that export using
Speaker 4: a command as well. It's just those little things that
Speaker 4: make it easier for people to use the dashboard as well.
Speaker 1: It's nice, I think, yeah, plumbing.
Speaker 2: Yeah, and you speak to doing more with how important
Speaker 2: a dashboard is in the dev cycle versus in the insductions.
Speaker 4: Well, that's the thing in the production cycle. It's I
Speaker 4: think to me currently Aspire kind of is a development
Speaker 4: time kind of thing. Once it's deployed, I don't seem
Speaker 4: as well deploying the Aspire dashboard or anything like that
Speaker 4: into a production environment, even though you can do that now.
Speaker 4: I mostly, as I said, look at it as a
Speaker 4: dev tool and that's where it can with things like
Speaker 4: little commands like that or maybe being able to look
Speaker 4: at different durls and actually have them properly describe what
Speaker 4: they do. Means that when you do a get pull
Speaker 4: F five to start the thing, you actually get everything.
Speaker 4: And now with the new support that they have where
Speaker 4: if you don't define parameters, it will actually ask you
Speaker 4: for missing parameters so you can get it down. You
Speaker 4: press have five and the first thing that says is
Speaker 4: the dashboard goes up and says, hey, there are missing
Speaker 4: parameters here. Can you give me the database password? Can
Speaker 4: you give me these other things? And then it stortes
Speaker 4: it to your user secrets automatically. Means that getting a
Speaker 4: new developer onto a project is so much easier, which
Speaker 4: I think is a massive benefit.
Speaker 1: Is yeah nice sharing. Configuration has always been an issue
Speaker 1: with me on the different teams that I worked on.
Speaker 1: Not not insurmountable, but you know you, like you said,
Speaker 1: you do a get pull and it doesn't work because
Speaker 1: of some configuration issue and oh you got to add
Speaker 1: this little section to your app settings whatever. So let's
Speaker 1: talk telemetry here. So open telemetry is everywhere and Aspire
Speaker 1: and in Azure, and you have that dashboard but once,
Speaker 1: once it's deployed, does that dashboard still work for you
Speaker 1: in terms of telemetry or do you go over to
Speaker 1: another kind of run time telemetry monitoring thing and Azure.
Speaker 4: Unfortunately, right now, I've been on my bank project for
Speaker 4: so long that it's actually been around the time that
Speaker 4: Aspire came out, so I haven't been able to do
Speaker 4: anything with Aspire with Azure, but I can know the
Speaker 4: dashboard that comes with a Spire would not be enough
Speaker 4: in my opinion, especially since it's as far as I know,
Speaker 4: in memory only right, so it doesn't persistent, So I
Speaker 4: would prefer having it offloaded to something else. As I said,
Speaker 4: I see the Spire dashboard as a nice thing for
Speaker 4: dev and then for production going to something like Honeycomb
Speaker 4: for example, or a third party system that is built
Speaker 4: specifically for that is probably the better solution. Or yeah,
Speaker 4: you can do application insights or monitoring.
Speaker 2: I mean, odds are your administrators already have a telemetry
Speaker 2: solution they need you to add too, And that's why
Speaker 2: they like open telemetry because they probably have an input
Speaker 2: feed for that. It's a good aim your app here
Speaker 2: at this endpoint. Now our telemetry adds to our existing
Speaker 2: monitoring solution. Yeah, Yep.
Speaker 1: It's a beautiful thing.
Speaker 2: Now, you hope, and then they'll complain about the crappy
Speaker 2: feed you've given them.
Speaker 4: But it's also I really like that because it's it's
Speaker 4: hard to get away from the fact that whatever dashboard
Speaker 4: day or solution they have solutions chosen for telemetry is
Speaker 4: a thing that's built purposely full for that thing. So
Speaker 4: it's going to be really good for that thing's not
Speaker 4: having to focus on that, not having to build your
Speaker 4: own telemetry monitoring system, which I've done over and over
Speaker 4: again for other clients, it's now really nice just shove
Speaker 4: it off and then do some own of your own
Speaker 4: custom hotel integrations instead, if you want to have your
Speaker 4: own metrics and your own spans and things like that.
Speaker 2: But if the new app is using Kubernetes, they already
Speaker 2: have an instrumentation pack for Kubernatores. They know how they
Speaker 2: want to look at the state of containers, so that's good.
Speaker 2: It's another part of why I don't want you to
Speaker 2: add redicity equation, because I now have to tune episode
Speaker 2: of telemetry for how do I know if Redis is
Speaker 2: happy or not? Yep.
Speaker 4: Yeah, Which that's actually an interesting point where you're saying that, Richard,
Speaker 4: that when you deployed, the ops guides will already have
Speaker 4: a thing for you, right, Yeah, And I think that's
Speaker 4: the way it works in and in most enterprises I've
Speaker 4: been involved in, there's always an obstavision that have very
Speaker 4: strict opinions, which then is interesting combining that with a
Speaker 4: spire's way of thinking about deployments. I know I've been
Speaker 4: on the show before and we talked about Infrastructure's code
Speaker 4: and some options that were out there and pollumium things
Speaker 4: like that, which I think was a cool idea, but
Speaker 4: it moved infrastructure into the developers region, and I think
Speaker 4: that is honestly a bit of a problem because most
Speaker 4: enterprises don't want their developers to mess about with infrastructure.
Speaker 2: Yeah. Now, you're right. If an organization has a deployment
Speaker 2: strategy already, and I'm telling you not all of them do,
Speaker 2: then they will be concerned. If they want to own
Speaker 2: that piece, then they want to understand that piece. And
Speaker 2: when you introduce other languages know the tuning around, they're
Speaker 2: going to get jumping about it, just like they jumping
Speaker 2: about ratus. But sometimes they don't have that. But they
Speaker 2: also get into trouble that way. Like, one of the
Speaker 2: issues you have when you have a lot of systems
Speaker 2: running in VMS are on against services in a shared
Speaker 2: infrastructure is badly behaved apps being introduced to the equation. Like,
Speaker 2: part of wanting to control the deployment is to know
Speaker 2: what it's impacting, to have better security controls on it.
Speaker 2: When you leave that too loose, you get surprised. Sometimes,
Speaker 2: you know, a new version of that app gets deployed,
Speaker 2: breaks this other thing over there, or gets a new
Speaker 2: security acount of that, or you know, lights off the
Speaker 2: seam right Like I've seen this happen where we didn't
Speaker 2: tell it that it's going to message this way, and
Speaker 2: suddenly it looks like a Dodos attack. The app operating normally,
Speaker 2: like the whole security system just goes berserk because we
Speaker 2: did this deployment.
Speaker 1: Like I love Poalumi, especially when you fry it, you know,
Speaker 1: because it doesn't melt so fast. It's really good. Geez.
Speaker 1: And on that happy note, let's take a little break.
Speaker 1: We'll be right back after these very important messages stick around.
Speaker 1: Did you know that you can work with AWS directly
Speaker 1: from your ide AWS provides toolkits for visual Studio, Visual Studio,
Speaker 1: Code and jet Brains Rider. Learn more at aws dot
Speaker 1: Amazon dot com, slash net, slash tools.
Speaker 2: And we're back. It's Donna Rocks. I'm Richard Campbell. That's
Speaker 2: Carl Franklin. Hey, hey here with our friend Chris and
Speaker 2: I seem to have fallen into the grumpy Sisaben role
Speaker 2: for this show, which I'm okay with because I know
Speaker 2: how to say no is good A where anyway?
Speaker 1: My friend?
Speaker 2: But I think, you know, we speak to this really
Speaker 2: challenging dynamic of you're building this complex software at the
Speaker 2: point where you have a tool like Aspire to help
Speaker 2: you with its construction and deployment, and your administrators need
Speaker 2: to understand it and you need to know where to
Speaker 2: interface with them, and it's obviously that deployment piece of
Speaker 2: telemetry piece, that services piece, Like that's a lot of
Speaker 2: conversations to have, like do you try and have that
Speaker 2: in advance or you just build some Aspire and see
Speaker 2: how it go.
Speaker 4: I would probably recommend having a conversation ahead of time
Speaker 4: because it kind of sucks when you spend a year
Speaker 4: building something and then you try to deploy it and
Speaker 4: opskys goes Nope, no, that's where I think, I'm not
Speaker 4: one hundred percent sure that I enjoy your I think
Speaker 4: that Aspire is going in the right direction of pushing. Hey,
Speaker 4: the configuration of the publishing goes to the developer. Once again,
Speaker 4: that doesn't work in a lot of areas unless your
Speaker 4: company then is big enough to build their own custom publishers.
Speaker 4: Because they now with the experimental stuff in aspires, it
Speaker 4: makes it possible for you for an organization to actually
Speaker 4: build something that is custom for their organization, which I
Speaker 4: guess would be a thing. But then the ops team
Speaker 4: needs to spec spence that specify that very well, and
Speaker 4: then the dev team has to build it for them
Speaker 4: and everything. But then if you you can then reuse
Speaker 4: that in theory at least.
Speaker 2: Yeah, I mean, I can see this being a real
Speaker 2: battle for the first deploy of the app. But once
Speaker 2: we get to an agreement, all that on that. Like you,
Speaker 2: you know, we're back to those old agile mindsets. If
Speaker 2: I want to be able to iterate quickly, so if
Speaker 2: I'm living within the constraints that have passed through the administrators.
Speaker 2: Once that the security contest is going to remain the same.
Speaker 2: Telemetry context is the same, the deployment pipeline is the same. Hey,
Speaker 2: deploy away. You know, don't interrupt me constantly with your
Speaker 2: next weird deploy Like I want to be highly involved
Speaker 2: in the first couple and after that, I'm kind of
Speaker 2: keen to let you guys iterate and get your features
Speaker 2: out without having a fight with us too much, or
Speaker 2: that we only talk about the delta. Hey, new telemetery here.
Speaker 2: You know, you need a new plumber in here. Oh
Speaker 2: my goodness, we need new service here. Yeah, I would hope.
Speaker 2: I mean, I just and buy me pizza and we
Speaker 2: can talk right, like honestly.
Speaker 4: Yeah, if you're that Adamin guy, I'd have to buy
Speaker 4: you a pizza. I my current or my current client is.
Speaker 4: It's not that idea. Uh, it's it's a very strict
Speaker 4: it's the every single application in the whole enterprise needs
Speaker 4: to be deployed using the same pipeline in Jenkins oh boy,
Speaker 4: Jenkins boy, and mostly focused on Java as well, so
Speaker 4: getting in there was kind of an interesting little way
Speaker 4: as well. So yeah, we've tried to fly under the
Speaker 4: radar and get our stuff done without having to talk
Speaker 4: too much to it and sorted it out, and like
Speaker 4: I said, reusing sequel for as much as possible because
Speaker 4: that's already there and needs to use.
Speaker 2: Yeah, you're literally doing staying within the guardline so you
Speaker 2: don't have to talk to them make it easier. Yeah,
Speaker 2: I appreciate that.
Speaker 1: I think I told this story before when we were
Speaker 1: talking about Aspire, but one of my customers wanted to
Speaker 1: aspireify their Blazer server application. So the only real issue
Speaker 1: they had was we're using poly and you know, the
Speaker 1: the stuff for for that is the HTTP Client Factory
Speaker 1: I think, and that's what Aspire uses. So there was
Speaker 1: like two you know systems going on there for for
Speaker 1: dealing with network outages and things. But that was right.
Speaker 4: Yeah, and that that can be fixed as well because
Speaker 4: all of that retry policy stuff for the client factories
Speaker 4: in the services default project, so you can you can
Speaker 4: either in case, you can either move the police stuff
Speaker 4: that you have built in the previous system through there,
Speaker 4: or you can remove your police stuff and use the
Speaker 4: services to fault and you should be good to go. Yeah,
Speaker 4: and I really I must admit I love that approach
Speaker 4: of having the Services default project where hey, here is
Speaker 4: everything we're doing and it's in C sharp format, where
Speaker 4: it's not a gazillion configuration things you need to plug into.
Speaker 4: We will give you the C sharp code. It just
Speaker 4: makes everything so much easier and exactly Yamo. Yeah, and
Speaker 4: it's not even Jason.
Speaker 2: Yeah right, it's its own thing.
Speaker 4: Yeah, the configuration code is always preferable in my world.
Speaker 4: It just makes it easier to have it in one
Speaker 4: place when you're a developer. I guess it's it makes
Speaker 4: it harder when you and admin and you need to
Speaker 4: maintain it afterwards, but it's don't know, I like having
Speaker 4: it as much as possible in code.
Speaker 2: Yeah, me too. What about testing? Like, what's your testing
Speaker 2: strategy for these apps in this style? Like? Is there
Speaker 2: anything special? Once you're scaffolding like this, I have.
Speaker 4: A very very specific way of testing. Actually, an Aspire
Speaker 4: unfortunately doesn't help with that in any way, shape or form.
Speaker 4: So there is a there is a test So there's
Speaker 4: the NBC test server thingy, which has got nothing to
Speaker 4: do with MBC at all. It's just a new GET
Speaker 4: package just named that unfortunately. But it runs your API
Speaker 4: in memory, and there's a there's a similar version for
Speaker 4: Aspire that can run you to do smoke tests and
Speaker 4: things like that. The problem is that you can't do
Speaker 4: any mocking. You can't fake any services because of the
Speaker 4: way that Aspire works, and that means that to me,
Speaker 4: it doesn't really work for testing. So what we're doing,
Speaker 4: and I do in most of my project is for
Speaker 4: all of the API projects, I use I tested those individually,
Speaker 4: and then I use the in memory test server for
Speaker 4: those and I verify that all of the Jason stuff
Speaker 4: comes back as I expected to. And I also like
Speaker 4: doing it integration style all the way down to the
Speaker 4: database and not back up again, so I know that
Speaker 4: it really works with all the layers.
Speaker 2: Nice. Yeah, yeah. And the main thing is you want
Speaker 2: it automated as part of the pipeline as well, or
Speaker 2: at least you know so you're always checking.
Speaker 4: YEP, and currently we don't have that in my project.
Speaker 4: But it's funny because I've been building the APIs for
Speaker 4: our system and I've only done tests. So I have
Speaker 4: all my integration tests and they go green, and I
Speaker 4: say it works. And then I have front end people
Speaker 4: building a React front end and they come and complain
Speaker 4: but it doesn't work. But I haven't actually fired up
Speaker 4: the front end on my machine for about a year
Speaker 4: and it's actually worked. It's worked pretty well because I
Speaker 4: we agree on the contract of what they want to
Speaker 4: get from the end point the end point, I write
Speaker 4: the test to verify that the endpoint. It does what
Speaker 4: it says and comes back in the right format and
Speaker 4: it looks right, and then it.
Speaker 1: Doesn't show up on the browser. That's your problem.
Speaker 4: Yeah, pretty much like that. Yeah, it does break once
Speaker 4: in a while, but it works nice. And I like
Speaker 4: the fact that you can go to and from API
Speaker 4: to database and verify the jobs or the Jason that
Speaker 4: comes back because you know that that really works. It's
Speaker 4: not I'm not a big fan of unit tests as
Speaker 4: such because they don't show you your system actually working.
Speaker 2: In my opinion, Well, that's yeah, that's not what unit
Speaker 2: tests are really for, right, Like you need you need
Speaker 2: a more than kind of tests. Tests are for you
Speaker 2: running locally as you're doing builds.
Speaker 4: And it's it's mostly if you to me, unit tests
Speaker 4: are great if you have really complex code like that
Speaker 4: does a lot of complex stuff, but ninety percent of
Speaker 4: our systems don't do very complex stuff. You can look
Speaker 4: at the code and go, I know that this is
Speaker 4: going to work because I can see the code, and
Speaker 4: then I don't feel like writing a gazillion unit test
Speaker 4: on that because it's that simple.
Speaker 2: It's plumbing.
Speaker 1: I think a lot of the things that were complex
Speaker 1: that we used to use, uh, you know, test first
Speaker 1: for a test driven development for is all the stuff
Speaker 1: that the browser does now that we used to have
Speaker 1: to hand code. Like you know, me as a Blazer developer,
Speaker 1: I don't do any of that old crazy Ajax stuff,
Speaker 1: you know anymore. And the way that architecture has evolved,
Speaker 1: it's just, you know something's too complex, you just break
Speaker 1: it apart, and then you have two or three pieces
Speaker 1: where you had one, and you put unit tests around them,
Speaker 1: and Bob's your uncle. So yeah, I think the whole
Speaker 1: idea of complex code in general is, you know, things
Speaker 1: have gotten simpler.
Speaker 4: I think, yeah, I think in most cases you can
Speaker 4: break it down. And like I said, I don't do
Speaker 4: a lot of unit test, but I spent the entire
Speaker 4: day to day writing actually unit tests on a serialization
Speaker 4: stuff that we're building. But I don't care about the
Speaker 4: unit test ask tests. To be perfectly honest, I don't
Speaker 4: care about them verifying my code. I care about being
Speaker 4: able to write click and say run tests so that
Speaker 4: I can run it without having to spin it up,
Speaker 4: so I can make a change, I can run the
Speaker 4: test and also going, hey, I want to debug this
Speaker 4: to see what this value is. Right now, debug test
Speaker 4: is just so much simpler than having to run an application.
Speaker 4: So I believe that there are definitely cases unit tests
Speaker 4: are nice, but they're not for finding bugs or checking
Speaker 4: my code in most cases because that gets checked by
Speaker 4: the integration tests.
Speaker 2: There's a whole there's a whole conversation yet to be
Speaker 2: had here about the structure of testing in these cloud
Speaker 2: apps now, like even how you break down testing a
Speaker 2: given service or testing your end against a mock of
Speaker 2: a service like this has all gotten really complicated, it has,
Speaker 2: and I'm just impressed with just how much people just
Speaker 2: test in production now because you can always roll back,
Speaker 2: you know. It's like you can fight for a long
Speaker 2: time to find a way to test is independentally or
Speaker 2: you could ship and see you and roll back if
Speaker 2: you must, And.
Speaker 4: I think some were some were in I prefer not
Speaker 4: to test it in production if I can get a
Speaker 4: get away from it. But yeah, the closer you can
Speaker 4: get to production tests, the better it is, obviously, because
Speaker 4: it's it's going to be what the users are going
Speaker 4: to use.
Speaker 1: Right.
Speaker 4: Yeah, we've I've done several different iterations. I think all
Speaker 4: developers have done that over the years, trying to figure
Speaker 4: out what works for you and how do we make
Speaker 4: this work. And especially in a service oriented architecture where
Speaker 4: we've got HTV services, if you can just define the
Speaker 4: interfaces and basically document how they work, then I think
Speaker 4: it works pretty well even if you're distributed, because you
Speaker 4: can verify one service individually from another one. And even better,
Speaker 4: to be perfectly honest, is don't let other teams use
Speaker 4: your service. Give them an SDK style project. Instead, give
Speaker 4: them a new gift package that has methods on it
Speaker 4: that you control that calls your API, which means that
Speaker 4: they can just add your SDK client to their system
Speaker 4: and call it like a c sharp thing. And you're
Speaker 4: in control of the API, but you're also in control
Speaker 4: of the thing calling the API, which means that it's
Speaker 4: easier for you to verify that it works and it's
Speaker 4: easier for you to make changes.
Speaker 2: Yeah, for sure. And plus you know the incremental updating
Speaker 2: instead of change model and a B testing. All these
Speaker 2: strategies about not needing a huge testing framework that the
Speaker 2: little things that you could trial, and even dark featuring
Speaker 2: in the field is ways to test stuff without having
Speaker 2: to build a huge test infrastructure and limiting your impact
Speaker 2: if you do make mistakes, so that often you can
Speaker 2: just feature switch something back off again and then the
Speaker 2: next bill will try and make another iteration.
Speaker 1: On it or feature switch it on for just the
Speaker 1: admin users you know, or or you the tester, so
Speaker 1: you can test it without giving the feature everybody.
Speaker 2: Mm hmm. Yeah, I think it's.
Speaker 1: Just using the old nag.
Speaker 4: And there's an interesting thing as well with if we
Speaker 4: go back to the Aspire stuff and testing is as
Speaker 4: I said, I don't do a lot of testing like
Speaker 4: with Aspire, but I kind of like with the service
Speaker 4: discovery built into Aspire, it actually allows you to mock
Speaker 4: external resources as well, very very easily. So in tests
Speaker 4: you can go and say, hey, I have this external resource,
Speaker 4: but it's your own mocked service, and then for production
Speaker 4: you go and say, I have this service over here
Speaker 4: that we want to use. That's actually a very nice
Speaker 4: feature to do as well, because it means that you
Speaker 4: don't have to mock everything in your code. You can
Speaker 4: actually mock the API that you're using instead, which is
Speaker 4: a nice little benefit of having Aspire in place.
Speaker 2: Nice, So what's missing from Aspire at this point, Like,
Speaker 2: we haven't really dug into the latest version nine point
Speaker 2: five at all. I'm going to do a separate show
Speaker 2: on that, but you know.
Speaker 4: Yeah, I haven't looked at it either.
Speaker 2: To be honest, it's moving for relatively rapidly. We think
Speaker 2: we did that original nine to oh show with David
Speaker 2: in January of twenty four, so you know, here we're
Speaker 2: not We're just over a year and a half on
Speaker 2: and we've had incremental updates. I don't think they're going
Speaker 2: to increment from nine until dot net ten ships obviously
Speaker 2: would be my guess, but they have pushed out a
Speaker 2: dot change every few months. But do you stuff see
Speaker 2: things that are missing from it? Still?
Speaker 4: The thing is, it's really hard because I know I
Speaker 4: use the things that are in there, and I have
Speaker 4: a really hard time saying like, well, this is really missing. Yes,
Speaker 4: I think the testing part is missing, and I've talked
Speaker 4: to the David and Damien about that and they know
Speaker 4: it's missing. But there's also not a very easy fix
Speaker 4: for it as such. Unfortunately, the thing about them shipping
Speaker 4: very rapidly on the other hand is also that some
Speaker 4: of the things are under experimental as well, so you
Speaker 4: actually or the mark experimental, so you actually have to
Speaker 4: go and say, if I want to use this feature,
Speaker 4: I need to turn off a bunch of warnings and things.
Speaker 4: I don't know. I get that they want to get
Speaker 4: it out there, but I'd rather have experimental things in
Speaker 4: a non released version. So basically you had a release
Speaker 4: vers non release version of it before and then not
Speaker 4: put it into the release version until it's not experimental anymore,
Speaker 4: because you can't really take a dependency on everything that
Speaker 4: is in there, even if it's not a release candidate
Speaker 4: or sorry, even if it's a if it's a release version.
Speaker 4: But that's just them iterating quickly, I guess. So we're
Speaker 4: going to have to live with that for a while,
Speaker 4: and that's that's good. They are iterating that quick rappily,
Speaker 4: and it's really hard to actually follow along with everything
Speaker 4: that's going going out because there's new stuff, but they're
Speaker 4: also there's most of this stuff that comes out is
Speaker 4: in my opinion, a lot of little edge cases, a
Speaker 4: little scenarios that they're trying to figure out that's missing
Speaker 4: that I haven't run into in other cases. I think
Speaker 4: the last thing they did was the publisher's stuff, which
Speaker 4: is undocumented and experimental at the moment. That is going
Speaker 4: to be interesting if they can get it into a
Speaker 4: non experimental state and maybe make it a bit easier
Speaker 4: for you to build a publisher, and also maybe document
Speaker 4: how to build a publisher because it's undocumented at the moment,
Speaker 4: So I had to build one for a demo I'm
Speaker 4: doing for one of my talks, and the only way
Speaker 4: to figure out how it works is to look at
Speaker 4: the open source versions one of the other open source
Speaker 4: versions and copy the code from there and then start
Speaker 4: messing with it. And that's Yes, they're releasing quickly, but
Speaker 4: it's not documented either, so it can be a bit
Speaker 4: hard to pick up the new stuff as well.
Speaker 2: Yeah, yeah, I don't extend. All these things are moving
Speaker 2: so quickly, so they think it's challenging to try and
Speaker 2: step in there and aspire. To me, has always been
Speaker 2: a brown fieldy kind of thing, like you're not really
Speaker 2: starting apps from scratch in this class. It's pretty rare,
Speaker 2: So you're trying to get more cloud centric on an
Speaker 2: existing application and you can interspend it aspire into it,
Speaker 2: or are you getting a chance to start from the
Speaker 2: beginning with Aspire.
Speaker 4: I start everything from scratch with Aspire to perfect honest,
Speaker 4: But I I work in a world where I only
Speaker 4: do I normally only do three to six months of
Speaker 4: the project because of well, I guess ADHD or something
Speaker 4: like that. I can't. It's I'm happy that I have
Speaker 4: my employer active solution that supports that, because I actually,
Speaker 4: if I get into a project that isn't fun, I
Speaker 4: actually get depressed and it goes bad sometimes. So being
Speaker 4: that I only go onto projects very very rapidly like that,
Speaker 4: it also means I often go on new stuff. So
Speaker 4: I will come in, I will build the foundational stuff,
Speaker 4: and then once the foundational stuff is up, I will
Speaker 4: move on to something else. So I'm one of those
Speaker 4: lucky people that actually do get to do Aspire new
Speaker 4: and then start from scratch.
Speaker 2: Very nice.
Speaker 4: We didn't do it quite in this project. We actually
Speaker 4: worked and had two services up and running before we
Speaker 4: put Aspire in place, but it was still very very
Speaker 4: early days as such.
Speaker 2: Right.
Speaker 4: But I'm also saying, like you say, brown Field stuff,
Speaker 4: I say that to everybody. It's if you've got a
Speaker 4: solution that has more than one project in it. See
Speaker 4: if you can get aspired to work, because it's going
Speaker 4: to make everything easier to work with. And honestly, if
Speaker 4: you only have one project but it's slightly complex, put
Speaker 4: a spire onto and anyway, so you get the dashboard,
Speaker 4: you get the open telemetry. No, you don't need the
Speaker 4: retripolsies and all the stuff that you get for free,
Speaker 4: but just the open telemetry dashboard and the ability to
Speaker 4: plug into that and being able to see your logs
Speaker 4: in a nicer way, that's worth it for a single,
Speaker 4: single project solution in my opinion, right.
Speaker 2: Right, Yeah, I bet that.
Speaker 1: Well, I'm going to keep that in mind as I
Speaker 1: go into this. We're doing this live, you know, aspire
Speaker 1: ify dot net rocks dot com.
Speaker 2: Yeah, and you're living the dream and the adventure man
Speaker 2: like I hope that's as well. Well, and again time
Speaker 2: shifting it'll have already happened.
Speaker 1: We hope, we hope.
Speaker 2: But I mean, I was appreciate Chris. You haven't done
Speaker 2: one project, Inspire, You've done a bunch. You wouldn't keep
Speaker 2: using this if it wasn't actually helping you.
Speaker 4: No, no, no, no, it's it's awesome. It's also I'm
Speaker 4: not an AI person at least Richard, you know that
Speaker 4: we've had conversations about that, and I have opinion it's
Speaker 4: about AI and everything. If you're sort of wanting to
Speaker 4: be a bit bleeding edge in the Microsoft sphere, it's
Speaker 4: either AI or Aspire. There's nothing else to actually look
Speaker 4: at at the moment the thing that comes out. But
Speaker 4: having that stat I actually love Aspire. I've loved the
Speaker 4: idea of it since I saw the first like release
Speaker 4: version that they've showed to the m v P s,
Speaker 4: and there's I don't know, it just solves so many
Speaker 4: little little things. It's not overwhelmingly wow, this is awesome,
Speaker 4: it will change revolutionize my world, but it solves a
Speaker 4: bunch of little things that annoy you every day and
Speaker 4: every time you press F five to start your application.
Speaker 4: It's I don't know, it's it's hard to say about
Speaker 4: those little things make it a little more more enjoyable.
Speaker 4: It's actually right code, and I think.
Speaker 2: It does strike me as a strategy to get gradually pregnant.
Speaker 2: All in this case, we're talking a gradually cloud native
Speaker 2: that yes, you you know, as you learn more about
Speaker 2: what it is to live in the cloud. ASPIRER was
Speaker 2: already there and ready to help you with the next problem. Yeah,
Speaker 2: that's it. I appreciate that he had. Davids did a
Speaker 2: good job of letting us gradually get involved and think
Speaker 2: more cloud dative. You don't have to jump out climb
Speaker 2: up this huge cliff before anything works, right.
Speaker 4: No, because that's kind of like you said, like it
Speaker 4: started off talking about a bit about Kubernetes, because I've
Speaker 4: been into the Kubernetes area as well for a while,
Speaker 4: and it's that's a that's a steep hill to climb
Speaker 4: before you get anything done. And then once you understand
Speaker 4: Kuberneties and you have to start doing helm charts and
Speaker 4: deployment pipelines for that, it's it's a pain, and it
Speaker 4: does and solve your local development in any way either.
Speaker 4: So it's I don't know. I think this is a
Speaker 4: nice way to make your day to day job easier.
Speaker 4: If you don't want to use it for deployment or whatever,
Speaker 4: that's going to have to completely fine, But your daily
Speaker 4: work is more enjoyable.
Speaker 2: I appreciate that.
Speaker 1: What's in your inbox, Chris, what's on your to do list?
Speaker 2: Sleep?
Speaker 4: I'm currently actually spending a lot of time working on
Speaker 4: I've done two new presentations that I'm working on or
Speaker 4: have have worked on, and we'll have to refinal a
Speaker 4: little bit after NBC Copenhagen working on a two day
Speaker 4: really wonky workshop on Microsoft Web Development where they attendees
Speaker 4: get to play with a spinnet Core minimal APIs, NBC
Speaker 4: g RPC, your project or lanes as identity server and
Speaker 4: some other stuff, so they basically get a little tour
Speaker 4: of everything. A lot of things you can find in
Speaker 4: acenet core. So that's kind of cool.
Speaker 1: That's very cool.
Speaker 4: Yeah, it's interesting going into so many different things and
Speaker 4: sniff around like what can we do here, what can
Speaker 4: we do there, and show people that acenet core is
Speaker 4: more than mbassy.
Speaker 2: Yeah, yeah, it certainly is and always have been. But
Speaker 2: you know, yes, it's basically the same thing you just
Speaker 2: did in this past hour. Chris is like, there's more
Speaker 2: to aspire than you know, and you can there's a
Speaker 2: bunch of different points to grab at it. So I
Speaker 2: appreciate that that you break down the pieces and say
Speaker 2: you could use this, and you could use this, and
Speaker 2: did you know about this? And there's lots of ways
Speaker 2: to help.
Speaker 4: And it's also I think like most people are stuck
Speaker 4: in not stuck, but most A lot of people work
Speaker 4: in enterprise environments where there's you're working on the same
Speaker 4: thing all the time and you get kind of shoved
Speaker 4: into this corner of this is the way that it works,
Speaker 4: and you don't have time to look at everything else.
Speaker 4: So that was kind of the idea behind my workshop
Speaker 4: was let's take people that work on maybe not so
Speaker 4: cool enterprise projects and show them what else is out there,
Speaker 4: so that if they come up with something new that
Speaker 4: needs to be built, maybe Project or Leans can help them,
Speaker 4: or building a new service using DRPC, you might be
Speaker 4: easier for some things and things like that. So that's
Speaker 4: the idea behind it.
Speaker 2: Nice, very good, I appreciate it.
Speaker 1: Chris. Thanks for spending an hour with us. It's been great.
Speaker 4: Well, thank you for having me again. It's it's always
Speaker 4: awesome to be on the show.
Speaker 1: Ye all right, go get some sleep. We'll talk to
Speaker 1: you next time on dot net rocks.
Speaker 5: Dot net Rocks is brought to you by Franklin's Net
Speaker 5: and produced by Pop Studios, a full service audio, video
Speaker 5: and post production facility located physically in New London, Connecticut,
Speaker 5: and of course in the 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 in September two thousand
Speaker 5: and two. And make sure you check out our sponsors.
Speaker 5: They keep us in business. Now, go write some code.
Speaker 5: See you next time.
Speaker 4: You got jam Vans
Speaker 1: And