Atypical ASP .NET Core Design Patterns With Carl-Hugo Marcotte


Summary

In this episode, host Jamie Gepardman-Taylor welcomes back Carl-Hugo Marcotte to discuss the second edition of his book, ‘An Atypical ASP.NET Core 6 Design Patterns Guide’. Carl-Hugo shares the extensive updates made for .NET 6 and C# 10, including the adoption of top-level statements, minimal hosting models, global using directives, and nullable reference types. He explains the book’s structure as a journey from architectural principles and automated testing through to component design patterns, layering, and microservices.

The conversation delves into the value of automated testing, with both participants reflecting on their early careers and the common misconception that testing is a waste of time. They discuss how well-written tests facilitate refactoring, improve collaboration, and ensure code correctness, especially for complex algorithms. Carl-Hugo emphasizes that testing becomes valuable once developers learn to write tests that verify the intended behavior (the ‘black box’) rather than implementation details.

Jamie and Carl-Hugo explore the importance of learning outside one’s technical domain, drawing parallels between software principles like the Boy Scout rule and concepts from Marie Kondo’s tidying method or Greg McKeown’s ‘Essentialism’. They also touch on security best practices, such as constant-time string comparisons and SQL injection prevention, highlighting that incremental improvements can significantly elevate an application’s security posture compared to the average.

The episode concludes with Carl-Hugo sharing details about his beginner-focused blog series on C# and .NET, and both host and guest reiterating the importance of curiosity, asking questions, and viewing failures as learning opportunities. Carl-Hugo encourages listeners to provide constructive feedback on his book to help drive future improvements.


Recommendations

Books

  • An Atypical ASP.NET Core 6 Design Patterns Guide (Second Edition) — Carl-Hugo Marcotte’s book, described as a journey through design patterns, architectural principles, automated testing, and microservices for intermediate .NET developers. Updated for .NET 6 and C# 10 with minimal APIs and top-level statements.
  • The Life-Changing Magic of Tidying Up by Marie Kondo — Referenced by Jamie as teaching principles analogous to the Boy Scout rule in software—tidying as you go and leaving things better than you found them.
  • Essentialism by Greg McKeown — Mentioned by Jamie as a business book teaching prioritization and saying ‘no’ to non-essential tasks, similar to focus and task management in software projects.

People

  • Robert C. Martin (Uncle Bob) — Referenced regarding his advice in ‘Clean Architecture’ to defer technology decisions until the last possible moment to avoid locking the design to a specific implementation too early.

Tools

  • OWASP Top Ten — The Open Web Application Security Project’s list of the most critical web application security risks. Mentioned as a key resource; addressing just a few items from this list can significantly improve an application’s security posture.

Topic Timeline

  • 00:00:00Introduction and welcome back for the second edition — Host Jamie Gepardman-Taylor introduces the episode and guest Carl-Hugo Marcotte, who is returning to discuss the second edition of his design patterns book. Jamie provides context about Carl-Hugo’s previous appearance on episode 84 and sets the stage for topics like automated testing, refactoring tips, and learning outside your domain.
  • 00:02:01Carl-Hugo’s background and career journey — Carl-Hugo gives a brief introduction to his background, starting from learning BASIC and web development in the 90s, earning a computer science degree, working as a freelancer for 10 years, and his current role as a DevSecOps Engineer at Export Development Canada. He mentions writing the first edition of his book during COVID and recently updating it to a second edition.
  • 00:04:46Elevator pitch for the design patterns book — Carl-Hugo describes his book as an atypical design pattern guide that is more of a journey than a cookbook. It covers architectural techniques, unit testing, Gang of Four design patterns, layering, vertical slice architecture, and microservices. He emphasizes it’s for intermediate developers who know how to code but want to learn techniques to create more maintainable and flexible software.
  • 00:09:30The importance and misconceptions of automated testing — Carl-Hugo and Jamie discuss their early experiences with automated testing, where they and many peers saw it as a waste of time. They explore how poor initial tests that are hard to maintain contribute to this perception. The value emerges when tests are written to verify the feature’s acceptance criteria (input → black box → output) rather than implementation details, enabling safe refactoring and collaboration.
  • 00:16:12Example of unit tests for a complex algorithm — Carl-Hugo shares a concrete example of writing unit tests for a file-renaming POC with a complex algorithm. Manually testing numerous edge cases would take forever, but automated tests executed in milliseconds. This allows for confident refactoring, knowing the renamer will always produce the correct output regardless of internal changes.
  • 00:20:31Learning from non-technical domains and books — Jamie advocates for reading outside of technology, citing Marie Kondo’s tidying method (similar to the Boy Scout rule) and Greg McKeown’s ‘Essentialism’ (similar to task prioritization). He finds it reinforces software principles. Carl-Hugo agrees, noting we are people who live outside computers, and learning about other fields is valuable and often reveals universal principles.
  • 00:23:12Key updates in the book’s second edition for .NET 6 — Carl-Hugo details the major updates for the second edition: leveraging .NET 6 and C# 10 features like top-level statements, minimal hosting model, global using directives, and implicit usings. He moved C# feature explanations to an appendix for a more linear reading flow. He also revamped chapters on automated testing, architectural principles, and microservices based on reader surveys.
  • 00:32:05The immense effort behind writing and updating a book — Jamie expresses admiration for the enormous effort involved in writing a book, noting Carl-Hugo worked seven days a week for months on the update. Carl-Hugo clarifies that while he is the sole author, a team including reviewers and editors (‘we’) provided crucial feedback through code reviews, editorial reviews, and clarifications to improve clarity and flow.
  • 00:35:01The value of rereading known topics and mentoring — Carl-Hugo reiterates that he always reads chapters covering knowledge he already has because he almost always learns a new detail or a different approach. Jamie connects this to the value of mentoring—juniors can teach seniors new things because everyone has different knowledge. They agree it’s best to read a technical book cover-to-cover first, then cherry-pick later.
  • 00:37:03Security example: constant-time string comparison — Jamie shares a security insight he learned from a Java book: constant-time string comparison. Standard string equality checks fail early, allowing attackers to infer how much of a password is correct based on response time. A constant-time comparison processes the entire string before failing, eliminating this timing side-channel vulnerability.
  • 00:41:33Incremental security improvements and the OWASP Top 10 — They discuss security as a relative game: being slightly more secure than others makes you a less attractive target. Basic measures like using parameterized SQL (preventing injection) or adding a Content Security Policy (CSP) can elevate an app above 70% of others. They reference the OWASP Top 10 list of critical vulnerabilities as a starting point.
  • 00:49:56Metaphor for refactoring and unknown complexities — Jamie uses a scene from ‘Malcolm in the Middle’ where changing a light bulb leads to fixing a drawer, then a car, to illustrate how refactoring or new development often uncovers hidden dependencies and unknowns. Carl-Hugo agrees metaphors are great for creating mental models and teaching both tech and non-tech people about software complexities.
  • 00:53:31Why requirements change and the value of Agile — Carl-Hugo reflects on early career frustration with changing requirements, realizing that stakeholders often don’t know what they want until they try the software. This is why Agile and delivering small, working chunks is valuable—it allows users to visualize and provide feedback, leading to the product they actually need despite inherent communication challenges.
  • 00:55:58Carl-Hugo’s beginner blog series on C# and .NET — Carl-Hugo discusses his blog series for absolute beginners, updated for .NET 6’s minimal hosting model. It starts with ‘Hello World’ and delves into fundamentals like variables, constants, comments, string operations, Boolean algebra, and selection statements. He aims to make concepts like escaping characters and De Morgan’s laws accessible to new programmers.
  • 01:02:04Importance of work-life balance and taking breaks — Carl-Hugo notes he took a writing break after finishing the book’s second edition, especially to enjoy Canada’s short summer. He and Jamie emphasize the importance of not spending all time in front of a computer—exercising, going outside, and clearing your mind can lead to better ideas and prevent burnout, as our bodies aren’t designed for constant sitting.
  • 01:03:44Book title, contact details, and concluding advice — Carl-Hugo reiterates the book’s full title: ‘An Atypical ASP.NET Core 6 Design Patterns Guide’. He shares contact methods via LinkedIn, Twitter, and his blog. He invites constructive feedback. Both host and guest conclude with advice for developers: be curious, ask questions, don’t fear mistakes, view failures as learning opportunities, and celebrate small wins.

Episode Info

  • Podcast: The Modern .NET Show
  • Author: Jamie Taylor
  • Category: Technology
  • Published: 2023-01-06T07:30:00Z
  • Duration: 01:09:32

References


Podcast Info

  • Name: The Modern .NET Show
  • Type: episodic
  • Site: https://dotnetcore.show
  • UUID: 91f7d1c0-7bea-0136-7b90-27f978dac4db

Transcript

[00:00:00] The .NET Core podcast is supported by our listeners who have become patrons.

[00:00:03] To see a full list of the patrons, or to join them, head over to .NETCore.show slash patrons.

[00:00:16] Hello everyone and welcome to the .NET Core podcast.

[00:00:21] An award-winning podcast where we reach into the core of the .NET technology stack,

[00:00:25] and with the help of the .NET community, present you with the information that you need

[00:00:30] in order to grok the many moving parts of one of the biggest cross-platform multi-application frameworks on the planet.

[00:00:39] I am your host, Jamie Gepardman-Taylor.

[00:00:42] In this episode, I talked with Carl-Hugo Marcotte about the second edition of his book,

