Fluent Assertions with Dennis Doomen - podcast episode cover

Fluent Assertions with Dennis Doomen

Jul 13, 202359 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

What can we do to make testing easier? Carl and Richard talk to Dennis Doomen about Fluent Assertions, an open-source set of extension methods to help write better tests. Dennis talks about working on Fluent Assertions for over a decade and the great team of folks that have helped it grow. With tens of millions of downloads, you should check it out! The conversation also digs into how these types of open-source projects don't make money, even though they help many people. Could we fix that?

Transcript

How'd you like to listen to dot net Rocks 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 will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Copenhagen is

happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. The Early Bird Discouver DC Porto ends July twenty first. Go to Dcporto dot com to register and check out the full lineup of conferences at NDC Conferences dot com. Hey there, this is Jeff Fritz, the purple bloa guy from Microsoft,

letting you in on a little secret about my friend Carl Franklin. You know, the guy who started dot net Rocks, the first podcast about dot net in two thousand and two. The guy who's been teaching Blazer on YouTube since twenty twenty. Yeah, that Carl Franklin. Well, Carl's joined up with the folks from Code in a Castle to teach a week long hands on Blazer class. Are you ready to get this? At a castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer learning built in.

Carl's calling it the Blazer master Class. You'll learn Blazer from the ground up, finishing the week with the ability to build and deploy Blazer applications. Since the training happens for only four hours in the morning over six days, you can bring your significant other, your partner with you and you should right This part of Italy is absolutely beautiful. There's so much to see and do and in Larion Marco from Code into Castle are organizing daily activities both at the castle

and in the area. The castle is in the Marema, a less touristed region of Tuscany, offering both classic Tuscan hill country as well as easy access to the Etruscan Riviera, with sublime local food, wine and olive oil around every corner. Breakfast is included every day. There will be two communal dinners at the castle book ending the experience, and most other meals and all activities are included. And did I mention you'll learn Blazer in person from Carl Franklin.

Listen, space is limited and for very good reason. This is quality training in a beautiful setting. Go to code in Acastle dot com slash Blazer twenty twenty three that's bla z o R two zero two three to take advantage of this amazing opportun tunity to join Carl in Tuscany for an unforgettable week of La dolce vita while advancing your programming skills in this important new technology. Hey guess what, it's dot net rocks again. I'm Carl Franklin, and I'm

Richard Cabell and Dennis Stouman is here. We're gonna be talking about all sorts of cool stuff but affluent assertions, I believe. But how are you, my friend, doing well? You know what we're doing. We're selling house, no kidding, Yeah, it's time the house in town, not the city, each house. Wow. The house we selected because it was near

good schools and then you know, built it and all that stuff. But it's been twenty five years, and yeah, you know, the girls are growing gone and it's time to downsize a bit, and I want to spend more time on the coast. That's good. Do you and at the host house, did you add like the waterfall tub filling and the Japanese toilet sea and all the things I remember about your house? Yeah? No, no,

no, that'll come later. In fact, as soon as we started having the conversation about selling the house, who's already a conversation about building something new. So I wouldn't be the least bit surprised to see those kirts of features up here. Do you have land up on the coast house to build something small that you could actually live in? Two and a half acres? Yeah? Yeah, good, we have space. That's cool. Yeah, I love it. Make a tree house because it's surrounded by woods, right

yeah, yeah, we're fully in the forest. But you know, I think that'd be so cool. I think I need something that can actually get a permit for, and that's going to be a little tricky, so well permit schmermit. Yeah, what is this whole safety thing? What do you you know? Yeah? All right, who does that? Who does that? All? Right, let's roll the crazy music, because I have something

cool for you for a better no framework awesome? All right, man, when you got well about trying to do the math here this is coming out on July thirteenth, and a good month and a half ago, I did a Blazer Train episode called Blazer is the New forty two. Okay, and those of you who have read Hitchhiker's Guide to the Galaxy know exactly what I'm talking about. A year old. Yes, I'm old. Yeah, I remember when I was forty two and I thought I was the answer to everything.

But apparently apparently I was wrong. Yeah, aren't we all? Well anyway, So the whole idea is that, you know, Blazer is a

component model can go anywhere. Now it can It can not only go to well we know it goes to websites in browsers, but it can go to you can use it for MAUI, so it can go to iOS applications and Android applications and if you're crazy, ties in TVs and things like that, macdesktop apps, but it can all you can also build WPF and Windows Forms apps with it, and so that that's the whole ideas that you know, the whole promise of Zammal was that it would be this ubiquitous thing, and

and it turned out to be completely untrue. There's at least seven or eight flavors of Zammal they used to be anyway. I mean, that's slowly cleaning that up. There were there were many forces at work there that cause that fragmentation, right. But if you think of what Microsoft's job is to with Zamal, it's to implement the behavior and look and feel of what Zamil does uh consistently on every platform. And it's not there yet. I'm just I'm

telling you the truth. It's even with Maui it's not there. Yeah, they never got to that part of the mission. But clearly that is the effort of products like Maui's finally after all these years, Yeah, that is the effort. But but a similar effort was done with the browser manufacturers, right to make sure that Htmail CSS and JavaScript performed and looked and acted the same on all of the browsers. And they've pretty much and that didn't work

either. Well, okay, well they're a lot farther along than then Microsoft, as exampled, they're having to do by themselves what all these browser manufacturers had to do with the browser. Yeah, one of would argue, that's an easier problem than running if safari code. Yeah, yeah, exactly. So anyway, it's a Blazer Train episode and the link is to a GitHub repo that explains everything, gives you code that you can copy and paste and

