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 NetRocks patron mug. Sign up now
at Patreon dot dot NetRocks dot com. Hey, welcome back to dot NetRocks.
I'm Carl Franklin and I'machard Campbell. And man, it's been a while
since we've done a show. We've done a studio show. We did recorded
a bunch in Copenhagen, which was fun, right, and we're going to
be in Porto not long from now recording a bunch more. But this is
like the in between the two. We get one studio show and you're in
your studio. I'm in my new studio. Yes, that's cool. How
is it are you? Take a look? I mean it's it seems familiar.
It's exactly what you think because you've been in the old ones. So
the walls are kept the red wall. Look, it's the same fabric.
It's not the same bolts of fabric because obviously I bought new ones time has,
but it's the same stuff. The insulation behind the fabric is rock wall
yep. And on the outside walls before we did rockwell, we did spray
foam insulation. Nice. So it's actually insulated to our fifty if anybody else
in construction, that's really really tight. Yeah, as soon as you can
heat the place with a sixty watt light bulb you know, still existed.
And I'll move my head so you can see that split h VAC unit.
Yeah, yeah, it doesn't have to work very hard. No, No,
that's great. I mean, i mean my space up on the coast,
so this is my office is still not assembled. I've been away a
fair bit, but you know, I've got enough running here to at least
from the portable rig. But this will eventually be the setting, yep.
You know, as we get stuff set up, it's good, you know,
change as I put. Yeah, and I'm sure that my microphone sounds
tighter, in other words, less echoey than it was even in my old
place, without a doubt, which I just had U haul blankets up on
the walls. You know. Yeah, this is like serious, yeah,
really properly proved. I'm probably I was thinking I've probably get a few real
traps in here, because it is a it is a jip rock box.
Yeah, but you know, I actually, you know what, I have
the stuff. Yeah, I have the the insulation and the material and the
glue. I could send it to you. Ethan Weiner is a genius.
Though. You know, a couple of real traps in the corner of this
room would probably go pretty flat. It probably would. Yep. Yeah,
okay, let's start off with something cool for better no framework awesome. You've
heard of Jeff Frits, right, Yeah, I'm lascinating because he's an old
friend of ours. Yeah, well, all I think is purple sequence.
I'm thinking purple sequence, purple sequence, purple goatee. He is working at
Microsoft and he's evangelizing for the Blazer team. He's doing live coding and that's
his job is to just you know, be in touch with the community over
Blazer. So he and I started this new weekly thing called the Blazer Puzzle.
Oh nice, And if you go to Blazer Puzzle dot com you'll see
all the ones that we've done so far. So here's the premise. They're
only like fifteen minutes long, so they're nuggets. Nuggets, yes, but
they're definitely nuggets that you can participate in and win coffee mugs and stuff.
So we show you some code that doesn't work, some Blazer thing. Why
doesn't it work? And then people send in their answers to Blazer Puzzle at
appv next and we pick from all of the correct answers, we pick one
at random. That person gets a you know, a puzzle mug and a
T shirt or a T shirt, we're not sure yet. And then we
basically you know, show the solution and then we do a new puzzle for
next week. Nice. Yeah, simple, and it's fun Blazer puzzle.
Yeah, and just getting people, you know, aware of what's out there,
that's right. I mean, you know, if you don't want to
sit through a lot of training, you know, hours of Blazer train or
even anything that's on YouTube or whatever, you can just have some fun and
learn little bits, a little bits and pieces. I love it. And
yeah, make it digestible just a little bit of the time. Yeah,
make it fun cool. If you've got Google you could probably do pretty well.
And we also have a talk a Blazer Puzzle talk in the upcoming dot
net comf that's awesome. Isn't that cool? Yeah? Dot net comf coming
up in No so, Yeah, it'd be great that you're in that.
Yeah, cool one, dude. Congratulations. You know it's sort of a
related topic area. I shot a video series with the Visual Studio team called
Tea and Technology because it couldn't be coffee and code. I don't drink coffee,
Uh tea, But yeah, I got to go run around and talk
to a bunch of the visual studio leadership folks, or not just leadership,
but like the engineers doing the thing. Of course. I talked to Mad's
Christiansen and Leslie Richardson, James Montamagno and yeapped up with with Amanda Silver.
Wow, that's so cool. And just to sort of reminder, you know,
digging into all the great things they're happening in studio. You know,
it seems like people have forgotten how good our IDEs are. You know,
it's easy to play with the new tools and different approaches to things. It's
like, you know why we like id's because they rock, They rock,
they work, they make you more productive, and so it was really great
to dig into the various products in the stack, Like you forget how good
the debugger is and you know, and those kinds of things. It was
really fun to DEBT series, so I'll include a link in the show notes.
But yeah, T and technology of the visual studios in mini series excellent.
All right, Well that's that's what I got. Who's talking to us?
Richard grabbed a comment of a show seventeen fifty nine, and that was
the show we did with our friend Mark Seeman back in twenty twenty one about
code that fits in your head. And the name on it is ye dev
Text. But I'm pretty sure it's not Kanye. I'm just saying, Kanye,
if you do you listen to the show. Interesting, No, I'm
pretty sure it's not. Anyway, Ye dev Text has a bit of a
rant, and I read it because I could so relate to it too.
He said, because we said something casual like get someone to look at your
code, I think I found the line where the buggies iss. I just
couldn't get a single personal look at the code I'm working on to save my
life. The reality is that zero higher ups could care less about the quality
of code. They only care if it works, then they tell to move
on and put out the next fire. This is from the point of view
of someone who makes internal code. I have an old web app that I'm
being asked to save, and none of it fits in my head. Man
sits in your head. Over time, I have learned the value of making
code that fits in your head, because I myself, in earlier years,
followed mentorship that didn't care about quality or readability of code. The only care
about performance, and more that it was if it worked or not. Zero
care about craftsmanship. As I tried to push for basic automated testing, and
as I tried to even learn how to make code more readable or maintainable,
I got labeled as the guy who just likes to write a lot of code
and that I made things too complex. No one noticed I was trying to
figure out how to go this route of making code that would fit in someone's
head. They even told me no one cared how my code looked as long
as it worked. The internal web app has as many god methods that don't
fit in your head, but the web app kind of works, so it's
considered good. Also, don't tell me to change where I work. I
have medical stuff that runs in my family, and this employer is willing to
be lenient on my leaves. So I'm stuck, or rather, you choose
to be stuck because you get some benefits to make it worthwhile. Yeah.
I used to want to learn so much, but that fire has just about
been put out. Now I do what it can, but slowly I will
bend my own opinions and feelings about should be done versus just get it done.
Experiences made it so that I can write bad code. It looks bad
on my part and underminds me personality. But hey, thanks for the therapy
session. That was a great episode. It's kind of a downer, but
at the same time, it's like, you know, it's hard to do
good when there's just no reinforcement for it at all. Yeah, you know,
although it really I think Ye, and I'm pretty sure his name's not
Ye. It's really about code you can live with too, because you're probably
gonna have to read it again as well, Like, don't make your own
life miserable. But I'm with you. You're not going to get any support
from your team about that, and I understand why you want to stay.
You know, you're taking care of the things that are important to you,
and that doesn't mean you get to spend a lot of time acraftsmanship. Yeah,
but hey, let me send you a copy of music Koba. And
if you'd like a copy of music Koba, I write a comment on the
website at dot net rocks dot com or on the facebooks. We publish every
show there, and if you comment there and I'm reading the show, we'll
send you copy of music Koba. And you can definitely follow us on Twitter
or ex or whatever the hell it's called today. But the real fun that
is happening over on mastadon. I'm at Carl Franklin at tech Hub dot social,
and I'm at Rich Campbell at mastadon dot social. Send us a toot.
We like toots. Yeah, some good conversations going on over there.
I got it, definitely, definitely, definitely more focused. I think people
are there for intentionally. It's just Debrie r. Yeah. So uh,
let me introduce again, bring him back to the show. Egil Hanson.
He's a Dane chilling in Iceland and a developer at Delegate and a Microsoft MVP.
He chats globally at conferences about nifty developer stuff and it's all about that
clean, maintainable code is. He's the creator behind b unit for Blazer tests
and angle sharp dot diffing think spot the HTML difference in c sharp. Though
he's danced to many techtoons. Egil's current jam is everything dot net and cloud
and yes, this bio was written by chat GPT. Oh no, it's
everywhere. Yeah. Yeah, I had to do something right. I had
a very long bias bio and very serious one on that right, so put
it in there and say make it funny. And this was what came out
with us few adjustments stop that at all. Well, welcome back. Yeah,
Hey, how's b unit? B unit is doing okay? And by
the way, just to comment on that, uh comment from ye comments,
yeah comment and coming from from Yeah, I'm a big fan of that book.
Martin Mark Shiemann wrote, we read that at the company actually as sort
of a book coupling and it's a it's it's a completely agree with that.
I think the biggest problem in that regard is you need us, we as
developers need to learn to speak a language that management will understand so that we
are allowed to actually write good, maintainable code because it doesn't actually pay in
the long long run. There's lots of leadershire supporting that yeah, and I
guess that's that's one of the challenges there is the you know, finding a
way to convince to see the value in quality code. But I'm empathizing with
you. I mean, it's it's a hard fight. And he's also got
things to deal with. I mean, obviously some challenges at home that his
employer is supporting. Like the these don't sound like bad people, right,
They're taking care of each other. They just have a different set of priorities
because they don't see the value. Yeah. Yeah, I gotta tell you
that I use B unit in my Blazer classes that I teach that's online.
I did a Blazer train on unit testing and we use b unit, So
I'm really really curious as to what's new in B unit. So curiously,
we haven't had to do a lot of changes, so I guess we started
around twoy nineteen when I sort of started prototyping and building it. And I
think mostly due to Stephen Sanderson's brilliant architecture around not being with a Blazer that
because we are sort of leveraging the low level bits in Blazer, those haven't
really changed a lot, right, So so the call render engine, call
rentering parts of Blazer have stayed the same all lists since then. Yeah,
because if the underlying platforms shifted on you, you be in the middle of
a big rewrite exactly. Yeah, but we do have a yearly cadence where
we have to do at least a small point release of b unit because as
a net release and we want to support that. This is a big one,
isn't it. I mean, this one changes things well, and surprisingly
it doesn't really right because the Blazer renderer is still the same. What it's
doing now is it's allowing you to render things on the server and instead of
sending we had bits and bobs down to the client using signal, of just
generating everything in using BASM on the client, it's generating HTVL and sending that
if you're using the streaming rendering and the service right side rendering things. But
that is all there on top of the core fundamentals of Blazer, so we
haven't actually had to do anything extra to support that, which is super nice.
So some of the things we are working on me and my cointaner Steven
Giselle, is more related to things we want to do for you too,
So you know, looking back, it's always fun to sit and and just
seeing that it's been four years now and and some of the things I would
have done different since then would probably be to remember the good old Yagni principle
you ain't gonna need it. And so I kind of made some design decisions
and we are stuck with them at least as long as we stay with the
V one, because we don't want to break people, right, even though
I think most if not all of the units users are not really using any
of the parts that we could potentially could want to break. But but things
like because of this design we talked about with Blazer at a support, basically
it can spit out everything that was that Blazer mobile bindings at one point,
which was might might become a thing. And I think Steven had a demo
where he generated FLOORA components of Flota code from Blazer. So I decided to
architect B units such that that's a core part that doesn't care what is the
output of your components, if it's HTML or something else. And then there's
a web part and that additional abstraction is there and it's working, but it's
not being used. So that's sort of a layer with added Yeah, and
it really is a classic example of what you ain't gonna need it because I
thought it might be useful at some point, and four years later, we
just have additional abstractions to maintain that we had to uh to have that we
have to work around. But one thing that we have been ironing out during
the last year and a half has been stability. So there are there have
been some it's cases you could get into where you rent a component that does
something maybe a syncness, and you sort of have to get the timing right
in your chest to to wait for that thing. And we've seen some interesting
behaviors Foxample. We had one user that was able to ended with a very
large component try he was rendering doing a test like with thousands of component that
was being rendered in a single test could cause a stag overflow, and we
spent a lot of time and I even actually got on a call with the
entire Blazer team asking for some input on that problem to really chase down and
see if that's anywhere in the code base on the Baser side of things that
isn't sort of thread safe or isn't has any surprising things. And the annoying
thing was actually it turned out after a lot of an investigation, what happened
was that when a test run is over, a test is finished, it
will dispose of the bi unit test contact with the sort of the whole host
for setting up at test right and running and rendering a based component and passing
in parameters and services to it. So typically what you do, if you
are a good you know dot net development, is that when you have something
that implements I disposable, you dispose of that when you're done with it.
So beally white thing to do exactly right, So what happened. What happened
is that we would when the test was over and the test had actually passed
its assertions. So when the test method is exiting, it will typically go
ahead and dispose of the beanal test context, which would then dispose of the
unit renderer. But in cases like this where you have a huge component tree
and some components might still be doing work, they might still be rendering,
they might have timers and other things going on inside them that would cause them
to be in the process of rendering at the time where the test was finished
running and would dispose of itself, and that would be disposed of the Blazer
renderer, which is like the core component that is driving and each test.
Yeah, yeah, well and that is completely fine, that's actually what we
want. The problem was we hadn't really thought about that as a problem because
we said, well, when we're disposing, we don't care about the state
of the componentry. But because things were still going on when we just most
of the renderer, the components that the components generating sort of got into an
invalid state, and all of a sudden it was possible to have cycles in
the components we which would cause the stack overflow. And it was a thing
that only happened obviously when you were running on a CI slow CI could the
server up in the clouds and and uh super high to reproduce, And it
only happened when we were running together with other tests and things like that.
So yeah, I've grown rary of disposables and really also protecting the state of
things after a disposed methods being called husband called. So that was a fun
one to track down. Yes, I mean what I like about this story
is like clearly people are pushing b unit to places you'd never imagine. Like
that's the best compliment you could make a piece of software. So I took
it to somewhere I'd never been before and we found some things. Oh absolutely,
yeah, I remember back you mentioned fridge. I use to jump on
on Twitch and hunt around for people that was using b unit back in two
thousand and twenty nineteen twenty twenty because I wanted to see how they were using
it, and and it's it's it's a fun experience watching people using your your
framework and and and and seeing them start heading down that rosy golden path that
you laid out for them where they will land in the pit up success and
all of a sudden they take a right turn right over the cliff and you're
like, uh, what what And and oh I should have put yeah,
I should have problem and put some guardrails up on there and and so so
I think building b unit has been a massively fun and interesting thing. Also
just learning about API design and being able to learning to design something where people
will land in that pitup success right and intuitively they will get to when they
try something that is probably what happens is probably what they wanted. So when
did you add snow shot testing to be unit? Because when I did my
Blazer train with Simon Cowell. We used b unit and then he introduced his
Snapshot testing framework, and so I was it in there then or did you
add that afterwards? So I initially prototyped something back before V one, and
I actually talked a lot with Simon. He's a fantastic omesource developer as well,
and his library you're talking about verify, which is sort of a foundational
library, and then he has a whole bunch of plugins on top of that
that understands HTML or Blazer or I don't know. In seat framework. He
has a whole bunch of extensions that basically allows us to allows you to do
snapshot testing. And so we prototyped a bit on something that would be embedded
directly in your Blazer test components. But at some point I decided to that
it wasn't really worth to have it built directly into b units and instead,
you know, point O point over to Simon's very I dot Blazer test library,
which uses be uted under the hood. Uh So, uh, I
guess the answer is I I never really did. We tried a little bit,
but then decided to just use whatever he has because it there's a whole
bunch of educases that it will handle for you. Okay, But but there
is snapshot tests in the unit used them, there was. That was sort
of part of the initial before V won. It's kind of been in an
I don't really support it phase since then. I just used it last month.
Has it been taken out since No, we just kept stopped using it.
Yeah, exactly. Like so if you go to b unit ad ev
to read the documentation there, we basically say use use verify, and I
do remember you. Also, I saw that Blazer train with you where you
had Simon on and I do believe you. I got that feeling that you
had some good arguments. Why actually his model was better than the one we
were trying to do. So well, it's different, right, I mean
it's different. Yeah. Yeah. Snapshot testing basically says, you know,
take a snapshot of it and when anything changes the output. Yeah, the
output exactly. Here's the input, you know, here are the parameters,
here's the output, and if anything changes, fail the task and you can
say, now I meant to do that or not. We do have something
now in b unit that is definitely supported and implemented through the angle Shop diffing
library, which was my building anglesh up diffing was a detO I took from
B unit of a couple of months because I wanted a way to semantically compare
two sets of markup like the one you expect, kind of like snapshot testing.
So you define this is what I expect, and then you have whatever
was produced by the component. But I wanted a semantic comparer that understood HTML
and understand that the order of attributes on an element doesn't matter, so that
shouldn't fail the test if you refactor your component to order the attributes differently,
or the order of classes in the class attribute, or even white space,
and white space is for the most part insignificant, at least if you have
two more spaces next to each other, right, So that is what is
that is definitely still there. And that is if you don't want to go
the Verify route with snapshots testing and snapshots being separate from the component test you're
writing, we have the markup matches method and it works. It works really
well if you have, for example, smaller snapshots that you can just in
line and I scally that is my preferred method. So you write a test
for a component and then you get to your assertion step. You say my
component and then you do markup matches and then you pass in the markup that
should be there. And if you write your B unit tests in race of
files, so you're actually writing them in race of files, you can use
mark up in line in your see sharp code, which means you don't have
to escape quotes and things like that, and you get intelliscence and you get
syntax highlighting FORTML directly in your CEE sharp code. So that is that is
actually also if you go and look at at being the the depth the dogmentation
side right now, that is the way we recommend doing it now because the
Razor editor experience in visual studio and in writer have become much much better than
it was originally, so it actually works quite well now. Now if you're
what about if you're using code behind, will it still work there? In
a C sharp class it will, And it's become a lot easier to work
with with C sharp eleven where you've got the wrong string literals, so you
can do triple quotes and then you can have some mark up and then in
the mark up parts it would still be a string, but at least you
don't have to escape all the quotes and and inlining and all of that.
So so it's a it's very good there as well. You know what's funny
is back when when I was doing VB net and I was excited about VB
VB nett a while ago. It was a while ago, but they came
out with these XML literals where you could find XML right in there, and
we were all like, mean, yeah, sea Sharp, you don't have
that, and C sharp programs like why would I need that that? Oh?
I remember being jealous of VB developers back in the two thousands when when
you still had to work with x molina regular basis that was that was a
super nice feature. I think we've opened up a bit more to having margob
and quote mixed together in the recent years. I think maybe react sort of
that that the chart with that with DSX right and saying, hey, it's
probably it might not be a bad idea to just mix concerns a bit more,
right, Right, It's okay, it's a little bit sharp developers got
a little less dogmatic. I think, yeah, yeah, for the better.
I think I think so too. Now you're talking about MADS, is
that what you're saying? No, no, no, no, I I
wouldn't blame him for that. I think it's a general in the community,
but mass has definitely also the interesting parts of the changes that been to c
SHAP for the last ten years or so, where they've gone from. I
remember talking to Annas Heilsberg back when he start just introduced a typescript and I
asked that noble annotations where you can say that this might be Noll might not
be there, are we getting that in C sharp And he was like,
you know, being a bit secret, sepen say maybe. And the history
around that was that originally they didn't want to put something into the language that
could where the compiler could come into a situations where it couldn't give a like
a yes or no answer. It should always be right with nobles. You
can you might have annull here, but we don't know necessarily in all cases.
That's why we have the bang operator and we have the yeah exactly so
like the way that John Skeek calls it the damn it operator. Yeah,
that's damn it. I mean it, trust me, stupid compiler, do
it? Do it? Just do what I say. So the Language group
definitely have loosened a bit up and allowed more we are not entire issue and
allowed the compilots to actually be wrong in a few instances, and I think
that's the better. Yeah, this is booleyant thinking, right, there's yes
and there's no, but there's no. Maybe, come on, is that?
What's that? What? Maybe? Gentlemen, I need to interrupt remote
moment for this very important message and we're back. It's dot net Rocks.
I'm Richard Campbell, that's Carl Franklin. Hey, hey, hey, each
in our respective studios for one studio show before we go back to the in
person live shows at conferences, and we're here with Eagle Hanson talking a bit
about the latest in B unit and all the goodness. I also wanted to
bring up the whole open source conversation because obviously it's been an ongoing thread for
us the past couple of years. And you, you know, you strike
me as a person building leading an open source project that helps you with your
work that other people are now depending on as well. I don't imagine there's
any commercialization in your future around this at all? Am I wrong? No?
Not really no, So I think the whole em Q drama I guess.
Yeah. I really didn't want to jump on that because I felt like
everybody, you're only amplifying rage, like it wasn't necessarily a good thing.
Nobody got off pretty quickly, I agree, So I I tried to say
a you know, a laid back approach and not be too aggressive. But
it's hard to you know, be quiet. But I think it was.
It certainly wasn't fun for Daniel, the maintain of IMQ, but I thought
it got a lot of interesting conversations to the front in the dot eco system
and the open source ecosystem at least. And I also adjusted my thoughts a
bit on what it means to have maintainable open source. So one of the
things I did realize was that is a surprising imbalance in the relationship between the
consumers of open source and the maintenance open source. True, and I don't
think it applies to all open source models. So we have the corporate open
I don't know if that's the right term, but bear with me. Like
the corporate open source models from like where people companies like mysour of the Google,
Amazon, the Linux Foundation, they hire people that work full time on
open source, like the big projects really we know and like that drive a
lot of things that we have thank for granted, like the Linux kernel or
the dot net or Java. Y sure exactly. So I assume that is
a business model in it for those big corporations because they are you know,
stock Rhythm. They wouldn't be doing that unless there was something in it for
them. So in that regard, I sort of consider that as somewhat balance
model. The consumers get the safety of knowing that's big company behind the open
source so they can safely take it a penancy on that, and Microsoft and
the likes probably get something out of that as well, I think. And
then that's the second model, which is sort of maybe where you have open
source that is some sort of dual that's a dual license for example, that
says to it all that is a company behind it that is setting services.
And I think we have examples of in service Bush with hands company and and
doing the software a dentity service. That's I have required a lot of success
stories around that where people have had some open source product that made sense to
lift up to like create a company around in some way and was obviously we
had those conversations on the show for that matter, and they said our customers
came at us and said, hey, you know, we want to pay
you so that we have certain rights, right exactly, yeah, yeah,
So so that again there there is a balance, right, they give money
and in return they get certain guarantees. Port is a lay and software,
right. But the third model is where I see the imbalance. And there
might be four, fourth and fifth models as well, but that is sort
of maybe the open source model where a b unit fits into an EMQ also
fits into even though MQ probably has a hundred times the downloads that we do
or throw automapper to that equation if I'm following you, right, yeah,
exactly. And the idea here is that it might be a loan developer that's
creating something that is becoming quite popular and being used in many places. MOQ
is an excellent example of that. Like, imagine how many projects, commercial
product project projects that are depending on a MOQ to be able to iterate deploy
a new version because it's part of the testing pipeline. So if for some
reason or another EMOQ ceased to exist or wasn't pushed out anymore or as it
were, people started to think, can I trust this? Can I have
this in my pipeline? Inmo Well, there's lots of millions and millions of
dollars and lines of code invested in EMQ and the I think the when you
think about it, the surprising thing to me is that the imbalance between the
consumer and the maintainer here is that it's actually to the It's even though the
consumers are getting em OQ and the likes for free, right, they also
have a huge disadvantage because they have no leverage, that's nothing that is basically
forcing them into the maintainer that is, to keep keep maintaining that product.
Yeah, yeah, no, is that great line when they're yelling at the
maintainer, it's like, would you like me to refund everything? Exactly?
Yeah, but I really appreciate what you're saying here, right eagle is and
I'm sorry interrupt, but it's like, oh, go ahead, Yeah,
we are treating all of these projects the same, and they're clearly not.
If micros, you know, you can rage as an issue in the c
sharp you know, GitHub repository and a set of full time employees are going
to read that that that make real salaries and share allocations on all that sort
of thing, right, or even if you do the same thing in duende
and you're paying customer Like that's another thing. But for Eagle or Jimmy or
Daniel, like come on right, yeah, And I like I saw some
people suggest to Daniel instead of you know, trying to bring awareness by you
know, you can agree a disagree with this tactic, but basically he was
trying to raise a flag and say, hey, I would like to work
more on this, but I don't have I don't have the you know,
time which is money to actually do that, and I want to you know,
keep moving forward with EMOQ, and not of people were suggesting, well,
instead of doing what you're doing, you should in step maybe create a
company, create a dual license and have a proversion. I think that's a
problem with that because certain projects like AMOQ and be unif of that matter are
they have periods where you really can do you can you can work full time
for a couple of months, maybe even a year on that, but then
there is a lot of downtime where it doesn't really make sense to build a
company around something like that. And then that's the thing, like I said,
you guys probably know that you created companies, right, so you know
it's not a real thing to actually have a proper company incorporated with taxes and
selling and vate and you know, sitting across country be making money. Otherwise
it's not worth it. Yeah, there's a there's an overhead to operating all
of that. It's also a different skill set. Like just because you're good
at building testing tools doesn't mean you're good at building testing tool companies. It's
not the same thing. And I can see why somebody like Daniel at least
certainly I wouldn't want to try to attend that because it would it's out of
my comfort zone. So right now, I think the open source system in
open source in general is lacking a way for developers to do what they do
best and then have other people's people, you know, maybe make a platform
that can make it sustainable. If that is a neat I think the best
example we have of that is actually might be the app stole concept that we
have for mobile apps, right because then there, you know, basement developer
can just put out an app and register his credit card with Apple or Google
and if people actually want to buy, and you know, they they may
sort of become the reseller of the software if they want to touch any To
minimize the company part of that overhead. You could be a quote unquote soul
proprietor and I'm using business terms here and just have it money up here and
pay your taxes, but a little ahock a lot simpler. Yeah, So
that that would be one way that it could, in theory go, but
I'm not sure that it's a viable option. No, And it's and again,
this is why it keeps coming up on the show, is that And
I think you've articulated super well that the tech giant's getting involved increase the sense
of the schism, right and then and now we're surfacing more and more and
saying shouldn't we have categories and shouldn't there be a mechanism to support these different
models? So I think this is not not done yet, definitely not a
finished finished so there are perfect solutions yet. I do want to give a
lot of credit to GitHub, because we've been pushing things with that gid ub
sponsors program, and they've been doing things recently where you as a company,
if you have a giit ub organization, you can go in and say,
give me a list of all the source software I depend on, and you
can prioritize those and you can upload a CSV file and say I want to
sponsor all of these, so that lowers the barrier for corporations to come for
companies to come in and say give like they can have I don't know,
one hundred dollars or five hundred dollars every month they want to give out,
and they just base that on what they're actually using. There is. Yeah,
so I definitely think that is also another approach that could be that it
may make it that easy, so there's no excuse, like it shouldn't be
should be a one click like the one click shop button from Amazon, just
re sponsoring all those souls you use, right, And we talked about this
on the show a while back, and I may have called my friend Martin
Woodward in the meantime and we're talking about exactly that that you know, the
average CFO wants to pay attention to this once a year or once a quarter
and no more, and so can getthub roll all that up. Plus I
would throw on top of that that basic hey, what open sources we depend
on. That's bill of material stuff too, right, Like that represents your
security exposure, Like these are things that a corporate customer that uses GitHub in
a meaningful way should be paying for because they're very valuable, and while they're
at it, putting some money into the projects that are important to the company
by utilization alone, if nothing by preference, just makes sense, Like it's
not like we can't afford it, and it's not like we don't get value.
What you got to do is reduce the friction. Yeah, at the
end of the day, I think the best way to ensure that the open
source software that people are depending on in their software sticks around is I don't
know any any better way than actually, you know, giving the maintainers a
little bit of money. That is, I can say I've been very lucky
to have some sponsors for the years. That it does. Actually, even
though it's not quit your job money, it's it's uh, it's it's a
boost some motivation for the things. Yeah, I like that, right,
it's quit your job money is a different ball of wax. But then we
acknowledge you with take your family out to dinner like that, that kind of
thing. I like everything about that, or get it yourself a new monitor,
right like that? That's respectful and beneficial. Mm hmm, yeah,
absolutely all right, So we touched on beat unit uh in dot net eight
and that yes, there's a major Blazer update you know, to the architecture,
and now we don't have to have a signal ar connection for anything that
just runs on the server, which is great. But what do you personally
think about dot net A in terms of its significance in the whole asp ne
net core ecosystem. Good question. I think I think it's going to have
a significant impact on the adoption of Blazer or rather Blazer components, because I
do think it is a superior model of using Blazer component instead of rail pages
or MVC controllers if you if you want to go really old school to model
your application in such a way. So I do think that it will become
a gateway drug to many that can actually just use it to create a classic
old static website. Well not static websites, but but but just websites,
right, not web applications. But you can use it to actually build websites
now, and it's much more intuitive and forgiving development model. And it's not
that you you, oh, let's not create a Blazer app. You know,
we're creating an asp net core app. Oh, and we can we
have this component model that we can use to generate data. Now that just
happens to be called Blazer. Some might even say it looks a bit like
wet forms just in a model or to you, yeah, well the US
easy as Yeah, well, I think wet force and well is a brilliant
technology for its time, right well, and I certainly there's a certain customer
that that familiarity will encourage them sure to tot least look at this. I
that was one of the other aspects I thought about this is this is another
checklist item where you don't know if you want to commit to client or service
side rendering, and you don't have to decide that's right, and you can
use a combination of both. I am so looking forward to r C two
or just the release in November. RC one kind of has a little speed
bomb in it for using you know, client side rendering and auto rendering.
You have to sort of put those things in a separate Razor class library right
now, but that it's only temporary. But I cannot wait. I have
so many websites that I just want to that I just I don't have interactivity,
you know, I just want to generate stuff and not give my users
the white screen of death when the signal service box. No. But yeah,
actually that that was the biggest sort of gotcha with with Blazer Server,
which is also in it off self a fairly good product, especially internal intranet,
not high scale websites. That that kind of grade out. We lost
connection counting up to eight right before it gives up. So the only thing
I can really fault when new the model for UH is gonna be a performance.
It is a bit more expensive to basically spin off the whole Blazer renderer
and spin out HTML compared to the moll UH that's list things going on if
you just do a raise of pages or even NBC just spinning out some HTML
right for dot that eighty speed speed speed speed. But this is a particular
set of libraries where they're adding functionality, so maybe we don't automatically get faster
all the time. It's really funny that I spun up r C one and
I'm messing with it, right, and I'm like, all right, I'm
just gonna do static stuff. And then I just have this little button on
blazertrain dot com that sports ascending, right, It's like one button with a
little bit of code and I'm like, oh, geez, now, I
kind of like do a Plazer server or Plaser reb as suddenly or auto.
I can't do that because the current state of it, it's like, nah,
I'm not just want to write some JavaScript? What what am I thinking?
Oh my god, did I just say that? Did I just think
that? Well? How you know you can just do you know that that
button could just be a link that if you click that it posts back to
the server with you know, corey fs. I know, but you you
all get into that thinging, Oh, it has to be a stateful thing,
right. It actually does, which is a nice thing. But but
again to the performance point of view, it's not a problem for ninety nine
percent of the apps out there. If you're building a new being, you
might not want to do it with Razor rather Blazer component, right, But
if you don't have a million you visit us every day, that's probably not
You probably want to prefer maintainability over a slight bombing performance, right. Well,
you know, and this really was just a hiccup in the current version.
Right, once it's done, I would have just set you know,
render mode to auto, and by the time anybody gets down to flipping that,
you know, sort of sending button. Everything would have been in web
assembly anyway, So it's I just can't wait for it. Yeah, I
agree, I think it's going to I suspect there will be a few more
customers in my boutique as well now with the unit because it's actually b unit's
even more ideal in this scenario because if you're just doing service side rendered stuff,
you don't have a lot of JavaScript in that. And that's the biggest
limitation of being Unit compared to something like play right is that it doesn't run
in a browser. So all the JavaScript that you might be calling from your
Blason components, well it stops sort of at the eye at yas run time
interface, and then you have to intercept that and deal with that in b
unit. So but if you're just generating HTML and making a service side application,
you don't have you don't typically have a lot of JavaScript, if any
at all, and then the unit is going to be a really excellent choice
for testing your components. Yes, so you Gil, is there anything else
that you want to talk about before we wrap it up? Yes, Well,
how about we talk about maybe the most controversial new API and dot net
eight, and it has even been backports to dot it two well dot net
stand dot two point zero, and that would be the time provider API.
So if you don't know what that is, it's basically an abstraction over the
daytime offset get UTC now that we all use in all our code. And
it also includes an abstraction over a timers so you know time that think things
that happens con in reoccurrence. And it also allows you to do things with
timestamps, right, So it's all about a single abstraction that encompass all of
those things. And I thought it was a really interesting API, and that
was designed during dot need eight. It actually started back all the way back
in twenty twenty, and it's a proposal that I've gone i think to three
hundred and fifty plus comments on githob and that issue related to it, and
wow, it was super interesting because there was a lot of objections. So
people didn't like the name a time provider. People thought maybe it should do
less things. People were throwing you know, single responsibility principle and solid principles
into the discussion and and I kind of understand why it like the objections,
So for me, the interesting thing started was actually last year I needed a
way to deal with timers and and day times in some product I was building
for customer, and we wanted to basically be able to test that code as
a fairly complex state machine kind of a thing that did things, you know,
based on clocks and things like that. So I ended up building something
quite similar to time Provider, And you know, as a typical is when
you like to build them solves, you prout an ounswer to the world and
push it to nugad and somebody points at the issue on GitHub and says,
have you seen this? And I was like, oh, but it was
fun. Actually I took a look and I could sort of immediately recognize why
it was designed like that, because I, while my design was similar and
it wasn't as you know, fought through as the one that the Microsoft team
has proposed, but I could immediately recognize the design and why they came to
it, why it came to be what it is, right, and you
know, to sort of in defense of all the people that are that are
sort of challenging the design in that gate tob issue, I would probably have
been on their side as well if I hadn't actually spent a month trying to
sort of go down that same path of myself. That's so that's such a
great statement, like the more I knew, the more I appreciated what problem
they were taking on. So I think why I think this is interesting is
that if you are using time like a time stamp or a daytime officet or
a timer in your application, which I think most of us are, you
probably want to switch to using the time provide our API going forward, and
it is available in seven and six and well all the way to back to
dot need framework actually via the dot need standard compatibility. So the key thing
about the time provider and why it isn't a bad design in my mind,
is that it's not an abstraction over just time and date. So we've seen
you probably have written some of those in your code. Basis the iClock interface
that helps get you to see now or you to see now property on it
that would allow you to replace the y clock with a fake or mock during
testing. Right, what it is actually a time provider is not just that
it's an abstraction over the flow of time or the progress of time. So
to be able to abstract flow of time, you need to start with the
concept of a timer, so can I quish you guys? So a new
time general time timer provider in dot need eight and backport it back is called
eye timer. And what is the promise? Not of that, but in
general, what is the promise of a timer in dot net that it will
fire and lapsed event or an event that you can handle on an interval exactly
until you say stuff. And to be more precise, if you fox sayuple,
create a new timer and say in one second, call my callback,
the promise is that the run time will call that callback in one second or
later. On This the process crisis, of course, and it never calls,
but it's it's it's it's in one second or later. So if the
operating system is doing stuff as busy and you can't get any process or time,
well it might not be in one second, it might be later.
You don't really know. There's no guarantees. So if imagine now that you
create a timer and you want to control that timer, may be doing testing
well to keep that promise. If that timer call back, for example,
checks when the timer came back happens, it goes and checks what is the
clock now? Because it might be relevant to it for it to know if
it actually, you know, had to wait one second or it took a
bit longer. Right, So it's quite typical. Actually you would if you
start looking at your code, you will see it's not It's quite often that
after a timer call back happens, you tend to check what the clock is,
or you tend to check a stop watch how much time has elapsed.
Right, So the promise, the reason why it's a sort of abstraction over
the flow of time or the progress of time, is that when the timer
happens, the clock that you would get when you call get you to see
now should also match the time that has progressed. So that means that the
flow of time is tied heavily, a coupled tightly coupled to what the time
is as well. And that is why it makes sense to couple these things
together, the concept of a timer and what the time is right now,
or what the timestamp would give you in terms of if you call get time.
So so for people not familiar with the time provider, there's a get
uty see now method, there's a great timer method, and there's a good
time stamp method, which is basically the fun foundational building blocks. And what
the dot NED team then did, which was brilliantly uh from from insight.
From that point of a brilliant insight they had was well, if I as
long as I have a timer, I can now use time providers to control
things like task dot delay because task do delays. Yes, the timer with
a single recurrent I can use things. It can be compatible with things like
the periodic timer type. It can be compatible with cancelation tokens that need to
cancel after a certain amount of time. It can be compatible with the weight
asan method. So all of those methods from dot NEIT eight and some of
them are being backparders to the dot NED six and lower. Now take the
time providers input as well, so that in your code, if you rely
on on time US in some way, you can inject the time provider in
your production code and use that and when you want to test that thing,
you can now instead inject a fake time provider that will allow you to forward
time immediately. Eagle, I think you just did it. Better know a
framework. Absolutely no, I can't feel your shoes, you can, but
totally get it. Your explanation was phenomenal. It's it's it's really interesting,
and and so at advice for people listening though, is you can because time
provider is an abstracts type. It's not an eye, it's not an interface.
And many people who also advocating let's get get an interface, it's going
to make it easier for us to you know, mark during testing, but
it is. It is just an abstract class and you can actually easily mark
that using EMO CU or in substitute or whatever you want your favorite thing to
be. But I would highly advise not to do that because unless you're sort
of in the most simple scenarios being able to uphold that I timer promise of
when time moves forward for the time when the callback happens, time for all
the other properties should also be up matching whatever has happened there, that is
a fairly complex thing to configure in a general purpose market framework. And so
Misoft has also built I guess, the official time fake time provider that you
can use during testing, which has a method like advance or get you gc
now that allows you to move time forward. And I was I had the
sort of good experience of being able to contribute to that fake time provider with
my you know what, I what I learned by building my own and and
sort of various educases that needed to be handled there. So that was a
fun, was a fun thing to to really do. So as a side
gig from b unit as as well. Awesome. Yeah, so what's next?
What's in your inbox? Well, I'll be heading to ndcposal and hopefully
have a beer with you guys or if that's still a thing and doing at
least at yes, oh well yeah, yeah, definitely, And well we
will continue working on V two of b unit me and not my my comments,
and I'll also I also have actually have also had the privilege of doing
a talk at dot dot com and then I'll be at erdav in Sweden Melmbury
as well in this year, so conference wise, a fairly full calendar.
And okay, yeah you're you're here, there and everywhere, so all right,
that's me so great. Well we'll see there, We'll see you in
Porto absolutely, and we'll see you, dear listener 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. 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 archives going back to show number one, recorded
in September two thousand and two. And make sure you check out our sponsors.
They keep us in business. Now, go write some code, see
you next time. You got middle and time, like mess home there,
like Texas line resin Hall