The .NET on AWS Show, featuring Dennis Doomen!

🎧👉 https://www.art19.com/shows/net-on-aws/episodes/a724506e-2e1d-4635-bac6-02dc0724aedd

Brandon Minnick 1:05

Hello, everybody, and welcome back to another episode of the dotnet. on AWS Show, the show where we talk about dotnet and AWS twice a week, every other Monday here on Twitch. I'm your host, Brandon Minnick, and with me, as always, is my amazing co host. Francoise, Francoise and it was your week.

Francois Bouteruche 1:27

Amazing. It was an amazing week, because we had an amazing launch last week. And I guess you know what I'm speaking about?

Brandon Minnick 1:37

Yes. In fact, I have it up on the screen here. What did we launch Francoise?

Francois Bouteruche 1:44

We launch the support for dotnet. Eight, run runtime on AWS lambda. So it means that starting now, you can update your project your AWS long that project to leverage dotnet, eight on AWS lambda. And that's really great. I did it on Friday. Just bump my IRA, AWS lambda function project with a bunch of CDK to deploy my AWS lambda function, I just burned everything to dotnet eight, rebuild, deploy, and it was working. Super cool. It just worked. It's just work. Yep. Goodness, yes. There are many goodness to get from that eight.

Brandon Minnick 2:32

Yeah, I love it is one of the biggest things, which is here in the blog post. And we've shared the link to this blog post in our chat. But essentially done at eight is the first runtime that will say GA is this feature called native EO T. And with native EO T, essentially compiles all your code ahead of time. So that's what a ot stands for ahead of time compiling, which you might think, Hey, I've been making C sharp apps for years. And I always have to click Compile before I deploy it. What's native IoT? Well, when we compile our C sharp apps, it doesn't compile it all the way down to the assembly language code, the ones and zeros that the CPU needs. So you know, Intel has specific instruction sets and Mac Apple silicon have specific instruction sets that need to know. So what actually happens is, when your app launches at runtime, the dotnet runtime quickly looks and sees, okay, what chipset are we running on, and then it compiles, it takes that dll file that we compiled, I'm doing finger quotes, quote unquote, file, and then actually compiles it for the processor. So with native EO, t, it does that all ahead of time. And long story short, what that means for lambda, is that our absolute launch faster. So we're seeing cold start times as low as 300 400 milliseconds now, as long as you have native IoT enabled, and that's basically what's new, or the big new feature done at eight, because IoT was released in dotnet. Seven, but the data team was like, we think it's good enough in that seven, but maybe we don't deploy it to production just yet. We're still trying it out and iron out some some of the kinks but not at eight. They're like, Yep, go use it. So yeah, not only do you get the latest greatest goodies in C Sharp 12 dotnet, eight for your ATS lambda, but also, if you turn on ahead of time compilation. Then here we've got a chart that shows all these different optimizations you can do with nativity like optimization, preference on size and speed, you can set the specific instruction set. And this chart you're seeing on the screen shows average cold start times of around 300 400 Max or I guess 450 Or there's a whole call Call Max, there we go 500 milliseconds, which is really incredible, because I remember when I started using serverless, back in the day, we're dealing with couple second cold start times. And it's like, okay, well, a couple seconds, users are going to notice this, how do I get around this? And I just put fun animations in my app to distract them. But now with, yeah, 300 400 500 milliseconds, people are starting to ask me like, why wouldn't I use serverless for everything, and I'm like, zero point. So it's as long as 300 millisecond Cold Start Time isn't going to kill your business. Like, if you need to make stock trades, and they need to happen in milliseconds, then probably still do it the old fashioned way. But I'm excited. I'm so glad we have done any support up and running on lambda. And, yeah.

Francois Bouteruche 5:54

Important things. We've updated every tooling. So if you are using the AWS toolkit for Visual Studio, it has been updated to support dotnet. Eight on AWS lambda, if you are using the SAM CLI, to build several less application with this CLI. It has been updated if you are using CDK that like I'm doing to package your lambda function and publish them on in your account. CDK has been updated as well. So everything is is ready to use dotnet on AWS lambda, whatever the tooling you're using. So that's pretty good.

Brandon Minnick 6:35

Yeah, so big day, go update all your all your serverless apps, it sounds like it's as easy as just flipping net six Dotto to net eight Dotto. And if you're me, I just right click publish. Don't Don't do that. But if you're me,

Francois Bouteruche 6:50

just read through your pipeline goes through your pipeline.

Brandon Minnick 6:55

Yeah. And sovereigns, just like Francois mentioned. Yeah. All the dotnet SDKs for ATBS have been updated for dotnet. Eight as well, that that's supported that should have been rolling out for a few months now. And I think we just with the data.

Francois Bouteruche 7:11

Maybe maybe the question is also about how the SDK support trimming for native LT n, the dotnet SDK is ready for training for dotnet native IoT, so we are ready for this as well.

Brandon Minnick 7:29

Love it, love it? Well, as much as I love serverless and can talk about this all day. We have an amazing guest with us. And I don't want to take away any more of his time. You know him as a Microsoft MVP and event sourcing veteran. He's the author of fluent assertions. Dennis doin. Welcome. Hey.

Dennis Doomen 7:49

Thank you. Thank you. It's a big honor to be here. Yes. Yeah, you make it sound like a big thing. But I'm sure Friends of the dotnet community

Francois Bouteruche 8:03

are it is it is a big thing to me. I've used flu intercession in the past and like, being able to speak with you is like, my honor. Not your honor. It's my honor to speak with you.