cut and paste into all these different projects. It's cool, Yeah, it's fun. Yeah, Blazery is the new forty two. Yeah, Blazer's new forty two. So who's talking to us? Richard grabbed commonhov A show seventeen thirty five. We get back in twenty twenty one with our friend Ian Cooper. We're talking about test driven development and testing as a whole, and actually lots of good comments on this show. Was one of those powerful conversations,

and Ryan said this. He says, what to test is a strategic topic. It depends on the risk profile. What is the cost of failure to the business that is financial, reputational, or opportunity? Is the code likely to be extended? Who'll be working with this code so many months from now? When I'm writing tests, I'm thinking how much production code can I get away with while keeping the sweet fast and comprehensible. If I get it right, it hits a sweet spot where I have a high level test API that

facilitates implementing changes as things evolve. Only certain types of modules get the full treatment business critical, complicated, dynamic requirements. Setting up this kind of test suite short and takes a lot of effort, but it pays off in a long run. And I also appreciate this sort of point here that if I know this is going to continue to be worked on and likely not by me, then build out a big test framework to make it easy for the folks

to handle it. But don't write tests for absolutely everything. And it's hard to argue about that. You know, we get a little fixated on one hundred percent test coverage thing, which is essentially to be strategic about thinking about you're testing him. I think it's smart, Ryan, good thinking. So Ryan, thank you so much your comment, and a copy of Ustic Coby is on its way to you. And if you'd like a copy Abustic co buy, 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 everybody in the show, we'll like your copy of mused to go buy and you should definitely think about following us on macedon. Twitter's fine, but the fun stuff and the cool kids are over Macedon. I'm at Carl Franklin at TecHub dot social, and I'm rich Campbell at Mastodon dot social and send us a too. We'll be waiting up for it. M mmm. So

let's bring on Dennis Duman. He's a Microsoft MVP and principal consultant at Dutch Microsoft consultancy firm of Vivas Solutions. We have twenty six years of experience under his belt as a software architect and lead developer. He specializes in designing full stack enterprise solutions based on dot net, as well as providing coaching on all aspects of designing, building, document deploying, and maintaining software systems in an

agile world. He is the author of Fluent Assertions, an assertion library to make your unit tests look great. Also Liquid Projections, a set of libraries for building events sourcing projections. And he's been maintaining coding guidelines for c Sharp since two thousand and one. Hey, Richard, that's a whole year before our podcast started. That's before c Sharp shipped. Yeah. You can find Dennis on Twitter, Mastodon, and Blue Sky. A Blue Sky is the

one I just learned about yesterday, right, that's right. Yeah, okay, Well, welcome Dennis. Thank you. It's an honor to be here. Finally. Oh, I'm looking forward to a great conversation. You've certainly got a lot of experience. You're you're old like us, not quite as old as old, almost as old. Yeah, true, Yeah, we had that discussion before we started, exactly. That was pretty awesome to be here, and I'm looking forward to what you're being exchanging here. Ye,

So fluent assertions. This is a testing work, not exactly. It's not like a competition to actually unit or an unit. And don't start me talking about amostest. No, it's a it's a very it's it's basically a tiny library to make your assertions look nicer. It's basically fluent affluent syntax. For you know, some variable should be equivalent to some object graph or an action or funk in c shops should throw an exception or an a sync exception.

That's cool. Stuff like that. It's very simple, honestly, but for some reason it got a lot of traction over the last twelve thirty years. Well, it's it's more accurate than what we're doing now, you know, which is naming testing methods, and what if you get those names wrong? What if the test changes of what it does and now you're going to change the name of it. You know, It's it makes sense, although that doesn't replace good naming, yes, because honestly, I also believe that.

I mean, I'm a big fan of test driven development and which Ward was just talking about one hundred percent, which are completely agree. It's it's completely unrealistic and it's it's it's a goal that you don't want to achieve. I would say, if you actually practice stiff development, getting ninety percent should be pretty trivial. Flu Dessertion itself has ninety seven percent, but that's not that

difficult. A very simple library with a simple API doesn't have complicated dependencies like real world codebases have, so it's completely obvious, and we use mutation testing and all kinds of stuff to really make it fully covered. But it's just because we want to be able to ship any release without even doing any manual testing, which we still don't do. Honestly, he's sticking with automated testing as much as possible. Yes, I mean the other part around this,

and I think this is associated with what Ryan was saying. Was it like those last few percentage points are also tested or perpetually breaking, Like it's code that was growlly in the first place, so it's hard to test, and so as changes are made to it, you're having tough time with the testing. Even though it's maybe functional, it's just the testing framework around it isn't

happy. True. On the other hand, I also see that the technology that we have makes it a lot easier to test things like remember like in the past when we did a speed on net controllers, and I still see that. By the way, these people actually create a test that creates an instance of that controller class and then calls the methods, which for me is like, wait a second, that's an implementation detail. So now actually it's

not even now. We even had that with Owen. If you remember that from the past, sure, yeah, test host build or a web host build, always forget which one it is. You can now test your entire HTP pipeline, you know, send HTOP requests to your test or to your actual code which includes everything even your startup class and all your d I registrations.

So it becomes a lot easier to do. And if I make comment on that as well, if you look at other areas where typically people were struggling to get full test coverage, was stuff interacts interacts with the database, right, I mean, yeah, we were all taught I don't know, twenty years ago. Isolate the ugly stuff, you know, create repository abstractions and stuff like that, and then people start creating tests for classes that barely