[00:00:47] an atypical ASP.NET Core 6 Design Patterns Guide,

[00:00:51] some of the changes he made to the second edition, and some of his top advice for developers.

[00:00:55] Regardless of where they are in their career.

[00:00:58] Long-time listeners of the show will know that this is actually his second appearance on the podcast,

[00:01:04] and it’s been almost a whole year since his last appearance.

[00:01:08] Along the way, we talked about the reason for writing automated tests,

[00:01:13] some top tips for refactoring,

[00:01:15] why Carl-Hugo makes a point to read chapters of technical books that cover knowledge he already has,

[00:01:21] and why I think it’s a great idea to learn outside of your domain.

[00:01:24] And he even shared some of the most important tips for you to learn outside of your domain.

[00:01:25] Here are some examples of why.

[00:01:27] So let’s sit back, open up a terminal, type in .NET New Podcast,

[00:01:33] and let the show begin.

[00:01:44] So Carl-Hugo, thank you ever so much for coming back onto the show.

[00:01:48] It’s been a long time since you were last on.

[00:01:51] Very many months.

[00:01:53] I’m not sure of what the episode number was,

[00:01:53] but I’m not sure of what the episode number was.

[00:01:55] I don’t know what the episode number will be,

[00:01:56] but it will be at least 25 episodes later.

[00:01:59] So, yeah.

[00:02:01] For those who don’t know,

[00:02:02] Carl-Hugo was on episode 84 of the podcast when we were talking about the first edition of his book.

[00:02:08] He now has a second edition out,

[00:02:09] so you should definitely go check that out.

[00:02:11] But before we get to that,

[00:02:12] firstly, welcome to the show.

[00:02:14] And secondly, for folks who maybe missed that episode,

[00:02:17] would you mind giving us a really quick sort of introduction to yourself?

[00:02:22] Of course.

[00:02:23] And thanks for having me a second.

[00:02:25] Thank you so much for having me, Carl-Hugo, for having me on the show.

[00:02:27] And we did record the last one almost a year ago,

[00:02:32] so that is many months indeed.

[00:02:39] Basically, I started coding when I was a kid,

[00:02:44] learned some basic,

[00:02:46] hacked together some web pages in the 90s.

[00:02:50] The web was fairly new there.

[00:02:53] Went to school, learned ASP, ESP,

[00:02:55] net.

[00:02:57] Ended up with a bachelor degree in computer science, part-time.

[00:03:06] I worked a few years in a firm,

[00:03:09] then went freelance for about 10 years working remote.

[00:03:14] So, I’m a big fan of remote work.

[00:03:19] I wrote a book, COVID,

[00:03:22] that gave me that opportunity to finish the first edition,

[00:03:25] the first edition of my book.

[00:03:27] And I then moved into Export Development Canada,

[00:03:33] or EDC as short,

[00:03:35] as a senior solutions architect.

[00:03:38] And now we’re in a big transformation,

[00:03:41] and my official title is DevSecOps Engineer, I believe.

[00:03:47] So, bringing new culture change to the enterprise.

[00:03:52] And…

[00:03:53] And…

[00:03:54] And…

[00:03:55] And…

[00:03:56] Yeah, updated the second edition of my book,

[00:03:57] this winter.

[00:03:58] I’ll finish this winter.

[00:03:59] And…

[00:04:00] And…

[00:04:01] Yeah.

[00:04:02] Here we are now.

[00:04:03] I’m a big fan of .NET C-Sharp.

[00:04:04] Of course.

[00:04:05] I think I forgot to say that.

[00:04:06] But, yeah.

[00:04:07] Yeah, yeah.

[00:04:08] That’s me.

[00:04:09] So, real quick.

[00:04:10] Talk us through the book, then.

[00:04:11] If you can give us, like, an elevator pitch for the book, right?

[00:04:12] Because, like I said, you’ve got the second edition out now.

[00:04:13] Let’s talk about the book first,

[00:04:14] and then we’ll move on to the next one.

[00:04:15] Yeah.

[00:04:16] Yeah.

[00:04:17] Yeah.

[00:04:18] Yeah.

[00:04:19] Yeah.

[00:04:20] Yeah.

[00:04:21] Yeah.

[00:04:22] Yeah.

[00:04:23] Yeah.

[00:04:24] Yeah.

[00:04:25] Yeah.

[00:04:26] Yeah.

[00:04:27] Let’s go.

[00:04:28] Yeah.

[00:04:29] Okay.

[00:04:30] Okay.

[00:04:31] I think I’ll go first.

[00:04:32] Just a real quick, like, elevator pitch,

[00:04:33] and then maybe if you can talk to us about what the changes are

[00:04:34] between the first edition and the second edition.

[00:04:35] I kind of think.

[00:04:36] Not obviously every single one.

[00:04:37] On page seven, I’ve changed this word to the .NET C-Sharp.

[00:04:38] But, like a, you know, like a brief overview,

[00:04:40] so, that we all know what the big differences are.

[00:04:44] Well, it…

[00:04:46] Well, the title is Enatipikoli SP.NET Core 6 Design Pattern Guide.

[00:04:54] Based on the…

[00:04:55] Basically, it’s a design pattern book, but it’s not a cookbook.

[00:05:03] It’s really more of a journey.

[00:05:07] So you can read, well, I think the best experience is to read it from cover to cover.

[00:05:14] Then you can use it as a reference book.

[00:05:17] So basically, I try to cover hands-on and experience-based design and coding principles.

[00:05:31] So we start with architectural techniques.

[00:05:34] We introduce some unit testing.

[00:05:39] We then go into smaller design patterns, like the Gang of Four design patterns, to build components.

[00:05:46] We move up.

[00:05:47] We move up to more higher level, like how do you build an app?

[00:05:52] And using layering, for example, using vertical size architecture, we touch and revamp the microservices chapter.

[00:06:03] So what are microservices?

[00:06:05] Of course, there’s many points there that also can lead to further.

[00:06:17] Further, I’m looking for my word here, but further learning.

[00:06:26] But yeah, it’s really, that’s pretty much, that’s pretty much, yeah.

[00:06:37] Well, there’s more to it, but I mean, if I have to phrase it real quick, I’d go, it’s a journey.

[00:06:44] How to build stuff.

[00:06:46] Like, you know how to code, how do you want to organize your code now, in a, yeah, so.

[00:06:56] Not a problem.

[00:06:56] Like I said, you know, I think you’ve covered it perfectly, though.

[00:07:00] You know, I don’t want, I didn’t want you to sit here and go, well, okay, so page one starts with, you know, it would be no good if you sat here and read the book, right?

[00:07:09] Because then you’re giving the book away for free.

[00:07:11] We don’t want that.

[00:07:14] It’s not about the money, though.

[00:07:16] But.

[00:07:16] But, yeah, it would be long to read 700 pages here on the show.

[00:07:24] Yeah, it would take a while.

[00:07:25] I don’t know whether you’ve ever, ever listened to, because I get loads of, loads of people making fun of me for this.

[00:07:32] I’m an auditory learner, so I tend to listen to people talking about code.

[00:07:37] And there’s a couple of audio books I’ve listened to where they literally read out code listings, which is great for me.

[00:07:43] But, you know, when they say public static.

[00:07:46] It’s like, I get it.

[00:07:53] You can just say it’s a program process, right?

[00:07:58] Yep.

[00:07:59] We don’t want that.

[00:07:59] Of course, of course.

[00:08:01] Yeah.

[00:08:01] And I think I forgot to mention that.

[00:08:04] But with its, like, second edition as the first is an intermediate level book.

[00:08:11] So it’s really, once you know how to code, as I do to paraphrase myself.

[00:08:16] Well, then you want to apply or learn about techniques to code better, to create more maintainable or more flexible softwares.

[00:08:26] That’s what we’re covering in the book.

[00:08:30] I wish somebody had written that book when I started my career.

[00:08:34] Jeez Louise.

[00:08:36] The amount of trouble I got into.

[00:08:38] Like the amount of times I would get into, like, architectural trouble.

[00:08:41] I’d written a whole app and then I’d get, you know, six, seven weeks in.

[00:08:46] And I’m like.

[00:08:46] I wish I could have changed that.

[00:08:48] I get it now.

[00:08:49] Looking back, why it was a bad idea to use a singleton or whatever, right?

[00:08:53] I wish, you know, 15 years ago, you’d have written the book then.

[00:08:58] Well, thank you.

[00:08:59] And I, yeah, I wish.

[00:09:01] Well, we’re talking a bit about mentoring and stuff before the show.

[00:09:04] And I so wish a similar thing that what you said happened to me, too.

[00:09:12] You learn by trying.

[00:09:15] But by trying.

[00:09:16] Yeah, it’s harder.

[00:09:18] It takes more time.

[00:09:20] Well, you never forget it, though.

[00:09:22] Because sometimes it’s got to stick there.

[00:09:26] But yeah.

[00:09:28] Just the testing.

[00:09:30] I do remember not doing unit testing and no automated testing at all.

[00:09:36] And finding it to be a waste, even at first when I learned it, I was like, this is a waste of time.

[00:09:44] But no.

[00:09:45] It is.

[00:09:46] It’s not.

[00:09:47] It just depends on the context.

[00:09:49] So I so wish that somebody would have explained to me, yeah, automated testing is good because, well, it helps you do refactoring.

[00:10:00] It helps if you work not alone.