Dennis Doomen 8:16

Float assertions doesn't define me that actually. I mean, the fact that I have a relatively successful open source project doesn't actually mean I'm a great developer. I've only been very good at marketing. Now. I'm also not. I have no clue. I honestly have no clue how it got there.

Brandon Minnick 8:34

Well, speaking of which, Dennis, who are you? And what do you do for folks who may not have met you before?

Dennis Doomen 8:39

Yeah. Cool. I'm Dennis. I'm from the Netherlands, which you can obviously hear from my accent. I started I'm actually in this profession for 27 years. Been coding in dotnet? Since 1991, basically, from the start, I think I started programming on my Commodore 64 When I was 11. Which is a long time ago, actually. And what happened? Yeah, Commodore 64. Then I started doing C C++ on my quarter Amiga. When the whole world was still doing single threaded programming on the what is it the was at that time? I 368 or 386 or something or any six? Yeah, we had like pre emptive multitasking on the Commodore Amiga, which was awesome at that time. But yeah, 1997 I started becoming professional, semi professional. And I think I got somehow ended up in Paris. We were talking about this before the session started. French Ah, so 1999 I lived in Paris for a year worked for a company the C and C++ programming. Object Oriented Programming was the first thing is first time I saw that and I got antastic and then somewhere in 2000, I made a switch to a different company and I started to adopt C sharp Um, wrote golden guidelines I did actually, I don't know if you remember it as something called Managed C++. So that was basically an extension to dotnet. So you could actually consume C++ libraries, native libraries in C Sharp and create a bridge between the two. So I was working in the Phillips somebody Phillips, medical systems, they build MRI scanners. And they had like, the whole UI was built in WinForms. At that time, but it was connected to this semi real time code written in C++. That was pretty amazing stuff at that time. Yeah. So that's how it started. Yeah. I worked for a small consultancy firm in the Netherlands called Aviva solutions, which not to be confused with the one the insurance company in the UK. And what I do, I spend most of the week helping my clients professionalize software development. So basically, looking at tools, practices, architecture dotnet, you know, properly using dotnet, looking at continuous deployment, which is a path by itself, looking at quality, everything that comes with software development. And I love doing that, because there's always so much to improve.

Brandon Minnick 11:11

Yeah, yeah, I love it. I'm the same way I love giving getting into a code base and just kind of cleaning everything up.

Dennis Doomen 11:18

Awesome. I love that day of the week is when I can actually delete code, preferably somebody else's code, because I can rewrite it. I love this stuff. I think I made a joke at some conference recently, where I said like, I'm addicted to legacy code, and I'm truly am I love taking it, you know, molding is introducing seems you know, making a testable. All this stuff. I love that.

Brandon Minnick 11:45

Yeah, yeah. So it's interesting, to me, at least, because I've, I've had to do similar jobs where you go in and you've have a team of developers that can sometimes be, let's say, hostile, but they don't want you there. And they'd say things like, yeah, like, we don't need any help, everything's fine. And then you look into code, and you're like, you haven't used anything new and C Sharp since like C sharp, three, like, Yeah, I saw code base ones that wasn't even didn't even know what generics were. But they already told me everything was fine. And they didn't need me there. Has like, okay, so, back in C Sharp, three, generics were introduced. And let's talk about async await. And basically, yeah, modernize their whole repo. But But speaking of which, before you do any modernization, you should have unit tests in place. And you mentioned Dennis, the fluent assertions library at the top of the stream. What is that? And how do we use that to make our unit tests better?

Dennis Doomen 12:52

So unit testing, and I'm a big, big proponent of test driven development is all about trying to make it clearer, extremely clear what the expected behavior of a piece of system a piece of the code is. And that can be class can be a couple of classes. And one element is obviously the name of the test. So use functional naming. Another element is the structure of the test, like, you probably know, the range act assert are given when then constructs, which are all important ingredients to make those tests more self self explanatory. You know, if a test fails, ideally, that's kind of the promise of TDD is if you actually go to the tests, you get a good sense of what are the different parts of the system? And what kind of behavior to expect. But of course, there's all only works if the tests themselves are readable, self describing? Well, one element of a test is what is the failure condition, you know, you're doing something, you're calling a method, you're invoking an HTTP endpoint, and you expect something back. And I wasn't really satisfied with the stuff that Microsoft provided at that time, we had MS test, be able to build an efficient, like, if you only have methods like assert, are sure adults are equal. The question is, what is the expectation? And which one is actually the, the actual value? Interestingly enough, it's very confusing. I don't even remember which one is which. So if your test fails, it wasn't really obvious. That kind of started like and we had extension methods at some point that we felt like okay, yeah, you know, what happens? You can do extension methods. Now, you have to use them everywhere. You know, your whole code base should be filled with extension methods, everybody, everybody has done that. But we discovered like, oh, we can actually make it more fluent. And at some point I think I read about fluid API's. I still love them. Some people despise them. I like them. Also practice the use the test data to build a better than a lot, which is also fluid API for building different test objects. And we started experimenting with a colleague of mine, Martin of them, like Can we can we make our tests more or fluids are more self explanatory. And that started as a small project internal, I think it was called Custom assertions at that point, or customization extensions or something like that. And eventually, it turned into fluid assertions. And then we had code flux, which wasn't really good, really wasn't really good platform. Ultimately, when we moved to get up and nougat was introduced, everything changed, and it became bigger. But in the end, it's still a tiny library, which only purpose is to make your assertions a bit more self explanatory. became more powerful. Like, sometimes you have object graphs that you want to be able to compare, it can do that for you. You want to re you want to throw or want to verify that some piece of code throws an exception. And if it doesn't do that, you want to know what did it throw in stat? Or why, what was the stack trace? Or what was the message? And that's how it evolved and became bigger and bigger.