do anything. Right now, we can just run sequel server or something in a Linux container and you know, start up to go. You have test containers for the net, which is a beautiful little library as well. You start Sequel serving your test suite, you run your tests, even create test data in the database, you interact with it. You you even cover all your ef core or whatever orm you prefer to use. So it becomes easier,

a lot easier these days. To get to that point. It's not a goal, it's a means to an end, right, but yeah, it does. It's interesting. Do you make that point that what's making is a lot more feasible is better and better tooling exactly? Yeah, Yeah, So if you ever run into a case where something just couldn't be tested, that could couldn't be re architected so it could be tested. No, that's a good question. But the thing is one of my one of my jobs

is to actually help clients with legacy codebases to make it more testable. Right, And that actually means that I'm looking at that code base and trying to figure out how can we make that more testable. One of the ways that I usually start with, and I didn't come up with idea myself. Michael Fellows came up with that idea in his brilliant book. I think it's called

working effectively with legacy code y characteristics tests. You know, you basically create a bunch of very ugly, unmaintainable you know you don't care about that, that suite that just repeats the behavior of the current system, including a database or whatever you have which is your temporary safety net. And then you start to identify, you know, pieces of your codebase that you can refact them. Maybe you can identify things that are being reused, you know that shouldn't

be reused. Maybe by duplicating some code you can actually remove some coupling and a code base, maybe you can imply things. I mean, I know that solid is a term that can be debate about. It's a lot of people that have opinions about that. But the the dependency in version principle actually like it. It's a nice tool and it's nothing more than that. A tool that helps me the couple you know, parts of the code base from

each other. But it's a big investment. It's it's you know, I use tools to create an architecture diagram of the code based trying to understand how things is, how things are connected. I look at the dependency graph, you're basically what is the word unraveling or and I think the word you want is unfu I wasn't sure you can actually say that. You could say whatever you want, it'll be believed. But a decoupling, I think it's what

you're looking for. Yeah, but it's like you have this this intertroned spaghetti code base, and what you're trying to do is you're trying to take every individual strain detan trying to Yeah, de tangle, that's the word I was looking at. Of course, named to the Disney movie Tangled, Who Knew? Who Knew? Disney was in the software deal ball. Yeah, I'm

Dutch. You can hear that from my accent. But as a lot of English terms titles of books, of series and movies, it's just the English term until you start to literally translate in your brain and then you think that's really stupid. Even star Wise is kind of stupid in that. By the way, I don't remember if we were talking about Freakindal before we started and bitter Balling, but I think it's before we started recording. But you know,

I spend a little time ragging on that. But you know, there is no better cheese than eat them, you know, yes, yeah, yeah, yeah, honestly. Yeah. You know, Dutch people actually the worst in all the cultural things. They don't walk in wooded shoes. They don't know where all the fancy places and the needlands are. You need to be an expat to actually, you know, visit all these places. Okay, were we talking about flu in assert I think we were. We were

trying to get there. It might have just been me. I don't know, No, So, yeah, it started tirteen years ago and I just checked it has two hundred and fifty one million downloads on new Gats Honestly, I have no clue. I have no clue why people are using it everybody that I mean, I go to conferences these days, I speak about completely different topics architecture, and then people say, oh, you're the guy that

created a fluent thank you for that. You've made my life, you know, much better, Like, oh, okay, I still don't know how to respond to that. Yeah, I think, yeah, thank you, the only thing you can really say. Yeah, yeah, Basically, I hope you enjoy it. If you have feedback, let me know what we can do about it, you know, create an issue if you like it, right, that's that's great, That's what I was hoping for. Indeed. Indeed, so it's fluent assertion something that you use in your test code

as well? Or is it just on attributes that for testing methods? How how exactly do you use it? Oh? No, it's it's actually an extension method which is called shoot as you can expect, okay, and that basically exposes a bunch of methods like it should be true, should be empty,

should contain stuff like that. So extension methods for for all basic types basically yeah, yeah, yeah, collections and let's even support for data set, which was a mistake because a contributor used uh and we were we were afraid to say yes, indeed no, But that's essentially what it is. It's just surprising how much time you have to spend on maintaining a code base like that that's popular, Like people always come up with niche IDs. You

have to be you know, backwards compatible. I'm really and by the way, I just want to give some kudos to my person that spent the last three years maintaining as well, you know us in Europe UM. But we work together and we tried to keep the whole API consistent. We tried to support all the frameworks, you know, make sure the code itself is test

it and it's actually example code. We practice test different ephilement our selves at NDC also even talked about like all the little tools and practices that we use to maintain that library, which to my own surprise was like, there's actually quite a lot we do to make it great. It's almost like a real project. So do you have almost like it's a real project. So getting back to the extension method thing, you have extension method for objects, so

it just works everywhere. So having your own models, you could say that should you know, you can do actually should be equivalent too. Yeah, and then you can pass in another object and what it will do it will treat that object as a truth. So you can also pass an anonymous object anonymous type. Sure, one, yeah and one. It's actually there's a design principle behind that, because I believe that in your unit test or automated

test, every test should have one purpose. So if you have some kind of object like subject or the test that has a bunch of property, but for that particular test you only care about, for example, two properties, then you can say it should be equivalent to create anonymous type only mentioned the two properties and those will be compared. The rest will be ignored, which

I use a lot for HTP based testing for example. Yeah, I remember before I discovered tricks like that, having to implement iclonable, you know, to make copies of the object just to test and to see you know this is that yeah yeah, yeah, And like it's also recursive, so it's a bit too smart, you know. It started with a simple thing, but this is equivalent too, does a kind of recursive analysis. It tries

