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