Brandon Minnick 15:57

I love that. So let's see, if we go we go back to the days before fluent assertions, and that's when I started unit testing. Hadn't hadn't heard of this fluent assertion libraries yet. So yeah, I would say like, I would run by tests, and we do this sort of the end. And if like a Boolean was expected to be false, for example, I would say assert dot false and then I would pass in the, the Boolean or if I expect them to be equal, I would say something like assert dot equal and then I'd pass in the expected and the actual object

Dennis Doomen 16:35

the other way around.

Brandon Minnick 16:37

Yeah, I can never remember. And, and maybe that's, that's one of the problems that we're solving here with fluent assertions. But explain to me how is fluent assertions different than just saying like assert dot false Pasighat a bool.

Dennis Doomen 16:49

So in this case, you would have some kind of variable name, let's say success value or outcome or something like that, which is of type boolean. The big difference is that you can actually say adult should be true, or should be false. Literally saying, like, what is the expected outcome? The extra thing is that if your variable has a very self described name, it will include that in the name. So if, for example, you have an a value, a Boolean value of which name is result, which is not very self explanatory, but just for the sake of the discussion, it would actually say expected result to be true, but found false, or the opposite way. So actually extract from your test the name of the variable and use that in the actual message. That's one thing love as

Brandon Minnick 17:43

you have like, a dozen assert statements, and one of them fails, and it just says, the whole test failed. It would be like the assert that failed, expected an object to be equal, and it wasn't like, Okay, I've got like a cert dot equals eight times here. And then I have to go back and put in a breakpoint and find out which one it actually failed on. And so with that, actually, tell me the variable name. Yeah, it seems so simple and obvious, but Well,

Dennis Doomen 18:11

it's it wasn't why were we doing that before requires quite some hacking around with stack traces and, you know, analyzing C sharp code and stuff like that, that's an extra thing, because sometimes you are, you're not just verifying that the success should have been true. But you also want to add some phrase like, because I'm expecting this operation to be successful, or because I don't know the system is not in the right state. So in addition to just calling success dot should be true. You can also pass in a string between the braces as a parameter and that will become the reason for the very sorry for the assertion. So to literally say then, expect it to be true because we were expecting some particular case situation, which makes nicely and those people don't use that. I want to use it occasionally when it adds value. Sometimes it does extra that does add value, especially with booleans there so yeah, anonymous in that sense. And that can be quite usual. It

Francois Bouteruche 19:14

is really about making your tests and and the message human readable to me like how you describe this it's really appears to be okay. I just want to read the message and get in one second just reading the message. What is going on?

Dennis Doomen 19:36

I think Jeremy D. Miller, I don't know if you know, Jeremy, he wrote a structure map and a cover. And now he's on the Quito stack. He was wrote like you should keep out of the Depo Raul. And that's one of the reasons you know, if the test fails, it should be completely and immediately obvious why it fails. Same with a string, like you have two strings. And I'm using my hands and I don't know if the audio version won't be able to see but you have the X Back to string, A, you have the actual string, this is going to really helpful says I'm expecting this string, but I found that string there, especially if the strings are almost the same. This one character, it floods assertions will actually use little arrows above the top to show you where the difference is, for example, say with collections of cool, that kind of stuff. And, yeah, that's where we invest a lot to make that message as self explanatory as possible.

Brandon Minnick 20:30

Yeah, and that makes a lot of sense. Because yeah, I've been there. I've gotten that error, where it's like, expected this string got this string. And like you just looking at him in the console, like, yeah, it's the same string, but you don't realize maybe one has a trailing whitespace, or something silly like that. So it's all good. Thanks. Yeah, I didn't realize

Dennis Doomen 20:49

if the same string, but there's some whitespace. At the end, it'll actually shade but the other one has extra whitespace at the end, you know, that kind of stuff. And again, to be honest, this is not something we designed from scratch, it's actually, you know, by trying by contributions from external contributors. It evolved over 1314 years that I worked on, I know, 16 years already. So yeah, it worked, became better and better. I think.

Francois Bouteruche 21:16

I really love the collective intelligence, you've added to the library over the time, because to me, that sounds like collective intelligence of people using the library and saying, Oh, we couldn't improve by adding this and this.

Dennis Doomen 21:31

But that's because I practice test driven development in all my projects. And I use the library, obviously, my site actually started because I was looking for something to make my test more self explanatory. I still do, you know, if I, a lot of people talk about quality of software, and I tend to make a distinction between internal quality and external quality, to help understand managers what quality is about because if you think about software quality, external quality is typically what managers love and quality assurance engineers will look at, and what product owners look at, and if the external quality, bucks responsiveness and a UI that's not very intuitive, typically what will happen, the product owner will complain, or your manager will complain, or clients will complain. But the internal quality is about like how well can you maintain and develop that code for it in the future. And for me, that kind of breaks down I thought about this, I'm trying to always explain that to managers. The internal quality is the part that you don't see that's about testability. It's about readability. It's about how isolated Can I make a change in one side of the system without breaking the other side? It is about traceability. It is about discoverability traceability, like why was this piece of code changed? So I also look at source control, you know, did you actually capture the rational, the reason for a code change and your commit message or a pull request message? Stuff like that? Yeah, but a lot of people don't do that. discoverable. Yeah.