to understand how to treat records and two poles and dictionaries. You know, if the dictionary contains the same keys and the values in those dictionaries are equivalent, it will also satisfy the assertion that you can completely twigg that. Well, that's one of the features that kind of exploded and became maybe became too powerful to be honest. Well, but I noticed you didn't say it uses

AI because the new Hi Fi of the fifties. Well, actually you can ask chet Cheapt to rewrite your test using fluids socitions and we'll do that for you. Well that's GPT. But yeah, I just hate it that I was listening to the radio this morning and there was some ad for some technology thing and they're saying, you know, now with AI, it's like, you know everything is AI now. Yeah, correct, everybody's trying to it's

big, one, big marketing thing. It's totally marketing thing. They Yeah, they went down to the home the home maintenance center, and they bought themselves a spray can at AI and they're squirting on everything. There you go, I just draw out the letters. It's got AI on it lows minards all that pick one. Uh, it's kind of astonishing. Like I was just poking on the good Hubb pods where I realized, like, you guys have been on good hubs. It's twenty ten, that's before it was cool.

Um, I think we just we we jumped from cod plaques to get Up just in time. Oh I see Coplex. Yeah I did. I did even I mean my Jonas didn't join by them, but I was doing this alone. But I think it started as in some kind of internal project. Then I moved into Coplex, which was kind of difficult to work with because if people want to contribute, they had to deliver a patch file like

yeah, it didn't work. Yeah. And then at some point I remember there was an option to confer it because it was basically team Foundation service under the hoods right, right, and they built some kind of feature that you can send an email to the Coplex team, say, can you confer this

GIT. That was basically when I started doing GIT. Yeah, and then get Up came and then you know, everything changes pool Quest and it didn't yeah, and now it's we barely keep up with all the pool request reviews that we get and the issue reports and the feature request and right, that's the flip side of being successful I would. I'm sure, I don't want to use the word successful, but I think that's fairly. Fifteen one million

downloads is pretty much qualifying you to be successful. Yeah, yeah, sure, well and still you know, like you look at the stats on the project, you go, this is a healthy open source project, like regular contributions, lots of people working on it, lots of issues, like it's a busy project. Your pull requests are pretty under control. Friend, at this particular moment, there are eight and they have real conversations attached to them.

This is not this blind code going in m That's true. It's costing me a lot of time, yea, Janus as well. Unfortunately you want to spend a bit more time on it. I also do a lot of talks and stuff around that, which consumes sometime about that. But yeah, it's I'm very happy with it. Good jobs just to yeah, yeah, thank you, Joan Us. That's something kind. It's funny because I actually

met him at the NBC for the first time in my life. Who like, literally, wow, collaborated remotely for three years, four years, three years, four years, and now you finally face to face with NDC Oslow. Yeah, indeed, it's it's like, yeah, indeed, that was really interesting. It was a great experience to finally meet the guy. And this was not the only There was another project from Jeremy Miller Marten, and he also met his major contributor for the first time in person. Actually,

I met Jeremy for the first time, which was also nice. It's cool. Yeah, yeah, all these folks that you've communicated with for years and years and you just don't actually get this whole in person thing. You know, we didn't do it for a couple of years, and now we can kind of like, hey, it's a feature true. Yeah, wow, yeah, I mean it's a lot. We could spend a lot of time to dig in through fluent, but I think you hit the key points here

and it does. I'd like this whole like detected a test framework and work with it kind of mindset to say, okay, well we're using in units, so do it like this. Yeah, yeah, and yeah. People ask me sometimes like why is it successful? Honestly, I don't know what is the key thing? Because there's a lot of open source developers in the world that want to contribute, and you know, sometimes like what is what makes it successful? And I don't know is the catching name. Probably not,

But yeah, we do care about the quality of the code. We do try to actually said contribute, have decent discussions on gid up, like try to understand what people try to do. Yeah, we have a slack as well. Obviously it's designed for extensibility, but it's like a real project. You make mistakes, you introduce technical debts, you accept pull a quest that in retrospect we shouldn't have accepted that. Well, we'll try to fix that the next major release. But yeah, we do semantic versioning, which

means you cannot Yeah, you have to be very careful. It's not just that it has to be compatible on the source code level, but there's also

quite a lot of Actually that's what I discovered in the hard way. There's a lot of people that build their own new get package is that depend on this as extensions, you know, And then you change the signature of a method, like the return type of a method like who cares that should be just compuls And then somebody says, oh, yeah, but now I have this binary compatibility issue missing, notthet exception stuff that that that makes it a

bit more harder for us. Yeah, yeah, it's I get the sense you made this because you had problems you were trying to solve, and then it became its own set of problems. Effectively, I don't see it like that. I mean, of course, I'm proud and I use it myself every day, and you know, I go, I do a lot of consultancy gigs, and then you come into your client and it turns out a lot of people already using it and they know you, and you know, yeah, the only thing is it starts to define you, like like okay,

this is mister fluent desertions. Yeah you all you do is testing. You don't do anything else, right, No, yeah, yeah, exactly. You know, but it does give me some credits. I even had at my client that people were I was working for the client for a couple of years and people were actually applying for a job because they knew that I was there. Like, okay, I don't want to spoil your your I'm not that good. Actually nobody is. Well you're humble, that's for sure.

Yeah, it's reasonable. Are you seeing a lot of folks, I mean, are taking TDD seriously? Like it's because it seems like fluent exactly what you want in this idea of I can describe the test before I write the code, and as the code gets developed, the test will pass. A lot of people want to do it right, and not a lot of