[00:10:04] Working alone is easier.

[00:10:05] Like, you see the whole thing.

[00:10:08] Or if the program is bigger at some point when it’s bigger, you can’t have it all in your head, no matter who you are.

[00:10:15] So that’s where.

[00:10:16] That’s where all that automation comes into play and help.

[00:10:21] Yeah.

[00:10:22] That’s why I think chapter two is automation testing.

[00:10:28] Because that’s important.

[00:10:31] Yeah.

[00:10:31] Sure.

[00:10:32] Yeah.

[00:10:33] I can’t speak for all developers, but I do know that there is a.

[00:10:37] I don’t know whether it was a specific situational thing or a time-based thing.

[00:10:41] But a lot of the developers that I sort of initially trained with.

[00:10:45] We trained.

[00:10:46] We spoke.

[00:10:47] Like you said, we spoke before we hit record about like our backgrounds and stuff.

[00:10:52] And the people that I went to university with and did all that training with, they were very against it for similar reasons.

[00:10:58] Very against testing.

[00:11:00] And they were like, nah, it’s a waste.

[00:11:01] It is a waste of time to write these tests.

[00:11:03] And I thought, well, why do we have them then if it’s a waste of time?

[00:11:07] And I fell into the crowd of it’s a waste of time.

[00:11:09] And then and then I had to refactor something and everything broke.

[00:11:14] But I couldn’t tell that it had broken until I hit run.

[00:11:17] Or indeed, build right.

[00:11:18] And then I was like, oh, no, I’ve got a million and one compilation errors.

[00:11:23] I don’t know what to do.

[00:11:24] Whereas, you know, with it, with a test, I could have just said, well, the keyboard is a keyboard.

[00:11:29] Shortcut is for running the tests.

[00:11:31] They would have told me straight away, oh, you Wally, you’ve changed this, you know?

[00:11:35] Yeah, no, exactly.

[00:11:37] And one reason I believe that we can perceive testing or automation, automated tests as a waste of time.

[00:11:46] Is when you start, well, when I’ll take myself, I cannot put everybody in the same basket.

[00:11:54] But personally, when I started self-learn how to test, the test I was writing was really bad.

[00:12:02] So you end up spending a lot of time writing bad tests that you spend a lot of time maintaining until you kind of learn to, OK, I’m not testing the right thing.

[00:12:15] It’s like writing.

[00:12:16] But the right feature, you need to understand the feature.

[00:12:20] And that’s what testing also bring once you get it.

[00:12:24] But you have to teach that or you have to learn it somehow.

[00:12:29] And that’s where the value comes in.

[00:12:32] There’s an input.

[00:12:33] There’s a black box.

[00:12:34] There’s an output.

[00:12:36] You test that the NIN returns the out or do whatever it should do.

[00:12:42] And you don’t care about the black box.

[00:12:44] Which is basically the definition.

[00:12:46] Or the acceptance criteria of the feature you’re trying or the story or whatever you’re implementing.

[00:12:53] Once you get it, now it starts to add value when you spend less time maintaining those crappy tests.

[00:13:01] And often you can delete a bunch of them.

[00:13:04] And you have to maintain that test suite.

[00:13:08] Sorry.

[00:13:10] Yeah.

[00:13:11] I think that’s where maybe some.

[00:13:14] Some.

[00:13:16] Some thoughts of seeing tests as a waste of time maybe come from.

[00:13:22] Yeah, yeah.

[00:13:24] Some.

[00:13:25] I can understand why some developers.

[00:13:28] Again, like you, I can’t speak for everyone, right?

[00:13:31] But I can understand why some developers.

[00:13:34] Like, why should I test this code automatically when I can test it myself?

[00:13:39] You know, by calling the code, right?

[00:13:42] And, you know, the difference is how fast are you calling that code?

[00:13:46] Right.

[00:13:46] Versus how fast can I run the unit tests, right?

[00:13:49] I can, if it’s well enough written or rather automated test, right?

[00:13:53] If it’s, if it’s, if it’s written well enough, I can, you know, exercise the majority of a code base for an API, for instance, a web API in about a minute, right?

[00:14:05] I don’t have to, like I’m talking about a microservice here, right?

[00:14:09] But, you know, in about a minute or less, I can exercise something like 90% of the code base just by hitting a button.

[00:14:16] And inside of Visual Studio, Ryder, code, whatever, right?

[00:14:20] Versus, well, okay, so I’ve got to click here and I’ve got to click there.

[00:14:23] I’ve got to form this JSON and then I’ve got to send it over the wire and then I’ve got to wait and then I’ve got to wait for the response.

[00:14:29] But then all I’m doing is testing the very front of it, right?

[00:14:32] I’m not testing, like you say, those opaque boxes that make up the application.

[00:14:37] And for me, for my own personal sort of development, it was when I saw unit tests, I was not proving that.

[00:14:44] That it’s not proving that the code does what it says it does.

[00:14:49] It’s proving that the code does what I say it does.

[00:14:53] And there’s a difference there, right?

[00:14:55] That’s how I think of it, right?

[00:14:57] There’s a big difference between doing what the code says it does and doing what I say the code does.

[00:15:04] And I think that’s similar to your, I’m not trying to put words in your mouth, but it’s similar to that idea of you get testing.

[00:15:14] After you’ve done it for a while, you get it.

[00:15:16] You get the whole automation testing.

[00:15:18] And then there’s the cost, right?

[00:15:20] If it takes me five minutes to test something and I know the code rather intimately, it’s going to take maybe a tester, you know, a professional tester, maybe 10, 15 minutes.

[00:15:29] Because they’re not as, you know, deeply, they don’t have the deep knowledge that I have of how the code works.

[00:15:36] But then you shouldn’t, right?

[00:15:38] Yeah, definitely.

[00:15:40] There’s so many advantages.

[00:15:42] As you said, you were talking.

[00:15:44] You were talking about, like, more integration tests around the APIs.

[00:15:48] And there’s all the unit tests that are really good to test complex algorithm.

[00:15:55] As you said, like, it can take, I don’t know, a few minutes manually to start testing something.

[00:16:00] And the more feature you add, the more time it takes.

[00:16:03] The automation, it’s there.

[00:16:05] It remains there.

[00:16:06] But on the algorithm part, let’s say you’re writing, well, anything.

[00:16:12] I’ve run a small POC.

[00:16:14] Let’s see, to skip the context.

[00:16:19] But basically, it was a thing to rename files.

[00:16:22] So you input any file name and it renames it based on a few rules.

[00:16:26] It was just a quick POC that I wrote for some reasons.

[00:16:30] And I wrote some unit tests because it’s a complex, well, complex, air quote, algorithm.

[00:16:38] There are still many in that can produce different out.

[00:16:42] So testing that manually.

[00:16:44] It would have taken forever.

[00:16:46] But with an automation, I think it took three milliseconds to test 10 cases.

[00:16:53] So 10 use cases with a few edge cases, three milliseconds there.

[00:17:00] So every time you run the program or you want to run the test, you have three milliseconds.

[00:17:08] You test that.

[00:17:09] If something is broken there, you will know instantly.

[00:17:13] And.

[00:17:14] I did not.

[00:17:14] Well, I did some refactoring in that code, but I could have done way more.

[00:17:19] But it was just a small POC to show something.

[00:17:24] But then I could have started to extract more components from there.

[00:17:29] And I would be certain that when I input the file name, my renamer would output the right file name at the end, no matter the changes I was putting into that code.

[00:17:41] So that’s where it’s also super.

[00:17:44] Super useful and productive, right?

[00:17:48] Those unit tests, testing algorithm, unit tests that are testing nothing or some testing your code, they cost more to maintain and are less useful.

[00:18:02] Absolutely.

[00:18:04] I sometimes find that tests that are less useful, shall we say, I’m trying to be all polite, right?

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:13] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:14] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:15] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:16] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:30] Yeah.

[00:18:32] And I have to then figure out what the unit test or what the test was supposed to be testing,

[00:18:37] what it was supposed to be exercising, how it’s supposed to be doing it, and then fix it.

[00:18:42] And it may be in a completely unrelated piece of functionality, right?

[00:18:46] Hopefully, we never get into a position where you’ve checked into your main branch broken tests, right?

[00:18:53] Unless you get to a point where I’ve seen code bases where it was like, you know, let’s take X unit, for example, right?

[00:19:02] It’d be a public void test something, and it would just be assert true.

[00:19:07] That was literally the body of the code, just assert true.

[00:19:10] Yeah, we’ve got loads of unit tests.

[00:19:12] All you’re doing is asserting true.

[00:19:14] You’re checking that true is true.

[00:19:16] That’s not testing anything, right?

[00:19:19] Well, you’re testing X unit assertion lives.

[00:19:24] But you don’t need to.

[00:19:27] But yeah, I know it’s, yeah.

[00:19:30] That’s a great subject there.

[00:19:32] Important.

[00:19:33] I think that a lot of these things, and especially like some of the design patterns that you teach in the journey that the reader takes in both of your books here,

[00:19:44] I think that most of these things come from experience.

[00:19:48] I mean, there’s lots.

[00:19:49] I mean, let’s not beat about the bush.

[00:19:51] There’s loads of books about solid and design patterns and stuff like that.

[00:19:55] But like learning where they’re useful is kind of an, I feel like it’s a,

[00:20:01] maybe a skill.

[00:20:02] It’s a 70-30 split on experience and book learning, right?