Brandon Minnick 23:01

That's why I'm laughing is I've not done that myself.

Francois Bouteruche 23:07

And I've, I've seen several times in my career, a point in time where manager start to care about what you've just described, but too late. Too late. Yes, it is. When you start to explain, okay, to fix this bug, it will take two days, not one day, it will take two days. But why? Because the code has not evolved in the right way, and it is a mess to fix this code.

Dennis Doomen 23:34

Yeah. Just fix it. Dude, just fix it. Yeah, but yeah, exactly. This is exactly what I'm what I was struggling and as a consultant. Although I'm not the type of consultant that just goes in for a couple of days, I'm usually at a client for a year or a couple of years to really make a change. This is a topic that comes up every time and because of that those five elements. testability is a big part of that. And testability is not just about using fluid fluid assertions, it's about you know, identifying the internal boundaries of your code base, making things testable understanding, like, what's the scope of a unit test. And again, fluid decision was one of the tiny ingredients that I was that I missed. And I started coding on that. But if you look at the unit tests that flow instruction themselves as I like to use them as a kind of an example of how I like to see unit tests in that case. So these are typically topic I don't I know, Brandon actually because we both speak at conferences. Yes. Thank you for the link. Because we both speak at conference and I typically also I don't I happen to be talking about Flint surgery a couple of times. Usually I talk about you know how to practice test driven development without shooting yourself in the foot, how to deal with lag as you go to stuff like that's, and that's how it evolved. It was just something I needed to do all the other things to accomplish the other things.

Brandon Minnick 24:57

I love that and honestly, I feel like that's where the best software comes from is when you have a need yourself. And I'm, I'm fairly selfish like that as well, where there's code, I find I'm copy pasting from repo to repo. And I'm just like, Yeah, that's great. I'll just publish it as a nougat package because I need it. And if anybody else wants to use it great. And that's how some of my libraries got started. Where, yeah, then folks start using it, it becomes a thing. But really, it was just, I needed it. And I got tired of copy pasting the code myself. So yeah, I feel like anytime you're creating something, because you found that need, and you're using that in your own project, so you're going to continue iterating it, you're going to find those rough edges and improve the software to make them better than Yeah, you end up with just this amazing library. And it's no wonder why fluid assertions have just taken off and become so popular because it's battle tested, Dennis, like, you're saying, like, you've been using it in your apps for years now. And you made it because it was a thing you needed, not just, Hey, I came up with this cool idea. It's like, you know, I came up with this cool idea, because I needed it.

Dennis Doomen 26:18

I also wanted to have other people, you know, want to make sure people benefit from that. I mean, you like me, go to conferences and talk speak to people about your your topics that you're passionate about? It's not because you're selfish, because you think other people can benefit from that. That's the same thing for me. But there's a flip side, of course, because yeah, if you put something on the internet, and it actually kicks off, you know, like, like an open source library. At some point, you don't do it for yourself anymore, because there's too many people wanting things from you. And that is obviously the flip side of open source development.

Brandon Minnick 26:55

Yep, yep. Yeah. That

Francois Bouteruche 26:57

costs a lot of time. Yeah. How do you deal with that? How do you deal?

Dennis Doomen 27:01

I don't? I'm currently no.

Brandon Minnick 27:06

It's because the discussion?

Dennis Doomen 27:08

Yeah. So it's, it's, it's, it becomes a project on itself. It becomes a project with requirements, priorities, design, challenges, maintenance, you know, you have to think about backwards compatibility, you have to be available, you actually become the architect, the team leads, the product owner, the business analyst, all of that at the same the quality assurance engineer, you become all these things. At the same time, I actually just popped into my mind, I just realized that, that you're doing all these things, because it's a project. It has timelines, you know, have people asking things from you, they issue a request, support, they suggest improvements. And if you say I liked that improvement, I liked that feature extension, then there's also this implicit expectation that you will work on that, that people actually forget that this is it's a, it's an open source project that I do next to my full time day to day job, you know, which makes it hard. And I know that a lot of open source developers are struggling with that. I mean, first they struggle, like, Okay, I want my thing to become a little bit more famous, I want to be able to use it, the people use it, but then it you know, the skill tips, the other side is okay, but now I have to support it. And I have to satisfy all these people that need it. Like with fluid assertions, which has something like three of the $30 million. Now. There's a lot of people wanting things from us, and you actually see, or we'll run into situations where people are pissed off, because you didn't like the idea. Or you decided not to accept that, you know, this is one of the topics I talk about about the conference talk is that we accepted at some point, a feature that we should never have, should never have accepted. Because, but we did accept it because we felt like Yeah, this guy actually put so much energy in it. And we know how painful that can be if you get rejected, you know, maybe we should just accept it. But then it started to, you know, backfire. And now we're trying to do that, or at least separate that feature in his own package. That's like, it's technical depth, you build a technical depth, which you have to address as well. That is the challenge of, I would say reasonably successful open source project.

Francois Bouteruche 29:24

Yeah, that's

Brandon Minnick 29:27