people. No, I would say thirty percent of the people that I meet actually do it or they're trying to, not necessarily with fluid desertion, because that's just the tiny ingredient of it, right, but a lot of them

are struggling with that. And this is also one of the many talks that I do at conferences because I see them struggling, and I've tried to understand why they're struggling with that, and quite often it's the mistakes I made myself, like testing at two small scope, like assuming every class is its own units, Well, for me, that's wrong. That's almost always wrong,

and that is already a change in mindset. And you know, you need to actually understand the internal boundaries of your system, of your code base and try to align the unit of your unit test with those boundaries, which means that you might actually testing a couple of different classes together. And the example that I use for that is that this single method and in flow dessertion be

equivalent too. It's a single method. But if you're going to look at the code base behind that, that's like twenty thirty different classes with strategy pattern

implementation and stuff like that. And then I'll show people the UMIL diagram, assuming people still can read UML you know something that we learned in the past, you know, three years ago, And I showed them the diagram, and then I'm asking them like, okay, this is the method that you use on the front time I'm using my hands, which obviously doesn't work here wildly. Yeah, you use to be equivalent to method. That is the

actual thing that you're working with, that is your contract. Everything underneath it is essentially an implementation detail. Because twelve years ago I had one class I think it was called equivalency validator or maybe even I don't know, extensions or something like that. Over the years, I wrote like tons of tests. I think there's like a two thousand different unit tests against this. Be careful the two methods. I never started testing the individual classes. I always test

the whole thing as a unit because all of them are implementation details. Because of that, I managed to refractor things over the years, and that's at least that's what I believe what the original gang of formant with, you know, design patterns. It's a way to refactor your codebase, you know, give it more structure, make it easier for people to understand that structure.

And I have a bunch of these examples that I do in my talk to try to make people aware that the unit is quite often much more than that single class, except if that class is designed to be usable, right right, That is one of the key ingredients, if I may that. I think that makes a big difference if you're trying to practice unit testing and test of development. Yeah, yeah, absolutely, that's the challenge. And it's

interesting to see. You know, you've got this recursive effect going on, Dennis, where you're using those testing principles on your testing framework, you know, and making all of those mistakes along the way. I mean, one of the parts about this has he'd been doing it long enough that you started before a new GAT like you didn't have all the help that it's around now,

so you've sort of grown up into that as well. True, and just say it's it's interesting to see that you were just learning along with the rest of us about all of these problems. I'm trying to get to. I think we're in a better place. I'm pretty sure we're in a better place. Yeah, were in a better place, absolutely, if I compare that. I mean, indeed, I remember that we didn't have new gats. I remember that we didn't have standard or dot net core. We didn't

have multi targeting. I remember that Claire Novoltki helped me a lot like implementing like a baiting click implementation, you know, so that we can support multiple frameworks and dynamically load certain parts of FLU desertions based on the framework you're targeting. I remember there was something called dot nuts five, which has nothing to do with uh oh, there's no dot get coal Five's that dotnet coal five. I don't even remember. No, it was just called dot net.

By then you'd just called five. Yeah, we got the get rid of the core. Yeah, And there was like this moniker called dot nuts five I remember correctly. A couple of years ago, way before donut core. They were trying to come up with some new new framework standards or maybe it was proposed Microsoft dot Net framework something like that. Because it's currently there is no five for that. No, no, it was what wasn't even called dotnet five man, it's it's a long it's it's a dark age time thing

where everything became very difficult with doldnet. I think when what was dotnet was kind of losing its popularity for a while, you know, Um, but yeah, I mean now multi targeting is just a matter if you know specified the targets you want to target, use some if deaf statements here and down. It just works. It's so much easier. That standard also enabled a

lot of things we couldn't do in the past. H Yeah. But also mock down being able to build your own documentation websites with jack all have get up hosed them love markdown. Yeah. Good ideas that help editing a little easier. Um, yeah, it's I think we're in a great world with that. Actually, it's definitely without doubt. Yeah, And Dennis, I'm gonna interrupt for one moment this very important message or two and we're back.

I'm Richard Campbell. That's Carl Franklin. Hey, you're listening to dot net Rocks. We're here with our friend Dennis Duman. We're talking a bit about fluent assertions. Do we need to talk about liquid projections? I like these names. I think we should. I mean, I think we should sort of start at the beginning about events sourcing and what it's used for. There

we don't really we haven't really gone into that. Um, so maybe we should define that and cqrs and then why we need projections in what they are. Yeah, so that's a question I assume, right, yeah, yeah, yeah, let's start there. Event sourcing is an architecture style. It's not an architecture, but it's just a style that you can use to store. Essentially, it means you store the state of your domain in the form

of a series of events. So instead of storing you know, creating a customer stable and you have a customer object and DOTNT and you just use an ORM or something like that, like anti framework or an hibernat if you're old enough, you store that into a table. You're actually storing things that happened in the domain changes, the changes, but not just the changes, but also you try to capture the intent, like what happened functionally in the system.

I think the textbook example of that is that when you change the address of a client or something like that, is that because there was a mistake in the address, or was that because the client moved to a different place.

I mean even the number, how the number of the street. I mean if you I know some pretty big, big streets in the US, and if you move from I don't know what is the biggest street with all the bars in the Los Angeles always forget But if you move from number fifteen to two thousands, is that a mistake or did you actually move to a different place? Right right. A canonical example also is in finance right where

where you can't just like change the amount that you charge somebody. If you overcharge them, you have to put in how much you charge them, and then you have to add an event for or a projection or something that says, oh, we had to correct for this, and now the current value is this, So that you always have a record of how the state has mutated and and hopefully you be able to undo that or go back in time and look to see what the state was at a certain time. That is