[00:20:06] And that’s why I think, like you were saying earlier about mentors and mentees, that’s why I’m a big proponent of trying, like I am looking for a mentor and I am teaching a mentee, right?

[00:20:19] I like to be in the middle of this kind of thing because then I can get some help on the stuff that I don’t know.

[00:20:24] But then I can pass on information to someone else who maybe they don’t know something, right?

[00:20:28] And that’s why I’m always, I said to someone the other day,

[00:20:31] I always read, I’m reading books outside of development and then I’m noticing where they are teaching the same, the same things, but like to, I hate this phrase, but normal people like non-developers, right?

[00:20:46] So for instance, have you heard of the Marie Kondo technique, the whole tidying up thing, the life changing, life changing experience of tidying up or something like that, right?

[00:20:57] It’s, it’s written by this Japanese lady called Marie Kondo.

[00:21:00] And she talks about how you should.

[00:21:01] Tidy up as you go, right?

[00:21:03] So, you know, tidy up, you’ve, you’ve done something on your desk before you leave, tidy things up and then carry it.

[00:21:09] And it’s a life changing experience because some people don’t tie whatever, right?

[00:21:13] But what, what she doesn’t realize is she’s teaching like the boy scout rule and clean architecture to non-developers.

[00:21:20] She talks about, yeah, well, you know, if you see, if you’re, if you’re in a space where you’re working and something is, it needs to be tied up, do that first and then get on with your work.

[00:21:29] And that’s, that’s that boy scout principle of.

[00:21:31] Tidy up a little bit, make the world a little better, make the code a little better just before you leave it.

[00:21:37] Right.

[00:21:37] And, um, and things like, uh, essentialism is a book by, uh, Greg McKeown.

[00:21:42] We’ll come back to your book in a moment.

[00:21:43] I promise.

[00:21:44] Um, essentialism is a book by Greg McKeown that teaches similar things, but more of a business context.

[00:21:53] And it’s more of a case of being able to say no to certain tasks because you need to prioritize for the work you’re working on.

[00:21:59] Um, and being able to like.

[00:22:01] Uh, juggle the, this idea of which tasks are more important and then, um, you know, how do I devote this much time to this and that, that kind of thing.

[00:22:10] Um, I just love reading outside of technology to re because it reinforces those, those lessons.

[00:22:17] Uh, but there you go.

[00:22:18] There’s a little bit of advice for, for people who are listening from me, but we’re not here to listen to my advice.

[00:22:25] Well, that, that, that’s very interesting.

[00:22:27] And so seriously, that, that’s important, I think, to, to read, uh, or to learn out.

[00:22:31] Of just tech, um, because, well, we’re also all people that live outside of a computer.

[00:22:40] So learning about, uh, non-tech stuff is, is, is interesting.

[00:22:46] And I, I find it, uh, uh, great what you were describing that.

[00:22:50] Yeah.

[00:22:50] It also applied to, or it’s kind of the same principle that, that, that we learn in tech applies to, to real life.

[00:22:59] Makes sense.

[00:23:00] Mm-hmm.

[00:23:01] Yeah.

[00:23:02] So with your, with the second edition then, um, I mean, obviously the, like the subtitle of the book, uh, includes the words .NET 6 and C-Shop 10.

[00:23:12] So everything’s been upgraded to .NET 6, right?

[00:23:15] In your, in your book.

[00:23:16] And it’s using, uh, are you using like the global using statements and the minimal APIs and stuff like that?

[00:23:22] Or are you, uh, are you not?

[00:23:26] Well, uh, we basically, um, well, there was a lot of changes.

[00:23:31] Uh, I spent, uh, six months, uh, working seven days a week, uh, well, day job plus updating, uh, the book and we rewrote everything like the, the code style.

[00:23:44] We leveraged the top level statements and minimal hosting model everywhere.

[00:23:50] We also upgraded to the nullable reference types feature, um, that, that are introduced and that were introduced in C-sharp 8.

[00:24:00] But that are now enabled by default in the templates.

[00:24:05] Um, so, well, I say, I said all, and I think most code samples are rewritten.

[00:24:12] Some were not, not that many.

[00:24:15] And there was a reason, um, for those.

[00:24:19] So most of the book now are, are, are, well, most of the book use that new code style that, that was introduced.

[00:24:29] Uh.

[00:24:30] Well, uh, first, first, I believe we talked about that and, and, um, previous show, but the minimal hosting model, which is new with .NET 6 and the top level statements, um, that’s amazing to get started.

[00:24:45] And I’m, I’m pretty, I’m glad they, they are working and proving that, uh, more now with .NET 7 and, and, uh, the next, uh, versions.

[00:24:58] Um, so, so yeah, there’s a big.

[00:25:00] Um, I also, uh, invested in, in revamping the title subtitles, which is might seem trivial, but, um, trying to create a better table of content, making it, uh, to, to make it easier for readers to just jump back somewhere.

[00:25:21] Uh, I, I’ve learned a lot writing first edition.

[00:25:24] I’m not a book writer.

[00:25:25] I’m a computer guy.

[00:25:27] I have teaching experience.

[00:25:30] Uh, but, uh, writing a book in English and English, uh, obviously based on my accent is not my primary language.

[00:25:39] So, uh, uh, all of that together, I’ve learned a lot and we improve a bunch of small things, uh, small content tweaks here and there, uh, added some diagrams, updated some diagrams, uh, code style.

[00:25:55] That’s the big thing.

[00:25:58] Um, then in the first.

[00:26:00] First edition, I, I inlined a lot of C-sharp features throughout the book.

[00:26:06] Um, I got, uh, the comment during the review, but it was too much work to maybe move it to an appendix, which we did in the second edition.

[00:26:17] So all the C-sharp features are now packed into appendix A.

[00:26:21] So when you read, there are some references there, but, uh, that, that allowed me to, to make the content more.

[00:26:30] More linear, easier to follow because we didn’t have that visual style in the book that could be very show that, okay, this is just a nap, an excerpt talking about the C-sharp feature.

[00:26:42] Then we go back, uh, in the appendix A, you have all the C-sharp features, like a bunch of, not all, but a bunch of old C-sharp features.

[00:26:52] Um, well, older than, uh, C-sharp nine.

[00:26:56] You have C-sharp nine and .NET five, which were introduced in the first edition.

[00:27:00] And then you have the, the, the newer, uh, C-sharp ten and .NET, and .NET six, uh, features that we use in the book.

[00:27:11] Um, so all of that now, uh, concentrated in appendix A.

[00:27:17] It probably makes it way easier for reader to, to just read what they want to learn, what they need.

[00:27:25] So if, if you know everything about C-sharp ten, maybe you don’t have to read it.

[00:27:30] You don’t have to go in the, in the appendix altogether, so you can just read the, the content.

[00:27:37] And on the other hand, if, if you reach a point where you’re like, eh, what is this?

[00:27:42] Then you can go to the appendix and find it there, or maybe just read it and learn a few tricks.

[00:27:49] Um, I always, in books, learn, uh, not learn, but read the, the, the, the chapters and, and the stories.

[00:28:00] Stuff that I, I know anyway, because I always, or almost always learn a little detail.

[00:28:07] Like, every, somebody else do, do stuff differently than me, and I usually pick, pick up actually something.

[00:28:15] So it’s worth reading anyway.

[00:28:18] Um, then, then what, what is new if we go back to, to the, the update?

[00:28:25] There’s, uh, uh, Fioscope namespace.

[00:28:29] Uh, Fioscope namespace.

[00:28:30] Uh, Fioscope namespace.

[00:28:30] Uh, Fioscope namespace.

[00:28:30] Uh, Fioscope namespace.

[00:28:30] Uh, Fioscope namespace.

[00:28:31] Uh, Fioscope namespace.

[00:28:31] Uh, Fioscope namespace.

[00:28:31] Uh, Fioscope namespace. We use Global Using Directive, Implicit Using, Minimal Hosting.

[00:28:36] So these are some of the features of .NET 6.

[00:28:40] Uh, we, we started with a big, uh, talking about automated testing.

[00:28:45] I revamped, uh, chapter two, automated testing, made it, uh, better.

[00:28:51] Um, I revamped and, and improved chapter three as well, the Architectural Principle.

[00:28:59] So I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I.

[00:29:00] I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I

[00:29:30] So it’s more or less the same in most of the principles. And I added the keep it simple stupid or the KISS principle, which for some reason it was too simple. I forgot about it in the first edition.

[00:29:48] So a lot of improvement there. Streamline chapter 4 and 5, sorry, about MVC, Razor and web APIs. Make it a faster read there.

[00:30:07] We also ran surveys last year to know what people was the most interested in.

[00:30:15] And both layering and microchipping.

[00:30:18] Microservices came up.

[00:30:21] So, yeah, so we have also after layering, invested a lot of time in the microservices chapter because people were very interested in there.

[00:30:34] Not in there, but in that.

[00:30:36] And I tried to update the chapter, improved quite a few things.

[00:30:45] Did some reordering of subject.

[00:30:48] Updating, adding content, talked a bit more about event-driven architecture, and I added a pattern, which is the microservice adapter pattern.

[00:31:01] I call it that.

[00:31:03] There’s probably other names.

[00:31:05] I don’t know.

[00:31:06] But basically, it’s the adapter pattern, but as microservice.

[00:31:10] So you can do a lot of stuff with that.

[00:31:13] You can either adapt one system that is not using.

