Speaker 1: How'd you like to listen to dot NetRocks with no ads?
Speaker 2: Easy?
Speaker 1: Become a patron for just five dollars a month you
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month will get
Speaker 1: you that and a special dot net Rocks patron mug.
Speaker 1: Sign up now at Patreon dot dot NetRocks dot com. Hey,
Speaker 1: welcome back to dot net Rocks episode two thousand and four.
Speaker 1: I'm Carl Franklin at Averagre Camra and Scott Sobers here.
Speaker 1: We're going to be talking to him in a minute,
Speaker 1: but you might hear him jump in on the intro here,
Speaker 1: because that's what we do now, right.
Speaker 2: Yeah, go to be at least for the next twenty
Speaker 2: or so episode, right, yeah, right, twenty two. I'm a
Speaker 2: little stressed about actually getting to the current history.
Speaker 1: Well well you know the shows won't have that wonderful
Speaker 1: intro again. Well we'll do something, but all right, something.
Speaker 1: I regret to inform everybody that I've got another cold
Speaker 1: luck at you and the gig tomorrow. Nice, just like
Speaker 1: last time. Save your voice, brother, Yeah, I'm gonna save
Speaker 1: it all.
Speaker 2: Right, A I fixed up?
Speaker 1: Or no, you know the best line when I get
Speaker 1: up on the microphone with the band is thank you
Speaker 1: for coming tonight. And tonight's show has absolutely no AI
Speaker 1: and people lose their minds, they roar, I'm sure, all right.
Speaker 1: So being two thousand and four, let's talk about the
Speaker 1: top events or the news events, the major news events
Speaker 1: so that year, unfortunately, we'll start with the Indian Ocean
Speaker 1: earthquake and tsunami. And we remember that, Yeah, I did.
Speaker 1: We did a bunch of fundraising for that, that's right.
Speaker 1: I remember Julie Lherman kind of spearheaded that she.
Speaker 2: Had friends in Bandahar right and needed help. Yeah, so
Speaker 2: they happened to be there. We're just wrapping up a
Speaker 2: charitable project when the tsunami and everyone needs a lot
Speaker 2: of help, and so we all dove in. We did
Speaker 2: a bunch of eBay auctions for time and resources and
Speaker 2: things like that and raised a lot of money.
Speaker 1: I think this might was am I wrong? Or is
Speaker 1: this one of the events that got you to consider
Speaker 1: doing the your charity?
Speaker 2: Yep, it's one of the catalysts of H two Box
Speaker 2: was watching what Julie was able to do, like she's
Speaker 2: such an inspiration mm hm.
Speaker 1: And we're talking about the humanitarian toolbox that Richard spearheaded. Okay,
Speaker 1: the Iraq war an insurgency escalation, So it didn't go
Speaker 1: well at first.
Speaker 2: No, Sadam is now gone right at that point, and
Speaker 2: now that comes the whole you broke it, you bought
Speaker 2: it phase.
Speaker 1: M Yeah, the Abu Grab prisoner abuse scandal. That was
Speaker 1: pretty bad.
Speaker 2: Ye.
Speaker 1: Madrid train bombings I remember this, Yeah, killed one hundred
Speaker 1: and ninety three people. I don't remember it having that
Speaker 1: big of a casualty number, but I guess it did.
Speaker 1: Trains are packed. Yeah, it was a right. Some more
Speaker 1: bad news. Darfur conflict escalated, big humanitarian crisis in Sudan.
Speaker 1: In the US, the presidential election of two thousand and four,
Speaker 1: George W. Bush defeated John Carry to win a second term.
Speaker 1: This September Eleventh Commission Report, which was a detailed report
Speaker 1: on the nine to eleven tax, the US Patriot Act
Speaker 1: reauthorization debates, so people were debating over civil liberties versus
Speaker 1: national security. NSA was big. And I remember interviewing Christian
Speaker 1: Bayer and he said NSA stands for no security anymore.
Speaker 1: Same sex marriage got legal in Massachusetts. Yeah, Mars. The
Speaker 1: Stewart went to jail. Yeah, and it wasn't even that much.
Speaker 1: It was like thirty grand or something something like that. Yeah,
Speaker 1: but insider trading is insider trading. The controversy over Mel
Speaker 1: Gibson's The Passion of the Christ boy, Oh Boy. And
Speaker 1: speaking of other movies, let's go through the top ten.
Speaker 1: National Treasure, which was a great fun movie. Nicholas Cage,
Speaker 1: Nicholas Cage. Yeah, Ocean's twelve, a bad Colooney, which was
Speaker 1: great at all. Think it was still pretty good. Shark Tale,
Speaker 1: which I never saw.
Speaker 2: But well you're not you don't have the little kids
Speaker 2: at that point.
Speaker 1: Well that's true, but I kind of still watched these
Speaker 1: big ones. Troy epic retelling of the Trojan War starring
Speaker 1: Brad Pitt. Brad Pitt is a gladiator. All the women's
Speaker 1: loved it. Day The Day after Tomorrow. I don't remember
Speaker 1: that one, but it was like a change global disaster film.
Speaker 1: And of course The Passion of the Christ to number five,
Speaker 1: The Incredibles number four. I did watch that and it
Speaker 1: was fun, fantastic, It was fun. And you know, my
Speaker 1: youngest daughter was only two years old, so I was
Speaker 1: watching these kind of things. Spider Man two. Okay, how
Speaker 1: much to say about that? Harry Potter and The Prisoner
Speaker 1: of Azba Khan Azkaban oz Kban. This is number two,
Speaker 1: and the number one grossing movie of two thousand and
Speaker 1: four is Shrek two. Yay, Shrek It again, Shrek and
Speaker 1: again and wow, I think Shrek and.
Speaker 2: Is it? Yeah?
Speaker 1: Shark Tail and Shrek were both from DreamWorks. Yeah, and
Speaker 1: they're both the number one, well in the top ten
Speaker 1: of that year.
Speaker 2: Awesome. Interesting forget what about Action's Janet Jackson's wardrobe malfunction.
Speaker 2: Wardrobe malfunction, Yes, at the at the power at Super Bowl. Yeah,
Speaker 2: we don't even remember the year, but that's what happened.
Speaker 1: The funniest part about that was her interview on Letterman
Speaker 1: the next day or whatever, and she was like, it
Speaker 1: just happened. I don't know, so I don't know. You
Speaker 1: guys got anything. I know, Richard, you've got space and technology.
Speaker 1: But Scott, do you remember anything about two thousand and
Speaker 1: four you want to share?
Speaker 3: Ah, Man, I don't know anything off hand. I mean
Speaker 3: I would have been a junior in high school at
Speaker 3: the time, but yeah, well that's an event. Yeah, it's
Speaker 3: almost done with high school all right, tell us about
Speaker 3: space and tech.
Speaker 2: Well, we're in the midst of the Columbia accident investigation.
Speaker 2: Columbia was lost in two thousand and three, so there's
Speaker 2: no Shuttle flying that year while the investigation's ongoing, and
Speaker 2: that means no additional building of the International Space Station easier.
Speaker 2: So the Russians are supporting the space station with progress
Speaker 2: and so used flights to bring cruise down. But there's
Speaker 2: plenty of other things going on at the time. The
Speaker 2: Stardust mission in January actually reaches Comet eighty one p
Speaker 2: wild and collects dust from a comet, which was its
Speaker 2: mission to return to the Earth, which is cool. Also
Speaker 2: in January, the Spirit Rover lands at the Gustev crater.
Speaker 2: Month later, the Opportunity Rover at Murdi and planum So
Speaker 2: and Nose rovers were designed to operate for ninety days. Yeah,
Speaker 2: and one lasted nine years and the other lasted fourteen.
Speaker 2: So for a variety of reasons, mostly to do with
Speaker 2: they got really good at understanding how the very thin
Speaker 2: atmosphere can actually kick up enough wind to blow the
Speaker 2: dust off the solar panels, and so they're able to
Speaker 2: keep clearing the solar panels off and keep the machines running.
Speaker 2: They loose spirit first, because it'll get stuck in sand
Speaker 2: at the wrong angle and ultimately we'll run out of power.
Speaker 2: The issue here for them primarily is to make sure
Speaker 2: they charged with the batteries enough to last overnight, because
Speaker 2: it gets very cold at night and equipment will freeze,
Speaker 2: and so you need to charge the batteries off solar
Speaker 2: panels to generate enough heat to be operational the next day,
Speaker 2: and so you're positioning before nightfall is super important.
Speaker 1: I remember doing a bit with Professor Schmackel on Mondays,
Speaker 1: which also started in two thousand and four. By the way,
Speaker 1: goodness forgot I left that one off the cultural list, Yeah,
Speaker 1: such as it is counter cultural, but yeah, I do
Speaker 1: remember that that happened.
Speaker 2: That was a big deal. Yeah. Also in two thousand
Speaker 2: and four, in June, the first flight of Spaceship one.
Speaker 2: This was Bert Rutan's technology trying to capture the Ansari prize.
Speaker 2: It's a subordable flight, but it does get above the
Speaker 2: Carmen line, and so Mike Melville becomes the first civilian
Speaker 2: astronaut ever in order to win the and sorry, prize,
Speaker 2: we'll have to do it again, which he will in
Speaker 2: September and so demonstrate that a reusable spacecraft. I mean,
Speaker 2: it's funny to think about, but in two thousand and
Speaker 2: four was an incredible breakthrough. Yeah.
Speaker 1: Wasn't the Shuttle supposed to be a reusable spacecraft? Is
Speaker 1: that what you're laughing about?
Speaker 2: Yes, it's also government not civilian. Yeah, And that was
Speaker 2: the whole point. Was privately funded, and that private funding
Speaker 2: was mostly Paul Allen. In July, the Cassini spacecraft, this
Speaker 2: bus size spacecraft flying to Saturn, reaches Saturday and gets
Speaker 2: into orbit round surround, the first thing to ever go
Speaker 2: into orbit around Saturn. And by December we'll release the
Speaker 2: Huygens probe onto Titan, the first time we'll ever soft
Speaker 2: land and the only time so far was soft landed
Speaker 2: anything on Titan.
Speaker 1: And Cassini also the name given by I think it
Speaker 1: was Scott gu three and team to the.
Speaker 2: Web server and visual studio. Okay, Cassini, there was a
Speaker 2: few of them. Messenger is the first spacecraft to go
Speaker 2: into orbit around Mercury. It launches in August of two
Speaker 2: thousand and four. It won't actually get into orbit around
Speaker 2: Mercury till twenty eleven seven years. It'll take longer than
Speaker 2: it takes Cassini to get to Jupiter because it needs
Speaker 2: to slow down so much to actually be able to
Speaker 2: be captured by Mercury that it'll do a flyby of Earth,
Speaker 2: two fly bys of Venus, and three flybys of Mercury
Speaker 2: to slow itself down enough to finally be captured by
Speaker 2: Mercury twenty eleven, and it'll do a complete map of
Speaker 2: Mercury and a bunch of further cool mission.
Speaker 1: See scientists, real folks, it's tricky laws of physics. Yeah,
Speaker 1: not just a good idea.
Speaker 2: And as you get closer to the Sun, it accelerates
Speaker 2: you a lot, so scrapping speed is hard. Finally, in December,
Speaker 2: Voyage Year one, launched in seventy seven or seventy nine,
Speaker 2: reaches the termination shock. That's the point at which the
Speaker 2: solar wind being pressed out from our star is pushed
Speaker 2: back by the interstellar wind, and so he crosses through
Speaker 2: that and we get new information from it. So that's
Speaker 2: all we get from space. Let's talk a little bit
Speaker 2: on the compute side, because I find I feel like
Speaker 2: two thousand and four is more important year than you realize. Okay,
Speaker 2: I would argue that this is the year that we
Speaker 2: recover from the dot com boom, Right, So, I mean
Speaker 2: the dot com boom it sort of ended in two
Speaker 2: thousand and one, and all the money it sort of disappeared.
Speaker 2: It's not like the web or anything went away. But
Speaker 2: I would argue that the harbinger event was Google's IPO,
Speaker 2: So they you know, had been born during the dot
Speaker 2: com boom, but they were in one of the companies
Speaker 2: that did not fail became the fundamental search tool of
Speaker 2: all time arguably still is today, and they were essentially
Speaker 2: forced to IPO they had too many shareholders and the
Speaker 2: SEC required it, so that they went somewhat reluctantly, but
Speaker 2: the response by the market was very positive. It's sort
Speaker 2: of the first good news about the web post dot com.
Speaker 2: This is also the year that O'Riley starts their Web
Speaker 2: two point zero conference where they talk about the focus
Speaker 2: on user contributed content things like wikis and blogs and
Speaker 2: ultimately social media, so how that comes from that. And
Speaker 2: speaking of social media, this is the year that a
Speaker 2: young Harvard student named Mark Zuckerberg starts a website called
Speaker 2: the Facebook. The Facebook. Oh, and also speaking of Google,
Speaker 2: on April first, they launch Gmail and everybody thinks it's
Speaker 2: a joke. Yeah, yeah, why I remember you had to
Speaker 2: thinking you had to be invited to that program. Yeah,
Speaker 2: that's right. It was the longest beta ever and just
Speaker 2: kept going and going and going. That turned out for them.
Speaker 2: On the Intel side, Intel final delivers the EM sixty
Speaker 2: four t on a Xenon. This is based on Dave
Speaker 2: Cutler's Windows on Windows mindset of like can we make
Speaker 2: sixty four bit process? It'll run thirty two bit properly.
Speaker 2: It actually makes sixty four come true because it has
Speaker 2: become the Itanic and so the Zenon No Kona is
Speaker 2: sort of the first towards that Cutler had actually worked
Speaker 2: with AMD first. So AMD had solved this problem and
Speaker 2: now Intel was playing catch up. One would argue this
Speaker 2: is the point where Intel really fell behind. Two thousand
Speaker 2: and four, the year of XP s P two. Oh boy,
Speaker 2: what a year that was. Yeah, one would argue the
Speaker 2: setup for the debacle that becomes Vista. You know, The
Speaker 2: argument here is that it was a breaking change to
Speaker 2: Windows XP, so it should have been XP version two.
Speaker 2: But in back in those days, you charged for a
Speaker 2: new version of an operating system, and Microsoft rannted everybody
Speaker 2: to install SP two, So making it a service pack
Speaker 2: was the right thing to do from a let's get
Speaker 2: this security out into the world perspective, but with lots
Speaker 2: of long term consequences from that yep. Two thou four
Speaker 2: is the year of the final version of fox Pro
Speaker 2: visual fox Pro nine, which had been booted out a
Speaker 2: visual studio as a visual Studio dot net in two
Speaker 2: thousand and two. It's now living on its own, and
Speaker 2: this is the final version of they will Ship. Beth
Speaker 2: Massy wasn't happy, No, none of the They can't really
Speaker 2: blame him, it's fair now. Two thousand and four is
Speaker 2: the year that Miguel diac has a Ship's the first
Speaker 2: version of Mono. He'd announced it in two thousand and
Speaker 2: one at another O'Reilly conference that he thought it was
Speaker 2: a good idea and effectively destroyed his career because all
Speaker 2: the Microsoft people are like, are you that Linux guy?
Speaker 2: And all thewis people are like, don't you work with
Speaker 2: Microsoft technology? So he couldn't win. It's hard to be Miguel,
Speaker 2: But yeah, that's the first time Mona comes out. Another
Speaker 2: important open source product Ruby on rails. In July, David
Speaker 2: Heinemeier Hansen DHH, who is a very controversial figure today,
Speaker 2: certainly guy behind base Camp. Takes an old language from
Speaker 2: the nineties Ruby that nobody cared all that much about,
Speaker 2: combines it with a scaffolding he calls rails and makes
Speaker 2: a phenomenal an old web tool, and again we talk
Speaker 2: about the rebirth of the web, reinterest in the web.
Speaker 2: Ruby all rails became this incredible prototyping tool for building
Speaker 2: websites fast. Yeah. People thought of it as like visual
Speaker 2: basic for the web. Yeah really, and you know, build
Speaker 2: it up, tear it down, just give data off you go.
Speaker 2: It was amazing. And I'm gonna mention two games only
Speaker 2: because I think they're profoundly important in gaming even today.
Speaker 2: This is the year that World of Warcraft launches under Blizzard,
Speaker 2: so that massive multiplayer game. It's still ongoing today. Wow
Speaker 2: and Wow from Valve Half Life two, and that's all
Speaker 2: I got.
Speaker 3: All right, I got I got one from two thousand
Speaker 3: and four tech related me. Firefox got released.
Speaker 2: So yeah, they they came out. It was no longer Phoenix,
Speaker 2: right as the first version was called Phoenix. Then they
Speaker 2: found oh you can't call it Phoenix, so they rebranded
Speaker 2: as Firefox. In two thousand and four.
Speaker 3: Yeah, and I don't think Firebug wasn't out at the time,
Speaker 3: but I did credit Firefox for like the developer tools
Speaker 3: that we have today in inspiring that with fire firebugg.
Speaker 1: So what about Firebase. Was that part of that whole
Speaker 1: thing or is that a separate thing part of the
Speaker 1: suite as well?
Speaker 2: All right, you're right. It does tie you into my
Speaker 2: larger message of this is the webabilitating because what the
Speaker 2: Mozilla Foundation was doing was building real dev tools for
Speaker 2: web devs. You weren't just hacking away like your ability
Speaker 2: to work in fire I was not necessarily a Firewok
Speaker 2: Fox fan, but if you had to build a web
Speaker 2: page and you weren't using Firefox, you were just torturing
Speaker 2: yourself like they figured out all F twelve before everybody else. Yep, yeah,
Speaker 2: like that's where that came from. Good enough that everybody
Speaker 2: copied it. All right, are we ready for better? No framework,
Speaker 2: Let's do the thing with the stuff, roll the music?
Speaker 3: All right, man?
Speaker 2: What do you got? All right?
Speaker 1: Well, although he didn't write it, our friend Simon Kropp
Speaker 1: brought this to my attention.
Speaker 2: I'm shocked Shock has done. This is cool.
Speaker 1: This is a Windows Defender performance tool interesting. It's a
Speaker 1: dot net application that monitors Windows Defender ETW events and
Speaker 1: visualizes scan durations in real time using a stacked bar chart.
Speaker 1: It can also visualize snapshots recorded offline with the PowerShell
Speaker 1: command lit and so listens to the Anti Malware Engine
Speaker 1: stream scan request tasks, stop ETW events, displays the scan
Speaker 1: durations per process, and a stacked bar chart. This is
Speaker 1: all real time. You can drag and drop files or
Speaker 1: folders onto the window to trigger an immediate scan of
Speaker 1: the dropped items and export to CSB when more than
Speaker 1: one snapshot is dragged to the window. It's all I know.
Speaker 1: It looks really cool. It's MIT licensed, and you know that.
Speaker 2: I think.
Speaker 1: There's an urgency about knowing what threats are out there
Speaker 1: as soon as possible, because by the time you see it,
Speaker 1: you're vulnerable.
Speaker 2: ILS argue that people blame Defender for performance problems all
Speaker 2: the time, and this is a tool that surfaces this
Speaker 2: is what Defender's actually doing. Yep.
Speaker 1: So it's very very cool. And Defender should always be on.
Speaker 1: If you ask me, that's you have to fight to
Speaker 1: turn it off.
Speaker 2: Yeah, right, And it's on by default mostly you know,
Speaker 2: the average mortal has it on, doesn't even know it
Speaker 2: doesn't even know, right, I think for us in dev,
Speaker 2: because we torture our machines, so you're often looking for
Speaker 2: like what's eating up all the resources? And let's be clear,
Speaker 2: you dump, especially new executables that you have generated that
Speaker 2: are unsigned. You trigger a defender when you do that,
Speaker 2: and sometimes those things can really hit a lot of cycles.
Speaker 1: Yeah, so hats off to Alexander Eulatin for putting this
Speaker 1: out there.
Speaker 2: Go get it. I'm gonna awesome. So who's talking to
Speaker 2: us today? Richard grad to comment off a show two thousand?
Speaker 3: Wow.
Speaker 2: Yeah, we published two thousand episodes. When do you know
Speaker 2: what a great show? And Aaron Old said, this podcast
Speaker 2: has been my longest continually listened to podcasts. The information
Speaker 2: that you have shared has been instrument to my twenty
Speaker 2: five plus year career in dot net. I remember the
Speaker 2: first time that one of my comments was read on
Speaker 2: the air. I was driving to work and I had
Speaker 2: to pull off on the road in the parking lot
Speaker 2: and listen to Richard read my comment. I was so excited.
Speaker 2: I do hope you guys continue to do the good work. Yeah, well,
Speaker 2: there you go eron, I read another one, so don't crash.
Speaker 2: Yeah right, it's gonna be fine, it's gonna be fun.
Speaker 2: Everything's okay. Yeah, and thanks so much for sticking with us,
Speaker 2: because we've been we're still doing this thing somehow Sometimes
Speaker 2: I wonder how all right? Yeah, two thousand shows in
Speaker 2: so thank you so much for your comment. And a
Speaker 2: copy of music co buy is on its way to you.
Speaker 2: And if you'd like copy of musicobe I read a
Speaker 2: comment on the website at dot NetRocks dot com or
Speaker 2: on the facebooks publish every show there. And if you
Speaker 2: comment there and to reading the show, well, I do
Speaker 2: you copy music?
Speaker 1: Go buy music to code by dot net if you
Speaker 1: want to just go get it? Okay, nice, go get it.
Speaker 2: Good link.
Speaker 1: So let's introduce Scott. You heard from him before just
Speaker 1: recently a couple of things. Scott Sober is the director
Speaker 1: of Engineering at Lean Techniques, a consultancy of about one
Speaker 1: hundred and seventy people based in the Midwest. Besides advising
Speaker 1: clients and delivering solutions for them, he enjoys helping teams
Speaker 1: realize their potential through technical practices and working more effectively together.
Speaker 1: He's a Microsoft MVP a Redgate Community Ambassador, international speaker,
Speaker 1: dome train author. He co organizes the Iowa dot Net
Speaker 1: User group and co organizes the Iowa Code Camp. You
Speaker 1: can find him pretty much anywhere online at Scottsaber. Welcome Scott.
Speaker 3: Yeah, thanks for having me, guys, first time, right it is.
Speaker 3: It is my first time. So excited to be here.
Speaker 2: Awesome. We've seen each other at the conferences for many,
Speaker 2: many years, so sorry about that. Shouldn't have been this lot,
Speaker 2: But I think his talk You've got is really cool,
Speaker 2: Like it's such a good idea to just sort of
Speaker 2: have a I gues you call it a checklist of
Speaker 2: things you're going to do in a dot net app.
Speaker 3: Yeah, totally, and uh yeah, just fair warning. This might
Speaker 3: be a little bit of a dense show of just
Speaker 3: random fire of different tips, but hopefully people will be
Speaker 3: able to walk away with something that they and literally
Speaker 3: take and apply immediately after the show.
Speaker 2: So it's called nutritional value.
Speaker 1: Unlike what we just did for the last twenty minutes.
Speaker 3: Dark here comes to Broccoli, right, Yeah, well where do
Speaker 3: we start?
Speaker 2: All right? All right?
Speaker 3: You go, Yeah, so probably one of the first things
Speaker 3: I talked about, and I know you guys have had
Speaker 3: people on the show talking about this topic is around
Speaker 3: feature folders. So I'm a big fan of organizing my
Speaker 3: code around feature folders as opposed to the traditional kind
Speaker 3: of way. So to kind of talk through that, a
Speaker 3: lot of people are familiar with, like you know, you
Speaker 3: might have like a data project or like you know,
Speaker 3: repository services, and like those all kind of live in
Speaker 3: different folders. You know, if you're doing NBC and rendering
Speaker 3: that on the server, you got like your views folder,
Speaker 3: your controllers folder, models folder.
Speaker 2: And just the way you don't look for anything exactly right.
Speaker 3: Yeah, So anytime you need to add a feature, you
Speaker 3: got to go touch upwards of you know, five ten
Speaker 3: folders just to add a feature. And if you want
Speaker 3: to delete a feature, now you got to go find
Speaker 3: it everywhere too, and it's just kind of scattered. So
Speaker 3: future folders kind of flips that on its head, and
Speaker 3: rather than organizing by like type of things, rather than
Speaker 3: having like a model's folder, controllers folder, you organized by feature.
Speaker 3: So let's say you've got my profile feature for instance,
Speaker 3: anything to do with that feature goes in a folder
Speaker 3: called my profile, so it's all kind of co located together.
Speaker 3: It's very easy to see at a glance what your
Speaker 3: features are, and so we want that code by future.
Speaker 1: Yep, it makes sense really. I mean it's kind of
Speaker 1: like we do that with projects, right. We have projects
Speaker 1: that are based you know, components or DLLs or whatever,
Speaker 1: they are based on what they do, and just take
Speaker 1: it another step inside those projects organizing feature folders.
Speaker 2: Yeah.
Speaker 3: Great, So I kind of use the analogy if in
Speaker 3: case somebody still thinks that this is like heresy, I
Speaker 3: challenge people think about, Oh.
Speaker 2: It's it's heresy, but it's good heresy.
Speaker 3: Yeah, exactly. If you think about like your house or
Speaker 3: your apartment or wherever you live, think about where you
Speaker 3: keep the soap in your house, Like do you have
Speaker 3: a closet full of all the different soap like hand soap, shampoo,
Speaker 3: body soap, dishwasher soap. Yeah, probably not. You probably keep
Speaker 3: that soap close to where it's used, Like you keep
Speaker 3: the hand soap by the sink, the shampoo in the shower,
Speaker 3: and so you use it where it's most used. You
Speaker 3: don't just have a soap closet you go reach into
Speaker 3: to go grab the soap.
Speaker 2: So God, I love the idea of a soap closet, the.
Speaker 1: First time I heard about feature folders, I was just like, duh,
Speaker 1: why didn't I do that? You know, it's it's just
Speaker 1: makes your life easier.
Speaker 2: Any any gotcha's what do you have to do to
Speaker 2: make feature folders work?
Speaker 3: Well, honestly, not a whole lot. I mean, if you're
Speaker 3: doing like server rendered NBC or raise the pages, is
Speaker 3: just a slight change you need to do to have
Speaker 3: a go look in that folder. But it's usually one
Speaker 3: liner to add that. I've got a blog post on
Speaker 3: how to do that, so we could drop that in
Speaker 3: the show notes in case people are interested. But otherwise,
Speaker 3: if you're just building an API, it should just work.
Speaker 2: Yep.
Speaker 3: So there's nothing magic about a controller's folder, for instance,
Speaker 3: as long as you are you know, there's a few
Speaker 3: different ways that can discover it. Whether you know it
Speaker 3: has the API controller attribute or the suffix of the
Speaker 3: classes controller, it'll find it that way. So there's really
Speaker 3: nothing magical about these folders for the most part, other
Speaker 3: than in like server rendered NBC.
Speaker 1: So how many folders deep like you do you have
Speaker 1: like my profile and under that controllers or do you
Speaker 1: just have the if you have one or two controller files,
Speaker 1: you just put them right there.
Speaker 3: Yeah, that's that's a good question. Usually I'll I won't
Speaker 3: start with nesting more folders underneath that until I find i,
Speaker 3: you know, starting to get tons of files in there
Speaker 3: and things like that. Yeah, it just kind of depends.
Speaker 3: But a lot of times I'll just kind of put
Speaker 3: things in there, and usually it's not more than you know,
Speaker 3: four to six files or so. So I find that
Speaker 3: usually pretty easy to manage.
Speaker 2: Very good, cool, good stuff.
Speaker 3: That's number two, all right, moving on to number two.
Speaker 3: So this is treat warnings as errors.
Speaker 2: Look at your believer.
Speaker 3: You being consultant, you get dropped into different projects all
Speaker 3: the time, and it's always not the best experience when
Speaker 3: you pull down a project for the first time you
Speaker 3: build it and there's like hundreds or even thousands of
Speaker 3: warnings of compiler warnings that you know, you're like, okay,
Speaker 3: which ones of these are valid? Which ones are not?
Speaker 3: I don't know what to do, And so I like
Speaker 3: treating warnings as errors. And so basically warnings don't exist
Speaker 3: in my world. It should either be something that I
Speaker 3: fix or something like I explicitly ignore because for whatever
Speaker 3: reason that warning is invalid.
Speaker 2: It's not necessary. Yeah, I mean and to your point there,
Speaker 2: it's more about don't be blind to the warnings that
Speaker 2: are actually important. So when you leave all those warnings on,
Speaker 2: you ignore them all correct, Yeah, because.
Speaker 3: A lot of times you're getting those warnings and there's
Speaker 3: something that's going to happen, might not be right away.
Speaker 2: Yeah, like there deprecation warning.
Speaker 3: Yeah, that you should be making the change to actually,
Speaker 3: you know, go go fix whatever the thing is.
Speaker 2: So yeah, often those warnings suddenly become real errors when
Speaker 2: you move up a version of the framework because there
Speaker 2: were a deprecation warning has been going on for like
Speaker 2: three versions that you've been ignoring you and would have
Speaker 2: been easy to fix yep at some point.
Speaker 3: And that's as simple in case people are wondering, that's
Speaker 3: a simple as going in your csprog and there's a
Speaker 3: treat warnings as errors flag and you just split that
Speaker 3: to true in the XML.
Speaker 2: So that's very good.
Speaker 3: As simple as that.
Speaker 2: Awesome cool.
Speaker 3: So the third one is authorization using something called fallback
Speaker 3: policy in asp DO core. So let's talk about why
Speaker 3: the why first before we get into the what it is.
Speaker 3: So the problem is, by default, ASPI core security is
Speaker 3: opt in, meaning if you're doing controller, you got to
Speaker 3: add an authorized attribute and have to remember to do that,
Speaker 3: or in minimal APIs you have to remember to say
Speaker 3: like require authorization on a minimal API, and if you forget,
Speaker 3: now that API is exposed to the whole world, which
Speaker 3: is obviously not great. And so instead what I want
Speaker 3: is secure by default. So with something called the fallback
Speaker 3: policy and ASP do core. The idea there is, if
Speaker 3: you haven't specified anything else, you apply this fallback policy.
Speaker 3: So you can set the fallback policy to say, hey,
Speaker 3: require an authenticated user, and so at least you have
Speaker 3: to be logged in to hit that API or or
Speaker 3: whatever the case is. Or you know, if you are
Speaker 3: building like Razor pages or Blazer app, you have to
Speaker 3: be logged in to hit that page. Now, you can
Speaker 3: still opt out, so you can add like an allow
Speaker 3: anonymous attribute on a controller, endpoint, or whatever the case is,
Speaker 3: and that will take precedence over the fallback policy. The
Speaker 3: fallback policy is basically like, hey, if you didn't add
Speaker 3: anything else, this is what security policy is going to run.
Speaker 3: So by default you're secure and you can always add
Speaker 3: more security saying hey, you have to be an admin
Speaker 3: to hit this endpoint or whatever the case.
Speaker 2: Is if you have no fallback policy, is it fallback
Speaker 2: then no security?
Speaker 3: Correct?
Speaker 2: Yes? Yi?
Speaker 3: So that's that's the default in ASPI core because it
Speaker 3: doesn't know what you want to do, and so this
Speaker 3: kind of flips that on its head. And it's really
Speaker 3: just like a one liner. When you're setting up authorization,
Speaker 3: you can just say, hey, set the fallback policy to
Speaker 3: require authenty kid, you use her right?
Speaker 2: Good? Yeah, that's a good fault.
Speaker 3: Yep, all right. Next one logging best practices. So, uh,
Speaker 3: just see a lot of people who uh spray logs
Speaker 3: and don't really know what what it is that they're doing,
Speaker 3: or you know, they go to the hitting exception and
Speaker 3: suddenly they don't have all the information that they need.
Speaker 3: And I'm not going to get into like open telemetry
Speaker 3: and things like that because it's like its own show
Speaker 3: and whatnot. More so, just I use a package called saraalog.
Speaker 3: It's really popular.
Speaker 2: Great the donet I.
Speaker 1: Use it too, ye, And you'll serialize your objects and
Speaker 1: put them in the log messages.
Speaker 3: Yep, yep for sure. And yeah, so I'll do like
Speaker 3: the structured logging you're talking about, and so you can
Speaker 3: like query off those things. So like basically you can
Speaker 3: write essentially SQL like queries saying like, hey, grab me
Speaker 3: all the logs from this user, and you don't have
Speaker 3: to like search through strings and things like that.
Speaker 2: Yeah. Right, it's really good game changer.
Speaker 3: Yep, and sarah loogs got a good feature in pretty
Speaker 3: much every logging framework out there has this feature too,
Speaker 3: of you can add certain properties to every single log.
Speaker 3: So for instance, you might want the user.
Speaker 2: ID yep, yeah, you want the user yes.
Speaker 3: Or like whatever point are they trying to hit? Or
Speaker 3: you know what version of the app is deployed. Is
Speaker 3: also another thing that's useful because let's say you fix
Speaker 3: something and ship it out. You can say like, okay,
Speaker 3: do I have any exceptions from this latest version I
Speaker 3: just deployed out?
Speaker 1: And so I typically use a class that I write
Speaker 1: around zero log that had that takes a dictionary of
Speaker 1: strings as parameters, so a string string dictionary.
Speaker 2: Right. So right there in.
Speaker 1: The you know, in the catch, you add the parameters
Speaker 1: that you want to put in there, which might include
Speaker 1: the objects or you know.
Speaker 2: The things that you were for. First of all, the
Speaker 2: thing that you were.
Speaker 1: Calling is in there, but you know, all the detai
Speaker 1: that one would need to make intent intentional queries yep, yeah.
Speaker 3: And Sarah loog so yeah, Sarah logs, yeah, log context
Speaker 3: you can slap uh slap those things together too, so
Speaker 3: on every log statement you don't. You kind of just
Speaker 3: get those things for free, which is pretty nice. So
Speaker 3: so yeah, that's some logging best practices. But I kind
Speaker 3: of want to transition into like this concept of logs.
Speaker 3: Sometimes I hear like, let's say we're doing some refinement
Speaker 3: or something and talking like, oh, yeah, we should log
Speaker 3: that piece of information, And I think there's a subtle
Speaker 3: difference between like logging versus metrics versus audits. And again
Speaker 3: I'm not going to get into open telemetry stuff, but
Speaker 3: technically sarah log does not guarantee delivery, meaning a lot
Speaker 3: of that a lot of times depending on what they
Speaker 3: call sinks, which is kind of like your end destination,
Speaker 3: like are you sending this to measure or where wherever
Speaker 3: you're sending it to. They don't guarantee delivery, so like
Speaker 3: they might depending on your settings, they might buffer those
Speaker 3: messages and memory. So what happens if the app suddenly
Speaker 3: crashes when all that stuff was in memory? Now all
Speaker 3: of those logs are gone. Yeah, and did not actually
Speaker 3: get flushed out, and so there's no guarantee of delivery,
Speaker 3: which is fine if you're using logs as they're meant
Speaker 3: to be used, which is like more of a developer tool,
Speaker 3: But if you're using it for like a replacement for
Speaker 3: like an audit tracking or audit logs, that's the problem.
Speaker 2: And right, so it's almost it a log everything except
Speaker 2: you accept the stuff you needed to understand what happened. Yeah.
Speaker 1: So with the logging system, though, can't you set up
Speaker 1: multiple sinks? Like you could have it right locally to
Speaker 1: a file so so it's there, and then on top
Speaker 1: of that you would have you know, some process to
Speaker 1: get it to another place that might you know, need
Speaker 1: to use poly or something. Yep, make sure it goes.
Speaker 3: Yeah, I just see some people like let's say you
Speaker 3: have a user management system and you want to log hey,
Speaker 3: who added who adds a user, changed the role or
Speaker 3: whatever the case is. Technically Sarah Loog's not going to
Speaker 3: guarantee that you get it to the place you set
Speaker 3: it too, so like instead you should just use it
Speaker 3: a good old fashioned audit table or something like that
Speaker 3: that has more guarantees around those things. And I've been
Speaker 3: in the healthcare industry at various points, and like they
Speaker 3: have some laws around like HIPPA that you have to
Speaker 3: keep data around for sure seven years, and so it's
Speaker 3: really not good if you don't keep that data around
Speaker 3: for seven years. And that's another problem with logging if
Speaker 3: you use audits as logs is your logging system might
Speaker 3: only keep things around for like thirty days or a
Speaker 3: year or something like that. So that's like another thing.
Speaker 3: You got to kind of consider the data store that
Speaker 3: you're using there.
Speaker 2: Yeah, it's usually a circular store and it has it's
Speaker 2: limited by space or time whatever that may be. Is
Speaker 2: also where you should call your friendly system men, who
Speaker 2: is also responsible for how long that stuff should be stored.
Speaker 2: So even if you are in a thirty day rotation,
Speaker 2: we take a snap of it periodically so that we
Speaker 2: have another copy somewhere. Like, yep, they have conversations. You're
Speaker 2: not the only one of this problem. Yep.
Speaker 1: This seems like a good place to take a break
Speaker 1: and we'll be right back after these very important messages
Speaker 1: don't go away. Hey Carl here, you probably know text
Speaker 1: control is a powerful library for document editing and PDF generation,
Speaker 1: But did you know they're also a strong supporter of
Speaker 1: the developer community. It's part of their mission to build
Speaker 1: and support a strong developer community by being present, listening
Speaker 1: to users, and sharing knowledge at conferences across Europe and
Speaker 1: the United States. So if you're heading to a conference soon,
Speaker 1: check if text Control will be there and stop buy
Speaker 1: to say hi. You can find their full conference calendar
Speaker 1: at dubdubdub dot textcontrol dot com and make sure you
Speaker 1: thank them for supporting dot NetRocks.
Speaker 2: And we're back. It's dot net Rocks.
Speaker 1: I'm Carl Franklin, that's Richard Campbell eight and we're talking
Speaker 1: to Scott Sober with his ten things that he does
Speaker 1: in every dot net project.
Speaker 3: Yeah, stealing something from David Letterman.
Speaker 1: I guess, and I think we're on four or five?
Speaker 1: Are we on five?
Speaker 2: Or six? Where are we?
Speaker 3: We've gone through five? Now we are non number six?
Speaker 3: So how about that six to one? Is we? I
Speaker 3: like to do validation with a library called Fluent Validation,
Speaker 3: so out of the box, uh you it's kind of
Speaker 3: I don't know, encouraged to use something called data annotations,
Speaker 3: which are just like little attributes saying hey, this field's required,
Speaker 3: and things like that when you're let's say you're taking
Speaker 3: in a form and you're someone signing up and you
Speaker 3: know their first name, last name, email, all that kind
Speaker 3: of stuff is required. Like data notations work well for
Speaker 3: those scenarios, but I find making custom ones when you
Speaker 3: have more advanced scenarios is a little awkward to make.
Speaker 3: Like let's say you're taking their birth date and you
Speaker 3: know they have to be above a certain age to
Speaker 3: sign up for the website. That's not out of the
Speaker 3: box and something customer you'd have to make, and that
Speaker 3: gets a little awkward. With data annotations, Yes, they're also
Speaker 3: hard to unit test. If you want to get really particular,
Speaker 3: you could argue the single responsibility principles violated because like
Speaker 3: you're kind of mixing your model business rules that you
Speaker 3: have with your validation. Yep. So instead, I like using
Speaker 3: fluent validation, which allows you to kind of separate your
Speaker 3: model from your validation, and it basically gives you this
Speaker 3: fluent like syntax, so you can say, like, hey, first
Speaker 3: name should not be empty, and you can write customer
Speaker 3: rules super easily. They read super nice, And I've even
Speaker 3: given the rules like literally screenshotted the c sharp and
Speaker 3: send it to a business person said hey, are these
Speaker 3: rules right, and they're like, yep, that's good.
Speaker 2: It all makes sense and they can read them. Yeah, yes,
Speaker 2: it makes sense to them, versus that's.
Speaker 3: Important showing them like, you know, attributes and things like that,
Speaker 3: and it's like, good luck with that. And so Flume
Speaker 3: validation also has a test helper built in too, so
Speaker 3: you can write automated tests around it super easily. So
Speaker 3: I really like Fluent validation for this.
Speaker 1: Was a better no framework a couple of years ago,
Speaker 1: and yeah I love it.
Speaker 2: Yep, yeah, cool, just a better way think about the problem. Yeah, sure, awesome.
Speaker 3: All right, Numero seven, we're going to talk about just
Speaker 3: generic coding guidelines. So you can probably make the argument
Speaker 3: there's like twenty five plus tips in here, but total,
Speaker 3: but I'm going to kind of bucket all these into
Speaker 3: generic coding guidelines. So, okay, I try and structure my
Speaker 3: methods where I put the happy path at the bottom
Speaker 3: of a method. And part of the reason for that
Speaker 3: is I don't like having to scan like a new
Speaker 3: code base, like what what does this method even do?
Speaker 2: Right?
Speaker 3: And let's say it's one hundred lines long and somewhere
Speaker 3: at lines sixty to seventy is the happy path of
Speaker 3: what went well? Like everything went right right? This is
Speaker 3: this is what this method does.
Speaker 1: Don't nest your success states, yes, and then get into
Speaker 1: something that's tabbed in you know, eight tabs or something exactly.
Speaker 1: You do your centuries, you return if you need to return,
Speaker 1: and at the bottom happy path yep.
Speaker 3: Yeah, don't test if it have nested if ELS's do
Speaker 3: early returns like you said, so you know, if let's
Speaker 3: say I've got an endpoint. If I'm if the request
Speaker 3: isn't valid, I'm going to bomb out and return a
Speaker 3: four hundred. If I'm not authorized, I'm a bomb out,
Speaker 3: returning forbidden, whatever the case is, and then kind of
Speaker 3: get to my happy path.
Speaker 2: It's just just a legibility thing that it's easier to
Speaker 2: see the correct path out if you put it at
Speaker 2: the end.
Speaker 3: Yes, and it forces you into that early return pattern
Speaker 3: that Carl was talking about, where you kind of bomb
Speaker 3: out if things aren't aren't good, versus that nested success
Speaker 3: case like oh I am valid, oh I am authorized? Okay,
Speaker 3: now let's do the thing.
Speaker 2: Well what about this? What about that? Yeah, fail early
Speaker 2: and often and only succeed at the.
Speaker 3: End and the kind of way I think about this
Speaker 3: too is a principle called the indentation proclamation. Now, if
Speaker 3: you google that, that doesn't exist. I made it up
Speaker 3: just to honest indentation proclamation.
Speaker 2: Nice.
Speaker 3: But the idea is the more indented your code is
Speaker 3: usually the harder it is to read. If you have
Speaker 3: nested if statements, if you have nested loops, all those
Speaker 3: kinds of things. So I try and avoid.
Speaker 2: Psychlomatic complexity yep. Not good, yep.
Speaker 3: And then I just have some like generic warning lights
Speaker 3: and not hard and fast rules. Now I'm about to
Speaker 3: offend somebody if I haven't already is and these are
Speaker 3: not like hard stops. Just like when I get over
Speaker 3: this number, I start to think, hmm, is there a
Speaker 3: better way to do this? Should I break this out?
Speaker 3: So classes that get, you know, a few hundred lines long,
Speaker 3: I start to think, like, hm, could I start breaking
Speaker 3: this out methods? Over twenty lines? I start thinking, hey,
Speaker 3: can I break this out? If people are using regions?
Speaker 3: I am not a regions fan, and I feel like
Speaker 3: when somebody uses a region, I feel like Clippy should
Speaker 3: pop up in their ID and say, hey, you're trying
Speaker 3: to use a region? Did you mean to add a
Speaker 3: new class or method instead, because we already have these
Speaker 3: code organization tools called classes and methods, and a lot
Speaker 3: of times I see people use regions when they really
Speaker 3: should have reached for a new class or method.
Speaker 2: And covering up code. Yeah, so fair.
Speaker 3: I know there's some region fans out there, so I
Speaker 3: know I offended somebody out there with with that. So
Speaker 3: sorry in advance opinions defense, yep. And it's also getting
Speaker 3: into the point. I mean we're kind of talking AI.
Speaker 3: We briefly talked about AI earlier, but I mean, some
Speaker 3: of these things are kind of interesting as we started
Speaker 3: to get into a world of how much does code
Speaker 3: quality matter? And I'm still in only in the camp
Speaker 3: of it does, but as agents are writing more and
Speaker 3: more of our code, I think it's.
Speaker 2: An interesting including more and more of our test Yes.
Speaker 3: I think it's a kind of an interesting question. I
Speaker 3: know Uncle Bob who wrote the Clean Code Book, who
Speaker 3: he tweeted out saying that he's actually not looking at
Speaker 3: the code that he's generating anymore, which I thought was interesting.
Speaker 3: But he is writing like he has code coverage enforcement
Speaker 3: he enforces like cyclomatic complexity constraints and those kinds of things,
Speaker 3: so he has a lot of automation around those things
Speaker 3: to enforce code quality. So he says, if passes all
Speaker 3: those things, then I'm not actually looking at what the
Speaker 3: agent generates. I'm not quite there yet, but I understand
Speaker 3: how some people are starting to get there.
Speaker 2: I've had a few folks say I never got to
Speaker 2: one hundred percent code coverage until I had automation to
Speaker 2: generate tests. Yep, humans won't create one hundred percent code coverage,
Speaker 2: but you can torment in the LLM to do it.
Speaker 3: Oh, yeah, for sure. And honestly that those like writing
Speaker 3: the test is a good way to keep AI on
Speaker 3: track because I've had lots of times where uh, you know,
Speaker 3: it makes a change and it unintentionally broke something, but
Speaker 3: like it just auto fixes it and I don't have
Speaker 3: to tell it to fix it. It just detected. Hey, reran
Speaker 3: the test and this is broken. So yeah, we'll get
Speaker 3: into tests on a little bit where I'll talk about
Speaker 3: that too. Okay, cool, So that's number seven. Let's move
Speaker 3: on to number eight. Modern solution files. So solution files
Speaker 3: and dot net. If you've ever cracked one of those suckers,
Speaker 3: open it looks a little I don't even know what
Speaker 3: the format is. It's like a tabbed format and things
Speaker 3: like that. So back in the dot nine time frame
Speaker 3: they actually released a modern solution style format. The format
Speaker 3: is modern, which means it's XML, right, so modern, yes,
Speaker 3: but I actually like it. So basically it takes your
Speaker 3: like twenty lines of like GUIDs and things like that
Speaker 3: that you didn't necessarily read, and it turns it into
Speaker 3: like three lines just saying hey, I'm referencing this project
Speaker 3: in the solution, so cleans it up a little bit
Speaker 3: as well as it prevents some merged conflict.
Speaker 2: And you're talking about sl.
Speaker 3: N X right, yes, yep, the sl nx format, So yeah,
Speaker 3: it'll change your file format s l n x. And
Speaker 3: if you want to migrate from an sl N file
Speaker 3: to sl n x, it's just a dot Net SLN
Speaker 3: migrate at the command line and boom you're migrated over.
Speaker 2: Nice. Yeah, I remember that. I'll go find the old
Speaker 2: blog post about that. It's a good format.
Speaker 3: Yep. So we got modern cs prog files a few
Speaker 3: years back with dot dot net Core, and now we've
Speaker 3: got modern solution files.
Speaker 2: So that's cool. Yeah, nice, Yeah, do love the idea
Speaker 2: of associating modern and XML.
Speaker 3: That's all right. So ninth one is kind of an
Speaker 3: obscure feature called validate on build and what this means
Speaker 3: and it's not build as in compiling of your app.
Speaker 3: It's build as in building of the dependency injection container
Speaker 3: and asp dow it core. So basically make sure that
Speaker 3: the lifetime of your things that you register match what
Speaker 3: they should be. So what I mean by that is
Speaker 3: a singleton can only depend on singletons, otherwise it's not
Speaker 3: a singleton. So let's say you've got a singleton that
Speaker 3: takes in a dB context, which is a scope to dependency.
Speaker 3: Now you have this problem where that scope dependency is
Speaker 3: trapped in that singleton, and it's what's known as the
Speaker 3: captive dependency problem, which it might not be a huge
Speaker 3: deal depending on what your dependency is doing, but like
Speaker 3: in a dB context case, it might leave a connection
Speaker 3: open or leave a leak something, depending on what code
Speaker 3: that you're doing. So this validate on build setting basically
Speaker 3: forces ap on corea check to make sure that you
Speaker 3: don't get into that situation. And this will happen by
Speaker 3: default if your local environment is called development, so you
Speaker 3: might see this. It basically throws an error, won't even
Speaker 3: boot your application. But if you don't have your environment
Speaker 3: set to development, like let's say you change it to
Speaker 3: dev or local for whatever reason, this won't run. So
Speaker 3: there's a flag off of Vieus service provider that you
Speaker 3: just say validate on build true, and now it will
Speaker 3: always validate.
Speaker 2: So interesting. Yeah, that's good, and so it'll when you
Speaker 2: have to build, now just generate an error correct yep.
Speaker 3: So when you go to run your application, it will
Speaker 3: just basically not even boot the application because it's you're
Speaker 3: in an invalid state. So sometimes this can cause little
Speaker 3: small ears and production that you can't really explain, like
Speaker 3: the connection lead problem or something like that.
Speaker 2: So yeah, but you got to Yeah, you go from
Speaker 2: random random error sometimes the hard ones to hunt down
Speaker 2: to No, I will not build for you because you
Speaker 2: have done this thing, yep, and you've got to go.
Speaker 2: You've got to do a refactor here, architect differently. Don't
Speaker 2: invoke inside that singleton like you're going to create trouble. Yep.
Speaker 2: That's right. I appreciate that.
Speaker 3: All right.
Speaker 2: They seem like good defaults, like they should have been
Speaker 2: on in the first flip in place, right.
Speaker 3: I know, I think. I think part of the problem
Speaker 3: is like the validate on build setting didn't get added
Speaker 3: until later in a sped on it core, And I
Speaker 3: think they didn't want to break people even though yeah,
Speaker 3: they're kind of you know.
Speaker 2: They're running in traffic.
Speaker 3: Potentially broken in production. Yeah, yeah, not realize it.
Speaker 2: So yeah, I know, he's exactly that. Like you've been
Speaker 2: running a piece of software that randomly crashes and you've
Speaker 2: probably even covered up the crash, right, You've got to
Speaker 2: reboot mechanism, things like that, and just not realizing, no,
Speaker 2: you have an architectural problem that Valuide don't build would
Speaker 2: have told you. Yep, yeah, all right, good stuff. But yeah,
Speaker 2: I appreciate that Microsoft doesn't want to break code.
Speaker 3: Yeah for sure, and we've all benefited from that mindset.
Speaker 3: It's just sometimes the trade off happens where right now
Speaker 3: they don't change a default that they should have changed.
Speaker 2: A long time ago. Yeah, I mean it also if
Speaker 2: they do turn it on by default, then it creates
Speaker 2: a bunch of tex support costs for them they don't
Speaker 2: want to incur, as well as anger. It's the right choice.
Speaker 2: Don't move up to this version of dot net because
Speaker 2: my app now crashes. It's bad, right.
Speaker 1: I think backward compatibility is their number one, I think,
Speaker 1: and I think that's good. Yeah, so you have to
Speaker 1: do a couple of things to get you know, working
Speaker 1: better or you're working better. It's always a wrestling match
Speaker 1: on this one, right, yeah, one percent. I hope it's
Speaker 1: spitting all kinds of warnings out, at least that they'll
Speaker 1: happily ignore along with the other five hundred warnings, unless
Speaker 1: you have warnings as errors errors, in which case, if
Speaker 1: you go through the list, it all works all right.
Speaker 2: Sorry, Scott, let's keep going.
Speaker 3: You're good. So number ten, although I think I'm gonna
Speaker 3: sneak in eleventh here, but uh, Number ten is a
Speaker 3: feature called central package management. So this has been in
Speaker 3: dot net since dot net six. But I when I
Speaker 3: gave this talk at a conference, I asked how many
Speaker 3: people are using this? And probably ten percent of the
Speaker 3: room raise their hands. So even though this has been
Speaker 3: out for a number of years, people still aren't using it.
Speaker 2: It's like four years now that central packages around yep.
Speaker 3: So the kind of the problem it solves is you
Speaker 3: might have multiple projects in your solution that reference the
Speaker 3: same package. Like let's say you've got multiple test projects
Speaker 3: and you're using x unit or n unit or whatever
Speaker 3: the case is. Well, now when you want to upgrade that,
Speaker 3: you got to kind of touch multiple CS projects to
Speaker 3: kind of upgrade them all to the same version. Or
Speaker 3: maybe you have anyy framework in multiple pack projects or
Speaker 3: whatever the case is. So the ADA behind central package
Speaker 3: management is to centralize that so you have one spot
Speaker 3: to upgrade your package is not multiple. So you put
Speaker 3: a directory dot packages dot props file at the root
Speaker 3: of your project and you kind of define saying, hey,
Speaker 3: I want x unit, I want anity framework, here's the
Speaker 3: version I want. And then in your cs prode you
Speaker 3: just say, hey, the cs proge references Entity framework and
Speaker 3: you don't have a version in your cs proge. And
Speaker 3: because that's now managed centrally, right, so now you can
Speaker 3: keep everything in sync. You don't have to worry about like, oh,
Speaker 3: I'm upgrading dot net ten, I need to go upgrade
Speaker 3: all my packages the ten dot x in all my
Speaker 3: different projects. I can just do that centrally in the
Speaker 3: directory packages prop style. And this works in Visual Studio Writer,
Speaker 3: so there's integrations there too. So any ID you're using
Speaker 3: most likely has integrations with it at this point, so yeah,
Speaker 3: super easy.
Speaker 2: Yeah, another thing you should just be on. Hey, you
Speaker 2: were talking about more about testing, like, we obviously are
Speaker 2: keen to use tools, but what do you what's your
Speaker 2: approach to testing?
Speaker 3: That was gonna be my last thing I was going
Speaker 3: to talk about was of.
Speaker 2: Course I'm stealing your thunder brother, I, So I apologize.
Speaker 3: So I guess first off, I'll say, like automated tests,
Speaker 3: you should be doing it at this point.
Speaker 2: Yes, And the tooling is so good now right, Really
Speaker 2: we're running out of excuses yep.
Speaker 3: And I find most companies I work with now I
Speaker 3: don't have to convince them of this. But ten years
Speaker 3: ago that was a different story. Sure, because they've done
Speaker 3: like research, the Dora DevOps Research Assessment did a bunch
Speaker 3: of studies and basically one of the things that they
Speaker 3: proved was when they interviewed a bunch of software teams,
Speaker 3: like tens of thousands of software teams, that you move
Speaker 3: faster with tests, long term and with higher quality. So
Speaker 3: but I think it's even more important in this era
Speaker 3: of agentic coding. Like I mentioned, it keeps it on
Speaker 3: the rail, keeps a on the rails. I've been in
Speaker 3: projects that are have minimal tests versus ones that have
Speaker 3: a lot of tests, and AI does a way better
Speaker 3: job when they have those rails. So I personally use
Speaker 3: x unit for automated tests, but I don't get too
Speaker 3: caught up in it, Like the more important thing is
Speaker 3: you're writing tests, not that you're using x unit VERSU
Speaker 3: nd unit. Maybe not MS test. Don't do that one.
Speaker 3: Just kidding, Just have to take a shot at Microsoft.
Speaker 3: You're not kidding, come on, yeah, uh, but Microsoft themselves
Speaker 3: actually use x unit for dot net, the dot net
Speaker 3: repos and ASPN core repos. You can go see and
Speaker 3: they're using x unit. Little thing people don't know is
Speaker 3: there's x unit came out with a V three package
Speaker 3: about a year ago, and it's not just a version upgrade.
Speaker 3: It's actually called x unit dot v three. So if
Speaker 3: you want to get the new latest bits of x unit,
Speaker 3: you need to install that package. So I'm not going
Speaker 3: to get into the y. They didn't just bump the
Speaker 3: version instead create a new package. But a lot of
Speaker 3: people don't know that that it's a whole separate package.
Speaker 3: So I just want to call that out.
Speaker 2: Well, it was breaking changes, wasn't it. Fundamentally? That was
Speaker 2: the issue.
Speaker 3: Yep, it was breaking changes, and it was enough that
Speaker 3: the main primary maintainer thought it warranted a whole new
Speaker 3: package name, not just a higher version. So yeah, some
Speaker 3: people disagree, but right or wrong, that's what That's what
Speaker 3: the reality is.
Speaker 2: So yeah, but.
Speaker 3: As I'm creating tests, I start to sometimes what people
Speaker 3: do when they create tests is they have a lot
Speaker 3: of setup code, so like the arrange step step in
Speaker 3: arrange act assert And so I want to kind of
Speaker 3: call call back to this idea of Chekhov's gun, which is, uh,
Speaker 3: Chekhov was a.
Speaker 2: Russian playwright, sick, yeah, metamorphosis.
Speaker 3: He's a Russian playwright who basically said, if a gun
Speaker 3: is hanging on the wall in the first act, it
Speaker 3: should fire in a later act of the play. Otherwise
Speaker 3: it shouldn't be hanging there. So basically, removed should be mentioned. Yes,
Speaker 3: remove what's not relevant to the story. And now everybody's
Speaker 3: brains are racking all the shows that they've seen, where
Speaker 3: like Game of Thrones that didn't actually have a lot
Speaker 3: of relevance to the story later on, So yes they did.
Speaker 1: Speaking of irrelevant, Metamorphosis was written by Kafka and not Chekhov. Sorry,
Speaker 1: about that. You're good, I got my Russian authors mixed up.
Speaker 3: And so we can actually apply that same logic of
Speaker 3: remove what's not relevant to the story to our tests,
Speaker 3: because lots of times I come into tests and there's
Speaker 3: like five ten twenty fifty lines of code for the
Speaker 3: range step, and then I go to the next next
Speaker 3: test and there's five ten twenty fifty lines of the
Speaker 3: range step, but there's like one slight difference and at
Speaker 3: a glance I can't tell what the difference is.
Speaker 2: Yeah, So instead covering so much code.
Speaker 3: Yeah, and instead I want to like rip that out
Speaker 3: and have the setup be more centralized in some way. Now,
Speaker 3: there's lots of different ways to do this. You might
Speaker 3: have a method do this, or an end unit you
Speaker 3: can put it in a setup method, or an ex
Speaker 3: unit you can put in constructor. But a lot of
Speaker 3: times if I set up the happy path in whatever
Speaker 3: setup construct that I have, then I'm just tweaking sad
Speaker 3: paths in my test. And it's super obvious that, like, oh,
Speaker 3: I'm setting first name to NOL and then I'm asserting that, hey,
Speaker 3: I get an error message when first name is NOL,
Speaker 3: And it's super easy to see versus you know, five
Speaker 3: to twenty lines of setup that it's hard to pick out. Oh,
Speaker 3: it's the null that's different. Right, So something to think
Speaker 3: about when you're writing tests is, hey, what's actually relevant
Speaker 3: to the story and what can I rip out and
Speaker 3: make it a little bit easier at a glance? What's
Speaker 3: different about this test versus a different test in this file.
Speaker 3: So so that's just kind of a concept you can apply.
Speaker 3: Is that Chekhov's gun concept of remove what's not relevant
Speaker 3: to the story when it applies comes to your test.
Speaker 1: Good stuff, And if you're using AI to write your tests,
Speaker 1: then make sure you put that in the system prompt yep,
Speaker 1: for sure.
Speaker 2: Yeah, AI's applied Chekhov's gun. Yeah.
Speaker 3: AI is really good at following pattern So if you
Speaker 3: don't do that from the get go, it will start
Speaker 3: to just proliferate that through your code base.
Speaker 2: Yeah, it's fair enough.
Speaker 1: This is such good advice, Scott, And it reminds me
Speaker 1: of the pattern and practices blocks that we used to use.
Speaker 2: Back in the day.
Speaker 1: Back in the day. Yeah, just the right way to
Speaker 1: do logging and the right way to do database access
Speaker 1: and all that stuff. And of course those things change
Speaker 1: and things get irrelevant, but it's really great to hear
Speaker 1: your your thoughts and they're they're wonderful, So thank you.
Speaker 3: Yeahoris, it's from a lot of pain I've experienced over
Speaker 3: the years, so trying to distill that pain into sure
Speaker 3: tips for people to go back and apply immediately back
Speaker 3: at work.
Speaker 2: Great. Well, thanks again, Scott.
Speaker 1: It's been great talking to you and we'll talk to
Speaker 1: you next time on dot net rocks. Dot net Rocks
Speaker 1: is brought to you by Franklin's Net and produced by
Speaker 1: Pop Studios, a full service audio, video and post production
Speaker 1: facility located physically in New London, Connecticut, and of course
Speaker 1: in the cloud online at pwop dot com.
Speaker 4: Visit our website at d O T N E T
Speaker 4: R O c k S dot com for RSS feeds, downloads,
Speaker 4: mobile apps, comments, and access to the full archives going
Speaker 4: back to show number one, recorded in September two.
Speaker 2: Thousand and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business.
Speaker 2: Now go write some code, see you next time. You
Speaker 2: got a Javans
Speaker 3: And