one of the strength of defense sourcings that you can actually do that. You can also replay history, can actually look at the state of the domain at a particular point in time, which is why it's coming from the financial word. So projections comes up within the context of cqrs, usually right command query fastility segregation, where you want to transform the state from maybe what your application

uses to something else. The event needs to be projected into some other kind of shape so that it's easier to do something that you want to do, like query correct because the challenge with the events, of course, if you only store events, you cannot do a query like give me all the open orders which total value is bigger than one hundred k or something, all the clients with orders that have over one hundred thousand dollars because that information is not

available. You can only say give me a particular customer if that's the entity that you have. So if you want to be able to do queries across all these entities and all kinds of different structures, you need to take those events and project, as you said, into a format that is more optimized for quarrying, and that can be an h T p API that you're use in the UI. You can even project it into adjacent or XML or xtmail page that is already pre rendered so by the time the request comes in,

which is very powerful. Yeah, that is usually a source of a lot of complexity to build those projections to think about Okay, should they be synchronous with the domain? You know, if you click on the save button from a web page and you do querry, should then be consistent? Or is it acceptable that these things built in the background. They're also a big problem. If you upgrade your version of the code based do new version, then

you need to deal with the schema changes or something like that. You have to reproject things. And if there's millions of events in your events stor as they used to call that, that can take a while. So Liquid Projections is just another tiny library that are built to make it easier to build those projects. The projection code basically what we call ject us um. Nothing more than that. It's it's just a bunch of building blocks, not even a

framework. I don't like frameworks. I like to build small building blocks that you can mix. A match does require you to understand those building blocks a bit better, and I have some documentation on the website about that, and nothing more than that. Doesn't even take me a lot of time to maintain. Actually, does it also use a fluent syntax? It does use fluent APIs yes, yeah, indeed, I sense a pattern here, Yeah, yeah, it it becomes cheesy. I also build something called I think it's

fluid. Fluid cashing was another little library I created, so liquid projections, fluid cashing, fluent assertions, and then I probably used Google to find other synonyms for things that can. You know, you could do a fluent library for f sharp and call it a fluent or some people that's pretty good. I love that, I think. Don't email me. Some people actually hate this whole fluent API, but I like it. I love it. I found. Yeah, there's another lot of people floral or something for building fluent

HTP request or something like that. Yeah. Yeah, well I just both poking around you getting suck two hundred and fifty million downloads of fluid assertions that thought. That's a big number. Okay, there's no question about it. You're successful here. Yeah. Well ask my wife. She said, like, but why can't you just earn I don't know one sent yeh, that's true, yeah, I said, doesn't work like that. So what do you get out of it? I don't know, the murray, the admiration

of your fans, yeah, something like that. Absolutely, you get to you get to be on dot net rocks. Yeah, indeed, which is worth it already. Listeners appreciate it. Yeah, that in five euros will get you all at today. Yeah, that's a topic on itself, funding an open source development. We were just talking about that last week. Yeah, I mean it's a recurring topic on the show lately, especially because I see you have a Patreon in things like is any of that helping? No,

right, the only thing that's helping is is get up sponsoring. Yeah, the gihub spont it did see there's a few gith hub sponsors. Yeah, it's not It seems to be the most direct. That's usually because it also supports Well. The thing is with funding is that a lot of companies don't know how to do that. Yeah. It's not like somebody can pull the credit card and pay for it. They have to go to the I don't know what's the name of this department procurement or something like that. Yes,

finance, right, yeah, yeah, finance. And it becomes very hard. And I was talking about this with Mathias Cork who built another library called Nuke, which is a c sharp build buildings build script library. You were struggling with the same thing. It's it's difficult, it's difficult and again I'm not doing it for the money. Yeah, I mean I have a day job, but it does help a little bit with getting a speaking gigs

and you know that kind of stuff. Yeah, but it is it is for better worth a labor or passion, because it isn't it isn't a business itself, and I don't know that it would be better. Like the other conversation we're having is, Okay, now I'm productizing this because there's certain customers out there that want to pay me, but only if it's actually got a commercial component to it. I don't know that fluid Assertions falls into that category.

I don't think of anything. I mean, what would you offer, like somebody has to pay for a unit testing a library, Like how would you even do that? For support? Like does that? Does that even make sense? Yeah, that's what I do. I do that. Yeah. Yeah, you can actually use gate of sponsors and pay a certain amount of money you get like some time for me to help you make your test

power. But that doesn't really it hasn't really helped. No, no, no, it's not like a density server, you know, where you actually this is a crucial part of your product, and then people are willing to pay for it because it solves a production issue. Yeah, it's a chunk of code they're running in production and they want, you know, certain things

from that. The funny part is in last week's show we were literally described and I said, hey, yeah, this makes sense when it's a CMS, which when we were talking to Sean Walker about it, that you can turn into commercial product. But there's going to be these internal libraries. It doesn't make sense for and here we are having a conversation with you about an

internal library that it doesn't make sense, doesn't correct. It has to come from people that appreciate it or they feel like it really helped them in a certain way and they're willing to do a one time thing or something like that. I mean, look at yourself, like how easy. How often do you contribute or do you sponsor other libraries? Yeah, I mean I should. I should actually pay for action in it and all these libraries that make my life, you know, that makes me a better developer, help my

clients. Even one thing that just occurred to me is that you know, in the music business of the past, because as I don't think it's really relevant anymore, they used to you used to bars and performance establishments used to pay or they still do, ask CAP and BMI to collect royalties for artists on their behalf, and they would just you know, how how many hours a week do you have? What joke box stations do you? Blah blah