[00:31:18] Event-driven architecture to an event-driven architecture model, decommission an old system, replace a system by another.

[00:31:29] It’s just a piece you put in the middle that plays the middleman there, if you wish.

[00:31:39] So added that.

[00:31:41] And yeah, so invested a lot of time there.

[00:31:46] Because that’s what the reader needs.

[00:31:47] The reader we surveyed wanted.

[00:31:50] So we’ve spent a lot of time improving those two areas as well.

[00:31:59] And yeah, many small changes here and there.

[00:32:05] I think that’s something that a lot of people who read books don’t quite get is just the astronomical amount of effort.

[00:32:14] Right?

[00:32:14] You said earlier on, you spent, you know.

[00:32:17] Seven days a week working in the evenings after work for several months to actually get this ready.

[00:32:24] And that’s just preparing it for V2, you know.

[00:32:31] Yeah.

[00:32:32] Oh, no.

[00:32:32] You went through.

[00:32:33] Go ahead.

[00:32:34] Sorry.

[00:32:35] I was just going to say where you went through and refactored the book.

[00:32:39] Right?

[00:32:39] I hope you had some tests.

[00:32:40] But just the amount of effort that goes into writing a book.

[00:32:46] It’s.

[00:32:47] It’s immense to me.

[00:32:49] I’m always really impressed.

[00:32:50] Always really impressed whenever someone writes a book.

[00:32:52] And I say we.

[00:32:54] I’m the sole author of the book.

[00:32:56] But I have a team there.

[00:32:58] I’m not the only one who work on it.

[00:33:00] Like I had a reviewer, a new reviewer in the second edition.

[00:33:06] Great, great guy.

[00:33:09] Really talented.

[00:33:11] I was really impressed with all the code review there.

[00:33:16] Yeah.

[00:33:17] There’s the editorial review.

[00:33:20] There’s a bunch of other people that works with me and lots of back and forth doing, okay, I changed something.

[00:33:26] Then, hey, what do you mean there?

[00:33:28] And you’re like, yeah, that was not clear at all.

[00:33:32] So you rewrite it, right?

[00:33:34] And make sure everything’s clear and flows well.

[00:33:38] And so that’s why I’m saying we, because I have a team behind me to help me out.

[00:33:47] And so that’s why I’m saying we, because I have a team behind me to help me out.

[00:33:49] And so that’s why I’m saying we, because I have a team behind me to help me out.

[00:33:50] And so that’s why I’m saying we, because I have a team behind me to help me out.

[00:33:50] If you’re enjoying this show, would you mind sharing it with a friend or colleague?

[00:33:54] Check out Podcatcher for a link to the show notes, which has an embedded player within it and a transcription and all that stuff.

[00:33:59] And share that link with them.

[00:34:01] I’d really appreciate it if you could indeed share the show.

[00:34:05] But if you’d like a few other ways to support it, you could leave a rating or review on your Podcatcher of choice.

[00:34:11] So if you head over to .netcore.show.review, you’ll find loads of ways to do that.

[00:34:16] You could consider.

[00:34:17] The Buy Me A Coffee link is available on each show’s show notes page on the website.

[00:34:23] This is a one-off financial support option.

[00:34:26] You could become a patron.

[00:34:28] This is a monthly subscription-based financial support option.

[00:34:31] And the link to that is included on each episode’s show notes page as well.

[00:34:36] I’d love it if you could share the show with a friend or colleague or leave a rating or review.

[00:34:40] The other options are completely up to you and are not required at all to continue enjoying the show.

[00:34:47] Anyway.

[00:34:47] Let’s get back to it.

[00:34:51] There was something that you mentioned earlier on when you said that you find it’s worth reading parts of a book that cover things you already know.

[00:35:01] Because there’s always something that you can pick up, right?

[00:35:04] And I feel like this is something that you mentioned in the previous episode.

[00:35:08] I think we talked about how sometimes it’s someone who’s more junior than you can teach you something new, right?

[00:35:14] Because everybody knows different bits.

[00:35:17] Everybody knows different parts of the technology stack.

[00:35:18] And everyone has, you know, as long as you have a very big enough team with big enough experience between each person,

[00:35:28] you can actually go to someone and say, hey, Brent, you are the Angular person.

[00:35:34] Teach me a little bit of Angular because I know enough to make the app work.

[00:35:38] But I broke it and I don’t know why, right?

[00:35:41] And I think going back, like you said, rereading chapters for things that you already know in other people’s books,

[00:35:47] I think it’s always worth reading.

[00:35:49] If you’re reading a technical book, I feel like it’s always worth start at the beginning, work all the way to the end.

[00:35:56] And then you can, like you say, you can cherry pick the bits.

[00:35:59] I need to remember to come back to chapter seven because there’s something in there that I get it, but I’ve never done it before.

[00:36:05] Whereas chapter two and chapter five totally get those.

[00:36:08] I’ve done that loads of times.

[00:36:09] But there’s this amazing section on page 32 or whatever.

[00:36:14] I’m just pulling numbers out of the air, right?

[00:36:15] This amazing section.

[00:36:17] Page 32.

[00:36:18] I’d never thought about it like that.

[00:36:19] Oh, my goodness.

[00:36:20] There’s this thing you can do and it’s great.

[00:36:22] And I never knew you could do it.

[00:36:23] That’s why I like reading technical books, even if it’s for like.

[00:36:26] I read one last year that was like a web API security in Java.

[00:36:34] And I’m not a Java developer.

[00:36:36] I’ve never written any.

[00:36:38] I have written some Java for a throwaway Android app that I started working on years ago.

[00:36:44] But like I’m reading this thing.

[00:36:46] And.

[00:36:46] And.

[00:36:47] And yes, it was focusing on Java, but it was teaching me the like the bits that I was reteaching me some parts that I already knew about building secure APIs.

[00:36:57] But like until I read this book, I had no idea about constant time string comparisons.

[00:37:02] So there’s.

[00:37:03] Yeah, I don’t know if you know about this.

[00:37:05] I’ll just drop this in here for the for the listeners.

[00:37:07] If you have let let’s say you’re in a really bad world where you’re sending a plain text password over the wire and you’re comparing it to a plain text password in the database.

[00:37:16] You wouldn’t do this.

[00:37:17] But it makes the example really simple, right?

[00:37:20] If you are doing variable time standard string equals right string equals or double equals will go character one character two.

[00:37:30] Are they equal?

[00:37:31] Brilliant character to character character one character string one character one string to character one.

[00:37:37] Are they the same?

[00:37:38] Excellent.

[00:37:39] Move to the next character and and work through the string one character at a time.

[00:37:43] And then it stops immediately when there isn’t.

[00:37:47] An equality, right?

[00:37:48] So let’s say you’re sending Jamie down the wire, but the password is James soon as it gets to the I in Jamie, it drops out and says, nope, that’s incorrect, right?

[00:37:59] So it doesn’t match James because there’s Jamie for people who don’t know how to spell it.

[00:38:03] J.A.M.I.E.

[00:38:04] James J.A.M.E.S.

[00:38:06] So you get to the I compared to the E and you drop out straight away.

[00:38:10] You fail the comparison, right?

[00:38:11] But that’s bad for security because if you are fast enough, you can tell.

[00:38:16] If you if you if you have good enough measuring utilities and you’re a malicious user, you can tell how fast that request is coming back.

[00:38:24] You can tell how much of your password is correct.

[00:38:27] And so you like it, let’s say it’s a 32 character password and it takes four milliseconds to tell you it’s incorrect.

[00:38:33] And you change that 32 characters.

[00:38:35] You change one character at the end and it now takes five milliseconds.

[00:38:39] You know that you’ve changed something that got you further along the password comparison.

[00:38:43] And so constant time string.

[00:38:46] Comparison is even the very basic way of doing it is even when the characters in the string don’t match.

[00:38:54] Keep going to the end because you don’t want to even give away the subtlest hint of where the comparison fails.

[00:39:00] You want to fail at the end, not partway through it.

[00:39:04] And I didn’t know about that till I read this book.

[00:39:06] And now it’s it’s a it’s a brilliant thing that you just most people just don’t think about.

[00:39:11] Right.

[00:39:12] Yeah, no, definitely.

[00:39:14] That’s I didn’t know about it personally.

[00:39:16] I mean, you just teach me that right here on the show.

[00:39:20] That’s that’s awesome.

[00:39:22] I mean, the show is the show is fun and I enjoyed my first time, too.

[00:39:28] But now I’ll go out with that piece of learning.

[00:39:34] I think security is something like I like

[00:39:37] to follow security at least up to some level.

[00:39:42] And

[00:39:44] when you look at people doing security,

[00:39:46] security and how they breach VMS or whatnot, and

[00:39:53] it’s clever, it’s something like, yeah, there’s security like like me.

[00:40:01] I’m able to apply secure coding principle and I know a lot about security, but I’m

[00:40:08] not well, I don’t consider myself a security expert.

[00:40:11] Right. Sure.

[00:40:13] But then you look at those security expert.

[00:40:16] That’s something else.

[00:40:19] This is so what I what I tend to say to people is and OK, so I’m going to have

[00:40:24] to talk about criminal activity right now, just just to put that to one side,

[00:40:28] just so that you can understand the metaphor I’m about to use.

[00:40:31] If I want to steal a car, right, I’m going to walk up and down the street.

[00:40:36] I’m going to look for the car that looks the easiest to steal.