I'll caveat this with I don't have any open source libraries that have 300 million downloads. So congratulations. That's a huge success. Because yeah, I mean, I we're kind of a couple open source projects like my async await Best Practices library has one and a half million downloads, which is pretty impressive. A couple of seconds ago, I thought was pretty good. And I'm still leading the dotnet Maori community toolkit library, which is all open source and yeah, I think something the are probably the biggest thing I struggle With is just the folks that come in and like I said, essentially demand things when that's the right word. Yeah. When the irony is that like, it's, it's an open source project. So, yes, you can absolutely ask for a feature or a bug fix. But at the same time, what's the solution? Like, you can also come with a solution like, here's you have all the same source code I do. You can submit the fix, you can submit, even just like an API design or proposal. But yes, some folks get really rude. To put it kindly, where it's like, I can't believe you haven't fixed this yet. Or I can't believe I haven't implemented this feature yet. And, and yeah, I found, really, all I can do is just remind them say, hey, yep, I don't get paid to work on this. This is something I do for fun on nights and weekends. And same with all the other maintainers here on this library. If you have a minute and would be able to help us out, like we'd love a pull request from you, or, you know, try to nudge them and just remind them like, Hey, I'm not making any money off this, like, I, I just do this for fun. I'm just another human on the other side of the world. So yeah, what, what have you and how do you.

Dennis Doomen 31:24

So we did, at least what we tried to do is streamlined approach process. So what we did, for example, is make it very clear from the contribution guidelines, what we expect, and how you can make that contribution as smooth as possible, you can get it into the main codebase. That's one thing. The other thing is what we do is we have this process when somebody actually submits a pull request. The first thing is what we do is actually suggest that that's also what we do in the pull request template, which GitHub offers, like create an issue First, create an issue that you where you suggest your improvement, we then tag it as API suggested, then we have some discussions about like, is this what we want? Is this what we want? Does it actually make sense? Is it like consistent across the whole code base? Because yeah, it's a library. And we want it to be consistent, because we want it to be intuitive for people to use. And a lot of developers forget about that. Like, oh, we can add this method. Yeah, but wait a second, we also have to have the negative version of it, or whatever. How are we going to implement that? Also, what we do is when people create an issue, one of the items, will you be able to create a pull request to implement this feature? Yes or No? If somebody says yes, you know, and they follow the guidelines, and we use Roslin analyzers and editor configs, to make sure that we don't even have to spend time on you know, the layout is not correct or something, we introduced a lot of things over the years in the build pipeline, even even spell checking that the documentation you write is correctly correct English and stuff like that. If you create a new feature, the website, the documentation website, flew the search.com is actually part of the code base. So you can actually create a pull request with a new feature. And also include the actual documentation for that with examples, release notes. So we tried to streamline that preparation. The good thing is I'm not also using all these ideas in my clients projects where we try to adopt this whole inner sourcing thing. But in the end, there will still be situations where we really don't want to feature, we have a Slack account. And we sometimes have to use the slack account to to start a discussion with somebody like you know what, we really appreciate what you're trying to do. And we understand your point. But sometimes we have to make a decision, like an architect has to do sometimes, you know, yeah, there's different area, different perspectives, different different opinions. Sometimes somebody has to put, you know, the fist on the table and say, Guys, girls, we talked, we talked a lot about that. There's reasons we made some decisions. We're not going to do this, are we actually going to do this? Are we going left or right? Exactly like influenza? Same thing. And I know some open source developers that actually got burned out because of this. Because there was so much demands from the community to do things where they actually at some point, like abandoned the whole project. That's not a good thing, either. So that's a that's a challenge. I guess. I'm lucky. I have a good companion or Jonas nyrup. He lives in Denmark, he has been helping me with for the last four or five years is very, very critical. spends a lot of time and we have pretty like a pretty great big group of contributors that help us. So that's a good thing. But we're lucky.

Brandon Minnick 34:45

That's fantastic. And that's something that it pains me to I've been in that similar situation where somebody's already done a ton of work, they've opened up the pull request and you know what, what they're asking for is essentially done, but at the same time, it It's, it doesn't fit. Or it's maybe just not the right way to architect it, maybe not the right way to do it. And so like, the idea is still good. We want to do it. But actually, we should have done it like this. And yeah, you feel terrible, closing that poll request, because you can just see the hours that they've put in and isn't even their library. They've gone through just the effort alone of forking and cloning and learning your codebase. And like that, in itself, before even implementing new features a ton of work. So yeah, I don't know what the solution is. But what I've done for the Dennett Valley committee toolkit is I copied this from the C sharp, the actual C sharp repo, where we've set I've set up this workflow where it's, you first, open a proposal for adding a new feature. So show us the API design, like what's the intent behind it. And that way we can, we can chat about what it is first, and hopefully save you the time from having to then close a PR that maybe like, this is a great idea. But we should have implemented it this way. Or, actually, that doesn't fit in with what we're trying to do here. You actually want this other repo over here. So yeah, it's, it's one of the toughest things first, because we're chatting earlier, there's more folks demanding things, and there are folks contributing. So when you get somebody who actually does contribute, you want to nurture that experience, and hopefully, they will contribute again. But yeah, sometimes you just have to close it, and you feel like just a terrible person.

Dennis Doomen 36:52