blah this and that. All right, we estimate you're going to pay, like, you know, a thousand dollars a year or something like that. And then the goal of ask cap and BMI then is to get artists to register with them and then distribute royalties accordingly. But you know that it's it's become a joke with live streaming and all that stuff. But yeah, but you know, there is a similar idea that you know, get hub or

one of these places that we've been talking about. Some some establishment or some nonprofit agency could essentially say, you know, if you if you use open source, you should become a member and pay a due and then those dues are collected and then distributed to open source projects based on the number of downloads they get. Whatever that is. I would embrace that, right, and if there was such a thing I would I would do that as well.

I would become a member of that organization because then it's not like I'm not nickel and diming myself for this project that project. In this project, that project, I'm saying, look, here's one hundred dollars a month or whatever it is. Then I'm giving to this membership, and then that is going to support the open source community. I like that. Somebody proved me wrong. I like that too. Actually in the Netherlands, in the Netherlands,

you actually still have to pay for music like that. If you have a bar, sports conteam, you actually have to pay well, I know, even if you Spotify. Yeah, I know Spotify business costs like fifty dollars a month per room that it's in um And I have people who I'm friends of mine that on restaurants to say it's worth it because they can just put on what they want, you know. But but that's you know, that's not ASCAP and BMI anymore. That's Spotify. Who's you know, distributing micropennies

to artists. Yeah, it's kind of broken. Yeah, it's just a question of yeah, is it is it usable money? Does it make a difference? That's right? Yeah, I feel this conversation keep coming up. I'm the guy who is good at talking to the CFO, and I feel an it's like, is there a construct here? You know, it's becoming more common in bigger companies to have like a giving fund for charities where the company says, hey, we'll match dollar for dollar what you contribute to to

your favorite charity. That kind of thing like should we be pushing on a construct for any organization as development? It says, let us know what open source libraries you're using, and you value you know, you put in your votes, and we have a pool. We're going to spend a thousand dollars a month distributed across the open source projects that you think are the most important for us. Right, let somebody else deal with the math. Well,

and you know you do that with a piece of software. They did all that. All of the developers that are working inside of an organization, they you know, we've got to do a bill of materials for our software anyway. Right, so we're right, sure, we already know what libraries we're using. Let's see what show up the most. Then throw in some voting, like tell me what your feel of the value of this is, how important is and so forth, and from that we just distribute the money and

you simply assign a budget item to that. It says, hey, we depend on a bunch of these things, so we're going to spend X many dollars a month and distribute from there. I think it takes us a good citizen. I think companies are more willing to embrace something like that that can be a line item in the budget, rather than you know, having developers come to them and say hey, I need yeah, five dollars and blah blah blah. Yeah, the dev doesn't want to do it because they don't

like talking to finances. Finance doesn't like these small ticket items. This is a paint in the buket, but it's a single monthly line item, and there's a mechanism for ding distribution done like dinner. I like that me too. Actually, I feel guilty that I haven't pushed for that at my clients, even my own employer, because it's not that hard to explain that. I mean, you spend tons of I mean just one developer of spends one

day of working is already much more than much more. That's a thousand dollars that you just mentioned exactly. The thing it can't do is evolve into a business that's for profit, Like it has to be very very stripped down, you know, and obviously it needs oversight. But but what Yeah, it can't. It can't turn into a for profit business because then it'll just eat up everything and then you know, the developerson won't anything. Well, some

people make that business. I know this FUGS project at some point on Patroon. I think there was like fifteen thousand dollars a month of Like that person can actually make it that job to do that right, which is not my goal because I actually love talking to clients, but I completely buy into what saying and I actually I've just decided I should push a little bit of hotter. It's not that complicated. Yeah, this sounds like a project we could

build. It's a little bit of software and so yeah, and it's about it's a mind and it's certainly a mindset. But the whole thing here is to lower the barrier to doing the right thing. I think get up has

a responsibility as well. And I think they're also trying to make it easier for companies to sponsor projects, right yeah, And that's the thing is like right now, get hub sponsorship means going to the individual project and is signing the money, Like, there really needs to be the company level viewpoint. And heck, if you if your company's functioning through gethhub with private, private repositories or public ones, like if that's where your source code flows through.

Anyway, gehub has all the data you need, right it can. It can produce that bill of materials for you, and you can tell you here's the dependencies you're taking, like and here's here's here suggested monthly donation or whatever it is. Whatever you let's let's go get Thomas Dems them to the wall. I think that's a great idea. That's a great idea. I don't know who that is, but see the current CEO of GitHub, so I should know. Oh I should at least send him a link to this episode.

Yeah, there you go. I think we can invite him on. He's been on my radar someone to invite on to talk to the state of geth hub. So let him talk extemporaneously for a while and then we'll nail him. Yeah, I'll pin him down. Now he's not coming. Okay. Well, we're just trying to make it a better place for developers all

around, that's all. Yeah, Well, and the thing is like we you know, we're thinking through each level's problems, right, Like, it is very reasonable for development organization to recognize the certain amount of money that we're saving because we use these libraries. Let's assign a portion of that to be distributed. But make it easy for me to do that, and so, and then you want to support the right things. You want your developers to

feel great that we're supporting the right things. So they want you want that involved in the process. But it should be simple. Yeah, it seems to you, guys just solved the whole problem for us. Well, now somebody's got it yet. Ideas are cheap, Yeah, ideas cheap. Execution is a painting the butt right as always? C sharp coding guidelines. Why did you do this? What is wrong with you? And what is your wife thinking about it? Yeah, she doesn't know. It's it's my secret,

