Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Become a patron for just five dollars a month. You
get access to a private RSS feed where all the
shows have no ads. Twenty dollars a month, we'll get
you that and a special dot net Rocks patron mug.
Sign up now at Patreon dot dot NetRocks dot com. Hey,
welcome back to dot NetRocks. This is Carl Franklin and
this Ridrid Gammon. This is going to be a great show, Richard.
Speaker 2: I'm expecting nothing less.
Speaker 1: Yeah, Dan Roth is here and it's also show nineteen
hundred and twenty two, and I'm summarizing what happened that
year from the peoplehistory dot com.
Speaker 2: Okay.
Speaker 1: In nineteen twenty two, significant global events shape the world.
The Union of the Soviet Socialist republics USSR was formed,
solidifying the rise of communism in the UK. The British
Broadcasting Company or the BBC was founded, making the start
of public radio broadcasting. In science, the first successful insulin
treatment for diabetes took place in Canada. Of course, Canada,
of course, it was meanwhile and refused to patent. It
actually published the specification so that anybody could make it.
Speaker 2: Because you guys are polite, well and you know you
do the right thing. And we don't want to we
don't want to make people alive. Cost a lot of money.
Speaker 1: Who would do that?
Speaker 2: Now? I don't know. I don't know.
Speaker 1: I just make it mad by saying things like that. Meanwhile,
the discovery of King Tut's tomb tooked uncommon, captivated the
world and in Italy Benito Mussolini ros to power. The
Lincoln Memorial was also dedicated in Washington, d C. Commencing
President Abraham's Lincoln legacy. Yeah, and that's only something that
you probably have things to add.
Speaker 3: Oh.
Speaker 2: No, my favorites of that year would be toot In
Commons tomb and the insulin. What else? What can I
think of?
Speaker 4: Uh?
Speaker 2: Egypt becomes independent from Britain.
Speaker 1: Yeah, okay, just was that before or after King Tut's
tomb was well, it was discovered, because wasn't it an
Englishman that discovered? Yeah?
Speaker 2: Howard was an Englishman, no question, do you remember it was?
It was a pleasant handover. It was a civilized han,
right and it's not like the British army actually pulled
out they you know, it's more of the like can
It was sort of like they filled in the form
and made the deal. Wasn't a big revolution or anything.
Speaker 1: Yeah, have a have some champagne. Okay, it's all yours now.
Speaker 2: See well, I mean it still turn into bigger issues
thirty years from now with the Suez Canal crisis. But
you know we'll figure it out that. You know, you've
got a year and a half before we have or
a half a year before I have to talk about
that part thirty episodes from now.
Speaker 1: Yeah, I like this. I like this trajectory we're on here. Okay,
it's very informative. Okay, let's roll the crazy music for
better no a framework?
Speaker 2: All right, man? What do you got?
Speaker 1: Well? I know that you know, Microsoft is all ai
ish these days. It's word definitely ai ish. So I
saw this and I don't know really anything about it.
But this was posted on dev Express's blog on September eighteenth.
New dev Express AI powered blazer Chat component Early access preview.
So it's a new UI library design to incorporate AI
driven interactions into your next great app and deliver responsive,
copilot inspired interfaces with absolute ease. Again, have it checked
it out? I just saw that. It came across my
desk and I was like, you know what, that might
be a good jumping off point for today.
Speaker 2: I also think it's the way we're going to see
a lot of these large language model technologies applied is
as a ux extension to an application.
Speaker 1: Mm hmm. Absolutely.
Speaker 2: And it's not not really a product, it's a feature
to a product. Yeah.
Speaker 1: And and it also makes you rethink your whole UI
in general. If you can do a lot of stuff
with a textbox, why do we need all these other controls.
I'm sure Dan's got ideas about that too.
Speaker 4: So all the smart components coming coming to the ecosystem,
it's it's pretty pretty fun. We've done some of our
own experiments around that in the in Dwton.
Speaker 2: I know it does imply that all everything we've done
up till now was dumb components.
Speaker 4: No, nope, more more intelligent components, don't.
Speaker 2: There you go?
Speaker 1: Yeah, smarter components. I like that.
Speaker 2: Smarter, smarter components.
Speaker 1: There you going. And when we get to smartest components
and then we're done, we can't go any smarter, more
resource intensive components. How about that? Okayeah, that's good. So
that's what I got today. Richard, who's talking.
Speaker 2: To us, grabbed a comment off the show eighteen thirty eight,
the one done by Javier Nelson and Steve Sanderson talking
about Blazer United. One of the few Blazer shows you've
ever done without mister Roth involved directly. Yeah, though I'm
sure he was pretty by the way. This is from
March of twenty twenty three, and lots of good comments
on this show from from our friends, including Richard Ruhima,
who although otherwise known as codeputer yep. On there he says,
this is going to get really interesting. I find this
to be a paradigm shift, not in terms of the web,
but in terms of building an application for the web.
Talking about Blazer United right in this context, not AI
Blazer United, where server and client could be intermixed very easily.
This unity of Blazer styles, I think, simply relates to
where the code resides, which updates the DOM Blazer server.
The DOM is updated on the server and the resulting
dip gram of the UX assent to the browser. Web
assembly is the traditional approach for server pouring the entire
application of the browser just to use client side reasers
to update the DOM to unify and the various design
thoughts expressed here, I thought I could simplify to say
what updates the dom? For example, if I'm using a
click event, why can't I attribute that code as server
and not attribute the code and have it execute on
the client. This is the most granular, but you could
also do it as a component level as well. All data, however,
should be streamed in my opinion, but as that data
becomes available and is simply defined by where it was requested,
I suggested the podcast, I'm going to head over to
GitHub and start planning to participate in what I think
is a very important development in the concept of web
application development.
Speaker 1: Richard is a very thoughtful guy. He was one of
the guys last year at Codena Castle event and just
loved it, and I really enjoyed talking to him well.
Speaker 2: And I don't disagree with this core sentiment here that
we're getting into this idea of units of compute in
the web that could run in multiple places. As a
certainly a conversation we've had mister Standerson before. We're not
just the client or the browser, but some interim location
close to the client but not actually on their machine. Right,
think about us smarter distributed network. Here your local caches
that could actually run compute units for you, so that
they have nice fast interaction with the browser, but the
sensitive data never actually enters a browser unless necessary, and
then trips back to the server asynchronously.
Speaker 1: The the problem I see with that, and basically we're
talking about, is having some button click events that work
on the server and some that work on the client.
And the problem is that if if you're doing server
side Blazer, let's say, uh, it has to keep track
of everything in all the time. Yeah.
Speaker 2: Yeah, Well but imagine you know you want you want
that security of the server side, but you can't handle
the round trip. It takes too long. So you have
you're able to deploy chunks of code to a CDN
close to that browser and have that code execute there
and very low latency.
Speaker 1: Right, But if it changes the dumb and you're still
using a service side dom graph model, that service side
dumb graph model has to stay informed and updated.
Speaker 2: Yeah, so it's got to work both directions. But I
dig it, I think it just gives us options, more
options on where to run our compute. Because you know,
there's a weird way to think about this, which is
a web assembly is almost another kind of container. Oh
definitely right that it's a smaller unit of code that
can be shipped around and executed on demand where you
need it. Richard, thank you so much for your comment.
You always bring up some great ideas, make us think
a little bit. I'd send you a copy of music Cobey,
but I'm pretty sure you got one already. But if
you don't, you know my number, give me a go
I'll look you up.
Speaker 1: Or does anything else? You want a mug or whatever,
just let us know.
Speaker 2: Yeah, whatever you want, brother, you know you're welcome. And
if you'd like copy of music code By, write a
comment on the website of donn at Rocks dot com
or on the facebooks we publish every show there. If
you comment there and ever ready in the show, we'll
send you a copy of music go by.
Speaker 1: And you can always follow Richard Campbell and myself on
ex Twitter. That's we've been there for a long time.
But all the cool kids nowadays are hanging out at
Macedon at least I think so. I'm at Carl Franklin
at tech Hub dot social.
Speaker 2: And I'm rich Campbell at Macedon dot social.
Speaker 1: Send us a toot. It's another way you can get
a free copy of music to code by if we
read your toot. Are they called toots?
Speaker 2: I think they're toots.
Speaker 1: Yeah, I think they are.
Speaker 2: I've been doing a lot of stuff on louse Ky
lately too, and if there's anything that Elon's done, he's
definitely fragmented this market. Yeah.
Speaker 1: I've got a lot more followers on Macedon than I
do on Blue Sky. Blue Sky didn't seem to get
anywhere with me, but I'm still there. Yeah, all right,
so let's bring back mister Daniel Roth. He is a
principal program manager on the aspnet team at Microsoft, specifically
working on dot net web development with Blazer. What's up, Dan, Hi, Carl, Hi, Richard.
Speaker 4: It's great to be here.
Speaker 2: Great to have you, Good to have you back. Friend.
Speaker 1: I guess there's a new dot net in town coming
in November, dot net nine imminently.
Speaker 4: Yeah, just around the corner. Every November release, whether you
want it or not, here comes. Oh you'll want it,
You'll want it nine.
Speaker 2: Yeah. Yeah.
Speaker 1: So I've been reading the blog posts and I saw
the blog post about what's new and asp neet core
for dot net nine, and that included a thing on
Blazer and I'm very lighted to see that in Blazer Server.
I'm calling it the semi opaque veil of death that
happens when you need to reload and you know, the
connection gets broken and stuff, and that is you're really
addressing that with this with this release.
Speaker 4: Release, we're helping. We're helped. I think there's still probably
some more things that we can do to improve that experience,
but yeah, we're making some improvements to the reconnection experience
for apps that use the Blazer server model, or as
we would call it now, the interactive server rendering render mode.
With Blazer server apps, it's a stateful model, right like
you have a live connection with the browser or with
the app to function, and you have server state, and
if the connection gets lost, then the app has this
sort of white overlay that that happens to let the
user know like, hey, I'm the app is not going
to be able to function right now because it doesn't
have that connection. All the uy gets driven from the
server in this in this paradigm, and.
Speaker 1: I find that users just aren't smart enough to configure
that reconnection stuff. They just don't they don't really don't.
Speaker 4: Know on the developer side, yeah, that there are things
you can do, but it it is a bit manual.
In dot AT eight and dot and nine, the goals
to try and make the default set up a little
bit more end user friendly for the people that are
using that that WebApp from that developer.
Speaker 1: Yeah, that's great news.
Speaker 4: Well, well, things that we'll do now will automatically refresh
the browser for the user with when the connection gets
re established and if the app detects like oh, the
user's circuit like their service side state has gone away
for whatever reason like that. That can happen for a
number of different cases, like maybe there was a server
deployment that happened because the servers or restart and whatever
state was held in memory got lost, or maybe the
connection was lost for too long and the server timed
out the circuit and so it just freed up that
those those resources forever. Reason, if the user state got lost,
they kind of need to start again, and before we
would and help them help them with that. And now
in DOTTA nine we will automatically refreshed the browser, the UI,
the UX that you see that the user sees when
that connection gets lost as a little friendlier it's not
that white overlay anymore. It's a little like sort of
mold dialogue style UI. You can you can customize it,
of course, however you'd like. But the fault experience is
a little a little cleaner, and it's a little bit
more responsive, like when the server comes back up, the
user has to wait less time, Like the polling intervals
are a little bit more intelligent in dotted nine, so
they get the app working working faster. So that's that's
all goodness. To be clear, though, the state on the
server is still the responsibility of the app developer. Like
it by the fault is just held in memory. If
you want to that state to survive, you know, sing
things like a server restart or the cirt of going
away and coming back, you do need to still write
code in your application to persist state and rehydrated again
when a user comes back and wants to resume whatever
it was that they were doing. So that that problem
is still very much an application developer problem. In ten
or some future Donnet, we still hope to create patterns
in the framework that make that a little easier. That's
something we in and I hopefully we'll get in the
future I.
Speaker 1: Have a pattern for that actually, and I'll post a
link to it. It's on a GitHub repo. And what
it does is it you create an interface off of
your app state, cascading parameter or cascading value that you
want to persist, and then every time that gets anytime
any of those variables get touched or changed, it persists
those And so you can take that whole idea of
using protected browser storage, or you could save in SQL
server whatever you know, but you save it. You can
even save the page that you were on right, the
form you were filling out, and the fields that you've
entered in the fields that you haven't entered, Like, you
can get down to that kind of level.
Speaker 2: Yeah, which, by the way, delights people. Right, Is there
not better than going back to a page you didn't
finish and the work you've already done is still there.
Speaker 1: Oh yeah, it's terrible if that doesn't happen.
Speaker 2: Well, I think it's expected if it doesn't happen, which
is why it delights when it does. Like, there's not
the tremendously difficult things we have to do, they're not
make people's lives a little bit better and to have
them smile at our software instead of frown.
Speaker 1: I had it. I remember this experience and you guys
probably have two. When I was I was applying for
a loan online and I got you know, there was
like nine pages that I had to fill out, and
I got to page seven and it said, oh, by
the way, which one of these dollar values was the
payment of your mortgage, you know, two years ago or whatever?
And I'm like, what now I have to go. I
have to walk away from the computer, go to the
file camp. By the time I came back, it said
to your sessions timed out. You got to start all
over again. I'm going to someone else now.
Speaker 2: Yeah, yeah, yeah, yeah, this stuff doesn't have to suck.
And I appreciate you built app server thinking in terms
of this is just a component you could add in
and have that behavior happen. Yeah, that's a good idea.
Speaker 1: So what else you got, Dan so well?
Speaker 4: Dotted eight obviously was the big move for Blazer to
become a full stack web framework, like you guys were
mentioning earlier, the Blazer United effort. That was the early
code name that we used for a name name of
that technology of uniting all the Blazers into one thing.
Where you now it's just.
Speaker 5: Called Blazer, the Blazer web app as well the way,
but you can have different render modes that you turn
on or off inside your Blazer web app to light
up different functionality in different places.
Speaker 4: And so that model really unified the web development experience
for for dot Net, like whether you're doing server or
doing client, you can do it with just one component
model using Blazer components, and it really positioned Blazers our
you know, our our primary our rec commended solution for
building web UI starting with with dot neet eight. But
it was new, like there's certainly user experience gaps in
that in that in that model that we're still ironing
out and filling in. The reconnection experience was was one
thing we did. Another is giving you more run time
visibility into which render mode is currently active. Like just
as a to walk you through a very common Blazer flow.
You might make the initial request to a Blazer web
app and it will render HTML from the server statically,
like just give you some HTMIL immediately. We often call
that pre rendering. That's a form of just static server
side rendering where you get HTMIL down to the browser
as fast as you can so you get pixels on
the user's screen as quickly as you.
Speaker 2: Get stuff floating look at.
Speaker 4: Then you might have interactive features though on that page
that you want to enable, like you want to handle
those button clicks or drag and drop or whatever, and
you have a choice on whether you do that from
the server using interactive server rendering or from the client
using web assembly based rendering. Now, while you're waiting for
that interactivity to light up, there might be interactive features
on the page that aren't quite functional yet, like the
counter button if you try to click on it in
that split second before interactivity has been enabled. There's nothing
yet set up for to handle those UI events or
due to do dynamic UI updates. So what you can
do now in Dota nine, we give you a runtime
API for detecting the render mode. So when you do
that first static service side render, you might maybe disable
the interactive features or don't render them yet, like wait
until interactivity is now live, right, and then when the
component renders interactively, like through from the over the web
socket connection or on web assembly, you then light up
those interactive features so they're now available for the user
to use.
Speaker 2: So you have this.
Speaker 4: Capability now of structuring the dom, adjusting the component rendering
based on how that component is currently being rendered, which
render mode is currently act.
Speaker 1: Nice and saving and low state is kind of important, right,
because if you go from an interactive thing where you've
got some state to a non interactive thing where you don't,
and then back to an interactive thing, what happens to
your state? Right?
Speaker 4: You might you know, yeah, you need some some way
of flowing that around, and that can be that can
be tricky, you know, you mentioned earlier options like I
think I think this is sort of one of the
the industry trends right now in front in web development
that the frameworks are getting are getting very powerful in
terms of the the flexibility and how you render your components,
Like you can render your components from the server, you
can render them from the from the client, and various
mixed cases as well, like enhanced uh static, enhanced navigation
and forum handling, streaming rendering. These these new patterns that
enable you to make your app more feel, more responsive,
load faster, have a better user experience, but it does
also result in complexity, like and it can result in
like these types of architectural questions that you're asking about like, well,
how I now flow state from each of these different
types of rendering within my application.
Speaker 1: Yeah.
Speaker 4: I think that's something that you know in general, not
just in Blazer, but like whether you're doing React or Angular,
you know, React server components, our thing right next JS
has similar patterns or newer frameworks like Astro and solid
like figuring out ways to help users navigate the complexity
of these different ways of rendering. Web UI is I
think an ongoing, an ongoing, challenging problem.
Speaker 2: Yeah.
Speaker 1: Yeah, just to be clear, you can use some props.
So when dot Net eight came out, Rocky Laca and
I noticed that there was some problems with scope services
just sort of dying and going null on you when
you switched modes. And that seems to have been fixed.
I didn't see a lot of fanfare about it, but
I tried it recently for a talk I was giving
and lo and behold those scope services are now surviving
the in it. Yeah, which is great, which is great.
So I mean working is expected, there was Yeah, working
is expected, but you know, there's like he said, there
were some glitches with dot and it eate when it
came out, and some of those things are being correct
and hats off man. Good stuff. Laser goes on.
Speaker 4: Laser continues to do to improve we do. We do
try to listen to to user feedback. I think they're
still like with state and persistence, like we were talking
about you know, your own libraries to helping with service
side persistence. I still think there's more to be to
be done, Like we've wanted for a while to have
like a more declarative model for persistence in Blazer where
you can sort of declare on your component, like here's
stuff that I'd like to be that's awesome persisted or
survive the pre render to the interactive rendering flow and
all these places where you want to flow state around
helping with framework patterns UH to deal with those types
of types of issues, and those are things I think
we'll look at in a future version.
Speaker 2: It's cool, very cool. The relationship with MAUI. I mean
they'd come up later than you know, Blazer's been around
longer and there's sort of this energy around this is
your you know, all purpose client environment. What are you
guys doing.
Speaker 4: We have a great partnership and integration with with MAUI.
I mean MAUI is all about cross platform native client
apps like you want to use, and Mali really specializes
in enabling you to use the native view y controls
and elements from the underlying platform. You when you render
a button, yeah, and you're gonna get the iOS button.
When you are on an Android, you get the Android button,
or when y you get the winduw I button. That's
their their bread and butter. Where we plug into Mali
with Blazer is well, you can render a WebView control
within a Maui app on regardless of the platform you're on,
and from that WebView control, you can then render Blazer
components from from the device. So this is what we
call the Blazer hybrid pattern. And actually, Donta nine we
have a new solution template I guess we could call
it for doing both a dott Maui Blazer hybrid app
in conjunction with a Blazer web app where you want
to target not only the native client platforms with your
Blazer components, but also the webs web, mobile and desktop
with one template setup. That's something you could do in
Donna Dight, but you had to kind of set it
up manually. It was a bit bit tedious and Dota
nine we give you a pre kit.
Speaker 2: It is a bit inception, ye, right, that you have
an UX inside of a framework inside of a UX
A little bit, yeah.
Speaker 4: But it's very common. Like we use these style of
apps all the time. If anyone's using Visual Studio code
have a native shell with a you know, chromium based
web view sitting inside of it. Your editor Microsoft teams
is built with a similar technology stack of similar similar
architecture or hybrid style architecture. Sure, the Blazer hybrid pattern
just lets you do it with Blazer components as opposed
to having to do it with JavaScript, right.
Speaker 1: I also like the fact that you can mix a match,
Like you can build a WPF app that has a
Blazer view for your main content and then hey, if
you can't find a good Blazer calendar control, you can
use a WPF calendar control and pop that up right,
and you know what I mean, it's just wind forms
or vice versa. Yeah, So you can truly use the
platforms inside the different platforms inside of an app for
what you know, the best of breed technology is whatever.
Speaker 4: I was talking with some of the Maui folks, and
I think in some cases they like if if there's
a control that's not quite available or not quite working
the way people want. At the native layer. People often
will go the Blazer hybrid rout to go grab a
control from you know, popular web frameworks or Blazer that
use that inside their mauway up and that that works
very quite quite quite well for them.
Speaker 2: Yeah, I just wonder about performance behavior, Like there's all
the subtleties that work when you're pulling in components through
these different layers like that, like does this UX hold together?
Does it look like this is a different component stat
that came from a different Blazer. Does it look like
it's all unified?
Speaker 4: Yeah? That that's so. The thing you lose out with
the Blazer hybrid pattern is you are now rendering web
UI within the native shell. If you've stuck with just
native native controls like the MAUI abstractions. For those native controls,
you get the look and feel consistency of that platform,
Like it'll look like an iOS app when it's running
on iOS, it will look like an Android app when
it's on Android. Once you go into the hybrid world
you're now in that.
Speaker 2: It looks like a web app.
Speaker 4: Yeah, well, however you style that that web app you
want it to look IOSC. Then you're gonna have to
use some CSS styles that make it follow the iOS
design patterns.
Speaker 2: Or if you want all your textbox to be in flames, yes,
CSS will do that for you.
Speaker 4: Yes, you can do it.
Speaker 1: All your text box are belonging to S.
Speaker 2: Yes. No applying for taste here, that's not it.
Speaker 4: I want you want to mention like for performance. I
actually think that the Blazer hybrid pattern is is a
really good story for a performance because the rendering of
the Blazer components is happening natively on the device. Like
there's no web assembly involved. No, there's no website get involved.
You're running your dot net Blazer components on a normal
dot net run time with JIT and normal garbage collector
and all that stuff running on the device. It's then
just talking to the WebView control over like a local
interrupt channel. So the component rendering is quick. That's very performant.
You do have a little extra weight because you are
bringing the web platform with.
Speaker 2: You as soon as the web control comes into play.
That's a spicy meatball, right, yeah, and spicy meat.
Speaker 1: And you can look, you know, you can look at
the task manager and see the difference right. The native
Maui stuff is smaller, right, and then you have the
in the in the process for the for the Blazer Hybrid,
you've got you know, edge webe chromium, the WebView and
all of the stuff that comes with it. Right. So yeah, yeah,
you aren't going to use more memory.
Speaker 2: You're going to feel it now that last time I look,
most of these machines have way too much memory anyway.
Speaker 1: So I totally agree Richard. Never run out of memory
on my iPhone to take back.
Speaker 4: The memory so they don't have so much to waste.
Speaker 1: I had. I had a group in here in the
studio the other night when we're recording something, and he says,
you know, he's trying to punch in and and I said, dude,
I'm not going to run out of tape.
Speaker 2: It's gonna be okay.
Speaker 1: You know, you can go as many times as long
as you want. You can just keep recording. He's like, oh, stop,
go back, you know. No, no, not gonna run out
of tape, not going to run out of memory.
Speaker 2: I'm not going to stop. It's not going to just
have one continuous stream, keep going. It's like my phone's
not running out of film. It's going to be take
another picture.
Speaker 1: It's okay, right, Yeah, yeah, this is just leftover behaviors
from old technologies.
Speaker 2: Yeah, I mean there is a phones have some constraints
they but mostly bandwidth related ones and storage related ones
depending on what phone you're getting. But yeah, definitely we
have you know, maintainability is more important these days and
optimizing the bites.
Speaker 1: Still, when my phone starts running low on battery, the
first thing I do is close all the apps that
are running there.
Speaker 2: You go, well, I just swapped up my phone because
the last one started to grow in the way that
says this will catch fire soon.
Speaker 1: So you mean like capacitors.
Speaker 2: No, the battery started to expand popular expanding Yeah, yike.
Not a good sign. No, not at all. So I
moved on. Hey, we should take a little break, and
then I.
Speaker 1: Get some questions. All right, we'll be right back after
these messages. Did you know you can lift and shift
your dot net framework apps to virtual machines in the cloud.
Use the elastic beanstalk service to easily migrate to Amazon
EC two with little or no changes. Find out more
at aws dot Amazon dot com slash elastic beanstalk. And
we're back. It's dot in a Rocks and Carl Franklin,
my friend Richard Campbell, Heye, and our friend Daniel Roth
from Microsoft in just as a reminder, if you don't
want to hear these ads, because let's face it, some
of them you really don't want to hear, you can
for five dollars a month go to Patreon dot dot
nerocks dot com and become a patron and you'll get
a feed that's ad free.
Speaker 2: Nice.
Speaker 1: All right, where were we dan? What's on your list next?
Speaker 2: What have we covered? So?
Speaker 4: I think it's important to stress that for DOTT nine,
a lot of what we're doing in this release is
about quality and fundamentals, like the features always get the
headlines right, new new capabilities, new functionality. But a pretty
significant investment was made in DOTTA nine just to focus
on things like performance, security, accessibility, just making sure that
the fundamentals of what we're shipping our top top quality.
I'm sure many people listening have heard of the Secure
Future initiative from microclock. The whole dot net team has
been participating in that effort as well, making sure that
every feature we ship is secure by default, has secure
characteristics for our users, and that's all.
Speaker 2: Work, expects to expects to managed identity, like those kinds
of things, right, really doing the zero testing.
Speaker 4: Making sure our samples show you best practices for the
latest threats and how you mitigate them, and just making
sure that our own infrastructure, of course is is as
tight and as secure as it possibly can be, a
lot of works gone to security performance, though it is
always a big area of investment.
Speaker 2: There is Steven tow isn't there.
Speaker 4: Has published his tomb Yes, the tome.
Speaker 2: Taking I know what I'm doing this weekend.
Speaker 4: I gotta say, like these these perform I know he
does a lot of like micro benchmarking part of showing
those benefits, but these benefits are real. Like we Donnet
is used heavily internally at Microsoft by our largest products,
you know Microsoft teams being in Tune, Xbox, like these
huge properties are using don net to power their back
ends and they just love that. Every donnet version comes out,
they install that on to.
Speaker 2: Change nothing and things are faster. Actually, some of my
favorite blog posts have been like the team's team saying,
here's our benchmarks. When we were on seven, and then
we switch to eight, here's the things we needed to fix,
and then we ran the same benchmarks again and here's
our performance on eight. Like those, I think are very
compelling for folks to see Microsoft consumes its own dog food,
like this is a product they use and they are
getting these benefits too, and they care about them. Absolutely, Yeah, absolutely.
I would tie that back to the Secure Future initiative
in the sense that it is still too hard to
write really secure code, but I'm glad you guys are
doing it because it will then get easier because you
need You've got deadlines too, right, and as soon as
security gets in the way enough that you're serious and
considering circumventing it, like you know where those guys work,
go get them and make it better.
Speaker 4: Fix it.
Speaker 2: Well, I remember what happened to WPF when the studio
team started implementing it back for the twenty ten edition.
WPF took this massive leap in improvement because those guys
rang it out and found its weaknesses and then hunted
down the folks who built it and made it better.
Speaker 1: And the dot Net Framework the same thing happened when
it was embedded in SQL service. Yeah, shook it out,
They beat the snot out of it.
Speaker 4: Things get used, they get refined in the the world.
Speaker 2: Yeah, but it's also there's there's a little insider angle
there where one Microsoft team's being impeded by another Microsoft team.
Like that gets energy right that you can actually make
step better. That will all bet of fit from. Like
I expect our process of making secure dot net applications
to get dramatically better the next year.
Speaker 4: It is a goal that as we improve our own security,
that that spreads to the rest of the eCos rolls
out to everybody. One example I can think of is
like one technique we're using internally on our code basis
is you know, static code analysis scanning, scanning our codebases
looking for problems in an automated fashion. One of the
tools we use for that is code ql, which is
a publicly available suite that's used as part of our
get up Advanced Security offering for scanning codebases. And so
as we you know, tweak and refine the rules that
we use for scanning our code bases, then those can
become available to external users and that that whole story
just gets better and stronger, so you can find issues
faster in an automated way. So security top top priority.
You know, huge amount of resources being spent on making
sure that our uh that that that our users can
trust the products that we ship from Microsoft because everything
else rides on top of.
Speaker 1: That getting back performance from it, and just this will
give you a good segway for you. Uh. I recall
several years ago. I don't remember what which version of
dot net it was, but it was like, for the
first time dot Net was outperforming. It's uh, you know,
not its rivals or its adversaries, but it's competitors. It's
competitive stacks in terms of you know, speed and performance.
And you know, at that point I was like, ah, okay,
dot Net is the most performance. I don't have to
worry about that now. But then you know, of course
every year those competitors' platforms also increase their performance. And
you've got this cat and mouse team, So what is
it in terms of performance? Do you know what the
rank is in terms of compared to everything else.
Speaker 4: The benchmark that we use for that and that we
target and Donnett is the Tech and Power Benchmarks, which
are a public set of benchmarks that look at all
the developer ecosystems that are on the planet. They implement
the same suite of benchmark tests and then they run
them and you can go and look and compare how
different implementations of different stacks look against each other. And
I don't have the numbers off the top of my head,
but you can, of course just go and check the
tech power benchmarks yourself.
Speaker 1: And we were Richard's doing that area.
Speaker 4: Well, yep, very very well on those benchmarks.
Speaker 2: You guys are always in the top few, right, I
mean the the.
Speaker 4: And usually it's the top few where we're like often
the one that is like the thing you would actually
consider using, like some of the other there are some.
Speaker 2: Right, yeah, some of these stacks are pretty weird.
Speaker 4: Academic I would say there are some other good stacks
out there. I don't want to say there are.
Speaker 2: Sure, yeah, there's plenty. There's plenty of good stacks. But
there dot net Core sitting at twenty three out of
what two hundred, three hundred, five hundred.
Speaker 4: Say pretty confidently that if you choose dot net for
your service stack, you will be very happy with its performance.
Speaker 2: Character performance will not be an issue. That's it's not
going to be an issue.
Speaker 4: And that's proven out in the real world by like
we were talking earlier about us running down it in our
own data centers, for our own cloud, for our.
Speaker 2: Own product offering.
Speaker 1: Okay, so Dan, I hate to put you on the spot,
but if I ask you this every time I interview you,
back when dot net was just coming out, dot net server,
you showed at dot ne kof a slide where you
did a headless test of the skew that Blazer server
was running on. How much RAM and how many CPUs
versus how many consecutive users you could have, not consecutive concurrent,
how many concurrent users you can have before a click
result doesn't return in two hundred milliseconds, which is kind
of the brain benchmark by which people think it's slow.
And you said that I think it was five thousand
for like, don't know, four gigs of RAM, and if
you increase that to something in for CPUs, it got more.
And the other thing that you said was how much
overhead blazer server used for each user to keep the state,
to keep the dom and back then I think it
was eighty five k. Do you have any idea, I mean,
you probably don't have a number, but would you expect
that number to go up or to go down?
Speaker 4: With the number to go down, give them amount of
performance tuning we've had, but I don't think we've run
that test again since we did. It Initially was done
as sort of a just a proof point to show
that Laser Server wasn't going to be the bottleneck for
a good chunk of apps.
Speaker 2: I think it was.
Speaker 4: It was act like it was a fairly small VM
that you could run five thousand concurrent users and.
Speaker 1: A more yeah, like a gig of RAM or something.
Speaker 4: Yeah, and a more reasonable size VM you could easily
handle twenty thousand concurrent using Blazer Server. Of course, that
changes as you add your own app logic, like if
you start allocating a bunch of memory for each circuit
for each user, then that will yeah, that's baseline change
the dynamics. But as a baseline, Blaser Server can certainly
handle quite easily with fairly reasonable hardware tens of thousands
of current users without sweating. And Microsoft do that all the.
Speaker 1: Time on one server, And this question I get asked
all the time, and just to so that everybody can
not make sure that I didn't lie to them, I'll
ask you. So, if you want to scale out Blazer Server,
you use the signal our service from Azure, and so
then you can scale out add more servers, right, so
if you're twenty thousand concurrent user servers and enough, you
add another one. But by default affinity is on, so
connections are sticky. So when somebody comes in and they
log in and they register, they're always using that server,
so you don't have to worry about, oh, this time
when they press this button, it went to this particular
server which doesn't have my state. So is that that
is true?
Speaker 2: Right?
Speaker 4: That is still the pattern You need to have session
affinity in order to run Blazer server apps because it
is a statefold.
Speaker 1: It's on by default in an app service, I think yes.
Speaker 4: And the signal Our service, what purpose that serves is
helping you with the connections scaled out, Like if you
have a server environment, we're flooding it with you know,
tens of thousands of concurrent web socket connections might be
an issue. They signal ADUs signilar service can help multiplex
those connections so that your server infrastructure is less loaded
on the at the connection part of the application in
many Azure services. Actually, we recently updated our guidance around
the Azure signal Our service, so it's worth noting if
you're using it today. In Azure app service, having lots
and lots of website and connections used to be more
of a concern than it is now, and so for
most of our Azure based hosts, we no longer say
that you need to use the adres signal our service
in companionship with it, because those services can already handle
the number of web socket connections by themselves, so it's
not a normally a problem. But if you have another
environment where that might be an issue, then the address
Signal our service is a great option.
Speaker 1: That's really good news.
Speaker 2: And yeah, you added a bunch of signal R features
for nine right.
Speaker 4: Yeah, yeah. Signal are now has sports polymorphic types, so
if you want to like pass an instance of a
derived type to to your hub methods, you can do that.
There was some work done around its tracing model, like
how how signal handles UH distributed tracing. It used to
be that all the hub invocations would kind of appear
under one big, giant long request, right, because these are
usually long running web socket connections, and so it looks
kind of weird when you're trying to analyze the distributed traces.
They now kind of appear more more like you would
imagine a request reply style trace, uh looking in the
in the traces, which is much It's much nicer when
you're like looking at your signal r hubs in like
the Aspire dashboard, you get a much easier view to
parts to see the what's what's happening with your your hubs.
So those are both new on the there's a couple
of performance improvements. I also wanted to mention on Blazer side,
the for Blazer server or interactive server rendering, we now
do compression at the web socket layer. So the traffic
that gets sent to your Blazer server hub, which itself
is a signaler hub underneath the cover, so it also
benefits from all those signal features too, but that traffic
is smaller and therefore has a lower latency and is faster.
On the web assembly side, we did a bunch of
work on the startup performance of the web assembly runtime.
In the past, we've we've focused a lot on shrinking
the download size so that you can get the bits
for the dotted web assembly runtime onto the device as
quickly as possible, and that is still important, and we
we've shrunk that thing of as far down as as
we can, and we look for ways to improve that,
but there is also still some latency that can occur
when you then boot it up, like you say, okay,
now run the runtime. That can take a you know,
some some number of milliseconds to actually get the runtime started,
which also delays the the interactive state of your app.
So we focused on that and dot at nine and
sped that up by good like I don't remember the
exact number, but something like twenty thirty percent faster runtime
startup performance. And then broadly for asp dot Core, we
did a bunch of work around static web assets, like
the static files that make up your your web applications,
whether this is a Blaser app or an NBC app
or a Razor Pages app, anything that lives in your
dubdub root folder. We now will build and publish time
identify those static web assets and do a bunch of
optimizations on them. We will free the print their filenames
so they have unique caches in the filenames that enables
us to then aggressively cash them when they're being served,
Like we can basically KnowI browsers that cash us forever,
because if there's a new version of it, I'm just
going to change the file name, so you don't need
to worry about that.
Speaker 2: Wow.
Speaker 4: We also pre compress them at build and published time
using Broadley compression. It's very similar to what we've had
in Blazer web assembly for a while, but now it's
done for any static web asset that you have that
isn't already in a compressed format. So thinks CSS files,
jobscript files. The acement core tooling will now do a
precompression on those those those files as well, so your
static web assets load faster and they're better cased, and
that helps Blazer apps as well as any dot Net
web front.
Speaker 1: And lazy loading comes to mind when you said that,
and are you doing any lazy loading automatically in the
background of your own assets in the dot Net framework
or is do we still can we still benefit from
doing that ourselves.
Speaker 4: So there's lazyloading and Blazer where you can like sort
of take a chunk of your app that gets downloaded
to the client and say, you know what, I don't
need this yet. I will tell you when I'm going
to load this, and then they can be lazyloaded in
later that that feature still exists for static web assets.
There are I don't think we've we got to this
point dot at nine, but on our roadmap we also
would like to do like preloading. It's not not really
lazy looad, but like saying like sure, hey, I'm about
to go to this asset and i can see that
it needs these other files too, so go ahead and
preload those into the browser because I'm probably going to
request them them soon. Like having links in your Yeah,
that's that's smart HDMIL. That's signal of that's that will
be the case. That can avoid waterfall style loading of
assets in your webpages that can slow things down. If
you can avoid that waterfall, then things will load faster
as well.
Speaker 2: Very cool.
Speaker 4: That's a future optimization that we hope to get to.
Speaker 2: Nice hate really great. I'm I'm going to go a
little off the beaten path here because I was just
going through some of the notes and it ran across
this mention of multiple Blazer web apps per server project,
which I totally get. I've dug into the issue and
so forth, where it's like, okay, you know you've got
to comment back end several different clients that they want
to manage in one project. What what I smiled at
was when I saw this is tagged for dot net
ten November twenty twenty five, and it's just like, man,
that's organized, Like we know definitely when this is going
to make it for another version, but it just speaks
to the whole conversation about this was a user submitting
the issue? I think just looking at the GitHub reposts
like November of twenty three, so it was it was
right after dot net eight had shipped, is when they
sort of post this issue. I'm sure folks were talking
about it before then, but I'm just looking at this
particular issue, like can you talk a bit about this flow.
I don't imagine this is your problem or not, Dan,
but it's just interesting to me, like.
Speaker 4: How we manage the user feedback and that.
Speaker 2: Yeah, and that's whole triage, Like the fact that it's
all in gidhub now where people can just write an
issue and I see guys like Havia interacting with this
issue and you know, taking it seriously and queuing it up.
Speaker 4: Yeah, yeah, this is this is good to know because
this is how you can understand if you have a
feature that's important to you, how you can engage with
us on the Blazer team to make sure your your
your feedback and your perspectives on these issues is being heard.
So all the feedback everything that we do is publicly
tracked on GitHub. We are a fully public open source
project and that's where we operate. That's where our devs
do their day to day work, and it's part of
every release. And we're about to go into the ten
planning cycle to think through what are we going.
Speaker 2: To do with You're you're in our see now. So
there's clearly stuff that's been triaged out to next and
it's time and this is probably one of them. And
yet now you're starting to sort out like what lives
in next?
Speaker 4: Yeah, so we we we have a number of different
signals that we use to figure out, okay, what what
do we want to push up the stack on our
on our backlog. The one that's most user facing is
if you just go to a GitHub issue and use
the thumbs up reactions right to say like this is
important to me, and do it on the original post,
do it at the top.
Speaker 2: Now I see fourteen fourteen thumbs up on that one.
Speaker 4: Please don't get this, like, please don't look your friends
from a bot network to click thumbs up on these things,
because we do use it as a signal, and we
know it's a rough signal. Yeah, at least lets us know, like, yeah,
I care about this too, so please please consider this.
The next, like level two of helping us out is
if you could post a comment on the GitHub issue
explaining the why, explaining the scenario that you care about
and why this is really important.
Speaker 2: Well, and you have a nice template here the is
there an existing issue? Is it really or fature requests
related to a problem? Can you tell us about the problem,
describe the solution you'd like, you know, some additional context,
Like you've given us some structure to sort of describe
the issue to you.
Speaker 4: So if you're the one that's posting the original issue,
like you're actually the one making the request, then you
follow the template, fill out that information, give us, give
us as much data as you can on your scenario,
your requirements, and why it's important, because that's all stuff
that we read through and factor into our prioritization. Even
if it's an issue that you find is already filed,
it's still helpful for you to post another comment saying
also this is important to me because of X, Y
and Z, So give us more perspective.
Speaker 2: Right, I mean this emphasis on search first, because if
there's an existing issue that you can contribute to, you
increase the likelihood of this happening a weight, right, the
weight gets bigger where multiple separate requests are less powerful
than one big one that everybody's contributing.
Speaker 1: It seems to me that before GitHub, you know, if
you were to, if anyone were to approach a team
member and say, hey, I have this, why don't you
implement this feature? Blah blah blah blah blah, that Microsoft
team members were programmed to say, why would you ever
want to do that? Right? I mean I've gotten that answer,
and I've seen them give that answer to in person,
because that it's not necessarily a combative question, but it
really makes you think I want less compa that I think, no, no,
But I mean it's a great question. But I think
that that's kind of what you're doing with GitHub. You know,
what is the real issue that you're having. Perhaps you've
already gone several abstractions higher than you need to go,
and maybe let's get to the core of the problem.
Speaker 4: And sometimes that's about us. We want to understand the
core of the problem because maybe you're requesting a particular solution,
but if you take the more context on what the
problem actually is, like what you're trying to solve, that
might lead us to a different solution that would work
better from a framework authoring perspective, like maybe we can
broaden the solution that would help not only your scenario
but also these other scenarios and you know, line things better.
So though, the why behind your request is really really helpful.
Speaker 1: And the search thing that Richard was talking about is
important too, because like in my world, I get probably
ten people coming to me a year with ideas for apps.
I have the idea, you build it and will split
it fifty to fifty. I think it's all the time right,
And I always say, all right, before you come back
to me again, I want you to do a thorough
search to see if that app already exists, and I
knit they never come back.
Speaker 4: There's a lot of people with the ideas out there.
It's hard to prome with something truly unique. A couple
of other things though, that are worth noting, So we will.
We have our backlog milestone that's where we put everything
that's like, you know, something we may consider to do
at some point. We often will have a you mentioned
a ten milestone, Richard, and usually that's a doit ten
planning milestone.
Speaker 2: Yeah, and I see it here now as I read
deeper into this thing, it's like you can see you
the point where when okay, this is going to be
in ten like it was initially in nine, and then
it would know it's going to make it to ten.
Speaker 4: So Donna ten planning is the stuff that we're like,
it's kind of like a level above the the just
being on the backlog. It's stuff that we have already
thought about that we do think is important, right, and
we'd like to consider as part of what we're going
to do in intent. It almost always has more stuff
in that milestone than we could ever possibly sure.
Speaker 2: Sure it is like the next it's where you put
all the next it might split across more so, it's not.
Speaker 4: A commitment yet, it's a it's a planning tool that
we used to say, you know, this is probably the
first batch of stuff that we'll look at for the
dot tent planning. And then we take all the user
data that the reactions, we take our our own understanding
about where's the industry going, Like we go do you know,
analysis on what other frameworks are doing, what's what's happening
on the web platform. We look from that direction, and
then we of course look from our own business priorities
and from Microsoft pays the bills.
Speaker 2: Yep, there's things they need. You're going to have to
do those things.
Speaker 4: The roadmap, the committed roadmap, and even this commitment is
is it's it's our our best understanding at the moment.
Roadmap then usually gets published early, like first quarter of
the year saying this is what we think we're doing
an ACEMT Core and Blazer for say dot ten, and
that should published on GitHub. That is still of course
subject to change. You know, software development is hard. We
we often sometimes we misjudge how much things are going
to cost. Sometimes initiatives come in that change plans, like
the secure initiative was certainly something.
Speaker 2: That definitely drew resources off change.
Speaker 4: Things for dot net nine. So the roadmap I wouldn't
view even that as like a guaranteed to happen for
the release. It's one of those things actually that I've
been we've been trying to improve on. It's like, have
that roadmap be more more trustworthy that yes, these things
will actually get done, but it is at least our
best understanding at that moment about what we think we're
going to bite off for.
Speaker 1: The I can also imagine that if you implement a
feature too soon that it can it can be more
of a problem later, So deferring a feature for the
next version the next version after that can often come
on the heels of an analysis that says, ah, before
we solve that problem. We have to solve these problems
because that will make this one a lot more intelligent
or whatever that we won't have to backfill.
Speaker 4: It's for people that maybe get frustrated by that, because
it can be frustrating right where you have like a
feature that's important that gets delayed from release to release.
Might I think the one that's maybe close to people's
minds at this point for web assembly is our multi
threading support. We've we've had multi threading on our i
think on our roadmap now for like two or three releases,
wanting to get it done, and then for various reasons
it having to be to be pushed out. Things that
the community can do to help out with some of
those is that if we are open source project, you
can contribute. That includes contributing design thoughts, contributing approaches, helping
us work through like how would we actually do this,
and even potentially contributing code.
Speaker 2: Yeah, I think someone who's frustrated because you haven't got
it yet writing up this is what I would use
it for, so that you have better case analysis of
like this is how this customer will implement this? Are
we headed in that path?
Speaker 1: Why would you ever want to do that?
Speaker 4: Yeah? With with multi threading, so that's the like the why,
and like like what problems should solve? You can also
help us with contributing and this is how I think
would be a good way to solve it, even if
it's a straw man proposal that that is a food
for a thought. We just went through through this with
web assembly, multi threading and DOTTA nine, where you know,
we went through design and you know, get up docs,
got written and start implementing that design. And for Blazer,
the design we landed on and look like it's gonna
be good. This looks So we weren't able to get
the Blazer part of the work done and DOT and nine,
so we're still waiting a little bit on that. We pretend,
but then we got feedback from other UI stacks in
the ecosystem that use our web assembly support like UNO
and Avolonia look at look at our looking at our
multi threading capabilities, and they have valid feedback about whoa
hold on, like this constraint might be problematic for the
way we use this feature. And both types of design
discussions also super valuable, like please look at what we're doing.
Share you're not every part of the product.
Speaker 2: Well you yeah, you're living. You provide a framework in
an ecosystem, don't break the ecosystem, like that's we.
Speaker 4: Try not to try to make the world a better
place for the ecosystem.
Speaker 1: Yeah.
Speaker 2: Yeah. To imagine a group like you know it's done
all kinds of great work where they say, hey, we're
not going to be able to use a new version
of Blazer based on what you're doing here. Yeah, exactly,
Well that would be bad. That's bad for everybody.
Speaker 4: This won't meet our needs, that might make Microsoft's needs.
And we we want to develop deliver features for the
entire ecosystem.
Speaker 2: Not But I think it's just you stepping into introduced
breaking changes knowing what you're breaking. I'm not saying you
wouldn't do it, but you want to have those considerations, like,
here's how big the impact actually is. You don't want
to ship it and then find out about the impact.
Speaker 4: Yeah, I mean, breaking changes are one thing, and in
other cases it's just like having a design that's overly
constrained or thought about certain scenarios in certain ways, you know,
adjusting the requirements based on as broad and inclusive an
audience as we can, we can.
Speaker 2: Get sure and I could see it'd be worth just
pushing back and working a little longer and then maybe
a pass the thresholder it's like, it's not going to
make this version. Yeah, I mean you're shipping every year,
which I think has got to be hard. I know
it's hard receiving new versions every year. So I gotta
think it's hard on you guys too, pushing these out
every year, knowing your ship date the second week of
November every.
Speaker 4: Time, got a ship one way or another.
Speaker 2: Yeah, And certainly other teams you talk to where it's like, oh,
this feature has been worked on, spanning multiple versions before
we could finally actually turn it on. Like absolutely, that's
just that's just the reality. Not everything fits into a
year long development, much less how the target moves like
you think you know, think about the the FSI. It's
how many of the features you're currently planning breach FSI
and need to be reworked to include new security requirements. Yeah,
all these things are hard, and it's reality tends to
smack you around, right, And I, for one, having been
on the side of you ship something that created a
bunch of problems for folks, I'd rather you wait.
Speaker 4: It, particularly when it comes to frameworks, because when things
go into a framework, it's it's hard.
Speaker 2: You can't ever take them out. Really, Yeah, taking them
out is way way more arduous.
Speaker 1: Or convince people not to use that anymore, use this instead.
Speaker 2: Yeah, that's that's a tough one, because they got working
code on the old way. It's something to see Steve
Sanderson's show up in some of these threads and just
make a couple of notes or something like that. It's like,
it's like this is as demigod, I blessed this, Like dang,
you got blessed.
Speaker 1: All right, Dan, I want to know who plays the
cello in your family.
Speaker 4: I play a little bit of the cello. I don't
play very much anymore. I did do a little like
talent show concert like a couple months ago. So I
had it out and was playing it. And I don't
know if you ever play a string instrument.
Speaker 1: I tried for a year.
Speaker 4: Oh yeah, your fingers get raw if you haven't played
in a while. So I was getting all the red fingertips.
I played through like high school, a little bit in college,
and definitely petered off after that. But I still have
my cello, still occasionally break it out.
Speaker 1: And yeah, I noticed the case. That's why everybody can't
see this because it's the radio show. But but there's
a case in the corner. Yeah. I tried it for
about a year. I was already playing guitar, so I
didn't have the fingertip problem, but the stretch, Like you know,
my hands are relatively small, and the figure your hands
sorry for a cello or bass player. The smaller your
fingers are for violin, the better. But anyway, I think
it was.
Speaker 2: A joke by Frank Carlwoods told me, says, you know
what the difference between a violin and a viola is
the viola burns longer. This is very How did you
know this? We should test it, all right, Dan? Anything
else before we jump off?
Speaker 4: I get get market calendar for fort comp November. That's
when we'll be having a big the big ship party.
So we look forward.
Speaker 1: You got early bits available now you can early what sorry,
early bits are early bits available now?
Speaker 4: Oh yeah, the release candidate is already the first release
Candidate's already shipped and here in just a few days.
Maybe by the time this this episode air, by.
Speaker 2: The time this is this publishes end of October, there'll
be they'll be you'll be second release candiate too, which
really means your interest away. Then it will be a
couple of weeks before dot dot com at that point,
so it'll be final.
Speaker 1: So awesome. Our timing works. Thank you, Dan, always a pleasure.
Speaker 2: Good to see you, frank for having me talking with
you guys. You bet all right.
Speaker 1: We'll talk to you next time on dot net rocks.
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com.
Speaker 3: Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archive going
back to show number one, recorded in September two thousand
and two.
Speaker 1: And make sure you check out our sponsors. They keep
us in business. Now go write some code, See you
next time. You got JAD middle vans, the
Speaker 3: Taxes,