And but what you just suggested what you just told us exactly what we do as well, you know, to prevent people from creating pull requests. And it's also about like, what do you get in return from it? Because some people say, like, why can't we get money for the open source? Like the work that we do? And that's, that's tricky. That's difficult, because on one hand, you're getting some sponsors. You know, getup has been very good at facilitating this is awesome, you know, review saw that, for example, to develop a few GS II earns quite a little money purely through sponsoring, you can probably, I think he gave up his day job already a couple of years ago, because he gets so much money. But it's still an open source project, I have a day job. And it's great to get some money in return. But that was never the goal. I mean, in the end, it was just to contribute to the community. Yeah, it won't give you money immediately, but will give you some kind of recognition. I mean, I can I can speak for myself. And I'm probably here because I spoke at NDC. And why did I speak at NEC, I guess, because desertion became like was was such a became such a big thing. All of that becomes part of that and kind of, is a way to become more more visible. And I have to admit, if I go to clients, and I can see I see that they're already using it, you know, everywhere. Of course, that's awesome. That's, that's probably the biggest, that's probably even Yeah, I would say, the most important or not the most important thing with the nicest thing to hear that, to see that they actually use it everywhere. Or I had ones that I had, like, I was working for a client, and they had a job applicant applicant guy coming in, all the way from the other side of the world. And they actually wanted to see me to thank me fluid searches. I don't even know how to respond to that, like

Brandon Minnick 38:39

thank you. Yeah, it's like, back to your resume.

Dennis Doomen 38:46

But you must have the same thing, right? If you if somebody you know, appreciate something you've done. That's that's all we need, right to get going to feel the appreciation.

Brandon Minnick 38:55

Yeah, that's, that's the best. I love that when it was like, I just want to say thank you use your library and my apps and means a lot to me, and thanks for continuing to support it and maintain it. But, ya know, I'm in a similar boat, Dennis, where? Yeah, I would love to make money off of all the work we do in open source. Yeah, I easily put in 10 to 20 hours a week, just maintaining open source projects. But But yeah, no, I agree it, it's kind of become it's a conduit to improve improving, improving yourself as a developer improving your career. You, if the open source project does take off, you will get some name recognition from that. And while you might, well we might not benefit directly from it like, Yes, you said GitHub sponsors, and yes, I have one sponsor and I get some like five bucks a month, which is great. But I can't quit my day job. But But yeah, at the same time, the opportunities that I'd open up then the folks that like said they just want to hear you speak now, because you have an open source project until.

Dennis Doomen 40:12

Like, last year, we, my client of my employer solutions, we were we had a little stand at the tech Rama Conference, which is a pretty big thing in Europe these days. And as a kind of a gig, we create a T shirts, fluids such as T shirts. And we like Chechi party actually generate the theme because the theme of tech Rama was the jungle. So we tried to you know, have to get up at generate, like taglines with jungle and fluid assertions in it. That's pretty funny, actually. And we create a T shirts with like the I mean, nobody wants these features. I mean, who wants a t shirt, the fluid surgeons, like within a couple of hours, they're all gone. And now I have people at NEC, asking like, Oh, do you have these T shirts? At some point? We'd love to have them. You know, it's, it's incredible as

Francois Bouteruche 41:02

we can predict, or?

Dennis Doomen 41:04

Yeah, it's, yeah, apparently it's a thing. It's a thing. But you could say the same thing about nougats. You know, you can say Phil hack actually did a great job introducing nougat to the world, it made a huge difference. Same with Get up, get up actually changed the way software development works for me, you know, and whatever you can say about the all the options, but get up actually, the whole pool quest thing, that was a big deal. And only when I moved from CodePlex to get up things started to you know, change, because it became obvious for people to contribute before that, remember, maybe batch files, you know, in a batch in the past, you had to use a batch file that contained a Delta of the change files. It was really Oh, yeah, you don't even remember that this

Brandon Minnick 41:49

is not a complex thing. Or like, it's

Dennis Doomen 41:51

complex thing. It was also a Linux thing. You could take two files and generate a batch file. You know, not the batch file, but the batch like ba ba DHCP. Yeah. And if people want to contribute, they could upload the patch file, then I had to manually manually apply the patch like, okay, come on. So yeah, it gets it was definitely, I would say, the big instigator that are the catalyst that made all this possible. Next thing you get, of course, yeah.

Brandon Minnick 42:25

Definitely, definitely. So that's I know, we've been talking about fluent assertions for a while now. But before the show, we were chatting about all the amazing things you do. And you mentioned to us a couple other topics on like, specifically, continuous improver.com, C, sharp coding guidelines.com, want to make sure we cover everything, although, we'd love to have you back for round two, and talk about even more amazing projects you work on. But uh, yeah, tell us a little bit more about continuous improver.com.

Dennis Doomen 42:54

It's, it's not really much. It's just my blog. And a couple of years ago, I read a book called soft skills, which I don't have no, just kidding. It's written by John summers. And it is a book that actually talks about Yeah, literally, with the title and soft skills. And one of the things that the book actually tries to suggest is that you come up with some kind of niche, you know, that that that identifies you that you actually like, or maybe some model to do to make you stand out from the rest? And I thought, like, yeah, what is the thing I'm doing? Well, I have, I have a little stupid little library. But that doesn't define me. And what defines me is the fact that I'm always looking for ways to do things better. I mean, that's why I go to conferences, not just to speak, but also to, you know, to talk to people exchange ideas, learn from other people. So at some point, I thought, like, okay, maybe I'm the continuous improve, I'm always continuously looking for new ways to do things, better new techniques, new tools, new architectures, you know, on the cultural level on the team, organization, all of that. And that's, that's what it is. And I try to share my experience there. Usually, when I come up with a presentation or conference talks, or you should also write blog post about that, where I tried to capture these things. And it's also a way for me, and that's also what I like about blogging both publicly as well as internally. It's a nice way to funnel my thoughts, you know, you have lots of stuff going on. And trying to write that down into a comprehensive story is very powerful, because it forces you to structure all these thoughts in your brain and trying to make it the make it in the nice integrated story. And that's what also and also from my past, I regularly run into blog posts on the past and I remember like, wow, I don't even remember I wrote that, but it's actually pretty nice. I should have followed that. So that's what's continuous improvement. It's just my blog, where I share everything around, tools, techniques, practices, everything if I go to I'd love to go to Q calm, which a big conference in various parts of the country. It's completely different from, for example, Microsoft conference because they talk about what GitHub did to scale the platform, or what LinkedIn they did to keep company, the company interesting for people like, I do grow people that stuff like that. And also about all this stuff that I learned, I tried to write it down for my future self. As a reminder, there's a lot of stuff that I wrote about just stuff that I learned. Sometimes a very inspired that sometimes I don't know.