[00:40:39] I’m going to look for a car that doesn’t

[00:40:41] have, you know, those locks you can put on the steering wheel.

[00:40:44] I’m going to watch people coming and going to see which one’s.

[00:40:46] I have alarms and immobilizers and I’m going to pick if I just want to steal

[00:40:51] a car, I’m going to pick the car that looks the easiest to steal.

[00:40:54] Same thing with breaking into systems.

[00:40:56] I’m going to look for the one that’s

[00:40:58] easiest to break into because of the low effort for me.

[00:41:01] Right.

[00:41:02] But if we teach everyone who parks that car down that street to put a lock on your

[00:41:08] steering wheel and to use an alarm and an immobilizer and to park in a well-lit area,

[00:41:15] maybe to set up a dash camera.

[00:41:16] Or something.

[00:41:17] And GPS tracking.

[00:41:19] If everyone does that, then the net benefit is everyone’s car gets to be more secure.

[00:41:24] The whole area becomes harder for crooks to steal cars from.

[00:41:28] Same thing with secure code and secure like DevSecOps.

[00:41:33] If everybody does it, you get risen.

[00:41:35] You rise above all of the easy to pull off attacks and it becomes more

[00:41:41] difficult for people to break into your code.

[00:41:44] And then because it’s more difficult, fewer

[00:41:46] people will do it.

[00:41:48] I’m not saying nobody will do it, but fewer people will do it.

[00:41:51] And I love that about about security, because it’s like there is no maximum

[00:41:57] secure thing for security. It’s all about being just a little bit better than

[00:42:02] everyone else, because if you’re just a little bit better than everyone else,

[00:42:05] there’s everyone else who gets hacked, not you.

[00:42:07] Right. We were talking before the show about

[00:42:11] writing raw SQL and why you shouldn’t do it and embed raw SQL into your code.

[00:42:16] Right.

[00:42:16] And, you know, some people don’t know that can be if you’ve never looked at it,

[00:42:21] do a Google search now for XKCD drop tables.

[00:42:24] Right. You can actually put in, you know,

[00:42:27] if you know the system is just running SQL, you pass a SQL to the to the server

[00:42:32] through a login or whatever to drop all the tables and it will just happily drop

[00:42:36] all the tables. Right.

[00:42:37] That’s a that’s a security thing you need to patch against.

[00:42:40] But you don’t have to if you’re using parameterize SQL or using an ORM and

[00:42:45] it’s

[00:42:46] something I really, really enjoy sort of pointing out to people, hey,

[00:42:50] you don’t have to be the world’s greatest security engineer.

[00:42:54] You have to do these basic things.

[00:42:56] No. Yeah, definitely.

[00:42:58] And yeah, that’s the SQL like an injection, which is like SQL injection is

[00:43:05] part of is well, in twenty twenty one, that was the top three OWASP

[00:43:12] vulnerability. So if you don’t know the OWASP

[00:43:16] top ten, that’s

[00:43:19] that that’s the top ten security vulnerabilities

[00:43:26] that have been cataloged

[00:43:30] throughout the years put by OWASP, which is

[00:43:34] an organ security organization, nonprofit.

[00:43:39] Yeah. The open web application security project.

[00:43:43] If you just take off the AC, if you

[00:43:46] just take off two or three of the things in that top ten, you’re like seventy

[00:43:51] percent better than seventy percent of all the other apps out there.

[00:43:54] Right. And that’s that’s kind of that’s a really

[00:43:57] distressing statistic when you actually think about it.

[00:44:00] If you just do two or three and they’re not

[00:44:03] they’re not the world’s most difficult things, but they’re also not entirely too

[00:44:07] trivial. Right. So using an ORM or parameterizing your

[00:44:11] SQL, you’re immediately out of this out of scope of SQL injection attacks.

[00:44:15] If you’re doing web stuff, putting like a content security policy on there.

[00:44:20] Yeah, it might take you a day to get it working because it’ll break stuff.

[00:44:23] But then again, you’re above seventy percent of the other apps out there.

[00:44:28] It’s these things that are not tiny wins, but they’re doable in a week or two weeks

[00:44:35] of work, and you’re immediately better than a huge amount of applications out there.

[00:44:40] Exactly.

[00:44:41] And there’s like on SQL, like that’s as you said.

[00:44:45] You can use an ORM or just if you want to write your own query, you can use just

[00:44:51] parameters like just that will make make your codes infinitely more secure than

[00:44:58] concatenation on the like CSP, as you were saying.

[00:45:03] You can start with slow win, too.

[00:45:06] You don’t have to do all of it at once.

[00:45:09] If you have an existing app, like, of course, if you’re building a new app, you

[00:45:13] can bake it in.

[00:45:14] But if you have an existing

[00:45:15] web app, you can start baking the security policies like

[00:45:21] iteratively. You start with more loose policies and then you strengthen them

[00:45:29] while refactoring that whole application into a really secure one.

[00:45:35] But at least if you have, you better have some loose security than no security at all.

[00:45:41] Absolutely. Yeah.

[00:45:43] A DAW which has

[00:45:45] a DAW which closes is way more secure than just a hole in the wall.

[00:45:51] Right.

[00:45:52] It’s it’s not as secure as a DAW with the world’s greatest lock on it, but it is

[00:45:57] more secure. It is 100 percent more secure than just a big hole in your wall.

[00:46:02] Right. Exactly.

[00:46:04] Loved the image, dear.

[00:46:06] It’s perfect.

[00:46:09] Right.

[00:46:09] That’s how you build slowly, just like when you build an app, build it up slowly.

[00:46:14] And I think that’s where perhaps that’s

[00:46:16] where it comes back to experience and talking with mentors and stuff, because

[00:46:20] there was something you were talking about earlier on before we hit record

[00:46:24] about being able to tell from an architecture diagram, hey, this bit of the

[00:46:29] code, you know, what you’ve architected, what you’ve drawn out in this diagram,

[00:46:34] this bit here, right down at the bottom of the tree.

[00:46:37] It’s not going to work the way you think it’s going to work.

[00:46:39] And that’s not I mean, what I took from that conversation, what I took

[00:46:44] from that conversation was not you saying, oh, I’m the best and I know everything.

[00:46:47] It’s more a case of in my experience, when I’ve built systems similar to this,

[00:46:52] you haven’t thought about this corner case, right?

[00:46:55] When you when you get all the way down to this, this part of the the code stack,

[00:46:59] which I think flies in the face of something that Robert C.

[00:47:03] Martin advises and he advises, I think it’s in clean architecture.

[00:47:09] He says what he wants people to do is wait until the last possible second to decide on

[00:47:13] the technology you’re going to use for each component.

[00:47:16] Because then otherwise the the the the

[00:47:22] the temptation is if you if you decide right at the beginning, we’re going to use

[00:47:25] entity framework, I’m going to talk to SQL Server and that’s how we’re going to store it.

[00:47:29] Right. You stop there.

[00:47:31] The point that he makes is that you’ll start programming the app specifically

[00:47:35] to use entity framework and SQL Server, whereas if you left it to the last minute

[00:47:40] and went, we’ll use Dapper and we’ll use Postgres.

[00:47:43] Right. Right at the last minute, you’re making that decision almost in real time.

[00:47:47] But then you can’t do that if you if you have lots of different experience

[00:47:50] with different technologies, like you were saying, where you look at an architecture

[00:47:54] diagram and say the database technology is not going to work because you want to store

[00:47:58] X data and this technology does not support storing that data in the database as it is.

[00:48:04] So only to transform it on the way in and transform it on the way back out.

[00:48:08] And that’s going to add lots of CPU time or whatever.

[00:48:12] And then we’ll.

[00:48:13] Affect our SLAs and, you know, our target things.

[00:48:16] Right. Is it is that that that I mean, correct me if I’m wrong.

[00:48:20] That’s kind of what you were getting at, right?

[00:48:22] Oh, yeah. Well, definitely.

[00:48:24] There’s yeah, there’s clearly that.

[00:48:27] And and there’s also the unknown like

[00:48:31] you’ll always face some unknown.

[00:48:33] But yes, experience is what you describe.

[00:48:36] Like, oh, I know that I already saw that.

[00:48:39] So let’s let’s investigate.

[00:48:42] Oh, that won’t work because of like like you said.

[00:48:46] And the other part is is always the unknown.

[00:48:51] You’ll try to program something and you design the perfect system.

[00:48:56] Then the team or the teams are starting to work on that thing.

[00:49:01] And then you hit a roadblock because you didn’t know

[00:49:07] whether you plan for five minutes or you plan for six months.

[00:49:11] You didn’t know more.

[00:49:14] Like there’s some of those things that you have to do to just build it.

[00:49:19] Sometimes that’s where iterating fast kind of help.

[00:49:23] It’s like do it or try it like

[00:49:27] the extreme programing spike idea.

[00:49:31] Try something like just do it and see how it works and then implement the feature.

[00:49:38] But yeah, no, the.

[00:49:41] Yeah, you raised a good point there.

[00:49:45] But it may take you may plan for it to take five minutes.

[00:49:48] It might take a couple of hours.

[00:49:50] There’s a wonderful scene in an American TV show called Malcolm in the Middle.

[00:49:55] They get series three.

[00:49:57] And I use this to explain refactoring

[00:50:00] when or indeed writing some new code when I’m talking to non developers.

[00:50:04] And there’s a scene where the dad comes in and he goes to turn the light on.

