Episode 113 - Atypical ASP .NET Core Design Patterns With Carl-Hugo Marcotte
Embedded Player
The .NET Core Podcast
Episode 113 - Atypical ASP .NET Core Design Patterns With Carl-Hugo Marcotte
Supporting The Show
If this episode was interesting or useful to you, please consider supporting the show with one of the above options.
Episode Transcription
Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.
I am your host, Jamie “GaProgMan” Taylor. In this episode, I talked with Carl-Hugo Marcotte about the second edition of his book “An Atypical ASP.NET Core 6 Design Patterns Guide”, some of the changes he made for the second edition, and some of his top advice to developers, regardless of where they are in their career.
Along the way, we talk about the reason for writing automated tests, some top tips for refactoring, why Carl-Hugo makes a point to read chapters of technical books that cover knowledge he already has, and why I think it’s a great idea to learn outside of your domain - I even share some examples of why.
So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.
The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository
Jamie
So Carl-Hugo, thank you ever so much for coming back onto the show? It’s been, it’s been a long time since you were last on very many months. I’m not sure of what the episode number will be, but it will be at least 25 episodes later. So, yeah, for those who don’t know, #### Car-Hugo was on episode 84 of the podcast where we’re talking about the first edition of his book, and now there’s a second edition out, so you should definitely go check that out. But before we get to that, firstly, welcome to the show. And secondly, for folks who maybe missed that episode, would you mind giving us a really quick sort of introduction to yourself.
Car-Hugo
Of course, and that thanks for having me a second time. And we did record the last one, almost a year ago. So that is many months. Indeed.
I basically, I started coding when I was a kid. Learned some basic hacked together some web pages in the 90s. Like, the web was fairly new there; went to school learning ASP, ASP NET. Ended up with a bachelor degree in computer science. Part time. I worked a few years in a firm, then went freelance for about 10 years working remote. So I’m a big fan of remote work.
I wrote a book, COVID gave me that opportunity to finish the first edition of my book. And I then move[d] into Export Development Canada, are EDC for short as a Senior Solutions Architect. And now we’re in a big transformation. And my official title is DevSecOps Engineer, I believe. So bringing new culture change to the enterprise.
And yeah, updated the second edition of my book this, this winter, have finished this winter. And here we are now I’m a big fan of .NET, C# of course, I think I forgot to say that.
Jamie
It’s me.
So real quick, talk us through talk us through the book, then. If you can give us like an elevator pitch for the book, right? Because, like I said, you’ve got the second edition out now. Let’s talk about the book first, just a real quick look, elevator pitch. And then maybe if you can talk to us about what the changes are between the first edition, the second edition, that kind of thing. Not obviously, every single, “on page seven, I’ve changed this word to…” like, you know, like a brief overview so that we all know what the big differences are?
Car-Hugo
Well, it well, the title is a need to recall the SP .NET Core six design pattern guide. Basically, it’s a design pattern book. But it’s not. It’s not a cookbook, it’s really more of a journey. So you can read well, I think the best experience is to read it from cover to cover down, you can use that as a reference book. Basically, I tried to cover hands on and experience based design and coding principles. So we start with architectural techniques, we introduce some unit testing. We then go into smaller design patterns, like the Gang of Four design patterns to build components. We move up to more higher level like how would you build an app and using layer ring for example, using vertical slice architecture, we touch and revamped the micro services chapter. So what are micro services? Of course, there’s many, many points there that also can lead to further further looking for my word here, but further learning. But yeah, it’s really up that’s pretty much it. That’s pretty much Yeah, well, there’s there’s more to add, but if I have to phrase it real quick, I’d go it’s a Journey, how to build stuff like, you know how to code. How do you want to organize your code now? And yeah.
Jamie
Not a problem, like I said, um, you know, I think you’ve covered it perfectly there, you know, I don’t want, I didn’t want 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? Because then you’re giving the book away for free. We don’t.
Car-Hugo
It’s not about the money, you know. But yeah, it would be long to read 700 pages here on the show
Jamie
will take a while. I don’t know whether you’ve ever, ever listened to because I get loads of loads of people making fun of me. And for this, I’m going to reach every learner. So I tend to listen to people talking about code. And there’s a couple of audiobooks I’ve listened to where they literally read out code lists things, which is great for me. But you know, when they say public, static, void, main, parentheses, args, square parenthesis, it’s like, I get it, you could just say is, is a program process, right?
Car-Hugo
Yep. Yep, of course, of course. Yeah. And I think I forgot mentioned that. But it’s like second edition as the first is an intermediate intermediate level book. So it’s really, once you know what to code, like two to read to paraphrase myself, well, then you want to apply or learn about techniques to code better to create more maintainable and more flexible software’s. That’s what we’re covering in the book.
Jamie
I wish somebody had written that book, when I started my career, geez, Louise. The trouble I got into, like, the amount of times I would get into, like, architectural trouble, I’d written a whole app. And then I get, you know, six, seven weeks. And I’m like, wish I could have changed that. I get it. Now looking back, why it was a bad idea to use a singleton or whatever, right? I wish, you know, 15 years ago, you’d have written the book, man.
Car-Hugo
Well, thank you. And I yeah, I wish well, we’re talking about about mentoring and stuff before the show. And I so wish, a similar thing that, that you what you said happened to me too, is you learn by trying. But by trying. Yeah, it’s harder takes more time. While you never forget it. Sometimes you get a stick there. But But yeah, how just the testing. I do remember not doing unit testing, and no automated testing at all. And finding it to be a waste, Evan. At first when I learned that it was like this is a waste of time. But no, it is not. It just depends on the context. So I, I so wish that somebody would have explained to me Yeah, automated testing is good, because, well, it helps you do refactoring. It helps. If your work not alone, working alone is easier, like you see the whole thing. Or if the program’s bigger, at some point, when it’s bigger, you can’t have it all in your head, no matter who you are. So that’s where all that automation comes into play and help you Yeah, that’s why I think chapter chapter two is automation testing? Because that’s important.
Jamie
Yeah. Yeah, I can’t speak for all developers. But I do know that there was a, I don’t know whether it was a specific like situational thing or a time based thing. But a lot of the developers that I sort of initially trained with, we spoke, like you said, we spoke before, we have record about like our backgrounds and stuff. And the people that I went to university with and did all that training with. They were very against it for similar reasons, very against testing. And they were like that. It’s a waste of it is a waste of time to write these tests. And I thought, Well, why do we have them then if it’s a waste of time, and I fell into the ground, I’ve it’s a waste of time. And then, and then I had to refactor something and everything broke. But I couldn’t tell that a broken until I hit run, or indeed build, right? And then I was like, oh, no, I’ve got a million or one. compilation errors. I don’t know what to do. Whereas with it with a test, I could have just said one of the keyboard is keyboard shortcut is for running the tests. They would have told me straight away Oh, are you wanna you’ve changed this? Yeah.
Car-Hugo
Yeah, no, exactly. And one reason I believe that we can perceive testing or automation automate. Test as a waste of time, is, when you start well, well, I’ll take myself, I can have everybody in the same basket. But personally, when I started self learn how to test, the test I was writing was really bad. So you ended up spending a lot of time writing bad tests that you spend a lot of time maintaining, until you kind of learn to, okay, I’m not testing the right thing. It’s like writing the right feature, you need to understand the feature. And that’s what testing also bring once you get it. But you have to teach that or you have to learn it somehow. Then that’s where the value comes in, there is an input, there’s a blackbox, there’s an output, you test that that then returns the out or do whatever it should do. And you don’t care about the blackbox, which is basically the definition or the acceptance criteria of the feature you’re trying or the story or the whatever you’re implementing, once you get it. Now it starts to add value when you spend less time maintaining those crappy tests. And often you can delete a bunch of them. You have to maintain that their su suites. Sorry. Yeah, I think that’s where maybe some, some some thoughts of seeing tests as a waste of time maybe come from?
Jamie
Yeah. Some I can understand why some developer again, like you, I can’t speak for everyone, right. But I can understand why some developers think, like, why should I test this code automatically, when I can test it myself? You know, by calling the code, right. And, you know, the difference is, how faster you were calling that code? Versus how fast can I run the unit tests? Right? I can if it’s well enough written or rather automated tests, right? If it’s if it’s if it’s written well enough, I can exercise the majority of a code base for an API, for instance, a web API in about a minute, right? I don’t have to, like I’m talking about Microsoft has here, right. But you know, in about a minute or less, I can exercise something like 90% of the codebase just by hitting a button inside of Visual Studio rider code, whatever. Right? Versus well, okay, so I’ve got a click, and I’m gonna click there, I’ve got a phone this JSON, and then I got to send it off the wire, and then I gotta wait. And then I don’t wait for the response. But then all I’m doing is testing the very front of it, right? I’m not testing like you say those opaque boxes that make up the application. And, and for me, for my own personal sort of development, it was one I saw unit tests as not proving that it’s not proving that the code does what it says it does. It’s proving that the code does what I say it does. And there’s a difference there. Right? That’s, that’s how I think of it right? There’s a big difference between doing what the code says it does and doing what the code doing what I say the code does. And I think that’s, that’s similar to you’re not going to, I’m not trying to put words in your mouth. But it’s similar to that idea of you get testing after you’ve done it for a while you get it, you get the whole automation testing. And then there’s the cost, right? If it takes me five minutes to test something, and I know the code rather intimately, it’s going to take maybe a tester, professional tester maybe 1015 minutes, because they’re not as deeply they don’t have the deep knowledge that I have of how the code works. But then you shouldn’t, right.
Car-Hugo
Yeah, no, definitively, there’s so many advantages. As you said, you were talking about, like more integration tests around the API’s. And there’s the all the unit tests that are really good to test complex algorithm, as you said, like, it can take, I don’t know, a few minutes manually to start testing something and the more feature you add, the more time it takes the automation, it’s there, it remains there. But on the algorithm part, let’s say you’re writing anything, I run a small POC, to to skip the context, but basically, it was a thing to rename files. So you input any file name, and it renames it based on a few rules. So it’s just a quick POC that I wrote for some reasons, and I wrote some, some unit tests because it’s a complex, complex air cooled algorithm, right, there are still many end that can produce different out. So testing that manually. will not take taken forever. But it within automation, I think it took three milliseconds to test down cases. So 10 use cases with a few you edge cases, three milliseconds there. So every time you run the program, or do you want to run the test, you have three milliseconds, you does that if something is broken there, you will know instantly. And I did not Well, I did some refactoring in that code. But I could have done way more. But it was just a small POC to show something. But then I could have started to extract more components from there. And I would be certain, and 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. So that’s where it’s also super, super useful and productive, right, those unit test testing algorithm, unit tests that are testing nothing, or some testing your code, they cost more to maintain and are less useful. It’s
Jamie
absolutely, I sometimes find that tests that are less useful, shall we say, try to be all pi tests that are less useful, ended up being similar to like comments, they get out of date very quickly. And like you say, they’re expensive to maintain. Because I then when I’m building a feature, say I’ve taken a branch, and I’m building my feature, and I don’t know, but one of the unit tests is now out of date, I’ve then got to go and figure I have to then figure out what the unit tests are, what the test was supposed to be testing, what it was supposed to be exercising, how it’s supposed to be doing it, and then fix it. And it may be in a completely unrelated piece of piece of functionality, right? Hopefully, we never get into a position where you’ve checked into your main branch broken tests, right? Unless you get to a point where I’ve seen code bases where it was like, let’s, let’s take x unit, for example. Right? It’d be public void tests. And then it would just be assert true that that was literally the body of coaches. So true. Here, we got loads of unit tests. Yeah, all you doing is asserting true, you checking that true is true. That’s not testing anything,
Car-Hugo
right. But you’re testing x unit assertion lives. You don’t need to, but yeah. That’s a great subject. They’re important.
Jamie
A lot of these things, and especially like some of the design patterns, that you teach in the journey that the reader takes in these in both of your, your books here. I think that most of these things come from experience. I mean, that there’s lots I mean, let’s not let’s not beat about the bush, there’s loads of books about solid and design patterns and stuff like that, but like, learning where they’re useful, is kind of, I feel like it’s a maybe a 7030 split on experience and, and book learning, right. And that’s why I think, like you were saying earlier about mentors and mentees. That’s, that’s why I’m a big proponent of Troy, like, I am looking for a mentor. And I am teaching a mentee, right, I like to be in the middle of this kind of thing. Because then I can get, I can get some help on the stuff that I don’t know. But then I can pass on information to someone else who maybe they don’t know something, right. And that’s why I’m always said to someone the other day, I always read it. I’m reading books outside of development, and then noticing where they are teaching the same same things. But like to, I hate this phrase, but normal people like non developers, right? So for instance, have you heard of the the Marie Kondo technique, the whole tidying up thing, the life changing, life changing experience of tidying up or something like that, right? It’s written by this Japanese lady called Marie Kondo, and she talks about how you should tidy up as you go, right? So you know, tidy up, you’ve done something on your desk, before you leave tidy things up, and then carry on. And it’s life changing experience, because some people don’t, whatever, right. But what what she doesn’t realize that she’s teaching, like the Boy Scout rule, and clean architecture to non developers, she talks about here, well, you know, if you see if you’re, if you’re in a space where you’re working, and something is needs to be titled, do that first and then get on with your work. And that’s, that’s that boy scout principle of tidy up a little bit. Make the world a little better, make the code a little better just before you leave it. Right. And, and things like essentialism is a book by Greg McEwan. We’ll come back to your book in a moment, I promise. essentialism that’s very interesting. It’s a book by Greg McEwan, that teaches similar things but more of a business context. 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. And being able to, like, juggle the this idea of which tasks are more important. And then, you know, how do I devote this much time to this kind of thing. I just love reading outside of technology to read because it reinforces those, those lessons. But they got this a little bit of advice for people who are listening from me, but we’re not here to listen to my advice.
Car-Hugo
Well, that’s very interesting. So seriously, that that’s important, I think, to to read, or to learn outside of just tech. Because well, we’re all so people that live outside of a computer. So learning non thing stuff is, is interesting, and I find it great, what you were describing that it also applied, or it’s guided the same principle that we learned intact, applies to real life, Excel.
Jamie
So with your with the second edition, then, I mean, obviously, that like the subtitle of the book, includes the words .NET, Six, and C sharp. So everything’s better great. It’s .NET. Six, right? In the new book, and it’s using are you using, like, the global USING statements and the minimal API’s and stuff like that? Or are you? Uh, you know,
Car-Hugo
well, we basically, well, there was a lot of changes, I spent six months working seven days a week, while the job plus updating the book, and we rewrote everything, like the code style, we leveraged the top level statements and minimal hosting model everywhere, we also graded to the knowledgeable reference types feature that are introduced and that were introduced in C Sharp eight, but that are now enabled by default and the templates. So well, I say I said, All right, I think most code samples are rewritten. Some were not. Not that many. And there was a reason for those. So most of the book now, or what most of the book use that new code style that was introduced. Well, first, I believe we talked about that and previous show, but the minimal hosting model, which is new with .NET, Six and the top level statements. That’s amazing to get started. And I’m pretty, I’m glad they are working and proving that more now with .NET, seven and next versions. So So yeah, there’s a big revamp there. I also invested in revamping the title subtitles, which is might seem trivial, but trying to create a better table of content, making it to make it easier for readers to just jump back somewhere. I’ve learned a lot writing the first edition, I’m not the book writer, I’m a computer guy, I have teaching experience. But writing a book in English and English, obviously based on my accent is not my primary language. So all of that together and we’re in a lot and we approve a bunch of small things, small component tweaks here and there. Added some diagrams, updated some diagrams, code style, that’s the big thing. Then in the first edition, I inlined a lot of C sharp features throughout the book. I got 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. So all the C sharp features are now packed into Appendix A so when you read there’s some references there but that allowed me to to make the content 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 then we go back in 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. Well, older than C sharp nine, you have C sharp nine and .NET, Five, which were introduced in the first edition. And then you have the newer C sharp, Devon .NET, in .NET, Six features that we use in the book. So all of that now concentrated in Appendix A, it probably makes it way easier for reader to, to just read what they want to learn what they need. So if you know everything about C sharp, then maybe you don’t have to go and in the appendix altogether, so you can just read the content. And on the other hand, if you reach a point where you’re like, What is this, then you can go to the appendix and find up there, or maybe just read at and learn a few tricks. I always and books learn, not learned but read the chapters and the stuff that I know anyway, because I always or almost always learn a little detail. Every somebody else do do stuff differently than me and I usually pick pick up actually something. So it’s worth reading anyway. Then Then what what is new, if we go back to to the Dr. Day, there’s
first cold namespace we use Global using direct, implicit using Mini models, things. So these are some of the features of .NET. Six. We started with a big, talking about automated testing, I revamped Chapter Two automated testing made it better. I have revamped and improved chapter three as well, the architectural principle. So I read the comments. And I know some people struggled with the Liskov substitution principle. So I’ve invested time there to rework that. Try to add some some more explanation. I removed some examples, too, there was many principal that had more than one example. So I removed those duplicate some of those, and also streamline the example. So it’s more or less the same in most of the principles. And I added there keep it simple, stupid, or the KISS principle, which for some reason, it was too simple. I forgot about it. First Edition. So a lot of improvement there. Streamline chapter five and four, four and five, sorry about MVC, razor and web API’s. Make it a faster read there. We also ran surveys last year to to know what people was the most interested in. And both layering and micro services came up. So yeah, so we have also after layering invested a lot of time into microservices chapter because people were very interested in in they’re not in there. But in that. And I tried to update the chapter improved quite a few things. Did some reordering of sub Jack, updating, adding content. talked a bit more about event driven architecture. And I added a pattern, which is the microservice Adapter pattern. I call it that. There’s probably other names, I don’t know. But basically it’s the adapter pattern but as microservice. So you can do a lot of stuff with that you can either at that one system that is not using event driven architecture to an even driven architecture model. decommission an old system replace a system or another. It’s just a piece you put in the middle that plays that middle. The middle man there if you wish, so added that and, and yeah, so invested a lot of time there, because that’s what the reader we surveyed wanted. So we spent a lot of time improving those two areas as well. And yeah, I think many small changes here and there.
Jamie
I think that’s something that a lot of people who read books don’t quite get is just the astronomical amount of effort. Right? You said earlier on, you spent, you know, seven days a week working in the evenings after work for several months to actually get this ready. And that that’s a company codes, just preparing it for V. Do, you know?
Car-Hugo
Yeah, oh, no, it
Jamie
went through. I was just gonna say we were you went through and refactored the book, right. I’ll be out some tests. But like, the, just the amount of effort that goes into, into writing a book is it’s It’s immense. Yeah, I’m always really impressed. always really impressed whenever someone writes a book.
Car-Hugo
And I say we, I’m the sole author of that book. But I have a team there. Like, I’m not the only one work on it. Like I had a reviewer, a new reviewer and the second edition. Great, great guy. Really talented. I was really impressed with all the code review there. There’s the editorial review. There’s a bunch of other people that works with me, and lots of back and forth doing okay, I changed something then, hey, what you mean there? And you’re like, Yeah, that was not clear at all. It’s what you write it right, and make sure everything’s clear and flows well. And so that’s why I’m saying we because I have teams behind me to help me out.
A Request To You All
If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.
But if you’d like other ways to support it, you could:
- Leave a rating or review on your podcatcher of choice
- Head over to dotnetcore.show/review for ways to do that
- Consider buying the show a coffee
- The BuyMeACoffee link is available on each episode’s show notes page
- This is a one-off financial support option
- Become a patron
- This is a monthly subscription-based financial support option
- And a link to that is included on each episode’s show notes page as well
I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.
Anyway, let’s get back to it.
Jamie
And there was there was something that you mentioned earlier on, when you said, you find this worth reading parts of a book that cover things you already know, because there’s always something that you can do, you can pick up, right. And I feel like this is something that you mentioned in the previous episode, I think we talked about how sometimes it’s someone who’s more junior than you can teach you something new, right? Because everybody knows different bits of the technology stack. And everyone has little, as long as you have a very, very big enough team with big enough experience between each, each person, you can actually go to someone and say, Hey, you are the angular person. Teach me a little bit of Angular, because I know, I know enough to make the app work. But I broke it. And I don’t know why. Right. And I think I think going back, like you said, rereading chapters, for things that you already know, in other people’s books, I think it’s always worth reading. If you’re reading a technical book, I feel like it’s always worth start at the beginning, walk all the way to the end. And then you can like you say, you can cherry pick the bits, 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. Whereas chapter two and chapter five, totally get those I’ve done that loads of times. But there’s this amazing section on page 32, or whatever. I’m just pulling numbers out the error, this amazing section on page 32. I never thought about it like that, oh, oh my goodness, this is thing you can do. And it’s great. I never knew you could do. That’s why I like reading technical books, even if it’s felt like I read one last year. That was like eight web API security in Java. And I’m not a Java developer. I’ve never written any book. I’ve written some Java for throw away Android app that I started working on. Yeah. Like I’m reading this thing. And, and yes, it was focusing on Java. But he was teaching me the like, the bits that I was really teaching me some parts. And I already knew about building secure API’s. And I can tell I read this book, I had no idea about constant time string comparisons. So there’s, yeah, I don’t know whether you know about this, we’ll just drop this in here for the for the listeners, if you have. Let’s say you’re in a really bad world where you’re sending a plaintext password over the wire, and you’re comparing it to a plaintext password in the database. You wouldn’t do this, but it makes the example really simple right? If you are doing variable time standard string equals right. String equals or double equals will go character one character two, are they equal brilliant character to character? Character, one character, string one character one string two character one. Are they the same? Excellent. Move to the next character and, and work through the string one character at a time. And then wait stops immediately when there isn’t an accord. All right, so let’s say you’re sending Jamie down the wire. But the password is James. Soon as he gets the AI in Jamie, it drops out and says, Nope, that’s incorrect, right? Because it doesn’t match James, because there’s Jamie, for people who don’t spell it J am i e, James J A M E S. So he gets to the I compared to the E and you drop out straightaway, you fail the comparison, right. But that’s bad for security. Because if you are fast enough, you can tell if you if you have good enough measuring utilities on your malicious user, you can tell how fast that request is coming back, you can tell how much of your password is correct. And so you like let’s say it’s a 32 character password, and it takes four milliseconds to tell you is incorrect, then you change that though, to do characters, you change one character at the end. And it now takes five milliseconds, you know that you’ve changed something that got you further along the password comparison. And so constant time string comparison is even the very basic way of doing it is even when the characters in the string don’t match, keep going to the end. Because you don’t want to even give away the subtlest hint of where the comparison fails. You want to fail at the end, not partway through it. And I didn’t know about that till I read this book. And now, it’s it’s a brilliant thing that you just most people just don’t think about, right?
Car-Hugo
Yeah, no, did they finish it? That’s I didn’t know about it. Personally. Yeah, just teach me that. Right here on the show. That’s that’s the show is the show was fun. And I enjoyed my first time too. But now I’m, I’ll go out with that piece of learning. But yes, security is something like I like to follow security. Athletes up some level. And when you look at that people doing security and how they breach VMs or whatnot, and it’s clever, it’s something like, yeah, there’s security, like, like me, like, I’m able to apply secure coding principle. And I know like a lot about security, but I’m not well, I don’t consider myself a security expert, right? Sure. But then you look at those security expert, man, that’s something else.
Jamie
This is, so what I tend to say to people is an okay, so I’m gonna have to talk about criminal activity right now, just to just to put that to one side, just so that you can understand the metaphor I’m about to use. If I want to steal a car, right, I’m gonna walk up and down the street, I’m going to look for the car that looks the easiest to steal, I’m gonna look for a car that doesn’t have, you know, those locks, you can put on the steering wheel, I’m going to watch people coming and going to see which ones have alarms and immobilisers. And I’m going to pick if I just want to steal a car, I’m going to pick the car that looks the easiest to steal. Same thing with breaking into systems, I’m going to look for the one that’s easiest to break into, because of the low effort for me, right. But if we teach everyone who parked that car down that street, to put a lock on your steering wheel, and to use an alarm and an immobilizer. And to park in, you know, in a well lit area, maybe to set up a dash cam or something. So and GPS tracking, if everyone does that, then the net benefit is everyone’s car gets to be more secure. That whole area becomes harder for crooks to steal cars from same thing with secure code and secure, like dev SEC up right? If everybody does it, you get risen, you rise above all of the the easy to easy to pull off attacks, and it becomes more difficult for people to break into your code. And then because it’s more difficult, fewer people will do it. Right. I’m not saying nobody will dope, a few people will do it. And I love that about about security, because it’s like, there is no maximum secure thing for security. It’s all about being just a little bit better than everyone else. Because if you just a little bit better than everyone else, there’s everyone else who gets hacked, not you. Right? We were talking before the show about writing raw SQL and why you shouldn’t do it. And then better to have raw SQL into your, into your code, right. And, you know, some people don’t know that can be if you’ve never looked at it, do a Google search now for XKCD drop tables, right? You can actually put in your receipt, if you know the system is just running SQL, you pass a sequel to the to the server through a login or whatever to tell this drop all the tables and it will just happily drop all the tables. Right? That’s a that’s a security thing you need to patch against, but you don’t have to if you’re using parameterize SQL or using an ORM and it’s something I really, really enjoy He’s sort of pointing out to people, Hey, you don’t have to be the world’s greatest security engineer, you have to do these basic things.
Car-Hugo
Know that? Yeah, definitively. And yeah, that SQL like an injection, which is why SQL injection is part of is, well, in 2021, that was the top three OWASP. vulnerability. So if you don’t know, the OWASP, top 10, that’s that the top 10 security vulnerabilities that have been catalogued throughout the years, put by OWASP, which is an Oregon security organization, nonprofit,
Jamie
the Open Web Application Security Project, if you just take off the AC, if you just take off two or three of the things in that top, then you’re like, 70%, you’re better than 70% of all the other apps out there. Right. And that’s, that’s kind of a really distressing statistic, when you actually think about it. If you just do two or three things, and they’re not, they’re not the world’s most difficult things, but they’re also not entirely too trivial, right. So using an hour or parameterizing, your SQL, you’re immediately out of this out of scope of SQL injection attacks. If you’re doing web stuff, putting like your content security policy on there, yeah, it might take you a day to get it working, because it’ll break stuff. But then again, you’re you’re above 70% of the other other apps out there. It’s tiny, it’s these things that are not tiny wins, but they’re doable in a week or two weeks of work. And you’re immediately better than a huge amount of applications out there.
Car-Hugo
Exactly. And there’s like on SQL like deaths, as you said, No around or just use, if you want to write your own query, like you can use just parameters. Like just that will make make your codes infinitely more secured and can’t get the nation like CSP, as you’re saying, you can start with slow wins, you don’t have to do all of it at once. If you have an existing app, like of course, if you’re building a new app, you can bake it in. But if you have an existing web app, you can start baking the security policies like iteratively, you start with more loose policies, and then you you strengthen them while refactoring that oh, the whole application into a really secure one. But at least if you are you better have some loose security than no security at all.
Jamie
Absolutely, yeah. A door, which has a door which closes is way more secure than just a hole in the wall. Right? It’s not as secure as a door with the world’s greatest lock on it. But it is more secure, it is 100% more secure than just a big hole in your wall.
Car-Hugo
Right? Exactly. I love the love image there.
Jamie
That’s how you build slowly, just like when you build an app, build it up slowly. And I think that’s where perhaps that’s where it comes back to experience and talking with mentors and stuff. Because there was something you were talking about earlier on, before we hit record, about being able to tell from an architecture diagram, a this bit of the code, you know what you’ve architected, what you’ve drawn out in this diagram, this bit here, right down at the bottom of the tree, it’s not going to work the way you think is going to work. And that’s not for me, what I took from that conversation, what I took from that conversation was not using who I’m the best. And I know everything is more a case of in my experience, when I’ve built systems similar to this, you haven’t thought about this corner case, right? When you when you get all the way down to this, this part of the the code stack, which I think flies in the face of something that Robert C Martin advisors, and he advises, I think it’s in clean architecture. He says what he wants people to do is wait until the last possible second to decide on the technology you’re going to use for each component. Because then otherwise, the the the the temptation is to if you if you decide right at the beginning, we’re going to use Entity Framework, and we’re going to talk to SQL Server. And that’s how we’re going to store it. Right. You start there. The point that he makes is that you’ll start programming the app specifically to use Entity Framework and SQL Server. Whereas if you left it until the last minute and when we use dapper and we use Postgres right at the last minute you making that decision, almost in real time, but then you can’t do that. If you if you have lots of different experience with different technologies, like you were saying, where you look at an architect’s diagram and say, the database technology is not going to work, because you want to store x data. And this technology does not support storing that data in the database as it is. So only to transform it drunk on the way in and transformer on the way back out. And that’s going to add a lot of CPU time or whatever. And that will affect our SLAs. And our target. Things. Right, is that? I mean, correct me if I’m wrong, that’s kind of what you were getting right?
Car-Hugo
Oh, well, yeah. Well, definitively, there’s, yeah, there’s clearly that and, and there’s also the unknown, like, you’ll always face some unknown. But yes, experience is what you describe, like, Oh, I know that I already saw that. So let’s, let’s investigate, or oh, that won’t work because of like, like you said, and the other part is always the unknown, killed, try program something, and you design the perfect system, then you the team, or the teams are starting to work on that thing. And then you hit a roadblock. Because you didn’t know whether you plan for five minutes, or you plan for six months, you didn’t know more. Like, there’s some of those things that you have to just build something like that’s where iterating fast, get the hell sake, do where they’re trying, like the Extreme Programming spike idea, try something like just do it and see how it works, and then implement the feature. But yeah.
Jamie
Yeah. You raised a good point there about it may take, you may plan for it to take five minutes, it might take a couple of hours. There’s a wonderful scene in the American TV show called Malcolm in the Middle, that good series three. And I use this to explain refactoring when I already need writing some new code when I’m talking to non developers. And there’s a scene where the dad comes in, he goes to turn the light on, but the bulb has blown. So it needs to replace the bulb. So then he goes to the tool shed to get a new bulb, but he opens the drawer, and the drawer falls to pieces. So then he has to build the list of repair the drawer. But in order to repair the drawing needs to get some new screws, doesn’t have any screws. So he goes to the car to go to the hardware store to buy the new screws to fix the drawers so that we could put the light bulb into the into the light. But then he goes to the car. And he turns the car over and it’s not working. And so he looks under the car and the oil tanks leaking. And so then he goes into the oil tank and starts fixing that. And his wife walks in says What are you doing? Because I’m trying to change the light bulb? Factoring, right.
Car-Hugo
I don’t know the big clearly. Yep. Good metaphor. They’re
Jamie
all about metaphors and examples. But when somebody says to me, why is he taking this look? Well, okay, go watch this video, and then you’ll understand why it’s taking that longer.
Car-Hugo
Yes. And your metaphors are great to learn to well teach non non tech people like, like, like this example, or just teach tech people to like, it’s easier when you can create that mental model of the problem or the fix or the whatever you’re trying to fix. And better for resort or create trade for that. Yeah. I don’t know that showed
Jamie
you. It’s personal opinion. It’s really silly. If you if you like, silly, daft sitcoms, they came out around I want to say it came out around the time of Scrubs. If you’ve ever seen that with the people in the hospital. Be it’s very silly. And it started Bryan Cranston’s career, you know, the guy from Breaking Bad. He was a he was an actor before this. But it sort of got him into the limelight, you know, got people really interested in what he does. But yeah, what I’ll do is I’ll put a link in the show notes to a version of that seen this maybe on YouTube or something so people can watch it and go, Oh, yeah, no, I totally get it. Because I’ve more than likely butchered my description of the actual scene. But it’s a really I feel like it’s a really good, real world example of why development takes so long. Because we’re messing with unknowns, right? When when you know, your user story you get given is written by a human talking to another human using a language that is based on vagary and not being very specific about something that they want to happen, but they don’t know what it is they want to happen. And then you take that user story Right, convert that into a bunch of technical requirements or will it has to have an API endpoint, that the user story should not say API endpoint, because that’s technical, as a technical, like a description of what you’re doing. So you go, Hey, you go and you build an API endpoint, you build microservice, and you build this whole system. And then they come back and say, No, what I actually wanted was the button to be read. And I want all this complexity, right? And that’s just because, and that’s not me saying that, you know, Bas are no good, because they are very, very smart people. But at the end of the day, you’re working with, with vague descriptions of vague stuff, using a language that isn’t really designed to be very specific. So yeah, I feel like it happens all the time.
Car-Hugo
But yeah, well, it does. And seriously, that’s something I found at the beginning of my carrier career to be
Jamie
to be
Car-Hugo
can I say deadly? That was pissing me off basically, for lack of better English. Sorry about that. But it was always like, why is our requirements always changing? Right. And at some point, I, well, it became very clear, people that want software’s don’t know what they want, what they think they do. But the only way to learn what they really want or need, actually what the need is by trying that software. So and at that point, I got a when I realized that I felt it was it was way easier to work first, because less frustration. But yeah, so that’s also why Agile is so good, like you really smaller chunks of work of working software, whether it’s every sprint or every whatever you’re really scattered, says, but at least when when the user actually tries that thing. That’s where they realize, I want that button read, right? Because they see ugly, it’s hard to visualize a feature if you’re a tech person. So it’s even harder if you’re not a tech person. So by doing smaller chunks, it helps create that actual products that your customer needs. And, and as you said, We’re all just humans trying to communicate communication is very hard. So yep.
Jamie
So speaking of communication, I know that you’ve started a series of blog posts for people to get started with .NET. Like, I think I think the first one is called creating your first dotnet or C sharp program. Can you talk a little bit about that? Because like, my just real quick, my personal opinion is that dotnet has never been easier to get into. Right? So the example. Hello, world is like, one line of code. Alright, it’s too because there’s a comment. But there’s one line of code.
Car-Hugo
Yes, yeah, no, definitely. And, yes, I did start a series of blog posts last year, leveraging the minimal. Well, not the minimal, but the top level statement, introducing .NET, Five. So I started, it’s all in the optic of you’ve never coded before. And you want to learn coding. So that first HelloWorld program is quite extensive. It’s not explained to you how to write a little word like ad copy, paste, in example, what’s the program and then dig deeper into how it executes how it works. And I started to update the series for a .NET Six. So then I use the minimal hosting model. So it’s even simpler like I basically deleted content because there is no more class. There’s no more anything, right? He’s just playing l world. So I did use a lot of content from the article. I want to do the other one too. So I can add them all up to date with with .NET. Six. But yeah, so you start super small, lots of program, you write one line, and then you write a few more lines in there. And then it continues, I have introduction to C sharp variable, what’s variable? What’s a constant after word? What’s a comment? Like comments? It’s simple, but what’s a comment? Like all those small things, too, for beginners? So how to read user input from console, it’ll revamp I may. Since now we can write top level statements for web app with that minimal minimum hosting model. And it’s just easier and easier. I may go to web faster than I originally originally anticipated. But still reading from a console app is always good. string concatenation, string interpolation escaping characters in a string. This one’s very interesting. Well, not well, okay, let me rewind a bit. I’ll subsidiaries in there. So for example, string concatenation, interpolation and escaping is like a sub series about drinks, and then a second sub series about Boolean. So there’s Boolean algebra and logical operators. So what’s that? Like? What’s an F, or even before a NIF? That one is just what’s a Boolean, like the logical tables? True and true? Is that true or false? Then the if else, selection statements, or switch statements, and finally, that that’s the last one I have for now is the Boolean algebra laws, which can be really good. This one may be to more than just beginners. But there’s all sorts of Boolean algebra laws, like the absorption law, annual min law, associative law compliment, there’s a bunch of them that De Morgan’s law are there of course, they’re all written in code, not in mathematical symbols. So it’s like, okay, like basically, a, n paranthesis. A or B, close parenthesis, is always equal to a. So that’s an absorption law. So all those small tweaks that can help you convert large, complex Boolean conditions into easier one to read, because you can get rid of a bunch of things. And that happen, it happened to me a few times like you read code, you’re like, II that’s complicated, then you start simplifying, and become simpler, like or even simple sometimes. Or even not useful. Like, if a equal always AZ you don’t need B to B’s useless. So so there that’s the final one. So a bunch of laws written for programmers and if the time if Well not if, but when I have time I’d like to continue that series. I took a small break to be honest after finishing the second edition of my book and and now i
i took a good break of writing I had my fair share for for a bit so I started updated that and I’ll go back gradually to two more blogging and of course, in Canada I’m from Canada it’s summer here and we have six months of winter give or take with actual snow not like rope snow it’s actual Well, depending on where in a rope of course but let’s say not friends level snow or I think UK you don’t have much either.
Jamie
You We got about a half an inch of snow and everything stops
Car-Hugo
Yes, exactly. But here we have feeds high multiple feeds of snow. So yeah, with summer we try to to enjoy the weather a bit more in winter. Well you stay home, there’s no everywhere. What are you doing outside activities?
Jamie
I think that’s a that’s a really good point. Is that you know, like, like you said, as we’re recording this as the middle of summer, right. And I think because I mentioned earlier on read out you know learn outside of your of your, your daily domain, right. I think your your bit of advice there is way more important. You know, go out and enjoy the summer. You know, make sure you stay hydrated make sure you can you know, sunscreen and all that kind of stuff. But you don’t spend all all of your time in front of a computer right?
Car-Hugo
Yeah, well, doing something else and computer helps. Like I’m not saying don’t have your side projects those helps a lot too. But just doing computer first you will end up heartbroken because we’re not there. Our bodies is not created to stay sit, sitting the whole day, like seven days a week. Right? So we need we need to exercise a bit and go outside, take some sun. And the best ideas sometime happen when you’re right on walking in the forest or whatever is your thing is, do we kayak whatnot, right? Because you clear your brain and when you come back or Energize?
Jamie
Yeah, definitely, definitely. So I guess, remind the folks, what are the books called, I’ll get some links for him, put them in the show notes. That’s fine. So if you’re, if you’re interested in you should be interested in getting kind of Google’s books, or you should check the show notes. But let’s remind the folks although the book is called, talk about how they can get in touch with you. And yeah, let’s let’s do that.
Car-Hugo
The title of the book is an atypical ASP .NET .NET, Core six design patterns guide. So that’s a long name. And it’s a typical book. I’m an atypical person, I like to think that.
And how to contact me can be LinkedIn, Twitter, I have a blog with an email there, you can reach me out to Carl yuko.ca domain, there’s no other email there. But yeah, you can just reach me out on social media, like LinkedIn or Twitter. And usually, I answer. So pretty quickly, or email, I answered most googled my name, there’s probably not that many. Count. We go back up, so. Yeah.
Jamie
Okay. Yeah. And I mean, I’d like to say just before we wrap up this, this is wonderful. And I feel like I said it last time. It’s a wonderful quote by you at the end of the first edition. As as you don’t, don’t worry if you don’t know any of this stuff, because we’re not born knowing it. Not knowing it is is like the default state. Right? Ask questions and be curious. I really like that, right? Because it’s so easy, especially when you’re a junior to go, Oh, my goodness, I don’t know this. And I don’t know that how am I going to survive? I don’t know what I’m going to do. Don’t worry about it. Right. So as long as you’re curious, and you’re reading the books, and you or you’re watching the videos, or listening to the podcasts or whatever, then you’ll pick it up. Don’t worry, and don’t be afraid of I used to say that. I used to be a teacher. He said, tell the students don’t be afraid of making a mistake. Without being horrible. You’re gonna get it wrong. Right? Because you don’t know. Do you think do you think when you when you, when you when you were a baby and you became a toddler, you just got up and walked know, you stood up and then you fell over? You laughed, then you stood up and you fell over again? Then you stood up and took one or two steps and then fell over again? You’re gonna eventually get it right. Don’t worry about getting it wrong. Focus on getting your focus on when you get it right. And celebrate it celebrate those wins.
Car-Hugo
Oh, yeah, totally. And well, as you said, like, don’t be shy to to ask or say something like, If you don’t know something, don’t act as you do or don’t Don’t feel shy or asking if there’s somebody that can help you? Well, chances are somebody will and will just make you learn that skill faster, you may still fail, but you may still fail less, right? So it is worth doing some time. It’s not easy, especially depending on the culture where you’re at, except like failures is seen as well as a failure. But failure should be seen as as the way to move forward. An opportunity for learning. No, who said that? Somebody said that?
Jamie
It’s great words to live by. That’s that’s what it is. Yeah. Let’s not worry about who said, Hey, let’s just all agree that great words to live by. Well, like I said, Call you good. Thank you ever so much for being on the show. Again. I had a blast. And I know I’ve I’ve learned a whole bunch of stuff. And I’m going to be going out and getting Volume Two of the book, because I’ve only got volume one. So I want to see what’s changed. And as much as I’m messing around with C Sharp 10 and .NET Six on daily basis. There will be things in this book that I have not done I’ve not done before. So let’s do this. Let’s get this book and let’s get it sorted.
Car-Hugo
Great. Yeah, thanks for having me again was great again and let me know like when you read the book Good and bad. That’s good for everyone. Like just if there’s stuff that you like or stuff you don’t like to slip, you know, like, send me a message. Explain to me why, like if you just tell me I hate that. It’s harder for me to understand how I write it.
Jamie
Is that constructive criticism? That’s
Car-Hugo
exactly right.
Jamie
That’s awesome. Well, like I said, Oh, you got he’s been great catching up with you. And, and yeah, I’m gonna go to this new book.
Car-Hugo
Awesome. Well, thank you.
Jamie
Hey, no worries. Thank you ever so much.
The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository
Wrapping Up
That was my interview with Carl-Hugo Marcotte. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.
And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, and to come back next time for more .NET goodness.
I will see you again real soon. See you later folks.