Brandon Minnick 45:38

I love that I, I, I've forgotten things that I've blogged about. And you google them later. And you come across your own blog post or your own StackOverflow answer like, oh, yeah, this is exactly what I needed.

Dennis Doomen 45:55

to jog your memory. Yeah. Right. Yes, of course. Yeah. And if other people benefit from that, that's, that's a plus. Right?

Brandon Minnick 46:04

Yeah, absolutely. Yeah.

Francois Bouteruche 46:06

And I hope we will continue to, to have many people writing blog posts, because personally, I think I take a lot of value of reading those blog posts. And it is really worth I really encourage, especially new developers to, to find some blog posts to blogs to follow and learn from from them, especially when you are an early stage of your careers, Evan, Evan after but even more at the early stage of your career, it's it really helps you to build your path to learn from others to learn from different experience perspective. It is, it is really important. Sometimes, I love video content for getting started. When you want to go deep into a topic, a good blog post, well written is really worse. So I really encourage everyone to continue to write but personally, I'm a bit worried about the fact that we, we stopped doing so because there is a AI coding companion or AI, Assistant, author, every every question. But we have to remember that they are fueled by what we write. So we need to continue to write.

Dennis Doomen 47:36

It's also like, I like I like reading, and I like writing. But there's of course, a whole generation now that actually only loves to watch videos. And they have an attention span of like, I don't know, 30 seconds. I'm struggling with that as well. Because creating videos, you know, is a lot more work than in creative writing. Especially to keep it appealing. Yeah. I mean, you probably know better than me. But I see these people creating blog posts or videos about all kinds of stuff. What's his name? The I think he's Mexican guy or something. He's very popular these days. He was also at NEC a couple of times. I forget his name.

Brandon Minnick 48:15

There's new chaps. This is probably yes.

Dennis Doomen 48:18

Yeah, exactly. Like, just imagine how much time you have to spend on the Create a video every day or something like that. That's ridiculous. But also doing demos live Amisha demos needs to be perfect. That's like a presentation. Right? And I guess you both me and Brendan, I don't know about Francois knows, like how much time it will take you to do a presentation. Oh, he lives in London. Now. I didn't

Brandon Minnick 48:43

know. Nick's originally, Greek and he lives in Greek.

Dennis Doomen 48:48

I thought they were from Mexico or something. Yeah, no, I the

Brandon Minnick 48:51

first time I hung out with Nick has, I just can't place your accent. And he's obviously super fluent in English, because he lives in London. But yeah, it's that mix of Greek in ah,

Dennis Doomen 49:04

I didn't know that. I thought this guy flew all the way from Mexico or something to London. Okay. But it's awesome. Because it also attracts a different kind of audience. You have you have different kinds of people that consume knowledge and different ways of doing it. Now I'm just not patient enough to watch a video. I was just put it on the you know, 1.5 speed or something. Podcasts broadcast Yeah, maybe in a car. If I have a long trip, but working from home so much. I I find it difficult to do that. But everybody has different ways of learning. And we need to accommodate for everybody, right? Yep, definitely.

Brandon Minnick 49:46

Yeah, absolutely. And, and yeah, you know, I was struck with my wife the other day because she's starting to make videos now too. And, you know, you you'll run into the same problem as you start making videos yourself where it's just Yeah, you realize how much work goes into it. And I told her I was like, yeah, no, I spent the whole day yesterday working on a five minute video. Five minutes. And but what that really entails is, yeah, you got to get everything set up. So you have your like your little studio and make sure your video is good and your sounds good. And then you got to script it out and then all the editing and, you know, it's it's so much work that you don't you don't see? Because yeah, you just see the on screen video. And like, five minutes. What do you mean, that took you a whole day? It's like, oh, there's a lot that goes into it.

Dennis Doomen 50:42

Yeah, what's the return of investment of that? I mean, I don't have the whole day I'm working. I have a full day, full day job. I have open source projects, I have a blog, I have a life, I have a family. I also like to play games, you know, my PC, once every while in a month we have we have the new risin forbidden West coming out on the PC. While don't expect any features in fluid assertions in this, you know, it's always about sometimes you're just fed up with it, sometimes your energy is drained, or your days you have spent so much time and energy and your your work your day job. I just want to sit on the couch, watch TV, you know, TV series, or movie or whatever. That's the reality. You know, it's not a job. It's not a job. How did we get here? Because we went off track completely I

Brandon Minnick 51:39