[00:50:08] But the bulb has blown. So he needs to replace the bulb.

[00:50:11] So then he goes to the tool shed to get a new bulb.

[00:50:13] But he opens the drawer and the drawer falls to pieces.

[00:50:16] So he has to build he has to repair the drawer.

[00:50:19] But in order to repair the drawer, he needs to get some new screws.

[00:50:21] Does have any screws.

[00:50:23] So he goes to the car to go to the hardware store to buy the new screws to fix

[00:50:26] the drawer so that we could put the light bulb into the into the light.

[00:50:30] But then he goes to the car and he turns the car over and it’s not working.

[00:50:34] And so he looks under the car and the oil tank’s leaking.

[00:50:36] And so then he goes into the oil tank and starts fixing that.

[00:50:39] And his wife walks in and says, what are you doing?

[00:50:41] I’m going to change the light bulb.

[00:50:44] That’s refactoring, right?

[00:50:46] Yeah, I don’t know that clearly.

[00:50:48] Yeah, that’s a good metaphor there.

[00:50:54] That’s all about metaphors and examples.

[00:50:57] Right. But when somebody says to me, why is it taking this long?

[00:51:00] Well, OK, go watch this video and then

[00:51:02] you’ll understand why it’s taking that long.

[00:51:04] Yes. And metaphors are great to to learn to, well,

[00:51:10] teach non non-dexters.

[00:51:11] Teach tech people

[00:51:13] like like like this example or just teach tech people to like it’s easier when you

[00:51:19] can create that mental model of the problem or to fix or whatever you’re trying to fix.

[00:51:27] And metaphors are great.

[00:51:30] Great for that.

[00:51:32] So, yeah,

[00:51:35] I don’t know that show, though.

[00:51:37] You should. It’s personal opinion.

[00:51:40] It’s really silly.

[00:51:42] If you if you like silly daft sitcoms, they came out.

[00:51:46] I want to say it came out around the time

[00:51:48] of Scrubs, if you’ve ever seen that with the people in the hospital.

[00:51:52] But yes, very silly.

[00:51:53] And it started Bryan Cranston’s career, you know, the guy from Breaking Bad.

[00:51:57] He was an actor before this, but it sort of got him into the limelight.

[00:52:02] You know, got people really interested in what he does.

[00:52:06] But yeah, what I’ll do is I’ll put a link

[00:52:08] in the show notes to a version of that scene that’s maybe on YouTube or something

[00:52:13] so people can watch it and go, oh, yeah, no, I totally get it because I’ve more

[00:52:17] than likely butchered my description of the actual scene.

[00:52:20] But I feel like it’s a really good real

[00:52:23] world example of why development takes so long because we’re messing with unknowns.

[00:52:28] Right.

[00:52:29] When when, you know, you’re the user story

[00:52:31] you get given is written by a human talking to another human using a language

[00:52:37] that is based on.

[00:52:37] Vagary and not being very specific about something that they want to happen,

[00:52:44] but they don’t know what it is they want to happen.

[00:52:46] And then you take that user story and convert that into a bunch of technical

[00:52:50] requirements or well, it has to have an API endpoint, which the user story should

[00:52:54] not say API endpoint because that’s technical as a technical like a description

[00:52:59] of what you’re doing. So you go you go in, you build an API endpoint,

[00:53:02] you build a microservice and you build this whole system.

[00:53:05] And then they come back and say, no, what I actually wanted was the button.

[00:53:07] I didn’t want it to be read.

[00:53:09] I didn’t want all this complexity.

[00:53:10] Right. And that’s just because and that’s not me

[00:53:13] saying that, you know, BAs are no good because they are very, very smart people.

[00:53:17] But at the end of the day, you’re working with with vague descriptions of vague

[00:53:22] stuff using a language that isn’t really designed to be very specific.

[00:53:26] So, yeah, I feel like it happens all the time.

[00:53:29] But yeah, well, it does.

[00:53:31] And seriously, that’s something I found at the beginning of my career career to be.

[00:53:38] Um, to to be.

[00:53:41] Can I say that?

[00:53:44] That was pissing me off, basically, for lack of a better English.

[00:53:48] Sorry about that.

[00:53:49] But it was always like, why is our requirements always changing?

[00:53:54] Right.

[00:53:56] And at some point, well, it became very clear

[00:54:01] people that want softwares don’t know what they want.

[00:54:04] Well, they think they do.

[00:54:06] But the only way.

[00:54:08] To learn what they really want or need,

[00:54:11] actually, what they need is by trying that software.

[00:54:14] So and at that point, I got a

[00:54:19] when I realized that I felt

[00:54:22] it was it was way easier to work first because less frustration.

[00:54:29] But yeah, so that’s also why agile is so good.

[00:54:33] Like you’ve really smaller chunks of work of working software.

[00:54:37] Whether it’s every sprint or every whatever your release cadet says,

[00:54:41] but at least when when the user actually tries the thing, that’s where they realize

[00:54:48] I want that button read, right, because they see it.

[00:54:53] It’s hard to visualize a feature if you’re a tech person.

[00:54:58] So it’s even harder if you’re not a tech person.

[00:55:01] So by doing smaller chunks, it helps create

[00:55:06] that actual products that that your customer needs.

[00:55:11] And and as you said, we’re all just humans trying to communicate.

[00:55:16] Communication is very hard.

[00:55:18] So.

[00:55:20] Mm hmm. Yeah.

[00:55:22] So speaking of communication, I know that you’ve started

[00:55:26] a series of blog posts for people to get started with that.

[00:55:32] That’s like, yeah, I think I think the first one is creating your first dot net.

[00:55:36] Oh, C sharp program.

[00:55:38] Can you talk a little bit about that?

[00:55:40] Because like my just real quick, my personal opinion is that dot net has

[00:55:43] never been easier to get into setting example.

[00:55:47] But hello world is like one line of code.

[00:55:52] All right.

[00:55:52] Because there’s a comment, but it’s one line of code.

[00:55:57] Yes. Yeah.

[00:55:58] No, definitely.

[00:55:59] And yes, I did start a series of blog posts last year.

[00:56:06] Leveraging the minimal.

[00:56:11] Well, not the minimal, but the top level statement introduced in dot net five.

[00:56:17] So I started it’s all in the optic of you never coded before.

[00:56:22] And you want to learn coding.

[00:56:24] So that first hello world program is quite extensive.

[00:56:30] It’s not to explain to you how to write a little where you can copy paste an example.

[00:56:35] What’s a program and then dig deeper into how it executes, how it works.

[00:56:42] And I started to update the series for dot net six.

[00:56:49] So then I use the minimal hosting model.

[00:56:55] So it’s even simpler.

[00:56:57] Like I basically deleted content because there’s no more class.

[00:57:01] There’s no more anything.

[00:57:03] I just.

[00:57:05] Plain L world.

[00:57:07] So I deleted a lot of content from the article

[00:57:12] and I want to do the other one, too, so I can have them all up to date with dot net six.

[00:57:20] But yeah, so you start super small.

[00:57:22] What’s a program?

[00:57:23] You write one line and then you write a few more lines in there and then it continues.

[00:57:29] I have introduction to C sharp for you.

[00:57:32] What’s a variable?

[00:57:34] What’s a constant after word?

[00:57:37] What’s a comment?

[00:57:38] Like comments.

[00:57:40] It’s simple, but what’s a comment?

[00:57:42] Like all those small things for beginners.

[00:57:46] So how to read user input from a console.

[00:57:49] In the revamp, I may since now we can write top level statements for web app

[00:57:55] with that minimal, minimal hosting model, and it’s just easier and easier.

[00:58:00] I may go to web faster than I

[00:58:04] originally anticipated, but still reading from a console app is always good.

[00:58:12] String concatenation, string interpolation, escaping characters in a string.

[00:58:21] This one’s very interesting.

[00:58:23] Well, not well, OK, let me rewind a bit.

[00:58:28] I have sub series in there.

[00:58:29] So, for example, string concatenation, interpolation and escaping is like

[00:58:34] a sub series about strings and then have a second sub series about Boolean.

[00:58:41] So there’s Boolean, algebra and logical operators.

[00:58:47] So what’s that like?

[00:58:49] What’s an if or even before an if that one is just what’s a Boolean?

[00:58:54] Like the logical tables, true and true.

[00:58:58] Is that true or false?

[00:59:01] Then the if else selection statements.

[00:59:04] A switch statements.

[00:59:06] And finally, that’s the last one I have

[00:59:10] for now is the Boolean algebra laws, which can be really good.

[00:59:15] This one may be to more than just beginners, but there’s all sort of Boolean

[00:59:21] algebra laws like the absorption law, annulment law, associative law, complement.

[00:59:26] There’s a bunch of them.

[00:59:28] The De Morgan’s law are there, of course, and they’re all written in code.

[00:59:34] Not in mathematical symbols.

[00:59:36] So it’s like, OK, like basically A and parenthesis A or B,

[00:59:43] close parenthesis is always equal to A.

[00:59:47] So that’s an absorption law.

[00:59:50] So all those small tweaks that can help

[00:59:54] you convert large, complex Boolean conditions into easier one to read because

[01:00:02] you can get rid

[01:00:04] of a bunch of things.

[01:00:05] And that happened to me a few times.

[01:00:08] Like you read code, you’re like, hey, that’s complicated.

[01:00:11] Then you start simplifying it and become simpler or even simple sometimes

[01:00:17] or even not useful.