the secret electric ship. You must have gotten ennamorative C sharp right at the beginning and the original announcement in two thousand, Like when did you encounter C sharp the first time? I think it's two thousand or end of nineteen

ninety nine. I was doing C plus plus mostly with I think it was called MFC, and I was working with a company that had C plus plus guidelines based on Stroutstrop industrial strength C plus plus or something like that goes really and initially it was really annoying, obnoxious set of rules, like you should not have more than one hundred lines. Now we have tools for that these

days. This is just a bunch of development guidelines, you know, some conventions and a lot of stuff you can cover with added a confix with what else rustling with the I use a lot of Jabbrains tooling. So with we sharper and writer you can get this stuff for done. But it's it's mostly

a set of guidelines and for me they're kind of obvious. Apparently there's still a market for it because people still fork the repository or print out this cheat sheet, which is a one page PDIA that you can put on people's desks, like where we're still working at the office, right, and it's more guidelines like that people don't start to overuse I don't know, the new pattern matching, or make switch statements from everything instead of thinking about object oriented design,

you know, stuff like that, to just to remind people about that every practice, every principle can be misused and overused. Sure, and I'm trying to fight some balance, like how you can do that? Nothing special? Yeah, yeah, and then every rule should be broken once in a while, just done coherently, like there's a reason why we broke this rule, that's right. Yeah, and that's why it's called the guideline or the rule. Yeah. I always worry when people print that stuff out and handed

the people it's like this is gospel. You must follow this or you have failed. I used to be like that, I don't know, fifty years ago or something. But yeah, at some point, I guess you grow up and you start to understand the pros and cons and when things apply, well, just acknowledge that there's more than one new way to be successful. There's no absolutes for any of this. If there was one right way, we'd be doing it, and there isn't. There isn't. Not true.

That's why it's a get a repo. And I even recommend people to clone a fork to repo, create air, own internal whatever they want to call it. I use that as a starting point. M great idea. And then but the main thing here is like why does this guideline exist? Here are the risks when you don't follow it, but they're only risks, right, like this, there's nothing certain. It's like we've when you're when these things get too long, they get harder to maintain, like they you you're

entangling different methods together. Like there's all the mistakes that we make as developers, and the guidelines try and steer us away from that. You can have opinions about that. You can disagree with it. It's totally fine. But I recently learned that I didn't realize that myself because we're getting older, I

mean, an adult that world for twenty years. There's an entire group of people that just graduated or have two or three years of experience, and they may be they may benefit from some of these guidelines because they don't even think

about it. They just try to make the code work, you know, and probably some senior developer will slap them in the face with my guidelines, I don't know, at least make them think about this kind of stuff, right, don't follow it blindly, don't be dogmatic about anything except that you should use flu insertions. Of course, yes, did we mention it, but yeah, I don't know if you heard. But also that, Yeah, don't be dogmatic about it. This is why we do it this way.

And it's hard when you're a new developer to understand the consequences of the code you write ten years from now. Yeah, because you haven't had that experience yet. And again, tooling has become better now we have Rosslyn analysis that help you fall. It doesn't solve the problems, doesn't solve your design issues, but they can help. We have so on a cube that may

you know, tell you that your method is too long. Okay, there's a risk that people that just blindly start to stupidly reflect the things and not make it better. But it should be a trigger. I hope it's a trigger. You know, people think about this or have a conversation with other developers, like, you know what, my method is pretty big. I can, of course make all these very small methods. Doesn't It's not going to make it better right at different ways of how I can approach that.

I hope that this will trigger things. It's almost a stimulus for conversation. It's like, why is my method getting a large Am I entangling two different things? Or is it just a big method? Could be you know, and you get into the pair of eyes involved. I look at this, you know why am I pressing up against this limit? Am I approaching this wrong? Or is it this the right thing to do? Refactoring it just to make it shorter when it still does all the same thing is questionable.

Really, I think the main issue here is am I not sticking with a single function? I mean, I'm making them do all the stuff method Well, that's why a lot of people are so let's say negative about clean code, because you know, people start to follow these these books and stuff like that blindly without understanding what's behind that. Yeah, that's what everything. I mean, you can configure son a cube in a certain way that your poolic

question will be rejected. But the whole point is you need to you need to think by yourself, or at least have that conversation. I should just set h Yeah, and then I think you you learn to think by yourself by having those conversations. You're hoping that the tools will give you indicators of when to have those conversations, not always running back all the time. Yeah, you just do when it's needed. No, I really appreciate that.

It's just astonishing to me to do anything for twenty years. Oh wait, how long will we make this bloody podcast? Oh my god, I think you're the same species, Dennis. You get involved in things and you just don't stop. Yeah, we have that disease. It's called passions. Okay, we'll call it that. It might be a kind of insanity too. Yeah, but I think if understood correctly, sanity means you're doing the same thing all over over and over again and expect different behavior. That is one

kind of insanive it is. I actually see change of behavior. Yeah, I see people ignoring me. I see people throwing my guidelines into you out of this because she just has your best interests in mind, you know, yes, yes, no, but that that's why we do these things, right, I mean you're doing a podcast to share experiences, to provide people with a different insight. I do the same thing with my blogs, with my presenting or conference. It's never the truth, it's just a mindset or

maybe these different perspectives to you. Yeah, right, Dennis. It's been an absolute pleasure having you on the show, and please do come back again. I love to thank you very much. All right, awesome, and we'll see you next time. I'm 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 dt nt r ocks 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 CE next time you got a m

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android