think it was it all stemmed from the continuous improver conversation. But speaking of which, C sharp coding guidelines.com, we've got another awesome resource that you shared with us. I'm looking at it now. And just the first paragraph says what is this? It says it's a document that attempts to provide guidelines or coding standards for all versions of sheet of C sharp. So yeah, tell us more about code, C sharp coding guidelines.com. And that's C sharp spelled out. So C. ARP coding guidelines stack is literally what it is.

Dennis Doomen 52:17

It is got like, when I when I start a program with C Sharp 20 years ago, I worked for a company and they had like a C++ standard. And at some point, we felt like it could be beneficial to have something similar for C sharp. And I mean, there were a lot of things that you can do wrong at that time, it talks about like, if you implement IDisposable, you have to call dispose. Because we didn't have an alias Roslyn analyzers that did that for you. We didn't have Resharper yet, or writer at that time to you know, help you make those mistakes. But it also basic object oriented principles and over the years, and it exists for like 20 years now. We've ripped out things which are completely obvious we introduced elements like when do I believe you should use for a why I believe you should not use an underscore for private fields, which can be almost like a religious debate, yes.

But it's just a collection of what I would say what I personally would think best practices that I follow myself, trying to encourage you in the proper application of C sharp. But it also comes with the roster analyzer created by Boyd Kumar was a contributor who created actually his own analyzers to help you detect certain things. And yeah, it's something you can use or you don't you don't use the cool thing about the C sharp coding guidelines of calm, it's actually a good upside that you can fork and adopt for your own company. So if you want your own guidelines, and there's always some architect that wants this, you can actually take that and fork it and adjust it for your needs, and publish it internally. That's the whole idea, actually, it can generate a PDF, or you have a cheat sheet, which is like a one a4. And some people hate this stuff. You know, I'd be notorious for my coding guidelines. But I still see value that becomes less and less, you know, with all these great rosin analyzers, but still, yeah, it's, you know, I would suggest just read them. Build your own opinion, disagree or agree or fork them or whatever you want. That's the whole point. That's the whole point.

Brandon Minnick 54:32

Yeah, I love that because that's something I, I do on every pull request that comes in to say that data Maori community toolkit or async, await best practices. Yeah, I have a set a coding guidelines that we asked you to follow. But at the end of the day, not everybody does not ever implement it. So I always kind of come in and you're kind of like the The cleanup guy or like the janitor, that it's not changing any functionality, but just rearranging things and like you said, maybe editing some variable names to make them more descriptive or adding or removing an underscore from from a field. And yeah, you just kind of hit me that. Why don't why don't I have an analyzer that does that.

Dennis Doomen 55:22

Actually go will be fast, you don't have to actually talk to, you know, complain to people about particular thing. On a pull request, you have the wrestling analyzer already giving you early feedback, right? That's the value of that. Yeah. And

Brandon Minnick 55:34

that's something we mentioned NDC, which, if you haven't heard of NDC, it's an amazing conference, you go to NDC conference, NDC conferences.com. And they've got conferences in London and Sydney. And I was just in Dennis and I were both in the one in Sydney. And actually, all three of us were at in London. But in Sydney, David Fowler, Damien Edwards, were there. Yeah, and they were talking about how the newer versions C sharp come out and actually met Mads as their mentor Goodson, the the pm for C sharp and how every year, you could argue C sharp gets more complicated because they add new features. But at the same time, it's modernizing C sharp. So you know, pattern matching was a huge thing that came out, and oh, yeah, with that log way of saying, what they're doing now is using analyzers to kind of nudge us in that direction. Because for the longest time, these new features have been coming out. And I love it. So I always read all the release notes and immediately add in the new C Sharp 12 features to my apps, but a lot of folks don't. And how do you discover those? And how do you do this all without breaking changes, you know, breaking that old dotnet C sharp code we wrote years ago, and yeah, they're using analyzers to get it, you know, give me a suggestion, maybe give, maybe give you a warning that you could do this better. Or there's a more succinct way of writing this code to nudge in that direction. So lots of great use uses for analyzers. So Dennis, we've only got about two minutes left, because there's another show coming on at the top of the hour. So we get kicked off whether we end the show or not. But before we do, this has been an amazing conversation. So thank you for coming on. But for folks who want to continue the conversation with you, where where can they find you?

Dennis Doomen 57:31

Well, I'm on Twitter, I'm on Mastodon, I'm on blue sky. You can also join the free decision slack, if you want to, you can email me email me. There's so many different channels, you can reach me. I love to talk about my work. I'd love to talk about TDD about architecture about event sourcing. All the other topics. There's so much stuff I love to talk about. And yeah, I guess you will share the all the different URLs where you can reach me. LinkedIn obviously. Yeah, I'm everywhere.

Brandon Minnick 58:03

Got it? And is are you d Duman. Everywhere. So d D o m e n? No,

Dennis Doomen 58:10

I'm actually Oh, that's nice question. I'll drop it in the show notes. Yes. There's a couple of different I guess that I don't actually know for sure what different names are but the Duma is definitely on the on Twitter, X.

Brandon Minnick 58:28

I'll drop them later on. Right. And we'll we'll grab those, we'll add them to the show notes. But, Dennis, again, thank you so much for joining us. It's always amazing having these conversations with folks like yourself who have been in the trenches contributing to the community creating open source libraries for years now. There's so much we can learn from you. I know. I'll be subscribing to continuous improver.com To stay up to date with the latest and greatest. But thanks again so much for joining us. And thank you for coming here and joining us today. We'll be back every other week. Don't forget to subscribe to our audio podcast and the Twitch stream. Make sure you never miss an episode. And we'll see you again in two weeks.