[01:00:20] Like if A equal always A, you don’t need B, B is useless.

[01:00:27] So that’s the final one.

[01:00:30] So a bunch of laws written for programmers.

[01:00:34] And if the time, if well, not if, but when I have time,

[01:00:40] I’d like to continue that series, I took a small break,

[01:00:44] to be honest, after finishing the second edition of my book.

[01:00:48] And and now I

[01:00:51] I took a good break of writing.

[01:00:53] I had my fair share for for a bit.

[01:00:57] So I started updated that and I’ll go back gradually to more blogging.

[01:01:04] And of course, in Canada, I’m from Canada.

[01:01:07] It’s summer here and we have six months

[01:01:10] of winter, give or take with actual snow, not like Europe snow.

[01:01:16] It’s the actual well, depending on where in Europe, of course,

[01:01:20] but let’s say not France level snow or I think UK, you don’t have much either.

[01:01:25] You we get about half an inch of snow and everything stops.

[01:01:29] Yes, exactly.

[01:01:30] But here we have

[01:01:32] feet high.

[01:01:34] Multiple feet of snow.

[01:01:36] So, yeah, with summer, we try to to enjoy the weather a bit more.

[01:01:42] And in winter, well, you stay home.

[01:01:45] There’s snow everywhere.

[01:01:47] Well, or you do outside activities.

[01:01:51] So I think that’s a that’s a really good point.

[01:01:56] Is that, you know,

[01:01:59] like like you said, as we’re recording, this is the middle of summer.

[01:02:03] Right.

[01:02:04] And I think because I mentioned earlier on read out, you know,

[01:02:08] learn outside of your of your your your daily domain.

[01:02:12] Right.

[01:02:13] And I think I think your your bit of advice there is way more important.

[01:02:19] You know, go out and

[01:02:21] enjoy the summer, you know, make sure you’re still hydrated,

[01:02:25] make sure you can, you know, sunscreen and all that kind of stuff.

[01:02:28] But you don’t spend all of your time in front of a computer.

[01:02:31] Right.

[01:02:33] Yeah.

[01:02:34] But doing something else on computer helps.

[01:02:38] Like I’m not saying don’t have your your side projects.

[01:02:41] Those helps a lot, too.

[01:02:42] But just doing computer first, you end up all broken because we’re not.

[01:02:48] Our bodies is not created to stay

[01:02:51] sitting the whole day, like seven days a week.

[01:02:54] Right. So we need we need to exercise a bit and go outside, take some sun.

[01:03:00] And the best ideas sometimes

[01:03:04] happen when you’re, I don’t know, walking in the forest or whatever is your thing

[01:03:09] is doing kayak or whatnot, right, because you clear your brain.

[01:03:14] And when you come back, you’re energized.

[01:03:18] Mm hmm.

[01:03:19] Yeah, definitely, definitely.

[01:03:21] So I guess

[01:03:24] remind the folks of what the book’s called.

[01:03:27] I’ll get some links for you and put them in the show notes.

[01:03:29] That’s fine.

[01:03:29] So if you’re if you’re interested and you should be interested in getting those books,

[01:03:33] you should check the show notes.

[01:03:35] But let’s remind the folks what the what the book is called.

[01:03:38] Talk about how they can get in touch with you.

[01:03:41] And yeah, let’s let’s do that.

[01:03:44] The title of the book is an atypical ASP dot net dot net core six design patterns

[01:03:52] guide, so that’s a long name and it’s an atypical book.

[01:03:58] I’m an atypical person.

[01:04:00] I like to think that.

[01:04:03] But we’re all

[01:04:05] but and how to contact me can be LinkedIn, Twitter.

[01:04:11] I have a blog with an email there.

[01:04:14] You can reach me out.

[01:04:16] I do have a cargo go that’s a domain.

[01:04:20] There’s another email there,

[01:04:23] but yeah, you can just reach me out on social media

[01:04:29] like LinkedIn or Twitter.

[01:04:30] And usually

[01:04:32] I answer.

[01:04:33] So pretty quickly or email.

[01:04:36] I answer those to Google my name.

[01:04:39] There’s probably not that many.

[01:04:42] Can you go back up?

[01:04:43] So yeah, I think.

[01:04:50] OK, yeah.

[01:04:51] And I mean, I’d like to say just before we wrap up this, this is wonderful.

[01:04:55] And I feel like I said that last time,

[01:04:57] it’s a wonderful call by you at the end of the first edition that says, you know,

[01:05:01] don’t don’t worry if you don’t know any.

[01:05:03] This stuff, because we’re not born knowing it.

[01:05:05] Not knowing it is is like the default state.

[01:05:09] Right. Ask questions and be curious.

[01:05:12] I really like that. Right.

[01:05:14] Because it’s so easy, especially when you’re a junior to go, oh, my goodness.

[01:05:17] I don’t know this and I don’t know that.

[01:05:18] How am I going to survive? I don’t know what I’m going to do.

[01:05:21] I don’t worry about it.

[01:05:22] Right. As long as you’re curious and you’re

[01:05:25] reading the books and you or you’re watching the videos or listening

[01:05:28] to the podcasts or whatever, then you’ll pick it up.

[01:05:31] Don’t worry. And don’t be afraid of.

[01:05:32] Right. I used to say this.

[01:05:34] I used to be a teacher.

[01:05:36] He said, tell the students, don’t be afraid of making a mistake

[01:05:40] without being horrible. You’re going to get it wrong.

[01:05:42] Right. Because you don’t know.

[01:05:44] Do you think do you think when you when you when you when you were a baby and you

[01:05:47] became a toddler, you just got up and walked?

[01:05:50] No, you stood up and then you fell over.

[01:05:52] You laughed. Then you stood up and you fell over again.

[01:05:54] Then you stood up and took one or two steps and then fell over again.

[01:05:57] You’re going to eventually get it right.

[01:05:59] Don’t worry about getting it wrong. Don’t focus on getting it wrong.

[01:06:01] Focus on when you get it.

[01:06:03] Right. Celebrate it.

[01:06:04] Celebrate those wins.

[01:06:05] Oh, totally.

[01:06:07] And well, as you said, like, don’t be shy to ask or say so.

[01:06:12] Like, if you don’t know something, don’t act as you do or don’t feel shy asking.

[01:06:18] If there’s somebody that can help you, well,

[01:06:22] chances are somebody will and will just make you learn that skill faster.

[01:06:29] You may still fail,

[01:06:31] but you may still fail less.

[01:06:34] Right.

[01:06:35] So

[01:06:37] it is worth doing.

[01:06:38] Sometimes it’s not easy, especially depending on the culture where you’re at.

[01:06:43] Except like failures is seen as well as a failure.

[01:06:48] But

[01:06:49] failure should be seen as as a way to move forward.

[01:06:53] An opportunity for learning.

[01:06:56] I don’t know who said that, but somebody said that.

[01:07:01] It’s great words to live by.

[01:07:03] That’s that’s what it is.

[01:07:04] Yeah.

[01:07:05] Let’s not worry about who said it.

[01:07:06] Let’s just all agree that it’s great words to live by.

[01:07:13] Well, like I said, thank you ever so much for being on the show again.

[01:07:17] I had a blast and I know I’ve I’ve learned a whole bunch of stuff and I’m going to be

[01:07:21] going out and getting volume two of the book because I’ve only got volume one.

[01:07:26] So I want to see what’s changed.

[01:07:28] And as much as I’m, you know, messing around

[01:07:30] with C-Sharp 10 and .NET 6 on a daily basis, there will be things in this book

[01:07:35] that I’ve not that I’ve not done before. So let’s do this.

[01:07:38] Let’s go get this book and let’s get it sorted.

[01:07:41] Great. Yeah.

[01:07:42] Thanks for having me again.

[01:07:43] It’s great again.

[01:07:44] And let me know, like when you read the book, good and bad.

[01:07:51] And that’s good for for everyone.

[01:07:53] I just if there is stuff you like or stuff you don’t like, just let me know.

[01:07:58] Send me a message.

[01:07:59] Explain to me.

[01:08:00] Why? Like, if you just tell me, hey, I hate that.

[01:08:04] It’s harder for me to understand how I can improve.

[01:08:07] Right.

[01:08:08] This is that constructive criticism.

[01:08:10] That’s what we need. Exactly right.

[01:08:13] That’s awesome.

[01:08:15] Well, like I said, he’s been great catching up with you.

[01:08:18] And yeah, I’m going to go order this new book.

[01:08:21] Awesome. Well, thank you.

[01:08:23] Any worries. Thank you ever so much.

[01:08:25] That was my interview with Carl-Hugo Mercotte.

[01:08:28] Be sure to check out the show notes

[01:08:30] for a bunch of links to some of the stuff that we covered and a full transcription

[01:08:34] of the interview. The show notes, as always, can be found at dotnetcore.show

[01:08:39] and there will be a link directly to them in your podcatcher.

[01:08:43] And don’t forget to spread the word.

[01:08:45] Leave a rating or review on your podcatcher of choice.

[01:08:48] Head over to dotnetcore.show forward slash review for ways to do that

[01:08:53] or reach out via our contact page.

[01:08:55] That’s at dotnetcore.show forward slash contact.

[01:08:59] And as always,

[01:09:00] remember to come back next time for more dotnet goodness.

[01:09:04] I’ll see you again real soon.

[01:09:05] See you later, folks.

[01:09:30] Bye.